1
00:00:00,000 --> 00:00:04,239
Well it made quite a meal about it. It took at least 10 minutes, maybe longer.
嗯，这真是一顿美餐。至少花了10分钟，也许更长。

2
00:00:04,239 --> 00:00:09,760
It ended up with more than 8,000 lines in total. It built a really extensive test suite.
最终总共有 8,000 多行。它构建了一个非常广泛的测试套件。

3
00:00:09,760 --> 00:00:13,039
It did have problems because of the way I shut down that server like that,
由于我这样关闭服务器的方式，它确实出现了问题，

4
00:00:13,039 --> 00:00:17,120
but it figured it out. It navigated through. It hit the context window filled up and it had
但它想通了。它顺利通过了。它击中了上下文窗口，并且它已经填满了

5
00:00:17,120 --> 00:00:22,719
to do an auto-compact, which is what it does when it realizes it's going to need to compact itself.
进行自动压缩，当它意识到需要压缩自身时就会这样做。

6
00:00:22,719 --> 00:00:27,200
And that's always a bit of a nail-biting experience for the voyeur, like you and me,
对于像你我这样的偷窥者来说，这总是有点令人紧张的经历，

7
00:00:27,200 --> 00:00:31,360
watching it, doing it. And sure enough, afterwards, it does seem for a moment to
看着它，做它。果然，事后，有一瞬间似乎

8
00:00:31,360 --> 00:00:35,439
be confused about what it's trying to do, but it figured it out. It finished the job
对它想要做什么感到困惑，但它想通了。它完成了工作

9
00:00:36,000 --> 00:00:42,880
and then it's declared success. And sure enough, I did just bring up our NDA creator and confirmed
然后就宣告成功了。果然，我确实提到了我们的保密协议创建者并确认了

10
00:00:42,880 --> 00:00:48,959
that it's working. You can see that 76 tests passed across five suites, a bunch of different
它正在发挥作用。您可以看到 5 个套件通过了 76 个测试，这是一堆不同的测试

11
00:00:48,959 --> 00:00:55,279
sets of tests, which is all very impressive. And then I can indeed go to localhost 3000
一系列的测试，这一切都非常令人印象深刻。然后我确实可以访问 localhost 3000

12
00:00:55,279 --> 00:01:00,880
and see that it is here. Everything seems to be just fine with everything. Presumably,
并看到它就在这里。一切似乎一切都很好。想必，

13
00:01:00,880 --> 00:01:05,440
if I type in something here, like the governing law in New York, we're going to see on the right
如果我在这里输入一些内容，例如纽约的管辖法律，我们会在右侧看到

14
00:01:05,440 --> 00:01:10,160
there, you go, you see that it does in fact, update things live. I wonder if I can download
在那里，你会发现它确实实时更新内容。我想知道是否可以下载

15
00:01:10,160 --> 00:01:14,879
a PDF before I finished. Yep, I can. That's fine. It will just show the fields in there that haven't
在我完成之前有一个PDF。是的，我可以。没关系。它只会显示其中还没有的字段

16
00:01:14,879 --> 00:01:20,160
yet been filled in. And I can click and see that it comes up with New York filled in there and
尚未填写。我可以点击并看到它出现了纽约填写在那里，

17
00:01:20,160 --> 00:01:26,639
other stuff just there as a placeholder to be filled in. So there we go. It is working nicely.
其他的东西只是作为占位符来填写。所以我们开始吧。它运行良好。

18
00:01:26,639 --> 00:01:33,839
And Cloud Code has built this very extensive set of tests and it has completed the task
Cloud Code 已经构建了这套非常广泛的测试，并且已经完成了任务

19
00:01:33,839 --> 00:01:41,360
ably. And now I will just quickly go to the MCP one more time and just re-authenticate
干练地。现在我将再次快速前往 MCP 并重新进行身份验证

20
00:01:41,360 --> 00:01:48,559
with Atlassian. I know you have to do this all the time. Up it comes, approve, scroll down, accept.
与 Atlassian 一起。我知道你必须一直这样做。向上滚动，批准，向下滚动，接受。

21
00:01:50,160 --> 00:02:06,959
Back we come to here. And now let's say, please merge the PR locally and push to main and switch
回来我们来到这里。现在我们说，请在本地合并 PR 并推送到 main 并切换

