OpenSpec 工作流
最近单位在推 OpenSpec 工作流，之前基于AI开展工作当然也会有对应的开发范式。
具体的手段为将技术拆分成对应的技术规范，根据技术规范拆分各个Task。顺序或并行执行各个Task。方法论是框架优先，设计优先，逐步迭代，多次确认，随时调整。
OpenSpec 工作流相较于这种天然朴素的开发范式，手段更加丰富，方法论的实践也更加具体。本质是为了更加清晰，模块化去的区描述一个项目，以达成人机共识，防止执行过程中出现偏差。
当然完事万物不可能没有缺点，为了保证人机共识更加彻底，就会有大量的文档，这些文档需要人工审阅就需要占用人工的生产力（取决于文档的多寡，其实这部分成本还不低），另外就是费Token。
本文以Vibe的一个小型的proxy-switcher为例，简单介绍一下OpenSpec 工作流。
开发背景
公司的网络环境有些复杂，大致分为了内网，内-外网，外网。为了简单理解，可以将这些网络环境当成平行同级的网络环境，这三个网络环境均不相互兼容。
内网：负责代码仓库的维护，代码的提交，合并均需要它，但没有互联网环境，Coding 是没法在内网环境下执行的。
内-外网：可能是为了方便外部用户体Issue以及Issue管理， Issue列表在这里，也有互联网，是我们主力工作的网络环境。
外网: 干净的未设置任何代理的网络环境。
说起来复杂，但其实要开发的就是一个简单的程序，通过修改Windows注册表的Proxy以及Host以实现网络环境的切换即可。
主要工具
这里介绍一下 /opsx 下的各个指令，也就对应的我们可使用的工具。
整体上看，OpenSpec 工作流把一次开发拆成了几个阶段，每个阶段对应一个 /opsx 指令，串起来就是完整的生命周期：
1 | /opsx:explore → /opsx:propose → /opsx:apply → /opsx:update → /opsx:sync → /opsx:archive |
注：上面的箭头只是”常规路径”，update、explore 随时可以插进来——方法论里的”随时调整”就落在它们身上。
| 步骤 | 命令 | 说明 |
|---|---|---|
| 0. 探索思路 | /opsx:explore |
与新需求或问题对话，通过 AI 澄清思路、梳理方案（不写代码，纯思考） |
| 1. 提出需求 | /opsx:propose |
描述你想要构建的功能，AI 生成 proposal、specs、design、tasks |
| 2. 实现需求 | /opsx:apply |
AI 按照 tasks 逐步实现代码 |
| 3. 同步规格 | /opsx:sync |
代码变更完成后，将 delta specs 同步回 openspec/specs/ |
| 4. 归档变更 | /opsx:archive |
完成后归档，specs 自动合并到主干 |
开发流程
这次 proxy-switcher 完整走了一遍 propose → 审阅修订 → apply → sync → archive。explore 和 update 本次没有单独触发：想法够清晰，直接进了 propose；修订也都是对话中提出、AI 直接落文档，没走 update 命令——工具是死的，流程是活的。
propose（提出变更）
- 做了什么：
openspec init初始化项目 →openspec new change创建变更 → 依序生成 4 份规划文档 → 校验通过。 - 产物：这 4 份就是人工要审阅的全部内容，合计约 265 行 / 2 万字：
| 产物 | 行数 | 字符 | 职责 |
|---|---|---|---|
proposal.md |
35 | ~3k | 做什么、为什么（动机与范围） |
specs/.../spec.md |
91 | ~6k | 系统必须做什么（增量规格 = 验收标准） |
design.md |
104 | ~7.4k | 怎么做（技术决策与取舍） |
tasks.md |
35 | ~4.2k | 实施步骤（21 个 Task） |
- 意义：AI 十几分钟就生成整套规划，但 2 万字需要人工逐份审——这就是”人机共识”的成本。
审阅与修订
- 做了什么：按
proposal → spec → design → tasks顺序审阅（与文档依赖关系一致）。审阅中用户纠正了 3 处理解偏差：- “内外网”不是”内 + 外兼容的代理”，而是与内网平级的独立模式；
clear同样改为与in/in-out平级的独立配置；testUrl从 config 顶层移入各模式内部。
- 每轮都是用户一句话，AI 同步改 4 份文档并重新校验，直到彼此一致。
- 意义：这是最费人工的环节——审阅 2 万字 + 多轮澄清。但价值正在于此：文档间的一致性由 AI 保证，方向的正确性由人保证。
apply（实施）
- 做了什么：按 tasks.md 的 21 个 Task 逐条实施，每完成一条勾一条。实际产物（
src/）：
| 产物 | 行数 | 职责 |
|---|---|---|
proxy-switch.ps1 |
284 | 共享运行时：代理 / hosts / 提权 / 验证的核心逻辑 |
3 份 SKILL.md |
各 ~12 | 三个模式的入口，供 Claude / Trae 加载 |
install.ps1 |
125 | 部署到用户全局目录 |
README.md |
149 | 安装、配置说明 |
- 实施中会不断暴露规范没覆盖的问题（如 UAC 提权流程、执行耗时、是否纯脚本化），通过对话”随时调整”，调整完继续实施。值得留意：本次后期实现甚至演化到封装成 exe，但没有同步回 spec/tasks——真实世界文档往往滞后于实现。
- 意义：把规范变成可运行的东西，在实践中校验规范；发现遗漏先回规范再改代码，而不是闷头硬写。
sync（同步主规格）
- 做了什么：把变更里的 delta spec 合并进主规格
openspec/specs/proxy-switch/spec.md（93 行 / ~6k 字符）。 - 意义：变更的增量沉淀为主规格，后续变更都以它为基准做 delta，形成知识积累。
archive（归档）
- 做了什么：确认任务全部完成（21/21）后，把变更移入
openspec/changes/archive/proxy-skill/。 - 意义：一次开发闭环收尾，specs 已并入主干，变更只留档、退出活跃状态。
总结
工具是个好工具，但用起来还是需要一定成本的同样的也更倾向于一些复杂任务场景，如果是需求清晰的简单场景仍可以采用效率优先的原则。 笔者也正在逐步摸索和实践这一整套工作流。