> ## 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.

# 直接投递 PRD：让 Native 从文档进入长程执行

> 把文件、附件、PRD 链接或 Grill me with docs 产物交给 Comet Native，由它生成完整目标 Spec；文档充分时跳过逐题澄清，确认后直接进入 Build。

Comet Native 可以直接接收文件、附件、PRD 链接或本地文档，并把其中的需求转换成可执行、可验收的完整目标 Spec。文档已经回答了目标、范围、行为和失败路径时，Native 无需再重复逐题澄清。你确认最终需求摘要后，它会进入 Build，继续完成实现、检查、独立验收和归档。

这条路径让你自由选择需求如何形成。你可以使用 Native 自带的 Sequential 或 Batch 澄清，也可以先用 Grill me with docs 等方式完成深度讨论，再把产出的文档交给 Comet。Native 负责把已有结论接入稳定的长程执行流程。

## 一份文档可以直接成为 Native 的需求入口

你可以通过多种形式提供需求：

| 输入方式                  | 示例                         | Native 的处理方式                 |
| --------------------- | -------------------------- | ---------------------------- |
| 对话附件                  | 上传产品需求、技术方案或验收清单           | 完整读取附件，记录来源覆盖并生成 Spec        |
| 本地文件或目录               | `docs/prd/batch-export.md` | 按文件结构提取需求、示例、约束和非目标          |
| PRD 链接                | Notion、语雀、飞书或其他可访问页面       | 读取页面内容；无法访问或只读取一部分时暂停并说明缺口   |
| Grill me with docs 产物 | 经过高强度澄清后形成的需求文档            | 把已确认结论作为需求来源，不重复询问文档已经回答的问题  |
| 已有 Spec               | 团队维护的规格、RFC 或设计文档          | 映射为当前 Change 的完整目标 Spec 和验收项 |

启动时直接说明文档的用途：

```text theme={null}
/comet 把我刚上传的 PRD 作为完整需求来源。根据全文生成 Spec 和验收项；
没有未决的用户选择时，展示最终摘要让我确认，然后直接进入 Build。
```

提供链接时也可以直接表达目标：

```text theme={null}
/comet 按这个 PRD 完成功能，并把它作为 Native Change 的需求来源：
https://example.com/product/batch-export-prd
```

## Native 会把原文转换成正式需求

Native 不会只保留一段摘要。它会按标题、段落、列表、表格、代码块、示例、约束和链接拆分来源，并将每个单元记录为：

* `complete`：内容已完整读取并完成归类；
* `partial`：只读取了一部分，仍可能遗漏有效要求；
* `unavailable`：当前平台或权限无法读取。

随后，Native 会生成并同步三类正式内容：

| 产物                           | 保存的内容                       | 作用                        |
| ---------------------------- | --------------------------- | ------------------------- |
| `brief.md`                   | 目标、范围、来源覆盖、决定、开放问题、验收示例和非目标 | 让你快速检查 Native 对原文的完整理解    |
| `specs/<capability>/spec.md` | 当前 Change 要交付的完整目标行为和场景     | 作为 Build 与 Verify 的正式需求依据 |
| 验收项                          | 可观察、可判定并带稳定 ID 的结果          | 约束实现、检查和独立 Verifier       |

需要实现的来源单元必须进入完整目标 Spec，并关联至少一个验收项。背景信息和非目标仍会保留分类与原因，但不会被误写成实现任务。新文档修正旧要求时，Native 会把旧单元标记为 `superseded`，并指向新的有效结论。

```text theme={null}
文件 / 附件 / PRD 链接 / Grill me with docs 文档
  → 完整读取与来源覆盖
  → brief + 完整目标 Spec + 验收项
  → 只处理真实缺口
  → 最终需求确认
  → Build → Verify → Archive
```

## 文档充分时跳过逐题澄清

Native 会先调查仓库、工具和运行环境中可以确定的事实。完成来源映射后，如果同时满足以下条件，它不会开启 Sequential 或 Batch 问答：

* 所有可访问内容已经完整读取；
* 每项有效要求都已经进入 Spec 和验收范围；
* 文档对目标、范围、默认行为和失败结果给出了唯一可执行解释；
* 文档内部没有互相冲突的要求；
* 仓库事实和项目规则没有暴露新的用户选择；
* 没有 `partial`、`unavailable`、未映射或待确认的阻塞项。

