Claude Code 最佳实践:从环境配置到并行协作
官方原文: https://code.claude.com/docs/en/best-practices
关于充分利用 Claude Code 的技巧和模式,从环境配置到跨并行会话扩展。
Claude Code 是一个 agentic coding environment。它不同于回答后等待的聊天机器人:它能读取文件、运行命令、修改代码,并在你观察、纠偏或暂时离开时自主推进问题。
这改变了你的工作方式。你不再自己编写代码然后请 Claude 审查,而是描述你想要什么,Claude 来想办法构建它。Claude 会探索、规划和实现。
但这种自主性仍然存在学习曲线。Claude 在你需要理解的某些约束下工作。
本指南涵盖了在 Anthropic 内部团队和使用 Claude Code 的工程师中被证明有效的模式,适用于各种代码库、语言和环境。关于 Agent 循环在底层如何工作,请参阅 Claude Code 工作原理。
大多数最佳实践基于一个约束:Claude 的 Context Window 很快就会填满,而且随着填满性能会下降。
Claude 的 Context Window 存储你的整个对话,包括每条消息、Claude 读取的每个文件和每个命令输出。然而,这会很快填满。一个调试会话或代码库探索可能会生成和消耗数万个 Token。
这很重要,因为随着上下文填满,LLM 性能会下降。当 Context Window 快满时,Claude 可能开始"忘记"早期指令或犯更多错误。Context Window 是最重要的资源,需要管理。要了解会话在实践中如何填满,请观看交互式演示,了解启动时加载的内容以及每次文件读取的成本。使用自定义状态栏持续跟踪上下文使用情况,并查看减少 Token 使用了解减少 Token 使用的策略。
让 Claude 能够验证自己的工作
包含测试、截图或预期输出,让 Claude 能够自我检查。这是你能做的最高杠杆的事情。
当 Claude 能够验证自己的工作时,表现会显著提升——运行测试、比较截图、验证输出。
没有明确的成功标准,它可能会产出看起来正确但实际上不工作的东西。你成为唯一的反馈循环,每个错误都需要你的关注。
| 策略 | 之前 | 之后 |
|---|---|---|
| 提供验证标准 | "实现一个验证邮箱地址的函数" | "编写一个 validateEmail 函数。测试用例:user@example.com 为 true,invalid 为 false,user@.com 为 false。实现后运行测试" |
| 可视化验证 UI 更改 | "让仪表盘更好看" | "[粘贴截图] 实现这个设计。对结果截图并与原图对比。列出差异并修复" |
| 解决根本原因,而非症状 | "构建失败了" | "构建失败,错误信息:[粘贴错误]。修复它并验证构建成功。解决根本原因,不要只是压制错误" |
UI 更改可以使用 Chrome 扩展中的 Claude 进行验证。它会在你的浏览器中打开新标签页,测试 UI,并迭代直到代码正常工作。
你的验证也可以是测试套件、linter 或检查输出的 Bash 命令。投入精力让你的验证坚如磐石。
先探索,再规划,然后实现
将研究和规划与实现分离,以避免解决错误的问题。
让 Claude 直接开始实现,可能会解决错的问题。使用计划模式把探索与执行分开。
推荐的工作流程有四个阶段:
1. 探索
进入计划模式。Claude 读取文件并回答问题,不做任何更改。
读取 /src/auth,了解我们如何处理会话和登录。
同时看看我们如何管理环境变量中的密钥。2. 规划
请 Claude 创建详细的实现计划。
我想添加 Google OAuth。哪些文件需要更改?
会话流程是怎样的?创建一个计划。按 Ctrl+G 在文本编辑器中打开计划,可以在 Claude 继续之前直接编辑。
3. 实现
退出计划模式,让 Claude 按计划实现并自行验证。
按照你的计划实现 OAuth 流程。为回调处理器编写测试,
运行测试套件并修复所有失败。4. 提交
请 Claude 带有描述性消息地提交并创建 PR。
用描述性消息提交并创建 PR计划模式很有用,但也会增加开销。对于范围明确且修复较小的任务(如修复拼写错误、添加日志行或重命名变量),直接让 Claude 做。当你不确定方法、更改涉及多个文件、或你不熟悉被修改的代码时,规划最有用。如果你能用一句话描述 diff,就跳过计划。
在提示词中提供具体上下文
你的指令越精确,需要的修正就越少。
Claude 可以推断意图,但它读不了你的心思。引用具体文件、提及约束、指向示例模式。
| 策略 | 之前 | 之后 |
|---|---|---|
| 限定任务范围。 指定哪个文件、什么场景和测试偏好。 | "为 foo.py 添加测试" | "为 foo.py 编写一个测试,覆盖用户已登出的边缘情况。避免使用 mock。" |
| 指向来源。 引导 Claude 找到能回答问题的来源。 | "为什么 ExecutionFactory 的 API 这么奇怪?" | "查看 ExecutionFactory 的 git 历史,总结它的 API 是如何演变的" |
| 引用现有模式。 指向代码库中的模式。 | "添加一个日历组件" | "看看现有组件在首页是如何实现的,了解模式。HotDogWidget.php 是一个好例子。按照模式实现一个新的日历组件,让用户可以选择月份并前后翻页选择年份。从头开始构建,不使用代码库中已使用库以外的库。" |
| 描述症状。 提供症状、可能的位置和"修复"的样子。 | "修复登录 bug" | "用户报告会话超时后登录失败。检查 src/auth/ 中的认证流程,特别是 token 刷新。编写一个重现问题的失败测试,然后修复它" |
模糊的提示词在探索阶段很有用,你可以承受纠正方向的代价。像 "你会改进这个文件的什么?" 这样的提示词可以发现你没想到要问的东西。
提供丰富内容
使用
@引用文件、粘贴截图/图片,或直接管道输入数据。
你可以通过多种方式向 Claude 提供丰富数据:
- 使用
@引用文件,而不是描述代码在哪里。Claude 会在回复前读取文件。 - 直接粘贴图片。复制/粘贴或拖放图片到提示词中。
- 提供 URL 用于文档和 API 参考。使用
/permissions将常用域名加入白名单。 - 管道输入数据,运行
cat error.log | claude直接发送文件内容。 - 让 Claude 获取它需要的。告诉 Claude 使用 Bash 命令、MCP 工具或读取文件来自己获取上下文。
配置你的环境
几个设置步骤可以让 Claude Code 在所有会话中显著更有效。关于扩展功能的完整概述以及何时使用每种功能,请参阅扩展 Claude Code。
编写有效的 CLAUDE.md
运行
/init根据当前项目结构生成一个初始 CLAUDE.md 文件,然后随时间完善。
CLAUDE.md 是 Claude 在每次对话开始时读取的特殊文件。包含 Bash 命令、代码风格和工作流程规则。这给了 Claude 仅从代码无法推断的持久上下文。
/init 命令分析你的代码库以检测构建系统、测试框架和代码模式,给你一个完善的基础。
CLAUDE.md 文件没有必需的格式,但保持简短和人类可读。例如:
# 代码风格
- 使用 ES 模块 (import/export) 语法,不要用 CommonJS (require)
- 尽可能使用解构导入(例如 import { foo } from 'bar')
# 工作流程
- 完成一系列代码更改后务必进行类型检查
- 为了性能,优先运行单个测试,而不是整个测试套件CLAUDE.md 每个会话都会加载,所以只包含广泛适用的内容。对于仅偶尔相关的领域知识或工作流程,请使用技能。Claude 按需加载它们,不会使每个对话变得臃肿。
保持简洁。对于每一行,问自己:"删除这个会导致 Claude 犯错吗?" 如果不会,就删掉。臃肿的 CLAUDE.md 文件会导致 Claude 忽略你的实际指令!
| 包含 | 排除 |
|---|---|
| Claude 无法猜到的 Bash 命令 | Claude 通过读代码就能弄清楚的任何东西 |
| 与默认不同的代码风格规则 | Claude 已经知道的标准语言约定 |
| 测试说明和首选测试运行器 | 详细的 API 文档(改为链接到文档) |
| 仓库规范(分支命名、PR 约定) | 频繁变化的信息 |
| 项目特定的架构决策 | 长篇解释或教程 |
| 开发环境特殊要求(必需的环境变量) | 代码库的逐文件描述 |
| 常见陷阱或非显而易见的行为 | "编写干净代码"这样不言自明的做法 |
如果 Claude 尽管有规则但仍然做你不想要的事情,文件可能太长了,规则被淹没了。如果 Claude 问你 CLAUDE.md 中已经回答的问题,措辞可能有歧义。把 CLAUDE.md 当作代码:出错时审查它,定期精简它,通过观察 Claude 行为是否真的改变来测试更改。
你可以通过添加强调(如 "IMPORTANT" 或 "YOU MUST")来调整指令以提高遵从性。将 CLAUDE.md 提交到 git,这样你的团队可以贡献。文件的价值会随时间复合增长。
CLAUDE.md 文件可以使用 @path/to/import 语法导入额外文件:
参见 @README.md 了解项目概述,参见 @package.json 了解可用的 npm 命令。
# 附加说明
- Git 工作流程:@docs/git-instructions.md
- 个人覆盖:@~/.claude/my-project-instructions.md你可以在多个位置放置 CLAUDE.md 文件:
- 用户主目录(
~/.claude/CLAUDE.md):适用于全部 Claude 会话 - 项目根目录(
./CLAUDE.md):提交到 git 与团队共享 - 项目根目录(
./CLAUDE.local.md):个人项目特定笔记;将此文件添加到.gitignore以不与团队共享 - 父目录:适用于 monorepo,
root/CLAUDE.md和root/foo/CLAUDE.md会自动加载 - 子目录:Claude 在处理这些目录中的文件时按需加载子 CLAUDE.md 文件
配置权限
使用自动模式让分类器处理审批,使用
/permissions将特定命令加入白名单,或使用/sandbox进行操作系统级隔离。每种方式都在保持控制的同时减少中断。
默认情况下,Claude Code 会为可能修改系统的操作请求权限:文件写入、Bash 命令、MCP 工具等。这是安全的但很繁琐。在第十次审批后,你已经不再真正审查了,只是在点击通过。有三种方式减少这些中断:
- 自动模式:一个单独的分类器模型审查命令,只阻止看起来有风险的操作:权限提升、未知基础设施或恶意内容驱动的操作。最适合当你信任任务的大方向但不想逐步点击时
- 权限白名单:允许你已知安全的特定工具,如
npm run lint或git commit - 沙箱化:启用操作系统级隔离,限制文件系统和网络访问,允许 Claude 在定义的边界内更自由地工作
使用 CLI 工具
告诉 Claude Code 使用
gh、aws、gcloud和sentry-cli等 CLI 工具与外部服务交互。
CLI 工具是与外部服务交互最节省上下文的方式。如果你使用 GitHub,安装 gh CLI。Claude 知道如何使用它创建 issue、打开 Pull Request 和读取评论。没有 gh,Claude 仍然可以使用 GitHub API,但未认证的请求经常遇到速率限制。
Claude 也很擅长学习它不了解的 CLI 工具。尝试这样的提示词:使用 'foo-cli-tool --help' 了解 foo 工具,然后用它来解决 A、B、C。
连接 MCP 服务器
运行
claude mcp add连接 Notion、Figma 或数据库等外部工具。
通过 MCP 服务器,你可以让 Claude 从 issue 追踪器实现功能、查询数据库、分析监控数据、集成 Figma 设计以及自动化工作流程。
设置 Hooks
对于必须每次都执行、零例外的操作,使用 Hooks。
Hooks 在 Claude 工作流程的特定点自动运行脚本。与建议性的 CLAUDE.md 指令不同,Hooks 是确定性的,保证操作会执行。
Claude 可以为你编写 Hooks。尝试这样的提示词:"编写一个 Hook,在每次文件编辑后运行 eslint" 或 "编写一个 Hook,阻止写入 migrations 文件夹。" 直接编辑 .claude/settings.json 来手动配置 Hooks,运行 /hooks 浏览已配置的内容。
创建技能
在
.claude/skills/中创建SKILL.md文件,为 Claude 提供领域知识和可复用的工作流程。
技能通过特定于你的项目、团队或领域的信息扩展 Claude 的知识。Claude 在相关时自动应用它们,或者你可以直接使用 /skill-name 调用它们。
通过在 .claude/skills/ 中添加包含 SKILL.md 的目录来创建技能:
---
name: api-conventions
description: 我们服务的 REST API 设计规范
---
# API 规范
- URL 路径使用 kebab-case
- JSON 属性使用 camelCase
- 列表端点始终包含分页
- API 在 URL 路径中进行版本控制(/v1/、/v2/)技能也可以定义你可以直接调用的可重复工作流程:
---
name: fix-issue
description: 修复 GitHub issue
disable-model-invocation: true
---
分析并修复 GitHub issue:$ARGUMENTS。
1. 使用 `gh issue view` 获取 issue 详情
2. 理解 issue 中描述的问题
3. 在代码库中搜索相关文件
4. 实现必要的更改来修复 issue
5. 编写并运行测试来验证修复
6. 确保代码通过 lint 和类型检查
7. 创建描述性的提交消息
8. 推送并创建 PR运行 /fix-issue 1234 来调用它。对于有副作用的工作流程,使用 disable-model-invocation: true,这样你需要手动触发。
创建自定义子 Agent
在
.claude/agents/中定义专门的助手,Claude 可以委派隔离任务给它们。
子 Agent 在自己的上下文中运行,拥有自己的一组允许工具。它们适用于读取大量文件或需要专门关注而不污染主对话的任务。
---
name: security-reviewer
description: 审查代码的安全漏洞
tools: Read, Grep, Glob, Bash
model: opus
---
你是一名高级安全工程师。审查代码中的:
- 注入漏洞(SQL、XSS、命令注入)
- 认证和授权缺陷
- 代码中的密钥或凭据
- 不安全的数据处理
提供具体的行引用和建议的修复。明确告诉 Claude 使用子 Agent:"使用子 Agent 审查这段代码的安全问题。"
安装插件
运行
/plugin浏览市场。插件无需配置即可添加技能、工具和集成。
插件将技能、Hooks、子 Agent 和 MCP 服务器捆绑成一个可安装单元,来自社区和 Anthropic。如果你使用类型化语言,安装代码智能插件,为 Claude 提供精确的符号导航和编辑后的自动错误检测。
关于在技能、子 Agent、Hooks 和 MCP 之间选择的指导,请参阅扩展 Claude Code。
有效沟通
你与 Claude Code 沟通的方式显著影响结果质量。
提出代码库问题
像问高级工程师一样问 Claude 问题。
在接触新代码库时,使用 Claude Code 进行学习和探索。你可以问 Claude 与问其他工程师相同类型的问题:
- 日志是如何工作的?
- 如何创建新的 API 端点?
foo.rs第 134 行的async move { ... }是做什么的?CustomerOnboardingFlowImpl处理哪些边缘情况?- 为什么这段代码在第 333 行调用
foo()而不是bar()?
以这种方式使用 Claude Code 是一种有效的入门工作流程,可以加快上手速度并减少对其他工程师的负担。不需要特殊提示词:直接提问。
让 Claude 采访你
面对较大功能,可先让 Claude 通过
AskUserQuestion工具向你逐项澄清需求。
Claude 会问你可能还没考虑到的事情,包括技术实现、UI/UX、边缘情况和权衡取舍。
我想构建 [简要描述]。使用 AskUserQuestion 工具详细采访我。
询问技术实现、UI/UX、边缘情况、关注点和权衡取舍。不要问显而易见的问题,深入挖掘我可能没考虑到的难点。
持续采访直到我们覆盖所有内容,然后将完整规格写入 SPEC.md。规格完成后,开始一个新会话来执行。新会话有干净的上下文,完全专注于实现,你有一个书面规格可以参考。
管理你的会话
对话是持久且可逆的。利用这一点!
尽早且频繁地纠正方向
一旦发现 Claude 偏离轨道就立即纠正。
最好的结果来自紧密的反馈循环。虽然 Claude 偶尔第一次就完美解决问题,但快速纠正通常能更快地产生更好的解决方案。
Esc:按Esc键在 Claude 操作中途停止。上下文被保留,你可以重定向。Esc + Esc或/rewind:按两次Esc或运行/rewind打开回退菜单,恢复之前的对话和代码状态,或从选定消息开始总结。"撤销那个":让 Claude 回退它的更改。/clear:在不相关的任务之间重置上下文。带有不相关上下文的长会话会降低性能。
如果你在同一个会话中对同一个问题纠正了 Claude 两次以上,上下文已经被失败的方法污染了。运行 /clear 并用一个融入你所学的更具体提示词重新开始。干净的会话加上更好的提示词几乎总是优于积累了大量修正的长会话。
积极管理上下文
在不相关的任务之间运行
/clear重置上下文。
Claude Code 在接近上下文限制时自动压缩对话历史,保留重要的代码和决策同时释放空间。
在长会话中,Claude 的 Context Window 可能充满不相关的对话、文件内容和命令。这会降低性能,有时会分散 Claude 的注意力。
- 在任务之间频繁使用
/clear完全重置 Context Window - 当自动压缩触发时,Claude 总结最重要的内容,包括代码模式、文件状态和关键决策
- 如需更多控制,运行
/compact <instructions>,如/compact 重点关注 API 变更 - 如需仅压缩部分对话,使用
Esc + Esc或/rewind,选择一个消息检查点,然后选择从此处总结或总结到此处。前者从该点向后压缩消息,同时保持早期上下文完整;后者压缩早期消息,同时完整保留最近的消息 - 在 CLAUDE.md 中自定义压缩行为,使用如
"压缩时,始终保留修改文件的完整列表和所有测试命令"的指令,确保关键上下文在总结中保留 - 对于不需要保留在上下文中的快速问题,使用
/btw。答案出现在可关闭的叠加层中,永远不会进入对话历史,这样你可以在不增长上下文的情况下查看细节
使用子 Agent 进行调查
委派研究任务:
"使用子 Agent 调查 X"。它们在单独的上下文中探索,保持你的主对话干净用于实现。
由于上下文是你的基本约束,子 Agent 是最强大的工具之一。当 Claude 研究代码库时,它读取大量文件,所有这些都消耗你的上下文。子 Agent 在单独的 Context Window 中运行并返回摘要:
使用子 Agent 调查我们的认证系统如何处理 token
刷新,以及我们是否有任何现有的 OAuth 工具可以复用。子 Agent 探索代码库,读取相关文件,并返回发现,完全不会污染你的主对话。
你也可以在 Claude 实现某些东西后使用子 Agent 进行验证:
使用子 Agent 审查这段代码的边缘情况使用检查点回退
你发送的每个提示词都会创建一个检查点。你可以将对话、代码或两者恢复到任何之前的检查点。
Claude 在每次更改前自动快照文件,以便检查点可以恢复它们。按两次 Escape 或运行 /rewind 打开回退菜单。你可以仅恢复对话、仅恢复代码、恢复两者,或从选定消息开始总结。
你不必仔细规划每一步,可以让 Claude 尝试一些有风险的操作。如果不行,回退并尝试不同的方法。检查点跨会话持久化,所以你可以关闭终端,稍后仍然可以回退。
警告:检查点只跟踪 Claude 做出的 更改,不包括外部过程。这不是 git 的替代品。
恢复对话
使用
/rename为会话命名,像对待分支一样:每个工作流都有自己的持久上下文。
Claude Code 在本地保存对话,所以当任务跨越多次会话时,你不必重新解释上下文。运行 claude --continue 恢复最近的会话,或 claude --resume 从列表中选择。给会话起描述性名称,如 oauth-migration,以便以后找到它们。
自动化和扩展
一旦你熟练使用一个 Claude,就可以通过并行会话、非交互模式和扇出模式来倍增你的输出。
到目前为止的一切都假设一个人、一个 Claude 和一个对话。但 Claude Code 可以水平扩展。本节中的技术展示如何完成更多工作。
运行非交互模式
在 CI、pre-commit hooks 或脚本中使用
claude -p "prompt"。添加--output-format stream-json获取流式 JSON 输出。
通过 claude -p "your prompt",你可以非交互地运行 Claude,无需会话。非交互模式是你将 Claude 集成到 CI 流水线、pre-commit hooks 或任何自动化工作流程的方式。输出格式让你可以程序化解析结果:纯文本、JSON 或流式 JSON。
# 一次性查询
claude -p "解释这个项目做什么"
# 脚本的结构化输出
claude -p "列出所有 API 端点" --output-format json
# 实时处理的流式输出
claude -p "分析这个日志文件" --output-format stream-json运行多个 Claude 会话
并行运行多个 Claude 会话以加速开发、运行隔离实验或启动复杂工作流程。
选择适合你想自己做多少协调的并行方式:
- 工作树:在隔离的 git 检出中运行单独的 CLI 会话,避免编辑冲突
- 桌面应用:可视化管理多个本地会话,每个在自己的工作树中
- Web 版 Claude Code:在 Anthropic 管理的云基础设施上,在隔离的虚拟机中运行会话
- Agent 团队:自动化协调多个会话,具有共享任务、消息传递和团队领导
除了并行化工作,多个会话还支持专注于质量的工作流程。干净的上下文可以改善代码审查,因为 Claude 不会偏向于它刚写的代码。
例如,使用编写者/审查者模式:
| 会话 A(编写者) | 会话 B(审查者) |
|---|---|
为我们的 API 端点实现一个速率限制器 | |
审查 @src/middleware/rateLimiter.ts 中的速率限制器实现。查找边缘情况、竞态条件以及与我们现有中间件模式的一致性。 | |
这是审查反馈:[会话 B 输出]。解决这些问题。 |
你可以用测试做类似的事情:让一个 Claude 编写测试,然后另一个编写代码来通过它们。
跨文件扇出
循环任务,为每个任务调用
claude -p。使用--allowedTools限定批量操作的权限。
对于大型迁移或分析,你可以将工作分发到多个并行的 Claude 调用中:
1. 生成任务列表
让 Claude 列出所有需要迁移的文件(例如 列出所有需要迁移的 2,000 个 Python 文件)
2. 编写脚本循环处理列表
for file in $(cat files.txt); do
claude -p "将 $file 从 React 迁移到 Vue。返回 OK 或 FAIL。" \
--allowedTools "Edit,Bash(git commit *)"
done3. 先在几个文件上测试,然后大规模运行
根据前 2-3 个文件出错的情况完善你的提示词,然后在完整集合上运行。--allowedTools 标志限制了 Claude 可以做的事情,这在无人值守运行时很重要。
你也可以将 Claude 集成到现有的数据/处理流水线中:
claude -p "<your prompt>" --output-format json | your_command在开发期间使用 --verbose 进行调试,在生产环境中关闭它。
使用自动模式自主运行
要在有后台安全检查的情况下进行不间断执行,请使用自动模式。分类器模型在命令运行前审查它们,阻止权限提升、未知基础设施和恶意内容驱动的操作,同时让常规工作无需提示即可进行。
claude --permission-mode auto -p "修复所有 lint 错误"对于带有 -p 标志的非交互运行,如果分类器反复阻止操作,自动模式会中止,因为没有用户可以回退。
避免常见的失败模式
这些是常见的错误。及早识别它们可以节省时间:
- 大杂烩会话。 你从一个任务开始,然后问 Claude 一些不相关的事情,然后又回到第一个任务。上下文充满了不相关的信息。
修复:在不相关的任务之间
/clear。 - 反复纠正。 Claude 做错了什么,你纠正它,它还是错的,你再次纠正。上下文被失败的方法污染了。
修复:两次失败的纠正后,
/clear并写一个融入你所学的更好初始提示词。 - 过度指定的 CLAUDE.md。 如果你的 CLAUDE.md 太长,Claude 会忽略一半,因为重要规则被噪音淹没了。
修复:无情地精简。如果 Claude 在没有指令的情况下已经正确地做了某事,删除它或将其转换为 Hook。
- 信任-验证差距。 Claude 产出了一个看起来合理的实现,但没有处理边缘情况。
修复:始终提供验证(测试、脚本、截图)。如果你无法验证,就不要发布。
- 无限探索。 你让 Claude "调查"某事但没有限定范围。Claude 读取了数百个文件,填满了上下文。
修复:将调查范围缩小或使用子 Agent,这样探索不会消耗你的主上下文。
培养你的直觉
本指南中的模式不是一成不变的。它们是通用的起点,但可能不是每种情况的最佳选择。
有时你应该让上下文积累,因为你深入在一个复杂问题中,历史是有价值的。有时你应该跳过规划,让 Claude 自己弄清楚,因为任务是探索性的。有时模糊的提示词恰好是对的,因为你想看看 Claude 如何解读问题再加以限制。
注意什么有效。当 Claude 产出优秀的输出时,注意你做了什么:提示词结构、你提供的上下文、你所在的模式。当 Claude 遇到困难时,问为什么。是上下文太嘈杂?提示词太模糊?任务太大一次无法完成?
随着时间的推移,你会培养出任何指南都无法捕捉的直觉。你会知道何时该具体、何时该开放,何时该规划、何时该探索,何时该清除上下文、何时该让它积累。
相关资源
- Claude Code 工作原理:Agent 循环、工具和上下文管理
- 扩展 Claude Code:技能、Hooks、MCP、子 Agent 和插件
- 常见工作流程:调试、测试、PR 等的分步指南
- CLAUDE.md:存储项目规范和持久上下文