用 Qodo 生成单元测试并接入 PR 自动审查

Qodo（原 CodiumAI）是一个面向代码质量与开发效率的 AI 开发平台。它把能力分散到开发者已经在用的几个位置：IDE 里的补全与生成、终端里的命令行工具、Git 平台上的拉取请求审查。它主要解决三类问题：写测试太费时间、代码审查容易漏、跨语言改写和命名这类琐事打断思路。适合已经在用 VS Code、JetBrains IDE、GitHub 或 GitLab 的个人开发者与小团队；如果只是想找一个聊天式问答工具，它不是最合适的选择。站内工具页 Qodo 可以作为一个入口参考。

下面按「先装起来、再生成、最后接进流水线」的顺序展开。所有命令与参数都来自公开可查的用法说明，价格、配额、可用模型与套餐差异请以官网当前信息为准。

准备工作

账号与权限

• 一个可用的 Qodo 账号。IDE 插件与 Git 平台集成通常需要在网页端完成授权，把账号与代码托管平台关联起来。
• 如果要使用 PR 审查功能，需要对目标仓库有读取权限，并能安装对应的应用或机器人。团队场景下通常由仓库管理员完成这一步。
• 如果要跑 GitHub Actions 集成，需要对仓库的 Actions 配置有写权限。

本地环境

• Node.js 与 npm。Qodo Command 通过 npm 全局安装，所以 npm 必须在 PATH 中可用。
• 一个已初始化的项目目录，最好已经接入 Git，因为测试生成与覆盖率分析需要读取源码结构。
• 如果要在本地跑覆盖率工具，项目需要能正常构建和运行测试，否则分析阶段会失败。

安装 Qodo Command

终端工具是整条链路的基础，先把它装上：

npm install -g @qodo/command

安装完成后，在终端里直接调用 qodo 相关子命令即可。如果提示找不到命令，检查 npm 的全局 bin 目录是否在 PATH 中。

安装 IDE 扩展

Qodo 支持 VS Code 与 JetBrains 系列 IDE。在对应 IDE 的扩展市场里搜索 Qodo 并安装，然后用账号登录。安装完成后，IDE 侧边栏会出现 Qodo 面板，代码编辑区也能通过命令面板唤起 Qodo Gen。

接入 Git 平台

GitHub 与 GitLab 都支持。接入方式是在平台上安装 Qodo 对应的应用，并授权目标仓库。授权范围建议只勾选需要审查的仓库，避免把无关项目暴露给第三方服务。

操作步骤

第一步：在 IDE 里生成代码

打开需要补全的文件，把光标放到目标位置，唤起 Qodo Gen，然后输入斜杠命令：

/generate

Qodo 会结合当前文件的上下文给出代码建议。除了整段生成，它还提供几项日常用得上的能力：

• 智能代码补全：根据上下文给出补全建议，减少手写样板代码的时间。
• 代码翻译：把一段逻辑从一种语言改写成另一种语言，适合跨语言迁移或参考实现。
• 自动命名：为变量和函数给出命名建议，降低重名与语义不清的问题。
• 代码文档化：为已有代码补充说明性文档。

生成结果需要人工过一遍再接受。上下文感知建议的质量取决于当前文件与相邻代码的可读性，命名混乱的项目里建议质量会明显下降。

第二步：为文件生成测试

打开需要测试的源文件，唤起 Qodo Gen，选择测试相关的组件，然后输入：

/test

Qodo 会引导完成测试生成，覆盖正常路径、边界情况和较少见的异常场景。生成结果通常以测试文件的形式给出，接受后写入项目。建议先在一个小模块上试，确认生成的测试风格与项目现有测试框架一致，再扩大范围。

第三步：用 qodo-cover 在本地跑覆盖率分析

Qodo Cover 是负责回归测试与覆盖率的部分。它既可以作为命令行工具在本地运行，也可以作为 GitHub Actions 的一部分接入 CI/CD。本地运行的基本命令格式是：

qodo-cover run --language <language> --source <source_dir> --tests <test_dir>

三个参数的含义：

• --language：源码使用的编程语言。
• --source：源代码所在目录。
• --tests：测试文件所在目录，生成的测试会写到这里。

一个具体的调用示例：

qodo-cover run --language python --source ./src --tests ./tests

