CLAUDE.md 越写越长，Agent 还是会忘：该把哪些规则变成代码？
CLAUDE.md 里第三次出现“千万不要再犯”，就该停下来想想了。
第一次数据库迁移出错，加一条规则；第二次忘了测试，再补一条；第三次乱改共享类型，把“禁止”加粗。文件越来越厚，下一次 Agent 还是可能照犯。继续改提示词很省事，但有些要求已经不该只靠它记住。
写清楚了，不等于管住了
项目背景、架构取舍、命名习惯，都值得写进 CLAUDE.md 或 AGENTS.md。模型需要这些信息才能判断。麻烦在于，我们还把重复流程和绝对不能越过的边界一起塞进去，期待同一份说明书包办所有事。
“优先使用 Server Component，确有必要再增加 Client Component”，需要结合页面判断，适合留在说明里。“页面做完检查移动端、空状态和加载状态”，可以整理成重复执行的 Skill。“不能直接 push main”，则应该尽量交给分支保护和权限控制。
这几句话都能写进 Markdown，执行方式却不能混为一谈。Skill 也仍然需要 Agent 正确调用；涉及不可接受的事故，还得在工具、权限或 CI 上检查。
举个机制上的例子：假设你希望 Agent 把能够独立运行的工具调用合并处理。写一句“尽量批量”只能提供提醒。若运行环境支持相应 Hook，就可以检测已定义好的低效调用模式，满足条件时给出反馈或拦截。不过检测条件得写准，依赖前一步结果的调用本来就该顺序执行，不能一刀切。
提醒负责告诉它理由，执行路径上的检查负责让违规动作停下来。后者也需要测试，写了 Hook 不等于自动获得可靠性。
Agent 配置也开始进仓库了
Anthropic 9 月 3 日的官方更新里，ant CLI 1.30.0 加入了 ant apply：在 Claude Managed Agents 中，可以从仓库文件创建或更新 Agent、Environment、Skill、Memory Store 和 Deployment。执行时先审批打印出来的计划，再把 claude-lock.json 提交到仓库，后续本地或 CI 运行才能更新同一组资源，避免不断新建。
这里说的是 Claude Managed Agents 的资源管理，并不意味着本地 Claude Code、Codex 的所有配置都被这个命令接管了。
我看重的是这种做法：Agent 怎么工作，也应该能够复现。项目说明、工具权限、Skills、Hooks、记忆和恢复步骤，如果只留在某个人电脑里，换台机器就得重新拼一遍。代码在仓库里，开发代码的那套配置却靠聊天记录找，很难长期维护。
软件工程里其实早就有类似做法。要求代码能编译，就让 CI 检查；要求格式一致，就让 Formatter 和 Linter 处理。没必要每天在 README 里劝大家自觉。Agent 反复出现、又能机械判断的错误，也值得这样处理。
模型升级，工作方式也要重测
模型会换版本，工具会升级，Skill 的触发和 Hook 的执行方式也可能变化。一套上个月能工作的配置，升级后还能不能照常跑，不能凭印象判断。
可以保留几个固定场景：该做安全审查时，Skill 有没有被调用；危险操作有没有被拦下；部署前要求的检查有没有留下结果。换模型或改配置后重跑一遍。测试的是 Agent 的工作流程，不只是它这次写出来的产品代码。
这听起来有点麻烦：让 AI 写代码，还要测试“AI 怎么写代码”。但如果数据库保护、部署或安全审查已经依赖这些配置，悄悄失效才更麻烦。做个一次性的页面可以从简，每天承担真实工作的流程，值得留几条回归用例。
一条“必须执行”的规则，最好能留下可核验的结果。要求跑测试，就检查这次代码对应的测试结果；限制目录，就落实到权限；要求看真实页面，就保留浏览器验证。单靠 Agent 最后说一句“都检查了”，证据还不够。
复制 Skill 很容易，复制效果没那么容易
把一套 Skill 用在 Claude、Codex 和 Gemini 上，是合理的打算。发布项目、检查页面、排查支付回调、验证迁移，这些经验没必要永久绑在某个模型上。
但同一份 SKILL.md 放进不同工具，不保证行为一样。可用工具、上下文、触发方式和默认行为都有差别。文件复制成功，只完成了第一步；同一项任务能否达到同样的验收要求，还得跑过才知道。
我更愿意一起保存任务和验收标准。以后换模型，具体执行步骤可以调整，结果要求不能顺手放宽。
记忆也一样。ant apply 把 Memory Store 纳入可声明资源，但记忆内容是否可信，仍然需要单独管理：从哪里来，适用哪个项目，什么时候过期，错误经验怎么纠正。能长期保存，不代表值得永久相信。
别把写代码变成配置收集
这套东西也很容易做过头。只是改个 Landing Page，先研究几天 Agent 架构、攒一堆 Hook，产品一行没动。提示词上瘾可以换个名字继续发生。
比较实用的办法是跟着实际错误长：先正常使用。某个错误反复出现、造成了明确成本，再决定补说明、做 Skill，还是加权限和测试。不要因为看见别人有几十个配置，就觉得自己也缺几十个。
第三次强调同一条要求时，可以先问：它能不能由程序检查？能的话，看看应该放在哪一步；属于权限，就限制权限；需要重复操作，就整理流程。那些真正依赖业务背景和取舍的部分，再留给模型判断。
这样积累下来的仓库，除了产品代码，还会记录机器如何继续开发这个项目。换电脑、换模型，或者半年后再回来，至少不用翻聊天记录找当初那句“神奇提示词”。
我不太相信能用几年的终极 Prompt。更值得留下的，是那次错误为什么发生、后来加了什么检查、现在还能不能拦住。手册可以继续写，但每重复一次同样的事故，都值得检查一下：是不是又让一句话承担了本该由程序承担的责任。
资料：Anthropic《Claude Platform release notes》，2026 年 9 月 3 日 ant CLI 1.30.0 更新。
