给大家翻译了一篇文章，来自于外网博主的分享，关于《Claude Code 的最佳实践》，内容挺干的。

原文如下：

真正能让 Claude Code 强大 100 倍的最佳实践。先说明一下，这不是一篇入门文章。

核心概念：上下文就是一块白板
在讲任何技巧之前，你需要先理解一件事。
Claude 有一个上下文窗口，你可以把它想象成一块白板。你发的每条消息、Claude 读的每个文件、执行的每条命令，全都会被写到这块白板上。一旦白板写满了，Claude 的表现就会开始下滑：它会忘掉之前的指令，犯一些本不该犯的错误。
用好 Claude Code 的核心，就是管理好这块白板。
这篇文章后面讲的所有东西，都跟这个概念有关。读的时候请始终记住这一点。

一、给 Claude 提供可验证的测试用例
这是你能做的、对结果影响最大的一件事。
大多数人的做法是：描述自己想要什么，然后祈祷 Claude 能做对。这样一来，你就变成了唯一的质检员，每个输出都得自己盯着看。相信我，这种方式很快就会把人累垮。
真正有效的做法是这样的。
当你让 Claude 写一个验证邮箱的函数时，不要只说“写一个邮箱验证函数”。
你应该这样说：

“写一个验证邮箱是否合法的函数。用这些用例测试：hello@gmail.com 应该通过，hello @ 应该失败，@domain.com 应该失败。写完之后跑一下测试。”

这样 Claude 就能自己检查自己的工作，不需要你在旁边一直盯着。
同样的思路也适用于视觉类的任务。如果你想让 Claude 修改网站上一个按钮的样式，贴一张截图然后说：“照这个样子改，改完截个图，告诉我哪里还有差异。”
只要你给了 Claude 可以对照的东西，你就不再是唯一的反馈回路了。这能帮你省下大量时间。

二、先规划，再动手
这一点几乎是所有 Claude Code 新手都会踩的坑。
你有一个想法，描述了一下，Claude 立刻就开始写代码。十五分钟后你发现，它解决的根本不是你想解决的问题。
是不是很熟悉？
解决办法很简单：让 Claude 先想清楚再动手。
Claude Code 有一个叫 Plan Mode（规划模式）的功能。在这个模式下，Claude 只读文件、梳理结构，不写任何代码，不做任何修改，纯粹是在探索和理解。
真正有效的工作流是这样的：
第一步：进入 Plan Mode，让 Claude 读相关文件，理解各部分之间的关系。
第二步：让 Claude 写出一份完整的计划。需要改哪些文件？执行顺序是什么？哪里可能出问题？
第三步：你自己读一遍这个计划，觉得哪里不对就改。
第四步：切回正常模式，让 Claude 按照计划去执行。
第五步：让 Claude 用清晰的提交信息把代码提交上去。
这个过程开头可能多花十分钟，但能帮你省掉后面好几个小时的返工。
Boris（Claude Code 的开发者）说他的团队每个复杂任务都会走这个流程。他团队里有一个人甚至会让一个 Claude 写计划，然后再开一个 Claude 来审查这个计划，就像高级工程师做 Code Review 一样。他们就是这么认真地对待这一步的。

三、提示词要具体，越具体越好
Claude 确实能从上下文中推断出很多东西，但它读不了你的心。
当你说“给我的文件加测试”，Claude 会写测试。但它可能测的不是你关心的点，可能用了你讨厌的 mock，可能漏掉了真正重要的边界情况。
对比一下这两种写法：
模糊版：“给 auth.py 写测试。“
具体版：“给 auth.py 写测试，重点覆盖用户会话在请求中途过期的场景。不要用 mock。特别关注 token 看起来有效但实际已过期的边界情况。“
同样的任务，结果天差地别。
你也可以直接告诉 Claude 去哪里找线索。与其问“这个函数为什么行为这么奇怪”，不如说“翻一下这个文件的 git 历史，找出这个行为是什么时候引入的，以及为什么。”
前者 Claude 给你的是猜测，后者给你的是真正的答案。

四、用好 CLAUDE.md 文件
如果你经常用 Claude Code 但还没设置 CLAUDE.md 文件，你正在白白浪费一大块价值。
CLAUDE.md 是一个 Claude 在每次会话开始时都会读取的文件。你放在里面的内容，会影响 Claude 每一次跟你协作的方式。
想想那些你发现自己反复在说的指令，比如：

“永远用 ES modules，不要用 CommonJS”

“测试里不要用 mock”

“每次改完代码都跑一下 linter”

