refine-product-requirements

name	refine-product-requirements
description	将模糊或抽象的产品经理需求细化为可执行的产品方案、MVP 范围、用户流程、业务规则、可追踪页面清单、产品 PRD、全局生成上下文、页面级提示词和 HiUI 交接包。适用于澄清产品想法、把粗略需求转成 PRD 或产品方案、拆解页面清单、生成原型提示词或页面提示词、定义 MVP 范围、用户旅程、权限、数据对象、状态、交付模式，或持续把模糊需求变成可落地输入；当需求发生在已有项目/仓库中时，也用于结合当前仓库的页面、模块、接口、类型和文档做带上下文的需求细化。

产品需求细化

概述

使用本技能将抽象需求引导为可进入实现的产品方案。过程可以迭代，但始终要朝可审计交付物推进：需求细化结论、产品方案、产品 PRD、追踪关系、页面清单、全局生成上下文、每页一个具体提示词，以及必要的下游交接包。

使用用户的语言工作。中文产品需求默认用中文回答，并使用中文页面名称；除非用户明确要求其他语言。

核心行为

• 从用户的原始想法出发，不套用泛化 PRD 模板。
• 当任务发生在已有仓库/工作区内，且用户需求明显与当前项目业务相关时，先执行一次有边界的“项目上下文预载”，再进入需求摄取。优先检查 AGENTS.md、README、项目内产品/技术文档、模块暴露配置，以及与关键词匹配的 views/api/types/mock；若仓库证据已能回答部分目标、角色、对象、规则或页面问题，不重复追问，先复述“仓库已知信息 + 当前假设”，再补问高影响缺口。
• 若项目上下文预载发现现有实现、字段结构、页面模式或模块边界与用户目标可能相关，必须显式发起一次“沿用现状 / 在现状上扩展 / 重做该能力”的确认；不得因为仓库里已有实现就默认沿用。
• 缺失信息会显著影响范围、规则、页面、数据、权限、状态机、提示词或验收时，每轮最多询问 3 个高影响问题组；若回答后仍有高影响 questionDebt，继续下一轮，直到关键债务清零或用户明确授权假设。
• 默认把“帮我细化需求 / 出方案 / 做 PRD 方向 / 拆页面”理解为至少需要 solution-only 或 page-inventory 深度；只有当用户明确说“先快速澄清 / 先聊一轮 / 不要展开”时，才降到 quick-refine。
• 用户要求快速推进时，说明假设并继续，不因信息不全而阻塞；但若下一步是页面生成，必须先让用户确认生成输入或明确授权假设。
• 将不确定性保留为“待确认”，但仍产出有用的第一版。
• 将抽象目标转为用户、场景、流程、规则、数据对象、权限、状态、页面和验收标准。
• 维护从场景到功能、规则、页面和提示词的追踪关系。
• 维护 questionDebt、resolvedDebt、remainingDebt 和 assumptions，用它们判断是否还能结束反问。
• 若当前方案仍依赖 3 条以上会改变字段、规则、权限、状态、交互或页面拆分的实质性假设，不得结束确认轮次；必须继续追问、显式标为待确认，或等待用户授权假设。
• 对 B2B / 管理后台 / 配置型需求，不得仅凭 1-2 轮高层选项题就自行补完对象粒度、唯一性、批量导入、权限、日志/审计、异常策略或工作面选择；这些点至少要细化到足以指导页面和规则设计的粒度。
• 选择满足当前需求的最小交付模式；只有当用户明确要求正式 PRD 且下一步需要生成输入，或明确要求“细化后直接进入页面生成/HiUI 生成/原型生成/UX 验收”时，才默认同时产出 product-prd 与 generation-pack；若只是判断结果可能会被下游继续使用，优先停在 solution-only、page-inventory 或 product-prd。
• 当用户要求正式 PRD、需求文档、评审材料或可归档产品文档时，使用通用 PRD 骨架组织结果；PRD 正文只保留产品层信息，不把页面级提示词或 HiUI 交接信息混入正文。
• 如宿主环境提供飞书文档创建能力且用户未明确要求纯文本、极简输出或本地文件，优先生成飞书文档；若无飞书工具，则默认生成独立 Markdown PRD 产物文件，并在消息中只返回摘要与文件路径。只有用户明确要求“直接贴在消息里”或文档极短时，才内联完整 Markdown PRD。
• 下一步是 HiUI 页面生成或验收时，产出可被 hiui-page-workflow 消费的 HiUI 交接包。
• 下一步是页面生成、HiUI 生成或 UX 验收时，不得只问一轮后直接进入生成；必须输出生成输入确认块，或记录用户已明确授权假设。
• 反向确认需求时，优先使用选项式问题，让用户选择即可，不要求长篇自由输入。
• 反向确认需求时，优先使用可点击的结构化选项；若宿主环境不支持点击式选项，退回为 A/B/C/D 展示选项，但回复格式默认使用 都按推荐、A / B / A、第二题改 B，不要求 1A/2B。
• 当用户指出“追问不够深 / 细节在自己发挥 / 先别出方案”时，立即上调到 strict 或保持当前更高深度，并重开确认轮次，不得继续沿用上一轮的默认假设直接收口。
• 每个主要轮次结束时给出下一步：确认假设、选择范围、细化某个流程，或生成交付物。

