Logo智人飞扬
Claude Code、AI、开发工具·

我如何使用 Claude Code 的所有功能 [译]

这篇文章分享了我如何在日常工作和个人项目中高效使用 Claude Code 的各项功能，以及我对其生态系统的反思。
Aa Josh Bayers

我使用 Claude Code，频率很高。

作为一个业余爱好者，我在虚拟机中每周多次运行它，常常带上 --dangerously-skip-permissions 选项，随心所欲地编写代码，抒发我脑中的想法。作为一名专业人士，我团队的一部分致力于为工程团队构建 AI-IDE 规则和工具，而我们的团队每月仅在代码生成方面就消耗 数十亿个 token。

命令行代理领域竞争激烈，Claude Code、Gemini CLI、Cursor 和 Codex CLI 之间的较量似乎实际上是 Anthropic 和 OpenAI 之间的竞争。但是坦白说，当我与其他开发者交谈时，他们的选择常常基于一些表面的因素——一个“运气不错”的功能实现，或是他们偏爱的系统提示“氛围”。此时，这些工具都已经相当优秀。我还觉得人们常常对输出风格或用户界面的关注过度。对我来说，那种“你绝对对！”的恭维并不是一个显著的缺陷；而是一个信号，表明你太过于参与其内部流程。通常我的目标是“发射后忘记”——委托工作，设定上下文，让它去执行。评价工具的标准应是最终的 PR，而不是过程。

在过去几个月坚持使用 Claude Code 之后，这篇文章是我对 Claude Code 整个生态系统的反思记录。我们将覆盖我使用的几乎所有功能（同样重要的是我没有使用的功能），从基础的 CLAUDE.md 文件和自定义命令到强大的子代理、Hooks 和 GitHub Actions。这篇文章可能有点长，我建议将其作为参考而不是全面阅读。

在你使用 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 命令复杂且冗长，不要写大量文档来解释它们。这是在修补人类问题相反的做法。相反，编写一个简单的 bash 包装器，提供清晰直观的 API，并记录 这个。保持 CLAUDE.md 尽可能简短是简化代码库和内部工具的绝佳强制函数。

以下是一个简化的快照：

# Monorepo

## Python
- 始终 ...
- 使用 <command> 测试
... 另外 10 个 ...

## <内部 CLI 工具>
... 10 个要点，专注于 80% 的使用案例 ...
- <使用示例>
- 始终 ...
- 永远不要 <x>，优先考虑 <Y>

对于 <复杂使用> 或 <错误>，请参见 path/to/<tool>_docs.md

...

最后，我们将此文件与 AGENTS.md 文件保持同步，以维护与工程师可能使用的其他 AI IDE 的兼容性。

如果你想获取更多有关为编码代理编写 Markdown 的技巧，请查看“AI 无法读取你的文档”，“AI 驱动的软件工程”， 和“Cursor (AI IDE) 的工作原理”。

结论： 将 CLAUDE.md 视为高层次的综合的防范措施和指引。利用它引导你在哪些方面需要投资更多的 AI（和人类）友好工具，而不是试图将其变为完整的手册。

我建议在编码会话中至少运行一次 /context 来理解你如何使用 200k 的 token 上下文窗口（即使使用 Sonnet-1M，我也不相信完整的上下文窗口实际上能够有效使用）。对于我们来说，在我们的单体仓库中开一个新会话的基本成本约为 ~20k tokens （10%），剩下的 180k 用于进行更改——这可能填满得相当快。

图片 1

这是我最近一个个人项目中 /context 的截屏。你几乎可以把这当作在你进行特征开发时填充的磁盘空间。经过几分钟或几小时后，你需要清除消息（紫色）以腾出继续工作的空间。

我有三种主要工作流程：

  • /compact （避免）： 我尽量避免这个。自动压缩是不透明的、容易出错且未得到良好优化的。
  • /clear + /catchup （简单重启）： 我的默认重启方式。我 /clear 状态，然后运行自定义的 /catchup 命令，让 Claude 阅读我 git 分支中所有的更改文件。
  • “文档与清除” （复杂重启）： 对于大型任务，我让 Claude 将它的计划和进展转储到一个 .md 文件中，然后 /clear 状态，再通过告诉它读取该 .md 文件并继续来开始一个新会话。

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

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

  • /catchup：我之前提到的命令。它只是提示 Claude 阅读我当前 git 分支中所有更改的文件。
  • /pr：一个简单的助手，用于清理我的代码、准备和提交拉取请求。