“我们的分支命名格式是 feature/工单号”

Boris 分享了一个他团队在用的模式，非常实用。当 Claude 犯了一个错误，你纠正了它之后，在对话结尾多加一句：
“更新你的 CLAUDE.md，确保下次不再犯同样的错。“
Claude 会自己写下这条规则。下次会话它就会自动遵守。随着时间推移，你的 CLAUDE.md 会变成一份活文档，让 Claude 越来越懂你的工作方式。
不过有一点要注意：保持精简。
如果你的 CLAUDE.md 膨胀到了 500 行，Claude 反而会开始忽略其中的重要规则，因为太多内容在争夺它的注意力。文件里的每一行都应该能回答一个问题：如果没有这一行，Claude 会犯错吗？如果答案是不会，就删掉它。

五、多会话并行，让多个 Claude 同时干活
这一点听起来太显而易见了，但大多数人从来没想过这么做。
你可以同时开多个 Claude Code 会话，每个会话处理不同的任务。
Boris 说这是他团队发现的最大生产力飞跃。团队里有人同时跑三到五个并行会话，用的是一种叫 git worktree 的东西（你代码库的多个独立工作副本，互不干扰）。
举个实际的例子。
会话 A 在写一个新功能。会话 B 在审查会话 A 刚写的代码。你把会话 A 的输出喂给会话 B，让它找边界情况和潜在问题，然后把反馈带回给会话 A。
一个 Claude 写代码，另一个 Claude 做审查。你得到的代码质量，比单个会话又写又审要好得多，速度也更快。
你也可以用这个思路来做测试。让一个会话先写测试用例，再让另一个会话写代码来通过这些测试。这就是测试驱动开发的思路，只不过重活都让 Claude 干了。

六、用 Subagent 保护你的上下文
回到前面说的白板概念。
当 Claude 调查一个问题的时候，它会读文件，有时候读很多文件。每读一个，白板就被填掉一块。等 Claude 研究完你的代码库准备开始写代码的时候，白板可能已经用掉一半了。
Subagent（子智能体）就是来解决这个问题的。
Subagent 是一个独立的 Claude 实例，它在自己的上下文窗口里做调查，然后把结果汇报回来，完全不占用你主会话的白板空间。
用法很简单，在任何调研任务里加上“use subagents”就行。
比如：“Use subagents to figure out how our payment flow handles failed transactions.”（用 subagent 调查一下我们的支付流程是怎么处理失败交易的。）
Subagent 会去读它需要的所有内容。你的主会话保持干净。等你拿到调查报告的时候，白板上还有大把空间让你去做真正的开发工作。
Boris 的团队甚至把权限审批请求交给一个由 Opus 4.5 驱动的 Subagent 来处理，它会扫描是否有可疑操作，安全的就自动放行。一旦你开始用 Subagent 来搭建工作流，能玩出来的花样远比你想象的多。

七、把重复操作封装成 Skill
如果有一件事你每天在 Claude Code 里做不止一次，就把它做成一个 Skill。
Skill 本质上就是一个保存好的工作流。你把步骤写一遍，起个名字，下次要用的时候直接调用名字就行。
Boris 的团队做了一个 BigQuery 的 Skill。团队里任何人都可以直接在 Claude Code 里跑数据分析查询，一行 SQL 都不用自己写。这个 Skill 在每个项目里都在复用。
给你一个今天就能上手的实际例子。
做一个 /fix-issue 的 Skill，让它自动完成以下流程：

读取 GitHub Issue → 在代码库里找到相关文件 → 修复问题 → 编写并运行测试 → 创建 Pull Request

你只需要输入 /fix-issue 447，Claude 就会把整个流程跑完。一条命令，零上下文切换。
Boris 的原则是：如果团队里有人每天做同一件事超过一次，就把它做成 Skill。这个原则值得借鉴。

八、给 Claude 原始数据，而不是你的解读
这一点是我读到的时候最意外的。
如果你把正确的信息指给 Claude，它完全有能力独立修复 Bug。
大多数人的做法是：用文字描述 Bug 是什么样的，然后看着 Claude 猜来猜去，纠正几轮，最终勉强修好。
更快的做法是：直接把实际的错误信息丢给 Claude，然后让开。
Boris 的团队接了 Slack 的 MCP。当 Slack 上有人报了一个 Bug，他们直接把那条消息贴给 Claude，然后说一个字：“fix”（修）。
不用描述，不用手把手带。Claude 自己读消息，自己定位问题，自己修。
或者他们会说“去修一下 CI 里挂掉的测试”，然后就走开了。他们不会告诉 Claude 是哪些测试挂了，也不会解释为什么挂了。Claude 自己搞定。
关键在于给 Claude 真实的信息来源：Slack 对话记录、错误日志、Docker 输出。给它原始数据，而不是你对问题的二手解读。
Claude 在读取分布式系统的日志、追踪问题出在哪里这方面，能力超乎你的想象。