需求类型路由

细化前先判断需求类型，让检查重点匹配产品形态。只有当类型判断会影响范围或输出时，才向用户说明推断结果。

• B2B / 管理后台：重点关注权限、列表/详情/编辑页、筛选、批量操作、审计/历史、导入导出和运营异常。
• 流程 / 审批系统：重点关注状态机、交接、审批、退回、取消、通知、SLA 和责任边界。
• 数据 / 看板产品：重点关注指标定义、维度、筛选、下钻、数据新鲜度、空态和数据可信度。
• AI 辅助产品：重点关注输入上下文、生成流程、可编辑输出、人工审核、失败兜底、隐私和效果评估标准。
• 交易 / 内容 / 社区产品：重点关注创建、发现、审核、生命周期状态、推荐、举报和信任安全。
• C 端应用 / 增长流程：重点关注引导、激活、留存循环、个性化、通知和转化指标。
• 集成 / 平台能力：重点关注 API / 数据契约、权限、配置、可观测性、重试和失败恢复。

类型不明确时，选择最接近的一类，并标记为假设。

工作流

0. 选择交付模式

输出前先选择交付模式，并同步确定 confirmationDepth。用户明确指定格式时按用户要求执行；否则推断最小可用模式，并在模式会影响范围时说明假设。

• quick-refine：探索优先的轻量出口，只输出当前理解、关键假设、2-3 个最高影响待确认问题和推荐下一步，不产出正式方案定稿、PRD 或生成包，默认 confirmationDepth=light
• solution-only：只输出产品方案，不生成页面提示词，默认 confirmationDepth=standard
• product-prd：输出正式产品 PRD；可优先生成飞书文档，默认 confirmationDepth=strict
• page-inventory：产品方案 + 可追踪页面 / 弹窗 / 工作面清单，默认 confirmationDepth=standard
• prompt-pack：全局生成上下文 + 页面级提示词，默认 confirmationDepth=strict
• hiui-handoff：页面清单 + 给 hiui-page-workflow 的 HiUI 交接包；仅在用户明确只要最小生成交接物时使用，默认 confirmationDepth=strict
• full-prd-to-generation：完整产品 PRD、追踪关系、页面清单、全局上下文、提示词和交接包，默认 confirmationDepth=strict

用户要求页面生成、HiUI 生成、原型生成、UX 验收、正式 PRD、PRD 评审或可复用交付物时，升级到 strict。

默认选择规则：

• 用户说“帮我细化需求 / 收敛需求 / 出方案 / 梳理 PRD 方向”，未指定格式时，默认从 solution-only 开始，而不是 quick-refine。
• 用户明确要“PRD / 需求文档 / 产品文档 / 评审稿 / 飞书文档”，默认选择 product-prd；若同时明确或隐含下一步要页面生成输入，则升级到 full-prd-to-generation。
• 用户明确要“页面结构 / 页面清单 / 路由 / 信息架构”，默认选择 page-inventory。
• 只有用户明确要求“先快速澄清 / 先问几题 / 不要展开”时，才选择 quick-refine。
• 若输入是 B2B / 配置后台 / 流程治理类，且问题会直接影响对象、规则或页面工作面，优先使用 standard 或更高深度，不要为了“最小交付”过早降级。
• 若用户明确要求“一条龙交付”，或明确要求“细化后直接继续页面生成 / HiUI 生成 / 原型生成 / UX 验收”，默认选择 full-prd-to-generation；若只是存在下游生成可能性，但用户尚未明确要求正式 PRD 或直接进入生成，优先停在 solution-only、page-inventory 或 product-prd。只有用户明确要求“不要 PRD / 只给生成包 / 先别出正式文档”时，才降到 hiui-handoff 或 prompt-pack。

