企业官网建设流程全解析

过去做开发，写代码本身往往就是最大的时间成本之一。

一个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 Checkpoint

AI快本身不是问题。

真正的问题是：

在方向还没有确认时就进入深执行。

所以未来更成熟的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会员订阅渠道，有需要可自取！