在我看来，如果你有一长串复杂的自定义斜杠命令，你就创建了一个反模式。对我来说，像 Claude 这样的代理的整个意义在于，你几乎可以输入 _任何_你想要的内容，并得到一个有用且可合并的结果。当你强迫一名工程师（或非工程师）学习一套新的、在某处有记录的关键魔法命令才能完成工作时，你就失败了。

结论： 将斜杠命令作为简单的个人快捷方式，而不是作为构建更直观的 CLAUDE.md 和更好工具代理的替代品。

从简单的层面上讲，我经常使用 claude --resume 和 claude --continue。它们非常适合重新启动出错的终端或快速重启较早的会话。我常常会 claude --resume 从几天前的会话中查看，让代理总结如何克服特定错误，然后我用来改进我们的 CLAUDE.md 和内部工具。

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

结论： 使用 claude --resume 和 claude --continue 重新启动会话，并发掘埋藏的历史上下文。

Hooks 非常重要。我在个人项目中不使用它们，但在复杂的企业代码库中它们是引导 Claude 的关键。它们是补充 CLAUDE.md 中“应该做”的建议的必做规则。

我们使用两种类型的 Hooks：

  1. 提交时阻止 Hooks： 这是我们的主要策略。我们有一个 PreToolUse hook，它包装任何 Bash(git commit) 命令。它检查 /tmp/agent-pre-commit-pass 文件，只有当所有测试通过时，我们的测试脚本才会创建该文件。如果文件丢失，hook 将阻止提交，迫使 Claude 进入一个“测试和修复”循环，直到构建通过。
  2. 提示 Hooks： 这些是简单的、非阻塞的 hook，在代理做出次优决策时提供“发射后忘记”的反馈。

我们故意不使用“写时阻止”hooks（例如在 Edit 或 Write 时）。在计划中阻止代理会让其感到困惑甚至“沮丧”。让它完成工作，然后在提交阶段检查最终的结果要有效得多。

结论： 使用 Hooks 在提交时强制执行状态验证（block-at-submit）。避免在写时阻止——让代理完成其计划后，再检查最终结果。

在进行任何“大型”功能更改时，规划是至关重要的。

对于我的个人项目，我专门使用内置的规划模式。这是一种在 Claude 开始之前与其对齐的方法，定义 如何 构建某些东西以及需要停止检查其工作成果的“检查点”。定期使用这可以建立强烈的直觉，了解实现良好计划所需的最小上下文，而不是让 Claude 出错。

在我们的工作单体仓库中，我们开始推出基于 Claude Code SDK 的自定义规划工具。其类似于原生计划模式，但经过大量提示，以与我们现有的技术设计格式对齐。它还不带任何形式地强制执行我们的内部最佳实践——从代码结构到数据隐私和安全——以确保我们的工程师可以像资深架构师一样对新功能进行“氛围规划”（或者至少是这样描述的）。

结论： 在复杂的更改前，始终使用内置的规划模式来对齐计划，以确保在代理开始工作之前达成一致。

我同意 Simon Willison 的观点：技能可能比 MCP 更重要。

如果你关注我的帖子，你会知道我已经在大多数开发工作流中逐渐远离 MCP，反而倾向于构建简单的 CLI（正如我在“AI 无法读取你的文档”中争辩的那样）。我对代理自主性的思维模型已经演变为三个阶段：

  1. 单一提示： 在一个庞大的提示中给代理提供所有上下文。（脆弱，不可扩展）。
  2. 工具调用： “经典”的代理模型。我们手工制作工具，抽象掉现实为代理服务。（更好，但会产生新的抽象和上下文瓶颈）。
  3. 脚本： 我们让代理访问原始环境——二进制文件、脚本和文档——并实时编写代码与之互动。

基于这个模型，代理技能显然是下一个特性。它们是“脚本”层的正式产品化。

如果你像我一样，已然在偏好 CLI 而非 MCP， 那你就自然而然获得了技能的好处。SKILL.md 文件只是一个更有组织的、可共享的、可发现的方式来记录这些 CLI 和脚本，并将其暴露给代理。

结论： 技能是正确的抽象。它们正式化了基于“脚本”的代理模型，较之 MCP 所代表的僵化的 API 模型，更具弹性和灵活性。

技能并不意味着 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 不仅是一个交互式 CLI；它也是构建全新代理的强大 SDK——适用于编码和非编码任务。我开始在大多数新的个人项目中将其作为我的默认代理框架，而不是 LangChain/CrewAI 等工具。

