KechuAI

0github：把 PR 链接换个域名，用热力图告诉审查者"哪里值得再看一眼"

AI
TOOL
SECURITY
2026/10/17
·

阅读时间: 大约 8 分钟

0github：把 PR 链接换个域名，用热力图告诉审查者”哪里值得再看一眼”

0github 热力图界面示例：左侧为审查进度、阈值滑杆与文件树，右侧 diff 按关注度着色（来源：Manaflow 开源仓库 heatmap-demo-1.png）

代码审查机器人（PR review bot）这几年已经卷到”自动找 bug”：静态扫描、规则匹配、AI 逐条点评。但 0github.com 换了个提问方式：它不问”这段代码有没有 bug”，而问”这段代码值不值得人再看一眼”。使用方式简单到有点俏皮：把任意 GitHub PR 链接里的 github.com 直接替换成 0github.com，页面就会把整个 diff 用热力图重新着色。本文基于官网说明与其背后的开源仓库 Manaflow，拆解它的思路、流程与自动标注的边界。

一、背景：审查的真正瓶颈不是”找错”，而是”注意力分配”

一个中等规模 PR 往往改动几百行，审查者的时间和注意力是稀缺资源。传统审查机器人输出一串”可能有问题”的评论，审查者仍然要从头读到尾；而真正高风险的改动（硬编码密钥、诡异的加密模式、绕来绕去的复杂逻辑）往往混在大量机械改动里被略过。0github 的切入点正是注意力分配：用模型先通读 diff，把”需要人类多瞄一眼”的位置用颜色标出来，让人把时间花在刀刃上。

二、它是什么

0github 是一个托管式在线服务，背后的热力图（Heatmap）功能开源在 Manaflow 仓库（manaflow-ai/manaflow，一个开源的 Claude Code Web / Codex Cloud / Devin 替代产品）。官网给出三个可直接体验的示例：tinygrad#12999、datasette#2548、cmux#666。它本身不是代码评审机器人，不直接”批准/拒绝”PR，也不往 GitHub 评论区写意见，而是提供一个叠加了关注度颜色的 diff 视图。

三、处理流程

0github 服务端处理流程（本文据官网说明整理）

按官网自述，流程分五步：

  1. 替换域名：用户把 PR URL 中的 github.com 换成 0github.com，无需安装插件或登录；
  2. 克隆到 VM：服务端把目标仓库克隆进一台虚拟机；
  3. 逐 diff 调用模型：为每一处 diff 启动一个 gpt-5-codex 实例进行分析；
  4. 输出结构化 JSON：要求模型输出结构化数据，标注每一行、每一个 token 大概需要多少人工关注；
  5. 渲染热力图：前端解析 JSON，把 diff 行按关注度映射为从浅黄到红的色带，审查者可在左侧用”Should review threshold”滑杆过滤只显示高于某分数的高亮，并按文件树跳转。

界面上还显示”Automated review progress（自动审查进度）“与本次高亮总数（演示图中为 241 highlights）；把鼠标悬停在风险行上会给出提示，例如演示中把 SHA1 is deprecated algorithm（SHA1 是已弃用算法）单独标出。

四、它标注什么：三类典型信号

官网明确举了三类例子，体现它的标注取向：

  • 硬编码密钥（hard-coded secret）：密钥、令牌、口令写进源码；
  • 异常加密模式（weird crypto mode）：少见或不安全的加密套件、哈希算法用法；
  • 复杂/缠绕逻辑（gnarly logic）：圈复杂度高、嵌套深、边界条件绕的代码块。

注意这三类都不等于”确定的 bug”：弃用算法不一定马上出错，复杂逻辑也可能完全正确。0github 只负责”提请注意”，判断权留给人。

五、评测口径与方法说明

官网没有提供准确率、误报率等量化指标，也没有与其他审查工具做对照基准；演示截图取自作者自己的 cmux PR，属于自演示，不构成第三方评测。热力图的分数来自 gpt-5-codex 的主观判断，属于模型启发式打分，不是可复现的静态分析结果。

六、适用与不适用

适合：开源项目维护者快速筛选外部 PR；审查前快速定位高风险段落；对”这次改动里哪里最该花时间”需要一个先验提示的场景。

不适用：把热力图高亮当作”已确认缺陷”直接据此打回；私有仓库（服务端需要克隆仓库，公开链接模式无法访问私有代码）；需要合规留痕、需要可解释规则引擎的安全审计场景。

七、优势与局限

优势：

  1. 零接入成本，换域名即用，不污染原 PR 评论区；
  2. 问题意识从”找 bug”转向”分配注意力”，更贴近人工审查的真实决策；
  3. 阈值滑杆 + 文件树让审查者可以按风险密度跳转，省去通读；
  4. 热力图能力随 Manaflow 开源，可自行审视其实现。

局限/口径：

  1. 判断完全依赖 gpt-5-codex：模型误判、漏判都会直接变成颜色，工具本身不保证正确，也不提供独立于模型的交叉验证；
  2. “值得看”不等于”有错”：高亮可能包含大量误报，低亮区也不代表安全，不能用颜色替代通读；
  3. 隐私边界：公开链接模式下仓库被克隆到服务端 VM，私有代码无法使用，公开仓库也要意识到内容离开本地；
  4. 成本与延迟：逐 diff 启动模型实例，大型 PR 的处理时间与调用成本由服务方承担，公开服务的容量与稳定性无 SLA 承诺；
  5. 无量化评测：官方未公布准确率/召回率，热度分数缺乏校准，不同 PR 之间的颜色深浅不宜直接横比；
  6. 项目较新，托管服务的长期可用性、是否收费、是否保留审查数据均未在官网说明。

八、它意味着什么

0github 代表 AI 辅助代码审查的一个务实分支：不试图替人下结论，而是帮人排优先级。它不会取代评审者，也不会消灭 review 评论，但”先看哪里”这件事本身确实值得被工具化。对维护者而言，把它当作一个”风险导航仪”试用是低成本的；对团队流程而言，仍应把它定位为辅助提示，最终结论与责任仍在人。

参考来源