Kimi Code + Claude Code (DeepSeek) 结对编程: 一个开发, 一个审查

为什么让两个不同的模型结对

单独用一个模型开发,最大的问题不是它不够强,而是它会自我认可:同一个模型写的代码,自己再看一遍,容易沿着同样的思路漏掉同类错误——错误的假设、被忽略的边界条件,第一遍没发现,第二遍大概率也发现不了。

把 Kimi Code 和 Claude Code(跑 DeepSeek 模型)凑成一对,各司其职:

理由	说明
盲点互补	两个厂商的训练数据、工具链、思维习惯不同,交叉审查的命中率远高于自我复查
成本可控	审查是"读多写少"的活,DeepSeek V4 Flash 输出参考价 $0.28/M tokens,便宜的一方正好干这个
角色隔离	审查方只读不写,天然不会和开发方改同一行代码打架;"写"和"评"的责任分开,问题清单喂回开发方,闭环清晰

分工:

角色	工具	模型	动作
开发	Kimi Code CLI	kimi-for-coding	改文件、跑测试、提交
审查	Claude Code	deepseek-v4-flash	只读 git diff,输出问题清单

备注

下文中的 "Claude Code" 均指接了 DeepSeek 后端的 Claude Code CLI。两款工具都是终端里的编码 Agent,自带文件读写、命令执行、多轮决策能力,结对不需要任何额外的框架。

环境准备

1. 安装 Kimi Code CLI

Kimi Code CLI 是 Moonshot 开源的终端编码 Agent,命令是 kimi,通过 npm 安装:

# 国内网络先切镜像, 已有镜像可跳过
npm config set registry https://registry.npmmirror.com
npm install -g @moonshot-ai/kimi-code

# OAuth 登录, 会打印一个网址和验证码, 浏览器确认即可
kimi login

验证安装:

kimi -p "用一句话介绍你自己"

-p(prompt 模式)是后续所有自动化的基础:不进入交互界面,执行完一条指令就退出,并且自动批准文件读写等常规操作,适合脚本驱动。

2. 安装 Claude Code 并接入 DeepSeek

npm install -g @anthropic-ai/claude-code

DeepSeek 提供了 Anthropic 兼容端点,Claude Code 不需要改代码,只改几个环境变量即可接入(2026-06-23 起 DeepSeek 官方发布了集成指南)。推荐写进 ~/.claude/settings.json 的 env 块,CLI 和 VS Code 扩展共用:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "<你的 DeepSeek API Key>",
    "ANTHROPIC_MODEL": "deepseek-v4-pro[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
    "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-v4-flash",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "786432"
  }
}

几个关键点:

配置	说明
ANTHROPIC_BASE_URL	必须是 https://api.deepseek.com/anthropic,/anthropic 后缀不能少,也不要加 /v1(会拼成 /v1/v1/messages 报 404)
ANTHROPIC_AUTH_TOKEN	填 DeepSeek 的 API Key,不是 Anthropic 的
deepseek-v4-pro[1m]	主力模型;[1m] 后缀申请 1M 上下文窗口,Claude Code 会剥掉后缀再发给 DeepSeek,建议保留
deepseek-v4-flash	轻量模型,映射给 Haiku 档和子代理,审查用它足够

警告

deepseek-chat / deepseek-reasoner 这两个旧模型名已于 2026-07-24 退役,请求会报 404 model not found。网上老教程的配置记得换成 deepseek-v4-pro[1m] / deepseek-v4-flash。

警告

API Key 不要进 git:如果 settings.json 会被提交,把 env 块挪到 ~/.claude/settings.local.json(本地文件,不进仓库),或者直接在 shell 里 export ANTHROPIC_AUTH_TOKEN=...。

验证:进入 claude 交互界面跑 /status,确认 Base URL 显示 api.deepseek.com/anthropic;再跑一句 claude -p "说一句你好"。

结对的核心规则

动手之前先立三条规矩,它们是后面所有工作流的地基:

1. 同一时刻只有一个 Agent 改文件。两个 Agent 同时写同一个工作区,互相覆盖是必然结局。

