Claude Code之父自曝:“今年还没亲手写过一行代码”，CC诞生的原因竟然是。。。

关注

转载最新推荐文章于 2026-07-30 17:00:28 发布 76 阅读 AI 写同款· GEO 优化 ›

Mac中安装Claude Code及cc-Switch 本文介绍了在Mac系统上安装和使用Claude Code及cc-Switch工具的完整流程。主要内容包括：通过curl或Homebrew安装Claude Code 使用npm全局安装Claude Code 基础配置和环境变量设置常用命令行操作和交互模式命令推荐使用cc-Switch工具实现模型供应商快速切换结合OpenRouter平台实现多模型API统一管理该方案支持国内外主流AI模型（如GPT、Claude、GLM等）的无缝切换，简化了开发者的模型调用流程。文章详细说明了从安装到配置再到实际使用阅读详情

*👇我的小册 54章教程:(**小白零基础用Python量化股票分析小册*) ,原价299，限时特价2杯咖啡，满100人涨10元。

来源：Sequoia Capital

转自：CSDN（ID：CSDNnews）

最近一段时间，AI 圈里最受关注的话题之一，莫过于 Anthropic 的持续升温。

一边，是其估值再度冲高，被外界视作超越 OpenAI 的新晋 AI 之王；另一边，则是 Claude Code 在开发者社区里的迅速扩散。越来越多人开始意识到：AI 写代码这件事，可能已经不再停留在“辅助工具”的阶段，而是在悄悄改写整个软件开发流程。

就在这样的背景下，Anthropic Claude Code 之父 Boris Cherny，近日出席了红杉资本举办的 AI Ascent 2026，与红杉资本合伙人 Lauren Reeder 展开了一场关于“编程未来”的深度对谈。

而 Boris Cherny 开场抛出的几个观点，几乎每一句都足够引发争议：

2026 年，我还没有亲手写过一行代码；
我认为早在去年 10 月或 11 月，我们就达到了模型可以编写 100% 代码的临界点；
编程问题其实已经“被解决了”；
现在大部分工作都在手机上完成，每天能在手机上提交几十个 PR；
我觉得 /loop（循环）代表了未来，强烈建议大家去尝试；
未来十年的创业公司数量将会增加 10 倍；
编写软件会成为每个人都具备的通用技能，就像发短信一样简单。

这并不是一场单纯讨论 AI Coding 工具效率的访谈。相比“AI 能不能替代程序员”这种老问题，Boris 更关心的是：当代码生成几乎趋近于零成本后，软件工程本身会变成什么？开发者的角色还剩下什么？为什么“循环（loop）”会成为下一代软件的核心？以及，人类是否正在进入一个“没人再真正手写代码”的时代？

以下是这场对谈的完整内容：

Claude Code 缘起一次“偶然”

Lauren Reeder：Boris，感谢你接受这次访谈，这其实挺难得的。今天现场坐着的大多都是开发者，而你某种程度上可以说是“开发者的开发者”。你职业生涯里写过大量代码，也写过像《TypeScript 编程》这样的编程书籍。

我记得我们上次聊天时，你提到自己在整个 2026 年到现在，甚至还没有亲手写过一行代码。这种变化，确实很惊人。

Boris Cherny：其实还有一个鲜为人知的事情，我在中学时写过一份关于为 TI-83 Plus 计算 Basic 语言编程的指南。我刚刚搜了一下，它居然还流传在互联网上，这太让人尴尬了，请大家千万别去搜。

Lauren Reeder：我们一定会去看看的（笑）。接下来想先聊几个基础问题。或许可以先从 Claude Code 的起源讲起：它最初是怎么诞生的？又是如何一步步发展起来的？

Boris Cherny：关于 Claude Code 的诞生，其实也是”误打误撞“出来的，带有一点偶然性。

我在 2024 年底加入了 Anthropic 的一个名为 Anthropic Labs 的孵化器团队。当时我们团队只有几个人，就像是一个创新小组。起初，我们明确了目标，开发了 Claude Code、MCP（模型上下文协议）和桌面应用程序。

