1
00:00:00,000 --> 00:00:05,760
Okay, so on to the main topic of the day, which is about how you best use these kinds
好的，现在进入今天的主题，即如何最好地使用这些类型

2
00:00:05,760 --> 00:00:10,560
of advanced coding agents if you're working on a large team with a big code base.
如果您在一个拥有庞大代码库的大型团队中工作，则可以使用高级编码代理。

3
00:00:10,560 --> 00:00:15,640
And this is where historically they've been criticized, because things like Cloud Code
这就是历史上他们受到批评的地方，因为像 Cloud Code 这样的东西

4
00:00:15,640 --> 00:00:20,700
work really well with great market data demos like the one you just saw, when there's a
当有一个很棒的市场数据演示时，就像您刚刚看到的那样，效果非常好

5
00:00:20,700 --> 00:00:26,159
nice defined small project, it's building from scratch, it can write the docs.
很好定义的小项目，它是从头开始构建的，它可以编写文档。

6
00:00:26,159 --> 00:00:31,479
Where they can struggle is when they're suddenly inheriting a massive code base.
当他们突然继承庞大的代码库时，他们会陷入困境。

7
00:00:31,479 --> 00:00:38,919
And to be honest, this is less true now, now that we are past the point of inflection from last November.
说实话，现在情况已经不那么正确了，因为我们已经过了去年 11 月以来的拐点。

8
00:00:38,919 --> 00:00:43,159
Now they are much better at handling massive code bases.
现在，他们在处理大量代码库方面做得更好了。

9
00:00:43,159 --> 00:00:47,380
But there are still rules of the road, there are still some good practices, which allow
但仍然有交通规则，仍然有一些好的做法，可以让

10
00:00:47,380 --> 00:00:49,880
you to be successful as a large team.
作为一个大团队，您将取得成功。

11
00:00:49,880 --> 00:00:51,360
And I'd like to go through them with you now.
我现在想和你们一起回顾一下。

12
00:00:51,360 --> 00:00:54,360
And I should warn you that in most cases, I'm really stating the obvious here, I feel
我应该警告你，在大多数情况下，我确实在这里陈述了显而易见的事情，我觉得

13
00:00:54,360 --> 00:00:58,439
like by this point in the course, you already know this stuff pretty well.
就像课程中的这一点，您已经非常了解这些东西了。

14
00:00:58,439 --> 00:01:03,279
We're basically talking about focusing on the top half of those kind of six ways of
我们基本上讨论的是关注这六种方式的上半部分

15
00:01:03,279 --> 00:01:11,360
doing things on the yellow on the 2025 techniques more than the purple 2026 crazy techniques.
办事上黄色2025技术比紫色2026技术更加疯狂。

16
00:01:11,360 --> 00:01:19,559
So first of all, invest time in your agents.md or your cloud.md in your documentation, which
因此，首先，在文档中投入时间在agents.md或cloud.md上，这

17
00:01:19,559 --> 00:01:24,680
is disclosed progressively only as you get to the subdirectories.
仅当您进入子目录时才会逐渐公开。

18
00:01:24,680 --> 00:01:31,559
Make sure that at every level at every subdirectory, there is great documentation, that it reflects
确保在每个子目录的每个级别都有很好的文档，它反映了

19
00:01:31,559 --> 00:01:37,160
the interface, it reflects what an agent would need to know in order to work within this
界面，它反映了代理需要知道什么才能在此范围内工作

20
00:01:37,160 --> 00:01:41,160
directory, this folder, without having to read all the files.
目录，这个文件夹，无需读取所有文件。

21
00:01:41,160 --> 00:01:48,800
So it should be like really good, tight documentation that reflects the package and what's needed
所以它应该是一个非常好的、紧凑的文档，反映了包和需要什么

22
00:01:48,800 --> 00:01:51,400
to be known as soon as one goes inside it.
一进去就知道。

