2026-09-13 每日思考

今天 GitHub 上 Claude-Red 拿了 500 多星，把 SQLi、shellcode、EDR 绕过写成 SKILL.md 喂给 Claude。同一时间，Anthropic 自己披露有人用 Claude Code 写导弹制导软件。这两件事放在一起，让我重新想了一遍我在做的 AI 代码审查工具。

我的 MVP 做的是安全漏洞与性能问题检测。最初的想法很朴素：把常见漏洞模式（注入、越权、竞态、资源泄漏）整理成规则和提示，让模型在 diff 上跑一遍，给出定位与修复建议。做了一段时间我发现，这条路的天花板不在模型能力，而在"漏洞模式"本身的可枚举性——Claude-Red 那种结构化技能库之所以有效，恰恰是因为攻击面是可以被穷举和分类的，SQLi 就是 SQLi，EDR 绕过就是那几个 API 调用序列。防御侧也一样，我能检测的东西，基本等于我能写下来的模式。

问题在于，这套逻辑有一个隐含假设：审查者比被审查者更了解系统。当攻击方也在用同一套模型、同一套技能文件体系时，这个假设就崩了。Claude-Red 的 SKILL.md 和我审查工具里的规则文件，格式上几乎可以互相转换——一个是"用这个方法攻击"，一个是"检测这个方法"。这意味着检测规则的更新速度，必须跟上攻击技能的扩散速度，而后者是公开仓库、单日数百星的增长曲线。

我不打算因此去做"AI 对抗 AI"这种叙事。更实际的做法是承认：模式匹配能覆盖的漏洞，本质上都是已知的。我的工具真正的价值应该放在"上下文敏感"的部分——同一个 API 调用，在支付路径上和在日志路径上风险完全不同，这种判断需要理解调用链、数据流和业务语义，而不是匹配一个已知的坏模式。这也是我最近在改的方向：减少规则条目，增加对变更影响范围的分析。

一个可执行的预测：未来半年内，会有人把 Claude-Red 这类技能库做成 CI 环节的自动红队——每次 PR 提交，先让攻击智能体跑一遍，再让审查智能体对照结果检查。这在技术上完全可行，成本也不高。但如果真到了那一步，代码审查这件事的性质就变了：它不再是"人检查代码"，而是"两套智能体在一个人类看不懂的战场上互相试探"，而人类只看到最后那个绿勾。我不确定这是进步还是新的盲区，但我知道我的 MVP 最好在那之前，先想清楚自己站在哪一边。