最近用 Claude Code 写代码，遇到了一个让人头疼的问题：前 20 分钟生成了 2 万行代码，接下来两个星期都在调试。

相信很多人都有类似的经历——一开始特别兴奋，让 AI 生成了完整的应用，结果在修改的时候陷入死循环。改这里，那里就坏了；越修越乱，最后只能推倒重来。

直到我发现了 OpenSpec，这个问题才算有了解决方案。

问题的根源

回想一下，为什么会陷入修改地狱？

其实很简单：AI 不知道你的整体规划。每次对话都是独立的，它只能根据当前的上下文来修改代码。今天改个登录功能，明天加个权限系统，AI 根本不知道这些功能之间的关系。代码越写越多，结构越来越乱。

OpenSpec 的思路是：先写规范，再写代码。

在 Claude Code 中配置 OpenSpec

OpenSpec 直接支持 Claude Code，配置很简单。

在项目根目录运行：

openspec init

系统会询问你使用的 IDE，选择 Claude Code 就行。

初始化完成后，你会看到项目里多了个 openspec/ 文件夹，里面有个 AGENTS.md 文件。这个文件告诉 AI 该怎么工作，Claude Code 会自动读取它。

工作流：#proposal 和 #apply

OpenSpec 的核心是两个命令的循环使用。

第一步：#proposal 创建规范

在 Claude Code 的聊天框里输入 /openspec proposal，然后描述你要做的功能。

AI 会在 openspec/changes/功能名/ 下生成三个文件：

• proposal.md - 功能目标和需求
• tasks.md - 具体任务清单
• design.md - 技术设计方案

这时候别急着写代码，先看看这些文件。需求理解对了吗？任务拆分合理吗？设计方案有没有坑？

不对的地方直接改，或者重新 /openspec proposal。这一步多花点时间，后面能省很多事。

第二步：#apply 开始实现

规范确认没问题了，输入 /openspec apply。

AI 会严格按照 tasks.md 里的清单，一项一项地写代码。不再是凭感觉发挥，而是对照着任务列表干活。

你可以随时检查进度。发现偏离了规范，别让它继续改，重新 #proposal 调整任务清单就行。

第三步：#archive 归档

功能开发完，测试通过了，用 /openspec archive 命令把这次变更归档。

这个变更就会从 changes/ 移到 specs/，成为项目的永久文档。下次开发新功能，AI 会参考这些历史规范，知道项目是怎么演进的。

两个文件夹的设计

OpenSpec 用两个文件夹管理状态：

• specs/ - 已完成的规范，代表线上的真实状态
• changes/ - 开发中的提议，代表计划中的变更

这个设计很巧妙。修改已有功能时，新旧代码不会混在一起，每个变更都在独立的文件夹里，方便追踪和审查。

我的实战经验

用了一段时间 OpenSpec + Claude Code，总结几个技巧：

小步快跑：一个 /proposal 只做一个功能模块。完成了立即 /archive，再开始下一个。别贪心一次做太多，容易失控。

及时检查：发现 Claude Code 偏离规范了，别让它继续改。停下来，重新 /proposal 调整任务清单。

保留记录：changes/ 文件夹里的文档就是你和 AI 的"合同"。出问题的时候回看规范，能快速定位原因。

从"氛围编程"到工程化

用 OpenSpec 之前，我和 Claude Code 的协作更像是"氛围编程"——聊着聊着代码就出来了，但不知道为什么这么写，也不知道改了会影响什么。

用了 OpenSpec 之后，整个流程变得可控：

• 通过 #proposal 定义清晰的规范
• 用 #apply 监督 AI 按规范实施
• 靠 #archive 积累项目知识库

你不再是救火队员，而是架构师。

试试看

如果你也在用 Claude Code，不妨试试 OpenSpec。

在项目里跑一下 openspec init，然后用 #proposal 和 #apply 循环工作。你会发现，AI 编程可以变得更加可控和可靠。