Running an AI-native engineering org

频道: Claude
视频: https://www.youtube.com/watch?v=IA5LWIGqnyM
原文语言: en
统计: 共 86 轮

[0:09]

[music] >> Hey everyone. Oh, thank you. I didn't expect applause. Well, thank you so much for joining me today. I'm excited to speak with all of you about, you know, some lessons I've learned as I've been leading Cloud Code and Co-work. So actually first I should do an intro. So yeah, my name is Fiona Fung and I lead engineering and product for Cloud Code and Co-work. And before Anthropic, I had

嘿，大家好。哦，谢谢。我没想到还有掌声。非常感谢各位今天来听我分享。我很期待跟大家聊聊我在带 Claude Code 和 Cowork 这两个团队的过程中学到的一些经验。不过我应该先做个自我介绍。我叫 Fiona Fung，负责 Claude Code 和 Cowork 的工程和产品。在加入 Anthropic 之前，

[0:40]

also built and led teams at Meta and Microsoft. So with that, let's dive into some lessons I'm excited to share with all of you. Hopefully, maybe you'll find a couple of tidbits that may be helpful to you.

我也在 Meta 和 Microsoft 组建并带过团队。那么，咱们就直接进入正题，分享几点我很想跟大家聊的经验。希望你们能从中找到一两个对自己有帮助的小点子。

[0:52]

So there are five topics I really want to cover today. The first is the bottlenecks have moved. And so when the bottlenecks have moved and it's shifted, what are all the team norms that we felt, "Oh yeah, we have to rewrite some of these because it's changed." How we rolled it out, I'll talk about like how we rolled out some of these updated team norms.

今天我主要想讲五个话题。第一个是：瓶颈已经转移了。当瓶颈转移、发生变化之后，有哪些团队规范是我们觉得「对，这些得重写了，因为情况变了」的。还有我们是怎么落地的，我会讲讲我们是怎么把这些更新后的团队规范推行下去的。

[1:12]

And in terms of the proof, what were some signals that I feel, "Okay, this is giving me confidence that we're trending in the direction right direction." And maybe it'll help you as well. And lastly, I'll leave you all with maybe a topic for you to all take back to your team to discuss because I'd love to hear about um yeah, whether any of this resonated.

至于成效验证，有哪些信号让我感觉「好，这让我有信心我们的走向是对的」。也许对你们也有帮助。最后，我会留给大家一个话题，你们可以带回团队去讨论，因为我很想听听看——这些内容有没有引起你们的共鸣。

[1:31]

So with that, let's touch on this first topic, which is the shift. So the bottlenecks have moved. And you notice there's that little subtitle there of what served you prior may no longer. It is one of my favorite sayings. Like actually, I think this is the muscle that has really helped me whether at Anthropic, but also before at the other companies. Always being of that growth mindset. Like you

那么我们就先聊第一个话题——这个转变。瓶颈已经转移了。你们注意到下面那行小标题：以前对你管用的，现在可能不再管用了。这是我最喜欢的一句话。其实我觉得，无论是在 Anthropic，还是之前在别的公司，真正帮到我的就是这块「肌肉」——始终保持成长型心态。

[1:53]

know, from all the talks this morning, you see our rate of change is just increasing. And so I found it's always helpful to look at what are either team norms that you've set up for your team or team processes and always ask yourself, is it still serving its purpose?

从今天上午所有的演讲你们也能看出来，我们的变化速度只会越来越快。所以我发现，回头看看你给团队定下的那些团队规范、或者团队流程，时不时问问自己：它还在发挥它原本的作用吗？——这一点特别有用。

[2:10]

So for years, many years, engineering bandwidth was expensive thing. And when you think about how do we all do software engineering, everything was around kind of like protecting this resource, right? Like we want to do a lot of planning cuz we want to make sure when we're building that we have high confidence that we're building the right thing. Or we want to do reviews, like

过去很多很多年里，工程带宽都是一种很昂贵的东西。当你想想我们大家是怎么做软件工程的，几乎所有事情都是围绕着保护这个资源在转，对吧？比如我们想做大量的规划，因为我们想在动手之前就高度确信自己做的是对的东西。或者我们想做评审——

[2:29]

there's a lot of action around when engineering bandwidth was a limiting factor. And maybe I'll pause there. Like when you think about our industry, this is not the first time that the bottleneck has shifted. Come I'll I'll take you all back in a time machine with me. We'll go all the way back to the early 2000s.

当工程带宽是制约因素的时候，围绕它有一大堆动作。我在这儿停一下。你想想我们这个行业，这并不是瓶颈第一次发生转移。来，跟我坐上时光机往回走，一直回到二十一世纪初。

[2:47]

And if you all remember, so back then I had just joined Microsoft. I was working on Visual Studio. There was no such thing as cloud. It sounds crazy now, right? Like now cloud is so ubiquitous. But back then there was no cloud and I remembered how we built Visual Studio was this one server room and everybody had to be on call for a week and then you'd just go into this room and I

你们要是还记得的话，那时候我刚加入 Microsoft，在做 Visual Studio。那会儿根本没有「云」这个概念。现在听起来很疯狂，对吧？现在云已经无处不在了。但那时候没有云，我还记得我们构建 Visual Studio 的方式——就一间服务器机房，每个人都得轮值一周 on-call，然后你就走进那间屋子。我

[3:08]

remember the whole build process, it was a queue, we can only merge six PR's at a time and anytime, you know, one of the tests would fail, you have to debug which of those PR's caused that failure. So back then, that was actually a big bottleneck. And then now with cloud and with continuous build, that bottleneck has also shifted. So this is just another shift for us to think about of

记得整个构建流程是个队列，我们一次最多只能合并六个 PR，而且任何时候只要有一个测试挂了，你就得去 debug 到底是哪个 PR 导致的失败。所以在那时候，那确实是个很大的瓶颈。后来有了云、有了持续构建，那个瓶颈也转移了。所以现在对我们来说，这只是又一次转变，值得我们思考：当编码不再是瓶颈时，会发生什么变化？

[3:29]

