为什么这项测试至关重要

AI 驱动的代码助手通常允许团队在仓库中放入一个“规则”文件，并期望模型在每次请求时都遵守其中的指令。在实践中，模型可能根本看不到该文件，或者看到了但忽略了其中的内容。最近针对 Claude Code 的一项实验表明了这两个问题。该工具静默跳过了 72 KB 的 AGENTS.md 文件；当同一个文件被重命名为 CLAUDE.md 时，助手加载了它，并增加了每次请求的 token 计数。额外的 token 开销会增加延迟和成本，并可能导致请求超出模型的限制。

那些认为“文件存在”就等于“模型遵循规则”的开发者，面临着隐藏的低效和不可预测输出的风险。这项三步测试强制要求在每个阶段提供具体证据：配置、加载和实用性。

需要询问的三个问题

  1. 已配置 (Configured) – 文件是否放置在助手查找的位置？不同的工具会硬编码路径或文件名约定；如果不匹配，文件就永远不会进入提示词流水线 (prompt pipeline)。
  2. 已加载 (Loaded) – 助手是否提供了已接收文件的任何证明？哈希值可以确认磁盘上文件的身份，但只有交付追踪（例如日志行或 token 计数）才能证明模型确实观察到了它。
  3. 有用 (Useful) – 文件的存在是否改善了任务结果？如果加载的文件增加了 token 却未改变结果，那将是净损失。

执行测试

该流程刻意保持极简，以便可以在任何平台上重复进行。

  1. 创建一个可见的规则 – 编写一个简单、可观察的指令。例如：“在编辑之前恰好列出两个文件。”可以通过助手的响应来检查规则的效果。

  2. 检查工具版本和模型 – 开启一个新会话，记录版本字符串和模型标识符。不同的版本可能会改变它们识别的文件名。

  3. 执行两次运行 运行 A：使用工具无法识别的文件名（例如 AGENTS.md）。 运行 B：使用工具的原生文件名（例如 CLAUDE.md）。

    记录：

    • 文件的源哈希值（以证明磁盘内容未发生变化）。
    • 使用的确切路径。
    • 助手记录的关于加载文件的任何证据（token 计数增加、明确的“loaded X.md”消息等）。
    • 每次请求的 token 计数。
    • 任务结果（助手是否恰好列出了两个文件？）。

如果运行 B 显示规则被遵守且 token 计数按预期增加，则说明文件既已加载且有用。如果尽管 token 计数增加了但规则仍被忽略，则说明文件正在被读取，但模型的提示词解析丢弃了指令。在这种情况下，向文件中添加更多文本没有帮助；应将规则移至硬编码的策略门控 (policy gate) 或测试套件 (test harness) 中。

数据揭示了什么

Claude Code 的案例展示了配置与加载之间的巨大鸿沟。那个 72 KB 的文件确实存在，具有正确的哈希值，并且已同步到仓库，但助手从未引用过它。将文件重命名为原生的 CLAUDE.md 触发了加载，但也增加了大量的 token 开销。每个额外的 token 都会消耗计算周期，并可能导致请求超出速率限制。

这项三步测试可以在这些隐藏成本成为生产阻碍之前将其暴露出来。通过捕获 token 增量 (delta)，团队可以决定规则带来的收益是否超过其成本。

总结

永远不要仅仅因为规则文件存在于仓库中就假设它正在发挥作用。使用三步测试——配置、加载、证明有用性——将这种假设转化为可衡量的证据。当证据表明文件仅仅是一个 token 消耗器 (token sink) 时，请将逻辑从提示词中移出，转而放入确定性的门控中。其结果将是更精简、更快速且更可预测的 AI 编码工作流。