使用 Fable 5、GPT-5.6 或同档模型，且不要求固定工程步骤时，可以选择 Native。需要 Comet 明确规定设计、计划、TDD 和审查步骤时，选择 Classic。
Native 管理目标和完成标准，具体实现方法由模型选择。Classic 同时管理目标、实现过程和阶段产物。两者适用于不同的开发方式。
30 秒完成选择
如果模型能力足够，而且团队没有必须遵守的固定开发流程，优先选择 Native。如果你更看重过程一致性，或需要模型严格执行指定方法，选择 Classic。
Native：轻量迭代与独立验收
Native 将核心精力聚焦在「交付目标与验收标准」，实现路径交由模型自主探索：
- 聚焦核心交付：在 Shape 阶段明确目标、非目标与验收标准，避免编写冗长的过程设计文档。
- Builder 提交候选：模型自主选择测试和实现策略。Builder 无法自行宣布任务完成，只能提交实现候选。
- 独立的只读 Verifier：Runtime 执行基础检查后，会派生全新的只读 Verifier Subagent，对照验收清单逐条核对代码与运行证据。
- 针对性修复循环：若有验收项未通过，Verifier 会携带具体失败原因将任务退回 Build 阶段，由 Builder 进行针对性修复，直到全部验收通过或达到轮次预算上限。
对于复杂任务，模型可按需调用特定 Skill，而不会在任务初期被强行要求完成形式化的多阶段文档。
Classic：全阶段工程治理与规范约束
Classic 适合对研发规范有严格要求的团队，提供可审计、分阶段推进的状态机治理：
- 阶段文档驱动：依次经过 Open（需求提案）、Design（技术方案）、Build（任务执行与 TDD）、Verify（规范核验）和 Archive（归档交付与经验留存）。
- 严格 Guard 门禁：每个阶段均有强约束的产物规范与 Guard 脚本，前序阶段产物未就绪无法进入下一阶段。
- 统一工程实践：系统会将 OpenSpec 与 Superpowers 相关规范以规则形式注入上下文，强制要求任务拆解与审查。
全阶段治理保障了研发流程的高度规范，但相对也会引入更多阶段上下文开销、过程文档和交互确认轮次。
选型建议与上下文考量：
- 强模型（如 Fable 5、GPT-5.6）：推荐优先使用 Native，端到端执行更快，交互轮次和 Token 消耗也更少。
- 私有化/较小规模模型（如 20B/30B 级别或 GLM 5.1 等级以下）：推荐使用 Classic。这类模型上下文窗口较小，Classic 在每个阶段生成的结构化文件能够防止长会话截断后丢失目标，通过明确的分步指令引导模型稳定交付。
两种工作流的实际区别
假设你要为用户资料页增加头像上传能力。
使用 Native 时，Comet 会先确认文件限制、失败行为等关键决定，再让模型自主完成实现和测试。Runtime 随后运行必要检查，并交给新的只读 Verifier Subagent 对照完整验收列表判断。发现有验收项未通过就返回 Build；全部通过后归档。
使用 Classic 时，同一需求会依次经过 Open、Design、Build、Verify 和 Archive。设计文档、任务计划、实现方式和审查过程都有明确边界，模型按阶段完成对应产物后才能继续。
同一项目可以同时使用
如果不同任务需要不同方式，可以同时启用两套工作流：
.comet/config.yaml 中的 default_workflow 决定 /comet 默认进入哪套工作流。这个设置只影响新入口，不会把已有 change 从 Native 转成 Classic，也不会把 Classic change 转成 Native。两边分别管理自己的 change、状态、Guard 和产物。
仍然拿不准怎么办
- 模型能力足够，想更快得到经过独立验收的结果：选择 Native。
- 团队要求固定设计、计划、TDD 或审查流程：选择 Classic。
- 项目里两种情况都会出现：同时启用，把更常用的一种设为默认。
模型名称只是能力参考。Comet 不会读取模型名称并自动切换工作流，最终选择由项目配置决定。
继续阅读：Native 快速开始、Native 工作流 和 Classic 工作流。 