when coding is no longer the bottleneck, what changes? And so on the cloud code team, coding is really the slow part anymore. And so like that's why all the upstream and all the downstream kind of like processes, we felt like we've had to change a little bit.

在 Claude Code 团队，编码真的已经不是慢的那部分了。所以正因为如此，我们觉得上游和下游的那些流程，都得稍微做点改变。

[3:47]

So as an example, what were some of the old bottlenecks, right? Like writing code, writing tests, refactoring. In fact, I'll share a story with you all. When I first joined Cloud Code, I wanted to onboard and fix some bugs, and I thought, "You know what? I'm going to try test-driven development." I remember that was a really big thing a while back. You know, the idea is write the

举个例子，以前有哪些瓶颈呢？写代码、写测试、重构。其实我跟大家分享个故事。我刚加入 Claude Code 的时候，想边熟悉环境边修几个 bug，我当时想：「这样吧，我来试试测试驱动开发。」我记得这在前些年是个特别火的东西。它的理念就是先写

[4:09]

test first, make sure it fails, then do the change, then now you already have a test. But, it was kind of like eating broccoli, you know, like even though I actually really do love broccoli, but I use it as an example. Uh but, I remember you It feels like eating broccoli to write the test first cuz it's not always the most enjoyable part of the process.

测试，确认它会失败，然后再做改动，这样你就已经有测试了。但是，这有点像吃西兰花，你懂的——虽然我其实是真的很爱吃西兰花，但我拿它当个例子。我记得，先写测试感觉就像吃西兰花一样，因为它并不总是整个过程里最享受的那部分。

[4:27]

And I remember always itching to build a product and get to, you know, playing around with it. And so, now with Claude, I remember the first bug. I'm like, "You know what? I want to try test-driven development again. Let's write the test, but first it will fail. Let's verify it fails cuz that's how I can verify the test is actually testing something." And then we we, you know, like I remembered

我记得自己老是手痒，急着想去搭产品、去把玩它。所以现在有了 Claude，我记得修第一个 bug 的时候，我心想：「这样吧，我再来试试测试驱动开发。先写测试，但它会先失败，咱们先验证它确实失败——因为这样我才能确认这个测试真的在测某个东西。」然后我们就，你懂的，我记得

[4:45]

like making the bug fix, and then we already had a test. And I remember that first experience, test-driven development was actually so much more fun and so much more pleasurable. It kind of took the tax out of test-driven development. So, that was a big aha for me. Refactoring is another fun topic.

做完了 bug 修复，然后我们已经有现成的测试了。我记得那第一次体验，测试驱动开发竟然变得有意思多了、舒服多了。它把测试驱动开发里那种「税负」给抹掉了。所以那对我来说是个很大的顿悟。重构是另一个有意思的话题。

[5:01]

Like, I don't know if you all felt this before, but, you know, I've been on a teams before where we have to either do like some big refactoring or some software architecture cleanup. And it's always a debate of when would we find time to do this work, this work that we know is so important, but it always has to come off at the cost of trading, you know, time to build product. So, again,

我不知道你们以前有没有这种感觉，但你懂的，我以前待过的团队里，我们时不时得做一些大的重构，或者一些软件架构的清理。而且永远都在纠结：我们什么时候才能挤出时间来做这件事？我们明知道它非常重要，但它总是得以牺牲做产品的时间为代价。所以，又一次，

[5:21]

thanks for the models, and with Claude, refactoring is also no longer a bottleneck. So, now when those shifts happened, what am I starting to see that as the new bottlenecks? Uh verification. That's a big one. A lot of it's because the bandwidth has just increased so much. We have to pay even more attention to is it correct? And I'll talk about this in a little bit, but also when

感谢这些模型，有了 Claude，重构也不再是瓶颈了。那么，当这些转变发生之后，我开始看到哪些新瓶颈？验证。这是个大问题。很大程度上是因为带宽一下子涨了太多，我们必须更加关注：它对不对？这个我待会儿会细讲。但还有就是，当

[5:42]

roles are blurring and more people are, you know, checking in changes, we also want to make sure everybody feels confident that their changes are correct. Who reviews? That's a really popular topic. And also, how is it maintained?

角色边界开始模糊、越来越多的人在提交改动时，我们也想确保每个人都对自己的改动是正确的有信心。谁来评审？这是个非常热门的话题。还有就是，它要怎么维护？

[5:55]

And this one is interesting because again, the throughput is now so much more. Also, have to think about, you know, the cost of maintenance as well. So, these were some of the old processes that we felt quietly stopped working.

这一点很有意思，因为同样地，现在吞吐量大了太多。你还得去考虑维护的成本。所以这些就是我们觉得「悄无声息地不再奏效」的一些旧流程。

[6:10]

And I love that phrase quietly stops working cuz actually, if I step back, anytime, you know, hopefully when somebody puts a process in place, it's to solve a problem. But very often, we forget to audit to go, "Wait, are those processes still required?" Or is it still serving its purpose? So, for example, what were some of the things that we had to change? Planning norms.

我特别喜欢「悄无声息地不再奏效」这个说法。因为如果退一步看，每当——但愿是这样——有人定下一个流程，那都是为了解决某个问题。但我们经常忘了去复盘、去问：「等等，这些流程现在还有必要吗？」或者说它还在发挥它原本的作用吗？那么，举例来说，我们当时必须改掉哪些东西呢？规划规范。

[6:30]

When coding is no longer, you know, the the the bottleneck and and not a like and you have like much more coding bandwidth, how did we rethink through planning? Uh code ownership is also another interesting question. Almost all the cloud code commits now are also, you know, co-authored by Claude. I don't think I've in the last few months ever saw a commit that wasn't. A code review

当编码不再是瓶颈、你手里的编码带宽多了很多的时候，我们是怎么重新思考规划这件事的？代码归属权也是另一个有意思的问题。现在 Claude Code 几乎所有的提交，也都是由 Claude 共同署名（co-authored）的。过去这几个月里，我印象中就没见过哪个提交不是这样的。代码评审

[6:51]

is a good one. Like that's a lot of questions I get a lot as well. Also, team makeup. Roles are blurring. And what are the skill sets that we're thinking, "Hey, you know what? These are actually skill sets we're kind of like doubling down into." And also, knowledge sharing. What happens when maybe documentation is no longer your source of truth?

