随着工作中越来越多地使用 AI 生成代码，需要评审的代码规模也越来越大，Code Review 的工作量和时间投入随之增加。每次评审都要理解改动背景、梳理涉及的模块，再判断实现是否合理，逐渐占用了越来越多的精力。
为了缓解自己的评审负担，我尝试让 Claude 帮忙做了一个桌面工具，取名为 Code Meeseeks。项目基于开源的 PR-Agent，把待评审 PR、代码阅读、AI 分析、追问和评论草稿放进同一个客户端，已经开源，也在团队内做了小范围试用。
项目名称来自 Rick and Morty 里的 Mr. Meeseeks，召唤出来帮忙完成一件具体的事情，用在这个评审助手上还挺合适。
需求拆解
业务团队内部、开源社区和商业产品中，已经有不少面向团队的评审工具。在我的需求里，还希望有一个面向个人 Reviewer 的工具，帮助自己理解和核查每次改动，主要考虑以下几点。
🔍 针对 Reviewer 梳理上下文
人工评审的投入，很大一部分发生在开始判断问题之前。面对一个复杂项目的复杂 PR，需要先弄清楚作者想解决什么问题、各处修改之间有什么关系、会影响哪些已有行为。随着代码改动的规模增加，需要理解和核查的内容也越来越多。
每个人对工程和模块的熟悉程度不同，需要补充的背景也不同。熟悉的工程可以依靠记忆，不熟悉的模块则需要沿着代码和调用关系继续查阅。团队级工具很难针对每位 Reviewer 解释改动的目的、模块关系与影响范围，我希望能按自己的理解进度获取说明，逐步建立评审所需的上下文。
🎯 保留个性化的审查重点
不同 Reviewer 有各自的审查重点，例如业务正确性、边界条件、异常处理、性能或兼容性。我希望能够明确自己重点关注的方向，让评审围绕这些问题展开。
规则偏好也需要可以调整，包括代码质量、模块职责、设计风格，以及项目已有的实现约定。个人可以维护这些要求，并按仓库匹配，让评审结合具体项目的规范与自己的关注点进行。
💳 复用 AI 工具订阅额度
我也希望直接利用已有的 AI 工具订阅额度，例如通过本机已安装并登录的 Codex CLI 或 Claude Code 执行评审，沿用对应账户的订阅与可用额度，降低额外接入模型 API 的成本。
因此，模型接入需要支持调用本地 CLI，也保留常用模型 API 与兼容接口，方便按自己的使用条件选择。
💬 在评审过程中持续互动
阅读梳理结果时，可以结合实际代码和已有分析，通过对话继续追问，补充对某个模块、调用关系或特定风险的理解。后续分析能够带上此前的讨论与代码引用，让认知随着审查过程逐步深入。
在个人工作流程中，我也希望保留对评审意见的决策权。AI 先生成候选意见，由自己核对、编辑和取舍，再发布到原有平台。仓库副本、分析记录和评论草稿保存在本机，方便切换任务后继续处理。
对于 Code Review 本身，我也希望有接近 VS Code 的编辑器体验，能够顺畅地阅读 Diff、切换文件、定位代码，并通过流畅的本地搜索查找相关实现，让阅读和核查过程更加连贯。
基于这些需求，我选择桌面客户端作为载体，把 Diff、评审发现与对话放在一起，让个人能够在已有 PR 上完成阅读、分析和意见整理。
本地客户端与模型调用分别配置。
仓库副本和草稿存放在本机，评审上下文会发送给使用者选择的模型服务。实际使用时，需要结合代码的使用范围选择相应的模型与部署方式。
客户端方案也意味着需要维护安装包、本地运行环境和跨平台行为。个人配置分散在各自电脑上，公共规则则需要额外约定共享和更新方式。验证初期，我接受这些维护成本，先把个人评审流程跑通。
设计上的构思
评审能力吸收成熟设计
复用已有的评审能力，是这个项目最核心的设计取舍。 Qodo 贡献给社区的 PR-Agent 已经提供了生成改动说明、分析代码问题和针对 PR 提问等基础能力，Code Meeseeks 直接以此作为评审内核。
Qodo 的使用体验
我此前在 GitHub 上体验过 Qodo 的评审能力，对改动概览、文件变更归类和代码建议的印象比较好。先把改动结构梳理出来，再带着重点阅读代码，确实能减少建立上下文的时间，也成为我选择复用 PR-Agent 的重要依据。
沿用开源评审内核，可以把自己的设计与实现精力集中到 Reviewer 的使用流程上，包括怎样阅读分析结果、继续调查问题，以及确认和发布意见。
评审引擎通过内嵌的 Python 运行时调用，安装包携带所需环境，尽量减少使用者额外准备依赖的步骤。
阅读改动、生成评审意见、继续追问与人工确认的工作流，也沿用 Qodo 的思路。Code Meeseeks 将这套流程组织到本地客户端中，一次常见的使用过程如下。
-
客户端拉取待评审 PR，按仓库组织列表。
-
打开 PR 阅读 Diff，通过
/describe获取改动概览和文件变更说明。 -
运行
/review，查看潜在问题及关联代码位置。 -
选中代码或引用评审建议，通过
/ask继续追问。 -
将确认有价值的意见整理为草稿，编辑后发布到代码平台。
AI 生成的发现先进入候选意见，支持编辑、舍弃和转成评论草稿。最终发表出去的内容，需要经过 Reviewer 确认。自动预评审开启后，可以提前分析待处理 PR，打开客户端时再检查已经准备好的结果。
本地仓库缓存
通过在线仓库接口获取评审上下文时，通常以 PR 的 Diff 为主。需要继续理解未修改的代码、跨文件调用关系或历史变更时，还要额外检索和读取，能够直接提供给评审的上下文比较有限。
因此，客户端在本地缓存仓库镜像，并为 PR 准备对应版本的工作树（worktree）。首次拉取后增量同步，代码阅读和分析可以复用本地仓库。Diff 按提交读取文件内容并在本地计算，也为快速代码检索、历史版本对照和 blame 分析提供基础。
本地仓库同时为后续的上下文交互提供支撑。Reviewer 可以从改动位置继续查找相关实现，使用本地 CLI 的 Agent 也可以结合工作树中的文件进一步核查，让追问能够延伸到 Diff 之外的代码与历史背景。
Agent 设计
基础的改动说明、代码评审和问答沿用 PR-Agent。在此基础上，我主要围绕 Qodo 商用版本的使用体验，以及本地客户端中的上下文交互，补充了几项能力。
🧩 架构图与方案说明
补齐在 Qodo 商用版本中体验到的架构图输出，通过 /describe 生成 Mermaid 图并在客户端渲染，帮助理解改动涉及的模块与关系。
同时补充替代实现思路与推荐理由，方便 Reviewer 对照代码理解设计取舍。
🔎 引用与复评
选中的代码可以连同位置一起带入提问，已有评审建议也可以作为复评上下文。
使用本地 CLI 模式时，进一步结合仓库文件核查疑点，复评结果可用于保留、替换或关闭原有发现。
📚 规则化上下文
用 Markdown 文件维护评审规则，支持按仓库匹配加载，也可结合项目和目标分支限定适用范围，让不同仓库使用各自的规范与检查重点。
同时读取被审仓库的 AGENTS.md，并结合工作规范、长期记忆和个人偏好补充上下文。公共约定可以通过 Git 共享，个人关注点则继续按自己的使用经验调整。
⚙️ 连续任务与执行控制
自然语言请求由 Agent 组织工具调用，保留任务进度和分析记录，允许中途补充方向或停止。
PR 出现新提交时标记代码版本变化，后续对话也能感知原有分析可能已经过时。AutoPilot 可以提前准备评审结果，写操作由运行时授权检查控制。
多轮分析会增加模型调用与等待时间，因此客户端也记录用量，并提供追问数量等策略配置，便于按任务需要调整。
贴近 VS Code 的视觉与交互
界面设计参考了 VS Code 的视觉风格与交互习惯，希望让熟悉代码编辑器的开发者能够更快上手。整体采用 Electron、React 和 TypeScript，代码阅读区域使用 Monaco 编辑器，提供文件树、并排与统一 Diff、代码高亮和行内评论。
布局上，左侧组织待评审 PR 与文件，中间阅读代码改动，右侧查看 AI 分析和继续对话。评审发现可以关联到代码位置，选中的代码可以引用到提问中，草稿也能直接放在对应行附近编辑，让阅读、分析与意见整理衔接起来。
主题、等宽字体与字号可以调整，常用操作通过命令面板和快捷键调用。视觉与操作方式尽量沿用开发者熟悉的习惯，减少切换到评审工具后的适应成本。
截图中展示的是项目自身的一个 PR。右侧给出改动说明和架构关系，左侧可以直接核对 Diff，行内草稿保留在对应代码位置。对于 Reviewer 来说，分析结果与代码之间的往返是否顺畅，会直接影响意见核查的成本。
多代码托管平台支持
工作中的内部协作较多使用本地部署的 Bitbucket Server，GitLab 和 GitHub 也是常见的集成场景。因此，在设计代码平台接入时，我考虑对不同平台统一做适配，让同一套评审流程能够在这些平台上使用。
从个人使用感受来看，Bitbucket 在企业场景下的评审协作体验相对较好。设计 Code Meeseeks 时，也吸收了不少相关的评审交互与协作设计。
Code Meeseeks 接入 GitHub、Bitbucket Server / Data Center 与 GitLab，包括相应的自建实例。平台适配层负责拉取 PR、获取变更、处理评论和评审操作，上层复用代码阅读、AI 分析与草稿处理流程。
各平台在评审状态、行内评论和接口能力上存在差异，客户端根据平台实际提供的能力展示操作。将这些差异集中在适配层，也便于后续分别维护平台接入与评审流程。
工具开放能力
项目还提供可选开启的本地 HTTP API 与配套 CLI，让外部 Agent 或脚本能够发现 PR、读取改动和调用评审能力。桌面阅读与外部工具可以使用同一套本地评审流程，后续有新的集成需求时也能继续复用。
本地 API 默认仅监听本机并要求令牌鉴权，接口按开放的动作范围执行操作。GUI、CLI 与 Agent 各自提供适合的交互入口，底层共用相关服务逻辑，减少不同入口之间的行为差异。
短期使用感受
项目实际运行了一个月，也在团队内做了小范围试用，反馈比较正向，帮助发现了一些细节层面的实际问题。
对我个人而言，比较明显的帮助来自理解改动的效率。先阅读改动概览，再沿着重点文件和候选问题核对，比完全从头建立上下文省力。部分原先需要投入三四十分钟的 PR，现在可以在十分钟以内完成评审。
上述耗时来自早期使用中的个人感受。PR 的规模、熟悉程度与复杂度各不相同，目前还没有做统一口径的量化统计。
有价值的建议仍需要自己回到代码确认。对于成立条件不明确的意见，可以继续追问、补充约束，再决定是否采用。保留编辑和舍弃的空间，让 AI 的输出能够融入已有的评审习惯。
项目做下来，客户端交互也逐渐成为需要持续投入的部分。评论草稿跨页面切换时的保留、行内定位、平台差异，以及新提交后的上下文更新，都关系到评审能否顺畅完成。基本模型调用接通之后，还需要逐步处理这些具体问题。
关于定制工具的想法
从自己的使用体验来看，像 Codex 这样的 Agent，配合能力较强的底层模型和调教良好的 harness，也能获得相当好的 Code Review 效果。模型之外，上下文组织、工具调用和任务执行机制，同样会影响评审过程与结果。
对我来说，开发 Code Meeseeks 的价值，主要是在交互体验上做进一步的定制。将待评审 PR、代码阅读、上下文追问和评论整理组织到熟悉的界面中，让已有的评审能力更贴合自己的工作习惯。
项目开发也让我对 Vibe Coding 的能力变化有了直观感受。年初使用模型和 Agent 时，遇到稍微复杂一些的项目，整体还会觉得力不从心。到了 2026 年中，完成一些中等规模、具有一定复杂度的项目，在我的使用体验里已经绰绰有余。
最后修改于 2026-07-31
