Claude Code AI 原生开发：从创造者到社区的完整方法论
创造者 Boris Cherny 的工作流
Boris Cherny 是 Anthropic 的 Staff Engineer，也是 Claude Code 的创造者。2026 年 1 月他公开分享了自己的完整工作流——CLAUDE.md 配置文件只有约 2,500 tokens（~100 行），但他同时运行 10-15 个 Claude Code 会话。
他的核心原则只有三条：每次修改尽可能简单，能删代码就不加代码；找到根因，不打补丁，按高级工程师标准要求自己；只动必要的地方，不引入副作用。
他的日常工作流："如果我的目标是写一个 PR，我会用 Plan 模式，和 Claude 反复推敲直到我满意它的计划。然后切换到自动接受编辑模式，Claude 通常能一次完成。好的计划真的很重要！"
知识沉淀机制： Anthropic 每个团队在 git 中维护一份 CLAUDE.md，记录错误（让 Claude 随时间改进）和最佳实践（代码风格、设计规范、PR 模板等）。Cherny 经常在同事的 PR 上用 @.claude 标签把经验添加到 CLAUDE.md，确保每个 PR 的知识都被保留。
自动验证闭环： Claude 用 Chrome 扩展测试他提交到 claude.ai/code 的每一个改动——打开浏览器、测试 UI、迭代直到代码工作且用户体验良好。这让团队能专注于代码审查和方向把控，因为工程师看到 PR 时代码已经处于良好状态。
所有主要工作流的统一模式
所有主要工作流收敛于同一个架构模式：Research → Plan → Execute → Review → Ship。
具体拆解：
Research（研究） — 让 Claude 先读代码库、理解架构、查阅文档，不要直接写代码。
Plan（规划） — 最大的错误是让 Claude 跳过规划直接写代码。Boris 的团队总是先进入 Plan 模式，让一个 Claude 起草计划，再让第二个 Claude 以"高级工程师"身份审查计划，然后才进入执行。
Execute（执行） — 支持多种并行模式：
- Agent Teams 配合 tmux 和 git worktrees 进行并行开发
- 子 Agent 分工处理不同任务，保持主上下文干净
- 说"use subagents"可以把更多算力投入问题——一个 Agent 可能引入 bug，另一个（同模型）可以发现它们
Review（审查） — 多维度自动审查 + 人类验收
Ship（发布） — 自动提交、创建 PR、通知团队
关键实践细节
CLAUDE.md 是活文档： Boris 的黄金法则："每次看到 Claude 做错事，就加到 CLAUDE.md 里，这样它不会再犯。"文件提交到 git，全团队共享，每周更新多次。
Slash 命令模板化一切重复操作： 为你每天做很多次的"内循环"工作流使用 slash 命令——节省重复提示，命令放在 .claude/commands/ 里并提交到 git。如果一天做某事超过一次，就把它变成 Skill 或 Command。
Hooks 实现自动化质量保障： Cherny 在 PostToolUse 中运行格式化 hook，每次 Claude 写或编辑文件后自动运行 bun run format，防止格式不一致导致 CI 失败。
上下文窗口管理： Claude 读的每个文件、每条命令输出、每条消息都会消耗上下文窗口。窗口满了 Claude 就开始"遗忘"早期指令。解决办法：用子 Agent 做研究，新任务开新会话，不要"以防万一"地堆信息。
当前的规模和影响
截至 2026 年初，Claude Code 产出了全球 GitHub 提交的 4%。Spotify 的工程师从 12 月起就不再手写代码。Anthropic 自己的团队每个工程师每天发布 10-30 个 PR，全部由 Claude 生成。
总结一下 Claude Code AI 原生开发的本质：
它不是"AI 帮你写代码"，而是一套完整的系统——用 CLAUDE.md 给 Agent 注入团队记忆，用 Plan 模式确保方向正确，用多 Agent 并行提升吞吐量，用 Hooks 和 CI 自动化质量保障，用 Slash Commands 和 Skills 把经验模板化。再加上 Every.to 的 Compound 步骤（把每次开发的经验自动沉淀回系统），就构成了当前 AI 原生开发的最完整实践框架。