也是个好话题。这也是我经常被问到的一堆问题之一。还有团队构成。角色边界在模糊。哪些技能是我们在想「嘿，你知道吗，这些其实是我们要加倍押注的技能」的？还有知识分享。当文档也许不再是你的事实来源（source of truth）时，会发生什么？

[7:10]

So, given some of those shifts, these are some of the team norms that we had to rewrite. We talked about code review. Uh and actually, Cat this morning in the talk really talked about cloud code review as well. That was a really uh like that's how an amazing tool for us to make sure we're also doing the right thing.

鉴于这些转变，下面这些就是我们不得不重写的团队规范。我们聊到了代码评审。其实今天上午 Cat 在演讲里也重点讲了 Claude Code review。那是个非常棒的工具，能帮我们确保自己做的事是对的。

[7:29]

Onboarding has also changed. I'll share with you all my onboarding story. Planning, I've talked about this already of when coding is no longer bottleneck, how does that shift our planning? Hiring and also, org shape. Org shape is a fun one like, you know, we really want to keep everybody more agile and flatter orgs, but every manager on Claude code actually start as an IC first.

入职上手（onboarding）也变了。我会跟大家分享我自己上手的故事。规划，我前面已经讲过了——当编码不再是瓶颈时，这会怎么改变我们的规划方式。招聘，还有组织形态。组织形态是个有意思的点，你懂的，我们真的很想让所有人都更敏捷、组织更扁平，但 Claude Code 上的每个 manager 其实一开始都是先做 IC（一线工程师）的。

[7:52]

So, with that, how have our planning and technical debates changed? So, in technical debate code wins. You know, it's like building is cheap, arguing is expensive. I'll actually share with you all like I remembered, you know, as I was onboarding I also wanted to do some code refactoring. I was kind of like, "Hey, what's some refactoring that we think is good to do but we haven't yet done?" And

那么，我们的规划和技术争论又是怎么变的呢？在技术争论里，代码说了算。就像那句话——构建很便宜，争论很贵。我其实想跟大家分享，我记得我在上手的时候，也想做一些代码重构。我当时就在想：「嘿，有哪些重构是我们觉得值得做、但还一直没做的？」然后

[8:13]

I remembered me and Boris had a couple of debates of approach. And in the old days, I remember and I almost did this. I almost said, "Hey Boris, let's just go to this meeting room and go to a whiteboard and whiteboard it out."

我记得我和 Boris 在方案上有过几次争论。要是搁在以前，我记得，我差点就这么干了——我差点就说：「嘿 Boris，咱们去那间会议室，到白板前把它画出来吧。」

[8:23]

Almost did it and I'm like, "Wait, if if, you know, with thanks to Claude, I can actually generate." I remember generating three different versions of the PRs. And actually that's what me and Boris used to have a really good technical debate cuz I wanted to not look at how the code was implemented, but also impact to the colleagues. Uh prototyping is another good one. So, now

差点就这么做了，然后我心想：「等等，多亏有了 Claude，我其实可以直接生成出来。」我记得当时生成了三个不同版本的 PR。其实这正是我和 Boris 后来能进行一场非常棒的技术争论的原因，因为我想看的不只是代码是怎么实现的，还有对同事们的影响。原型设计（prototyping）也是个好例子。所以现在，

[8:43]

like anytime we're really having idea, go ahead and prototype and let's actually go ahead and dog food it and then we'll try. I remember many years ago also having this uh prototyping conversation in another team I was at.

任何时候我们一有想法，那就直接去做原型，然后真正地去试用它（dog food），再来评估。我记得很多年前，在我待过的另一个团队里，也有过这么一场关于原型设计的对话。

[8:57]

Um you know, cuz there was a debate. There were kind of two camps. One camp of prototyping is great. It allows you to move quickly, to build, you know, kind of like a wire skeleton and get a feel for the product. But on the other camp, I think there was a concern. Well, you know, code prototyping you're kind of doing it with speed, you're cutting corners, and there's concern of what

你懂的，因为当时有过一场争论，大致分成两派。一派认为原型设计很棒，它让你能快速行动、搭出一个大致的骨架、对产品有个直观的感觉。但另一派，我觉得是有顾虑的。他们觉得，你做代码原型是图快，是在偷工减料，而他们担心的是——

[9:15]

happens when you show a prototype that kind of works and then, you know, maybe you get hung up on it, you don't want to throw the code away, and then you end up trying to ship that thing. It's not built to scale.

当你拿出一个勉强能跑的原型之后会怎样：你可能会对它产生执念，舍不得把那些代码扔掉，结果你就硬着头皮想把那个东西发布出去。可它压根不是为规模化而构建的。

[9:25]

Again, with Claude, now actually prototyping is a great way to get started cuz we could iterate and learn. And then thanks to, you know, the models help, we can also then actually scale out a prototype to production a lot faster.

再说一遍,有了 Claude,现在做原型其实是个很好的起步方式,因为我们可以快速迭代、快速学习。然后多亏了模型的帮助,我们还能把一个原型更快地扩展到生产环境。

[9:39]

So, what's one thing we reduced on the Cloud Code team? It's you know, I might have been on teams before maybe y'all as well like design docs like really in-depth planning and design docs. Most of our discussions actually happen in PRs or prototypes. And again, that's just because the engineering bandwidth, you know, is is now increased and coding is no longer a bottleneck.

那我们 Claude Code 团队减掉了哪样东西?你知道,我以前待过的团队,可能你们也一样,会写设计文档,那种特别深入的规划和设计文档。而我们现在大部分讨论其实都发生在 PR 或者原型里。这同样是因为工程产能现在提上来了,写代码不再是瓶颈。

[10:00]

Uh what do we really want to double down on? Verification. And this is something that I want to make sure, you know, me and our team keeps keeps doing better as well because now with all the bandwidth is even more important to how do you verify quality? And I call this like, you know, like shift left. So, for example, what's better than you running It really sucks for me when I hear from

