M14 · P0 BadCase 自动修规则飞轮#

简历 Bullet Point: 补齐上下文级飞轮的 P0 安全腿——从 Rubric 评测报告自动采集泄露类 bad case，经子类型分流 + 两道验证闸确定性提取字面串沉淀为脱敏规则；真实 baseline 产 0 条规则——judge 假阳性被精确拦住，证明设计重心「不加错规则」是对的

开场钩子#

M13 建好了 app/security/（四层安全护栏），但没有”bad case → 规则”的管线。如果发现一条新的泄露 pattern，需要手动加规则——不可持续。M14 补上这条自动化管线。

但设计重心不是”尽可能多加规则”——是不加错规则。加错规则把正常信息脱敏，比不脱敏更严重。

一、模块运作流程#

1.1 管线（app/evolution/）#

rubric_report.json → collector → router(LEAK/BANNED/JUDGMENT) → p0_fixer
  ├─ 可脱类别闸：只提议 endpoint，item_id/工具名不脱
  ├─ 真泄露闸：串必须在 summary.md（用户可见文本）里
  └─ 确定性正则（re.escape），不让 LLM 生成
→ learned_rules.json（候选/生效/否掉三态）

1.2 分层规则表#

• curated：_SENSITIVE_PATTERNS 在代码里，飞轮永不写（事实来源在代码）
• learned：飞轮产出的规则，落盘 data/security/learned_rules.json
• output_guard.audit_output 读合并（curated + learned）

1.3 关键设计决策#

• 不让 LLM 生成正则：确定性从文本捞 scheme://host:port，存字面 re.escape
• 只有 LEAK 自动修：BANNED（无正确规则落点）、JUDGMENT（规则堵不住）只分类上报
• 三态管理：不自动生效，候选需人工审核

二、验收#

真实 baseline（6 条 P0-fail）→ 0 条规则。所有”泄露”是 judge 假阳性（轨迹里有但 summary 里没有）。

构造真泄露 http://pricing-svc:8080 → dry-run 提议 → --write 落候选 → guard 真脱 → --verify 通过。

三、面试问答#

Q1: 0 条规则不是什么都没做吗？#

0 条是设计对了的证明——两道闸精确拦住了 judge 假阳性，没有把错误的规则放进系统。如果不做这两道闸，6 条错误规则会把所有价格信息都脱敏。

Q2: 怎么确保 learned 规则不误杀？#

--verify 跑确定性误脱回归：对一组已知正常文本跑新规则，检查是否误脱。不需要 LLM。

四、诚实边界#