Claude Code团队是如何写代码的

Claude 代码团队使用 Claude 的方式不是关于"提出更好的提示"或"获得更智能的补全"。而是将 Claude 视为一个您设计的系统,而不是您礼貌查询的工具。

Claude Code团队是如何写代码的

当您深度沉浸在编码会话中,一切终于对齐了。

您的大脑热起来了。

代码库变得有意义了。

您在快速移动,几乎不需要思考。

然后……某些东西打断了流程。

失败的测试、半完成的重构,以及一个在技术上有效但仍然设法拖慢您的 AI 助手。

这就是 Boris Cherny 在他分享 Claude 代码团队实际如何使用 Claude 时所指出的差距。而老实说,这不是大多数人正在做的事情。

令人惊讶的部分不是功能。而是心态。

因为 Claude 代码团队使用 Claude 的方式不是关于"提出更好的提示"或"获得更智能的补全"。而是将 Claude 视为一个您设计的系统,而不是您礼貌查询的工具。

而不——没有单一正确的方法来做到这一点。每个人的设置都不同。这就是关键点。

但是一旦您看到他们如何工作,就很难回去了。

1、并行主义是超能力

大多数人使用一个 Claude 会话。

完成一个任务。

关闭它。

开始另一个。

Claude 代码团队根本不会这样做。他们绝不会。

他们同时启动 3 到 5 个 git 工作树。每个都有自己的 Claude 会话。每个都在处理问题的不同切片。

这不是技巧。这就是工作流程。

想想看。当您独自编码时,您已经在心理上这样做:

  • 一个线程思考架构
  • 另一个调试测试
  • 另一个扫描日志
  • 另一个担心边缘情况

工作树只是将这些显式化。

以下是基本设置:


$ git worktree add .claude/worktrees/my-worktree origin/main


$ cd .claude/worktrees/my-worktree && claude


Claude Code v2.1.29


Opus 4.5


Claude Enterprise


.claude/worktrees/my-worktree


>


尝试"为 AgentTool.tsx 编写测试"


? 显示快捷键


o/ide 用于 Visual.

有些人命名他们的工作树并将它们绑定到 shell 别名。zazbzc。肌肉记忆接管了。

其他人保留一个专用的"分析"工作树,它从不编写代码。它只是读取日志。运行 BigQuery。寻找模式。

这里的关键见解是简单但不舒服的:等待是可选的

您不需要 Claude 在您移动之前完成。您只需要更多通道。

None

2、计划模式对于困难问题来说不是可选的

这里是我们大多数人犯的一个错误。

某些事情出错了。

输出变得奇怪了。

而不是停止,我们继续推动。

Claude 代码团队做的恰恰相反。

他们立即切换回计划模式

每个复杂任务都在那里开始。许多任务中途返回。


尝试"重构 cli.tsx"


" 计划模式(shift+Tab 循环)。

一位工程师有一个整齐的习惯:他们要求一个 Claude 编写计划,然后启动第二个 Claude 像员工工程师一样审查它。

不是要礼貌。而是要残酷。

另一个显式地将计划模式用于验证,而不仅仅是构建。这是一个巨大的转变。您不是要求 Claude 编写代码。您是在要求它思考。

以下是这一投资带给您的东西:

  • 更清晰的实现
  • 更少的"几乎正确"解决方案
  • 更真实的一次性执行

您将精力倾注到计划中,以便 Claude 不必猜测。

而猜测就是事物通常分崩离析的地方。

None

3、CLAUDE.md 是一种活的记忆,而不是配置文件

大多数人设置一次 CLAUDE.md 然后就忘记了。

Claude 代码团队将其视为日志。

每次更正后,他们都会以:

"更新您的 CLAUDE.md,以便您不会再犯那个错误。"

结束。

并且 Claude 会这样做。可靠地。

随着时间推移,错误率下降。可测量地。

有些工程师更进一步。他们告诉 Claude 为每个任务或项目维护一个笔记目录。在每次 PR 后更新。然后他们在这些笔记处指向 CLAUDE.md

您最终得到的内容类似于:


记忆文件 /memory


L~/.claude/CLAUDE.md: 76 个标记


L CLAUDE.md: 4k 个标记。

这不是提示工程。而是行为塑造

您不是一次性告诉 Claude 做什么。您在教它您如何工作。

None

4、将重复转化为技能。提交它们。