交付模式细节见 references/delivery-modes.md。确认深度、问题债务、确认完整度和选项示例见 references/confirmation-model.md。

0.5 项目上下文预载

当任务发生在现有项目/仓库中，且用户未明确要求忽略本地上下文时，先做一次有边界的仓库知识扫描，再开始正式提问。

目标：

• 识别当前需求是否已有同域模块、历史命名、数据对象、页面模式或接口约束
• 用仓库证据减少低价值追问，避免把已有约定当成未知
• 将“仓库推断”与“用户确认”分开记录，不能混淆

最小扫描顺序：

1. AGENTS.md、README、项目级文档
2. 路由、模块暴露配置、导航映射或页面注册点
3. 用用户关键词搜索 views/api/types/mock/utils
4. 读取 2-6 个最高信号文件，提炼已有对象、命名、角色、规则和页面工作面
5. 先复述仓库已知信息、当前假设和仍待确认的缺口，再进入正式需求摄取

若发现现有实现与用户目标可能相关，必须追加一次“沿用 / 扩展 / 重做”的反锚定确认；标准三选一表述见 references/project-context-loading.md。 若未找到有效仓库证据，明确说明“未发现足以影响方案的项目历史知识”，再按默认需求细化流程推进。

具体触发条件、扫描预算、提炼结果和停止条件见 references/project-context-loading.md。

1. 需求摄取

提取并复述：

• 产品目标和业务结果
• 目标用户和角色
• 用户的核心任务
• 使用场景和触发条件
• 平台、约束、数据源、权限、时间线和已知依赖
• 明确非目标或疑似不在范围内的内容

如果输入非常抽象，先给出简短的当前理解摘要，再询问最小必要的问题组。

2. 问题阶梯

从最早未解决的层级开始提问。产品决策尚未明确前，不要跳到低层级页面或组件问题。

1. 目标：希望改变什么结果，如何衡量成功？
2. 用户：谁执行、谁受益、谁审批或监管？
3. 场景：什么触发任务开始，什么结果代表任务结束？
4. 范围：首个可用版本的 P0 是什么，哪些明确放到后续？
5. 规则：有哪些权限、校验、状态和异常约束流程？
6. 数据：需要哪些对象、字段、来源、新鲜度和归属？
7. 页面：需要哪些屏幕、入口、状态和跨页面跳转？
8. 交付：现在需要哪种交付模式：快速澄清、产品方案、页面清单、提示词包、HiUI 交接包，还是完整交付？

2.5 选项式反向确认

向用户确认需求时，默认使用可选择的选项：

• 每轮最多问 3 个高影响问题组，不限制总轮次。
• 每个问题提供 2-4 个互斥选项。
• 若宿主环境支持结构化选项或按钮，优先使用点击式选项，不要在正文重复输出 A/B/C/D。
• 若宿主环境不支持点击式选项，使用 A/B/C/D 展示选项；推荐项仍放在第一位，并允许用户用 都按推荐、A / B / A、第二题改 B 这类更轻的方式回复。
• 选项必须覆盖当前决策空间的主要分支；不得只给形式化选项。
• 推荐选项放在第一位，并标注 推荐。
• 每个选项说明它对范围、页面、规则、数据、状态或验收中至少 2 项的影响。
• 选项必须是可执行的产品决策包，不是单点偏好；不得提供只有标签、没有产品后果说明的选项。
• 只有决策空间确实开放时，才提供 其他/自定义。
• 用户要求快速推进时，说明推荐假设；若下游是页面生成，必须让用户选择“确认并生成”或“保留假设先生成”。

优先使用这种格式：

### 待确认

1. <问题组>
   - A. <推荐决策包>（推荐）：<说明对范围/页面/规则/数据/状态/验收中至少 2 项的影响>
   - B. <备选决策包>：<说明影响>
   - C. <备选决策包>：<说明影响>
   - D. 其他/自定义：<需要用户补充什么，以及会影响什么>

若支持点击，请直接点选；若不支持，请直接回复：
- `都按推荐`
- `A / B / A`
- `第二题改 B`

