Chengsi Shuai 帅成思

Pocket Cocktail Lab 个人产品

一个移动端优先的家庭酒吧 Web App：主人维护酒柜、发布今晚的酒单，客人扫码看酒单、点单、记录品鉴。我负责产品定义、规则制定、验收与上线决策；代码主要由 Claude Code 生成，中途一段由 Codex 接手。

公司 / 项目
个人项目 · 已上线
角色
产品负责人 · AI 辅助开发推动者
时间
2026.11

60 秒速览

43
款核验酒谱
V1→V3
版本迭代上线
100+
项自动化测试通过
业务问题Business Problem
在家招待朋友时，主人不清楚手头的材料能调什么，客人不知道能点什么、点单靠口头，聚会后也没有记录可以回看。普通酒谱网站按百科组织，不关联个人库存，也不区分主人和客人。
我的贡献My Contribution
我是产品负责人：定义每个版本的范围和禁止项，设计主人端与客人端的信息架构和关键规则，审查 AI 的方案与测试结果，决定是否上线。代码由 AI 编程助手生成，我没有手写主要代码。
关键行动Key Actions
  1. 把产品从酒谱展示页重新定位为「主人管理 + 客人扫码点单」的双端工具，酒谱从计划的 120 款收缩为 43 款核验酒谱
  2. 定下数据规则：主人酒柜以云端为唯一数据源，修改酒柜不自动改变客人酒单，任何设备不能静默覆盖云端
  3. 每个版本写结构化需求（目标、保留项、禁止项、验收清单），生产数据库迁移和正式部署前设人工确认
结果与产出Outcome
产品已上线并可公开访问；V3 上线前单元 37 项、接口 61 项、浏览器端到端 36 步测试全部通过。目前主人端只有我一个用户，真实聚会的使用数据尚未积累。
体现的能力Competencies
  • 需求定义与范围取舍
  • 信息架构
  • 规则与边界设计
  • 指标口径
  • 验收与上线把控
  • AI 协作开发

§ 02关键过程

跨设备酒柜不同步：从现象到规则

以下每一步都来自我当时的需求原文、PR 记录和代码。

  1. 01 发现

    我在电脑和手机上用同一个主人口令登录后台，电脑的酒柜显示 27 种材料，手机只显示 1 种（冰块）。界面上写着「选择只留在这台设备上」，我怀疑酒柜存在浏览器本地，但要求先查实原因，不要只根据现象猜测。

  2. 02 影响

    酒柜决定「现在能调什么」，也是发布客人酒单的依据。两台设备各存一份，主人在手机上看到的可调酒款是错的；旧版本发布时直接使用本机数据，在手机上发布可能让云端酒单被这 1 种材料覆盖。

  3. 03 原因

    查实：主人酒柜只存在各自浏览器的本地存储里（默认值只有冰块），云端只保存已发布的客人酒单，没有主人酒柜。

  4. 04 规则

    我在需求里定下：主人酒柜以云端数据库为唯一数据源，本机只做缓存；修改酒柜只更新主人库存，客人酒单保持上次发布的状态，只有点「发布」才改变；不允许手机的 1 种覆盖电脑的 27 种，任何设备都不能未经确认覆盖云端；迁移前先备份；要处理更新时间、请求失败和多设备冲突，至少避免旧数据静默覆盖新数据。

  5. 05 实现

    AI 按这些规则实现：每次写入带版本号，版本不符时服务器拒绝并返回最新数据，本机把自己的改动合并到最新版本上，而不是整份覆盖；离线改动先暂存再提交；停用旧的直接写入接口。首次迁移用已发布的 27 种材料初始化云端酒柜，已有数据不覆盖，旧的本机数据只有在我确认后才导入。

  6. 06 验证

    自动化测试：单元 21 项、接口 26 项（本地数据库）、双设备浏览器端到端 17 步；上线前做数据库时间点备份和去敏导出，上线后对生产环境只做只读检查。云端酒柜初始化为 27 种，与已发布酒单一致。

* 修复上线后我在手机上的复测情况没有留下记录，因此这里只列出自动化测试结果。