23
00:01:51,400 --> 00:01:55,800
And then, you know, making sure that it that it is at the right level of detail, not so
然后，你知道，确保它处于正确的细节水平，而不是这样

24
00:01:55,800 --> 00:02:01,000
much detail that it consumes context, but enough so that the right core functions are
它消耗了上下文的很多细节，但足以使正确的核心功能得以实现

25
00:02:01,000 --> 00:02:03,160
called in that package.
在那个包中调用。

26
00:02:03,160 --> 00:02:04,160
That is the trick.
这就是窍门。

27
00:02:04,160 --> 00:02:06,040
And that takes time and effort.
这需要时间和精力。

28
00:02:06,040 --> 00:02:08,639
You can get of course, Cloud Code to write this for you.
当然，您可以使用 Cloud Code 来为您编写此内容。

29
00:02:08,639 --> 00:02:11,800
But then you need to eyeball it and make sure you're satisfied with it.
但随后您需要仔细观察并确保您对此感到满意。

30
00:02:11,800 --> 00:02:18,399
Do a couple of rounds of reviews, invest time in your agents.md, it will pay dividends.
进行几轮审查，在您的代理上投入时间。md，它会带来回报。

31
00:02:18,399 --> 00:02:23,559
And also project documentation for agents is what it's all about.
代理的项目文档也是它的全部内容。

32
00:02:23,559 --> 00:02:30,039
If you have a document that you tag with the at sign, then that gets inserted into in entirety
如果您有一个带有 at 符号标记的文档，那么该文档将被完整插入

33
00:02:30,039 --> 00:02:34,240
into that outer document, which is not normally what you want.
到外部文档中，这通常不是您想要的。

34
00:02:34,240 --> 00:02:38,759
Better is to describe what a document does and then put a link to it.
更好的方法是描述文档的用途，然后添加指向该文档的链接。

35
00:02:38,759 --> 00:02:44,759
Because then Cloud Code or the other coding agent can decide, does it need to know about this document?
因为 Cloud Code 或其他编码代理可以决定，它是否需要了解此文档？

36
00:02:44,759 --> 00:02:47,000
And if so, it will read it.
如果是这样，它就会读取它。

37
00:02:47,000 --> 00:02:52,399
So structuring your documents to be summarizing, and then to be pointing to more detailed documents
因此，构建文档时要先进行总结，然后指向更详细的文档

38
00:02:52,399 --> 00:02:55,320
so that an agent can navigate properly.
以便代理可以正确导航。

39
00:02:55,320 --> 00:03:01,199
That is a key to success with big code bases and taking time to get that documentation
这是成功使用大型代码库并花时间获取文档的关键

40
00:03:01,199 --> 00:03:04,800
and making sure that it's up to date as changes happen.
并确保在发生变化时它是最新的。

41
00:03:04,800 --> 00:03:08,679
Always make sure there's a step when documents are revised and updated.
始终确保文档修改和更新时有一个步骤。

42
00:03:08,679 --> 00:03:16,600
And then having a consistent strategy for how you will work as a team using coding agents.
然后就如何使用编码代理作为一个团队工作制定一致的策略。

43
00:03:17,199 --> 00:03:22,520
So for example, if you want to use the GitHub approach where you will tag Claude, then have
例如，如果您想使用 GitHub 方法来标记 Claude，那么

44
00:03:22,520 --> 00:03:26,000
that be the policy, have that be the way that you're going to work as a team.
这就是政策，这就是你们团队合作的方式。

45
00:03:26,000 --> 00:03:30,080
If everyone's approaching it a bit differently, things can become a complete muddle.
如果每个人的处理方式都不同，事情就会变得一团糟。

46
00:03:30,080 --> 00:03:32,160
You're not sure who's following what process.
您不确定谁遵循什么流程。

47
00:03:32,160 --> 00:03:34,500
Who is it that's putting tickets in JIRA?
谁在 JIRA 中存票？

48
00:03:34,500 --> 00:03:36,899
And then you're using one flow for this.
然后您为此使用一个流程。

