一份仅由 Andrej Karpathy 的观察凝练而成的 Markdown 文件，如何成为 Claude Code 生态里星标最多的仓库——以及它在实践中真正站得住脚的部分。
一个除了单个 CLAUDE.md 文件之外什么都没有的 GitHub 仓库，目前已经斩获超过 25,000 个星标。没有框架，没有 CLI，没有 Python 包。只有文本。项目 andrej-karpathy-skills 把 Andrej Karpathy 对反复出现的 LLM 失败模式的公开观察，提炼成给 Claude Code 的四条行为准则。
偏偏是一份 Markdown 文件获得了这样的关注度，这绝非偶然。它是一个信号，标示出当下与 AI 编码助手打交道的真正难点所在：不在于模型能不能写代码，而在于你如何塑造它的行为，让写出来的代码真正可用。
Karpathy 的诊断
这份文件承接了 Karpathy 在其关于 LLM 编码的帖子中作出的三条观察：
"模型会替你做出错误的假设，然后不加核实地一路照做下去。它们不去管理自己的困惑，不主动寻求澄清，不指出前后矛盾，不呈现取舍，该反驳的时候也不反驳。"
"它们特别喜欢把代码和 API 搞得过于复杂，把抽象层堆得臃肿，不清理死代码……本可以用 100 行搞定，却写出一套一千多行的臃肿架构。"
"它们有时仍会作为副作用去改动或删除自己并未充分理解的注释和代码，哪怕这些与当前任务毫不相干。"
任何在生产环境中使用 AI 助手的人都会认出这些模式。这个仓库提出的有趣论断是：如果错误是可预测的，那么用对指令就能防患于未然。
四条原则
把假设摆到明面上。遇到含糊之处，列出多种解读，而不是默不作声地挑一个。如果有更简单的路径，就提出反对。不清楚时就停下来发问。这是对付「悄无声息误读」的解药。
只写能解决问题的代码。不添加没人要求的功能。不为一次性代码搞抽象。不为臆想的场景预留「灵活性」。不为不可能发生的情况写错误处理。如果 200 行能压缩成 50 行，就重写它。
只碰非改不可的地方。即便你会用别的写法，也要匹配现有风格。不要在任务边缘顺手「清理」。每一行改动都必须能追溯回用户的请求。
先定义成功标准，再写代码。「修复这个 bug」要变成「先写一个能复现它的测试，再让它通过」。强标准让模型能自行迭代。弱标准（「让它跑起来」）则逼得你来回反复沟通。
这份文件真正解决了什么——又没能解决什么
这些原则针对的是真实、反复出现的失败模式。仅第 3 条在实践中就能省下大量时间：一旦你亲眼见过智能体修一个错别字、顺手把半个文件的格式「优化」了一遍，你就会明白为什么外科手术般的精准需要被立为一条原则。
与此同时，一份 CLAUDE.md 并非包治百病。这些规则是通用的。它们对你的架构、你的测试、你的部署流水线一无所知。对于更复杂的任务——PDF 处理、浏览器自动化、特定领域的工作流——四条抽象原则远远不够。这正是结构更完整的 Claude Code Skills 登场的地方：按需加载，配有具体的工具和脚本。
CLAUDE.md 与 Skills：何时用哪个
CLAUDE.md
- • 始终在上下文中
- • 通用行为
- • 覆盖整个项目
- • 最适合风格、纪律、该做与不该做的事
Skills
- • 按需加载
- • 具体的工作流
- • 针对特定任务
- • 最适合工具、脚本、特定领域
这两种机制并不互斥。恰恰相反：一份精简、只写行为准则的 CLAUDE.md，再加上一组负责实际工具能力的 Skills，正是在我的项目中运行得最稳定可靠的搭配。文件让智能体不越界，Skills 则为它提供每项任务所需的具体能力。
为什么是 25,000 星标
这个仓库的成功，讲述的是一个比文件本身更大的故事。开发者们正在转移重心。「用 AI 来写代码」是过去两年的阶段。「塑造 AI 的行为，让代码真正过硬」则是我们正在步入的阶段。
而实现这一点的工具，结果出人意料地朴素：文本。一条清晰的指令、一条措辞得当的原则、一项明确的成功检验，往往胜过下一个框架。眼下 Claude Code 生态里最好的工具并不是软件，而是精心打磨的指令。
如果你在生产环境中与 AI 智能体协作，别把 CLAUDE.md 当作可有可无的文档。要把它当作架构的一部分。写进它里面的内容，共同决定了最终会落进仓库里的东西。
使用的工具：
正在打磨 AI 辅助的开发工作流，却苦于不知如何把智能体的行为稳稳地掌控起来？聊聊吧。我帮你搭建在真实项目中真正管用的 CLAUDE.md 与 Skill 配置。