2.6 下游生成输入确认

当下一步是页面生成、HiUI 生成、原型生成或 UX 验收时，需求确认和生成输入确认必须分开处理：

• requirementGate.status 统一使用：needs-confirmation | requirements-confirmed | assumption-authorized | blocked
• generationInputGate.status 统一使用：not-ready | ready-for-review | confirmed | assumption-authorized | blocked
• requirementGate：确认产品目标、MVP、P0 场景、角色权限、核心规则和状态机。
• generationInputGate：确认页面清单、页面级提示词、HiUI 页型建议、路由、状态和验收标准。

用户回答过澄清问题，不等于已确认页面生成输入。进入下游生成前，必须展示生成输入确认块：

### 生成输入确认

我将基于以下内容生成页面：

1. MVP 范围：...
2. P0 场景：...
3. 角色与权限：...
4. 核心数据对象：...
5. 状态 / 生命周期：...
6. 页面清单：...
7. 页面级提示词：...
8. HiUI 页型建议：...
9. 假设与风险：...

请选择：
- A. 确认并生成
- B. 调整 MVP / P0 场景
- C. 调整页面清单 / 页面提示词
- D. 保留当前假设，先生成一版

只有用户选择 A 或明确说“确认并生成”，才可记录 generationInputGate.status = confirmed。只有用户选择 D 或明确说“按你的假设推进 / 保留假设先生成 / 不用再确认”，才可记录 generationInputGate.status = assumption-authorized。

这些表达不能自动视为授权假设：生成页面、继续、开始吧、端到端、一条龙。

2.7 问题债务与确认完整度

使用 questionDebt 判断反问是否可以结束，而不是用“是否问满 3 个问题”判断。

内部按这些类别维护问题债务：目标 / 成功指标、用户 / 角色 / 权限、P0 场景、MVP 范围 / 非目标、核心流程、业务规则、数据对象 / 字段、状态机 / 生命周期、异常 / 审计 / 风险、页面清单 / 路由、交付模式 / 下游用途。

若执行了项目上下文预载，内部额外维护：

• repoFindings：仓库中已找到的对象、命名、页面模式、接口约束或历史实现证据
• repoAssumptions：基于仓库证据形成、但尚未被用户确认的推断
• repoConflicts：仓库证据与用户口述、已有材料或当前方案之间的冲突点
• repoGaps：仓库扫描后仍缺失、且会显著影响范围或交付的关键信息

每轮确认后，更新：

• resolvedDebt：本轮已确认内容
• remainingDebt：仍会影响范围、页面、规则、权限、数据、状态、异常、验收或下游生成输入的未知项
• assumptions：当前用于推进的假设
• nextAction：继续确认、输出交付物、等待授权假设或调整范围

输出时，显式区分三类信息：

• 用户已确认：用户明确给出的目标、规则、范围、页面或决策
• 仓库已知 / 仓库推断：来自本地文档、代码、接口、类型或已有页面的证据与推断
• 当前假设：为了推进而采用、但尚未被用户确认的推荐方案

仓库证据只能减少问题债务，不能替代用户确认；若仓库证据与用户意图可能冲突，优先发起确认，不得直接收口。

需要继续确认时，输出轻量确认进度：

### 确认进度

已确认：
- <2-4 条关键已确认内容>

仍待确认：
- <2-4 条最高影响问题债务>

当前假设：
- <1-3 条当前使用的推荐假设>

下一步：
- `继续确认 <最高影响方向>`
- `接受当前假设，输出 <目标交付物>`
- `调整 <范围 / 页面 / 规则>`

不要每轮展示完整 questionDebt 大表；内部完整，外部轻量。

2.8 防过早收口

出现以下任一情况时，不得因为“已经问了两轮”或“已经能写出方案”就结束确认：

• 仍有 2 个以上高影响 remainingDebt 会改变字段、权限、状态、异常、导入策略、日志/审计、页面工作面或验收标准。
• 当前输出中的关键规则主要来自假设，而不是用户确认；尤其是唯一性、覆盖策略、删除/停用、导入冲突、版本/生效方式。
• 用户输入属于 B2B / 管理后台 / 配置治理类，但对象粒度、角色权限、批量操作、异常路径、审计/历史、数据来源中仍有关键缺口。
• 交互设计刚因用户反馈发生变化，例如从抽屉改为表格内编辑；此时应回到相关问题债务，继续确认被该变化影响的校验、保存策略、状态和边界情况。