我主要有三种使用方式：

  1. 大规模并行脚本： 对于大规模重构、错误修复或迁移，我不使用交互聊天。我编写简单的 bash 脚本以并行调用 claude -p “在 /pathA 中将所有引用从 foo 更改为 bar”。这比让主代理管理数十个子代理任务更可扩展且可控制。
  2. 构建内部聊天工具： SDK 非常适合将复杂的流程封装在简单的聊天界面中，以供非技术用户使用。例如，安装程序在出错时可以回退到 Claude Code SDK，以便为用户 修复 问题。或者是一个内部的 “v0-at-home” 工具，让我们的设计团队在我们的内部 UI 框架中进行“氛围编码”的模拟页面，确保他们的想法具有高保真度，而代码在前端生产代码中的可用性更高。
  3. 快速代理原型制作： 这是我最常使用的。它不仅限于编码。如果我有任何代理任务的创意（例如，一个使用自定义 CLI 或 MCP 的“威胁调查代理”），我使用 Claude Code SDK 快速构建和测试原型，然后才决定完全部署。

结论： Claude Code SDK 是一个强大的通用代理框架。利用它进行代码的批处理、构建内部工具以及在更复杂的框架出现之前快速原型化新代理。

Claude Code GitHub Action（GHA）可能是我最喜欢和被低估的功能之一。它的概念简单：在 GHA 中运行 Claude Code。但正是这种简单性让它变得强大。

它类似于Cursor 的后台代理或 Codex 管理的 Web 界面，但更具可定制性。你可以控制整个容器和环境，给你更好的数据访问，以及至关重要的，比任何其他产品提供的更强大的沙箱和审核控制。此外，它还支持所有高级功能，如 Hooks 和 MCP。

我们已经用它构建了自定义的“从任何地方 PR” 工具。用户可以从 Slack、Jira，甚至是 CloudWatch 警报触发 PR，而 GHA 会修复错误或添加特性，并返回一个经过全面测试的 PR1。

由于 GHA 日志是完整的代理日志，我们有一个运营过程定期审查这些日志，寻找常见错误、bash 错误或者不一致的工程实践。这形成了一个数据驱动的飞轮：错误 -> 改进 CLAUDE.md / CLI -> 更好的代理。

$ query-claude-gha-logs --since 5d | claude -p “查看其他 Claude 遇到的困难并修复，然后提交 PR“结论： GHA 是操作化 Claude Code 的最终方式。它将其转变为一项核心、可审计的、自我改进的工程系统的一部分。

最后，我有一些具体的 settings.json 配置，发现对于个人和专业工作都至关重要。

  • HTTPS_PROXY/HTTP_PROXY：这对于调试很有帮助。我会用它检查原始流量，以了解 Claude 发送了哪些提示。对于背景代理，它也是一种强大的细粒度网络沙箱工具。
  • MCP_TOOL_TIMEOUT/BASH_MAX_TIMEOUT_MS：我会将这些提高。我喜欢运行很长、复杂的命令，而默认超时往往太保守。老实说，我不确定现在 bash 后台任务已经成为常态后是否仍然需要这一点，但我保留它以防万一。
  • ANTHROPIC_API_KEY：在工作中，我们使用企业 API 密钥（通过 apiKeyHelper）。它将我们从“每席位”许可转换为“基于使用”的定价，这对我们的工作方式更为合适。
    • 这考虑到开发人员使用上的 巨大 差异（我们见到过工程师之间的差异为 1:100x）。
    • 它让工程师可以在我们单一的企业账户下自由尝试非 Claude-Code 的 LLM 脚本。
  • “permissions”：我偶尔会自我审查所允许 Claude 自动运行的命令列表。

结论： 你的 settings.json 是一个强大的高级定制场所。

这一切可能有点多，但希望你觉得有用。如果你还没有使用像 Claude Code 或 Codex CLI 这样的基于 CLI 的代理，你大概应该试试。关于这些高级功能的指南很少，所以唯一的学习方式就是潜入其中。

1

对我来说，一个相当有趣的哲学问题是，由客户请求直接生成的 PR 应该由多少审阅者进行审查（没有内部人类提示者）？我们目前已经决定对任何 AI 发起的 PR 需要 2 位人类批准，但当由非人类情境下所生成的内容进行审查时，至少对我而言，确实是一种奇怪的范式转变。

原文链接：https://blog.sshh.io/p/how-i-use-every-claude-code-feature

压缩进步驱动：一个统一解释好奇心、美感与创造力的算法原理

深入探讨 Jürgen Schmidhuber 的革命性理论：为什么婴儿的笑声、科学家的发现、艺术家的创作和一个精彩的笑话，背后都是同一个简单的算法原理？

AI 的下半场 [译]

我们正处于 AI 的中场休息。从专注于开发训练方法和模型的上半场，转向定义问题和重新思考评估的下半场。

© 2025 智人飞扬