古法编程

Claude Code 创始人 Boris Cherny 的工作流哲学核心是构建面向未来模型的产品，并实践极致的自动化与极简主义。自 2024 年 11 月起，他 100% 的代码由 Claude Code 编写，个人每天产出 20-30 个 PR。其产品开发遵循 latent demand（潜在需求）原则，而他的个人 CLAUDE.md 配置文件仅包含两行，体现了“最小必要配置”的哲学。

Boris Cherny 访谈精华：Claude Code 创始人的工作流哲学与产品理念

通过梳理 Claude Code 创始人 Boris Cherny 在三个不同场合的深度访谈，我们可以提炼出其构建这一革命性工具背后的核心产品哲学与日常工作流范式。这些见解不仅解释了 Claude Code 为何如此设计，也为所有用户提供了从“随意编码”迈向“结构化代理工程”的实践参照。

1. 面向未来模型：核心产品哲学

Boris 反复强调的首要原则是 “不要为今天的模型而构建，要为六个月后的模型而构建”。这意味着产品团队需要具备前瞻性，为模型即将具备但尚未普及的能力设计产品。

  • 证据：在 Y Combinator 访谈中，Boris 解释道：“在 Anthropic，我们的思路是不为今天的模型构建。我们为六个月后的模型构建。这其实是我给所有在大模型上构建产品的创始人的建议。试着去思考模型目前还不擅长、但未来会变好的前沿领域。”
  • 哲学延伸：这一哲学直接导致了 Claude Code 选择相对“简陋”的终端（Terminal）作为主要交互形式。Boris 提到，团队曾探索过其他形式，但认为“没有哪种 UI 能在六个月后依然相关，因为模型进步太快了”。终端作为一种通用、稳定的交互层，能够更好地适应模型的快速迭代。同时，这也引出了“脚手架”（scaffolding）的价值与局限：围绕模型构建的优化（如某些提示工程）能短期提升 10-20% 的性能，但可能很快被下一代模型的原生能力所取代。因此，Claude Code 的设计倾向于提供工具和扩展点（如命令（Commands）、技能（Skills）、子代理（Subagents）），让用户自己组合，而不是固化一个复杂的应用层。

2. 最小化配置：CLAUDE.md 与指令哲学

Boris 的个人实践完美诠释了“最小必要指令”原则。他的个人 CLAUDE.md 文件内容极简。

  • 证据：在 The Pragmatic Engineer 访谈中，Boris 检查并透露了他的 CLAUDE.md 仅包含两行：1. whenever you put up a PR, enable automerge；2. whenever I put up a PR, post it in our internal team stamps channel。第一行确保 PR 被接受后自动合并，减少手动操作；第二行是为了将 PR 广播到团队频道，以便获得及时反馈和审批（“stamp”），从而解除他的阻塞。
  • 实践建议：他认为许多人会“过度工程化” CLAUDE.md。他的建议是：如果模型行为出现偏差，再逐步添加指令。随着模型能力的提升，需要添加的指令会越来越少。这与项目最佳实践中提倡的根据模型反馈迭代更新 CLAUDE.md 的理念一致。关于指令，他还提到 Plan Mode 的本质“只是向提示中添加了一句话：请不要编码”，其初衷完全源于用户的潜在需求。

3. 规模化工作流：100% 代码由 Claude 编写

Boris 的个人工作流是其产品理念的终极实践，展示了在高度自动化下工程师角色的转变。

  • 证据：在 Lenny’s Podcast 中，他明确表示：“我 100% 的代码由 Claude Code 编写。自 2024 年 11 月以来，我未手动编辑过一行代码。我每天提交 10、20、30 个 PR。” 在 Pragmatic Engineer 访谈中，他进一步确认了这一数据，并提到 Opus 4.5 模型的发布是转折点，其强大的能力使他可以直接卸载 IDE。
  • 个人习惯：
    • 并行代理：他通常同时运行 5 个 Claude 实例（如 5 个终端标签页或桌面应用窗口），以并行处理任务。
    • 偏好模型与模式：他主要使用 Opus 模型并开启 Thinking 模式。同时，他是 Plan Mode 的重度用户，约 80% 的会话从 Plan Mode 开始，让 Claude 先规划，确认计划可行后再让其执行。他认为 Plan Mode 的生命周期可能有限，但目前仍是必要的质量控制环节。
    • 反馈驱动：他将内部用户反馈频道（Slack）的链接直接指向 Claude，让 Claude 分析反馈并生成修复 PR，形成极快的“反馈-修复”循环。

