Claude Code 项目负责人Boris Cherny内部最新访谈，和最顶级的大佬学习Claude Code，比你看多少碎片化的信息都强

Boris Cherny 作为Claude Code 创造者 和 Alex Albert (Claude Relations 负责人) 深入详细的讨论智能体编程的实用化、背后模型的演进过程、直觉驱动的Claude Code 迭代，以及 Claude Code 的设计哲学

其中Boris首次揭秘的直觉驱动的Claude Code 迭代非常有意思，原来Claude Code这个神器开发并不是依靠什么基准测试而是内部构建的“直觉系统”

Boris认为如果你未来要当软件工程师，基本的计算机编程知识和coding技能仍然是必须的，只有懂“手艺 ”的人，才能更好地驾驭和指导 AI 这个强大的工具！软件工程师的未来将向更高层次的抽象演进，更侧重于目标设定、系统设计和创意实现

访谈最后Boris 还给出了如何高效使用 Claude Code独家秘笈和最佳实践

整个访谈20分钟，以下是访谈的核心内容

仅一年时间Agentic Coding (智能体编程)走向实用

在探讨智能体编程的未来之前，我们有必要先回顾一下它在短时间内所经历的剧烈演变。仅仅在一年多以前，AI 在编程领域的应用还相当初级和分散。开发者的工作流通常是这样的：在一个集成开发环境 (IDE) 中编写代码，IDE 自带一些基础的自动补全功能，旁边可能还会开着一个独立的聊天应用。当遇到问题时，开发者会向聊天机器人提问，然后手动复制、粘贴代码片段，再进行修改和整合。这在当时，就是 AI 辅助编程的最高水平。

然而，在过去的一年里，整个范式发生了根本性的转变。AI 不再仅仅是一个被动提供代码片段的工具，而是进化成了一个主动的、能够深度参与开发流程的agent。如今，使用智能体进行编程已经从一个新奇的概念或原型功能，转变为许多开发者日常工作循环 (inner loop) 中不可或缺的一部分

这场变革的核心在于，开发者与代码的交互方式从直接操作文本演变为指导智能体为你操作文本。过去，我们逐行逐字地编写、修改和调试代码；现在，我们更多地是向一个智能体下达指令，描述我们想要实现的功能或修复的 Bug，然后信任它去分析、修改甚至创建大量文件和代码。智能体能够独立完成过去需要开发者手动执行的大量编辑工作，有时甚至能从零开始构建一个完整的应用程序。

这一飞跃之所以能在今天实现，Boris 认为主要归功于两个关键因素的成熟：

模型的进化：首先，底层语言模型的能力得到了质的提升。早期的模型或许能完成一些简单的任务，但往往缺乏长期规划和复杂逻辑推理的能力。随着像 Claude 3.7、Claude 4.0 乃至 Opus 4.1 这样更强大的模型问世，它们在理解复杂指令、保持任务连贯性以及执行多步操作方面的能力越来越强

“鞍具”的完善：其次，仅仅有强大的模型是不够的，还需要一个高效的“鞍具”来驾驭它。Boris 用了一个例子：模型就像一匹强大的马，而“鞍具”就是驾驭这匹马所需的全套装备，比如马鞍和缰绳。对于 Claude Code 而言，这个“鞍具”就是整个产品本身。它包含了所有模型之外的、用于交互和控制的系统组件，例如：

a.系统提示 (System prompt)：用于设定模型的角色、行为准则和目标

b.上下文管理 (Context Management)：智能地决定在与模型交互时提供哪些相关的代码文件和信息

c.工具集 (Tools)：赋予模型执行具体操作的能力，比如读写文件、运行命令、搜索代码库等

d.扩展协议：例如 MCP (meta-Context Protocol)，允许模型接入外部信息源，如 Sentry 的错误日志或 Slack 消息

e.设置与权限系统：让用户可以精细地控制智能体的行为边界。

这个“鞍具”和模型之间是一种共同进化的关系。在 Anthropic 内部，包括模型研究员在内的所有员工都在日常工作中使用 Claude Code。当他们在实际开发中遇到模型的局限，比如模型在执行某个特定类型的代码编辑时频繁失败，或者在长时间自主运行时会跑偏，这些第一手的使用体验会直接反馈给模型团队。团队可以根据这些具体的失败案例，针对性地进行数据收集和模型微调，从而教会模型如何更好地完成这些任务。这个有机的、持续的反馈循环，使得模型本身越来越擅长智能体式的工作，而“鞍具”系统也在不断迭代，以便更好地发挥出新模型的能力。正是这种模型与产品之间的协同进化，共同推动了智能体编程从理论走向了实用

直觉驱动迭代Claude Code

