一句话区分
- Native：强模型不需要被手把手教方法。Native 把计划、实现、测试、审查方法全部交给模型自己判断，只用可哈希的需求契约、内容寻址的验证证据和可恢复的归档锁住结果。
- Classic：模型需要明确的过程约束。Classic 用 OpenSpec 和 Superpowers 提供五阶段治理（open → design → build → verify → archive），显式组织设计、计划、TDD、调试与审查。
最根本的差异：完成判定权归谁
这是两套工作流最核心的分水岭。 Classic 依赖 guard 脚本检查 task/state 字段——流程走到位、字段填齐，就算通过。它的可靠性建立在”按方法走完五阶段”上。 Native 把完成判定权从模型手里收回 Runtime。它不信任”自述完成”：一次 Agent 轮次、一次 checkpoint、或 Agent 说”complete”都不算终点。Runtime 用一套机器可校验的证据系统判断是否完成——acceptance matrix、类型化 receipt、新鲜度围栏。强模型的可靠性瓶颈恰恰在”能不能被信任地完成”，而不在”会不会写代码”，所以 Native 把工程精力全押在验证和证据上。 代价是：Native 的 Runtime 比 Classic 重。这套证据系统（内容哈希、失败签名、停滞检测）是 Native 之所以”轻流程但可信”的根基。执行开销：Token、轮次、耗时
强模型被方法论束缚是最大的浪费。Native 不预设 TDD/review/subagent 模式、零外部 Skill 依赖（Classic 依赖 OpenSpec + Superpowers），因此执行开销显著更低。 Native 与 0.4.0 Classic 的对齐实验（16 个任务、每个任务 3 次运行，取双方均通过的 41 组配对样本）：
这说明两套工作流都能覆盖任务、完成质量相当，但 Native 在该实验中执行更轻。注意：该实验支持这个结论，但不能单独证明在所有模型、仓库和任务上 Native 都有因果优势。详见 Native 与 Classic 真实评估。
阶段取舍：为什么 4 个，不是 5 个
Classic 用五个阶段，每个阶段是独立的认知步骤：
Native 把 open 和 design 合并进 Shape——强模型能自主做澄清和设计决策，不需要被拆成两个强制阶段。Native 的四个阶段对应四个不可合并的认知边界：Shape 把目标说清楚（契约），Build 把东西做出来（实现），Verify 证明做对了（证据），Archive 把成果固化进基线（事务）。
少一个阶段不代表能跳过需求或验证。Native 的 Runtime 同样会检查 brief、target spec、用户确认、implementation scope 和验证证据——只是它不强制你按固定的方法走到位。
什么时候选 Native
满足以下任一条件，优先 Native：- 主力模型是 Fable 5、GPT-5.6 及同档强模型；
- 任务需要模型自主选择实现方法，不想被 TDD/计划/review 流程束缚；
- 想要更低的 Token 和轮次开销；
- 团队信任模型的执行能力，更关心”结果是否真的完成”。
什么时候选 Classic
满足以下任一条件，优先 Classic：- 模型能力档低于 Fable 5、GPT-5.6，需要更细的步骤指导来减少遗漏；
- 任务有强合规要求，需要显式的五阶段记录和决策点协议；
- 团队偏好明确的方法论约束（强制 TDD、review 深度、isolation 模式）；
- 仓库复杂或团队不熟悉，需要流程兜底而非模型自主。
两套可以共存
一个项目可以同时启用两套工作流，/comet 按 default_workflow 进入默认那一侧，互不迁移、互不替换：