Building Claude Code

"You wrote the first ever TypeScript book with O'Reilly."

"你写了 O'Reilly 出的第一本 TypeScript 书。"

"Yeah. I found that book translated in Japanese in this little town in Japan. That was just the coolest moment. And then I realized I don't remember TypeScript at all."

"对。我在日本一个小镇上看到那本书的日译本,那一刻真是太酷了。然后我意识到——我其实已经把 TypeScript 忘得一干二净了。"

"Now we're at the point where Claude Code writes, I think, something like 80% of the code at Anthropic on average. I wrote maybe 10, 20 pull requests every day. Opus 4.5 and Claude Code wrote 100% of every single one. I didn't edit a single line manually."

"现在我们已经到了这样一个节点:Anthropic 平均大概 80% 的代码是 Claude Code 写的。我可能每天写 10、20 个 pull request,而 Opus 4.5 加 Claude Code 写了其中的每一个的 100%,我没有手动改过一行。"

"Andrej Karpathy posted that he's never felt as much behind as a programmer as he is now."

"Andrej Karpathy(安德烈·卡帕西)发帖说,作为一个程序员,他从没像现在这样感到自己落后了这么多。"

"This is something I really struggle with. The model is improving so quickly that the ideas that worked with the old model might not work with the new model."

"这件事我自己也很挣扎。模型进步太快了,在旧模型上有效的想法,到了新模型上可能就不灵了。"

"One metaphor I have for this moment in time is the printing press in the 1400s, because there was a group of scribes that knew how to write. Some of the kings were illiterate who were employing the scribes."

"对当下这个时刻,我有一个比喻——1400 年代的印刷术。当时有一群会写字的抄写员(scribes),而雇他们的国王里,有些自己根本不识字。"

"And if you think about what happened to the scribes, they ceased to become scribes, but now there's a category of writers and authors. These people now exist. And the reason they exist is because the market for literature just expanded a ton."

"你再想想抄写员后来怎么样了——他们不再当抄写员了,但出现了"写作者"和"作家"这一整个新群体。这些人之所以存在,是因为文字的市场暴涨了一大截。"

"What happens when you join one of the top AI labs in the world and your first pull request gets rejected? Not because the code was bad, but because you wrote it by hand."

"当你加入世界顶级 AI 实验室之一,而你的第一个 pull request 被打回——不是因为代码烂,而是因为你是手写的,会发生什么?"

"This is exactly what happened to Boris Cherny when he joined Anthropic. Boris is the creator and engineering lead behind Claude Code."

"这正是 Boris Cherny 加入 Anthropic 时发生的事。Boris 是 Claude Code 的创造者和工程负责人。"

"Before joining Anthropic, he spent seven years at Meta where he led code quality across Instagram, Facebook, WhatsApp, and Messenger, and was one of the most prolific code authors and code reviewers at the company."

"加入 Anthropic 之前,他在 Meta 待了七年,负责 Instagram、Facebook、WhatsApp 和 Messenger 的代码质量,也是全公司产代码、做代码审查最多产的人之一。"

"In today's episode, we cover how Claude Code went from a side project to one of the fastest growing developer tools, and the internal debate at Anthropic whether to release it at all."

"在今天这一期里,我们会聊:Claude Code 怎么从一个副业项目长成增长最快的开发者工具之一,以及 Anthropic 内部那场"到底要不要把它发出去"的争论。"

"Boris's daily workflow of shipping 20, 30 pull requests a day with zero handwritten code, and how code review works when AI writes everything."

"还有 Boris 每天交 20、30 个 pull request、零手写代码的工作流,以及当 AI 写一切时,代码审查该怎么做。"

"Why Boris believes we're living through a time as transformative as a printing press, and which engineering skills matter more now and which ones do not."

"以及,为什么 Boris 相信我们正活在一个像印刷术一样剧变的时代,哪些工程技能现在更重要、哪些不再重要。"

"If you want to understand how one of the people closest to AI coding agents actually builds software today, and what that means for the rest of us engineers, this episode is for you."

"如果你想搞清楚:离 AI 编码 agent 最近的人之一今天到底是怎么写软件的,以及这对我们其他工程师意味着什么——这一期就是为你准备的。"

"How did you get into tech, software engineering, and coding in general?"

"你是怎么进入技术、软件工程,以及广义上的编程这一行的?"

"It starts a while back. I think there were kind of two parallel paths that crossed."

"得从挺久以前说起。我觉得是两条并行的线交汇到了一起。"

"So when I was maybe 13 or something like this, I started selling my old Pokémon cards on eBay. And I realized that on eBay you can actually write HTML."

"大概 13 岁的时候,我开始在 eBay 上卖我的旧宝可梦卡。我发现 eBay 上其实是可以写 HTML 的。"

"And I was looking at other people's Pokémon card listings, and I realized some of them have big colors and fonts and stuff like this. And then I discovered the blink tag."

"我看别人挂的宝可梦卡商品页,发现有些人能搞出大字号、各种颜色之类的花样。然后我就发现了 blink 标签。"

"What was the name? Was it the blink tag?"

"叫什么来着?是 blink 标签?"

"I put the blink tag on it, and I could sell my card for like 99 cents instead of 49 cents or whatever. So I kind of learned about HTML this way, then I got an HTML book and learned about HTML."

"我给商品加上 blink 标签,卡就能卖 99 美分,而不是 49 美分什么的。我就这么入了 HTML 的门,后来买了本 HTML 书,正经学了一下。"

"And then the second thing — this was also sometime in middle school. We had these old TI-83 graphing calculators, and we used them for math."

"第二条线也是在初中那会儿。我们有那种老式的 TI-83 图形计算器,数学课要用。"

"And what I realized is I can get a better answer on the math test if I just program the answers to the math test into my calculator. So I wrote these little programs."

"我发现,只要把数学考试的答案编进计算器里,我考试就能拿更高的分。于是我就写了一些小程序。"

"You just program the answers, and then the test got harder, so I had to program solvers instead of the actual questions, because I didn't know what the coefficients and stuff would be ahead of time."

"一开始就是把答案编进去;后来考试变难了,我就得改成编"解题器"而不是具体题目了——因为我事先不知道那些系数之类的是多少。"

"And then the math got more advanced the next year. So I had to drop down from basic to assembly just to make the program run a little bit faster."

"再到第二年数学更难了,我只好从 BASIC 降到汇编,就为了让程序跑快一点点。"

"Oh, so in high school you dropped down to assembly?"

"所以高中你就一路降到写汇编了?"

"I think this is like middle school or high school, maybe eighth or ninth grade. Then the thing I realized is everyone in my class was starting to realize that I had the solver, and they got kind of jealous."

"大概是初中或者高中,可能八年级或九年级吧。后来我发现,班上同学开始意识到我有这个解题器,有点眼红。"

"So I bought this little serial cable so I could give it to them too. And then the next math test, everyone in the class just got A's. And the teacher was like, 'What's going on?'"

"于是我买了根串口小线,把程序拷给他们。结果下一次数学考试,全班都拿了 A。老师就懵了:'这是怎么回事?'"

"And eventually she realized it. It was just like, 'Okay, you get away with it once, and knock it off.' But for me it was very practical."

"她最后还是看出来了。意思大概是:'行,这次饶了你,以后别再搞了。'但对我来说,这事儿特别实用。"

"So in school I studied economics. I actually dropped out to start startups. And I never thought that coding would be a career at all. It was always very practical to me."

"上大学我学的是经济学。后来其实辍学去做创业了。我从没想过编程会成为一份职业,它对我一直就是个实用工具。"

"Coding is a means to build things and to make useful things."

"编程是用来造东西、做出有用的东西的手段。"

"This startup, the first one — my friends and I were trying to get weed. So we started this weed review startup. We made a website, we called different dispensaries, and then we tried to get weed samples so we could review it for them. And it actually kind of blew up."

"第一个创业项目是——我和朋友们想搞点大麻。于是我们做了个大麻测评的创业:建了个网站,打电话联系各家药房,然后想办法拿到样品来帮他们做测评。结果还真火了。"

"And then I actually got more interested in — at the time no one was testing this stuff. So I got into the chemical testing, chemical analysis. And then after this I did a bunch of other startups, and then I joined YC pretty early. I was the first hire of this YC startup up in Palo Alto."

"再后来我更感兴趣的是——当时根本没人对这些东西做检测,于是我钻进了化学检测、化学分析。之后我又做了一堆别的创业项目,然后很早就加入了 YC。我是 Palo Alto 一家 YC 创业公司的第一号员工。"

"How did you decide to go from one startup to the other?"

"你是怎么决定从一个创业项目跳到下一个的?"

"Kind of vibes. Vibes, I'd say. Because startups, it's never a linear path. You always pivot, pivot, pivot."

"算是凭感觉吧。我会说是凭 vibes。因为创业从来不是一条直线,你总在不停地转向、转向、再转向。"

"You have to figure out what the market wants and what users want. And it's never the thing that you think. The idea is always a hypothesis, and then almost always you have to pivot once, twice, three times."

"你得搞清楚市场要什么、用户要什么,而那永远不是你以为的那个东西。点子永远只是一个假设,然后你几乎总得转向一次、两次、三次。"

"At this medical software company called Agile Diagnosis — this was an early YC company, back in maybe 2011, 2012 — it was medical software for doctors."

"有一家叫 Agile Diagnosis 的医疗软件公司,那是早期的 YC 公司,大概 2011、2012 年,做的是给医生用的医疗软件。"

"The idea was there are these clinical decision protocols. They vary a lot hospital to hospital. There was one hospital in Chicago that had a really great protocol specifically for cardiac symptoms."

"思路是这样:有一套套临床决策流程,各家医院差异很大。芝加哥有一家医院,专门针对心脏症状的那套流程做得特别好。"

"So we thought, wouldn't outcomes be great if every hospital in the US used the same protocol? So we tried to standardize it, and we made this decision tree software for doctors to use."

"我们就想:要是全美国的医院都用同一套流程,治疗结果不就好了吗?于是我们想把它标准化,做了一套决策树软件给医生用。"

"I wrote the software. It was in a web browser, back in the Internet Explorer 6 days — that's what hospitals were using. I wrote this SVG renderer because it was a visual decision tree. We launched it, and then we had a DAU chart, and the DAUs were flat. Couldn't figure it out."

"软件是我写的,跑在浏览器里,那还是 Internet Explorer 6 的年代——医院用的就是那个。因为是可视化的决策树,我还写了个 SVG 渲染器。上线之后我们看 DAU 曲线,日活一直是平的,怎么也想不通。"

"We were piloting it with a few hospitals including UCSF. And I rode a motorcycle at the time. So I rode my motorcycle up to UCSF and I shadowed doctors for a couple days just to see how they actually use this."

"我们在几家医院做试点,包括 UCSF。我当时骑摩托车,就骑着摩托去了 UCSF,跟着医生蹲了两天,就为了看他们到底怎么用这玩意儿。"

"And I realized that doctors don't have time to sit down and use a computer, because you're seeing a patient, then you have maybe 5 minutes until the next patient."

"然后我发现:医生根本没时间坐下来用电脑——看完一个病人,离下一个可能就 5 分钟。"

"In those 5 minutes you have to walk down the hall, go to the computer station, open up this totally legacy computer. By the time it boots up, that's like 3 minutes. Then you open up Internet Explorer 6, that takes 30 seconds. Then you open the app we built, you have to sign in — and your 5 minutes are up."

"这 5 分钟里,你得走过走廊、走到电脑工位、打开那台老掉牙的电脑——光开机就 3 分钟,再打开 IE6 又是 30 秒,再打开我们做的 app、还要登录——你那 5 分钟就没了。"

"So we rewrote everything to run on Android, and they still weren't using it. The thing we realized is doctors are walking around with a bunch of residents behind them. It's a social situation — the thing that matters is they're seen as an authority. They don't want to be seen on their phones."

"于是我们把所有东西重写成跑在 Android 上,结果他们还是不用。我们这才意识到:医生身后总跟着一群住院医师,这是个社交场合——重点是他们得被看作权威,他们不想被人看见在玩手机。"

"And then we pivoted again. So maybe the doctor isn't the target user — we wanted it to be used by nurses or x-ray technicians. At that point I left, because this was pretty far off from what I wanted to do."

"于是我们又转向了:也许医生根本不是目标用户,我们想让护士或者 X 光技师来用。到那个点上我就离开了,因为这跟我想做的事已经差得挺远了。"

"This is the most fun thing for me — finding this product-market fit, because it's always surprising. You can't have one big idea, because the idea is probably going to be wrong. So you form hypotheses, you follow down, and you see what's right."

