软件开发的历史，本质上是一部不断降低心智负担的历史。
最早的时候，程序员用汇编语言跟机器对话，每一个指令都对应着具体的寄存器操作，门槛极高，效率极低。后来出现了C、Java这样的高级语言，抽象层次提高了，程序员可以更专注于逻辑而非硬件。再后来，框架和工具链越来越完善，开发效率进一步提升。
2025年初，Andrej Karpathy 在 X 上提出了 Vibe Coding 的概念——"完全沉浸在氛围里，拥抱指数级增长，忘记代码的存在"。这种工作流的核心是：你说需求，AI写代码，你看效果，再调整，循环往复。开发者从"代码编写者"变成了"意图表达者"。
Vibe Coding 的速度是惊人的。一个产品经理用自然语言描述需求，Cursor 的 Composer Agent 就能自动生成路由、组件、API 请求、状态管理，整个过程可能只需要几分钟。但问题也随之而来：随着项目规模扩大，对话上下文被截断，AI 开始"修一个 Bug 引入三个新 Bug"，代码重复率飙升，没人能解释某个 Redis Key 的结构为什么是这样。业界称之为"三个月之墙"——前三个月速度飞快，三个月后技术债务开始反噬。
于是，Spec Coding 应运而生。
Spec Coding 到底是什么？
简单来说，Spec Coding 就是 Vibe Coding 的超级提示词工程。
它的核心思想来自一篇提交至 AIWare 2026 的 arXiv 论文："规格说明书是首要产物，代码完全从中派生。" 工作流是这样的：先写一份详细的技术规格文档（Spec），定义需求、接口契约、数据模型、边界条件；然后人工评审这份规格；接着让 AI 把规格拆分成原子任务；最后逐任务实现，并验证实现是否与规格对齐。
这听起来很像传统的软件开发流程——产品经理写 PRD、架构师出设计文档、程序员写代码。但 Spec Coding 的关键区别在于：过去这三层是分离的，由不同的人完成；现在这三层被压缩成一层"规格工程"，由 AI 作为兼容层直接输出可运行产物。
换句话说，"代码文件"正在从编程语言变成自然语言，AI 则扮演 Vite 在 Vue 和浏览器之间的角色——它负责把人类可读的自然语言"编译"成机器可执行的代码。
如果你回顾软件工程的发展史，会发现一个清晰的模式：科技进步的很大一部分，就是在加兼容层。
操作系统是硬件和应用之间的兼容层；虚拟机是物理机和程序之间的兼容层；浏览器是操作系统和 Web 应用之间的兼容层；框架是语言和业务逻辑之间的兼容层。每一层兼容层的加入，都让上层开发者的心智负担降低了一个数量级。
Spec Coding 也是这个逻辑。只不过这一层兼容层更智能——它不是用固定的规则做翻译，而是用 LLM 的推理能力做"智能编译"。
过去，产品经理写 PRD，架构师出设计文档，程序员写代码，测试工程师写用例——这是一个线性流水线，信息在传递中不断衰减和失真。现在，一份足够精确的 Spec 可以直接驱动 AI 生成代码、测试和文档，信息传递的链条被压缩到了极致。
这里有一个更深层的观点：自然语言的表达能力理论上是图灵完备的。
什么意思？人类可以用自然语言描述任何算法。你可以用中文把快速排序、Dijkstra 最短路径、甚至一个完整的分布式系统架构描述得清清楚楚。自然语言不是受限的声明式语言，它是人类最擅长的沟通媒介。
而 LLM 的"编译"能力，正在逼近这个上限。它不是用一种受限的 DSL 替代代码，而是用人类最擅长的沟通媒介替代形式化符号。
这就引出了一个"暴论"：如果 Spec 足够精确、可验证、可执行，它本身就是代码——只是人类可读的那种。
从汇编到自然语言：Code 一直在往 Language 的方向发展
人类编程语言的发展史，其实是一部"可读性进化史"。
汇编语言几乎不可读，只有机器能直接理解。C 语言引入了人类可读的语法，但指针和内存管理仍然折磨着无数程序员。Java 和 Python 进一步提高了抽象层次，让代码更接近人类思维。到了现在，TypeScript、Rust 这样的现代语言，类型系统和语法设计都在努力让"错误的代码看起来就是错的"。
而 Spec Coding 把这个趋势推到了极致：干脆不要编程语言了，直接用自然语言。
你可以理解成，大模型是编译器，人类通过写自然语言，大模型把自然语言编译成"可读性低"的编程语言，或者直接编译成机器语言。
这听起来是不是很熟悉？早期的 4GL（第四代编程语言）就是这个思路。
上世纪70年代，RAMIS、NOMAD、FOCUS 等 4GL 语言的出现，核心理念就是"用更高层次的抽象快速开发商业软件"。它们的口号是：一行 4GL 代码可以替代几百行 COBOL。比如 PRINT ACROSS MONTH SUM SALES BY DIVISION 这样接近自然语言的指令，就能生成复杂的报表。
4GL 最终没有取代 3GL，原因是多方面的：当时的硬件性能不足以支撑高级抽象的运行时开销，4GL 的表达能力确实有限，生态也不够成熟。但问题的本质不是方向错了，而是时机未到。
现在的 Spec Coding，某种程度上就是 4GL 的"精神续作"，只是这次的"编译器"不是固定的语法解析器，而是具备推理能力的 LLM。自然语言的表达能力不再受限，因为 LLM 可以理解上下文、处理歧义、甚至主动澄清需求。
软件工程里有一个长期存在的痛点：需求工程。
需求分析、需求规格说明、需求验证——这些活动占据了项目成本的很大一部分，而且一直是人工密集型工作。需求文档写完后往往就束之高阁，与代码实现逐渐脱节，成为"活死人文档"。
Spec Coding 本质上是把"需求工程"这一层也自动化了。
当规格文档成为"唯一的事实来源"（Single Source of Truth），并且 AI 能够严格基于规格生成代码、验证对齐时，需求文档就不再是静态的 PDF，而是可执行的活文档。AWS Kiro 提出的"Living Specs"概念，以及 Augment Code 的 Intent 产品，都在验证这个方向——规格文档随代码实现自动更新，多个 AI Agent 同时读写同一份规格。
这意味着，未来的开发流程可能是这样的：
- 人类用自然语言写出精确的系统规格
- AI 自动将规格拆分为任务、生成代码、编写测试
- AI 自动验证实现与规格的对齐度
- 人类只需要做架构决策和最终审批
人类的角色从"写代码的人"变成了"写规格的人"和"审规格的人"。
Thoughtworks 有一个很精辟的观察："理解系统曾经是动手写代码的自然副产物。现在，团队需要新的习惯来保持这种理解。上下文管理已经从副产品变成了一项核心技能。"
过去，工程师的核心能力是写代码的能力、Debug 的能力、熟悉语法的能力。现在，这些能力正在让位于：
- 写规格的能力：如何用自然语言精确描述系统行为
- 评估 AI 输出的能力：如何判断 AI 生成的代码是否符合意图
- 架构决策的能力：在多个技术方案中做出正确选择
- 规格 Review 的能力：像过去 Review 代码一样 Review 规格
这不是说写代码的能力不重要了，而是说在 AI 时代，"与 AI 协作的能力"比"独自写代码的能力"更有价值。
当然，Spec Coding 不会取代 Vibe Coding，就像施工图不会取代草稿纸。
Vibe Coding 的价值在于探索和验证——快速原型、技术选型、概念验证。当你还不确定要做什么的时候，Vibe Coding 是最快的路径。但一旦确定了方向，一旦系统要进入生产环境、要团队协作、要长期维护，就必须切换到 Spec Coding。
聪明的工程师会在对的时间用对的工具：探索时用 Vibe，让想法快速落地；建设时用 Spec，让系统经得住考验。
写在最后
如果我们把视野拉远，会发现一个清晰的趋势：Spec 和代码的边界正在模糊。
未来的规格文档可能就是可执行的——它包含约束条件、接口定义、测试场景，AI 直接从中生成完整的实现。到那时，"写代码"和"写需求"将是同一件事，只是用人类最自然的语言来完成。
人类从汇编到低级语言再到高级语言再到 Spec Coding，从始至终都在做一件事：把 Code 往 Language 的方向发展，让编程语言越来越可读，最后干脆变成自然语言。
也许再过十年，我们会回头看今天的 Python 和 JavaScript，就像今天的程序员看汇编语言一样——"当年的人居然用这么难读的东西写程序？"
而 Spec Coding，就是这个漫长进化过程中的最新一站。
（本文基于 Claude Code、Cursor、AWS Kiro 等工具的工程实践，以及 Andrej Karpathy、Thoughtworks、RedMonk 等来源的公开信息整理而成。）