当 AI 模型的能力越来越强大，一个核心问题也随之而来：我们如何准确地评估一个编码模型是否真的更好了？传统的做法是依赖于标准化的基准测试集 (benchmark)，例如 SWE-bench 或更新的 T-bench。这些测试集包含了一系列预设的编程问题，通过模型解决问题的成功率来对其性能进行打分。虽然这些测试在一定程度上可以量化模型的进步，但 Boris 指出，它们正面临越来越大的局限性。软件工程的真实世界充满了复杂性、模糊性和多变性，这些是任何合成的、标准化的测试集都难以完全捕捉的

因此，在 Claude Code 团队的实践中，他们更依赖一种看似不科学但却更有效的方法：直觉测试，或者说是“氛围检查 (Vibe Check)”。当一个新模型版本或一个产品新功能需要评估时，Boris 的做法非常直接：他会用这个新版本来完成自己当天的日常开发工作。他不会去运行一套预设的测试用例，而是将新工具无缝地融入到真实的工作流中——无论是编写新功能、修复一个紧急的 Bug，还是为了回复一个 GitHub issue 而去阅读和理解既有代码。

这种评估方式的核心在于，它能真实地反映出工具在实际应用场景中的表现。一个在基准测试上得分很高的模型，在实际使用中可能会感觉很笨拙；反之，一个模型可能在某些指标上不突出，但用起来却异常聪明和顺手。真正的衡量标准变成了：它是否让我感觉更有效率？它是否能更好地理解我的意图？它是否让我的开发过程更流畅？这种基于真实使用体验的直觉，成为了判断模型和产品是否进步的最重要信号

为了系统性地收集和利用这种直觉，Claude Code 团队在 Anthropic 内部建立了一个极其高效的反馈循环

中心化的反馈渠道：团队设立了一个专门的 Slack 频道，作为所有内部用户提供反馈的唯一入口。任何人在使用中遇到问题、有新想法或感到困惑，都可以直接在频道里发布。

超快速的响应与闭环：这个反馈循环成功的关键在于 Boris 和团队成员的积极参与。每当有新的反馈出现，Boris 都会第一时间用 emoji 回应表示收到，并主动追问更多细节以厘清问题。最重要的是，他会以极快的速度修复 Bug 或实现简单的功能改进。有时他会花上几个小时，集中处理频道里积压的反馈，并且每解决一个问题，都会回到原帖下回复用户，告知问题已经修复

激励与正向循环：这种有问必应、有求必应的文化，打破了许多组织中反馈石沉大海的困境。当用户看到自己的意见被认真倾听并迅速得到解决时，他们会受到极大的鼓舞，从而更愿意在未来提供更多、更高质量的反馈。久而久之，这个 Slack 频道变成了一个信息量巨大的消防水管 ，源源不断地为团队提供最真实的、来自一线的用户信号。

这个紧密的、由直觉驱动的内部 dogfooding (内部试用) 循环，让 Claude Code 团队能够在没有复杂评估框架的情况下，依然能快速、准确地迭代产品，确保每一次更新都真正解决了用户的痛点，提升了实际的开发体验。在这个过程中，所有用户的集体直觉汇聚成了比任何硬性指标都更宝贵的导航信号。

Claude Code 的设计哲学：保持简单，可扩展性

从诞生之初，Claude Code 的核心设计哲学之一就是保持简单，并使其尽可能地具有可扩展性 ”。团队深知，每个开发者、每个团队、每个代码库都有其独特的工作流程和上下文需求，一个封闭的、一成不变的工具是无法满足所有人的。因此，Claude Code 被设计成一个开放的平台，提供了一系列由浅入深的扩展点，让用户可以根据自己的需求对其进行定制和改造。

这种可扩展性的设计经历了持续的演进，从最初简单的配置文件，发展到如今复杂的命令和子智能体系统

1.CLAUDE.md：这是最早也是最基础的扩展方式。用户可以在项目的根目录或任何子目录中创建一个名为 CLAUDE.md 的 Markdown 文件。这个文件的内容会被 Claude Code 自动读取，作为与模型交互时的额外上下文。开发者可以在里面写下项目的架构概述、编码规范、常用库的说明，或者任何希望 AI 在工作时了解的背景信息。由于这个文件是项目的一部分，可以被签入代码版本控制系统 (如 Git)，因此它能随着代码库的演进而同步更新，确保 AI 掌握的信息始终是最新、最准确的

2.设置与权限系统：随着功能的增加，团队引入了更精细的设置和权限系统。用户可以配置智能体的行为，例如限制它可以访问的文件路径、可以执行的命令类型等，从而在赋予其强大能力的同时，确保安全性和可控性

3.Hooks (钩子)：为了满足更高级的定制需求，团队工程师 Dixon 构建了一套强大的钩子系统。它允许用户在 Claude Code 工作流的特定节点（例如，在执行一个命令之前或之后）注入自定义的逻辑。这为实现复杂的自动化流程和与其他工具的深度集成打开了大门

