IT资源栈
什么改变了我的想法？ 以前我认为”规格说明书”这种东西是给大团队、正式项目用的，个人用 AI 写代码根本不需要这套流程。看完这个视频我意识到，恰恰因为 AI 写代码时的”自行补全”倾向太强，你反而更需要一个清晰的规格来约束它，否则它在每个模糊点上替你做决定，最后出来的东西跟你想的差很远。
如果只记住一件事： OpenSpec 的核心价值在于它把”你到底要什么”和”AI 去实现它”拆成了两个清晰的阶段，并且用文件系统持续维护这份规格，让项目的文档永远不会和实际代码脱节。
推荐给谁： 已经在用 Claude Code 或类似 AI 编码工具、但反复被”AI 自作主张”坑到的人。尤其是当你有一个已经有一定规模的个人项目，想用 AI 做大规模 UI 重构时。
AI 总会在你没预料到的地方替你做决定
用 AI 编码工具写过一段时间的人大概都有这种体验：你说了一句话，AI 理解成了另一件事；你觉得”它应该知道我的意思”，结果它按照自己的理解走了一条完全不同的路。
问题出在哪？你脑子里有一个模糊的画面——”我想要一个好看的个人主页”——但这个画面里有多少细节是清晰的？布局、配色、间距、交互逻辑、数据结构……大多数时候，你自己都没想清楚。AI 没想清楚也不告诉你，直接动手了。
这就是视频里博主要解决的问题：他已经用 AI 搭出了一个食谱应用的 V1 版本，功能都在，但 UI 简陋到他自己都不想用。他找设计师在 Claude Design 里做了完整的视觉稿，现在需要把这些设计稿翻译成实际的代码。这是一个典型的”从能用到好看”的升级，也是 AI 编码最容易翻车的场景——因为审美判断是最模糊的东西。
市面上这些 AI 编码工具，到底有什么区别？
视频里把市面上的 AI 编码辅助工具粗略分成了三类：
规格驱动型。 以 OpenSpec 和 GitHub Spec Kit 为代表。核心逻辑是你先花时间把”要做什么”写得足够清楚，形成一份规格文档，然后 AI 照着这份文档干活。人在主导，AI 在辅助。
流程纪律型。 代表是 Obra、AgentSkills。这类工具的重点在于强制你遵循好的工程实践——测试驱动开发、红绿重构之类的。不管你用 AI 还是手动，流程本身才是价值。
自主管道型。 代表是 B Mad、GetDone。你定义好目标，然后真的可以走开喝杯咖啡，回来发现 AI 已经帮你搭完了。干预很少，自动化程度很高。
博主认为 OpenSpec 属于第一类，而且这类工具对”vibe coder”（随性写代码的人）或 AI 编码新手尤其友好。因为规格驱动逼你在动手之前把事情想清楚，这本身就是一种训练。
OpenSpec 实际用起来是什么感觉
安装很简单，一行 npm 命令，然后进入项目目录运行 openspec，选环境，就绪。
完整流程有四个阶段：explore → propose → validate → apply。
explore：把模糊点翻出来
第一步是 explore。你可以让它帮你分析当前代码库和你的需求之间的差距、找出潜在问题、列出需要澄清的模糊点。
这步的价值很多人会低估。博主举了个很实际的例子：他要做的是一个完整的 UI 设计系统迁移——从 Claude Design 里搞出来的设计稿要替换掉项目里现有的设计 token、组件结构、路由架构。如果直接让 AI 开干，AI 会在每个”新的设计系统用哪套间距”这类问题上自己拍脑袋决定，结果就是一锅粥。
explore 阶段把这些模糊点全翻出来了：设计 token 怎么迁移？项目结构要怎么改？文档要不要同步更新？你一个个确认之后，后面才不会有惊喜。
我觉得这步的设计很聪明。你可以在任何环节调用 explore，不一定要在开始的时候。写着写着发现某个地方拿不准，随时可以停下来探讨。比 Spec Kit 那种”上来就要写规格”的方式灵活不少。
propose：三份文档把事情交代清楚
explore 完之后，运行 propose，你会得到三样东西：
- proposal.md —— 具体要改什么、为什么要改
- design.md —— 高层技术方案，架构决策
- tasks.md —— 分阶段的实施步骤
举个例子。博主的 proposal 里清楚列出了：设计系统迁移、新页面构建、组件库搭建、保持现有后端逻辑不变。每个变更都有明确的边界——哪些动、哪些不动，一目了然。
design.md 讲的是怎么迁移设计 token、怎么组织新组件、路由架构怎么改。tasks.md 把所有东西拆成了可执行的任务列表。
这个三件套的好处是：假设和决策全部落在纸面上。你不用猜 AI 为什么要这么做，因为 proposal 里写了。你不用担心任务有没有遗漏，因为 tasks.md 里列了。后续 review 也容易——对着文档看结果就行。
validate：验证做得够不够
这步有点意思。OpenSpec 有一个 validate 命令，你可以让它在正式开干之前先验证规格的完整性。博主结合了 Chrome 浏览器扩展 MCP，让 AI 在规格中加了”视觉验证”步骤——用浏览器实际打开页面，对照设计稿检查。
绝大多数 AI 编码工具只做功能验证：跑测试、检查接口。视觉验证这个需求很现实但很少被原生支持，因为”好不好看”本身很难形式化。OpenSpec 的做法是让你在规格里显式定义验证条件，然后它照着检查。不够完美，但比没有强太多。
apply：两小时跑完一个大规模重构
最后一步就是 apply，告诉它项目标识符，然后让它跑。博主的案例跑了大约两小时（开着自动模式），包含代码实现和浏览器视觉验证。
结果如何？发现的页面大致还原了设计稿——hero 区、筛选器、编辑推荐流这些关键元素都在。个人主页也基本到位。有些间距和细节对得不准，但作为一个大规模设计系统迁移的首版，博主相当满意。
他的判断是：OpenSpec 之所以能做得这么接近设计稿，正是因为前面几步把需求拆得足够细、验证条件写得足够具体。AI 的”自行补全”能力被约束在了正确的方向上。
改完之后：archive 和 sync
代码改完，OpenSpec 还有两步收尾工作。
archive 把当前这次变更的所有规格、任务、设计决策保存到一个历史目录里。你可以随时回去翻——当初改了这个东西，方案是什么，为什么这么选。项目越大，这个回顾能力越值钱。
sync 把变更中涉及的功能规格同步回主规格文件。比如你改了公开个人资料的 API，sync 会把新的数据模型要求和接口规格更新到”公开个人资料”的主规格里。
这意味着你的项目文档永远不会和代码脱节。每次改动都会自动回流更新规格。大多数工具都不管这事——你改了代码，文档还是旧的，三周后你自己都忘了当初为什么这么设计。
new 和 continue：分步迭代的后端迁移
视频后半部分介绍了 OpenSpec 新增的工作流。
博主做完前端重构后，需要补后端——API 路由、数据模型等等。他没有再走一遍完整的 explore → propose → validate → apply 流程，而是用了 new 命令启动一个新的规划上下文，然后用 continue 命令逐步推进。
new 创建一个新的变更框架。continue 让你一步步往下走：起草 proposal → 生成 specs → 创建 tasks → apply。中间你随时可以停下来用 explore 深入某个问题，或者用 fast-forward 跳过剩余阶段让它自动完成。
博主把后端工作拆成了多个 slice——每个 API 模块一个独立的变更。每个 slice 都有自己的 proposal、specs 和 tasks。虽然花更多时间，但质量更有保障。这种”小步提交、每步验证”的方式在涉及后端逻辑时特别重要，因为一个错误的数据库 schema 可能影响面很广。
我的几点判断
看完整个演示，我有几个判断：
规格驱动开发这个思路并不新鲜。传统软件工程里，写需求文档、技术方案、实施计划是标准流程。OpenSpec 做的事情是把这套流程变得足够轻量，让个人开发者和 AI 编码场景也能用。
它解决的核心痛点是 AI 编码中的”模糊决策问题”。当你的需求描述不够精确时，AI 会用自己的判断填补空白，而你往往不同意它的判断。OpenSpec 用”先对齐再动手”的方式大幅减少了这种摩擦。
文档自动同步这个功能可能是被低估的亮点。大多数 AI 编码工具只管帮你写代码，不管帮你维护文档。但长期来看，项目文档的准确性直接影响后续所有 AI 编码的质量——AI 读到的上下文越准确，输出的结果越好。这形成了一个正循环。
不过也要说，OpenSpec 的学习成本比直接上手 Claude Code 高不少。如果你只是在写小脚本、单页面应用，规格驱动可能显得过度。它的甜点区是有一定规模、多个功能模块、需要持续迭代的项目。
还有一个值得注意的点：博主在用 OpenSpec 的同时还在调用 Obra 的 work tree skill 做测试。不同工具各有所长，组合使用比单打独斗效果好。OpenSpec 管规划和规格，Obra 管工程纪律，各司其职。
一句话说完
OpenSpec 的核心主张简单说就一句话：在你让 AI 写代码之前，先把你要的东西写清楚，写成一个活的、会随代码同步更新的规格文档。
这个主张在”AI 编码”这个语境下特别有价值，因为 AI 的补全能力越强，你越需要一个明确的方向来约束它。否则你就是在用最强大的引擎开一辆没有方向盘的车。
它未必适合所有场景，但如果你正在用 AI 做一个有一定复杂度的项目，并且对”AI 自作主张”这件事感到困扰，OpenSpec 值得认真试一试。
评论前必须登录！
立即登录 注册