使用 Fable 5、GPT-5.6 或同档模型，且不要求固定工程步骤时，可以选择 Native。需要 Comet 明确规定设计、计划、TDD 和审查步骤时，选择 Classic。
Native 管理目标和完成标准，具体实现方法由模型选择。Classic 同时管理目标、实现过程和阶段产物。两者适用于不同的开发方式。
30 秒完成选择
如果模型能力足够，而且团队没有必须遵守的固定开发流程，优先选择 Native。如果你更看重过程一致性，或需要模型严格执行指定方法，选择 Classic。
什么时候选择 Native
Native 适合你把重点放在“最终要得到什么”，并愿意让模型自己决定“具体怎么做”的情况。
选择 Native，通常意味着：
- 你确认目标、范围和影响结果的决定。
- 模型自主选择设计方式、测试策略和相关工程 Skill。
- Runtime 管理工作区、状态、中断恢复和阶段推进。
- Builder 只提交候选实现，不能自行宣布完成。
- Runtime 运行必要检查后，会启动一个全新的只读 Verifier Subagent，逐项核对验收标准。
- 验收失败会带着失败原因返回 Build，修复后重新验证。
Native 的主流程是：
它不会强制模型使用固定的设计模板、实施计划或 TDD 流程。需要这些方法时，模型可以按任务选择对应 Skill。
什么时候选择 Classic
需要每次开发都遵循明确、可复查的工程过程时，适合使用 Classic。
选择 Classic，通常意味着：
- 需求先进入 Open 阶段，建立正式 change。
- Design 阶段整理规格、设计和任务边界。
- Build 阶段按照计划执行，并根据配置使用 TDD、调试和审查方法。
- Verify 阶段检查实现与规格是否一致。
- 每个阶段都有明确产物和 Guard，不能随意跳过。
Classic 的主流程是：
这些约束让过程更统一，也会带来更多阶段上下文、过程产物和交互轮次。
Classic 的额外开销：Classic 会把 OpenSpec 和 Superpowers 的大量 Skill 渐进式加载进系统上下文，由于工程规则的变多，通常任务执行时间会远长于Native模式。我们建议在模型能力不足或团队要求固定流程时使用 Classic。如你是采用私有化部署的量化模型，典型规模为20B、30B模型，或私有化部署低于GLM 5.1等价能力的模型，这类模型上下文窗口不大，Classic会在各种阶段记录关键文件，防止窗口压缩后的任务目标和进度丢失，用更可控的工程流程约束Agent完成任务。
两种工作流的实际区别
假设你要为用户资料页增加头像上传能力。
使用 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 工作流。 