那我们真正想加倍投入的是什么?是验证(verification)。这也是我想确保我和我们团队持续做得更好的一点,因为现在产能这么充裕,怎么验证质量就变得更加重要。我把这叫做"左移"(shift left)。举个例子,有什么比你自己撞上 bug 更糟呢?对我来说真的很难受的是,当我听到

[10:20]

our customers and developers and you all run into code. I'm always like, "Ah, I wish we caught it first." But you know, what's actually better than me running into the bug first? Us having automation in place actually catch it closer to the source. So, that's like that's something that we're really constantly looking at as well of how to make sure we keep shifting left and automating more.

客户、开发者、还有你们大家撞上某段代码的问题时,我总会想:"唉,要是我们能先发现就好了。"但其实有什么比我先撞上这个 bug 更好呢?那就是我们提前部署好自动化,在更靠近源头的地方就把它抓住。所以这也是我们一直在琢磨的事:怎么不断往左移、把更多东西自动化。

[10:40]

Who made this change? This used to be a question that a lot of folks would ask of, "Hey, who who who was the last person that touched this or who's a code owner?" And now I encourage you all like if you find yourself asking that question to get to the root of the question. Like what are you trying to answer? Is it Are you looking for someone that caused a regression? Are you looking for someone

"这个改动是谁做的?"这曾经是很多人爱问的一个问题:"嘿,这块儿最后是谁动过的?谁是这部分代码的 owner?"现在我鼓励你们,如果你发现自己在问这个问题,就去深挖一下问题的根源。你到底想搞清楚什么?你是在找谁引入了某个回退(regression)?还是在找某个人

[11:00]

to answer a question? Are you looking to gain context? And is there a way that Cloud could actually help you with that? Uh Kat actually talked about routines as well like earlier today. That's one of the routines I have set up like automatically, you know, in the morning I like over my morning cup of coffee I like to review all the feedback in our various feedback channels. So, I have a

来回答一个问题?还是你想补充一些 context?有没有可能 Claude 其实就能帮上你这个忙?Kat 今天早些时候也讲到了 routines(例行任务)。这就是我设好的一个 routine——每天早上,我喜欢就着早晨那杯咖啡,把我们各个反馈渠道里的反馈都过一遍。所以我有一个

[11:20]

routine that will go through to kind of amalgamate all the feedback for me and help me to identify themes. How do you keep up with code reviews? Before we actually shipped Cloud Code code review, this was a question that I would get all the time and I can share that answer with you all. Like definitely Claude code code review is one one tool that has really helped us

routine,会帮我把所有反馈汇总到一起,帮我识别出共性的主题。"你是怎么跟上 code review 的节奏的?"在我们真正上线 Claude Code 的 code review 功能之前,这是我经常被问到的问题,现在我可以把答案分享给你们。Claude Code 的 code review 绝对是真正帮到我们的一个 tool,

[11:40]

to make sure we keep up with the coding bandwidth. And so where Claude is really good, right? Like the style and lint, obvious bugs, um anytime that you actually have like like if if you there is a spec, I encourage you to actually check the spec into your code base cuz Claude is very good about verifying against spec drift. But this still really important to still have a human

让我们能跟上写代码的产能。Claude 真正擅长的地方在哪儿?比如代码风格和 lint、那些明显的 bug,还有任何时候——如果你有一份 spec(规格说明),我鼓励你把 spec 也提交进代码库,因为 Claude 特别擅长检查代码有没有偏离 spec(spec drift)。但这里仍然非常重要的一点是,还是要有人

[12:01]

in the loop. So where do we find even in code reviews is really important for humans still? Legal reviews, anything that is actually about risk tolerance. So especially when you look at trust boundaries, it's all about that trust but verify and where humans bring a lot of the needed expertise.

在回路里(human in the loop)。那即便是在 code review 里,哪些地方依然非常需要人?法务审查、任何涉及风险容忍度的东西。尤其是当你看信任边界(trust boundaries)的时候,关键就在于"信任但要验证"(trust but verify),以及人在哪些地方能贡献那些不可或缺的专业判断。

[12:17]

Product sense and taste is another fun one. So last uh December, I wanted to update Claude in our CLI to, you know, give Claude a little holiday theme and I was ambitious. I wanted to turn Claude into a snowman. I you know, like I I coded up an example and I asked her designer, "Hey, can you go ahead and review this for me?" And she gave me such excellent feedback of no, this

产品直觉和品味是另一个有意思的例子。去年十二月,我想给我们 CLI 里的 Claude 更新一下,给 Claude 加点节日气氛,而我野心还挺大,我想把 Claude 变成一个雪人。我自己写了个示例,然后请我们一位设计师帮我看看:"嘿,你能帮我 review 一下吗?"她给了我特别棒的反馈:不,这

[12:39]

looks nothing like a snowman. You you you create you turned Claude into Mr. Peanut. I don't know if Mr. Peanut's an American brand and and in the US we have this jar of peanuts and you know, their their mascot is this little peanut character and I was like, "Holy crap, that's totally right. I I thought it was a snowman but you're right, it's a peanut." And so that's where like humans

一点都不像雪人。你这是把 Claude 变成了 Mr. Peanut(花生先生)。我不知道 Mr. Peanut 是不是只有美国才有的牌子——在美国我们有一种罐装花生,他们的吉祥物就是这么个小花生人。我当时心想:"我的天,你说得太对了。我还以为是个雪人,可你说得没错,这就是颗花生。"所以这就是人

[12:59]

also like with that product is really important to keep that expertise in the loop as well. Now what should my team makeup be cuz roles are blurring and Claude is augmenting. And so when it comes to engineering, these are the two profiles that I now really like focus on. One is creative builders with product sense um and then another is deep system expertise. And so

在产品这件事上同样重要的地方,要把这种专业判断保留在回路里。那现在我的团队该怎么配置呢?因为各个角色之间的边界正在模糊,而 Claude 在不断增强每个人。所以在工程方面,我现在真正看重的是这两类人。一类是有产品直觉的创造型构建者(creative builders),另一类是有深厚系统专长的人。所以

[13:25]

