## 需求评审纪要自动分发 {.case data-case-id="009"} | 字段 | 值 | | --- | --- | | 案例编号 | `009` | | 行业 / 部门 | 互联网 / 产品 | | 角色 | 产品经理 | | 难度 | `入门` | | 调用来源 | `manual`（评审结束后由外部调用方发起一次手动调用） | 需求评审会开完后，PM 手写纪要发给相关团队，经常漏人、格式不一、关键决策淹没在聊天里，发错频道也常不了了之。目标：评审结束后把会议要点交给纪要 Agent 自动整理成结构化纪要（含关键决策、待办与负责人、需要跟进的问题），经 PM 确认后分发到输入里列出的全部团队频道，每个动作留审计时间戳。指标：从评审结束到分发完成的中位数 < 5 分钟；关键决策召回率 ≥ 95%。 - **覆盖**：把评审会议要点自动整理成结构化纪要，经 PM 确认后分发到输入里列出的全部团队频道。 - **不覆盖**：自动创建任务、录音转写、多语言翻译、自动判定频道归属。 - **假设**：会议要点由 PM（或外部调用方）在评审结束后以文字形式提供；目标频道清单作为调用输入提供，分发即按该清单逐个发送。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：把需求评审会议的要点交给纪要 Agent，让它整理成结构化纪要（含关键决策、待办与负责人、需要跟进的问题）；待办的负责人只能用要点携带的负责人受控令牌或角色代号（由平台在要点抽取时按白名单赋代号），缺失则标"待确认"，不从议题或部门猜测。App/Extension 在读取侧即完成聚合，Agent 只接收要点文本与发言人受控令牌（或平台赋予的角色代号）等白名单字段，不带出联系方式等个人字段。 结果由 PM 审批后，再发到评审输入里列出的全部团队频道。 触发：评审结束后由外部调用方发起一次手动调用，调用时带入会议要点的安全引用（令牌）、频道清单、纪要 Agent 和审批人（PM）；原始纪要留在会议系统，App/Extension 凭引用在进入工作流前抽取白名单字段，纪要 Agent 只处理要点的脱敏投影文本。 审批：确认后才分发，审批本身不设自动超时、无默认通过或否决；驳回则本次失败结束，需要更正就改输入、重新发起一次。 异常：纪要 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；分发时发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容；发现发错频道则更正频道清单、新开一次 Run 重发，并留审计时间戳。 完成：全部频道发送成功后结束，并留审计时间戳。 ``` ![案例 009 需求评审纪要：发起调用带入要点安全引用（令牌）与频道清单，纪要 Agent 整理结构化纪要，回传不合结构时停在原等待点；PM 确认后按清单分发到全部团队频道并成功结束，驳回则失败结束，分发发送失败按重试上限升级](../../../media/cases/fig-case-009-01-flow.svg){#fig-case-009-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **发起调用**：外部调用方（PM 或外部定时）发起一次手动调用，带入会议要点安全引用（令牌，原始纪要留在会议系统，由 App/Extension 凭引用抽取白名单字段）、频道清单、纪要 Agent 与审批人。 2. **整理纪要**：纪要 Agent 读取要点，按"关键决策 / 待办 / 跟进"分类生成结构化纪要；待办负责人只用要点携带的负责人受控令牌或角色代号（由平台在要点抽取时赋代号），缺失标"待确认"、不猜测；回传结构不合要求时停在原等待点，等其修正后重新提交，不自动重跑。 3. **PM 确认**：PM 看到分类好的决策与待办，确认继续或驳回。 4. **分发频道**：确认后按频道清单逐个发送到全部团队频道，并留审计时间戳。 5. **结束**：全部频道发送成功即成功结束；PM 驳回则失败结束、不分发，要返工就改输入、再发起一次。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个流程——它知道"整理纪要"需要一个发消息并等待回调的 Agent 环节、"PM 把关"需要一个审批环节、"分发"需要一个按频道清单逐个发送的发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整（每个环节的输入是否都连好），你不必关心这些技术细节。 - **纪要 Agent 回传不合结构**：本次完成请求被拒绝，流程停在等待点等 Agent 修正后重新提交，不会反复重跑，也不会发出残缺纪要。 - **PM 驳回**：本次失败结束、不分发；要改纪要或频道，改输入后新开一次 Run 即可。 - **分发发送失败（技术）**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发，不留死角。 - **发错频道（语义）**：不是不了了之——更正频道清单，新开一次 Run 把纪要重发到正确频道，并在审计记录里留下原发错误、更正动作与时间戳，可回查。 - **长时间无人审批**：审批本身不设自动超时，流程会停在等待状态。若业务需要响应时限，这是运营策略：由另一条定时检查的 Workflow（或值班人员）扫出超过时限的待审批项并通知 PM，而不是依赖本流程自动升级。 纪要必须经 PM 确认后才分发——确保发给团队的内容是准确、完整的。审批只有确认或驳回两种结果，驳回即本次失败，没有"AI 自动改"。PM 在确认时能看到分类好的决策和待办，扫一眼就能判断有没有遗漏；要返工就改会议要点输入、新开一次 Run。若要更严（如跨团队纪要双审），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流不直接对接外部系统；调用输入只携带会议要点的安全引用（令牌）与频道清单——原始纪要留在会议系统，App/Extension 凭引用在进入工作流前抽取白名单字段，原始纪要文本不作为调用输入带入。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），可回溯个人的字段（姓名/邮箱/证件/联系方式等）在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录。若将来要让纪要 Agent 自动从会议系统拉取要点或转写，由该 Agent 通过 App 或 Extension 完成，你只需在提示词里说"从会议系统读取本次评审要点"，不必在工作流里写对接逻辑。 - **回放集与基准**：取最近 30 次评审纪要回放，人工基准答案为既定关键决策清单；纪要覆盖的关键决策召回率 ≥ 95% 视为通过。 - **分母与口径**：召回率分母为基准决策总数；每次回放记录整理与分发时间戳。 - **人工确认**：每份纪要 100% 经过 PM 确认后才分发。 - **结果可见**：分发成功、发送失败、发错频道更正重发三类动作 100% 各有可见回执与审计时间戳，不出现静默结束。 - **时效**：从评审结束到全部频道分发完成的中位数 < 5 分钟。 - **抽样**：每周抽取 20% 已发纪要由 QA 复核格式与完整性。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 ### 复用与变体 - **同构迁移**：周会纪要、客户访谈整理、技术评审记录。 - **多频道路由**：按议题把待办分别发到对应团队的频道，而非全量广播。