GitHub 排名第一的 12 条核心模式，教你如何从靠提示词"随缘编程"升级为用配置、钩子、子智能体和自动化工作流驱动的智能体工程。不需要新工具，只需要用好 Claude Code 自带的那些被大多数人所忽略的能力。

CLAUDE CODE

当我第三次看到 Claude 删错分支时，就不再怪罪模型了。

真正的问题在于对模型的使用方式。每次会话都是从零开始，没有结构，没有约束，没有可复用配置。我输入提示词，逐条批准权限，得到一个差强人意的结果，然后重复。出了问题，就在提示词里再加一句话。

• 只分析，不要修改文件。
• 别碰 /cmd 里的任何东西。
• 记住，我们用的是 Go 1.22。

那时我就是在 vibe coding，只是还不知道这个词。

这个词来自 shanraisshan/claude-code-best-practice，一个在 2026 年 3 月登上 GitHub 趋势榜第一的仓库，它的副标题是："从氛围编程到智能体工程。"作者整理了 11 个类别下的 69 条可实操技巧，并听取了 Claude Code 的构建者、Anthropic 工程师 Boris Cherny 的见解。

读完整个仓库之后，我找到了能够实际改变工作方式的 12 种模式。

1. CLAUDE.md 可能在帮倒忙

大多数人把 CLAUDE.md 当成配置文件来用：越长越详细越好。我自己的有大约 500 行，包含了代码风格、提交格式、测试要求、变量命名约定、包组织规则。

Claude 忽略了下半部分。不是一直忽略，而是恰好频繁到让我无法依赖它。

让我惊讶的发现是：60 行是最优的。200 行是上限。超过这个限度，文件靠后的规则会被悄悄降级处理。Claude 的工作注意力是有限的，一个 500 行的文件等于要求它同时记住太多约束。

解决方案不是删除规则，而是让规则只在相关时才出现。

<important if="language=go"> 语法正是为此而生。包裹在这个标签里的规则，只有当 Claude 在处理 Go 文件时才可见；当它在写 Python 脚本时，整个代码块对 Claude 来说根本不存在。

对于一个多层的 Go 服务，文件结构如下：

my-service/
├── CLAUDE.md           # 根目录：通用规则，约 30 行
├── api/
│   └── CLAUDE.md       # REST 约定、错误码
├── internal/
│   └── CLAUDE.md       # 包命名、接口模式
└── cmd/
    └── CLAUDE.md       # 参数解析、日志初始化

internal/CLAUDE.md 使用条件规则：

<important if="language=go">
- 不要使用裸 goroutine。用 errgroup 或 WaitGroup 管理生命周期。
- 通道容量 > 0 时需要内联注释说明原因。
- context 必须是第一个参数，命名为 ctx。
</important>

总行数保持可控。每条规则只在真正相关时才会生效。

2. 别再把 Claude Code 当成聊天窗口了

有一个习惯我花了很长时间才改掉：每次请求都用全新的提示词重新申明所有规则。

"帮我审查这个 PR。只读文件，不要修改任何东西。重点关注 internal/ 包。使用项目的错误处理约定。"

每次都是如此。

另一种做法是把 Claude Code 当作编排系统，而不是聊天界面。.claude/ 目录支持三种类型的配置：

• commands/：可复用工作流快捷方式，存储为斜杠命令
• agents/：专用子智能体，工具权限明确受限
• skills/：可跨项目移植的知识模块

代码审查的例子让这种差异变得具体。我在 .claude/agents/ 中创建了一个 reviewer.md，一个专用智能体，只有 Read 权限，除此之外什么都没有。没有写入工具，没有 shell 执行权限，没有网络访问权限。

这个智能体物理上无法修改文件。无论我在对话中要求它做什么都无关紧要，约束不由提示词来执行，而是由配置本身来执行。

"只读文件，不要修改任何东西"这句话已经从我的每一条提示词中删除了。不再需要了。

3. 上下文是资源，请这样对待它