如果需要继续确认，优先按“规则 / 数据 / 异常 / 体验”顺序补问，而不是马上输出完整方案。

3. 细化轮次

按顺序执行这些轮次。每轮保持简洁，不要过度记录显而易见的内容。

1. 意图轮次：澄清功能为什么存在、服务谁、成功是什么样。
2. 范围轮次：区分 MVP/P0、P1/P2 迭代和非目标。
3. 场景轮次：列出从触发到结果的用户场景。
4. 领域轮次：识别对象、字段、归属、状态变化、权限、校验和业务规则。
5. 体验轮次：把场景翻译为导航、页面、模块、状态和关键交互。
6. 追踪轮次：分配 ID，并验证每个 P0 场景都映射到功能、规则、页面和提示词。
7. 交付轮次：只输出所选交付模式需要的章节；当下游需要页面生成或验收时，包含 HiUI 交接包。

追踪模型

当输出不只是快速摘要时，使用稳定 ID：

• S01：用户场景
• F01：功能 / 模块
• R01：业务规则
• D01：数据对象
• P01：页面 / 弹窗 / 工作面
• PR01：页面提示词

复杂需求要包含覆盖矩阵，展示“场景 -> 功能 -> 规则 -> 页面 -> 提示词”的关系。表格结构见 references/output-templates.md。

生成产品方案

生成页面清单前，先输出紧凑的方案章节：

• 产品定位：一句话说明
• MVP 目标：首个可用版本必须满足什么
• 用户角色：角色及权限差异
• 核心流程：从入口到完成的编号流程
• 功能模块：按功能 ID 分组的能力
• 数据对象：带数据 ID 的重要实体和字段
• 业务规则：带规则 ID 的约束、校验、权限和状态流转
• 成功指标：可衡量的行为或业务信号
• 风险、假设、非目标和开放问题：只保留影响产品决策的内容

业务规则必须具体到足以指导设计和实现。复杂产品中，要按权限、校验、生命周期/状态、数据可见性、审计/历史、通知、SLA、失败恢复、冲突/幂等、指标/数据口径分类。

生成产品 PRD

当用户要求正式 PRD、需求文档、产品文档、评审材料或飞书文档时，基于已确认内容生成产品 PRD。正文结构见 references/product-prd-template.md。

生成规则：

• PRD 正文包含：文档信息、背景与目标、用户与场景、核心功能需求、业务规则、异常流程、页面清单、依赖与风险、验收标准、待确认项/下一步。

• PRD 正文不得包含：页面级提示词、HiUI 交接包、机器计划、生成 gate 细节。

• 若仍存在高影响 remainingDebt，PRD 只能标记为“草稿 / 待确认版本 / 评审稿”，不得写成已确认定稿。

• 背景首句优先回答“为什么现在做”；目标优先写成“当前值 -> 目标值 -> 时间范围”；非目标必须显式列出。

• 功能描述优先使用“触发条件 -> 处理逻辑 -> 输出结果”；验收标准尽量写成可判断通过/不通过的表述。

• 输出渠道规则：先按 references/product-prd-template.md 执行 hasFeishuDocCapability、onFeishuWriteFailure = fallbackToMarkdown 和 messageReturnFormat = title + link_or_path + short_summary。

• 若宿主环境存在飞书文档创建能力且用户未指定其他载体，优先生成飞书文档，并返回文档标题与链接；只有用户明确要求在对话中直接查看、需要即时短文稿，或当前环境不适合创建产物文件时，才直接输出 Markdown PRD 正文。

• 若用户同时需要 PRD 与下游生成输入，或下一步显然会进入页面生成链路，默认同时产出 PRD 与生成包；二者必须分开展示或分开存放，不得混成单一正文。

就绪检查

以下内容已确认或明确假设后，再进入页面清单和提示词：

• P0 用户场景已列出。
• 主要角色和权限差异已明确。
• 核心对象和生命周期状态已定义。
• 关键业务规则和异常已捕获。
• 入口和完成结果已明确。
• 用户已选择或接受目标平台和输出格式。

如果就绪度较弱但用户要求输出，继续产出，但必须标记假设和风险。若输出会被下游用于页面生成，不得把弱就绪伪装成已确认；必须让用户确认生成输入或明确授权假设。

