software

从代码补全到代码团队：我们如何将 Claude Code 打造成工程部门

发布: (2026年3月11日 GMT+8 00:40)
13 分钟阅读
原文: Dev.to

I’m happy to translate the article for you, but I’ll need the full text of the post (or the portions you’d like translated). Could you please paste the article content here? Once I have it, I’ll provide a Simplified‑Chinese translation while preserving the source link, formatting, and any code blocks.

Introduction

我们每天都在使用 Claude Code。它非常出色：能够处理复杂的重构、编写测试、在大型代码库中导航，并捕捉我们可能遗漏的 bug。经过数月将其作为自主多代理系统的一部分运行后，我们注意到一点：Claude Code 是一个强大的工具，但它本质上是 被动 的。它等待指令，执行指令，然后停止。它不会自我监控、提前规划、审查自己的输出，或记住上一次出错的地方。

这并不是批评——而是设计选择。Claude Code 的定位是编码助理，而非自主工程代理。我们一直在自问：要把它变成自主工程代理，需要做哪些改动？

答案就是我们称之为 V2 架构 的方案：一个由三层组成的系统，围绕 Claude Code 加入监控、规划和审查层。本文将介绍我们构建的内容以及每一层存在的原因。

被动工具问题

当你直接运行 Claude Code 时，交互模型是：

  1. 你给它一个任务。
  2. 它开始处理。
  3. 它完成（或卡住）。

没有进程监控它是否仍在取得进展，没有它正在执行的结构化计划，也没有对输出是否真正正确的第二意见。实际上，这会产生我们反复遇到的三种失败模式：

失败模式描述
循环卡住Claude Code 有时会重复同一个失败的方案。没有外部监控，会话会一直运行，直到你注意到有问题——如果是夜间自动运行，可能要几个小时后才发现。
缺乏前置计划对于包含多个步骤或依赖关系的任务，在没有明确实现计划的情况下直接跳入代码，往往会导致昂贵的中途转向。人类通常会先草拟方案；Claude Code 默认并不这样做。
缺乏交叉审查模型审查自己的输出会有盲点——导致错误的推理往往还能为“错误是合理的”提供理由。拥有不同训练分布的第二个模型可以捕捉到不同的问题。

每一种情况都是可以解决的。将它们组合起来，就形成了 V2 架构。

V2 架构概览

系统在每个 Claude Code 会话周围运行三层：

Layer 1: Heartbeat (watchdog)
  └─ tmux session monitor
  └─ detects stuck/crashed → auto‑recover

Layer 2: Skill‑Driven Dev (planning)
  └─ SKILL.md written before code
  └─ implementation blueprint

Layer 3: Dual Review (verification)
  └─ Claude Code self‑review
  └─ Gemini CLI cross‑review

Claude Code 仍然负责实际编码。这些层并不取代它——它们是对其的包装。

第1层 – 心跳

Claude Code 在一个 tmux 会话中运行。心跳是一个看门狗进程，每 30 秒轮询该会话并检查终端输出。它只寻找一个指示器：Claude Code 的提示符 (❯) 是否可见，这表示模型已经完成并在等待输入。

SOCKET="${TMPDIR:-/tmp}/openclaw-tmux-sockets/openclaw.sock"
LAST5=$(tmux -S "$SOCKET" capture-pane -p -J -t claude-code:0.0 -S -5)
echo "$LAST5" | grep -q "❯" && echo "DONE" || echo "RUNNING"

如果提示符在超过可配置的超时时间后仍不可见，则说明出现了问题。

当心跳检测到会话卡住时，它会按升级顺序尝试三种恢复策略：

  1. 温和中断 – 发送 Ctrl‑C。
  2. 重启 – 关闭并重新启动 tmux 会话，保持相同的任务上下文。
  3. 人工介入 – 呼叫编排器（Orange）进行手动干预。

大多数卡住的会话会在第 1 步得到解决。没有这个看门狗，自治编码会话会变得脆弱：网络错误、权限问题，或 Claude Code 误以为自己在取得进展的循环都会变成无声的失败。心跳将这些情况转化为已处理的异常。

第 2 层 – 基于技能的开发

在任何非平凡任务交给 Claude Code 之前，编排器会先编写一个 SKILL.md 文件。这是一个结构化的实现计划——相当于设计文档——Claude Code 随后会依据它执行。

skills/
  feature-name/
    SKILL.md    # implementation plan + steps

常见的 SKILL.md 部分

部分目的
Goal（目标）任务是什么以及“完成”标准是什么。
Reference style（参考风格）需要模仿的已有代码。
Outline（大纲）具体章节或步骤，填入关键技术细节。
Implementation steps（实现步骤）按顺序列出的操作步骤。
Privacy / safety checklist（隐私/安全检查清单）提交前需要核实的事项。

