AI 写代码,另一个 AI 找茬。
像拳击陪练一样,互相推动变强——直到代码值得上线。
一句话: 你描述任务,Claude 写方案+代码,Cursor/Codex/GLM 找茬,人类只在关键节点拍板。
Sparring 是 Claude Code 的插件。它给 Claude 配一个"对手"——专门挑毛病的第二个 AI,以"假设有 bug,找到它"的心态审查方案和代码。最多 5 轮,直到双方一致。
- 2026-05 · 🔥 支持智谱 GLM 作为第三个审查后端,配合主/备降级机制;新增 JSON 配置系统(
~/.config/sparring/config.json+.sparring/config.json),支持团队共享;仓库正式更名为sparring(旧workflow命令保留为软链兼容) - 2026-04 · 🎯 新增 Codex CLI 后端 + 后台 review job(长耗时 review 可异步跑)
- 2026-03 · 首发:Claude + Cursor 双 AI 协作 + 最多 5 轮 review 机制;GitHub Issue 驱动工作流(从 Project 看板接任务,讨论自动同步到 Issue 评论)
|
一个 AI 写,另一个 AI 找茬。不是互相夸奖,是像拳击陪练那样互相逼出更好的输出。最多 5 轮,直到双方一致才放行。 |
|
|
内置默认 → 全局 config → 项目 config → 环境变量。API key 放全局(chmod 600),backend 选型放项目(团队共享),临时覆盖走 env。一键 |
从 Project 看板认领 Issue,AI 讨论自动同步到 Issue 评论,完成后开 PR。全程带身份标记(🧠 Claude / 🤖 Cursor / 🧪 Codex / 🌟 GLM),协作过程可追溯。 |
AI 写代码快,但会犯错——幻觉 API、漏掉边界、引入回归。让人逐行 review?不现实。
| 没有 Sparring | 有 Sparring | |
|---|---|---|
| AI 的每个结论 | 直接告诉你 | 先过另一个 AI 审一遍 |
| 漏掉边界情况 | 🤷 发 PR 才发现 | 🛡️ reviewer 在 review 环节抓住 |
| 看起来对但有隐患 | 😬 上线后出事 | 🎯 "假设有 bug 找它" 的视角挑出来 |
| Cursor/Codex 挂了 | ❌ 工作流卡住 | 🔄 自动降级到备用 backend |
| 两个 AI 视角不一致 | — | ✅ 必然至少两种意见,降低盲区 |
效果:AI 产出更可靠,人工 review 更少,心智负担更低。
# 在 Claude Code 里
/plugin marketplace add krislavten/sparring
/plugin install sparring@sparring# 退出 Claude Code 后重新打开
/sparring:setup/sparring:workflow 给登录接口加 rate limiting就这样。Claude 写方案 → Cursor 找茬 → 你确认 → Claude 实现 → Cursor 再找茬 → 你合并。
| 模式 | 命令 | 适用场景 |
|---|---|---|
| 💬 普通 | /sparring:workflow <任务> |
你参与方案讨论,AI 双方自动完成审查,你最后拍板 |
| 🚀 YOLO | /sparring:yolo <任务> |
AI 全自动,你只确认最终提交。小改动 / 明确任务 |
| 🎫 Issue | /sparring:issue <看板URL> [编号] |
从 GitHub Issue 接任务,讨论同步到 Issue 评论 |
你描述任务
↓
┌─────────────────┐
│ Claude 写方案 │
└────────┬────────┘
↓
┌─────────────────┐ CONCERNS
│ Reviewer 挑战方案 │─────────┐
└────────┬────────┘ ↓
↓ APPROVE Claude 修改
↓ (最多 5 轮)
你确认
↓
┌─────────────────┐
│ Claude 写代码 │
└────────┬────────┘
↓
┌─────────────────┐ CONCERNS
│ Reviewer 挑战代码 │─────────┐
└────────┬────────┘ ↓
↓ APPROVE Claude 修复
↓ (最多 5 轮)
你确认并提交
交叉审查原则:Claude 给你任何建议或结论之前,都会先让 reviewer 审一遍。"建议用 Redis 做缓存" → 先让 reviewer 质疑 → 确认或调整 → 再告诉你。
三种 backend,可自由组合主备:
| Backend | 账号 | 特点 | 推荐场景 |
|---|---|---|---|
🤖 cursor |
Cursor 订阅 | 默认后端,gpt-5.5-extra-high |
日常主力 |
🧪 codex |
OpenAI 订阅 | Codex CLI,reasoning 可调 | Codex 额度充足 |
🌟 glm |
智谱按量付费 | 国产、API key 就能用 | 降级兜底 / 无订阅 |
主 backend 调用失败(超时 / 网络错 / CLI 异常)时自动切到备,工作流不阻塞:
⚠ 主 backend Cursor Agent 调用失败,降级到 GLM...
三种典型组合:
四层优先级(低→高):内置默认 → 全局 → 项目 → 环境变量。
sparring config init # 生成 ~/.config/sparring/config.json(chmod 600,存 api_key)
sparring config init project # 生成 .sparring/config.json(团队共享,不放 key)
sparring config show # 看合并后的配置(key 自动掩码)
sparring config get glm.api_key # 取单值(敏感字段掩码)全局配置 ~/.config/sparring/config.json(含 api_key,不入库):
{
"review": {
"backend": "cursor",
"fallback": "glm",
"timeout": 60,
"retries": 1
},
"glm": {
"api_key": "<id.secret>",
"model": "glm-5.1"
}
}项目配置 .sparring/config.json(默认入库,团队共享 backend 选型):
{
"review": {
"backend": "cursor",
"fallback": "glm"
}
}
⚠️ 项目配置不要填 api_key。它会跟着 git 进仓库暴露给所有协作者。api_key 只放全局 config(chmod 600)或SPARRING_GLM_API_KEY环境变量。
环境变量覆盖(SPARRING_* 主推,WORKFLOW_* 兼容别名):
export SPARRING_REVIEW_BACKEND=glm # → review.backend
export SPARRING_GLM_API_KEY=<id.secret> # → glm.api_key
export SPARRING_REVIEW_TIMEOUT=120 # → review.timeout| key | 默认 | 说明 |
|---|---|---|
review.backend |
cursor |
主后端:cursor / codex / glm |
review.fallback |
null |
备后端(可选) |
review.timeout |
60 |
单次调用超时秒数 |
review.retries |
1 |
失败后重试次数(共尝试 retries+1 次) |
cursor.model |
读 agents/cursor.md |
Cursor 模型 |
codex.model |
读 codex config | Codex 模型 |
codex.effort |
null |
none|minimal|low|medium|high|xhigh |
codex.home |
/tmp/workflow-codex-home-<user> |
Codex 本地状态目录 |
glm.api_key |
必填 | 申请 |
glm.model |
glm-5.1 |
智谱模型 |
glm.thinking |
disabled |
开 enabled 质量更高但慢 |
glm.max_tokens |
8192 |
开 thinking 时建议调到 65536 |
glm.temperature |
0.3 |
review 场景不需要太高 |
glm.api_base |
官方 URL | 可换自建网关 |
完整清单随时用 sparring config show 查看。
sparring verify # 检查主/备 backend 连通性 + 模型 + key 掩码给团队用的。通过 GitHub Issues + Project 看板管理:
/sparring:issue https://github.com/orgs/your-org/projects/3 106自动完成:认领 Issue → 看板「进行中」→ AI 讨论同步到 Issue 评论 → 完成开 PR → 移到「审查中」
评论都带身份标记,一眼看出谁说的:
| 图标 | 角色 | 做什么 |
|---|---|---|
| 🧠 | Claude Code | 写方案、实现 |
| 🤖 | Cursor Agent | 审查意见 |
| 🧪 | Codex CLI | 审查意见 |
| 🌟 | GLM | 审查意见 |
| 🔧 | Workflow | 状态流转 |
Sparring 管审查质量,ClawTeam 管多 agent 并行。组合使用:每个 agent 既能并行加速,又有质量保障。
ClawTeam 分 3 个任务并行
├── Claude #1: auth 模块 ← Sparring: Reviewer 审查
├── Claude #2: database ← Sparring: Reviewer 审查
└── Claude #3: frontend ← Sparring: Reviewer 审查
# 安装 ClawTeam
pipx install clawteam
# 创建团队 + spawn worker(每个 worker 完成后跑 Sparring review)
clawteam team spawn-team my-project -d "重构用户系统" -n leader
clawteam spawn tmux claude --team my-project --agent-name auth \
--task "实现 auth 模块。写完后运行 sparring review-code my-project 让 reviewer 审查"
clawteam board attach my-project # 看所有 agent 同时工作Issue + Team 协同:大 Issue 拆成子任务让多 agent 并行开发(见 ClawTeam 完整示例)。
自动接单:让 Claude 定时轮询看板:
/loop 5m /sparring:issue https://github.com/orgs/your-org/projects/3review 耗时长时可后台执行:
sparring review-proposal-bg <task-id> # 启动后台 job
sparring review-code-bg <task-id>
sparring review-status [job-id|task-id] # 查状态
sparring review-result <job-id> # 看结果
sparring review-cancel <job-id> # 取消# 初始化
sparring setup # 交互式安装
sparring config init # 生成全局配置
sparring verify # 检查环境
# 任务
sparring create <name> <claude|cursor>
sparring propose <task-id>
sparring review-proposal <task-id>
sparring implement <task-id>
sparring review-code <task-id>
sparring approve <task-id>
sparring list
sparring status <task-id>
# Issue
sparring --project <url> issue-poll
sparring issue-claim <number>
sparring issue-comment <number> <body>
sparring issue-read <number>
sparring issue-done <number> [pr-url]完整列表:sparring help。兼容别名:workflow xxx 仍可用(bin/workflow 是软链)。
欢迎 Issue / PR。这个项目本身就用 Sparring 开发——你能看到主分支上每个改动都过了 Cursor/Codex review。
MIT