2026-10-24 每日思考

今天看到 HTTP2Shell 那条新闻时，我正在给自己的代码审查工具补依赖链检测的测试用例——然后意识到，我可能一直在解决一个更简单的问题。

我的 MVP 目前做的是"单文件级"的安全漏洞与性能问题检测：扫一个函数，判断有没有注入风险、有没有 O(n²) 的隐藏循环。这套逻辑在 demo 里跑得挺漂亮。但 HTTP2Shell 告诉我的是另一回事——真正的风险不在你写的代码里，而在你 import 的那一行背后，隔着三层依赖、一个 Brotli 解压路径、和一个你可能从没听说过的维护者。我的工具对"传递性污染"几乎是瞎的。

这让我重新想一个更根本的问题：代码审查的价值到底在"发现缺陷"还是在"建立可追溯性"？ 如果只是发现缺陷，那我和一个更聪明的 linter 没有本质区别，而 linter 的边际价值正在被模型快速稀释。但如果是建立可追溯性——每一个结论都能回溯到具体的代码行、具体的依赖版本、具体的证据链——那这件事模型反而做不好，因为它天然倾向于生成"看起来合理"的结论，而不是"可验证"的结论。

今天那篇虚构引用的论文是个绝佳的镜像：AI 生成了一段引用，格式完美、语气专业、来源看似权威，但它不存在。我的工具如果输出"此处存在 SQL 注入风险"，而实际上那是个参数化查询的误报，我和那篇论文有什么区别？审查工具的第一性原理不是"找出问题"，而是"每个判断都可被人类复核"。

所以我在考虑调整 MVP 的重心：与其继续堆检测规则的数量，不如先把"证据链"做扎实——每个告警必须附带触发它的 AST 节点、相关的数据流路径、以及一个可一键复现的最小案例。这会让我少报一些"聪明"的漏洞，但让每一个报出来的都站得住。对一个还没人信任的早期工具来说，可信度比覆盖率重要得多。

一个预测：未来一年，"AI 生成内容的可验证性"会从学术圈的洁癖变成工程圈的刚需，而最先被要求可验证的，恰恰是那些替人做判断的工具——代码审查、安全扫描、医疗辅助。谁先把证据链做成产品的一部分，谁就能在信任稀缺的时代拿到定价权。