打开 IDE 里的 AI 面板，问一句，写一段。改完代码，再手动切终端跑测试、提 Git、查日志。

你是不是也把 AI 编程工具，用成了一个「纯聊天框」？

看起来提效了。其实很多时候，只是把「手动写代码」，换成了「手动喂提示词」。

问题不在模型不够强。问题在于，工具形态还停留在旧时代。

当开发者开始从「写代码的人」，变成「管理编码智能体的人」，AI 编程工具就不能只停留在补全代码、回答问题这一层。它必须更靠近真实工作流，更靠近工具链，更靠近软件生产的全流程。

斯坦福大学2025年秋季课程《The Modern Software Developer（CS146S）》第四周第二讲，Anthropic 的 Boris Cherny 讲的表面上是 Claude Code。但更准确地说，他在回答一个更大的问题：

真正适合编码智能体时代的开发工具，到底该长什么样？

00｜核心结论（TL;DR）

这一讲最重要的是一个非常清晰的产品判断：

下一代AI开发工具，不该只是「AI + 编辑器」。它应该是一个终端原生、可调用工具、可适配不同任务工作流、覆盖更长软件开发生命周期的编码智能体工作台。

Boris 的逻辑，可以浓缩成四句话。

第一，编程正在来到一个拐点。被改写的，不只是「代码怎么写」，而是「软件怎么被生产、验证、交付」。

第二，Claude Code 给出的答案，不是做一个更花哨的聊天框。而是选择三条路线：终端原生、底层模型可访问性、无限可定制。

第三，真正好的 AI 开发工具，不是为今天的模型做设计。而是为六个月后更强的模型做设计。

第四，AI 开发工作流不该只有一种。研究型任务、测试型任务、原型型任务，本来就应该走不同路径。

这就是这场讲座最有价值的点。Boris 教你：未来的 AI 开发工具，应该站在软件生产链的哪一层。

01｜核心追问：AI 编程工具该站在软件生产链的哪一层？

很多人一看到 Claude Code，第一反应是：

不就是又一个 AI 编程工具吗？

但 Boris 这场讲座最有价值的地方，不在「它有哪些功能」。而在于他试图重新定义：

AI 编程工具，到底应该站在软件生产链条的哪一层。

过去十几年，开发工具的核心战场一直是 IDE。谁更顺手，谁更懂当前文件，谁集成得更深，谁就更有优势。

但到了编码智能体时代，问题变了。

你关心的不只是：

它会不会写这段代码。你真正关心的是：

它能不能理解代码库；能不能拉 Git 历史；能不能搜索文档；能不能跑测试；能不能接 CLI 命令行界面；能不能进入 PR、部署、自动化这些真实流程。

这时你需要的，已经不是一个更强的聊天窗口。而是一个更完整的工作台。

说得更直白一点：

它不是把模型硬塞进 IDE 里凑数。而是要让模型真正接入到软件生产的全流程中。

这才是 Claude Code 这一讲真正讨论的东西。

02｜为什么 Boris 一上来就在讲「拐点」：因为三条曲线同时变陡了

Boris 一开场就给了一个判断：

编程正在来到一个拐点。

为什么是拐点？

因为今天不是只有模型在变强。而是至少三条曲线，同时在加速。

第一条，是编程语言的生产力曲线。从 Fortran、C、Java、Python，到 Go、Rust、TypeScript，抽象层越来越高，甚至从命令式编程向声明式编程演进，开发者能用更少的心智负担组织更复杂的系统。

第二条，是 IDE / DevX 的生产力曲线。从 ed、vi、Emacs、Eclipse，到 Copilot、Devin、Claude Code，工具不再只是编辑器，而开始接管越来越长的任务片段。

第三条，是验证方式的演进曲线。从手动调试、静态类型、自动化测试、持续集成，一路扩展到 AI 驱动的漏洞测试、AI 驱动的单元测试、AI 驱动的模糊测试。

这三条曲线叠在一起，指向一个核心变化：

被重写的不只是「代码怎么写」，而是「软件怎么被生产、验证、交付」。

这三条曲线叠加后的直接影响，其实也很残酷：

开发者最值钱的能力，不再只是「写代码的手速」。而是「组织软件生产的能力」。

这也是很多人会觉得今天的AI编程工具「提效，但还不够颠覆」的原因。因为大家只是把 AI 用在了「写代码」这一层。而真正大的变化，发生在更长的软件生产链路上。