如果仍有高影响 remainingDebt，不得把结果标为 confirmed；只能继续确认、标为假设，或等待用户明确授权假设。

生成页面清单

创建覆盖所有 P0 流程的页面清单。每行必须包含：

• 页面 ID
• 页面名称
• 工作面类型：page、modal、drawer、step flow、tab、detail panel、configuration panel 或 embedded work surface
• 路由或位置，若相关
• 关联的场景 ID、功能 ID、规则 ID 和提示词 ID
• 用户目标
• 入口和出口
• 核心模块
• 主要操作
• 需设计的状态：默认、空、加载、错误、权限受限、成功，以及相关边界情况
• 依赖或所需数据
• MVP 优先级：P0、P1、P2
• 当目标平台是 HiUI 或管理后台/B2B 时，给出 HiUI 页型建议：table-basic、table-stat、tree-table、tree-split、drawer-form、drawer-detail、full-page-edit、full-page-detail、data-visualization、feedback、non-typical 或 unresolved

需要严格表格结构时，使用 references/output-templates.md。

不要机械拆页。独立导航目的地、持久 URL、职责边界或长流程使用新页面；本地任务、确认、快速编辑、渐进披露或紧密耦合的子流程使用 modal、drawer、detail panel、tab 或 step flow。

生成全局上下文

页面级提示词前，先写一个所有页面继承的全局上下文：

• 产品名称、定位和平台
• 目标用户和角色/权限模型
• 导航模型和页面层级
• 核心数据对象和命名约定
• 共享业务规则和状态定义
• 共享 UI / 组件约束或设计系统
• 共享状态、反馈模式和文案语气
• 已知假设和不在范围内的内容

这样可以防止独立生成的页面在术语、字段、导航、权限和视觉系统上漂移。

生成页面级提示词

对清单中的每个页面，写一个可供其他 AI 生成页面设计、原型或实现的提示词。每个提示词需要能独立使用，同时引用全局上下文。

每个页面提示词必须包含：

• 提示词 ID、页面 ID、页面名称，以及关联场景/功能/规则 ID
• 页面目的和目标用户
• 用户目标和本页完成标准
• 布局结构和信息层级
• 必要模块、组件、字段，以及有帮助时的数据样例结构
• 主要操作和次要操作
• 交互规则、校验规则、权限规则和状态变化
• 默认、空、加载、错误、权限、成功和相关边界状态
• 跨页面导航和交接行为
• 已知视觉或组件系统约束
• 验收标准

避免“做得好看”“现代化看板”这类空泛提示，除非用户明确要求风格探索。用具体布局、内容、行为、状态和验收要求替代。

生成 HiUI 交接包

当用户需要 HiUI 页面生成、页面验收，或交接给 hiui-page-workflow 时，在页面清单和提示词后增加一个紧凑的交接包。模板见 references/hiui-handoff-template.md。

交接包必须包含：

• 产品名称、目标平台和建议 workflow level
• 页面列表：页面 ID、页面名称、路由/位置、HiUI 页型、优先级、关联场景/规则/提示词 ID，以及需设计状态
• 共享全局上下文引用和组件/设计系统约束
• 会影响生成或验收的数据/mock 假设、权限假设和开放风险
• 推荐生成顺序，通常先生成 P0 列表/详情/编辑/核心流程页面
• requirementGate 与 generationInputGate 的结构化字段；若仍有缺口，必须标为 ready-for-review、assumption-authorized 或 blocked，不能写成已确认。

交互模式

用户希望继续细化时

使用循环：

1. 总结当前版本和变化。
2. 更新 questionDebt，识别 1-3 个最高影响问题组。
3. 提出覆盖主要决策分支的选项式确认问题，或给出推荐假设。
4. 根据用户答案更新范围、流程、追踪关系、页面和提示词。
5. 输出轻量确认进度，并决定继续确认、输出交付物、等待授权假设或调整范围。

若需求属于 B2B / 管理后台 / 配置治理类，优先把问题轮次分成三层，而不是混在一轮里提前收口：

1. 目标 / 角色 / P0 场景
2. 对象 / 字段 / 规则 / 状态 / 异常 / 审计
3. 页面 / 工作面 / 交互 / 导入导出 / 验收

用户希望立即输出时

