平台PRD构建器（Platform PRD Builder）
利用此技能将粗糙的输入转化为结构化、可实施的产品需求。不要仅仅翻译。要理解、重组、丰富内容，并保持精确的范围。
操作模式
选择满足请求的最轻量模式：
- 完整PRD构建：为复杂的或跨系统的需求创建完整的PRD。
- 章节构建：仅编写请求的章节，如背景、范围、流程、API/数据变更或发布计划。
- 重写/润色：在不改变决策的前提下，改进结构、清晰度、英文或双语措辞。
- 输入标准化：在起草前，将零散的笔记转化为已确认的决策、假设、缺失的决策以及工程可读的语言。
- 模板匹配：当请求不一定需要完整的PRD时，选择合适的文档类型。
- 方向对齐草稿：在扩展为完整PRD之前，创建一个轻量级的概念/对齐版本。
第一步
简要识别：
- 业务场景
- 平台能力
- 涉及的系统
- 当前阶段和排除项
- 文档类型：完整PRD、PRD章节、单页BRD、双语草稿、英文重写、表格或流程描述
如果用户仅询问影响或可行性，请勿起草PRD；先进行影响分析。
如果文档类型不明确，提议最小的有用文档并继续，除非该选择会造成交付风险。
第0步：阶段检测
在起草前，对用户的阶段进行分类：
- 仅想法：首先创建方向对齐草稿。
- 零散笔记：首先规范化决策、假设和缺失的决策。
- 范围未定：在起草当前阶段需求前，路由至
platform-scope-checker。 - 准备好起草：构建请求的PRD或章节。
- 已有草稿：改进结构，或如果用户想要反馈，路由至
platform-prd-reviewer。 - RFC细节请求：在PRD中保留产品语义，并将实施细节路由至工程跟进。
构建挑战门控
在将请求转化为繁重的PRD构建之前，简要挑战是否可以通过以下方式实现相同的业务目标：
- 现有平台能力
- 配置
- 运营流程或临时人工处理
- 较小的工作流变更
- 分阶段发布
- 没有完整当前阶段行为的兼容性占位
如果答案不明确或构建风险较高，建议在编写完整PRD前进行范围检查。
两阶段交付
对于模糊的、从0到1的或大型跨系统需求，优先采用两个阶段：
- 方向对齐草稿：问题、目标用户/运营、平台能力、范围边界、核心流程、所有权、假设和开放决策。
- 详细PRD：按系统划分的需求、字段/API/数据变更、状态/边界情况、发布/运营、验收标准和风险。
当核心产品方向、MVP边界或事实来源仍未确定时，不要直接跳到详细PRD。
何时不使用
在以下情况下，不要将此技能作为第一步：
- 业务问题或目标用户仍存在争议；首先使用
platform-product-guide明确方向。 - 问题是“我们现在应该做这个吗？”；首先使用
platform-scope-checker。 - 用户只想要对现有文档的评审反馈；使用
platform-prd-reviewer。 - 请求是纯工程RFC、代码设计或实施计划，没有产品需求工作。
PM输入标准化器
当输入模糊、非技术性或为散乱笔记时，先将其转化为工程可读的产品决策，然后再起草。不要要求用户使用技术词汇。
当决策缺失时，使用这种轻量级输出：
已知决策
- ...
缺失决策
- ...
工程相关转化
- “需要审批记录”意味着审计日志字段、写入时机、查询权限和保留策略需要决策。
- “通知另一个系统”意味着回调时机、重试、超时、失败处理和状态一致性需要决策。
用业务语言提问，而不是技术标签问题：
- 不要问“幂等键是什么？”，而是问“如果相同请求被提交两次，系统应该创建新记录、拒绝它，还是返回现有记录？”
- 不要问“回调重试策略是什么？”，而是问“如果无法通知接收方系统，用户应该看到什么？谁负责修复？可以保持未解决状态多久？”
- 不要问“事实来源是谁？”，而是问“如果两个系统显示不同状态，应该信任哪一个？”
- 不要问“兼容性策略是什么？”，而是问“发布后，现有记录或进行中的流程会受影响吗？”
- 不要问“定义状态机”，而是问“这个请求从创建到完成可以有哪些状态？每个状态允许哪些操作？”
假设与证据账本
当重要决策是从粗略笔记中推断出来时，在最终确定前将其表面化：
假设
- A1：...
证据/来源
- E1：来自用户笔记/原型/先前PRD/会议记录/明确指示
需要确认
- C1：...
不要默默地将假设转化为需求。如果用户要求继续，则在开放问题中保留未解决项，并在已知时附带负责人/依赖项。
模板选择
根据文档类型选择模板，而不是强制使用一种固定结构。
短功能PRD：
- 背景
- 目标
- 范围
- 需求
- API/数据变更
- 边界情况
- 附件/链接
API/字段变更说明：
- 背景
- 变更的契约
- 字段表
- 验证/默认行为
- 向后兼容性
- 下游消费者
- 示例
配置UI PRD：
- 背景
- 目标
- 页面路径/入口
- 列表字段
- 筛选/查询行为
- 创建/编辑行为
- 验证规则
- 权限/审计
- 附件/原型
迁移PRD：
- 背景
- 范围
- 源/目标系统
- 迁移流程
- 数据映射
- 验证/对账检查清单
- 切换/回滚
- 开放问题
公式/规则逻辑PRD：
- 背景
- 规则格式
- 字段定义
- 处理逻辑
- 示例
- 边界情况
- 向后兼容性
默认PRD结构
除非用户提供不同模板，否则使用此结构：
- 背景
- 目标
- 范围
- 参与者/系统
- 整体流程
- 流程细节
- 按系统划分的需求
- API/数据变更
- 场景与边界情况
- 发布/运营
- 开放问题
- 依赖/风险
对于简短章节，只保留相关标题，但保持相同的思考顺序。
何时使用平台流程建模器
当需求涉及3个以上系统、生命周期/状态变更、回调/重试/超时、回滚/取消/重新提交、对账、结算、迁移或人工降级时，在编写整体流程、流程细节、场景与边界情况、状态转换或运营章节前，使用 platform-flow-modeler。
让它先形成流程表格，然后将这些表格转化为PRD散文、按系统划分的需求、场景、验收标准和开放问题。
输出契约
每个PRD风格的输出应使以下内容可测试：
- 问题和“为什么是现在”
- 当前阶段目标
- 范围边界
- 主要流程和关键异常流程
- 仍开放的产品决策
- 验收标准或场景矩阵
- 跨系统行为的所有者/事实来源
- 相关的发布、回滚或临时人工处理
默认响应形式：
- 简要说明所选文档类型（如有用）
- 起草的PRD内容或请求的章节
- 假设和开放决策（如有）
- 建议的下一步评审路线：范围检查、PRD评审、RFC跟进或干系人确认
此技能应产出文档，而不仅仅是建议。如果不能安全地产出文档，则输出缺失决策账本和下一步行动。
有关详细PRD模板和特定文档的输出契约，请在与完整PRD、0到1平台PRD、迁移PRD、配置UI PRD或API/数据变更说明相关的任务中，阅读 references/prd-output-contract.md。
场景与验收标准
对于场景与边界情况章节，使用Given/When/Then验收标准可以改进QA与工程对齐：
**场景：[名称]**
- Given：[前置条件：系统状态、参与者、数据、配置]
- When：[触发动作]
- Then：[预期结果：最终状态、用户/运营可见的结果、下游同步、审计记录]
在相关时涵盖以下场景类型：
- 快乐路径
- 验证失败：缺少字段、无效值、重复提交
- 下游系统失败：回调超时、API错误、部分失败
- 并发或重复提交
- 状态转换边界情况：从终态重新提交、流程中取消
- 回滚或逆转
- 人工降级：运营干预或异常队列条目
- 权限边界：不允许的操作者或源系统不匹配
使每个 Then 子句可测试。命名最终状态、用户/运营可见结果、是否通知下游系统、是否创建审计/事件记录。
如果场景矩阵很大，使用紧凑型表格：
| 场景 | 前置条件 | 触发器 | 最终状态 | 用户/运营结果 | 下游 | 审计 |
|---|---|---|---|---|---|---|
API/数据表格样式
对于API或数据变更，默认使用表格，包含：
- 字段
- 数据类型
- 必填
- 值/验证
- 描述
- 示例
- 变更类型：新增/现有/删除（相关时）
- 所有者/消费者（所有关系重要时）
0到1平台PRD补充
对于新的平台/基础设施能力，添加：
- 平台方向和设计原则
- 配置对象与运行时对象
- 所有权/事实来源表
- 生命周期/状态机
- 版本控制和快照行为
- 回调、重试、超时和幂等行为
- 审计/事件记录
- 权限和源系统隔离
- MVP排除项及未来迭代
- 按角色、数据范围和运营区域的UI/工作区模型
编写规则
- 当请求英文输出时，将粗糙的笔记转化为专业英文。
- 在反映真实系统名称或团队工件时，保留中英混合术语。
- 添加读者理解和实施所需的缺失解释，但不要发明业务决策。
- 如果输入质量参差不齐，在编写最终PRD前，将其规范化为业务层和工程协作层。
- 使用编号层次结构以提高可审查性。
- 对字段、API、所有权、场景、计算、状态转换和开放问题使用表格。
- 当多个系统变更时，按系统分离需求。
- 保持产品可读章节的产品可读性；将底层细节移至API/数据章节或开放问题。
- 当用户要求基于提供的原型或现有PRD结构时，遵循它们。
范围纪律
始终区分：
范围内范围外本阶段不支持未来迭代
不要将未来阶段的功能包含在当前阶段的需求中，除非作为明确的排除项、兼容性说明或未来迭代。
流程和数据需求
对于跨系统工作：
- 在相关时分别描述创建/查询/回调/更新/结算/对账流程
- 识别持久化点和状态变更
- 分别定义配置时字段和运行时字段
- 区分快照字段和动态解析字段
- 谨慎使用字段名称；单复数命名可能编码范围，例如
portalCode与portalCodes
护栏
- 将历史PRD视为学习/参考材料，除非用户要求重写它们。
- 不要注入来自以前项目的不相关上下文。
- 当用户询问需求时，不要输出代码。
- 不要过度润色为营销语言。
- 不要隐藏开放决策；在知道时，明确列出它们以及负责人/依赖项。
需要标记的常见错误
- 在方向对齐准备好之前，起草详细需求。
- 在不标记的情况下将假设转变为需求。
- 将当前MVP与未来迭代行为混合。
- 只编写页面/按钮行为，而将状态、所有权和异常处理隐含。
- 在PRD中过度规定数据库、队列、重试任务或服务设计。
- 在未检查业务目标和范围边界的情况下，将实施请求视为产品就绪。
路由
- 当业务方向、平台抽象或决策框架尚未准备好时，路由至
platform-product-guide。 - 在将流程密集的章节转化为PRD内容前，路由至
platform-flow-modeler。 - 当当前阶段包含、MVP大小或隐藏复杂性未解决时，路由至
platform-scope-checker。 - 在起草后，当用户想要就绪度、差距或评分时，路由至
platform-prd-reviewer。 - 将RFC级别的实施问题路由至工程跟进，同时在PRD中保留产品语义。
质量检查清单
在最终确定前，验证：
- 文档解释了要构建什么以及为什么。
- 范围明确：范围内、范围外、现在不支持、未来。
- 需求对于QA或工程评审来说足够可测试。
- 跨系统所有权和事实来源可见。
- 假设与已确认的决策分离。
- 技术考量已被表面化，但没有过度规定实施。
- 下一步路线或评审步骤明确。
参考资料
references/prd-output-contract.md：当需要详细模板、特定文档契约或质量检查清单时加载。