03｜三大产品观：击中开发者最痛的三个问题

Boris 把 Claude Code 的方法，概括成了三个词：

• 终端原生
• 底层模型可访问性
• 无限可定制

这不是三个卖点。这是三条产品判断。

📌 Claude Code 三大核心产品观

1. 终端原生：离执行面更近，让AI融入真实开发工具链
2. 底层模型可访问性：放开模型底层能力，如上下文窗口、多模态能力等，而非只使用封装好的对话接口
3. 无限可定制：真实团队的工作流，本来就不可能只有一种

3.1 为什么是「终端原生」：因为你的痛点从来不是「代码写得慢」

很多开发者会本能地觉得，下一代 AI 开发工具应该更图形化、更 IDE 化。

为什么 Claude Code 反而选择终端原生？

因为你真正的痛点，往往不是写一段代码要多久。而是 AI 只能做局部工作，不能沿着你的真实开发流程把事做完。

你在聊天框里让它改了文件。然后你还得自己切终端跑测试。自己看日志。自己提 Git。自己排查脚本和环境问题。

这时 AI 只是一个局部助手。不是一个工作伙伴。

而终端恰恰是最接近执行面的地方。

Git、Docker、测试命令、部署脚本、自研CLI、日志查询工具，都在这里。这也是 Boris 为什么会强调：掌握团队的 CLI 工具，才能让你关注解决方案，而不是语法。

所以终端原生不是复古。而是一个非常现实的判断：

未来的 AI 开发工具，必须活在开发者真实工作的地方。

编者注：最近 MCP 走衰，以谷歌为首的公司正在推动 CLI+API 的方式让 AI 接入其生态系统。

3.2 为什么强调「底层模型可访问性」：因为很多工具不是模型不够强，而是封装太厚了

很多产品会把模型包成一个很完整的「魔法黑盒子」。

表面上，这很友好。实际上，也很容易把开发者锁死在少数预设姿势里。

而 Boris 的思路不是这样。

Claude Code 不只有终端。它还有 SDK，也就是软件开发工具包；还有程序化调用，比如 claude -p 这种非交互调用，本质上就是可以直接嵌进脚本和自动化流程里的调用方式。

这背后的意思非常重要：

不要只问模型能不能回答你。要问模型能不能被嵌进你的工作流、自动化、系统和产品里。

这才是「底层模型可访问性」的价值。

它让 AI 开发工具从「一个界面」，变成「一个能力层」。

3.3 为什么要「无限可定制」：因为真实团队一定是异构的

真实团队里，从来没有一条放之四海而皆准的标准工作流。

有人每天要查日志。有人要扫 Git 历史。有人要接内部 CLI。有人要进 CI。有人要做 PR 自动化。有人要对接 MCP。

编者注：MCP 可以理解成多工具协作协议，本质上是让编码智能体能用一种更标准化的方式去调用外部工具。你可以把它想成「给智能体插工具」的一层通用接口。

如果工具不够可定制，它就只能在演示环境里很亮眼。一旦进入真实团队，就会因为适配不了而失效。

Claude Code 把「工具集成 和 mcps」和「智能高效自动化」单列成使用场景，这已经说明 Boris 不是把它当成一个单纯写代码的产品。

越接近真实生产环境，越不能指望一种固定姿势。所以强工具的上限，不只取决于模型，也取决于它有多可编排。

04｜One code, many faces：同一个引擎，适配全开发环节

Boris 提到一句话：

one code, many faces。

它不是在说「我们支持很多平台」。它真正要说的是：

未来强产品不会只存在于一个界面里。它会是一个底层能力引擎，然后在不同入口长出不同的工作面。

在终端里，它是日常开发控制台。在 IDE 里，它是贴着代码上下文的协作层。在 GitHub 里，它是异步工作流的一部分，如 PR 评审。在脚本和自动化里，它又变成了一个可被流水线调用的能力节点。在 Web 端，它则更像一个团队共享的工作台。

所以你真正该记住的，不是「Claude Code 支持很多入口」。而是：

同一个 AI 能力层，能不能在不同开发环节里被复用。

这才是「智能体工作台」和普通 AI 工具最大的区别。

更进一步说，这也解释了 Claude Code 的野心为什么不只是「写代码」。

Boris 把它的覆盖范围写成了：