22
00:02:07,919 --> 00:02:25,600
the branch to main and mark this issue PL3 done in Jira. That's our final instruction.
分支到 main 并将此问题标记为 PL3 在 Jira 中完成。这是我们的最终指示。

23
00:02:25,600 --> 00:02:31,440
That should polish this off. Let it get on with it. I'll see you when it's done. And it's done.
这应该解决这个问题。让它继续下去吧。完成后我会见到你。一切都完成了。

24
00:02:31,440 --> 00:02:37,919
And it's successful. And that was too easy. It seems crazy. We built this prototype application
并且它是成功的。那太容易了。看起来很疯狂。我们构建了这个原型应用程序

25
00:02:37,919 --> 00:02:42,320
in a matter of minutes, hardly doing anything. We just had to tell it to write some tests,
几分钟之内，几乎什么也没做。我们只需要告诉它写一些测试，

26
00:02:42,320 --> 00:02:45,919
but it didn't need to because it was already working. But now it's also written a bunch of
但它不需要，因为它已经在工作了。但现在也写了一堆

27
00:02:45,919 --> 00:02:50,960
tests. Now, the bad news is that I wanted to go through with you today debugging strategies. And
测试。现在，坏消息是我今天想与您一起了解调试策略。和

28
00:02:50,960 --> 00:02:55,119
for that, I wanted it to have a bug. I was sure there was going to be a bug. And then we go through
为此，我希望它有一个错误。我确信会有一个错误。然后我们通过

29
00:02:55,119 --> 00:02:59,360
and fix it together. And what we may have to do is I'll tell you about the strategy we would have
并将其固定在一起。我们可能要做的是我会告诉你我们的策略

30
00:02:59,360 --> 00:03:05,520
followed. And we'll no doubt hit bugs tomorrow instead and go through the strategy with it then.
紧随其后。毫无疑问，我们明天会发现错误，然后再执行策略。

31
00:03:05,520 --> 00:03:11,600
So here's my recommended strategy for going after debugging. It begins by taking a snapshot.
这是我推荐的调试后策略。首先拍摄快照。

32
00:03:11,600 --> 00:03:16,960
When you debug, you can go off down a tangent. Sometimes Cloud Code can go way off track.
当你调试时，你可以沿着切线走下去。有时，云代码可能会偏离正轨。

33
00:03:16,960 --> 00:03:21,919
And so it's important to do this. And I mean, do a git commit of where you are.
因此，这样做很重要。我的意思是，对你所在的位置进行 git commit。

34
00:03:21,919 --> 00:03:27,279
Don't just trust the rewind functionality, because as you know, that will only back out changes
不要只相信倒回功能，因为如您所知，这只会取消更改

35
00:03:27,279 --> 00:03:32,800
made directly to file edits made by Cloud Code. It can't affect things that are
直接对 Cloud Code 进行的文件编辑进行编辑。它不能影响那些事情

36
00:03:32,800 --> 00:03:36,559
side effects of running a script. So do a git commit to start with.
运行脚本的副作用。因此，首先进行 git 提交。

37
00:03:36,559 --> 00:03:41,759
Then particularly for small issues, for things that just seem to be like something that is just
然后特别是对于小问题，对于那些看起来只是简单的事情

38
00:03:41,759 --> 00:03:47,520
bashed up against, the first mode that one tends to be in is just simply take the stack trace,
受到攻击，人们倾向于采用的第一种模式只是简单地获取堆栈跟踪，

39
00:03:47,520 --> 00:03:53,520
the error message, whatever it is, copy it, and paste it as is into Cloud. And just do that. And
错误消息，无论是什么，都将其复制并按原样粘贴到 Cloud 中。就这么做吧。和

40
00:03:53,520 --> 00:03:57,279
repeat it. Fixes something, just do it again and again. You don't even need to explain,
重复一遍。修复一些东西，只需一遍又一遍地做。甚至不需要解释，

41
00:03:57,279 --> 00:04:02,880
I was doing blah, blah, blah, and this happened. Just focus on efficiency, copy, paste, copy, paste.
我正在做废话，废话，废话，然后这件事发生了。只注重效率，复制，粘贴，复制，粘贴。

42
00:04:02,880 --> 00:04:08,800
Usually for simple problems, Cloud gets the joke, it understands the context, it figures it out,
通常对于简单的问题，云会理解这个笑话，它理解上下文，它会弄清楚，

43
00:04:08,800 --> 00:04:13,199
it fixes it, and you're on. And that's a super productive way to work.
它修复了它，然后你就可以了。这是一种超级高效的工作方式。