49
00:03:36,899 --> 00:03:41,160
Who is it that's using the GitHub actions and tagging Claude?
是谁在使用 GitHub 操作并标记 Claude？

50
00:03:41,160 --> 00:03:47,759
So you want to have one consistent flow, one agreed process that everyone follows.
因此，您希望拥有一种一致的流程，一种每个人都遵循的商定流程。

51
00:03:47,759 --> 00:03:51,119
And if you're going to use plugins, which makes a lot of sense, like the FeatureDev
如果您要使用插件，这很有意义，例如 FeatureDev

52
00:03:51,119 --> 00:03:55,720
plugin that I guess we used a couple of weeks ago now, or a week ago, then have that be
我想我们几周前或一周前使用过的插件，那么就可以了

53
00:03:55,720 --> 00:04:01,679
something that you all agree to and you rally around and is part of your project process.
你们都同意并团结起来的事情，并且是项目过程的一部分。

54
00:04:01,679 --> 00:04:05,240
And that way you'll have common, you'll have consistency across the project.
这样你就会在整个项目中拥有共同点和一致性。

55
00:04:05,240 --> 00:04:10,039
And also everyone knows when you're going to order a new feature, what's the right way to approach it.
而且每个人都知道您何时要订购新功能，以及实现它的正确方法是什么。

56
00:04:10,039 --> 00:04:14,160
So when it comes to choosing things to add on for your project, I would focus on plugins
因此，当谈到为您的项目选择要添加的内容时，我会关注插件

57
00:04:14,160 --> 00:04:15,960
first and foremost.
首先也是最重要的。

58
00:04:15,960 --> 00:04:21,160
Add the right plugins, like maybe the code simplification and the FeatureDev and a few
添加正确的插件，例如代码简化和 FeatureDev 等

59
00:04:21,160 --> 00:04:23,279
others that make sense for your project.
其他对您的项目有意义的内容。

60
00:04:23,279 --> 00:04:29,880
When it comes to building specialized functionality for coding agents to use on your project,
当涉及到为编码代理构建在项目中使用的专用功能时，

61
00:04:29,880 --> 00:04:34,760
I recommend focusing on skills as a thing that makes so much sense right now.
我建议关注技能，因为它现在非常有意义。

62
00:04:34,760 --> 00:04:40,040
Develop skills, special skills that make sense for your project, how common things
培养技能，对你的项目有意义的特殊技能，常见的事情

63
00:04:40,040 --> 00:04:41,959
should work in your project.
应该在你的项目中工作。

64
00:04:41,959 --> 00:04:47,679
An example that's a bit of an obvious example might be the Cerebras skill that we wrote.
一个比较明显的例子可能是我们编写的 Cerebras 技能。

65
00:04:47,679 --> 00:04:52,720
If you particularly want to use that approach for LLM inference in your project, then build
如果您特别想在项目中使用该方法进行 LLM 推理，那么构建

66
00:04:52,720 --> 00:04:53,720
that out as a skill.
作为一项技能。

67
00:04:53,720 --> 00:04:56,119
But that's a bit of a bitty thing to mention.
但这是一件值得一提的小事。

68
00:04:56,119 --> 00:05:00,640
I'm really thinking of bigger skills you might want your agent to know, ways in which it
我真的在考虑您可能希望您的代理人了解的更重要的技能，以及它的方式

69
00:05:00,640 --> 00:05:05,920
has to understand the frameworks that you're using on your project, and making sure that
必须了解您在项目中使用的框架，并确保

70
00:05:05,920 --> 00:05:10,880
that's something that has a special skill that is domain-specific.
这是具有特定领域特殊技能的东西。

71
00:05:10,880 --> 00:05:14,880
If for example you were using a particular technique for market data that mattered, then
例如，如果您使用某种特定技术来获取重要的市场数据，那么

72
00:05:14,880 --> 00:05:19,440
you might have a skill around that so that it was very clear the right way to use the
您可能拥有这方面的技能，因此非常清楚使用该方法的正确方法

