精简智能体规则文件的实用检查清单
文章建议先统计指令文件的 token 成本，再清理重复规则、解决相互冲突的要求，并保留统一的规则来源。必须执行的约束应交给 hooks、lint 和 CI，而非仅依赖 Markdown 指令。
AI 深度解读
AGENTS.md 越写越长，未必能让 AI 编程助手更守规矩。作者给出了一份按顺序执行的 10 项清理清单，目标是减少每轮常驻的指令，让模型更容易找到真正需要遵守的要求。
这份清单最有用的地方，是把规则放在哪里、由谁执行分开考虑：项目通用约定留在根文件，局部要求跟着目录走，低频流程按需加载，不能出错的限制交给工具。它没有给出效果对照实验，适合当作一次仓库维护指南来读。
删规则之前，先查重复和冲突
作者建议先测量，再动刀。把 AGENTS.md、CLAUDE.md 和 Cursor rules 一起检查，记录 token 成本，并找出重复或矛盾的指令。只想统计单个文件时，使用单文件 token 计数器即可。
这里的 token 成本，是这些文字占用的模型输入量；原文没有把它换算成具体费用。
清理时，先处理互相打架的要求。例如，一个文件要求「始终执行 X」，另一个文件却要求「禁止执行 X」。作者认为，这会让模型犹豫。相比把每句话压短几个字，先决定究竟遵守哪一条更有价值。
重复的 Always/Never 列表也应合并，只保留一个权威版本，其他位置删除副本或改成一行指引。跨工具维护时，作者倾向于让 AGENTS.md 成为唯一事实来源，CLAUDE.md 和 Cursor 配置只保留必要的适配内容，同时避免产生分叉副本或导致重复计入的符号链接。
清理的第一目标，是消除歧义和重复，再缩短文字。
根文件只放每轮都需要的要求
作者接下来的几项检查，都围绕一个问题：这条规则有必要一直出现吗？
如果要求只适用于 src/api/**，就使用按路径生效的 Cursor rule，或者放进对应目录下的 AGENTS.md / CLAUDE.md。大白话理解，就是让助手处理相关目录时，再接触那部分约定。
原文提到 Cursor 的约约 500 行规则限制和四种规则类型，但没有展开具体类型，也没有交代限制的适用版本。这个数字可以作为检查线索，不能直接当作所有工具的统一上限。
发布清单、迁移步骤、每月才执行一次的工作流，则适合移入按需调用的 skills 或文档。它们可能很重要，但重要不等于每轮都要加载。根文件仍然过长时，作者建议按职责拆分成局部规则和 skills，不要继续把所有内容挤在一个文件里。
目录树和长篇技术栈清单也是删除候选。作者的理由是，助手可以读取仓库自行发现这些信息，没必要让静态清单反复占用输入。
不能违反的限制，要交给工具执行
这篇清单最值得保留的判断，是 Markdown 指令的作用边界。
写下「禁止」不会自动产生强制约束。
作者把这类文件定位为提供建议和上下文的材料。如果某条要求违反一次就会造成损失，应使用 hooks、权限、linter 或 CI 来落实。formatter、typechecker 等工具已经能检查的要求，也应审视是否还需要在常驻文件里重复描述。
最后要重新测量清理后的整组文件，确认 token 数下降，并检查是否引入了新冲突。作者认为，多数仓库做一轮就够，但没有提供样本或统计依据。
文末推荐了他们开发的 Clogmeter：据原文描述，它可在浏览器内统计 token，识别完全重复、近似重复以及 Always/Never 冲突，提供删减建议并导出精简副本，内容不会上传。这些是作者对工具能力的说明，文中没有展示验证过程。
我的判断
我赞成按适用范围和使用频率安排指令，也赞成让自动化检查承担硬性要求。相比不断追加「务必遵守」，这两项做法更容易维护，也能让团队明确知道规则由谁执行。
但「更短就更容易遵守」在这篇文章里仍是经验判断。作者没有提供清理前后的任务成功率、违规次数或不同模型的对照数据，token 下降只能证明输入变少，不能单独证明结果变好。
删减也有前提。工具能检查出错误，不代表它能解释团队为什么这样设计；助手能读取仓库，也不代表它能轻易发现隐藏约束。因此，应该删的是机械重复和过期信息，关键设计理由、容易踩坑的例外仍可能值得保留。多工具共用一个来源也需要确认各自的加载方式，原文没有给出具体配置。