1. 从 Karpathy 的吐槽说起AI 编程到底哪里不让人省心Andrej Karpathy 那条被反复转发的贴文核心信息其实很朴素他自己在很短时间里从「80% 手写代码、20% 交给 agent」切换到了「80% agent coding、20% 手动修补」。这句话之所以传播广是因为它戳中了很多人的真实体感——AI 编程已经不是玩具而是真的进了主工作流。但随之而来的问题是模型一旦大量参与开发它暴露的错误就不再是「少个分号」这种级别而更像一个「会写代码、但判断力不稳的初级工程师」。具体表现有三类。第一它会替你擅自假设需求不澄清、不暴露矛盾闷头往下写第二它特别容易过度设计本来一百行能解决的问题膨胀成上千行还顺手给你加一堆「以后可能有用」的抽象层第三它改代码时「手太长」你让它修一个小 bug它给你重排格式、重写注释、删掉几个它觉得没用的函数改动和原任务毫无关系。forrestchang 的 andrej-karpathy-skills 项目做的事就是把这些「经验吐槽」翻译成「行为约束」最后收敛成一个很短的 CLAUDE.md 文件。它没有发明新技术只是把 Karpathy 的观察整理成四条可执行原则Think Before Coding、Simplicity First、Surgical Changes、Goal-Driven Execution。这个仓库能迅速积累到接近 29k stars说明大家真正缺的不是又一个提示词合集而是一套能约束 AI 编程行为的规则骨架。这篇要解决的问题是规则文件写好了怎么让它真正跑起来我的做法是用 TaoToken 统一 Key 接入 Claude Code把 settings.json 和 CLAUDE.md 配好再用一次真实请求验证规则生效。适合已经在用 Claude Code、或者准备把 AI 编程纳入团队流程的开发者。下面从接入配置讲到规则骨架每一步都能直接复制。2. TaoToken 前置统一 Key 接入 Claude Code 的准备Claude Code 默认走 Anthropic 官方通道但很多团队的实际需求是「一个 Key 管多个模型、多个工具」避免每个工具单独配一套凭证。TaoToken 在这里扮演的角色是统一接入层你拿到一个 Key就能在 Claude Code、模型对话、Coding Plan 等场景里复用不用为每个工具重复申请和轮换。需要提前准备的东西不多一个可用的 TaoToken API Key以及本机已经装好的 Claude Code。Key 在控制台的 API Keys 页面创建创建后只显示一次记得先存到安全的地方。接入文档里有各客户端的详细字段说明配置前扫一眼能省不少排查时间。这里要强调一点TaoToken 是正规的 API 接入服务不是所谓「灰色中转」配置方式就是标准的 base_url api_key 替换和你在任何兼容 Anthropic 协议的客户端里做的事一样。理解这一点很重要因为它决定了后面 settings.json 的写法——我们改的是请求地址和凭证不是去动 Claude Code 的核心逻辑。如果你还没创建 Key可以先到控制台生成一个如果已经有 Key直接进入下一节的配置。整个前置阶段的目标只有一个手里有一个能用的 Key并且知道它对应哪个 base_url。3. 可复制配置settings.json 与 CLAUDE.md 骨架Claude Code 的配置分两层一层是连接层放在 settings.json 里决定请求发到哪里、用哪个 Key另一层是行为层放在 CLAUDE.md或 AGENT.md里决定模型怎么干活。两层分开管好处是换 Key 不影响规则改规则不影响接入。先看连接层。Claude Code 的 settings.json 通常位于用户目录下的.claude文件夹字段结构如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: 你的_TaoToken_API_Key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }三个字段各司其职ANTHROPIC_BASE_URL指向 TaoToken 的 API 地址注意这里用的是https://taotoken.net/api不带任何查询参数ANTHROPIC_AUTH_TOKEN填你创建的 KeyANTHROPIC_MODEL指定默认模型按你实际可用的模型名填写。如果你习惯用环境变量而不是配置文件也可以在执行前 export 这三个变量效果一样。注意base_url 末尾不要多加斜杠也不要拼上/v1之类的路径Claude Code 会自己补全。多写一段路径是接入失败最常见的原因之一。再看行为层。把下面这份 CLAUDE.md 放到项目根目录Claude Code 启动时会自动读取。它就是我基于 Karpathy 四条原则整理的可复制骨架# Karpathy Guidelines Behavioral guidelines to reduce common LLM coding mistakes. Tradeoff: bias toward caution over speed. For trivial tasks, use judgment. ## Core Rule Prefer correctness, clarity, and bounded changes over speed, speculation, or over-engineering. ## 1. Think Before Coding Do not assume. Do not hide confusion. Surface tradeoffs. - State assumptions explicitly. - If anything is unclear, say what is unclear and ask. - If multiple interpretations exist, present them instead of choosing silently. - If a simpler approach exists, propose it. - Do not start coding until the task boundary is clear. ## 2. Simplicity First Write the minimum code that solves the problem. Nothing speculative. - Do not add features beyond what was requested. - Do not build abstractions for single-use code. - Do not add flexibility or configuration unless requested. - If 50 lines can solve it, do not write 200. - Checkpoint: would a senior engineer call this overcomplicated? ## 3. Surgical Changes Touch only what you must. Clean up only your own mess. - Change only the code required for the task. - Do not refactor adjacent code unless necessary for correctness. - Match the existing code style and local conventions. - If you notice unrelated issues, mention them separately. Do not fix unprompted. - Scope test: every changed line should trace to the users request. ## 4. Goal-Driven Execution Define success criteria. Loop until verified. - Add validation - Write tests for invalid inputs, then make them pass. - Fix the bug - Write a failing test that reproduces it, then make it pass. - For multi-step tasks: state a short plan, execute one step at a time, verify each step with a concrete check, report what was verified. ## Execution Defaults - Before coding, briefly summarize the task and your assumptions. - For non-trivial work, provide a short step-by-step plan. - After changes, run the smallest relevant verification first. - Do not claim completion without verification when verification is possible.如果你用的是 Codex 而不是 Claude Code把同样的内容命名为 AGENT.md放到用户目录的.codex下或项目根目录即可规则本身是通用的。这份骨架的关键不在字数而在每条规则都给了可检查的判断标准比如「每一行改动都能追溯到用户请求」「50 行能解决就别写 200 行」模型有了明确的验收线漂移就会少很多。4. 验证请求确认配置真的生效配置写完不代表生效得用一次真实请求验证。最直接的方式是在项目目录下启动 Claude Code然后给它一个带明确验收条件的小任务观察它是否按规则先陈述假设、再动手。先确认连接层通了。在终端里执行claude --version能正常输出版本号说明 Claude Code 本身没问题。接着进入你的项目目录启动交互cd /path/to/your-project claude启动后先问一个轻量问题比如「这个项目用的是什么语言和构建工具」看它能否正常返回。如果这一步就报鉴权错误或连接超时说明 settings.json 里的 base_url 或 Key 有问题先回到上一节检查。连接通了之后验证行为层。给它一个故意模糊的任务比如「帮我优化一下 utils 里的函数」。按 Karpathy 规则它应该先陈述自己的假设、指出模糊点、而不是直接开改。如果它上来就动手说明 CLAUDE.md 没被读到——检查文件是否在项目根目录、文件名是否大小写正确。再给一个带验收条件的任务比如「给 parse_config 加输入校验先写能复现非法输入的测试再让测试通过」。观察它是否先列计划、再写测试、再改实现、最后报告验证结果。这一步能同时验证 Goal-Driven Execution 和 Surgical Changes 两条规则。实测下来规则文件生效后模型主动提问和列计划的频率会明显上升改动范围也更收敛。5. 本篇常见错排查配置过程中最容易踩的坑集中在几处逐个说清楚。第一类是 base_url 写错。常见写法是https://taotoken.net/api/带尾斜杠或者写成https://taotoken.net/api/v1。正确写法就是https://taotoken.net/api不多不少。如果报 404 或路径错误先查这里。第二类是 Key 没生效。settings.json 里字段名必须是ANTHROPIC_AUTH_TOKEN写成ANTHROPIC_API_KEY在部分版本里不认。另外 Key 创建后只显示一次如果复制时漏了字符鉴权会直接失败。建议重新生成一个再试。第三类是 CLAUDE.md 没被读取。Claude Code 只读项目根目录下的 CLAUDE.md放在子目录或改了文件名都不行。如果你同时用了 AGENT.md注意两者不要冲突选一个作为主规则文件。第四类是模型名不匹配。ANTHROPIC_MODEL填的模型名必须是你的 Key 实际可用的填错会报模型不存在。不确定的话先留空让客户端用默认值跑通后再指定。第五类是规则文件太长导致模型忽略。CLAUDE.md 不是越长越好Karpathy 这套骨架之所以有效恰恰因为它短、每条都可执行。如果你往里塞了几十条规则模型反而会挑着看。建议保持在一屏以内把最重要的约束放前面。排查顺序建议从连接层到行为层先确认能正常对话再确认规则被读取最后确认规则被执行。这样定位问题最快。6. 把规则沉淀成团队资产规则文件真正的价值不在于你一个人用而在于它能进版本库、能被团队复用。把 CLAUDE.md 提交到项目仓库新成员拉下来就自带一套行为约束不用每个人重新踩一遍坑。团队里如果有人用 Codex同一份内容复制成 AGENT.md 即可规则语义完全一致。更进一步的做法是把规则和接入配置分开管理settings.json 属于个人环境不进仓库CLAUDE.md 属于项目资产跟着代码走。这样换 Key、换模型都不影响规则规则迭代也不影响接入。如果你还没开始配可以先到控制台创建一个 Key再照着接入文档把 settings.json 填好规则骨架直接用上面那份跑一次验证请求看模型是否开始先提问、再动手。长期做编码和 Agent 任务的团队可以了解下 Coding Plan把统一 Key 和规则文件一起纳入日常流程。规则立好了AI 编程才从「碰运气」变成「可预期」。
