每个错误都成为规则：
diffray 如何从您的反馈中学习

产品负责人 Aakash Gupta 完美地总结道："每个错误都成为规则。"团队与 AI 合作的时间越长，AI 就越聪明。

这正是 diffray 构建的理念。今天，我们将向您展示它是如何在底层运作的。

问题：上下文污染扼杀审查质量

在讨论规则之前，我们需要了解 AI 代码审查的主要技术挑战——上下文污染。

Anthropic 的研究表明，LLM 像人类一样，随着上下文窗口的填充而失去焦点。修正不断累积，旁枝讨论堆叠，过时的工具输出仍然存在。结果是可预见的：

JetBrains Research（2025年12月）量化了这一点：代理上下文增长如此之快以至于变得昂贵，但并没有带来显著更好的任务性能。更多上下文 ≠ 更好的结果。

解决方案：具有隔离上下文的专业子代理

Boris Cherny 使用子代理作为"最常见工作流程的自动化封装"。他的理念是：

他的代码审查命令不是使用一个全知的审查者，而是生成多个并行代理，各有不同的职责：

这个对抗层至关重要。次级代理通过结构化的怀疑主义质疑第一轮的发现，消除误报。

用 Cherny 的话说，结果是："找到所有真正的问题，没有虚假的。"

技术原理

当主代理委托给子代理时，会生成一个全新的上下文窗口，仅包含任务描述和相关参数。子代理可以广泛探索——在搜索代码时消耗数万个 token——但只返回一个1,000-2,000 token 的精简摘要。

这在允许深度分析的同时保持了主代理的专注。

在 diffray，我们使用30 多个专业代理，每个都专注于特定领域：安全、性能、代码风格、架构模式等。每个代理在隔离的上下文中运行，只返回实质性的发现。

规则制定：将反馈转化为知识

现在进入主题。子代理解决了上下文问题。但是如何让 AI 从您的修正中学习呢？

CLAUDE.md 模式

在 Claude Code 中，团队在其代码库中维护一个 CLAUDE.md 文件——项目的某种"宪法"。该文件在每次会话时自动加载到上下文中。

但有一个关键限制。HumanLayer 的研究表明，Claude Code 的系统提示已经包含约 50 条指令，而前沿 LLM 只能可靠地遵循总共150-200 条指令。随着数量增加，指令遵循质量均匀下降。

这意味着：你不能简单地倾倒 500 条规则然后期待奇迹。

知识的三个层次

有效的规则在三个层次上编码知识：

## 技术栈
- 后端：Python 3.11、FastAPI、SQLAlchemy
- 前端：React 18、TypeScript、TailwindCSS
- 数据库：PostgreSQL 15

## 为什么我们不使用 ORM 进行复杂查询
历史：ORM 在报告中生成 N+1 查询。
决定：分析用原生 SQL，ORM 仅用于 CRUD。

## 提交前
- 运行 `make lint` — 必须无错误通过
- 运行 `make test` — 覆盖率不能下降

手动方法的问题

手动规则维护可以工作...只要您的团队小而有纪律。但实际上：

diffray 如何自动化规则制定

diffray 颠覆了这个过程。不是手动编写规则，您只需对审查提供反馈。

学习循环

diffray 中的规则类型

实际示例：从烦恼到规则

想象一下：diffray 在您的 PR 上留下评论：

您知道这是一个计划在下个季度重写的遗留模块。现在修复类型将是浪费时间。

您回复："这是遗留代码，类型将在 Q2 重构时处理"

接下来发生什么：

但重要的是：规则不是永久的。过期日期意味着 Q2 之后，diffray 将再次开始检查该目录中的类型。

指标：降低误报率

AI 代码审查有效性的关键衡量标准是误报率。100 条评论中有多少是无用的？

典型的行业基准：

我们如何实现这一目标：

入门：三个步骤

每次互动都会让 diffray 更聪明。一个月后，您将拥有一个个性化的 AI 审查者，比新员工入职后更了解您的约定。

结论：与您的团队一起成长的 AI

"每个错误都成为规则"的理念不仅仅是一个朗朗上口的短语。它是一个架构原则，将玩具工具与生产就绪的解决方案区分开来。

diffray 建立在三个支柱上：

结果：AI 代码审查随着每个 PR 变得更好。不是因为模型更新了，而是因为它从您的团队中学习。