Claude Code 最佳实践（利用这些让 Claude Code 强大 100 倍）:

Meer | AI Tools & News @Meer_AIIT

Claude Code 的最佳实践 (使用这些方法让 Claude Code 强大 100 倍)：

88 44K 大家好，欢迎回来

上次我写了一篇关于“Transformer 架构”的全面解析，反响非常热烈

你们中的许多人收藏、分享了它，并给我发消息说这是你们读过最清晰的解释

这种反馈对我来说意义重大

对于新来的朋友，我来快速介绍一下这个账号是关于什么的

这里不是我发布随机 AI 新闻并称之为内容的地方

我在这里发布的每一篇文章都有其目的

从将复杂的 AI 概念分解成初学者都能理解的内容，到对你每天使用的工具进行深度剖析

到目前为止，我已经涵盖了 Claude Skills、如何从零开始构建自己的技能、LangChain 初学者指南、MCP 等等

已经有 7 到 8 篇长篇文章了，每一篇都值得你花时间阅读

现在，我绝不妥协的一点是

如果我对某个主题不甚了解，我就不会撰写相关内容

我不在乎是否有 1000 人在询问

我会坐下来，从可靠来源认真学习，亲自测试，然后才向你解释

因为半生不熟的文章随处可见，你值得更好的内容

好的，今天我们来谈谈 Claude Code

具体来说：那些能让 Claude Code 真正提升 100 倍效用的最佳实践

在你开口说“我早就知道 Claude Code 了”之前，我要说明这不是一篇入门文章

你们现在都知道 Claude Code 是目前每个开发者最喜欢的工具了

作为一名软件工程师，我个人已经使用了近 3 个月

老实说，在最初的几周里，我并没有充分发挥它的潜力

今天，我将分享那些改变了我的实践方法

本文中的所有内容都经过官方文档记录，并由我个人测试过

我结合了两个来源：官方 Anthropic 最佳实践文档和 Claude Code 的实际创建者 Boris Cherny 分享的技巧

我完整阅读了这两份资料，所以你无需再费神

我会在文章末尾附上来源链接，但阅读完本文后，你真的不需要再去看它们了

让我们开始吧

你最大的敌人是上下文窗口（你可能不知道这一点）

在做任何事情之前，你需要理解一件事。

Claude 有一个上下文窗口。把它想象成一块白板。

你发送的每条消息。Claude 读取的每个文件。它运行的每个命令。所有这些都会写在这块白板上。一旦白板变得太满？Claude 就会开始表现变差。它会忘记之前的指令。它会犯平时不会犯的错误。

善用 Claude Code 的关键在于管理这块白板。

本文中的其他所有内容都与这一理念相关。阅读时请牢记这一点。

始终让 Claude 有办法检查自己的工作

这是你可以做到的、能获得更好结果的最重要的一件事。

大多数人描述了他们想要什么，然后就寄希望于 Claude 能做对。

这让你处于需要自己发现每一个错误的位置。相信我，这很快就会让人筋疲力尽。

以下是有效的方法。

当你让 Claude 编写一个函数来检查电子邮件是否有效时，不要只说“编写一个电子邮件验证函数”。

相反，你应该这样说：

“编写一个函数来检查电子邮件是否有效。用这些案例进行测试：hello@gmail.com 应该通过，hello@ 应该失败，@domain .com 应该失败。编写完成后运行测试。”

现在 Claude 可以检查自己的工作了。它不需要你对每个输出都进行“保姆式”看管。

同样的思路也适用于视觉方面。如果你想让 Claude 修改你网站上按钮的设计，粘贴一张截图，然后说“让它看起来像这样，然后截取结果图并告诉我有什么不同。”

如果你给 Claude 提供测试依据，你就不再是唯一的反馈循环了。这可以节省你数小时的时间。

不要再让 Claude 直接动手写代码了

这一点几乎让所有初次使用 Claude Code 的人都犯了错。

你有一个想法。你描述它。Claude 立即开始编写代码。十五分钟后，你意识到它完全解决了错误的问题。

听起来耳熟吗？

解决办法很简单。让 Claude 在行动前先思考。

Claude Code 有一个名为 Plan Mode 的功能。在 Claude 触及任何文件之前，它会先阅读并梳理事物。不编写。不修改。只是探索。

以下是真正有效的工作流程：

