点击上方蓝字关注我们

提示词工程已死，未来属于“规范工程师”。面对 AI 时代的高速开发需求，Vibe Coding（氛围编程）带来的无序正在被淘汰。本文从 OpenAI 的核心理论 出发，结合 AWS Kiro 的行业落地 与 GitHub 的现象级开源项目 spec-kit，探讨从「氛围编码」到「规范驱动开发」的演进。当 AI 成为执行者时，软件开发的核心将转向 —— 精确传达意图的能力。


1

一切从那句「你先搞一个出来看看」开始
相信很多开发者都经历过这样的“共情”时刻：
“需求还不太确定，你先凭感觉搞个原型看看。”
于是你打开 IDE，凭感觉写下第一行代码。几天后，需求改了；快上线时，方向又变了。最后虽然项目能跑，但大家都不太满意——代码像拼布，逻辑像迷宫。
这，就是所谓的 “Vibe Coding”——氛围编程。
Vibe Coding 的特点：
  • 没有明确的规范文档；
  • 代码先行、需求滞后；
  • 以“先做再说，快速迭代”为主旋律。
而它的问题也显而易见：重复返工、沟通混乱、技术债堆积如山。整个团队都在忙碌，但都在为混乱买单。


2

OpenAI 揭秘：你的价值，80% 在于「结构化沟通」
当所有人都在聚焦 AI 如何写代码时，OpenAI 对齐团队的 Sean Grove 提出了一个颠覆性的观点：
“在 AI 时代，软件开发的核心瓶颈不再是写代码的能力，而是 —— 精确传达意图的能力。”
他认为，程序员最有价值的产出并不是代码。代码可能只占创造价值的 10%～20%；剩下 80%～90% 的价值，在于 结构化沟通（Structured Communication）。
随着 AI 模型的执行力越来越强，能与 AI 高效沟通的人，才是最有价值的程序员。
这也解释了为什么 OpenAI 连续三次发布《Model Spec》文档——它不是给模型“画红线”，而是在为人类提供 “与 AI 沟通的规范模板”。


3

代码只是 Spec 的「有损投影」
Sean Grove 预言：编程的核心介质正在从代码转向 「规范」（Specification, 简称 Spec）。
他指出，Vibe Coding（即“用 Prompt 生成代码”）有个悖论：我们保留了生成物（代码），却丢弃了包含意图的 规约（Prompt/Spec）。
Sean 的比喻一针见血：“这就像你把源代码撕成碎片，然后小心翼翼地对编译后的二进制进行版本控制。”
这正是 Spec-Driven Development 背后的核心哲学。
Spec 的价值：
  • 一次编写，处处运行：代码只是 Spec 的「有损投影（lossy projection）」。一份足够强大的 Spec，在 AI 辅助下可以“编译”为 TypeScript、Rust、API、测试乃至文档。
  • 对齐人类：Spec 让所有人（产品、研发、安全、法务）在同一语义层协作。

4

行业巨头验证：AWS Kiro 的实践
Sean 的愿景并非空谈。

亚马逊云科技（AWS） 近期推出的 AI IDE——Kiro，便是 Spec 驱动思想的落地案例。

Kiro 认为，从原型到生产，必须有严格的规范流。因此它通过 AI 将开发流程强制“前置思考”：

  1. 从 Prompt 到需求：将自然语言 Prompt 分解为详细的用户故事与验收标准。  

  2. 从需求到设计：分析 Spec 与代码库，生成技术设计文档、数据流图、接口说明。  

  3. 从设计到实现：自动生成任务清单、排序优先级、附带测试细节。

AWS 推出 Kiro，不是炫技，而是源于他们内部痛点：  

“当上千团队与 AI 协作时，缺乏统一规格语言会让沟通成本呈指数级增长。”

这清楚表明——Spec 驱动开发已从理念，变为现实生产力。



5

