Anthropic工程师的CLAUDE.md有200行

200行配置换来输出质量"跳崖式"上涨——方向是对的。这是Boris Cherny的真实经历，他亲手搭建了Claude Code。而大多数开发者的CLAUDE.md，本质上是个自暴自弃的README。

你的"规则清单"正在拖垮Claude

HumanLayer引用arXiv一篇关于指令跟随极限的论文指出：前沿推理模型能可靠执行的指令约150-200条。他们对Claude Code系统提示词的拆解显示，你的CLAUDE.md加载前，Claude已经内置了约50条指令。

具体数字或许有争议，但趋势没有。规则加到某个临界点，Claude执行所有规则的能力都会下降——不只是新加的。

Compliance drops uniformly. 你最在乎的规则，和那些忘了删的废话，被忽略的概率一模一样。

这就是为什么X上那些"400行CLAUDE.md让Claude变10倍工程师"的病毒推文，实际上在帮倒忙。作者好意，但追随者们往文件里塞规则，Claude在前100条之后就悄悄停止执行了。

上下文是预算。要像付房租一样花它，而不是当赌场筹码。

一半内容在浪费指令额度

最讽刺的是，多数人塞进CLAUDE.md的东西，Claude本来就能推断。技术栈在package.json里，TypeScript配置在tsconfig.json里，Linter规则在.eslintrc里。Claude全都会读。重复这些内容，等于把指令额度烧在毫无影响的事情上。

Boris Cherny给每条规则设了一个测试："删掉这条，会让Claude犯一个无法挽回的错误吗？"

删掉"use TypeScript"，而你的项目有tsconfig.json——无事发生。删掉"Convex queries不能调用mutations，要用actions"——Claude会生成通过类型检查、但运行时爆炸的代码。

只放Claude独自搞不定的东西。

他晒出自己的旧CLAUDE.md，十一行"信息"：Stack、Node版本、包管理器，以及"用TypeScript""写测试""别删.env"。Claude三秒就能从仓库里扒出来的东西。剩下的是"写干净代码""遵循最佳实践""保持组件小巧"——多小？React组件那么小，还是微服务那么小？Claude不知道，你也没说。

真正有效的四类信息

重构四个生产仓库后，Boris把CLAUDE.md拆成四个区块，按重要性排序：

1. 项目级上下文（最多50行）

这是"为什么"和"为谁做"。不是功能列表，是决策依据。目标用户是谁，核心用户旅程是什么，技术选型背后的约束——比如"用Convex是因为需要实时同步，但代价是查询不能调mutations"。

Claude Code的维护者Trail of Bits，在审计仓库里会写清：这份代码是做什么的，审计范围是什么，已知风险在哪。不是给人类看的文档，是给Claude的决策锚点。

2. 工作流偏好（20-30行）

怎么和现有代码库协作。测试命令是什么，怎么跑类型检查，提交前必须过哪些门。Anthropic黑客马拉松的获胜团队会写明：先写测试再写实现，还是反过来；遇到不确定的设计决策时，该问谁或查哪份文档。

关键要具体。"写测试"是废话。"用vitest，测试文件放__tests__/，覆盖率门槛80%"才是指令。

3. 常见陷阱（10-15行）

Claude反复踩过的坑。不是通用最佳实践，是本项目特有的 gotcha。比如"Convex的auth()在edge runtime里不可用，要用getAuth()""这个repo用zod做运行时校验，别用io-ts"。

Boris的200行里，这部分不到10%。但每条都救过命。

4. 禁止事项（5-10行）

红线列表。不是"别写烂代码"，是"别动这个文件""别升级这个依赖""别用React Server Components，我们还没迁移"。

数量少，因为每条都必须是"违反就回滚"级别。

从"文档"到"环境变量"的思维切换

README是给新同事看的，CLAUDE.md是给Claude看的。两者的区别像用户手册和.env文件——一个解释"这是什么"，一个配置"怎么运行"。

Boris的转折点发生在对比了Trail of Bits的审计仓库之后。他们的CLAUDE.md没有"项目介绍"，只有"审计范围""已知漏洞模式""工具链版本"。Claude生成的报告直接可用，不需要人类再改格式。

另一个参照是Anthropic官方黑客马拉松的获胜项目。他们的CLAUDE.md平均长度是失败项目的三分之一，但"具体指令密度"高出五倍。"用shadcn/ui，主题色slate-950"——不是"用好看的组件库"。

核心洞察：Claude不是需要更多信息，是需要更精确的信息。每多一行模糊的指导，就挤占一行能改变行为的指令。

怎么验证你的CLAUDE.md有效

Boris的测试方法：删掉CLAUDE.md，让Claude完成一个典型任务，记录哪里出错。然后把修复指令写进CLAUDE.md，重复测试。有效的条目会让错误消失，无效的条目会让Claude在其他地方犯错——因为上下文被稀释了。

他最初的200行里，经过三轮测试后剩下127行。被删掉的包括：所有能从配置文件推断的内容，所有"尽量""考虑""适当"开头的句子，所有和本项目无关的通用最佳实践。

一个反直觉的发现：把CLAUDE.md从50行扩充到200行，输出质量先降后升。中间那段"150行左右"是最差的——规则够多造成干扰，又不够多形成体系。要么精简到核心，要么系统化到完整，卡在中间最致命。