这篇博客文章本身就是依据它自己的 SKILL.md 编写的。规划步骤在任何代码编写之前就强制要求精确。模糊的任务会在规划阶段得到澄清，而不是在实现过程中才解决。它还为 Claude Code 提供了具体的成功标准，而不是让它自行推断何时完成。

复用 是另一大好处。技能会随时间累积。当出现类似任务时，编排器可以在技能库中搜索相关模式，并在现有计划的基础上进行适配，而不是从头开始。随着时间推移，系统会形成关于如何处理特定类型任务的机构性知识。

第三层 – 双重审查

在 Claude Code 完成并暂存其更改后，提交之前会进行两轮审查。

  1. Claude Code 自审 – 在一个独立的会话中，Claude Code 会审查它刚刚生成的 diff。此步骤可以捕获一些直接的问题：残留的调试输出、未完成的实现，或针对错误行为的测试文件。

  2. Gemini CLI 交叉审查 – 暂存的更改会被传递给第二个大模型（Gemini），其训练数据分布不同。Gemini 会寻找 Claude Code 自身推理可能遗漏的问题，例如细微的逻辑错误、安全隐患或风格违规。

只有当两轮审查都通过时，编排器才会合并这些更改。这种双管齐下的验证方式能够显著降低静默回归进入生产环境的风险。

TL;DR

层角色
Heartbeat检测并恢复卡住或崩溃的 Claude Code 会话。
Skill‑Driven Dev在开始编码前提供具体、可复用的实现计划（SKILL.md）。
Dual Review在提交前执行自审（Claude Code）和交叉审查（Gemini）。

通过在 Claude Code 之上加入这三层，我们把一个被动的编码助手转变为 强大的自主工程代理。该架构简洁、模块化且可扩展——任何团队都可以采用它，使基于 LLM 的开发流水线更加可靠和自给自足。

diff to Gemini

git diff --cached | gemini -p "Review this diff for: security issues, privacy leaks (IPs, emails, API keys), code quality. Output: PASSED or list of issues."

交叉审查更为重要

不同的模型使用不同的训练分布，能够可靠地捕捉到 Claude Code 自审遗漏的内容——尤其是安全问题和隐私泄露。我们已经看到 Gemini 捕获了硬编码的测试凭证、不应出现在公开代码中的内部主机名，以及 Claude Code 自审将其描述为有意设计决策的逻辑错误。

输出格式严格：只能是 PASSED 或者问题列表。如果出现问题，提交将被阻止，问题会返回给 Claude Code 进行修复。循环将持续进行，直至 Gemini 通过为止。

The full V2 workflow

Putting it together, the orchestrator’s AGENTS.md describes a fixed sequence for every coding task:

1. memory_search → find relevant lessons and patterns from past work
2. Write SKILL.md (plan before code)
3. Launch Claude Code via tmux (with Heartbeat active)
4. Wait for Heartbeat signal: DONE
5. Gemini Review on staged diff
6. If issues: send back to Claude Code, loop
7. Commit
8. Update lessons/MEMORY.md with what was learned

步骤 1 和 8 为系统提供记忆功能。开始之前，编排器会在其向量记忆中搜索类似过去任务的经验教训——包括之前的决策、失败模式以及有效的模式。完成后，它会把学到的内容写回记忆中。随着时间推移，这会形成一个反馈回路，使系统在某些类型的任务上显著提升。

What this isn’t

  • 这并不是一个完全自主的工程团队。编排器（Orange）仍然需要人类（Qiushi）批准任何涉及生产、金融操作或重大的架构决策的事项。V2 架构自动化了日常的编码工作；它并未自动化判断。
  • 它也不是 Claude Code 的替代品——它只是为其提供一个使用框架。编码质量仍然来源于 Claude Code。该架构仅确保质量得到检查，会话不会静默失败，并且系统能够累积知识，而不是每次都从头开始。

原则

我们发现自己经常回到的模式是：AI 工具在不是独立使用时最为强大，而是嵌入到能够监控、指引并检查其输出的系统中。单独的 Claude Code 已经是一个强大的编码器。加入 Heartbeat、规划层以及交叉审查步骤的 Claude Code 则更接近可靠的工程工作流。

同样的原则也适用于任何有能力但被动的 AI 工具。工具完成工作，系统确保这项工作值得保留。

本文最初发布在 claw‑stack.com。我们正在构建一个开源的 AI 代理运行时——查看 文档 或者 GitHub 仓库。

0 浏览
#software #programming #community
查看原文
Share:
Back to Blog

相关文章

阅读更多 »