跳到正文

我如何使用 Claude Code 的每一项功能

Shrivu’s Substack作者：Shrivu Shankar
阅读 0—
打开原文

我使用 Claude Code 的所有方式的脑力倾泻。

本文目录文章开头

如果你对站在 AI 编程的前沿感兴趣，或者你的公司没有给你无限的 Claude Code 额度——我们正在招聘！

Abnormal Builder 的 Substack

实时 AI 构建的舞台。Abnormally。

由 Abnormal AI 出品

/plugin marketplace add abnormal-ai/claude-plugins
/plugin install careers-abnormal-ai@abnormal-ai
/careers-abnormal-ai

我使用 Claude Code。非常频繁。

作为一个业余爱好者，我每周会在虚拟机里运行它好几次来做副业项目，经常配合 --dangerously-skip-permissions 来随心所欲地编写任何我脑海中的想法。在工作中，我团队的一部分人负责为我们的工程团队构建 AI-IDE 规则和工具，仅代码生成每月就消耗数十亿个 token。

CLI 智能体领域正变得越来越拥挤，在 Claude Code、Gemini CLI、Cursor 和 Codex CLI 之间，感觉真正的竞争是在 Anthropic 和 OpenAI 之间。但说实话（TBH），当我与其他开发者交谈时，他们的选择往往取决于一些看似表面的东西——一个“幸运”的功能实现，或者一个他们就是更喜欢的系统提示词“氛围”。到了这个阶段，这些工具都已经相当不错了。我也觉得人们往往过度关注输出风格或 UI。比如对我来说，“你说得太对了！”这种谄媚并不是一个显著的 bug；它是一个信号，表明你介入得太深了。通常我的目标是“发射后不管”——委派任务，设定上下文，然后让它去工作。用最终的 PR 来评判工具，而不是它如何到达那里。

在过去几个月一直坚持使用 Claude Code 之后，这篇文章是我对 Claude Code 整个生态系统的思考总结。我们将涵盖我使用的几乎每一个功能（同样重要的是，还有那些我不用的），从基础的 CLAUDE.md 文件和自定义斜杠命令，到强大的 Subagents、Hooks 和 GitHub Actions 世界。这篇文章最终写得有点长，我建议把它当作参考手册，而不是从头读到尾的文章。

CLAUDE.md

在代码库中，要有效使用 Claude Code，最重要的单一文件就是根 CLAUDE.md。这个文件是智能体的“宪法”，是其了解你的特定仓库如何运作的首要事实来源。

你如何对待这个文件取决于具体情境。对于我的业余项目，我让 Claude 想往里写什么就写什么。

对于我的专业工作，我们单体仓库的 CLAUDE.md 是严格维护的，目前大小为 13KB（我很容易想象它会增长到 25KB）。

  • 它只记录被 30%（任意设定的比例）或更多工程师使用的工具和 API（否则工具会被记录在产品或库专属的 markdown 文件中）

  • 我们甚至开始为每个内部工具的文档分配一个有效的最大 token 数量，几乎就像向团队出售“广告位”一样。如果你不能简洁地解释你的工具，它就还没准备好进入 CLAUDE.md。

技巧与常见反模式

随着时间的推移，我们已经形成了一套强烈且有主见的理念，用于编写有效的 CLAUDE.md。

  1. 从护栏开始，而不是手册。你的 CLAUDE.md 应该从小处着手，根据 Claude 出错的地方来进行记录。

  2. 不要把 @ 文件当作文档。如果你在别处有大量文档，你可能会想在你的 CLAUDE.md 中 @ 提及那些文件。这会在每次运行时嵌入整个文件，从而膨胀上下文窗口。但如果你只是提及路径，Claude 往往会忽略它。你必须向智能体推销为什么以及何时去读该文件。“对于复杂的……用法，或者如果你遇到 FooBarError，请参阅 path/to/docs.md 以获取高级故障排除步骤。”

  3. 不要只说“绝不”。避免仅包含否定的约束，比如“绝不使用 --foo-bar 标志”。当智能体认为它必须使用该标志时，就会陷入困境。请始终提供替代方案。

  4. 将 CLAUDE.md 用作强制函数。如果你的 CLI 命令复杂冗长，不要写大段文档来解释它们。那是在修补人为造成的问题。相反，编写一个具有清晰、直观 API 的简单 bash 包装器，并为它编写文档。让你的 CLAUDE.md 尽可能简短，是简化代码库和内部工具的绝佳强制函数。

