哪些决定需要你确认

Native 只在真正的用户选择点暂停：存在两个或更多合理选项，而且不同选择会改变最终结果。仓库中可以查清的事实由 Agent 调查；内部实现方式由 Agent 在已确认的目标和约束内决定。 你负责确认目标、范围、默认行为和验收标准，Agent 负责在这些边界内选择实现方法。

​

三类信息，三种处理方式

Shape 会先判断每项信息由谁负责： 一个问题要成为用户选择点，必须同时满足三个条件：

1. 有两个或更多合理且可执行的选项；
2. 不同选项会改变用户可见结果、默认行为、失败结果、范围、风险或不可逆影响；
3. 你的要求、正式规格、项目文档和项目规则都没有给出答案。

不满足这些条件的问题不会来问你：能从仓库查清的，Agent 自己调查；只有一个可行选项的，Agent 说明依据后继续。执行出错或无法安全继续时，Native 会报告阻塞，说明当前状态和需要你处理的内容。

​

直接提供 PRD、文件或链接时

文件、附件、链接或本地路径构成需求来源时，Native 会读取完整内容，并建立来源覆盖：

• 按标题、段落、列表、表格、代码块、示例、约束、链接和边界记录来源单元；
• 将每个来源单元标记为 complete（已完整读取并归类）、partial（只读取了一部分）或 unavailable（当前平台或权限无法读取）；
• 把需要实现的内容映射到完整目标 Spec，并关联至少一个验收 ID；
• 将背景、非目标和已被新要求替代的内容分别归类并说明原因；
• 将无法读取、只读取一部分、缺少映射或仍有歧义的内容保留为 [blocking]。

这些记录写在 brief.md 的 Scope 部分。很长的文档会分多次读取，但每次读到的内容都会登记为来源单元，不会因为分块而漏掉任何部分。Native 也会生成需求摘要，帮你快速了解背景，但摘要可能省略细节，所以内容是否齐全以逐项映射为准：每条来源单元都对应到 Spec 和至少一个验收 ID。 你提供的材料如果明显用于排错、取证、审查或实现参考，Native 按它们的原有用途处理，不会当成需求；用途说不清时，会先问你是否把它作为需求来源。

​

澄清问题的提出方式

Native 会先调查事实，再根据决定之间的依赖关系组织问题。每道题都说明推荐方案和各选项的实际影响。native.clarification_mode 决定一轮提出一道题，还是集中提出本轮所有已经就绪的问题。 Sequential、Batch、问题编号和跨会话恢复的完整规则见 Sequential 与 Batch 澄清。

​

最终确认与进入 Build

所有用户选择处理完成后，Native 会汇总目标、范围、关键决定、验收项和非目标，并请你确认完整理解。Runtime 收到明确确认后，才允许 change 从 Shape 进入 Build。Sequential 和 Batch 使用相同的确认门禁。 大型需求还会检查是否适合拆成 Supervisor Change。多个结果能够独立实现和验证，并且存在明确依赖或并行价值时，Native 会给出拆分建议，由你确认子任务和推进方式。

​

Build 后需求发生变化

• 实现遗漏，需求保持不变：返回 Build 修复。
• 用户可见行为或验收标准发生变化：返回 Shape，更新正式需求并重新确认。
• 新要求与当前需求无关：为它创建另一个 change，保持当前范围稳定。

继续阅读：Native 工作流、Sequential 与 Batch 澄清、归档与交付 和 产物与状态。