EPISODE· generated 2026-06-09 16:39:10· 29 min
Boris Cherny: Claude Code & the Future of Engineering | Acquired Unplugged presented by WorkOS
Anthropic开发的Claude代码智能体源自一个内部原型团队，负责探索未来AI产品可能性。最初在基本编码任务上遇到困难，该项目利用了Anthropic在AI安全研究方面的重点以及编码任务的清晰和受限性质，逐步提升了其能力。
interviewcryptoaiweb3
ready · seed-vc · qwen3-tts
0:00/0:00
⚠ The Chinese audio is an AI-generated dub (speech synthesis / voice conversion), not a real recording and may contain errors. Based on the original English interview; all rights remain with the original creator.
original lang
EN
dubbed into
中文 (ZH)
pipeline
Plan C · voice conversion
voice model
seed-vc · qwen3-tts
001
好吧，我们需要听一听起源故事。
002
Claude 的代码是从哪里来的？顺便说一句，能在这里听到你们的声音真的很疯狂，因为我习惯于以两倍速度听到你们的声音。
003
大概是以两倍速度。两倍速度，而且我们对所有这些小的口头习惯都做了很多编辑，你知道的，所有这些。
004
嗯，是的，从很多方面来说，这有点像是一次意外。嗯，我在 Anthropic 的一个团队里加入，时间是 2024 年底，这个团队当时是一个原型开发团队。嗯，这个团队叫做 Labs 团队。我们
005
实际上把它重新带回了公司。这个想法是弄清楚下一个大产品是什么。同时，我们也在推动模型的前沿，弄清楚我们该如何改进模型，以更好地支持这个产品，你知道的，
006
那个尚未被构建的未来产品。很难知道模型应该朝哪个方向进化，因为直到有一个真正推动前沿的产品出现之前，你其实并不清楚。
007
当时有一种非常强烈的‘产品滞后’感觉，也就是说，模型可以做到很多事情，但还没有任何产品能够真正捕捉到这些能力。
008
比如说当时的代码工具，只有自动补全功能。你可以向智能体提问，但它无法编写代码。
009
是的，直到最近模型才变得足够强大。之前它确实做不到。所以我们觉得，有机会全力以赴，打造一个纯粹的代码智能体产品。
010
你知道，我们确实做了，但一开始效果很一般。它可能只替我写了大约10%到20%的代码。
011
在这之前，Anthropic的编码状况如何？有多少关注？
012
你知道，在 Anthropic 内部，当时我们仍然在使用 IDE。不过，作为 Anthropic 这家公司，我们一直都很重视编码。嗯，我们一直都很重视工具的使用。
013
我们一直都很重视计算机的使用。这一直是我们的核心研究方向，因为，你知道，对我们来说，我们的存在就是为了研究 AI 安全。这就是我们存在的原因。
014
比如说，如果你随机问 Anthropic 的一个人，你只要把他叫到走廊里问，"你为什么在这里？" 他会说 AI 安全。
015
这就是公司里每个人存在的原因。他们，包括我，都深信不疑，这正是最需要解决的问题。
016
解决这个问题有很多方法。你可以研究机制可解释性，也可以做对齐工作。有很多方法可以像在培养皿中一样研究模型。
017
但从根本上说，你必须在真实环境中研究它，才能看到它在各种安全措施到位后会做什么。这就是 Claude 代码的作用。嗯。但，你知道，对于
018
Anthropic作为一家公司，方向一直专注于安全。而研究安全的方式，你知道，有很多层次，包括在真实环境中部署模型。而且，嗯，
019
什么样的方式是有效的？那就是编程。因为这是模型与世界互动的方式。因此，如果你想研究各种模型对齐问题，你得让它足够有用，让人们使用它，这样你才能对其进行研究。
020
编程只是一个非常明显的应用场景。
021
嗯，所以从一开始，这就是重点。这是一个非常干净的领域，因为你们有这么多训练数据。
022
它要么能工作，要么不能工作。而且，根据语言，它要么能编译，要么不能编译，或者它有某种非常明确的通过或失败的
023
测试能力。而且这是一个正确解决方案非常受限的领域。在英语中，有无数种正确、优美的诗歌，但编写正确代码来解决某个问题的方式却是有限的。嗯，用它作为你的培养皿，有一种优雅之处，
024
鉴于这一点。没错，是的。之前，呃，你知道，你知道 Hofstadter吗？
025
他是写过《哥德尔， Escher， Bach》的人。有人读过吗？哦，是的，是的，是的。是的，很棒的一本书。是的，那本书真的很棒。但他还写了一本非常奇怪的书，在
026
‘80年代，关于他对于人工智能路径的想法。因为他是一位教授，他在学校教过 AI，而且当时他也在授课。他当时在谈论认知和智能的基础，即识别模式。
027
他研究这一问题的一种方式是，他的一项爱好是将英语诗歌翻译成法语。直接翻译很少是正确的翻译。实际上，这其中有很多品味的考量。有时你可能想稍微调整一下，使韵律
028
合适。有各种不同的方法可以做到这一点。所以是的，这就像一个模糊的问题。但我觉得编程更容易解决。它也非常具有商业价值。
029
嗯，所以它帮助我们构建业务。而且这也是我们最喜欢的客户，企业、初创公司、公司所拥有的那种业务。
030
因此它帮助我们建立这种商业模式。所以你知道，我们不需要做广告。而且你知道，我们可以专注于安全性，这是我们关心的事情。它帮助我们建立一个可以真正做到这一点的业务。
031
嗯，你在加入Anthropic之前来自Meta。你在Meta时有很多关于代码的专注。我很好奇，现在回过头来看，你当时在Meta所做的事如何影响了Claude Code 的起步？
032
嗯。对我来说，开发工具一直是一个副业。它从来不是主要的事情。我觉得这是构建开发工具的最佳方式，因为你想要专注于解决一个商业问题，打造一个人们喜爱且对人们有用的东西。
033
从根本上说，这就是我们作为工程师在这里要做的事情。你知道，总是 YC 像这样灌输给你。我也是这么想的。你之前做过 YC 吗？
034
是的，是的。我实际上我曾是一家 YC 公司的首位员工。这要追溯到大约2010年、2011年。差不多那个时候。那是一批早期的员工之一。
035
哇，真酷。对我来说，开发工具一直是一种副业，我做产品，而在做产品的过程中，如果开发体验不好，我就会构建工具来让它变得好一点。我一直都是这样做的。
036
嗯，所以在这里我只是应用了那种先为自己构建东西，然后希望对其他人也有用的心态。而且呃，我看到它确实如此，这太棒了。
037
所以你说它一开始很糟糕，你只信任它处理你工作中大约10%的任务，它也只完成了你工作中大约10%的任务。早期的瓶颈是什么，你们是怎么
038
解决它的，让它变得更好？据我所知，你已经六个月没有在工作中写过一行代码了。是的。
039
所以这和它只完成大约10%的工作完全不同。是什么改变了？呃，我记得，那是五月份，是 Sonnet 4 和 Opus 4。然后在呃，十一月，它变成了 Opus 4.5。
040
所以只是底层模型发生了变化。是模型本身。在 harness 上做了很多工作。在让 Claude Code 变得更好上做了很多工作。你知道，每个人使用这些东西的方式都不一样。
041
这就是为工程师构建产品的难点。它不是消费品，因为工程师在使用方式上非常有主见。
042
因此，你知道，我们最初是从一个 CLI 开始的，但后来我们开发了一个桌面应用，开发了一个移动应用，开发了，iOS 和 Android 应用。我们有像 Slack 应用，GitHub 应用。你可以使用 Claude Code
043
以你想要的任何方式。因此，很多这些功能都是我们不断创新、学习、试图弄清楚哪些功能是有用的。例如，计划模式就是由此产生的。很多
044
不同种类的工具和体验都是由此产生的。但从根本上说，当我想到这些重大改进以及我的代码中有多少百分比是由模型生成的，它只是模型。比如模型
045
变得更好了，然后它就提升了。在你能够谈论的范围内，到什么程度 Claude Code 的体验反馈到了模型的工作中在 4.0、4.5 等版本发布之前？
046
所以，你知道，每个人 Anthropic 每天都在使用 Claude Code。
047
嗯，所以，构建模型的研究人员使用 Claude Code，而构建产品的人员也使用 Claude Code。
048
所以，这基本上就是循环。你们有没有一些指标，可以数值化地描述它对公司轨迹的影响程度？比如从外部看，你们现在似乎推出的产品比以前多了很多
049
因此，可以合理地假设其中很大一部分原因是因为你们在整个公司内部都在使用 Claude Code。真正把握有多少是归功于Claude Code的正确方式是什么？
050
是的，所以在 AI 实验室工作，你会习惯用指数级的方式来思考。基本上，所有的图表都是指数增长的。所以我们实际上使用对数线性图表来呈现几乎一切。
051
呃，所以x轴是，你知道的，像线性增长，而y轴则是对数线性增长。
052
嗯，而且你知道，一切都在呈指数级增长。比如收入是指数级增长，使用量也是指数级增长，这作为工程师来说，简直是最大的乐趣。谢谢对于忍受这一点。
053
嗯，而且基本上所有的东西都在增长，包括代码。嗯，所以当我们看从 Anthropic 的员工撰写的代码行数和拉取请求数量时，自我们
054
发布了 Claude Code，这已经增长了数百个百分点。嗯，我们之前分享的最新数据大概是3倍左右。不过这个数据其实已经非常过时了。现在实际上要高得多。
055
什么是3倍？呃，是 Anthropic 每位工程师所编写的代码量。我明白了。所以，工程团队的规模增长了很多倍。通常情况下，会发生
056
随着工程团队规模的增长，生产力会下降。在我在 Meta 工作时，我的职责之一是负责所有代码库的代码质量。我们之所以关心这一点，是因为它很有用
057
生产力。如果代码质量高，会让工程师更加高效。我们在这方面也进行了实证分析。嗯，通常会发生的是代码质量变差，生产力下降。另一个现象是，随着工程师人数的增加，生产力也会下降，因为新人
058
人们经常会问工程师，比如，"我该怎么做到这个？我该怎么做到这个？" 但被问的工程师却无法自己编写代码。而且，你知道的，这需要一定的上手时间时间。
059
我们在 Anthropic 看到的第一个现象是，当新成员加入时，他们的上手时间大约是两天。因为，你知道，以前这需要几周时间，但现在只需要两天，因为你只需要问 Wad。
060
我们仍然需要向新加入团队的人解释，比如有人会问："怎么查询数据库？" 答案是打开 Wad，在 Wad 的代码库中运行它，然后让 Wad 查询数据库。
061
因为查询数据库是一种技能，它本身就懂。那么，在 2026 年你招聘的新工程师中，有多少人写过任何代码？
062
嗯，我意思是，你怎么定义写代码？对，对。那是什么？ 等等，你怎么定义写代码？
063
你知道，对我来说，工程一直就像，你知道的，我爷爷用打孔卡编程。比如在苏联 Union，就像对你爷爷来说，编程就是
064
像它是一种纸质的东西，往上面打孔，然后把它放进这个大机器里，机器运行一会儿，然后给你答案。这就是编程。对吧。
065
就像我爸爸写了很多汇编代码，他可能会笑话我写 Python，然后说，"你这不是编程。" 没错，没错。这并不是真正的工程师做的事
066
或者它是非常高级的。但编程的本质就是指令的层级一直在上升。
067
所以，它从开关到打孔卡，再到汇编，然后到 Cobol、Fortran，再到 Java 和高级语言，再到 JavaScript 和
068
Python 和真正的高级语言。嗯。这一直都在发生，而我认为我们正在做的是这个连续体上的某一点。嗯，对我来说，一年前我编程的方式是我在 IDE 中使用某种自动补全功能编写代码。
069
在11月，我卸载了我的 IDE，因为我没怎么用它。我我就是，你知道的，大概在上个月，我根本就没打开过它，所以我我就卸载了它。哇。到那个时候，我可能同时运行了五到十个quad。
070
它们并行运行。我当时是通过提示 Claude 来写代码。现在，我觉得又提升到了下一个抽象层次，我不再提示 Claude 了。我有
071
正在运行的循环。这些循环是那些在提示 Claude 并大致判断该做什么的人。我的工作就是写循环。我认为这将是接下来几个月，甚至可能在今年余下时间里会看到的一种转变。哇。
072
嗯，假设中的我，显然不是真实的我，是一个想加入 Anthropic 工程团队的工程师。嗯，你们今天会怎么评估我？
073
我认为在我们团队中，特别是针对 Claude 代码，我特别看重的是通才。所以，我想大概六个月前我们开始注意到，团队中真正只做传统意义上的工程工作的工程师非常少，你知道的，比如你
074
有一个用户研究员，他们与用户交流，然后把信息写成文档交给设计师，设计师再制作原型，接着交给产品经理，他们进行规划，然后
075
它会交给工程师来实现。我曾在 Microsoft 工作。我对这个过程非常熟悉。
076
这就是过去的情况，但你知道的，我们后来意识到这已经不是团队现在做的事情了。而我们的团队一直以来更偏向于原型开发，但也许六个月前，我们发现团队中的每一位工程师都在做需求界定。
077
每个人都每天与用户交流。人们在做设计。工程师，团队中的每个人都能够胜任像提取数据、进行数据科学工作、构建仪表板等任务。所以，我认为我们团队的
078
开始看到所有角色逐渐融合，几乎变成一个构建者。我认为 Satya 将其称为构建者，大致就是这个意思。
079
这几乎就像一个产品工程师，但你甚至不一定非要是个工程师。没错。而且，比如我们有设计师在发布代码，或者财务人员也在发布代码。
080
嗯，我认为这 我们的首席助理也在发布代码。是的。
081
现在我们在 Acquired 的所有基础设施都迅速转移到了 Claude 代码，因此我可以讲一个关于 Acquired 的有趣小故事吗？
082
所以，我们是一个音频播客。而 YouTube 没有办法只上传音频。你必须上传一个视频。
083
这会很有趣。很长一段时间，它只是一个黑色屏幕的 MP4。
084
嗯，所以，有一个转录本会是个好主意，但我们还没有转录本，因为需要一周时间让人类来制作转录本。幸运的是，有 AI。
085
不管怎样，我之前草草写了一堆类似Claude代码的脚本，其实是我和Claude一起写的，后来我把它扔给了David，然后我说：“你能继续做下去吗？”
086
Yeah. open the terminal. What One day after classes in college, and that was the last time I opened a terminal.
087
嗯。打开终端。呃，大学里的一天之后，之后我就再也没有打开过终端。
088
那天之后，呃，Codox就发布了。而 Codox 的卖点是，如果你想拥有 Claude 代码的强大功能，但又不想去处理终端，你知道的，输入命令，还有安装 NPM 之类的麻烦事。我们
089
实际上听说 David 必须打开终端，所以我们说，"我们必须发布这个。我们只有一天时间。"
090
所以，呃，我想用这个作为切入点，来讲讲 Claude Codox 的故事，因为在我看来，比起那些知道怎么打开终端的人， Claude Codox 的目标市场要大得多，是那些不想打开终端的人。
091
它先走 Claude 代码的方向，说实话，直到 Quadcode 发布之前，这个过程其实花了很长时间。
092
没错。说实话，这就是当时的故事。当时就像是这个版本的某种演绎，比如四月的时候，我记得走进办公室，就在 Quadcode 旁边，你知道的，我们几个人坐的地方，旁边有几个数据科学家。
093
我走进去的时候，其中一个数据科学家的屏幕上开着 Quadcode。
094
这还是 Quadcode 只能在终端上使用的时候，还没有在桌面应用或移动应用上推出。所以，你真的必须知道你在做什么。我问 Brandon，比如说，"Dude，你在干什么？
095
你是在用它做狗食测试吗？只是想大概弄清楚这个东西是干什么的？" 他刚加入团队不久。
096
他说："不，我用它来做数据分析。" 他学会了如何打开终端，学会了如何下载 Node.js，因为当时必须这么做。
097
他还学会了如何安装 Quadcode，如何设置 API 密钥。当时我们甚至还没有订阅服务。
098
他只是用它来做分析。然后，第二周，所有的数据科学家都打开了多个 Quadcode 窗口来做分析，因为它确实很擅长这个。
099
嗯，然后快进到可能五月份或六月份左右，当时有个人在 Twitter 上。你们看到这个了吗？他用它来种植他的番茄植物。
100
他当时就像，他有一个小摄像头，他设置好让它只是监控他的番茄植株。它还控制着植株的营养，而且持续了好几周。和然后在某个时刻，就像那个小番茄一样，他搞定了。
101
Quad说：“这太棒了，就像我们所有的努力都得到了回报。”就像我刚刚看到一条推文，我当时就想到，"天啊，我觉得是时候了。
102
比如现在我们开始突破到主流市场。花了很长时间才让工程师们理解这是什么，但最终他们明白了。现在我们开始看到一个关键的
103
大量非工程师都能使用它。当需求和重量级如此之强时，我认为这正是构建产品的时机。因此，我们开始探索，有很多想法
104
不同的想法。我们用 Claude 编写的代码本身大概用了一周多一点，可能八九天。嗯。
105
大致如此。它完全使用 Claude 代码构建而成。这是众多想法中的一个。一旦我们有了它，我们就觉得这就是我们要找的那个。
106
你们放弃的其他路径有哪些？嗯，如果我要描述创意简报的话，就是把 Claude 代码的强大功能带给那些不想打开终端的人
107
它并不能完全一一对应。你在构建产品时必须有一定的立场，才能抓住 Claude 代码所能完成的一部分工作。
108
是的，我们试过很多。我甚至不记得所有原型了。我想我们试过基于 Slack 的方案，但效果不太好，因为构建一个感觉良好的 Slack 聊天机器人
109
真的非常困难。嗯，我们还试过基于网页的方案。我们做过很多不同的网页原型，但都不太理想。比如
110
在浏览器中进行操作，总感觉不太顺手。而且如果在浏览器中，就无法访问你所有的工具。比如我桌面上有一个Word 文档，我无法在浏览器中告诉它一些事情。
111
文件系统访问感觉是必要的。仅仅需要将文件拖拽到浏览器中的那一小点摩擦，就足以让人感觉不好。而我我
112
认为这其实又回到了我们对产品设计的思考方式，就是我们先打造自己真正热爱的东西，然后你想要打造一个你自己会爱上、每天都会使用的产物，
113
也许有些用户也会喜欢它，希望它也能为其他人所用。嗯。
114
我有点惊讶，由于在聊天窗口中写了很多 Python 代码，我的 Claude 代码使用量下降了很多。我会问一些需要大量数据
115
分析的问题，我可以看到，哦，它正在写一些软件来做这个分析，然后它会生成一堆 HTML 和 CSS 以及 JavaScript，然后为我生成一个全新的
116
UI，让我在里面玩耍，这用了很多 Claude 代码生成，虽然我从未与 Claude 代码产品进行过任何交互，就完成了这一切。是的，是的。
117
有一种有趣的理论问题，就是你什么时候想执行计算？你是在从模型中采样时实时执行，进行推理？还是你想预先计算，这样模型可以写一个程序，然后你可以反复运行这个程序，对你来说是免费的。
118
基本上，我们尽可能想做后者。但其实这取决于模型。你知道，这又回到了模型作为软件存在，它需要一种与世界互动的方式。因为它作为软件存在，它实现这一点的方式
119
就是编程。这就是它所使用的自然语言，也是它所理解的东西。
120
所以，你知道，从 Claude Code 最早的版本开始，我给它提供了一个 bash 工具，让它可以在我的电脑上运行命令。我没有告诉它任何关于这个工具的信息，它
121
自己就弄明白了如何使用它。你知道，我讲过无数次这个轶事，我问它，我正在听什么音乐？
122
它打开了 bash 工具，写了一个小程序，生成了一个 Apple 脚本，而我从来没有写过 Apple 脚本。
123
它写了一个小的 Apple 脚本，然后打开了我的音乐播放器，说这就是你正在听的歌曲。
124
即使在那时，这还是 Sonnet 3.5 版本，那并不是一个非常智能的模型。那是当时最好的模型，但按照现在的标准来看，它并不智能。
125
嗯，它只是知道如何做到这一点。所以编写代码这件事，使用工具与世界互动这件事，模型似乎很想做
126
这个。嗯。我想暂时放下这些具体产品的问题，问一些关于文化和组织设计的问题。你是一名技术团队成员。我想很多人有这个头衔。嗯，这是怎么回事？有什么好处？
127
有什么坏处？你会推荐这个头衔给这个小组吗？
128
好的，当我加入时，最烦人的一点是，你在 Slack 上给某人发消息，然后它只显示“技术团队成员”。
129
他是不是像，这个人是设计师还是工程师？他们是经理吗？你不知道。而且他们做什么工作？他们做什么工作？是的，你不知道。嗯，我其实很喜欢这个。
130
嗯，当我在 Meta 的时候，我真的很喜欢的一点是，每个软件工程师的头衔都是软件工程师。没有像高级软件工程师或者首席软件工程师这样的头衔。真的吗？是的，这根本不是一回事。
131
嗯。我喜欢这个，因为实际上如果你给人们比较高级的头衔，有时他们会提出糟糕的主意，而人们出于尊重会直接接受这些主意。嗯，但实际上他们应该反对。实际上，这是一种非常好的文化推动方式，让所有人都处于同一竞争场地上。
132
但是，这会不会暴露出来呢？比如，我知道你只是一个软件工程师，而我也是一个软件工程师，但我知道你是一个某个级别的软件工程师，即使
133
虽然这不在你的头衔里。不过这不在你的头衔里。
134
我想有时候你知道这个，但很多时候你并不知道。嗯，比如，当我还在Facebook的时候，我刚加入的时候是L4工程师。而
135
我有一个想法，然后我找到了VP的连接人，去找他，我说，这是我想到的主意，我们一起来做吧。而他并不知道我的级别。哦，这很有趣。而且他这个想法其实很糟糕，最后也没成功。
136
但后来我又用了一个不同的VP，结果还是没成功，不过第三次的时候成功了。然后你知道，我们组建了一个团队，开始做一些东西，接着又转向了下一个想法。我现在经常能看到这样的事情。
137
你知道，我们团队里的人都有这些老的资历观念，但事实上在很多方面这已经不重要了。比如那些有20年、30年经验的工程师，他们必须
138
放弃很多旧的习惯。你得花几个月的时间教他们如何放弃这些已经不再相关的旧习惯。而有时候，一个应届毕业生加入团队，他们会教我一些如何更好地使用Quadcode的方法。嗯。
139
因为他们是原生地思考这个问题，而这不是我的本能。而且这尤其困难，因为每次新模型出现，你都必须重新校准和重新学习。
140
但回到技术成员这个角色，我认为这实际上是一个非常重要的事情，因为所有这些关于工程师与PM与设计师与用户研究员之间的旧有区分，到年底的时候就消失了。
141
因此，这帮助我们非常清晰地看到这一点，并以这种方式行动。我认为，这正是在AI实验室中需要做的事情，就是推动每个人更加敏捷地构建，并以这种方式更多地思考未来。
142
在这方面，我想稍微泛化一点，对于在座的所有创始人和公司，你们现在应该为组织在年底前做些什么进行思考？你认为创始人和公司在未来几个月内需要在思维方式上做出哪些改变？
143
我想我现在要做的事情就是，我会给每个人尽可能多的词元，我会这么说，因为我确实在一个 AI 实验室工作，但我会给每个人尽可能多的词元。
144
正如 Jensen 所说，买得越多，省得越多。
145
买得越多，省得越多。
146
所以我开始思考的地方是，给人们尽可能多的词元，让他们去实验，另外我还会稍微低估所有项目的资金。
147
所以如果你正在做一个项目，你觉得这需要四名工程师，那就只安排两名工程师，给他们大量词元，让他们想办法完成它。
148
很可能会成功。他们很可能可以自动化很多东西，也可以简化很多流程，因为他们正在自动化，所以下次可以做得更好。
149
但下次会更便宜。所以这就像一种复利效应，除了词元之外，资源越少，复利效应越明显。没错。这有点像
150
在商业和产品设计中，你要做很多决策，拥有一个原则集是非常有帮助的。
151
所以你不需要每次都做决定，你可以依靠这些原则，你不需要每次都做出临时性的决定，很多时候创始人和公司都会有这些类似的原则文件和
152
所以这有点像那样，但模型也可以使用这些原则，它以技能的形式出现。当然，如果有某个用例突然流行起来并使用大量词元，那就是你去优化它并尝试使其高效的时候。
153
但总的来说，如果我要把它简化一下，给你的建议是减少人类员工的数量，将预算从人类转移到词元，这样做的结果是提高前期成本但降低
154
持续成本。因为你已经做了大量的前期工作，这几乎就像预编译一样。你已经做了大量工作，这样重复的任务就变得简单和高效了。是的，是的。这
155
可能是思考这个问题的一种方式。而且因为你投入的人更少，这意味着你公司里的人可以做更多的事情。
156
这对我来说感觉像是组建团队最大的挑战之一，人们已经习惯了拥有一个头衔和一个专业领域，人们以自己是一个优秀的 PM 为荣。我要
157
写很多关于产品学科的博客文章之类的东西。你知道，外面有很多这样的人，或者设计师。我迫不及待想展示我的作品集，展示我漂亮的
158
设计。那我们是不是在12个月内都该摆脱我们是某种特定角色的观念，每个人其实都只是一个灵活的词元生成袋？
159
好吧，Ben，你太乐观了。嗯，我可能会用稍微不同的措辞，但确实是这样。就是这样。你应该把这句话印在T恤上。
160
我觉得，大概是这样。对我来说，我当了几年工程师，但一直担任不同的角色。比如，我之前创办过初创公司
161
我也在业务部门工作过，做过产品方面的工作，也做过用户研究和设计方面的工作。对我来说，我真的很喜欢做产品。我不在意
162
我是不是必须戴工程师的帽子。所以现在我看到这种趋势正在形成。是的，我觉得现在正是通才的黄金时代。想要做多件事情的人，现在比以往任何时候都更有趣，也更容易。
163
可能还有一个问题，我们之前和 Jared 简短地聊过。我很好奇你的看法。嗯，你怎么看待品味？无论是你自己还是 Anthropic？
164
我觉得每次我总觉得自己的编码方式有些特别的时候，其实我都是错的。我以前对写代码的方式有很多看法。
165
比如，我喜欢函数式编程。所以，我特别喜欢 Haskell 和 Scala 这些比较奇特的函数式语言。在最开始的时候，我
166
给我们的代码库设了一个规则：代码库中不能有任何类，只能有函数。因为这就是我写代码的方式。我喜欢这样。但到了周末，工程师们开始偷偷地在代码中加入类。
167
而且啊，我周一发现之后，就会去查看那个拉取请求，然后就会说，"不，不，不要这么做。"
168
后来到了某个时候，模型开始自己写所有代码，它就开始写类了。我当时想，"好吧，也许模型是对的。也许我的这个观点有点傻，"
169
这只是一个我特别坚持的东西，但其实并不重要，因为业务目标已经达到了。而且结果上，达到目标的速度更快了。代码实际上并不差。而且显然，代码随着时间推移一直在变好。
170
所以每当我感觉自己在某些方面特别的时候，往往都会被证明是错的。而且我认为，现在随着模型能力的提升，人们经常讨论的一个问题是产品的口味是alpha（早期版本）的。
171
我认为这一点也会消失。现在这只是一个alpha阶段的问题，但目前我已经有几百个quad在运行，它们在做各种事情，其中很多
172
正在查看 Twitter 的反馈，他们正在查看 GitHub 的问题，他们正在查看 Slack，并思考下一步要构建什么。目前大多数想法都不好，但可能有 20% 是好的。
173
如果你等待下一个模型，你知道的，如果展望未来三到六个月，大多数想法可能会变得不错。嗯，你知道，将会有一些新的东西。还会有我们特别擅长的其他事情，但我认为从长远来看，这种
174
会逐渐消失。你有什么猜测吗？有没有某种最终的事情，是人类特别擅长的？
175
我认为我们最终要教模型的是价值观。比如，我们教孩子如何成为好人，我们也会教模型如何成为一个好的模型。
176
非常有趣。嗯，这确实是个不错的结束点。
177
是的。Boris，非常感谢你。这真的很有趣。
178
谢谢。
end of transcript · 178 segments