同一套流水线，三个产品最重的一步完全不同
上一篇 我把 claude design + big-task 这套流水线讲成了线性的：brief → 六方向探索 → 选一个 → HANDOFF.md → ship。纸面上是这个顺序没错。实际跑的时候，同一套流水线放到三个产品上，跑出来是三个完全不同的样子。原因也简单：每个产品的起点状态不一样，ship 的约束也不一样，流水线里最重的那一步自然就落在不同的地方。
同一条流水线放到三个产品上，起点状态不同，流水线里最重的那一步就落在不同位置
这篇就把三个案例摆开讲一遍。
ÉLAN：从零开始，探索得铺够宽
ÉLAN 的起点是什么都没有。没有 codebase，没有现成的视觉语言，只有一段话的 brief——一个给创作者的日记 app——加上一点直觉，觉得它应该慢一点、有触感一点。
这种情况下，流水线里最重的是探索（第 2 步）和方向 study（第 5 步）这两步，而且上游一步都省不掉。因为没有任何约束把你往某个方向拉，探索就只能铺得够宽，宽到把可能性大致都盖住。
具体流程就是上一篇讲的那个：六个方向探索 → 收敛到三个 → 选中 Film Stock → 方向 study → HANDOFF.md → big-task 的 ui profile。
ÉLAN 三个决选方向——Film Stock / Chiaroscuro / Field Notes——每个都带完整的字体、色板和样本屏
整个过程里最花时间的反而是第 4 步，选。三个方向都成立，都能做，我看了半天才定下来。这里面的比例挺有意思：那些支撑决定的探索，二十分钟就全生成完了，做决定本身反而花了半天。我觉得这挺合理的，探索现在已经很便宜了，反正贵的还是人自己做判断这一步。
big-task 这边，ÉLAN 的 repo 一旦有了 HANDOFF.md、directions/*.jsx 和 Playwright，Phase 0.0 就自动把它识别成 ui-project。之后每个 UI phase 都强制走视觉验证——Playwright 截图，每张 PNG 派一个 subagent 并行去看。24 张 PNG 就是 24 个 subagent，主线程只做一件事，把它们的 verdict 聚合成一个 matrix，自己不看图。
识川：app 已经上线，只能按类目一个一个迁
识川的起点完全是另一回事：app 已经上线了。初版 UI 能用，但七个产品类目——冥想、占卜、产品摄影这些，每个都有自己的怪毛病——视觉上漂移得很厉害。品牌 DNA 成形了一半，还没锁死。
所以流水线到这儿直接跳过探索。方向早就定了：东方静思、衬线为主、大地色系。没定的是这个方向在七个类目之间怎么展开。于是最重的一步变成方向 study（第 5 步），而且这个 study 是按类目一个一个做的。
识川方向 study——类目级视觉语言的三种变体，手机 mockup 展示各方向怎么处理内容摄影、文字、导航
为什么不能像 ÉLAN 那样一把全换？因为它是个活的 app。一次 ship 就把整个 UI 推倒重来，老用户会直接懵。所以迁移的单位是类目：一次迁一个，每个类目走自己的 Playwright 验证，每个类目作为独立的 phase 去 ship。
流水线于是长这样：
- 用 claude design 定视觉 DNA（一个方向，不是六个）。
- HANDOFF.md 装品牌级 token（字体、色板、动效）。
- 七个类目，每个跑方向 study，生成类目专属的
directions/category-X/*.jsx，在big-task开一个 phase。 big-taskPhase 0.0 识别ui-project，走 Tier 3 GSD-lite，类目级 Playwright 验证。- ship 这个类目，观察一下，再进下一个。
这一单真正贵的地方不在设计本身，在七个类目之间的一致性。每个类目都有自己的遗留布局怪癖，你要品牌自洽，又要尊重每个类目自己的 UX，两头都得顾。实际做起来，这比 ÉLAN 那种从零开始的场景难多了。impeccable:normalize 在这儿真的值回票价——它去审计每个类目跟设计系统之间的漂移，直接标出哪个类目的哪块屏走偏了。
到 big-task 这层，类目逐个迁移正好是 Tier 3 GSD-lite 针对的场景——3 个以上的 task、文件互相独立、活是机械的、模式是已知的第 N+1 次应用。所以 subagent policy 选的是 parallel-worktree：每个类目一个 worktree，implementer subagent 并行跑，互相不踩脚。
盘盘猫：monorepo，三个表达并行跑
盘盘猫的起点又是第三种：一个 monorepo，里面好几个 surface——Telegram bot、web、admin dashboard、mobile。v1 已经上线，v2 重设的要求是把视觉语言统一起来，但不能把任何一个 surface 的个性做没了。
这次探索步还是跑的，但目的变了：品牌 DNA 已经锁死——东方玄学、阴阳、中文字体——方向没什么好选的，跑探索是为了给这个 DNA 做不同的表达。所以跑了三个并行的表达：纸本（warm cream）、夜观（indigo + 墨金）、现代（off-white + 玉色）。这三个之间没有竞争关系，都是同一种视觉语言底下的主题，或者说三套皮肤。
盘盘猫 v2 重设——三个并行品牌表达：纸本（暖米白）、夜观（靛蓝 + 墨金）、现代（浅白 + 玉绿），代表性手机屏
为什么要三个？因为不同 surface 面对的受众不一样。占卜流程要庄重感，配夜观；onboarding 要亲切，配纸本；分析和 dashboard 要清晰，配现代。硬逼一个表达去覆盖所有 surface，至少有两个会不对劲。但这些 surface 又必须让人一眼看出是同一个产品，这部分靠的就是共享的那份品牌 DNA。
Notion 和 Linear 处理暗黑/浅色模式大概是类似的思路，只不过我这三套主题是按 surface 的角色选的，不是按用户偏好选的。
盘盘猫 landing page——阴阳主导的 hero，深色调，东方字体语言。夜观表达的代表
monorepo 到了 big-task 这层，路由本身就会变。Phase 0.0 看到多个 app，加上 design-ref（docs/redesign-v2/ 里的 HANDOFF.md）；Supabase schema 和支付这两个依赖，又让 tier 直接比 ÉLAN 和识川高一级。所以盘盘猫走的是 Tier 4 的 full GSD，通过 gsd-autonomous——这个重设跨 monorepo 里多个 app，phase 之间还有依赖：先出设计 token 包，再到组件库，再铺到各个 surface app。
Phase 4 的 8 轨清理也是在 monorepo 层面跑的，每个 package 一组并行 agent。到验证阶段，subagent 怎么派就更关键了：4 个 surface × 3 个表达 × 每个大概 8 条 route，差不多 96 张 PNG。主线程聚合 96 个结构化 verdict 没问题，但让主线程自己去读 96 张原图，肯定爆。所以底线还是那条：每张 PNG 单独派 subagent。
验证时每张截图单独派一个 subagent 去看，主线程只聚合它们的判定矩阵、自己从不读原图
盘盘猫 v2 完整 app 屏概览——多个流程（首页 / 占卜 / 解梦 / 八字 / 卦象 / 分析）跨纸本表达一致呈现
回头看，三个产品跑的确实是同一条流水线，变的只是起点状态，以及流水线里最重的那一步落在哪儿。big-task Phase 0.0 干的就是识别你的产品处在哪种状态，然后把活路由到对的跑法上。它识别对了，下游那些步骤自然就顺了。
延伸阅读：
- 本系列前两篇：
- 两个月，我把 AI 工作流推倒重来了四次 ——
big-task是什么、为什么存在。 - 一下午出六个设计方向 ——流水线的线性形态。
- 两个月，我把 AI 工作流推倒重来了四次 ——
- 产品系列：