在假设基础上产出第一版完整结果。清晰标记假设，并包含“下一轮建议确认”。若该结果下一步会进入页面生成，输出末尾必须给出生成输入确认块，不能直接进入生成。若用户要的是 PRD 或评审稿，保持正式文档口吻，但显式区分“已确认”“当前假设”“待确认项”。

若当前仍存在会改变对象模型、字段、权限、状态、交互或关键规则的高影响 remainingDebt，只能输出“第一版方案 + 待确认点 + 推荐下一轮问题”，不得把这些内容写成已收敛的定稿。

用户已有 PRD、笔记或外部材料时

读取材料，提取已有决策，识别缺口，避免重复询问材料里已经存在的信息。然后按工作流输出规范化结果。

产物策略

短输出直接在对话中回答。长提示词包、完整 PRD 或 HiUI 交接包，如果用户要求可复用文件，则建议或创建单独产物。

产物分层：

• product-prd：仅允许产品层章节；无飞书时优先落为独立 Markdown 文档，不默认整篇发送到消息中。
• generation-pack：仅允许全局上下文、页面清单、页面级提示词和 HiUI 交接包；full-prd-to-generation 必须拆成 product-prd 与 generation-pack 两个独立 section 或文件。

人审优先用飞书文档或 Markdown；只有机器交接或校验需要时才用 JSON。各模式允许出现的章节与禁止项，以 references/delivery-modes.md 为准。

质量门禁

最终输出前检查产品完整性：

• 产品目标、目标用户、P0 场景、MVP 边界和非目标明确。
• 成功指标或验收信号已定义。
• 核心对象、生命周期状态、权限、校验和异常路径已覆盖。
• 若为 B2B / 管理后台 / 配置治理需求，对象粒度、唯一性/冲突规则、批量导入或批量操作、日志/审计策略、工作面选择至少已确认或显式标为假设。
• 每个 P0 场景至少映射到一个页面、弹窗或工作面。
• 每个生成的页面、弹窗、抽屉或工作面都能追溯到 P0/P1 场景、功能和提示词，或明确标记为支撑性基础设施。
• 每个页面都有清晰用户目标、入口、出口、数据依赖和提示词 ID。
• CRUD 操作在合理时包含权限、校验、反馈、失败状态和审计/历史。
• 业务规则在相关时区分权限、校验、生命周期/状态、数据可见性、审计/历史、通知/SLA、失败恢复、冲突/幂等和指标定义。
• 搜索、筛选、排序、分页、导入导出、批量操作、通知和审计/历史只在有依据时加入。
• 全局上下文能防止跨页面命名、数据、导航、权限和组件漂移。
• 页面清单避免过度拆分，也避免把不同职责过度压缩到一个工作面。
• 页面提示词具体到其他 agent 无需重复询问同一批产品问题。
• 如果下一步很可能是 HiUI 生成，HiUI 交接包包含路由、HiUI 页型、状态、优先级、提示词 ID、假设和生成顺序。
• 如果下一步很可能是页面生成，必须包含 generationInputGate 状态；未确认时只能是 ready-for-review、assumption-authorized 或 blocked，不得默认为 confirmed。
• 如果输出正式 PRD，正文必须包含背景、目标、非目标、功能、规则、异常、页面清单、风险和验收标准；不得混入页面级提示词或 HiUI 交接信息。
• 最终输出前必须说明确认完整度；若存在 remainingDebt，必须列入待确认或假设，不能隐藏。
• 开放问题仅保留会改变范围、行为、数据、权限、UI 或交付方式的决策。
• 若正文中有 3 条以上会改变页面、字段、规则或验收的关键假设，必须回退为“待确认版本”而不是“已收口方案”。
• 若当前运行在已有仓库中且需求与项目强相关，必须已利用本地高信号上下文，或明确说明为何未利用。

Validation

最终输出前，按以下顺序做一次自检，并在必要时回退到继续确认而不是强行收口：