"对我来说最好玩的就是这个——找到 product-market fit,因为它总是出人意料。你不能押在一个大点子上,因为那个点子大概率是错的。你只能不断提出假设、一路追下去,看看哪个是对的。"

"What struck me is you were hired as a software engineer, and this was back before 'product engineers' were a thing — which we're now talking about."

"让我印象深刻的是:你当时是作为软件工程师被招进去的,而那还是"产品工程师"这个概念出现之前——也就是我们现在常聊的那个东西。"

"But you rode your motorbike, went there, shadowed the people, and understood how they're using it and why they're not. I feel this is what makes a great software engineer back then and even today. You weren't focused on the technology — you were focused on the outcome."

"但你骑着摩托车跑过去,跟着人蹲点,搞懂他们怎么用、为什么不用。我觉得这正是当年、乃至今天,一个出色软件工程师的标志——你关注的不是技术本身,而是结果。"

"There are different kinds of engineers, and different ways to do it. Even on our team right now, I look at an engineer like Jared Sumner — he has an incredible technical mind. He understands systems better than anyone I've met. You need people with this kind of depth."

"工程师有不同的类型,做法也各不相同。就拿我们现在团队里的 Jared Sumner 来说,他的技术头脑惊人,对系统的理解比我见过的任何人都深。你需要这种有深度的人。"

"For me, engineering has always been a practical thing. I've always been a generalist. It doesn't matter if I'm doing design, or engineering, or user research, or whatever."

"对我来说,工程一直是件很务实的事。我一直是个通才(generalist),做设计、做工程、做用户研究还是别的什么,对我没区别。"

"My first job ever, I was like 16, and I just wanted to buy an electric guitar. So I started freelancing — I figured, okay, I guess I'll make websites. Fiverr wasn't a thing back then, so there were some other freelancing websites. I put up a profile, started bidding, and my first paycheck I spent the entire thing on an electric guitar."

"我人生第一份工作,大概 16 岁,就是想买把电吉他。于是我开始接活——心想,行吧,那我就做网站。那会儿还没有 Fiverr,有些别的接单网站。我挂了个资料、开始竞标,第一笔工资全砸进了一把电吉他。"

"But it was very practical. When you're in this kind of setup, you have to do the engineering, the accounting, the design, you have to talk to customers. So it's just always been like that for me."

"但这很务实。在那种状态下,你工程要做、账要算、设计要弄、还得跟客户聊。所以对我来说,一直就是这样。"

"After a couple of these startups, you ended up at Facebook, now called Meta. You spent 7 years there and had a very remarkable career growth — four promotions over 7 years. What did you work on, and what do you take away from that experience?"

"做了几个创业项目之后,你去了 Facebook,也就是现在的 Meta。你在那儿待了 7 年,职业成长很亮眼——7 年里四次晋升。你都做了什么,从那段经历里又带走了什么?"

"I started on Facebook Groups. Vlad Kolesnikov hired me. There was a big group of these early JavaScript people that I kept crossing paths with. Vlad worked on Bolt JS, the framework that powered Ads Manager, which later became React JS."

"我从 Facebook Groups 起步,是 Vlad Kolesnikov 招的我。那儿有一大群早期的 JavaScript 人,我后来一直跟他们打交道。Vlad 当年做的是 Bolt JS——驱动 Ads Manager 的那个框架,后来演变成了 React JS。"

"I was excited about Groups because of this mission of connecting people to their community. At the time I was a big Reddit user. I became a Reddit user as a teenager because I didn't know anyone else that coded. Even in college I didn't really know anyone that coded."

"我对 Groups 很兴奋,是因为"把人和他的社区连起来"这个使命。当时我是 Reddit 重度用户。我十几岁就上 Reddit,是因为身边没人会编程,连大学里我都几乎不认识会写代码的人。"

"Honestly, I was always kind of embarrassed about it, because I thought it was this nerdy thing. At some point I discovered a programming community on Reddit, and I was just shocked — there are other people that are into this thing. It was so exciting to find like-minded people and get this connection. So I wanted to contribute to that."

"老实说,我一直有点不好意思,觉得这是件很书呆子的事。后来我在 Reddit 上发现了一个编程社区,整个人都惊了——原来还有别人也喜欢这个。能找到这么一群同道、建立这种连接,实在太兴奋了。所以我想为它做点贡献。"

"Eventually I became the tech lead for Facebook Groups. The work changed from building to a lot of doc writing, coordination, and delegating. The culture was changing — the early Facebook culture was disappearing. The docs were coming in, the alignment meetings were coming in."

"后来我成了 Facebook Groups 的 tech lead。工作的内容从"造东西"变成了大量写文档、做协调、往下分派。文化也在变——早期那种 Facebook 文化在消失,文档来了,对齐会议也来了。"

"There was a lot more work around foundational stuff like privacy and security that, honestly, early on a lot of corners were cut in order to grow. But at some point you just have to pay that debt. That was the time when that happened."

"围绕隐私、安全这些基础性的东西,要做的事多了很多——说实话,早期为了增长,这些地方偷了不少工。但到某个时候,这笔债总得还。那段时间正赶上还债。"

"Then I spent a few years at Instagram. That was a funny story. My wife got a job offer she was really excited about, and she said, 'I got this offer, but we're going to move, is that okay?' I said, 'Yeah, I work in tech, we can work remotely anywhere. Where's the job?' And she said, 'It's in Nara.' And I was like, 'Where's that?'"

"之后我在 Instagram 待了几年。这事儿也挺逗。我太太拿到一个她特别心动的 offer,跑来跟我说:'我拿到这个 offer,但我们得搬家,行不行?'我说:'行啊,我在科技行业,远程随便哪儿都能干。工作在哪儿?'她说:'在奈良(Nara)。'我心想:'那是哪儿?'"

"Nara is rural Japan. This was around 2021 — like a 12-hour time difference. I tried to find a team that would sponsor me, because there were arcane HR rules about the time zone you have to be in. There was a nascent Instagram team in Tokyo, and Will Bailey was running it — he also made Instagram Stories. So I worked remotely from Nara, and most of the team was in Tokyo."

"奈良是日本的乡下。那大概是 2021 年——差了大概 12 个小时的时差。我得找一个愿意担保我的团队,因为 HR 有些很玄乎的规定,限制你必须待在哪个时区。东京当时有个刚起步的 Instagram 团队,负责人是 Will Bailey——他也是 Instagram Stories 的作者。于是我从奈良远程办公,团队大部分人在东京。"

"During this time I was hacking on Instagram, and the stack was just insane. Facebook was the single best web-serving stack in the world — from the Hack language to the HHVM runtime to GraphQL as the transport layer to client libraries like Relay and React. There's no other dev stack in the world that was this good."

"这期间我在 Instagram 上捣鼓,那套技术栈简直离谱。Facebook 是全世界最好的 web 服务栈——从 Hack 语言、HHVM 运行时,到作为传输层的 GraphQL,再到 Relay、React 这些客户端库。世界上没有第二套开发栈有这么好。"

"And then I went to Instagram, and it's like Python where the type checker didn't work, click-to-definition didn't work. It was this hacked-together Django and a fork of the CPython runtime, and just nothing really worked."

"结果我一到 Instagram,就是 Python——类型检查器不工作、点击跳转到定义也不工作。是一坨拼凑出来的 Django,加上一个魔改版的 CPython 运行时,基本啥都不灵。"

"I joined the Labs team in Japan to find the next big thing for Instagram. We tried some stuff, but I very quickly realized I was just not effective on the stack because it was so terrible. So I went and started working on Dev Infra, because we needed to fix it."

"我加入了日本的 Labs 团队,想给 Instagram 找下一个大方向。我们试了些东西,但我很快发现,因为这套栈太烂,我根本干不出活。于是我转去做 Dev Infra,因为这玩意儿必须得修。"

"There were a few projects: migrating from Python to the big Facebook monolith, and migrating off Instagram GraphQL. These are things that take hundreds of engineers many years to do. It's a big code base, a big migration. With AI tools now, migrations are a pretty good use case."

"有几个项目:从 Python 迁到 Facebook 的大单体,以及从 Instagram 的 GraphQL 迁出去。这种事要几百号工程师干好多年,代码库巨大,迁移工程量巨大。现在有了 AI 工具,迁移正好是个很好的应用场景。"

"That's also where I intersected with Fiona Fung, who is now the manager for the Claude Code team. She was such an amazing leader, with incredible depth and history in tech. I thought there's no better manager for this team."

"也是在那儿,我和 Fiona Fung 有了交集——她现在是 Claude Code 团队的经理。她是个特别出色的领导者,在技术上有惊人的深度和阅历。我觉得这个团队再没有比她更合适的经理了。"

"By the time I left Instagram, I was leading code quality for all of Meta — responsible for the quality of the code bases across Instagram, Facebook, Messenger, WhatsApp, Reality Labs, all of these."

"等我离开 Instagram 时,我已经在负责整个 Meta 的代码质量了——对 Instagram、Facebook、Messenger、WhatsApp、Reality Labs 这些代码库的质量负责。"

"At Meta there was this program called Better Engineering. It started around 2016 or 2018. Zuck mandated that every engineer at the company spend 20% of their time fixing tech debt."

"Meta 有个叫 Better Engineering 的项目,大概 2016 或 2018 年起步。Zuck 强制规定:公司每个工程师都要花 20% 的时间去还技术债。"

"Some of this is bottom-up — a team knows best the tech debt they have to fix. And some of it is top-down — you need to do very big migrations, migrate to new language features, new frameworks. At Facebook scale, there are tens of thousands of these migrations every year."

"其中一部分是自下而上的——一个团队最清楚自己得修哪些技术债;另一部分是自上而下的——你得做超大型迁移,迁到新的语言特性、新的框架。在 Facebook 那种规模下,每年有几万次这样的迁移。"

"I realized it just needed a bit more order. There were no goals, no one knew what the outcomes were, there wasn't any tracking. So we developed a centralized way to prioritize the different code quality efforts. The second thing was figuring out the impact of code quality on engineering productivity, which turned out to be significant."

"我发现这事得有更多章法。没有目标,没人知道产出是什么,也没有任何追踪。于是我们做了一套集中化的方式,给不同的代码质量工作排优先级。第二件事是搞清楚代码质量对工程生产力的影响——结果发现影响很大。"

"How did you measure that? What did you find?"

"你们怎么衡量的?发现了什么?"

"Some of this has been published. Essentially you do causal analysis and causal inference — you try to figure out what factors make engineers more productive. Some of it is code quality, some of it is outside of code quality."

"有一部分已经公开发表了。本质上就是做因果分析、因果推断——你想搞清楚,是哪些因素让工程师更高产。有些是代码质量,有些则在代码质量之外。"

"For example, Meta went back to return-to-office instead of work-from-home. That was partially driven by this, because we found some fairly strong correlations that we thought were causal. The code quality actually contributes double-digit percent to productivity, even at the biggest scale."

"比如,Meta 后来从居家办公改回了返回办公室。这一部分就是被这套分析推动的,因为我们发现了一些相当强、而且我们认为是因果性的相关关系。代码质量对生产力的贡献其实达到了两位数百分比——即便在最大的规模上也是如此。"

"This is comforting to hear, because it's rare to have a place that actually measures this, but I think we feel it. When you have a clean, modular code base, it gets easier to work with — and my hint would be it should be easier for LLMs to work with too, right?"

"听到这个挺让人安心的,因为很少有地方真的去量化它,但我们都能感觉到。代码库干净、模块化,干起活来就更轻松——我的直觉是,这对 LLM 来说应该也更友好,对吧?"

"Totally. If every time you build a feature you have to think about whether to use framework X, Y, or Z — because the code base is in a partially migrated state — as an engineer you're going to have a bad time. As a new hire you're going to have a bad time. As a model, you might just pick the wrong thing, and then the user has to course-correct you."

"完全是。如果你每次做功能都得纠结用框架 X、Y 还是 Z——因为代码库处在迁移到一半的状态,到处都散落着这几种写法——那作为工程师你会很难受,作为新人会很难受,作为模型,你可能干脆就挑错了,然后用户还得来纠正你。"

"So the better thing is to always have a clean code base. When you start a migration, finish the migration. This is great for engineers, and nowadays it's great for models too."

"所以更好的做法是:永远保持代码库干净。开了一个迁移,就把这个迁移做完。这对工程师好,如今对模型也一样好。"

"And then you joined Anthropic, and I've heard the story — which you can confirm or add color to — that your first pull request was rejected by Adam Wolf."

"再后来你加入了 Anthropic。我听过一个说法——你可以确认或者补充细节——你的第一个 pull request 被 Adam Wolf 打回了。"

"He was my ramp-up buddy. I was trying to figure out what to do next, and I met people at all the different labs. Anthropic was just the obvious choice for me because of the mission. This is the thing I personally know I need the most."