FIG. 01 酒柜数据分层（修复后）
  1. 01 本机缓存 最后确认的版本 + 尚未提交的改动；离线时先暂存 每台设备
  2. 02 云端主人酒柜 唯一数据源；每次写入带版本号，冲突时合并而不是覆盖 仅主人可读写
  3. 03 发布 只有主人点击「发布」才执行 人工动作
  4. 04 客人酒单 服务器生成的发布快照；主人后续改动不影响 公开只读

主人改动先写入云端主人酒柜；客人酒单只在点「发布」时更新。

§ 03背景与问题

Pocket Cocktail Lab（微醺实验室）是一个可以添加到手机主屏幕的 Web App（PWA）。主人维护酒柜、写自己的特调、发布酒单、处理点单；客人通过邀请二维码进入，浏览酒单、点单，在「品鉴护照」里记录喝过的酒。

项目从一个按材料匹配酒谱的静态页面开始，先后加入主人与客人分离、云端酒柜、原创特调、客人点单和数据看板，目前前后端完整并在线运行。

形态
移动端优先 PWA
前端
React · TypeScript · Vite（Vercel）
后端
Cloudflare Workers + D1，零月费
开发方式
AI 生成代码，本人定义与验收
  1. A

    主人：不知道手头的材料能调什么

    酒谱网站默认你什么都有，而主人的问题是反过来的：「我有这几瓶，能做哪几杯？下一瓶买什么最划算？」

  2. B

    客人：不知道能点什么，点单靠口头

    客人不关心主人缺什么材料，只想知道今晚能喝什么；口头点单人一多就容易漏单、记错。

  3. C

    主人：聚会后没有记录

    哪些酒被点得多、客人偏甜还是偏苦，没有记录可以回看。

FIG. 02 产品界面
Pocket Cocktail Lab 客人首页，显示今晚的酒单、按口味找、随机推荐和无酒精特调入口
a. 客人首页
酒款详情页，有「我想喝这杯」点单按钮和做法、杯型、酒精度信息
b. 酒款详情与点单
品鉴护照页面，显示客人的品鉴记录和口味偏好
c. 品鉴护照
主人工作室，列出我的酒柜、我的特调、今晚的点单、发布给客人
d. 主人工作室
主人点单页，按待处理、制作中、已完成、已取消分组，展开显示配方
e. 点单管理
数据看板，显示到访、独立设备、看酒单、看详情、点单、已完成等指标
f. 数据看板

截图来自本地测试环境，看板与订单中的数字和称呼均为测试数据。

FIG. 03 信息架构

A 客人端

  • 首页
  • 酒单
  • 按口味找
  • 品鉴护照
  • 酒款详情 → 我想喝这杯
  • 我的点单（状态自动刷新）

B 主人端（需登录）

  • 工作室
  • 我的酒柜
  • 我的特调
  • 今晚的点单
  • 发布给客人
  • 数据看板 · 邀请卡

C 服务器

  • 云端酒柜与特调
  • 发布快照
  • 订单状态机
  • 匿名访客与限频
  • 指标汇总与导出

客人端和主人端各有独立的底部导航；低频页面不占导航位置。

§ 04我的职责

这是我个人主导的项目。我和 AI 编程助手的分工如下：

  • 我：定义需求和每个版本的范围，写明目标、保留项、禁止项、验收清单与授权范围
  • 我：设计主人端与客人端的信息架构，定下数据、发布和点单的规则
  • 我：审查 AI 的实现方案与测试结果，设置人工确认关口，决定是否迁移数据库和正式上线
  • Claude Code：生成大部分前后端代码、数据库迁移和测试，执行备份、部署与只读验证
  • Codex：在 Claude Code 额度中断期间接手二维码邀请卡收尾、首页布局调整和一次正式部署

