1. 为什么“写得越多Claude越不听话”——从入职须知到协作契约的认知重构你有没有过这种体验花一整个下午把项目里所有命名规范、错误处理方式、测试覆盖率要求、日志格式、commit信息模板……事无巨细地写进claude.md保存信心满满地让 Claude Code 开始写一个简单的 API 路由。结果它生成的代码里还是出现了try/catch还是用了console.log还是把user-service.ts里明明写得清清楚楚的ResultSuccess, Failure模式替换成了一段带throw new Error()的老式写法你点开文件对比心里那句“我明明写了啊”几乎要脱口而出。这不是你的错也不是 Claude 的错。这是你对claude.md的本质产生了根本性误判。绝大多数人把它当成一份“AI行为守则”一份需要 Claude 逐条背诵、严格执行的《刑法典》。但真相是claude.md不是给机器人下的命令而是给你和 Claude Code 共同签署的一份动态协作契约。它不是用来约束它的是用来同步你们之间认知落差的。这就像你刚招来一位经验丰富的高级工程师他技术扎实、思维敏捷但对你这个项目的上下文一无所知。你不会给他发一份 20 页的《公司代码行为白皮书》然后说“照着做”。你会带他走一遍核心流程指给他看几个关键文件告诉他“这是我们处理错误的唯一方式参考app/shared/src/result.ts这是我们写单元测试的范式看user-service.spec.ts这个目录下的代码改动影响面极大改之前务必先跑通pnpm test:shared。”——你给的是上下文不是考卷。Claude Code 正是这样一位能力极强、但项目经验为零的“高级工程师”。它没有记忆每次对话开始它都是一张白纸。而claude.md就是你递给它的第一份“入职须知”。这份须知的价值不在于它有多厚而在于它能否在最短的时间内让这位新同事建立起对项目最核心、最关键的“直觉”。我踩过的第一个大坑就是把claude.md当成了“规则大全”。第一版我写了三千多字涵盖了从 Git 提交信息格式feat(user): add email validation到 TypeScript 接口命名IUserRepository的所有细节。结果呢Claude 在生成代码时对“必须用Result类型”这条规则的遵守率甚至不如我口头强调一次。后来我才明白问题出在信息密度上。当一份文档里塞进了三十条规则Claude 的注意力就被平均分配了。它记住了“要用 pnpm”也记住了“要用 Vitest”但关于“为什么不能用throw”的深层原因却被淹没在文字海洋里。这就像你给实习生发了一份包含 30 条注意事项的清单他大概率只记住了第一条和最后一条中间的全靠临场发挥。所以重构claude.md的第一步是彻底抛弃“全面覆盖”的执念转而拥抱“精准打击”。你要问自己的不是“我有哪些规则”而是“在我这个项目里Claude 最容易在哪几个地方犯错而这些错误一旦发生修复成本最高” 这个问题的答案就是你claude.md的全部内容。其他所有能被 ESLint 自动修复、能被 Prettier 格式化、能在代码库里一眼看出的通用规范统统删掉。把宝贵的上下文窗口留给那些真正定义了你项目灵魂的、独一无二的约定。提示一个简单有效的自检方法是想象你正在给一位刚加入团队的 Senior Frontend Engineer 做入职培训。你只有五分钟时间必须让他立刻理解这个项目最不可妥协的三条铁律。这三条就是你claude.md的核心骨架。2. 从“规则手册”到“活文档”claude.md的结构化写作与持续演进明白了claude.md是一份“协作契约”之后下一步就是解决“怎么写才能让它真正生效”的问题。答案是结构化 动态化。一份好的claude.md绝不是一成不变的静态文本而是一个随着你和 Claude 协作深度不断生长、不断修正的活文档。我现在的claude.md稳定在 780 字左右分为四个清晰区块每个区块都有其不可替代的作用。它不是我坐在电脑前冥思苦想出来的而是过去两个月里每一次 Claude “又犯了那个错”之后我立刻打开文件删掉一句模糊的描述补上一条具体的、可执行的指令日积月累而成的。2.1 区块一核心身份与绝对红线必须放在最前面这是整份文档的“宪法序言”必须开门见山用最简练的语言定义 Claude 在这个项目里的角色和底线。它决定了 Claude 的整个工作基调。# 项目身份与绝对红线 - 你是一位资深全栈工程师熟悉 Node.js (v20)、TypeScript (v5.4)、NestJS 和 PostgreSQL。 - 你**绝不**使用 throw new Error() 处理业务逻辑错误。所有业务错误必须封装为 ResultSuccess, Failure 类型。 - 你**绝不**在业务代码中使用 console.log。所有日志必须通过 app/shared/logger 模块的 logger.info()/logger.error() 方法输出。 - 你**绝不**修改 app/shared 目录下的任何已有逻辑除非 spec 明确要求你重构该模块。注意这里的措辞。我没有写“请使用 Result 类型”而是用了“绝不使用throw new Error()”。正如前文所说“不要做什么”比“要做什么”更有效。Claude 的训练数据里充满了throw它需要一道非常明确、非常强硬的“防火墙”来阻止这个本能反应。我把这条放在最前面确保它在读取文档的第一毫秒就接收到最强信号。2.2 区块二核心约定与标杆文件提供可模仿的范式这一部分是“怎么做”的具体指南。它不讲抽象原则只提供最直接、最可复用的样板。Claude 是一个卓越的模式识别者它模仿一个好例子的能力远胜于理解一百句文字描述。# 核心约定与标杆文件 - **错误处理**严格遵循 app/shared/src/result.ts 中的 Result、Ok、Err 实现。所有服务方法返回 Result控制器层统一处理。 - **API 路由**NestJS 控制器必须继承 BaseController并使用 ApiResponse 装饰器。参考 app/modules/user/user.controller.ts。 - **单元测试**使用 Vitest。每个 .spec.ts 文件必须包含 describe、it 和 expect 断言。参考 app/modules/user/user.service.spec.ts。 - **依赖注入**所有服务必须通过 NestJS 的 Injectable() 和构造函数注入禁止全局变量或单例模式。这里的关键是“参考”二字。我给出的不是规则而是路径。Claude 在生成代码时会主动去读取这些标杆文件并精确地模仿其中的每一个细节ApiResponse的写法、describe的嵌套层级、expect的断言风格。这比你写十行文字描述“测试要覆盖 happy path 和 error path”要可靠得多。2.3 区块三常见错误持续更新的“防错清单”这是claude.md的心脏也是我投入精力最多、回报最高的部分。它不是一个静态列表而是一个动态的“错误日志”。每当我在 Claude 的输出里发现一个重复出现的、代价高昂的错误我就立刻把它加进来。# ⚠️ 常见错误请务必遵守 - ❌ 错误在 app/modules/* 下的服务中直接 import { logger } from winston。 ✅ 正确必须 import { logger } from app/shared/logger。 - ❌ 错误为数据库查询编写 try/catch并在 catch 中 throw new Error()。 ✅ 正确使用 Result.fromPromise() 包装查询并在 mapErr 中转换为 Failure。 - ❌ 错误在 user-service.ts 中将 userRepository.find() 的返回值直接赋值给一个 User[] 类型变量。 ✅ 正确必须使用 ResultUser[], Failure 类型并进行 match 处理。 - ❌ 错误在 user.controller.ts 中Post(/register) 的 handler 函数返回 void 或 any。 ✅ 正确必须返回 ResultUser, RegistrationError并由 BaseController 统一响应。这个区块目前有 7 条不多不少。每一条都对应一个我亲手踩过的坑。它的力量在于“具体”。它不谈“要写好测试”而是指出“不要在user.service.spec.ts的it块里漏掉await”。这种颗粒度让 Claude 的执行变得无比精准。而且因为它是基于真实错误构建的所以每一条都直击要害没有一句废话。2.4 区块四执行指令让 Claude 知道下一步该做什么最后一部分是给 Claude 的“行动指令”。它告诉 Claude当它完成当前任务后应该自动执行哪些验证步骤。这一步把“写代码”和“保证质量”无缝衔接起来避免了人工检查的疏漏。# ▶️ 执行指令每次生成后自动执行 - 生成代码后**必须**立即运行 pnpm lint 并修复所有错误。 - 生成测试文件后**必须**立即运行 pnpm test --run --testNamePatternyour-test-name 验证其通过。 - 修改任何 app/shared 相关文件后**必须**运行 pnpm test:shared 并确保 100% 通过。 - 所有新增的 API 路由**必须**在 app/modules/*/e2e/*.e2e-spec.ts 中添加对应的端到端测试。这个区块的效果立竿见影。以前我总要手动去跑测试现在只要看到 Claude 的回复末尾附上了✅ pnpm test --run --testNamePatternregister user success passed我就知道这段代码是可信的。它把质量保障变成了一个自动化流程的一部分而不是一个事后补救的动作。注意这个结构不是教条。你的项目可能不需要“执行指令”区块但一定需要“常见错误”区块。关键是理解每个区块的目的——身份定义基调标杆提供范式错误清单堵住漏洞执行指令闭环质量。3. 模型选择不是“越贵越好”而是“任务匹配度”决定效率天花板回到标题那个反直觉的结论“日常编码Opus 是最差的选择。” 这句话听起来很刺耳但它背后是一个经过两个月真实账单和生产力验证的深刻洞察模型选择的本质是任务分工而不是能力排名。把博士生派去干数据录入把实习生拉去主持架构评审结果都不会好。Claude 的三个主力模型——Haiku、Sonnet、Opus——正是这样三个不同定位的“人”。我当时的策略是“无脑用最好的”觉得 Opus 能力最强开着它肯定没错。结果两个月后账单比我预期高了将近一倍而我的实际编码速度却慢了下来。因为 Opus 在帮我写一个简单的表单验证函数时花了 3 秒钟思考“这个验证是否应该做成一个可复用的 Hook”又花了 2 秒钟分析“如果用户输入的是恶意 SQL 片段前端验证是否足够”最后才给我一个能跑的函数。而 Sonnet只用了 0.8 秒就给出了完全符合我需求的、一行不多一行不少的代码。我节省下来的 2.2 秒在一天几十次的微小任务中累积成了巨大的时间黑洞。3.1 Sonnet你的“高级工程师”负责 80% 的日常交付Sonnet 是我日常编码的绝对主力承担了我 80% 以上的任务。它的定位非常清晰一个执行准确、响应飞快、成本合理的高级工程师。它不擅长天马行空的创意也不喜欢过度设计但它对“已知需求”的实现堪称完美。适用场景CRUD 功能开发、API 路由生成、React/Vue 组件编写、单元测试补充、函数重构、类型定义补全、调试报错分析已知错误、JSDoc 注释添加。核心优势响应速度快通常 1stoken 成本低约为 Opus 的 1/3对明确指令的执行准确率极高。关键短板当遇到它不熟悉的领域时它有“假装会”的倾向。它会生成一段看起来语法完美、逻辑自洽但实际运行就会报错的代码。比如让我用一个我从未用过的数据库驱动写一个连接池配置它可能会编造出一个根本不存在的 API。我做过一个对比实验用同一个claude.md和同一个 Prompt让 Sonnet 和 Opus 分别写一个 Stripe 订阅取消的 API 路由。Sonnet 的输出是Delete(/subscriptions/:id) async cancelSubscription(Param(id) id: string) { const result await this.stripeService.cancelSubscription(id); return result.match({ ok: (sub) this.successResponse(sub), err: (e) this.errorResponse(e) }); }干净、利落、完全符合我的claude.md规范。而 Opus 的输出开头是长达 200 字的分析“考虑到 Stripe 的订阅生命周期管理我们需要区分canceled和incomplete_expired状态……建议引入一个SubscriptionStatus枚举……” 然后才是路由代码。我只需要一个能跑的路由不需要它帮我做产品决策。3.2 Opus你的“首席架构师”只在关键时刻出场Opus 不是不好是它太强大了强大到在大多数日常任务里它的能力是一种“过度杀伤”。它的价值只在那些需要“把所有角度想清楚”的战略性时刻才会真正爆发。适用场景全新系统架构设计、复杂技术选型如 GraphQL vs REST vs gRPC、大型业务逻辑拆分、深度 Bug 根因分析表现与原因隔着多层因果、进入一个完全陌生的技术领域时的“认知建模”。核心优势无与伦比的推理深度、全局视角、追问能力。它能帮你发现你根本没想到的风险点。关键短板响应慢通常 3-5stoken 成本高是 Sonnet 的 3 倍在简单任务上会产生大量冗余信息降低效率。我最有价值的一次 Opus 使用是在为一个出海 SaaS 设计多租户架构时。我问它“我们计划用 PostgreSQL 的schema方案实现多租户有哪些关键风险” Opus 没有直接给我代码而是列出了一个包含 7 个要点的分析报告其中两点让我拍案叫绝一是指出了pg_dump在多 schema 场景下备份恢复的复杂性二是提醒我如果未来要支持跨租户的报表查询schema方案会导致JOIN变得极其笨重建议提前规划tenant_id列的方案。这两点是我作为开发者完全没考虑到的。Opus 在这里扮演的不是一个写代码的工具而是一个经验丰富的 CTO。3.3 Haiku你的“超级助理”专治批量机械任务很多人把 Haiku 当成“穷人版 Claude”这是最大的误解。Haiku 的定位非常精准一个高速、低成本、专为简单、明确、重复性任务而生的执行引擎。它不适合思考但特别适合干活。适用场景CLI 批处理脚本如为 100 个文件批量添加 JSDoc、代码格式化微调、字符串替换、生成固定模板如 Dockerfile、CI 配置、简单数据转换。核心优势速度极快比 Sonnet 快 3-5 倍成本极低比 Sonnet 便宜 10 倍以上在明确指令下执行稳定。关键短板对项目上下文的“消化能力”极弱。如果你的claude.md写得很长、很复杂Haiku 很可能只执行了其中一半。它无法像 Sonnet 那样从一堆文字中推断出隐含的约束。我有一个 CLI 脚本需要为项目里所有.ts文件自动添加 JSDoc 注释。我最初用 Sonnet处理 30 个文件花了 12 秒花费了约 $0.03。换成 Haiku 后只用了 2.5 秒花费不到 $0.003。但这里有个关键技巧用 Haiku 时Prompt 必须极度明确。我不能只说“为这个文件添加 JSDoc”而必须说“请为以下 TypeScript 文件的getUserById函数添加 JSDoc 注释。注释格式必须严格遵循param id - 用户唯一标识符和returns ResultUser, UserNotFoundError。只输出修改后的完整代码不要有任何解释文字。” 加上最后一句“只输出代码”就完美避开了它偶尔会输出“以下是修改后的代码”这种导致语法错误的坑。实操心得我的工作流是“Opus 拆解 - Sonnet 实现 - Haiku 批量”。当需求模糊时先用 Opus 做一轮深度拆解产出一份清晰的spec然后关掉这个对话用 Sonnet 按spec逐条实现最后对于那些重复性的收尾工作如加注释、改文件名再开一个 Haiku 会话批量搞定。三者各司其职效率最大化。4. 工作流升级从“单点提问”到“Vibe-Coding”的工程化实践当你把claude.md写对了模型选准了接下来的瓶颈就不再是工具本身而是你如何组织自己的工作流。我曾经也陷入过“对着一个聊天窗口反复提问、反复修改”的低效循环。直到我借鉴了 SWE-agent 的理念将整个编码过程重新设计为一个以智能体为中心的、可验证、可迭代的工程化流程效率才实现了质的飞跃。这个流程的核心是将一个模糊的“我要做个功能”拆解为三个清晰、独立、可并行的阶段Plan规划、Spec设计、Code实现。它们不是线性顺序而是可以双开、甚至三开的并行窗口。4.1 Plan 窗口用 Opus 做“战略规划”产出可执行的路线图Plan 阶段的目标不是写出代码而是产出一份能让任何普通工程师甚至实习生都能按部就班执行的详细计划。这份计划就是你的plan.md。我通常会这样向 Opus 提问“我们有一个需求将用户注册流程从邮箱验证码改为手机号短信验证码。现有代码在app/modules/auth/下。请为这个需求制定一个详细的plan.md要求按照1. 分析影响范围、2. 列出待修改文件、3. 描述每个文件的具体修改点包括新增、删除、修改的代码行、4. 列出所有需要编写的单元测试、5. 列出所有需要编写的端到端测试的结构。每个修改点必须具体到函数名和关键逻辑例如‘修改auth.service.ts中的register函数将sendEmailVerification调用替换为sendSmsVerification并处理新的SmsVerificationError’。不要写任何代码只写计划。”Opus 会给出一份 2-3 页的plan.md。这份计划的价值在于它把一个模糊的需求转化为了一个可验证的、有明确终点的任务清单。它告诉你什么时候算“做完”了。我曾经做过一个判断如果一份plan.md你读完后能产生一种“这事儿交给一个靠谱的实习生他干一个月肯定能搞定”的感觉那这份 plan 就是合格的。4.2 Spec 窗口用 Humanize 插件做“设计确认”锁定最终形态Spec 阶段的目标是把plan.md里的每一条“修改点”转化为一份精确的、可验证的设计文档。它回答的问题是“这个功能到底要长成什么样子”我通常会用humanize插件配合一个精心设计的 Prompt让 Claude 基于plan.md生成spec.md。spec.md的格式我强烈推荐学习 Loom 项目的 spec format 。它的精髓在于“SIMT”Single Instruction, Multiple Threads思想不是让你一次性想出一个完美方案而是让 AI 同时探索多个可能性最后用一个明确的 CLI 测试来筛选。一个典型的spec.md片段是## 用户注册 API (POST /auth/register) - **输入**{ phone: string, password: string } - **输出**201 Created with { userId: string } OR 400 Bad Request with { code: INVALID_PHONE, message: 手机号格式不正确 } - **核心逻辑** - [x] 验证 phone 是否为合法中国手机号正则 /^1[3-9]\d{9}$/ - [ ] 调用 smsService.sendVerificationCode(phone) 发送验证码 - [ ] 创建用户记录状态为 PENDING_VERIFICATION - **测试用例** - pnpm test --run --testNamePatternregister with valid phone - pnpm test --run --testNamePatternregister with invalid phone这个spec.md的伟大之处在于它把“设计”和“验证”绑定在了一起。每一个[ ]后面的描述都对应着一个即将编写的、可运行的测试用例。当我看到spec.md里所有的[ ]都被打上了[x]并且所有列出的测试用例都通过了我就知道这个功能的设计已经锁定了可以进入实现阶段了。4.3 Code 窗口用 Sonnet 做“战术执行”严格按spec.md编码Code 阶段就是纯粹的、机械的、高精度的执行。我打开一个新的 Claude Code 会话把spec.md的全文粘贴进去并加上一句“请严格按照以上spec.md的要求为app/modules/auth/目录下的文件编写代码。只输出修改后的代码文件内容不要任何解释。”这时Sonnet 就像一个最听话的高级工程师它不会质疑spec.md的合理性也不会提出更好的方案它只会一丝不苟地、精准地把spec.md里描述的每一行代码都写出来。因为它知道spec.md是经过 Opus 战略规划和 Humanize 迭代确认后的最终产物它的唯一使命就是完美执行。我习惯于“双开”一个窗口是plan.md另一个窗口是code。我每次只让 Sonnet 实现plan.md里的一个最小单元比如“修改auth.service.ts中的register函数”。实现完成后我立刻运行pnpm test --run --testNamePatternregister with valid phone验证通过再继续下一个单元。这种“单步前进、即时验证”的方式让我彻底告别了“写完一大段代码一跑全崩”的噩梦。实操心得这个工作流的终极目标是让你的“人类时间”被完全填满。我的典型状态是左手边是plan.md规划中间是code实现右手边是spec.md设计。我每完成一个code小任务就去spec.md里打一个勾每打一个勾就去看一眼plan.md确认下一步该做什么。三个窗口轮流切换我的大脑始终处于高度专注的“心流”状态没有任何一分钟是浪费在等待、猜测或返工上的。5. 常见问题与排查技巧实录那些没人告诉你的“血泪教训”再完美的claude.md和工作流也无法避免在实战中遇到各种意想不到的状况。下面这些都是我过去两个月里从一次次失败、一次次调试、一次次崩溃中总结出来的独家经验。它们不是理论而是刻在骨子里的肌肉记忆。5.1 问题Claude 输出的代码里总是混杂着解释性文字导致文件被覆盖后直接报错现象你在 CLI 脚本里调用 Claude API让它为一个文件生成新代码。脚本执行后打开文件一看开头赫然写着“以下是根据您的要求修改后的user.service.ts文件”后面才是代码。tsc一跑直接报SyntaxError: Unexpected token 以下是。根因分析这是模型的“默认行为”。Claude尤其是 Haiku 和 Sonnet在生成代码时倾向于先做一个简短的说明再给出结果。它认为这是一种“礼貌”但在自动化脚本里这就是灾难。解决方案在 Prompt 的末尾必须、必须、必须加上一句斩钉截铁的指令“只输出纯代码不要任何解释、不要任何前缀、不要任何后缀、不要任何 Markdown 代码块符号。输出的内容必须是能直接写入.ts文件并被 TypeScript 编译器接受的合法代码。”我曾经以为加一次就够了结果发现有时候它还是会“手滑”。现在我的标准做法是在 Prompt 的开头和结尾各加一遍这句话。双重保险。进阶技巧在你的 CLI 脚本里加入一个简单的“清洗”步骤。在 Claude 返回结果后用正则表达式^.*?(|typescript|js|javascript).?\n([\s\S])去提取 代码块内的内容。如果没找到代码块则直接丢弃整个输出并报警。这比指望模型永远不犯错要可靠得多。5.2 问题Claude 在修改shared目录时总是“顺手”加一些它认为“有用”的新功能导致连锁反应现象你只想让 Claude 把user-service.ts里的一个函数改成异步的。结果它不仅改了函数还在app/shared/src/utils.ts里加了一个全新的asyncRetry工具函数并在user-service.ts里引用了它。你一跑测试整个shared模块的测试全挂了。根因分析Claude 的“优化本能”在作祟。它看到了一个可以“改进”的地方就忍不住动手。而shared目录的特殊性恰恰是claude.md里最容易被忽略的“上下文”。解决方案在claude.md的“核心身份与绝对红线”区块里必须有一条用加粗和感叹号强调的、不可动摇的规则❗ 绝对红线你绝不修改app/shared目录下的任何已有逻辑你只能阅读它、引用它、在spec明确要求时才允许重构它。任何对shared的修改都必须在plan.md和spec.md中被明确提及、讨论和批准。光有这条还不够。在每次让 Claude 修改涉及shared的文件时我的 Prompt 开头一定会加上“请再次确认本次任务不允许修改app/shared目录下的任何文件。你只能修改app/modules/user/下的文件。请严格遵守claude.md中的绝对红线。”这是一种“心理暗示”不断强化它的认知边界。5.3 问题Claude 的输出在不同会话间“失忆”同一个问题反复问它给出的答案不一致现象你昨天让 Claude 为一个 API 设计了错误响应格式它给出了{code: USER_NOT_FOUND, message: 用户不存在}。今天你让它为另一个 API 设计同样的格式它却给出了{error: USER_NOT_FOUND, detail: 用户不存在}。两个格式不统一前端要写两套解析逻辑。根因分析Claude 没有长期记忆。每个新会话它都是一个全新的、对项目一无所知的“人”。它不记得昨天发生了什么除非你把昨天的结论明确地、永久地写进claude.md。解决方案建立一个“共识沉淀”机制。每当 Claude 在某个设计点上给出了一个你认可的、高质量的答案比如那个错误响应格式立刻、马上把它写进claude.md的“核心约定”区块。把它变成一条正式的、不可更改的规范。例如我会在claude.md里加上- **API 错误响应**所有 HTTP 错误响应必须是 JSON 格式且必须包含 code字符串大写下划线和 message字符串两个字段。参考 app/modules/auth/auth.controller.ts 中的 handleAuthError 方法。从此以后这个问题就不再是“问 Claude”而是“查claude.md”。claude.md就是你和 Claude 之间所有重要共识的唯一、权威、永久的存储库。它不是一份文档而是一个活的、不断生长的“项目宪法”。5.4 问题Claude 在处理超长上下文如 272k tokens时性能急剧下降且费用翻倍现象你在一个超大型仓库里工作claude.md写得很精炼但你为了让 Claude 理解整个项目把package.json、tsconfig.json、nest-cli.json甚至几个核心的README.md都塞进了上下文。结果发现Claude 的响应变得异常缓慢而且账单上出现了很多意料之外的高额费用。根因分析这是 Anthropic 模型的一个已知限制。当上下文长度超过 272,000 tokens 时模型的性能会出现断崖式下跌同时Anthropic 会对这部分超长上下文收取双倍费用。这不是 bug是设计如此。解决方案严格控制上下文窗口。这是我的~/.codex/config.toml文件里的关键配置[model] model_context_window 272000这个配置强制 Codex 在发送请求前将上下文截断到 272k。但这只是治标。治本的方法是永远不要试图用“堆上下文”来弥补claude.md的不足。如果你觉得 Claude 总是“看不懂”问题 99% 出在claude.md写得不够好而不是上下文不够长。我的经验是一个写得好的claude.md800 字以内配合 3-5 个精准的标杆文件路径就能让 Claude 在 95% 的任务中表现出色。剩下的 5%是那些真正需要“全局视野”的复杂任务那时你才应该启动 Opus并准备好为此支付相应的费用和时间。最后一个血泪教训永远不要相信“Claude 会自己理解”。它不会。它只会忠实地、尽全力地执行你给它的每一条指令无论那条指令是清晰的还是模糊的是正确的还是错误的。claude.md的终极目的不是教会 Claude 什么而是教会你自己如何成为一个更清晰、更精准、更高效的“指挥官”。