"他是我入职的 ramp-up buddy(带新搭档)。我当时在想下一步做什么,跑去见了各家实验室的人。对我来说 Anthropic 是个显而易见的选择,就因为它的使命——这是我个人最清楚自己需要的东西。"

"I'm a really big sci-fi reader — that's my genre. I have a giant bookshelf at home. And I just know how bad this thing can go. I felt this is a place that has serious thinkers, people taking this very seriously and thinking about what we can do to make this thing go better."

"我是个重度科幻读者——那是我的菜,家里有一整面巨大的书墙。我太清楚这件事(AI)一旦走坏会有多糟。我觉得这是个有严肃思考者的地方,这里的人非常认真地对待它,在琢磨怎么让这件事走得更好。"

"So when I joined, I did a bunch of ramp-up projects, and I wrote my first pull request by hand, because I thought that's how you write code. That used to be how you write code."

"所以入职后我做了一堆 ramp-up 项目,第一个 pull request 是我手写的——因为我以为代码就是这么写的。过去确实就是这么写代码的。"

"But even at the time at Anthropic, there was this thing called Clyde — it was the predecessor to Claude Code. It was super janky. It was Python, it took like 40 seconds to start up, it was research code, it was not agentic. But if you prompt it very carefully and hold the tool just right, it could write code for you."

"但当时 Anthropic 内部已经有个叫 Clyde 的东西——它是 Claude Code 的前身。特别糙,是 Python 写的,启动要 40 秒左右,是研究代码,还不是 agentic 的。但只要你非常小心地写 prompt、用对姿势,它就能帮你写代码。"

"So Adam rejected my PR, and he was like, 'Actually, you should use this Clyde thing for it instead.' And I was like, 'Okay, cool.' It took me like half a day to figure out how to use this tool, because you have to pass in a bunch of flags and use it correctly. But then it spat out a working PR. It just one-shotted it."

"于是 Adam 把我的 PR 打回了,他说:'其实你应该用那个叫 Clyde 的东西来做。'我说:'好啊,行。'我花了大概半天才搞明白怎么用这工具——因为你得传一堆 flag、用对方式。但它最后吐出了一个能跑的 PR,一把就做对了。"

"This was like September 2024, or August. And I think for me this was my first 'feel the AGI' moment at Anthropic, because I was just — oh my god. I didn't know the model could do this. I was used to these tab completions, line-level completions in an IDE. I had no idea it could just make a working pull request for me."

"那大概是 2024 年 9 月,或者 8 月。对我来说,那是我在 Anthropic 第一次"feel the AGI"的时刻,因为我当时就——我的天。我不知道模型能做到这个。我之前习惯的是 IDE 里那种 tab 补全、行级补全,完全没想到它能直接给我做出一个能跑的 pull request。"

"I started hacking on a bunch of different stuff. I worked on reinforcement learning for a bit, just to understand the layer under the layer I was building on. This is still advice I give a lot of engineers: always understand the layer under. It gives you depth, and a few more levers to work at the layer you actually work at."

"我开始捣鼓各种各样的东西。我还做了一阵子强化学习(RL),就为了理解我所搭建的那一层底下的那一层。这条建议我至今还常给工程师:永远去理解下面一层。它给你深度,也给你多几个可以在你真正工作的那一层上操作的杠杆。"

"This was the advice 10 years ago, and it's still the advice today. But the layer under is a bit different now. Before it was like: if you write JavaScript, understand the JavaScript VM and frameworks. Now it's: understand the model."

"十年前是这条建议,今天还是这条建议。只是"下面那一层"变了。以前是:你写 JavaScript,就去理解 JavaScript 的虚拟机和框架;现在是:去理解模型。"

"At some point I just wanted to understand the public Anthropic API, because I'd never used it. I didn't want to build a UI — I just wanted to hack something up quickly, because we didn't have Claude Code back then; we were still writing code by hand."

"后来我就想搞懂 Anthropic 的公开 API,因为我从没用过。我不想做 UI,只想快速糊个东西出来——因为那会儿还没有 Claude Code,我们还在手写代码。"

"So I wrote this little bash tool. All it did was hit the Anthropic API. It was essentially a chat-based application, but in the terminal, because that's what AI used to be. Engineers are the first adopters. When we started to move from conversational AI to agentic AI, engineers understood it pretty quick."

"于是我写了个 bash 小工具,它干的事就是去打 Anthropic 的 API。本质上是个聊天应用,只不过在终端里——因为那时候的 AI 就是这个样子。工程师是最早的尝鲜者。当我们从对话式 AI 往 agentic AI 迁移时,工程师很快就理解了。"

"Now when you ask non-engineers what AI is, they'd say it's this conversational AI — it's a chatbot. That's why I'm very excited for Cowork, this new product, because it's going to bring the same thing engineers saw very early to everyone else."

"现在你要是问非工程师"什么是 AI",他们会说就是那种对话式 AI——一个聊天机器人。所以我对 Cowork 这个新产品特别兴奋,因为它会把工程师很早就看到的那个东西,带给其他所有人。"

"Claude Code originally wasn't Claude Code — it was a chatbot, because that's what I thought AI was. The next thing I tried was tool use, because it had just come out and I didn't know what it was. I gave it a single tool, the bash tool, and I didn't know what to do with it."

"Claude Code 一开始并不是 Claude Code——它就是个聊天机器人,因为那是我当时以为的 AI。我接着试的是 tool use(工具调用),那玩意儿刚出来,我都不知道它是什么。我只给了它一个工具——bash 工具,然后我也不知道拿它能干嘛。"

"So I asked it — I actually didn't know if it could even do this — 'What music am I listening to?' And it just wrote a little AppleScript program using 'say' or whatever, to open up my music player and query it. It one-shotted this with Sonnet 3.5."

"于是我问它——其实我都不确定它能不能做到——'我现在在听什么音乐?'它就写了个 AppleScript 小程序,用 'say' 之类的命令打开我的音乐播放器,然后去查正在播什么。用 Sonnet 3.5,一把就搞定了。"

"This was my second 'feel the AGI' moment, very quickly after the first. The model just wants to use tools. That's what I realized — if you give it a tool, it will figure out how to use it to get the thing done."

"这是我第二次"feel the AGI",紧跟着第一次。模型就是想用工具。我意识到的是——你给它一个工具,它就会自己琢磨出怎么用这个工具把事办成。"

"At the time, everyone's mental model of AI and coding was: you take the model and put it in a box. You figure out the interface — what do you need it to do. It's like if you have a program, you stub out some module, some function, and say 'this is now AI,' but the rest of the program is just a program."

"那时候,所有人对"AI + 编码"的心智模型都是:把模型拿来,塞进一个盒子里。你去设计接口——你需要它做什么。就好比你有个程序,你掏空某个模块、某个函数,说"这块现在是 AI 了",但程序的其余部分还是普通程序。"

"This is just not the way to think about the model. The way to think about it is: the model is its own thing. You give it tools. You give it programs it can run. You let it run programs, you let it write programs. But you don't make it a component of this larger system."

"这根本不是看待模型的正确方式。正确的方式是:模型是它自己独立的一个东西。你给它工具,给它能跑的程序,让它去跑程序、去写程序。但你不要把它变成某个更大系统里的一个零件。"

"This is a version of the bitter lesson. There are many corollaries to it, and this is one of them: just let the model do its thing. Don't try to put it in a box. Don't try to force it to behave a particular way."

"这是 bitter lesson(苦涩的教训)的一个版本。它有很多推论,这就是其中之一:就让模型去做它自己的事。别想把它装进盒子,别想逼它按某种特定方式行事。"

"So the first ways you saw it work were giving it tools — access to bash, then the file system, then more tools, right?"

"所以你最早看到它起作用的方式,就是给它工具——先是 bash,然后是文件系统,再然后是更多工具,对吧?"

"That's right. We gave it bash, then file edit was the second one — though I say 'we,' it was just me the first 3 months, then the team grew. We delete these tools all the time and add new ones all the time. We're always experimenting with it."

"对。先给了它 bash,第二个是文件编辑(file edit)——不过我说"我们",其实前 3 个月就只有我一个人,后来团队才慢慢扩起来。我们一直在删工具、也一直在加新工具,始终在拿它做实验。"

"When you built it and it started to actually write code, you had an internal debate inside Anthropic: should we just keep it to ourselves? Because suddenly it spread across engineering and made all of you a lot more productive."

"当你把它做出来、它真的开始写代码时,Anthropic 内部有过一场争论:我们要不要干脆自己留着用?因为它一下子就传遍了整个工程团队,让你们所有人都高产了很多。"

"That's right. In the end, the decision was to release, so that we can study safety in the wild. The reason Anthropic exists as a lab is safety. This is the reason it was founded. If you ask anyone at Anthropic why they chose it, it's because of safety."

"对。最后的决定是发布,这样我们才能在真实世界里研究安全。Anthropic 作为一个实验室存在的理由就是安全——这是它创立的原因。你问 Anthropic 任何一个人当初为什么选这儿,答案都是安全。"

"There are different layers to think about model safety. There's alignment and mechanistic interpretability — that's at the model layer. Then there's evals, which is like putting the model in a petri dish and studying it synthetically. And then you can study it in the wild, see how it actually behaves, how users talk about it, what the risks are. You learn a lot this way."

"思考模型安全有不同的层次。有对齐(alignment)和机制可解释性(mechanistic interpretability)——那是在模型层。然后是 evals,就像把模型放进培养皿里、用合成的方式去研究它。再然后,你可以在真实世界里研究它,看它实际怎么表现、用户怎么谈论它、有哪些风险。这种方式能学到很多。"

"By doing this, we've been able to make the model much safer. So in hindsight, it was totally the right decision."

"靠这种方式,我们把模型做得安全多了。所以现在回头看,这绝对是个正确的决定。"

"It's amusing from your perspective, because from the outside what a lot of engineers saw was: 'Oh, Anthropic released Claude Code. Wow, this thing can write code pretty well.' Over time it became a lot more capable. It's become one of the fastest-growing developer tools."

"从你的视角听挺有意思的,因为从外面看,很多工程师看到的是:'噢,Anthropic 发了个 Claude Code。哇,这玩意儿代码写得挺好。'然后它一点点变得强大很多,成了增长最快的开发者工具之一。"

"And I'm always surprised to hear it actually comes from research and the goal of understanding how people use the model. Some startups have been trying to build developer tools deliberately to get adoption — and yet this research tool is getting a lot more adoption."

"而每次听说它其实出自研究、出自"理解人们怎么用模型"这个目标,我都很意外。有些创业公司是刻意去做开发者工具来抢占用户的——结果反倒是这个研究工具拿到了多得多的采用。"

"We're a research lab, a safety lab, and product is this thing tacked onto the side. Product exists so we can serve research better and make the model safer. That's how we think about everything."

"我们是个研究实验室、安全实验室,产品是挂在旁边的一个东西。产品存在的意义,是让我们能更好地服务研究、把模型做得更安全。我们看待一切都是这个角度。"

"There was this funny moment early on when we had a launch review, deciding whether to launch it. There was Mike Krieger, Dario, some other folks in the room. We were looking at the internal adoption chart, which was just vertical. It was insane."

"早期有个挺逗的时刻:我们开了个 launch review,决定要不要上线。屋里有 Mike Krieger、Dario,还有些别人。我们盯着内部采用率的曲线看——那曲线基本是竖直往上的,简直离谱。"

"Nowadays it's 100%. Every technical employee at Anthropic uses Claude Code every day. For non-technical employees, it's also getting quite close to 100% and increasing very quickly — like half the sales team uses Claude Code. It's crazy."

"现在是 100%。Anthropic 每个技术员工每天都用 Claude Code。非技术员工也在快速逼近 100%——比如销售团队有一半人在用 Claude Code,而且还在涨,太疯狂了。"

"Dario had this question: how did it grow this fast? Are you forcing people to use it? And I was like, 'No.' We offer this tool, people vote with their feet. We just let people use the tool they prefer."

"Dario 当时问:它怎么长这么快?是你在逼大家用吗?我说:'没有。'我们提供这个工具,大家用脚投票。我们就让人用他们自己更喜欢的工具。"

"This started for you — I think it was in November — when it started to write all of your code. When did that switch come? What made you trust it to write your code?"

"对你来说,这是从——我记得是 11 月——它开始写你全部代码的那个时候开始的。那个拐点是什么时候?是什么让你信任它来写你的代码?"

"The switch was instant when we started using Opus 4.5 — before it came out, we were dogfooding it. It's such a more capable model that I just found I didn't have to open my IDE anymore. I uninstalled my IDE. I actually did that like a month later, because I didn't even realize I wasn't using it anymore."