这是一个简化的快照：

# Monorepo

## Python
- Always ...
- Test with <command>
... 10 more ...

## <Internal CLI Tool>
... 10 bullets, focused on the 80% of use cases ...
- <usage example>
- Always ...
- Never <x>, prefer <Y>

For <complex usage> or <error> see path/to/<tool>_docs.md

...

最后，我们通过一个 AGENTS.md 文件同步此文件，以保持与工程师可能正在使用的其他 AI IDE 的兼容性。

如果你正在寻找更多关于为编码智能体编写 markdown 的技巧，请参阅 “AI 读不懂你的文档”， “AI 驱动的软件工程”， 以及 “Cursor（AI IDE）如何工作”。

要点：将你的 CLAUDE.md 视为一套高层次、经过精心策划的护栏和指引。用它来指导你在哪里需要投入更多对 AI（和人类）友好的工具，而不是试图把它变成一本全面的手册。

感谢阅读 Shrivu 的 Substack！免费订阅以接收新文章并支持我的工作。

压缩、上下文与清晰度

我建议在编码过程中至少运行一次 /context，以了解你如何使用 200k token 的上下文窗口（即使有 Sonnet-1M，我也不相信整个上下文窗口真的被有效利用）。对我们来说，在 monorepo 中开启一个新会话的基础开销约为 20k token（10%），剩下的 180k 用于进行你的更改——这可能会很快填满。

这是我最近一个副项目中 /context 的截图。你几乎可以把它想象成随着你开发功能而不断填满的磁盘空间。几分钟或几小时后，你需要清除消息（紫色部分）以腾出空间继续。

我有三种主要工作流：

  • /compact（避免）：我尽可能避免使用它。自动压缩不透明、容易出错，且优化不佳。

  • /clear + /catchup（简单重启）：我的默认重启方式。我 /clear 状态，然后运行一个自定义 /catchup 命令，让 Claude 读取我 git 分支中所有已更改的文件。

  • “记录并清除”（复杂重启）：用于大型任务。我让 Claude 将其计划和进度转储到一个 .md 中，/clear 状态，然后通过告诉它读取 .md 并继续来开始一个新会话。

要点：不要信任自动压缩。使用 /clear 进行简单重启，使用“记录并清除”方法为复杂任务创建持久的外部“记忆”。

自定义斜杠命令

我把斜杠命令视为常用提示词的简单快捷方式，仅此而已。我的设置非常精简：

  • /catchup：我之前提到的命令。它只是提示 Claude 读取我当前 git 分支中所有已更改的文件。

  • /pr：一个简单的辅助命令，用于清理我的代码、暂存它并准备拉取请求。

依我看，如果你有一长串复杂的自定义斜杠命令，你就制造了一种反模式。对我来说，像 Claude 这样的智能体的全部意义在于，你几乎可以输入任何你想要的内容，并获得有用、可合并的结果。一旦你强迫工程师（或非工程师）去学习一份记录在某处的、必不可少的魔法命令清单才能完成工作，你就失败了。

要点：将斜杠命令用作简单的个人快捷方式，而不是用来替代构建一个更直观的 CLAUDE.md 且工具更完善的智能体。

自定义子智能体

从理论上讲，自定义子智能体是 Claude Code 在上下文管理方面最强大的功能。其卖点很简单：一个复杂任务需要 X 个 token 的输入上下文（例如如何运行测试），累积 Y 个 token 的工作上下文，并产生一个 Z token 的答案。运行 N 个任务意味着在你的主窗口中产生 (X + Y + Z) * N 个 token。

