## Pull Request 描述自动生成与审核 {.case data-case-id="007"} | 字段 | 值 | | --- | --- | | 案例编号 | `007` | | 行业 / 部门 | 互联网 / 研发 | | 角色 | 技术负责人 | | 难度 | `进阶` | | 调用来源 | `manual`（由 CI/脚本/代码托管 webhook 转为一次手动调用发起，调用时带入改动摘要的安全引用） | 开发者常提交 PR 却描述马虎，审查人不知道改了什么、为什么改。目标：外部调用方把改动摘要带入工作流，由描述 Agent 生成结构化描述（做了什么、为什么改、影响范围、如何测试），缺权威信息的部分标"未提供/待确认"而非编造，经技术负责人确认后通知审查人频道。指标：描述四要素完整率从 30% 提升到 90%；审查启动时间中位数下降 40%。 - **覆盖**：基于外部调用方带入的改动摘要生成结构化描述，缺权威信息的部分标"未提供/待确认"，经确认后通知审查人频道。 - **不覆盖**：自动审查代码质量、自动合并、自动分配审查人、由工作流直接从代码托管平台拉取改动。 - **假设**：改动摘要作为调用输入由外部调用方带入（CI/脚本/代码托管 webhook 转为手动调用）；"为什么改/如何测试"等权威信息若调用方未携带则视为缺失。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：把一个 PR 的改动摘要交给描述 Agent，让它生成结构化描述，包含做了什么、为什么改、影响范围、如何测试四部分。 触发：由外部调用方（CI/脚本/代码托管 webhook）发起一次手动调用，调用时带入改动摘要的安全引用（令牌，原始改动数据留在代码托管平台，App/Extension 凭引用在进入工作流前抽取白名单字段）、审查人频道、描述 Agent 和审批人。 生成规则：做了什么、影响范围可从改动摘要推断；为什么改、如何测试若摘要未含权威信息，对应部分输出"未提供/待确认"，不要编造。 审批：结果由技术负责人确认后才通知审查人频道，审批本身不设自动超时、无默认通过或否决；驳回则本次失败结束，要更正就改输入、新发起一次。 异常：描述 Agent 回传的结构不合要求，就停在等待点等它修正后重新提交，不自动重跑；调用方带入的改动摘要为空或不完整，告警失败并留审计时间戳；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：审查人频道收到通知后成功结束，并留审计时间戳。 ``` ![案例 007 PR 描述生成：外部调用方带入改动摘要安全引用（令牌），描述 Agent 生成结构化描述，回传不合结构停在原等待点；技术负责人确认后通知审查人频道并成功结束，驳回则失败结束；缺权威信息的部分标未提供不编造](../../../media/cases/fig-case-007-01-flow.svg){#fig-case-007-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **发起调用**：外部调用方（CI/脚本/代码托管 webhook）发起一次手动调用，带入改动摘要安全引用（令牌）、审查人频道、描述 Agent 与审批人。 2. **生成描述**：描述 Agent 依据改动摘要生成四部分描述；做了什么与影响范围从摘要推断，为什么改与如何测试若摘要未含权威信息则标"未提供/待确认"，不编造；回传结构不合要求时停在原等待点，等其修正后重新提交，不自动重跑。 3. **人工确认**：技术负责人看到生成的描述，确认继续或驳回。 4. **通知审查人**：确认后把描述发到审查人频道。 5. **结束**：通知发出即成功；技术负责人驳回则失败结束、不发通知，要更正就改输入、新发起一次。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个流程——它知道"生成描述"需要一个发消息并等待回调的 Agent 环节、"确认"需要一个审批环节、"通知"需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整（每个环节的输入是否都连好），你不必关心这些技术细节。 - **描述 Agent 回传不合结构**：本次完成请求被拒绝，流程停在等待点等 Agent 修正后重新提交，不会反复重跑，也不会发出错误描述。 - **技术负责人驳回**：本次失败结束、不发通知；要更正描述就改输入、新发起一次调用，没有"AI 自动改"。 - **改动摘要为空或不完整**：调用方带入的摘要缺失关键信息时，告警失败并留审计时间戳，由调用方补全后重发，而不是让 AI 凭空补全。 - **为什么改/如何测试等权威信息缺失**：对应部分输出"未提供/待确认"，不编造原因与测试方法；技术负责人确认时能看到哪些部分缺失，决定是否要求开发者补充。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 每条描述都必须经技术负责人确认后才通知审查人，防止 AI 把不准的描述发出去。审批只有确认或驳回两种结果，驳回即本次失败，没有"AI 自动改"。确认时技术负责人能看到四部分中哪些是推断、哪些标了"未提供/待确认"，据此判断是否放行。 本工作流不直接对接外部系统；调用输入只携带改动摘要的安全引用（令牌），由外部调用方（CI/脚本/代码托管 webhook）转为手动调用带入——原始改动数据留在代码托管平台，进入工作流前由 App/Extension 凭引用抽取白名单字段。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段，原值不进入以上任何一层，并按 10% 抽查四层实际记录。数据源与失败路线由此明确：摘要为空或不完整走上面的告警失败回执。若将来要让获授权 Agent 定时从代码托管平台拉取改动，改用 `schedule` 调用来源，由该 Agent 通过 App/Extension 查询，工作流本身仍不直接调用外部系统。 - **回放集与基准**：取最近 50 个 PR 的改动摘要回放，人工基准答案为对应 PR 已确认的最终描述；四要素完整率 ≥ 90% 视为通过。 - **分母与口径**：完整率分母为回放总数，每个要素单独计数；每次回放记录生成与确认时间戳。 - **缺失信息处理**：基准中未含权威信息的要素，模型输出"未提供/待确认"记为正确而非缺失；编造原因或测试方法记为不合格。 - **抽样**：每周抽样 10 个已确认描述，人工复核与改动摘要的一致性。 - **时效**：审查启动时间中位数（从 PR 创建到审查人开始 review）下降 ≥ 40%；技术负责人确认耗时中位数 < 2 分钟。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录。 ### 复用与变体 - **同构迁移**：提交信息自动生成、变更日志生成、代码审查 checklist 生成。 - **定时拉取改动**：把调用来源改为 `schedule`，由获授权 Agent 定时经 App/Extension 查询代码托管平台的新 PR，再交给描述 Agent。