大家好，我是娜娜·安杜克瓦伊（Nana Andukquay），我是Kodo的开发者关系负责人。我们以前只是一个AI代码审查平台，但现在我们正在向更广泛的领域扩展，涵盖整个软件开发生命周期中的代码质量和治理。我花了很多时间思考并致力于构建结构化的AI编码流程。
目前大家采用的方式多种多样，我很想在最后听听大家的意见。但今天我想带大家梳理一下这种流程可以是什么样的形态。我有一个仓库，任何人都可以分叉（Fork）。如果你们只记住一件事，那就是让AI分析这个仓库的结构并从中获取建议，看看能如何应用到你们自己的工作流中。
好的，让我们简单介绍一下开头和我自己——娜娜。作为一名开发者关系专家和前全职软件工程师，我对AI在开发领域的应用充满热情。我住在波士顿，这是我的猫皮彭（Pippen）。它是以《指环王》中的霍比特人命名的，而不是那个篮球运动员，因为很多人会问我这个问题。
我在这里就是为了实施结构化的AI编码工作流。我们将使用Kodo平台，大家可以登录。如果你们不想在软件开发生命周期的早期阶段使用它，也可以仅用于PR代码审查。首先，如果需要访问幻灯片，最简单的方法是前往github.com/myame（注：原文为myame或类似拼写），幻灯片应该会在仓库顶部找到，或者链接到我的GitHub/Google Slides。
我给大家一分钟时间操作一下。幻灯片在这里，仓库应该在顶部。如果有人没看到或无法访问请举手示意；如果没问题就竖起大拇指，我就继续往下讲。
那么，代码质量通常会在哪里和如何出现问题呢？在座有多少人正在使用AI进行编码？我猜是所有人。这里有Claude Code的粉丝吗？有CodeX的吗？哇，用CodeX的人手少了一些。我之前以为它最近几个月会火起来。我用Codecraft做过很多事情，但在代理开发生命周期中，代码质量会在哪里出错？答案是 everywhere（处处）。
规划与设计、开发、代码审查、测试、部署，每一个环节都存在潜在故障模式。仅仅为了交付高质量的软件就使用AI编码，风险无处不在。这就是我们需要介入的地方：我们必须通过引导AI编码代理来确保获得我们需要的结果，以便我们对代码质量负责。
我们要能够自信地说：“好的，我可以为这段代码署名。”这意味着它可以顺利通过流水线，或者我有信心让其他开发者审查我的代码。[轻笑] 因此，我坚信我们应该构建以质量驱动的系统。我认为代理工程需要验证环节，而这始于第一点：为你和你的团队定义什么是代码质量。
如果你们是一个开发团队，这一定义必须明确并落地 somewhere（某个地方）。它需要被编码化，这样无论使用什么界面，AI都能提取这些信息并尽力遵守你们制定的代码标准。一旦决定了这些标准的存放位置——无论是在本地特定仓库中，还是在上下文管理层（稍后讨论）——就可以将其分发到不同的界面。
无论是CLI、IDE还是CI工作流，这些标准都应该是可分发的。我们不需要经历所有这些繁琐步骤。我已经解释过，也许我们可以直接操作化我们的上下文。我有一个包含规则、技能和各种内容的仓库，我们要利用它来进行规划、代码生成和审查。
其核心目的是尽早且频繁地验证质量，理想情况下，我们在每个阶段要求代理检查的标准都是相同的。这就是重点所在。哦，这是我的技能库，我有好多啊。那么，我想直接切入我们需要做的事情。首先，让我们进入Kodo质量工作坊——Signal Pay项目（假设大家能看到）。
哦，我调不了音量……让我们看看。好的，这就是我们要去的仓库：Kodo Quality Workshop Signal Pay。这是一个支付应用。我想请大家分叉这个仓库，并告诉我何时完成。然后克隆它。[轻笑] 如果想课后自行练习，自述文件中有所有说明。我将高度依赖我的编码代理在元层面帮我实现这一点。
代码质量工作坊-Signal Pay。在这个仓库中，我们将 walkthrough（逐步演示）编码变更的规划过程。我们要阅读仓库规则以确定哪些规则适用于此次特定的编码变更；使用技能，并确保通过TDD（测试驱动开发）和BDD（行为驱动开发）编写适当的测试。
然后，我们要求编码代理实现代码变更并运行本地门禁（Local Gates）。我们会运行Linter和静态分析，因为我们想要确定性的检查以及AI辅助的良好组合。接着，我们将打开一个拉取请求（Pull Request），让Kodo直接在GitHub上审查我们的PR。
之后，我们将回顾Kodo发现的问题，并利用代理技能自动解决这些问题。[轻笑] 我们在构建什么？这是一个自包含的FastAPI支付API，没有前端界面。因此我们可以专注于后端部分，它就像一个可以在UI中查看的API一样简单。
好的，我们来审视一下仓库结构。我们有一个 agents.md 文件，一个隐藏的 plan（计划）目录、rules（规则）、skills（技能）和 docs（文档）。我们有实际的 API 本身，还有测试。我们也使用 SER Grep 进行静态分析。此外，我们还有像 CI（持续集成）工作流这样的验证过程。[喷鼻息声] 所以，首先我们要在本地运行这个应用。因此，我们将使用 make setup 指令，一旦你克隆了这个仓库。就像我说的，你可以自己跟着做，只需复制粘贴这些指令即可。让我看看……我在哪？
好的，一旦我们完成了那一步，我认为应该是 make run。
好了，现在它正在运行，在本地应该可以访问了。这是我们拥有的支付 API。没什么复杂的，非常简单。嗯，这并不是重点所在，但当应用本地运行时，你应该看到的就是这个界面。
好的。如果你想查看的话，还有一些其他可用的端点。>> [喷鼻息声] >> 现在，你可以选择你的路线：如果你想动手操作或者只是观察。以下是我们将要 walkthrough（逐步讲解）的质量门禁检查点。嗯，有一个完整的设置门控过程，对吧？我们运行这些不同的命令，并且有一个验证指令，这非常重要。所以，你已经在本地仓库中有了这个 working（工作）环境。如果需要帮助，让你的代理修改任何本地内容以确保运行顺畅。下一步我们要做的是使用 Kodo（注：原文为 Kodto/Kodos，推测指代特定工具或拼写变体）。Kodo 的棒之处在于，我们不仅仅是在拉取请求（PR）中运行它。我们希望设置我们的账户与 Kodo 连接，以便它能够摄取这个仓库中已有的技能（skills）和规则（rules）。这对我们至关重要，因为这样我们才能将这些内容作为上下文应用到代码审查阶段，而不仅仅是在编码代理工作或规划时。嗯，就像我说的，你不必这样做，但我们会稍后讲到那部分。[喷鼻息声]
因此，一些重要的标准门控就是规则本身。我们在这个仓库中包含了一些专注于支付 API 的规则，代理的工作是能够判断在何时必须实现你请求我的这些代码更改。我需要确定哪些规则与此相关，以便我遵守它们。所有这些都在这个仓库中，以及用于实现的技能（skills）。嗯，然后我们有规划和测试驱动开发门控。这个仓库中有一个高层计划和一个规划模板，还有一个执行重点计划。这些是非常详细的模板，因为据我所知，你相对越详细、在规划阶段以及代理需要回去阅读和遵循的文档越一致和结构化，它就会更好地遵守规范，并在意识到遗漏了你流程中的某些关键点时进行自我纠正。你想要能够识别什么是预期行为、我将使用哪些技能来实现，所有这些都作为规划模板的一部分存在。
然后我们有本地验证门控：我使用 ruff、pylint、bandit、pytest 和 conventional commits（约定式提交），以提供确定性证据，证明本地进行的更改保留了本地契约。我是将确定性与 AI 结合的大信徒。[喷鼻息声] 最后一个门控是拉取请求审查和修复门控。当我们打开 PR（Pull Request）时，会检查 Kodos 的发现结果，记录修复和延期项，然后我们可以重新运行我们的验证指令来修正那些代码更改。这将是一个完成你自己代码审查循环的过程，而不是仅仅停留在本地通过运行这一步骤就结束。[喷鼻息声] 以下是先决条件：我们需要 git、GitHub 账户、GitHub CLI（命令行界面）、Python、UV、Node.js JS 和 npm，以及你使用的任何编码代理（最好是 CodeEx 或 Cloud Code），然后我们将获取我们的 Kodo 账户。[喷鼻息声]
好的，以下是设置指令。我让你们自己去做那部分。我们将登录到 Kodo 应用。这是 app.codto.ai。就这样。嗯，如果你能在这里登录，你将能够设置连接 GitHub 应用程序到分叉的仓库中。所以是 app.codto.ai。嗯，谁在这里已经有 Codto 账户了？有人吗？好的，太好了。嗯，[喷鼻息声] 所以是的，登录并使用你的 GitHub 电子邮件地址登录。我认为这是最简单的方法。然后你将能够……你会 landing（着陆/到达）让我们看看这里的集成页面或主页，你需要添加一个连接，这将是 GitHub Cloud 的连接。它将引导你完成安装指南。我建议不要像所有仓库那样连接，只连接分叉的 repo（仓库）。它应该列在那里，但如果没看到请告诉我。[喷鼻息声] 所以如果点击 GitHub 和安装指南，连接你的组织。嗯，我已经连接了，但它应该列在这里供你添加。
这只是一个例子。就像我们使用 Kodo 作为示例一样，无论你是否使用 Kodo，你都需要让技能和规则存在于某个地方。理想情况下，如果你在一个团队中工作，它应该在本地仓库之外，除非你有充分的理由将它们包含在那个仓库中并且是隐藏的之类。如果没有的话，外面有一些上下文管理层。我认为 unblocked 是其中之一。这只是一个让你随时管理上下文的单独地方，你应该能够在任何需要的地方拉取下来。这样解释清楚了吗？而我们使用 Codto 只是一个例子。好的，当你登录到 Kodo 门户并将 GitHub 连接到你的分叉仓库后，你需要从 Kodo 门户生成一个 API 密钥。你可以通过点击个人资料中的“API Keys”来做到这一点，并创建一个 API 密钥并命名它。你可能想将这个 API 密钥保存在本地某个地方，以便随后将其添加到 codto.codto /config.json 中。所以先生成 API 密钥，然后通过这个 JSON 结构保存它。同样地，如果你有访问仓库的权限，你可以让你的编码代理为你完成所有这些工作。[喷鼻息声] 我们也有 Kodo 技能（skills）。你可以使用 npx skills add-to-skills。如果你不想用它，这些技能已经在本地仓库中了。>> [喷鼻息声] >> 好的，这是我们要处理的任务：支付工作流安全流程。任务是添加一个小的支付工作流。它要么是一个退款工作流，要么是一个捕获重试处理工作流。你可以选择你想要哪一个，但这故意是一个小的更改，对吧？带有一些……
代码中内置了一些潜在风险，或者说是支付 API 这一敏感环节的问题。支付相关的变更操作往往是 AI 生成的代码看似合理但可能引入问题的地方，所以这是一个很好的例子来带大家一起梳理。Veru 将使用这些文本内容，我们的编码代理会利用这些信息来完成退款工作流或捕获重试处理等任务。在这里你可以复制粘贴代理提示词以开始操作，首先是帮助配置仓库以供研讨会使用，如果你使用的是 Portal 端的 Kodto API Key。接着是本地设置的必要要求。
由于我已经完成了这部分，我将直接复制粘贴安装或验证 Kodto 技能、读取 agents.mmd 文件以及规则，并为此动手任务选择相关的仓库本地规则 ID。我是在 CodeEx 中执行这些操作的……希望我能顺利做到，让我看看。所以我现在处于项目环境中，正在复制粘贴内容，让代理做好开始处理项目的准备，赋予它所需的上下文。
如果大家对当前进度有任何疑问，或者希望我放慢速度或回顾之前的内容，请举手示意。
就在这里，“安装并验证 Kodto 技能”。我们在读取 agents.mmd 文件和规则，然后要求它查看即将实施的动手任务相关的仓库规则 [轻笑]，解释为什么每条规则对即将到来的任务都相关。此外，如果技能可用，我还可以选择将这些规则与 Kodto 获取的规则进行比较，如果你想下载这些技能的话。
好的 [轻笑]，让我们看看它说了什么。我会先基于仓库自身的说明进行操作，在选定规则之前验证本地 Kodto 设置和依赖健康状况。好的，它发现我们处于研讨会项目内部，并且已经识别出我拥有 Kodto 技能。[轻笑] 哦，仓库本地的研讨会技能尚未安装。所以我将运行 repos installer，它只会将已提交的本地技能文件夹复制到代理的技能目录中。
好的，太好了。所以它将处理我们拥有的本地技能。[轻笑] 我将让它运行，然后回到我们当前的位置，也就是设置提示符那里。让我们看看它是否取得了进展。当我们确认代理就绪后，我们将切换到计划模式。
对于这个计划模式，我们指示使用本地研讨会规划技能，将 readme 中的动手任务转化为高层实施计划和构建会话执行计划。然后我们需要读取 agents、规则，并使用任何相关技能来确定约束条件。该计划必须包含实施技能交接内容，即命名第一个实施技能以及接下来将链式运行和执行的测试驱动开发提示词。此时不要编写代码。
我非常推崇计划模式，但如果你不想使用它，系统仍有提示词确保你不会实施任何操作。这花了一些时间……这是因为我把所有验证步骤都设置好了。好吧 [轻笑]，让我们看看结果如何。
[清嗓子] [轻笑] >> 好的。嗯，这花了不少时间来做这件事。
[轻笑] >> 我可能会做捕获重试处理。你呢？>> 嗯，我在想退款流程，但你在哪里告诉它你要做那个呢？>> 呃，它会提示并询问你。>> 好的。>> 嗯，如果没有的话，你可以在提示词中明确说明这一点。你现在进展到哪一步了？[轻笑] >> 好的，太棒了。好吧，终于完成了。验证了仓库说明，运行了安装技能指令或命令。
现在所有本地技能都已拉取下来。以下是为此支付工作流任务选定的仓库本地规则，这些都是在过程中将被考虑的所有规则。>> [轻笑] >> 你知道的，也许我也会和你一起做退款工作流。我将复制粘贴规划提示词并切换到计划模式。[轻笑] 嗯，它应该会问我，但我会说我将处理退款。叫什么来着？退款。[轻笑] 呃，我们开始吧。退款工作流计划。
[轻笑] [轻笑] 好的，让我们看看。所以我将使用仓库本地研讨会任务规划技能和支付项幂等性技能，并将计划基于 agents.mmd、readme 和规则进行 grounding。在这个特定模式下，我只读取和检查文件，不会编写任何代码或计划中的文件。
所以 [轻笑] 现在 CodeEx 正在评估应用程序的当前行为。我们显然还没有实现这一点，但它正在确定需要做什么、代码变更的形状会是什么样……呃，我可能现在就应该深入看看模板，因为 Kodto 正在工作，这样你就可以看到规划模板的样子。所以这里是规划模板。
我真心相信这是一个非常重要的工件，如果你还没有使用结构化模板的话，一定要带走它。我认为计划应该回答：我们要改变什么行为、哪些规则适用、哪些技能会指导代理、哪些测试能证明预期行为，以及在审查之前必须通过什么样的质量门禁。
[轻笑] 它以一个高层计划模板开始，然后是构建会话执行计划。对于这个研讨会，我们期望它的样子大致如下。
这里是模板。我们有摘要、我们要解决的问题、需要担心的任何特定约束，以及技能路由。如果你需要提前规划编码代理在实施过程中预期会依次启动的所有技能，这很有帮助，特别是如果你想使用某种循环或 CodeEx 中的目标来代表你工作而不需要你介入的话。
[轻笑] 我们还有范围、行为场景和验证门禁，失败与恢复规则以及提交计划。这允许编码代理以一种非常结构化的方式处理特定任务，以整洁的方式组织代码使其具有展示性，使用常规提交有序地创建提交，并最终达到可以实际提交拉取请求的状态。一切都像在没有 AI 的时代团队协作时那样井然有序 [轻笑]。
然后是构建执行模板。我发现非常有帮助的一点是拥有对初始状态的文档记录：我们处于哪个分支？当前的本地验证流程是什么？有哪些预期的命令用于确定代码通过或失败？还有对 linter 的任何期望，当然这里指的是实现技能。
交接和执行步骤方面，我希望知道代理了解此过程中代码更改的每一个步骤，并希望它也能确定测试计划是什么。此外还有完成定义或完成说明：你需要确保已为该分支运行所有命令，需要确定哪些内容被推迟了。如果你中途改变了主意，所有这些都在此计划中记录在案。
现在我们有了一个退款工作流研讨会计划。我们有摘要，有关联的仓库规则、高层实施计划和构建会话执行计划。这里还有一些假设。（轻笑）在座有多少人已经到达这一步？好的，很酷。那么我将继续实施这一方案。（轻笑）
在此过程中，我们可以看一些幻灯片。我之前提到的将上下文、规划、代码生成和代码审查操作化，这是我发现在整个软件开发生命周期中保持一致性极其有帮助的。我使用不同代理技能的组合，这取决于我正在处理的仓库、使用的编程语言和框架。
从高层来看，你会看到顶部有一些 Python 技能，如 Pydantic、Pyright 或 Python 类型契约。其中许多技能在网上随处可见，或者你可以让编码代理自行构建它们。还有一些是我从一些知名开发者那里获得的，比如 Aaron Francis 的审计技能：边界审计、漂移审计、名称审计、抽象审计、死代码和错误审计。
我发现这些技能在实施阶段对于简化和提高代码质量极其强大。我不知道他是否公开提供了这些，但如果你能查找、找到它们或让编码代理自行创建，这绝对是朝着正确方向迈出的一步。正如我所说的，尽早并经常执行质量管控。
使用技能和 Qodo 规则的价值之一在于：从上下文管理层拉取这些规则，然后确定哪些规则与任务相关。我坚信随后运行本地代码审查工作流。无论你使用什么工具，无论是 CodeGeeX、Cloud Code 的内置代码审查，还是 Qodo，都要始终运行本地代码审查。
因为总有一些小改动可以在其他开发者看到你的代码之前尽早做出。尽早解决这些问题是值得的，我们试图减少问题浮现的风险。然后我们在 CI 或 Git 提供商中运行自动代码审查，这是默认设置。（轻笑）
当我这样做时，我 walkthrough 了我正在构建的一个开源工具的整个工作流。证明体现在大型 PR（拉取请求）中更改的行数上。我故意让它很大，因为我想测试这个实际工作流本身的质量。在使用 Qodo 进行自动代码审查的超过 900 行代码中，只发现了一个 bug。
那是一个可靠性问题，这很有道理。但这对我来说是一个很好的练习，让我看到这个过程的价值。（轻笑）是的。我希望我能展示一个图表，说明我如何拥有更高层的规划模板：无论我在哪个仓库中，我都期望使用这种计划结构。
在最高层面上有整体代码质量如工程标准，这些适用于任何编程语言；在其之下是针对使用 Python 的仓库的所有技能。你需要根据用例决定什么最相关。但技能的通用性越强，它就需要被更多仓库访问和使用。这说得通吗？
举个例子，让我确保只针对我的仓库进行范围界定。哦，好的。好吧，看看这个：我们在 Qodo 门户中，这是规则部分。因此，在多个仓库之间有一些被推断、摄取并保存在此门户中的规则，它们按类别划分：可访问性、正确性、可维护性、架构和安全性。
它们还按严重程度级别组织。并非每条规则都应以相同的严重程度对待。有些规则足够强，以至于你想阻止合并；另一些则只是良好实践，但如果它们通过并不会造成损害。（轻笑）
是的，这些是规则分类的一些方式。我相信如果希望更细致化，或者让 Qodo 自行推断，你可以将规则限定到特定仓库。你实际上可以设计这个过程来限定这些规则或技能，使它们仅适用于非常特定的仓库。（观众提问：你能重复一下吗？）
我不这么认为。我认为唯一能做的就是在这个仪表板中进行过滤。这是一个很好的问题，我可能会把它带回产品团队进行验证。（观众：这让你想到了什么？）
仓库。对，它们目前按组织级别和仓库级别自然划分。（观众：好问题。）是的。（轻笑）
我猜你知道……（轻笑）我只是好奇。可以这样。很好的问题：规则是如何成为规则的？Qodo 如何确定什么是规则什么不是，因为它看起来很自动化。这取决于你现有的组织方式。
如果你有 literally 在 rules 目录中的编码规则，Qodo 会很容易识别：好的，我在这里看到的每一条规则我都……
我将像大多数情况那样复制并粘贴这些内容，将其摄入到门户中。但会出现一些作为建议显示的规则，这是专门通过阅读或分析实际代码库得出的结果。因此，你可能没有明确地将这些规则写入代码中，但 Qodo 是基于分析整个代码库而注意到的惯例。它不会自动为其创建规则，但会作为建议出现供你审查。这就是生成的内容：你可以编辑所有这些内容，包括好代码示例和坏代码示例，以便非常清楚地向 AI 代理展示什么是好的、什么是坏的。然后你可以定义类别和警告级别。当你对其外观满意后，就可以接受并激活该规则，它将自动应用。
是的，继续。在另一边……那种方式如何？对于 Qodo 来说……嗯，我看到像我要……[喷鼻息声]。我认为在这里它只是拉取本地仓库规则，其中大多数甚至全部都与本研讨会中采取的不同路径相关联。但一般来说，Qodo 的获取规则技能是在与 Qodo 平台的后端对话，这有点像这种代理式的 RAG（检索增强生成）过程，用于确定哪些是真正无关的，并将其过滤掉。是的……[喷鼻息声] 这是一个非常好的问题。
好的，所以计划已实施，我不知道为什么它创建了一个草稿。我喜欢真正的 PR（拉取请求），但没关系，随它去吧。复制链接。好的，“添加退款工作流和质量门禁”。你到了那里吗？嗯，好吧……[喷鼻息声] 太棒了。这里我们有摘要。我打算直接将其变为真正的 PR，因为我希望 Qodo 在不合并拉取请求的情况下审查它。如果 Qodo 已连接到你的仓库，你应该会自动看到弹出以下内容：它将开始分析过程……[喷鼻息声] 当然，我没有查看所有代码，因为我们没有一整天时间来做这个。但你要理解实施这些流程的意义。所以在几分钟内 Qodo 将完成对此代码的分析，我们将提出任何潜在问题并查看它们。作为任何潜在编码问题的结果，我们要运行一个代理技能以自动解决它……[喷鼻息声]
还有其他问题吗？那些真的很好。是的，我有一个问题和随之而来的第二个问题：我在技能中看到它们可以非常通用，比如“尝试代码”，看起来就是这样。我和工程师们争论说这太泛了，现在应该包含在代理的权重中，我认为你应该等到出现问题再说。但为了平息这些争论，拥有像这样的技能数据来证明其真正有用会非常有益。Qodo 提供类似的东西吗？或者你怎么知道这些技能实际上是有价值的，而不仅仅是……嗯，Qodo 只是在摄入技能。它没有评估它们的质量，但有一个工具确实这样做：TeSSL（Tessle），你听说过 TeSSL 吗？TeSSL 是一家专注于技能评估的公司。你可以确定是否有安全问题，或者它是否真的如你预期的那样有效。这是一个我建议用于集成以确定这些内容的工具……谢谢。
好的，PR 摘要已自动生成。我们有了描述和变更图表，显示了图例 API、内存存储中的函数。我们有 API 客户端和 FastAPI 应用以及不同的……让我们看看指向四个不同字段（[喷鼻息声]）的支付退款端点。……嗯，所以我推荐的一件事是我意识到我刚才跳过了验证提示词。所以在完成创建代码更改并进行本地审查的过程后，我们可以运行一个验证提示词以确保一切通过。但由于仓库的设置方式，Codeex 已经自动完成了这一点。但这将是逐步执行该流程的最佳实践……[喷鼻息声] 任何一天 Qodo 都会很棒。[笑声]
好吧，我们可以看看我已经创建的一个 PR。这是一个我没有运行我们刚才讨论的任何过程的 PR。但我通过 Qodo 门户拉入了上下文，这是我之前提到的代码审查中的上下文管理层所高度考虑的事情。Qodo 识别出 Qodo 门户中存在与此实际代码审查相关的规则。我们不再谈论规划或实施，而是专门谈论代码审查。然后它还拉取了与此代码更改相关的技能……[喷鼻息声] 这里有一些需要操作的结果。在我组织内部有一条规则，要求所有 Python 函数都必须附加文档字符串（docstring）。因此，这被显示为规则违规和维护性问题。之所以标记为“需要操作”，是因为我们的工程组织确定这是高严重性的，因为你可以自定义规则的严重程度级别。它不必是阻塞合并的，只需要被解决即可，这由你决定……[喷鼻息声] 这是与其相关的证据：要求所有 Python 函数（我会说是方法）都有文档字符串。是的，是的……[喷鼻息声]
所以这是在代码审查阶段确定的：哪些规则是相关的。可以确定的是，你可以根据规则的严重程度级别来决定此代码分支或 PR 是否会被阻止合并。你可以在 Qodo 门户中配置这一点：如果识别出任何需要操作或高严重性问题，我们将阻止合并，直到你修复它并再次运行代码以验证你是否已解决。关于确保……[喷鼻息声] 嗯，有可能它不会确定其相关规则实际上会……是的。我真的很高兴你提出了这一点，因为这是我们与产品团队讨论过的事情。随着我们接触的越来越多企业客户——特别是在高度监管的行业——他们非常希望以这种方式实现确定性。所以我希望能推动将其变为现实，因为我认为这极其重要。我同意你的看法。
抱歉，是的。修复后需要进行验证，因为情况已经改变。你是指这个吗？对。在我解决这些问题之后呢？是的。我认为这也是最佳实践，以防万一。你永远不知道会发生什么。它是自动完成的吗？嗯……我想这更多取决于你的代理，可能是它来决定是否运行验证。无论如何，你可以提示代理这样做。但总的来说，这取决于你的代理如何响应[轻笑]。最后来看看结果。哦，好的。调用了五个技能。好吧，我们有一个错误、三个规则违规和两个技能洞察。[轻笑] 内存中存储的退款项目效力存在问题。因此，退款支付使用进程本地字典来存储和重放基金结果，这不是持久的持久化存储。我们有相关的代码片段以及证据、规则和以下文件。
这里的重要部分是，你们一定要尝试复制并粘贴这个旨在修复弹出建议的代理提示词。你可以手动处理每个出现的问题，或者运行 Kodto PR 解析器来自动解决。你已经运行过这个技能了吗？我想要一切代码化或重新检查，因为[轻笑]可能会发生其他事情。绝对如此。如果有自动化，再次包含验证部分是很重要的。没错。我认为这是最佳实践，这也是我会做的——或者说是预生成 AI 时代为了谨慎起见的做法。你也希望你的代理这样做。这真是一个很好的观点。[轻笑]
在查看完此 PR 中的所有结果后，我运行了 COD PR 解析器技能。我将它针对拉取请求编号四进行了运行，看到它提取了 COD 已经识别出的所有问题，从严重到高危。结果去哪了呢？哦，好的。它提取了所有的结果，现在我可以决定是逐个审查每个问题，还是为了本次演示的目的自动修复所有问题。如果你想更亲力亲为，与代理一起决策如何制定修复计划，你可以选择“逐个审查每个问题”选项。[轻笑] 自动修复所有。现在让我们看看它的反应。
我将自动修复这六个 codto 问题。接下来会发生什么？好的。你可以看到这里说它将运行验证，并进行提交。如果结构不正确，提交将被自动阻止。但这正是它随后会做的步骤，并通过实际发布回 PR 来采取下一步行动，附上所有修复更改的摘要。从那里开始，PR 就会更新，所有已解决的问题都会被划掉。
我做过使用工作树的操作。你用过吗？是的，嗯……这不是 Kodto 真正处理的事情。我觉得这是编码代理自己处理的东西。不过这是个很好的观点，也是个好问题。在我结束之前还有其他问题吗？是的。[轻笑] 是的，你可以运行代码审查。我这次没做是因为时间飞逝。但你是指 COD 还是你的编码代理？我们要推出一个本地代码审查工作流，它将直接与 Kodto 后端通信。因此，你在拉取请求中拥有的所有代理能力，你也可以在本地拥有并解决。
那是什么？[轻笑] 它是如何审查所有代码的？它克隆仓库。是的，这就是我们在后端做的流程。[轻笑] 只是临时克隆，以便它理解超出代码差异的更广泛变更范围。[轻笑] 非常好的问题。好的，我想我们时间差不多了。所以，[轻笑] 它没能详细过一遍所有内容，但就像我说的，如果你从中带走什么，就拿这个仓库去问你的 AI 一些关于你想实施或练习在本地实施的验证步骤的建议。
我认为这将是一个非常重要的主要步骤，只是自动为你的工作流添加更多结构并考虑任何工具。有一些开源工具有类似于 Kodto 所做的上下文管理层。我想……嗯，那里有一个，但如果你搜索一下，你应该尝试练习将规则、技能和其他工程标准存储在其他地方。无论是什么，都要跨……以便在相关时从工作流的各个阶段拉取这些信息。哦是的，我想叫 Packmind。Packmind.com。[轻笑] 所以如果你想通过不同的规则和类似的东西一致地治理你的 AI 代码，特别是在团队和仓库之间，一定要研究一下这个。[轻笑]
好的。我希望网速更快些，但它没有。所以……我不知道……这从未发生过，但我们就这样了。如果你们有任何问题请告诉我。嗯，我想我接下来几分钟还在这里。谢谢。[掌声] 让我们……是的。我做过了。
我现在处于一个阶段，我不清除上下文，比如让它压缩，而且我没有像三四个月前那样遇到问题。我想是他们取得了进步。我只是没有经历太多的退化。[轻笑] 好的，像压缩……是的，我会的。嗯，但如果我真的觉得有必要，我就创建一个新会话，并可能将之前会话中的一些内容复制粘贴进去。[轻笑] 是的，我们这里有一个巨大的展位。所以……来参观一下我们吧。
嗯，是的，是的。出于安全原因，你们有本地选项吗？是的，我们有像本地部署这样的东西，以及几乎所有你想要的部署选项。因为我们与银行等机构合作，你知道的……还有像英伟达的一些团队这样的公司，别无选择只能这样做。所以我们确实进行了这种集成。谢谢。[轻笑]
让我们看看……哦，在那儿。这是修复摘要。[轻笑] 是的，它做到了。我甚至不知道现在实际几点钟了。解决了多少问题？全部解决。所有问题都已解决。太棒了。好的，谢谢大家。如果有任何问题，我就在外面。[轻笑] [音乐]