AI 编程光会写代码还不够?聊聊 6 种主流 Harness 框架到底怎么选

Vibe Coding 玩得爽，但真上项目就翻车？也许你缺的不是更强的模型，而是一套「脚手架」。

一、AI 编程为什么需要「脚手架」？

想象一下：你请了一个能力超强的实习生，写代码飞快，做一个小工具又快又好。但当你把他丢进一个几万行代码的大项目，说”帮我重构一下用户系统”——他大概率会搞出一堆看起来能跑、但细看全是坑的东西。

这就是现在 AI 编程的真实状态。

过去一两年，AI 写代码的能力突飞猛进。但越来越多人发现一个扎心的事实：能写 ≠ 能稳定交付。

你让它改个页面、补个函数，当然又快又爽。但一旦任务变复杂——需求不明确、代码量大、需要多人协作、质量要把关——问题就来了：

• 🔸 需求全靠聊天传达，换个会话可能就理解成另一个东西
• 🔸 聊久了就「失忆」，约束忘了、规则丢了、越写越偏
• 🔸 跨会话像断片，昨天讲的架构原则今天得从头再来
• 🔸 多个 AI 同时干活，不但不协作，反而互相捣乱
• 🔸 看起来写对了，实际上删了功能、绕了校验、埋了隐患

所以社区里慢慢出现了一类东西，叫 Harness——你可以把它理解成给 AI 搭的「工程化脚手架」。它不是让 AI 更会聊天，而是让 AI 在真实项目里更可控、更可验证、更能规模化地干活。

二、6 种主流框架，各管什么？

市面上已经冒出了不少 Harness 框架。今天聊 6 个比较有代表性的：OpenSpec、Superpowers、GSD、OMC、ECC、Trellis。

先打个底：这 6 个不是同一种东西。 它们各自在不同的层面上解决不同的问题。

用一张表快速建立直觉：

下面逐个拆。

三、逐个拆解

🔍 OpenSpec：先把要做的事讲清楚

OpenSpec 的核心理念就四个字：先对齐，再开工。

它推崇一种叫 SDD（规格驱动开发）的方式——在开始写代码之前，先把需求拆成 proposal → specs → design → tasks 这样一组结构化文件。

这解决的是最基础但最容易被忽视的问题：需求只存在脑子里或聊天记录里，AI 只能靠猜。而 OpenSpec 把模糊意图变成了可审核、可复用、可迭代的资产。

它不管你怎么写代码、怎么编排 Agent——它只管一件事：确保你在干正确的事。

⚡ Superpowers：让 AI 像工程师一样干活

如果 OpenSpec 解决的是”做什么”，Superpowers 解决的就是”怎么做”。

它的思路是把优秀工程师的工作习惯（TDD、代码审查、分支隔离、系统化调试）变成 AI 的默认技能。

你不用每次都在 prompt 里叮嘱”先写测试再写代码”——有了 Superpowers，这些就是 Agent 的标准动作。

适合什么场景？ 你发现 AI 写代码太随意、不做测试、不走审查、调试全凭运气——这些问题它都能管。

💪 GSD（Get Shit Done）：专治「聊着聊着就歪了」

GSD 有一种很强的实战气质。它的核心卖点三个字：防失忆。

任何用过 AI 做复杂任务的人都知道，聊天记录一长，AI 就开始遗忘约束、重复犯错、自相矛盾。GSD 称这个问题为 context rot（上下文腐烂）。

它的解决方案是把复杂任务拆成阶段：讨论 → 计划 → 执行 → 验证，每个阶段用干净的上下文重新开始。

不是让 AI 更聪明，而是让它在变笨之前就换一波新鲜空气。

🤖 OMC（Oh My ClaudeCode）：单兵变团战

前面三个更偏”一个 AI 怎么干活”，OMC 开始解决”多个 AI 怎么配合”。

它围绕 Claude Code 构建了一套团队式编排：team-plan → team-prd → team-exec → team-verify → team-fix。支持 tmux workers、多模型协作、并行执行。