第 1 步：进入 Plan Mode。要求 Claude 读取相关文件并理解事物之间的联系。

第 2 步：要求 Claude 编写一份完整的计划。哪些文件需要更改？操作顺序是怎样的？哪些地方可能出错？

第 3 步：你自己阅读计划。如果发现有问题，进行编辑。

第 4 步：切换回正常模式，让 Claude 根据该计划进行构建。

第 5 步：要求 Claude 提交工作，并附上清晰的提交信息。

这在开始时可能需要多花十分钟。但它可以让你避免后续数小时的修正。

Boris（Claude Code 的创建者）说他的团队在处理每个复杂任务时都这样做。他团队中的一个人甚至让一个 Claude 编写计划，然后启动第二个 Claude 像高级工程师一样审查它。他们对这一步的重视程度可见一斑。

要具体，否则就是浪费时间

这里有一些值得了解的东西。

Claude 可以从上下文中推断出很多信息。但它无法读懂你的心思。

当你说是“为我的文件添加测试”时，Claude 会编写测试。但它们可能测试了错误的东西。它们可能使用了你讨厌的 mock。它们可能遗漏了真正重要的边缘情况。

比较这两个提示：

模糊的：“为 auth.py 添加测试”

具体的：“为 auth.py 编写测试，涵盖用户会话在请求中途过期的情况。不要使用 mocks。重点关注 token 看起来有效但实际上已过期的边缘情况。”

相同的任务。完全不同的结果。

你也可以直接指出 Claude 需要查看的位置。与其问“为什么这个函数表现得如此奇怪？”，不如说“查看此文件的 git 历史记录，找出此行为何时引入以及原因。”

这就是 Claude 给出猜测与 Claude 给出实际答案的区别。

你的 CLAUDE.md 文件比你想象的更强大

如果你经常使用 Claude Code，但还没有设置 CLAUDE.md 文件，那么你正在错失大量价值。CLAUDE.md 是 Claude 在每次会话开始时都会读取的文件。你在其中放置的任何内容都会影响 Claude 每次与你协作的方式。

想想你发现自己反复重复的指令。比如：

• “始终使用 ES 模块，而不是 CommonJS”
• “测试中不要使用 mocks”
• “完成更改后始终运行 linter”
• “我们的分支命名格式是 feature/ticket-number”

没有 CLAUDE.md 你会一遍又一遍地输入这些内容。有了 CLAUDE.md 你只需说一次。

Boris 分享了他的团队使用的一个真正有用的模式。在 Claude 犯了错误，你纠正它之后，在对话末尾添加一行：

“更新你的 CLAUDE.md 以便你不再犯这个错误。”

Claude 会写下自己的规则。下一次会话它会自动遵循该规则。随着时间的推移，你的 CLAUDE.md 会成为一个活文档，让 Claude 在与你协作方面变得更好。

但有一点需要注意。保持简洁。

如果你的 CLAUDE.md 变成一个 500 行的文档，Claude 会开始忽略其中的一部分，因为太多的内容在争夺注意力。文件中每一行都应该回答一个问题：如果这一行不存在，Claude 会犯错吗？如果答案是否定的，就删除它。

同时运行多个会话

一旦你听说这个，它会显得几乎太明显了，但大多数人从未想过这样做。

你可以同时运行多个 Claude Code 会话。每个会话同时处理不同的任务。

Boris 说这是他的团队发现的最大的生产力提升。他团队中的一些人同时运行三到五个并行会话，使用一种叫做 git work trees 的东西（你的代码库的独立工作副本，互不干扰）。

这是一个实际的例子，说明它是如何工作的。

会话 A 正在编写新功能。会话 B 正在审查会话 A 刚刚编写的代码。你将会话 A 的输出输入给会话 B，并要求它查找边缘情况和问题。然后你将会话 B 的反馈带回会话 A。

一个 Claude 编写。另一个 Claude 审查。你比单个会话同时做这两件事时能更快地获得更好的代码。

你也可以用这个来进行测试。先让一个会话编写测试。然后让另一个会话编写代码来通过这些测试。这与测试驱动开发背后的思想相同，只是 Claude 承担了所有繁重的工作。

使用子代理来保持主会话的整洁

回到前面提到的白板理念。

当 Claude 调查一个问题时，它会读取文件。有时会读取很多文件。每个文件都会更快地填满白板。当 Claude 完成对你代码库的研究并开始编写代码时，白板已经半满了。