2. 审查方只读。审查命令里显式限制工具白名单(见下文 --allowedTools),从机制上保证它改不了东西。

3. 审查的对象永远是 git diff。审查方只看"这次改了什么",不看整个仓库——上下文小、速度快、意见聚焦;也避免审查方被既有代码带偏。

在这个基础上,有串行和并行两种组织方式:

• 串行(推荐入门):开发方改完提交,审查方审最后一次提交,问题喂回开发方修复,循环。简单可靠,一次只有一个 Agent 在工作。

• 并行(进阶):用 git worktree 给每个 Agent 一个独立工作区,开发在主区,审查在另一个 worktree 读 diff。适合审查要花很长时间的大改动,后面"进阶玩法"再展开。

方式一: 设计 + 评审(先定方案再动手)

开发之前,先让一方出设计、另一方挑刺,这是性价比最高的检查——设计阶段的漏洞改起来只要改文档,代码阶段改起来要动真金白银。

终端 A(Kimi 出设计):

你是资深架构师。任务: {任务描述}
请输出一份设计文档, 保存到 docs/design-{主题}.md, 内容包括:
1. 方案概述与备选方案对比
2. 关键数据结构 / 接口定义
3. 边界情况与异常处理策略
4. 对现有代码的影响面

终端 B(Claude Code 评审设计):

claude -p "你是设计评审员, 只评审 docs/design-{主题}.md, 不要修改任何文件。
找出设计漏洞: 性能瓶颈、数据一致性问题、安全风险、影响面遗漏、可维护性问题。
每条意见给出文档中的出处, 按严重程度分级。" \
  --dangerously-skip-permissions \
  --allowedTools "Read,Grep,Glob"

把评审意见贴回终端 A:"按以下意见修订设计:..."。来回一到两轮,方案就比单模型自说自话扎实得多。

方式二: 开发 + 审查(手动结对, 两个终端)

最直观的结对:两个终端并排,一个写一个查。

终端 A(Kimi 开发):

你是资深开发者。任务: {任务描述}
流程:
1. 先浏览相关代码, 说明你的实现方案
2. 按方案实现, 改动保持最小
3. 运行相关测试确认通过
完成后停下, 不要提交, 等我的下一步指令。

开发完成后,你手动提交(提交动作留在人手里,是关键的检查点):

git add -A
git commit -m "feat: {任务描述}"

终端 B(Claude Code 审查):

claude -p "你是严格的代码审查员。审查最后一次提交 (git show HEAD), 不要修改任何文件。
规则:
1. 每条问题必须给出 文件:行号 证据
2. 按严重程度分级: 阻断(必须修) / 建议(应该修) / 观察(了解即可)
3. 关注: 边界条件、错误处理、资源泄漏、并发问题、测试覆盖
4. 只报确实存在的问题, 不写客套话" \
  --dangerously-skip-permissions \
  --allowedTools "Read,Grep,Glob"

审查输出通常是一份带 文件:行号 的问题清单。把清单原样贴回终端 A,补一句"按以上意见逐条修复",Kimi 会对照着改。改完再提交、再审,循环:

        sequenceDiagram
    participant K as 终端A: Kimi (开发)
    participant G as Git
    participant C as 终端B: Claude Code (审查)
    K->>G: 实现并提交
    G->>C: git show HEAD
    C-->>K: 问题清单 (文件:行号 + 分级)
    K->>G: 修复并提交
    G->>C: 新一轮 diff
    C-->>K: 通过 ✓
    

两个终端各开一个 tmux 窗口很顺手;不想贴来贴去的话,方式三把它自动化。

方式三: 全自动结对(脚本驱动)

两个 CLI 都支持无头模式(kimi -p / claude -p),所以"开发 → 提交 → 审查 → 修复"整条链路可以写成一个脚本,人在旁边只看结果。

#!/usr/bin/env bash
# pair.sh — Kimi 开发 + Claude Code (DeepSeek) 审查, 循环直到审查通过
# 用法: ./pair.sh "任务描述"
set -euo pipefail

TASK="${1:?用法: ./pair.sh \"任务描述\"}"
MAX_ROUNDS="${MAX_ROUNDS:-3}"