此时，Native 已经完成需求理解和 Spec 生成，可以跳过逐题澄清，直接展示最终需求摘要。摘要包含目标、范围、关键决定、验收项和非目标。你明确确认后，Runtime 才允许 Change 进入 Build。

<Note>
  “跳过澄清”指跳过没有必要的提问轮次。最终需求确认仍然保留，它确保 Native 生成的
  Spec 与你投递的文档一致，再把长程执行交给 Runtime。
</Note>

## 文档有缺口时只追问缺口

文档很长不代表需求已经完整。以下情况会形成 `[blocking]`：

* 链接需要登录，当前 Agent 无法读取；
* 文件损坏、格式无法解析或只读取到部分内容；
* 两个章节对同一行为给出不同结论；
* “支持失败重试”等表述缺少会改变用户结果的具体语义；
* 有效要求尚未映射到 Spec 或验收项；
* 材料可能只是调试证据、评审参考或实现资料，需求用途不明确。

Native 只围绕这些缺口提问。它不会重新询问文档中已经明确的内容。问题解决后，答案会立即写入 `brief.md`、完整目标 Spec 和验收项，再进入最终确认。

如果链接无法访问，最直接的处理方式是把原文导出为文件并投递给当前会话。摘要无法代替完整来源，因为被省略的表格、示例或限制条件仍可能改变最终行为。

## 使用 Grill me with docs 完成你偏好的澄清

Native 的澄清协议适合从一个目标逐步形成需求。如果你更喜欢 Grill me with docs 的高强度追问，可以先在它的对话中讨论产品决定、失败路径、隐含假设和非目标，并生成一份完整文档。

随后把文档交给 Comet：

```text theme={null}
/comet 将 ./docs/grilled/session-security.md 作为完整需求来源。
生成 Native Spec 和验收项，确认后把这个长程任务执行完成。
```

Comet Native 不依赖 Grill me with docs，也不会要求外部文档采用 Comet 专有模板。它把文件内容视为需求来源，检查覆盖、歧义和验收完整性，再接管后续流程。因此，你可以替换前置澄清方法，同时继续使用 Native 的 Runtime、状态恢复和验证门禁。

## 把 Native 作为长程任务执行器

文档确认后，你可以把注意力从“如何推进流程”转回最终结果。Native 会继续处理：

* 创建或绑定分支、worktree 和 Change 工作区；
* 根据 Spec 自主选择实现方法，并持续维护任务进度；
* 运行必要检查，提交可验证的 Builder 候选；
* 启动新的只读 Verifier，对照验收项检查真实结果；
* 验收失败时返回 Build 修复，并重新验证受影响范围；
* 在会话中断、上下文压缩或设备切换后，从项目中的稳定状态恢复；
* Verify 通过后完成 Archive 和已确认的交付动作。

你仍会在新的用户选择、无法访问的需求来源、执行阻塞或最终交付决定上收到提示。普通实现选择、状态推进和恢复工作由 Agent 与 Runtime 处理。

## 根据需求成熟度选择入口

| 当前输入            | 推荐用法                      | 交互结果                                    |
| --------------- | ------------------------- | --------------------------------------- |
| 只有一个初步想法        | 直接启动 Native 澄清            | Native 调查事实，并通过 Sequential 或 Batch 收敛需求 |
| 已有较完整的 PRD      | 直接投递文件或链接                 | Native 生成 Spec，只询问覆盖缺口和真实用户选择           |
| 已完成外部深度澄清       | 投递 Grill me with docs 等产物 | 跳过已回答的问题，确认最终摘要后进入长程执行                  |
| 已有正式 Spec 和验收标准 | 将其声明为完整需求来源               | Native 建立来源映射并接入 Build、Verify、Archive   |

Native 提供澄清能力，也接受你已经形成的需求。你可以让 Comet 从一句目标开始，也可以让它从一份成熟文档开始；两条路径最终都进入同一套可恢复、可验收的长程执行流程。

继续阅读：[哪些决定需要你确认](/zh/native/decision-ownership)、[Sequential 与 Batch 澄清](/zh/native/clarification-modes)、[Native Loop](/zh/native/native-loop) 和 [连续推进与稳定恢复点](/zh/native/continuation-and-checkpoints)。