每份 CLAUDE.md 都需要的 4 行
如果你只来得及写四行 CLAUDE.md，就写这四行。我们审过大约一百个项目后发现，这四行把真正承重的 CLAUDE.md 和那些漂进 dead-letter pile 的文件分开了。缺少它们时，最容易出现“agent 做了我不想要的事”。有它们时，最容易出现“agent 第一个决定就是对的”。这篇讲的是哪四行，为什么是这四行，以及它们各自做了什么别的行替代不了的事。
为什么是四行
这个数字来自经验，不是审美。我们整理了那些写得好的 CLAUDE.md 里出现的规则，找出其中在 大多数 文件里出现的规则，再按对观察到的 agent 行为影响排序。超过四行后，边际价值掉得很快：第五行不如第四行重要，第十行不如第五行重要。少于四行时，文件会缺一块我们在几乎所有没有它的项目里都看到过的问题。所以四行成了操作底线。
这不是说四行就够。四行是最低限度。大多数能工作的文件是 100 到 250 行。但如果你只 ship 下面四行，prose 能提供的大部分价值你已经拿到了。四行之外都是 refinement。
第一行：一句话说明这个项目是什么
This is a real-time collaboration tool for editing shared documents
in the browser. TypeScript, React, Yjs, Postgres, Redis. Deployed on Fly.io.
agent 在读第一份 source file 前，需要知道这是哪类项目。第一句话能阻止一整类早期错误决定：给 frontend-only project 建议 database migrations，给 Node script 建议 browser polyfills，给 desktop-only tool 优化 mobile。没有这一行，agent 会从 package.json 和 src/ 结构推断，通常能对，但偶尔会自信地误判，然后把整个会话带偏。
这一行应该回答三个问题：它做什么，用什么构建，跑在哪里。二十五个词够了。如果你没法用二十五个词描述项目，agent 第一场会话里的困惑就是警告：项目本身缺少清晰身份。
第二行：怎么改东西，也就是流程规则
All changes go through PR. No direct pushes to main. Tests must pass before merge.
流程规则把“agent 做了好事”和“agent 凌晨 3 点把东西 ship 到 production”分开。没有流程行，agent defaults 会接管，而 defaults 经常是“用户让做什么就做什么”。用户要 quick fix，agent 就会 push 到 main。用户很急，agent 就会跳过 test run。
流程行告诉 agent，改动发生方式里哪些不可谈判。三个 sub-rules 覆盖大多数项目：branching policy、push policy、gating policy。有些项目还会加 review policy、commit-message policy 或 merge strategy。一行里四到六条规则可以接受；不可约的核心是“改动从哪里开始，到哪里结束，什么 gate 卡住它”。
这也是最需要配执行层的一行。CLAUDE.md 描述；hooks 执行。除非真的有 pre-push hook 或 branch protection rule 拦住 push，否则 “no direct pushes to main” 就是愿望。把这行和 ~/.claude/scripts/push-gate.sh 或等价物配上，规则才有牙齿。
第三行：语言和风格承诺
TypeScript with strict mode. No `any`. State via Jotai (Redux/Zustand
deprecated). Tests live next to source as `<name>.test.ts`.
语言和风格行告诉 agent，项目的技术选择已经是什么，这样它就不会提出替代方案。没有这一行，agent 有时会看着项目提出团队已经明确不想做的迁移。“This codebase looks like it should use Pinia”，但团队其实出于具体原因选了 Zustand。“TypeScript would be cleaner with branded types here”，但团队有一条反对 branded types 的规则。这一行会提前挡住这些建议。
这行里三个 sub-rules 覆盖多数情况：language pinning（TypeScript strict、Python with uv 等）、framework pinning（state 用哪个 library、forms 用哪个、routing 用哪个）、linter 抓不到的 structural conventions（test 放哪里、哪些命名用 kebab-case 或 PascalCase）。这行里五到十条规则很常见。
2026 best practice 是明确捕捉 deprecated choices。“State via Jotai (Redux/Zustand deprecated)” 比 “State via Jotai” 更有用，因为它告诉 agent 哪些建议要主动避开。agent 读代码能推断 Jotai 在用；它不能推断 Redux 曾经被试过并拒绝过。
第四行：能处理 edge cases 的原则
Don't add error handling for cases that can't happen. Trust internal
code; validate at boundaries. Three identical lines is better than a
premature abstraction.
原则行处理其他几行覆盖不到的情况。具体规则告诉 agent，当 case 被点名时该做什么；principles 告诉 agent，当 case 没被点名时该怎么 reasoning。没有 principles，agent defaults 会接管，而 defaults 往往是“防御性写法、早抽象、处理所有情况”。这对有些项目没问题，对另一些项目正好错。
三到七条 principles 是操作范围。每条 principle 都应该有一句 rationale，即使你不写出来也要心里有。rationale 让 agent 能把 principle 应用到规则表面没有点名的 edge cases。“Don't add error handling for cases that can't happen — because the handling code itself becomes a maintenance burden and obscures the real failure modes” 就能干净地应用到一个规则表面没说的场景。
principles 最难的是保持短。原则很诱人；你一开始写，每个团队价值观都想变成一条。纪律是问：删掉这条 principle，会不会改变 agent 原本会做错的决定？如果会，保留。如果不会，删。
这四行合起来做了什么
每一行覆盖 agent 决策空间的一层。第一行给 agent 定位（“我在哪个世界里”）。第二行约束 agent 行动（“什么不能做”）。第三行引导 agent 选择（“哪些 defaults 适用”）。第四行指导 edge-case reasoning（“没有规则适用时怎么做”）。
没有第一行，agent 靠推断 context 工作，大多数时候对，偶尔会非常错。没有第二行，agent 会 ship 你自己不会 ship 的东西。没有第三行，agent 会提出你不想要的迁移。没有第四行，edge cases 会退回到它的 training 上，而那是几百万个项目的平均值，未必适合你的项目。
四行放在一起，会让 agent 在第一场会话里做出看起来像你自己会做的决定。这就是全部游戏。
这四行刻意不做什么
也值得说清楚这四行 不 试图做什么。
它们不是整个 CLAUDE.md。Operational notes（那个所有人都会踩的 symlink、flaky CI step）、communication style（English / Chinese、terse / verbose）、meta-rules（review cadence、override declarations）都属于这个文件。它们只是不属于不可约的四行。
它们不替代 enforcement。每一行都需要对应机制：process line 需要 hooks，style line 需要 linter config，principles 需要 code review 或 AgentLint sweeps。CLAUDE.md prose 是 briefing；harness 是 enforcement。
它们不替代 AGENTS.md 或 .cursor/rules。如果你的项目有多个 agent harness files，每个文件都需要自己的四行（或指向一个共享 source of truth）。四行纪律是 file-by-file 适用的。
一个挑战
如果你已经有 CLAUDE.md，这里有个有用练习。打开它，找出分别对应“这个项目是什么”、“改动怎么发生”、“语言和风格”、“原则”的四行。如果文件缺了其中任何一行，就补上。如果某个 slot 有超过四行在竞争，合并它们。
如果你还没有 CLAUDE.md，先写这四行，ship 它们，然后只在观察到具体 agent 行为能证明新规则必要时，才让文件变长。带着四行的第一场会话，会有 200 行文件第一场会话 80% 的效果。第二场会话，在你已经看到哪些规则真正承重后，你会知道该加什么。而这些新增规则，会比你看到 agent 行动前凭空预测的任何内容都更好。
四行不是终点。它们是 launchpad。但 ship launchpad 正是大多数项目跳过的部分，所以那么多 CLAUDE.md 文件从第一百行开始，却从来没有在第四行时真正有用过。