两个月，我把 AI 工作流推倒重来了四次
那个让 vanilla 崩盘的 session
三月中。我在改识川一个功能，牵涉七个文件。用的是裸 Claude Code，没脚手架也没 skill，就主线程自己干。改到第四个文件，主线程已经塞满：所有读过的文件原文、每次跑失败的测试输出、我对每次迭代的评注。上下文到 80%。我只能打断，跑 /compact，眼睁睁看模型丢掉三十分钟的细节状态。
那一刻我才认了：裸 Claude Code 是 tier-1/tier-2 的工具。单文件、单函数、单问题，完美。再大一点，主线程就是 context 垃圾场。
那之后我把 AI 工作流推倒重来了四次。每次都是被一个具体 session 逼的，不是"这看着挺酷"的跟风。下面是这四版的轨迹、崩盘点，和我最终留下的东西。
Harness 1：vanilla
就它： 裸 Claude Code。主线程读文件、改文件、跑命令。没 subagent，没 skill。
好用在： tier-1/tier-2——一个 hotfix、一个打字错、改一个函数、问一个问题。这种活儿主线程信噪比高。
崩在： 一旦超过两三个文件，或者得反复跑测试，或者想并行干点别的，它就撑不住。主线程会吞掉每次读的文件、每次测试输出、每次推理。10 文件 feature 加 TDD，一小时内主线程必 80%。
这不是 Claude Code 的 bug。只是"一个线程干所有事"不适合团队规模的活。solo dev 的活干到后面，也会越来越像团队规模。
Harness 2：GSD
就它： get-shit-done (GSD)，TÂCHES 做的多 agent 框架，把活拆成 phase。每个 phase 跑一条 skill 链：gsd-discuss-phase → gsd-plan-phase（内置 plan-checker agent）→ gsd-execute-phase → gsd-verify-work → gsd-audit-fix。规划和执行都 subagent 做。状态落盘在 .planning/。
好用在： 真的大活。我用 GSD 跑过识川一次完整重设——schema 迁移、新子系统、跨 phase 依赖。多 agent 规划在执行前抓出过真 bug。Execute-phase 的并行波次跑的时候我能干别的事。GSD 的 execute 引擎主线程只占 ~15%——subagent 自己从磁盘加载 plan，只回结构化 summary 不回原文。真正的 tier-4 活，这套纪律值它的搭建成本。
崩在： solo dev 的 tier-3 活，GSD 过度工程。每个 phase 会生成六个 meta 产物——CONTEXT.md、PATTERNS.md、RESEARCH.md、REVIEW.md、VALIDATION.md、VERIFICATION.md——都在实际 PLAN.md 之外。我从两个 repo 里拉了 .planning/ 的行数：
| 项目 | .planning/ 行数 |
|---|---|
| 识川 | ~21,000 |
| ÉLAN | ~24,000 |
其中有些文档确实抓到了真 bug。大部分是同一个"要做什么？风险在哪？会崩在哪？"的 checklist 被六个略微不同的框架重复问一遍。对 solo dev，把六份读完比代码本身还长。
我用了 GSD 大概三周，每次想 ship 三文件的小活儿都在心里咒它。但真想扔掉的时候又发现，多 agent 规划确实抓出过我会 ship 错的东西。所以不能直接丢。
Harness 3：superpowers
就它： superpowers，Jesse Vincent 做的 skill 库，大约 14 个通用 skill：brainstorming、writing-plans、subagent-driven-development、requesting-code-review、verification-before-completion、test-driven-development、using-git-worktrees、dispatching-parallel-agents 这些。没 phase 结构，没 .planning/——哪个 skill 适用你自己调。
我喜欢的地方：
- Skill 可组合。按当前活儿挑匹配的，不走固定 phase 链。
subagent-driven-development每 task 起新 subagent，两段 review（先 spec 合规、再 code 质量），merge 前抓 spec 漂移。- session-start hook 自动把 meta-skill
using-superpowers注入每个 session，告诉模型"只要有 1% 概率某个 skill 适用你就必须调"。强势，但管用——我再也没漏调过 skill。 - skill 明写 "user instructions > skill instructions"。优先级对。
崩在：
第一，auto-injection 每 session 固定 ~5,000 token。不管这对话用不用 skill 这税都得交。
第二，更关键，subagent-driven-development 明文串行。原文：Never dispatch multiple implementation subagents in parallel (conflicts)。对共享文件实现任务这是对的——两个 agent 改同一个文件就是 merge 灾难。但这意味着 superpowers 做不了 GSD execute-phase 那件事：跨独立文件的并行波次。跑长时自动 session，superpowers 每 task 串行，每 task 三个 subagent（实现者 + spec 审查 + 质量审查），主线程协调整个序列，所有 task 文本全塞在主线程里。20 task 的 plan，controller 主线程 context 涨得比我预期快。
说白了这时候我手里两个对了一半的 harness。GSD 并行波次强但小活淹在规划仪式里。superpowers 轻但长跑比不上 GSD 的精简 orchestrator。
Harness 4：big-task
就它： 我自己写的一个 orchestrator skill，把前三个藏在一个记得住的名字后面。描述的活涉及 3+ 文件或引入新功能时它自动触发。选哪个底层 harness 按工作形状，不是默认某一个。
它不是要替代那三个，是路由。big-task 不重新实现 TDD，合适时委托给 tdd-workflow。不重新实现 subagent dispatch，委托给 superpowers:subagent-driven-development 或 gsd-execute-phase。它唯一的活是选对。
Phase 0.0：自动检测项目形状
任何 tier 决定之前，big-task 把项目分成四种 workflow profile 之一：light、ui、heavy 或 unknown。跑一个 bash 启发（~1 秒）收集信号：
content-N—content/posts/、_posts/等里的 markdown 文件数components-ui—components/目录 +package.json里有 UI 库（tailwind / radix / shadcn / mui / chakra）design-ref—HANDOFF.md、directions/、docs/design/任意一个存在schema— Prisma / Drizzle / Knex 配置，或 SQL migrationauth-payment— 依赖里有 Stripe / Better-Auth / NextAuth / Luciaplaywright— 依赖里有@playwright/testbackend-lang— 检测到 Go、Rust 或 Python
首次匹配胜出：content ≥ 20 → light（270 篇博客就算有 components 目录还是 blog）。schema 或 auth-payment + backend-shaped → heavy。components-ui 或 design-ref → ui。
这是 repo 形状。但不是全部。
Phase 0.0 第 2.5 步：任务意图（判断，不是关键词匹配）
repo 扫描回答"这 codebase 是什么形状"。它不回答"这次请求是什么形状"。blog repo 是 light，但"给 premium 文章加 Stripe paywall"是 heavy 任务，只是碰巧落在 light repo 里。这种事我不在乎 repo 信号怎么说——它跨了 trust boundary、动了 revenue 路径，不管 repo 什么形状都得走 heavy。
第一版我用的是关键词匹配。扫描任务描述里有 stripe / auth / migration / schema → 强制 heavy。这种做法错得最愚蠢——我本来就是个 LLM 在读任务描述。在 LLM context 里拿 regex 过自然语言是反模式。有人说"我昨天在看 Stripe 的 API"和"集成 Stripe 支付"完全不是一回事，但两句话都有 Stripe 这个词。
改法：关键词列表换成判断标准。skill 现在让我分类这任务对系统做了什么：
- 本质重活 — 持久化变更、trust boundary、revenue 路径、原子性/并发、跨系统合约、引入新架构子系统
- 本质轻活 — 书面文字、纯视觉微调、单一稳定 schema 的配置改动
- UI 性质 — 套用已有设计模式、已知模式的第 N+1 次应用
这些还定不下来时还有几个框架问题：爆炸半径（客户的钱 vs 糟糕的下午）、可逆性（git revert 还是数据迁移回滚）、是设计决定还是设计翻译、模式新颖度。
组合规则按顺序：本质重 → heavy 不管 repo。本质轻 → light 不管 repo。引入新模式 → max(repo, 上一档)。其余用 repo profile。
新规则比我的关键词列表还短，而且更对。
Subagent 派发策略
这是最后一块，今天才加。big-task 里每个 phase 现在带一行 Subagent policy，按工作性质选，不按 tier：
| 模式 | 何时用 | 主线程占比 |
|---|---|---|
| parallel-worktree | 独立文件上的实现 | <20% — 每个 subagent 在自己的 worktree 写 |
| parallel-readonly | 调查、审查、审计、视觉验证 | <20% — 每个目标一个 subagent |
| serial-subagent | 共享文件上的实现 | ~30% — superpowers 的 subagent-driven-development，每 task 新 context |
| inline | 单文件改、tier-2 hotfix、琐碎决策 | 100% |
我强制的规则是：tier ≥ 3 且独立任务 ≥ 3 时，绝不 inline。再大还 inline 主线程必臃肿，subagent 架构的整个意义就没了。
orchestrator 纪律跟模式选择一样重要：
- Subagent 自己从磁盘加载输入。主线程不把 task 全文塞进每个 subagent prompt。superpowers 的 controller 在 20 task plan 上就是这么不小心囤了 context。
- Subagent 回传结构化 summary ≤200 token，不是原始输出。
- 状态在磁盘，不在 chat history。
- 并行前用 worktree 隔离——这样就绕过 "禁止并行实现者" 的共享状态门槛。
进 phase 时声明模式：Phase 2b · parallel-readonly (4 routes)。让路由可审计。也抓得住 inline 滥用——要是我连续三个 phase 都声明 inline 而且还是 tier-3 活，那一定哪儿错了。
GSD 身上有件事我两个月才看懂
这里有件我差点扔掉的东西。GSD 的规划开销——每 phase 六个 meta 产物——是真的。但 GSD execute-phase 引擎本身是精简的。Orchestrator 在 ~15% 主线程 budget，因为 subagent 自己从磁盘加载 plan 回传 summary。对长时自动跑——你不在旁边盯着、想让实现自己走完那种活——这套纪律无人能敌。
我之前把规划开销和执行开销搞混了。想扔 GSD 的时候，我其实想扔的是 gsd-discuss-phase 和 gsd-plan-phase 那套仪式，不是 gsd-execute-phase 的机制。花了点时间才把这俩分开。
现在的 big-task 配置尊重了这一点：tier-4 多 phase 实现、依赖图清楚、预计跑数小时的活，它路由去 gsd-autonomous。spec 不清楚、架构决策比吞吐量更重要的探索性 feature，路由去 superpowers 的 brainstorming → writing-plans → subagent-driven-development 链。没单一默认。
想对你说的
如果你是 solo dev，中等规模的活总撞 context 上限，那你大概率需要一套 harness。但别把某一个 harness 当默认。按工作形状挑：
- 琐碎改动 — vanilla
- 内容 / 视觉 — vanilla 或 light-profile big-task
- 标准 feature、设计锁死 — superpowers 的 subagent-driven-development（两段 review 很强）
- 多 phase 实现、跨文件可并行 — GSD 的 execute-phase 引擎（长跑精简 orchestrator）
- spec 不清、架构决策 — superpowers 的 brainstorming → spec → plan 链
我前三次犯的错都一样：先挑 harness，再逼工作去匹配。对所有事用 GSD，3 文件小 feature 一半 token 花在规划仪式上。对所有事用 superpowers，长跑串行拖慢。对所有事用 vanilla，中等活撞 context。
Harness 得跟工作形状匹配。上面套的那个 orchestrator（我这儿叫 big-task）不是重点——它就是个路由。重点是知道该路到哪，而这要求你知道这次到底是什么活。
链接：
- big-task skill：github.com/xingfanxia/claude-config/blob/main/skills/big-task/SKILL.md
- GSD（TÂCHES）：github.com/gsd-build/get-shit-done
- superpowers（Jesse Vincent）：github.com/obra/superpowers