AI 时代，真正的工程资产
不再只是代码

过去很长一段时间里，我们默认代码库是软件团队最重要的资产。每一行代码都来自真实业务、真实用户、真实故障和真实妥协，因此尊重历史代码是必要的。

但在 AI 参与软件生产之后，这个判断需要被重新审视。历史代码仍然重要，但它不再是最重要的资产。真正决定一个团队能否持续交付、持续演进、持续复用能力的，不只是已有代码本身，而是代码背后那些更高层次的沉淀：概念建模、业务建模、业务流程、SPEC、技术方案、工程化规范，以及它们之间的连接关系。

换句话说，最重要的资产正在从"实现结果"转向"可持续交付的能力"。

从代码资产，转向模型资产

AI 可以更快地产生代码，也可以更快地重写代码。过去需要数天完成的实现，现在可能在清晰约束下被压缩到数小时。

这带来了一个很直接的变化：如果底层概念是错的，继续修补代码往往不如重新实现。因为实现成本下降了，但概念错误带来的系统性偏差没有下降。

真正昂贵的部分，变成了这些问题：

• 我们到底在解决什么业务问题？
• 核心概念如何定义？业务对象之间是什么关系？
• 流程中的关键约束是什么？
• 技术架构需要支撑哪些属性？
• 哪些决策是长期稳定的，哪些只是当前阶段的取舍？

这些内容如果没有被沉淀下来，AI 只能围绕局部代码做推理，很容易陷入"修补实现"的循环。相反，如果团队沉淀了清晰的概念模型、业务流、设计分层和技术约束，AI 就可以围绕正确的上下文持续协作。

因此，业务、技术和工程化融合后的沉淀，才是 AI 时代更关键的工程资产。融合意味着 SPEC 引用业务概念和业务流程，测试用例直接对应 SPEC 中的验收条件，架构决策注明它在保障哪条业务约束。三者各写各的，AI 只能在某一层做局部推理；三者打通，AI 才有可能在正确的上下文里展开实现。

人的协作方式也需要进阶

AI 并不会自动让团队协作变好。它只是放大现有协作方式的效果。如果团队仍然只围绕任务列表协作，AI 会加速任务执行，但不一定带来更好的结果。真正需要升级的是协作对象本身。

过去我们常说"任务拆解"，现在更需要"目标拆解"。任务拆解关注的是做什么，比如实现页面、接接口、修 bug、补测试。目标拆解关注的是为什么做、做到什么程度、哪些边界不能破坏、如何判断结果是对的。

举个例子。用户提出"为团队成员做一个 Key 状态页"。按任务拆解会立刻进入"做表格、加状态字段、写接口、补几条测试"；按目标拆解会先问：成员真正想知道的是"我现在能不能开始任务"，这个判断需不需要管理员介入，失败时该找谁。目标定下来，方案才有判断标准；只看任务清单，AI 写得很快，但写出来的不一定是用户要的东西。

过去我们习惯制定方案细节，比如字段怎么命名、接口怎么写、组件怎么拆。现在更重要的是先定义概念模型和宏观约束，让实现细节可以在清晰边界内由人和 AI 共同展开。

过去我们经常直接讨论技术细节。现在更应该先讨论业务流、设计分层和架构属性：一致性、扩展性、可观测性、可测试性、可恢复性。这些才决定了系统长期能不能演进。

甚至 debug 的对象也在变化。过去 debug 更多是在调功能、调代码、调接口。现在很多时候真正要 debug 的，是概念本身：模型是否错了？边界是否错了？业务流程是否遗漏了状态？SPEC 是否表达了错误假设？

这不是要求团队一次性做到完美。相反，AI 时代更适合渐进式进阶。人和 AI 可以一起迭代概念，一起补全模型，一起把模糊经验变成可复用资产。

Ops 层会变得越来越关键

当 AI 进入软件生产流程后，单纯"让 AI 写代码"远远不够。真正决定效率上限的，是团队是否打通了 Ops 层。这里的 Ops 不只是传统意义上的部署、CI、监控，而是围绕 AI 协作建立的一整套闭环。

• 打通 AI 自检验闭环，让 AI 不只是生成结果，还能基于工具、数据和反馈验证结果。
• 定义卡点、规范和质量验收标准，让协作过程不是靠个人经验临时判断。
• 追踪过程信息，记录一次需求从概念、方案、实现到 review 的演进路径。
• 建立 review 规范，维护"业务 - 架构 - 技术实现"之间的知识库，让 review 不只是看代码风格，而是检查实现是否匹配业务模型和架构约束。

这也是为什么团队会越来越急需一个 DevOps Agent。它不只是帮忙跑命令、看 CI、发通知，而是把 Ops 层那些工程师容易遗漏、重复消耗、难以持续维护的过程性工作自动化。具体来说，它需要承担类似这样的职责：

• 把方案文档自动拆解为验收 checklist，方案改了 checklist 跟着变。
• 检查"代码改了但 SPEC 没改"或者"SPEC 改了但测试没跟"，主动指出错位。
• 从 review 评论和返工记录里抽提结论，沉淀进"业务 - 架构 - 技术实现"知识库。
• 追踪一次需求从概念、方案、实现到验收的完整演进路径，让历史决策可被检索。

它的价值不是替代工程师，而是把工程师从重复消耗里释放出来，专心做判断和取舍。

两个实践结论

第一个结论是：当核心概念被推翻时，重写实现往往优于继续调整代码。

这条规则有一个明确的边界：局部 bug 当然应该局部修复，不是所有改动都需要重写。但如果核心概念已经变了，继续沿着旧实现打补丁，往往会留下更多历史包袱。AI 降低了重写成本，也让我们有机会更果断地回到正确模型上重新生成实现。

第二个结论是：不要过早打磨细节。

在概念还没有稳定之前，过早优化 UI、接口细节、代码结构、边缘体验，都会增加后续调整成本。更好的顺序是先做概念迭代，再做细节迭代。先确认模型、流程、边界和约束，再打磨实现质量。

结语

AI 时代的工程效率，不来自于更快地写更多代码，而来自于更快地形成正确概念，并把这些概念转化为可验证、可复用、可持续交付的工程资产。

历史代码仍然值得尊重。但未来真正拉开差距的，是团队能否把业务理解、技术判断和工程化过程沉淀成系统能力。

这篇文章讲的是团队该沉淀什么；前一篇《我们为什么要做 AI Coding Harness》讲的是 AI 的产出该怎么被验收。两件事是一组：前者提供原料和约束，后者提供检查和反馈。AI 编程要走得稳，两边都要在场。