2023年那波AI Coding工具刚火起来的时候我第一反应和大多数人一样先把代码补全安排上看看能省多少打字的力气。头一个月确实爽一个排序、一个时间格式化、一个对象转换命令敲下去代码就出来了效率高到我一度觉得程序员快被替代这种说法也不是完全没道理。但三个月迭代跑下来我把交付数据摊开一看发现一个不太舒服的事实需求交付周期几乎没有缩短有些需求甚至比以前更慢。代码生成确实快了需求交付提效却不明显这个矛盾不是我们一家的问题我和好几个团队交流下来大家都有同感。后来把问题拆开分析所有复盘最后都指向同一个词——返工。AI生成的代码里有相当一部分要改、要重写生成时省下的时间全被返工吃了回去还额外搭进去review的精力。这篇文章把我自己摸索出来的降返工套路完整讲一遍从需求拆解、上下文构建、测试先行到规则沉淀和工具选型每一条都来自实际踩坑适合正在用或准备引入AI Coding、却觉得效率没有真正起来的团队。1. 代码生成快了、交付没快返工才是隐藏的时间黑洞1.1 表面上的快和体感上的慢先用一个我们团队的真实对比来说。同样是用户修改个人资料这个需求我排了两名开发并行做一个完全传统方式一个全程用AI Coding工具。传统方式那位两天写代码、半天联调总共两天半。AI方式那位第一天上午就把代码生成完了速度确实惊人。但AI写出来的实现有三个问题漏了邮箱修改后必须重新验证这个隐含约束更新时间字段一直写成创建时间字段前端期望返回字段名是驼峰风格AI按数据库风格返回了下划线。每改一个问题都要重新翻一遍AI生成的上下文最后一天半全花在修补上。总账算下来AI方式不但没省时间人还更累了。这种反差就是典型的局部快、整体慢。代码生成这个环节在整条需求交付链路里只是很小的一段。前面有需求理解、上下文对齐、验收标准定义后面有联调、测试、代码评审、上线验证。如果AI只在中间那段加速前后环节没有配套调整整条链路的瓶颈就会转移到返工上。生成得越快返工的速度也越快错误被快速放大。你不是在提效你是在用更高的速度制造更多待修改的内容这也是为什么很多人对AI Coding的评价会两极分化只体验过单函数生成的人觉得它无所不能真正把一个完整需求从头跑到上线的人才发现提效没那么简单。结论不是AI Coding没用而是我们还没有为它重新设计工作方式。1.2 四类返工形态哪一种最花时间我在复盘里把AI带来的返工分成四类每一类都有自己的典型场景需求理解型返工业务规则没写清楚AI只能按直觉猜。你以为它知道发货后不能取消它其实只看到了取消订单四个字。这种返工最贵因为不只是改代码还要重新对齐需求、重新设计实现一次就是半天。接口契约型返工AI自创字段名、自创接口路径、自创参数结构导致前后端联调大量修改或者服务间调用对不上。这种返工最气人因为完全可以通过前置输入来避免。边界条件型返工正常路径跑得通一遇到空值、超时、并发、超大输入就崩。数量最多每一个都不起眼加起来是大头。架构一致性返工AI生成的代码本身没有bug但不符合团队的分层规范、命名风格、数据库访问模式代码评审过不了必须重写。从返工成本看需求理解型最贵边界条件型最多架构一致性型对老团队伤害最大因为一套好的架构风格需要长期维护AI却完全不认识它。而且返工的成本不只是重复劳动还有隐性认知负担你需要在AI生成的一大段代码里找问题这种review比看人写的代码累得多因为你不知道模型当时猜了哪些上下文代码风格又不是你熟悉的出了问题只能一点一点回溯。1.3 为什么传统的效率指标会骗人很多团队统计提效喜欢看每千行代码生成耗时或者AI生成代码行数这个指标在AI Coding时代会严重误导决策。一个容易忽略的事实是当生成速度已经不成问题时单位时间内产出代码的正确可交付率才是真正的问题。我今天能用AI一小时生成一千行代码但如果其中有三百行要返工那实际的净效率反而比人肉写还低。我建议所有团队换一个度量方式不要统计生成快不快而是统计从需求卡片进入开发到功能上线总共用了多少个工作日期间返工了几次每次返工的原因是什么。只有当返工率和返工原因被记录下来了你才会发现AI问题只是表象真正的短板在需求侧和流程侧。这也是标题里那个问题的本质需求交付提效不明显不是AI不够强而是返工黑洞把效率全吃光了。2. 返工高的四个根源需求、上下文、验收、规则2.1 需求停留在人话级别AI只能在猜先说需求。人类写需求天然充满模糊词。我经常在需求文档里看到做合理的校验给出友好的提示根据业务规则判断处理异常情况这类描述。人看这句话会结合自己多年的项目经验自动补全。AI没有你的项目经验它只有训练数据里的平均经验所以你给模糊输入它给的是最可能的输出而业务最怕的就是可能。举一个具体例子用户下单时校验库存这句话你让不同AI工具生成可能得到三四套实现有的只查库存大于零就通过有的加了锁库存逻辑有的把超卖场景也考虑进去了。在没有需求细节的情况下这三四种实现都可以说是对的但你的业务只允许一种于是AI生成的代码跑通单测等联调或产品验收那天才发现语义不对返工。下面这个表格能直观看出模糊描述和可执行描述的差距模糊描述问题出在哪可执行描述用户登录时要做合理校验AI不知道合理的定义账号冻结时返回错误码1003密码连续错5次锁定30分钟对请求参数做合法校验校验什么、返回什么没定义订单号为空返回4001非数字返回4002均附统一文案库存不足时给出提示AI随意处理可能只改文案不回滚库存不足返回4301提示库存不足不做任何扣减动作模型的本质决定了它比人类更不能容忍模糊。所以降返工的第一步不是换更强的工具而是把需求改造成AI可执行的格式。这个我在第三部分展开这里先记住结论模糊需求扔给AI它只能赌赌输了就是返工。2.2 AI没有全局视角写对了函数也可能写错了系统第二个根源是上下文。大语言模型的本质是根据可见上下文预测后续代码。如果可见上下文只有当前一个文件AI对系统其他部分几乎一无所知它就会大量自创自创一个不存在的工具方法自创一个不匹配的数据模型字段自创一个接口路径。这不是AI笨是它真的没看到。我自己碰到过的最典型事故是让AI在一个老项目里加导出功能它直接引用了一个项目里根本没装的库还按那个库的API写了一大段导出逻辑。编译不过去查依赖配置才发现版本和平台支持全是问题最后花了一上午查文档、改实现。类似的接口契约错误十个返工里至少三个是AI以为某个东西存在导致的。上下文窗口再大如果你不主动把系统结构喂给它它还是两眼一抹黑。解决思路其实很简单像给新人做入职培训一样给AI准备一套项目上下文文档。项目是干什么的、目录结构怎么分、技术栈版本是什么、有哪些核心数据模型、字段命名是什么风格、已有的接口和服务有哪些、之前踩过什么坑。这些信息放进文档每次开始新任务时用工具的引用功能让AI先读一遍它的系统猜中率会明显提高。别指望AI靠自动索引就能完全理解你的业务主动把上下文递到它手里是成本最低的做法。2.3 没有验收标准AI生成的代码能跑不等于能交第三个根源是验收标准缺失。传统开发里测试用例往往在需求后期补写但在AI Coding时代这个顺序必须倒过来先写测试再要实现。原因很简单AI没有能力自我判断我这个逻辑对吗它只能靠外部信号来校正而测试就是最强、最明确的外部信号。如果任务旁边挂着一组测试大部分AI工具会在生成过程中主动向测试对齐跑不过就修这种自愈能力带来的正确率提升非常明显。反过来没有测试的AI生成完全靠人肉review兜底。问题在于AI一小时能生成几百上千行代码人工review的速度根本跟不上结果要么堆积要么走形式。最后大量bug漏到联调、测试阶段才暴露返工成本直接翻倍。而且很多AI生成的代码属于happy path正确你去问它库存恢复失败怎么办它不会回答因为验收标准里根本没要求它回答。把验收标准翻译成测试用例等于在告诉AI我不关心你是怎么写的我关心的是你能否满足这些断言。2.4 团队规范没沉淀AI每次都在从零发明轮子最后一个根源是规则。大部分团队都有自己的编码规范、命名约束、分层约定、错误处理套路但问题在于这些规范往往只存在老开发脑子里没有形成机器可读的配置。AI工具默认生成的是全网最常见的写法不是你们团队的写法。于是AI生成的代码单看没问题放到团队里就不对味Controller里写着业务逻辑、错误处理散落各处、异常类型乱抛、数据库访问到处都是new连接。代码评审每次都要为了这些重复问题打回浪费时间也消耗开发者的耐心。那怎么让AI从通用程序员变成懂团队规矩的资深开发答案就是自定义规则。把团队规范写成规则文件注入AI的工作流让AI在生成代码前先看到这些约束。这也是最近可自定义规则的代码生成工具越来越受关注的核心原因。自定义规则不只是一个功能开关它决定了AI生成物的团队适配度适配度越高返工率自然越低。后面我会具体讲规则文件应该怎么组织。3. 真正能降返工的四件事需求规格、上下文、测试、规则3.1 把需求改成AI任务卡先把歧义杀干净我在团队里推行了一个东西叫AI任务卡说白了就是把需求描述从散文改成结构化技术规格。一张任务卡包含五块内容输入、处理规则、输出、边界异常、验收样例。拿用户取消订单举例最终写出来的任务卡长这样需求US-102 用户取消订单 输入 - 订单号 orderId - 当前用户ID userId 处理规则 1. 只允许订单状态为待支付、待发货时取消 2. 已发货订单不能直接取消要引导走售后流程 3. 取消成功后必须恢复库存数量 4. 取消动作必须写入操作日志 输出 - 成功返回新状态 CANCELLED 和取消时间 - 失败返回具体业务错误码 边界异常 - 订单不存在错误码 4001 - 订单状态不允许取消错误码 4002文案当前订单状态不可取消 - 非本人订单错误码 4003文案无权操作该订单 - 库存恢复失败事务回滚错误码 4004 验收样例 - 输入(待支付订单, 本人) - 返回成功状态 CANCELLED - 输入(已发货订单, 本人) - 返回 4002订单状态不变 - 输入(待支付订单, 他人) - 返回 4003这张卡写完了AI基本不用猜。尤其边界异常和验收样例这两块是降低返工的黄金地段因为AI翻车通常就翻在边界上边界一旦被明确定死它就没有自由发挥空间了。在写任务卡上多花半小时至少省下半天返工时间这笔账非常划算。实操上有个细节任务卡格式不用多高级最简单的Markdown就行重点是强制要求业务规则编号化方便AI逐条对应实现。另外验收样例一定要给AI对输入输出示例的学习能力极强几个例子顶得上十句描述。3.2 用项目上下文文档给AI补全局视角任务卡解决这个需求是什么上下文文档解决这个项目是什么。我建议每个仓库维护一份AGENTS.md或者CONTEXT.md内容控制在能在一分钟内读完的程度包括项目一句话简介、技术栈清单语言、框架、ORM、关键库及版本、目录结构说明、命名规范、核心数据模型简表、关键约定事务、缓存、日志、外部调用超时、已知坑列表。上下文文档不是越大越好我的经验是只放绝对核心的信息其余细节留在具体业务文档里。内容太多反而是负担既烧token又会分散模型对当前任务的注意力。实际使用时每开始一个任务就用工具的引用功能把相关部分喂给AI比如改订单模块就引用数据模型文件、接口文档以及上下文文档里的对应章节。这种按需引用的方式比一股脑把所有文档塞进上下文更省token也更容易让AI聚焦在当前相关代码上。会话管理同样重要我坚持一个需求开一个新会话不允许在同一个长会话里连续做无关任务因为对话越长早期约束越容易被后续内容稀释。关键信息宁可每次重新贴一遍也不要赌模型的长期记忆。3.3 测试先行把验收标准变成AI的执行指令测试先行是我认为所有降返工措施里性价比最高的一条。具体操作流程是拿到任务卡后先让AI根据任务卡生成完整的测试用例注意这里要的是测试而不是实现这一步很关键测试是在描述应该发生什么模型在这种任务下不容易跑偏。开发人肉检查一遍测试重点看边界有没有覆盖到位。AI写的测试有自证倾向它倾向于写能让自己实现通过的用例所以关键业务逻辑的边界用例一定要人工补充比如空值、越权、并发、超时、异常回滚。检查完测试之后先跑一遍确认它是红灯因为功能还没实现。这一步是为了确认测试不是摆设。然后交给AI写实现让AI自己运行测试跑到绿灯。现在很多AI Coding工具支持执行命令、读取报错信息AI会基于报错反复修改这个循环通常在十几分钟内完成。绿灯之后人工做最后审查再提交。这套流程的本质是把验收标准从人心中模糊的期望变成机器可执行的断言。AI不再需要猜测这样算不算对测试会告诉它。返工发生的时机也从联调、测试阶段大幅前置到AI生成阶段越早发现问题修复成本越低。有人担心测试先写浪费时间实际恰恰相反。测试文件编写本身有AI辅助实际耗时远小于想象多花半小时写测试换来的却是联调、测试、评审环节大把时间的节省这笔投入怎么算都值。最重要的一点是测试先行的方案同时解决了需求理解问题和验收标准问题一个动作打了两个补丁。3.4 自定义规则的正确写法与工具取舍最后是规则沉淀。团队规范要变成AI能遵循的东西大致有三种形态。第一种是IDE或AI工具的自定义指令比如Cursor里的rules、Copilot的custom instructions以及一些国产工具的项目级prompt。这类规则适合全局性约束注释用中文还是英文、错误响应统一格式、Controller不要写业务逻辑、禁止魔法数等。第二种是静态检查配置比如ESLint、Checkstyle、golangci-lintAI生成的代码必须过同一套检查。第三种是专门的规则式代码生成工具这类产品主打自定义规则、局部注入、不烧token把团队规则拆成可独立启用的模块只在匹配到对应文件类型或任务场景时才把规则注入请求避免每次生成都带着一大坨无关规则白白消耗token还稀释模型注意力。规则怎么写才有用我的体感是规则要写禁止什么和必须什么不要写建议什么。AI对确定性指令的遵循度远高于建议性表述。比如下面一段规则就是团队里实际在用的当生成Controller方法时 - 参数校验放方法入口业务逻辑委托Service返回统一ResultT结构 - 禁止在Controller中直接操作数据库 当生成Service方法时 - 所有外部HTTP/DB调用必须显式设置超时时间 - 禁止在循环中使用await - 事务必须显式声明禁止依赖框架默认行为 错误处理 - 统一使用ErrorCode枚举禁止魔法数 - 所有异常必须返回结构化的{code, message, requestId}另外要记住规则不是一次配完就结束的。每次遇到一种新的返工原因都值得反推一句能不能把它写成规则。比如我们发现AI生成的代码总是漏权限校验就把所有写接口必须调用RequiresPermission注解写进了规则文件。AI不是记不住而是没人告诉它。规则库持续跟返工原因对齐工具就会越用越顺手这也是我推荐优先选择支持灵活自定义规则工具的核心原因。4. 我们团队跑通的一条低返工AI交付流水线4.1 需求拆解会的改变评审会多花半小时返工少花好几天我们团队现在的需求评审开法变了。以前是PO讲一遍故事大家问几个问题估个时间就散会。现在评审会只讲清楚两件事业务目标是什么边界条件有哪些。会议现场必须产出上一节说的AI任务卡PO回答不上边界条件的需求不允许进入开发。这是最硬的一条纪律。为什么这么硬因为以前需求模糊开发阶段总有个经验丰富的程序员把模糊补全。现在AI当主力开发没人帮它补全了需求侧的模糊会原封不动变成代码侧的偏差。与其在开发后期花几天改不如在评审阶段多花半小时把问题问透。代价是会议时间变长了一开始团队也有抱怨但坚持了两三个迭代之后大家看到测试阶段的问题单数量明显下降联调阶段的冲突变少抱怨就自然消失了。现在团队反而形成共识写任务卡的时间不能省省了后面全是还债。4.2 小步渐进式生成给AI清晰的可验证台阶第二个执行细节是坚决不要一条提示生成一个完整需求。AI和人类写代码一样任务越大越容易跑偏越难纠偏。我们把一个需求拆成两三天能上线的小任务每个小任务再拆成更细的步骤第一步先让AI读取上下文文档和相关文件确认理解了业务再生成数据模型第二步生成接口骨架和DTO第三步实现业务规则第四步补异常分支和边界最后统一过测试。每一步都有明确的可验证产物跑不通就及时喊停不让错误累积。这里有个很实用的小细节每完成一步就把那部分代码提交或暂存不要等AI把整个需求写完再一次性落地。这样即使后续AI生成的东西有问题也不会污染已有代码回滚非常方便。另一个习惯是在提示词里明确要求AI只完成指定任务不要顺手重构其他代码。AI经常好心办坏事改个变量名顺手把不相关代码格式化了结果你的diff里混进一堆无关变更评审负担剧增。这个约束写进规则之后少了很多麻烦。4.3 PR前的三道门槛单测、静态检查、人工reviewAI生成的代码进入主干之前必须过三道门槛。第一道是单测新增功能必须带测试测试覆盖率达到项目既有水平。做了这个硬性要求之后没有测试的裸PR基本不会出现在review队列里。执行上不要靠自觉要靠CI和本地钩子凡是测试不过的代码不允许提PR。第二道是静态检查和lintAI生成完代码第一步就跑有报错先丢回给AI修修到全绿再交人。这个循环不需要人参与省下了大量本该人工处理的低级问题。第三道门槛是人工review。因为前两道已经把低级问题挡掉了人工review的注意力只集中在两件事需求理解对不对、设计合理不合理外加安全性检查比如权限校验是否到位、敏感信息是否入库或者打日志、输入输出有没有做校验。这样做之后review节奏轻松了很多你review的不再是代码写得对不对而是意图对不对。很多团队最大的问题就是让review一个人扛所有质量责任AI产出的代码全堆到人肉审查这里。三道门槛的本质是把质量责任前置到机器能处理的环节人只做机器做不了的事返工自然就降下来了。4.4 三个迭代之后的实际变化这套流水线跑了三个多月体感数据是AI生成代码的返工率从大概四成降到了一两成需求交付周期平均缩短了差不多三分之一。相比时间缩短更重要的是交付节奏变稳定了测试和联调阶段的大返工明显减少每个人精神压力都小了很多。当然也有没改善的地方。最明显的是需求拆解和任务卡编写对PO的要求提高了以前光讲故事的人会很不适应。其次是业务极其复杂、多个系统交织的需求AI还是胜任不了这类需求回归人工主导AI只做辅助。把这些边界划清楚之后团队对AI Coding的信任反而建立得更快了不会被一次大返工打击到全盘否定工具。顺带一提现在有些公司招聘已经开始加入AI Coding笔试环节专门考察候选人把需求拆给AI、用规则约束AI的能力说明这套方法论正在变成基本职业技能值得团队系统化投入。5. PLC和Simulink场景里的返工控制比Web更较真5.1 工业PLC代码生成返工可能变成停机事故前面聊的都是常规业务系统的AI Coding最近AI PLC代码生成这个方向也很热。工业控制领域AI正在被用来生成PLC的结构化文本或梯形图。这个场景下返工的代价和Web完全不是一个量级。Web返工最坏就是功能临时不可用PLC代码返工一旦漏到现场可能直接引发设备误动作轻则报警停机重则涉及人身安全。因此PLC场景的AI辅助工具没有一个敢说生成完就能用。实际流程必须结合严格的验证链路先做I/O清单和控制逻辑时序表把所有输入信号、输出信号、状态转换列清楚AI按这个表格生成代码片段然后在仿真环境里跑逻辑验证确认所有状态都能正确转换再上HIL硬件在环测试最后才是现场点动和带载调试。哪一步都不能省。这其实就是我们前面讲的任务卡和测试先行只不过约束更严格。这个案例给Web团队一个提醒不要在返工控制上松手返工不只是成本问题在一些行业里是安全生产问题方法论通用标准要按行业风险调整。5.2 Simulink模型生成C代码模型评审与覆盖率兜底另一个热词是Simulink模型 C代码生成。嵌入式领域用Simulink建模、Embedded Coder生成C代码本来就是很成熟的生产流程。现在AI开始进入这个链路主要做模型生成的辅助、测试用例自动生成和辅助模型评审。这个场景下返工控制的重点在模型层而不在代码层。模型里漏了一个状态迁移生成出来的C代码在语法上完全正确功能却是错的而且这种错隐藏得很深通常要台架测试甚至实车阶段才能发现。我见过类似案例模型里少画了一条状态迁移生成代码后正常工况没有任何表现直到一次外部中断进来状态机卡死控制器直接挂起。所以嵌入式场景的核心思路也是把验收标准前置到模型层面用覆盖率分析看状态迁移覆盖了多少用形式化验证工具确认模型逻辑有没有死锁再谈生成代码。AI只是加速器代替不了验证闭环。这个场景其实是整篇文章主题的极端版返工降不下来不是AI工具不行是输入端和验证端没有跟上生成端的速度。谁先把输入端和验证端补齐谁才能真正吃到这波红利。5.3 工具选型快不是第一指标规则和成本才是最后回到工具选择。市面上AI Coding工具一大把卖点普遍是生成速度快支持大上下文代码补全能力强。我的建议是这些指标都重要但不是决定长期效率的核心指标。真正要问自己的是下面几个维度维度关注点我踩过的坑规则定制能否按项目、语言、目录配置不同规则能否按需注入不支持按目录注入的规则全量输出token浪费且模型容易被无关规则干扰上下文管理是每次全量塞入代码库还是有本地索引和精准引用全量塞入的响应慢、成本高还有数据出域风险流程集成能否在CI里跑、能否和IDE的lint/test联动只能聊天生成、无法自动跑测试的工具返工率压不住数据安全是否支持本地或私有化部署公司代码不能出内网时云端工具直接不能选工具选择上我个人的倾向是优先支持自定义规则、支持按需注入、最好能私有化部署的工具哪怕它的单次生成效果不是最惊艳。因为长期看规则库和流程融入才是提效的大头单次生成的惊喜感维持不了三个月。那句简单、高效、不烧token概括的本质就是这个思路通过局部上下文、按需规则、缓存复用把每次请求的有效信息压缩到最小降低使用成本同时减少无关信息对模型判断的干扰。团队达到一定规模之后token成本差几倍就是很可观的数字。5.4 每次返工都值得反推一次和AI Coding工具打了这两年交道我最深的感受是模型的能力边界一直在往外扩但能不能把能力变成业务价值决定权不在模型手里而在使用模型的人手里。代码生成只是把想法翻译成代码的速度变快了想法本身是模棱两可的翻译出来的一定是返工。我现在不管接什么需求都不会急着打开IDE而是先问三个问题需求描述有没有歧义AI需要哪些项目上下文验收标准能不能被测试表达这三个问题想清楚了再让AI动手。最后分享一个小技巧任何一次AI生成导致的返工都值得花十分钟反推一下原因——是需求没说清是上下文没给足是规则没写到还是测试没覆盖把答案补进任务卡、上下文文档或规则库AI的下一次输出立刻会不一样。返工降不下来往往不是AI不够好而是我们一直在让AI替我们背锅。希望这篇文章里的思路能给你一些可落地的参考。