这两天某知名网站上有一篇文章挺火，标题很抓人：Karpathy （就是那个创造了llm-wiki的大神） 的 4 条 CLAUDE.md 规则，把 Claude 的出错率从 41% 降到 11%；作者又在 30 个代码库里测试了 6 周，继续补了 8 条规则，最后把错误率压到 3%。
这个数字很吸引人，先不看这个它的真实与否，真正值得看的也不是“3%”这个数字本身，而是它把很多 Claude Code 和 Hermes 用户都会遇到的问题讲透了。
很多人刚开始用 Claude Code 或 Hermes 写代码时，最关心的是它能不能写出来。用一段时间后，真正烦人的问题会慢慢出现：它不是不会写，而是经常写得像完成了，实际却在某些地方悄悄跑偏。
比如你让它修一个小问题，它顺手改了旁边几个文件；你让它补测试，它确实补了，但测试没有覆盖真正的业务逻辑；你让它跑迁移，它说完成了，过几天才发现有一部分数据被跳过；你让它遵守项目风格，它看到两种旧写法，最后混出第三种更奇怪的写法。
这些问题比直接报错更麻烦。报错至少会告诉你哪里坏了，假完成会让你以为事情已经结束，直到后面更难收拾的时候才暴露。
这篇文章的价值就在这里。它不是再教你写一段更花哨的提示词，而是在讨论一件更底层的事：如果你经常让 AI Agent 进项目、改代码、跑命令、做多步任务，就不能只给它任务，还要给它工作纪律。
CLAUDE.md 到底有什么用？
CLAUDE.md 可以理解成 Claude Code 进入项目后会看的项目规则文件。它不是让你每次都在聊天框里重复“请谨慎一点”“请不要乱改”，而是把一些长期有效的协作规则写下来，让 Claude 每次处理这个项目时都有基本约束。
Hermes 用户也可以用同样思路。文件名不一定叫 CLAUDE.md，你可以把这些规则放进项目规则、Skill 说明，或者常用的代码任务约束里。关键不是文件名，而是让 Agent 在动手之前先看到这些规矩。
原文提到，Karpathy 当时吐槽过 Claude 写代码的几个典型问题：默默做错误假设，把简单问题搞复杂，顺手破坏不该碰的代码。后来 Forrest Chang 把这些问题整理成 4 条规则，放进一个 CLAUDE.md 文件，项目迅速走红。作者后面在真实代码库里继续测试，认为这 4 条规则能解决早期常见问题，但现在 Claude Code 的使用已经变成多步骤 Agent 工作流，问题也变多了，所以他又补了 8 条。
这条脉络很有意思。它说明项目规则不是装饰，也不是“写给 AI 看看的礼貌提示”。好的规则应该来自真实错误，每一条都对应一个具体失败模式。
最基础的 4 条，解决的是“别乱写”
最早那 4 条规则，其实都很朴素。
第一，写之前先想清楚。需求有歧义时，不要默认猜一个答案就开工，要把假设说出来，必要时先问。
第二，简单优先。能用最小改动解决的问题，不要为了显得高级去加抽象、加框架、加未来可能用到的扩展。
第三，只做必要修改。你让它修一个问题，它就修那个问题，不要顺手美化旁边代码，不要重排无关格式，不要改没坏的地方。
第四，按目标执行。不要只机械执行步骤，要知道成功标准是什么，做完后要能验证。
这 4 条对新手已经很有帮助。很多 AI 写代码的翻车，根本不是技术能力不够，而是边界没守住。它不是改不了，而是改太多；不是不会想，而是默默替你做假设；不是不会测试，而是没把“什么算完成”讲明白。
如果你只想给 Claude Code 或 Hermes 加一份最短规则，这 4 条就可以作为底线。
为什么还需要后面 8 条？
原文更有价值的部分，是它指出现在的问题已经不只发生在“写代码”那一刻。
早期你可能只是让 AI 改一个函数、补一段逻辑。现在 Claude Code、Hermes 这类工具会读文件、跑命令、调用工具、写测试、多轮推进，甚至参与长任务和跨文件重构。任务形态变了，风险也跟着变了。
原来的 4 条规则，主要防止 AI 在局部写代码时乱猜、乱加、乱改。但长任务里还会出现别的问题：上下文越来越长，Agent 开始绕圈；某一步错了，它继续在错误基础上往下做；项目里存在两套冲突风格，它试图折中；测试虽然通过，但其实没有测到真实意图；迁移或脚本跳过了异常数据，却用一句“完成”带过去。
这些问题都需要更具体的约束。
最值得抄的几条
我个人不建议所有人无脑复制完整 12 条。规则越多，越容易变成噪音。更好的做法是先看自己最常遇到什么问题，再把对应规则加进去。
如果你的 Agent 总是把简单逻辑做复杂，就加“简单优先”。如果它总是顺手改旁边文件，就加“只做必要修改”。如果它总是写测试但测不到重点，就加“测试必须验证业务意图”。规则要服务于真实问题，不要为了显得专业把所有东西都塞进去。
原文补充的 8 条里，有几条尤其值得 Claude 和 Hermes 用户借鉴。
第一条是：确定性的事不要交给模型判断。
这条很容易被忽略。现在很多人会把一切都交给 AI，连“收到 503 要不要重试”“状态码怎么处理”“这个字段怎么路由”这类明确规则，也让模型来判断。短期看能跑，长期就会变得不稳定。状态码、重试、路由、固定格式转换，这些更适合用确定性代码。模型更适合处理分类、总结、解释、从非结构化文本里提取信息这类任务。
第二条是：长任务要有预算。
Agent 很容易在一个问题上绕很久。尤其是调试任务，跑一次命令，看到一个错误，改一下，再跑，再看到另一个错误，继续改。这个循环如果没有预算，很容易把上下文拖得很长，最后模型开始忘记前面试过什么。更好的做法是，到一定长度就停下来总结当前状态：已经试过什么，哪些方向排除了，剩下什么问题，下一步怎么做。Claude Code 用户可以结合 /compact 和 /clear，Hermes 用户也可以在长任务里要求阶段性总结。
第三条是：遇到冲突不要平均。
很多代码库都有历史包袱。一个模块一种写法，另一个模块另一种写法。AI 最容易犯的错，是试图讨好两边，最后写出一个混合版本。比如一边用显式 try/catch，一边用全局错误边界，它可能两个都用，结果错误被处理两次。正确做法应该是选一种更近、更稳定、更有测试覆盖的模式，并说明理由；另一种冲突模式可以标出来，留给后续清理。
第四条是：写之前先读。
很多 AI 写错，不是因为不会写，而是没读够。它在文件里加了一个新函数，却没有发现同一个文件里已经有类似函数；它新增了工具方法，却没有看调用方和共享工具。结果项目里出现重复逻辑，甚至因为导入顺序影响原有行为。这个规则很简单：改文件之前，先读当前文件、直接调用方和相关共享工具。看清楚已有结构，再动手。
第五条是：测试要验证意图。
“测试通过”听起来很安全，但这句话有时会骗人。AI 可能写出一堆很浅的测试，只证明函数返回了某个东西，没有证明它符合业务要求。比如认证函数返回了一个用户对象，测试只检查“返回不为空”，但没有检查权限、过期、错误输入和边界条件。这样的测试通过了，也不能说明功能真的对。以后让 AI 补测试时，不要只说“补测试”，要问它：这个测试验证了什么业务意图？如果业务逻辑错了，这个测试会不会失败？
第六条是：长任务要有检查点。
多步骤任务最怕中间一步错了还继续往下做。比如 6 步重构，第 4 步已经方向不对，AI 还继续做第 5、6 步，最后你要回滚的就不是一步，而是一串。更稳的方式是每完成一个重要阶段，都让它说明做了什么、验证了什么、还剩什么。如果它自己也说不清当前状态，就应该先停下来整理，而不是继续往前冲。
第七条是：项目约定优先于模型品味。
AI 经常会写出看起来更现代的代码，但已有项目不一定需要“更现代”，更需要一致。如果项目一直用 class component，它突然引入 hooks；如果项目一直用 snake_case，它突然改成 camelCase；如果项目已有固定错误处理方式，它又加一套自己的处理方式，后面维护会很痛苦。项目里的局部新风格，往往比旧风格本身更糟。
第八条是：失败要说出来。
这是我觉得最值得放进所有规则的一条。AI 最贵的失败不是报错，而是看起来像成功。迁移跳过了一部分数据，却说完成；测试有一部分没跑，却说通过；边界情况没验证，却说功能可用。以后一定要明确要求：不确定就说不确定，跳过了就说跳过了，没有验证就不能说完成。
规则别写成愿望清单
这篇文章还提到一个很重要的点：规则不是越多越好。作者测试过更多规则，超过一定数量后，遵守率会明显下降。他还发现，“小心点”“认真思考”“专注”这类话基本没用，因为它们不可检查；“像高级工程师一样工作”也没什么用，因为模型本来就会表现得像自己很懂，真正缺的是具体行为约束。
这对很多人很有提醒意义。
很多项目规则写着写着，就变成了愿望清单：
请认真。
请谨慎。
请高质量。
请全面思考。
请像专家一样。
这些话看起来对，但约束力很弱。真正有效的规则要能回答一个问题：它防止哪一种具体错误？
“只改必要文件”防止范围失控。“写之前先读调用方”防止重复造轮子。“测试要验证业务意图”防止假测试。“长任务要有检查点”防止跑偏。“失败要说出来”防止假完成。
这种规则才值得留下。
给 Claude 和 Hermes 用户的中文简化版
下面这份我做了压缩，尽量保持可执行。Claude Code 用户可以放进项目根目录的 CLAUDE.md。Hermes 用户可以放进项目规则、Skill 说明，或者作为代码任务的长期约束。你不需要全用，可以先挑最适合自己项目的几条。
# AI 代码协作规则这些规则适用于本项目的代码修改、排错、测试和重构任务。## 1. 写代码前先说明假设如果需求不清楚，先列出你的理解和不确定点。不要默默猜测。明显有歧义时，先问我。## 2. 简单优先只写解决当前问题需要的最小代码。不要添加未要求的功能，不要为了未来可能用到而提前抽象。## 3. 只改必须改的地方不要顺手优化相邻代码、注释、格式或目录结构。不要重构没坏的部分。保持项目现有风格。## 4. 按完成标准推进开始前先明确成功标准。完成后必须说明如何验证。不能只说“应该可以”。## 5. 确定性逻辑用代码处理模型适合分类、总结、解释和判断。状态码处理、重试策略、路由、固定格式转换，优先用确定性代码。## 6. 控制上下文和 token如果任务变长，先总结当前状态，再继续。不要在同一个会话里无限循环。接近预算时，要主动提醒并建议新会话或压缩上下文。## 7. 遇到冲突不要混合如果项目里存在两种冲突写法，不要折中拼接。选择更近、更稳定、更有测试覆盖的一种，并说明理由。## 8. 写之前先读修改文件前，先读当前文件、直接调用方和相关共享工具。如果已有工具能复用，不要新造一套。## 9. 测试要验证真实意图测试不能只验证“有返回”。要验证业务逻辑、边界情况和错误路径。如果测试不能在逻辑出错时失败，它就是无效测试。## 10. 长任务要有检查点每完成一个重要步骤，说明做了什么、验证了什么、还剩什么。如果你自己说不清当前状态，就先停下来整理。## 11. 项目约定优先于个人偏好命名、组件写法、目录结构、错误处理方式，优先匹配项目现有习惯。如果你认为现有约定有问题，先提出来，不要偷偷引入新风格。## 12. 失败要说出来不确定就写不确定。跳过了任何文件、记录、测试或边界情况，都必须说明。没有验证的内容，不能说完成。如果你觉得 12 条太多，可以先保留 6 条：只改必须改的地方、写之前先读、测试验证真实意图、长任务检查点、项目约定优先、失败要说出来。它们覆盖了最容易让人付出代价的几类错误。
怎么用到自己的项目里？
Claude Code 用户最简单，直接在项目根目录创建或更新 CLAUDE.md。不要把这个文件写得太长。官方和很多实践经验都指向同一个问题：规则太长以后，模型并不会认真执行每一句，反而容易只知道“这里有很多规则”，但抓不住重点。
Hermes 用户可以把这套规则转成项目约束。如果你有固定项目，可以放进 AGENTS.md、项目说明、Skill 规则，或者你平时让 Hermes 进入项目时会读取的文件。做代码任务前，也可以把其中最相关的几条贴进去。
关键是不要把规则当摆设。每次 Agent 犯错后，都可以回头问一句：这个错误能不能变成一条更具体的规则？
如果它乱改范围，就加强“只改必要部分”。如果它测试写得浅，就加强“测试验证意图”。如果它长任务跑偏，就加检查点。如果它假装完成，就要求失败必须显式说明。
这样规则才会越用越贴合你的项目，而不是从网上复制一份就放在那里吃灰。
最后
Claude Code 和 Hermes 这类 Agent 工具，真正厉害的地方是能连续做事。它们可以读文件、改代码、跑命令、看测试结果，再继续修正。可越能连续做事，越需要边界和纪律。
这篇热文最值得借鉴的，不是那份 12 条规则原封不动复制过去，而是它背后的方法：先观察 AI 在你项目里真实犯过什么错，再把这些错误改写成明确、可执行、可检查的项目规则。
AI 写代码越来越快，但快不等于省心。
真正省时间的，是让它少跑偏，少假完成，少把小问题改成大问题。
热门跟贴