目录膨胀到 68 张卡之后
68 张灵感卡重新分类
这个 session 本来是修 bug 的。
五个积攒了几天的小毛病，都不难，修完就去干别的。但修到一半来了个用户需求："能不能加旅行目的地的灵感卡？香港、日本、东南亚那种。"
十二个小时后，ÉLAN 从 31 张灵感卡变成了 68 张，浏览分类系统推倒重来，我一个人编排了 37 个卡定义、37 张封面、444 张样本图。
卡不难做。难的是我发现——导航坏了。
先把桌上的烂摊子收了
碰新功能之前，得先清桌面。五个问题：
文案生成在 Web 端跑了两遍。 服务端已经通过 SSE 并行生成了文案，移动端正确地消费了这个流，但 Web 端直接无视了服务端的返回，自己又调了一遍。同样的活干两次，API 白烧了好几天我才发现。
Gemini 有两条内容拦截路径。 这个坑我踩了两次才搞明白。promptFeedback.blockReason 是 prompt 本身被拒（还没开始生成），candidate.finishReason === 'SAFETY' 是输出触发了安全过滤（已经部分生成了）。两个都得查。我之前只查了第一个，结果有些被拦截的输出悄无声息地返回了空结果，连个错误提示都没有。
微信内置浏览器。 Web 开发的特殊地狱。很多现代 API 不支持，blob URL 直接崩，JS 引擎还有自己的脾气。我的选择是不兼容——检测微信 user-agent，弹一个模态框解释情况，给一个"复制链接到浏览器打开"的按钮。有时候最对的修法就是不修。
图片太大。 Gemini 只出 PNG，一张 3-5 MB。用户在移动网络上等到花儿都谢了。服务端用 sharp 转 JPEG（quality 85），一下压到 600KB-1MB。视觉差异几乎看不出。
Zustand 闭包陷阱。 React 的经典坑：useEffect 捕获了 Zustand store 的旧引用。effect 跑起来读到的值是上一次渲染的。改成 getState() 在 effect 内部读最新值就好了。这种 bug 95% 的时候正常，5% 的时候让你怀疑人生。
五个 bug，半天。桌面清了。
一个用户需求，四个 agent 出动
用户需求很宽泛："旅行目的地——港澳台、东南亚、日本、云南、西藏、新疆、欧洲。"
七个地区。每个地区要好几个场景。每个场景要一整套灵感卡定义——场景配置、服装、Pose、调色、文案。手写 40+ 张卡？不现实。
我派了四个并行调研 agent，每个负责一块地区：
- 日本 — 神社、庭园、街景、时令景点
- 东南亚 + 港澳台 — 热带海滩、殖民建筑、夜市、天际线
- 国内 — 云南梯田、西藏高原、新疆沙漠、张家界
- 欧洲 — 地中海小镇、巴黎咖啡馆、瑞士雪山、冰岛
每个 agent 返回一份排了优先级的场景清单，附带 AI 生成可行性评分（1-10 分，衡量当前模型处理这个场景的能力）。
结果很有意思。
自然风光生成得很好。 梯田、薰衣草田、高山湖泊——干净的几何线条，一致的光线，没有可能出错的文字和精细细节。
标志性建筑也行。 鸟居、圣托里尼蓝顶、吴哥窟剪影。辨识度高的形状，强视觉标识。
密集文字和招牌不行。 涩谷十字路口、道顿堀、香港霓虹街——任何画面里有大量文字的场景。AI 生成的字符是乱码，一眼就穿帮。这些场景直接砍了。
人群也不靠谱。 夜市、庙会、街拍——需要逼真背景人群的场景容易出怪异感。我们只留了人物相对独立的构图。
40 个候选场景，筛完留了 37 个（可行性 7 分以上）。加上原来的 31 张，ÉLAN 有 68 张灵感卡了。
然后真正的问题来了。
68 张卡往里一塞，导航直接崩了
31 张卡的时候，原来的四分类标签系统没问题。远方的光、城市漫游、日常诗意、时令之美。每个标签 7-10 张卡。浏览、挑选、搞定。
68 张卡的时候，乱了。
我的第一反应是按地区分标签：日本 | 东南亚 | 欧洲 | 国内 | 港澳台。地理作为组织原则。看起来很合理——新卡本来就是按目的地做的。
但我在准备实现的时候自己停下来了。原因是三个问题：
桶大小不均。 国内 12 张卡，港澳台只有 3 张。有的标签点进去很丰富，有的点进去空荡荡。
相同氛围被拆开了。 巴厘岛海滩、三亚海滩、普吉海滩——三张情绪几乎一样的卡，分散在三个不同的地区标签里。一个想找"梦幻海滩照"的用户得翻三个标签才能看全。
用户不是按地理想的。 这是关键。
用户打开 ÉLAN 的时候，脑子里想的不是"我要一张日本照片"。想的是"我想要一张度假感的照片""我想要一张都市夜景""我想要一张有文化感的"。
说白了，心智模型是氛围优先，不是地图优先。
按地区分导航适合旅行预订 App——你已经决定去哪了。不适合灵感浏览 App——你在找一种感觉。
双轴方案
答案是两层系统：
主轴：氛围标签 — 你现在想要什么情绪？
| 标签 | 里面有什么 |
|---|---|
| 度假放松 | 海滩、泳池、度假村晨光——一切说"我在放松"的场景 |
| 自然秘境 | 雪山、梯田、森林、高原——原始自然之美 |
| 都市光影 | 天际线、天台、霓虹、街景——城市能量 |
| 文化体验 | 寺庙、茶室、传统建筑——厚重与底蕴 |
| 精致生活 | 咖啡馆、画廊、高级餐厅、SPA——日常的高级感 |
| 时令限定 | 樱花、红叶、初雪——限时场景 |
副轴：地区芯片 — 可选叠加筛选。
🇯🇵日本 | 🌴东南亚 | 🇭🇰港澳台 | 🇪🇺欧洲 | 🇨🇳国内
芯片排在氛围标签下面。点一下筛选当前氛围里的特定地区，再点一下取消。默认显示全部地区。
这意味着用户可以：
- 浏览"度假放松"，同时看到巴厘岛、三亚、普吉、圣托里尼的海滩——因为氛围一样
- 然后点 🇯🇵 只看日本的度假场景
- 或者完全不管地区，纯按心情浏览
原来的 31 张卡自然吸收进了新分类。"远方的光"按实际氛围拆到了"度假放松"和"自然秘境"。"城市漫游"整体进了"都市光影"。没有硬塞。
为什么这样做
氛围优先解决了那三个问题：
- 桶均匀。 每个氛围标签 8-14 张卡，没有空标签。
- 相同氛围聚在一起。 所有海滩卡在一个标签里，不管哪个国家。所有寺庙卡在另一个。
- 匹配用户心智模型。 打开 App，选心情，可选缩小地区。浏览流程和人的实际想法一致。
这个分类讨论花了大概 30 分钟。实现花了一个小时。但这是整个 session 里最重要的设计决策——因为没有它，68 张卡就是一面让人选择恐惧的墙，而不是一个能逛的目录。
37 张卡怎么生出来的
分类定了，得真的把 37 张新卡做出来。每张卡需要：
- 卡定义 — 场景配置、服装、Pose、调色、文案（~200 行结构化数据）
- 封面图 — 浏览时用户看到的缩略图
- 样本图 — 每张卡 12 张（4 棚拍 + 4 自拍 + 4 拍立得）展示效果
37 个定义 + 37 张封面 + 444 张样本图。一个 session。
卡定义：并行 agent 编排
37 张卡分给 4 个并行 agent：
- Agent 1：日本场景（8 张）
- Agent 2：东南亚 + 港澳台（10 张）
- Agent 3：国内（11 张）
- Agent 4：欧洲（8 张）
每个 agent 拿到 MuseCard 的 TypeScript 接口定义、三张现有卡作为风格参考、以及分配到的场景清单。输出：完整的卡定义文件，四个 agent 加起来大约 7000 行结构化数据。
其中一个 agent 写到一半撞了 token 上限——11 个卡定义一次性输出太长了。解决办法：拆成两个子 agent，每个写 5-6 张。
实践中的编排经验：即使是大上下文窗口，生成几千行结构化数据也有天花板。得提前规划。
封面图：批量生成
37 张封面通过 Gemini API 生成，视觉语言和现有封面一致——干净、有向往感、不加文字。原始输出是 PNG（Gemini 的唯一选项），平均每张 2 MB。
批量转 WebP 后降到 ~150 KB——压缩 13 倍，浏览网格在手机上瞬间加载。
样本图：444 张
这是生产规模的挑战。37 张新卡 × 12 张样本：
- 4 张棚拍风格（卡的 Pose 序列）
- 4 张自拍风格（更近、更随意、不同角度）
- 4 张拍立得风格（胶片感、方构图、柔和调色）
按卡分批生成，每批用卡的完整 prompt 系统跑参考面部图像。
面部漂移 QC
产量上来了，质量控制就是真问题了。最大的失败模式：面部漂移——生成的面部偏离参考照片，输出不像用户本人。
我用 Gemini Flash 建了一个 QC 管线。每张生成的样本和参考面部图像做对比，Flash 打 1-10 的相似度分。低于 7 分的标记重新生成。
第一轮：95.2% 通过率。444 张里 21 张被标记。
重新生成后：~97%+ 通过率。剩下几张是极端角度或重阴影的边缘案例，漂移不可避免。
一个人，一个 session
一个人编排了 37 个卡定义、37 张封面、444 张样本图。不是团队。不是工作室。一个人加 Claude Code 的并行 agent 加 Gemini 的图像生成。
这就是超级个体的日常——不是理论，是周二下午的现实。瓶颈不在生成（AI 搞定），不在质控（自动化），在决策：选哪些场景、怎么分类、往什么审美方向推。
人的工作是品味和判断。其他的都能规模化。
加东西容易，重新想"怎么逛"才难
目录 3.8 倍增长，加卡是容易的。重新想"用户怎么逛"才难。
氛围优先的分类没有被规划过。它不在任何路线图上。它是内容体量和导航简洁性之间的张力逼出来的。
如果我把 37 张新卡塞进老的四分类系统，每个标签 15-20 张卡——选择恐惧症警报。内容的扩张逼出了一次导航重设计，这个重设计连原来的 31 张卡都受益了。
我反复看到一个模式：内容创建的速度超过了信息架构的速度。 一下午能生成 37 张卡。一下午能不能设计好分类？除非内容的压力逼着你想。
Bug 挺烦的。扩张挺兴奋的。但那 30 分钟的分类讨论——推倒了整个浏览体验——才是这一天最值钱的事。
有时候，最好的产品洞察来自你自己制造的问题。 内容跑在前面，架构被迫跟上——这种压力反而逼出了对的设计。
第一篇：不经意的优越感 | 第二篇：架构 | 第三篇：灵感卡设计 | 第四篇：从 Web 到移动端 | 第五篇：衍生品 | 第六篇：发现体验重设计
This post is also available in English.