this is definitely like, you know, the hard part. Want to make sure that we can still have that trust but verify. Maybe I'll talk a little bit about product sense. When I gave this talk in San Francisco, afterwards a lot of engineers came up to ask me a question of how do I build this product sense muscle? So I figure I will share with you all of what I have found helpful and it's helpful

这确实是难点所在。我们要确保还能做到"信任但要验证"。我可以稍微讲讲产品直觉。我在旧金山做这个演讲的时候,结束后有很多工程师跑来问我一个问题:我该怎么练出这种产品直觉的"肌肉"?所以我想把我自己觉得有用的方法分享给大家,它对

[13:43]

for me and maybe it will resonate with you all. Like for me it's this muscle that you build with it first starts with dog fooding. And especially for managers actually like making sure you're spending time using the product that you're building and your team is building. In fact most of the time anytime I join a new team like that's one of the first things I do. I'm like

我很有帮助,也许也能引起你们的共鸣。对我来说,这块"肌肉"的练成,首先是从用自己的产品(dog fooding,吃自家狗粮)开始的。尤其对管理者来说,真的要确保自己花时间去用你正在做的、你团队正在做的产品。其实大多数时候,每当我加入一个新团队,这就是我最先做的几件事之一。我会

[14:01]

dog fooding the product to make sure I understand it. Cuz this way you really start feeling your product in your bones and you remember you always ask yourself wait when I was building this product what problem are we trying to solve?

亲自去用这个产品,确保自己真的理解它。因为这样你才会真正打心底里感受到你的产品,你会一直记得、一直问自己:等等,我当初做这个产品的时候,我们想解决的到底是什么问题?

[14:12]

Like what experience was I trying to enable for our users? So with that in mind like dog fooding is a really good way especially for managers who before Cloud you may not have time to be in the code base anymore. Um but yeah like actually anytime I join a team and I would dog food a lot of team members would always come up to me and say it's so awesome to see you using our product

我当时想为用户创造什么样的体验?带着这个意识,亲自用产品就是个特别好的办法,尤其对那些在有 Claude 之前可能已经没时间再碰代码库的管理者来说。不过说真的,每次我加入一个团队、开始亲自用产品时,很多团队成员都会跑来跟我说:看到你用我们的产品太棒了,

[14:31]

cuz you really care. Cuz that's a way for you to experience the work as well. So for me product sense comes from a lot of dog fooding and then also like iterating shipping and then going out to speak to customers. One of my personal passion projects is working with small businesses. I love small businesses. I feel small businesses are the lifeblood that forms our community. And uh we

因为这说明你是真的在乎。因为这也是你亲身体验大家工作成果的一种方式。所以对我来说,产品直觉来自大量地亲自用产品,加上不断迭代、发布,然后走出去跟客户聊。我个人特别热衷的一个项目就是和小企业打交道。我特别喜欢小企业。我觉得小企业是构成我们社区的命脉。而且我们

[14:51]

actually just announced Cloud for small business which is a product I'm so excited at um but I have a lot of friends that run restaurants. They and they work incredibly hard. And so I met with a lot of them to onboard them onto Cloud Work cuz I wanted to see how you know like outside of enterprise with small businesses how do our users actually onboard? And I got such

其实刚刚发布了面向小企业的 Claude,这个产品让我特别兴奋。我有很多开餐厅的朋友,他们工作起来真的特别拼。于是我跟他们中的很多人见了面,带他们上手 Claude Work,因为我想看看,在企业客户之外,小企业用户实际是怎么完成上手(onboard)的。我得到了特别

[15:10]

valuable feedback. It's actually really humbling to see where in the onboarding flow we there was so many things that we could have been doing better. So I really encourage you all to to dog food your product so then you really I call it like feeling it in your bones cuz really get keeps you um giving you a sense of what your product is doing. If not, after a while, you might find

宝贵的反馈。看到在上手流程里有那么多本可以做得更好的地方,真的很让人清醒。所以我特别鼓励你们都去亲自用自己的产品,这样你才能真正——我把它叫做打心底里去感受它——这能让你对自己的产品到底表现如何有切身的体会。要不然,过一阵子你可能会发现

[15:31]

yourself making product decisions that's all just based on either metrics or dashboards or PowerPoints. So definitely dog food dog food dog food or as we call it Anthropic ant food. So filling cross-functional gaps with Claude. This is interesting cuz I actually see this for all roles. So for example, designers on Claude code team previously, you know, anytime we wanted

自己做的产品决策全都只是基于一些指标、仪表盘或者 PowerPoint。所以一定要用自己的产品,用、用、再用,或者用我们在 Anthropic 的说法叫"吃 ant food"。那再说用 Claude 来填补跨职能的空缺。这点很有意思,因为我发现它适用于所有角色。比如说,以前 Claude Code 团队的设计师,任何时候我们想

[15:54]

to make polish or UX fixes, designers would go ahead and create that red line and then hand it off to engineering. And it's always a wait, you know, cuz engineering is always about I have to build this product, I have to fix this bug, when will I time to actually do this polish. Designers on Claude code actually, you know, use Claude to make a lot of those polish fixes so then it

做一些打磨或者 UX 上的修正,设计师都会去画出标注稿(red line),然后交接给工程。可这总是要等,因为工程那边永远是:我得做这个产品、我得修这个 bug,我哪有时间去做这些打磨。而 Claude Code 团队的设计师现在会用 Claude 自己去做很多这类打磨修正,这样就

[16:14]

really closes that iterative loop a lot faster. And again, this goes into why it's so important to do the verification. On the flip side, for me like for example, one time I was fixing a bug and I needed a little bit of content help. I I don't know about you all but as an engineer I tend to be very verbose and when I'm like, you know, if you ask me to write a very short sentence to

把那个迭代闭环收得快多了。这又一次说明了为什么做验证这么重要。反过来,拿我自己举例,有一次我在修一个 bug,需要一点文案上的帮助。我不知道你们怎么样,但作为工程师,我写东西往往特别啰嗦,如果你让我写一句很短的话来

[16:34]

describe what something's supposed to do, I tend to go too much into the weeds but Claude was a really great content design partner for me. And so that's what I found really interesting on Claude code team. For all roles, Claude is actually augmenting all the areas where you may not be a strong.