子智能体的解决方案是将 (X + Y) * N 工作分派给专门的智能体，它们只返回最终的 Z token 答案，从而保持你的主上下文干净。

我发现这是一个强大的理念，但在实践中，自定义子智能体会产生两个新问题：

  1. 它们把守上下文：如果我创建了一个 PythonTests 子智能体，我就把所有的测试上下文从我的主智能体中隐藏了。它无法再对一次变更进行整体推理。现在它被迫调用子智能体，仅仅是为了知道如何验证自己的代码。

  2. 它们强制人工工作流：更糟糕的是，它们迫使 Claude 进入一种僵化的、人为定义的工作流。我现在是在规定它必须如何委派任务，而这恰恰是我试图让智能体为我解决的问题。

我更喜欢的替代方案是使用 Claude 内置的 Task(...) 功能来生成通用智能体的克隆。

我把所有关键上下文放在 CLAUDE.md 中。然后，我让主智能体决定何时以及如何将工作委派给自身的副本。这让我获得了子智能体的所有节省上下文的好处，而没有其缺点。智能体动态地管理自身的编排。

在我 《构建多智能体系统（第二部分）》 的文章中，我称之为“主-克隆”架构，并且我强烈倾向于它，而不是自定义子智能体所鼓励的“主管-专家”模型。

要点：自定义子智能体是一种脆弱的解决方案。给你的主智能体提供上下文（放在 CLAUDE.md 中），并让它使用自身的 Task/Explore(...) 功能来管理委派。

恢复、继续与历史记录

在简单层面上，我经常使用 claude --resume 和 claude --continue。它们非常适合重启出现故障的终端或快速重启较早的会话。我经常会 claude --resume 几天前的某个会话，只是为了让智能体总结它是如何克服某个特定错误的，然后我用这些信息来改进我们的 CLAUDE.md 和内部工具。

更深入地说，Claude Code 将所有会话历史存储在 ~/.claude/projects/ 中，以便利用原始的历史会话数据。我有脚本对这些日志进行元分析，寻找常见的异常、权限请求和错误模式，以帮助改进面向智能体的上下文。

要点：使用 claude --resume 和 claude --continue 来重启会话并挖掘被埋藏的历史上下文。

钩子（Hooks）

钩子非常重要。我不在业余项目中使用它们，但在复杂的仓库中引导 Claude 时，它们至关重要。它们是确定性的“必须做”规则，与 CLAUDE.md 中的“应该做”建议相辅相成。

我们使用两种类型：

  1. 提交时阻断钩子：这是我们的主要策略。我们有一个 PreToolUse 钩子，它包装任何 Bash(git commit) 命令。它会检查是否存在 /tmp/agent-pre-commit-pass 文件，而我们的测试脚本只有在所有测试通过时才会创建该文件。如果文件缺失，钩子会阻止提交，迫使 Claude 进入“测试并修复”的循环，直到构建通过。

  2. 提示钩子：这些是简单的、非阻断的钩子，如果智能体正在做次优的事情，它们会提供“即发即忘”的反馈。

我们有意不使用“写入时阻塞”钩子（例如在 Edit 或 Write 上）。在计划中途阻塞智能体会让其困惑甚至“受挫”。远更有效的方法是让它完成工作，然后在提交阶段检查最终的完成结果。

要点：使用钩子在提交时强制执行状态验证（block-at-submit）。避免在写入时阻塞——让智能体完成其计划，然后检查最终结果。

规划模式

对于 AI IDE 中任何“大型”功能变更，规划都是必不可少的。

对于我的业余项目，我完全使用内置的规划模式。这是在 Claude 开始之前与其对齐的一种方式，既定义如何构建某物，也定义它需要停下来向我展示工作的“检查点”。经常使用这一点，可以培养出一种强烈的直觉，知道需要哪些最小上下文才能获得一个好的计划，同时又不会让 Claude 搞砸实现。