4.模型上下文协议 (Model Context Protocol)：这是一个重要的扩展点，它让 Claude Code 能够超越本地代码库，接入外部数据源。通过实现 MCP 服务器，开发者可以让 Claude Code 读取来自公司内部文档、任务管理系统、错误监控平台（如 Sentry 日志）或通信工具（如 Slack 消息）的信息，从而在解决问题时获得更全面的上下文

5.Slash Commands (斜杠命令) 与 Subagents (子智能体)：这是目前最新的、也是功能最强大的扩展方式。用户可以自定义斜杠命令，它本质上是一个预先定义好的、可复用的工作流，通常以 Markdown 文件的形式存在于代码库中

Boris 举了一个他自己的例子：他创建了一个 /commit 命令。这个命令对应的文件中包含了他对如何编写一条高质量 Git commit message 的所有要求和格式说明，并且预先授权了 git commit 这个 Bash 命令。这样，当他需要提交代码时，只需输入 /commit，Claude 就会自动按照预设的规范生成提交信息并执行提交操作，无需他每次都手动确认权限

子智能体可以看作是斜杠命令的另一种形式，它的特殊之处在于拥有一个“分叉的上下文窗口 (forked context window)”。这意味着它可以像一个独立的、专注于特定任务的智能体一样工作，而不会干扰主对话的上下文

这些丰富的扩展点共同构成了 Claude Code 的可扩展性生态。它们将 Claude Code 从一个单纯的编码工具，提升为一个可以被深度定制和集成的开发平台。展望未来，Boris 表示团队将继续沿着这个方向努力，让 SDK 变得更加强大和通用，不仅能用于构建编码智能体，还能支持任何需要智能体能力的场景，真正赋能开发者在 Claude Code 之上构建自己的创新应用

软件工程师的未来

随着智能体编程能力的飞速发展，一个所有工程师都关心的问题浮出水面：我的工作在未来会变成什么样？我应该如何提升自己以适应这个新时代？

Boris 认为未来人类软件工程师并非无事可做，整天只审核 AI 生成的拉取请求 (Pull Request)，而是一种工作重心的战略性转移，即从具体的代码实现细节，上升到更高层次的抽象

短期未来 (6-12 个月内) 的工作模式：

人机协作模式的演变：传统的手工编码并不会消失，但其形式会发生改变。开发者将越来越少地直接编辑文本，而是更多地通过与 Claude 的对话来指导它完成代码的修改、重构和生成

主动与被动工作的结合：工作流将包含两种模式。一种是开发者主动发起任务，指导 Claude 完成；另一种是 Claude 会变得更加主动，它可能会根据代码库的静态分析、或新出现的 issue，主动地提出改进建议、修复 Bug，甚至自己完成代码修改并提交。在这种模式下，工程师的角色更像是最终的决策者和质量把关人，决定是否接纳 AI 提出的变更

长期愿景 (12-24 个月及以后) 的工作模式：

从任务导向到目标导向：工程师与 AI 的交互将进一步抽象化。届时，你可能不再需要告诉 AI “请修改这个文件里的这个函数”，而是直接给它设定一个高级别的目标，例如：“为我们的应用增加一个用户认证系统”，或者“将这个服务的平均响应时间优化 20%”。AI 智能体将能够自己分解这个宏大目标，规划出详细的执行步骤，并自主完成所有必要的编码、测试和部署工作

工程师成为架构师和产品经理：随着 AI 接管越来越多的底层实现工作，工程师将能够将更多的精力投入到更具创造性和战略性的任务上，例如系统设计、技术选型、定义产品目标和用户体验。工作的核心将从如何实现转变为应该实现什么和为什么这样实现

**开发者如何为未来做好准备

面对这一趋势，Boris 提供了两条核心建议：

打好坚实的基础功底：AI 的出现并没有让基础知识变得不重要，反而可能要求更高。你仍然需要深入学习编程语言、编译器原理、运行时环境、网络协议、系统设计等核心计算机科学知识。因为当 AI 犯错或无法解决复杂问题时，最终还是需要具备深刻理解的工程师来介入、诊断和纠正。只有懂“手艺 ”的人，才能更好地驾驭和指导 AI 这个强大的工具。

拥抱创造力，将想法快速落地：Boris 回忆起自己中学时用 TI-83 Plus 计算器学习编程的经历。那时，编程的魅力在于能快速将一个想法（比如编写一个能计算数学题答案的程序）变成现实，这种即时反馈的乐趣是巨大的。然而，现代软件开发的栈变得异常复杂（例如 React, Next.js, Webpack 等），大大提高了从想法到产品的门槛。智能体编程正在改变这一点，它让开发者能够像当年使用计算器一样，快速地将创意原型化并构建出来

