为什么默认情况下挖掘出的规则来得太晚
代码评审是大多数团队执行标准的地方，它通过“返工”来发挥作用。有人用一种方式编写代码，一个曾见过这种方式出错的评审人员指出它，然后代码被重写。知识传递是真实的，但它发生在工作完成之后。
对于人类作者来说，这个循环是可以忍受的——评审人员纠正一次，作者通常就会记住。但对于编写代码的 Agent，这个循环无法闭合。上周写错的 Agent 下周还会以同样错误的方式编写，因为评审中的任何内容都没有成为它所掌握知识的一部分。您需要反复支付返工成本，而不是一次性付清。
Rule Miner 让这一切变得更好，也更可见。更好是因为标准变成了显性的资产，而不是存在于某位资深工程师的脑海中。更可见是因为您现在可以看到评审中不断捕获的问题列表。Qodo 对符合条件的标准有着精确的定义：“仅考虑被开发人员接受并导致代码更改的意见。”每条挖掘出的规则都代表了一次实际落地且反复出现的纠正。
信号权重告诉您这些规则是什么。Qodo“评估每个评审人员对更改代码的所有权，并相应地对他们的意见进行加权，因此规则反映了最熟悉该代码的人员的标准。”循环出现的反馈“会上升为候选规则”，并且“当意见来自对受影响代码拥有强所有权的评审人员时，单条意见也符合条件。”聚类会产生“特定区域的规则，其范围限定在它们所管辖的路径上”。系统还会自我纠正：“一旦规则激活，它生成的被驳回建议会随着时间的推移降低其信号，因此噪音会自行消退。”
That is a well-designed learning loop aimed entirely at the reviewer. The author — increasingly an agent — is not in it.
人们尝试的其他替代方案
根据评审反馈手动编写 AGENTS.md。 有人阅读了三个月的拉取请求，并将约定提炼到一个指令文件中。它起初有效，然后就失效了，因为没有人会重复这个过程。六个月后，该文件描述的是去年春天的标准，而且这种失效是隐蔽的：过期的指令文件看起来与最新的文件一模一样。这就是为什么 Agent 会忽略您的指令文件中提到的漂移问题。
手动将 Qodo 挖掘出的规则复制到指令文件中。 这种方法更好一些，因为源头得到了维护。但在维护方面更糟，因为 Rule Miner 会持续运行——它“每两周继续学习一次，每次运行每个仓库最多生成 5 条新规则”——而您的副本不会。带有手动同步步骤的两个单一事实来源，实际上等于一个事实来源加上一个 Bug。
让评审来捕获它。 这是大多数团队所采用的坦诚的默认方式。对人类来说没问题，对 Agent 来说成本高昂。
假设 Agent 会从代码库中推断出约定。 Agent 擅长匹配可见的局部模式，但不擅长推断禁令。您的代码中没有任何内容写着“在发生那次事故后，我们停止了那种做法”；模式的缺失并不能被解读为一条规则。
解决方案：将挖掘出的规则置于作者面前
步骤 1：了解实际挖掘出了什么，以及在什么窗口期内
在进行任何配置之前，先看看存在什么。挖掘出的规则会显示在 Review Standards 页面的 Rules 选项卡中，“源类型为 Mined Pattern”，这使它们有别于人类编写的规则。如果您的仓库中没有显示任何规则，在认为出现问题之前，请先检查触发条件：首次运行“是在仓库连接到 Qodo 后，在该仓库上开启第一个拉取请求时触发的，而不是在连接时自动触发”，并且规则会在“首次运行后的几个小时内”出现。
有两个边界比数量更重要。
第一个是窗口期。Qodo 指出，“Rule Miner 提取多达约 1,000 个您仓库最近合并的拉取请求的索引窗口，其中可以包括您仓库连接之前的活动”，然后直接说出了重要部分：“这不是您仓库的完整历史记录。”对于一个繁忙的仓库，一千个合并的拉取请求可能只是几个月的时间。您团队建立并成功停止违反的标准——这就是成功的样子——可能完全在这个窗口期之外，恰恰是因为最近没有人需要指出它们。Qodo 直接指出，低产出并非故障：“一个仓库可以非常健康，但仍然只产生几条规则，甚至一条也不产生。”
第二个是激活，它取决于一个日期。Qodo 的文档指出，Rule Miner 默认是启用的，并且“对于自 2026 年 9 月 1 日起开始使用 Qodo 的组织，生成的规则会自动激活”，而“对于在该日期之前加入的组织，生成的规则首先作为建议显示在 Rules > Suggestions 中，以便在执行前进行评审。”这两个设置都是可以更改的——“Mine rules from code review history”和“Auto-approve rule miner suggestions”位于门户配置的 Context 选项卡下的 Review standards 部分——但您处于哪种默认设置决定了挖掘出的规则是已经在影响评审，还是在队列中等待。在做出假设之前，请先进行检查。
步骤 2：安装 Agentic Toolbox 并确认 Get Rules 可达
Agentic Toolbox 是 Qodo 将这些功能置于您已使用的 Agent 内部的机制。它自身的定位是：它“将 Qodo 的代码理解、编码标准和评审功能引入您现有的编码 Agent 中”，并且“不会取代您的编码 Agent，也不需要您直接与 Qodo 交互”。
安装是通过 Qodo 安装端点的一行脚本完成的——他们的文档提供了 macOS、Linux 和 Windows PowerShell 的形式——并且它需要 Node.js 20 或更高版本。在运行脚本之前先阅读它，就像对待任何管道安装（install-by-pipe）一样。关于接下来会发生什么，有两点需要了解：“安装程序会安装该工具箱，并为支持的 Agent 环境配置可用的 Qodo 工具”，以及“您可以在没有 Qodo 帐户的情况下安装 Agentic Toolbox，但在您的 Agent 实际运行任何工具之前，您需要注册或登录 Qodo。”该工具箱和 Get Rules 目前都被记录为 Beta 版。
Get Rules 通过多个接口提供：Claude Code 插件、Codex 插件、Kiro 插件、CLI、Agent 技能，以及适用于“任何兼容 MCP 的客户端或 Agent”的 MCP Server。如果您的团队并非都在使用相同的客户端，那么 MCP 路径是首选，因为它不会将设置绑定到某一个编辑器的插件系统。
在连接到 Qodo 的仓库中，通过询问您的 Agent 哪些规则适用于您即将开始的任务，来确认其是否正常工作。返回的内容应该结合了不同的范围——Qodo 的文档指出 Get Rules “结合了全局规则、特定于仓库的规则和上下文引导”，其常见问题解答（FAQ）也明确指出它“除了特定于仓库的规则外，还包括适用的全局规则”。如果您只看到仓库规则，组织级别的范围可能尚未连接。
值得注意的是它不做什么：“Get Rules 会修改代码吗？不会。Get Rules 为 Agent 提供适用的引导。”它只是一个读取操作。
步骤 3：在您的指令文件中告知何时进行询问
Agent 从不调用的工具就是您没有安装的工具。这是人们常常跳过、然后得出该功能不起作用结论的步骤。
Qodo 的文档对此非常直接：“当编码 Agent 的指令文件中包含 Agentic Toolbox 的指令时，它们可以更有效地使用该工具箱。将 Qodo Agentic Toolbox 指令……添加到您的 Agent 指令文件中，例如 AGENTS.md 或 CLAUDE.md，以帮助 Agent 在其整个工作流中有效地使用该工具箱。”他们为此发布了一个默认模板。
关键的一行是触发器：规则应该在实现开始之前加载，而不是在第一次失败之后。Qodo 的常见问题解答阐明了这一意图——“规则在实现开始之前加载，允许 Agent 在生成代码时使用它们，而不是在评审期间发现问题”——而指令文件条目的意义在于让这成为 Agent 的习惯，而不是您的提醒。将其写为编写代码的前提条件，而不是一个可选的功能。
一个操作细节：工具箱会自行更新。“在交互式使用期间，Agentic Toolbox 会定期检查更新并在后台安装较新版本”，并且默认情况下，它“会将新发布的推荐技能添加到您已安装 Qodo 技能的编码 Agent 环境中”。它“不会覆盖您拥有或已自定义的技能”，这是正确的行为，但工具的覆盖面可能会在您无需进行任何操作的情况下扩大。
在 MemoryLake 中进行设置
Get Rules 闭合了经过代码评审的标准循环。但还有第二类它无法触及的标准，而这一类往往让团队付出最大的代价。
Qodo 自身的框架为您划定了界限。Rule Miner 作用于大约一千个合并拉取请求的索引窗口内“被开发人员接受并导致代码更改的意见”。您团队所做出的、从未以评审意见形式呈现的所有决策都在此范围之外：在会议中做出的架构决策、事故复盘的结论、客户施加的供应商限制、您尝试了两次并因无 diff 记录的原因而放弃的方法。这些都无法作为评审规则来强制执行，而且都不在窗口期内。
MemoryLake 保存了这另一半——这是一个存在于任何仓库或评审平台之外的存储库，任何正在工作的 Agent 都可以通过 MCP 或 API 进行读取，并且它旨在被纠正，而不是悄无声息地过时。
步骤 1：创建 API 密钥
生成一个密钥，并在大约三十秒内发出您的第一次请求。一个密钥即可覆盖您团队使用的每个 Agent 界面，这使得知识不会成为单一平台的专属财产。
步骤 2：上传您的第一批记忆
放入那些已经保存了评审从未见过的决策的文档、图像和文件——复盘报告、架构决策记录，以及每个人都提及但没人重读的设计评审。
步骤 3：连接您的 AI 和 Agent
让 Claude、Codex、OpenClaw 和其他 Agent 能够通过 MCP 或 API 进行访问。结合 Get Rules，Agent 在开始任务时就同时拥有了这两部分：您的评审所强制执行的标准，以及您的评审从未讨论过的决策。
这在实践中改变了什么
评审发现的问题减少了，原因很简单：Agent 停止犯那些您的评审人员一直在捕获的错误，因为在它编写任何内容之前，它就已经被告知了这些错误。Qodo 将此命名为目标——规则“从第一行代码起就作为护栏”。
两周一次的挖掘节奏开始产生复利效应，而不仅仅是累加。新规则会自动到达作者手中，而不需要等待有人去更新指令文件，因此“我们学到了这个”与“Agent 知道这个”之间的差距只是一个挖掘周期，而不是取决于是否有志愿者去更新。
新人入职培训的形式发生了改变。新工程师的 Agent 在第一天就能获得与其他人相同的挖掘出的标准，外加早于挖掘窗口期的决策。这几乎就是“隐性知识”成为一个常用词的全部原因，也是在有人离职时保留 AI 上下文所面临的相同问题。
并且挖掘窗口期不再是一个隐蔽的隐患。一旦较早的决策存在于拉取请求索引之外的某个地方，它们是否从最近的一千次合并中掉出就不再重要了。
挖掘规则和 Agent 端检索的最佳实践
检查您处于哪种默认激活设置。 开启自动批准（Auto-approve on）意味着挖掘出的规则已经开始强制执行；关闭自动批准（Auto-approve off）意味着它们在 Suggestions 中排队。该行为取决于您的组织何时加入。
在批量批准之前，先阅读 Suggestions 队列。 挖掘出的规则反映了评审行为，其中可能包括您不希望作为标准的评审人员个人偏好。
首选 MCP 而不是单一客户端插件。 Get Rules 作为 Claude Code、Codex 和 Kiro 插件以及 MCP 服务器提供。MCP 在更换编辑器后依然适用。
将工具调用设为前提条件。 将其放入 AGENTS.md 中，作为 Agent 在编写代码之前必须执行的操作，而不是它可能会使用的一项功能。
不要手动将挖掘出的规则复制到指令文件中。 Rule Miner 会持续生成；而您的副本不会。应采用检索而不是复制的方式。
结论
Rule Miner 建立在正确的观察之上——即大多数工程标准“仅存在于评审人员的记忆中”——并利用它做了一些有用的事情，将接受的、重复的评审反馈转化为具有合理权重和自我纠正信号的显性规则。差距在于放置的位置。评审标准在评审时运行，当作者是一个不会记住被纠正的 Agent 时，这就是循环中错误的一端。
Get Rules 是解决这一问题的关键，其设置只需三个实际步骤：查看挖掘出了什么以及在什么窗口期内，安装工具箱并确认 Get Rules 在下个季度仍将使用的接口上可达，并在您的指令文件中将该调用设为前提条件，而不是一个可选项。
然后，坦诚地面对窗口期。一千个合并的拉取请求是很多的评审历史，但只是团队所知的一小部分。那些从未转化为评审意见的决策——会议、事故、客户限制、两次失败的尝试——恰恰是人们最常重新解释的内容。这些决策需要有自己的存储库，一旦拥有了存储库，您的评审所强制执行的标准和您的评审从未见过的决策就会同时到达：在第一行代码编写之前。