核心价值： 你不再是跟一个助手聊天，而是指挥一支 AI 开发小队。

不过边界也很清楚——它深度绑定 Claude Code 生态，如果你主要用其他工具，这套可能不太合适。

🧠 ECC（Everything Claude Code）：给整套流程装上「大脑」

ECC 容易被误解成一个配置包，但它想做的其实更大——给 AI 的整个工作流补上记忆、技能、安全和持续学习的能力。

比如：每次新会话不再从零开始，因为有 memory 系统；代码不只是能跑就行，因为有安全扫描和验证闭环；踩过的坑不会再踩，因为有 instincts（直觉集合）在学习。

代价是什么？ 东西多，信息密度高，学习曲线陡。适合已经跑通基础流程、想进一步系统化的团队。

🏗️ Trellis：给整个项目搭一副骨架

Trellis 和前面几个都不太一样。它不是给某个 Agent 增强能力，而是给整个项目搭一套统一的结构。

核心目录只有三个：.trellis/spec/、.trellis/tasks/、.trellis/workspace/。但这三层就把规格、任务、工作区记忆全串起来了。

它解决的核心问题是：团队用了好几个 AI 工具，每个工具一套规矩，项目记忆到处散落，换个人接手就像考古。Trellis 让所有东西有了统一的「归档地址」。

它不追求单次使用的爽感，更像是长期沉淀的基础设施。

四、怎么选？一张决策树

别想着”6 选 1″。实际上你需要的是弄清楚自己最缺哪一层。

第一步：找最痛的点

• 需求总跑偏 → 从 OpenSpec 开始
• 代码质量太随意 → 上 Superpowers
• 长任务容易崩 → 用 GSD
• 需要多 Agent 并行 → 考虑 OMC
• 想做系统化增强 → 学习 ECC
• 多工具协作混乱 → 搭 Trellis

第二步：轻量组合（如果需要）

跑稳一层之后，可以考虑补第二层：

• OpenSpec + Superpowers：先保证做对的事，再保证做事的方式对
• OpenSpec + GSD：规格固定 + 上下文保鲜，双重保险
• OMC + Superpowers：多 Agent 编排 + 工程纪律

⚠️ 千万别一上来就叠三四层。 框架一多，规范重复、资产重叠、状态分散——系统本身可能比业务还复杂。

五、实战踩坑：老手们的教训

聊几条社区里反复验证过的经验：

📊 多 Agent ≠ 自动高效。 很多人以为 Agent 越多越好，结果发现：设计文档越来越厚、协调成本越来越高、真正落到代码上的产出反而没涨。核心问题是控制面膨胀——Agent 们忙着开会，没人干活。

🧹 长期能力比单次表现重要。 短会话里比的是”谁写得快写得像”，长任务里比的是”谁更不容易失忆”。能不能压缩历史、能不能生成交接文档、新会话接手时能不能快速恢复——这些才是真功夫。

🎯 把大愿望拆成小任务。 一次性把一大堆耦合需求扔给 AI，它不会线性变强，只会在复杂度里迷路。写清 spec → 拆成 task → 按阶段推进 → 每段留验证 才是稳的。

🧠 让贵的大脑做决策，让便宜的手做执行。 高阶模型负责架构判断和方向决策，执行型工具负责批量修改和重复工作。别让最聪明的模型泡在日志堆里磨时间。

六、说句实在的

Harness 不是银弹，也不该被当成公司强推的”又一个新规范”。它更像是 AI 编程从玩具走向生产工具的过程中，自然长出来的工程需求。

就像早年 JVM 调优——服务器只有 128M 内存的时候你不得不调；现在动辄 16G 了，很多时候不用手动管了。今天 Harness 里的不少做法，未来模型上下文窗口够大之后，可能也会被简化。

但现阶段，它就是让 AI 从”能写”到”能交付”的必要过程。

如果让我总结成一句话：

Harness 是一种思想，不是一套模板。核心是在使用中发现缺口，再把缺口补起来。

这个思路，就算未来模型再强，也不会过时。