73
00:05:19,440 --> 00:05:22,160
market data API throughout your project.
整个项目的市场数据 API。

74
00:05:22,160 --> 00:05:27,720
So building special skills is a great way to have common standards, common approaches
因此，培养特殊技能是拥有共同标准、共同方法的好方法

75
00:05:27,799 --> 00:05:33,079
that you know will be reinforced for all development across the project by coding agents.
您知道，编码代理将在整个项目的所有开发中加强这一点。

76
00:05:33,079 --> 00:05:38,880
And the next one is stating the obvious, I'm afraid, but having a robust test suite, of
恐怕下一个是显而易见的，但是有一个强大的测试套件，

77
00:05:38,880 --> 00:05:45,000
course, it's like it's always, I mean test-driven development of course is well known as being
当然，就像往常一样，我的意思是测试驱动开发当然是众所周知的

78
00:05:45,000 --> 00:05:50,799
something that is incredibly important for large projects and having 80% unit test coverage
对于大型项目来说非常重要并且具有 80% 的单元测试覆盖率

79
00:05:50,799 --> 00:05:53,679
for a long time has been the kind of gold standard.
长期以来一直是那种金标准。

80
00:05:53,679 --> 00:05:59,359
I sort of suggest, though, being less focused on things like the percentage coverage of
不过，我建议不要那么关注诸如百分比覆盖率之类的事情

81
00:05:59,359 --> 00:06:06,399
your tests, LLMs will often focus on that, and they will often, to a fault, do things
你的测试，法学硕士通常会关注这一点，他们经常会错误地做一些事情

82
00:06:06,399 --> 00:06:12,600
like mocking out, if you're familiar with this, they'll write tests that are very specifically
就像模拟一样，如果您熟悉这一点，他们会编写非常具体的测试

83
00:06:12,600 --> 00:06:16,640
designed to make sure that every path through the code is tested, and that's not really
旨在确保通过代码的每条路径都经过测试，但这并不是真正的

84
00:06:16,640 --> 00:06:21,320
what you want, and you certainly don't want brittle tests that are overly mocked.
你想要什么，你当然不想要被过度嘲笑的脆弱测试。

85
00:06:21,320 --> 00:06:26,320
You want good tests, you want tests that actually test the functionality you're trying
您需要良好的测试，您需要能够实际测试您正在尝试的功能的测试

86
00:06:26,320 --> 00:06:31,040
to build, such that if there's some reimplementation, it doesn't break your tests, but if there's
构建，这样如果有一些重新实现，它不会破坏你的测试，但如果有

87
00:06:31,040 --> 00:06:34,640
something that actually does break the logic, then it breaks the tests.
确实破坏逻辑的东西，然后它破坏了测试。

88
00:06:34,640 --> 00:06:40,640
So making sure that you have, that you give feedback on the testing strategy, maybe as
因此，请确保您对测试策略提供反馈，也许是这样

89
00:06:40,640 --> 00:06:47,440
part of your agents.md, that's very important, and always pushing back if you see a ton of
你的agents.md的一部分，这非常重要，如果你看到大量的，总是会推迟

90
00:06:47,440 --> 00:06:52,160
tests getting put in there just for the sake of testing, mocking everything out and just
测试只是为了测试而放在那里，模拟一切，只是

91
00:06:52,160 --> 00:06:54,640
making sure the different paths through the code are tested.
确保测试代码的不同路径。

92
00:06:54,640 --> 00:06:58,399
I mean, that's what you would do as a human reviewer as well, and that's what you should
我的意思是，这也是你作为人类审稿人会做的事情，也是你应该做的

93
00:06:58,399 --> 00:07:00,880
do particularly with coding agents.
尤其是编码剂。

94
00:07:00,880 --> 00:07:04,440
And there's a lot of overlap here, because really that second item about having consistent
这里有很多重叠之处，因为实际上第二条关于保持一致