社区追随：spec-kit 的开源实践
与巨头的商业实践同步，开源社区也以惊人速度响应。
GitHub 上的开源项目 spec-kit
（短短数周已获 39.7k⭐️），

正是将“Spec 优先”理念大众化的工具。

1.《项目宪法》（CONSTITUTION.md）
定义技术栈、代码规范、性能要求等底线标准。
技术栈：必须使用 Next.js 
代码规范：遵循 Prettier 格式 
性能要求：首屏加载 < 2 秒
2.《项目规范》（SPEC.md）
通过自然语言命令驱动整个项目：
  • /specify —— 定义规格
  • /plan —— 生成计划
  • /tasks + specify apply —— 执行任务
几分钟后，一个 结构清晰、风格统一、可直接运行 的项目
便自动生成在你的屏幕上，连 README 都写好了。


6

从混沌到秩序：规范驱动开发的崛起
在国内开发者圈，
这一转变同样正在发生。
正如知乎专栏《规范驱动开发的兴起》指出：
“当业务复杂度与协作规模快速膨胀时，‘凭感觉写代码’会让系统失去方向感。
每个开发者都在忙，但没人真正知道系统该长什么样。”
规范驱动开发（Spec-Driven） 正是在这种混乱中诞生的秩序力量。
它让团队在编码前先对齐目标、标准与接口，
让 AI 和人类都能读懂项目的意图。
“过去我们以‘实现功能’为目标；
现在我们以‘定义规则’为起点。”
——知乎《规范驱动开发的兴起》
这不是形式主义的回潮，
而是 “让意图被机器理解”的新生产方式。


7

RedMonk 视角：规格是「意图的载体」
在 RedMonk 的 Rachel Stephens 分析中，
她提出了一个关键洞见：
“规格并非真理的源头（source of truth），
而是意图的载体（source of intention）。”
她认为，Vibe Coding 与 Spec-Driven 并非对立阵营：
阶段最优策略
创新探索期Vibe Coding —— 解放创造力、快速试错
系统化协作期Spec-Driven —— 对齐意图、提升一致性
她总结道：
“Vibe coding unlocks momentum.
Spec-driven development helps teams slow down just enough to think clearly about what they’re building and why.”
Vibe 让我们快起来，Spec 让我们准下来。


8

Vibe Coding 的终局：程序员变身「规范工程师」
无论是 Kiro 还是 spec-kit，
它们都在证明一件事：
Spec-Driven Development 是对无序开发的优化升级。
它不是要替代程序员，
而是让程序员从“码农”进化为“系统设计师”。
旧范式（Vibe Coding）新范式（Spec + AI）
以手写代码为中心以定义规范为中心
执行需求、修 Bug设计系统、定义规则
代码即成果思维即生产力
在中文开发圈，这股“从 Prompt 到 Spec 的转变”也在发生。
越来越多团队开始用 AI 辅助定义接口契约、生成测试、撰写 ADR，
这正是 Specification Engineering（规范工程） 的早期雏形。


9

未来展望：让 AI 读懂「我们的规范」
未来的 IDE，不再是 “Integrated Development Environment”，
而会成为 ——
Integrated Thought Clarifier（集成思想澄清器）
在不远的未来，我们不会再问
“AI 能写什么代码”，
而会问：
我们该如何写出 AI 能真正理解的规范？
请问,你的选择？
当代码不再靠“感觉”，
你还愿意 Vibe 一下，还是愿意先 Spec 一下？



👇 欢迎在评论区聊聊你的看法！

如果觉得这篇文章对你有启发，

请点赞 + 收藏 + 在看

让更多人看到这场正在发生的开发范式变革。✨




10

扩展阅读
  • OpenAI Model Spec（2025-02-12）
  • OpenAI Model Spec（2025-04-11）
  • OpenAI Model Spec（2025-09-12）
  • RedMonk：Spec vs. Vibes
  • 知乎专栏：《规范驱动开发的兴起》
  • GitHub：spec-kit 项目