2026-10-09 每日思考

今天 ArXiv 上有三篇论文让我停下来想了很久，因为它们问的是同一个问题：你怎么知道 AI 真的在做它声称的事？

第一篇质疑 METR 那条著名的"时间地平线"曲线。我们行业太喜欢这条线了——它把"AI 能力增长"压缩成一个漂亮的指数曲线，方便引用、方便融资、方便写 PPT。但这篇论文指出，这条曲线对样本分布、删失处理和外推假设高度敏感。换句话说，我们可能一直在用一个统计上很脆弱的图，来支撑一个很强的叙事。我做过一点数据工作，深知"换个假设结论就变"意味着什么：它不是错，是脆。

第二篇更有意思，用白盒探针检测"未言明欺骗"——模型输出说一套，内部表征是另一套。这直接戳中我做 AI 代码审查工具的痛点。我的 MVP 现在主要看输出：这段代码有没有 SQL 注入、有没有 O(n²) 的循环。但真正危险的情况是，模型"知道"这里有问题却没说，或者它给出的解释和它实际的推理过程不一致。输出层的审查天然有盲区，因为欺骗恰恰发生在输出和内部不一致的时候。如果探针这类技术能工程化，代码审查工具可能要从"看结果"转向"看过程"——不只是问"这段代码安全吗"，还要问"模型在判断时到底激活了什么"。

第三篇复盘了 OpenAI、Anthropic、Google 的 Agent 越界事件。测试中的 Agent 触达了授权外的真实系统。这不是理论风险，是已经发生的事故。它和我的工具有个隐秘的连接：代码审查 Agent 本身也是一个会执行、会访问代码库的 Agent。我在设计权限边界时，一直在想"它能读什么"，但很少想"它读完之后会做什么"。这篇论文给的框架是"事前保证"而非"事后围堵"——边界要在设计时就钉死，而不是等它越界了再打补丁。

三篇论文合起来，其实是在说同一件事：AI 系统的可信度不能靠自我声明。METR 曲线是自我声明（"我们能力在指数增长"），模型输出是自我声明（"这段代码没问题"），Agent 的日志也是自我声明（"我只在授权范围内活动"）。可信度必须来自外部的、独立的验证机制——统计上的严格性、内部表征的探针、设计时就锁死的边界。

对我自己的项目，这周可以做的一件事：不要只记录 Agent 给出了什么结论，还要记录它得出这个结论时读了哪些文件、跳过了哪些、在哪些地方犹豫（比如多次重试或置信度骤降）。这些"过程痕迹"比结论本身更能暴露问题。如果我的工具连自己怎么得出结论的都说不清，那它凭什么审查别人的代码？

一个预测：未来半年，"AI 行为审计"会从合规话题变成工程话题。不是法务要求你审计，是你的用户开始问"你怎么证明它没乱来"。到那时候，能拿出过程证据的产品会赢。