Boris 强调，在这个新时代，代码本身不再那么珍贵了。因为 AI 可以轻松地重写和重构代码，所以代码的完美性不再是唯一的追求。更重要的是你想要构建的“东西 (the thing you make)”——你的产品、你的创意

因此，给开发者的建议是：在打好基础的同时，要变得更有创造力。如果你有一个创业点子或一个产品想法，现在就可以借助 AI 智能体立即动手去实现它。这个时代解锁了前所未有的潜力，让个人能够以过去无法想象的速度和规模进行创造。

总而言之，未来的工程师将是AI 增强型的创造者，他们利用 AI 处理繁琐的实现细节，从而能更专注于那些真正需要人类智慧、洞察力和创造力的领域。

Boris 的独家秘笈：如何高效使用 Claude Code

作为 Claude Code 的创造者，Boris 分享了他个人在使用这款工具时总结出的一些最佳实践和技巧。这些建议旨在帮助用户，无论是新手还是老手，都能更高效、更智能地与 AI 编程智能体协作。

他提出了两个核心建议，第一个是针对新手的入门心法，第二个是针对日常使用的分级策略

技巧一：入门时，先问而后写

这个建议听起来可能有些反直觉：当你第一次使用像 Claude Code 这样的强大代码生成工具时，先不要急着用它来写代码

从提问开始：你应该从把它当作一个代码库的专家问答系统开始。利用它来探索和理解你正在处理的代码库。你可以问一些问题，例如：

“如果我想在这个项目里新增一个日志记录器 (logger)，我应该怎么做？涉及到哪些文件？”

“这个函数为什么被设计成现在这样？能帮我追溯一下它的历史背景吗？”

“请帮我梳理一下用户认证流程的核心逻辑，它分布在哪些模块里？”

建立信任与心智模型：通过这种方式，你可以亲身体验 Claude Code 是如何为你进行代码库研究的。它会去阅读文件、分析依赖关系，甚至能通过 git blame 查看代码的历史演变来回答你的问题。这个过程能帮助你建立对 AI 智能体能力的信任，并形成一个正确的心智模型——它是一个可以为你执行研究任务的伙伴，而不仅仅是一个代码生成器。当你对它以这种方式辅助你的工作感到舒适后，再开始让它为你编写代码，效果会好得多

技巧二：根据任务难度，采用分级协作策略

在实际编码工作中，任务的复杂程度各不相同。Boris 建议将任务大致分为简单、中等和困难三类，并针对每一类采取不同的协作模式。

简单任务 ：

定义：这类任务通常很明确，Claude 基本上可以通过一次提示 (one shot) 就准确完成。例如，修复一个拼写错误、为一个函数添加文档字符串、或者实现一个简单的 API 端点。

工作流：对于这类任务，Boris 会采用最放手的方式。他甚至不会在自己的本地终端里操作，而是直接在 GitHub 的 issue 页面里 @Claude，然后简单描述任务，让 Claude 自动完成编码、创建 Pull Request 并提交。这样做的好处是完全不占用他本地的开发环境和注意力，可以并行处理其他更重要的事情

中等任务：

定义：这类任务比简单任务更复杂，可能需要修改多个文件或包含一些逻辑判断，AI 不一定能一次性完美搞定

工作流：对于中等任务，Boris 会在自己的终端里启动 Claude Code，但会采用一种“先规划，后执行”的模式。他会首先进入规划模式 (plan mode)（通过快捷键 Shift + Tab），与 Claude 一起讨论并确定一个清晰的执行计划。这个计划会列出所有需要进行的修改步骤。只有当他对这个计划感到满意，并确认 Claude 的理解与他一致后，他才会切换到自动接受模式 (auto-accept)，让 Claude 按照既定计划去执行。这个过程确保了 AI 的行动在可控的轨道上

困难任务 ：

定义：这是指那些高度复杂、充满不确定性或需要深度架构思考的任务。例如，设计一个新系统、重构一个核心模块，或者解决一个深层次的性能瓶颈

工作流：在处理这类任务时，人类开发者必须是主导者。Boris 强调，此时的他才是驾驶员，而 Claude 则扮演着一个强大的结对编程伙伴或辅助工具的角色。他会利用 Claude 来快速进行代码库研究、探索不同的实现思路、或者快速编写一些原型代码来验证想法和理解系统边界。但他会亲自完成大部分核心的、关键的代码实现工作。在这种模式下，AI 的角色是辅助思考和加速探索，而不是主导执行。最后，或许可以让 Claude 来完成一些收尾工作，比如编写单元测试

通过这种分级策略，开发者可以根据任务的性质灵活地调整与 AI 的协作深度，既能最大化地利用 AI 的效率优势，又能确保在关键和复杂的环节中保持人类的控制力和洞察力

参考：

https://www.youtube.com/watch?v=iF9iV4xponk