移动 PR 分维首轮评审简报
你是移动代码评审顾问。只根据用户约束写首轮代理提纲，不要编造已节省的分钟数。
平台与仓：{{stack}}
维度：{{dimensions}}
现有门禁：{{gates}}
输出 Markdown：
1. 每维检查问题与「必须含失败场景」的发现模板
2. 作者修复→人审判断的顺序
3. 禁止自动合并的条件
4. 上线前要约定的度量
禁止建议代理全绿即合并；禁止伪造「必省 30 分钟」。← 返回用例列表
Oleh：iOS 多维代理首轮评审——约省每人每天 30 分钟，人仍握合并键
团队（跨国 iOS）；披露多代理按正确性/一致性/测试/i18n·a11y 首轮；作者自测约省每人每天 30 分钟、评审周期下降且人审质量未降；自动合并曾翻车已撤。
场景说明
面向评审队列被机械检查拖死的移动团队：把「分维首轮代理 + 作者先修 + 人只做判断」写成门禁，区别于 CVE 无写权自动驾驶与四代理仓审计。
案例叙事
01他们做了什么
Oleh 在 veheria.tech《A Claude Code Review Workflow That Saved 30 Minutes Per Engineer a Day》（JSON-LD datePublished 2026-07-06 → 2026-07-06）写明：评审耗时主要耗在等待与机械检查，而不是缺一次「全能 LGTM」；他把机械维交给分维代理，把判断留给人，并坚持人握合并键。
实践上按正确性/一致性/测试/i18n·a11y 风扇审查 diff，发现必须带失败场景；作者先修再进人审。自动合并与单代理大杂烩都被他标为失败模式。自测口径约省每人每天 30 分钟。
本场景据此输出「分维首轮评审」提纲。禁止把 30 分钟写成组织 KPI，或建议代理全绿自动合入生产。
02实际效果
- 源披露分维首轮、约省每人每天 30 分钟、评审周期下降且人审质量未降、以及撤回自动合并等作者口径；属单一跨国 iOS 窗口，不可外推为你的逃逸缺陷率、编制或「代理评审必省半小时」。
- 能把「人从头到尾扫机械项」与「分维代理建议 + 作者先修 + 人做判断」拆开。
- 为无失败场景的噪声评论、以及缺度量就全仓铺开提供提问清单。
03值得知道
- 作者承认逃逸缺陷与高管工时等未干净测量，故不引用。
- 文末有策略咨询 CTA；流程仍依赖团队对信号的信任建设。
- 上面写的是 Oleh 团队实践帖，不是 Apple/Anthropic 官文。
04可复制提示词
代理评审噪声或漏并发问题复盘提纲
评论充斥空泛建议，或人审仍被 nil/并发打回。请写复盘提纲。
现象：{{symptom}}
输出：
1. 缺失败场景规则、单代理过宽，还是维度未覆盖
2. 最小修补
3. 下次验收标准
4. 人工确认清单
不要伪造「更多代理等于更少等待」。怎么做
- 粘贴仓库类型（如 iOS）、现有 PR 门禁，以及希望代理覆盖的维度（正确性/一致性/测试/i18n·a11y）
- Agent 按实践帖输出：分维首轮提示字段、必须含失败场景的发现格式，以及作者修复→人审判断的顺序
- 人工保留合并键；Agent 不代你打开「代理全绿即合并」
实用提示
- 源帖（JSON-LD datePublished 2026-07-06T00:00:00.000Z → 2026-07-06；页内 July 6, 2026；DEV 转载 JSON-LD 2026-08-22）：Oleh（veheria.tech / DEV@5uper0）把 Claude Code 代理放进跨国 iOS 团队的真实评审环：PR 打开即多代理分维首轮——正确性（边界/nil/并发）、一致性（模式/命名/错误处理）、测试（是否覆盖行为而非镜像实现）、i18n 与无障碍（硬编码文案、Dynamic Type、触控目标 <44pt）。每条发现必须引用文件行并描述具体失败场景，否则丢弃，用以压「请改进可读性」噪声。作者先根据发现修改，人再只做判断（模块边界、API 形状、该不该做）。明确翻车：①代理全绿自动合并——代理会优化「测试通过」而非「值得合并」，已撤回，代理建议、人决定；②单一大评审代理——发现浅，分维风扇才抓到真问题；③上线前未约定度量——30 分钟是事后回测基线。作者只愿引用自己量到的：数月日用后约省每人每天 30 分钟、评审周期下降、人审质量未降；逃逸缺陷率与高管工时回收未干净仪器化故不报。建议从单一维度（一致性最稳）、单仓、建议而非门禁起步。
- 与 henri-cve-migration-control-autopilot / davron-four-agents-77-projects-90-min 不同：本条是移动 PR 分维首轮评审省等待，不是 CVE 无写凭证自动驾驶或多仓并行审计