Execution 与闭环——从执行到知识的回流

Specification 写好了。AI 知道改哪里、怎么改、不能动什么、需要测什么。接下来就是把这份精确的描述，变成可运行的代码

这就是 Execution。在整个链路中：

1 2	Knowledge → Context → Decision → Specification → Execution 收集筛选判断翻译执行

它是最后一环——前面五环的全部投入，在这一环兑现

但 Execution 有一个独特之处：它是整个链路中 AI 最擅长的一环，却也是整个链路中最依赖上游质量的一环

如果 Specification 准确完整，Execution 是高效的、机械的、几乎不需要人工干预的。如果 Specification 有遗漏或歧义，AI 会忠实地把问题变成 bug。如果 Specification 约束过多，AI 被捆住手脚，发挥不出它在实现细节上的优势

Execution 的上限，是 Specification 的质量。而 Specification 的上限，是 Decision 的质量。以此类推。整个链路是一条质量传递链，Execution 是最后一道

但 Execution 不只是被动的接收者。它有两个重要的反馈功能，常常被忽略

Execution 不只是「写代码」

说「AI 执行」容易让人以为 Execution 就是生成一个 diff——Spec 进去，代码出来，完事。

但实际上，Execution 是一个完整的闭环：

1
2
3

生成代码 → 运行测试 → 测试通过？→ 通过 → 完成
                        ↓
                       失败 → 分析原因 → 修正 → 重新测试

每一步都在考验 Specification 的质量。

代码生成：AI 读取 Spec，在项目现有代码的基础上生成修改。如果 Spec 中写了「不可删除 hasRefunded()」，AI 会保留它。如果 Spec 没提——AI 看到一段看起来冗余的代码，可能会合理地删除它来「清理代码」。Spec 中的每一个约束，在这一步承受检验。

测试生成与执行：AI 根据 Spec 中的验证场景生成测试——TC1 正常退款、TC2 超 30 天拒绝、TC3 MQ 重复消息。测试跑起来，如果全部通过，说明 Spec 和实现之间没有偏差。如果有测试失败——

问题诊断：这是 Execution 中最被低估的一步。测试失败之后，AI 需要判断：是它生成的代码写错了（实现问题）？还是 Spec 中遗漏了某个约束（Spec 问题）？还是代码中有一个 AI 不知道的隐含依赖在起作用（Context 问题）？

这个诊断能力的强弱，决定了一个 AI Agent 是「写完就完」还是「能真正闭环交付」。

如果 AI 能诊断到问题的真正来源——「这个测试失败是因为 Spec 中没有提到 RefundEventConsumer 也需要同步更新」——它就可以把问题追溯到上游。要么自行补充（如果影响面清晰可推断），要么标记出来让人确认（如果影响面不确定）

Execution 不是一个单向的「生成」动作，而是一个「生成→验证→诊断→修复」的闭环。这个闭环的质量，决定了 AI 能把多少比例的开发任务做到真正可交付，而不是生成一堆代码之后再让人花同样的时间改 bug

Execution 是上游质量的照妖镜

闭环中的诊断步骤，还有一个更深远的价值：它会把前面五环中的问题，一个不漏地压出来

Knowledge 不完整（没有历史决策记录）→ AI 在 Execution 中删除了关键的幂等检查 → 测试失败 → 诊断：为什么这个检查不能删？→ 答案在 ADR 里，但 ADR 不存在
Context 有遗漏（没追踪到 MQ 消费者）→ AI 生成的代码和消费者逻辑不一致 → 集成测试失败 → 诊断：漏评估了影响面 → 上游 Context 构建阶段的缺口判断不够
Decision 有问题（选了方案 A 但方案 A 在当前架构约束下不可行）→ AI 实现后发现违背了架构约束 → 回退 → 需要重新做 Decision
Specification 有歧义（「同步更新消费者」但没说怎么更新）→ AI 猜了一个实现方式 → 不符合预期 → 需要人介入澄清

每一条 Execution 中的失败，都可以反向追溯到上游某个环节的不足。这听起来很糟糕——但反过来想，这恰恰是 Execution 的价值之一

