2025年2月2日，Andrej Karpathy在X平台发表了关于AI编程领域的重要观点，首次系统性地提出了”Vibe Coding”（氛围编程）这一概念。
这一概念迅速引发了业界关注。其吸引力在于让开发者能够以类似”产品经理向研发团队传达需求并快速获得产品原型”的交互方式进行编程，大幅提升了原型开发的效率。Andrej在原文中阐述了该理念的三个核心特征：
- 直觉驱动与即时反馈：充分依赖直觉感知（Fully give in to the VIBES），显著降低开发门槛，使非专业开发者也能构建出功能完整的产品原型
- 自然语言交互：采用自然语言作为统一的交互界面，打破了传统编程语言的壁垒，实现了人机协作的范式转变
- 接纳代码冗余：在快速原型开发场景下，允许代码存在一定的冗余和非最优结构（Not too bad for throwaway weekend projects），优先保证交付速度而非代码质量，特别适用于概念验证和短期项目
在开发社区中广泛兴起的”Vibe Coding”理念与实践的推动下，一批主打Vibe Coding的初创企业迅速涌现。其中，Base44 的发展轨迹尤为引人注目：该公司自成立至被收购仅历时六个月，最终以8000万美元的价格成交，充分体现了资本对这一趋势追捧的新高峰。
然而，随之而来的问题也逐渐显现——以自然语言为基础的直觉交互模式，本质上难以实现对开发需求的精确描述，因而对长期项目的稳定性、团队协作效率以及代码的可维护性造成了灾难性的打击。如今甚至出现专门致力于修复Vibe Coding遗留问题的公司，例如 Ulam Labs，已开始进入公众视野。
2025年Q2末期到Q3，一种名为”规格驱动编程”（Spec Coding，或Spec Driven Coding）的新兴理念逐渐在社区中受到关注。尽管目前难以追溯其确切起源，但这一概念在AI编程领域所发挥的重要作用已日益凸显。它不仅有效缓解了此前Vibe Coding所遗留的工程管理问题，更进一步推动了AI辅助编程范式的演进与重构。
Spec Coding是指以形式化的软件规格说明（Specification）为核心输入，借助AI编程技术将其转化为可执行代码的过程。其核心基础源于软件工程中的”规格”（Spec）概念——即对系统、模块、接口或组件”应实现什么功能”以及”在何种约束条件下运行”的精确描述。
在实际应用中，规格并不总是以模糊的需求文档呈现，而可能采用结构化或半形式化的表达方式，例如JSON Schema。在DevOps的主流理念中，“Spec-as-Code”可视为一种极端实践；而在本文所讨论的AI Coding语境中，符合规格实践原则的自然语言描述（如软件需求规格说明书，SRS，Software Requirements Specification）同样被视为良好实践。
需要强调的是，规格本身并不关注”如何实现代码”，而仅聚焦于”应完成什么”以及”需满足何种条件”，本质上承担着沟通契约的角色。笔者将这种现代软件评价体系概括为”自验证软件系统”（Self-verifying Software System），以突显其内在的闭环验证结构。
2025年8月27日，GitHub官方正式发布Spec Kit项目，该项目旨在通过规格驱动开发（Spec-Driven Development，SDD）协助企业提升AI辅助编程的质量与效率。该工具能够将自然语言描述的需求转化为结构化规格文档，并基于Claude、GPT、Gemini或Copilot等AI编程助手自动生成可执行代码。项目自发布当日GitHub Star迅速增长，并获得开发者社区的广泛关注与认可。
从以上的讨论不难看出，从过往优秀的软件工程实践过渡到AI Coding时代的Spec Coding已经出现了部分非共识，借由Spec Kit项目进行总结：
- 代码资产的重新审视
- 测试驱动开发的重要性提升
- 对于”抽象”级别的重新思考
我们来逐一进行讨论。
反常识1：代码资产不再成为核心壁垒
这一现象挑战了互联网时代数十年来的基本认知——代码是组织的核心资产。长期以来，开发者构建了完整的工具链（如Git版本控制、软件工程规范流程等）来保护和管理代码资产。一个高度复杂的业务系统通常包含数十万行代码，这些代码积累本身便构成了互联网时代企业的重要竞争壁垒。
然而AI编程能力的快速提升正在改变这一格局。尽管截至本文撰写（2025年10月12日）尚缺乏严谨的实证研究来量化纯AI生成项目的代码规模与AI能力增长之间的关系，但从开发者社区的实践反馈来看，Claude Code和CodeX等先进的AI编程代理（AI Coding Agent）已经能够在经验丰富的程序员协作下高效完成中等规模的项目开发。
一些实证研究已经展现出这种趋势的端倪。在针对157个开源项目的567个PR请求的研究中，超过半数由Agent生成的PR获得了83.8%的接受率。Agent生成的代码量同样达到了可观的规模，尽管目前仍存在代码冗余和引入不必要变更等问题。
可以预见，AI编程对软件工程行业的变革将类似于纺织机对传统纺织业的颠覆性冲击。在这个新范式下，我们需要将注意力从代码实现本身转向更精确的需求规格说明的维护。当规格说明足够精确时，代码生成的时间成本将逐渐降低，手写编写和维护代码反而会成为低效的选择。
终有一天，数十万行的业务代码将不再是系统复杂度壁垒。取而代之的将是由Agent和人类协同构建的、规模更加庞大、复杂度更高的超大型系统。
反常识2：测试驱动开发的重要性提升
在SDD的constitution.md（一系列指导Agent Coding的规范化文件）中，测试驱动开发（Test-Driven Development，TDD）原则被提升至NON-NEGOTIABLE级别。尽管在实际开发中，并非所有代码都能严格遵循”测试驱动”的范式，但这一原则在多数场景下都展现出显著的有效性。其核心价值在于：当代码生成成本大幅降低时，测试单元作为可验证的执行环境，能够为代码求解过程提供类似强化学习系统中的奖励信号。
测试即规格的可执行表达！（Tests are Executable Specifications）这一理念在某种程度上借助AI的能力，实现了传统软件工程中测试驱动开发(TDD)与行为驱动开发(BDD)的概念融合。通过AI辅助生成测试代码，测试本身的创建过程同样可以基于对测试规格的形式化描述来完成。在这一框架下，测试演变为连接自然语言规格与计算机实际行为的关键对齐机制，从而在AI辅助开发的新范式中发挥着更为基础和核心的作用。
反常识3：“过度工程化”的重新定义
在传统软件工程中，我们通常通过”抽象”来实现功能的分层与解耦。“过度工程化”往往表现为过度添加抽象层。而在AI Coding场景下，这一概念呈现出两个新的维度：
- LLM在生成代码时，由于其训练数据中包含大量工程模式和”最佳实践”，容易倾向于过度抽象，将企业级架构模式不加区分地应用于简单场景
- 在Spec Coding范式中，规格说明已经明确界定了功能边界，此时抽象行为的价值发生了根本性转变——代码的主要维护者从人类变为AI。这要求我们重新审视抽象的必要性和粒度
在Spec Kit中采用复杂度举证来约束Agent的过度抽象。
我们暂不对该方案的长期有效性下定论，因为随着技术演进，可能会出现更优的解决方案。事实上，从Claude Sonnet 4.5发布后的表现来看，Claude Code在过度编码方面已有明显改善。
不过，笔者认为抽象层级的问题仍值得深入探讨。在Spec Coding中，当AI成为代码的主要消费者时，抽象的目标应当转向业务领域的概念边界而非传统的技术实现边界。具体而言，抽象粒度应与业务概念的自然边界相对齐，同时兼顾规格本身的可组合性和可验证性。
限于篇幅和个人能力，本文无法充分展开关于自然语言层面的规格抽象规范的实践讨论。这一话题涉及诸多细节和权衡，笔者希望未来有机会与各位读者进一步交流探讨。
站在2025年Q4，回望Spec Coding的演进轨迹，我们见证的不仅是编程范式的变革，更是一次深刻的行业重构。正如计算机技术曾重塑各行各业的生产方式，对编码行为本身的革命，正在成为赋能千行百业的全新支点。
这一理念的价值远超本账号聚焦的AIDD领域本身，它实质上回应了AI时代最核心的工程命题：如何AI+的时代中用AI重做一遍行业。软件工程师的职能边界也随之重构：从逐行编写实现的执行者，转变为业务逻辑的精确表达者，从技术的实践者，升华为领域知识的架构师。
Spec Coding让我们得以将数十年积累的工程智慧，从实现细节中解放出来，重新聚焦于业务本质的抽象与建模。
祝愿每一位在这场变革中前行的探索者！