4. 潜在需求与偶然的终端形式

Latent Demand（潜在需求） 是 Boris 提到的“最重要的产品原则之一”。产品的许多特性（如 CLAUDE.md 的出现、Plan Mode 的诞生）都源于观察到用户在自发地以某种方式使用工具，然后官方将其标准化。

  • 证据：CLAUDE.md 的起源就是用户开始自发编写 Markdown 文件来指导模型，团队发现了这一“潜在需求”并将其固化。同样，Plan Mode 的诞生源于 Boris 在周日晚上浏览 GitHub Issues 和内部反馈，看到用户们需要一个“先计划再编码”的模式，于是他花了 30 分钟编写并当晚发布。
  • 终端的偶然性：Boris 将终端作为初始界面描述为“一个意外”。它仅仅是 2024 年 9 月作为个人快速原型的最廉价选择。然而，这种偶然选择带来的限制（没有 GUI）反而迫使团队专注于模型能力和工具集成的核心，而非界面复杂性，最终意外地契合了“面向未来模型”的哲学，并成为了 Claude Code 的标志性特征。

5. 从个体到团队：协作与技能的演变

Boris 的视野并未局限于个人编码。他预见了软件工程角色的演变和团队协作的新形态。

  • 团队协作：Claude Code 团队内部已高度自动化，Claude 负责自动代码审查、安全审查、标记 Issue、引导部署等。他提到，代码中的很大一部分是由 Claude 自己发起的子代理（Subagents）编写的，形成了“母体 Claude”（mama Claude）分派任务给递归子代理的模式。
  • 技能演变：他认为，在 AI 时代，最重要的技能是从第一性原则出发进行科学思考，以及承认错误并快速学习的能力。他喜欢招聘那些“做过奇怪事情”、具有跨界思维的人。他观察到，即使是初级工程师，有时也能比资深工程师更“AGI 前沿”地使用工具，因为后者可能被旧有的思维模式所束缚。

FAQ

Q: 为什么 Claude Code 坚持以终端为主要形式，而不是开发全功能的 IDE？ A: 根据 Boris Cherny 的解释，这主要基于两个原因。第一，终端是 2024 年初快速原型开发最廉价、最快捷的方式。第二，也是更根本的原因，他们信奉“为六个月后的模型而构建”的哲学。模型的进化速度极快，团队认为任何复杂的 GUI 都可能在几个月内过时，而终端作为一种稳定、通用的交互层，能更好地适应这种快速变化，让核心价值聚焦于模型能力和工具调用上。

Q: Boris 建议的个人 CLAUDE.md 应该如何配置？ A: Boris 的个人实践是极度精简的。他的 CLAUDE.md 只有两行：一行让 Claude 在提交 PR 时自动启用合并，另一行让 Claude 将 PR 发布到团队特定频道以获取审批。他的核心建议是避免过度工程化，采用“最小必要配置”：只有当模型反复出现某种偏离预期的行为时，才添加相应的指令。随着模型进步，需要的指令会越来越少。

Q: 如何理解 Boris 提到的 “100% 代码由 Claude Code 编写”？这是否意味着他完全不看代码？ A: 这意味着自 2024 年 11 月起，Boris 没有手动编写或编辑过任何一行代码。所有功能开发、bug 修复等编码任务都通过 Claude Code 完成。然而，这并非完全放手。他强调自己仍然会查看代码，尤其是在代码会被广泛运行或涉及安全性时，以确保其正确性。Anthropic 内部还有 Claude 自动进行的代码审查层，之后可能还有人工审查。因此，这是一种人机协作的高效模式：Claude 执行，人类进行关键的质量与安全验证。