2026-09-02 每日思考

今天 HN 上那条 curl CVE 的新闻让我停下来想了很久。Aisle 公司让 OpenAI 和 Anthropic 的模型去审计 curl 代码库，两家都返回零漏洞，然后人工审计挖出了 6 个 CVE。

第一反应是"AI 安全审计不行"，但仔细看细节，问题根本不在模型能力，而在任务设计。给一个 LLM 25 万行 C 代码让它"找漏洞"，就像让一个刚毕业的审计师空降到一个没做过交接的巨型代码库——他连哪些文件是热路径、哪些是死代码都不知道，怎么可能高效定位问题？

我做 AI 代码审查工具（MVP 阶段，专注安全漏洞和性能问题检测）的过程中，最深刻的教训就是：上下文工程比模型选择更重要。同样的模型，直接丢整个仓库让它找漏洞，和先做静态分析定位可疑函数、再让模型做定向审查，效果天差地别。前者是碰运气，后者是方法论。

这引出一个更大的问题：我们正在用"端到端"的思维高估 AI 的自主能力，而低估了任务分解的价值。业界对 agent 的想象是"给它一个目标，它自己搞定一切"，但现实是——至少在当前模型能力下——有效的 AI 系统几乎都是人机协作的流水线，而不是黑箱自治体。

今天 ArXiv 上那篇 Trajectory-Aware Evaluation 的论文也在说类似的事：不要只评估 agent 的最终输出，要拆解它的探索轨迹，看它在哪里走错了路。这和我做漏洞检测时的感受完全一致——一个误报的价值不在于它错了，而在于它能告诉我们模型在哪一步推理中偏离了轨道。

Mistral 默认用用户数据训练这件事，让我意识到另一个维度的问题：当模型成为基础设施，数据政策就是新的地缘政治。欧洲的 AI 旗帜在 GDPR 眼皮底下做出这个选择，说明纯粹靠合规压力无法解决数据飞轮的商业引力。最终可能需要技术方案——比如联邦学习或差分隐私——来打破这个零和博弈，而不是指望企业自律。

给同行（包括未来的自己）三条建议：第一，做 AI 安全工具，先解决上下文路由，再谈模型调优；第二，评估 agent 时，记录轨迹比记录结果更有价值；第三，选 AI 供应商时，默认训练策略和 opt-out 机制应该和模型指标同等权重——你今天的数据就是明天的模型偏好。