44
00:04:13,199 --> 00:04:18,160
So that's typically the first kind of mode that I'm in. But if that doesn't yield good results,
所以这通常是我所处的第一种模式。但如果这不能产生好的结果，

45
00:04:18,160 --> 00:04:23,279
or sometimes it just makes things even worse, I will revert back to where I took the last commit
或者有时它只会让事情变得更糟，我会恢复到上次提交的位置

46
00:04:23,279 --> 00:04:28,079
and do things in a more organized way. And if that quick interactive approach doesn't work,
并以更有条理的方式做事。如果这种快速互动方法不起作用，

47
00:04:28,079 --> 00:04:35,200
then I change tactic completely to a more disciplined, regimented approach, where I focus
然后我完全改变策略，采用更有纪律、更有条理的方法，我专注于

48
00:04:35,200 --> 00:04:40,799
on a file, a markdown file, that Cloud should write to. I start by saying, this is the issue,
Cloud 应该写入的文件（Markdown 文件）。我首先说，这就是问题，

49
00:04:40,799 --> 00:04:45,760
I need you to reproduce it consistently, every time, and document how you do it,
我需要你每次都一致地重现它，并记录你是如何做到的，

50
00:04:45,760 --> 00:04:52,399
document it in debug.md or whatever.md. Then I want you to investigate, look at all the
将其记录在 debug.md 或 another.md 中。然后我要你调查一下，看看所有的

51
00:04:52,399 --> 00:04:58,799
related logs, put in extra logging information, get all the information you can, gather information,
相关日志，放入额外的日志信息，尽可能获取所有信息，收集信息，

52
00:04:58,799 --> 00:05:04,720
investigate deeply, come up with hypotheses for what could be causing this, and document them
深入调查，提出可能导致这种情况的假设，并记录下来

53
00:05:04,720 --> 00:05:10,959
in debug.md. Get everything recorded out there. Include in that doing a web search for other
在debug.md中。把一切都记录下来。包括在网络上搜索其他内容

54
00:05:10,959 --> 00:05:15,760
people that have had these problems. And by the way, there is a classic Cloud problem to
遇到这些问题的人。顺便说一句，有一个经典的云问题

55
00:05:15,760 --> 00:05:20,480
watch out for. One of the things that Cloud Code is famous for, and the other tools too,
小心。 Cloud Code 闻名的事情之一，以及其他工具，

56
00:05:20,480 --> 00:05:27,359
is it sees, it finds online a reported stack overflow issue or a GitHub issue
它是否看到、在线发现报告的堆栈溢出问题或 GitHub 问题

57
00:05:27,359 --> 00:05:31,359
that's recorded there, and it sees that it matches the problem that it's found,
记录在那里，它发现它与它发现的问题相匹配，

58
00:05:31,359 --> 00:05:35,519
and it sees someone's complained about it, and there's a workaround, and it says something like,
它看到有人对此抱怨，并且有一个解决方法，它说，

59
00:05:35,519 --> 00:05:41,839
I found it, this is the problem, it's a known problem. That's always one of my red flags
我发现了，这就是问题，这是一个已知的问题。这始终是我的危险信号之一

60
00:05:41,839 --> 00:05:48,640
when I hear that. What it doesn't notice is that this was an issue reported by maybe one person
当我听到这个消息时。它没有注意到的是，这可能是一个人报告的问题

61
00:05:48,640 --> 00:05:54,320
three years ago, and it just takes a sense of perspective and frankly some common sense
三年前，这只需要一种远见卓识和一些常识

62
00:05:54,320 --> 00:05:59,040
to see that this is in fact a sort of one-off thing, that there's no way that this could
看到这实际上是一种一次性的事情，这不可能

63
00:05:59,040 --> 00:06:03,279
actually be the same thing that you've got. It's just someone else out there on the internet
实际上和你拥有的东西是一样的。这只是互联网上的其他人

64
00:06:03,279 --> 00:06:08,160
had a very similar problem three years ago, which no one ever responded to because it wasn't a big
三年前有一个非常相似的问题，但没有人回应，因为这不是一个大问题

65
00:06:08,160 --> 00:06:14,640
deal. But Cloud will say, found it, and this was what to do. You have to install a prior version
交易。但克劳德会说，找到了，这就是要做的事。您必须安装以前的版本

