Claude Code最佳实践：来自真实生产环境的经验

[运营者视角] 我在两家企业里每个工作日都在用Claude Code——一个是咨询品牌，一个是Pickleland，德克萨斯州Pflugerville的一个匹克球场地——用途从这个博客的发布流水线到生产环境Worker上的代码审查，无所不包。这不是一篇介绍Claude Code是什么的入门文章。这是我用了几个月之后保留下来的习惯，也是那些因为代价大于收益而被我放弃的习惯。

目录

展开目录

• 把CLAUDE.md写成规则，而不是文档
• 什么交给子代理，什么留在自己的主线程
• 上下文管理是日常纪律，不是一次性设置
• 我学到的:哪些事不能让它自己做主
• 上线前先核实——Claude的”完成了”是一句断言,不是事实
• 运营者的结论
• FAQ
  • CLAUDE.md文件里到底应该放什么?
  • 你怎么决定什么时候可以信任Claude Code的输出而不用再核实?
  • 你会让Claude Code自己提交和推送吗?
  • 哪一个习惯为你省下的时间最多?

把CLAUDE.md写成规则，而不是文档

我写的每一版CLAUDE.md，最初都太长，而且每一版都随着时间变短，从没变长过。常见的错误是把它当成维基页面来写——背景、理念、“我们为什么这么做”。Claude在每次会话中都会读完整个文件，不管当前任务是否用得上那段细节，所以每一段不是指令的文字，都在和真正的指令抢注意力。

经过反复精简后留下来的东西更窄：硬性规则，最好是由测试来强制执行的那种，这样它们就不会悄悄地失效；再加上指向更长文档的链接，留给那些真正需要细节的场景。“标题控制在60个字符以内”值得一行字。这个限制为什么存在的来龙去脉，值得一个指向文档的链接，而不是塞进Claude每次会话都要重读的那个文件里的一整段。

我加的第二样东西，也是我没想到会这么重要的一样：一份简短的”已确定事实”清单，只写一次，并明确指示不要再重新调查。早期，Claude Code每隔几次会话就会重新诊断同一个假警报——一个不稳定的检查项，一个构建步骤里已知的怪癖——白白烧掉上下文，去重新推导一个我早就得出的结论。写一行声明这个已验证的事实、并告诉智能体直接往下走而不是重新展开调查，就把这种空转时间几乎降到了零。我用的规则是：如果同一句”其实这是预期行为”你已经解释过两次，它就该以事实的身份写进CLAUDE.md，而不是第三次在聊天里重新打一遍。

什么交给子代理，什么留在自己的主线程

关于技能、斜杠命令和子代理的完整决策框架我已经单独写过了，这里不再重复。值得补充的是我在生成子代理之前实际使用的运营层面的过滤标准：我能不能用一句话说清楚”完成”是什么样子，如果中间步骤留在我的主线程里，我真的会去读吗？

如果两个问题的答案都是否——任务是有边界的，我只想要结果——那就交给子代理。把这篇文章翻译成12种语言就是最清晰的例子：每份译文都可以独立核实，这种并行分发正是内容流水线为什么按语言各派一个子代理的原因——我绝不希望12种语言的中间往返把我还在判断英文原稿对不对的那条线程搅乱。

如果任务需要我实时跟着推理过程走——比如一次schema改动，其中第三个决定取决于第二个决定揭示了什么——那它就留在我的主线程里。我真正踩过的失败模式是：明明是这种任务，还是派了个子代理出去，拿回一份干净的摘要，然后三次追问”等等，你到底发现了什么”,因为摘要恰好丢掉了那个唯一重要的细节。同一类任务上这种情况出现两次，我就不再把它委派出去。

上下文管理是日常纪律，不是一次性设置

CLAUDE.md是大家写一次就忘掉的部分。上下文窗口才是我每次会话都要管理的部分,也是真正决定结果好坏的那个变量。

• 先读再让它改。 Claude Code很乐意针对一个它没见过完整当前状态的文件提出修改建议。我总是先让它读文件,哪怕我自认为很清楚里面写了什么——我在这种”自认为清楚”上栽过太多次跟头,这一步已经不再是可选项。
• 不要让一次会话干两件不相关的活。 一个花了一小时调试部署问题、然后转向写营销文案的线程,会把那一小时不相关的工具输出拖进接下来的每一次回复里。我会开一个新会话,而不是让Claude”忘掉部署那档子事”——这种指令并不会删掉那些token,它只是让模型去忽略它们,而模型做得并不彻底。
• 先规划再让它执行。 对于任何超过两三步的事,我都先要计划,并在批准执行之前读完它。读一份五行的计划只要十五秒。等第五步都跑完了才发现第三步是错的,要搭进去一整个下午。
• 大段粘贴是成本,不是方便。 只有三行有用的时候,把整个日志文件或完整的API响应扔进对话,是在为剩下的97%内容白白烧上下文。我会先grep,再粘贴匹配到的那部分。

