为什么 AI 还没解决软件交付问题，以及什么才能解决

01

一个功能的旅程

跟随一个功能走过一家典型的公司。

它始于一次对话。业务部门的某个人解释客户需要什么，分析师把它写成了一页文字。架构师读了那一页，画出一张图。有人把图变成 API 规范。产品负责人把它切成工单。开发者读工单并写代码。测试人员再读一遍工单并写测试。

六个人，六份文档，六次翻译。每一次都是手工完成的，每一次都丢失了一点原本的意思。等到代码发布时，它做的事情与业务所要求的接近——但并不完全一致。而图、API 规范和工单已经开始偏离代码，也彼此偏离。

软件交付没有打字问题。它有翻译问题。

02

于是我们在每一步都加入了 AI

显而易见的做法是加速每一步：为需求配一个聊天机器人，为代码配一个副驾驶，为工单配一个 AI 插件，为图配一个生成器。采用率巨大——90% 的技术专业人士现在在工作中使用 AI（DORA）。它一波波到来：

1. AI 辅助编码。每个编辑器里的副驾驶。主流且已稳定。
2. 规模化编码智能体。跨多个团队修改多个文件的智能体。正在跨越鸿沟。
3. AI 原生的交付生命周期。围绕一个连通的意图表示重新设计整个流程。才刚刚开始。

前两波让每一步更快。它们没有让交付更快，因为步骤之间的翻译仍然是手工完成的——而现在有更多产出需要翻译。

确实看到真正收益的团队有一个共同点：他们先重新设计了流程，把中间文档变成机器可以处理的东西，然后再加入智能体。他们获得超过 20% 收益的可能性是两倍。正如 DORA 所说，AI 是“无论好坏，都会放大已经存在的任何系统。”

03

市场尝试的四种方式——以及每一种都缺失的那一块

工具制造商也看到了这个问题。四种主要方法各自解决了其中真实的一部分：

规范驱动框架

GitHub Spec Kit、BMAD-METHOD、OpenSpec、Kiro。用持久的书面规范代替一次性的聊天提示。但规范只存在于一个项目和一个智能体；它不会作为一个随每次发布而成长的模型被延续下去。

上下文平台

Augment。跨会话对大型代码库的深度记忆。但现有代码是事实来源，所以它无法判断该代码是否仍然符合业务需求。

架构工具

C4 工具和企业架构平台。系统和边界的清晰图景。但图是给人看的；智能体无法查询它们，它们也不治理代码如何变化。

约定工具

Agent OS。从代码中学习团队的约定并将其提供给智能体。但它刻意不设一个常驻的意图模型，因此架构留给模型去猜测。

每一个都只修复一个片段。它们都没有把一端的业务意图与另一端的运行代码连接起来。这种连接正是缺失的线索。查看完整对比。

04

让线索成为现实

连接各个步骤需要五件事协同工作。以下是每一项，以及它在 M1Spec 中的位置。

05

有什么变化

向任何 AI 交付工具提出的五个问题

1. 它是否会构建一个随每次发布而成长的模型，还是你每次都要编写新的规格和提示词？
2. 它是否从业务意图出发，还是只从已经存在的代码出发？
3. 智能体能否读取架构并据此行动，还是它只是一张仅供人看的图？
4. 结构模式是否作为代码运行，还是留给语言模型去解读？
5. 是否只有一个词汇表，从需求一直贯通到类名？

为你的自身设置回答这些问题

M1Spec 的构建就是为了让这五个问题的答案都是是。