AI编程工具在真实代码库里真正拖慢团队的，往往不是它写得慢，而是它写完之后留下的返工。横向实测显示的一条共性规律值得警惕：响应快但返工多的工具，综合效率未必高于慢而稳的工具。这意味着控制返工风险，本质上是一项工程治理问题，而非单纯的工具选型问题。
返工风险主要集中在三类环节。其一是复杂缺陷修复，典型表现为"看似修好、实则换了个 Bug"——工具修好了表象却漏掉根因，异步竞态这类问题尤其容易让人误判已经收敛。其二是跨文件重构，当改动涉及十余个文件时，常出现"后半程走样"：前几个文件改得标准，越往后模式应用越不一致。其三是单元测试补全中的"自我迎合"，即断言围绕当前可能有缺陷的实现来写，制造出"全绿却无意义"的测试。这三类的共同点在于，它们都触及正确性判断，而正确性恰恰是工具最难自我保证的部分。
把任务拆小，让走样可控
控制返工的第一道闸门是任务粒度。一次性把一个跨十几个文件的重构整体丢给工具，走样概率会显著上升；分步提交则把每一步的产出都限制在可核对的范围内。拆分的价值不只是降低单次复杂度，更在于它把"最后统一返工"的大成本，摊薄成多次小幅校正，使问题在扩散前就被发现。对于存量项目维护这类高度依赖上下文理解的任务，分步推进尤其能压低返工成本。
在关键环节设置人工验收
工具是放大器，不是替身。测试和重构必须保留人工验收这一关：对测试要警惕"全绿"，断言的正确性必须人工把关，确认它围绕正确预期而非当前实现；对 Bug 修复要复核根因，而非只看表象是否消失；对重构要检查全局一致性与文件间依赖是否贯通。把人工复核明确为流程中不可省的一步，而不是依赖个人自觉，才能避免隐性缺陷被一路带到合并。
还有一条判断原则值得前置：不要用 Demo 结论做采购和流程决策。演示里的"一句话成片"，到真实代码库里普遍要打对折，围绕夸大预期搭建的协作方式，本身就是返工的来源。
归根结底，当生成和补全日益廉价，团队的核心竞争力正从"写得快"转向"判断得准"。界定需求、识别产出中的隐性缺陷、为正确性负最终责任，这些既是人难以被替代的地方，也正是控制返工风险的真正支点。工具越能写，能读懂、能质疑、能兜底的人就越关键。