从 Stitch 原型到 Flutter 产品：YourDiary Plus 的 AI 前端设计实践
YourDiary Plus（你记plus）是我从零开始维护的一款 Flutter 客户端。它接入了原有的账号、同步、写日记、交换日记、图片、树洞和个人中心等能力，同时把 Android、iOS 和 Web 端的交互重新整理了一遍。
这轮迭代的时间很短，功能补齐的速度却很快。到目前为止，产品已经触达近千名用户。对我来说，值得记录的重点不在于用了多少工具，设计探索、原型验证和真实开发怎样连在一起，才是这次实践里更有价值的部分。
前端设计的瓶颈通常不在写代码
页面数量开始增加以后，最先变慢的地方往往是设计决策：首页应该让用户先看到什么，功能入口放在哪里，哪些页面需要保持情绪感，哪些页面可以更偏工具属性。如果这些问题没有提前想清楚，模型很容易把页面做成一个能运行的后台，或者每个页面都像来自不同的产品。
YourDiary Plus 的核心场景是两个人安静地交换日记。我希望用户进入首页后，先看到最近的记录和关系状态，再自然地写下今天；树洞、素材、服务中心和接口诊断等能力可以完整存在，但不能抢走主线。
这类产品需要先确定整体气质，再处理页面细节。颜色、字体、卡片、导航和动效之间只要有一处脱离主线，用户就会感觉界面是拼出来的。
先用 Stitch 把视觉方向摊开
我在早期设计阶段使用 Stitch 做视觉探索。相比只讨论“做一个好看的日记 App”，让模型同时生成今日、平行空间、树洞和我的页面，更容易看出一套风格能不能覆盖完整的产品路径。
这一轮我让 Stitch 生成了五组浅色主题：niji_blue、niji_red、cute_pink、hat_green 和 geigei_purple。它们共享同一套页面结构，只替换主题色和玻璃质感的细节。放在一起比较以后，哪些变化只是换色，哪些变化会影响身份表达和阅读层级，就清楚了很多。
Stitch 对我最大的帮助，是把视觉讨论从抽象形容词变成了可以并排比较的页面。颜色是否太抢，卡片是否太满，标题和正文的比例是否合适，用户一眼就能看出来。设计方向确定得越早，后面返工的成本越低。
HTML 原型让设计进入可运行状态
Stitch 更适合探索整体方向，模型本身的 HTML 生成能力则适合把方向做成可以操作的原型。我在项目里保留了 prototypes/glass-diary-v3.html，后续又补了今日页、编辑页和日记详情弹窗等 HTML 原型。
HTML 原型有一个很实际的好处：它比直接修改 Flutter 页面便宜得多。布局、间距、按钮位置、弹窗层级和移动端滚动方式都可以快速调整，设计还没有稳定时，不需要牵动真实接口和页面状态。
原型也让需求讨论变得具体。看到一个页面之后，我们可以直接讨论“这个入口应该放在这里”“这张卡片的信息太多”“详情页应该先展示正文还是留言”，讨论会从一段描述里的反复猜测，落到具体的页面和交互上。
确认页面结构后，我再把 HTML 里的视觉关系翻译成 Flutter 组件。这个过程的重点也不在于照着 CSS 逐行转换成 Dart，真正需要保留的是信息层级、组件边界和交互意图。Flutter 负责适配真实设备、接口状态和平台差异，HTML 原型负责让这些决定更早被看见。
前端 skill 把灵感收敛成规范
模型可以很快生成一个页面，但页面能不能长期保持统一，仍然需要一套明确的设计约束。我在设计过程中会结合 Claude Code 的 frontend-design skill，以及 ui-ux-pro-max 插件来辅助思考布局、字体、颜色、响应式行为、交互反馈和可用性问题。
这些 skill 除了提供风格方向，还会提醒我检查页面的主次关系、触控尺寸、空状态、错误状态和不同屏幕尺寸下的布局，也能减少模型反复生成“卡片加渐变加大按钮”的套路化结果。
我会把 skill 产出的方案当作候选设计，用它们做评审清单和探索工具，具体取舍仍然要回到产品场景。比如登录页可以有玻璃卡片，但输入框本身需要足够实，保证文字可读；树洞页面可以有更多内容，但首页的日记时间线不能因此变成信息流后台。
稳定下来的部分会被我写进项目文件，让它们在下一次开发时仍然可以被读取：
.stitch/DESIGN.md保存颜色、字体、间距、组件样式和 Stitch 生成提示。.trellis/spec/frontend/design-guidelines.md保存 Flutter 端的 Liquid Glass 规范、页面骨架、状态处理和组件约束。lib/design/glass_diary/保存日记产品的主题、卡片、图标、路由和阅读样式。lib/design/liquid_glass/保存玻璃背景、玻璃 surface 和降级配置。lib/design/responsive/处理 Web 和宽屏下的内容容器。
这样做以后，新页面可以沿着已有的设计系统继续扩展。模型需要补一个页面时，有具体文件可以读取，开发者也能快速判断它有没有偏离产品的视觉语言。
从视觉方向到功能补齐
我在实际开发中通常会按下面的顺序推进：
- 先确认用户路径和功能边界，明确这页要帮助用户完成什么事情。
- 固定背景、字体、卡片、TabBar 和主要操作入口，先把共同的页面骨架搭起来。
- 用 Stitch 和 HTML 原型验证视觉方向与交互层级。
- 选择一条真实功能路径接入 Flutter 和真实接口，尽早暴露加载、空数据、失败和权限问题。
- 按页面补齐功能，再把重复出现的视觉和交互抽成共享组件。
- 运行测试和真实设备验证，最后把确认过的规则写回设计文档和项目 spec。
这个顺序让我能同时推进两件事：一边快速看到页面，一边避免每做一个新功能就重新发明一套视觉。登录、日记同步、写作、图片库、平行空间、树洞和个人中心这些功能逐步补齐后，整个产品仍然像同一个系统。
这套组合真正带来的价值
它缩短了设计决定到真实反馈之间的距离。 以前一个页面可能要先讨论、画图、实现，再发现层级不对。现在可以先让 Stitch 生成方向，用 HTML 原型验证，再进入 Flutter。错误的方向更早暴露，调整也更轻。
它让功能补齐少一些对一致性的牺牲。 短迭代最容易留下临时页面：功能有了，入口能点，颜色和间距却各自为政。设计 token、共享组件和前端 spec 把这些决策留下来，模型继续开发时有可参考的边界。
它提高了产品对复杂功能的承载能力。 树洞、图片、交换日记和个人中心的场景差异很大，页面不能全部套成同一个模板。统一的是颜色、字体、卡片质感和交互节奏，具体页面仍然根据用户任务做变化。
它让 AI 的速度更接近产品价值。 模型生成代码的速度本身不能代表最终价值。设计方向清楚、原型可以验证、真实功能能快速接上，用户才有机会更早用到完整产品，开发者也能更快从反馈里发现问题。
到目前为止，YourDiary Plus 已经触达近千名用户。这个数字不能单独证明某一种设计流程一定有效，但它至少说明，短周期里把视觉方向、核心功能和真实使用连接起来，确实能让一个个人项目更快走出原型阶段。
AI 加速了设计，产品判断仍然要在场
Stitch 可以生成很完整的页面，HTML 原型也能做出漂亮的交互；真实用户是否看得懂，接口失败、无数据、慢网络、键盘遮挡和低端设备性能，则需要继续放回真实环境里验证。
所以我会把 AI 产出的页面当作候选方案，继续用真实数据、真实设备和测试去检查。玻璃效果要看性能，字体要看长文本，卡片要看异常内容，按钮要看触控尺寸。设计只有进入这些具体场景，才算真正完成了一部分。
YourDiary Plus 让我逐渐形成了一套比较稳定的前端工作方式：先用 AI 扩展设计空间，再用 HTML 原型验证交互，用 Stitch 和 skill 帮助收敛视觉语言，最后把确定的规则沉淀进 Flutter 组件和项目 spec。AI 把前端迭代的起点往前推了很多，产品方向、用户场景和最终取舍仍然需要由人负责。
