告别盲写与失控：用 OpenSpec 拯救你的 Vibe Coding 工作流

如果你在过去几个月里尝试过 Cursor、Windsurf 或是 Claude Code，你一定体验过 Vibe Coding 的魔力：在聊天框里随口提个需求，“帮我加个深色模式”或者“写个贪吃蛇”，AI 就会像变魔术一样把代码刷刷地写出来。

对于单文件脚本或早期的 Demo 来说，这种心流体验简直令人沉醉。但当你试图用这种方式去维护一个真实的、拥有数十个组件和复杂业务逻辑的商业项目时，现实往往会给你泼一盆冷水。

---

一、 Vibe Coding 正在摧毁你的复杂项目

当项目从从零开始进入维护与迭代已有代码库阶段时，纯粹的 Vibe Coding 会暴露出致命的缺陷：

1. 回归错误：AI 像是一个极其聪明但缺乏大局观的实习生。你让它修改 A 模块的逻辑，它为了图方便，可能会悄悄改掉底层的通用函数，直接导致 B 模块和 C 模块彻底崩溃。
2. 上下文遗忘（Context Loss） ：大模型的记忆是有限的。当你和 AI 针对一个复杂功能来回对话了十几轮后，它可能已经忘了第一轮定下的核心数据结构，开始胡言乱语或输出自相矛盾的代码。
3. 意图偏移与“代码屎山” ：没有设计文档，没有架构规划。遇到报错就让 AI 去修，修出新 Bug 继续修。几次迭代下来，代码逻辑就会变得极度扭曲，成为一坨屎山。

Vibe Coding 的极限，就是人类大脑能短时间内掌控的上下文极限。要想突破这个瓶颈，我们需要引入规范驱动开发（Spec-Driven Development, SDD） 。

---

二、 OpenSpec 解决了什么问题？

OpenSpec 的核心理念非常简单粗暴：在写任何一行真实代码之前，先让人类和 AI 针对计划达成共识。

它完美解决了上述的失控问题，主要体现在两个机制上：

• 变更隔离（Change Isolation） ：当你提出新需求时，OpenSpec 会在项目里创建一个独立的沙箱目录（如 .openspec/changes/add-payment）。这就像是给代码动手术前建了一个“无菌手术室”，确保 AI 的思考过程不会污染主工作区。
• 强制规划（Forced Planning） ：它剥夺了 AI “直接改代码”的权力。AI 必须先输出业务提案（Proposal）和任务清单（Tasks）。只有当人类作为“技术总监”审查通过后，AI 才能按照清单一步步实施。这让每一次修改都可审计、可追溯。

---

三、 OpenSpec 的两个核心工作流：Core Workflow 与 Expanded Workflow

OpenSpec 提供了两套工作流，让你根据任务的影响范围灵活切换。

1. 典型流程（Core Workflow）：极速微调

核心理念：轻量、快速、单刀直入、阅后即焚。

适用场景：修复简单的 UI 错位、调整文案、添加一个独立的工具函数等低风险操作。

操作步骤：

1. /opsx:propose <需求> ：提出你的意图（例如修复按钮遮挡）。AI 会极速扫描上下文，生成一个简短的 proposal.md。
2. /opsx:apply：你扫一眼提案，觉得没问题，下达实施指令，AI 瞬间完成代码修改。
3. /opsx:archive：本地测试代码无误后归档。AI 会清理掉临时的提案文件，代码库干干净净，就像你亲手改的一样。

2. 扩展流程（Expanded Workflow）：系统级重构

核心理念：严谨规划、步步为营、强制验证。

适用场景：接入第三方单点登录（SSO）、重构底层数据库、开发复杂的电商结算模块等牵一发而动全身的高风险任务。

操作步骤：

1. /opsx:new <变更名称> ：建立隔离区，防止 AI 乱跑。

2. 规划与拆解（ /opsx:continue 或 /opsx:ff ） ：

   1. 如果你思路清晰，使用 /opsx:ff (Fast-Forward) 一键让 AI 生成所有设计图纸和任务清单（tasks.md）。
   2. 如果业务极度复杂，使用 /opsx:continue。让 AI 先写业务提案，你确认；再写架构设计，你确认；最后写任务清单。这叫“挤牙膏式”审核。

3. /opsx:apply：AI 此时不再盲写，而是严格按照 tasks.md 的步骤，一步步修改真实代码。

4. 应对突发状况（ /opsx:sync ） ：如果开发中途，你手动修改了某个文件，或者拉取了同事的新代码。运行此命令，让 AI 重新阅读工作区，更新它的上下文和任务清单，避免代码冲突。

5. 强制验收（ /opsx:verify ） ：强迫 AI 运行项目里的测试脚本（如 npm run test）。如果报错，AI 会自动根据报错信息修复代码，直到测试全部标绿。

6. /opsx:archive：所有功能跑通后，合并归档，完美收尾。

---

四、 最佳实践：如何真正驾驭 OpenSpec

要将 OpenSpec 发挥到极致，你需要完成从“打字员”到“技术负责人（Tech Lead）”的思维跃迁：

• 根据影响范围选工具：不要用高射炮打蚊子。改一个 CSS 样式坚决只用 Core Workflow（Propose -> Apply）。只有涉及模块联动时，才开启 Expanded Workflow。
• 在 Markdown 里改 Bug，而不是在代码里：在审查 proposal.md 或 design.md 时，如果发现 AI 漏掉了某个极端场景的处理，直接在 Markdown 文件里补充说明。在规划阶段纠偏的成本，是写完代码后再去修 Bug 成本的百分之一。
• 守好“批准”这道防线：永远不要在没有阅读 AI 提案的情况下盲目输入 /opsx:apply。你的主要工作不再是写代码，而是审查 AI 的“施工图纸”。

Vibe Coding 带来了生产力的爆发，而 OpenSpec 则为这股爆发的能量装上了方向盘和刹车。