子代理解决了这个问题。

子代理是一个独立的 Claude 实例，它在自己的上下文窗口中运行自己的调查。它会报告它发现的结果，而不会触及你主会话的白板。

使用方法很简单。只需在任何研究任务中添加“使用子代理”。

“使用子代理来弄清楚我们的支付流程如何处理失败的交易。”

子代理会读取它需要的所有内容。你的主会话保持干净。当你收到报告后，你仍然有足够的空间来用它实际构建一些东西。

Boris 的团队通过一个由 Opus 4.5 提供支持的子代理来处理权限请求，该子代理会扫描任何可疑内容并自动批准安全请求。一旦你开始使用子代理进行构建，你会发现事情可以深入到这种程度。

对于重复做的事情，创建技能

如果你在 Claude Code 中一天多次做某件事，请将其转换为一项技能。

一项技能基本上就是一个保存的工作流。你将步骤编写一次并给它一个名称。下次你想运行它时，只需调用其名称。

Boris 的团队为 BigQuery 设置了一项技能。团队中的任何人都无需编写一行 SQL 即可直接从 Claude Code 运行分析查询。这项技能在每个项目中都会被重复使用。

这是一个你今天就可以设置的实用例子。

一个 /fix-issue 技能，它可以自动执行以下操作：

读取 GitHub 问题 > 查找代码库中相关文件 > 进行修复 > 编写并运行测试 > 创建拉取请求

你输入 /fix-issue 447，Claude 就会处理整个事情。一个命令。零上下文切换。

Boris 使用的规则是：如果他的团队一天做某事不止一次，它就会成为一项技能。这是一个值得借鉴的好规则。

不要再微观管理，相信 Claude 能解决 Bug

当我读到这一点时，它让我感到惊讶。

如果你能将 Claude Code 指向正确的信息，它就能很好地完全自主修复 bug。

人们做事的无聊方式：用语言描述 bug。看着 Claude 猜测可能出了什么问题。纠正它几次。最终得到一个修复。

快速的方式：将实际的错误信息交给 Claude，然后放手不管。

Boris 的团队连接了 Slack MCP。当 Slack 上出现 bug 报告时，他们将帖子粘贴到 Claude 中，然后说一个词：“修复。”

没有描述。没有手把手指导。Claude 阅读帖子，发现问题并修复它。

或者他们会说“去修复失败的 CI 测试”，然后走开。他们不告诉 Claude 是哪些测试。他们不解释为什么它们会失败。Claude 自己会弄清楚。

关键是给 Claude 提供真实的信息来处理。Slack 帖子、错误日志、docker 输出。而不是你对哪里出了问题的解释。而是原始数据。

Claude 在读取分布式系统日志和准确追踪问题发生位置方面具有惊人的能力。

在会话崩溃之前修复上下文污染

你已经在 Claude 会话中工作了一个小时。

你修复了一个 bug。然后你问了一个与不同文件无关的问题。然后你回到 bug。然后你又问了别的问题。现在会话一片混乱，充满着半相关的对话，Claude 开始跑偏。

这就是上下文污染。它会严重影响性能。

解决办法很残酷但很有效：/clear

只需重置上下文。使用一个包含你所学到的内容的更好提示重新开始。

大多数人抵制这样做，因为感觉像是在抛弃进度。但一个干净的、有良好提示的会话几乎每次都会比一个混乱的三小时会话表现得更好。

值得遵循的规则是：如果你已经就同一件事纠正了 Claude 两次，而它仍然没有做对，不要第三次纠正它。清除上下文，重新编写一个更精确的起始提示。

还有一个更温和的版本叫 /compact，你可以告诉 Claude 记住会话中的什么内容，然后它会把其他所有内容都压缩掉。例如，/compact focus on the payment integration changes 可以在清除噪音的同时保留重要内容。

像玩电子游戏中的撤销一样使用检查点

Claude 每做一次更改，就会创建一个检查点。就像一个保存点。

如果 Claude 的方向你不喜欢，你可以回溯到任何之前的检查点。你可以只恢复对话。只恢复代码。或者两者都恢复。

这改变了你对风险的看法。

与其在 Claude 采取行动之前仔细规划每一步，不如直接说“尝试这种有风险的方法”。如果它成功了，那太好了。如果失败了，你就可以回溯并尝试其他方法。没有任何损失。

