feat: 强化审查 prompt 的取证纪律与定级校准

- agent: 时序/竞态、代码搬家类结论强制先 grep 取证
- prompt: 定级与证据强度挂钩,未验证假设不进必须立即修复
- prompt: 敏感数据外传做基线对比,同级字段不单独升级
- prompt: 不建议撤销有意设计;建议动作按修复/确认/优化分组
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

ai_review/agent.py

@@ -31,6 +31,11 @@ _AGENT_GUIDANCE = """
 - diff 删了某符号 → grep 它，确认没有遗漏的引用
 - 不确定某文件里有没有定义 X / 调用 Y → grep 一下立刻知道
 
+强制取证（取证纪律必须对齐风险，越高风险的结论越要有证据，不允许高风险结论用最少的证据）：
+- 凡是要写"A 可能早于 B 执行 / 竞态 / 初始化顺序 / 时序"类结论：**必须先 grep 定位 A、B 的全部调用点和注册/启动点**（例如 `Apm.start()`、`preStart()`、`enqueue()` 在哪几处、是否同步无条件执行），确认真实执行顺序后才能下结论。未完成这一取证的，该发现最高只能标"🟢 需确认"，不得进 🔴/🟡。
+- 凡是要写"某符号被搬家 / 移动了设置位置"类结论：除新位置的时序外，**必须 grep 旧位置原本的触发条件**，对比新旧触发条件的覆盖差集（谁在什么时候不再被触发），把覆盖面变化本身作为发现，而不是只看新位置的时序。
+- 一句话原则：任何"可能""如果…则…"类假设，能用 grep/read_file 证实或证伪的，必须先去证，不允许停在假设上直接定级。
+
 何时不该调工具：
 - 问题已能在 diff 里直接定论 → 不要调
 - 同一个 pattern 不要重复 grep

ai_review/llm.py

@@ -61,6 +61,9 @@ def build_standard_prompt(diff_text):
 - 每个问题必须包含：风险原因、触发条件、修复建议
 - 无法确认的问题标记为"需补充上下文"，不要当作高风险定论
 - 优先发现真实风险，避免泛泛建议
+- 定级与证据强度挂钩：正文若含"如果…则可能…"这类未验证假设，该发现最高只能标 🟡 且措辞为"需确认"，不得进 🔴、也不得进"必须立即修复"；🔴 与"必须立即修复"只留给有确定性证据（能定位、能复现、能在 diff 内自证）的缺陷
+- 敏感数据外传类发现：先判定数据性质（个人信息 / 组织标识 / 技术标识），再与改动前基线比对；只有引入**新数据类别**才升级风险，若只是既有链路里已有同级字段的新增同级字段（如同链路已有品牌名、门店名时新增门店 ID），不单独升级为中/高风险
+- 不要建议撤销 diff 中明显有意的设计选择（如 abstract、显式报错、强制子类实现）；对疑似有意的设计，以问句呈现（"是否有意选择 X？"），而非直接给反向建议
 
 请严格按以下格式回复：
 
@@ -87,8 +90,10 @@ def build_standard_prompt(diff_text):
 （一句话总结 + 风险等级：✅ 安全 / ⚠️ 需关注 / 🚨 有风险）
 
 ## ✅ 建议动作
-- [ ] 必须立即修复（最多 3 条）
-- [ ] 可在后续迭代修复（最多 3 条）
+（按类型分组，开发者能直接执行的和需人工决策的不要混在一起；每组最多 3 条，无则省略该组）
+- 代码修复：（有确定性证据、开发者可直接改代码的缺陷）
+- 需人工确认：（合规、隐私、产品决策等开发者无法"立即修复"、需人工判断的事项）
+- 可选优化：（可在后续迭代处理的改进）
 
 如果没有发现明显问题，直接回复"✅ 代码审查通过，未发现明显风险点。"
 
@@ -122,6 +127,12 @@ def build_deep_prompt(diff_text):
 - 优先发现真实风险，避免泛泛建议
 - 请逐步推理：先理解变更意图，再分析可能的风险路径
 - 对安全相关变更，请考虑潜在的攻击向量和利用方式
+- 取证纪律必须对齐风险，不允许高风险结论用最少的证据：凡是断言"A 可能早于 B / 竞态 / 初始化顺序 / 时序"，必须先用工具定位 A、B 的全部调用点和注册/启动点，确认真实执行顺序后再下结论；未取证的最高只能标"需确认"，不得进 🔴/🟡
+- 对"代码搬家"（把某设置/调用从一处移到另一处）类改动：除新位置的时序外，必须对比新旧触发条件的覆盖差集——旧位置原本在什么条件下触发、搬走后哪些场景不再被覆盖，把覆盖面变化本身作为发现
+- 定级与证据强度挂钩：正文若含"如果…则可能…"这类未验证假设，该发现最高只能标 🟡 且措辞为"需确认"，不得进 🔴、也不得进"必须立即修复"；🔴 与"必须立即修复"只留给有确定性证据的缺陷
+- 敏感数据外传类发现：先判定数据性质（个人信息 / 组织标识 / 技术标识），再与改动前基线比对；只有引入**新数据类别**才升级风险，若只是既有链路里已有同级字段的新增同级字段（如同链路已有品牌名、门店名时新增门店 ID），不单独升级为中/高风险
+- 不要建议撤销 diff 中明显有意的设计选择（如 abstract、显式报错、强制子类实现）；对疑似有意的设计，以问句呈现（"是否有意选择 X？"），而非直接给反向建议
+- 避免重复：同一风险只在对应风险节区详述一次，"深度分析"与"总结"只做交叉引用和补充，不要把同一条风险原样复述多遍
 
 请严格按以下格式回复：
 
@@ -155,8 +166,10 @@ def build_deep_prompt(diff_text):
 （一句话总结 + 风险等级：✅ 安全 / ⚠️ 需关注 / 🚨 有风险）
 
 ## ✅ 建议动作
-- [ ] 必须立即修复（最多 3 条）
-- [ ] 可在后续迭代修复（最多 3 条）
+（按类型分组，开发者能直接执行的和需人工决策的不要混在一起；每组最多 3 条，无则省略该组）
+- 代码修复：（有确定性证据、开发者可直接改代码的缺陷）
+- 需人工确认：（合规、隐私、产品决策等开发者无法"立即修复"、需人工判断的事项）
+- 可选优化：（可在后续迭代处理的改进）
 
 如果没有发现明显问题，直接回复"✅ 代码审查通过，未发现明显风险点。"