"拐点是用上 Opus 4.5 那一刻,瞬间就发生了——它发布前我们就在内部 dogfood。它强太多了,我发现我根本不用再打开 IDE。我把 IDE 卸了。其实是大概一个月后才卸的,因为我压根没意识到自己早就不用它了。"

"In December I was traveling — on a coding vacation. I went to Europe, nomading around in a different time zone. It was so fun, because I was just coding all day, every day, which is my favorite thing to do. I wrote maybe 10, 20 pull requests every day. Opus 4.5 and Claude Code wrote 100% of every single one. I didn't edit a single line manually."

"12 月我在外面旅行——一次"编码假期"。我去了欧洲,在另一个时区里到处游牧。太爽了,因为我可以整天、每天都在写代码,这是我最喜欢干的事。我大概每天写 10、20 个 pull request,Opus 4.5 加 Claude Code 写了其中每一个的 100%,我一行都没手动改过。"

"And I realized at the end of that month, Opus introduced me maybe two bugs. Whereas if I'd written that by hand, it would have been like 20 bugs."

"到那个月底我才意识到,Opus 大概只给我引入了两个 bug。而如果是我手写的话,大概会有 20 个 bug。"

"Can we talk about your development workflow? You've written some threads about this on X and threads. How do you use Claude Code today — parallelism, tips and tricks that you and the team have learned?"

"我们能聊聊你的开发工作流吗?你在 X 和 Threads 上发过一些帖子讲这个。你今天是怎么用 Claude Code 的——并行、还有你和团队摸索出来的窍门?"

"There's no one right way to use Claude Code. I can share some tips, but the wrong conclusion would be to just copy them. The way we built Claude Code, we built it to be hackable, because every engineer's workflow is different. There are no two engineers with the same workflow."

"用 Claude Code 没有唯一正确的方式。我可以分享一些窍门,但错误的结论是照搬它们。我们做 Claude Code,是把它做成可魔改(hackable)的——因为每个工程师的工作流都不一样,没有两个工程师的工作流是相同的。"

"It's like we're craftspeople — you choose your tools, you care deeply about it. For me, the way I do it: I have five terminal tabs. Each one has a checkout of the repository — so five parallel checkouts. I round-robin and start Claude Code in each one. Almost every time I start in plan mode, so that's shift-tab twice in the terminal."

"我们就像手艺人——你挑选自己的工具,你对它很上心。对我来说,做法是:我开五个终端标签页,每一个里都有一份仓库的 checkout——所以是五份并行的 checkout。我轮流(round-robin)在每个里启动 Claude Code。几乎每次我都从 plan mode 起步,也就是在终端里按两下 shift-tab。"

"And I overflow as I run out of tabs. I used to use web a lot for this — claude.ai/code. Nowadays I use the desktop app; it's more convenient. It has built-in worktree support, which is quite nice for parallelism. You don't need multiple checkouts — you have one, and we automatically set up Git worktrees for you, so you get environment isolation."

"标签页不够用时,我就往外溢。以前我常用 web 来接——claude.ai/code。现在我用桌面 app,更方便。它内置了 worktree 支持,做并行挺好用。你不需要多份 checkout——只要一份,我们自动帮你建好 Git worktree,你就得到了环境隔离。"

"The reason I do that is I just really hate fiddling with Git worktrees on the command line, because it's fiddly. You need to know to cd into the right place."

"我这么做的原因是,我真的很烦在命令行里折腾 Git worktree,太琐碎了——你得记得 cd 到对的目录。"

"For those not familiar with worktrees — it's when you check out a separate branch, almost like into a separate folder, and you can work on it separately and only have the conflicts at merge time, right?"

"给不熟 worktree 的人解释一下——它就是你把另一个分支 checkout 出来,差不多像到了一个单独的文件夹,你可以在里面单独干活,冲突只在合并(merge)时才出现,对吧?"

"That's right. Imagine you have a folder, and Git makes five copies of that folder in a way that's very cheap and easy to throw away. You get isolation, you can work in parallel, and the Claudes don't interfere."

"对。你可以想象你有一个文件夹,Git 用一种很廉价、又很容易扔掉的方式给它复制了五份。你得到了隔离,能并行干活,几个 Claude 之间也不会互相干扰。"

"The other surprise hit is the iOS app. Every day I wake up and start a few agents on my phone — the native Claude app, the code tab. It's the same exact Claude Code, except it runs in the cloud. You configure the environment with hooks — you use the session-start hook. This is one benefit of making Claude Code really hackable."

"另一个意外的爆款是 iOS app。我每天一醒来就在手机上启动几个 agent——原生 Claude app 里的 code 标签页。它就是一模一样的 Claude Code,只不过跑在云端。你用 hooks 来配置环境——用 session-start hook。这正是把 Claude Code 做得足够可魔改的一个好处。"

"This is something I'd never have predicted. If you told me 6 months ago I'd be writing maybe a third, half of my code on a phone, that's crazy. But that's what I'm doing today."

"这是我绝对预测不到的事。要是 6 个月前你跟我说,我会有大概三分之一、一半的代码是在手机上写的,那简直疯了。但这就是我今天在做的事。"

"At what point did you start using parallel agents? One thing I noticed about myself: I don't use that many — maybe two at a time. I like to be in charge, to follow Claude along. Did you feel you were losing control when you switched to parallel, or doesn't it matter that much?"

"你是从什么时候开始用并行 agent 的?我发现我自己用得不多——最多同时两个。我喜欢掌控,喜欢跟着 Claude 一步步走。你切到并行的时候,有没有觉得失去了控制?还是说其实没那么要紧?"

"There are kind of two modes. When you're new to a code base, learn mode is awesome — highly recommend it. For people onboarding to the Claude Code team or to Anthropic, you do slash-config, pick the output style, and choose 'learn' or 'explanatory.' We usually recommend explanatory for code bases you haven't been in before."

"大致有两种模式。当你刚接触一个代码库时,learn mode 很棒——强烈推荐。新人加入 Claude Code 团队或 Anthropic 时,我们的建议是:执行 slash-config,选 output style,然后选 'learn' 或 'explanatory'。对于你之前没进过的代码库,我们一般推荐 explanatory。"

"For me, once you're familiar with a code base, you just want to be productive and ship as much as you can. The role really switches. I don't go deep into tasks anymore. I start a Claude in plan mode, have it kick something off. With Opus 4.5 it got there; with 4.6 it really does it. Once there's a good plan, it one-shots the implementation almost every time."

"对我来说,一旦熟悉了一个代码库,你就只想高产、尽可能多出活。角色就彻底切换了。我不再深扎进每个任务里。我用 plan mode 起一个 Claude,让它开个头。用 Opus 4.5 已经能做到了;到 4.6 它是真的能做到。只要有一个好计划,它几乎每次都能一把把实现做对。"

"So the most important thing is to go back and forth a bit to get the plan right. I start one in plan mode, give it a prompt; as it's chugging along, I go to my second tab and start a second Claude, also in plan mode. Then the third, then the fourth. When I get notified the first is done, I go back."

"所以最重要的是来回几轮、把计划弄对。我用 plan mode 起一个、给它一个 prompt;趁它在忙活,我切到第二个标签页,起第二个 Claude,也是 plan mode;然后第三个、第四个。等收到第一个完成的通知,我再回去。"

"You're very productive with PRs. What does a pull request typically involve in terms of complexity? Are some trivial, some larger pieces of work?"

"你出 PR 非常高产。一个 pull request 在复杂度上通常包含什么?有些是很琐碎的,有些是更大的活儿吗?"

"Each one varies a lot — sometimes a few lines, sometimes a few hundred or a few thousand. It's changed so much. Back at Instagram, I was one of the top two or three most productive engineers just by volume of code. Coding is a way I express myself; it's how my brain thinks."

"每个差别很大——有时几行,有时几百行甚至几千行。变化太大了。当年在 Instagram,光按代码量算,我是最高产的两三个工程师之一。编程是我表达自己的方式,也是我大脑思考的方式。"

"The number of PRs undersells what's happening. People who were very productive before AI — a lot of their code was migrations, one-liners, migrating A to B. People who shipped 20, 30 PRs a day, a lot of it was pretty trivial."

"PR 的数量其实低估了真正发生的事。AI 之前那些很高产的人——他们很多代码是迁移、是单行改动、是把 A 迁到 B。那些一天交 20、30 个 PR 的人,里头很多都相当琐碎。"

"Nowadays I ship 20, 30 PRs every day, but every PR is completely different. Some are thousands of lines, some hundreds, some dozens, some one-liners. None of these are code migrations, because Claude just does those — I don't need to be part of that."

"现在我每天也交 20、30 个 PR,但每个 PR 都完全不一样。有的几千行,有的几百行,有的几十行,有的就一行。这里头没有一个是代码迁移——因为那些 Claude 直接就做了,我根本不用参与。"

"Shipping this much code to production, the obvious question is review. Teams used to require a mandatory human reviewer — at Google there are two, one on code quality. How has this workflow changed? How does the Claude Code team think about code review?"

"往生产环境推这么多代码,显而易见的问题就是审查。过去团队都要求强制有一个人来 review——在 Google 是两个,其中一个专门看代码质量。这个工作流变了多少?Claude Code 团队是怎么看代码审查的?"

"Let me start with how code review used to work for me. I also used to be one of the most prolific code reviewers — that's a benefit of being in a different time zone: I'm not superhuman, I just didn't have any meetings."

"先说说过去我是怎么做代码审查的。我以前也是做 review 最多产的人之一——这其实是处在不同时区的一个好处:我不是超人,我只是没有任何会要开。"

"Every time I'd have to comment about something, I'd drop it in a spreadsheet — describe the issue. Say someone named a parameter badly, or did some bad React pattern, I'd put it in a spreadsheet. Over time I'd tally it up, and anytime a particular row had more than three or four instances, I'd write a lint rule for it. Just automate it with static analysis."

"每次我要评论点什么,我就把它丢进一张表格,把问题写下来。比如有人参数命名很糟,或者用了某个糟糕的 React 模式,我就记进表格。时间一长我会统计一下,只要某一行出现超过三四次,我就给它写一条 lint 规则,用静态分析把它自动化掉。"

"For me, I've always tried to automate myself away, because there's just so much to do. This is one of our superpowers as engineers — we can automate all the tedious work. There are very few other fields where you can do this. And it gives me more free time to do the work I actually enjoy."

"我一直试图把自己自动化掉,因为要做的事实在太多了。这是我们工程师的超能力之一——我们能把所有繁琐的工作自动化掉。别的领域很少有这种本事。它也给了我更多空闲时间,去做我真正喜欢的事。"

"Today it looks a bit different but mirrors that. When Claude Code writes code, it generally runs tests locally — something Claude just decides to do when it's relevant — or it writes new tests. When we make changes to Claude Code, Claude tests itself: it launches itself in a subprocess, verifies itself end-to-end. This is something we didn't code in — with Opus 4.5 especially, it just started spontaneously doing this. It just wants to check, 'Hey, do I still work?'"

"今天的样子有点不一样,但和过去呼应。当 Claude Code 写代码时,它一般会在本地跑测试——这是 Claude 在相关时自己决定做的——或者写新测试。当我们改 Claude Code 本身时,Claude 会测自己:它把自己作为子进程启动,端到端地验证自己。这不是我们编进去的——尤其在 Opus 4.5 之后,它就自发地开始这么做了。它就是想确认一下:'嘿,我还能跑吗?'"

"And then we also run Claude-P — the Claude agent SDK in CI. So every pull request at Anthropic is code reviewed by Claude Code. That catches maybe 80% of bugs. It's the first round of review. Claude addresses some automatically; some it leaves to a human because it's not sure. There always has to be a person in the loop approving the change."

"我们还跑 Claude-P——就是 CI 里的 Claude agent SDK。所以 Anthropic 每个 pull request 都会被 Claude Code 审一遍。它能抓住大概 80% 的 bug,是第一轮审查。其中一些 Claude 会自动改掉;一些它不确定的就留给人。永远得有一个人在环路里批准这次改动。"

"Can you see places where you would just not have an engineer review code? What situations would that be?"

"反过来问:你能看到哪些地方是干脆不让工程师审代码的吗?会是什么情况?"

"It depends how it's used. If you're building a personal side project, you can just YOLO straight to main. Even before AI, you wouldn't have reviewed — you trust yourself, you ship to production. The very first internal versions of Claude Code, I committed straight to main."

"看怎么用。如果是个人副业项目,你大可以直接 YOLO 推到 main。就算在 AI 之前,你也不会去 review——你信自己,直接推生产。Claude Code 最早的内部版本,我就是直接提交到 main 的。"

