如何让AI先按OpenSpec规格，再写 Claude Code？

这两年，AI 编码工具越来越像一个“高产、聪明、执行力很强，但偶尔也会自作主张的新同事”。 你让它写个功能，它往往真能写出来； 但写出来的东西是不是你真正要的、边界是不是清楚、设计是不是一致、后续是不是好维护，就不一定了。 很多团队已经感受到一种很现实的落差： 不是 AI 不会写代码， 而是 AI 太容易在需求还没对齐时，就把代码写得飞起。 于是，问题开始从“怎么让 AI 写得更快”，转向“怎么让 AI 写得更准、更稳、更可追溯”。 这正是 OpenSpec 的价值所在。 它不是再造一个 AI，也不是替代 Claude Code。更准确地说，OpenSpec 是一套面向 AI 编码助手的规范驱动开发工作流；Claude Code 则是把这套工作流真正执行起来的强执行代理。 一个更像“方向盘”，一个更像“发动机”。 放在一起用，目标不是让 AI 写更多代码，而是让 AI 少写那些方向看似对、其实需求没对齐的代码。 先给结论： 如果你只是想让 AI 帮你“写一段代码”，OpenSpec 可能显得有点正式； 但如果你已经开始用 Claude Code 做真实项目、改现有代码库、推进多人协作任务，那 OpenSpec 往往不是“锦上添花”，而是“避免反复返工”的那层护栏。 这篇文章适合谁看 这篇文章尤其适合下面几类人： 已经在用 Claude Code、Cursor、Windsurf 之类 AI 编码工具的人； 经常做真实项目改造，而不是只写 demo 的开发者； 想把“聊天式开发”升级成“有留痕、有规范、有归档”的团队负责人； 看过一些 OpenSpec 教程，但被旧命令、旧流程、旧截图绕晕过的人。 读完你能得到什么 这篇文章会尽量回答 5 个最现实的问题： OpenSpec 到底解决什么问题？ 它和 Claude Code 为什么适合一起用？ OpenSpec 1.2.0 之后，命令和工作流到底怎么理解？ 不同场景下，应该怎么走 propose / explore / apply / archive？ 团队如果想低成本落地，最小实践方案该怎么搭？ 你不需要先接受一整套“新方法论”，再决定要不要用它。 更实际的方式是：先把文章读完，看看它能不能帮你解决下面这些老问题—— AI 总是抢跑，需求还没对齐就开始写代码； 功能确实做出来了，但设计决策留不下来； 聊天里讲过的约束，过几天就没人记得； 一旦多人并行或者跨会话继续，整个上下文就开始漂移。 如果这些问题你都遇到过，那 OpenSpec 大概率值得认真看一遍。 一、先说人话：OpenSpec 到底是什么 一句话解释： OpenSpec 是一套把“需求、规格、设计、任务、实现、归档”串起来的 AI 协作工作流。 它强调的不是“想到什么就直接让 AI 开始改”，而是： 先把这次变更说清楚； 再把系统行为和边界写清楚； 必要时把技术方案定清楚； 再把任务拆成可执行清单； 最后才让 AI 进入实施阶段。 这套思路，本质上就是 Spec-Driven Development（规范驱动开发） 在 AI 编程时代的落地版本。 OpenSpec 的核心价值，不是多几个命令，而是把原本散落在聊天记录里的“共识”，沉淀成项目里的正式工件。这样一来，AI 的上下文不再只依赖会话记忆，而是开始依赖项目内可追踪、可审查、可归档的事实。 换句话说： 没有 OpenSpec 时，很多需求只存在于聊天里； 有了 OpenSpec 后，需求、设计和任务会变成项目内的正式资产。 这件事对个人开发者有帮助，对团队协作更重要。 因为团队最怕的不是 AI 写得慢，而是： 每个人都在用 AI，但每个人理解的范围不一样； 每个人都在提效，但结果不可复盘、不可审计、不可继承； 过几天回头看，只记得“改过”，却说不清“为什么这么改”。 OpenSpec 的意义，就是尽量把这种“聊天式开发”升级为“带工件留痕的工程式开发”。 二、为什么它和 Claude Code 很搭 Claude Code 的强项很明显： 能读取真实代码库上下文； 能连续执行多步任务； 能跑命令、查文件、改代码、补测试； 对真实工程改造比只会“补全一段代码”的工具更有行动力。 但工具越强，越需要约束。 因为越能干的代理式工具，越容易在下面这些场景里“用力过猛”： 需求边界没说清，就开始大范围改动； 设计方案还没定，已经先把实现铺开； 聊天里说过的关键限制，没有被固化进项目； 多任务切换后，前一次变更的上下文被新的目标冲掉； 最终代码能跑，但没人说得清“为什么这么实现”。 Claude Code 负责把事推进下去，OpenSpec 负责把事定义清楚。