全球 AI 大佬都在用的AI 使用说明书Andrej Karpathy 的 CLAUDE.md 究竟是什么你有没有遇到过这种情况让 AI 帮你写代码结果它噼里啪啦写了一大堆但很多都是你根本没要的东西。或者 AI 二话不说就开始改你代码把你原本好好的逻辑拆得七零八落。说白了不是 AI 不好用是你不懂怎么跟它约法三章。Andrej Karpathy 这个人你可能听说过。他是 OpenAI 的创始成员之一后来去了特斯拉当 AI 负责人在 AI 圈子里算是大神级别的人物。最近他搞了一个叫 CLAUDE.md 的文件在网上火得不行。这个文件不是什么复杂的技术文档简单来说就是一份跟 AI 助手打交道的使用说明书。CLAUDE.md 本质上是一组行为准则专门用来减少 AI 写代码时犯的那些低级错误。它只有四条规则但每条都说到了点子上。下面我就一条一条给你掰扯清楚。规则一先思考再编码说白了就是别让 AI 蒙着头就开干。很多人在用 AI 写代码的时候丢一句话过去就不管了。AI 呢它可不会主动问你你确定吗而是直接按自己理解开始写。结果经常跑偏。Karpathy 的解决方案很简单——让 AI 在做任何事情之前先停下来想一想。具体怎么做呢有四点第一把假设说出来。AI 可能会对你的需求有一些猜测让它把这些猜测摊到桌面上。如果猜错了你还能纠正。第二有歧义就列出来。如果你的需求有几种不同的理解方式让 AI 把它们全列出来而不是悄悄选一个它觉得最可能的。第三敢于说不。如果 AI 觉得你的方案太复杂有更简单的做法它应该说出来的。这在 AI 协作中非常关键——你付钱给它写代码不是让它当应声虫。第四不懂就问。如果 AI 觉得你的描述不清楚别让它瞎猜直接问你就行。简单来说就是让你的 AI 助手在动手之前先学会动脑子。规则二简洁至上这个最有意思——教 AI 学会偷懒。你有没有发现AI 写代码特别喜欢加戏你让它写个登录功能它给你整了一套完整的用户管理系统还带权限控制和邮件通知。你明明只需要一个按钮它给你写了一整个仪表盘。Karpathy 是这么治这个毛病的不多写一行没用的代码。用户没要的功能绝对不写。不用为只用一次的代码做抽象。有些代码只在一个地方用到就别搞什么封装复用了。过度设计比没有设计更可怕。不加没必要的灵活性和可配置性。你只要一个开关别整出一套配置系统。不为不可能发生的错误写处理逻辑。如果某个错误理论上不会出现就别为它写 try-catch。Karpathy 还教了 AI 一个自我检查的方法——写完代码后问自己如果是一个资深工程师来看这段代码会不会觉得太复杂了如果答案是会那就重写。举个例子你写了 200 行代码但其实 50 行就能搞定——那就重写成 50 行。别舍不得。规则三外科手术式修改改代码像做手术切哪里切多少都有讲究。当你让 AI 修改现有代码的时候它有一个坏毛病——顺手把旁边没问题的代码也改善一遍。这就像你让医生给你割个阑尾结果医生顺手帮你把扁桃体也切了。Karpathy 定了这么几条规矩第一不改无关的代码。注释不要动格式不要调旁边那些明明好好的代码也少碰。第二不重构没坏的东西。这代码虽然能工作但我觉得可以写得更好——打住能工作就别碰它。第三跟现有风格保持一致。就算你觉得原来的风格很丑也要忍着跟原来保持一致。一致性比美观重要得多。第四发现死代码可以提但别删。如果你看到一些没用的代码可以告诉用户这里有一段没用的代码但别自作主张删掉。当然如果你的改动导致原来的某些代码变得没用了比如你删了一个函数导致某个 import 没用了那你是要清理干净的。这叫自己拉的屎自己擦。检验标准很简单你改的每一行代码都应该能直接说清楚是为什么需求改的。说不清楚那就别改。规则四目标驱动执行别跟我说优化代码跟我说写完测试跑通再重构。这个规则解决的是 AI 容易假努力的问题。如果你跟 AI 说帮我优化一下这段代码它可能会不知道怎么才算完成。但如果你说先写测试确认测试通过再重构重构完再跑一遍测试确保全通过它就非常清楚要做什么。Karpathy 是这么教 AI 把模糊任务变清晰的加个验证 → 改成先写针对无效输入的测试然后让测试通过修个 bug → 改成先写一个能复现 bug 的测试然后让测试通过重构 X → 改成确保重构前后测试都能通过对于多步骤的任务还有一个简单好用的格式1. [做什么] → 验证[怎么检查做对了] 2. [做什么] → 验证[怎么检查做对了] 3. [做什么] → 验证[怎么检查做对了]这个框架看起来简单但非常管用。因为它让每个步骤都有明确的完成标准。没有完成标准的任务AI 很容易蒙混过关。有完成标准的任务AI 就能自己检查、自己迭代不需要你一遍遍地去催它。总结一下Karpathy 的 CLAUDE.md 表面上是教 AI 怎么做的但仔细想想它其实也在教我们一个道理——跟 AI 合作最重要的不是技术而是沟通。你越清楚自己的需求越能把模糊的任务拆成清晰可验证的步骤AI 就越能帮到你。反过来如果你自己都没想清楚给 AI 一个模棱两可的需求那就别怪 AI 给你一个模棱两可的结果。四条规则串在一起讲的其实就是一个故事想清楚写简单改精准做明白。不管你是程序员还是普通用户只要你在用 AI 辅助工作这套使用说明书都值得好好看看。附录CLAUDE_CN.md 完整内容CLAUDE.md减少常见 LLM 编码错误的行为指南。可根据需要与项目特定说明合并使用。权衡这些指南偏向谨慎而非速度。对于琐碎任务请自行判断。1. 先思考再编码不要假设。不要隐藏困惑。把权衡摆在明面上。在实施之前明确陈述你的假设。如果不确定就问。如果存在多种解读把它们都列出来——不要默默选择一个。如果有更简单的做法就说出来。在必要时提出异议。如果有什么不清楚停下来。说出困惑之处。提问。2. 简洁至上用最少的代码解决问题。不写任何推测性的东西。不多实现任何未被要求的特性。不为一次性使用的代码做抽象。不添加未被要求的灵活性或可配置性。不为不可能发生的场景做错误处理。如果你写了 200 行代码而它本可以只用 50 行重写它。问问自己一个资深工程师会说这太复杂了吗如果是就简化。3. 外科手术式修改只动必须动的。只清理自己造成的混乱。在编辑现有代码时不要改进相邻的代码、注释或格式。不要重构没有问题的东西。匹配现有的风格即使你有不同做法。如果发现无关的死代码提出来——但不要删掉它。当你的修改产生了孤儿代码移除因你的改动而变得未使用的导入/变量/函数。除非被要求不要移除已有的死代码。检验标准每一行改动的代码都应能直接追溯到用户的请求。4. 目标驱动执行定义成功的标准。循环直到验证通过。将任务转化为可验证的目标添加验证 → 编写针对无效输入的测试然后让它们通过修复这个 bug → 编写一个能复现它的测试然后让测试通过重构 X → 确保重构前后测试都能通过对于多步骤任务陈述一个简要计划1. [步骤] → 验证[检查项] 2. [步骤] → 验证[检查项] 3. [步骤] → 验证[检查项]强有力的成功标准让你能独立迭代。薄弱的标准让它能工作则需要不断澄清。这些指南有效的标志是diff 中不必要的变更减少因过度复杂而重写的次数减少澄清性问题在实施之前提出而非在犯错之后。