九、及时清理上下文
你在一个 Claude 会话里干了一个小时。
先修了一个 Bug，然后问了一个跟另一个文件相关的问题，接着又回到那个 Bug，然后又问了一个完全不搭边的事情。现在整个会话乱成一锅粥，Claude 开始跑偏了。
这就是上下文污染，它会严重拖垮 Claude 的表现。
解决办法简单粗暴但确实有效：/clear
直接重置上下文。带着你已经学到的东西，重新写一个更好的提示词，从头开始。
大多数人不愿意这么做，因为感觉像是在丢弃进度。但一个干净的会话配上一条写得好的提示词，几乎每次都能跑赢一个乱七八糟的三小时旧会话。
一条值得记住的原则：如果你已经纠正了 Claude 两次，它还是没搞对，不要纠正第三次。清掉上下文，写一条更精准的起始提示词。
还有一个温和一点的版本叫 /compact，你可以告诉 Claude 在压缩上下文之前记住哪些内容。比如输入 /compact focus on the payment integration changes，它就会保留跟支付集成相关的重要内容，把其他噪音清掉。

十、善用检查点，大胆尝试
Claude 每做一次修改都会创建一个检查点，就像游戏里的存档点。
如果 Claude 走的方向你不喜欢，你可以回退到之前的任意一个检查点。你可以只恢复对话，只恢复代码，或者两个都恢复。
这会改变你对待风险的方式。
你不需要在 Claude 动手之前把每一步都仔细规划好，你可以直接说“试试这个激进的方案”。如果成了，很好。如果没成，回退就行，零损失。
检查点即使你关掉了终端也不会丢。你可以第二天回来，还能回退到昨天会话里的某个节点。
有一点需要知道：检查点追踪的是 Claude 做的修改，不包括其他进程做的修改。它不能替代 git，两个都要用。

十一、用高级提示词技巧榨干 Claude 的潜力
Boris 分享了一些他团队在用的提示词技巧，大多数人根本想不到还能这么玩。
当你觉得第一版修复做得比较平庸的时候：

“你现在已经完全了解了这个方案涉及的所有东西。把它扔掉，重新写一个优雅的版本。”

这招很有意思，因为 Claude 第一遍有时候会走捷径。在它已经完全理解问题之后再要求一个优雅版本，往往能得到比你一开始就要求“写好一点”更好的结果。
当你想在发布前做一轮压力测试的时候：

“对这些改动严格审查。问我每一个刁钻的问题。在我通过你的考核之前，不要提交 PR。”

角色反转。Claude 变成审查者，你来为自己的决策辩护。这个做法听起来有点奇怪，但它确实能抓到你自己会漏掉的问题。
当你想要证据证明改动是有效的：

“证明给我看这个改动是有效的。展示 main 分支和我的分支之间的行为差异。”

不要只是相信测试通过了就完事。让 Claude 把实际的差异演示出来。

十二、把 Claude 当成学习工具
大家把 Claude Code 当成一个产出代码的工具。但如果你用对了方法，它也是一个非常好的学习工具。
当你加入一个新的代码库时，你可以这样问 Claude：

“这个项目的日志系统是怎么工作的？”
“这个函数具体在干什么？为什么它调用的是这个方法而不是那个？”
“帮我走一遍用户登录的完整流程，从第一个请求到会话创建。”

这些问题你通常会去问一个资深工程师。Claude 回答得一样好，而且你问第二遍它也不会不耐烦。
Boris 的团队用 Claude 来生成 HTML 幻灯片，用可视化的方式解释不熟悉的代码。Claude 还能画 ASCII 架构图，展示系统各部分之间的连接关系。这两个功能听起来有点傻，但你真正试过之后就会发现，它们能让复杂的东西变得清晰的速度快得惊人。
还有一个间隔重复的学习技巧：你把自己对某个东西的理解讲给 Claude 听，Claude 会追问你问题，找出你理解断裂的地方，记下这些薄弱点，过一段时间再回来考你。这是一套完全在 Claude Code 里搭建的学习工作流。

原文地址：x.com/Meer_AIIT/status/2027509711722188976

#科技先锋官##How I AI#