§ 05方法与行动

  1. 1

    范围取舍：做家庭酒吧，不做酒谱百科

    否决把酒谱扩充到 120 款的计划，收缩为 39 款经典酒谱和 4 款无酒精特调，以 IBA 官方配方为主要来源核验，家庭简化版单独标注；不常备的基酒归档，旧链接和收藏仍可打开。

  2. 2

    主人与客人分离：发布才生效

    主人酒柜与客人酒单分开存储。主人修改酒柜、编辑特调，都不会改变客人看到的内容；只有点「发布」，服务器才生成新的酒单快照。客人看到的始终是确定能做的酒。

  3. 3

    点单：家庭酒吧，不是外卖平台

    客人在酒款详情页点「我想喝这杯」，不需要登录、支付或留手机号。订单按「待处理 → 制作中 → 已完成 / 已取消」流转，由服务器校验状态；同一次提交不会重复下单，并设置了下单频率上限。

    技术细节：点单与访客数据
    • 订单保存下单时的酒名与配方快照，酒谱之后修改或归档都不影响历史记录
    • 访客用浏览器随机生成的匿名编号识别，服务器只保存其哈希值，不记录 IP 与设备信息
    • 客人可以一键删除自己留下的全部记录；订单中的称呼 30 天后自动清空
  4. 4

    数据看板：先写清每个数字的局限

    看板统计到访、看酒单、点单、完成率、品鉴评分等 10 项指标，每项都写明定义和局限。例如「独立设备」只是估算，不等于客人人数：一人多设备会多算，多人共用一部手机会少算。主人自己登录过的设备不计入。

  5. 5

    与 AI 协作：需求写清楚，关口留给人

    每个版本先写结构化需求，再让 AI 读代码、提方案、实现和测试；我审查方案与结果。生产数据库迁移和正式部署都设人工确认；迁移只新增表，前端、后端、数据库都能单独回滚。

FIG. 04 迭代过程（2026.11.14 – 11.15）
  1. V1
    材料匹配

    首页、酒柜、酒单、配方页；按材料匹配酒谱、替代建议；可添加到主屏幕。

  2. V2
    主人 / 客人分离

    发布与客人酒单分离、口味筛选、云端后端与主人登录、酒谱精简为 39+4、隐藏后台入口、邀请二维码。

  3. V2.5
    云端酒柜与原创特调

    修复跨设备不同步：云端唯一数据源、版本号与冲突合并；新增「我的特调」。

  4. V3
    点单与数据

    左右滑动导航、客人点单、品鉴护照、主人数据看板。

§ 06成果

  • 已上线

    产品在线运行，可直接访问；支持添加到手机主屏幕。

  • 版本迭代

    V1 材料匹配与酒谱；V2 主人 / 客人分离、云端后端与发布；V2.5 云端酒柜与原创特调；V3 滑动导航、客人点单、品鉴护照、数据看板。

  • 测试

    V3 上线前：单元测试 37 项、接口集成测试 61 项、浏览器端到端 36 步（V3 19 步 + V2 回归 17 步）全部通过。端到端测试使用模拟 iPhone 设备，不等同于真机测试。

  • 使用情况

    目前主人端只有我一个用户；真实聚会使用、真机与微信扫码测试尚未记录，因此不展示用户量或使用数据。

FIG. 05 V3 上线前的自动化测试
测试内容方式结果
同步合并、特调校验、滑动判定、订单状态机等单元测试37 / 37
V2 + V3 全部接口（本地数据库）接口集成测试61 / 61
新后端 + 旧数据库（兼容性）接口集成测试26 / 26
滑动、点单、护照、看板（3 台模拟 iPhone）浏览器端到端19 / 19
V2 功能回归浏览器端到端17 / 17

浏览器端到端测试在模拟 iPhone 设备上运行，不等同于真机测试。

§ 07复盘

01

AI 写代码很快，难的是把规则说清楚

大部分时间花在定义边界上：哪些设备能写入、什么时候才算发布、订单可以从哪个状态转到哪个状态。规则越具体，AI 的产出越接近预期。

02

数据口径要在建看板之前定

先写指标定义和局限，再决定记录哪些事件，否则看板上的数字很容易被误读。

03

局限与下一步

目前没有真实用户数据。下一步计划在 2–3 次真实聚会中使用，记录扫码、点单转化、完成率和评分，并访谈几位客人，再据此改进一处体验、对比前后变化。

这个项目体现的能力

  • 需求定义与版本规划
  • 信息架构
  • 数据与发布规则
  • 指标定义
  • 测试验收
  • AI 辅助开发

依据说明：未标注的内容均有工作材料或线上产品可查；标 本人确认 的事项材料中无直接记录；标 团队成果 的为团队共同结果，我是参与者。公司与客户的经营数据不在本站公开。