ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Andrej Karpathy Skills 实战:用 CLAUDE.md 给 Claude Code 装上编码指南

Andrej Karpathy Skills 实战:用 CLAUDE.md 给 Claude Code 装上编码指南 1. 为什么你的 Claude Code 总在“自作主张”用 Claude Code 写代码的人大概率都遇到过下面这些场景你让它加一个参数校验它顺手把整个函数重构成三个抽象类你让它修一个边界条件的 bug它把旁边那段你没看懂的注释删了你让它“优化一下性能”它没问清楚瓶颈在哪就开始改数据结构。这些行为不是模型能力不够而是它默认的编码习惯和人类资深工程师的直觉不一致。Andrej Karpathy 在多次公开分享里点过这个问题LLM 辅助编码时最危险的不是写不出代码而是在不确认的情况下替你做假设以及把简单问题复杂化。Claude Code 本身支持项目级上下文文件CLAUDE.md这个文件会在每次会话启动时被读取相当于给模型一份“项目宪法”。把 Karpathy 观察到的那些陷阱翻译成CLAUDE.md里可执行的规则骨架就能明显改变它的行为。这篇内容聚焦一件事在项目根目录写一份CLAUDE.md把编码指南拆成可复用的规则然后通过重启 Claude Code 验证规则是否真的被加载。适合已经在用 Claude Code、但被它的“过度工程”和“乱改代码”困扰的开发者。下面给出的配置片段可以直接复制改完重启就能观察效果。2. 前置准备TaoToken 接入与 Claude Code 环境确认在写CLAUDE.md之前先确认你的 Claude Code 能正常跑起来。Claude Code 需要配置模型接入端点这里用 TaoToken 的 API 作为接入地址它兼容 Anthropic 的接口格式配置方式比较直接。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。注意 API 地址后面不加 UTM 参数保持干净。你需要先在控制台创建一个 API Key。打开 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 登录后进入 API Keys 页面新建一个 key 并复制保存。这个 key 只显示一次丢了就得重建。拿到 key 之后在终端里设置环境变量。Claude Code 读取的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY这两个变量export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的key如果你用的是 zsh把这两行写进~/.zshrcbash 就写进~/.bashrc。写完后source一下或者新开一个终端窗口。验证接入是否正常可以先用一个最小请求测试。Claude Code 本身有交互界面但为了确认 key 和端点没问题可以用 curl 直接打一次模型对话接口curl -s https://taotoken.net/api/v1/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 64, messages: [{role: user, content: 回复 ok 两个字母}] }如果返回的 JSON 里有content字段且文本是ok说明接入链路通了。这一步不做的话后面CLAUDE.md加载失败你分不清是文件问题还是接入问题。注意API Key 不要提交到 git 仓库也不要写进CLAUDE.md。CLAUDE.md是给模型看的规则文件不是配置文件。3. 可复制配置把 Karpathy 编码指南拆成 CLAUDE.md 规则骨架CLAUDE.md放在项目根目录Claude Code 启动时会自动读取。它的内容不是“提示词”而是系统级约束所以写法要像规则不像聊天。下面这份骨架把 Karpathy 提到的四类问题拆成四个区块每个区块给出可判定的标准而不是模糊的“请认真思考”。先看完整片段你可以直接复制到项目根目录的CLAUDE.md里# 项目编码规则 ## 1. 编码前思考Think Before Coding - 不要假设需求。如果用户请求存在歧义先列出你识别到的歧义点并给出 2-3 种解释等待确认后再动手。 - 不要隐藏困惑。遇到与现有代码逻辑冲突、或你认为不合理的需求时直接指出不要默默执行。 - 呈现权衡。当有多种实现路径时用简短列表说明各自的代价改动范围、性能、可读性再推荐一个。 - 禁止在未确认的情况下修改公共接口、数据库 schema、环境变量名。 ## 2. 简洁优先Simplicity First - 用最少的代码解决当前问题。不写“以后可能会用到”的抽象层、工厂、基类。 - 检验标准如果一位资深工程师看到这段代码会不会说“这过度设计了”如果是重写。 - 不引入新依赖除非用户明确要求。需要新依赖时先说明理由和替代方案。 - 不写没有调用方的函数、没有引用的变量、没有使用的 import。 ## 3. 精确修改Surgical Changes - 只改必须改的行。每一行改动都必须能追溯到用户的具体请求。 - 不删除、不重写你没有完全理解的注释和周边代码。如果注释看起来过时先问不要直接删。 - 不顺手格式化整个文件。只格式化你改动的行。 - 修改完成后列出你改了哪些文件、每个文件改了什么方便用户 review。 ## 4. 目标驱动执行Goal-Driven Execution - 把指令式任务转化为可验证目标。用户说“修复 bug”你要先写一个能复现该 bug 的测试再改代码让测试通过。 - 用户说“添加验证”你要先为无效输入写测试再实现验证逻辑。 - 每个任务结束时说明你用什么命令或测试验证了结果。没有验证步骤的任务不算完成。 - 如果无法验证比如缺少测试框架明确说明并给出建议的验证方式。这份骨架的关键在于每条规则都有可判定的触发条件。比如“不假设需求”后面跟了“列出歧义点并等待确认”模型就知道遇到歧义时该输出什么而不是继续猜。“简洁优先”里放了检验标准那句话模型在生成代码后会拿这句话自检。你可以在四个区块后面追加项目特有的规则比如代码风格、目录结构约定、测试命令。追加时保持同样的写法规则 判定标准 触发动作。不要写成“请尽量保持代码整洁”这种没有可操作性的句子。如果你已经有自己的CLAUDE.md把上面四个区块追加到文件末尾即可不需要替换原有内容。原有规则和这套骨架不冲突前者管项目细节后者管编码行为。4. 验证规则是否生效重启 Claude Code 并观察行为变化文件写完后Claude Code 不会热加载CLAUDE.md。你需要退出当前会话重新启动。启动后Claude Code 会在会话开始时读取项目根目录的CLAUDE.md把它作为系统上下文的一部分。验证是否加载成功最直接的方法是给一个故意有歧义的请求看它是否按规则先确认再动手。比如在项目里输入帮我优化一下 utils.js 里的 formatDate 函数如果规则生效Claude Code 不应该直接改代码而应该先列出它识别到的歧义优化目标是性能、可读性还是减少依赖当前函数有没有测试覆盖它应该给出几种解释等你确认。如果它直接开始改说明CLAUDE.md没被读到或者规则写得太模糊。第二个验证动作是给一个简单任务看它是否过度设计。比如给 parseConfig 函数加一个参数允许传入自定义分隔符规则生效时它应该只改parseConfig的签名和内部用到分隔符的那一行不会顺手重构整个配置解析模块也不会新增一个SeparatorStrategy类。改完后它应该列出改动文件和你需要 review 的点。第三个验证是目标驱动。输入登录接口在密码为空时会返回 500修复它按规则它应该先写一个测试用例复现“密码为空返回 500”然后改代码让测试通过最后告诉你它跑了哪个测试命令。如果它直接改代码而不写测试说明第四条规则没有被执行。如果验证下来发现规则没生效先检查三件事CLAUDE.md是否在项目根目录不是子目录文件名大小写是否完全一致CLAUDE.md全大写启动 Claude Code 时的工作目录是否是项目根目录。这三点任何一个不对文件都不会被读取。5. 本篇常见错排查报错一启动后模型行为没变化规则像没加载。最常见的原因是CLAUDE.md放在了错误的位置。Claude Code 读取的是当前工作目录下的CLAUDE.md。如果你在~/projects/myapp/src里启动它读的是src/CLAUDE.md不是项目根目录的。解决方法是cd到项目根目录再启动或者确认你的启动脚本没有改变工作目录。另一个原因是文件里有语法问题导致解析失败。CLAUDE.md是 Markdown但 Claude Code 对它的解析比较宽松一般不会因为格式报错。不过如果文件里有大量 HTML 注释或特殊字符可能影响读取。保持纯 Markdown 文本最稳。报错二规则生效了但模型变得过于谨慎什么都不做。这是规则写得太严的副作用。比如“不要假设需求”如果写成“任何情况下都必须先确认”模型连“把变量名从 a 改成 b”这种明确请求都要问一遍。解决办法是在规则里加边界明确、无歧义的请求直接执行只有存在多种合理解释时才确认。你可以在CLAUDE.md里补一句- 对于明确、单一解释的请求直接执行不需要确认。只有存在多种合理解释、或改动影响范围超出请求本身时才先确认。报错三模型改了代码但没有列出改动文件。这说明“精确修改”区块里的“列出改动文件”没有被执行。检查你的规则里是否写了这条以及是否写在了显眼位置。模型对规则区块的注意力不均匀越靠前、越具体的规则越容易被遵守。可以把“修改完成后列出改动文件”这条挪到CLAUDE.md靠前的位置或者单独作为一个## 输出格式区块。报错四接入正常但 Claude Code 启动时报 401。先确认ANTHROPIC_API_KEY环境变量在当前终端里确实存在用echo $ANTHROPIC_API_KEY检查。如果为空说明export没生效检查你写的是~/.zshrc还是~/.bashrc以及是否source过。另外确认 key 没有多余空格或换行复制时容易带上尾部空格。如果 key 确认无误仍然 401去控制台看一下这个 key 是否被禁用或额度用尽。API Keys 页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 可以查看 key 状态和用量。报错五模型在长会话后期开始违反规则。CLAUDE.md的内容在会话开始时注入随着对话轮次增加模型对早期上下文的注意力会下降。这是正常现象。解决办法是在长会话中当你发现它开始乱改代码时直接提醒一句“按 CLAUDE.md 的精确修改规则来”它会重新对齐。或者把大任务拆成多个短会话每个会话重新加载规则。6. 把规则用起来从 CLAUDE.md 到日常编码习惯CLAUDE.md写完之后真正影响输出质量的还有你下指令的方式。Karpathy 那套原则里“目标驱动执行”其实对使用者也有要求你给的请求越接近可验证目标模型越容易按规则执行。对比一下两种写法。以前你可能说“修复这个 bug”现在改成“写一个能复现这个 bug 的测试然后改代码让测试通过”。以前说“添加输入验证”现在改成“为无效输入写测试然后实现验证逻辑让测试通过”。这种改写把“做什么”变成了“怎么验证做完了”模型在执行时就有了明确的停止条件不会无限扩展。如果你长期用 Claude Code 做编码和 Agent 任务可以了解一下 Coding Plan它针对长时间编码会话做了额度优化地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。日常想快速验证模型行为用模型对话页面就够了 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有不同语言和工具的配置示例。最后说一个我自己的习惯每次项目里新增CLAUDE.md规则后我会故意给一个模糊请求看模型是直接动手还是先确认。这个动作花不了两分钟但能确认规则真的在起作用。规则文件不是写完就完事它需要你偶尔用边界请求去“戳”一下看它有没有被遵守。发现某条规则总是不生效就把它改得更具体、更靠前或者拆成更小的判定条件。
返回列表