描述某个东西该干嘛,我往往会陷进太多细节里。但 Claude 在内容设计上是个特别好的搭档。这就是我在 Claude Code 团队里发现的特别有意思的一点:对所有角色来说,Claude 其实都在你不那么擅长的那些地方增强着你。

[16:52]

So this was the manager slide that I was like, oh, this was, you know, maybe a good spicy topic but when I first joined Claude code, this was one of the first things I changed. I'm like, hey, I was working with a recruiting team to go because I believe so much in dog fooding and on Claude code we're using Claude to build Claude, we're using Claude code to build Claude code. And uh so every

这是讲管理者的那一页,我当时还想,哦,这也许是个有点"辣"的话题。但我刚加入 Claude Code 的时候,这是我最先改的一件事之一。我当时跟招聘团队合作去推动这件事,因为我太相信亲自用产品这件事了——在 Claude Code,我们用 Claude 来构建 Claude,我们用 Claude Code 来构建 Claude Code。所以每一个

[17:11]

manager started as an IC first. I actually felt this worked really well cuz it enabled managers before you have to worry about the responsibility of supporting people actually having time to, you know, like roll up your sleeves and get into the code base and learn what it's like to be an engineer on the team.

管理者一开始都得先做一段时间的 IC(一线工程师)。我真切感受到这招效果特别好,因为它让管理者在还没背上"支持下属"这份责任之前,先有时间真正撸起袖子、扎进代码库里,亲身体会在这个团队里当一名工程师是什么感觉。

[17:26]

Um maybe I'll also, you know, like touch on this is also a great time that if you're a manager to actually get some maker hours back and actually get back into the code base cuz the onboarding is a lot less daunting than it used to be.

我也想顺便提一下,如果你是管理者,现在其实是个很好的时机,去把一些动手编码的时间(maker hours)拿回来,重新回到代码库里,因为现在上手要比过去轻松得多了。

[17:40]

Um actually even before Anthropic, there were different roles I've had where I've switched between manager and IC. And I think every time I switched to an IC, it really helped me build up the engineering toolbox. But that onboarding was always a little like, you know, that slight hesitation cuz it could be daunting if you haven't done it in a while. But like speaking for myself, I

其实早在来 Anthropic 之前,我在不同的岗位上就在管理者和 IC 之间来回切换过。我觉得每次切回去做 IC,都真的帮我充实了工程上的工具箱。但那个重新上手的过程总会让人有那么一点点犹豫,因为如果你有阵子没干这个了,它确实会让人发怵。不过就拿我自己来说,我

[17:58]

remember when I onboarded to Claude, it was uh it was such a different experience. And actually, that's what I'll go into next. So in terms of knowledge sharing, what becomes a new source of truth? So when I was onboarding to Claude, the code is our source of truth. And so I again, like in the old days, anytime I join new team, I'd meet with all the engineers to

记得我上手 Claude 的时候,那是一种特别不一样的体验。其实接下来我就要讲这个。那在知识共享方面,什么会成为新的"真理之源"(source of truth)?我上手 Claude 的时候,代码就是我们的真理之源。所以,还是那句话,在过去,每当我加入新团队,我都会去跟所有工程师碰面,

[18:18]

I still do meet with all the engineers on the team, but now we talk a lot more about what's on top of minds and because before I would always so like do these tech deep dives. And now I actually did my first, you know, like tech deep dive just with Claude like because Claude has is really good at answering all these questions I have. So even when I was doing that

我现在还是会去跟团队里所有工程师碰面,但现在我们更多聊的是大家心里最关心的事。因为以前我总会去做那种技术深挖(tech deep dive),而现在我第一次的技术深挖其实是直接跟 Claude 一起做的,因为 Claude 特别擅长回答我所有的这些问题。所以即便当时我在做那

[18:36]

first bug fix, I remember asking Claude, "Hey, before I dive into this bug fix, can you actually teach me a little bit about the surface area and also what are what about all the areas around that bug as well?"

第一个 bug 修复时,我记得我会问 Claude:"嘿,在我扎进这个 bug 之前,你能先教我一点这块涉及的范围(surface area),还有这个 bug 周边那些区域的情况吗?"

[18:49]

And so for Claude code and co-work team, our code is a source of truth. I would encourage all of your teams like if whatever is your source of truth, where whether it's a spec, you might actually change that into a skill that you check into the code base. Like whatever you can make sure becomes your source of truth, keep it in the code base cuz this way you can actually keep it up to date.

所以对 Claude Code 和 co-work 团队来说,代码就是唯一的真相来源(source of truth)。我建议你们各个团队都这么做:不管你的真相来源是什么,哪怕是一份 spec,你都可以把它转成一个 skill,然后 check in 到代码库里。只要能做到,就把你的真相来源放进代码库,因为这样你才能真正让它保持最新。

[19:08]

Cuz that's the other thing when coding, you know, bandwidth is so much, you know, like so much more. It also makes it easier for any documentation that also doesn't isn't part of the update loop to get out of date.

因为这是另一个关键点:写代码的时候,带宽要大得多。这也意味着,任何不在这个更新循环里的文档,都更容易变得过时。

[19:21]

So, how did we roll out all these changes on the Cloud Code team? There were things that we was really important that we aligned as a team. And then there's also I want to make sure we also give space for bottoms up because each team is focused on different things and there might be, you know, like different tool chains or anything that resonates more with each team.

那我们在 Claude Code 团队是怎么推这些变化的呢?有些东西我们觉得作为一个团队必须对齐(align)。但同时我也想给自下而上的空间留出余地,因为每个团队关注的点不一样,可能各自有不同的工具链,或者有些东西对某个团队来说更有共鸣。

[19:40]

So, what did we align with kind of like the teams as a must do? These are some of our Cloud Code team principles and what we call forcing function. And this slide is out of date. Like I shouldn't put every engineer, every teammate uses Cloud Code and also co-work, actually.

那我们作为团队对齐、要求大家必须做到的是什么呢?这些是我们 Claude Code 团队的一些原则,我们管它叫"强制函数"(forcing function)。这张幻灯片其实已经过时了,我都不该列出来——每个 engineer、每个队友都在用 Claude Code,现在其实也都在用 co-work。

