Claude Code on KnightLi的博客

Karpathy 的 65 行 CLAUDE.md：让 AI 编程少犯三类错误

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一个围绕 AI 编程的项目很火，核心其实只是一个大约 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因为技术实现复杂，而是因为它抓住了很多人使用 AI 写代码时反复遇到的问题。

这个项目的背景，要从 Andrej Karpathy 对 AI 编程的观察说起。Karpathy 是 AI 领域很有影响力的教育者和工程师：斯坦福博士，参与过 OpenAI 早期工作，也曾在 Tesla 负责 Autopilot 视觉系统。后来他持续分享对大模型、教育和 AI 工具的理解，所以他对编程方式变化的判断，总会引起很多开发者关注。

他在一次分享中提到，自己使用 Claude Code 几周后，编程方式发生了明显变化：过去大概是 80% 手写代码、20% AI 辅助，现在更接近 80% 让 AI 写代码，自己做 20% 修改。他形容这像是“用英语编程”，通过自然语言告诉 LLM 要写什么。

但他也指出了 AI 编程的几个典型问题。

01 错误假设

第一个问题是模型很容易替用户做假设，然后沿着这个假设一路写下去。它不一定会主动管理自己的困惑，也不一定会在需求含糊时停下来追问。

比如用户只说“添加用户导出功能”，模型可能会默认导出全部用户，默认输出 JSON，默认写成本地文件，默认权限和字段都不需要再确认。等代码写完，用户才发现它理解的需求和真实场景并不一致。

更好的做法应该是先把不确定点列出来：导出全部用户还是筛选结果？是浏览器下载还是后台任务？需要哪些字段？数据量大不大？是否有权限限制？这些问题不问清楚，后面写得越快，偏得也越远。

02 过度复杂化

第二个问题是模型很容易把简单问题写复杂。一个函数能解决的问题，它可能加上抽象类、策略模式、工厂模式、配置层和一堆“未来可能有用”的扩展点。

这类代码看起来很工程化，实际却增加了维护负担。AI 尤其擅长快速生成大量结构，但并不总能判断这些结构是否真的必要。结果就是一百行能解决的任务，被膨胀成一千行。

判断标准其实很直接：一个资深工程师看到这段改动，会不会觉得它过度设计？如果答案是会，就应该删掉多余层次，用最少的代码解决当前问题。

03 附带伤害

第三个问题是模型有时会修改或删除自己没有充分理解的代码。它可能在修一个小 bug 的时候顺手改注释、重排格式、清理看似无用的 import，甚至动到和当前任务无关的逻辑。

这类“顺手优化”很危险，因为它扩大了变更范围，也让 review 变得更困难。用户本来只想修复一个空邮件导致验证器崩溃的问题，结果模型顺便增强了邮件验证、加了用户名校验、改了文档字符串，最后很难判断到底哪一行影响了行为。

更稳妥的原则是：只动必须动的代码，只清理自己造成的问题。原本就存在的死代码、格式问题或历史包袱，除非任务明确要求处理，否则最多提醒一句，不要直接改。

04 把吐槽变成 CLAUDE.md

在 Karpathy 的观点被大量传播后，开发者 Forrest Cheung 做了一件很聪明的事：他把这些吐槽整理成可以执行的行为准则，写进一个 CLAUDE.md 文件。

这个项目没有复杂代码，关键就是把 AI 编程中最容易出问题的地方，转成明确的工作规则。大致可以概括为四条。

第一条是先想再写。不要默默假设，不要隐藏困惑；如果需求有多种理解，就把它们列出来；如果存在更简单的方案，也要说出来；该追问时追问，该反驳时反驳。

第二条是简单优先。不添加没被要求的功能，不为一次性代码做抽象，不加入多余配置，也不为极小概率场景写大量防御代码。如果 50 行能解决，就不要写成 200 行。

第三条是精准修改。每一行改动都应该能直接追溯到用户请求。不要顺手改善邻近代码，不要重构没坏的东西，尽量匹配项目既有风格。

第四条是目标驱动。不要只给模型一个模糊指令，而是给它可验证的成功标准。比如“修复 bug”可以变成“先写一个能复现 bug 的测试，再让测试通过”；“添加校验”可以变成“写无效输入测试并通过”。成功标准越清楚，模型越容易自己循环到完成。

05 为什么它会火

这个项目能火，不是因为内容很玄，而是因为它足够贴近真实开发。

很多人用 AI 编程时都经历过类似场景：模型自信地误解需求，代码越写越复杂，或者在不该动的地方动手。CLAUDE.md 的价值，是把这些经验变成可以放进项目里的协作规则。

它的门槛也很低：一个文件就能开始生效，不需要复杂接入。再加上 Karpathy 本人的影响力，以及项目里有实战对比案例，它很自然会在 Claude Code 用户和 AI 编程社区里传播开来。

