技术方案的关键词：极简

「碎片」的架构可以概括为一句话：一个云函数 + 一个注册页面 + 一个边缘数据库 + 四个自定义组件。但这套极简架构背后，解决了不少实际问题。

app.json 里只注册了一个页面 pages/home/home，另外两个视图（时间线、设置）全是 CSS Overlay。

一、从多页到单页：消除白屏闪烁

最初「碎片」和普通小程序一样，每个视图一个独立页面。但微信小程序的页面切换在 webview 模式下有白屏闪烁——哪怕用了动画过渡，切换时还是会闪一下。

解决方案：把所有视图放在一个页面里，用 CSS 控制显示隐藏。app.json 只注册一个页面：

// app.json{  "pages": ["pages/home/home"],  "renderer": "webview"}

时间线和设置面板是 CSS overlay 浮层，从右侧滑入：

<view class="overlay-mask" bind:tap="closeTimeline"></view><view class="overlay-panel panel-slide-in" wx:if="{{showTimeline}}">  <timeline-view></timeline-view></view>

CSS：

.overlay-panel {  position: fixed;  right: 0;  top: 0;  width: 85%;  height: 100vh;  z-index: 100;  transform: translateX(100%);  transition: transform 280ms ease-out;}.panel-slide-in { transform: translateX(0); }

二、Turso 边缘数据库 + 云函数代理

数据库选的是 Turso——一个基于 libSQL（SQLite 的 fork）的边缘数据库。每个查询路由到离用户最近的只读副本，延迟很低。

但微信小程序不能直连 Turso（不支持 libSQL 的 HTTP2 协议），所以中间加了一层 腾讯云函数 做代理。

整个后端只有一个云函数 tursoProxy/index.js（357 行），负责所有操作：

云函数通过 cloud.getWXContext() 获取用户的 openid，零配置实现用户身份识别。

三、缓存优先策略

为了让用户打开页面「秒看内容」，实现了双层缓存：

读取: 内存 → wx.getStorageSync → 显示（立即）写入: 内存 + wx.setStorageSync（同时）网络: 后台静默拉取最新数据，更新缓存

三个缓存桶：

• __fg_cache_cards__ — 卡片列表
• __fg_cache_records__ — 时间线记录
• __fg_cache_weight__ — 体重历史

效果：即使手机刚开机第一次打开小程序，也是立即看到上次的数据，1-2 秒后如果网络数据更新了会自动替换。

四、JWT Token 失效自动恢复

登录用 JWT（30 天有效期），但总有过期的时候。在 API 请求中，如果捕获到 Token 错误，自动调用 auth.login() 刷新 Token，然后重试失败的请求。调用方完全无感知。

这个机制在 home.js 的 loadWeightHistory() 中实现：