[19:55]

So, like us using our product day in day has been really important. Cloudify everything we can. And so, like anytime we have a question of, you know, what yeah, I'm doing this, what's better than me doing it? Can Cloud do it for me cuz then it actually frees up more of my bandwidth for other problems to solve.

所以我们每天都在用自己的产品,这一点非常重要。能 Claude 化(Claudify)的都 Claude 化。所以任何时候我们一遇到问题,比如"我在做这件事,有没有比我自己做更好的办法?Claude 能帮我做吗?"——因为如果能,它就真正释放了我更多的带宽去解决别的问题。

[20:11]

And my last one is a explicit permission to kill old processes. Again, it's the e- even our team principles and even processes as we put on, even after a few months when we notice, hey, is this really serving its intended purpose? We really always give ourselves permission to always critique and make sure to always revisit.

最后一条是:明确授权大家去砍掉老的流程。哪怕是我们定下的团队原则和流程,过了几个月之后我们也会注意到——"嘿,这个东西真的还在发挥它本来该有的作用吗?"我们总是给自己留出这种权限,随时去批判、随时重新审视。

[20:30]

And but bottoms up, there's a lot of freedom for, you know, like, you know, team or pods to adapt. So, for example, how Cloud shows up in team triage or any teams like planning rituals or stand-ups or which workflows get Cloudified first, that is a a lot of bottoms up. So, I found that this balance of make sure you align with the team of in terms of like what's important in terms of team

但在自下而上这块,团队或者小组(pod)有很大的自由去适配。比如说,Claude 在团队 triage、各种规划仪式、站会里怎么用,或者哪些工作流先被 Claude 化,这些很大程度上都是自下而上决定的。所以我发现这种平衡很关键:在团队文化里什么重要这件事上要对齐,

[20:52]

culture and also update those as you go, but then leave some room for each pod to adapt. So, if I zoom out, what were the three things that I prioritized for Cloud Code and co-work that I think has worked really well? And number one, it was, you know, like keeping the org as agile and as flat as possible, having managers also, you know, like support parts of

并且随着情况变化不断更新这些东西,但同时给每个小组留出适配的空间。那如果拉高一点视角,我为 Claude Code 和 co-work 优先抓的三件事、而且我觉得效果很好的是什么呢?第一,就是尽量让组织保持敏捷、保持扁平,让管理者也去支持一部分具体工作,

[21:13]

work, but also really get into the code base and be directly responsible for parts of the product as well. Uh number two, that's our Claude-ify. So, if Claude can do it, Claude should. So, that's always a question we're asking. And And maybe that's the other interesting, too, like um you know, this morning you heard the talks about the models. The models are improving at an

同时也真正深入代码库,直接对产品的某些部分负责。第二,就是我们的 Claude 化。如果 Claude 能做,那就该让 Claude 做。所以这永远是我们在问自己的问题。还有个有意思的点——今天早上你们听了关于模型的演讲,模型在以惊人的速度进步。

[21:32]

amazing pace. So, sometimes we might find even if Claude wasn't good at doing something two or three months ago, now with like a model update, it's actually gone really good. And this is why again, it always goes back to that whole like always revisit and always have the growth mindset cuz the models are also improving really fast.

所以有时候你会发现,哪怕两三个月前 Claude 还做不好某件事,现在随着一次模型更新,它其实已经做得非常好了。这也是为什么——又回到那句话:永远重新审视、永远保持成长型心态,因为模型也在飞快地进步。

[21:51]

And again, you know, people don't delete processes on their own, they tend to pile up. I remember I was on a team where we had so many different SLAs. There was an SLA for P0 bugs, an SLA for incident response. And after a while, I'm like, with all these SLAs, I need a stacked rank list to actually have cuz even the engineers are coming to me going, "There's only 24 hours in a day,

再说一遍,人是不会主动去删流程的,流程往往只会越堆越多。我记得我以前待过一个团队,有一大堆不同的 SLA。P0 bug 有个 SLA,事故响应有个 SLA。过了一阵子我就想,有这么多 SLA,我都得搞一份排好序的优先级清单了——因为连 engineer 都来找我说:"一天就只有 24 小时,

[22:11]

like which SLA am I supposed to do?" And but that's why it's always so important to audit. I remember that time, I'm like, "You know what? We really should be auditing. Are all these SLAs still really necessary?"

我到底该先做哪个 SLA?"这就是为什么定期审计(audit)永远这么重要。我记得那时候我就想:"你知道吗?我们真的该好好审计一下,这些 SLA 是不是都还有必要?"

[22:24]

So, now for the proof. What are some signals that we're seeing of like is it actually working? So, these are some numbers that I find as helpful that I wanted to share with you all. And so, these were some of the shifts we've seen as we've been kind of improving our workflows. Onboarding ramp-up time goes down. Like I think that's actually really good signal of

那现在来看看实打实的证据。我们看到哪些信号能说明这套东西真的在起作用?这些是我觉得挺有用、想分享给大家的一些数字。随着我们不断改进工作流,我们看到了一些转变。新人上手时间(onboarding ramp-up time)在下降。我觉得这其实是个非常好的信号,

[22:45]

like we used to have this thing of like what's the span of time it takes for the engineer to land their first PR. The onboarding ramp-up time and also like costs to other team members we notice keeps going down. Like I I I even like a lot of times sometimes when a person joins a team, they'll ask me a question, I'm like, "That's a great question. We should ask Claude. Like that's how we

比如我们以前会看这么一个指标:一个 engineer 从入职到提交第一个 PR 要花多长时间。这个上手时间,还有他对其他队友造成的占用成本,我们注意到都在持续下降。很多时候,一个新人加入团队来问我问题,我会说:"这是个好问题,我们应该去问 Claude。"我们就是这么

[23:03]

kind of like Claude has really helped us to onboard and answer a lot of questions. Which is also why for the managers, I it's why it's fun for me to actually get back to the codebase cuz in the old days, I would actually feel bad cuz I feel like, oh, I need to learn this area. I'm going to ask an engineer and take time away from their day cuz they're all so busy. But now thanks to

