简体中文
参考资料
eyeful 审查时依据的标准，以及它借鉴的三个项目。
软件质量
- ISO/IEC 25010:2023，Product quality model。专家按它的质量特性划分（见名册）。
代码审查
- Google Engineering Practices：The Standard of Code Review（评论何时阻塞，见评审标准）、What to look for（专家问的问题；每一行都要读）和 How to write comments。
- Conventional Comments。每条评论的格式，以及标签和修饰词的名字（见评论格式）。它是社区约定，只给标签命名，不论证分类。
- M. V. Mäntylä 和 C. Lassenius，“What Types of Defects Are Really Discovered in Code Reviews?”，IEEE TSE，35(3)，2009。评审发现分为功能性缺陷和可演化性缺陷：
note与其他严重度之间的那条线（见评论格式）。 - OASIS，SARIF 2.1.0。发现的保存格式，以及给发现定级的两套刻度：
kind（§3.27.9）和level（§3.27.10）（见类别与严重度）。 - Tenny，Trust Doesn't Live in the Code Review，Raft，2026。审查是一个事件，信任是一种状态；一项检查只有被看到失败过才算数（见局限、多轮审查、tests）。
设计与可维护性
- T. J. McCabe，“A Complexity Measure”，IEEE TSE，1976。圈复杂度。
- W. Stevens、G. Myers 和 L. Constantine，“Structured Design”，IBM Systems Journal，1974。耦合与内聚。
- R. C. Martin，Design Principles and Design Patterns，2000。SOLID。
- M. Nygard，Documenting Architecture Decisions，2011。
正确性与安全
- SEI CERT Coding Standards。
- CWE 和 CWE Top 25。每条正确性和安全发现的弱点类别。
- OWASP Top 10 和 OWASP ASVS。
- OSV 和 CVE。依赖里的已知漏洞。
测试
- E. T. Barr、M. Harman、P. McMinn、M. Shahbaz 和 S. Yoo，“The Oracle Problem in Software Testing: A Survey”，IEEE TSE，41(5)，2015。specified、derived、implicit 和 human 四种测试预言（见判定依据）。
- ISO/IEC/IEEE 29148:2018，Requirements engineering。inspection、analysis、demonstration 和 test（见证据）。
- C. E. Jimenez 等，“SWE-bench: Can Language Models Resolve Real-World GitHub Issues?”，ICLR 2024。fail-to-pass、pass-to-pass，以及
PASSED、FAILED、ERROR三种状态（见验证器）。 - R. Just、D. Jalali 和 M. D. Ernst，“Defects4J”，ISSTA 2014。缺陷与引入它的改动绑定：
introduced关卡。 - C. Zhang 等，“SoK: DARPA's AI Cyber Challenge (AIxCC): Competition Design, Architectures, and Lessons Learned”，arXiv:2602.07666，2026。先证明漏洞存在，再用复现和功能测试验证补丁：正是关卡支撑的两个结论。它是先例，不是关卡的来源。
- N. Alshahwan 等，“Automated Unit Test Improvement using Large Language Models at Meta”，FSE Companion 2024。生成的测试只有能构建、且五次运行结果一致才保留：
runs和not_flaky关卡。 - ISO/IEC/IEEE 29119，Software testing。测试设计技术。
- A. van Deursen、L. Moonen、A. van den Bergh 和 G. Kok，“Refactoring Test Code”，XP 2001。测试坏味道。
- Y. Jia 和 M. Harman，“An Analysis and Survey of the Development of Mutation Testing”，IEEE TSE，2011。
- Martian，“Code Review Bench”，2026，https://github.com/withmartian/code-review-benchmark。离线数据集，以及
match.py运行的裁判。
可用性与无障碍
- W3C，WCAG 2.2 和 WAI-ARIA Authoring Practices Guide。
- J. Nielsen，10 Usability Heuristics for User Interface Design。
- ISO 9241-110:2020，Interaction principles。
- RFC 9457，Problem Details for HTTP APIs，以及 Semantic Versioning 2.0.0。
可读性与文档
- Effective Go、PEP 8 和 Google 风格指南，在项目没有自己的规范时使用。
- Diátaxis。文档的四种类型。
项目
来自 antfu/pulls.review（MIT）。eyeful 运行 @pulls.review/core 给改动分组（见计划），并在终端里先展示它的摘要。另外借鉴了三个想法：
| 想法 | 用在哪里 |
|---|---|
| 在任何模型运行之前先用规则分类文件 | 分拣 |
| 通过索引的副本读取工作区 | 快照 |
| 大型改动一次审查一个范围 | 大型改动 |
来自 umputun/revmux：
| 想法 | 用在哪里 |
|---|---|
| 固定的阶段顺序 | 各个阶段 |
| 合并两行以内的发现并统计来源 | 排序报告 |
| 某一步失败时带着较少的结果继续 | 各个阶段 |
| 把上一轮的发现传给下一轮 | 多轮审查 |
| 把一轮的输入和输出放在一起 | snapshot.json 和 change.diff |
| 每个审查者一个进程 | 每个专家单独运行 |
| 限制同时运行的审查者数量和每次调用的时间 | Agent |
来自 alibaba/open-code-review（Apache-2.0），2026-10-28 一次云端审查用了 58 分钟后对照借鉴：
| 想法 | 用在哪里 |
|---|---|
| 同时最多八个专家或裁判，每次调用最多 15 分钟 | Agent |
| 每次模型请求有时间上限 | agent 与模型 |
与类似工具的比较
| Claude Code ultrareview | revmux | Open Code Review | eyeful | |
|---|---|---|---|---|
| 谁挑选审查者 | 未公开 | 调用者选择一个 profile | 规则匹配文件，每个文件包一个 agent | 规划器给改动分组，Go 按规则挑选 |
| 审查什么 | Bug | profile 的各个视角覆盖的内容 | 缺陷，按每个文件匹配的审查规则 | 设计、功能、安全、测试、可用性、可读性 |
| 怎样验证发现 | 在云端沙箱里复现 | 另一个 agent 阅读代码 | 反思模块重读每条评论，不执行代码 | 验证器运行测试，其余标为 review |
| 反馈 | 发现，不带修复 | JSON 或 Markdown，带 fix 文本 | 行内评论和一条总结 | 排序报告里的 Conventional Comments |
| 在哪里运行 | Anthropic 的云 | 被审查的仓库内 | 用户的机器、CI job 和 IDE 插件 | 用户的机器，或每个 pull request 一个沙箱 |