即使你关闭终端，检查点也会保留。你可以在第二天回来，仍然可以回溯到昨天会话中的某个点。

唯一需要知道的是：检查点跟踪的是 Claude 更改的内容，而不是其他进程更改的内容。它不能替代 git。两者都要使用。

挑战 Claude 让它表现得更好

Boris 分享了一些他的团队使用的提示技巧，大多数人可能从未想过尝试。

在一次平庸的修复之后：

“你现在已经了解了所有构成这个解决方案的东西。把它全部丢掉，构建一个优雅的版本。”

这很有趣，因为 Claude 有时在第一次尝试时会走捷径。事后要求它提供优雅版本，往往会产生比你一开始就要求它提供的东西更好的结果。

当你想要在发布前测试某物时：

“就这些更改对我进行盘问。问我所有难题。在我通过你的测试之前，不要打开 PR。”

你把角色反转过来。Claude 成为评审员，你必须为自己的决定辩护。这听起来很奇怪，但它能发现你可能会忽略的问题。

当你想要证明某事有效时：

“向我证明这有效。向我展示主分支和我的分支之间的行为差异。”

不要只相信测试通过了。让 Claude 展示实际的差异。

语音听写让你的提示词好三倍

这一点听起来与 Claude Code 完全无关，但它确实很重要。

当你输入提示词时，你倾向于让它简短。

打字很慢。你会偷工减料。你会遗漏那些实际上可以帮助 Claude 的上下文。

当你说话时，你会自然地提供更多细节。

你解释背景。你提到限制条件。你描述你真正想要什么。

Boris 的团队经常使用语音听写。

在 Mac 上，你可以通过双击功能键来启用它。

你自然地说话，它会转录。

通过说话获得的提示词几乎总是比通过打字获得的提示词更好，因为它们包含了 Claude 完成工作所需的更多上下文。

试一次，你可能就不会再回去了。

使用 Claude Code 真正学习知识

人们把 Claude Code 当作一个输出工具。但如果你用对了方法，它也是一个真正优秀的学习工具。

当你加入一个新的代码库时，你可以向 Claude 提出以下问题：

“这个项目中的日志是如何工作的？” > “这个特定函数到底做了什么？为什么它调用这个方法而不是那个方法？” > “请给我讲讲用户登录时会发生什么，从第一个请求到会话创建的整个过程。”

这些问题你通常会问高级工程师。Claude 也能同样很好地回答它们，而且你问同样的问题两次它也从不感到恼火。

Boris 的团队使用 Claude 生成 HTML 幻灯片，以可视化方式解释不熟悉的代码。Claude 还可以绘制系统不同部分如何连接的 ASCII 图。这两件事听起来都很傻，直到你真正尝试它们，并意识到它们能多快地使复杂事物变得清晰。

还有一种间隔重复的技巧，你可以向 Claude 解释你对某事的理解，然后 Claude 会提出后续问题，以找出你理解上的漏洞。它会存储这些漏洞，并在稍后回顾它们。这是一种完全在 Claude Code 中构建的学习工作流程。

导致会话失败的模式

以下是人们浪费数小时却未意识到问题所在的方式。

大杂烩会话。你从一个任务开始，然后转向五个不同的主题。上下文被与当前问题无关的东西填满。修复方法：在不相关的任务之间清除上下文。

纠错循环。Claude 做了错事。你纠正它。还是错的。你再次纠正。还是错的。上下文现在充满了失败的方法，Claude 对你真正想要的东西感到困惑。修复方法：在两次纠正失败后，清除所有内容，并编写一个更精准的起始提示。

臃肿的 CLAUDE.md。你的指令文件太长了，Claude 在噪音中迷失了重要的规则。修复方法：如果你不能回答“没有这一行 Claude 会犯什么错误？”，那么删除这一行。

无限探索。你要求 Claude 调查某事却没有给出范围。Claude 读取了数百个文件，在你开始构建之前，你的上下文就已经耗尽了。修复方法：为调查设定一个狭窄的范围，或使用子代理，以便探索在单独的上下文中进行。

以下是各来源的链接：

1. https://code.claude.com/docs/en/best-practices
2. https://x.com/bcherny/status/2017742741636321619?s=20 如果你想了解最新的 AI 新闻、工具和研究论文解析……请订阅我的免费新闻简报：

• 原文链接： x.com/meer_aiit/status/2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～