在我们的工作 monorepo 中，我们已经开始推出一个基于 Claude Code SDK 构建的自定义规划工具。它类似于原生计划模式，但经过大量提示工程，使其输出与我们现有的技术设计格式保持一致。它还开箱即用地强制执行我们的内部最佳实践——从代码结构到数据隐私和安全。这让我们的工程师可以像资深架构师一样“凭感觉规划”一个新功能（或者至少这是宣传语）。

要点：对于复杂变更，始终使用内置的规划模式，以便在智能体开始工作之前就计划达成一致。

技能

我同意 Simon Willison 的观点：技能（Skills）（也许）比 MCP 更重要。

如果你一直在关注我的文章，你会知道我已经在大多数开发工作流中放弃了 MCP，转而构建简单的 CLI（正如我在“AI 读不懂你的文档”中所论证的那样）。我对智能体自主性的心智模型已经演变为三个阶段：

  1. 单次提示：在一个巨大的提示中给智能体所有上下文。（脆弱，无法扩展）。

  2. 工具调用：“经典”的智能体模型。我们手工制作工具，并为智能体抽象掉现实。（更好，但会产生新的抽象和上下文瓶颈）。

  3. 脚本编写：我们让智能体访问原始环境——二进制文件、脚本和文档——它即时编写代码来与它们交互。

有了这个模型，智能体技能（Agent Skills）显然是下一个功能。它们是“脚本编写”层的正式产品化。

如果你像我一样，已经倾向于使用 CLI 而非 MCP，那么你一直都在隐式地获得技能的好处。SKILL.md 文件只是一种更有条理、可共享且可发现的方式来记录这些 CLI 和脚本，并将它们暴露给智能体。

要点：技能是正确的抽象。它们将基于“脚本编写”的智能体模型形式化，该模型比 MCP 所代表的僵化的、类似 API 的模型更稳健、更灵活。

MCP（模型上下文协议）

技能并不意味着 MCP 已死（另见“MCP 的所有问题”）。以前，许多人构建了糟糕的、上下文繁重的 MCP，包含数十个只是镜像 REST API 的工具（read_thing_a()、read_thing_b()、update_thing_c()）。

“脚本编写”模型（现在已由技能形式化）更好，但它需要一种安全的方式来访问环境。在我看来，这就是 MCP 新的、更聚焦的角色。

MCP 不应是一个臃肿的 API，而应是一个简单、安全的网关，提供几个强大的高级工具：

  • download_raw_data(filters…)

  • take_sensitive_gated_action(args…)

  • execute_code_in_environment_with_state(code…)

在此模型中，MCP 的职责不是为智能体抽象现实；它的职责是管理身份验证、网络和安全边界，然后让开道路。它为智能体提供入口点，智能体随后使用其脚本编写能力和 markdown 上下文来完成实际工作。

我仍在使用的唯一 MCP 是 Playwright，这很合理——它是一个复杂、有状态的环境。我所有的无状态工具（如 Jira、AWS、GitHub）都已迁移到简单的 CLI。

关键要点：使用充当数据网关的 MCP。给智能体一两个高级工具（如原始数据转储 API），然后让它针对这些工具编写脚本。

Claude Code SDK

Claude Code 不仅仅是一个交互式 CLI；它还是一个强大的 SDK，用于构建全新的智能体——涵盖编码和非编码任务。对于大多数新的业余项目，我已开始将其作为默认的智能体框架，取代 LangChain/CrewAI 等工具。

我主要通过三种方式使用它：

  1. 大规模并行脚本编写：对于大规模重构、bug 修复或迁移，我不使用交互式聊天。我编写简单的 bash 脚本，并行调用 claude -p “in /pathA change all refs from foo to bar”。这比试图让主智能体管理数十个子智能体任务更具可扩展性和可控性。

  2. 构建内部聊天工具：SDK 非常适合将复杂流程封装在简单的聊天界面中，供非技术用户使用。比如一个安装程序，在出错时回退到 Claude Code SDK，直接为用户修复问题。或者一个内部的“v0-at-home”工具，让我们的设计团队使用内部 UI 框架进行 vibe 编码来制作前端原型，确保他们的想法是高保真的，且代码能更直接地用于前端生产代码。

  3. 快速智能体原型设计：这是我最常见的用法。它不仅仅用于编码。如果我对任何智能体任务（例如，一个使用自定义 CLI 或 MCP 的“威胁调查智能体”）有想法，我会使用 Claude Code SDK 快速构建并测试原型，然后再投入完整的部署脚手架。