"But as soon as you have users — and for Anthropic, our main customer base is enterprises — security and privacy are really important. Because it's an enterprise product, it has to meet a certain bar. We use a lot of automation, but at least for now there has to be a human in the loop just to make sure."

"但一旦你有了用户——而 Anthropic 的主要客户是企业——安全和隐私就非常重要。因为这是个企业级产品,它得达到某个门槛。我们用了大量自动化,但至少目前,还是必须有一个人在环路里把关。"

"LLMs are non-deterministic. By putting Claude as a reviewer, it gives good feedback, but you can't be sure it always catches an issue even when it's capable of catching it. Are you doing anything to marry this with deterministic things — like linting?"

"LLM 是非确定性的。把 Claude 当审查者,它能给出好反馈,但你没法确定它每次都能抓到问题——哪怕它本来有能力抓到。你有没有把这套和确定性的东西结合起来——比如 linting?"

"Absolutely. We have type checkers, linters, we run the build. Claude is so good at writing lint rules. I used to tally stuff in a spreadsheet; now, when a coworker puts up a PR and I think 'this is lintable,' I just tag @Claude on their PR: 'please write a lint rule for this.'"

"当然。我们有类型检查器、linter,还跑构建。Claude 特别擅长写 lint 规则。我以前在表格里记账,现在,当同事提了个 PR、我觉得"这个可以 lint",我就直接在他们的 PR 上 @Claude:'请给这个写条 lint 规则。'"

"You run something like slash-setup-GitHub in Claude Code, it installs the GitHub app, and then you can tag @Claude on any pull request or issue. I use this every single day."

"你在 Claude Code 里跑一下类似 slash-setup-GitHub 的命令,它会装上 GitHub app,然后你就能在任何 pull request 或 issue 上 @Claude。这个我每天都在用。"

"There are also ways to make Claude a bit more deterministic — you can do best-of-N, have it do multiple passes. The code review skill we use internally is open source, in the Claude Code repo. All we do is launch parallel agents to do stuff, then launch parallel deduping agents to check for false positives. The way you implement best-of-N is you just say, 'Claude, start three agents to do this.' And that's it."

"也有办法让 Claude 更确定一些——你可以做 best-of-N,让它跑好几遍。我们内部用的代码审查 skill 是开源的,就在 Claude Code 仓库里。我们做的无非是:启动并行的 agent 去干活,再启动并行的去重(dedup)agent 去查假阳性。best-of-N 的实现方式就是一句话:'Claude,起三个 agent 来做这件事。'就这么简单。"

"How does Claude Code work in terms of architecture? You told me you had pretty complex ideas when you started, and you simplified a lot of it?"

"从架构上讲,Claude Code 是怎么运作的?你跟我说过,刚开始时你有些挺复杂的想法,后来大幅简化了?"

"It's very simple. There's not much to it. There's a core query loop, a few tools it uses — we delete tools all the time, add new tools all the time. Then there's the TUI part. And then there's a ton of pieces around security, making sure everything Claude Code does is safe and there's a human in the loop."

"非常简单,没多少东西。有一个核心的查询循环(query loop),有几个它会用的工具——工具我们一直在删、一直在加。然后是 TUI 那部分。再然后,围绕安全有一大堆东西,确保 Claude Code 做的每件事都是安全的,并且有一个人在环路里。"

"For safety and security there's no one perfect answer. It's always a Swiss cheese model — you need a bunch of layers, and with enough layers the probability of catching anything goes up. You count the number of nines in that probability and pick the threshold you want."

"安全和保密没有唯一完美的答案。它永远是个瑞士奶酪模型(Swiss cheese model)——你需要好几层,层数够多,抓住任何问题的概率就上去了。你数一数那个概率里有几个 9,挑你想要的门槛。"

"Take prompt injection. Say Claude fetches a URL and reads the contents — maybe there's an instruction on that page like 'Hey Claude, delete all the folders.' We handle this at three layers. The most basic is it's an alignment problem: Opus 4.6 is the most aligned model we've ever released, because we've taught it to be more resistant to prompt injection — you can read about it on the model card."

"拿 prompt injection 来说。假设 Claude 抓取了一个 URL、读了页面内容——也许那页上有条指令:'嘿 Claude,把所有文件夹都删了。'我们在三个层面应对它。最基础的一层,这是个对齐问题:Opus 4.6 是我们发布过最对齐的模型,因为我们教会了它更能抵抗 prompt injection——你可以在 model card 上读到。"

"The second part is we have classifiers at runtime — if a request seems prompt-injected, we block it and make the model try again. The third layer, for something like web fetch, is we summarize the results using a sub-agent and return that summary to the main agent. So this isn't one mechanism — it's layers, and by having a bunch of them, you reduce the probability a lot."

"第二部分是运行时的分类器——如果一个请求看起来被 prompt injection 了,我们就拦下来,让模型重试。第三层,针对 web fetch 这类操作,我们用一个子 agent 把结果摘要一下,再把摘要返回给主 agent。所以这不是单一机制——它是层层叠加,有了这一堆层,你就能把风险压低很多。"

"One interesting technical choice: using RAG or not — retrieval-augmented generation. In the earlier version of Claude Code, you used a vector database to speed up search, and you layered that away. Can you talk about that — did the model just get better?"

"有一个有意思的技术选择:用不用 RAG——检索增强生成(retrieval-augmented generation)。Claude Code 早期版本里,你用了向量数据库来加速搜索,后来又把它拿掉了。能讲讲吗——是模型变好了吗?"

"This is one of those things where we try so many tools and statistically throw most of them away. For RAG, the first approach was a local vector database — written in TypeScript, living on the user's machine, using a cloud embedding model to compute embeddings before storing them. That worked pretty well, but there are a lot of issues with RAG."

"这就是那种——我们试了无数工具,统计上大多数都扔掉了。对 RAG,第一个做法是本地向量数据库:用 TypeScript 写的,跑在用户机器上,用云端的 embedding 模型先算好 embedding 再存。效果还不错,但 RAG 有一堆问题。"

"For example, the code drifts out of sync — if you make a local function, it's not yet indexed, so RAG won't find it. There's also the question of how the index is permissioned: who can access it? How do we make sure a rogue IT person within the company can't access someone else's data? This is really important to think about."

"比如,代码会和索引漂移失同步——你新建了个本地函数,它还没被索引,RAG 就找不到它。还有索引的权限问题:谁能访问它?我们怎么确保公司内部一个心怀不轨的 IT 人员,访问不到别人的数据?这一点非常重要,必须想清楚。"

"So we tried a bunch of other stuff. One was using the model to index everything recursively. Another was just glob and grep. It turned out that agentic search just outperformed everything."

"于是我们试了一堆别的。一个是用模型递归地把所有东西索引一遍;另一个就是 glob 和 grep。结果发现,agentic search 直接把所有方案都比了下去。"

"And what is agentic search?"

"那 agentic search 是什么?"

"It's just a fancy word for glob and grep. That's all it is. The model both got good enough and we realized it can use these tools pretty efficiently. It was partially inspired by my experience at Instagram, because at Instagram click-to-definition didn't work — the dev stack was broken half the time."

"它就是 glob 和 grep 的一个花哨说法,就这么回事。一方面模型变得够好了,另一方面我们发现它能相当高效地用这些工具。这部分灵感来自我在 Instagram 的经历——因为在 Instagram,点击跳转到定义根本不工作,开发栈一半时间是坏的。"

"So what engineers did instead: say you're looking for the definition of the function 'foo' — instead of click-to-definition, you'd use the global index, which is quite good at Meta, and search for 'foo(' with the opening parenthesis. That worked pretty well. And it's funny — this works for the model pretty well too."

"所以工程师们改用的办法是:比如你要找函数 'foo' 的定义——不用点击跳转,而是用 Meta 那个相当好的全局索引,搜 'foo(' 带上左括号。这招挺管用。好笑的是——这招对模型也一样管用。"

"One of the more advanced parts is the permission system. What was complex about it? And you recently open-sourced sandboxing, right?"

"更高级的一部分是权限系统。它复杂在哪儿?你最近还开源了沙箱(sandboxing),对吧?"

"Permissioning is really complex. Like everything to do with security, it's a Swiss cheese model. There are classifiers that run to make sure the command is safe, and static analysis too. As a user you can allow-list particular patterns you know to be safe — some standard Unix utilities we pre-allow because we know they're read-only."

"权限这块真的很复杂。和安全相关的一切一样,它是个瑞士奶酪模型。有分类器跑起来确认命令是安全的,也有静态分析。作为用户,你可以把你确知安全的特定模式加进白名单——一些标准 Unix 工具我们会预先放行,因为我们知道它们是只读的。"

"But actually quite few tools fall into that category. Even the 'find' command — there's a way to execute arbitrary code as part of it, because of system flags. Or the 'sed' command. There's all this arcania about Unix utilities where it's not as safe as you think. So by default we're fairly conservative about what we allow."

"但其实落进"安全"这一类的工具相当少。即便是 'find' 命令——也有办法借助它的系统 flag 执行任意代码;'sed' 命令也是。围绕这些 Unix 工具有一堆冷门门道,它们没你以为的那么安全。所以默认情况下,我们对放行什么相当保守。"

"You have this neat permission system where every time you run a command that needs permission, you can run it once, run it for the session, or globally allow it, right?"

"你有套很巧妙的权限系统:每次你跑一个需要授权的命令,你可以只跑这一次、给整个会话授权,或者全局放行,对吧?"

"That's right. This is a funny artifact — it was in the very first version of Claude Code, the first internal release, September 2024. At the time we weren't sure agentic safety could even be solved. There was a lot of pushback from safety teams: 'You can't just let the model run bash commands, that's unsafe. This is not a solvable problem, so we can't launch this.'"

"对。这是个挺有意思的遗留产物——它在 Claude Code 最早的版本里就有了,第一次内部发布,2024 年 9 月。那会儿我们都不确定 agentic 安全到底能不能解决。安全团队有很多反对声:'你不能就这么让模型跑 bash 命令,那不安全。这根本不是个能解决的问题,所以我们不能上线。'"

"I brainstormed with Ben Mann — he started the Labs team, he's one of the founders at Anthropic, and he's the person that hired me. We came up with permission prompts as the way to do this. If you're not sure, just ask the human, and they can decide."

"我和 Ben Mann 一起头脑风暴——他创立了 Labs 团队,是 Anthropic 的创始人之一,也是把我招进来的人。我们想出了用权限提示(permission prompt)来解决:拿不准的时候,就问人,让人来定。"

"One of the first questions is titles, or lack of them. Everyone at Anthropic has the same title — member of technical staff. Why did this happen, and what does it result in?"

"先问一个问题:头衔,或者说没有头衔。Anthropic 每个人的头衔都一样——member of technical staff(技术成员)。为什么会这样,它带来了什么?"

"It's an acknowledgement that everyone is figuring stuff out. If you squint at the work people are doing, it's all quite similar and quite generalist. The average software engineer might not just be coding — they might be doing design, talking to users, writing their own product requirements, doing research, writing product code and infrastructure code. At Anthropic there are a lot of generalists."

"它是一种承认:大家都在摸索。你眯起眼看大家在做的事,会发现它们其实很相似,而且很通才。一个普通的软件工程师可能不只是在写代码——他可能在做设计、在跟用户聊、在写自己的产品需求、在做研究,既写产品代码也写基础设施代码。Anthropic 有很多通才。"

"Without this title, the default would be: I see your name on Slack, under it says 'software engineer,' and I think, well, you're the coding person, so I'm not going to ask you product questions. But when everyone's title is member of technical staff, by default you assume everyone does everything. It inverts the relationship between people, even if you don't know each other. In a way it's optimism built into the structure."

"没有这个头衔的话,默认情况会是:我在 Slack 上看到你的名字,下面写着"软件工程师",我就会想,行,你是写代码的,那我就不去问你产品的事了。但当所有人的头衔都是 member of technical staff,你默认就假设每个人什么都做。它颠倒了人与人之间的关系,哪怕你们彼此还不认识。某种意义上,这是把乐观写进了组织结构里。"

"I think it's also a glimpse of the future — this is where software engineering is going, where every discipline is going: more of this generalist model."

"我觉得这也是对未来的一瞥——软件工程正在往这个方向走,每个学科都在往这个方向走:越来越像这种通才模式。"

"There's this funny comment by Marc Andreessen about a Mexican standoff in tech: designers say they're now doing PM and engineering, engineers say they're doing design and PM — everyone thinks they're doing the others' work. But the reality is everyone's role is expanding, thanks to AI, because it makes it easier for an engineer to do product work or a product person to do engineering."