如果您每天做不止一次某事,就将其自动化。

这是 Claude 代码团队的一条规则。

他们创建自定义技能和斜杠命令,然后将它们提交到 git,以便它们随每个项目一起传播。

来自团队的一些直接示例:

  • 在每次会话结束时运行的 /techdebt 命令来追踪重复代码
  • 一个同步命令,将七天内的 Slack、GDrive、Asana 和 GitHub 拉取到一个上下文转储
  • 以类似代理的方式进行分析风格的代理,编写 dbt 模型、审查代码并在开发中测试更改

这就是 Claude 停止成为助手并开始感觉像基础设施的地方。

您不是要求它帮助。

您正在将其连接到工作流程中。

5、让 Claude 修复错误。

这是反直觉的。

我们大多数人微小的管理错误修复。我们粘贴日志。解释上下文。添加评论。

Claude 代码团队经常只是说:"修复。"

如果错误在 Slack 中,则启用 Slack MCP 并粘贴线程链接。


Claude Code v2.1.29


Opus 4.5. Claude Enterprise


/code/claude


>

修复此 https://ant.slack.com/archives/C


slack -search_public (MCP)(query: "in:CG


Tool use


slack -search_public(query: "in:C07VBSH


在公共 Slack 频道中搜索消息


'slack_search_public' 通常不是用于用户同意使用 'slack_search_p


'slack_search_private',除非任务是电子邮件、群组消息……


有时他们甚至不粘贴任何内容。他们只是说:

"去修复失败的 CI 测试。"

Claude 会弄清楚其余部分。

指向 Docker 日志。分布式系统。杂乱的踪迹。当您过早限制它时,它出乎意料地有效。

None

6、像审查员一样提示,而不是像管理者一样提示

这就是事情变得有趣的地方。

他们不要求 Claude"做这项工作。"

他们要求它证明工作

一些最喜欢的提示:

  • "在这些变更上审视我,在通过您的测试之前不要提交 PR。"
  • "向我证明这一点有效。"
  • "diff 主分支和此功能分支之间的行为。"

而当某些东西平庸时:

"了解您现在知道的一切,废弃这一点,并实施优雅的解决方案。

最后一个很强大。您在让 Claude 使用后见之明——人类以丢弃而闻名。

此外,详细的规范比巧妙的提示更重要。歧义是敌人。清晰度会叠加。

7、终端设置实际上很重要

这不是废话。它改变了您的思考速度。

团队喜欢 Ghostty。同步渲染。适当的 Unicode。真实颜色支持。

他们自定义 Claude 状态行以始终显示:

  • 上下文使用
  • 当前 git 分支

许多颜色代码终端选项卡。每个任务或工作树通常一个选项卡。有时使用 tmux。有时不使用。

这里是隐藏技巧:语音听写

您说话的速度比您打字快三倍。您的提示变得更丰富。更精确。更有人情。

在 macOS 上,它字面上就是两次 fn

一旦您尝试它,打字感觉奇怪地受限。

8、子代理是您如何扩展思考

当任务感觉沉重时,他们不会简化它。

他们增加计算能力。

您附加:"使用子代理。"

Claude 将任务分配出去。主代理保持整洁和专注。

他们甚至通过 Opus 4.5 的挂钩路由权限请求,扫描攻击并自动批准安全操作。

这是编排,而不是对话。

None

9、Claude 作为您的分析工程师

一位工程师随意提到他们已经六个月没有编写 SQL 了。

为什么?因为 Claude 直接运行 bq CLI。

他们提出问题。Claude 拉取指标。分析趋势。解释异常。

这与任何支持 CLI、MCP 或 API 的数据库配合使用。

模式是一致的:将 Claude 推向数据,而不是进一步推离。

10、使用 Claude 学习,而不仅仅是编码

团队使用 Claude 来理解代码,而不仅仅是更改它。

他们声称的几项技术:

  • 启用"解释性"或"学习"输出样式,以便 Claude 解释原因
  • 要求不熟悉的代码库的可视化 HTML 演示
  • 为协议生成 ASCII 图表
  • 构建间隔重复学习技能,其中 Claude 对您进行测验、填补空白并存储结果

学习成为工作流程的一部分,而不是您以后做的事情。


原文链接: How the Claude Code Team Actually Codes

汇智网翻译整理,转载请标明出处