两个月，我把 AI 工作流推倒重来了四次
三月中。改识川一个功能，牵涉七个文件。裸 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 之外。
| 项目 | .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 文本全塞在主线程。
说白了手里两个对了一半的 harness。GSD 并行波次强但小活淹在规划仪式里。superpowers 轻但长跑上 orchestrator 不如 GSD 精简。
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 migration。auth-payment——依赖里有 Stripe / Better-Auth / NextAuth / Lucia。playwright——依赖里有 @playwright/test。backend-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 产物——是真的。但 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。按工作形状挑。
琐碎改动——vanilla。内容/视觉——vanilla 或 light-profile big-task。标准 feature、设计锁死——superpowers 的 subagent-driven-development。多 phase 实现、跨文件可并行——GSD 的 execute-phase 引擎。spec 不清、架构决策——superpowers 的 brainstorming → spec → plan 链。
前三轮犯的同一个错：先挑 harness，再逼工作去匹配。对所有事用 GSD，3 文件小 feature 一半 token 花在规划仪式上。对所有事用 superpowers，长跑串行拖慢。对所有事用 vanilla，中等活撞 context。
关键是知道什么活该用什么 harness。上面的 orchestrator 只是一个路由。
链接：
- 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