从 Model Spec 到 Spec-driven Development

在 AI 时代，我们正在见证软件开发范式的根本性转变。从 OpenAI 的 Model Spec 到 Kiro IDE，一个清晰的趋势正在浮现：规范（Specification，以下简称 Spec）正在成为编程的新核心。

The New Code — Sean Grove, OpenAI

OpenAI 对齐团队的 Sean Grove 在演讲中提出：在 AI 时代，软件开发的核心瓶颈已经不再是编写代码的能力，而是精确传达意图的能力。

Sean 认为，编写一份严谨、可版本化、可执行的 Spec，将成为未来程序员乃至所有知识工作者的「新超能力」。这份 Spec 将作为 source of truth，最终编译成文档、评估、模型行为，乃至代码本身，从而做到「一次编写，到处执行」。

核心洞察：代码只占价值的 10-20%

Sean 揭示了一个被长期忽视的真相：

“代码本身可能只占程序员工作价值的 10-20%，而其余 80-90% 的价值在于结构化沟通。在不久的将来，最有效沟通的人将成为最有价值的程序员。”

在我们的业务开发流程中，也确实花了大量的时间和产品对需求、和后端对接口、和设计对视觉等等，整个研发流程中充斥着大量的沟通。

这种认知转变为我们理解现代软件开发奠定了基础：编程从来不是关于代码本身，而是关于精确表达人类意图。

我们之所以觉得 Vide Coding 很爽，是因为在整个过程中，我们通过一轮轮 prompt 与模型进行沟通，整个过程将我们的期望描述的足够清楚，代码只不过是最后的一个产物。但这里就存在一个问题，我们煞费苦心调教模型的这些 prompt，其实包含了我们所有的意图，但在我们得到代码之后，就全都被丢掉了。

Sean 比喻：这就像你把源代码撕得粉碎，然后小心翼翼地对编译后的二进制文件进行版本控制。

我们传统的研发流程也是一样的，当我们遇到 PRD 没有写清楚的，与产品沟通后没有迭代 PRD，而是直接去写代码了，道理是一样的。

The New Code

Spec 的核心价值在于，它能够让所有人在一个共同的目标集上对齐。代码是 Spec 的一种「有损投影」（lossy projection），就好比将编译好的二进制再反编译，你不会得到清晰的注释与语义化的变量。而一份好的 Spec，它编码了生成代码所需的所有必要信息。一份足够强大的 Spec，在 AI 辅助下可以生成任意代码、文档甚至播客。

OpenAI 的 Model Spec

Model Spec 是 OpenAI 内部对 Spec 一个实践，表达了 OpenAI 希望为其模型注入的意图和价值观。

Model Spec 的特点

1. 人类可读：Markdown 格式，技术和非技术人员都能参与
2. 版本控制：像代码一样进行版本管理
3. 可测试性：每个条款都有对应测试用例（如 https://github.com/openai/model_spec/blob/095dabb04dd2ade5e19d4438cec9a329ad967e02/examples/sy73.md?plain=1#L4）
4. 可执行性：通过 Deliberative Alignment 直接影响模型行为

信任锚点实战：sycophancy 危机

2024年4月25日，OpenAI的GPT-4o更新引发严重的”过度迎合”危机——模型变得过分讨好用户，盲目认同错误观点。社区猜测这是有意为之还是 bug？ 在 Model Spec 中有明确的条款 「Don’t be sycophantic」，而当模型实际行为与 Model Spec 不一致时，就说是 bug 了。

在这个问题中，Model Spec 扮演了「信任锚」（trust anchor）的角色。

Kiro IDE：Spec-driven Development

Kiro 认为，虽然 Vibe Coding 很有趣，但是要将原型投入生成，需要更严谨的东西，所以 Spec 的工作流是将模糊需求的 prompt，变成 EARS 语法的需求文档，再生成技术设计，最后生成一系列开发任务去开发。更重要的是，Kiro 的Spec 与代码库保持同步

工具链演进：从 IDE 到 ITC

未来的开发环境可能是 ITC（Integrated Thought Clarifier）——一个帮助澄清思维、消除歧义的集成思考环境。

Sean 的愿景：

“当你撰写规格时，它会帮助你揪出模糊之处，要求你澄清，从而让你能更有效地将意图传达给其他人类和 AI 模型。“

立即行动：从规格开始

Sean的行动号召：

“当你开发下一个 AI 功能时，请从一份规格开始。你真正期望发生什么？成功的标准是什么？让这份规格变得可执行：将它喂给模型，并根据它进行测试。“

流程转变

• 传统流程：想法 → 对话 → 代码 → 调试 → 文档（也许）
• 规格驱动：想法 → 规格 → 代码 → 验证 → 迭代