迭代式 OCR 代码审查

它解决什么问题

多仓库项目的代码审查有三个反复出现的麻烦。第一，审查工具默认只盯着根仓库，子仓库的改动经常被整段漏掉。第二，一轮 review 跑完，报告里高优先级的空指针、安全漏洞和一句风格建议混在一起，没人负责分诊。第三，改完代码再跑一次，上一轮已经修掉的问题又被原样报出来。ocr-review-loop 把这几件事串成一个可重复的循环：发现仓库、跑审查、分优先级、最小修复、抑制已知项、再跑一轮。

核心能力

• 仓库发现：扫描根目录下所有含 .git 的子目录，把清单展示给用户确认后才继续；工作区无改动的仓库直接跳过，不浪费 LLM 调用；最终报告按仓库分组汇总。
• 上下文注入：先分析审查目标（工作区 / 分支 / 单个 commit），提取简洁业务上下文，通过 ocr review --audience agent -b "context" 传给 OCR，同时用 --audience agent 抑制进度 UI。
• 优先级分诊：每条意见分三级。高＝明确 bug、安全漏洞、数据风险、空指针，必须修；中＝合理但依赖上下文的建议，修前先问用户；低＝疑似误报或吹毛求疵，直接丢弃且不展示。每个问题带唯一编号 R{轮次}-{序号}，后续引用只报编号。
• 最小修复：同一文件存在多个问题时从底部往顶部修，避免行号漂移导致后续定位错位。只修问题本身，不顺手重构无关代码。
• 抑制与循环：已确认修复的问题写入项目级抑制配置，下一轮不再报；修完重跑 review 验证，若仍有高/中优先级则回到分诊继续。

终止条件与适用边界

正常通过条件是高优先级清零，且中优先级为零或已明确判定无需修复。为防止无限循环，另有硬性约束：同一仓库跑满 3 轮仍未清零，强制终止并标注 ⚠️，列出剩余未解决问题；同一问题连续 3 轮出现且已确认无法修复，记入项目 TODO 并从后续审查中移除。

几个注意点：审查结论完全来自 ocr 的实际输出，不推测也不编造；不确定的问题会被降级，而不是为凑数塞进高优先级；commit 前必须经用户确认；低优先级意见在本流程里没有出口，如果你希望所有风格建议都留档，这个技能并不适合。