66
00:06:14,640 --> 00:06:21,359
of some package, and it's all over the shop, and so having that sanity check to say, just because
一些包裹，而且商店里到处都是，所以要进行健全性检查，只是因为

67
00:06:21,359 --> 00:06:28,000
you found one other recorded instance of this issue, do you have evidence that this is a common
您发现了此问题的另一个记录实例，您是否有证据表明这是一个常见问题

68
00:06:28,000 --> 00:06:33,600
issue? Did more than one person report it? Does it really seem like this is the same thing we're
问题？是否有不止一个人举报？这看起来真的和我们是同一件事吗

69
00:06:33,600 --> 00:06:39,040
encountering? You've got to challenge it hard on things like that. Jumping to conclusions is what
遇到？你必须在这样的事情上努力挑战它。急于下结论是什么

70
00:06:39,040 --> 00:06:43,519
these models often do, even though we didn't see that earlier, but it does happen, and that's the
这些模型经常这样做，尽管我们之前没有看到这一点，但它确实发生了，这就是

71
00:06:43,519 --> 00:06:48,799
kind of thing to watch out for, seizing on one reported incident that happened a while ago.
需要注意的是，抓住不久前发生的一起报道事件。

72
00:06:49,359 --> 00:06:55,600
So, investigate hypotheses and sanity check the hypothesis that you see, and as a result of that,
因此，调查假设并检查你所看到的假设的合理性，结果，

73
00:06:55,600 --> 00:07:00,720
it should come up with a root cause that it has identified as being the root cause of the issue,
它应该提出一个已确定为问题根本原因的根本原因，

74
00:07:00,720 --> 00:07:06,880
in which case it needs to demonstrate it, prove that that really is the root cause, and document
在这种情况下，它需要证明它，证明这确实是根本原因，并记录

75
00:07:06,880 --> 00:07:11,600
the proof in debug.md, and you're guiding it through, you're giving it these instructions.
debug.md 中的证明，并且您正在引导它完成，您正在向它提供这些说明。

76
00:07:11,600 --> 00:07:19,679
Okay, if that's the root cause, prove it, document it, write it to .md, and then, of course,
好的，如果这是根本原因，请证明它，记录它，将其写入 .md，然后，当然，

77
00:07:19,679 --> 00:07:26,239
the next step is, now you know the root cause, now fix it, and prove that your fix consistently
下一步是，现在您知道了根本原因，现在修复它，并证明您的修复始终如一

78
00:07:26,880 --> 00:07:31,279
fixes the issue. You've reproduced it consistently, you've applied your fix, and now it works
解决了这个问题。您已经一致地重现了它，您已经应用了修复程序，现在它可以工作了

79
00:07:31,279 --> 00:07:38,160
consistently, and finally, document lessons learned in claude.md. Come back and realizing,
最后，始终如一地记录 claude.md 中吸取的经验教训。回来后才发现，

80
00:07:38,160 --> 00:07:44,160
recognizing what you did, learn from it for this project, put down some tips so that you don't
认识到你所做的事情，从中学习这个项目，写下一些提示，这样你就不会

81
00:07:44,160 --> 00:07:48,320
repeat the same mistake again, because often, once you clear the conversation, or there's a
再次重复同样的错误，因为通常，一旦你清除了对话，或者有一个

82
00:07:49,920 --> 00:07:55,040
compact, suddenly it's forgotten about this, and it repeats, which is awful, which is the worst,
紧凑，突然忘记了这一点，然后重复，这很糟糕，这是最糟糕的，

83
00:07:55,040 --> 00:08:00,559
it's infuriating. You don't want that to happen, document it in claude.md. This is the approach I
真令人气愤。如果您不希望这种情况发生，请将其记录在 claude.md 中。这就是我的方法

84
00:08:00,559 --> 00:08:06,399
go through, it's disciplined, it's a bit frustrating, but it tends to yield good outcomes,
经历，它是有纪律的，有点令人沮丧，但它往往会产生好的结果，

85
00:08:06,399 --> 00:08:11,440
and it is common to find it going off the rails and going off on a tangent that proves to be a
通常会发现它偏离轨道并偏离正轨，这被证明是

86
00:08:11,440 --> 00:08:16,959
red herring, and then I would typically go back to my git commit, I'd wipe everything out, I'd put
红鲱鱼，然后我通常会回到我的 git 提交，我会清除所有内容，我会把

