这次不是从 Figma 开始了
Plocr-chef 从 Figma 设计稿出发，而「碎片」（Fragments）的起点更原始——一张手绘草图。
纸笔画出首页布局，拍照，描述给 AI。然后开始一个漫长的循环：截图 → 描述问题 → AI 改代码 → 再看 → 再截图……
第一步：纸和笔
「碎片」是一个生活记录小程序，灵感来自 Claude Monet 的印象派色调。最初的想法是一叠卡片的交互形式——首页展示一张大卡片，左右露出相邻卡片的边缘，底部有导航点。
我在纸上画了这张草稿：中间一张大卡片（带内容），左右各露出半张卡片的边缘，底部三个导航图标加一个滑动指示器。
✏️ 手绘草图 vs Figma
手绘的优点：快，10 分钟画完，不需要打开任何软件。缺点：不能精确描述颜色、间距、动画。这意味着 AI 需要更多轮次的「看图改图」才能接近预期的效果。
第二步：描述给 AI，生成 HTML 线稿
把手绘草图的照片发给 AI，口头描述交互逻辑：
- 一套卡片叠放布局，当前卡片居中放大
- 左右可滑动切换
- 每张卡片不同类型（体重、心情、愿望、笔记）
- 底部导航栏有三个入口
- 莫奈风格的色彩
AI 生成了一份完整的 HTML 页面，用纯 CSS 实现了卡片叠放、玻璃态效果、滑动切换。这个 HTML 就是在浏览器里看的样子——和微信小程序还有很大距离，但交互概念验证够了。
第三步：漫长的手工调试循环
HTML 验证了概念后，开始在微信开发者工具里建项目。这里开始了一个极其磨人的循环：
截图 → 发给 AI 描述问题 → AI 改代码 → 粘贴 → 再看 → 新截图 → 再描述 → 再改这个循环里踩了无数微信小程序的坑，值得单独列出来：
⚠️ 记住这个列表，以后可能还会遇到
踩坑记录
| 问题 | 原因 | 解决 |
|---|---|---|
<nav> 标签不渲染 | 微信小程序不支持 <nav>，只能用 <view> | 全部换成 <view> |
inset: 0 无效 | 小程序 CSS 不支持 inset 简写属性 | 分别写 top/right/bottom/left: 0 |
模板里 }}rpx 解析失败 | WXML 会把 }}rpx 的 rpx 当成模板语法一部分 | 用 }} 闭合后加空格再接 rpx |
| 卡片上出现「true」文字 | WXML wx:if 布尔值渲染 bug | 数据在 JS 中预计算后在模版渲染 |
| 玻璃态元素看不见 | 背景透明度初始设太低（0.18），在莫奈渐变背景上消失 | 透明度从 0.18 提到 0.34~0.48 |
page-container 无效 | 微信 webview 模式不支持该组件 | 改用纯 CSS overlay 方案 |
这些坑没有一个是「读文档能提前知道的」——大部分是跑起来之后才发现的。这也是为什么 vibe coding 到中期需要大量人力介入调试。
第四步：手绘 vs Figma 的取舍思考
做完两个项目后，对手绘草图和 Figma 两种路径有了实际体会：
| 手绘草图 | Figma | |
|---|---|---|
| 启动速度 | 10 分钟 | 2-3 小时 |
| 精确度 | 低，需要大量调试 | 高，AI 可直接照着实现 |
| 适合场景 | 探索期、快速试错 | 设计已定、追求还原度 |
| 与 AI 协作效率 | 需要更多轮次「看图改图」 | 一次性描述即可生成 |
「碎片」走的是手绘路线，因为它是一个更偏实验性的项目——设计风格在开发过程中不断调整（莫奈色调是后来才定下来的）。如果一开始就用 Figma 画死，反而会限制很多后来才想到的好点子。
下一篇写「碎片」的完整设计系统：莫奈色卡、玻璃态组件体系、卡片翻转机制和 8 色笔记循环。