95
00:07:04,440 --> 00:07:09,279
workflows and plugins, that should include having the kinds of workflows and instructions
工作流程和插件，应包括各种工作流程和说明

96
00:07:09,279 --> 00:07:14,399
to LLMs that make sure that they write good tests that don't overly mock.
致法学硕士，确保他们编写出良好的测试，但不会过度模拟。

97
00:07:14,399 --> 00:07:20,040
Okay, and then finally, of course, at the end of the day, you are responsible, you are
好吧，最后，当然，归根结底，你是有责任的，你是

98
00:07:20,040 --> 00:07:22,760
accountable for the quality of your code.
对代码的质量负责。

99
00:07:22,760 --> 00:07:26,399
Your coding agent is a tool that is helping you, you and your team.
您的编码代理是一个可以帮助您、您和您的团队的工具。

100
00:07:26,399 --> 00:07:31,399
And so there needs to be a culture of there being a human reviewer, the buck stopping
因此，需要有一种文化，让人工审核员来承担责任

101
00:07:31,399 --> 00:07:37,519
with the human, and a strong culture of rejecting coding agent slop.
与人类合作，以及拒绝编码剂溢出的强烈文化。

102
00:07:37,519 --> 00:07:43,440
If they are writing long, long files that are just going to be hard work to review,
如果他们写的文件很长很长，审核起来会很困难，

103
00:07:43,480 --> 00:07:49,040
if they're being overly defensive, all of these things need to be caught and fixed.
如果他们过度防御，所有这些问题都需要被发现并修复。

104
00:07:49,040 --> 00:07:54,880
And there's definitely this asymmetry problem that is becoming increasingly easy to generate
肯定存在越来越容易产生的不对称问题

105
00:07:54,880 --> 00:08:00,880
tons and tons of code, and the onus is becoming on the human to then take all of this code
大量的代码，人类有责任获取所有这些代码

106
00:08:00,880 --> 00:08:03,600
and have to review it, which is hard work.
并且必须进行审查，这是一项艰苦的工作。

107
00:08:03,600 --> 00:08:05,440
It's very hard work.
这是非常辛苦的工作。

108
00:08:05,440 --> 00:08:10,920
And so making sure that there are disciplined processes in place to make sure that that
因此，确保有严格的流程来确保

109
00:08:10,959 --> 00:08:16,839
human review happens, and making sure that coding agents are challenged to write succinct
进行人工审查，并确保编码人员面临编写简洁的挑战

110
00:08:16,839 --> 00:08:22,079
code that doesn't overwhelm the human reviewer, these are all priorities.
代码不会压垮人类审阅者，这些都是优先事项。

111
00:08:22,079 --> 00:08:26,279
And there's tons of other good advice, and you'll see lots of articles about this stuff,
还有很多其他好的建议，你会看到很多关于这些东西的文章，

112
00:08:26,279 --> 00:08:31,239
and some of the good advice will become no longer relevant very quickly as the models
随着模型的发展，一些好的建议很快就会变得不再相关。

113
00:08:31,239 --> 00:08:32,760
get stronger and stronger.
变得越来越强。

114
00:08:32,760 --> 00:08:37,719
But one of the things that I would certainly add to this list would be to always work with
但我肯定会添加到这个列表中的一件事是始终与

115
00:08:37,719 --> 00:08:39,479
bite-sized chunks.
一口大小的块。

116
00:08:39,479 --> 00:08:44,239
When you're dealing with a massive project, you don't want to tag Claude and say, hey,
当你处理一个大型项目时，你不想标记克劳德并说，嘿，

117
00:08:44,239 --> 00:08:47,320
refactor the whole code base, because you're asking for trouble.
重构整个代码库，因为你是在自找麻烦。

118
00:08:47,320 --> 00:08:51,080
You could do that with a small project, we could do it with our little one that we're
你可以用一个小项目来做到这一点，我们也可以用我们的小项目来做到这一点

