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 不只是被动的接收者。它有两个重要的反馈功能，常常被忽略

上一篇文章讨论了 Decision——在信息不完整的情况下，如何做出最好的工程决策。

但决策做出来之后，问题还没完。决策是在人脑子里完成的——带着判断、权衡、以及对系统上下文的理解。而下一环 Execution，是由 AI 来执行的——AI 需要精确、完整、无歧义的输入

人脑子里的决策，和 AI 需要的输入，是两种不同的东西。二者之间存在一个翻译鸿沟

在整个链路中：

1
2

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

Specification 就是这个翻译层。它回答的问题是：如何把工程决策，变成 AI 可以精确执行、不会误解的描述？

经过了上一篇关于 Context 的讨论，一个自然的问题是：上下文构建完成之后呢？

上一篇文章的结论是，Context 构建永远不可能完美——五重约束互相冲突，完备性和最小性无法兼得。这意味着一个让人不太舒服的现实：工程决策，永远是在信息不完整的情况下做的

这听起来是个缺陷。但这正是「工程判断力」之所以存在的原因。如果每次决策之前信息都是完备的，那就不需要判断力了——按规则执行就行

在整个 AI Native 软件开发的链路中：

1

Knowledge → Context → Decision → Specification → Execution

Decision 是第三环。它是整个链路的价值兑现点——前面收集 Knowledge、构建 Context，全部是为了支撑这一环。如果 Decision 的判断质量低，上游的一切投入都白费了

更重要的是，Decision 可能是整个链路中最需要人的一环

上一篇文章把软件开发中的知识拆成了六个层次：代码、业务逻辑、架构设计、历史决策、需求、基础知识

拆完之后，一个很自然的问题就摆在了面前：六层知识浩瀚如海，但一次具体的开发任务——比如「在退款流程里加一个超 30 天拒退的校验」——只需要其中的极少一部分。剩下的全是噪音，不仅没用，还会干扰判断

怎么从知识的海洋中，捞出刚好需要的那一滴？

这就是 Context 要解决的问题。在整个 AI Native 软件开发的链路中：

1

Knowledge → Context → Decision → Specification → Execution

Context 是第二环，承接 Knowledge，支撑 Decision。但我越来越觉得，它可能是整个链路中最难的一环

不是因为其他环节简单，而是因为这一环要解决的问题，本质上没有一个完美解

上一篇文章讨论了一个观点：软件开发真正管理的对象，也许从来都不是代码，而是知识。AI 的出现没有让知识变重要——它只是让我们不得不正视这个一直存在的事实

但文章写完之后，一个更基础的问题一直在我脑子里转：

当我们说「知识」的时候，到底在指什么？

代码算知识吗？业务逻辑呢？架构设计呢？那些只存在于老员工脑子里的历史决策呢？这些看起来完全不相关的东西，为什么都叫「知识」？

这篇文章把这个问题拆开来看

最近一段时间，一个感受变得非常清晰：AI 写代码的速度，已经远超过去了

一个 CRUD 接口、一个 Controller、一个 SQL，甚至一整个功能模块，AI 都能够很快完成

但是，在真正的业务项目里，我花费时间最多的，却越来越不是写代码

而是：

• 不知道应该改哪里；
• 不知道为什么这里要这样设计；
• 不知道有没有类似实现；
• 不知道修改之后会影响哪些地方；
• 不知道这个看起来无关的模块为什么会一起坏掉。

举一个很常见的例子，一个需求只是：修改退款流程中的某一个逻辑。看起来只是改一个 Service，结果上线测试之后，却发现：

• 积分没有发放；
• 优惠券状态异常；
• 消息通知没有发送。

最后检查代码才发现：退款流程后面还有

• MQ
• Event
• 定时任务
• 另外几个系统的监听逻辑

这些依赖关系，并没有直接写在你修改的代码里

困难的地方，从来都不是：怎么写代码，而是：如何理解这个系统

最近几个月，我开始越来越多地使用 AI 参与日常开发，起初我以为变化最大的会是 Coding

