1 氛围编程可以安心的走远了
说实话从我第一眼看到氛围编程的说法时，就觉得他是个海市蜃楼，空有幻觉和口号。就好像有人提倡“人人都是产品经理”一样，喊喊口号还挺带劲的，现实中且不说有没人真就随便抓一个就来做产品经理的，就是精挑细选的产品经理，能把产品做好的也是寥寥可数。
氛围编程就跟人人都是产品经理一样，夸张的强调了门槛的低下，故意忽略了实际对能力，理论，技术，知识，阅历，洞见的高度要求。 上手容易，一实操一地鸡毛。 氛围编程在这一点上几乎做到了极致： 一句话立刻给你生成一堆代码文档，跑起来一看，还真是那么回事，不仅好看，功能也都像那么回事！ 即时爽感简直爆表。 当然等你真的仔细琢磨的时候，自然就会发现啥啥都不是那么回事了。
氛围编程最强大的就是他的即时满足感，不够他的优点也基本到此为止了。你要是坚持继续用氛围编程完成编码，就会见识到他的另一个强大的特性：极快的腐烂速度。 很快就会让你寸步难行，最终全部丢弃了。
为什么氛围编程只能起个头，干不了真正的事情呢？ 原因是他的几个致命的缺陷：
1.1 需求模糊，边界不清。
任何一个系统，比如包含了无数的逻辑、流程、约束、以及特定领域的定制化规则等等。所有这些都是必须严密的表达的。任何其中的稍微偏差，都可能导致系统的生产级别的缺陷。
这种情况下，指望氛围编程的口头描述来编码，甚至像宣传的那样，普通人都可以编程，岂不是沙上建塔，刀尖上跳舞？ 危如累卵不就是形容这种情况么？
1.2 上下文孤立
对于氛围编程方式产生的代码，最大的问题就是改了这里，坏了那里。说到东，忘了西。 其核心本质是对话过程限于当前几轮的对话，之前系统做的啥，怎么做的，全都不在上下文范围内，自然也就没法匹配，就跟人一样全忘了。 这就基本导致了系统越改越乱，急速腐烂。
当然，除了这俩最核心的问题外，其他的问题也很多，比如缺乏验证，质量不可控，文档缺失，没法协作，没有知识积累等等等等。由于核心问题足以判他死刑，其他就不一一列举了。
2 规格降临
既然氛围编程不可行，那自然就会有其他的解决方案冒出来。从最近时间各个大厂的实践经验来看，规格驱动开发越来越称为趋势。
2.1 github的spec-kit
一篇文章 规格即代码，需求即资产 详细的介绍了github的spec-kit在规格驱动开发上的尝试和解决方案。
GitHub spec-kit 作为规范驱动开发的入门级工具，其核心价值在于将自然语言需求转化为结构化文档（如 Markdown 格式的用户故事 1模板），帮助团队快速对齐需求边界。该工具以“轻量性”为显著特点，无需复杂配置即可通过插件集成到 GitHub workflow 中，特别适合个人开发者或小团队采用。
作为规范驱动开发的前置工具，spec-kit 专注于需求的初步梳理与结构化表达
2.2 OpenAI的model-spec
绝不Open的OpenAI根据他们的经验（通常更多的意味着教训）推出了 model-spec，而且在最近一次AI Engineer演讲中，OpenAI的Sean Grove更明确提出：提示词已死，我们正迎来新代码时代，而这份新代码，不是你我熟知的程序语言，而是规范。
Model-Spec构建了三层规范框架以实现AI行为的可预测性：目标层确立”造福人类”等宽泛原则，规则层设置”禁止生成有害内容”等刚性约束，默认行为层提供”假设用户意图善意”等权衡指导。
其核心创新在于指令链优先级 2机制，2025年9月更新后明确权限层级为”Root→System→Developer→User→Guideline”，Root级伦理红线（如人类安全至上原则）不可被任何下级指令覆盖，确保平台安全规则始终优先于开发者设置和用户输入。
2.3 Fission AI的 openspec
OpenSpec 是由 Fission AI 团队开源的一款 规范驱动开发工具。它的核心使命是管理和自动化 AI 应用（尤其是基于大语言模型的应用）的开发生命周期，其方法是通过一个单一的、权威的规范文件来定义整个应用的行为。
OpenSpec 的核心逻辑分为两部分，一是 specs，用于记录当前的规范状态，包括项目规则、API 约束、模块定义等；二是 changes，用于追踪每一次变更提案及其实施过程 3。
2.4 amazon 的 kio
相对于其他几家的尝试而言，amazon 的kio说实话是不声不响的做了件大事。就目前来看，我的观点，kio是将规范驱动编程落实到实际中的最好的实践。
kiro将规范驱动开发落地为可操作的工作流，其核心流程分为需求转化、设计生成、任务执行三个步骤：
需求转化：开发者输入自然语言需求，Kiro 会依据产品想法，自动将模糊需求分解为用户故事，并为每个用户故事生成采用 EARS 语法编写的验收标准 4，涵盖边界情况，确保意图被正确理解。之后生成需求分析文档，即 requirements.md，作为项目需求分析阶段的文档标准。
设计生成：Kiro 分析代码库和需求规格，自动生成设计文档，包括技术栈、架构图、时序图、接口和数据库结构等，形成 design.md 文件，减少开发过程中关于需求澄清的反复沟通。此过程需要人工对生成的系统设计进行确认。
任务执行：Kiro 基于需求和设计自动生成任务和子任务，依赖关系清晰，并与规格一一对应，每项任务都包含单元测试、集成测试等要素，生成 tasks.md 文件。用户可以逐个触发任务，查看进度与执行结果，还可以通过代码差异和日志来审计整个过程。
此外，Kiro 的 “代理钩子”（Agent Hooks）会在保存文件、提交代码等触发条件下运行自动化检查，比如更新测试文件、刷新 README 文件、扫描安全漏洞等。并且，Kiro 会将规范编写过程中生成的文件进行统一管理，确保开发过程的透明度和可追溯性。
3 规格驱动开发，未来可期
纵观各个大厂在规格驱动开发上的实践，不难看出，大家即各有各的思路和理解，又不约而同的朝向规格对齐。 我们来详细对比下：
- GitHub的Spec-kit
- 核心思路：以“宪法”（不可变高层原则）为记忆库，通过bash脚本+模板实例化文件/提示，按“宪法→指定→计划→任务”流程推进，用清单跟踪内容。
- 优点：可定制性强、支持多AI Coding Agent；流程自动化结构化，串联需求到校验全环节；模板降低误差传播；TDD融入流程，提前暴露风险。
- 缺点：生成的Markdown文件冗长且内容交叉，审查难度大；规范分支管理易导致长期维护跟踪困难，社区反馈设计逻辑混乱。
- 解决的问题：减少“意图走样”，让规格可执行并派生实现计划/测试；实现“文档生码”，避免文档失效；用规则和模板约束LLM，降低过度设计。
- 适合领域：大型项目开发与维护，对规范严谨性、可追溯性要求高的场景。
- OpenAI的Model-Spec
- 核心思路：以“目标（方向）+规则（防有害/保合法）+默认值（样式指导）”为框架，明确平台、开发者、用户的指令优先级，规范GPT模型行为。
- 优点：定制能力强，指令优先级清晰；设定安全边界，拒绝高风险请求；框架开源，支持自由使用、修改和二次构建。
- 缺点：仅侧重模型行为与伦理规范，对具体开发流程、代码生成的支持较弱。
- 解决的问题：确保AI模型行为符合伦理与用户意图，规避有害/不合法任务，为企业落地伦理AI提供标准框架。
- 适合领域：对AI模型伦理、行为规范要求高的场景，如金融、医疗等合规敏感领域。
- OpenSpec
- 核心思路：拆分“specs（记录规范状态）+changes（追踪变更提案与实施）”双核心，支持命令行+自然语言交互，衔接AI开发工具。
- 优点：轻量实用，适配个人开发者与小团队；规范语言和流程统一，人类与AI共识更清晰；兼容性强，可配合Codex、Cursor等工具使用。
- 缺点：对全新项目支持较弱，更适配已有项目的功能演进与维护。
- 解决的问题：明确AI编程需求，减少代码反复修改；记录技术决策，让设计选择可追溯；提供完整变更历史，助力团队协作与知识传递。
- 适合领域：已有项目的功能演进与维护，尤其需修改现有功能、触及多模块规范的场景。
- Kiro
- 核心思路：按“需求转化→设计生成→任务执行”三步流程，将自然语言需求拆分为用户故事+EARS验收标准，生成设计文档与关联规格的任务清单。
- 优点：轻量级设计，上手门槛低；集成于VSCode，使用便捷；流程结构化，确保需求清晰完整，减少沟通成本。
- 缺点：处理简单问题时流程繁琐，易将小需求过度拆分；多任务的规范锚定支持不够明确。
- 解决的问题：将模糊需求转化为具体用户故事、验收标准与开发文档；减少需求理解偏差，降低澄清沟通频率。
- 适合领域：小型项目或简单功能开发，对快速上手、轻量级流程有需求的场景。
从上面的对比，我们能得出什么结论呢。首先，大家都很自然的抛弃了氛围编程，不在提哪个空中楼阁了，而是务实的开始在规格上开始深挖。 其次，我们也能看出，大家还是在自己的领域上，基于自己企业业务的经验（以及教训），给出了基础解决方案。 还远没到能提供完整通用的解决方案的地步。当然这也意味着，在这个领域，将来还有大玩家出现的可能。
总结来说，大家是凭借着丰富的工作经验（和教训）在向规格对齐。 但是都脱不开 SRS 软件需求规格 5的范围。也都未能完全实现 SRS 软件需求规格的全部。
学习需求分析，掌握SRS的知识，不仅能更好的用好这些规格驱动开发的工具，还能更好的指导将来可能出现的规格驱动开发的工具。 在趋势没来之前，提前立于不败之地。