119
00:08:51,080 --> 00:08:55,640
working on right now this week, but you can't do that if you've got a massive project with
这周现在正在工作，但是如果你有一个大型项目，你就不能这样做

120
00:08:55,640 --> 00:08:57,679
50 people working on it.
有 50 人参与其中。

121
00:08:57,679 --> 00:09:03,479
So take small bits at a time, let a human or working with something like Claude Code
因此，一次只取一小部分，让人类或使用像 Claude Code 这样的东西

122
00:09:03,479 --> 00:09:09,159
divvy up a big piece of work into smaller steps, and then assign the small steps to
将一项大工作分成较小的步骤，然后将这些小步骤分配给

123
00:09:09,159 --> 00:09:14,719
the coding agent, and have each one be something that is independently, can be specified, can
编码代理，并且让每一个都是独立的、可以指定的、可以

124
00:09:14,719 --> 00:09:17,840
be tested, can be reviewed by a human.
可以进行测试，可以由人类进行审查。

125
00:09:17,840 --> 00:09:21,320
So taking it in small steps, absolutely crucial.
因此，一步一步地采取行动绝对至关重要。

126
00:09:21,320 --> 00:09:23,239
And this is very much an evolving story.
这在很大程度上是一个不断发展的故事。

127
00:09:23,239 --> 00:09:27,280
If you have your own advice from your own experiences, please do post them in Udemy,
如果您根据自己的经历有自己的建议，请将其发布在 Udemy 上，

128
00:09:27,280 --> 00:09:30,239
it'd be great to have a conversation about this.
很高兴能就此进行对话。

129
00:09:30,239 --> 00:09:35,119
If you want to have a quick assignment, one thing that's quite entertaining to do is to
如果你想快速完成任务，一件非常有趣的事情就是

130
00:09:35,119 --> 00:09:40,440
take a big open source project, maybe something from your domain, maybe something that's from
采取一个大型开源项目，也许是来自您的领域的东西，也许是来自

131
00:09:40,440 --> 00:09:45,760
whatever industry vertical you work in, a popular open source platform, and then clone
无论您从事哪个垂直行业，一个流行的开源平台，然后克隆

132
00:09:45,760 --> 00:09:50,479
it, and then try and take on something that's got a to-do, or something like that.
然后尝试去做一些有待办事项的事情，或者类似的事情。

133
00:09:50,479 --> 00:09:57,760
Ask the LLM to find a to-do in the code, and do it, and see how it does, and then work
让LLM在代码中找到一个待办事项，然后执行，看看效果如何，然后开始工作

134
00:09:57,799 --> 00:10:04,000
on things, some of these steps here, work on a more detailed agents.md across all of
在事情上，其中一些步骤在这里，在所有的更详细的agents.md上工作

135
00:10:04,000 --> 00:10:11,239
the entire directory structure, work on perhaps the feature dev plugin, and put some of these
整个目录结构，也许可以使用功能开发插件，然后放置其中一些

136
00:10:11,239 --> 00:10:13,719
things into practice and see how it does.
将事情付诸实践，看看效果如何。

137
00:10:13,719 --> 00:10:18,599
And you could also, as a sort of anti-test, you could try the kind of, hey, refactor the
你也可以，作为一种反测试，你可以尝试那种，嘿，重构

138
00:10:18,599 --> 00:10:22,479
whole code base, and see what happens, simplify everything.
整个代码库，看看会发生什么，简化一切。

139
00:10:22,479 --> 00:10:26,320
You could maybe put that in a Ralph loop and leave it going for 10 iterations, see what
您也许可以将其放入 Ralph 循环中并让它进行 10 次迭代，看看会发生什么

140
00:10:26,320 --> 00:10:29,520
comes out the other end, but it's probably not going to be pretty.
从另一端出来，但可能不会很漂亮。

141
00:10:29,520 --> 00:10:34,320
And that will give you a good sense of what does work and what doesn't work with a massive code base.
这将使您很好地了解在庞大的代码库中什么有效，什么无效。