这和AI智能体的上下文工程背后是同一个原理——Claude Code只是把这个成本更早地摆在了明面上,因为是你亲眼看着上下文实时被填满,而不是事后在某个Worker日志里排查。

我学到的:哪些事不能让它自己做主

每一个不可逆的动作——提交、推送、发布、发送、花钱——都停在一个我亲自执行的明确批准环节之后,绝不会是Claude Code自己判断任务完成就擅自采取的动作。这和我在任何智能体触及真实后果的地方都会用的人工介入模式是同一套,Claude Code不会因为它跑在我自己的机器上而不是云端就成为例外。

我停止做的另一件事:给破坏性命令开出宽泛、长期有效的许可。rm -rf、强制推送、跳过测试钩子——这些都不会得到一个笼统的”可以”。每一次都要在当下的上下文里单独申请,因为唯一一次我为了”省时间”提前批准了一个宽泛的许可,恰恰就是任务偏离到我根本没真正审查过的范围的那一次。一个权限确认弹窗要花的那五秒钟,是对抗那种后果的廉价保险。

上线前先核实——Claude的”完成了”是一句断言,不是事实

这是回报最大的一个习惯,也是最不起眼的一个:我不相信完成报告。我会亲自跑一遍真正的检查。

Claude Code会告诉你构建成功了、测试套件全绿了、链接能打开。有时候这份报告确实是根据真实输出生成的。有时候它是对一个只跑了一半的命令、或者一个提前返回、里面什么有用信息都没有的检查项,给出的一份自信满满的总结。这两种情况在聊天记录里看起来一模一样。唯一能分辨的办法,就是自己去看真实的输出——这和我用来交付智能体的评测框架背后是同一套纪律:一项任务不是因为智能体说完成了就算完成,而是当定义好的检查真的通过了才算数。

具体做法是:自己跑一遍构建命令,读它的真实输出,而不是Claude的转述。打开它说自己改过的那个文件。点开它说能打开的那个链接。针对内容,我尤其会带着挑刺的态度,对照那些我知道会被强制检查的规则重新审读一遍草稿——长度限制、禁用的表达模式、失效的站内链接——而不是相信Claude第一次就全部应用对了,因为它大多数时候确实做对了,偶尔没做对,而偶尔的失误一旦上线到真实网站,代价要比重新审读多花的那九十秒高得多。

运营者的结论

这一切都不是关于随着时间推移对Claude Code信任得更少——而是要精确划定这份信任到底该在哪里被真正挣得。简短、可执行的CLAUDE.md,胜过冗长的文档。有边界、可核实的工作交给子代理,推理过程和结果同样重要的一切留在自己的线程里。新鲜的上下文,胜过一个被拖得太长的会话。在任何无法撤销的事情上设置批准关卡。还有一项真正的检查,由你自己读过,才能让任何委派出去的东西上线。清单就这些,而且是我真正在执行的清单。

FAQ

CLAUDE.md文件里到底应该放什么?

智能体在每次会话中都必须遵守的规则,写成指令的形式——而不是代码库为什么变成现在这样的背景说明。如果一条规则是由测试强制执行的,那就明说,让测试成为事实来源。更长的背景信息应该放进CLAUDE.md链接指向的文档里,只有任务真正触及那个领域时才去读,而不是默认在每次会话中都重新加载。

你怎么决定什么时候可以信任Claude Code的输出而不用再核实?

我从来不是决定跳过检查——我是在衡量检查的成本有多高。自己跑一遍构建命令几乎不花什么成本,所以我总会跑。对一篇长文档做一次完整的、带挑刺态度的重新审读要花更多时间,所以我把它留给要面向真实受众的内容。唯一从不跳过的一类:任何不可逆的事——发布、提交、花钱。

你会让Claude Code自己提交和推送吗?

不会。每一次提交、每一次推送都是我自己在看完diff之后执行的。Claude Code提出修改建议;我是任何要脱离草稿状态的东西的批准关卡,这和我用在其他每一个智能体身上的规则是一样的。

哪一个习惯为你省下的时间最多?

把完成报告当作一句断言,而不是事实,自己去跑真正的检查。听起来像是会拖慢一切。但实际上恰恰相反——用三十秒抓到一个假的”完成了”,比三天后在生产环境里发现它要快得多。

---

相关文章： Claude 技能、斜杠命令与子代理的区别 · 我用来运行30个以上生产Agent的技术栈 · 人机协同 AI 代理：何时该搭建批准关卡 · 如何使用Claude的定时任务

想在自己的企业里也这样运行Claude Code？ 我的AI Agents for Beginners课程涵盖了这套打法所假设你已经掌握的构建基础。协作项目是我以结构化小组的形式教授这些运营习惯的地方。如果你更希望直接让我帮你把设置搭好，预约一次30分钟的会谈。