Boris Cherny 已经不再自己给 Claude 发提示词了。
这不是网上那种疯传的转述。这是他本人的、有公开记录的原话："我不再自己给 Claude 发提示词了。我有些循环在跑，它们会向 Claude 发提示词、判断该怎么做。我的工作就是写这些循环。"他在多个公开场合都说过这句话：Sequoia 的一次演讲、Acquired 的一次访谈、Y Combinator 的 Startup School。而这句话背后的模式，才是这篇文章真正要讲的主题。不是技巧清单，不是功能列表。而是 Claude Code 的创造者本人日常实际使用它的具体方式，并且是依据他本人的公开陈述来核实的，而不是二手转述。
这就是完整的拆解：以 Cherny 实际说过的话为基础，再加上 Anthropic 自己为这款他亲手打造的工具所记录的最佳实践。
Claude Code 从一开始就没打算成为一个产品
要理解 Cherny 如何使用这个工具，得先理解它的来历，因为起源解释了背后的理念——而且这个故事比今天大多数使用者所知道的要有趣得多。
Claude Code 始于 2021 年，当时是一个 AI 安全对齐研究项目，而不是一个产品。它最初是一个粗糙的 VS Code 扩展，后来变成了一个名为 clide 的内部 CLI 工具，在 Anthropic 内部使用了多年，公司外部都没有人听说过。Cherny 于 2024 年 9 月加入这个项目，并在当年 12 月用两周的冲刺式开发重写了核心。2025 年 2 月的公开发布很低调，没有太多造势，得到的反应更多是耸耸肩，而不是兴奋。然后 Claude 4 发布了，采用率几乎一夜之间爆发。
他对自己这个工具现状的评价，直截了当："我们才完成了 1%。"
这个定位会影响你应该如何使用它。Cherny 描述的不是一个已经完成、有固定正确用法的产品。他描述的是一件仍在被积极重写的东西，而且是由一支用这个工具来构建这个工具的团队在重写。Claude Code 已经反复用 Claude Code 自身重写了很多次，这个自我改进的循环，甚至比"循环工程"（loop engineering）这个说法在公开场合被任何人使用还要早。这一点值得停下来想一想，因为它解释了很多新用户感到困惑的一件事：为什么这个工具的"正确"用法似乎一直在变。这不是做法不一致。而是一个连创造者自己都还在实时探索它真实能力的工具——并且正是用这个工具本身去探索的。
在成为产品之前，它作为内部研究工具度过的那几年，也解释了为什么下面的理念读起来比一般开发者软件显得格外有主见。大多数工具从第一天起，就是为了满足外部庞大用户群体那些相互竞争的需求而不断堆加功能。Claude Code 则是先积累了自己的理念——在一个解决自己问题的小团队内部——之后才需要去满足别人的工作流。这段历史恰恰说明，为什么值得花时间去真正吸收 Cherny 本人的使用模式，而不是泛泛的"AI 编码工具"建议。
核心转变：从写提示词到设计循环
Cherny 在公开场合说过的、关于实际使用 Claude Code 的最重要的一件事，就是上面那句关于循环的话。这句话值得拆开来看它在实践中到底意味着什么，而不只是一句可以引用的漂亮话。
提示词（prompt）是一条指令，发送一次，回答一次。循环（loop）是一个系统：它给 Claude 发提示词，评估返回的结果，决定下一步做什么，然后重复——整个过程不需要人在每一个周期之间插手。Cherny 所说的"我的工作就是写循环"，意思是他的时间花在设计那些生成和评估提示词的系统上，而不是自己一条一条地输提示词。
他已确认的日常工作流直接反映了这一点。手机是他主要的操作入口，而不是笔记本电脑键盘。同时有五到十个活跃会话在运行，每个都能派生出子 Agent（sub-agent）——有时一次几百个，做更有深度的任务时一晚上几千个。几十个循环在后台持续不断地运行：盯着 pull request、维护持续集成（CI）的健康、按照固定计划对反馈做聚类。这些例行程序会在服务器端持续运行，即使他的笔记本电脑已经合上。
对每个日常使用 Claude Code 的人来说，实际的收获是：这个工具的能力上限，不是由单条提示词写得多好决定的，而是由你如何设计一个围绕"发提示词—检查—重试"的重复自动化循环的系统决定的。
系统提示词里到底改了什么，为什么这很重要
Cherny 还直接谈过一个具体的技术决策，它揭示了他对"如何给 Claude 下指令"这件事的思考方式："我们为新模型删掉了 Claude Code 系统提示词里大约 80% 的内容，这就是我们学到的关于如何写系统提示词的经验。"
这次删减发生在 Opus 4.8 这一代模型上，系统提示词从大约 15,000 个字符缩减到大约 4,500 个字符，而在编码评估上没有任何可衡量的损失。根据 Anthropic 自己的上下文工程指南，这背后的教训是：一旦模型的能力足够强、能够行使真正的判断力，那些僵化、面面俱到的规则清单就不再必要了。规则变成了酌情判断。工具使用示例被设计成自文档化的界面所取代。事无巨细的前置上下文被渐进式披露（progressive disclosure）取代——信息只在某个具体场景真正需要时才会浮现，而不是默认在每一个会话里全部加载。
有一点值得如实写出来，因为它让这个故事的简单版本变得更复杂：当 Opus 5 发布时，独立开发者的测试发现，它实际的系统提示词比 Opus 4.8 的大约长了 72%。这不是对上面那个教训的否定，而是它更深层的一个版本。提示词在僵化的指令数量上缩小了，然后又以更丰富、更具体的参考资料形式增长——工作示例、测试套件、评估标准——这些正是一个真正更强的模型能充分利用的那类上下文。所以结论不是"越短永远越好"，而是：指令的量应该跟着具体某个模型实际需要的、能支撑它做出良好判断的内容走，而不是朝任何一个方向设定固定目标。
像 Anthropic 自己的团队那样写 CLAUDE.md
这直接关系到你应该如何组织自己的项目级指令。Anthropic 的官方文档对应该采用的心智模型说得很明确：把 Claude 想象成一个很聪明但非常新、而且患有失忆症的员工，需要明确的指令。
这个思路的实际含义如下。聪明意味着你不需要过度解释通用能力，它本来就在那里。新意味着它对你的项目历史或约定没有任何先验知识。失忆意味着每一次会话都从零开始，CLAUDE.md 是唯一能可靠地在会话之间传递上下文的东西。
Anthropic 文档中的建议是把这个文件保持在 200 行以内，一些最自律的团队甚至压到 60 行。判断某个内容是否应该放进这个文件的测试标准是：它是不是几乎每个会话都真正需要？还是只跟一小块、特定场景下的工作有关？通用的东西——构建命令、不可妥协的样式规则、测试预期、真正的护栏——应该放在根文件里。任何更狭窄的内容，都应该放在一个被导入的文件里，只有当某次会话的具体工作真的需要时才拉入上下文——使用工具直接支持的 @path/to/file 导入语法。
对于真正不能跳过的指令，Anthropic 内部的做法是使用明确的强调标记："IMPORTANT" 或 "YOU MUST"，并且只保留给少数几条规则——那些如果 Claude 漏掉了、代价真的会很高的规则。如果什么内容都用这种方式标记，那就完全失去了意义，因为一旦不加区分地使用，它就不再是一个有效的信号了。
Plan Mode：先理解，再动手
有一个值得融入你实际工作方式的具体行为模式：让 Claude 先做计划再执行，而不是直接跳到改动上。
这不只是一个功能开关，它反映了 Anthropic 自己的材料中描述的一个真实转变：新一代模型不需要像早期模型那样靠大量前置引导就能正确做计划，以至于有些团队报告说，已经不再需要为每个任务强制加一个显式的 plan mode 步骤了，因为模型自身的默认推理在行动之前就能产生一个连贯的计划。话虽如此，对于真正复杂的、涉及多文件的改动，先明确要求一份计划、在批准执行之前先审查它，仍然是一个非常有意义的检查点——它能在误解的需求扩散到十几个文件修改之前就把它拦住，而不是等它扩散之后才补救。
子 Agent 与并行工作
Cherny 已确认的工作流——在单个会话里跑几百个、有时几千个子 Agent——指向的是一个结构性能力，值得有意识地理解和使用，而不是无意中偶然碰上。
主 Agent 可以把一个复杂任务拆解成更小的部分，并派出子 Agent 去独立执行，每个子 Agent 在自己的上下文里工作，而不是全部在一个连续对话里争抢空间。这同时服务于两个目的。第一，它让那些会撑爆单个上下文窗口的工作，改由许多更小的窗口来分担。第二，它增加了一个真正的验证层：子 Agent 审查另一个 Agent 的输出时，检查的是它自己并未参与产出的一项工作——这在结构上比一个 Agent 刚写完作业就给自己打分要可靠得多。
具体到并行工作，git worktrees 可以让多个会话同时在独立的分支或目录上操作，一个会话进行中的改动不会干扰另一个。这正是 Cherny 所说的那种同时运行大量并发循环的底层机械基础——不是一个 Agent 跑得更快，而是很多 Agent 同时处理真正相互独立的各项工作。
grep 决策：一个"简单胜过花哨"的案例研究
Cherny 自己的团队有一个具体的、有据可查的技术决策，体现了一种值得内化的更广泛理念。Claude Code 放弃了用于代码库搜索的向量搜索和嵌入（embeddings），改用朴素的 grep 和 glob。他对结果的原话是："超过了所有其他方案。而且是大幅领先。"
这个教训可以推广到这一个具体决策之外。一个听起来更高级的解决方案——语义向量搜索——并不自动优于一个更简单的方案——grep——如果那个更简单的方案实际上与问题是高度匹配的。代码库有精确的语法、精确的函数名、精确的导入路径，这些正是 grep 擅长的那种精确、字面的匹配；而模糊的语义匹配反而可能因为给出"看似合理实则错误"的结果而把它破坏。
这对你应该如何配置自己的工作流带来的实际启示：不要因为默认"复杂就等于能力"，就去选听起来更复杂的工具或架构。先拿简单方案在你自己的真实用例上测一测。它往往是赢家；就算没赢，你也确认了那个更复杂的方案是靠实力赢得一席之地的，而不是被想当然地认定。
绝不让 Agent 给自己的作业打分
来自 Anthropic 自己的 harness 工程实践，有一条独立的、已确认的原则，和你应该如何组织自己 Claude Code 工作流中的任何验证步骤直接相关：生成和评估应该发生在真正独立的角色中，因为一个模型在同一轮产出中审查自己的输出时，往往会偏向正面评价，哪怕人类审查者一眼就能看出问题。
在实践中，这意味着写代码的那个 Agent，不应该是决定代码是否够格发布的那一轮。一个独立的评估步骤——最好能访问到生成 Agent 没有的东西，比如实际测试套件的输出、原始需求文档——能抓到自我评估会漏掉的问题。这与上面子 Agent 验证模式背后的原则是同一个，只不过它是作为一种通用纪律来应用，而不是一个具体功能。
投入度与上下文管理
对于跑长会话、高要求会话的人来说，理解如何直接表达投入度（effort）很重要。在提示词里加上 "ultrathink"，可以针对那一次特定响应发出最大推理深度的信号，同时不改变整个会话的全局设置。对于会话级别的自动工作流编排，把 effort 级别设到最高档位，会在整个会话中把深度推理与自动任务拆解结合起来——不过这要求模型真的支持那个 effort 档位，并不是同一个产品线里的每个模型都支持。
在长会话中，上下文管理本身就值得刻意关注。随着会话越跑越长，累积的上下文会开始稀释"当下什么才是真正重要的"这个信号——这正是臃肿的 CLAUDE.md 文件会造成的问题，只不过它是动态地发生在一个对话内部，而不是静态地发生在文件里。当一个真正的新工作阶段开始时，定期开一个新会话，而不是无限期地延长一个对话，是一项真实、实用的纪律，值得去执行，而不是想当然地认为上下文越多就越好。
一个实操例子：把这些原则用在一个真实任务上
为了让上面所有内容从抽象变得具体，这里展示这些原则是如何在一个真实、常见的任务上结合的：给一个已有代码库添加一个新功能，有相当的复杂度，涉及几个相互关联的文件，有一些现有测试，是一个不算小但也不算稀奇的变化。
首先，让 CLAUDE.md 已经就位：简短、通用，包含构建和测试命令、不可妥协的样式规则，没有任何情境化的东西堆在里面。这意味着会话一开始就自动加载了真实、相关的上下文，你不需要从头再解释一遍你项目的约定。
与其写一条又长又充满期望的提示词、把整个功能描述得事无巨细，不如描述目标，让模型自己的规划能力来处理拆解——这正是上文系统提示词讨论中"减少脚手架"理念的体现。对这么大一个任务，先明确要求一份计划，值得多花这一步：因为在这里发现被误解的需求，代价只是两分钟的修正，而不是后来花一个小时在多个文件里把改动拆开重来。
一旦计划看起来没问题，就让执行继续。如果任务自然地分成真正独立的部分——比如更新数据模型，和单独更新消费该模型的 UI——那就是子 Agent 拆解的自然候选：每个部分在各自的上下文里工作，而不是全部挤在一个连续对话里。
在把结果当作完成之前，单独跑一轮验证，而不是相信执行 Agent 自己报告的"一切正常"。这可以简单到开一个新会话，或者用一个只读权限的子 Agent，去检查实际的测试输出、以及对照原始计划的 diff——而不是接受来自同一个写出了代码的上下文里那句自信的"完成了"。
注意这次演示里缺了什么。没有花哨的工具。没有不寻常的配置。只是普通地应用了这些原则：真正复杂的工作先做计划，真正独立的部分用子 Agent 拆解，用分离的验证代替自我评估——就是贯穿前面所有内容的三个原则，只不过这一次是应用到一个具体任务上，而不是抽象地描述。
从一个人扩展到整个团队
上面描述的都是一个人如何有意识地使用 Claude Code 的做法。Cherny 自己已确认的工作流——每天几百个子 Agent，隔夜几千个——本身就已经是一种规模化：一个人调度着真正大量的并行自动化工作。但同样的原则也可以扩展到一个团队共同采纳这些做法，其中有几个具体注意事项值得直接点出来。
一旦团队里不止一个人在使用 Claude Code 针对同一个代码库工作，CLAUDE.md 就不再是一个私人偏好文件了。对它的修改，要采用你会应用到任何影响全团队工作流的共享配置上的那种审查纪律。某位同事在经历了一次令人沮丧的会话之后，加了一条一次性的"hotfix"指令，而且没有经过审查——这正是产生那些臃肿、自相矛盾、最终不再有人真正遵守的文件的确切机制。一个轻量级的审查步骤，哪怕只是在合并之前有另一个人看一眼 diff，就能在问题积累成真正的麻烦之前拦住相当大一部分。
验证纪律在团队规模下比单人用户时更加重要。当一个人既是自己 Agent 辅助工作的作者又是审查者时，至少还有一线可能他个人会抓到 Agent 漏掉的东西。但当团队依赖 Claude Code 的输出流经一个共享的审查流程时，前面说的评估分离原则就不再是可选项了——它是真正保护代码库的机制，防止一个 Agent 自信但错误的自我评估进入生产环境。因为另一种选择就是寄希望于某个忙碌团队的流程中，某个环节的某个人碰巧抓到了 Agent 自己没有标记的问题。
还值得为定期的 CLAUDE.md 审计明确指定负责人——这和任何共享的、不断积累的文档都适用的维护纪律是一样的。如果没有明确分配的负责人，这项工作往往会没人管，恰恰因为它不像构建失败那样会阻塞任何一项即时任务。而六个月里无人负责的堆加，最终产生出来的正是"通用适用性"原则从一开始就要防止的那种臃肿、矛盾的文件。
这些原则最容易被误用的地方
上面这些想法里有一小撮具体的误读会反复出现，值得直接点出来，因为每一种都有简单、具体的纠正方法。
把"用循环代替提示词"当作可以完全跳过理解任务的理由。 Cherny 自己的说法是，他的工作是写循环，而不是说他不再思考这些循环到底应该干什么。设计一个好的循环——好的成功定义、好的停止条件——仍然需要像写一条好提示词那样清楚地理解问题。循环替代的是重复的手动输入，而不是前期的思考。
把系统提示词缩减读成"总是给模型更少的上下文"。 本文前面那个 Opus 5 的反例，就是专门用来纠正这种误读的。真正的教训是：指令的量应该匹配某个具体模型真正需要的、能够支撑它行使良好判断力的量——有时候意味着更少的僵化规则罗列，有时候意味着更丰富、更具体的参考资料。因为"最新模型需要更少"就不加区分地削减上下文，是把一个细致的、针对特定模型的发现错误地当成了放之四海皆准的规则。
习惯性地把简单任务过度拆解成子 Agent。 子 Agent 拆解只有在面对真正大型、真正独立的工作时，才配得上它带来的这份复杂度。只是为了用这个模式，就把一个小的、紧耦合的改动硬拆成人为的子 Agent 片段，只会增加协调开销，却得不到在更大任务上那种能证明其合理性的好处。本文前面那个实操例子刻意只在各部分自然独立的地方使用了子 Agent，而不是不管任务大小、对每个任务都默认使用。
因为"新模型不再需要了"就跳过验证。 评估分离原则不是针对较弱模型的权宜之计，不会随着能力提升而变得不必要。它是关于自我评估的一个结构性事实：一个模型在产生输出的同一上下文里检查自己的工作，总是比独立检查更难发现自己的盲区——无论这个底层模型变得多强都是如此。这对人类审查者同样成立，而且不会因为审查者变得更聪明就不再成立。
真正值得养成的日常习惯
把上面所有内容收拢成一套具体、可操作的日常实践，真正践行 Cherny 所展示的方法，就是这个样子。
别再对待每个任务时都指望一条提示词第一次就能写对。改为设计一个循环
