> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 用户决定与需求澄清协议
> 理解 Native 如何区分产品决定与实现选择，以及为什么共享理解完成前不能进入 Build。
Native 把“结果由用户决定、方法由强模型决定”作为核心边界。它不会用更少阶段换取模糊需求，也不会把行业惯例或现有代码默认值当成用户授权。
## 哪些必须由用户决定
任何会改变以下内容的未解决分支都属于用户决定：
* 用户可见输出、默认行为或错误结果；
* 兼容性、范围与风险承担；
* 数据删除、迁移或其他不可逆结果；
* 一个新能力在边界条件下的可观察语义。
实现结构、库选择、内部算法和测试组织方式，如果不改变上述结果，则由模型自主选择。
## 问题如何排序
Shape 会把关键动作写成输入→输出或触发→结果示例，再检查默认值、边界、失败路径和兼容性。一个反例能够区分两种合理解释，就说明共享理解尚未形成。
发现多个问题时，Native 不发固定问卷，而是先确定问题的前置决定和所需仓库事实。默认的 `sequential` 模式每轮询问一个最上游问题；`batch` 模式则一次提出所有前置条件已确定、且彼此不依赖的问题。每道问题都包含：
1. **问题**：需要用户确定的可观察行为；
2. **推荐**：基于目标和权衡给出的建议；
3. **影响**：各选项会怎样改变结果。
问题写入 `brief.md` 的 `[blocking]` 项。用户回答前，模型可以调查仓库或创建 change，但不能把某个选项写成既定规格、修改项目实现或推进到 Build。
## 什么时候不需要确认
当本轮已没有可回答问题，且另一个没有当前聊天记录的强模型仅凭 brief、完整目标规格、仓库事实和项目规则就能实现并验收时，共享理解已经成立。Sequential 模式会直接继续，不额外询问通用确认；Batch 模式会先给出一次最终共享理解摘要，只有用户明确确认后才进入 Build。
`--confirmed` 只用于记录用户刚刚回答了先前的阻塞问题。用户最初提出功能并不自动等于一次确认，也不能通过手工修改 approval 绕过需求澄清协议。
“保持现有行为”只能保护已经存在的结果，不能替一个全新的行为自动定义语义。相邻功能、依赖库默认值和最小改动原则只能帮助形成推荐，不能代替用户答案。
详细的模式选择、Claude Code 结构化提问和断点恢复见 [澄清模式与共享理解](/zh/native/clarification-modes)。下一步阅读 [Native 工作流](/zh/concepts/native-workflow#四阶段工作流)，了解同一个 Skill 如何从 Shape 持续推进。