Skills 默认共享主智能体的上下文。这比听起来影响更大。

我有一个代码质量分析 skill，它会读取 40 个文件来生成报告。运行之后，该会话中的每个后续任务都变重了，Claude 带着所有这些文件内容，甚至在回答完全无关的问题时也是如此。响应变慢了，清晰度也略有下降，而且很难归因到具体原因。

在 skill 的 frontmatter 中加一行就能解决这个问题：

context: fork

该 skill 在隔离的子智能体中运行，运行结束后，上下文被丢弃。主智能体只看到输出 —— 一个干净的摘要、一份发现列表。

不需要手动执行 /compact，不需要开新会话清空缓存。

4. Hook 在智能体循环之外运行

PreToolUse、PostToolUse 和 Stop —— 三个大多数 Claude Code 用户从未配置过的钩子点。

它们在架构上值得关注的原因是：它们在 Claude 的主推理循环之外执行。不消耗 token，不中断任务。它们是附加在 Claude 动作上的自动化工具，而非 Claude 动作本身。

几个具体用途：

写入时自动格式化：一个 PostToolUse 钩子在每次写入 Go 文件后运行 gofmt，这样格式化就不再是你需要要求 Claude 做的事情，而是自动就发生了。

受保护的危险操作：/careful 模式激活一个 PreToolUse 钩子，拦截任何不可逆操作（文件删除、覆盖、分支强制推送）并在执行前要求明确确认，可以在进行风险重构前激活，任务完成后自动停用。

完成验证：在模式 11 中详细说明。

5. 减少 84% 的权限提示

Claude Code 的默认行为是在执行每个 shell 命令时要求批准。这对安全来说是合理的默认设置，但对工作流来说却是错误的默认设置。

/sandbox 在隔离环境中运行 shell 命令。任何单个命令的爆炸半径都受到限制，因此批准门槛大大降低。实践表明：权限提示减少了 84%。

权衡是真实存在的，沙箱命令的系统访问权限有限。但对大多数编码任务来说，沙箱边界从未被触及，而中断消失了。

6. "随时都有十几个 Claude 在同时运行。"

这是 Boris Cherny 对自己工作方式的描述。这不是夸张。

claude -w 在 git worktree（工作树）内启动 Claude —— 一个独立分支上的隔离工作目录。结合 tmux 的多个窗格，你就可以同时运行独立的 Claude 实例，每个实例都有自己的上下文、自己的分支和自己的任务。

智能体 A 在重构认证模块。智能体 B 在修复数据库层。智能体 C 在为两者编写测试。它们不共享上下文，彼此不冲突。它们的更改分别保存在不同分支上，直到准备合并。

从一次等待一个 Claude 回复，到同时运行十几个，这种转变可能是在氛围编程和智能体工程之间最明显的区别。

7. ultrathink 不是噱头

在任务描述中的任何位置输入 ultrathink，Claude 就会进入更高投入的推理模式。这是扩展思考的自然语言触发方式 —— 不需要改配置，不需要切换模型，只是在提示词里加一个词。

它并非适用于所有任务。大多数任务不需要它。

我有一次用它来设计服务拆分方案。普通模式下，Claude 给出了三个还算不错的选项。使用 ultrathink 后，Claude 揭示了两个我之前没考虑到的约束——跨服务事务边界和现有监控系统的上手成本。最终的选择与普通模式推荐的结果完全不同。

8. CI 做不到的本地自动化

/loop 30m /code-review

这段命令每 30 分钟运行一次代码审查工作流。不需要人工介入。间隔最长可达 1h，持续时间最长可达 3 天。

CI/CD 自动化的是代码合并之后发生的事情。/loop 自动化的是开发过程中发生的事情，而且它能做到 CI 根本做不到的事情，因为它可以访问你当前的工作状态。

CI 流水线看到的只是一个 diff。基于循环的审查知道你在这个会话中一直在做什么、之前提到了哪些问题、以及你已经建立了哪些约束。周五下午，我开始让循环在周末持续运行。周一早上，我不在的时候它已经标记了问题并起草了 PR 摘要。