关键要点：Claude Code SDK 是一个强大的通用智能体框架。用它来批量处理代码、构建内部工具，以及在转向更复杂框架之前快速原型设计新智能体。

Claude Code GHA

Claude Code GitHub Action (GHA) 可能是我最喜欢且最被低估的功能之一。它的概念很简单：就在 GHA 中运行 Claude Code。但正是这种简单性使其如此强大。

它类似于 Cursor 的后台智能体或 Codex 托管的 Web UI，但可定制性要强得多。你控制整个容器和环境，从而获得更多数据访问权限，更重要的是，拥有比任何其他产品都更强大的沙箱和审计控制。此外，它支持所有高级功能，如 Hooks 和 MCP。

我们用它构建了自定义的“随处创建 PR”工具。用户可以从 Slack、Jira 甚至 CloudWatch 警报触发 PR，GHA 会修复 bug 或添加功能，并返回一个经过完整测试的 PR1。

由于 GHA 日志就是完整的智能体日志，我们有一个运维流程，在公司层面定期审查这些日志，以发现常见错误、bash 错误或不一致的工程实践。这创造了一个数据驱动的飞轮：Bug -> 改进的 CLAUDE.md / CLI -> 更好的智能体。

$ query-claude-gha-logs --since 5d | claude -p “see what the other claudes were getting stuck on and fix it, then put up a PR“

关键要点：GHA 是将 Claude Code 落地运营的终极方式。它将 Claude Code 从个人工具转变为工程系统中一个核心的、可审计的、能自我改进的部分。

settings.json

最后，我有几个特定的 settings.json 配置，我发现它们对业余和专业工作都至关重要。

  • HTTPS_PROXY/HTTP_PROXY：这对调试非常有用。我会用它来检查原始流量，确切地查看 Claude 发送了哪些提示词。对于后台代理来说，它也是一个强大的工具，可用于细粒度的网络沙盒化。

  • MCP_TOOL_TIMEOUT/BASH_MAX_TIMEOUT_MS：我会调高这些值。我喜欢运行长时间的复杂命令，而默认超时时间往往过于保守。老实说，我不确定现在有了 bash 后台任务后是否还需要这个，但我还是保留着以防万一。

  • ANTHROPIC_API_KEY：在工作中，我们使用企业 API 密钥（通过 apiKeyHelper）。这使我们从“按席位”许可转变为“按用量”计费，这对我们的工作方式来说是更好的模式。

    • 它考虑到了开发者用量的巨大差异（我们见过工程师之间 1:100 倍的差异）。

    • 它让工程师可以在我们单一的企业账户下折腾非 Claude-Code 的 LLM 脚本。

  • “permissions”：我会偶尔自我审查我允许 Claude 自动运行的命令列表。

关键要点：你的 settings.json 是进行高级定制的强大之处。

结论

内容很多，但希望你觉得有用。如果你还没有使用像 Claude Code 或 Codex CLI 这样的基于 CLI 的代理，你可能应该用起来。这些高级功能很少有好的指南，所以学习的唯一方法就是亲自上手。

感谢阅读 Shrivu 的 Substack！免费订阅以接收新文章并支持我的工作。

1

在我看来，一个相当有趣的哲学问题是：一个直接由客户需求生成的 PR（没有内部人类提示者）应该有多少个审阅者？目前我们已确定，任何由 AI 发起的 PR 需要 2 个人工批准，但这确实是一种奇怪的范式转变（至少对我来说），因为不再是人类为另一个人类制作东西供其审阅。

阅读显示设置

调整正文排版

当前浏览器记住选择，应用于文章正文。手机上正文宽度以屏幕可用空间为限。

图表完整性提示

普通文章遇到图表保存问题时显示提示。