当时，在做出我们真正想做的东西之后，团队便暂时解散了。如今，这支队伍已经重新集结，开始推进第二阶段的工作。目前，整个项目由 Anthropic 首席产品官、Instagram 联合创始人之一 Mike Krieger 负责领导。

我之所以开始关注编程领域，是因为我们感觉到存在一种“产品过剩（ProductOverhang）”。这是我们在实验室内部常说的一个词，指的是模型已经具备了执行某些任务的能力，但目前还没有产品能够充分发挥出这些能力。

在 2024 年底，编程的最高水平还是“自动补全”，也就是在 IDE 里按 Tab 键，一行一行地完成代码。那是由 Claude Sonnet 3.5 首次开启的能力。但我们觉得可以走得更远，模型已经准备好迈出下一大步了。我们不需要再做自动补全，而是可以让 Agent（智能体）直接编写所有的代码。

所以我把它做了出来，但最初的六个月体验其实并不好，基本上很难正常使用。我自己也只在大约 10% 的编码工作中会用到它。甚至在我们刚发布 Claude Code 的时候，它也没有立刻引起很大的反响。

虽然当时已经有不少人在使用，但它并没有像今天这样呈现出指数级增长。真正的转折点出现在 2025 年 5 月份 Claude Opus 4 发布之后。我记得很清楚，从那时起 Claude Code 的使用开始进入指数级增长阶段，并随着后续 4.5、4.6、4.7 等版本的迭代持续攀升。

本质上，我们其实是在做一个初期完全不具备 PMF（Product Market Fit，指产品和市场达到最佳的契合点，你所提供的产品正好满足市场的需求，令客户满意）的东西。我们清楚它前六个月不会有 PMF，因为我们是围绕“下一代模型”的能力来设计产品的。这也一直是我们的核心思路。

就 Anthropic 而言，我们长期关注的方向始终是业务、企业、安全以及编程，这些领域也是我们希望重点构建产品的地方。因此，在某个阶段，我们其实已经明确想要做一款产品，但具体形态并不清晰。这在某种意义上，就变成了一次产品方向的押注。

不再手搓代码，大部分的工作都是在手机上完成的

Lauren Reeder：这是一个非常精彩的故事，特别是它起源于一次“偶然”。你曾在公开场合说过，你认为编程问题已经“被解决了”。既然这是 Anthropic 的三大核心赌注之一，你能详细解释一下你的意思吗？还有哪些问题是尚未解决的，或者说可能会产生哪些其他问题？

Boris Cherny：我想先问大家一个问题：谁现在还是 100% 手写代码？（现场无人举手）那么，谁是 100% 使用像 Claude Code 这样的 Agent 编写代码？（现场部分人举手）剩下的朋友应该是在两者之间，大概各占 50%。

对我个人来说，这个比例是 100%。Claude Code 的代码库是公开过的，所以大家知道，它的结构其实很简单，就是 TypeScript 和 React，没有什么大秘密，也不复杂。

我们选择 TypeScript 和 React 的原因是它们对模型来说非常“易于理解”。当我们开始构建代码库时，模型还没有今天这么智能，所以语言和框架的选择非常重要。当然，现在的模型几乎可以编写任何语言，可以快速掌握它从未见过的各种新框架。正因为如此，我认为早在去年 10 月或 11 月，我们就达到了模型可以编写 100% 代码的临界点。

对我现在的工作来说，模型编写了我 100% 的代码。我每天通常会提交几十个 Pull Request (PR)。上周有一天我甚至提交了 150 个 PR，那是我为了测试极限而刷新的纪录。所以对我来说，编程问题确实已经“被解决了”。

但这并不代表在所有地方都是如此，毕竟还有很多非常庞大、复杂的代码库，以及模型还不擅长的冷门语言。但正如大家所知，模型正在快速进化。通常情况下，答案就是：等待下一个版本的模型。

Lauren Reeder：你能和我们分享一下你个人的开发环境配置吗？你前几天跟我们展示过，那真的非常疯狂。