87
00:08:16,959 --> 00:08:22,079
a note about what the problem is not, and then I'd start it all over again. There was some, the kind
说明问题不是什么，然后我会重新开始。有一些，那种

88
00:08:22,079 --> 00:08:26,239
of thing that it loves to latch on to, when it does, it says it with such confidence, it would
它喜欢抓住的东西，当它抓住时，它会充满自信地说出来，它会

89
00:08:26,239 --> 00:08:33,760
say things like, no, an LLM cannot both have tool use and structured outputs in the same LLM call,
比如说，不，LLM 不能在同一个 LLM 调用中同时拥有工具使用和结构化输出，

90
00:08:33,760 --> 00:08:38,400
this is the problem, it's a known issue, and as a result, and then it rewrites everything.
这就是问题所在，这是一个已知问题，因此，它重写了所有内容。

91
00:08:38,400 --> 00:08:42,880
And when you look back, it's a completely fictional, fictional issue, maybe someone
当你回头看时，这完全是一个虚构的、虚构的问题，也许有人

92
00:08:42,880 --> 00:08:47,840
reported something about this by mistake years ago, and now I often find that that particular
几年前错误地报道了一些关于这方面的事情，现在我经常发现那个特定的

93
00:08:47,840 --> 00:08:52,000
thing has happened two or three times to me, when it suddenly latches onto that and starts
这种事在我身上发生过两三次，突然抓住它并开始

94
00:08:52,000 --> 00:08:57,599
rebuilding things, and you're like, no. So that's a moment when you stop it, you restore from your
重建东西，你会说，不。所以那是你停止它的那一刻，你从你的状态中恢复过来

95
00:08:57,599 --> 00:09:04,880
last commit, and then you go and tell it, this is not the problem, try again. And another hot tip
最后一次提交，然后你去告诉它，这不是问题，再试一次。还有另一个热门提示

96
00:09:04,880 --> 00:09:11,919
that works really well, is using a different agent, and I mean using a different LLM. So time
效果非常好，就是使用不同的代理，我的意思是使用不同的法学硕士。那么时间

97
00:09:11,919 --> 00:09:18,400
to pull up Codex, and you know, or Antigravity, one of the other ones we did last week, back in
拉出法典，你知道，或者反重力，我们上周做的其他事情之一，回到

98
00:09:18,400 --> 00:09:24,640
the IDE again, and give it the assignment instead, make it go through this process, because it's like
再次打开 IDE，然后给它分配任务，让它经历这个过程，因为它就像

99
00:09:24,640 --> 00:09:28,479
saying having a second pair of eyes, but because each model has gone through a different training
说有第二双眼睛，但因为每个模型都经过了不同的训练

100
00:09:28,479 --> 00:09:33,919
experience, and has some different prompts, and is just set differently, there's every chance
经验，并有一些不同的提示，只是设置不同，有机会

101
00:09:33,919 --> 00:09:38,799
that it will discover something that Claude has missed. And so doing that is a really great
它会发现克劳德错过的东西。所以这样做真的很棒

102
00:09:38,799 --> 00:09:45,760
technique to have multiple different LLMs, totally different prompts, and models work on the same
拥有多个不同的法学硕士、完全不同的提示以及在相同的模型上工作的技术

103
00:09:45,760 --> 00:09:51,200
problem. That is a pro tip for sure, particularly with really hard problems. And as a final point,
问题。这无疑是一个专业提示，尤其是对于非常困难的问题。最后一点，

104
00:09:51,200 --> 00:09:55,280
there is in fact a skill, there are in fact a bunch of skills for debugging. This I think is the
事实上有一个技能，事实上有很多调试的技能。这我认为是

105
00:09:55,280 --> 00:09:59,919
most popular one as of right now, systematic debugging, and it's a really good one. If you
目前最流行的一种，系统调试，而且非常好。如果你

106
00:09:59,919 --> 00:10:04,159
read through this, the skill is brilliantly written. I've actually not tried it myself,
通读此文，功力写得非常精彩。其实我自己也没有尝试过

107
00:10:04,159 --> 00:10:08,320
but I really want to, because it's a bit like my five steps here, but it's a lot more
但我真的很想这样做，因为这有点像我这里的五个步骤，但它还有更多内容

108
00:10:08,320 --> 00:10:13,599
thorough. It has a lot more about searching the web, it has a lot about really hammering home,
彻底。它有很多关于搜索网络的内容，它有很多关于真正锤炼的内容，

