Skip to main content
Native 识别出需要你决定的用户选择后，会根据问题之间的依赖关系组织澄清轮次。native.clarification_mode 控制每轮提出多少问题；两种模式使用相同的正式产物，也都要完成进入 Build 前的需求确认。 新项目默认使用 Batch。需求仍在快速变化，或一个答案可能改写后续问题时，可以切换到 Sequential。 用户选择点的判断标准和来源文档覆盖规则见 哪些决定需要你确认。

​
Sequential 和 Batch

在 .comet/config.yaml 中设置澄清模式：
切换模式只影响下一轮的提问节奏。brief.md 中已经保存的 [blocking] 问题继续有效，未回答的问题仍等待你的决定。

​
问题从决策树中产生

Native 会在工作过程中建立一棵决策树。每个节点记录一项用户决定、它依赖的上游决定、需要调查的事实，以及当前状态。决策树停留在 Agent 的工作过程，Runtime 只保存实际未解决的问题。 当一个问题满足以下条件时，它进入本轮可回答集合：
  1. 上游用户决定已经确定；
  2. 回答所需的仓库或环境事实已经查清；
  3. 它不依赖本轮其他尚未回答的问题。
Sequential 从这个集合中选择一道题。多个问题同时就绪时，优先处理影响下游分支更多、对用户可见结果影响更大的问题。Batch 会收集整个集合，并在一轮中一起提出。相互独立的事实调查可以并行执行；平台缺少并行能力时，由当前 Agent 逐项完成。每次收到答案或新的调查结果后，Native 都会重新计算决策树，因此后续问题会随着已确认的需求变化。

​
每道题都说明实际影响

Native 会把含糊表述转换成可以执行的行为，例如“输入 → 输出”或“触发条件 → 处理结果”。每道题包含三部分：
  • 问题：当前需要确定的用户可见行为；
  • 推荐：结合现有目标、约束和权衡给出的建议；
  • 影响：每个选项会怎样改变范围、结果或风险。
平台提供结构化提问工具时，Native 会在选项边界清晰且可以直接执行时使用它。Sequential 每次提交一道题；Batch 将本轮完整问题集放在同一次请求中。整组问题超出工具容量时，Native 会统一改用编号文本，保留原有选项、推荐和影响。 单选用于互斥选项。只有同一个决定允许组合多个兼容选项时，才使用多选。一次结构化调用失败后，本会话后续轮次直接使用文本，保持问题编号和回答方式稳定。

​
答案会立即写入正式产物

对话内容只负责交互，磁盘产物负责恢复。Native 收到答案后，会立即更新 brief.md 的 Decisions、完整目标 Spec 和对应验收项。含糊、遗漏或仍需决定的内容继续保留在 Open questions 中。 Sequential 保存当前问题：
Batch 使用稳定编号保存本轮问题：
部分回答只解决对应问题。其余项目保留原编号，下一轮会基于最新决定继续计算。

​
进入 Build 前确认需求

所有问题处理完后，Native 会再次检查事实、决定、默认行为、边界、失败路径和隐含假设，并向你展示最终需求摘要。摘要覆盖：
  • 目标与范围；
  • 关键决定；
  • 验收项；
  • 非目标。
最终确认不会写成 brief.md 中的 [blocking] 问题。Native 会让 Runtime 持久化 Shape 的确认边界，并返回 await-user；Agent 会展示完整摘要，等待你明确确认。 你确认后，Native 才会通过带有 --confirmed 的当前继续命令进入 Build。Runtime 对 Sequential 和 Batch 执行相同检查；缺少最终需求确认时，change 会停留在 Shape。你补充或修改摘要时，旧确认会失效，Native 会重新准备确认内容。

​
跨会话继续澄清

再次打开项目或继续一个 change 时，Native 会自动读取 .comet/config.yaml 和 brief.md，恢复当前澄清模式、已经确认的决定以及仍在等待回答的问题。你只需要继续说明自己的选择，恢复过程由 Native 完成。 如果你想查看当前记录，可以运行：
Native 会把你的答案对应到 brief.md 中的 Q1、Q2 等问题，写回正式产物，再计算下一轮。中途修改澄清模式只会改变后续提问节奏，当前阻塞项及其编号保持不变。 继续阅读：用户选择点与需求澄清协议、Native 配置 和 恢复与故障处理。
最后修改于 2026年9月4日