用 Claude 来帮新人上手、回答一大堆问题的。这也是为什么对管理者来说——我重新回到代码库这件事对我来说很有意思,因为在过去,我会觉得很不好意思,我会想:哦,我得搞懂这块,我得去问某个 engineer,这会占用他一天里的时间,因为他们都太忙了。但现在多亏了

[23:21]

Claude, I don't feel like I'm wasting anybody's time. The PR cycle time should also go down, but this one's interesting. I'm going to say it's important for you to not just look at the end-to-end, but actually break it out into like what are all the different funnels in terms of a PR. Cuz if your PR cycle time isn't going down, it might not mean you're not adopting

Claude,我不觉得我在浪费任何人的时间了。PR 周期时间(cycle time)应该也会下降,但这个指标挺有意思的。我得说,你不能只看端到端的总时间,而要把它拆开,看看一个 PR 里到底有哪些不同的环节。因为如果你的 PR 周期时间没下降,不一定说明你没在用

[23:39]

AI. It could be other parts of your queue is actually getting jammed up because of all the throughput. So for example, are your build and CI systems keeping up? So for PR cycle time, I think it's actually really healthy to break it down into all the different chunks and seeing which of those you might be able to improve or automate.

AI。也可能是你队列里别的环节被堵住了,正是因为吞吐量上来了。比如说,你的 build 和 CI 系统跟得上吗?所以对 PR 周期时间,我觉得很健康的做法是把它拆成各个环节,看看其中哪些是你能改进或者自动化的。

[23:58]

And lastly, Claude-assisted commits go up. As I mentioned, I don't think I've ever like in the last few months I've not seen a commit that wasn't you know, like assisted by Claude. But if I step out, like I would say what's even more important than just throughput is whatever, you know, you and your team are trying to solve, whatever the product or problem. Find some way to

最后,Claude 辅助的提交(Claude-assisted commits)在上升。就像我说的,过去这几个月里,我几乎没见过哪个 commit 不是 Claude 辅助完成的。但如果跳出来看,我会说,比纯粹的吞吐量更重要的是——不管你和你的团队在试图解决什么,不管是哪个产品或者哪个问题,想办法去

[24:18]

measure that cuz outside of just throughput, hopefully we're also making meaningful change to make the product better or improve quality. Okay, so now it's time for me to maybe share like a little takeaway home exercise that might be fun for you to take back and go have discussions with your team. But first I want to be really transparent. I still have questions as

衡量它。因为除了吞吐量之外,我们希望也在做出有意义的改变,让产品更好、或者提升质量。好,那现在该轮到我分享一个小小的"带回家作业"了,你们可以带回去跟团队讨论,应该会挺有意思。但首先我想非常坦诚地说:我自己也还有很多问题

[24:40]

well. So I'll share with some of those that we're still working out through the Claude code team. So for example, do you still need separate iOS and Android orgs? Like that was kind of like more of the traditional org approach if you would usually have like one for iOS, one for Android. But now with Claude and enabling our engineers to go flex across different

没想明白。所以我也分享几个我们在 Claude Code 团队还在摸索的问题。比如说,你还需要把 iOS 和 Android 拆成两个独立的组织吗?这算是比较传统的组织方式——通常你会有一个 iOS 组、一个 Android 组。但现在有了 Claude,我们的 engineer 能够灵活地跨不同的

[24:58]

mobile platforms, we're thinking, "Hey, do we really still need you know, two separate mobile teams?" Uh how far do you push fully automated reviews? We always want to make sure we're striking that right balance between kind of speed and fast enough and make sure we're not losing something important.

移动平台来回切换,我们就在想:"嘿,我们真的还需要两个独立的移动团队吗?"还有,完全自动化的 review 你要推到多远?我们总想确保在速度——够快——和不丢掉重要的东西之间,把握好那个恰当的平衡。

[25:15]

And roles are blurring. And how do we make sure everybody is productive? And that's why we're we're right now looking through verification is a big one. So, that hey, as we're going through, make sure everybody that makes a change has confidence in their change. But also, what are all the different parts of the workflow, too? Like I'm working with my designers. We actually just, you know,

还有,角色之间的边界正在变得模糊。我们怎么确保每个人都保持高产?这就是为什么我们现在在重点研究验证(verification)这件事。也就是说,在我们推进的过程中,要确保每个做出改动的人都对自己的改动有信心。但同时,工作流里还有哪些不同的环节?比如我在和我的设计师们一起工作,我们其实刚刚

[25:33]

announced Claude design. Also thinking through how can we make sure that we're also improving the workflows of all the functions on the team. So, with that, this is what I would love to leave you all with. Pick your noisiest workflow. Or it could be just some workflow or team meeting that you don't particularly enjoy or is really high tax on the team. Like I remember it

发布了 Claude design。也在思考,我们怎么确保也能改进团队里各个职能的工作流。所以,我想留给大家的就是这句话:挑出你最"吵"的那个工作流。也可以只是某个你不太喜欢、或者对团队来说成本特别高的工作流或团队会议。我记得

[25:54]

I was on another team where we would have this really expensive weekly meeting and I noticed everybody's on their laptop. And you know, except for when they have to pop their head up to give status and then they go back to their laptop. I'm like, this is when you count, you know, like how many people's in this room, this is a very expensive room. So, always like kind of like pick

我在另一个团队待过,我们有个每周开的、成本特别高的会,我注意到所有人都低头盯着自己的笔记本,除了轮到自己汇报状态时抬一下头,汇报完又埋回笔记本里。我就想,你数一数这屋里坐了多少人,这是个成本极高的房间。所以一定要这样:挑出

[26:11]

a workflow and always ask yourself, "Is it still serving its purpose?" Or if it's like really expensive, is this something that Claude might be able to help you with? And kind of like do this one step at a time.

一个工作流,然后问自己:"它还在发挥它该有的作用吗?"或者如果它成本真的很高,这是不是 Claude 也许能帮你处理的事情?然后一步一步来,慢慢做。

[26:25]

And with that, thank you so much for listening to my talk. >> [applause] >> It's been a pleasure.

好,那就到这里,非常感谢大家听我的分享。[掌声] 很荣幸。