前阵子我花了大半天写了一个批量数据迁移脚本，正想截图纪念一下，然后发现这种“把需求描述清楚，让AI几分钟出活”的事情，最近已经在团队里发生过很多次了。AI写代码越来越快这件事，已经不只是个话题，而是每个开发者手边正在发生的现实：补全能猜出你大半意图，模板代码一键生成，重构任务丢过去就有初版。于是问题就摆到了面前——如果写代码的速度不再是稀缺能力，开发者的价值到底该往哪里走？
我花了几周时间，专门做了一些对比实验和团队观察，也刻意把一部分工作流切换成“AI优先”再切回来。这篇想把我看到的真实变化、踩过的坑、以及最终沉淀下来的协作方式，完整地梳理一遍。适合正在焦虑“会不会被AI替代”的开发者，也适合想认真把AI用起来、又不想被它带偏的团队一起参考。
1. 从“码字速度”到“问题定义速度”：AI真的把瓶颈换了位置
先说我观察到的第一个反直觉现象：代码生成的耗时在大幅缩短，但功能从“开始做”到“真正上线”的总工期，并没有同比例缩短。
以前我们估算一个功能，经常把“写代码需要几天”当作大头。现在这部分被AI压得很低，于是你很快会发现，卡住你的不是打字，而是“到底要做什么”和“做成什么样才算对”。我举一个自己经历的例子：当时想做一个内部的库存查询页面，需求方只给了一句“帮我看看在途库存有没有超期”。我直接让AI生成了一个标准的列表页，字段、分页、筛选都齐全，看起来特别完整。结果需求方看了一眼说，不对——在途库存里有一部分是在运输过程中的，有一部分是已经到达但还没有入库的，这两类要分开展示，而且“超期”要按不同运输渠道的标准分别计算。
这个信息在最初的需求描述里根本没有。AI不可能知道“在途库存”在你们业务里意味着两种状态，也不可能替你判断超期的业务口径。它只能根据你发过去的词，生成一个最平均、最通用的理解。当你把任务描述发出去的时候，真正的思考已经做完了；AI只是负责把你想清楚的东西翻译成代码。
所以我的结论是：AI没有消灭思考环节，它只是把瓶颈从“实现层”顶到了“定义层”。之前你写代码时一边写一边发现需求漏洞，现在这个过程被压缩到了开头。想在AI时代提高交付速度，最值得练的能力不是更快地写代码，而是更快地把模糊需求变成精确、可验证的任务描述。相反，如果你只是把同样模糊的需求丢给AI，然后拿回来改，往往比自己去写还要慢——因为你要在AI的“平均答案”里找出每个不对的细节，相当于做一次双向校验。
这也是为什么我在团队里开始提倡“先写清楚，再写代码”：任务描述花的时间值得占总工期的一半以上。AI只是把编码这一步变成廉价劳动力，但前期的需求分析、边界确认、验收标准设计，都需要人来完成，而且这部分恰恰是价值密度最高的部分。
2. 只给AI三十秒，它能写对什么？写不对什么？
为了搞清楚AI的能力边界，我专门整理了一批典型任务做测试：从简单的工具函数，到复杂的分布式任务调度。结论可以概括成一句话——AI特别擅长“有标准答案”的编码，但非常不擅长“需要理解现场”的决策。
先说它擅长的部分。语法完备的小函数、标准的增删改查接口、常见的算法实现、表单页面、正则表达式、数据格式转换这类任务，AI生成的代码质量相当稳定，基本可以做到“拿来即用”。原因也简单，这类任务在训练数据里出现频率极高，而且评判标准客观，输入输出清清楚楚，模型几乎不会犯方向性错误。我自己的经验是，给足字段定义和接口文档，它生成的CRUD代码比大部分初级开发者写的更规范，空指针异常处理得也更到位。
但它写不对的，是那些看起来很简单、实际上藏着大量上下文的任务。我整理了一张对比表，供大家参考：
| 场景 | AI表现 | 原因 |
|---|---|---|
| 独立算法/工具函数 | 质量高，可直接用 | 训练数据充足，标准答案收敛 |
| 标准CRUD接口 | 质量高，稍作修改即可 | 模式固定，边界清晰 |
| 老系统内的局部修改 | 经常“正确但格格不入” | 不了解历史决策和约定 |
| 跨模块数据流调整 | 容易漏掉隐式依赖 | 全局上下文缺失 |
| 修复线上问题 | 能给出补丁，但缺少验证 | 不理解问题的完整链路 |
| 涉及性能/一致性权衡 | 偏向“教材答案” | 不懂你的业务优先级 |
给我印象最深的是改一个老接口的例子。那个接口十年前就存在，当时为了兼容某个老客户端，返回字段里故意保留了一个拼写错误，后面所有调用方都依赖它，谁都不能改。AI看到这个字段名，自动帮我“修正”成了正确拼写，然后整个数据链路的兼容性都被打破了。代码本身没有错，甚至更规范了，但在那个系统上下文里，它就是一个严重的bug。
再看一个分布式任务调度的案例。我让AI处理一个消息重复消费的问题，它给出的方案是增加Redis分布式锁。这个答案放在教科书里没有任何问题，但当我把实际代码贴进去它才发现，这个服务嵌入在一个已经用数据库唯一键做过幂等的老架构里，锁机制反而会引入新的单点风险。AI看不到线上日志，看不到这个系统经历过的几次架构演进，它只能基于你给它的局部代码做局部推断。
所以我对团队的要求是：AI输出之后必须回到现场核对“这个改动是否尊重历史约束”。尤其要警惕那些“看起来更优雅”的重构建议——模型默认会往整洁的方向改，但生产环境里的很多丑陋代码，都是为某个特定问题服务的。你可以用AI做备选方案，但判断“哪种丑可以接受”这件事，AI做不了。
3. 我踩过的坑：“全部交给AI”的工作流失效现场
有一段时间，我特别迷信“AI优先开发法”，在一个功能迭代里给自己定了个规则：所有代码先让AI生成，人工只做代码评审和合入。前三天非常爽，每天能合出平时两倍的代码量。但从第四天开始，问题像滚雪球一样涌过来。
第一个暴露的问题是评审成本变了。过去review一段人写的代码，我会顺着作者的思路去看逻辑是否成立；现在review AI生成的代码，我要先猜它为什么这么写，再判断这个“为什么”是不是符合当前需求。比如有一次AI给一个用户配置接口加了很完整的入参校验，看起来特别正确，但它完全没加权限校验——因为需求描述里没有提到“这个接口只有管理员能调用”，而模型默认情况下倾向于“满足显式要求就行”，不会主动推测隐含的权限边界。这个漏洞如果换成经验丰富的开发者，根本不用你提，他会直接问“这个接口谁可以调”。结果那一次，这个疏忽漏到了线上，被外部请求绕过了权限限制，成了我那段时期最后悔的一件事。
第二个问题是修改反馈循环变得很长。AI生成的东西看着没问题，但当你需要调整某个中间逻辑时，直接改AI生成的代码会破坏它的风格和结构，全部重新生成又要重写一大段上下文。尤其当同一个模块被多次迭代时，AI对旧代码的“记忆”其实来自你重新粘贴的内容，只要忘了附带某个细节，它就会把之前已经解决的问题重新放回来。有一次为了修一个缓存过期问题，我前前后后让AI改了四版，每一版都能解决当前描述的问题，但都反复踩同一个坑：业务层自己也缓存了数据。因为每次生成的缓存读取代码都会覆盖业务缓存逻辑，最后我只能自己手工把三条缓存链路合并成一条，才真正修好。
我还做了一组粗略统计：在标准CRUD模块上，AI工作流大概能提升30%左右的效率；但到了修bug、做复杂业务迁移时，效率反而是下降的，大约负20%。下降的原因不是AI不会写，而是验证AI写的代码成不成立，需要付出的测试成本比原来更大。人写的代码错了，你通常能从代码风格和逻辑里回溯出思路；AI写的代码错了，你只能把整个模块当成一个黑盒重新推断。
那次实验之后，我给自己定了一条“代码生成边界”规则：只有能被快速验证的任务才交给AI，比如单一函数、独立脚本、页面骨架；凡是需要多个模块协同、存在历史约束、验证成本高的任务，一律先用文档把方案讲清楚，再让AI做局部实现。这条规则后来成了我所有AI协作流程的基础。
4. 拆问题才是护城河：从模糊需求到AI能执行的任务描述
经过那段时间的折腾，我越来越确认一件事：AI本质上是个“答题机器”，它不负责“出题”。你问的问题质量，直接决定了它回答的质量。而开发者真正的护城河，是把一个模糊的业务愿望，拆成一个一个能被执行、被验证的原子任务。
我目前在实践中把这种“拆题”能力，沉淀成了一套五层任务描述法。每次让AI写代码前，我会先在文档里回答五个问题：
第一层，背景与目标：这段代码在什么系统里运行？要解决用户的什么诉求？第二层，输入与输出：明确的入参格式、出参格式、数据类型、存储位置。第三层，边界与异常：哪些情况不需要处理？空数据、超时、重复调用分别怎么应对？第四层，验收标准：拿到什么结果算完成？有没有可以自动跑的测试样例？第五层，约束条件：性能要求、权限要求、兼容范围、不能改动的部分。
举个例子。如果直接对AI说“写一个批量重命名工具”，你得到的东西大概率是一次性脚本，参数只能硬编码。而我用五层描述法写出来的任务是：背景是我需要每周把导出的报表文件按照日期前缀重命名；输入是一个目录路径、一个日期参数；输出是不需要在终端打印详情；异常情况是遇到文件名冲突时自动追加数字后缀而不是覆盖；验收标准是有十个文件时运行结果符合预期；约束是脚本只能使用系统自带命令，不能在目标环境额外安装依赖。丢给AI之后生成的脚本，基本不需要大改就能跑通。
这件事单独看没什么技术含量，但它揭示了一个更关键的变化：以前能力体现在“怎么实现”，现在能力体现在“定义实现”。需求方常常给的是感受，“我想看得更清楚”“这个操作太麻烦”，你把感受翻译成规格，再把规格切成AI能执行的任务，最后做出来的东西才对得上真实意图。有了AI之后，这个翻译环节变成整个工程链条上最稀缺的能力。
另外一个更高级的拆解，是把大任务切成多个可独立验证的小任务。我通常在写任何非平凡功能时，会把任务拆到“每一个小任务都可以用一个单元测试来验收”的程度。AI每完成一个小任务，我就立刻跑对应的测试，通过之后再进入下一个。这样哪怕它生成了完全错误的代码，我也能在五分钟之内定位到是哪个小任务出了问题，而不是等整个模块完成后面对一座“翻车现场”。
你可能会觉得，这种拆法是不是反而比直接写代码还费事？我的实际体验是，对于简单任务确实是这样，直接写更快；但当任务复杂度上升，尤其是涉及多模块协作时，拆解的时间成本远远小于返工成本。拆解还有一个额外的好处：它让任务描述本身变成了可复用的资产，下次做类似功能时可以拿旧的任务描述去套，AI的生成质量会稳定很多。
5. 目前实践下来最顺手的三种AI协作模式
在踩了一大圈坑之后，我现在用的工作流已经稳定下来，基本是三种模式的切换。没有哪一种模式是“万能解”，但组合起来，效率和质量的平衡是最好的。
模式A叫“速写板模式”，用在最标准的场景：新建一个页面、写一个CRUD接口、生成一个工具函数。做法是先把接口文档、表结构、字段定义完整贴给AI，让它生成第一版，人工只改逻辑相关部分。注意事项是尽量把“不重要”也写清楚，比如样式不做要求、鉴权由网关统一处理，否则AI会把注意力浪费在无关细节上，甚至画蛇添足地引入你根本没用的封装。
模式B叫“结对搭档模式”，用在比较复杂但可以明确拆解的算法或数据迁移任务。我先在注释里写清楚伪代码思路，把这个“思路骨架”丢给AI，让它补充实现细节。这个模式和模式A最大的区别是：人工掌握方向和步骤，AI负责填肉。我使用下来它比直接让AI从头写质量高很多，因为伪代码本身就完成了任务拆解，AI不需要靠猜来理解上下文。
模式C我习惯叫“考古解释器模式”，专门用来读老代码。我经常把一段看得头大的历史代码贴给AI，让它帮我解释数据流、理清调用关系、指出潜在的坑。这个模式下一定要记住：不要把AI的解释当作最终真相信任，尤其是它对“依赖关系”的总结，很多时候它会漏掉配置文件中隐藏的bean绑定。我会把它的解释当作是一条线索，然后回到IDE里亲手验证一遍。
三种模式各自有明确的适用边界和人工介入点，整理下来就是一个简单的规则：AI生成越快的地方，验证就要越重。我给自己定了一个“信任半径”清单，列在维基里，每次都对照执行。清单包括：生成的代码有没有对应的测试或验证手段；有没有触碰权限、安全、审计相关的逻辑；有没有改动公共接口的输入输出；有没有引入新的依赖。任何一项触线，我都要求自己拉回来做人工评审，而不是图省事直接合入。
这套工作流的另一个关键，是让AI在必要时暴露“不确定”。我会在任务描述里加一句：如果需求存在歧义，先在回复里列出问题，不要直接猜测实现。这听起来很基础，但能规避掉一大批“AI自作主张”造成返工的情况。说实话，想让AI替你干活，反而需要比指挥人更细致的表达——因为人听不懂你模糊的话会主动来问，AI不会，它只会努力把模糊猜成一种默认答案。
6. 技能权重正在重置：不同阶段开发者该往哪发力
说了这么多工作流，最后聊聊我认为对每个开发者都适用的一些方向判断。
对刚入行没几年的开发者，最容易被AI替代的其实是“照着教程写代码”的那部分。之前大家学API、背框架、记设计模式，这些在AI面前都迅速贬值。但反过来，有一个技能比以前更重要：读代码。想写得好，先得能看懂别人写的代码——包括AI写的。我建议新人不要花太多时间刷语法题，而是多去读自己项目里最老的模块，读框架的源码，然后用你自己的话把这段逻辑讲清楚。当你具备“解释一段陌生代码在干什么”的能力，你才真正成为AI生成结果的把关者，而不是AI产出物的搬运工。
对已经工作三五年的开发者，重心要从“实现者”切换到“决策者”。过去你可能因为代码写得好被认可，现在代码写得好的人太多了，更需要的是从几个方案里选一个的能力。比如用Redis还是用本地缓存、接口是同步还是异步、这个月系统是重构还是继续缝补，这类决策背后的依据，是技术判断和业务理解的结合。AI可以帮你列出每个方案的优缺点，它甚至可以帮你做个小原型验证，但最后拍板的时候，你还是得回到业务目标来权衡。掌握这种决策节奏，是中级开发者拉开差距的地方。
对更高层级的开发者或技术负责人，核心资产已经不再是编码速度，甚至也不只是架构能力，而是“定义问题的准确性”。一个业务方过来提需求，能不能在一小时内把模糊愿望整理成结构化问题，并且在关键分歧点上让AI产出多个方向的代码原型，然后快速投票选择，这会成为高端玩家的日常工作方式。也就是说，AI越强，定义问题的杠杆效应越大——你能同时指挥越多条AI流水线帮你探索方案，你的产出半径就越宽。
我自己也有一个切身的感触：为了让AI生成更稳定，我不得不把很多年没认真做的“文档撰写”重新捡起来。现在我在团队里要求，所有涉及多个模块的功能，先写一页纸的任务规格，再过评审，然后才允许碰代码。刚开始大家觉得多了一道流程，但磨合一个月后，返工率明显降了。这里面的原因不难理解：AI让“写代码”的门槛变低之后，错的代价反而更高了——以前写错了，改代码就行；现在如果问题定义错了，整个AI生成的几千行代码都得推倒重来。
最后分享一个个人习惯吧：不管AI生成得多顺，我每天仍然会留出半小时，亲手写一段小代码，不追求功能，只追求“这件小事我自己能完全搞明白”。这个习惯让我一直保持对实现的敏感度，不至于在大量AI产出物之中丧失手感。毕竟我们做工程的人，最值钱的不是“拥有答案”，而是“随时能重新推导出答案”的能力。AI给了我们一个更快的起点，但往哪个方向走、走多远，依然是把关的人说了算。
