1860 年的伦敦街头大约有三十万匹马在拉车、运货、载人。围绕这些马形成了完整的产业链马夫、马具匠、兽医、马厩清洁工、马车制造商、马粪清运工——无数人的生计和这个四蹄动物绑定在一起。然后汽车来了。按照当时最悲观的预测司机们会失业马车业会崩溃。最终的结果比这更残酷马真的被淘汰了但人的工作岗位并没有消失。今天全世界的汽车保有量数以亿计从事运输、物流、出行服务的人比马车时代多了不知道多少倍。真正消失的是所有能力组合恰好等于驾驭马匹的工作。这就是这个标题想讨论的问题当 AI 开始写代码、写方案、画图、做数据的时代到来我们会不会成为那匹被替换的马我的判断是AI 不会让人变得多余但会让某些技能组合恰好等于熟练工的人处境非常危险。而且在程序员这个行业这场变化已经开始只是它不以岗位消失的形式出现而是以任务重组的形式出现。这篇文章会拆解三件事一是为什么替代发生在任务层面而不是岗位层面二是程序员工作中哪些任务正在被 AI 改变哪些真的无法替代三是摆在每个开发者面前的可执行转型路径。1. 马被淘汰这个故事里真正被误解的东西人类在讨论新技术取代工作时总是抓住职业会不会消失这个命题但历史给出的答案通常是职业不会消失职业会重组。马车夫这个职业确实消失了。但它的消失不是突然的而是一个渐变过程最初是马车夫学会修车、加油变成汽车驾驶员然后是驾驶员学会看地图、规划路线变成客运从业者再后来是客运从业者面对调度系统、移动互联网变成平台司机。职业名称换了技能栈换了但把人和货物从 A 点运到 B 点这个需求从来都在而且需求总量在急剧膨胀。所以所谓替代真正发生的位置不是职业而是任务。马车时代的职业由一堆任务构成驾驭马匹、维护马具、判断路况、喂养照料。汽车出现后其中一部分任务被机器取代了另一部分任务则被重新组合形成新的职业。这个规律放在 AI 时代同样成立。一个程序员的日常工作可以拆解成几十个任务写接口、写 SQL、查日志、修 Bug、写测试、做代码评审、梳理需求、设计架构、排查线上事故。AI 不会说我要代替程序员它只会逐个任务地渗透——今天帮你生成一个 CRUD 接口明天帮你写一条复杂 SQL后天替你根据报错日志定位问题。等这些任务被逐个蚕食掉之后程序员这个职业还存在但岗位对技能的要求已经彻底变了。这跟马的处境有本质区别但也因此更需要警惕马的问题是它的技能上限摆在那里而人的问题是——很多人明明可以学会新技能却因为舒适区而选择继续待在只需要重复技能的位置上。如果只看表面很容易误以为 AI 和以前的技术革新没有区别反正总是旧岗位消失新岗位出现。但真正需要看清楚的是以前的技术革新一代就是几十年人的技能可以慢慢更替而 AI 的能力迭代是按月算的。这意味着任务重组的周期被急剧压缩了。一个开发者如果在两三年内没有完成技能组合的调整他的处境就会非常接近那匹尽力拉车但不再被需要的马。2. 人类工作的替代规律替代发生在任务层不是岗位层要理解 AI 对就业的影响需要先建立一个分析工具任务分解法。任何一个岗位本质上都是若干任务的集合。以程序员为例可以这样拆任务类型具体内容自动化难度当前 AI 能力规则明确的编码CRUD 接口、样板代码、常规工具类低已能胜任信息查找与转换日志分析、格式转换、代码翻译低已能胜任测试生成单测用例、边界值枚举中低已能胜任大部分复杂逻辑实现业务规则、状态机、算法定制中需要人定义约束跨模块设计架构设计、技术选型、接口契约定义高只能辅助建议问题定位线上故障排查、性能瓶颈分析中高能缩小范围不能负最终责任需求澄清把模糊业务诉求变成技术方案高几乎不能独立完成从工业革命到信息革命自动化一直遵循一个规律越是规则明确、重复度高、可编码的任务越容易被替代。过去被替代的大多是体力型任务比如搬砖、拧螺丝、收割庄稼。这次 AI 带来的变化是大量认知型规则任务也开始被替代了。什么是认知型规则任务就是不需要体力但也并不需要真正意义上的创造力的工作根据模板写一份合同、把需求翻译成接口代码、把一段 Java 翻译成 Python、按固定的规则审核一张报表。这些任务在过去被认为怎么说也是坐办公室的脑力活但讽刺的是它们的规则性越强越容易被大模型学会。这里有一个关键判断AI 现在更像是一个非常熟悉规则但没有业务判断力的初级工程师。它可以在几秒内完成一个熟练工半小时的编码任务但它不理解业务的目标是什么、客户真正的痛点在哪里、这个功能上线后对系统稳定性意味着什么。更深一层的问题是当大量初级任务被 AI 接管之后从初级工程师成长为中高级工程师的路径会断掉。以前一个应届生可以靠写两年代码练出业务 sense现在这一步被跳过了直接面对的是如何定义问题、如何做取舍、如何对系统整体负责这些高级要求。这就是为什么纯执行者的处境最危险。因为纯执行者的技能组合里大部分是规则明确的任务而这些正是 AI 当前最擅长替代的部分。3. 在程序员身上AI 已经改了哪些任务把视角从宏观拉回来看程序员的具体工作。细数目前 AI 编程工具已经能稳定完成的任务大致有这七类。第一样板代码生成。包括 Spring Boot 的 Controller-Service-Mapper 三层结构、 MyBatis 的 XML 文件、 DTO 定义、常量类、异常类。这类代码规则固定AI 生成的准确率很高。第二跨语言代码翻译。把 Java 片段翻译成 Python把 JavaScript 翻译成 TypeScript把旧框架写法改成新框架写法。AI 在语法层面基本不出错但需要人工检查语义是否完整。第三单元测试生成。给定一个方法AI 可以生成覆盖正常路径、异常路径、边界条件的测试用例。它能处理的覆盖率远超多数人手写测试的意愿。第四SQL 编写与优化建议。根据表结构生成查询语句、解释执行计划、推荐索引。这是 AI 编程工具中实用性最高的能力之一。第五日志与报错分析。把一段堆栈日志贴给 AI它通常能指出哪个类、哪一行可能出了问题。这在联调阶段能节省大量时间。第六代码审查辅助。让 AI 帮忙检查空指针风险、资源泄漏、SQL 注入隐患它虽然不能替代人的代码评审但可以提前过滤掉一部分低级问题。第七技术文档与注释。生成接口文档、数据库说明、README、代码注释。这件事很多开发者不喜欢做恰好是 AI 最擅长的。可以用一个最典型的实战场景来说明这些能力是怎么组合起来的。假设现在需要给用户模块新增一个邮箱注册接口过去的流程是查其他模块的写法、复制粘贴改一改、写参数校验、写异常处理、启动服务用 Postman 调一遍。现在可以直接这样提示 AI请为一个用户模块生成 Spring Boot 接口包含邮箱注册、登录、查询用户信息。 要求 - 使用 Spring Boot 3 MyBatis-Plus - 密码使用 BCrypt 加密存储 - 登录成功返回 JWT token包含用户 ID 和角色 - 使用 jakarta.validation 做参数校验 - 邮箱格式校验规则标准邮箱格式长度不超过 64 - 重复注册时抛出 BizException错误码为 USER_EMAIL_EXISTSAI 会直接生成类似这样的代码结构// 文件路径src/main/java/com/example/demo/controller/UserController.java RestController RequestMapping(/api/users) public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } PostMapping(/register) public ResultVoid register(RequestBody Valid RegisterRequest request) { userService.registerByEmail(request); return Result.success(); } PostMapping(/login) public ResultLoginResponse login(RequestBody Valid LoginRequest request) { return Result.success(userService.loginByEmail(request)); } GetMapping(/{id}) public ResultUserVO getUser(PathVariable Long id) { return Result.success(userService.getUserById(id)); } }看起来确实很快但这里真正容易踩坑的地方在于AI 可以生成接口的骨架却无法替你决策业务上是否允许同一个邮箱注册多个账号、登录失败五次是否要锁定、token 过期时间应该多长。这些规则决定了接口的字段、状态的流转、异常分支的写法AI 只会根据提示词里的约束生成而不会主动追问。所以AI 编程工具显著降低的是从设计到代码的转换成本但它没有降低从业务到设计的思考成本。那些声称AI 让程序员失业的说法和那些认为AI 写完代码就能直接上线的做法其实踩的是同一个坑把代码生成当成了软件开发的全部。4. 当 Agent 开始接活从工具到半自动员工前面讨论的还是人用 AI 工具。另一个正在快速演进的趋势是 AI Agent——它不再等人类一条一条地发指令而是接收一个目标后自己拆解步骤、调用工具、逐步执行直到完成任务。对开发者来说Agent 带来的变化比单纯的代码补全大得多。Copilot 类的工具是人负责想清楚每一步AI 负责把某一步写快一点Agent 则反过来是人给出目标AI 负责把很多步骤都跑完人只在关键节点做确认。举一个具体场景。假设线上有一个用户登录接口偶发空指针异常的 Bug。传统排查流程是翻日志、找堆栈、定位代码、分析调用链、改代码、加测试、回归验证。这个过程可能需要一个开发人员半天时间。而一个配置完整的开发 Agent 可以这样工作# agent-workflow.yaml # 仅展示配置思路实际字段以你选用的 Agent 框架为准 name: bug-fixer-agent description: 定位并修复代码缺陷的智能体 model: 按部署环境实际配置 tools: - search_codebase # 检索代码库 - read_file # 读取文件 - create_patch # 生成修改补丁 - run_test # 执行测试 - git_diff # 对比改动 human_approval: - before_create_patch # 生成补丁前需要人工确认 - before_push # 推送前需要人工确认Agent 的执行链路是读取错误日志中的堆栈 → 在代码库中定位到对应方法 → 分析调用链上哪个方法可能返回 null → 生成一个修复补丁 → 运行相关测试验证 → 输出差异说明等待人工确认。这个过程已经非常接近一个初级工程师的工作方式。但注意我在这里加了一个关键配置human_approval。这不是多余的而是必须的。因为 AI 会把看似正确当作真的正确——一个 Agent 在修改代码后如果测试恰好没有被覆盖到出错的场景它很可能自信地告诉你已修复然后把这个改动提交上去。这就是业界常说 AI 幻觉问题在 Agent 场景里的放大效应幻觉不再只是一段文本生成错误而是变成了一处错误的代码修改。所以Agent 的第一性原理是人在环上不是人不在环上。Agent 可以跑完 80% 的流程但 20% 的关键决策点必须有人确认比如改动的方案是否符合团队规范是否影响其他模块是否引入了新的风险边界。那些试图把 Agent 变成全自动无人值守程序的做法本质上就是在拿生产系统的稳定性给 AI 的幻觉买单。从这个角度看AI Agent 对开发者的意义不是取代而是把开发者从写每一行代码中解放出来推到一个更上游的位置——定义目标、设计约束、验证结果。但前提是你得具备判断 AI 做得好不好的能力否则你连确认都不知道该怎么确认。5. 程序员真的会变成马吗哪些能力不可替代如果只把眼光放在AI 能做什么很容易得出悲观的结论。但换一个角度去看那些 AI 虽然能做但不敢负责的事才是人真正的护城河。第一问题定义能力。真实世界的需求从来不是清晰的。业务方说做一个用户等级体系具体是几个等级、升降级条件是什么、过期时间怎么算、对外的展示规则是什么这些都需要人去澄清、去定义、去用技术语言把模糊诉求翻译成可执行边界。AI 只能基于已经定义好的规则生成代码它无法在需求不明确的时候向业务方提出好问题。第二架构判断能力。同样是系统变慢了可能的原因有几十种数据库索引失效、代码死循环、缓存穿透、网络带宽瓶颈、第三方接口超时。初级工程师容易直接翻代码而资深工程师会先画出一张请求链路图逐层排查定位问题的层次再决定用什么手段解决。这种先定位故障层次、再选择方案的判断力AI 短时间学不会。它可以辅助你查日志、做分析但无法替你说这里不应该加索引应该改表结构。第三质量与成本权衡能力。技术上正确的方案往往不是最合适的方案。一个功能可以用分布式事务保证强一致也可以改成最终一致把复杂度转移到业务层一条 SQL 可以优化到极致但可能让代码可读性变得极差。做这种权衡需要理解业务价值、团队能力、系统现状、上线节奏这不是一个纯逻辑推理问题而是一个在约束条件下做决策的问题AI 不具备这种现实的权重判断。第四责任承担能力。AI 可以生成一段代码但不会对它的运行后果负责。线上发生事故时值班电话会打给团队里的真人合同由公司签名合规风险由企业承担。这看起来是制度问题实际上是能力问题——愿意承担责任的唯一前提是你自信自己已经理解了系统、理解了变更的影响边界。这种责任感无法外包给大模型。用马的类比讲当年留下来的不是跑得更快的马而是会开车的人。马的悲剧在于它无法改变自己的能力结构而人的优势在于可以重新组合技能。对程序员来说真正的转型不是和 AI 比赛写代码的速度而是把能力重心从写代码的动作移到定义问题、验证结果、承担判断这些 AI 短期无法接管的位置上。6. 从写代码的人到验证代码的人技能组合的转型清单判断是认知层面的行动才是技术层面的。对普通开发者来说与其焦虑AI 会不会取代我不如先做一次小范围评估和转型。这里给出一份可以直接执行的行动清单。第一步列出你过去一个月的任务清单。具体到任务颗粒度比如写了 10 个 CRUD 接口排查了 5 个线上 Bug整理了 2 份数据库文档设计了 1 个活动页方案。然后给每个任务标记AI 能不能独立完成如果能完成的质量是否稳定这个标记过程就是你个人的被替代风险扫描。第二步把 AI 能用好的任务交给 AI把省出来的时间投到不可替代的任务上。如果你发现自己大量的时间消耗在写样板代码和查日志上这不是坏消息这说明你有机会把时间转移到需求分析、架构设计、代码评审上。第三步建立自己的验证工作台。当 AI 生成代码成为常态验证能力就是你的核心生产力。你需要一套稳定的本地验证命令。比如AI 改完一个模块后你可以这样快速验证# 以 Java 项目为例编译、测试、静态检查 mvn compile mvn test -DtestUserServiceTest mvn spotbugs:check如果是 Python 项目# 以 Python 项目为例运行测试 lint 类型检查 pytest tests/test_user_service.py -x -q ruff check src/user_service/ mypy src/user_service/验证不是跑一遍测试就完事而是要对 AI 输出的代码带着审查意识去读。重点看几个地方有没有空指针隐患、有没有跳过异常处理、SQL 有没有拼接风险、事务边界是否被破坏、对外的接口返回结构是否有变化。如果你不知道从哪开始可以直接把代码贴给 AI让它按安全维度过一遍请审查下面这段代码重点检查 1. 是否存在空指针风险 2. 是否有 SQL 注入或路径穿越风险 3. 事务边界是否正确是否可能出现事务失效 4. 是否存在资源泄漏比如未关闭的连接或流 5. 极端输入下行为是否正确比如空字符串、超长字符串、并发请求 代码 java // 这里粘贴你需要审查的代码注意用 AI 审查 AI 的代码也是一种可行的效率策略但最终你要亲自看一遍关键路径。因为 AI 审查输出的结论同样是概率性的它可能漏掉你项目里的特定上下文。 第四步刻意练习提示词即需求文档的能力。AI 生成代码的质量高度取决于你给出的约束粒度。习惯于把提示词写成包含背景、功能、约束、边界、验收标准的完整描述这个习惯倒逼你把需求想清楚而这恰好是 AI 无法替代的能力。 第五步建立个人知识库。把常用的提示词模板、AI 生成的优秀代码片段、验证命令、团队规范沉淀下来。未来的开发效率差距很大程度上是提示词资产的差距。你的知识库越厚你离验证者的位置就越近离马的位置就越远。 ## 7. 团队层面AI 正在重构软件开发流程 个体开发者的变化如果放大到团队和组织层面看到的就是整个软件交付流程的重构。一个团队引入 AI 编程工具之后最先变化的通常是代码评审环节。以前的代码评审评审者看的是实现是否符合需求;现在由于大量代码由 AI 生成评审者要看的是这个 AI 生成实现是否被正确约束——有没有漏掉业务规则、有没有隐藏的安全问题、有没有不符合团队架构的地方。 另一个变化发生在需求阶段。传统流程中产品经理给出需求文档开发者自己理解、自己补充细节。AI 时代需求描述本身成为重要的生产资料。因为提示词的质量直接决定 AI 输出代码的质量。那些能把需求写得足够明确的团队AI 的辅助效果显著反之需求模糊的团队AI 只能在一堆歧义中生成看起来正确但实际跑不通的代码。 测试环节也同样在被改变。AI 可以快速生成大量测试用例但判断这些用例是否有效、是否覆盖了真正的高风险路径仍然需要人工。更关键的是AI 生成的代码在边界条件下容易出错测试的覆盖面恰恰应该向这些方向倾斜。 这里还需要强调工程化的问题。AI 的能力再强要落到生产环境依然绕不开模型部署、上下文管理、成本控制、输出校验这些工程问题。AI 写代码这件事本身不难难的是把 AI 的能力安全地嵌入到现有的开发、测试、发布、回滚体系里。这就解释了为什么AI 工程实践和AI 应用开发正在成为热门方向——AI 不是拿来即用的黑盒它同样需要被工程化管理。 团队在引入 AI 协作时可以考虑制定一份内部规范明确什么场景可以用 AI 直接生成、什么场景必须人工编写、什么场景需要额外审查。给出一个配置思路 properties # ai-development-guidelines.properties # 仅展示配置思路具体字段与值由团队自行定义 # 是否允许 AI 生成代码 ai.codegen.enabledtrue # AI 生成的代码是否必须经过人工评审 ai.review.requiredtrue # 禁止 AI 直接生成/修改的敏感模块清单 ai.blocked.scopeauth,payment,migration # 关键路径是否需要额外的人工测试 ai.manual-test.requiredcritical-path这类规范的核心不是限制 AI 的使用而是建立风险边界。AI 是一把很快的刀用得好能大幅提高效率用不好会快速在生产环境制造事故。规范的目的是把看起来很快变成稳定地快。8. 关于人会不会失业一个更准确的说法回到标题里的那个问题当世界不再需要马的那一天马没有选择但人有。与其争论AI 会不会取代程序员不如把问题重新定义一遍你的任务组合里有多少比例是 AI 现在就能稳定完成的有多少比例需要人的判断和决策。前者比例越高你越接近那匹正在被汽车时代逼近的马后者比例越高你就越接近开着汽车的人。对程序员来说最危险的状态不是不会用 AI 工具而是误以为自己的价值等于会写某种语言的代码。语言会变框架会变工具会变但把模糊问题定义清楚、在约束条件下做决策、对技术结果负责这些能力是穿越技术周期的底层能力。马不可能学会开车但人可以。这也是人和马最大的区别。接下来的方向已经很清楚了把 AI 当成一个能力极强的初级协作对象学会给它清晰的任务描述学会审查它的产出然后把省下来的时间投入到那些真正需要人的判断力的工作中。建议你先从一个最小的任务开始——挑一个手头的工作尝试用 AI 完成初稿再亲手审查、修改、验证一遍。这个过程会比你读十篇文章更能让你感受到自己所处的位置。如果你对提示词工程、AI 编程工具选型、AI Agent 开发、以及如何在团队中落地 AI 辅助开发流程感兴趣后续可以沿着这几个方向继续深入。技术变化很快但判断力永远是硬通货。 AI取代程序员？真正的危机是任务重组而非岗位消失
1860 年的伦敦街头大约有三十万匹马在拉车、运货、载人。围绕这些马形成了完整的产业链马夫、马具匠、兽医、马厩清洁工、马车制造商、马粪清运工——无数人的生计和这个四蹄动物绑定在一起。然后汽车来了。按照当时最悲观的预测司机们会失业马车业会崩溃。最终的结果比这更残酷马真的被淘汰了但人的工作岗位并没有消失。今天全世界的汽车保有量数以亿计从事运输、物流、出行服务的人比马车时代多了不知道多少倍。真正消失的是所有能力组合恰好等于驾驭马匹的工作。这就是这个标题想讨论的问题当 AI 开始写代码、写方案、画图、做数据的时代到来我们会不会成为那匹被替换的马我的判断是AI 不会让人变得多余但会让某些技能组合恰好等于熟练工的人处境非常危险。而且在程序员这个行业这场变化已经开始只是它不以岗位消失的形式出现而是以任务重组的形式出现。这篇文章会拆解三件事一是为什么替代发生在任务层面而不是岗位层面二是程序员工作中哪些任务正在被 AI 改变哪些真的无法替代三是摆在每个开发者面前的可执行转型路径。1. 马被淘汰这个故事里真正被误解的东西人类在讨论新技术取代工作时总是抓住职业会不会消失这个命题但历史给出的答案通常是职业不会消失职业会重组。马车夫这个职业确实消失了。但它的消失不是突然的而是一个渐变过程最初是马车夫学会修车、加油变成汽车驾驶员然后是驾驶员学会看地图、规划路线变成客运从业者再后来是客运从业者面对调度系统、移动互联网变成平台司机。职业名称换了技能栈换了但把人和货物从 A 点运到 B 点这个需求从来都在而且需求总量在急剧膨胀。所以所谓替代真正发生的位置不是职业而是任务。马车时代的职业由一堆任务构成驾驭马匹、维护马具、判断路况、喂养照料。汽车出现后其中一部分任务被机器取代了另一部分任务则被重新组合形成新的职业。这个规律放在 AI 时代同样成立。一个程序员的日常工作可以拆解成几十个任务写接口、写 SQL、查日志、修 Bug、写测试、做代码评审、梳理需求、设计架构、排查线上事故。AI 不会说我要代替程序员它只会逐个任务地渗透——今天帮你生成一个 CRUD 接口明天帮你写一条复杂 SQL后天替你根据报错日志定位问题。等这些任务被逐个蚕食掉之后程序员这个职业还存在但岗位对技能的要求已经彻底变了。这跟马的处境有本质区别但也因此更需要警惕马的问题是它的技能上限摆在那里而人的问题是——很多人明明可以学会新技能却因为舒适区而选择继续待在只需要重复技能的位置上。如果只看表面很容易误以为 AI 和以前的技术革新没有区别反正总是旧岗位消失新岗位出现。但真正需要看清楚的是以前的技术革新一代就是几十年人的技能可以慢慢更替而 AI 的能力迭代是按月算的。这意味着任务重组的周期被急剧压缩了。一个开发者如果在两三年内没有完成技能组合的调整他的处境就会非常接近那匹尽力拉车但不再被需要的马。2. 人类工作的替代规律替代发生在任务层不是岗位层要理解 AI 对就业的影响需要先建立一个分析工具任务分解法。任何一个岗位本质上都是若干任务的集合。以程序员为例可以这样拆任务类型具体内容自动化难度当前 AI 能力规则明确的编码CRUD 接口、样板代码、常规工具类低已能胜任信息查找与转换日志分析、格式转换、代码翻译低已能胜任测试生成单测用例、边界值枚举中低已能胜任大部分复杂逻辑实现业务规则、状态机、算法定制中需要人定义约束跨模块设计架构设计、技术选型、接口契约定义高只能辅助建议问题定位线上故障排查、性能瓶颈分析中高能缩小范围不能负最终责任需求澄清把模糊业务诉求变成技术方案高几乎不能独立完成从工业革命到信息革命自动化一直遵循一个规律越是规则明确、重复度高、可编码的任务越容易被替代。过去被替代的大多是体力型任务比如搬砖、拧螺丝、收割庄稼。这次 AI 带来的变化是大量认知型规则任务也开始被替代了。什么是认知型规则任务就是不需要体力但也并不需要真正意义上的创造力的工作根据模板写一份合同、把需求翻译成接口代码、把一段 Java 翻译成 Python、按固定的规则审核一张报表。这些任务在过去被认为怎么说也是坐办公室的脑力活但讽刺的是它们的规则性越强越容易被大模型学会。这里有一个关键判断AI 现在更像是一个非常熟悉规则但没有业务判断力的初级工程师。它可以在几秒内完成一个熟练工半小时的编码任务但它不理解业务的目标是什么、客户真正的痛点在哪里、这个功能上线后对系统稳定性意味着什么。更深一层的问题是当大量初级任务被 AI 接管之后从初级工程师成长为中高级工程师的路径会断掉。以前一个应届生可以靠写两年代码练出业务 sense现在这一步被跳过了直接面对的是如何定义问题、如何做取舍、如何对系统整体负责这些高级要求。这就是为什么纯执行者的处境最危险。因为纯执行者的技能组合里大部分是规则明确的任务而这些正是 AI 当前最擅长替代的部分。3. 在程序员身上AI 已经改了哪些任务把视角从宏观拉回来看程序员的具体工作。细数目前 AI 编程工具已经能稳定完成的任务大致有这七类。第一样板代码生成。包括 Spring Boot 的 Controller-Service-Mapper 三层结构、 MyBatis 的 XML 文件、 DTO 定义、常量类、异常类。这类代码规则固定AI 生成的准确率很高。第二跨语言代码翻译。把 Java 片段翻译成 Python把 JavaScript 翻译成 TypeScript把旧框架写法改成新框架写法。AI 在语法层面基本不出错但需要人工检查语义是否完整。第三单元测试生成。给定一个方法AI 可以生成覆盖正常路径、异常路径、边界条件的测试用例。它能处理的覆盖率远超多数人手写测试的意愿。第四SQL 编写与优化建议。根据表结构生成查询语句、解释执行计划、推荐索引。这是 AI 编程工具中实用性最高的能力之一。第五日志与报错分析。把一段堆栈日志贴给 AI它通常能指出哪个类、哪一行可能出了问题。这在联调阶段能节省大量时间。第六代码审查辅助。让 AI 帮忙检查空指针风险、资源泄漏、SQL 注入隐患它虽然不能替代人的代码评审但可以提前过滤掉一部分低级问题。第七技术文档与注释。生成接口文档、数据库说明、README、代码注释。这件事很多开发者不喜欢做恰好是 AI 最擅长的。可以用一个最典型的实战场景来说明这些能力是怎么组合起来的。假设现在需要给用户模块新增一个邮箱注册接口过去的流程是查其他模块的写法、复制粘贴改一改、写参数校验、写异常处理、启动服务用 Postman 调一遍。现在可以直接这样提示 AI请为一个用户模块生成 Spring Boot 接口包含邮箱注册、登录、查询用户信息。 要求 - 使用 Spring Boot 3 MyBatis-Plus - 密码使用 BCrypt 加密存储 - 登录成功返回 JWT token包含用户 ID 和角色 - 使用 jakarta.validation 做参数校验 - 邮箱格式校验规则标准邮箱格式长度不超过 64 - 重复注册时抛出 BizException错误码为 USER_EMAIL_EXISTSAI 会直接生成类似这样的代码结构// 文件路径src/main/java/com/example/demo/controller/UserController.java RestController RequestMapping(/api/users) public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } PostMapping(/register) public ResultVoid register(RequestBody Valid RegisterRequest request) { userService.registerByEmail(request); return Result.success(); } PostMapping(/login) public ResultLoginResponse login(RequestBody Valid LoginRequest request) { return Result.success(userService.loginByEmail(request)); } GetMapping(/{id}) public ResultUserVO getUser(PathVariable Long id) { return Result.success(userService.getUserById(id)); } }看起来确实很快但这里真正容易踩坑的地方在于AI 可以生成接口的骨架却无法替你决策业务上是否允许同一个邮箱注册多个账号、登录失败五次是否要锁定、token 过期时间应该多长。这些规则决定了接口的字段、状态的流转、异常分支的写法AI 只会根据提示词里的约束生成而不会主动追问。所以AI 编程工具显著降低的是从设计到代码的转换成本但它没有降低从业务到设计的思考成本。那些声称AI 让程序员失业的说法和那些认为AI 写完代码就能直接上线的做法其实踩的是同一个坑把代码生成当成了软件开发的全部。4. 当 Agent 开始接活从工具到半自动员工前面讨论的还是人用 AI 工具。另一个正在快速演进的趋势是 AI Agent——它不再等人类一条一条地发指令而是接收一个目标后自己拆解步骤、调用工具、逐步执行直到完成任务。对开发者来说Agent 带来的变化比单纯的代码补全大得多。Copilot 类的工具是人负责想清楚每一步AI 负责把某一步写快一点Agent 则反过来是人给出目标AI 负责把很多步骤都跑完人只在关键节点做确认。举一个具体场景。假设线上有一个用户登录接口偶发空指针异常的 Bug。传统排查流程是翻日志、找堆栈、定位代码、分析调用链、改代码、加测试、回归验证。这个过程可能需要一个开发人员半天时间。而一个配置完整的开发 Agent 可以这样工作# agent-workflow.yaml # 仅展示配置思路实际字段以你选用的 Agent 框架为准 name: bug-fixer-agent description: 定位并修复代码缺陷的智能体 model: 按部署环境实际配置 tools: - search_codebase # 检索代码库 - read_file # 读取文件 - create_patch # 生成修改补丁 - run_test # 执行测试 - git_diff # 对比改动 human_approval: - before_create_patch # 生成补丁前需要人工确认 - before_push # 推送前需要人工确认Agent 的执行链路是读取错误日志中的堆栈 → 在代码库中定位到对应方法 → 分析调用链上哪个方法可能返回 null → 生成一个修复补丁 → 运行相关测试验证 → 输出差异说明等待人工确认。这个过程已经非常接近一个初级工程师的工作方式。但注意我在这里加了一个关键配置human_approval。这不是多余的而是必须的。因为 AI 会把看似正确当作真的正确——一个 Agent 在修改代码后如果测试恰好没有被覆盖到出错的场景它很可能自信地告诉你已修复然后把这个改动提交上去。这就是业界常说 AI 幻觉问题在 Agent 场景里的放大效应幻觉不再只是一段文本生成错误而是变成了一处错误的代码修改。所以Agent 的第一性原理是人在环上不是人不在环上。Agent 可以跑完 80% 的流程但 20% 的关键决策点必须有人确认比如改动的方案是否符合团队规范是否影响其他模块是否引入了新的风险边界。那些试图把 Agent 变成全自动无人值守程序的做法本质上就是在拿生产系统的稳定性给 AI 的幻觉买单。从这个角度看AI Agent 对开发者的意义不是取代而是把开发者从写每一行代码中解放出来推到一个更上游的位置——定义目标、设计约束、验证结果。但前提是你得具备判断 AI 做得好不好的能力否则你连确认都不知道该怎么确认。5. 程序员真的会变成马吗哪些能力不可替代如果只把眼光放在AI 能做什么很容易得出悲观的结论。但换一个角度去看那些 AI 虽然能做但不敢负责的事才是人真正的护城河。第一问题定义能力。真实世界的需求从来不是清晰的。业务方说做一个用户等级体系具体是几个等级、升降级条件是什么、过期时间怎么算、对外的展示规则是什么这些都需要人去澄清、去定义、去用技术语言把模糊诉求翻译成可执行边界。AI 只能基于已经定义好的规则生成代码它无法在需求不明确的时候向业务方提出好问题。第二架构判断能力。同样是系统变慢了可能的原因有几十种数据库索引失效、代码死循环、缓存穿透、网络带宽瓶颈、第三方接口超时。初级工程师容易直接翻代码而资深工程师会先画出一张请求链路图逐层排查定位问题的层次再决定用什么手段解决。这种先定位故障层次、再选择方案的判断力AI 短时间学不会。它可以辅助你查日志、做分析但无法替你说这里不应该加索引应该改表结构。第三质量与成本权衡能力。技术上正确的方案往往不是最合适的方案。一个功能可以用分布式事务保证强一致也可以改成最终一致把复杂度转移到业务层一条 SQL 可以优化到极致但可能让代码可读性变得极差。做这种权衡需要理解业务价值、团队能力、系统现状、上线节奏这不是一个纯逻辑推理问题而是一个在约束条件下做决策的问题AI 不具备这种现实的权重判断。第四责任承担能力。AI 可以生成一段代码但不会对它的运行后果负责。线上发生事故时值班电话会打给团队里的真人合同由公司签名合规风险由企业承担。这看起来是制度问题实际上是能力问题——愿意承担责任的唯一前提是你自信自己已经理解了系统、理解了变更的影响边界。这种责任感无法外包给大模型。用马的类比讲当年留下来的不是跑得更快的马而是会开车的人。马的悲剧在于它无法改变自己的能力结构而人的优势在于可以重新组合技能。对程序员来说真正的转型不是和 AI 比赛写代码的速度而是把能力重心从写代码的动作移到定义问题、验证结果、承担判断这些 AI 短期无法接管的位置上。6. 从写代码的人到验证代码的人技能组合的转型清单判断是认知层面的行动才是技术层面的。对普通开发者来说与其焦虑AI 会不会取代我不如先做一次小范围评估和转型。这里给出一份可以直接执行的行动清单。第一步列出你过去一个月的任务清单。具体到任务颗粒度比如写了 10 个 CRUD 接口排查了 5 个线上 Bug整理了 2 份数据库文档设计了 1 个活动页方案。然后给每个任务标记AI 能不能独立完成如果能完成的质量是否稳定这个标记过程就是你个人的被替代风险扫描。第二步把 AI 能用好的任务交给 AI把省出来的时间投到不可替代的任务上。如果你发现自己大量的时间消耗在写样板代码和查日志上这不是坏消息这说明你有机会把时间转移到需求分析、架构设计、代码评审上。第三步建立自己的验证工作台。当 AI 生成代码成为常态验证能力就是你的核心生产力。你需要一套稳定的本地验证命令。比如AI 改完一个模块后你可以这样快速验证# 以 Java 项目为例编译、测试、静态检查 mvn compile mvn test -DtestUserServiceTest mvn spotbugs:check如果是 Python 项目# 以 Python 项目为例运行测试 lint 类型检查 pytest tests/test_user_service.py -x -q ruff check src/user_service/ mypy src/user_service/验证不是跑一遍测试就完事而是要对 AI 输出的代码带着审查意识去读。重点看几个地方有没有空指针隐患、有没有跳过异常处理、SQL 有没有拼接风险、事务边界是否被破坏、对外的接口返回结构是否有变化。如果你不知道从哪开始可以直接把代码贴给 AI让它按安全维度过一遍请审查下面这段代码重点检查 1. 是否存在空指针风险 2. 是否有 SQL 注入或路径穿越风险 3. 事务边界是否正确是否可能出现事务失效 4. 是否存在资源泄漏比如未关闭的连接或流 5. 极端输入下行为是否正确比如空字符串、超长字符串、并发请求 代码 java // 这里粘贴你需要审查的代码注意用 AI 审查 AI 的代码也是一种可行的效率策略但最终你要亲自看一遍关键路径。因为 AI 审查输出的结论同样是概率性的它可能漏掉你项目里的特定上下文。 第四步刻意练习提示词即需求文档的能力。AI 生成代码的质量高度取决于你给出的约束粒度。习惯于把提示词写成包含背景、功能、约束、边界、验收标准的完整描述这个习惯倒逼你把需求想清楚而这恰好是 AI 无法替代的能力。 第五步建立个人知识库。把常用的提示词模板、AI 生成的优秀代码片段、验证命令、团队规范沉淀下来。未来的开发效率差距很大程度上是提示词资产的差距。你的知识库越厚你离验证者的位置就越近离马的位置就越远。 ## 7. 团队层面AI 正在重构软件开发流程 个体开发者的变化如果放大到团队和组织层面看到的就是整个软件交付流程的重构。一个团队引入 AI 编程工具之后最先变化的通常是代码评审环节。以前的代码评审评审者看的是实现是否符合需求;现在由于大量代码由 AI 生成评审者要看的是这个 AI 生成实现是否被正确约束——有没有漏掉业务规则、有没有隐藏的安全问题、有没有不符合团队架构的地方。 另一个变化发生在需求阶段。传统流程中产品经理给出需求文档开发者自己理解、自己补充细节。AI 时代需求描述本身成为重要的生产资料。因为提示词的质量直接决定 AI 输出代码的质量。那些能把需求写得足够明确的团队AI 的辅助效果显著反之需求模糊的团队AI 只能在一堆歧义中生成看起来正确但实际跑不通的代码。 测试环节也同样在被改变。AI 可以快速生成大量测试用例但判断这些用例是否有效、是否覆盖了真正的高风险路径仍然需要人工。更关键的是AI 生成的代码在边界条件下容易出错测试的覆盖面恰恰应该向这些方向倾斜。 这里还需要强调工程化的问题。AI 的能力再强要落到生产环境依然绕不开模型部署、上下文管理、成本控制、输出校验这些工程问题。AI 写代码这件事本身不难难的是把 AI 的能力安全地嵌入到现有的开发、测试、发布、回滚体系里。这就解释了为什么AI 工程实践和AI 应用开发正在成为热门方向——AI 不是拿来即用的黑盒它同样需要被工程化管理。 团队在引入 AI 协作时可以考虑制定一份内部规范明确什么场景可以用 AI 直接生成、什么场景必须人工编写、什么场景需要额外审查。给出一个配置思路 properties # ai-development-guidelines.properties # 仅展示配置思路具体字段与值由团队自行定义 # 是否允许 AI 生成代码 ai.codegen.enabledtrue # AI 生成的代码是否必须经过人工评审 ai.review.requiredtrue # 禁止 AI 直接生成/修改的敏感模块清单 ai.blocked.scopeauth,payment,migration # 关键路径是否需要额外的人工测试 ai.manual-test.requiredcritical-path这类规范的核心不是限制 AI 的使用而是建立风险边界。AI 是一把很快的刀用得好能大幅提高效率用不好会快速在生产环境制造事故。规范的目的是把看起来很快变成稳定地快。8. 关于人会不会失业一个更准确的说法回到标题里的那个问题当世界不再需要马的那一天马没有选择但人有。与其争论AI 会不会取代程序员不如把问题重新定义一遍你的任务组合里有多少比例是 AI 现在就能稳定完成的有多少比例需要人的判断和决策。前者比例越高你越接近那匹正在被汽车时代逼近的马后者比例越高你就越接近开着汽车的人。对程序员来说最危险的状态不是不会用 AI 工具而是误以为自己的价值等于会写某种语言的代码。语言会变框架会变工具会变但把模糊问题定义清楚、在约束条件下做决策、对技术结果负责这些能力是穿越技术周期的底层能力。马不可能学会开车但人可以。这也是人和马最大的区别。接下来的方向已经很清楚了把 AI 当成一个能力极强的初级协作对象学会给它清晰的任务描述学会审查它的产出然后把省下来的时间投入到那些真正需要人的判断力的工作中。建议你先从一个最小的任务开始——挑一个手头的工作尝试用 AI 完成初稿再亲手审查、修改、验证一遍。这个过程会比你读十篇文章更能让你感受到自己所处的位置。如果你对提示词工程、AI 编程工具选型、AI Agent 开发、以及如何在团队中落地 AI 辅助开发流程感兴趣后续可以沿着这几个方向继续深入。技术变化很快但判断力永远是硬通货。