Boris Cherny：我大概半年前在 Twitter 上分享过我的配置（https://x.com/bcherny/status/2007179832300581177）。

有趣的是，我当时并没意识到这会让大家感到惊讶，因为那对我来说就是很平常的编程方式。但从那时起，情况又发生了变化。

现在，我大部分的工作都是在手机上完成的。如果你打开手机上的 Claude App，在左侧有一个小小的代码选项卡，我会在那里同时开启很多个会话。每个会话通常会有很多个 Agent 在运行。目前我可能同时运行着几百个 Agent。每天晚上，我会有几千个 Agent 在进行更深层次的工作。管理这些工作有几种方式：一种是让 Claude 启用一系列子 Agent（Sub-agents）去执行任务。

而我发现自己越来越频繁使用的功能是 /loop。这是一个非常酷且简单的功能。本质上，你可以让 Claude 使用 Cron（计划任务）来调度未来某个时间点的重复任务。它可以每分钟、每五分钟或每天运行一次。

我现在有几十个 loop 任务在运行：有一个负责照看我的 PR，比如修复 CI 错误、自动 rebase；另一个负责监控 CI 的健康状况，如果出现不稳定的测试，它会自动去修复；还有一个负责抓取 Twitter 上的反馈，并每 30 分钟为我进行一次聚类分析。

我觉得 /loop 代表了未来，强烈建议大家去尝试。我们最近还推出了 routines（常规任务），它的原理类似，但运行在服务器端，所以即使你关掉电脑，它也会继续运行。

Lauren Reeder：这就是你个人的开发方式。那么你认为未来的团队会是什么样子的？基于你现在的实践，如何让团队中的每个人都能理解上下文并协同前进？还是说我们应该把更多的控制权交给 Agent？

Boris Cherny：虽然很难做预测，但我认为未来的趋势是会出现更多的“通才（Generalist）”。目前我们谈论的通才通常还是指工程师，比如一个产品工程师既能做 iOS，也能做 Web 和后端。但我认为，未来我们会看到更多跨学科的通才。这些工程师不仅擅长产品工程，还精通设计；或者同时精通产品、数据科学和工程。

这种情况已经在我们团队中发生了。Claude Code 团队的很多人都是跨学科通才。我们团队的每个人都会编程：工程经理、产品经理、设计师、数据科学家、财务人员、用户研究员，每个人都在写代码。他们可能是某个领域的专家，但现在每个人都在参与编程。

所谓的“SaaS 大崩盘”是否会发生？

Lauren Reeder：随着 AI 让编写代码的成本降低了 10 倍甚至 100 倍，软件产品的价值会发生什么变化？我们会面临所谓的“SaaS 大崩盘（SaaS-pocalypse）”吗？

Boris Cherny：这是我最喜欢的问题。我认为会有两件事发生，而且都不是大家目前普遍讨论的内容。

首先，我不知道在座各位是否听过《Acquired》这个播客？那是我最喜欢的播客，我有幸去参加过一次他们的节目，感觉就像见到了偶像。他们提到过 Hamilton Helmer 写的《战略 7 力》这本书，里面讲述了商业中的七种护城河。我认为随着 AI 的出现，其中一些护城河会变得更重要，而另一些则会变弱。

首先，“切换成本”将变得不再重要，因为你可以直接让模型帮你把数据和功能从一个平台迁移到另一个平台。同样，“流程能力”作为护城河也会变弱。对于那些以工作流和流程为核心竞争力的公司来说，现在的模型非常擅长梳理和优化流程，尤其是 Opus 4.7 这种具备极强爬坡能力的模型。只要你给它一个目标，它就能不断迭代直到完成。

其次，如果我们回顾过去十年的创业公司数量，我认为未来十年的创业公司数量将会增加 10 倍。因为现在一个几人的小团队就能构建出与大公司同等价值的产品，并进行正面竞争。大公司必须不断调整业务流程、改变协作方式、重新培训员工使用新技术，这会面临巨大的内部阻力。但对于在座的各位创业者来说，你们没有这个包袱。如果你从零开始，原生性地利用 AI 进行构建，你会拥有巨大的优势。这是创业最好的时代，尽管颠覆即将到来。

