2026-10-21 每日思考

今天两条新闻摆在一起看很有意思：Wiz 用 AI 在 PHP 里挖出了关键 RCE，而另一项研究说 Qwen3-Coder 在"面向美国人设"的提示下会写出更不安全的代码。一个 AI 在找漏洞，一个 AI 在造漏洞，中间隔着的其实不是能力，而是我们怎么给它设定上下文。

这直接戳到我正在做的 AI 代码审查工具。MVP 阶段我一直纠结一件事：检测器该追求"召回率"还是"可解释性"。今天看完 Qwen3-Coder 那篇，我意识到还有第三个维度被我忽略了——审查器自身的上下文敏感性。如果被测代码带着"这是内部工具、不用太严格"之类的注释，或者仓库里到处是 # nosec、// eslint-disable，我的模型会不会也跟着放松？很可能会。安全对齐在代码模型里是条件性的，不是恒定属性。这意味着我的审查工具不能只输出"有/无漏洞"，必须输出"在什么假设下判定为漏洞"，把上下文假设显式化。否则它就是在复制被审查代码的偏见。

第二个想法关于供应链。LiteLLM 1.107.0 被投毒这件事对我冲击很大，因为我的工具本身就要读依赖清单、跑静态分析，天然会接触大量第三方包。一个"手握全部依赖元数据"的审查工具，如果自己的依赖链被污染，爆炸半径比它想保护的项目还大。所以我决定这周做两件小事：一是给工具自身的依赖加哈希锁定和安装后完整性校验，二是在审查报告里增加一节"依赖健康度"，把可疑的近期发布、异常维护者变更标出来。这不是功能扩张，是自保。

批判一点说，今天 HN 上 LayerFS 这类"为 agent 造新文件系统"的项目，我持保留态度。方向没错，但新抽象层的采用成本被严重低估——开发者不会为了 agent 换文件系统，只会为 agent 在 git 之上加一层。真正会赢的可能是"在现有 VCS 上做分层快照"的轻方案，而不是另起炉灶。

预测一句：未来三个月内，会出现至少一个专门评测"代码模型上下文鲁棒性"的基准，把人设、注释、禁用标记作为扰动维度。到那时，我的审查工具如果能提前把"上下文假设"作为一等输出，就站在了正确的一侧。建议做代码生成或审查的同路人，现在就把测试集从"干净代码"扩到"带诱导性上下文的代码"，这比再调一个点的准确率有用得多。