claude-ship
一位量化开发者跑了半年、已开源的 Loop Engineering 实现——7 个专责 agent 加 /ship 状态机，把单人 AI 开发的确认偏误、审查疲劳、记忆蒸发关进系统性约束里。
简介
claude-ship 是 Peakstone-Labs 开源的一套结构化 AI 开发系统（GitHub: github.com/Peakstone-Labs/claude-ship），是 Loop Engineering 从抽象范式落地为可运行工具的一个完整样本。它由 7 个各有独立人格定义、工具权限和模型分配的 agent 组成，通过 /clarify → /architect →（可选 /third_party_review）→ /ship → /retro 的 slash 命令序列驱动，全部输出统一落在 <feature-name>/ 目录形成”七件套”文档。
它与一般的多 agent 框架的区别在于设计动机：不是追求”让 AI 更聪明”，而是针对单人开发被 AI 放大的三个人性弱点——确认偏误、审查疲劳、记忆蒸发——各派系统性约束去对冲。作者强调这套系统已在生产环境（其量化交易系统）实打实跑了半年，每个设计决策背后都有真实使用痕迹，包括那些最后发现没用的部分，因此选择 build in public 开源。
claude-ship 的灵魂不在代码循环（dev→review→qa），而在进化循环（retro→memory→下一个 feature）：前者保证”这一次”不出错，后者保证”下一次”自动比这一次更强。
关键信息
- 类型：工具 / 开源开发系统
- 领域：AI 编程 / Agent 工程 / 结构化开发流水线
- 作者定位：量化交易系统开发者（build in public）
- 仓库地址：github.com/Peakstone-Labs/claude-ship
- 开源协议/状态：开源，一条
install.sh装进~/.claude - 依赖底座：Claude Code（headless 模式用于跨厂商评审）
- 相关概念：Loop Engineering、预提交预测、自我改进代理系统、7 Agent 软件工厂、验证者子代理
核心特性
七个 agent 与”七件套”文档
7 个 agent 各有独立人格、工具权限、模型分配，输出统一落在 <feature-name>/ 目录形成七件套：requirements → design → third_party_review → implementation → review → test_report → retro。模型分配按认知特征而非强弱：
| Agent / 命令 | 职责 | 模型分配 | 关键设计 |
|---|---|---|---|
| clarify | 需求澄清 | 默认模型 | 一次只问一个问题，先读代码再提问 |
| architect | 架构设计 | 默认模型 | 产出 design.md |
| third_party_review | 跨厂商设计评审 | 第三方模型 | 建议性、不阻断 /ship |
| dev | 实现 | Sonnet（快速便宜） | 在本 session 执行，可实时打断 |
| review | 代码审查 | Opus（高判断力、慢但准） | 先猜后看的预提交预测 |
| qa | 测试验证 | Sonnet | 独立 subagent，隔离上下文 |
| retro | 复盘蒸馏 | — | 三条铁律筛 memory |
clarify：一次只问一个问题
clarify agent 有硬约束：一次只问一个问题，禁止批量提问、禁止”顺便问一下”，且先读代码再提问（代码里能直接回答的问题不该出现在对话里）。理由是人的注意力是串行的，批量提问时你回答第 3 个已经在想”什么时候问完”。代价是慢（一个 feature 澄清可能 4-6 轮），但有退出机制：用户随时说”够了/开始设计”立即终止，第 8 轮还没完系统主动暂停。
review：先猜后看 + memory 驱动预测
review 的工作流程不是”读代码→找问题”，而是先只读设计文档列出 3-5 个最可能的缺陷区域，再带着预测审代码，同时记录命中和未覆盖的问题。这是 预提交预测 的核心实现，预测起点从 memory 检索历史事故模式，使审查能力随使用次数增长。
分级阻断 + 低风险即修
review 发现问题后分级处置：Critical/Important 阻断循环、必须修复或白名单豁免；Minor/Suggestion 套用”低风险即修”准则——同时满足有客观依据、无副作用、改动 ≤20 行且单文件、不需用户确认四条就必须修。延后理由只有四种合法白名单（超出 scope、需用户确认、需大重构、与 design 冲突），禁止”后续优化”这类模糊措辞。本质是用低摩擦执行换零技术债积累。
/ship 状态机：真正会阻断的 gate
/ship 不是 agent 而是状态机，把 dev→review→qa 串成循环，四个关键工程决策决定它是”真 gate”还是”走形式”：
- review/qa 跑在独立 subagent：dev 在本 session（可打断），review/qa 用 Task 工具开隔离上下文，只看 design.md/implementation.md，看不到 dev 的内心独白，强制保持不相关性。
- gate 硬阻断：提取 Critical/Important 阻断计数，任一 > 0 就跳过本轮 QA 直接打回 dev（跳过 QA 是为了省 token——带着已知缺陷跑 QA 只会重复发现同样问题）。
- 循环硬上限：第 4 轮暂停询问用户，超 5 轮强制终止并给根因分析（设计缺陷/实现能力不足/需求本身矛盾），防止在”接近完成但差一点”里无限烧 token。
- 文档是接口协议：review.md/test_report.md 增量追加，新章节插顶部、历史往下推，不得改删历史章节，可回溯整个 feature 的决策演进。
third_party_review：跨厂商设计评审
在写代码前用另一个厂商的模型独立评审 design.md，抓 Claude 因同模型家族训练数据导致的共有偏见。实现是 headless Claude Code + 切换 ANTHROPIC_BASE_URL 到第三方端点（DeepSeek、Kimi 等兼容 Anthropic Messages API 的服务）。定位是建议性、不阻断 /ship——它不是 gate 而是另一个视角。
不同素材中的观点
- 2026-07-10-juejin-loop-engineering-claude-ship：作者用半年实战拆解 claude-ship 的每个设计决策，并诚实列出五个未解决缺陷：(1) loop 一多 context window 吃紧，三轮以上光读历史文档要几万 token，历史章节自动摘要压缩还没上线；(2) review/qa 跑在同一模型家族有共有盲区，third_party_review 只做到设计层、代码层跨模型 review 还没做；(3) 流程对简单任务太重（修一行 typo 不需要走完整流水线），“小任务”目前靠直觉判断，是下一个要工程化的问题；(4) retro 到 memory 的闭环不够紧，architect 与 memory 集成还弱；(5) 最根本的前提是你能写清楚 CLAUDE.md，垃圾进垃圾出。核心论点是”最重要的循环是 retro→memory→下一个 feature 的进化循环”，这是复利结构而非一次性效率提升。
实用信息
快速上手步骤
git clone https://github.com/Peakstone-Labs/claude-ship.gitcd claude-ship && ./install.sh（拷贝进~/.claude，立即可用）- 任意项目里跑
/clarify <feature>→/architect <feature>→（可选/third_party_review <feature>）→/ship <feature>→/retro <feature> - 启用跨厂商评审：复制
third-party-review.d/provider.env.example为<provider>.env，填入第三方端点信息。
注意事项/避坑指南
- 从 review 和 retro 开始，不要七个全上：这两个 agent ROI 最高（review 阻止缺陷进库，retro 把修复变成永久记忆），其他 agent 等真的需要再加。
- 先写好 CLAUDE.md：所有 agent 有效性取决于项目上下文准确度，花一小时写好 CLAUDE.md 比花一天调 agent prompt 更值。
- 把前几个 feature 的 memory 当投资：前三个 feature 因三条准入规则很严可能存不进多少 memory，属正常；它们是在给第四个及之后的 feature 种地。