跳转到内容

代码审查

审查标签页审查 diff 而不把它粘贴进对话。对话中显示审查内容的摘要,模型则分批获得按其上下文窗口大小切分的 diff。从侧边栏顶部的拉取请求图标打开,或运行 Code reviewer

本地变更

对打开的 git 仓库,标签页显示当前分支和两个按钮:

  • Review working tree:已暂存和未暂存的变更,附变更文件数。
  • Review branch:此分支相对基准分支的全部变更。twinny 建议远程默认分支或 mainmaster 等常见名称,你也可以输入其他分支。

点击后审查以普通会话的形式流式进入对话,你可以以审查为上下文追问(“展示你会怎么修复第二个问题”)。

GitHub 拉取请求

标签页从 origin 远程检测 GitHub 仓库,按最近更新排序列出其打开的拉取请求并标注草稿状态。修改所有者和仓库名可审查其他项目。选择一个拉取请求即以同样方式审查其 diff。

公开仓库无需令牌。私有仓库以及频繁使用 GitHub API 时,需要在 twinny.githubToken 中设置具有 repo 读权限的个人访问令牌。只会获取拉取请求列表和 diff;twinny 从不向 GitHub 写入。

模型被要求做什么

审查提示(review.hbs)要求特定结构:

  • Summary:两三句话说明修改做了什么以及看起来是否稳妥。
  • Issues:最重要的问题优先,最多八条,每条带严重程度标记(🔴 bug、🟠 风险、🟡 小问题)、文件和大致行号、问题所在和具体修复。
  • Suggestions:可选的改进。
  • Verdict:可以合并、修复后合并,或需要返工。

它被要求引用相关代码,不复述 diff,不要求添加注释或文档。这些都可以在模板中修改;见提示词模板

长 diff

twinny.reviewMaxDiffChars(16,000)是每部分的大小。超过的 diff 在文件边界处切分成多部分,各部分依次审查并在对话中各有标题,最后由各部分生成总结(review-summary.hbs):跨所有部分最重要的问题,最严重的优先,以及一行合并就绪评价。

上下文窗口小的模型可调低;大上下文模型可调高,部分更少、审查更连贯。lock 文件、二进制文件、压缩后的文件和构建产物会被跳过,不占用预算。

获得好的审查

  • 审查用你能跑的最大对话模型。7B 模型能发现明显的 bug;14B、32B 或托管模型在推理修改方面明显更好。
  • 小改动勤审查,胜过大改动偶尔审查。审查 200 行比审查 2,000 行更有用。
  • 追问。diff 摘要留在会话中,所以“第 40 行的空值检查真的需要吗?”是可行的。
  • 审查仅供参考。模型没有运行过代码,除非模板告知,它也不知道你的约定。