更重要的是，这类规则不是只适用于 Claude Code。无论使用哪种 AI 编程工具，本质问题都很相似：模型需要知道什么时候该问、什么时候该简化、什么时候该停手、怎样判断任务已经完成。

06 对普通开发者的启发

这件事给普通开发者的启发很简单：AI 编程不是把一句需求丢给模型，然后等待奇迹发生。真正有效的方式，是给模型建立边界。

需求不清楚时，让它先暴露假设。实现方案变复杂时，让它主动回到最小可行解。修改代码时，让它只围绕任务目标行动。完成任务时，用测试、命令或明确检查点来验证结果。

AI 写代码的能力已经很强，但它仍然需要好的协作约束。一个短小的 CLAUDE.md 能获得大量关注，说明开发者真正需要的并不只是更聪明的模型，也包括更可靠的工作方式。

简单总结：

先想再写，减少错误假设。
简单优先，避免过度设计。
精准修改，控制变更范围。
目标驱动，用可验证标准推动完成。

这四条并不复杂，却很实用。AI 编程真正提升效率的前提，不是让模型写得更多，而是让它写得更准、更少、更可控。

Claude Code 额度省着用：模型选择、上下文、缓存与 /compact

Sun, 19 Apr 2026 15:26:56 +0800

最近很多人在用 Claude Code 或 Claude Max 时会遇到一个问题：明明买了 Pro、Max 5x，甚至 Max 20x，结果没跑多久就提示额度快满，或者直接需要等重置。尤其是在大项目里让 Claude Code 读很多文件、修复杂 bug、跑长任务时，这种感觉会更明显。

这里先说结论：额度不是按“时间”线性扣的，而是和模型、上下文长度、附件、代码库规模、对话历史、工具调用和当前容量都有关系。同样 5 小时窗口，有的人能用很久，有的人十几分钟就耗尽，通常不是账号坏了，而是每次请求都太重。

这篇整理一套比较实用的省额度习惯。

01 先理解 Claude 的用量窗口

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量会和 Claude 网页、桌面、移动端共享同一套订阅额度。官方说明里提到，消息数量会受到消息长度、附件大小、当前对话长度、所用模型或功能影响；Claude Code 还会受到项目复杂度、代码库大小、自动接受设置等影响。

大致可以这样理解：

Pro：适合轻量使用和小项目。
Max 5x：适合更频繁使用和较大的代码库。
Max 20x：适合更重度、日常高频协作。
用量窗口按 5 小时会话重置。
长消息、长对话、大文件、复杂任务会更快消耗额度。
Opus 这类更强模型会比 Sonnet 更快触发限制。

所以“我只用了 20 分钟”这个说法不一定能说明问题。真正重要的是这 20 分钟里 Claude 读了多少上下文、用了什么模型、是否反复处理大文件、是否在同一个长对话里继续加任务。

02 第一件事：不要默认一直用最贵模型

Claude 系列里常见的定位是：

Opus：能力最强，适合复杂推理、架构决策、疑难 bug。
Sonnet：能力和成本比较均衡，适合大部分日常编码任务。
Haiku：更轻量，适合简单分类、摘要、格式转换等任务。

日常写脚本、改小 bug、整理文档、解释代码，大多数时候 Sonnet 已经够用。Opus 更适合留给这些场景：

复杂架构设计。
多文件深度重构。
难复现的 bug。
需要长链路推理的排障。
普通模型明显卡住的任务。

Claude Code 里可以用 /model 切换模型，也可以在 /config 里设置默认模型。比较稳的习惯是：默认 Sonnet，关键节点再切 Opus，而不是整场任务都用 Opus 扛。

03 第二件事：控制上下文，不要让旧任务拖着走

上下文越长，Claude 每次处理要看的内容越多，额度消耗也越高。Claude Code 官方文档明确建议主动管理上下文：

换到不相关任务时，用 /clear 清空历史。
当前任务做完一个阶段但还要保留重点时，用 /compact 压缩。
想知道上下文里什么占空间，用 /context。
想持续看到状态，可以配置 status line。

一个好用的节奏是：

小阶段完成：/compact
大任务结束：/clear
切换无关项目：/clear
上下文接近很高占用：提前 /compact

/compact 会把前面的对话压成摘要，保留关键任务状态、结论、文件路径、待办事项，但减少后续每次请求要携带的历史。你也可以给它补一句重点：

`1`	`/compact 保留已修改文件、测试结果、剩余待办和关键设计决策`

不要等自动压缩才处理。官方文档提到，Claude Code 会在上下文接近容量上限时自动压缩，但手动在阶段边界压缩，通常更可控。

04 第三件事：长对话和大文件会让每次请求变贵

很多人以为“我只是继续问一句”，应该很便宜。但在长对话里，这一句背后可能带着大量历史、文件摘要、工具定义和系统规则。

特别容易涨上下文的东西包括：

一直不清理的长对话。
让 Claude 读完整大文件。
贴很长日志、构建输出、测试输出。
一次性塞很多截图或图片。
让它反复扫描整个仓库。
过长的 CLAUDE.md。
开了很多 MCP server。

