LinkedIn 上有人说，一个 Markdown 文件在 GitHub 上爆火。
听起来太像营销了。
就是那种截一张 star 数截图，然后硬说“开发方式被彻底改变了”的内容。
点进 repo 看了一眼。
然后有点愣住了。
91,000 个 star。 没有依赖。 没有构建步骤。 没有模型。 甚至没有什么复杂工具链。
只有一个叫CLAUDE.md的文件。
里面写了四条行为规则。
更离谱的是，这四条规则并不新。它们不是某种神秘提示词，也不是高级 agent 架构，而是每个资深工程师第一天带新人时都会讲的基本原则。
可就是这么一个文件，成了 GitHub 当前排名第一的 trending repo，而且增长曲线还没停下来。
所以我认真看了一会儿。
这件事真正有意思的地方，不是文件本身。
而是它为什么会火。
这个文件到底是什么？
Forrest Chang 把 Andrej Karpathy 关于 LLM 写代码常见失败方式的四条观察，整理成了一个CLAUDE.md文件。
Claude Code 每次启动会读取它。
这就是整个“产品”。
文件放在项目根目录。 Claude Code 会自动识别。 同一个 repo 里的每个开发者，都会得到同一套行为约束。
零配置。 零维护。 零 API 调用。
听起来是不是很朴素？
但它偏偏击中了问题。
那四条规则是什么？
我简单转述一下，因为原则本身很短，具体措辞反而不是重点。
第一，写代码之前先思考。
先说清楚假设。需求不明确，就问。存在更简单方案，就指出来。发现自己不确定时，不要硬选一个方向往下冲，而是停下来，把不清楚的地方说出来。
第二，优先简单。
只写解决问题所需的最小代码。不要提前抽象。不要设计没人要求的灵活性。判断标准很直接：资深工程师看了，会不会觉得这东西过度设计？
第三，手术式修改。
任务需要改哪里，就只改哪里。不要顺手优化旁边的代码。不要重构没有坏掉的东西。每一行改动，都应该能追溯到用户的原始请求。
第四，目标驱动执行。
在写第一行代码之前，把模糊指令变成可以验证的目标。
比如“加一下校验”，就应该被拆成：“先为非法输入写测试，然后让测试通过。”
就这些。
这就是那个文件。
为什么这事没有看起来那么简单？
第一次读这些规则时，心里其实有点不屑。
这不就是正常工程纪律吗？
为什么还需要专门写进文件里？
然后我想了想自己过去一周用 coding agent 的经历。
我让一个 agent 给 Polars 数据管道加一个很小的缓存层。
结果它改了函数签名，引入了我根本没要求的依赖注入模式，还把缓存包成了一个类，里面暴露了八个我永远不会调用的方法。
真正的缓存逻辑，只有三行。
我又让另一个 agent 修一个日期解析 bug。
它确实修了。
但它还顺手格式化了整个文件，把两个完全无关的函数从列表推导式改成了循环，还非常“贴心”地给另一个模块里的函数加了类型标注。
这不是罕见翻车。
这是默认行为。
只要你真的把 coding agent 用在实际工作里，你几乎一定见过类似场景：它做对了一部分，但顺手制造了一堆你没要的变化。最后你还得安静地帮它收拾残局。
这四条规则，对资深工程师来说当然明显。
但对模型来说，不明显。
这就是CLAUDE.md正在填补的空隙。
自己最近弄了个 AI API 中转站，先开放 50 个内测名额。
注册地址：
https://api.aidazhi.com/
注册后把用户名发我，手动送 10 美元测试额度。目前是 0.2 倍率，可以调用很多次。每人限领一次，先到先得。
先别神化它
到这里，LinkedIn 上那些兴奋帖子通常就结束了。
但真正的问题，其实才刚开始。
这个文件是行为上下文，不是强制合约。
Claude Code 会读取CLAUDE.md，并把它当作指令参考。
但它不保证每次都严格遵守。
它改善的是行为分布，而不是给你一个确定性承诺。
Reddit 上有人指出这一点，他们是对的。网上流传的那些“准确率从 65% 提升到 94%”之类数字，来自某篇博客文章。说实话，我不会把项目 deadline 赌在这种数字上。
而且，这些原则也不是 Claude 专属。
它们描述的是任何 coding agent 都应该遵守的行为方式。
同一份内容，换个文件名，也可以作为 Cursor rule 使用。这个 repo 里也提供了对应版本。
所以，有意思的不是具体工具。
有意思的是这套原则。
还要说清楚一点：Karpathy 并没有亲自写这个文件。
他提出了观察。 Forrest Chang 把这些观察整理成 repo。 Karpathy 后来在自己的渠道放大了它，也没有要求把自己的名字从标题里拿掉。
所以，这个 repo 的爆火，既有原则本身的价值，也有名字带来的传播红利。
两件事都是真的。
另外，这个 repo 更像菜单，不是模板。
四条规则可以作为基线，但它不能替代你项目里的具体约定，比如命名规范、框架选择、测试策略、目录结构、发布流程。
正确做法不是把原来的CLAUDE.md全删掉。
而是把这几条放进已有文件里的 “Behavioral Guidelines” 部分。
最后
现在 agent 工具生态里，很多精力都在堆更多层：
skills。 plugins。 fine-tuning。 system prompts。 各种复杂编排。
但这个东西，只有几十行普通英文，放在 repo 根目录里。
它之所以赢，不是因为它又加了一层。
而是因为它像一份契约。
它告诉 coding agent：你不要急着表现，你先像一个靠谱工程师那样工作。
今年到目前为止，最有效的 coding agent 改进之一，居然可能只是一个 Markdown 文件。
这听起来有点好笑。
但也挺扎心。
因为它说明，很多时候我们缺的不是更复杂的工具。
而是把最基本的工程纪律，明确写下来。
你可以直接把CLAUDE.md放进项目根目录，也可以把那四个部分复制进你已有的CLAUDE.md。
不一定神奇。
但很可能有用。
最后：
精通 React 面试：从零到中高级(针对面试回答)
CSS终极指南
Vue 设计模式实战指南
20个前端开发者必备的响应式布局
深入React:从基础到最佳实践完整攻略
python 技巧精讲
React Hook 深入浅出
CSS技巧与案例详解
vue2与vue3技巧合集
