AI 代码审查中的上下文感知：
智能系统如何理解您的代码库
审查语法的 AI 与理解系统的 AI 之间的区别。上下文感知将代码审查从噪音转变为有用信号。
大多数 AI 代码审查工具孤立地分析差异——它们看到变更但看不到它所在的系统。上下文感知 AI 理解您的架构、依赖关系、编码模式和业务逻辑。这种根本性的差异决定了您获得的是可操作的见解还是通用噪音。
什么是上下文感知？
上下文感知是 AI 理解代码在哪里适配更大系统的能力。上下文感知系统不是孤立地分析一个函数，而是会问：什么调用了这个函数？它依赖什么？代码库遵循什么模式？考虑到数据如何流动，安全影响是什么？
想象一下拼写检查器和编辑之间的区别。拼写检查器发现拼写错误；编辑理解您的论点、受众和意图。上下文感知代码审查是您代码库的编辑。
本地上下文
- • 同一文件中的周围代码
- • 函数签名和类型
- • 变量作用域和闭包
- • 注释和文档
依赖上下文
- • 导入关系
- • 模块边界
- • 第三方库使用
- • API 契约
架构上下文
- • 系统设计模式
- • 数据流路径
- • 服务边界
- • 基础设施约束
历史上下文
- • 此代码的先前更改
- • Bug 模式和修复
- • 团队惯例
- • 审查反馈历史
为什么上下文感知对代码审查很重要
考虑这个常见场景：开发人员添加一个新的 API 端点，它接受用户输入并将其写入数据库。没有上下文感知的工具可能会检查该特定函数中的 SQL 注入——如果代码使用参数化查询，则不会发现任何问题。
但上下文感知系统会追踪数据流：这个输入来自哪里？它在 API 边界是否被验证？它是否经过任何转换层？代码库中是否有其他地方类似的输入处理存在漏洞？
上下文感知 vs 上下文盲分析
UserService.save() 到达数据库。输入在 middleware/validation.ts 的第45行通过 sanitizeInput()，但该函数不清理 XSS——只清理 SQL 注入。鉴于这些数据在管理面板中渲染（AdminPanel.tsx:128），考虑添加 HTML 实体编码。"问题：上下文感知 vs. 上下文倾倒
这里有一个悖论：虽然上下文是必要的，但过多的上下文会破坏 AI 性能。来自斯坦福、Anthropic 和 Google 的研究表明，随着上下文长度的增加，LLM 准确率下降 13.9% 到 85%——即使所有相关信息都存在。
这种现象被称为上下文稀释，意味着简单地将整个代码库倾倒到 AI 的上下文窗口是适得其反的。相关信号会在噪音中丢失。
上下文悖论
AI 需要上下文来做出智能决策，但过多的上下文会导致它"丢失"关键信息。解决方案不是更多上下文——而是更智能的上下文选择。
这就是为什么策划的上下文胜过上下文体量。研究表明，更少但高度相关的文档比大量上下文倾倒表现好 10-20%。关键是提供正确的上下文，而不是所有上下文。
diffray 如何实现上下文感知
diffray 通过多智能体架构解决上下文悖论，每个专业智能体接收为其领域精确策划的上下文——每个智能体从不超过 25K tokens，同时仍然理解整个系统。
多智能体上下文架构
安全智能体
认证流程、输入验证、数据处理、已知漏洞模式
性能智能体
热点路径、数据库查询、内存分配、基准历史
架构智能体
模块边界、依赖图、设计模式、API 契约
每个智能体只看到与其领域相关的上下文——而不是整个代码库的倾倒。
上下文三位一体：感知、策划和抗稀释
有效的 AI 代码审查需要平衡三个相互关联的概念：
延伸阅读
上下文稀释
为什么更多 token 可能意味着更差的 AI 性能。基于研究深入探讨"迷失在中间"现象。
阅读文章策划上下文 vs 体量
研究证明：带有智能体上下文收集的精确检索大大优于上下文倾倒。
阅读文章