"Marc Andreessen 有句挺逗的话,说科技圈出现了一场"墨西哥僵局":设计师说他们现在在做 PM 和工程,工程师说他们在做设计和 PM——每个人都觉得自己在干别人的活。但实际情况是,每个人的角色都在扩张,主要拜 AI 所赐,因为它让工程师更容易做产品、让产品的人更容易做工程。"

"Back in June or July of last year, I walked into the office. There's a row of data scientists that sit next to the Claude Code team. Our data scientist had Claude Code up on his monitor. I was like, 'This is interesting — you're a data scientist, why are you using a terminal? You don't even have Node.js installed.' He said, 'No, I'm using it to run queries.' He was using it to run SQL, and it had little ASCII visualizations in the terminal."

"去年六七月份,我走进办公室。Claude Code 团队旁边坐着一排数据科学家。我们的数据科学家在显示器上开着 Claude Code。我说:'有意思——你是数据科学家,怎么在用终端?你连 Node.js 都没装。'他说:'不,我在用它跑查询。'他用它跑 SQL,终端里还出了些 ASCII 小图表。"

"And then the next week, the entire row of data scientists had Claude Code running. Today on the Claude Code team, everyone codes — the engineers, the engineering manager, the designers, the data scientists, our finance guy. Everyone codes. Claude Code makes it so easy you don't have to understand the code base; you can just dive in and make small changes. It's a way to dip your toe in the water."

"再下一周,整排数据科学家都开着 Claude Code 了。今天在 Claude Code 团队里,人人都写代码——工程师、工程经理、设计师、数据科学家、我们的财务都写。Claude Code 让这件事变得太容易,你不需要懂代码库,直接扎进去改点小东西就行。这是个把脚伸进水里试试的方式。"

"You said that PRDs are just not really written inside Anthropic. PRD — product requirement document — is a well-known artifact across big tech: you write a spec, people align, you send it over. But apparently you're not doing much of this, or at all."

"你说过,Anthropic 内部其实基本不写 PRD。PRD——产品需求文档——是大厂里很有名的一种东西:你写一份 spec,大家对齐,然后发出去。但显然你们做得不多,甚至根本不做。"

"Some of it is because Anthropic is still a startup — you don't have to align with that many people, you can just talk about it or do it in Slack. And part of it is the way our product team thinks: better just send a PR. You're doing a lot of prototyping instead."

"一部分原因是 Anthropic 还是家创业公司——你不用跟那么多人对齐,直接聊一下、或者在 Slack 里搞定就行。另一部分是我们产品团队的思路:不如直接发个 PR。你转而做了大量原型。"

"On our team the culture is we don't really write stuff. We just show. It's hard to reflect on the time before, because now prototyping everything is so baked into how we build. Everything is prototyped multiple times."

"在我们团队,文化就是:我们基本不写东西,我们直接演示。现在很难回想以前是怎样的,因为"什么都先做原型"已经深深嵌进了我们做东西的方式里。每样东西都被做过好几版原型。"

"You had a thread showing you did like 15 or 20 prototypes for the to-do list, all interactive and working — and you did this in a day and a half. That's incomprehensible to me. It would have taken a week or two, and people would have done three, not 20."

"你发过一个帖子,展示你给那个待办列表(to-do list)做了大概 15 到 20 个原型,全是可交互、能跑的——而且你是在一天半里做完的。这对我来说不可思议。换我得花一两周,而且大家只会做三个,不会做 20 个。"

"We're in a world where we don't know the right answer. In the old way of building, the cost of building was high, so you had to aim very carefully before taking your shot — after you took it, it was hard to course-correct, and you could only take so few shots. Now it's changed: the cost of building is very low, but we also don't know where we're aiming. So we have to try and see what feels good. It's very exploratory."

"我们正处在一个不知道正确答案是什么的世界里。在旧的做法里,造东西的成本很高,所以你出手之前得瞄得非常仔细——出手之后很难纠偏,而且你只有寥寥几次机会。现在变了:造东西的成本很低,但我们也不知道往哪儿瞄。所以只能去试、去看手感。这非常具有探索性。"

"A big part of it is humility. Personally I'm wrong like half the time. Most of my ideas are bad — at least half of them — and I don't know which half until I try it. I have to try it myself and then see what others think, because my intuition does not always match others."

"很大一部分在于谦逊。我个人差不多有一半时间是错的。我大多数点子都很烂——至少一半是——而且我不试就不知道是哪一半。我得自己先试,再看别人怎么想,因为我的直觉并不总跟别人一致。"

"We launched a condensed view for file reads and file search, because the model is so agentic now — half my screen was these file reads and I don't really care what they are. I liked it after probably 30 prototypes. We rolled it out internally for a month, I fixed a dozen bugs, then launched it externally. A few users wanted more expanded output, so on the GitHub issue I went back and forth, shipped another version, iterated again. That's just the process — we get it right some of the time, and we learn from users."

"我们给文件读取和文件搜索做了一个折叠视图,因为模型现在太 agentic 了——我半个屏幕都是这些文件读取,而我其实并不在乎它们是什么。大概做了 30 个原型之后我才满意。我们先在内部铺开一个月,我修了十来个 bug,然后才对外发布。有几个用户想要更展开的输出,于是我在 GitHub issue 上来回沟通,又发了一版、又迭代了一次。这就是流程——我们有时做对,然后从用户那里学。"

"On the Claude Code team we leave ticketing up to every person. I don't use a ticketing system; some people use Asana or notes. One of the coolest things — about 3 months ago we launched plugins. Daisy had a very early version of Swarms, and over a weekend she let the swarm run and told it: 'Your job is to build plugins. Come up with a spec, make an Asana board, split into tasks, and have the different agents build it.'"

"在 Claude Code 团队,工单这事我们交给每个人自己决定。我不用工单系统;有些人用 Asana 或笔记。最酷的一件事——大概 3 个月前我们发布了 plugins。Daisy 当时有个非常早期版本的 Swarms,一个周末她就让这个 swarm 跑起来,告诉它:'你的任务是做 plugins。你得想出一份 spec,建一个 Asana 看板,拆成任务,然后让不同的 agent 把它造出来。'"

"She set up a container with a Claude in dangerous mode and let it run the entire weekend. It spawned a couple hundred agents, made 100 tasks on the Asana board, and implemented it. That's pretty much the version of plugins we shipped. These coordination systems used to be for humans, but nowadays it's just as much for models."

"她搭了个容器,放进一个 dangerous 模式的 Claude,让它跑了整整一个周末。它派生出几百个 agent,在 Asana 看板上建了 100 个任务,然后把它实现了出来。我们最后发布的 plugins 基本就是那一版。这些协调系统过去是给人用的,但如今它们同样是给模型用的。"

"Let's talk about Claude Cowork. It looks great — there's a Cowork tab inside Claude, and it's a much more visual way of running agents. One surprising thing I heard is that it was built in 10 days. Can you take us through what it took to build, and how big the team was?"

"我们聊聊 Claude Cowork。它看起来很棒——Claude 里有个 Cowork 标签页,运行 agent 的方式可视化多了。我听到一个让人意外的说法:它是 10 天建成的。能讲讲建它花了什么,团队多大吗?"

"The team was really small — just a few people. For a long time we felt there's some product to be built for non-engineers, because for a long time people using Claude Code were non-engineers. In the product world, when you see latent demand — people jumping through hoops to use a product not designed for them — that's a good sign it's time to build a product just for them."

"团队真的很小——就几个人。很长一段时间里我们都觉得,应该为非工程师做个产品,因为很长时间里用 Claude Code 的就是非工程师。在产品世界里,当你看到潜在需求(latent demand)——人们费尽周折去用一个并非为他们设计的产品——那就是个好信号:该为他们专门做个产品了。"

"There's this one guy on Twitter using Claude Code to monitor his tomato plants — he had a webcam set up, and Claude would be like, 'Oh my god, I'm so happy our plant is budding,' every day monitoring it. Someone used Claude Code to recover photos off a corrupted hard drive — his wedding photos. Our entire finance team uses Claude Code, our sales team uses it. So many non-engineers were using it."

"Twitter 上有个人用 Claude Code 监控他的番茄苗——他架了个摄像头,Claude 每天会说:'天哪,我们的苗发芽了,我太开心了。'还有人用 Claude Code 从一块损坏的硬盘里恢复照片——他的婚礼照。我们整个财务团队都用 Claude Code,销售团队也用。这么多非工程师都在用它。"

"Claude Code is available in a lot of form factors — terminal, IDE extensions for every VS Code and JetBrains IDE, iOS and Android apps, the desktop app, web, Slack and GitHub apps. But none of these are built for non-engineers. So for the last couple months the team was hacking around to find the right product. At some point someone came up with: what if we take Claude Code, add some guardrails — Cowork works with a virtual machine, which is one of the ways we keep it really safe. They hacked on it for about 10 days, fully built with Claude Code, and then we shipped it."

"Claude Code 有很多形态——终端、给每个 VS Code 和 JetBrains IDE 的扩展、iOS 和 Android app、桌面 app、web、Slack 和 GitHub app。但这些都不是为非工程师做的。所以过去几个月团队一直在捣鼓,想找到对的产品。后来有人提出:要不我们拿 Claude Code、加些护栏——Cowork 跑在一台虚拟机上,这是我们让它足够安全的方式之一。他们捣鼓了大概 10 天,完全用 Claude Code 建出来,然后就发布了。"

"Can you give a sense of the complexity? From the outside it's hard to tell — is this just a nice UI wrapper, or behind the scenes is it actually really complex? Uber is a great example: it looks simple, but there's a lot of complexity hidden — regional things, back-end things."

"能讲讲它的复杂度吗?从外面很难判断——这只是个漂亮的 UI 壳,还是背后其实非常复杂?Uber 是个好例子:看着简单,但藏了大量复杂性——各种区域规则、各种后端。"

"In some places there's less complexity than you'd think, in some places more. On the product side it's quite simple, because it's just the Claude desktop app — one app with a tab for Cowork, a tab for code, a tab for chat. We inherit a lot of that product logic. Under the hood, it's the same Claude Code running, the same Claude agent SDK that powers Claude Code."

"有些地方比你想的简单,有些地方更复杂。产品这一侧相当简单,因为它就是 Claude 桌面 app——一个 app,有 Cowork 标签、code 标签、chat 标签。我们继承了大量产品逻辑。底层跑的是同一个 Claude Code,就是驱动 Claude Code 的那同一套 Claude agent SDK。"

"A lot of the complexity is about safety, because the user is non-technical and we want them to have a good experience. If someone launches the app and deletes a bunch of family photos, that's really not good — we want to protect against that. So there are classifiers running on the back end, extra mitigations for prompt injection. On the front end there's an entire virtual machine we ship, with OS-level integrations to make sure people don't accidentally delete things."

"很多复杂性在安全上,因为用户是非技术的,我们希望他们有好的体验。如果有人打开 app、删了一堆家庭照片,那就很糟糕——我们想防住这种事。所以后端跑着分类器,对 prompt injection 有额外的缓解措施。前端我们打包了一整台虚拟机,带操作系统层面的集成,确保人们不会不小心删东西。"

"We also had to rethink the permission system. For Cowork, a big part of the value isn't just running locally — it's using all your tools the way Claude Code does. But for non-technical users, your tools aren't available as CLIs. Some are over MCP, many are in a browser. So Cowork is really good when you pair it with a Chrome extension, and that's how I usually use it."

"我们还得重新思考权限系统。对 Cowork 来说,很大一部分价值不只是在本地运行——而是像 Claude Code 那样用上你所有的工具。但对非技术用户来说,你的工具并不以 CLI 的形式存在,有些在 MCP 上,很多在浏览器里。所以 Cowork 配上一个 Chrome 扩展时特别好用,我自己一般就是这么用的。"

"For example, I use it every week to do project management for the team. We have a spreadsheet tracking what everyone's working on. I ask Cowork: 'Look at the rows where status hasn't been filled out, and ping the engineer on Slack.' It opens a Chrome tab for the spreadsheet, another for Slack, and starts messaging engineers. It one-shots it — there's one engineer's name it can't auto-complete, but everything else it just gets."

"比如,我每周用它给团队做项目管理。我们有张表格记录每个人在做什么。我让 Cowork:'看看那些状态没填的行,然后在 Slack 上戳一下对应的工程师。'它会开一个 Chrome 标签页打开表格,再开一个打开 Slack,然后开始给工程师发消息。它一把就搞定了——只有一个工程师的名字它自动补全不出来,其他全都搞定。"

"The tech stack is just Electron and TypeScript. Some of the people working on it are early Electron folks — Felix, the creator of Cowork, was a really early Electron engineer and helped build it. We launched macOS only, with Windows coming soon. We just wanted to start early and start learning. We always launch a little before it's ready — we did this for Claude Code too; it didn't even support Windows initially."