if (err.code === 'TOKEN_EXPIRED') {  await auth.login()  return await api.records() // 自动重试}

五、styleIsolation 陷阱

自定义组件默认样式隔离（styleIsolation: isolated），但时间线组件需要继承全局的 .paper-sheet、.chip-glass 等样式类。解决方案是显式声明：

{  "component": true,  "styleIsolation": "apply-shared"}

这样组件既能使用全局样式，又能覆盖自己特有的样式。

六、数据库：5 张表 + 7 个索引

Turso 上建了 5 张表：

• users — 用户信息（openid 为 PK）
• cards — 卡片数据（type, title, content, colors, data JSON 等）
• records — 时间线记录（关联 card_id）
• weight_history — 体重历史（始终存 kg，前端显示时转换斤/公斤）
• wish_items — 愿望列表（关联 card_id，级联删除）

七、免费方案总结

这套设计系统不是从零想的——是从莫奈的画里偷来的

「碎片」的配色直接取自莫奈的印象派画作：睡莲的绿、日本桥的蓝、日落的珊瑚、玫瑰园的红……然后包装成一套 CSS 变量 Token。

设计系统的核心是：用 8 个颜色 Token 支撑起 4 种卡片类型、6 种玻璃组件、2 种布局模式。

一、莫奈调色板

从莫奈的《睡莲》《日本桥》《日落》等画作中提取了 8 个颜色 Token：

背景是一个三层渐变 + 模拟画布纹理：

background:   linear-gradient(150deg, #ecdfc8 0%, #dbe8e2 54%, #bfd6d1 100%),  repeating-linear-gradient(0deg, transparent, transparent 56rpx, rgba(0,0,0,0.02) 56rpx, rgba(0,0,0,0.02) 57rpx);

这个渐变的三个颜色分别对应莫奈画中的草地、水面、天空——也是这个项目名字「碎片」的由来：把一幅画拆成色块，散落在交互里。

二、玻璃态组件体系

6 种玻璃态组件类，每个都用统一的毛玻璃公式：

background: rgba(255, 255, 255, 0.34~0.48)backdrop-filter: blur(10px)border: 2rpx solid rgba(255, 255, 255, 0.72~0.82)

透明度的数值经过反复调试：一开始设 0.18~0.26，在莫奈渐变背景上几乎完全消失。最终提到 0.34~0.48 才能看到清晰的玻璃质感。

三、卡片堆叠位置算法

首页的核心交互是一叠卡片，当前卡片居中，左右露出相邻卡片的边缘。这个位置计算用了一个 relativePosition() 函数：

function relativePosition(index, active, total) {  // 环形回绕：计算当前卡片到活跃卡片的偏移量  // 处理 wrap-around 情况（从最后一张划到第一张）  // 返回 -2, -1, 0, 1, 2 等相对位置}

每个相对位置对应一组 CSS 样式：

• pos-active（0）：居中，scale(1)，opacity 1，z-index 4
• pos-prev（-1）：左侧偏移 260rpx，scale(0.88)，opacity 0.82，z-index 2
• pos-next（+1）：右侧偏移 260rpx，scale(0.88)，opacity 0.82，z-index 2
• pos-far（其他）：translateY(36rpx)，scale(0.82)，opacity 0.28，z-index 1

滑动切换的阈值：Math.abs(dx) >= 50 && Math.abs(dx) > Math.abs(dy)——水平划够 50px 且比垂直滑动多才触发切换。

四、卡片翻转机制

每张卡片都可以翻转——正面显示内容，反面是表单（填体重、记心情、写愿望）。

实现上用一个 flipMap[cardId] 状态映射表，驱动 wx:if / wx:else 切换显示正面或反面。数据在 JS 中预计算（buildCardsState()），避免在模板中动态计算——这是为了解决 WXML 的「true 文字渲染」bug。

五、4 种卡片类型 + 笔记工厂

卡片按类型区分，每种的样式和交互都不一样：

笔记工厂是最好玩的设计——每次点「写笔记」按钮，系统自动生成一张新的笔记卡片，颜色在 8 色调色板中循环。这 8 个颜色也是从莫奈画作中提取的，每张新卡片都像从画布上撕下的一小块碎片。

六、底部导航指示器

底部导航栏有一个会滑动的绿色透镜，跟随当前激活的 Tab。实现上用 createSelectorQuery() 动态计算每个 Tab 的宽度，而不是写死偏移量——这样即使未来修改了 Tab 文案也不会断裂。

点击 Tab 时，图标有一个 200ms 的弹跳动画（scale 关键帧），这是除了卡片滑动外最常用的交互反馈。

这次不是从 Figma 开始了

Plocr-chef 从 Figma 设计稿出发，而「碎片」（Fragments）的起点更原始——一张手绘草图。

纸笔画出首页布局，拍照，描述给 AI。然后开始一个漫长的循环：截图 → 描述问题 → AI 改代码 → 再看 → 再截图……

第一步：纸和笔

「碎片」是一个生活记录小程序，灵感来自 Claude Monet 的印象派色调。最初的想法是一叠卡片的交互形式——首页展示一张大卡片，左右露出相邻卡片的边缘，底部有导航点。

我在纸上画了这张草稿：中间一张大卡片（带内容），左右各露出半张卡片的边缘，底部三个导航图标加一个滑动指示器。

第二步：描述给 AI，生成 HTML 线稿

把手绘草图的照片发给 AI，口头描述交互逻辑：

• 一套卡片叠放布局，当前卡片居中放大
• 左右可滑动切换
• 每张卡片不同类型（体重、心情、愿望、笔记）
• 底部导航栏有三个入口
• 莫奈风格的色彩

AI 生成了一份完整的 HTML 页面，用纯 CSS 实现了卡片叠放、玻璃态效果、滑动切换。这个 HTML 就是在浏览器里看的样子——和微信小程序还有很大距离，但交互概念验证够了。

第三步：漫长的手工调试循环

HTML 验证了概念后，开始在微信开发者工具里建项目。这里开始了一个极其磨人的循环：

截图 → 发给 AI 描述问题 → AI 改代码 → 粘贴 → 再看 → 新截图 → 再描述 → 再改

这个循环里踩了无数微信小程序的坑，值得单独列出来：

踩坑记录

这些坑没有一个是「读文档能提前知道的」——大部分是跑起来之后才发现的。这也是为什么 vibe coding 到中期需要大量人力介入调试。

第四步：手绘 vs Figma 的取舍思考

做完两个项目后，对手绘草图和 Figma 两种路径有了实际体会：

「碎片」走的是手绘路线，因为它是一个更偏实验性的项目——设计风格在开发过程中不断调整（莫奈色调是后来才定下来的）。如果一开始就用 Figma 画死，反而会限制很多后来才想到的好点子。

上一篇写了流程，这篇写代码

Plocr-chef 是一个有 11 个页面的微信小程序，后端用 Supabase 免费计划，前端全是原生 WXML/WXSS/JS，没有用任何 UI 框架。这篇记录它的技术实现要点。

整个项目前端代码约 4000 行，后端零代码（只有 Supabase 的 REST API）。

一、Supabase：CRUD + 图片 + 保活

后端用的是 Supabase 免费计划，提供一个 PostgreSQL 数据库和对象存储。没有写后端代码，直接从微信小程序发 REST 请求。

封装了一个 utils/supabase.js，暴露 6 个函数：

所有请求通过 wx.request 发送，请求头带 apikey 和 Bearer token。上传图片走 multipart，上传后返回公开 URL 存数据库。

数据库三张表：

dishes    — id, name, category, price, recipe, image_urlorders    — id, date, status, items (jsonb), totalwishlist  — id, dish_name, who, note, status

还有一个值得一提的细节：保活机制。Supabase 免费计划超过 7 天不活动会暂停数据库。所以在 app.js 里加了一个 keepWarm()，每 24 小时 ping 一次 /rest/v1/dishes。

二、FLIP 动画：卡片展开详情

首页推荐菜品的卡片，点击后不是跳转页面，而是从卡片当前位置展开成一个详情的浮层。这是用 FLIP（First, Last, Invert, Play）动画实现的。

核心逻辑在 utils/flip.js 里：

1. 点击时用 createSelectorQuery 获取卡片当前位置和尺寸（First）
2. 浮层渲染后拿到它的最终位置（Last）
3. 计算位移差和尺寸差（Invert）
4. 用 this.animate() 执行 9 个关键帧的展开动画（1.25s ease-in-out）
5. 关闭时执行逆动画（8 个关键帧，0.9s）缩回原位

效果就是卡片像从页面上「长」出来一样顺滑。这是整个项目里用户感知最明显的交互亮点。

三、Lottie 动画：状态反馈

为了替代微信小程序里比较单调的 loading/empty/success 反馈，我封装了一个 Lottie 动画组件：

<lottie-player type="loading" width="200" height="200"></lottie-player><lottie-player type="empty" width="300" height="300"></lottie-player><lottie-player type="success" width="150" height="150" loop="{{false}}"></lottie-player>

三组动画数据内嵌在组件 JS 里（不是从网络加载），用一个 npm 包 lottie-miniprogram 渲染到 <canvas type="2d"> 上：

• loading：3 个弹跳的圆点
• empty：一个冒着热气的锅
• success：圆圈 + 勾

这个组件被用在了首页、购物车、订单、菜品管理、统计、心愿单等 6 个页面里，统一了所有状态反馈的视觉风格。

四、液态玻璃 UI 设计系统

整个项目的视觉风格是「液态玻璃」——温暖、通透、柔软。用 26+ 个 CSS 变量定义了一套完整的设计 Token：

--bg-primary: #fdf6f0--bg-card: rgba(255, 255, 255, 0.68)--glass-blur: blur(20px)--glass-saturate: saturate(180%)--radius-card: 24rpx--radius-sm: 12rpx--shadow-card: 0 4rpx 20rpx rgba(0,0,0,0.06)--accent: #a0522d--accent-light: rgba(160, 82, 45, 0.1)--text-primary: #3d2b1f--text-secondary: rgba(61, 43, 31, 0.6)

支持深色模式，每个组件都有显式的暗色覆盖（TabBar、返回按钮、卡片、弹窗、购物车栏、分类标签、表单输入）。深色模式通过 @media (prefers-color-scheme: dark) 媒体查询自动切换。

五、11 个页面的路由与交互

底部 TabBar 只有两个入口：

TabBar├── 首页 ──→ 全部菜单 ──→ 购物车 ──→ 提交订单└── 管理 ──→ 菜品管理 ──→ 新增/编辑菜品           ├── 订单管理 ──→ 食谱查看           ├── 数据统计           └── 心愿单

所有页面跳转使用 navigateTo + animationType: 'slide-in-right'（300ms），返回用 navigateBack + slide-out-right。

每个页面都有完善的边界处理：

• 加载态（骨架屏或 Lottie loading）
• 空态（Lottie empty + 提示文案）
• 网络失败（本地备份数据兜底）
• 防重复提交（submitting 标志位）
• 输入校验（价格非数字/负数、菜品名必填）

六、本地备份

Supabase 免费计划可能暂停，数据可能丢。所以每次成功拉取数据后，都会调用 app.backupData(type, data) 把数据存到 wx.setStorage。网络失败时自动读取本地备份。

同样，购物车数据也在每次修改后同步到 wx.setStorage，App 启动时自动恢复。

这是一篇写给自己的开发记录

记录 Plocr-chef 这个家庭菜单小程序是怎么从一张 Figma 设计稿，一步步变成能用的微信小程序的。

整个开发过程几乎没写什么原创代码——全是和 AI 对话聊出来的。但也不是一键生成，中间有很多手工活。

第一步：Figma 画图

所有事情的起点是一张 Figma 设计稿。我在 Figma 里画了首页的布局、卡片样式、配色方案，然后导出 PDF。

为什么是 Figma？因为那时候我还不知道后面会用什么技术栈，Figma 是纯视觉的，不绑定任何实现方式。画出想要的样子，再想怎么实现它。

设计风格是后来贯穿整个项目的「液态玻璃」（Liquid Glass）：温暖的大地色系（主色 #a0522d），半透明毛玻璃卡片，大圆角，柔和的阴影。

第二步：把 PDF 丢给 AI，生成文件树

有了设计图之后，我把 PDF 上传给 AI，描述我想要的功能：

• 一个家庭私用的点菜小程序
• 首页展示推荐菜品
• 完整的菜单浏览和搜索
• 购物车 + 下单
• 订单管理 + 食谱查看
• 菜品后台管理（CRUD）
• 数据统计
• 心愿单

AI 根据设计图和需求描述，生成了一整套项目文件树——每个文件叫什么、放在哪里、大致负责什么。这个文件树后来基本没改过，一直用到了项目完结。

Plocr-chef/├── app.js / app.json / app.wxss├── custom-tab-bar/          # 自定义毛玻璃 TabBar├── components/lottie-player/  # Lottie 动画组件├── utils/│   ├── supabase.js           # Supabase REST API 封装│   └── flip.js               # FLIP 动画├── pages/                    # 11 个页面│   ├── index/                # 首页│   ├── dishList/             # 全部菜单│   ├── cart/                 # 购物车│   ├── order/                # 订单│   ├── manage/               # 管理后台入口│   ├── dishManage/           # 菜品管理│   ├── addDish/              # 新增菜品│   ├── editDish/             # 编辑菜品│   ├── recipe/               # 食谱│   ├── stats/                # 数据统计│   └── wishlist/             # 心愿单└── node_modules/

第三步：手工活——建文件、粘贴代码、改 bug

文件树有了，AI 也生成了每个文件的代码。但这里有一个关键步骤：不能一键生成。

我需要：

1. 在微信开发者工具里手动创建每个文件
2. 把 AI 生成的代码逐段粘贴进去
3. 运行看效果——几乎每次都有问题
4. 截图 → 描述问题 → AI 改代码 → 粘贴 → 再看

这个循环重复了无数次。微信小程序的坑特别多：<nav> 标签不支持、CSS 某些属性不认、组件间传值容易丢……每个都是人工发现的。

第四步：升级工具——Claude Code + DeepSeek API

项目到中期，手动粘贴代码已经效率太低了。我开始接入 Claude Code 开发模式：让 AI 直接读取项目代码、分析问题、生成 patch。

同时，为了降低 API 成本——Claude 的 API 调用在大量迭代时费用不低——我接入了 DeepSeek API 来做辅助优化。DeepSeek 在代码理解和生成上表现不错，价格却便宜很多。

具体分工是：

• Claude Code：架构设计、复杂逻辑、新功能开发
• DeepSeek API：代码优化、bug 修复、样式调整、小修小改

相当于一个「主力 + 辅助」的双模型工作流。这在 vibe coding 项目里是一个值得记录的模式——不必所有对话都用最贵的模型。

第五步：免费方案全家桶

整个项目没有花一分钱（除了 API 调用的零散费用）：

唯一的潜在成本是 Supabase 免费计划如果超过 7 天不活动会暂停。解决方案是在 App 启动时加了一个 keepWarm() 函数，每 24 小时 ping 一次数据库。

回顾

这个项目的开发方式总结下来就是三个词：Figma 定稿 → AI 写代码 → 人工调试。

Figma 负责「我要什么」，AI 负责「怎么写」，人负责「哪里有问题」。三个角色缺一不可。

它不是那种「输入一句话，AI 生成一个完整 App」的魔法——魔法不存在。但它确实是「输入一个设计稿，和 AI 聊几百轮，手工粘贴调试，最终得到一个能用的 App」的可行路径。

第一步：本地新建文章

在博客项目根目录打开终端：

cd "F:\文档\GitHub blog\Plocr.github.io"

用 Hexo 新建一篇文章：

npx hexo new "文章标题"

这会在 source/_posts/ 下生成一个 .md 文件。把它重命名为 .html 后缀，然后用 HTML 格式写。

文件顶部有一段叫 Front-matter 的配置区域：

---title: 文章标题date: 2025-05-15tags: [项目日志]excerpt: 摘要文字，显示在首页卡片---

第二步：写内容

用 HTML 写正文。常用标签：

<h2>二级标题</h2><h3>三级标题</h3><p>段落文字</p><blockquote>引用文字</blockquote><ul>  <li>列表项</li></ul><a href="https://...">链接</a><img src="图片URL" alt="描述"><pre><code>代码块</code></pre>

图片建议用在线图床链接，不要放本地文件。

第三步：本地预览

写完后在本地看看效果：

npx hexo server

浏览器打开 http://localhost:4000，找到文章点进去。修改文件保存后刷新页面即可看到变化。

第四步：提交并推送

确认没问题后：

git add -Agit commit -m "新文章：文章标题"git push origin master

推送后，Vercel 会自动检测到 master 分支的更新，开始构建并部署到 plocr.online。

第五步：等一会儿

Vercel 构建通常需要 1-2 分钟。去 Vercel Dashboard 可以实时看到构建进度。构建完成后，文章就在线了。

常见问题

推送后网站没变化？

去 Vercel 看部署日志。如果失败，大概率是 Front-matter 语法错误。

本地 hexo s 报错？

检查 Front-matter 的格式，--- 必须成对出现。

标签不对？

标签只能从四个分类里选：项目日志、工作流分享、随笔、影音推荐。

文章没有封面？

有图就用第一张，没图就随机分配 12 种手绘插画之一，不用担心。

就是这样。写给自己看的，也算帮未来的自己省点事。

如果你今晚想看一部不废话的科幻片

2018年有一部电影叫《升级》（Upgrade），它什么都没做。没铺世界观，没讲大道理，就安安静静花了100分钟讲了一个故事。看完了，爽了，甚至有点背后发凉。

故事真的很简单

未来某个时间，男主格雷是个老派的人，开手动挡车，不碰智能设备。一天和妻子出了车祸，妻子被杀，他全身瘫痪。一个科技公司老板找上门，说能让他站起来——往脊椎里植入一枚叫 STEM 的芯片。

效果立竿见影，他不光能走，还能打。重点是：打架的时候不是他想怎么打，是芯片在接管他的身体。他只能看着自己像提线木偶一样把对手揍得血肉横飞。

它到底好看在哪

当然，也有不喜欢它的人

有一部分观众觉得这片子太「B级片」了——血浆给得足，但说到底还是个复仇套路，思想深度比不上《机械姬》或者《降临》。这个评价也没错，它本来就不是冲着哲学论文去的。它要做的事情很简单：让你100分钟里手心出汗，最后给你心口来一拳。

它做到了。

欢迎来到我的小窝

这是我的第一个博客。从 2023 年开始搭建，断断续续折腾了两年多，才有了现在的样子。

一开始只想有个地方放文章，最后变成了一个精装修的 Web 项目。

框架

Hexo，一个用 Node.js 驱动的静态博客生成器。用 HTML 写文章，一条命令生成静态网页。当初选它是因为简单——不用数据库、不用服务器，写完 push 上去就完事。

主题

最早用的是 Butterfly 主题，后来觉得太花哨，删了重写。现在的主题是照着 Claude 官网的设计语言手搓的：

• 低饱和莫兰迪色系
• 手绘 SVG 插画
• 12px 圆角、4px 间距
• 亮暗双模式
• 全站小濑字体 + Fantasque Sans Mono 代码字体

没有用任何现成的 UI 框架，CSS 从零写，JS 从零写。细节全都是自己可控的。

其他

• 亮/暗模式一键切换
• 手绘 SVG 插画 × 12 种随机轮换
• 一键回到顶部按钮
• 光标跟随光晕
• 响应式适配

人生下来的时候都只有一半，为了找到另一半而在人世间行走。

关于爱情，我认为无为非是我们不需要二十四小时都在线，不需要通过刻意且频繁的聊天来维持关系。我只希望我们忙的时候认真努力，闲下来的时候就能立刻想起对方。我希望我们是相互想念的，相互在意就好。

就像莎士比亚说的那样。

💕 和我家那位的恋爱时长 →

古时的爱情

山有木兮木有枝，心悦君兮君不知。
——《越人歌》

只愿君心似我心，定不负相思意。
—— 李之仪《卜算子》

衣带渐宽终不悔，为伊消得人憔悴。
—— 柳永《蝶恋花》

或是惊觉相思不露，原来只因已入骨，情不知所起，一往而深。恨不知所踪，一笑而泯。人世间有百媚千红，唯独你是我情之所钟。

古人的深情总是超乎我们的认知，而他们对爱情的解答总是带着一抹温柔。

爱情可以成为一个人的精神支柱，每个人都渴望真正的爱情。有的人幸运，很快就找到了；而有人却要寻一辈子。

爱情的确很难，因为这其中有太多的弯路要走，而我们太容易迷失在里面了。

愿深情不被辜负，愿大家所遇皆良人，爱有所归，情有所属。