OpenSpec：AI 编码越来越强，为什么你反而更需要先写规格，再写代码？

这几年大家用 AI 编码工具越用越顺，Claude Code、Codex、Cursor、Copilot、OpenCode、Gemini CLI，一个接一个往工作流里钻。可越是这样，另一个老问题越明显：AI 会写，不代表团队就对齐了。真正把项目拖偏的，很多时候不是代码写不出来，而是需求散在聊天记录里，今天补一句，明天改一句，最后人和 AI 都点头了，落地却开始拧巴。

OpenSpec 这类工具之所以值得看，就是因为它没去硬卷“谁更会写代码”，而是把力气放在了更前面那一步：先把规格写清楚，再让代码去实现。说得直白点，它不是再造一个编码助手，而是在 AI 编码助手外面加了一层更稳的协作底座。先对齐意图，再动手，这个顺序听着朴素，但在 AI 时代，朴素反而成了稀缺货。

一、OpenSpec 到底解决的是什么事

OpenSpec 是 Fission AI 开源的一个 spec-driven development 框架，核心不是“帮你多写点代码”，而是把需求、设计、任务和变更这些东西，整理成能被审阅、能被追踪、也能被归档的结构化文件。它的思路很直接：当前系统怎么工作，放在 openspec/specs/；某次变更准备怎么改，放在 openspec/changes/<change>/；变更过程再拆成 proposal、specs、design、tasks 这些产物。做完之后，再把这次改动归档回主规格。

这套玩法的重点，不是把文档写得多漂亮，而是把“意图”从聊天框里拽出来，落回仓库里。因为一旦 AI 协作多起来，最容易丢的就是边界：这次到底改什么，哪些不改，为什么这么改，失败了怎么退回去。聊天记录能看一眼，真到交接、评审、回溯的时候，还是仓库里的结构化信息更靠谱。人脑记不住的，仓库至少能替你记一部分。

所以 OpenSpec 本质上不是一个编码工具，它更像是给 AI 编码流程补了一层“规格记忆”。这个记忆不负责替你下结论，只负责把结论从空气里落到文件里。别小看这一步，很多团队的返工，恰恰就卡在“大家当时都觉得自己懂了”这句废话上。

二、它最强的地方，不是写代码，而是对齐

OpenSpec 最值得琢磨的一句话，其实是：先对齐，再实现。乍一听像正确废话，真放到 AI 编码场景里，才知道这句话有多扎实。现在很多人的工作流都差不多：先在聊天里说需求，让 AI 给方案，一边追问一边补限制，差不多了就直接开改。这个流程不是不能用，但它太吃上下文了，也太吃“这轮对话没跑偏”了。只要中间某一句理解歪了，后面几轮会越来越顺嘴，最后顺到沟里去。

OpenSpec 想做的，是把这种临时对话，变成稳定流程。proposal.md 讲清楚为什么做、范围是什么；spec.md 讲清楚行为会怎么变；design.md 讨论技术方案；tasks.md 把实施拆成清单。这样评审时，先看的是这次变更的意图和行为变化，而不是上来就盯着 diff 找茬。对于个人开发者，这能少掉很多“AI 以为你懂”的坑；对于团队协作，这能少掉那种最恶心的返工——代码都写完了，才发现需求理解根本不在一个频道。

OpenSpec 官网那句“Review intent, not just code”，说白了就在提醒你：AI 编码越快，越不能把“为什么要改”丢掉。代码可以生成，意图不能假装已经对齐。

三、为什么它会吸引这么多人

OpenSpec 不是重量级规范平台，它吸引人的地方，恰恰在于自己够轻。它讲的是 fluid not rigid、iterative not waterfall、easy not complex、brownfield-first，翻成人话就是：别把团队重新拖回厚重的瀑布文档流程，也别把规格写成官样文章。它想要的是最小成本把边界固定下来，而不是再造一套吓人的流程。

这点对老项目尤其重要。现实里大多数工作根本不是从 0 到 1，而是从 1 改到 1.1、1.2、2.0。你要真每次都重写一整份规范，团队早就先被流程拍死了。OpenSpec 的 delta spec 思路挺聪明：主规格描述“系统现在怎么工作”，change 里的规格只描述“这次准备改什么”。这样你不用每次重写全量规范，只写变化部分，存量系统也能接得住。

还有一点更实际：它不绑某一个 AI 工具。Claude Code、Codex、Cursor、Copilot、OpenCode、Gemini CLI、Kiro、Pi、Windsurf，这些工具都能接。模型会换，IDE 会换，团队偏好也会换，但规格不该跟着失忆。这个判断很工程，也很现实。一个工具如果只能在自己那点小天地里转，迟早被换掉；能跨工具迁移的规划层，才有机会留下来。

四、它为什么最近更值得关注

如果只把 OpenSpec 看成一个会生成 proposal/specs/tasks 的脚手架，那确实有点小看它了。到 2026 年 3 月下旬，GitHub 页面已经到 32k stars，正式版也推进到 v1.2.0。版本里最值得注意的，不是某个炫技命令，而是几个很朴素、很工程的更新：可以用 profile 控制安装核心工作流还是自定义组合；propose 工作流更完整了，能一步生成 change proposal；还新增了对 Pi 和 Kiro 的支持；openspec init 还会自动检测项目里已有的 AI 工具目录，少了不少手工配置。

