feat: 补齐审查 prompt 的取证广度与定级下探规则

第二轮真实报告暴露的残留问题:
- agent: grep 要搜"符号族"而非单个字面(修 Apm.start 搜到、Apm.preStart 漏搜)
- prompt: 文件"本次新增"判定必须以 diff 为准(修把既有 AAR 误报为本次引入)
- prompt: 修复建议须标注已知陷阱(修建议 recycle 位图却不提渲染线程竞争)
- prompt: 极端/异常输入才触发的缺陷定级下探到 🟢(收敛过高定级)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

ai_review/agent.py

@@ -34,6 +34,7 @@ _AGENT_GUIDANCE = """
 强制取证（取证纪律必须对齐风险，越高风险的结论越要有证据，不允许高风险结论用最少的证据）：
 - 凡是要写"A 可能早于 B 执行 / 竞态 / 初始化顺序 / 时序"类结论：**必须先 grep 定位 A、B 的全部调用点和注册/启动点**（例如 `Apm.start()`、`preStart()`、`enqueue()` 在哪几处、是否同步无条件执行），确认真实执行顺序后才能下结论。未完成这一取证的，该发现最高只能标"🟢 需确认"，不得进 🔴/🟡。
 - 凡是要写"某符号被搬家 / 移动了设置位置"类结论：除新位置的时序外，**必须 grep 旧位置原本的触发条件**，对比新旧触发条件的覆盖差集（谁在什么时候不再被触发），把覆盖面变化本身作为发现，而不是只看新位置的时序。
+- grep 要搜"符号族"而非单个字面：排查初始化/生命周期顺序时，不要只搜一个调用字面（如只搜 `Apm.start(`）就下"仓库仅此一处"的结论；必须连带搜同类生命周期入口（同一类名/前缀，如 `Apm.`、`preStart`、`getInstance`、`init` 等），把全部入口找齐再判断真实初始化时序。"只发现一处"只能是搜过符号族之后的结论，而不是搜过一个字面之后的结论。
 - 一句话原则：任何"可能""如果…则…"类假设，能用 grep/read_file 证实或证伪的，必须先去证，不允许停在假设上直接定级。
 
 何时不该调工具：

ai_review/llm.py

@@ -64,6 +64,9 @@ def build_standard_prompt(diff_text):
 - 定级与证据强度挂钩：正文若含"如果…则可能…"这类未验证假设，该发现最高只能标 🟡 且措辞为"需确认"，不得进 🔴、也不得进"必须立即修复"；🔴 与"必须立即修复"只留给有确定性证据（能定位、能复现、能在 diff 内自证）的缺陷
 - 敏感数据外传类发现：先判定数据性质（个人信息 / 组织标识 / 技术标识），再与改动前基线比对；只有引入**新数据类别**才升级风险，若只是既有链路里已有同级字段的新增同级字段（如同链路已有品牌名、门店名时新增门店 ID），不单独升级为中/高风险
 - 不要建议撤销 diff 中明显有意的设计选择（如 abstract、显式报错、强制子类实现）；对疑似有意的设计，以问句呈现（"是否有意选择 X？"），而非直接给反向建议
+- 判断文件是否"本次新增/本次变更"必须以下方 diff 为准：只有出现在 diff 里的文件才算本次改动；仓库中早已存在、只是被本次改动的代码引用/注册的文件（既有二进制、既有依赖等）不得称"本次新增"，也不要据此提"本次引入 XX 风险"
+- 提修复建议时若该做法本身有已知陷阱（线程竞争、平台尺寸/纹理上限、回收对象被在途使用等），必须一并标注副作用或改用更稳妥做法；不得给出会引入新失败模式的建议而不提示
+- 定级下探：若触发缺陷需要正常业务数据不会产生的极端/异常输入（如数千字符的超长字段），且无证据表明此类输入真实会出现，则定 🟢 不进 🟡；仅当上游确有不受限的可疑数据源时才升级
 
 请严格按以下格式回复：
 
@@ -133,6 +136,9 @@ def build_deep_prompt(diff_text):
 - 敏感数据外传类发现：先判定数据性质（个人信息 / 组织标识 / 技术标识），再与改动前基线比对；只有引入**新数据类别**才升级风险，若只是既有链路里已有同级字段的新增同级字段（如同链路已有品牌名、门店名时新增门店 ID），不单独升级为中/高风险
 - 不要建议撤销 diff 中明显有意的设计选择（如 abstract、显式报错、强制子类实现）；对疑似有意的设计，以问句呈现（"是否有意选择 X？"），而非直接给反向建议
 - 避免重复：同一风险只在对应风险节区详述一次，"深度分析"与"总结"只做交叉引用和补充，不要把同一条风险原样复述多遍
+- 判断文件是否"本次新增/本次变更"必须以下方 diff 为准：只有出现在 diff 里的文件才算本次改动；仓库中早已存在、只是被本次改动的代码引用/注册的文件（既有二进制、既有依赖等）不得称"本次新增"，也不要据此提"本次引入 XX 风险"
+- 提修复建议时若该做法本身有已知陷阱（线程竞争、平台尺寸/纹理上限、回收对象被在途使用等），必须一并标注副作用或改用更稳妥做法；不得给出会引入新失败模式的建议而不提示
+- 定级下探：若触发缺陷需要正常业务数据不会产生的极端/异常输入（如数千字符的超长字段），且无证据表明此类输入真实会出现，则定 🟢 不进 🟡；仅当上游确有不受限的可疑数据源时才升级
 
 请严格按以下格式回复：