运行后 Qodo Cover 会分析源代码行为，生成补充性的回归测试，用来在代码演进过程中保持功能完整性。第一次运行建议把 --source 指向单个模块目录而不是整个仓库，输出更容易核对。

第四步：把覆盖率分析接进 GitHub Actions

Qodo-Cover 提供了 qodo-cover-pr Action，可以在 PR 创建或更新时自动触发测试覆盖率分析。在仓库的 .github/workflows 目录下新建一个工作流文件，把该 Action 作为步骤引入，并配置触发条件为 pull_request 事件。这样每次提交 PR 或向 PR 追加提交时，流水线都会跑一次覆盖率分析，结果直接反馈在 PR 上。

接入时注意两点：工作流需要能访问源码与测试目录；如果项目本身有构建步骤，要保证 Action 在依赖安装完成之后再执行，否则分析会因为缺少依赖而中断。

第五步：在 PR 中触发代码审查

Qodo Merge 负责拉取请求层面的审查。在 PR 页面中，Qodo 会自动分析变更并给出上下文感知的建议。除了自动分析，也可以通过评论触发命令：

/review

执行后 Qodo 会生成一份代码审查报告，指出潜在问题并对照最佳实践给出修改方向。Qodo Merge 还会根据开发者实际接受的建议动态调整，逐步积累一套贴合该项目的最佳实践知识库，所以用得越久，建议越贴近团队习惯。

第六步：用配置文件定制行为

Qodo 支持通过配置文件（例如 configuration.toml）调整行为，可配置项包括使用的模型、Git 提供商、可用命令等。自定义命令也在这里添加，用来把团队特有的检查流程固化下来。配置文件建议随仓库一起提交，让所有协作者使用同一套规则。

一个完整示例

假设有一个 Python 小项目，目录结构如下：

my-project/
├── src/
│   └── calculator.py
├── tests/
│   └── test_calculator.py
└── .github/
    └── workflows/
        └── qodo-cover.yml

第 1 步，安装命令行工具：

npm install -g @qodo/command

第 2 步，在 IDE 中打开 src/calculator.py，唤起 Qodo Gen，输入 /test，接受生成的测试文件，保存到 tests/ 目录。

第 3 步，在项目根目录运行覆盖率分析：

qodo-cover run --language python --source ./src --tests ./tests

检查 tests/ 下新增的测试文件，确认它们能被现有测试框架识别并执行。

第 4 步，创建 .github/workflows/qodo-cover.yml，把 qodo-cover-pr Action 配置为在 pull_request 事件触发时运行。

第 5 步，提交代码并开一个 PR。流水线跑完后，在 PR 评论区输入 /review，等待审查报告生成。

第 6 步，根据报告修改代码，再次推送。Qodo Merge 会重新分析变更，并根据此前接受的建议调整后续判断。

这条链路跑通之后，日常开发就变成：写代码时用 /generate 补全，写完用 /test 补测试，提交后用 /review 过一遍审查，覆盖率分析交给流水线自动完成。

注意事项

• 数据范围与合规：Qodo 的说明是只分析必要的代码，传输过程使用 SSL 加密，并持有 SOC2 认证。即便如此，涉及敏感业务逻辑的仓库在接入第三方服务前，仍应按所在组织的合规要求评估。
• 生成结果必须复核：测试用例和代码建议都是基于上下文的推断，可能包含与项目约定不符的写法。接受前至少确认测试能跑通、断言有意义。
• 覆盖率不等于质量：Qodo Cover 生成的是回归测试，用于防止功能退化。覆盖率数字上升不代表逻辑被正确验证，关键路径仍建议手写断言。
• 集成范围要收敛：GitHub 与 GitLab 授权时只勾选需要的仓库，避免无关项目被纳入分析范围。
• 配置文件随仓库管理：configuration.toml 里定义了模型、Git 提供商和自定义命令，团队成员应使用同一份配置，否则审查结果会不一致。
• 企业级能力另议：企业团队可用的用户管理、仪表板、SSO 与优先支持属于单独的能力范围，具体包含哪些、如何计费，以官网当前信息为准。
• 价格与配额：套餐、调用额度、模型可用性都会变动，本文不给出具体数字，使用前请查阅官网当前信息。