echo "==> [1] Kimi 开发: $TASK"
kimi -p "你是资深开发者, 任务: $TASK
- 先读相关代码再动手, 改动保持最小
- 改完运行相关测试, 保证通过
- 不要执行 git commit, 提交由脚本处理"

echo "==> [2] 提交改动"
git add -A
git commit -m "dev(kimi): $TASK"

for round in $(seq 1 "$MAX_ROUNDS"); do
  echo "==> [3] 第 $round 轮审查 (Claude Code + DeepSeek)"
  claude -p "你是严格的代码审查员, 只审查下面的 diff, 不要修改任何文件。
规则:
1. 每条问题必须给出 文件:行号 证据
2. 按严重程度分级: 阻断(有 bug 或安全风险) / 建议(值得改) / 观察(了解即可)
3. 只报告确实存在的问题, 不写客套话
4. 最终只输出一个 JSON 对象, 不要 markdown 代码块:
{\"findings\": [{\"file\": \"...\", \"line\": 1, \"level\": \"阻断\", \"description\": \"...\"}]}
没有问题则输出 {\"findings\": []}

diff:
$(git show --format=fuller HEAD)" \
    --output-format json \
    --dangerously-skip-permissions \
    --allowedTools "Read,Grep,Glob" > /tmp/review.json

  # 从 claude 的 JSON 输出中提取"必须处理"的问题, 生成反馈
  python3 - <<'PY' > /tmp/feedback.txt
import json
outer = json.load(open("/tmp/review.json"))
text = outer.get("result", "")
i, j = text.find("{"), text.rfind("}")
findings = json.loads(text[i:j+1]).get("findings", []) if i >= 0 else []
serious = [f for f in findings if f.get("level") in ("阻断", "建议")]
if not serious:
    print("PASS")
else:
    for f in serious:
        print(f"[{f['level']}] {f['file']}:{f['line']} — {f['description']}")
PY

  if grep -q '^PASS$' /tmp/feedback.txt; then
    echo "==> 审查通过, 共 $round 轮"
    exit 0
  fi

  echo "==> [4] 问题清单:"
  cat /tmp/feedback.txt
  echo "==> 交回 Kimi 修复"
  kimi -p "代码审查发现以下问题, 逐条修复:
$(cat /tmp/feedback.txt)
修复后运行相关测试, 不要执行 git commit"
  git add -A
  git commit -m "fix(kimi): 第 $round 轮审查问题修复"
done

echo "==> 达到最大轮数 $MAX_ROUNDS, 仍有问题待处理, 见 /tmp/feedback.txt"

逐段拆解:

1. kimi -p 无头开发:prompt 模式不弹交互界面,自动批准常规操作,跑完退出。指令里明确"不要 commit",把提交权留给脚本;

2. 提交:人(或脚本)提交,Kimi 的改动变成一个干净的 diff,供下一环审查;

3. claude -p 无头审查:三个参数是安全关键——--dangerously-skip-permissions 免去逐条确认,--allowedTools "Read,Grep,Glob" 把工具白名单锁成只读,--output-format json 让输出可被程序解析;

4. 解析 JSON:claude 的 json 输出是 {"result": "..."} 结构,审查清单在 result 字段里,用 python 提取;只把"阻断/建议"两级问题喂回 Kimi,"观察"级不阻塞;

5. 循环:修复后重新提交、再审,直到 PASS 或超过 MAX_ROUNDS。

警告

kimi -p 模式会自动批准文件读写等常规操作,等于把工作区交给了模型。脚本只在你信任的目录(比如一个专门的项目仓库)里跑,别拿去对 ~ 或生产服务器用。

审查 prompt 怎么写才有效

审查质量九成取决于 prompt。上面两个模板里藏着四条经验:

1. 强制证据:"每条问题必须给出 文件:行号"。没有这个要求,模型会输出"整体结构可以优化"之类的空话;有行号,你(和修复方)才能逐条核实——审查方也可能说错,行号让它说的话可证伪;

2. 分级:阻断 / 建议 / 观察。分级既给修复方排了优先级,也让脚本能只把高级别问题喂回去,避免在鸡毛蒜皮上空转;

3. 禁止客套:"只报确实存在的问题,不写客套话"。模型默认有迎合倾向,不约束它,一半的输出是"整体完成得很好,建议..."

4. 只审 diff:"审查下面的 diff",把范围钉死。范围越小,意见越具体;顺便省 token。

如果审查意见和你的判断冲突,当场追问它:"给出这个结论的依据"。两个模型互相制衡,最后的判断权在你。

进阶玩法

git hook: 提交即审查

把审查挂到 post-commit hook,每次 Kimi 提交完自动触发:

# .git/hooks/post-commit
#!/usr/bin/env bash
claude -p "你是严格的代码审查员, 审查最后一次提交 (git show HEAD), 不要修改任何文件。
每条问题给出 文件:行号 证据, 按 阻断/建议/观察 分级, 只报确实存在的问题。" \
  --dangerously-skip-permissions \
  --allowedTools "Read,Grep,Glob"

适合有审查意识的仓库:每笔提交都有一份独立的、来自另一个模型的意见。

交互式深审: /code-review

无头模式的审查胜在自动化,但讨论感弱。大改动、拿不准的改动,开一个 Claude Code 交互会话,让它审查当前 diff,针对每条意见追问"为什么""有没有反例",把审查变成对话。修起来慢,但适合关键路径。

worktree 并行: 一个写一个审, 互不阻塞

开发要跑很久时,可以让审查方在另一个 worktree 上并行读 diff:

git worktree add ../project-review HEAD~1
cd ../project-review
claude -p "审查 ../project 最后一次提交 (git -C ../project show HEAD), 不要修改任何文件" \
  --dangerously-skip-permissions --allowedTools "Read,Grep,Glob"

两个 Agent 各有各的工作区,物理上不可能互相覆盖;开发不被打断,审查意见开发完再统一处理。

角色互换: 防止盲区固化

长期固定"Kimi 写、DeepSeek 审",等于默认了 Kimi 的开发水平总是对的。每过一段时间交换一次角色(DeepSeek 开发、Kimi 审),两边的问题都会暴露出来,也顺带比较两个模型在你项目上的真实水平。

常见坑

坑	现象	处理
两个 Agent 同时改文件	改动互相覆盖,git 状态混乱	严格遵守串行;要并行就用 worktree
审查全是空话	"整体不错,建议优化"	prompt 强制 文件:行号 + 禁止客套
互相认同错误	修复方照单全收错误意见	逐条核实行号;拿不准让审查方给依据
DeepSeek 报 404 model not found	旧教程的 deepseek-chat 配置	换成 deepseek-v4-pro[1m] / deepseek-v4-flash
DeepSeek 工具调用偶发失败	diff 编辑偶尔重试、丢工具调用	这是已知现象(成功率低于官方 Claude),审查只用只读工具影响很小;开发方仍用 Kimi
上下文超限报 400	DeepSeek 上下文窗口较小	设置 CLAUDE_CODE_AUTO_COMPACT_WINDOW=786432;审查只喂 diff 不喂全仓库
API Key 泄漏	settings.json 被 git 提交	key 放 settings.local.json 或环境变量
无头模式误操作	kimi -p 自动批准改动	只在受信任的目录跑;提交动作保留在脚本/人手里

总结

• 分工:Kimi Code 写代码、Claude Code(DeepSeek)审 diff,审查方永远只读;

• 闭环:开发 → 提交 → 审查 → 问题清单喂回开发 → 再审查,直到通过;

• 自动化:两个 CLI 的无头模式(kimi -p / claude -p --output-format json)让整个闭环可以脚本化,post-commit hook 让审查零成本;

• 边界:审查意见要带 文件:行号 证据,最后判断权在你手里。

参考资料

• Kimi Code CLI 官方速查表(中文版)

• DeepSeek 发布官方 Claude Code 集成指南(2026-06-23)

• DeepSeek V4 接 Claude Code:从零到跑通配置教程(含旧模型退役说明)

• awesome-deepseek-agent:Claude Code 接入 DeepSeek 中文文档

• Kimi 与 Claude CLI 无头模式对比(2026-05)