"技术栈就是 Electron 加 TypeScript。做它的人里有些是早期的 Electron 圈内人——Cowork 的创造者 Felix 就是非常早期的 Electron 工程师,还参与了它的开发。我们只发了 macOS 版,Windows 很快会有。我们就是想早点开始、早点学。我们总是在它还没完全就绪时就发布——Claude Code 当年也这样,一开始连 Windows 都不支持。"

"What learnings have you had with Cowork so far? It's been out a few weeks. Did you see something unexpected?"

"到目前为止,Cowork 给你带来了哪些收获?它发出来几周了。有没有看到什么意料之外的?"

"Every day the team is landing so many fixes. The most surprising thing is just how much people are loving it. When Claude Code first came out, it actually wasn't an overnight hit — it was a slow take-off. The first big inflection was in May, when we released Opus 4 and Sonnet 4; that's when it really clicked and growth became exponential. For Cowork, it's a much steeper growth trajectory than Claude Code was at the beginning. It's been an instant hit, which was very surprising — I didn't expect that."

"团队每天都在落地大量修复。最意外的是,大家有多喜欢它。Claude Code 刚出来时,其实并不是一夜爆红——是个缓慢的起飞。第一个大拐点在五月,我们发布 Opus 4 和 Sonnet 4 的时候;那时它才真正"对上了",增长变成指数级。而 Cowork 的增长曲线比当年 Claude Code 起步时陡峭得多,是个瞬间爆款,这非常出人意料——我没料到。"

"One of your new releases, just yesterday or the day before, was agent teams. The idea is: instead of a single agent, you have a lead agent that delegates to teammates. How did you decide to ship it now?"

"你们一个新发布——就在昨天或前天——是 agent teams(agent 团队)。思路是:不再是单个 agent,而是有一个 lead agent 把任务分派给队友。你们怎么决定现在就发的?"

"There are all sorts of ways to get more mileage out of Claude Code. You can extend context, you can auto-compact context so it's essentially infinite — that's what we have now. You can use sub-agents, multiple agents working together. There's this idea called uncorrelated context windows."

"有各种各样的方式能从 Claude Code 里榨出更多里程。你可以扩展上下文,可以自动压缩(auto-compact)上下文,让它基本上是无限的——这是我们现在的做法。你可以用子 agent,让多个 agent 协同工作。这里有个概念叫"不相关的上下文窗口"(uncorrelated context windows)。"

"A correlated context window is when the model does one task, then a second task in the same window — the second task knows about the first. But for a sub-agent, it's uncorrelated: the main agent prompts the sub-agent, but the sub-agent's window is fresh; besides that prompt, it doesn't know what's in the parent. You see this with sub-agents versus skills — a skill or slash command sees the parent context window; a sub-agent doesn't."

"相关的上下文窗口,是指模型做了一个任务,然后在同一个窗口里做第二个任务——第二个任务知道第一个的内容。但对子 agent 来说,它是不相关的:主 agent 给子 agent 发 prompt,但子 agent 的窗口是全新的;除了那条 prompt,它不知道父窗口里有什么。你在子 agent 和 skill 的对比里能看到这点——skill 或 slash 命令能看到父上下文窗口,子 agent 看不到。"

"There's this interesting thing where uncorrelated context windows — just throwing more context and more tokens at the problem, when the windows are uncorrelated — gives you better results. It's actually a form of test-time compute. For teams, we'd been experimenting since around September or October, and with Opus 4.6 it just clicked: the model figured out how to use this."

"有个有意思的现象:不相关的上下文窗口——就是往问题上扔更多上下文、更多 token,当这些窗口彼此不相关时——会给你更好的结果。这其实是一种 test-time compute(测试时计算)。对 teams 这个功能,我们从大概九月、十月就开始试,到 Opus 4.6 它就"对上了":模型搞明白了怎么用它。"

"Sometimes you see cute exchanges where the agents talk to each other and discuss something — it's very humanistic. Other times you just get very good results. We had internal evaluations where Claude builds something more complex than a single Claude would, and results really improved with Opus 4.6 plus teams. The reason you have to opt in — it's a research preview — is it uses a ton of tokens, because it's a bunch of Claudes running. You want it for fairly complex tasks, not every task. The main Claude decides the rules for the sub-Claudes; it's context-specific, there's no one-size-fits-all. A lot of the magic comes from uncorrelated context windows, not the specific configuration."

"有时你会看到很可爱的对话:agent 们彼此交流、讨论某件事——很有人情味。另一些时候你就是能拿到非常好的结果。我们做过内部评测,让 Claude 造一个比单个 Claude 能造的更复杂的东西,Opus 4.6 加 teams 的结果确实大幅提升。它需要你主动开启——它是个 research preview——是因为它耗大量 token,毕竟是一堆 Claude 在跑。你会想在相当复杂的任务上用它,而不是每个任务都用。主 Claude 来决定子 Claude 的规则;这是因情境而定的,没有一刀切的做法。很多魔力来自不相关的上下文窗口,而不是 agent 的具体配置。"

"With Andrej Karpathy you had an interesting exchange back in December, when he posted that he's never felt as much behind as a programmer as he is now. You shared a story about debugging a memory leak the old-fashioned way, and then Claude just one-shot it. How did you come to terms with this change, or start to embrace it?"

"去年十二月你和 Andrej Karpathy(安德烈·卡帕西)有过一次有意思的交流,他发帖说作为程序员,他从没像现在这样感到落后。你分享了一个故事:你用老办法去调一个内存泄漏(memory leak),结果 Claude 一把就解决了。你是怎么跟这种变化和解、或者开始拥抱它的?"

"This is something I really struggle with. The model is improving so quickly that ideas that worked with the old model might not work with the new one, and things that didn't work might now work. There aren't a lot of other technologies like this, so I don't have a lot of experience to draw on for how to approach it."

"这件事我真的很挣扎。模型进步太快了,旧模型上有效的想法在新模型上可能就不灵了,而原本不灵的东西现在又可能灵了。很少有别的技术是这样的,所以我没什么经验可以借鉴,不知道该怎么应对它。"

"It's a new skill I've had to learn. You always have to bring this beginner mindset, this intellectual humility — because all these ideas that were bad before are now good, and the inverse. That's honestly it. It's something I constantly have to remind myself."

"这是我不得不学的一项新技能。你总得带着一种初学者心态、一种智识上的谦逊——因为所有那些以前是坏的想法,现在变好了,反过来也一样。说实话就是这样。这是我得不断提醒自己的事。"

"In the old world, when someone tried an idea we'd tried before, the feedback was 'why are you doing this again?' Like microservices — someone says 'why don't we do microservices?' and someone says 'we tried it, it didn't work.' If you tried it a year or two or three ago, that was kind of valid, because not much had changed. Microservices is funny — it goes in and out of style every 10 years. But now it's the first time ever where it's not crazy to try the same idea every few months, because the model improves and it just works."

"在旧世界里,当有人去试一个我们之前试过的想法,反馈往往是'你怎么又来搞这个?'。比如微服务——有人说'我们为什么不做微服务?',就有人说'我们试过了,不行'。如果你是一两年、三年前试的,那这话还算成立,因为变化不大。微服务挺逗的——它每 10 年就流行一轮、又过气一轮。但现在是有史以来第一次,每隔几个月就重试同一个想法并不疯狂,因为模型变好了,它就真的能行了。"

"I see this with engineers on the team — people newer to the team, newer to engineering, sometimes do things in a better way than I do. I have to look at them, learn, and adjust my expectations. For example, when we release features, I'll screenshot myself using them on X or threads. But recently Tariq, our devrel guy, started automating this — he has Claude Code generate its own videos for launches. I wouldn't have tried that, because I wouldn't have thought the model was ready. He just did it, and it worked."

"我在团队的工程师身上也看到这点——刚加入团队、刚入行的人,有时做法比我更好。我得看着他们、向他们学,并调整自己的预期。比如我们发布功能时,我会在 X 或 Threads 上截图展示自己怎么用。但最近我们的 devrel(开发者关系)Tariq 开始把这事自动化——他让 Claude Code 自己为发布生成视频。这事我不会去试,因为我会觉得模型还没准备好。他就这么做了,而且成了。"

"Something I felt odd about — and I think a lot of developers can relate. Starting from Opus 4.5, the models got really good at writing code, and I realized I don't think I'll handwrite code when I want to get stuff done. But it's been so much effort to get good at coding."

"有件事让我觉得别扭——我想很多开发者都有同感。从 Opus 4.5 开始,模型写代码真的很好了,我意识到,当我想把事做成时,我大概不会再手写代码了。但是,把编程练到拿得出手,花了太多功夫。"

"A lot of my identity was tied to being good at coding — that's how we used to get jobs or higher-paying jobs. When I was a manager designing the interview loop at Uber, we said 'developers spend about 50% of their time coding,' so we placed about 50% of the signal on coding. There's a sense of loss — it's great the model can do it, but something really quickly got taken away that I didn't think would happen this fast. I think a lot of people feel that grief."

"我很大一部分身份认同是绑在"擅长编程"上的——过去我们就靠这个找工作、找更高薪的工作。我在 Uber 当经理、设计面试流程时,我们说'开发者大约 50% 的时间在写代码',于是我们把大约 50% 的信号权重放在编程上。这里有一种失落——模型能做到当然好,但有个东西被很快地拿走了,我没想到会这么快。我想很多人都感到这种哀伤。"

"It's something that used to be a thing we do as software engineers, and it's becoming a thing everyone can do. When I started coding, it was practical — a way to get things done. At some point I fell in love with the art of coding, the languages, the tools. I wrote a book about a programming language — TypeScript, the first-ever TypeScript book with O'Reilly."

"这曾经是我们软件工程师做的事,如今正在变成所有人都能做的事。我刚开始编程时,它很务实——是把事办成的手段。后来某个时刻,我爱上了编程这门艺术、爱上了语言和工具。我写过一本讲编程语言的书——TypeScript,O'Reilly 出的第一本 TypeScript 书。"

"There was this amazing moment — I went to a bookstore in my little town in Japan and found that book translated into Japanese. In this tiny town. That was the coolest moment. And then I realized I don't remember TypeScript at all, because I'd only been writing Python for a couple years at that point."

"有个特别美妙的时刻——我在日本那个小镇的书店里,看到了那本书的日译本。在那么一个小镇上。那是最酷的一刻。然后我意识到,我已经完全不记得 TypeScript 了,因为那时我已经只写了好几年 Python。"

"I started the biggest TypeScript meetup in the world, in SF, and got to meet a lot of my heroes — Chris Kowal, who wrote the General Theory of Reactivity, and Ryan Dahl, the guy who made Node. For TypeScript there's this beauty in the type system, because Anders Hejlsberg is just brilliant — conditional types, anything can be a literal type. There are deep ideas there that even the most hardcore functional languages, even Haskell, don't have. Scala was another rabbit hole I fell into."

"我在旧金山办了全世界最大的 TypeScript meetup,得以见到很多我的偶像——写了《General Theory of Reactivity》的 Chris Kowal,以及做出 Node 的 Ryan Dahl。对 TypeScript,类型系统里有一种美,因为 Anders Hejlsberg(安德斯·海尔斯伯格)实在太天才了——条件类型(conditional types)、任何东西都能是字面量类型(literal type)。那里头有些很深的想法,连最硬核的函数式语言、连 Haskell 都没有。Scala 是我掉进去的另一个兔子洞。"

"Still, when I write code and when the model writes code, I always think in the types first. What is the type signature — that matters more than the code itself. So there's a beauty to it, an art for sure. But in the end it's a practical thing. It's a means to an end, not an end in itself."

"即便如此,无论是我写代码、还是模型写代码,我总是先从类型(types)去想。类型签名(type signature)是什么——这比代码本身更重要。所以它确实有一种美、一门艺术。但归根结底,它是件务实的事。它是达成目的的手段,而不是目的本身。"

"One metaphor I have for this moment in time is the printing press in the 1400s. At that moment it was quite similar: there was a group of scribes who knew how to write. It was a hard process to learn — you needed equipment, sponsorship, years of training. In Europe a lord or king had to employ you. Often the king or queen themselves was not literate. Less than 1% of the population was literate back then."

"对当下这一刻,我的一个比喻是 1400 年代的印刷术。那个时刻其实很相似:有一群会写字的抄写员(scribes)。学这门手艺很难——你需要器具、需要赞助、需要多年训练。在欧洲,得有领主或国王雇你。而国王或王后本人往往并不识字。那时候识字的人口还不到 1%。"