编写软件会像发短信一样简单

Lauren Reeder：听起来我们还是有希望的。下面我们进入观众提问环节。

问：你提到在产品达到市场契合点（PMF）之前六个月就构建了它。现在模型已经足够强大，你认为 Claude Code 的成功有多少归功于模型能力，有多少归功于产品决策？

Boris Cherny：我认为是两者的结合。如果是一年前，比例可能是 50/50。现在来看，虽然模型变强了，但产品设计的“外壳”依然很重要。在 YC 这种创业孵化器里，他们一直强调：构建人们真正热爱的东西。无论模型多么强大，你最终还是要关注每一个细节，为用户创造极佳的体验。

随着模型能力的提升，很多之前需要复杂设计的安全机制——比如针对提示词注入的防护、静态命令验证、权限模式、人工干预等——重要性可能会降低，因为模型本身会变得更加对齐，能更自然地做出正确的判断。

问：你认为编写软件会像使用 Office 办公软件一样，成为每个人都具备的通用技能吗？

Boris Cherny：绝对会，甚至会更普遍，就像发短信一样简单。

我经常读科技史，我觉得最恰当的类比是 1400 年代欧洲印刷术的发明。在印刷术出现之前，只有 10% 的欧洲人识字。那些识字的人通常被国王和贵族雇佣，他们的工作就是读和写，这不是普通人能做到的。

印刷术发明后的 50 年里，欧洲出版的文献数量超过了之前一千年的总和，书籍成本下降了 100 倍。虽然此后又过了几百年，随着教育体系和政府的完善，识字率才真正普及到 70%，但现在我们每个人都会读写。

我认为软件行业正在经历同样的过程，而且速度会比 50 年快得多。软件将被彻底民主化，任何人都具备构建软件的能力。这会产生一个结果：比如编写会计软件，最合适的人选不再是工程师，而是一个精通业务的会计师，因为编程将变得简单，而理解领域知识（Domain Knowledge）才是最难的部分。

问：上次我们聊到多智能体（Multi-agent）时，它还处于实验室阶段。现在我们有了 /loop、/batch 和子团队。你能从模型层面或产品层面讲讲，你们是如何改进智能体协作和任务分派体验的吗？

Boris Cherny：在产品层面，这很大程度上取决于提示词（Prompting）的优化。我们会微调提示词来引导模型更好地进行并行处理。但更神奇的是，随着模型能力的提升，它开始自发地具备这种能力。

例如，当我告诉 Opus 4.7 去查询某个数据时，它会主动意识到数据随时间变化，并建议说：“我为你开启一个循环任务吧，每 30 分钟给你一份报告，并通过 Slack 发给你。”它会自动调用 Slack 的 MCP 连接器来完成这一切。

所以，随着时间推移，不再需要用户去思考如何更好地操作工具，这应该是产品设计和模型进化的责任。

问：Claude Code 很好地利用了开发者的本地工作流。但对于一般的知识工作者来说，他们的工具大多在云端。你们如何让非开发者也能像使用 Claude Code 一样高效地使用这些工具？

Boris Cherny：这是一个非常好的问题。我以前在大公司工作过，深知在大规模组织中迁移环境是多么痛苦。

对于知识工作者来说，好消息是他们的工具（如 Salesforce、Google Docs）已经在云端了。我们的解决方案是 MCP（模型上下文协议）。你在 Claude AI 中使用的那个 MCP 连接器，可以同样连接到 Salesforce、Google Docs 或日历。

无论是 Claude CLI 还是 Claude Code 都能调用这些能力。对于那些还不支持 MCP 的系统，我们有“Computer Use”能力。目前 Anthropic 在这一领域处于领先地位，它能像人一样操作电脑上的几乎任何软件。虽然现在速度还比较慢，但在 Opus 4.7 版本的加持下，效果已经非常惊人。

Lauren Reeder：好的，感谢 Boris 精彩的分享。