Okay, so on to the main topic of the day, which is about how you best use these kinds 好的，现在进入今天的主题，即如何最好地使用这些类型
of advanced coding agents if you're working on a large team with a big code base. 如果您在一个拥有庞大代码库的大型团队中工作，则可以使用高级编码代理。
And this is where historically they've been criticized, because things like Cloud Code 这就是历史上他们受到批评的地方，因为像 Cloud Code 这样的东西
work really well with great market data demos like the one you just saw, when there's a 当有一个很棒的市场数据演示时，就像您刚刚看到的那样，效果非常好
nice defined small project, it's building from scratch, it can write the docs. 很好定义的小项目，它是从头开始构建的，它可以编写文档。
Where they can struggle is when they're suddenly inheriting a massive code base. 当他们突然继承庞大的代码库时，他们会陷入困境。
And to be honest, this is less true now, now that we are past the point of inflection from last November. 说实话，现在情况已经不那么正确了，因为我们已经过了去年 11 月以来的拐点。
Now they are much better at handling massive code bases. 现在，他们在处理大量代码库方面做得更好了。
But there are still rules of the road, there are still some good practices, which allow 但仍然有交通规则，仍然有一些好的做法，可以让
you to be successful as a large team. 作为一个大团队，您将取得成功。
And I'd like to go through them with you now. 我现在想和你们一起回顾一下。
And I should warn you that in most cases, I'm really stating the obvious here, I feel 我应该警告你，在大多数情况下，我确实在这里陈述了显而易见的事情，我觉得
like by this point in the course, you already know this stuff pretty well. 就像课程中的这一点，您已经非常了解这些东西了。
We're basically talking about focusing on the top half of those kind of six ways of 我们基本上讨论的是关注这六种方式的上半部分
doing things on the yellow on the 2025 techniques more than the purple 2026 crazy techniques. 办事上黄色2025技术比紫色2026技术更加疯狂。
So first of all, invest time in your agents.md or your cloud.md in your documentation, which 因此，首先，在文档中投入时间在agents.md或cloud.md上，这
is disclosed progressively only as you get to the subdirectories. 仅当您进入子目录时才会逐渐公开。
Make sure that at every level at every subdirectory, there is great documentation, that it reflects 确保在每个子目录的每个级别都有很好的文档，它反映了
the interface, it reflects what an agent would need to know in order to work within this 界面，它反映了代理需要知道什么才能在此范围内工作
directory, this folder, without having to read all the files. 目录，这个文件夹，无需读取所有文件。
So it should be like really good, tight documentation that reflects the package and what's needed 所以它应该是一个非常好的、紧凑的文档，反映了包和需要什么
to be known as soon as one goes inside it. 一进去就知道。
And then, you know, making sure that it that it is at the right level of detail, not so 然后，你知道，确保它处于正确的细节水平，而不是这样
much detail that it consumes context, but enough so that the right core functions are 它消耗了上下文的很多细节，但足以使正确的核心功能得以实现
called in that package. 在那个包中调用。
That is the trick. 这就是窍门。
And that takes time and effort. 这需要时间和精力。
You can get of course, Cloud Code to write this for you. 当然，您可以使用 Cloud Code 来为您编写此内容。
But then you need to eyeball it and make sure you're satisfied with it. 但随后您需要仔细观察并确保您对此感到满意。
Do a couple of rounds of reviews, invest time in your agents.md, it will pay dividends. 进行几轮审查，在您的代理上投入时间。md，它会带来回报。
And also project documentation for agents is what it's all about. 代理的项目文档也是它的全部内容。
If you have a document that you tag with the at sign, then that gets inserted into in entirety 如果您有一个带有 at 符号标记的文档，那么该文档将被完整插入
into that outer document, which is not normally what you want. 到外部文档中，这通常不是您想要的。
Better is to describe what a document does and then put a link to it. 更好的方法是描述文档的用途，然后添加指向该文档的链接。
Because then Cloud Code or the other coding agent can decide, does it need to know about this document? 因为 Cloud Code 或其他编码代理可以决定，它是否需要了解此文档？
And if so, it will read it. 如果是这样，它就会读取它。
So structuring your documents to be summarizing, and then to be pointing to more detailed documents 因此，构建文档时要先进行总结，然后指向更详细的文档
so that an agent can navigate properly. 以便代理可以正确导航。
That is a key to success with big code bases and taking time to get that documentation 这是成功使用大型代码库并花时间获取文档的关键
and making sure that it's up to date as changes happen. 并确保在发生变化时它是最新的。
Always make sure there's a step when documents are revised and updated. 始终确保文档修改和更新时有一个步骤。
And then having a consistent strategy for how you will work as a team using coding agents. 然后就如何使用编码代理作为一个团队工作制定一致的策略。
So for example, if you want to use the GitHub approach where you will tag Claude, then have 例如，如果您想使用 GitHub 方法来标记 Claude，那么
that be the policy, have that be the way that you're going to work as a team. 这就是政策，这就是你们团队合作的方式。
If everyone's approaching it a bit differently, things can become a complete muddle. 如果每个人的处理方式都不同，事情就会变得一团糟。
You're not sure who's following what process. 您不确定谁遵循什么流程。
Who is it that's putting tickets in JIRA? 谁在 JIRA 中存票？
And then you're using one flow for this. 然后您为此使用一个流程。
Who is it that's using the GitHub actions and tagging Claude? 是谁在使用 GitHub 操作并标记 Claude？
So you want to have one consistent flow, one agreed process that everyone follows. 因此，您希望拥有一种一致的流程，一种每个人都遵循的商定流程。
And if you're going to use plugins, which makes a lot of sense, like the FeatureDev 如果您要使用插件，这很有意义，例如 FeatureDev
plugin that I guess we used a couple of weeks ago now, or a week ago, then have that be 我想我们几周前或一周前使用过的插件，那么就可以了
something that you all agree to and you rally around and is part of your project process. 你们都同意并团结起来的事情，并且是项目过程的一部分。
And that way you'll have common, you'll have consistency across the project. 这样你就会在整个项目中拥有共同点和一致性。
And also everyone knows when you're going to order a new feature, what's the right way to approach it. 而且每个人都知道您何时要订购新功能，以及实现它的正确方法是什么。
So when it comes to choosing things to add on for your project, I would focus on plugins 因此，当谈到为您的项目选择要添加的内容时，我会关注插件
first and foremost. 首先也是最重要的。
Add the right plugins, like maybe the code simplification and the FeatureDev and a few 添加正确的插件，例如代码简化和 FeatureDev 等
others that make sense for your project. 其他对您的项目有意义的内容。
When it comes to building specialized functionality for coding agents to use on your project, 当涉及到为编码代理构建在项目中使用的专用功能时，
I recommend focusing on skills as a thing that makes so much sense right now. 我建议关注技能，因为它现在非常有意义。
Develop skills, special skills that make sense for your project, how common things 培养技能，对你的项目有意义的特殊技能，常见的事情
should work in your project. 应该在你的项目中工作。
An example that's a bit of an obvious example might be the Cerebras skill that we wrote. 一个比较明显的例子可能是我们编写的 Cerebras 技能。
If you particularly want to use that approach for LLM inference in your project, then build 如果您特别想在项目中使用该方法进行 LLM 推理，那么构建
that out as a skill. 作为一项技能。
But that's a bit of a bitty thing to mention. 但这是一件值得一提的小事。
I'm really thinking of bigger skills you might want your agent to know, ways in which it 我真的在考虑您可能希望您的代理人了解的更重要的技能，以及它的方式
has to understand the frameworks that you're using on your project, and making sure that 必须了解您在项目中使用的框架，并确保
that's something that has a special skill that is domain-specific. 这是具有特定领域特殊技能的东西。
If for example you were using a particular technique for market data that mattered, then 例如，如果您使用某种特定技术来获取重要的市场数据，那么
you might have a skill around that so that it was very clear the right way to use the 您可能拥有这方面的技能，因此非常清楚使用该方法的正确方法
market data API throughout your project. 整个项目的市场数据 API。
So building special skills is a great way to have common standards, common approaches 因此，培养特殊技能是拥有共同标准、共同方法的好方法
that you know will be reinforced for all development across the project by coding agents. 您知道，编码代理将在整个项目的所有开发中加强这一点。
And the next one is stating the obvious, I'm afraid, but having a robust test suite, of 恐怕下一个是显而易见的，但是有一个强大的测试套件，
course, it's like it's always, I mean test-driven development of course is well known as being 当然，就像往常一样，我的意思是测试驱动开发当然是众所周知的
something that is incredibly important for large projects and having 80% unit test coverage 对于大型项目来说非常重要并且具有 80% 的单元测试覆盖率
for a long time has been the kind of gold standard. 长期以来一直是那种金标准。
I sort of suggest, though, being less focused on things like the percentage coverage of 不过，我建议不要那么关注诸如百分比覆盖率之类的事情
your tests, LLMs will often focus on that, and they will often, to a fault, do things 你的测试，法学硕士通常会关注这一点，他们经常会错误地做一些事情
like mocking out, if you're familiar with this, they'll write tests that are very specifically 就像模拟一样，如果您熟悉这一点，他们会编写非常具体的测试
designed to make sure that every path through the code is tested, and that's not really 旨在确保通过代码的每条路径都经过测试，但这并不是真正的
what you want, and you certainly don't want brittle tests that are overly mocked. 你想要什么，你当然不想要被过度嘲笑的脆弱测试。
You want good tests, you want tests that actually test the functionality you're trying 您需要良好的测试，您需要能够实际测试您正在尝试的功能的测试
to build, such that if there's some reimplementation, it doesn't break your tests, but if there's 构建，这样如果有一些重新实现，它不会破坏你的测试，但如果有
something that actually does break the logic, then it breaks the tests. 确实破坏逻辑的东西，然后它破坏了测试。
So making sure that you have, that you give feedback on the testing strategy, maybe as 因此，请确保您对测试策略提供反馈，也许是这样
part of your agents.md, that's very important, and always pushing back if you see a ton of 你的agents.md的一部分，这非常重要，如果你看到大量的，总是会推迟
tests getting put in there just for the sake of testing, mocking everything out and just 测试只是为了测试而放在那里，模拟一切，只是
making sure the different paths through the code are tested. 确保测试代码的不同路径。
I mean, that's what you would do as a human reviewer as well, and that's what you should 我的意思是，这也是你作为人类审稿人会做的事情，也是你应该做的
do particularly with coding agents. 尤其是编码剂。
And there's a lot of overlap here, because really that second item about having consistent 这里有很多重叠之处，因为实际上第二条关于保持一致
workflows and plugins, that should include having the kinds of workflows and instructions 工作流程和插件，应包括各种工作流程和说明
to LLMs that make sure that they write good tests that don't overly mock. 致法学硕士，确保他们编写出良好的测试，但不会过度模拟。
Okay, and then finally, of course, at the end of the day, you are responsible, you are 好吧，最后，当然，归根结底，你是有责任的，你是
accountable for the quality of your code. 对代码的质量负责。
Your coding agent is a tool that is helping you, you and your team. 您的编码代理是一个可以帮助您、您和您的团队的工具。
And so there needs to be a culture of there being a human reviewer, the buck stopping 因此，需要有一种文化，让人工审核员来承担责任
with the human, and a strong culture of rejecting coding agent slop. 与人类合作，以及拒绝编码剂溢出的强烈文化。
If they are writing long, long files that are just going to be hard work to review, 如果他们写的文件很长很长，审核起来会很困难，
if they're being overly defensive, all of these things need to be caught and fixed. 如果他们过度防御，所有这些问题都需要被发现并修复。
And there's definitely this asymmetry problem that is becoming increasingly easy to generate 肯定存在越来越容易产生的不对称问题
tons and tons of code, and the onus is becoming on the human to then take all of this code 大量的代码，人类有责任获取所有这些代码
and have to review it, which is hard work. 并且必须进行审查，这是一项艰苦的工作。
It's very hard work. 这是非常辛苦的工作。
And so making sure that there are disciplined processes in place to make sure that that 因此，确保有严格的流程来确保
human review happens, and making sure that coding agents are challenged to write succinct 进行人工审查，并确保编码人员面临编写简洁的挑战
code that doesn't overwhelm the human reviewer, these are all priorities. 代码不会压垮人类审阅者，这些都是优先事项。
And there's tons of other good advice, and you'll see lots of articles about this stuff, 还有很多其他好的建议，你会看到很多关于这些东西的文章，
and some of the good advice will become no longer relevant very quickly as the models 随着模型的发展，一些好的建议很快就会变得不再相关。
get stronger and stronger. 变得越来越强。
But one of the things that I would certainly add to this list would be to always work with 但我肯定会添加到这个列表中的一件事是始终与
bite-sized chunks. 一口大小的块。
When you're dealing with a massive project, you don't want to tag Claude and say, hey, 当你处理一个大型项目时，你不想标记克劳德并说，嘿，
refactor the whole code base, because you're asking for trouble. 重构整个代码库，因为你是在自找麻烦。
You could do that with a small project, we could do it with our little one that we're 你可以用一个小项目来做到这一点，我们也可以用我们的小项目来做到这一点
working on right now this week, but you can't do that if you've got a massive project with 这周现在正在工作，但是如果你有一个大型项目，你就不能这样做
50 people working on it. 有 50 人参与其中。
So take small bits at a time, let a human or working with something like Claude Code 因此，一次只取一小部分，让人类或使用像 Claude Code 这样的东西
divvy up a big piece of work into smaller steps, and then assign the small steps to 将一项大工作分成较小的步骤，然后将这些小步骤分配给
the coding agent, and have each one be something that is independently, can be specified, can 编码代理，并且让每一个都是独立的、可以指定的、可以
be tested, can be reviewed by a human. 可以进行测试，可以由人类进行审查。
So taking it in small steps, absolutely crucial. 因此，一步一步地采取行动绝对至关重要。
And this is very much an evolving story. 这在很大程度上是一个不断发展的故事。
If you have your own advice from your own experiences, please do post them in Udemy, 如果您根据自己的经历有自己的建议，请将其发布在 Udemy 上，
it'd be great to have a conversation about this. 很高兴能就此进行对话。
If you want to have a quick assignment, one thing that's quite entertaining to do is to 如果你想快速完成任务，一件非常有趣的事情就是
take a big open source project, maybe something from your domain, maybe something that's from 采取一个大型开源项目，也许是来自您的领域的东西，也许是来自
whatever industry vertical you work in, a popular open source platform, and then clone 无论您从事哪个垂直行业，一个流行的开源平台，然后克隆
it, and then try and take on something that's got a to-do, or something like that. 然后尝试去做一些有待办事项的事情，或者类似的事情。
Ask the LLM to find a to-do in the code, and do it, and see how it does, and then work 让LLM在代码中找到一个待办事项，然后执行，看看效果如何，然后开始工作
on things, some of these steps here, work on a more detailed agents.md across all of 在事情上，其中一些步骤在这里，在所有的更详细的agents.md上工作
the entire directory structure, work on perhaps the feature dev plugin, and put some of these 整个目录结构，也许可以使用功能开发插件，然后放置其中一些
things into practice and see how it does. 将事情付诸实践，看看效果如何。
And you could also, as a sort of anti-test, you could try the kind of, hey, refactor the 你也可以，作为一种反测试，你可以尝试那种，嘿，重构
whole code base, and see what happens, simplify everything. 整个代码库，看看会发生什么，简化一切。
You could maybe put that in a Ralph loop and leave it going for 10 iterations, see what 您也许可以将其放入 Ralph 循环中并让它进行 10 次迭代，看看会发生什么
comes out the other end, but it's probably not going to be pretty. 从另一端出来，但可能不会很漂亮。
And that will give you a good sense of what does work and what doesn't work with a massive code base. 这将使您很好地了解在庞大的代码库中什么有效，什么无效。