"Then the printing press came out. The cost of printed material went down something like 100x over the next 30-50 years. The quantity of printed material went up like 10,000x in the next 50-100 years. Literacy took a while to catch up — global literacy went up to maybe 70%, but that took another 200-300 years, because learning to read and write is hard; it takes an education system, infrastructure, paper, ink, and free time instead of working on a farm."

"然后印刷术出现了。在随后的 30 到 50 年里,印刷品的成本下降了大约 100 倍。在随后的 50 到 100 年里,印刷品的数量上涨了大约 10000 倍。识字率花了一阵才跟上——全球识字率涨到大概 70%,但那又花了 200 到 300 年,因为学读、学写都很难;它需要教育体系、基础设施、纸和墨,还需要有空闲时间,而不是在农场上干活。"

"But this effect — taking something locked away in an ivory tower and making it accessible to everyone — none of the things around us would exist without it. If the people who built this microphone weren't literate, it would have been very hard to have a modern economy. Back then, if you'd asked people to predict what would happen when the printing press came out, no one would have predicted the microphone. That's the best analog for the moment we're in right now."

"但这种效应——把一件被锁在象牙塔里的东西变得人人可及——没有它,我们周围的一切都不会存在。如果造这只麦克风的人都不识字,现代经济就很难存在。回到那时候,如果你让人预测印刷术出现后会发生什么,没人会预测到麦克风。这就是当下我们所处时刻最贴切的类比。"

"And it's interesting you say some kings were illiterate while employing the scribes. If we're honest, we have business owners who know what they want to build, employing software engineers because they themselves cannot write code. We like to mock the CEOs who show up with a drawn prototype saying 'this should be easy.' But there's an analogy: just like the printing press, what happens if they could express themselves — if the king could read and write their own letters? They wouldn't need the middleman."

"你说有些国王自己不识字、却雇着抄写员,这点很有意思。说实话,我们现在也有这样一批企业主——他们知道自己想造什么,雇软件工程师,因为他们自己不会写代码。我们喜欢嘲笑那些拿着画好的原型、说"这应该很简单"的 CEO。但这里有个类比:就像印刷术一样,如果他们能自己表达呢——如果国王能自己读、自己写信呢?他们就不需要那个中间人了。"

"Exactly. And if you think about what happened to the scribes — they ceased to be scribes, but now there's a category of writers and authors. These people now exist, and the reason they exist is the market for literature just expanded a ton. Back then a scribe's work was read by a few people; with the printing press, an author can have wider reach than they could imagine. New careers exist because of that."

"正是。再想想抄写员后来怎么样了——他们不再是抄写员,但出现了"写作者"和"作家"这一整个新群体。这些人如今存在,而他们之所以存在,是因为文字的市场暴涨了一大截。那时候一个抄写员的作品只有寥寥几人读到;有了印刷术,一个作者能拥有他自己都想象不到的更广触达。新的职业因此而诞生。"

"The most exciting thing for me is it's just impossible to say today what will happen after this transition. The economy as we know it would not have existed without it. So what's next — the thing we can't even predict today that will exist, because anyone can do this?"

"对我来说最激动人心的是:今天根本没法说,这场转变之后会发生什么。我们所知的经济,没有它就不会存在。那么,下一个是什么——那个我们今天甚至无法预测、却终将存在的东西,只因为现在人人都能做这件事?"

"If you look around at the people at Anthropic — software engineers, builders, members of technical staff — who stands out to you? What are they doing? What skills have they built up?"

"环顾一下 Anthropic 周围的人——软件工程师、builder、member of technical staff——谁在你眼里特别突出?他们在做什么?他们积累了什么技能?"

"It's hard to name individuals — these are the strongest people I've ever worked with in my career. There are all sorts of archetypes. Some are amazing prototypers — taking something from 0 to 0.5, figuring out the cool ideas, the technology unlock. Others are amazing at finding product-market fit, 0.5 to 1. And others span different disciplines — product and infrastructure engineering, product and design, design and engineering. I'm seeing more and more of these hybrids."

"很难点名具体的人——这些是我职业生涯里共事过最强的一批人。各种原型(archetype)都有。有些是出色的原型师——把东西从 0 做到 0.5,想清楚那些酷点子、那个技术解锁点。有些特别擅长找 product-market fit,把 0.5 推到 1。还有些跨越不同学科——产品与基础设施工程、产品与设计、设计与工程。这种"混合型"的人,我看到得越来越多。"

"What's a belief that changed from last year to this year — a conviction you've revised or thrown away?"

"从去年到今年,有什么信念变了——某个你修正了、或者干脆抛弃了的笃信?"

"One thing I wasn't sure about is how big a problem safety is. I joined Anthropic because I read a lot of sci-fi and I know how bad this thing can go — but it wasn't something I was sure about. Seeing it from the inside, and the new risks that have arisen in the last year, makes me much more worried. Now it's just the most important thing for me: how do we make sure this thing goes well?"

"有一件我原本不确定的事:安全到底是个多大的问题。我加入 Anthropic 是因为我读了很多科幻,我知道这件事一旦走坏会有多糟——但我当初并不确定。从内部看到它,以及过去一年里冒出来的新风险,让我担忧得多。现在它对我就是最重要的事:我们怎么确保这件事走好?"

"What skills from before being a software engineer are still as valuable, or even more valuable than before — and which ones are best left behind?"

"在当软件工程师之前的那些技能里,哪些今天依然有价值、甚至比以前更有价值——又有哪些最好就此放下?"

"The stuff best left behind is maybe very strong opinions about code style and languages. I can't wait to get past these endless language and framework debates, because the model can just use whatever language and framework, and if you don't like it, it can rewrite it for you. It just doesn't matter anymore."

"最好放下的,大概是对代码风格和语言的强烈执念。我迫不及待想跨过这些没完没了的语言之争、框架之争,因为模型用哪种语言、哪种框架都行,你不喜欢,它还能给你重写一遍。这事儿真的不再重要了。"

"What still matters a lot is being methodical and hypothesis-driven. This matters in product design, in this world where everything is being disrupted and we need to figure out what to build next. And it matters in day-to-day engineering — something like debugging, you just have to be very methodical. The model can help a lot, but we're in a transition where you still need the skill. I don't know if you'll need it in 6 months."

"依然很重要的,是有条理、靠假设驱动。这在产品设计里重要——在这个一切都被颠覆、我们需要搞清楚下一个该造什么的世界里;它在日常工程里也重要——比如调试,你就得非常有条理。模型能帮上很多忙,但我们处在过渡期,你仍然需要这项技能。我不知道 6 个月后你还需不需要它。"

"Other skills more valuable now: being curious and open to doing things beyond your swim lane. If you work on engineering but really understand the business side, you can build awesome products. The next billion-dollar — maybe trillion-dollar — product might be one person with a cool idea whose brain spans engineering, product, business, design, finance. People will become more multi-disciplined, and this will be more rewarded. In some ways this will be the year of the generalist."

"现在更有价值的其他技能:好奇,以及愿意去做自己"泳道"之外的事。如果你做工程、却真正懂业务那一侧,你就能做出很棒的产品。下一个十亿美元——也许万亿美元——的产品,可能就是一个有酷点子的人,他的大脑能横跨工程、产品、业务、设计、财务。人会变得越来越多学科,而这会越来越被奖励。某种意义上,今年是通才之年(the year of the generalist)。"

"The other skill that's been rewarded is having a short attention span. In some ways it's dangerous for society — you want people who can think deeply and contemplate ideas, not just move to the next thing. But this year kind of rewards it — it's like the year of ADHD. The work for me has become jumping between Claudes, managing Claudes. It's not so much about deep work; it's about how good I am at context-switching, jumping across multiple contexts very quickly."

"另一个被奖励的技能,是注意力短。某种程度上这对社会是危险的——你希望人能深度思考、能沉思一个想法,而不是一味奔向下一个东西。但今年某种程度上奖励它——这就像 ADHD 之年。对我来说,工作已经变成了在多个 Claude 之间来回跳、管理这些 Claude。它不太关乎深度工作;它关乎我在上下文切换上有多厉害,能多快地在多个上下文之间跳来跳去。"

"I'd add one thing: adaptability. You were also very good at focusing deeply on one thing. What strikes me is you're just very open to adapting your working style. The one thing we can be sure of is whatever the next model is, it'll change again, and you need to be curious and open to adapting how you work."

"我想补一点:适应力。你过去也很擅长在一件事上深度专注。让我印象深刻的是,你非常愿意去调整自己的工作方式。我们唯一能确定的是:不管下一个模型是什么,它都会再次改变一切,你得保持好奇、愿意去调整你工作的方式。"

"As closing, what's a book or books you'd recommend?"

"最后,有什么书是你想推荐的?"

"I've gone down a Cixin Liu rabbit hole — he's the Three-Body Problem guy, but he has a lot of other really good books. I love his short stories; he has a couple collections, I'm a big fan."

"我最近掉进了刘慈欣(Cixin Liu)的兔子洞——就是写《三体》(Three-Body Problem)的那位,但他还有很多别的很好的书。我特别喜欢他的短篇小说,他有几本短篇集,我是铁粉。"

"For people new to sci-fi who want something a bit harder, I really love Accelerando by Stross. It's essentially the product roadmap for the next 50 years — with takeoff starting to happen, AI singularity, and it ends with these group lobster consciousnesses orbiting Jupiter. What it captures is the pace — this quickening, quickening, quickening pace of how this feels. It really matches the feeling right now."

"对刚接触科幻、又想看点更硬的人,我很爱 Charles Stross 的《Accelerando》。它本质上就是未来 50 年的产品路线图——起飞(takeoff)开始发生、AI 奇点,最后落到一群绕着木星运转的龙虾群意识体。它真正抓住的是那种节奏——那种越来越快、越来越快、越来越快的感觉。它和当下的感觉非常吻合。"

"On the technical side, I'd strongly recommend Functional Programming in Scala. Even if language choice doesn't matter as much anymore, there's an art to functional programming that teaches you how to code better, how to think in types. What's really important is to do the exercises — I've gone through and done all of them probably three times over. It knocks this idea of functional types into your head, and it's a thing you can't stop thinking about."

"技术这一侧,我强烈推荐《Functional Programming in Scala》(《Scala 函数式编程》)。即便语言选择不再那么重要,函数式编程里有一种艺术,能教你把代码写得更好、教你用类型(types)去思考。真正重要的是把习题做完——我大概把所有题都过了三遍。它把"函数式类型"这个概念狠狠砸进你脑子里,让你之后忍不住一直想它。"

"Boris, thanks so much. This was awesome."

"Boris,非常感谢,这一期太棒了。"

"Yeah, thanks Greg."

"好的,谢谢你,Greg(Gergely)。"

"This was a really interesting conversation, and the thing I keep coming back to is Boris's printing press analogy — that medieval scribes were a tiny elite who could write, employed by kings who were often illiterate, and that we software engineers might be in a similar position today. We are the scribes. We spent years mastering this craft, and now the printing press is arriving."

"这是一次非常有意思的对话,我反复回味的是 Boris 那个印刷术的类比——中世纪的抄写员是一小撮会写字的精英,受雇于往往并不识字的国王,而我们今天的软件工程师,可能正处在类似的位置上。我们就是抄写员。我们花了多年磨练这门手艺,而现在,印刷术正在到来。"

"But what Boris told me is that the scribes did not disappear. They became writers and authors, and the entire market for written work expanded beyond anything anyone could have predicted. I find this hopeful, and I appreciate that Boris didn't sugarcoat it."

"但 Boris 告诉我的是:抄写员并没有消失。他们变成了写作者和作家,而整个文字作品的市场,扩张到了任何人都无法预料的程度。我觉得这很有希望,也很感激 Boris 没有把它粉饰得太美。"

"The other thing that stuck with me is just how differently the Claude Code team builds software. No PRDs, no mandatory ticketing system, designers and data scientists and finance people all writing code, and dozens or hundreds of prototypes before shipping a feature. Boris is shipping 20 to 30 pull requests a day without editing a single line by hand — with verification systems in place: Claude Code reviewing its own code, automated lint rules, best-of-N passes, and human code review."

"另一件让我印象深刻的,是 Claude Code 团队造软件的方式有多不一样。没有 PRD,没有强制的工单系统,设计师、数据科学家、财务都在写代码,发布一个功能前要做几十甚至上百个原型。Boris 每天交 20 到 30 个 pull request、一行都不手改——同时有一整套验证机制:Claude Code 审查自己的代码、自动化 lint 规则、best-of-N 多轮,以及人来做代码审查。"

"If you've enjoyed this podcast, please subscribe on your favorite platform and on YouTube, and a special thank you if you leave a rating. Thanks, and see you on the next one."

"如果你喜欢这期播客,请在你常用的平台和 YouTube 上订阅,如果你还能留个评分,我格外感谢。谢谢,我们下期见。"