这些更新说明一件事：OpenSpec 已经不是“概念方向正确”的项目了，它在往更低摩擦的方向拧。因为规格驱动开发如果太重，团队是不会用的。这个道理很简单，谁都懂，但真能把“结构化”和“轻量”同时做好的工具不多。大多数流程工具最后都死在一个地方：想管得太多，结果谁都不想碰。

OpenSpec 现在聪明的地方就在这儿。它没有把自己包装成救世主，而是在认认真真地处理一个工程问题：让规格变得足够轻，轻到团队愿意用；让结构足够稳，稳到 AI 不容易把事情带偏。这个平衡感，比功能堆砌重要得多。

五、它和 AI 自带的 Plan 模式，到底差在哪

很多人第一次看 OpenSpec，都会顺手问一句：现在很多 AI 编码工具自己就有 plan mode、todo list、任务拆解能力了，那还需要 OpenSpec 吗？需要，而且差别不小。Plan 模式解决的是“这一轮对话里怎么推进”，OpenSpec 解决的是“这个项目长期怎么保留意图和上下文”。

Plan 很适合当前会话，临时、灵活、改起来快。OpenSpec 更适合需求会跨多轮会话不断迭代、团队需要多人评审、仓库里必须保留为什么这么做、老项目改动很多又必须区分当前行为和提议变更的场景。换句话说，Plan 像临时驾驶舱，OpenSpec 更像长期导航系统。前者帮你这一段路别开歪，后者帮你整趟路别迷路。

这也是为什么 OpenSpec 更像“规格驱动协作层”，而不是“AI 自带计划功能的替代品”。它不是来抢 plan mode 的活，而是把 plan mode 走不远的那部分补上。临时对话能跑，长期协作不能只靠记忆力和运气。

六、谁最适合现在就试

如果你已经高频使用 AI 编码助手，但经常返工；如果你做的是存量项目，不是全新 demo；如果你希望 PR 审查先讨论需求边界，再讨论代码细节；如果你在团队里推 AI 协作，希望流程可复制、可审计、可沉淀——那 OpenSpec 很值得试一次。

它上手其实不重，官方给的最短路径就是先装，再 init，然后开始用 /opsx:propose 这类工作流，把一次改动沉淀成 change folder。对很多团队来说，这可能就是从“AI 帮我写代码”走向“AI 参与团队工程协作”的第一步。别小看这一小步，它改变的是习惯，不只是工具。

真正有价值的，不是让 AI 更会写，而是让人和 AI 在动手前先把事说对。先写规格，不是多一道负担，而是给后面的代码少埋几个雷。

变更摘要（改了什么）

这版把原始内容的重点，从“OpenSpec 是什么”往“它为什么在 AI 编码时代更关键”上收了一层。结构上保留了原文的核心信息：OpenSpec 是什么、它解决什么、它和 plan mode 的区别、谁适合试，但表达上更偏公众号口语和工程复盘，少一点说明书味，多一点场景感。

同时把“规格驱动开发”这件事讲得更贴地了一点：不是文档崇拜，也不是流程回潮，而是把对齐从聊天记录里拉回仓库里。这样读起来会更像真人在讲取舍，不是只在复述产品官网。

风险点（哪里可能翻车）

这篇最大的风险，是很容易写成“流程正确但不够有劲”的文章。OpenSpec 本身比较工程、比较克制，如果语言再偏硬，就会显得像在念文档；如果往大里拔，又容易掉进概念腔。另一个风险是，工具名和版本信息很多，稍不注意就会把读者看晕，最后记住了一串名词，没记住核心判断。

回滚方案（怎么撤）

如果你觉得这版还是偏长，最稳的撤法是把后半段“谁适合试”和“它和 Plan 模式的区别”合并压缩，只保留“OpenSpec 解决对齐问题”的主线。这样文章会更像一个清晰判断，而不是功能介绍。

行动清单（读完怎么做）

如果你已经在高频用 AI 编码助手，先找一个返工最多的存量项目试 OpenSpec；先别追求全量替换，先试一条变更链路，把 proposal/spec/design/tasks 跑通；再看 PR 审查能不能先看规格、后看代码，能不能把需求边界提前钉死。能跑通这一小段，才算真的开始用，不然就只是多了几份文件。

封面3要点

AI 越强，越要先写规格
OpenSpec 先解决对齐问题
规格驱动比聊天更稳

爆款标题备选（任选其一）

AI 编码越来越强，你反而更需要先写规格
OpenSpec 火起来，不是因为它会写代码
先对齐，再写代码：OpenSpec 为什么值得看
AI 会写代码了，为什么团队更怕“没对齐”
OpenSpec 不是编码工具，是协作底座
真正值钱的，不是更快写代码，而是先写对规格
Plan 模式之外，OpenSpec 解决的是长期对齐
AI 编码时代，规格比代码更先重要