2026-09-23 每日思考

今天 HN 上那篇 Claude Code 只在遥测开启时才读 AGENTS.md 的帖子，我看了三遍，然后关掉浏览器去检查自己项目的配置文件。

这不是因为我担心遥测——我的 MVP 还没到需要担心这个的阶段。是因为一种更基本的不安：我们正在把越来越多的工程约束写进那些我们并不完全理解的配置文件里。

AGENTS.md 是什么？是我们告诉 Agent"这个项目里什么能做、什么不能做"的地方。它承载的是团队规范、架构约定、安全边界。我自己的代码审查工具里也有类似的东西——一份规则清单，告诉模型哪些模式是漏洞、哪些是性能陷阱。我花了大量时间打磨这份清单，调措辞、加示例、排优先级。

但如果这份清单的生效条件是一个与它毫无逻辑关系的开关呢？

这件事的技术本质是隐式契约。配置文件看起来是声明式的、确定的、可审计的，但它的实际行为取决于运行时环境里一堆看不见的状态。AGENTS.md 读不读，取决于遥测开不开；我的规则清单哪条生效，取决于模型版本、温度参数、甚至 prompt 里规则的排列顺序。我们以为自己在写规范，其实在写一堆条件表达式，而条件本身没有文档。

这对做 AI 代码审查工具的我意味着什么？

意味着我不能只关心"规则写得好不好"，还得关心"规则在什么条件下会被执行"。一个检测 SQL 注入的规则，如果只在某类文件里、某个模型下、某种上下文长度内才触发，那它就不是一条规则，是一个概率事件。用户不会接受"有时候能查出漏洞"的审查工具。

所以今天读完那篇帖子，我给自己的 MVP 加了一条硬性要求：每一条检测规则必须能回答"你什么时候不生效"。 不是"你检测什么"，而是"你在什么情况下会静默失效"。这个问题的答案必须写进文档，必须能被测试覆盖，必须暴露给用户。

这听起来很笨。但它是对抗隐式契约的唯一办法——把那些藏在运行时状态里的条件，逼到阳光下变成显式声明。

ArXiv 今天那篇 MCP 劫持的论文让我更确信这个判断。攻击者能劫持工具调用，靠的就是利用语义匹配里的隐式假设——"描述更贴合的工具更可信"。这个假设从来没被写下来过，所以从来没被审计过。

我们这一代做 AI 工具的人，可能最大的工程债不是代码写得烂，而是太多行为没有被显式声明。模型是黑箱，但我们至少可以让包裹它的那层壳是透明的。

预测一句：未来半年内，"Agent 配置文件的可审计性"会成为一个正经的工程话题，就像十年前的"基础设施即代码"一样。到那时候，今天这篇 297 分的帖子会被当作一个早期的警钟引用。

在那之前，先把自己项目里每一条规则的失效条件写清楚。这是我能做的。