大多数开发者不知道 Claude Code 原生就支持这种能力。但它确实支持。

9. 不中断任务的前提下提问

你在进行一个大型重构。进行了 90 分钟时，你想问一个不相关的问题，关于另一个文件、另一个关注点。中断意味着丢失上下文，但这个问题需要答案。

/btw 将问题加入队列。Claude 继续当前任务，记下你的问题，在某个自然的暂停点处理，然后回到之前的工作。

一旦你用过了，就会发现停下整个任务去问一个旁支问题简直是浪费时间。

10. 让 Skill 值得编写的关键部分

如果你正在为团队编写 skills，Thariq（这个仓库在 skill 方面的核心贡献者之一）有一条特别的建议：

"任何 skill 中信噪比最高的内容是 Gotchas 部分。"

不是概述，不是使用示例。是 Gotchas。

Gotchas 部分记录了 Claude 在实际使用中真正遇到的失败模式。不是预想的边界情况，而是真实发生的失败，随时间积累，在每次发生时记录下来。它们的信噪比远高于解释性文字，因为它们具体、可验证、且不断累积。你记录的每一次失败都会成为未来的预防措施。

先构建 Gotchas 部分。每次 Claude 失败时更新，让它成为 skill 文档中的核心产物。

11. 让"完成"真正意味着完成

Claude 会告诉你任务完成了。但这不代表它真的完成了。

我曾让 Claude 写一组 API 处理器。它说完成了。我看了代码——三个处理器中有两个的错误处理是空的。err != nil 后面什么也没有。如果我有一个 Stop 钩子连接到了测试覆盖率检查，它会立即发现这个问题，并把 Claude 送回去修复。

Stop 钩子在 Claude 发出任务完成信号时触发。将它连接到一个验证脚本 —— 运行测试套件，检查预期文件是否存在，访问 API 端点并验证响应。如果验证失败，任务状态回滚，Claude 继续工作直到通过。

在跨夜或跨多个会话的自动化工作流中，这就是可信输出和仍需手动检查的输出之间的区别。

12. 一个参数让 SDK 调用快 10 倍

当通过 Agent SDK 以编程方式使用 Claude 时（而非交互式 CLI），加上 --bare。

上下文发现是 Claude 的启动例程：定位 CLAUDE.md 文件、加载配置、检查环境。在交互式会话中，这只需要一次。在批量自动化中，每次调用都会执行。

--bare 跳过这一过程。启动时间最多减少 10 倍。

单次调用时，差异几乎不可察觉。我们有一个日常代码分析管道 —— 大约 300 个文件，每个文件并行运行一个智能体。使用 --bare 之前：约 40 分钟。之后：18 分钟。同样的基础设施，同样的工作负载。

这 12 种模式的共同点

看完全部 69 条技巧后，我发现氛围编程和智能体工程之间的实际差距不在于使用不同的工具。而在于以不同方式使用同样的工具。

氛围编程是被动的。描述想要什么；Claude 尝试实现；纠正；重复。输出质量几乎完全取决于提示词写得有多仔细。

智能体工程将这项工作卸载到配置中。约束存在于文件中，而不是提示词里。工作流按计划运行。智能体有硬性的权限限制，无论你在对话中要求什么都不会改变。上下文自动清理。系统的稳定性是指令撰写永远无法达到的。

实现这一切的工具（智能体、skills、钩子、工作树、循环）都是 Claude Code 自带的。它们不是高级功能。只是大多数人从来没用过。

这个仓库是 shanraisshan/claude-code-best-practice。仍在积极更新。值得从头到尾读一遍。

参考资源

• shanraisshan/claude-code-best-practice —— 69 条技巧，持续维护
• Boris Cherny 在 X 上的分享：推文 1 · 推文 2
• Claude Code 官方文档：code.claude.com/docs

本文由mdnice多平台发布