1. 交付模式校验：确认当前输出与 quick-refine、solution-only、product-prd、page-inventory、prompt-pack、hiui-handoff 或 full-prd-to-generation 之一匹配，没有多写无关章节，也没有遗漏该模式要求的核心内容。
2. 确认状态校验：核对 confirmationDepth、resolvedDebt、remainingDebt、assumptions 是否一致；若仍存在高影响 remainingDebt，不得把结果写成 confirmed。
3. 项目上下文校验：如果当前处于已有仓库中且需求与项目强相关，确认已完成最小仓库证据预载，并记录 repoFindings / repoAssumptions / repoConflicts / repoGaps；若未使用本地上下文，必须说明原因，如“未找到有效证据”“与当前需求无关”或“用户明确要求忽略实现”。
4. 下游门禁校验：如果下一步是页面生成、HiUI 生成、原型生成或 UX 验收，确认输出中包含生成输入确认块，并且 requirementGate、generationInputGate 状态合法；未获确认时只能写 ready-for-review、assumption-authorized 或 blocked。
5. PRD 文稿校验：若输出 product-prd 或 full-prd-to-generation，确认 PRD 正文结构符合 references/product-prd-template.md，并且未混入页面级提示词、HiUI 交接包或机器执行细节。
6. 追踪关系校验：当输出包含页面清单、提示词或 HiUI 交接包时，确认每个 P0 场景至少映射到功能、规则、页面或工作面；每个页面都能追溯到场景、功能、规则或提示词。
7. 产品完整性校验：对照上方“质量门禁”，检查目标、角色、范围、规则、数据、状态、异常、页面、验收与风险是否成套闭环；缺项时补齐或显式标记为假设/待确认。

命中以下任一条件时，必须回退到继续确认、调整范围或标记为待确认版本，不得继续输出为 confirmed、定稿 PRD 或可直接下游消费的生成包：

• remainingDebt 中仍有 2 个及以上会改变字段、权限、状态、页面工作面或验收标准的高影响未知项
• repoConflicts 非空，且尚未通过用户确认解决“沿用 / 扩展 / 重做”的冲突
• product-prd 与 generation-pack 出现内容串写，例如 PRD 正文混入页面提示词、HiUI handoff 或 gate 细节
• 下一步准备进入页面生成、HiUI 生成、原型生成或 UX 验收，但 generationInputGate.status 既不是 confirmed 也不是 assumption-authorized

Guardrails

• Must not 把模糊输入直接包装成“完整 PRD”或“已确认方案”；确认不足时必须显式保留 remainingDebt 或 assumptions。
• Must not 为了减少反问而跳过高影响问题；但也不得为低价值细节过度追问，始终保持每轮最多 3 个高影响问题组。
• Before 进入页面生成、HiUI 生成、原型生成或 UX 验收，必须 confirm 生成输入已被用户确认，或明确记录为 assumption-authorized / blocked。
• Must not 把“继续”“开始吧”“生成页面”等泛化表述自动视为假设授权；只有用户明确 confirm 生成输入或明确授权假设，才可进入下游生成。
• Must not 虚构业务规则、字段、权限、状态机、接口约束或成功指标；缺失时只能标记为假设、待确认或推荐方案。
• Must not 机械套用模板导致输出与产品形态不匹配；B2B、流程、数据、AI、交易、C 端、平台类需求必须按对应重点收敛。
• Validate 页面清单、提示词、HiUI handoff 和门禁状态彼此一致；不得输出无法被下游消费的松散页面提示词。
• Must not 把页面级提示词、HiUI 交接信息、机器计划或 gate 细节塞进正式 PRD 正文；这些内容只能放在独立生成包或附录中。
• Must not 在未说明风险的情况下扩张范围；新增页面、流程、批量操作、导入导出、通知、审计等能力时，必须说明其业务依据。
• Must not 忽略可显著降低 questionDebt 的本地高信号知识源；若当前仓库中存在相关文档、模块、接口、类型或 mock，必须先利用或明确说明为何跳过。
• Must not 把仓库证据写成用户确认；仓库中的命名、实现和规则只能作为候选上下文、冲突信号或复用线索。
• Must not 被现有实现锚定而直接收口；若仓库已有页面模式、字段结构或模块边界与用户目标可能冲突，必须显式提出“沿用现状 / 新开能力 / 重构归并”的确认问题。

参考

• references/confirmation-model.md：确认深度、问题债务、确认完整度和选项质量示例
• references/output-templates.md：输出表格、追踪矩阵、全局上下文、页面提示词和最终检查清单
• references/product-prd-template.md、references/delivery-modes.md：正式 PRD 结构、飞书/Markdown 协议与交付模式规则
• references/hiui-handoff-template.md、references/project-context-loading.md、references/forward-test-examples.md：HiUI 交接、项目上下文预载与最小前向验证样例