在传统流程里，上游的问题同样存在——只是它们不会被系统性地暴露出来。人写代码时，遇到知识缺失会去问、会自己补全、会在敲键盘的过程中修正。这个过程是有效的，但是不可见的——你不知道「问同事」这一步花掉的时间，本质上是在填补 Knowledge 中缺失的历史决策

AI Execution 把这些问题暴露在日光下。每次 AI 停下来说「我不确定这里该怎么处理」，不是因为 AI 不行——是因为上游的某个环节留下了一个信息缺口。Execution 是整条链路的质量仪表盘。 它的反馈告诉你哪个上游环节需要加强

回到 Knowledge：链路的闭合

Execution 最重要的产出，不是代码本身——而是代码进入 Knowledge 空间，成为下一次任务的知识来源。

Knowledge → Context → Decision → Specification → Execution
    ↑                                                      │
    └──────────────────────────────────────────────────────┘
                       代码、测试、部署配置
                       回归 Knowledge 空间

这不是一条有终点的直线，这是一个持续运转的循环。

一次退款校验的 Execution 完成之后，系统里多了一段新的代码、新的测试、新的错误处理逻辑。下一次的任务——比如在退款流程里再加一个 VIP 用户的特殊处理——它的 Context 构建会自动包含这次新增的代码。AI 会看到上次加的 validateOrderAge 方法、会看到已有的校验模式、会看到历史测试用例——它的 Context，比上一次任务开始时更丰富了一点。

这就是知识的累积效应：每一次 Execution，都在为下一次任务降低 Context 构建的成本。

但这个累积效应有一个前提——其他几层知识也需要跟着更新。Execution 只自动更新了代码层。业务逻辑、架构设计、历史决策、需求——它们不会自动更新。如果不主动维护，下一次任务的 Context 里，代码是最新的，但 ADR 还是三年前的，架构图还是五年前的。

这就是知识的累积效应的另一面：如果不主动维护，其他几层知识不会自己更新。Execution 之后，需要一个显式的收尾动作——把这次改动中涉及的决策理由、影响面发现、新增的边界条件，写回 ADR 或项目文档。不做这一步，知识负债又多了一笔

这就回到了系列第一篇的命题：软件开发管理的对象不只是代码，是知识。Execution 产出了新的代码——但如果不把这次 Execution 中产生的决策理由、影响面发现、踩过的坑记录下来，下一次任务还是会从同样不完整的 Context 出发，还是会踩同样的坑

系列回望

从第一篇到这一篇，整个 AI Native 软件开发的链路走完了。

第一篇提出了一个命题：软件开发管理的对象，可能从来都不是代码，而是知识。

第二篇追问：那「知识」到底是什么？拆出了六个层次——代码、业务逻辑、架构设计、历史决策、需求、基础知识。

第三篇讨论了从浩瀚的 Knowledge 空间中筛选 Context——为什么这是最难的一步，它的五重约束，以及迭代构建的循环。

第四篇把 Decision 拆成了四类——定位、方案、影响评估、验证策略——并讨论了在信息不完备下做决策的策略。

第五篇引入了 Specification，一个传统流程中不需要但在 AI 时代变得必要的东西——把人类决策翻译给 AI 的翻译层。

这一篇讨论了 Execution——链路的终点，也是新循环的起点。

整个系列有一条暗线贯穿始终：AI 没有改变软件开发的本质——它只是把很多一直隐式存在的问题，从暗处搬到了明处。

知识一直都很重要。Context 构建一直都很花时间精力。决策一直在信息不完备的情况下做。Specification 的缺失一直由程序员在敲键盘时自动补全

AI 做的事情不是创造了这些问题，而是让这些问题无法再被忽略。因为 AI 不会自动补全、不会主动问、不会在不知道该怎么做的时候去拍同事的肩膀

这看起来是 AI 的局限。但这可能恰恰是 AI 带来的最大价值：它逼我们把一直隐式存在的工程流程，变成显式的、可管理、可优化的过程。

这是 AI Native 软件开发系列的第六篇。前五篇：软件开发管理的对象是知识 → 知识的六个层次 → 从知识到上下文的筛选 → 工程决策——在不确定中做最好的选择 → Specification——把决策翻译给 AI。下一篇继续：知识沉淀的第一步——统一语言与 ADR。如果你有不同的理解或者实践经验，欢迎一起讨论。