案例：从会议纪要到可评审 PRD

把目标、Runtime、Skills、Tools、状态、审批和评估组合起来，设计一个协助产品经理推进 PRD 的 Agent。

「产品经理的 Agent 入门」之九
上一篇：Agent 的评估与产品化 · 系列入口

前八篇分别解释了 Agent 的定义、适用任务、运行过程、上下文、工具、自主权、状态和产品化。现在把这些概念放回一个具体场景：用户提交会议纪要、业务背景或 BRD 草稿，系统协助把需求推进成可评审、可追溯的 PRD。

它不是替产品经理一次性写完文档的聊天机器人，而是一个帮助用户识别缺口、组织证据、推进阶段并保留控制权的产品工作台。

1. 定义委派目标

用户委派的不是“生成一篇 PRD”，而是把不完整材料推进成可以由产品、设计、研发和测试共同评审的需求文档，同时保留来源、假设、待确认项和风险。

完成标准也不再是输出 Markdown，而是目标、用户、范围、流程、异常、指标、依赖和验收标准达到质量门禁。

业务想法 / 原始材料 → BRD 共创 → 产品定义
→ PRD 撰写 → 需求评审 → 上线复盘

如果目标用户和业务指标不清楚，系统不应为了快速输出而假装材料足够。它可以生成草稿，但必须暴露假设和缺口。

Skills 保存稳定方法，主 Agent 负责路由。这样可以独立改进评审 Rubric，而不必重写整个 Agent。

每个重要结论属于已确认事实、Agent 假设、待确认项或高风险项。这个设计把模型的合理补全从隐藏风险变成产品对象。

读取材料、获取需求、创建文档 Patch、运行评审、提交审批都由独立 Tool 完成。正式写入必须经过 Product API，在服务端检查身份、版本和权限。系统不提供无边界的“管理需求”工具。

顶部：需求阶段、评审状态、保存状态
左侧：Agent 提问、建议和执行进度
中间：原始材料、BRD、产品定义、PRD、评审、复盘
右侧：当前文档、来源标签、Diff 和预览

对话负责协作，文档区承载长期 Artifact，状态栏显示正式进度。用户每轮只回答少量真正阻塞下一阶段的问题。

用户回答后，Agent 生成结构化 Patch；Product Layer 校验目标文档、版本与字段；界面展示差异；用户批准后创建新版本并记录审计。版本与冲突检测阻止并发修改被无声覆盖。

评测要覆盖阶段判断、提问价值、证据分类、Skill 与 Tool 选择、PRD Rubric、越权与审批、中断恢复，以及用户接受率、完成时间和人工修改量。文笔流畅只是很小的一部分。

层	设计
Experience	对话共创、文档工作台、Diff、审批
Product	Requirement、Artifact、Review、Version、Permission
Orchestration	主 Agent、五个 Skills、阶段 Workflow、Resume State
Capability	文档、Patch、评审、搜索与业务 API Tools
Model	阶段判断、问题生成、内容生成、结构化输出
Control	证据标签、Schema、Approval、Trace、Eval、Replay

产品经理理解 Agent，不是为了替代工程师写 Runtime，而是为了设计一种新的软件关系：用户把目标委派给系统，同时保留必要的知情、判断和控制。

Agent 的价值来自判断和行动，可信度来自边界和证据。把两者同时设计好，才是从“AI 能生成什么”走向“产品能替用户完成什么”。