Qoder CLI 配 TaoToken：一键 Code Review 的 GitHub Action 配置骨架

1. 为什么要在 GitHub Action 里跑 Qoder CLI 做 Code ReviewQoder CLI 是一个 AI 原生的命令行工具能在终端里直接执行代码生成、理解和审查任务。把它塞进 GitHub Action 之后每个 Pull Request 都会自动触发一次 AI 审查不用人工逐行盯 diff也不用在风格问题上反复拉扯。它和传统 Lint 工具最大的区别是Qoder 会读你的代码变更、结合项目结构给出带业务上下文的意见而不是只匹配规则。这套方案适合谁适合已经在用 GitHub 做协作、PR 数量开始堆积、又不想把审查完全交给静态扫描的团队。你只需要一个 workflow YAML、一份 AGENTS.md 约定文件以及一个统一的模型接入 Key就能让审查流程跑起来。我这次把模型调用统一走 TaoToken 的 API好处是 Key 只配一次Qoder CLI 和其他工具共用同一个入口不用在多个平台之间来回切换。下面按“前置准备 → 配置骨架 → 验证请求 → 排错”的顺序走一遍每一步都给可复制的代码。2. TaoToken 前置拿到统一 Key 并配好环境TaoToken 在这里扮演的是模型调用的统一入口。Qoder CLI 在 Action 里执行审查时需要访问大模型能力我们把这一步指向 TaoToken 的 API 地址Key 通过 GitHub Secrets 注入不写进仓库。第一步打开官网注册并进入控制台官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content在 API Keys 页面创建一个新 Key复制出来。这个 Key 后面会同时用于 Qoder CLI 的模型调用和本地调试。API 的基础地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为 base_url 使用。第二步把 Key 存进 GitHub 仓库的 Secrets。进入仓库 Settings Secrets and variables Actions新建一个 Secret名字建议用TAOTOKEN_API_KEY值就是刚才复制的 Key。这样 workflow 里通过${{ secrets.TAOTOKEN_API_KEY }}引用不会明文暴露。第三步如果你还想在本地先验证一下 Key 是否可用可以配一个环境变量export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api本地验证通过后再推到 GitHub能省掉不少“到底是 Key 问题还是 workflow 问题”的排查时间。3. 可复制配置workflow YAML settings.json AGENTS.md这一节是核心三份文件配齐就能跑。先看 workflow。3.1 .github/workflows/qoder-review.ymlname: Qoder CLI Code Review on: pull_request: types: [opened, synchronize, reopened] permissions: contents: read pull-requests: write jobs: review: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Node uses: actions/setup-nodev4 with: node-version: 20 - name: Install Qoder CLI run: npm install -g qoder/cli - name: Run Qoder Code Review env: TAOTOKEN_API_KEY: ${{ secrets.TAOTOKEN_API_KEY }} TAOTOKEN_BASE_URL: https://taotoken.net/api GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | qoder review \ --repo ${{ github.repository }} \ --pr ${{ github.event.pull_request.number }} \ --config .qoder/settings.json \ --output-language Chinese这里几个点值得说明。fetch-depth: 0是为了让 Qoder 能拿到完整的提交历史做上下文理解时更准。permissions里给了pull-requests: write因为审查结果要以评论形式写回 PR。模型调用的 Key 和 base_url 都通过 env 注入Qoder CLI 会读取这两个变量。3.2 .qoder/settings.json{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, modelName: claude-sonnet-4-5, maxTokens: 8192, temperature: 0.2 }, review: { agentsFile: AGENTS.md, ignorePatterns: [ dist/**, generated/**, *.min.js, *.lock ], maxDiffLines: 500, commentStyle: inline }, output: { language: Chinese, summary: true, riskLevel: true } }provider用openai-compatible因为 TaoToken 的 API 兼容这套协议Qoder CLI 直接按这个格式发请求就行。apiKeyEnv指向环境变量名不把 Key 写死在文件里。maxDiffLines设成 500超过这个行数的 PR 会跳过或只做摘要避免一次审查消耗过多额度。如果你更习惯 TOML 格式等价写法是这样[model] provider openai-compatible baseUrl https://taotoken.net/api apiKeyEnv TAOTOKEN_API_KEY modelName claude-sonnet-4-5 maxTokens 8192 temperature 0.2 [review] agentsFile AGENTS.md maxDiffLines 500 commentStyle inline [output] language Chinese summary true两种格式二选一Qoder CLI 会优先读settings.json找不到再找config.toml。3.3 AGENTS.md定义团队审查规则放在仓库根目录Qoder CLI 会自动加载。这份文件决定了 AI 审查时遵守哪些约定写得越具体误报越少。# 项目代码审查规范 ## 审查重点 - 所有数据库查询必须使用参数化查询禁止字符串拼接 - API 接口必须进行权限验证 - 敏感信息密码、token不得硬编码或记录到日志 - 所有外部输入必须进行验证和清理 - 异步操作必须有错误处理禁止裸 await ## 可以忽略的检查 - 测试文件*.test.js、*.spec.ts的代码重复检查 - 自动生成的文件generated/、dist/的代码风格问题 - Mock 数据文件的复杂度警告 ## 团队约定 - 使用 async/await 而非 Promise.then() - 组件命名使用 PascalCase - 工具函数使用 camelCase - 常量使用 UPPER_SNAKE_CASE这份文件的作用是给 AI 一个“团队规范”的上下文。比如你写了“禁止使用 any 类型”审查时它就会专门盯 TypeScript 里的 any。实测下来把规则写清楚之后评论里关于命名和风格的无效意见明显减少。4. 验证请求触发一次 PR 审查并看结果配置推上去之后怎么确认它真的在工作按下面几步走。第一步新建一个分支改点代码推上去开一个 PR。比如改一个 API 处理函数故意留一个字符串拼接的 SQL// 故意留的问题示例 const query SELECT * FROM users WHERE id userId;第二步PR 创建后进入 Actions 标签页能看到Qoder CLI Code Review这个 workflow 被触发。点进去看日志正常的话会依次输出安装 Qoder CLI、加载 settings.json、读取 AGENTS.md、拉取 PR diff、调用模型、写回评论。第三步回到 PR 页面等一两分钟应该能看到 Qoder 的审查评论。针对上面那个 SQL 拼接它会给出一条 inline 评论指出这违反了 AGENTS.md 里“禁止字符串拼接”的约定并建议改成参数化查询。如果你想在本地先验证模型调用是否通可以跑一条 curlcurl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 OK 即可}], max_tokens: 16 }返回里有正常的choices字段说明 Key 和地址都没问题。这一步能帮你把“模型接入问题”和“workflow 配置问题”分开排查。5. 本篇常见错排查配置过程中容易踩的坑集中在这几个地方对照着查。报错 401 Unauthorized多半是 Secret 名字对不上。workflow 里写的是secrets.TAOTOKEN_API_KEY仓库 Secrets 里也必须叫这个名字大小写敏感。另外确认 Key 没有多余空格复制时容易带上换行。报错 404 或 base_url 拼接错误检查 settings.json 里的baseUrl是不是https://taotoken.net/api不要自己加/v1后缀Qoder CLI 会按协议补全路径。如果手动加了/v1/chat/completions这种完整路径反而会拼出重复段。workflow 跑完但 PR 没有评论先看permissions有没有给pull-requests: write。GitHub 默认的 GITHUB_TOKEN 权限是只读的没显式声明写权限评论就发不出去。另外确认 PR 不是来自 fork 仓库fork 场景下 Secrets 默认不注入需要额外配置。审查意见和团队规范不符检查 AGENTS.md 是否在仓库根目录文件名大小写是否一致。Qoder CLI 默认找根目录的AGENTS.md放在子目录里不会自动加载。如果规则写了但没生效可以在 settings.json 里显式指定agentsFile路径。大 PR 消耗过多额度maxDiffLines设一个合理阈值比如 500。超过阈值的 PR 可以只做摘要不做逐行审查或者加一个前置 step 判断 PR 大小超过就跳过。这样能控制成本也不至于让审查跑太久。模型返回超时maxTokens设太大加上 diff 很长时容易超时。把maxTokens控制在 8192 以内temperature调低到 0.2 左右输出更稳定也更快。6. 把 Key 和审查流程固定下来整套跑通之后日常使用其实就三件事PR 一开Action 自动触发Qoder 读 AGENTS.md 按团队规则审查评论直接落在 PR 里。模型调用统一走 TaoToken 的 APIKey 只在 Secrets 里配一次本地调试和 CI 共用同一个入口。如果你还想在本地终端里直接和模型对话调试 prompt可以用模型对话入口https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content长期跑编码任务或者 Agent 工作流想控制调用成本可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档里有完整的参数说明和更多配置示例https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentKey 管理和新建入口在 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content配好之后下一次开 PR 就能看到 Qoder 的审查评论了。如果评论没出现先按第 5 节的排查顺序走一遍多数问题出在 Secret 名字和 permissions 这两处。