概览

eyeful 用一组 agent 审查代码改动。规划器给改动分组，每个组需要的专家并行审查。eyeful 找到项目的测试命令时，会让 agent 为每个报告的 bug 写一个测试并运行它；找不到时由 judge 阅读这些发现。结果以审查评论的形式交给人。

现状

• 可用： 本地审查。eyeful review、provider、connect、commit 和桌面应用用你自己的编码 agent 运行完整的工作流（见本地运行）。
• 进行中： 评估。工具已经写好，实验还没有运行（见评估）。云端审查在 GitHub Actions 的 job 里逐个处理 pull request，并在每次审查的沙箱容器里验证（见云端运行）。
• 规划中： L1 工具和专家自己的工具（见路线图）。

局限

• 它不是测试工具。 它为每条发现写一个测试，并运行项目自己的测试套件。它不生成测试套件，也不统计覆盖率（见与 CI 的关系）。
• 它看不到运行中的界面。 usability 专家阅读标记和组件代码，没有任何东西渲染页面（见专家）。
• 没有发现的审查什么都证明不了。 它找到的是模型在改动文件里注意到的东西，同一个改动的两次审查可能不同。
• 它只报告改动引入的问题。 基准提交原本就有的缺陷，以及仓库之外的一切，都不在范围内。
• 它只能证明单元大小的测试能证明的东西。 性能、线程间的时序、需要数据库或浏览器的行为由裁判阅读，从不运行。
• 它不批准也不合并（见一次审查）。
• 本地没有沙箱。 它的 agent 以用户身份运行（见本地运行）。

文档

一次审查怎样进行：

文档	内容
一次审查的全过程	阶段、结果、评审标准、规则、缺口
规划与分拣	CI 检查、分拣、大型改动、计划
层级	谁决定看得多细、预算
专家	每个专家的标准、skill 和工具
证据与验证	验证器、判定依据、裁判、SARIF
审查反馈	评论格式、排序报告、多轮审查
本地运行	桌面端和 CLI、快照、agent、本地风险
常见问题	审查什么、大型改动、文件变化
参考资料	标准和借鉴的项目
原则	作者的八条工作原则

eyeful 怎样测量：评估。

代码怎样构建：

文档	内容
架构	组件、工作流、布局
本地开发	环境搭建、命令、代码生成
代码风格与审查	编码规则，以及改动怎样被审查

云端是独立的一部分。pull request 在自己的沙箱里审查和验证：

文档	内容
云端运行	pull request、agent 与模型、沙箱
Action 程序	组件、布局、生命周期
审查生命周期	触发、谁能发起审查、重新运行
部署	workflow、secrets、模型 provider

所有配置项见配置。接下来做什么：路线图。

每篇文档只负责一个主题，描述代码现在的行为；规划中的工作会标明。英文是源文档，zh/ 是译文。