比较省的做法是：日志只贴关键报错，测试输出只给失败部分，大文件让它先用 rg、head、tail、符号搜索定位，再读必要片段。能用命令行过滤的内容，不要整包塞进上下文。

05 第四件事：理解缓存，但不要迷信缓存

Anthropic 的 Prompt Caching 会缓存重复的 prompt 前缀。默认缓存生命周期是 5 分钟，也支持 1 小时缓存。缓存命中时，重复的大段上下文不需要完整重新处理，有助于降低成本和改善额度利用。

但缓存有几个限制：

需要内容完全匹配，文字和图片都要一致。
默认缓存是短生命周期。
改模型、改工具、改系统提示、改上下文结构，都可能降低命中。
输出 token 不会因为缓存而消失，该生成的回答仍然要生成。
Claude Code 具体如何利用缓存，是产品层实现细节，不要把它当成永远稳定的“免费记忆”。

实际使用里，最重要的不是研究缓存细节，而是保持会话稳定：

同一阶段尽量别频繁切模型。
不要中途反复改大量规则。
不要在同一任务里不停贴新图片。
长任务中间不要闲置太久后又继续塞大请求。
阶段结束主动 /compact。

这样更容易让重复上下文保持可复用，也能降低后续请求负担。

06 关于高峰时段：能避开就避开，但不要当固定公式

网上常有人说某些时段额度会更紧。官方帮助中心的表述更谨慎：可发送数量会受到 Claude 当前容量、对话长度、附件、模型和功能影响。也就是说，高峰容量确实可能影响体验，但不要把某个地区的某个时间段当成永久固定规则。

实用建议是：

大重构、大批量分析尽量放到自己网络和服务都稳定的时段。
不要在快到休息时开启一个超长任务。
预计会离开很久时，先 /compact 或 /clear。
如果只是小改动，不要开 Opus 加长上下文硬跑。

这比记一个固定“几点到几点不能用”的规则更可靠。

07 精简 CLAUDE.md、rules、MCP 和 skills

Claude Code 会在会话中加载项目规则、工具信息和一部分环境上下文。官方文档也建议把通用规则和专用规则分开，避免每次启动都带着一大包不相关内容。

比较推荐的拆法：

CLAUDE.md：只放全局都适用的核心规则。
rules：放特定路径、特定文件类型才需要的规则。
skills：放特定工作流，例如发文章、部署、生成图片、提交代码。
MCP：只启用当前任务真的会用到的 server。

如果 CLAUDE.md 写了几百上千行，每次会话都要带进去。更好的方式是把“偶尔才用”的流程移到 skill 里，需要时再调用。

MCP 也是一样。工具多不等于效率高。Claude Code 文档提到可以用 /mcp 查看并禁用不需要的 server，也可以用 /context 看是什么占用了上下文空间。

08 实用指令清单

日常最常用的是这几个：

/model

切换模型。默认建议用 Sonnet，复杂推理再用 Opus。

/clear

清空当前上下文。换无关任务时用，最省。

`1`	`/compact`

压缩历史上下文。一个阶段完成但还要继续同一任务时用。

`1`	`/context`

查看上下文占用，排查是什么吃掉空间。

/status

查看当前订阅或额度相关状态。官方帮助中心也建议用它监控剩余额度。

/mcp

查看和管理 MCP server，关闭当前不用的工具。

如果你用 API 计费模式，还可以关注 /cost；但如果是 Pro/Max 订阅，官方文档说明 /cost 的美元估算不适合作为订阅账单依据，订阅用户更应该看 /stats 和 /status 这类使用信息。

09 一套省额度工作流

比较顺手的流程可以是这样：

新任务开始前先 /clear。
默认用 Sonnet。
先让 Claude 读项目结构和关键文件，不要一口气读全仓库。
每做完一个小阶段就 /compact。
复杂卡点再切 Opus。
日志、报错、测试输出先过滤再给。
任务完成后 /clear，不要拖着旧上下文开新活。
定期检查 CLAUDE.md、MCP 和 skills，把常驻上下文压小。

这个流程的核心是：让 Claude 每次只看当前真正需要看的东西。

10 小结

Claude Code 额度快速耗尽，通常不是单一原因，而是几个因素叠加：用了高成本模型、长对话一直不清、文件和日志塞太多、MCP 和规则常驻过重、缓存命中变差，再加上高峰容量波动。

省额度的核心也很简单：

日常任务优先 Sonnet。
Opus 留给真正复杂的问题。
阶段完成用 /compact。
换任务用 /clear。
用 /context 找上下文占用来源。
精简 CLAUDE.md、rules、MCP 和 skills。
不要把整仓库、整日志、整图片包都丢进去。

同样的 Pro 或 Max 方案，能做多少事，很大程度取决于你怎么管理上下文。把上下文变小、任务边界变清楚，Claude Code 的可用时间和稳定性都会明显好很多。

参考链接

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching