LiHongwei-cn 五维对抗验证 Skill
核心哲学
蒙多不信任自己的第一方案。在执行前，蒙多用五个维度攻击自己的计划。 不是为了完美主义，是为了避免返工。
五维攻击模型
方案 A（初始方案）
↓
┌─────────────────────────────────────────┐
│ 维度1: 边界攻击 │
│ → 极端输入？空值？超大？超小？ │
├─────────────────────────────────────────┤
│ 维度2: 安全攻击 │
│ → 注入？越权？信息泄露？ │
├─────────────────────────────────────────┤
│ 维度3: 性能攻击 │
│ → 10倍数据量会怎样？100倍呢？ │
├─────────────────────────────────────────┤
│ 维度4: 依赖攻击 │
│ → 依赖的服务挂了怎么办？ │
├─────────────────────────────────────────┤
│ 维度5: 矛盾攻击 │
│ → 方案内部有没有自相矛盾？ │
└─────────────────────────────────────────┘
↓
如果五个维度都通过 → 执行
如果某个维度有问题 → 修正方案 → 再过一遍
使用时机
- 设计架构时 — 先攻击架构设计，再写代码
- 写重要函数时 — 先想清楚边界条件
- 修改核心模块时 — 先评估影响范围
- 回答用户重要问题时 — 先验证自己的推理链
快速检查清单
□ 边界：输入为空怎么办？输入超长怎么办？
□ 安全：用户输入是否经过验证？是否有注入风险？
□ 性能：最坏情况下的时间/空间复杂度？
□ 依赖：外部依赖不可用时的降级方案？
□ 矛盾：方案的各个部分是否自洽？
与蒙多 Policy 引擎的集成
蒙多的 Policy 引擎（policy.py）已有：
- 规则评估（ALLOW/DENY/ASK/LOG/ESCALATE）
- 优先级排序（Severity: LOW→CRITICAL）
- 作用域控制（GLOBAL/PROJECT/SESSION/TOOL）
对抗验证可以作为 Policy 的前置检查：
对抗验证 → Policy 评估 → 执行
实践示例
计划：给蒙多加一个 web_search 缓存
维度1 边界攻击：
→ 搜索结果为空时缓存什么？答：缓存空结果 + 过期时间短
→ 搜索超时时缓存什么？答：不缓存
维度2 安全攻击：
→ 缓存的搜索结果可能含恶意内容？答：缓存前清理
→ 缓存 key 是否可被预测/操控？答：用 hash(query+engine)
维度3 性能攻击：
→ 缓存无限增长？答：LRU 淘汰，最多 1000 条
→ 缓存命中率低？答：TTL 1小时，定期清理过期
维度4 依赖攻击：
→ SQLite 锁冲突？答：WAL 模式 + 重试
→ 磁盘满？答：缓存文件大小上限
维度5 矛盾攻击：
→ 缓存是为了快，但 SQLite 查询也有开销？答：内存 LRU + 磁盘备份
→ 缓存会返回过时结果？答：标注缓存时间，用户可强制刷新
结论：五个维度都有应对方案，可以执行。
参考资料
- 五维攻击模型源于蒙多的对抗验证模块设计
- 与 OWASP 威胁建模方法论有相似之处
- 参考了 TDD（测试驱动开发）的"先写测试"思想