Claude Code创始人鲍里斯详解其“人机共生”开发工作流，从多实例并行、Opus 4.5模型选择、CLAUDE.md共享知识库到自动化验证闭环，全面展示下一代AI编程范式。
Claude Code 的缔造者鲍里斯
在AI编程工具风起云涌的今天，Claude Code 已经成为无数开发者口中的“神级编码助手”。而它的创造者——鲍里斯（Boris），正是 Anthropic 内部核心工程团队的关键人物之一。他不仅主导了 Claude Code 的产品设计，更是日常重度使用者。不同于许多工具开发者“自己不用自己做的产品”，鲍里斯每天与多个 Claude 实例并肩作战，将人机协作推向极致。
我的开发环境出奇地“朴素”，但背后是极致的并行思维
很多人以为我会有一套极其复杂的自定义配置，但其实恰恰相反——Claude Code 开箱即用的表现已经足够强大，所以我个人几乎不做深度定制。但这并不意味着我的工作流简单。恰恰相反，我每天同时运行 5 个本地终端中的 Claude 实例，每个终端窗口我都用 1 到 5 编号，配合系统通知来感知哪个 Claude 需要我介入。这种“人机多线程”模式让我能同时推进多个任务，比如一个在写前端组件，另一个在调试后端接口，第三个在跑数据查询。
更疯狂的是，我还会在 claude code 上再开 5 到 10 个网页版 Claude 会话，与本地实例并行运行。当我本地终端里某个任务变得复杂，我会用 & 符号把它“移交”到网页端继续处理；或者直接在 Chrome 里手动启动新会话。
更妙的是，Claude Code 支持 --teleport 功能，让我能在本地和云端会话之间无缝跳转，就像瞬移一样。
每天早上，我还会从 iPhone 上的 Claude App 启动几个长期任务，比如代码审查或文档生成，等下午喝咖啡时再回来检查结果。
这种“跨设备、跨平台、多实例”的工作方式，才是现代AI开发者的真实日常。
为什么我只用 Opus 4.5？因为它才是真正省时间的“慢即是快”
尽管 Sonnet 模型更快、更轻量，但我所有任务都坚持使用 Opus 4.5 + thinking 模式。
原因很简单：虽然 Opus 4.5 单次推理更慢，但它对任务的理解更深、工具调用更精准、犯错率更低。这意味着我几乎不需要反复纠正它，反而整体效率更高。
举个例子，让它写一个复杂的数据库迁移脚本，Sonnet 可能要我来回修正三次，而 Opus 4.5 一次就能产出可直接合并的代码。在软件工程这种高容错成本的领域，“少犯错”比“快一点”重要得多。
Opus 4.5 不仅是我用过最好的编码模型，更是我眼中 AGI 在工程领域的早期体现——它不仅能写代码，还能像资深工程师一样思考架构、权衡取舍。
CLAUDE.md：我们团队的集体记忆与防错知识库
我们整个 Claude Code 团队共享一份 CLAUDE.md 文件，并把它提交到 Git 仓库中。这份文档不是静态的说明，而是动态演化的“集体记忆”。每当任何成员发现 Claude 做了错误的假设、生成了有缺陷的代码，或者误解了某个 API 的用法，我们就会立刻更新 CLAUDE.md，明确告诉它“下次不要这样做”。久而久之，这份文档就成了 Claude 的“经验手册”，让它能避免重复踩坑。
更酷的是，其他团队也有自己的 CLAUDE.md。每个团队负责维护自己的版本，确保它反映本项目的上下文和规范。在代码审查时，我经常在同事的 PR 里 @.claude，要求它根据这次修复的问题更新 CLAUDE.md。我们还为此开发了 GitHub Action（通过 /install-github-action 安装），自动将 PR 中的教训转化为知识沉淀。这本质上是一种“复合型工程”（Compounding Engineering）——每一次修复都在为未来的 AI 能力添砖加瓦，让团队整体越来越聪明。
从“计划模式”开始：好的蓝图决定90%的成功
我几乎所有的编码会话都从 Plan 模式开始——只需按两次 Shift+Tab。在这个模式下，我不会让 Claude 直接写代码，而是先和它反复讨论任务目标、技术方案、依赖项和潜在风险。
比如我要实现一个新功能，我会问：“你打算怎么设计这个 API？前端如何调用？需要哪些数据库变更？有没有安全考虑？”我们会来回几轮，直到我对它的计划完全满意。一旦 Plan 敲定，我就切换到 auto-accept edits 模式，这时 Claude 通常能一次性生成高质量代码。
事实证明，花10分钟打磨计划，能省下1小时调试时间。AI 不是盲目执行的机器人，而是需要人类引导的“思维伙伴”——而 Plan 模式就是那个引导的起点。
斜杠命令：把重复劳动变成一键自动化
每天重复的操作，我都会封装成 /slash 命令。这些命令不是简单的快捷方式，而是带有上下文感知的智能工作流。比如我们每天要用几十次的 /commit-push-pr 命令，它内部会执行一段内联 Bash 脚本，自动获取 git status、生成语义化 commit message、推送分支并创建 PR。因为预计算了这些信息，Claude 不需要再问我“当前分支是什么？”“有哪些改动？”，直接一步到位。
所有斜杠命令都保存在 .claude/commands/ 目录下，并提交到 Git。这意味着整个团队都能复用这些高效工作流。更重要的是，Claude 本身也能“学会”使用这些命令——当我让它“提交代码并发起 PR”，它会自动调用 /commit-push-pr，而不是一步步问我操作细节。这种将人类经验编码为可复用指令的方式，正是“知识乐高化”的体现：每个人贡献一块积木，整个团队就能快速搭建复杂系统。
子智能体：为高频任务配备专属小助手
除了主 Claude，我还长期使用几个“子智能体”（subagents）。比如 code-simplifier，它会在 Claude 完成编码后自动运行，把冗长或复杂的逻辑简化成更易读的形式；verify-app 则负责端到端测试整个 Claude Code 应用，确保新代码没有破坏核心功能。这些子智能体就像我的“数字学徒”，专门处理那些重复但关键的收尾工作。
和斜杠命令一样，子智能体的配置也保存在项目目录中，团队共享。我认为，真正的AI赋能不是让一个全能模型做所有事，而是构建一个由多个专用智能体组成的“蜂巢”——每个负责一个环节，协同完成复杂任务。这种模块化设计，既提高了可靠性，也降低了单个模型的认知负担。
后处理钩子：让代码格式100%通过CI
尽管 Claude 生成的代码通常格式良好，但我们还是配置了一个 PostToolUse 钩子，在每次工具调用后自动格式化代码。这个钩子处理了最后10%的边缘情况，比如缩进不一致、换行符错误等，确保提交的代码永远能通过 CI 的格式检查。在大型团队中，这种自动化细节至关重要——它避免了因格式问题导致的无谓代码审查，让工程师聚焦在真正重要的逻辑上。
权限管理：安全与效率的平衡术
我从不使用 --dangerously-skip-permissions 这种高风险选项。相反，我会用 /permissions 命令预授权一批我知道在当前环境中安全的 Bash 操作，比如 git pull、npm install、ls 等。这些权限规则保存在 .claude/settings.json 中，并和团队共享。这样，Claude 在执行常见操作时不会频繁弹出权限确认，既提升了流畅度，又保证了安全边界。AI 不是“全权代理”，而是在人类划定的安全区域内自主行动的智能体。
Claude 代我工作：自动对接 Slack、BigQuery 和 Sentry
Claude Code 不只是写代码的工具，更是我的“数字同事”。它会自动通过 MCP 服务器搜索并发布消息到 Slack 频道；当需要回答产品分析问题时，它会调用 bq CLI 执行 BigQuery 查询；遇到线上错误，它能直接从 Sentry 抓取日志并分析根因。所有这些集成配置（如 Slack 的 MCP 设置）都保存在 .mcp.json 中，团队成员开箱即用。这意味着，当我让 Claude “查一下昨天的用户活跃数据”，它真的会去 BigQuery 跑查询，而不是凭空编造——这才是真正的“工具使用”能力。
长任务处理：用钩子和插件实现无人值守
对于耗时很长的任务（比如训练一个小型模型或跑完整测试套件），我会采用三种策略：一是提示 Claude 在完成后启动一个后台代理来验证结果；二是配置 agent Stop 钩子，在任务结束时自动触发验证流程；三是使用 ralph-wiggum 插件（由杰弗里·亨特利最初构想），它能监控任务状态并自动重试失败步骤。在沙盒环境中，我还会临时启用 --permission-mode=dontAsk 或 --dangerously-skip-permissions，让 Claude 在隔离空间里“自由发挥”，避免被权限提示打断。这种“启动即遗忘”（fire-and-forget）的模式，极大释放了我的注意力带宽。
验证闭环：AI编程质量的终极保障
如果说 Claude Code 有什么“最核心的秘诀”，那就是——永远给 Claude 一个验证其工作的途径。无论是运行一个 Bash 命令、执行测试套件，还是在浏览器中实际操作 UI，只要 AI 能获得反馈，它的输出质量就能提升 2 到 3 倍。我自己就用 Claude Chrome 扩展来测试 http://claude.ai/code 的每一个变更：它会自动打开浏览器，模拟用户操作，检查 UI 是否正常，并不断迭代直到体验完美。
验证的形式因领域而异。Web 开发可能是 Cypress 测试，数据分析可能是结果校验脚本，移动端可能是模拟器截图比对。但原则不变：没有验证的 AI 输出是不可信的。投资构建可靠的验证机制，是每个团队迈向“AI 原生开发”的必经之路。
当 AI 能自我修正时，它才真正成为值得托付的工程伙伴。