但真正用了一段时间后，我发现最大的变化其实发生在研发流程——一个我们过去习以为常、现在却开始处处「别扭」的地方

一、旧流程为什么开始别扭

一个让我一直觉得别扭的问题

我们团队的研发流程和大多数技术团队差不多：

1

需求评审 -> 技术方案设计 -> 技术方案评审 -> 开发 -> 测试 -> 上线

过去，这套流程跑得很顺，但在引入 AI 之后，我们很自然地开始让 AI 根据需求直接生成 Spec（实现规范）进行开发。这时不出意外的话，很快就遇到了一个尴尬的情况～

就是 AI 生成的 Spec 非常的详细，详细到了包含 DTO、数据库字段、SQL、Mapper、API、Migration、Unit Test，甚至每个字段的命名和类型

这时候，当我们拿着这份 Spec 去评审时，就会有些奇怪…，因为评审会上，大家真正关心的问题是：

• 整体业务流程是否合理？
• 服务之间如何交互？
• 数据应该归属于哪个系统？
• 为什么用 MQ 而不是 RPC？
• 为什么新增一张表，而不是修改已有表？

几乎没有人会讨论 refund_reason 字段是 VARCHAR(100) 还是 VARCHAR(255)

于是，我们可能会做一件更别扭的事：先让 AI 生成一份极详细的 Spec，再让 AI 把这份 Spec 「翻译」成传统技术方案模版的文档，以供评审

后来我意识到：问题不在于 Spec 写得不好，而在于我们还在用 AI 出现之前的研发流程，去套一个 AI 出现之后的协作方式

我们开发的每一个需求，基本 80% 的时间在搞清楚该改什么，只有 20% 在写代码。这不是能力原因，更是在于软件的复杂度

一个似曾相识的场景

比如接到需求：结算单状态机增加一个「部分退款」中间状态

在梳理了 SettlementService、SettlementController、SettlementStateMachine 后，改动范围很清楚——加一个枚举值，改三条状态流转路径。改动量很小，代码 review 也顺利通过。

结果上线第二天，告警来了：对账报表里部分退款的结算单被重复计入

问题出在一个没人知道的类——ReconciliationReportBuilder。它内部有一个 switch-case 遍历结算单状态来决定归入哪个科目，新增的枚举值走到了 default 分支，被当成「已结算」处理了

这个类的存在，在改代码的时候可能完全不知道。甚至不知道「我应该知道它的存在」

如果你在接手业务需求的时候也踩过类似的坑，这篇文章就是写给你的

AI 编程助手已经越来越常见。很多人会用 Claude Code、Cursor、Codex CLI 这类工具来读代码、改代码、解释架构、定位 bug。

但 AI 经常会遇到一个问题，尤其是项目比较大的时候：它并不是真的掌握了整个代码库的结构，而是在不断搜索文件、读取文件、猜测关系。

比如你问：这个请求最后是怎么走到数据库查询的？

如果没有更好的索引，AI 可能会从 route 开始搜索，打开几个 controller，再继续找 service、model、query builder。过程中它会消耗很多 token 和工具调用，而且一旦漏掉某个框架约定或隐式调用，结论就可能不完整。

而 CodeGraph 要解决的，就是这个问题。它为代码库建立一个本地的代码知识图谱，让 AI 编程助手可以直接查询代码结构，而不是每次都从零开始翻文件。

最近在读 Superpowers 里的一个 skill：subagent-driven-development。

这个 skill 很有意思。它并不是教 agent 如何写某一种代码，而是在设计一种开发流程（开发+review）：当我们已经有一个实现计划，并且计划里的任务相对独立时，主 agent 不再亲自完成所有工作，而是把每个任务派发给新的 subAgent，再通过两阶段 review 来控制质量。

它的核心思想可以用一句话概括：

每个任务派一个新的 subAgent + 两阶段审查 = 可控、高质量、低上下文污染的开发流程。

也就是说，它真正关注的不是「让更多 agent 干活」，而是「如何让多个 agent 在明确边界内协作」。