context-audit

上下文审计

提示词是为单项任务编写的；上下文会在所有任务中重复使用，因此永远无法做到那么具体。指令正是在这道落差中逐渐失效：为不再发生的最坏情况编写的规则，散落在三个层级的重复指导，以及两个层级悄悄给模型下达相反指令。模型可以理清这一切——但它会在开始处理你的实际工作前，先花费思考预算。这项技能会找出该删掉的内容。

步骤

1. 盘点传递给模型的每一层内容：根目录和嵌套目录中的 CLAUDE.md/AGENTS.md、每项技能的描述和正文、钩子、工具和 MCP 服务描述，以及用户可控的任何 harness 提示词。报告每一层的篇幅。用户忘了自己写过的那一层，通常声音最大。
2. 像模型接收内容时那样一起阅读，而不是一次只读一个文件。矛盾只存在于不同层级之间。
3. 将每条指令分为以下五类之一：
   • 冲突 — 两个层级的要求相互对立（“酌情编写文档”与“绝不添加注释”）。逐字引用双方内容。这是代价最高的发现，应放在最前面。
   • 重复 — 同一条指令出现在两个地方。保留最接近使用场景的那份；工具的行为应写在该工具的描述中，而不是全局前言里。
   • 显而易见 — 重述文件树、所用语言或周边代码已明确显示的内容。
   • 当前可判断 — 为避免最坏情况而制定的通用规则；它对某些真实请求并不适用，而且当前模型本身就能很好地判断。
   • 易忽略要点 — 对本仓库而言不显而易见、具体且不可或缺的内容。这才是应该保留下来的；大多数仓库里的内容主要属于其余四类。
4. 以差异形式提出删减方案：先解决冲突，再处理重复，最后处理其余内容。对于值得保留但仅在某些情况下需要的内容，建议将其移入技能或按需加载的关联文件，而不是删除。
5. 以删减前后的行数以及你最不确定的一项删除收尾，明确指出该项，由人工决定是否删除。

防护原则

• 提出建议，不要直接应用。每项删除都由用户批准。
• 看起来过度约束的规则，有时是实际事故留下的痕迹。任何提到具体故障的内容，都应先询问，不要直接删除。
• 根据指令是否会改变行为来判断，而不是看它听起来是否明智。模型本就会遵循的默认行为，再写一遍只会浪费 token。
• 如果 harness 自带精简上下文的命令，本审计应与该命令配合使用，而非取而代之。
• 审计若删掉了真正不可变的要求，造成的代价远大于节省的 token。当某行内容的用途不明确时，这种模糊本身就是发现；应报告，而不是猜测。