109
00:10:13,599 --> 00:10:19,840
about finding and proving the root cause, which it calls the iron rule. So read the skill,
寻找并证明根本原因，这被称为铁律。所以读技能，

110
00:10:19,840 --> 00:10:25,359
it's great, and try it out if you get stuck on debugging. And if we get stuck in the next week
太棒了，如果你在调试中遇到困难，可以尝试一下。如果我们在下周陷入困境

111
00:10:25,359 --> 00:10:29,440
and a bit, maybe we'll try it ourselves, that would be fun. But that's a good skill to know,
也许我们会自己尝试一下，那会很有趣。但这是一项很好的技能，要知道

112
00:10:29,440 --> 00:10:32,719
and if you look under skills and debugging, you'll see there's a ton of them that you can
如果你查看技能和调试，你会发现有很多你可以

113
00:10:32,719 --> 00:10:39,200
experiment with as part of trying to problem solve. And with that, a quick reminder, a recap
尝试作为尝试解决问题的一部分。在此，快速提醒、回顾一下

114
00:10:39,200 --> 00:10:46,799
of what we did today. We were able to read issues from JIRA using an Atlassian MCP server,
我们今天所做的事情。我们能够使用 Atlassian MCP 服务器从 JIRA 读取问题，

115
00:10:46,799 --> 00:10:52,000
that was then flowed through into Claude Co, where we were running the feature dev plugin
然后流入 Claude Co，我们在那里运行功能开发插件

116
00:10:52,000 --> 00:10:56,400
that took it through the discipline seven step process, although for some reason it skipped
这使它完成了纪律七步过程，尽管由于某种原因它跳过了

117
00:10:56,400 --> 00:11:03,280
step six, but we made it go back and do it. And then that used the GitHub MCP server to create
第六步，但我们让它回去做。然后使用 GitHub MCP 服务器来创建

118
00:11:03,280 --> 00:11:10,320
a PR and then merge it. And all of that ran into end and allowed us to deliver a full feature,
PR 然后合并它。所有这一切都结束了，让我们能够提供完整的功能，

119
00:11:10,320 --> 00:11:15,119
and it worked, which is super impressive. And of course, the cool thing is that all of this was
它成功了，这令人印象深刻。当然，最酷的是所有这一切都是

120
00:11:15,119 --> 00:11:21,119
running inside Claude Co, all of these different bells and whistles of using Claude Co really
在 Claude Co 内部运行，使用 Claude Co 的所有这些不同的附加功能确实

121
00:11:21,119 --> 00:11:26,159
effectively. And it was just that one command that we typed out, feature dev, colon feature dev,
有效地。这只是我们输入的一个命令，feature dev，colon feature dev，

122
00:11:26,159 --> 00:11:31,039
please implement JIRA issue PL3 with a Next.js application and a directory called front-end
请使用 Next.js 应用程序和一个名为 front-end 的目录来实现 JIRA 问题 PL3

123
00:11:31,039 --> 00:11:36,880
and raise a PR when done. Bam, that's all it took, and it all ran. And so again, looking back at the
并在完成后提出 PR。嘭，就这样，一切都跑了。如此反复，回顾过去

124
00:11:36,880 --> 00:11:43,359
Carpathy tweet, this is the kind of way that you can build a workflow that is robust and that is
Carpathy 推文，通过这种方式，您可以构建强大的工作流程，即

125
00:11:43,359 --> 00:11:51,520
thorough and disciplined and really uses Claude Co to the max. And that is a wrap on day four of
彻底、纪律严明，真正最大限度地利用克劳德公司。这是第四天的总结

126
00:11:51,520 --> 00:11:56,479
week two. And tomorrow is when we bring all of this into a project now that we're really good
第二周。明天就是我们把所有这些都带入一个项目的时候，因为我们真的很擅长

127
00:11:56,479 --> 00:12:03,359
at driving Claude Co. And I'm so excited to tell you that that brings us to the 60% point,
我很高兴地告诉你，这使我们达到了 60% 的目标，

128
00:12:03,359 --> 00:12:09,440
60% of the way through. And hopefully you really do feel that big step that's been made now and
已经完成60%了。希望你确实感受到现在已经迈出的一大步

129
00:12:09,440 --> 00:12:13,280
that we're ready for tomorrow, ready for a big project. Bring it on.
我们已经为明天做好了准备，为一个大项目做好了准备。来吧。