用 Claude Code、Codex 写过正经项目的人，大概率都经历过这种崩溃：需求全散在聊天记录里，AI 换个会话就开始“失忆”；改完代码后系统该怎么跑，没人能说清；下一个会话又凭着过时记忆接着写，同样的坑反复踩。知乎专栏知乎
最近知乎上就冒出一个热问：规范驱动开发会不会是 AI 编程的未来。B站上关于它的实战视频也一波接一波。这个让 AI“先写规范、再写代码”的 OpenSpec，到底值不值得跟？知乎
OpenSpec 是什么
先说清楚：OpenSpec 不是替代 Claude Code、Cursor、Codex，而是一个轻量的规范管理框架，给它们加上一套“先想清楚、再动手”的流程。知乎
核心思路很简单：每次改动前，先把需求变成一组 Markdown 文件——
proposal：为什么改、影响范围有多大；
specs：改完后系统应该怎么表现，带验收场景（WHEN/THEN）；
design：技术上怎么实现；
tasks：拆成可逐项勾选的任务清单。
流程是 init → new change → 写四件套 → validate 校验 → apply 实现 → archive 归档回写规格。规格最终沉淀为系统的“长期事实之源”，下次再改就基于它写增量，AI 不再靠聊天记录里的记忆干活。知乎专栏
最关键的设计是规划与实现分离：AI 写完提案会先停下，等人确认“你理解的需求对不对”，才允许动代码。先审理解、再审设计、最后才审代码，而不是等它改完几十个文件后发现方向错了。知乎专栏知乎
为什么火
背景是“规范驱动开发”（SDD）这波浪潮整体升温。GitHub 上的开源工具包 spec-kit 挂着约 13 万星、38 个编程 Agent 集成（仓库自报数字），AWS 的 Kiro 也在用同一套思路。逻辑不复杂：AI 写代码越来越快，一个 Agent 短时间就能改几十个文件——一旦理解错需求，错误扩散得比人写快得多。速度把瓶颈从“写”挪到了“说清楚”。知乎专栏知乎
而 OpenSpec 相比重流程的 spec-kit，卖点是轻：不是每个变更都要产出全套文档，更适合已有项目的持续迭代。
三盆冷水，跟之前先喝
第一，费 Token、费时间，甚至有人直接发问：多花 3 倍 Token，代码真的更好吗。有开发者的实践是按改动分量分派：核心链路的逻辑走完整的测试驱动流程，“页面加个字段”这种小改动走简化流程，甚至直接改。哔哩哔哩知乎专栏
第二，审文档未必比审代码轻松。martinfowler.com 上一篇横评点破：SDD 的卖点常是“你审 markdown，别审代码”，但实际是从审一个 diff，变成审需求、设计、任务三份文档，还要保证它们互不打架。知乎专栏
第三，规范不能替代测试。AI 完全可能实现了错误的逻辑，再写出一套跟错误逻辑自洽的测试。规范定义预期，测试检查实际，谁也替代不了谁。知乎
还有一盆更釜底抽薪的冷水：按那篇横评的实测，市面上自称 SDD 的工具基本都停在“规范先行、用完就删”这一层，真正做到规范与代码持续同步的，还没有。知乎专栏
我的建议
个人写小工具，可以不装任何东西——先给复杂任务写一段“需求+验收标准”再丢给 AI，就已经吃到 SDD 的大部分好处；长期迭代的项目和团队协作，则不妨试试 OpenSpec 这类工具，把规范、代码和测试逐步整合起来。但小改动别硬套流程。知乎
AI 编程的竞争，从来不是谁一次生成最多代码，而是谁能让 AI 持续、可靠地做对事。规范只是这条链路上的一环——重要，但不是万能药。