• 理解代码库与历史
• 查文档、做设计、定架构
• 写代码、写测试、提提交与PR
• 自动化 CI/CD、配置环境、管理部署
• 调试错误、大规模重构、监控性能

它显然不是要做一个代码补全插件。它更像是一个覆盖整条软件开发生命周期的编码智能体工作台。

图4：One code, many faces 机制图。建议画成一个中心引擎向五个入口发散：终端、IDE、GitHub、Web、SDK。图注：不是多平台适配，而是同一个智能体引擎适配不同开发环节

05｜最容易被讲浅的一点：不是找万能提示词，而是让工作流适配任务

这一讲最实用的部分，是 Boris 没有给出一条「最佳用法」。

他给的是一个更高级的判断：

别找万能提示词。要让工作流适配任务。

这句话，基本可以当作整个 AI 开发工作流设计的总原则。

📌 AI 开发三大核心工作流

1. 研究型任务🔍：explore → plan → confirm → code → commit
2. 测试驱动型任务✅：tests → commit → code → iterate → commit
3. 原型型任务🎨：code → screenshot → iterate

5.1 研究型任务：先探索，再规划，再确认

Bug 根因分析、读历史设计、理解陌生代码库，这类任务最怕的不是慢。最怕的是模型太快开始改代码。

所以更好的节奏是：

先探索，再规划，再确认，然后再编码。

举个更有体感的例子。

比如线上出现一个偶发的支付失败 bug。这时更好的做法，不是直接让 AI 去改支付逻辑。而是先让它探索最近三次相关提交、搜索关键日志、梳理可能的根因，再给你两种修复方案。你确认方向之后，它再开始动代码。

这其实就是四个字：

先计划，后执行。

5.2 测试驱动型任务：先立验证闭环，再开始收敛

有些功能补全、边界修复、历史欠账，非常适合另一条路径：

先写测试，再编码收敛。

这背后的逻辑是：你不是让模型凭感觉写。你是在先给它一个明确的验收边界。

比如你要给订单接口补一个「库存扣减」逻辑。这时可以先让 AI 写好覆盖「库存不足」「并发扣减」「重复提交」这些场景的单元测试。先把测试提交下来。然后再让它去写业务代码，迭代到测试全过为止。

这就是「验证闭环」的价值。

AI 工具再强，它本质上也还是概率系统。你越早把验证闭环建起来，后面的返工就越少。

5.3 原型型任务：代码、截图、迭代

前端、交互、原型，并不总是「代码对了就行」。

很多时候，核心是：它看起来是不是对。

所以 Boris 给出的第三个步骤是：

编码做出来。截图。对照设计稿并迭代。

比如你要做一个移动端支付弹窗。第一轮先让 AI 写出基础 UI。第二轮把截图和设计稿放在一起比。第三轮把「按钮层级不对、间距不对、文案位置不对」这些点喂回去。再迭代到接近设计稿。

Boris 给出的 TODO UI 反复迭代的例子，本质上就在说明：今天的编码智能体，已经不只是在写实现。它开始进入产品和设计反馈闭环。

AI 编程的高阶能力，不是更会写提示词。而是知道不同任务，该走哪条工作流。

06｜最后三条教训，整场讲座最宝贵的内容

如果说前面讲的是产品形态。那最后讲的，就是产品方法论。

Boris 最后给了三条教训：

1. 为六个月后的模型做设计
2. 随时准备演化
3. 别只问「模型还能替我做什么」

这三条，几乎可以当作今天所有 AI developer product 的生存法则。

6.1 为六个月后的模型做设计

不要只为今天能做的事设计产品。因为模型进步太快了。

今天你觉得必须手动的部分，半年后也许就自动了。今天你觉得很惊艳的功能，半年后也许就成了底层能力。

所以真正好的 AI 开发工具，不是追着当前模型能力做壳。而是让模型变强以后，自己的价值还能继续放大。

6.2 随时准备演化

AI 工具的交互、边界、工作流，不会长期稳定。

今天最顺手的入口，可能半年后就不是了。今天最合理的权限模型，后面也可能要重写。

所以你做的不是一个固定工具。而是一套持续演化的人机协作系统。

6.3 别只问「模型还能替我做什么」

这句话很像一把刀。

它在提醒开发者，也在提醒产品经理：

别只盯着模型能力清单。别只问「这个模型还能替我多做什么」。

