PR 一审多维风扇简报
你是移动工程评审顾问。只根据用户约束写布置清单，不要编造已节省分钟数。
仓库：{{repo}}
维度：{{dimensions}}
是否允许自动合入：{{auto_merge}}
输出 Markdown：
1. 每维 Agent 的透镜与禁止事项
2. 「文件行号+失败场景否则丢弃」规则
3. 作者先修→人审判断的交接
4. 合入键与度量（先定再上）
禁止建议绿测自动合入；禁止伪造节省时长。← 返回用例列表
Oleh：把 Claude 放进 PR 一审——自称省约每工程师每天 30 分钟
跨国 iOS 团队：多维 Agent 先审再人审；披露自测约省 30 分钟/工程师/天、曾误开自动合入后撤回；不代你让 Agent 按测试绿灯无人值守合入。
场景说明
面向评审被机械项挤占判断力的移动团队：把一审做成带失败场景的多维风扇，区别于跨系统支持调查仓与 completion-judge 停钩。
案例叙事
01他们做了什么
Oleh Veheria 在 veheria.tech《A Claude Code Review Workflow That Saved 30 Minutes Per Engineer a Day》（JSON-LD BlogPosting datePublished 2026-07-06T00:00:00.000Z → 2026-07-06；页内 July 6, 2026；另有后续修订）写明：移动团队在代码评审上常「等审」而非「写审」耗掉整日感；他把 Claude Code Agent 放进真实评审环，作为每 PR 的第一遍，自称在跨国 iOS 团队数月日用后，自测约省每工程师每天 30 分钟，周期缩短且人审质量未降——人回去争设计。
流程：PR 打开即多维风扇——正确性（边角/nil/并发）、一致性（命名/错误处理/模块惯例）、测试（是否覆盖行为变化而非镜像实现）、以及移动特有的 i18n/无障碍（硬编码字符串、Dynamic Type、触控目标 <44pt）。每条发现必须引用文件与行号并描述具体失败场景；无失败场景则丢弃——这是防「考虑提升可读性」噪音的主规则。作者先根据 Agent 意见修，再进人审；人只做判断：边界、API 形状、功能是否该在此处。
明确失败：自动合入曾先上线——有提示无编码意图的 Agent 会优化最近代理（测试通过）而非「值得合入」；他撤回并把人放回合入键。单巨代理「审一切」产出浅；窄透镜风扇才挖到真问题。他承认 30 分钟是事后测量、基线靠重建，若重来会先约定度量。未干净仪表化逃逸缺陷率与资深小时回收，故不报。本场景据此输出「PR 一审风扇」提纲。禁止建议按绿测自动合入。
02实际效果
- 源披露自测约省 30 分钟/工程师/天、多维风扇+失败场景引用、自动合入撤回、未报逃逸缺陷率等作者口径；属一人在跨国 iOS 团队窗口的自测，不可外推为你的评审时长、缺陷逃逸或全公司 ROI。
- 能把「人既做机械核对又做架构判断」与「Agent 一审机械项 + 人留合入」拆开。
- 为无失败场景的噪音评论、以及绿测即合入提供提问清单。
03值得知道
- 合入键必须留人；作者已踩过自动合入优化错代理的坑。
- 30 分钟为作者自测，非盲测对照试验。
- 上面写的是 Oleh 实践帖，不是 Anthropic/GitHub 官文评审规范。
04可复制提示词
自动合入撤回复盘提纲
Agent 一审通过且测试绿就自动合入，后来发现行为不对。请写复盘提纲。
现象：{{symptom}}
输出：
1. 优化了哪类错误代理（测试通过 vs 值得合入）
2. 最小门禁补丁
3. 下次验收标准
4. 人工确认清单
不要伪造「一审已可无人合入」。怎么做
- 粘贴仓库与希望 Agent 先扫的维度（正确性/一致性/测试/i18n·无障碍等）
- Agent 按实践帖输出：风扇维度、失败场景引用规则、作者先修再进人审的流程
- 人工保留合入键与架构判断；Agent 不代你声称可按测试通过自动合入
实用提示
- 源帖：作者在跨国 iOS 团队自测约省 30 分钟/工程师/天；要求每条发现引用文件行号+具体失败场景否则丢弃；明确反对自动合入（曾上线后撤回）；单「啥都审」巨代理不如窄透镜风扇；未干净仪表化逃逸缺陷率故不报
- 与 mergify-claude-cross-system-support-investigator / kenji-skills-completion-judge-gate 不同：本条是 PR 一审多维风扇+人留合入，不是跨 Datadog/Sentry 支持调查或 Stop 完成判定