同一套流水线，三个产品最重的一步完全不同
上一篇 我把 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——类目级视觉语言的三种变体，手机 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 要管的那种活。task 有 3 个以上，文件互不相干，活是机械的，套的是已知的模式，这回只是第 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 工作流推倒重来了四次 ——
- 产品系列：
