ChatGPT、Codex趋势：为什么AI写代码速度越来越快以后，“返工成本”反而更值得关注？

过去做开发写代码本身往往就是最大的时间成本之一。一个Feature要写半天。一个Bug要排查几个小时。一个模块重构可能要持续几天。所以很多工程效率讨论都会围绕一个问题怎么把代码写得更快但随着ChatGPT、Codex这类AI越来越能自主完成Coding任务这个问题正在发生变化。AI可以快速读代码。写实现。改多个文件。补测试。跑验证。甚至连续执行很长时间。于是“写代码”本身正在变便宜。但与此同时另一个成本开始变得更值得关注如果方向错了要花多少代价把这些已经生成、已经修改、已经验证过的东西重新推翻这就是Agent时代越来越重要的一个概念Rework Cost——返工成本AI写得越快错误方向扩张得也越快。所以未来真正高效的开发者不只要关心AI生成了多少代码。还要关心这些代码里有多少最后需要重新做。一、为什么AI时代返工会变得更贵先看一个很典型的场景。你让Codex修复用户登录后偶尔掉线的问题。Agent开始分析。它认为问题来自Token刷新。于是修改Token逻辑。随后调整Session处理。补Regression Test。相关调用方也跟着变化。最后测试全部通过。整个过程可能只用了20分钟。然后你Review时发现真正问题其实来自缓存状态同步。这意味着刚才的20分钟虽然执行得非常高效但方向错了。接下来不是简单改两行。你可能需要撤销错误实现。恢复调用方。重新判断哪些测试还能保留。清理错误假设。重新建立Context。再从正确方向重新执行。这时候会发现一个反常识的事实AI帮你把错误方向也执行得更快了。过去一个开发者20分钟可能还在分析。现在Agent20分钟已经能制造一个完整错误方案。二、以前慢一点反而天然限制了错误扩张传统开发有一个不太明显的“保护机制”人写代码是慢的。一个开发者如果方向错了通常不会瞬间改完20个文件。他可能先查代码。改一个地方。跑一下。发现不对。于是纠正方向。也就是说人类执行速度本身会提供很多自然Checkpoint。但Agent不一样。一旦它认为方向成立就可以快速向下执行。所以AI越快以后会出现Error Velocity错误传播速度。错误假设不再停留在思考阶段而会迅速变成代码。测试。配置。调用链变化。于是返工成本就不只是“重新写代码”。而是把一整条错误执行链拆掉。三、返工真正贵的不是代码重写而是状态恢复很多人说返工会想到再写一遍。但Agent时代真正昂贵的部分往往不是Code Generation。因为代码本身AI可以继续快速生成。真正贵的是State Recovery状态恢复。比如一个错误任务已经修改了10个文件。你要重新确认哪些改动是错的哪些其实仍然有价值哪些测试是建立在错误假设上的哪些文件需要Rollback哪些Context已经过期哪些后续任务依赖了这个结果这些都需要重新判断。所以未来AI Coding里一个很重要的变化是代码生成越来越便宜正确状态的维护反而越来越重要。四、测试也会让返工变得更复杂假设AI方向错了但它又按照错误方向补了很多测试。现在你发现需求理解不对。这时候不能简单保留所有测试。因为有些测试可能是在证明错误行为。你需要重新判断哪些是原有Regression。哪些是AI新增的实现测试。哪些断言本身应该被删除。哪些测试还能作为独立Evidence保留。所以错误方向一旦进入Implementation Test两层以后返工复杂度会明显上升。如果再继续进入Integration。Documentation。Config。Migration。返工成本还会继续增加。五、可以建立一个指标Rework Ratio未来判断AI开发效率可以看一个很实用的指标Rework Ratio——返工比例简单理解AI生成的工作里有多少最后需要被撤销、重写或大幅调整。比如一天Agent一共执行了10个任务。其中7个直接进入最终结果。2个经过小调整。1个几乎完全推翻。那整体Rework Ratio还比较健康。但如果10个任务里4个都要大幅重做。即使AI每天生成很多代码真实生产力也未必高。因为大量计算只是先快速生成再快速推翻。所以未来效率不应该只看完成多少任务。还要看最终有多少工作真正留下来了。六、为什么“写得快”很容易掩盖返工问题因为AI产出速度非常有视觉冲击力。一次修改20个文件。几分钟生成完整Feature。测试不断变绿。很容易让人产生“效率非常高。”但真正应该看的是Net Productive Output净有效产出。比如AI一天生成了5000行代码。最后真正进入生产的只有1500行。剩下大量修改被删除。被重写。被Rollback。那5000行并不能代表真实效率。所以未来开发者需要从Gross Output——总产出转向Net Output——净产出。这和传统工程管理其实很像。忙不等于有效。AI生成很多也不等于交付很多。七、返工最容易发生在哪些任务里第一类Goal不清楚比如“把这个模块优化一下。”AI必须自己决定什么叫优化。方向越开放返工概率越高。第二类Root Cause未确认Agent还没确定真正原因就开始修改代码。这种任务很容易反复推翻。第三类Scope太大一个任务同时包含Bug Fix。Refactor。测试。性能。依赖升级。一旦某个方向错了很难只撤掉一部分。第四类Acceptance Criteria不明确AI做完以后才发现这不是你真正想要的行为。这几类任务都有一个共同特点执行开始得太早。八、最有效的办法不是让AI慢一点而是增加Early CheckpointAI快本身不是问题。真正的问题是在方向还没有确认时就进入深执行。所以未来更成熟的Workflow应该增加Early Checkpoint——早期检查点比如在大规模修改前先确认当前理解的Goal是什么Root Cause是什么哪些Assumption还没有验证准备修改哪些文件Done Criteria是什么如果这一步就发现方向偏了修正成本非常低。可能只是改一句任务描述。但如果等20分钟、30分钟以后再发现返工成本会大很多。所以真正要优化的是Time to Detect Wrong Direction发现错误方向所需时间。越早发现越便宜。九、复杂任务可以用“先证据后执行”对高风险Bug尤其适合Evidence First先让Codex找Evidence。不要一开始就改。比如只复现问题。只分析调用链。只列Root Cause Hypothesis。等Evidence足够以后再进入Implementation。这样做的好处是如果方向错了前面的损失主要是分析成本。而不是分析 代码 测试 Refactor Rollback。这其实是在控制Rework Surface返工面。十、Rollback Boundary也会直接影响返工成本如果一个Agent任务非常干净只修一个Bug。只改相关文件。独立Commit。出现问题以后直接Rollback。那么返工成本很低。但如果一个任务里混着Bug Fix。重构。依赖升级。配置修改。测试整理。那你发现方向错以后很难整体撤回。所以每个AI任务最好尽量拥有Rollback Boundary一个清晰回滚边界。未来AI任务不仅要问“能不能完成”还应该问“如果做错了能不能便宜地撤掉”十一、可以再看一个指标Rework Depth除了Rework Ratio还可以看Rework Depth——返工深度同样是任务失败严重程度完全不同。Level 1改几个参数就能恢复。Level 2需要重写实现。Level 3实现和测试都要推翻。Level 4跨模块、配置、数据结构都需要恢复。返工深度越高真正成本越大。所以高风险任务的目标不只是降低失败概率。还要做到即使失败失败也尽量停留在浅层。这就是为什么小阶段。Checkpoint。独立验证。会越来越重要。十二、Multi-Agent会让返工成本进一步放大如果一个Agent的错误结果被另一个Agent当成前提继续执行就会形成Cascading Rework级联返工。比如Agent A设计错误API。Agent B根据它写前端。Agent C补测试。Agent D更新文档。最后发现A的设计错了。那么需要返工的就不只是A。B、C、D都可能跟着重做。所以Multi-Agent时代必须更加重视什么结果已经稳定什么结果还只是Draft。不稳定结果不要太早成为其他任务的Dependency。十三、未来开发者真正要优化的是“返工发生得有多晚”这是一个很值得注意的判断。错误不可避免。AI也不可能每次都一次正确。所以目标不是Rework 0。更现实的是Fail Early尽早失败。在分析阶段发现方向错。比代码阶段发现便宜。代码阶段发现。比Integration以后发现便宜。Integration发现。比上线以后发现便宜。所以未来AI开发真正成熟的标志不是从来不返工。而是错误尽量在便宜阶段被发现。十四、Plus用户为什么特别应该关注Rework Ratio很多人觉得Codex额度不够可能会看到一天跑了很多任务。消耗很快。然后想到是不是应该升级Pro但如果其中大量任务最后都需要Rollback。重写。重新测试。重新开Session。那真正的问题可能不是容量不足。而是Rework Ratio太高。增加容量只会让AI拥有更多机会更快完成错误方向。所以Plus阶段很值得先优化Goal。Intent Checkpoint。Evidence First。Rollback Boundary。十五、什么时候Plus通常已经够如果你的日常任务主要是明确Bug。中型Feature。Review。测试。并且已经做到方向先确认。复杂任务先找Evidence。高风险修改有Checkpoint。大任务拆成可验证阶段。返工大多停留在浅层。那么Plus通常已经可以承担大量Agent开发工作。因为真正被浪费的执行明显减少。同样的容量能够产生更多Net Productive Output。十六、什么时候Pro才真正开始匹配更接近Pro的情况是你的Rework Ratio已经比较低。大部分Agent输出最终都会留下。复杂任务也能及时发现错误方向。Rollback Boundary成熟。Multi-Agent不会建立在不稳定结果上。但每天仍然有大量高价值。复杂Repository。长时间。可并行。的Agent任务持续排队。这时候问题才真正从Rework Problem返工问题变成Capacity Problem容量问题。这时更高容量才能真正转化成更多有效交付。最后AI写代码速度越来越快以后很容易让人觉得最大的效率提升就是“写得更快”。但真正进入Agent时代以后另一个问题可能越来越重要写错以后要花多少成本重新回来因为AI不仅能把正确方向执行得更快。它也能把错误方向分析得更完整。实现得更彻底。测试得更充分。甚至扩散给其他Agent。所以未来真正高效的AI开发不会只看生成速度。修改数量。任务运行时间。而会越来越关注Rework Ratio。Rework Depth。Time to Detect Wrong Direction。AI把Code Generation变便宜以后真正昂贵的可能变成把错误状态重新恢复成正确状态。所以未来最有价值的工程能力之一不是让AI永远不犯错。而是让它犯错时尽量早一点、浅一点、便宜一点。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的Plus/Pro会员订阅渠道有需要可自取