更重要的问题是：

你有没有把自己的工作流、控制面、护栏、验证闭环、可追溯流程搭好，去真正放大模型。

这里其实隐含着一个特别像《The Bitter Lesson》的判断：

长期有复利的，不是把产品绑死在今天最好用的技巧上。而是让它变成一个能持续适配模型进化的通用系统。

07｜今天就能开始的五个动作：把这堂课的产品观落到你的开发里

这一讲中最宝贵的内容是 Boris 和 Claude Code 的产品观。你不需要先把所有工具全换掉。你先把以下五个动作做起来，就已经是在往对的方向走了。

编者注：这五个动作，对应着前面提到的三大产品观和核心方法论，帮助你把抽象的判断落地。

第一，把 AI 从聊天框里释放到终端。实践一个简单的真实工作流。比如使用 Claude Code CLI 修 lint、跑测试、生成 commit message，不用 IDE 面板，只用终端去完成。你会第一次真正体会到「局部补全」和「全流程执行」的差别。

第二，按任务类型设计 AI 开发工作流。排查根因，用「探索→规划→确认→编码」。补能力边界，用「测试→提交→编码→迭代」。做前端原型，用「代码→截图→迭代」。不要所有事情都只会「问一句，改一轮」。

第三，把高频动作做成可复用资产。跑测试、做 review、整理提交说明，这些动作别每次都临时手写提示词。把它们做成命令、脚本、技能，才能真正沉淀成团队资产。

第四，给 AI 工具接上外部能力。如果它只能看当前目录里的文件，那它永远只是在局部打转。试着让它接入公司的日志查询接口、GitLab API、设计稿链接，或者内部 CLI。让它不只是碰代码，还能碰到真实业务上下文。

第五，用「六个月后」的眼光评估你现在的 AI 编程工具。问自己一个问题：

如果模型能力再强十倍，我现在用的工具，会放大我，还是束缚我？

你慢慢会发现：

未来更值钱的，不是你亲自做完每一步。而是你能不能搭好控制面、护栏、验证闭环和可追溯流程，让编码智能体持续把事情做成。

08｜结尾：这不是一堂功能课，而是一堂产品观课

如果你把这场讲座理解成「Claude Code 有哪些功能」，那就看浅了。

Boris 真正想讲的，其实是：

未来的 AI 开发工具，不是帮你写代码。而是帮你组织整条软件生产线。

它不是一个更花哨的聊天框。不是一个更聪明的补全器。也不是另一个只能做局部工作的AI面板。

它更像一个新的软件工作台。一个让模型、工具链、验证体系、自动化流程真正连起来的执行面。

这，才是编码智能体时代最值得重视的方向。

09｜下一篇我们讲什么

这一讲介绍的是未来的工具形态。下一讲将由 Mihail Eric 介绍一个更接近产品真相的问题：一个卓越的 AI 开发者产品，到底是怎么做出来的？

当智能体开始进入开发环境，开发者熟悉的 IDE、终端、聊天界面、反馈闭环，会被怎样重新组合？什么样的产品，才能既让普通用户「零配置也能立刻感受到价值」，又让高级用户拥有足够深的配置能力和工作流自由？

本讲金句和互动

✨本讲核心金句

1. 下一代 AI 开发工具，不是「AI + 编辑器」，而是覆盖从理解问题到交付结果的全流程执行面。
2. 真正的好产品，不为今天的模型做设计，而为六个月后更强的模型做设计。
3. AI 编程的高阶能力，不是找万能提示词，而是让工作流适配不同任务类型。
4. 未来的 AI 开发工具，核心不是替你写代码，而是帮你组织整条软件生产线。

互动话题

看完这篇，你现在用 AI 编程工具时，最卡壳的环节是哪一步？

欢迎在留言区聊聊。如果这篇内容也戳中了你对 AI 编程工具的困惑，别忘了点个赞、点个在看，也欢迎转发给身边的开发者朋友。

课程 PPT

建议结合 Claude Code 这份原始 PPT 一起看。你会更直观看到 Boris 是怎么一步步把「AI 编程工具」讲成「编码智能体工作台」的。尤其是三条产品判断、三类工作流，以及最后三条 lessons，原始表达都很值得品味。

关键词

斯坦福 CS146S｜Claude Code｜AI 编程工具｜终端原生｜编码智能体工作台｜AI 开发工作流