AI 指令台.

业务背景

平台侧后台是给运营看的，门店老板只关心三件事：今天几单、钱什么时候到、有没有要处理的。商家控制台把这三件事放在首屏：指标卡 + 最近订单 + 营业额曲线 + "需要你处理"待办区，登录进来十秒看完一天的生意。

经营首页

100 Boil Pot & Grill 首页：今天 / 近 7 天 / 近 30 天切换；四指标卡——订单·近 7 天（已支付订单）、营业额·近 7 天（顾客实付合计）、预计到账·近 7 天（已扣佣金与手续费）、出票失败·近 7 天（需要重新出票）；最近订单表带短码（BO-WEYXVN 等）、类型自取、实付 $53.67 → 到账 $47.29 与状态已完成；右侧近 7 天营业额柱状图（9/3-9/9）；底部"需要你处理"空态。左导航：订单记录 / 菜品分析 / 谷歌评论 / 私密反馈 / 门店素材 / POS 连接 / 来单通知 / 收款与结算（结算账户、交易明细、争议处理 1）；中/EN/ES 三语与明暗主题切换。

核心业务成果

• 实付与到账双列展示，佣金手续费透明，老板不用问平台"我的钱怎么少了"；
• 出票失败单独成指标并进待办区，支付成功但出票异常的单不会被漏掉；
• 争议处理带角标计数（1），结算争议在导航层就看得见；
• 三语 + 明暗主题全量覆盖，北美多语种店员可直接使用。

技术难点总结

1. 金额口径：实付、到账、预计到账三个口径分别扣除佣金、手续费与未结算周期，卡片副标题直接写明口径避免误读；
2. 待办聚合："需要你处理"汇聚出票失败、争议、改期审批等多源待办，空态明确告知"目前没有需要处理的事项"；
3. 多语言：中/EN/ES 文案与金额、日期格式一起本地化，切换语言不刷新页面；
4. 权限边界：商家账号只能看到本店数据，结算账户等敏感页按角色挂载。

业务背景

整个系统有三类界面：顾客侧品牌站、门店侧商家控制台、平台侧 UpDeal/Raccoon OS 后台。三处如果各做一套登录，账号体系和密码策略必然漂移。统一鉴权的做法是：一个 auth 服务签发 JWT，各端只验 token 不碰密码；账号由平台管理员在后台统一开设，前端登录页全平台共用一套。

登录页与 token 签发

统一登录页（Raccoon OS）：邮箱 + 密码登录商家控制台；提示"没有账号或忘记密码?联系平台管理员在后台为你设置"——不开自助注册，开户权收归平台管理员，从源头控制账号来源。

POST /api/auth/login：username + password 换 200 { token: eyJhbGciOiJIUzI1NiIs…, user: { id, username } }；token 为 JWT，各端持同一密钥验签，到期走换发流程，刷新期间无感续期。

核心业务成果

• 品牌站 Sign in、商家控制台、平台后台共用一套登录页与 token 机制，新端接入只验签不重建账号体系；
• 密码只存在于 auth 服务，业务服务拿到的只有 token 里的用户身份，横向越权面收窄；
• 开户收归管理员后台，离职店员账号可即时停用；
• 登录验证码短信与营销短信走不同 Messaging Service，鉴权通道送达率不受营销投诉影响。

技术难点总结

1. token 换发：access token 短有效期 + 换发接口静默续期，前端 401 重试一次而非直接踢回登录页；
2. 密码存储：bcrypt 加盐哈希，登录接口对"用户不存在"与"密码错误"返回同一提示，避免账号枚举；
3. 多端角色：同一 token 结构携带角色声明，商家端与平台端路由守卫按角色挂载，接口层二次校验；
4. 会话安全：登录失败限流 + 异常提示统一化，后台开户密码由管理员设置后强制首登修改。

项目背景

魔法书是一个即将面向市场的商业化项目：把纸质书写体验搬进屏幕，同时保住"手写感"这件最容易被数字化磨掉的东西。技术上的三个抓手是识别精确率、书写质感与回答质量。

做了什么

• 多模态大模型做底层识别：用多模态模型替代传统 OCR 链路做底层识别，提升复杂版面与手写混排场景的精确率；
• 矢量化笔迹生成：笔迹以矢量方式生成而非位图贴图，放大缩小不失真，笔画的起收与连笔保留书写感；
• 精炼提示词控制回答质量：用精炼后的提示词约束模型输出风格与结构，保证产物稳定可用，而不是每次开盲盒。

核心成果

• 识别精确率由多模态底层模型托底，混排手写内容的可用率显著提升；
• 矢量笔迹让产物在任意尺寸下保持手写质感，直接可用于打印与分享；
• 提示词精炼后输出方差变小，商业化交付的质量底线可控。

界面一览

官网首屏：手写提问、墨水作答的主视觉，配早鸟订阅与等待名单入口。

产品页：整页羊皮纸质感，配置 API key 后唤醒日记本。

配置页：OpenAI / 通义千问 / 自定义三档模型源，密钥本地封存（Seal to the Diary）。

技术要点

1. 多模态识别链路：图像与文本统一进模型，避免传统 OCR + 后处理两级误差叠加；
2. 矢量化笔迹：笔迹建模为矢量路径，渲染与存储分离，兼顾质感与体积；
3. 提示词工程：以最小提示词集控制回答质量，减少冗余指令带来的漂移。

项目背景

短视频是门店营销的刚需，但剪辑门槛把大多数商家挡在外面。这个项目把剪辑做成三档能力：会剪的人全自定义，不会剪的人套模板，连模板都不想选的人直接跟 AI 说话——agent 全流程接管。

三档剪辑能力

• 自定义模块：自由调整分镜、配音音色与语速/气口、字幕颜色字号、品牌名与地址、转场与音效、BGM，每个参数都开放；
• 模板模块：配置大量 AE 模板，用户选模板后填入素材、选择 BGM 与文案音色即可自动生成，质量可控、零经验可用；
• AI 全自动模块：与 AI 对话下达剪辑任务——直接把素材发给 AI 助手，由 AI 调用剪辑功能完成；预览后指出问题即可自动修改，例如"不满意第 2-3 个分镜的转场"，说明后 AI 自动完成调整。

核心成果

• 零经验商家从素材到成片只要一次对话，改稿也是对话；
• 模板档保证质量下限，自定义档保留专业上限，三档共用同一条渲染流水线；
• agent 能真正"调用功能"而不是只给建议：下达任务 → 执行 → 预览 → 按反馈修改的闭环跑通。

界面一览

选模板：内置真实 AE 模板，填素材与文案即出片，时长与段数预先标注。

自己调：分镜顺序、配音音色/语速/句间停顿、画幅、稳定性、情绪、字幕与 BGM 全参数开放。

技术要点

1. agent 工具调用：剪辑能力封装为可被 AI 调用的工具集，对话意图映射到分镜/配音/字幕/转场的具体参数变更；
2. 反馈式修改：预览后的自然语言反馈定位到具体分镜区间（如第 2-3 个分镜），只重跑受影响片段；
3. 模板参数化：AE 模板抽象为参数槽位（素材位、BGM、音色、文案），同一模板服务多行业素材。

项目背景

AI 全栈黑客松比赛项目（2026.05–2026.06），已开源。命题是"没有网也能用的 AI 办公助手"：完全基于 QVAC SDK 开发，靠边缘大模型在本地跑全部能力，并且全程检测并隔离软件内网络环境——断网不是降级模式，而是默认模式。

功能清单

• 文档版本管理：本地文档的版本链维护与回溯；
• 基于 LLM 的文档检索：边缘大模型驱动的语义检索，不走云端 embedding；
• TTS 朗读：朗读文档与 AI 回答内容，本地语音合成；
• 会议录音转文字：本地语音识别转写会议纪要；
• 网络隔离：全程检测并隔离软件内网络环境，保证数据不出机。

核心成果

• 全部 AI 能力（检索、TTS、转写）在边缘大模型上闭环，离线可用；
• 网络隔离做成产品特性而非口号：软件内环境全程检测，敏感文档零外发；
• 项目已上传 GitHub 开源，比赛交付后仍可复现与二次开发。

界面一览

AI 对话：多会话管理、上下文文档挂载，回答可一键本地朗读。

知识库管理：文档批量导入/导出/翻译/删除，全部本地入库。

语音转写（ASR）：拖入 WAV 本地转写，实时进度与历史转写记录。

翻译视窗：原文/译文对照，结果可导出或直接导入知识库。

系统设置：系统状态与硬件占用、凭据托管与 AES-256-GCM 加密、一键数据清理。

技术要点

1. QVAC SDK 全栈使用：从模型加载、推理到资源管理完全走 SDK，控制内存与启动时间；
2. 边缘模型选型：在本地算力约束下平衡检索质量与响应速度，检索与生成分离部署；
3. 隔离验证：以网络检测钩子验证全流程零外联，作为验收标准写进测试。

项目背景

VoidTidy 是一个 .NET 窗口管理工具，2026.06 开源。它有两个实验性约束：一是完全使用 Claude Code 调用 GLM-5.1 API 开发，按最小代码量完成；二是选 .NET 4.8 而非新运行时，目标是把常驻资源压到几乎无感。

做了什么

• AI 协作开发：全程用 Claude Code 调用 GLM-5.1 API 写代码，以最小代码量为验收标准，功能不缩水；
• 窗口管理：Windows 窗口的整理与排布能力，常驻后台随叫随到；
• 资源极限优化：基于 .NET 4.8 节省内存与 CPU 资源，避免新运行时的额外开销。

核心成果

• 静默状态内存占用 <10MB、CPU <0.1%；
• 运行状态内存约 40MB、CPU <1%；
• 已上传 GitHub 开源，可作为"AI 写的小而美工具"样本复现。

界面一览

收纳栏：桌面顶部按 Adobe / 游戏 / 软件开发等分类停靠图标，随叫随到。

设置：收纳文件夹、停靠位置、缩回模式与延时、图标尺寸、开机自启。

隐藏图标：把桌面与托盘的杂项图标统一收进收纳栏，保持桌面整洁。

技术要点

1. 最小代码量约束：把"代码量"当作成本指标写进开发流程，AI 生成代码逐段审、能删就删；
2. .NET 4.8 取舍：老运行时换来更低的基线开销与更广的兼容面，代价是 API 面更窄，靠 Win32 互操作补齐；
3. 常驻优化：静默路径零轮询、事件驱动唤醒，保证后台常驻不抢资源。

业务背景

客户是服务北美本地商家的 SaaS 平台（hiraccoon.com / Raccoon OS / UpDeal 后台），已上线品牌站的门店 30 多家，业态横跨餐饮、美甲、汽修、零售。每家门店都需要"自己的"官网：独立的品牌视觉、独立的菜单与服务列表、独立的地址与营业时间，但点单、预约、评价、营销这些运营能力必须完全复用。目标是新门店品牌站从签约到上线以天计，同时首屏性能和 SEO 不能妥协。

架构简述

• 前端：Next.js 静态输出（SSG），品牌站纯静态托管，首屏不依赖服务端渲染；
• 主题化：每站点独立主题 Token（主色、字体、圆角、按钮形态），同一套组件渲染出完全不同的视觉——拉面店的暗色配正红、美甲店的紫、回转寿司的红白、汽修店的黑黄、零售店的粉色动效；
• 通用骨架：What We Make / Our Story / Visit Us / Menu 导航结构，Location & Hours 页内嵌 Google Maps 与结构化营业时间表；
• 转化入口：Order online / Order Pickup / Call to Book / Reservations / Free Estimate 统一挂载，直连在线点单与预约系统；
• 信任要素：首屏评分带（4.6★ · 278+ local reviews）、数据带（8h 熬汤 / 100% 猪骨 / No MSG）、好评弹幕流与 Before & After 真实案例区，把 Google 评价资产直接变成转化组件。

代表站点

Machiya Ramen（Montréal）：暗色主题 + 正红 CTA，首屏挂 4.6★ · 278+ local reviews 与 8h / 100% / No MSG 数据带。

Sichuan Alley Bistro（West Hartford）：浅色头图 + 红字点缀，"Culture you can taste."，Order Online 与 Reservations 双入口。

KAISEN Kaiten Sushi Bar（Santa Ana）：红白回转寿司主题，轮播头图，$2.00 起按盘色计价。

Yo2 Nail Bar（Cary）：美甲业态的紫色主题，35+ 服务 / 每周 7 天 / Cary Pkwy 数据带，View Services 与 Call to Book。

Legend Sushi（Orlando）：和风纸纹底 + 金墨配色，自助价格牌午市 $22.95 / 晚市 $35.95。

Carheart Auto Tech & Collision（Hillsboro）：黑黄高对比，电话与免费估价双 CTA，Before & After 真实案例区。

动效、地图与信任组件

YUGO Asian Lifestyle：粉色花瓣放射动效首屏 + 全屏巨型字标，零售业态的视觉天花板。

Legend Sushi 整页：首屏价格牌之后是 ALL YOU CAN EAT 价格区，长页结构按业态自由拼装。

100 Boil Pot & Grill（Tucson）：Location & Hours 页，Google Maps 嵌入 + 结构化营业时间表（含周二休息）+ Open in Maps。

Carheart 估价表单：年份/品牌/车型、保险信息、最多 6 张车损照片（浏览器端压缩后上传）；背景是流动的好评弹幕信任墙。

核心业务成果

• 30 多家门店共用一套品牌站架构，新站从立项到上线以天计；
• 品牌站全静态输出，首屏无服务端等待，利于收录与分享；
• 估价表单照片在浏览器端压缩（JPG / PNG / WEBP / HEIC）后再上传，不消耗顾客流量；
• 评分带、数据带、好评弹幕、Before & After 四类信任组件跨业态复用，直接把 Google 评价资产变成转化率。

技术难点总结

1. 主题隔离：主题 Token 只作用于站点作用域，避免多主题 CSS 互相污染，同时保证组件层零分支；
2. 多业态复用：餐饮菜单、美甲服务、汽修估价、零售展示四类完全不同的转化路径，收敛到统一的入口组件与下单/预约接口；
3. 地图与营业时间结构化：营业时间按周建模（含休息日），地图落点用 Place ID 而非坐标，避免地址变更失效；
4. 动效性能：首屏花瓣放射等动效用纯 CSS/transform 实现，静态导出后依旧满帧，不拖累 LCP。

业务背景

30 多家品牌站跑起来之后，问题变成"哪家店流量真实在涨、广告费花得值不值"。第三方分析工具按站点收费、且拿不到订单数据，无法把"访问 → 下单 → 付款"串成一条链。于是自研了一套轻量分析：品牌站埋点上报，后台按门店聚合，和订单库同库关联，转化口径完全自己定义。

模块总览与汇总指标

流量分析总览：站点选择器（全部站点 38）+ 今天/近 7 天/近 30 天与自定义区间，总览/来源/用户画像/热门页面/转化漏斗/搜索排名页签；同屏 UV 8,063 / PV 12,550 / 访问 8,709 / 跳出率 80.5% / 付款订单 123 单 $5,620.10 / 真转化率 1.41%，底部按天（美东）订单金额与订单数双曲线。

汇总指标接口：GET /api/websites/<id>/stats 一次返回当期 pageviews / visitors / visits / bounces / totaltime 与 comparison 上期同口径，总览四个数与跳出率全部由它算出。

趋势、来源与画像

趋势图：访问 / UV / PV 与订单金额按天曲线，时区统一按门店当地（美东）归天。

趋势曲线核心代码：时区对齐的按天聚合与缺日补零，避免跨时区门店曲线错位。

来源分析：付费广告 40.9% 等渠道占比环图 + 明细表，广告依赖度一眼可见。

维度分布：自选维度拆解会话、跳出与转化，定位"哪种流量在浪费"。

用户画像：城市 / 设备 / 浏览器 / 操作系统 Top 榜，决定投放与兼容优先级。

页面、排名与谷歌搜索

热门页面追踪：浏览量 Top 页 + 入口页 / 退出页，找出承接力最差的那一页。

排名分析：Semrush 关键词榜 + "查什么"成本面板（单次查询 $0.018/页、余额 $0.757），把 SEO 开销做成可见预算。

谷歌搜索追踪：Search Console 曝光 4,296 / 点击 130 / CTR 3.0% / 平均排名 17.0，关键词与落地页各 Top 25，固定 28 天窗口。

门店排行与订单对照

门店排行：Legend Sushi Orlando 1,686 访客居首；Hokkaido Ramen House 46 单 $1,787.76、转化率 4.36%；Chung Wah 11 单 5.19%；Machiya Ramen 3 单 4.62%。

本周 vs 上周对比表 + 每日订单与金额记录：合计 123 单 $5,620.10，周界按美东对齐。

转化漏斗

漏斗前端：预设漏斗卡片一键套用；漏斗配置支持页面/事件混排步骤、转化窗口 60 分钟、只看指定来源；结果 131 → 58（流失 55.7%）→ 8（流失 86.2%）。

漏斗核心代码：会话切分、步骤顺序匹配与窗口剪枝，保证同一步骤不被重复计数。

核心业务成果

• 访问到付款全链路同库关联，真转化率 1.41% 这类口径只有自研能算；
• 广告渠道占比、SEO 查询成本、GSC 表现三本账放在同一屏，预算决策不再拍脑袋；
• 漏斗步骤可由运营自行配置（页面/事件混排 + 转化窗口），新活动上线不用改代码。

技术难点总结

1. 时区归天：门店横跨美东/美中/山地/太平洋时区，所有按天聚合一律按门店当地时区归天，周对比表同规则；
2. 真转化口径：只统计付款成功的订单金额，持位未付与退款单分别剔除，避免漏斗虚高；
3. 漏斗会话切分：同一访客多次会话按窗口切分后再匹配步骤，防止跨会话拼接出假转化；
4. 外部配额管理：Semrush 按次计费、GSC 有配额，查询结果落库缓存 + 余额面板，超支前先看得到。

业务背景

美甲、按摩这类服务业的预约痛点不是"能不能约"，而是"约到的时段是不是真的有人能做"：员工技能不同（美甲师不会做蜜蜡）、排班不同（有人周日休）、项目时长不同（凝胶 manicure 40 分钟、spa pedicure 15-25 分钟）。系统必须把这三者叠在一起算可约时段，而不是简单按营业时间切格子。

客户端：选日子、选时段

Yo2 Nail Bar 预约页：日期横滑条（Today Sep 9 起一周）+ 15 分钟粒度时段网格；提示"This appointment takes about 40 min. Times shown already leave room for it."——展示的每个时段都已按项目时长和员工排班校验过。

下单与改期接口

POST /booking/hold：带 menuItemId / providerId / startAtIso / 顾客信息 / payLater 与 items 下单，返回 appointmentId、orderId、短码 A7X2、depositCents 与 status confirmed——持位成功即锁时段。

POST /booking/requests：kind=reschedule 提交改期申请（requestedStartAtIso + 顾客备注"临时有事"），返回 requestId 与 status pending、"已提交，等门店确认"——改期走审批，不直接改单。

商家后台：技能与周排班

商家后台预约页"员工与排班"：添加员工时勾选能做的项目（42 项技能芯片：Standard/French/Gel Manicure、Dip Powder、各类 Pedicure、蜜蜡系列等），再按周设置班次（周一到周六 10:00-19:00、周日休息，美东 24 小时制）；下方 Store Staff 卡片汇总技能与每日班次，支持改排班/删除。

后台日视图接口

GET /admin/booking/day?slug=yo2-nail-bar&date=2026-09-11&includeCancelled=1：返回当日 appointments（含 providerName、serviceName、status confirmed、depositCents / depositPaidCents / refundedCents 押金三态）与 nextAppointmentDate，后台日历与取消单同接口出。

核心业务成果

• 可约时段 = 员工排班 ∩ 技能匹配 ∩ 项目时长留白，顾客看到的每个时段都真实可履约；
• 下单持位返回短码（A7X2），门店前台口头核销不用翻系统；
• 改期走申请-审批流，门店对日历有最终控制权；
• 押金三态（应付/实付/已退）在日视图接口直接给出，对账不用二次查询。

技术难点总结

1. 时段计算：按项目时长在员工班次内滑动开窗，再扣除已持位区间与缓冲时间，复杂度控制在门店规模可实时响应；
2. 持位并发：同一时段多人下单用持位记录互斥，未付款超时自动释放，不超卖；
3. 改期审批：改期不直接移动订单，而是生成 pending 申请，门店确认后原子换时段，避免审批期间时段被抢；
4. 时区：排班按门店当地时区存储与展示（美东 24 小时制），接口一律 ISO 带时区，杜绝夏令时错位。

业务背景

门店的营销短信/邮件过去靠店主手动群发：没分层、没时机、也没合规意识。Content Studio 把"顾客经历"变成触发器——第一次来、没付完款、好久没来、周末和节日、吃完请留评——开一条规则，剩下的系统自己做。短信走 Twilio、邮件走 Resend，两条通道独立开关、独立模板。

规则中心：六条生命周期规则

Raccoon OS 顾客自动营销：按店切换（CM Korean Fried Chicken），KPI 卡显示本店可发邮件 112 人（在该店下过单）、本月已发 0、短信已同意 0、短信发送器未配置；黄色横幅明确"短信受 TCPA 管，必须顾客事先明确同意才能发；邮件走退订制"。六条规则：新顾客欢迎+首单优惠、弃单提醒、30 天未回老顾客召回、每周主题回购（周一/周五/周六+节日促销）、节日祝福（当天不带优惠）、用餐后评价邀请（付款后 3 小时）。

Content Studio：模板与发送记录

UpDeal 后台 Content Studio（Chung Wah Restaurant）：顶部 Twilio Messaging Service SID 配置横幅 + Email Resend 已配置、时区 America/New_York；KPI 今日发送 / 送达率(7日) / 退订(STOP) / 本月预估花费；六张规则卡各自带 SMS/Email 通道页签、变量模板（{名字} {店名} {优惠} {订单链接} {评价链接}）、发送预览与"测试发送"；底部发送记录表 65 条，按时间/渠道/触发规则/内容/状态/Provider ID 全量留痕，支持重发。

同意与合规

同意/退订面板：营销短信同意 0 人、STOP 抑制名单 0 人、营销邮件同意 58 人、未勾选同意/仅 OTP 138 人，支持手动设同意/退订（测试用）；合规检查卡对照 TCPA / A2P 10DLC 上线前项：独立营销 Messaging Service（与登录验证码号隔离）、STOP/HELP 自动退订（入站 webhook + 本地抑制名单已接）、发送引擎（cron + 事件钩子）、结账 opt-in 勾选 UI 已接。

核心业务成果

• 六条规则覆盖新客、弃单、召回、回购、节日、邀评全生命周期，门店零操作成本；
• 短信只发给 opt-in 顾客、STOP 即时生效入抑制名单，TCPA / A2P 10DLC 上线前检查全绿；
• 营销号与登录验证码号隔离，验证码送达率不被营销投诉拖累；
• 发送记录带 Provider ID 全量留痕，客诉与退订争议可逐条回溯重发。

技术难点总结

1. 同意建模：短信同意、邮件同意、STOP 抑制三张名单独立维护，结账勾选、手动设置、入站 webhook 三个入口写同一事实源；
2. 触发与去重：cron 扫表 + 事件钩子双通道触发，同一顾客同一规则按冷却期去重，弃单提醒"隔一会儿提醒一次"而非连发；
3. PAID GUARD：弃单提醒发送前复查订单支付状态（min-unpaid 30 分钟），顾客刚付完款立刻停发，避免催付乌龙；
4. 模板变量安全：{名字} {订单链接} 等变量在预览与实发走同一渲染器，测试发送即所见即所得。

业务背景

线下门店想要 Google 好评，但直接贴 Google 链接会把差评也全公开出去。分流页的做法是：顾客扫桌牌二维码进入打分页，4-5 星跳转该店 Google 写评价，1-3 星转成私密反馈发到店主邮箱——好评上墙、差评到店主手里先处理。整套页面由 UpDeal 后台配置，保存即生效，不需要发版。

后台管理：一店一页

UpDeal 后台扫码评价页列表：每家店一条 /r/<slug>（bestbuffet、bunny-nails、carheart、chungwah…），含 Google 落点核对链接、店主邮箱与差评计数；顶部黄色提示"未开通 14 家：这些门店在 merchants 里，但没填 Place ID，/r/ 页是 404"，把待办直接亮出来。

一键生成与内容修改

编辑抽屉：按店名地址搜 Google 取 Place ID（提示"同名餐厅很多，选错会把好评送到别人家"），或粘贴 Google 地图链接免 API key 解析；选中店铺绿卡回显地址与 Place ID 并提供"在 Google 地图上核对"链接；slug 已印在二维码上不可改，店主邮箱各家各填（1-3 星差评转发到这里），保存并生效按钮一键上线。

桌牌二维码生成

桌牌二维码弹窗：指向 https://hiraccoon.com/r/bestbuffet；打印用 SVG 放大不糊，容错级 H 沾油磨损也能扫；支持下载 SVG / PNG 两种格式直接交印厂。

核心业务成果

• 好评进 Google、差评进邮箱，门店评分资产与客诉处理互不干扰；
• 配置保存即生效，新开一家店的评价页分钟级上线，无需发版；
• 未开通门店（缺 Place ID）在列表顶部集中提示，运营按清单补录即可；
• 二维码容错级 H + SVG 源文件，桌牌印刷与日常磨损场景均可扫。

技术难点总结

1. slug 生命周期：二维码印上桌牌后 slug 不可修改，改店名、换 Place ID 都不能动 slug，绑定关系单独建模；
2. Place ID 绑定：同名门店多，搜索候选必须带地址回显 + 地图核对链接，另提供免 API key 的地图链接解析兜底；
3. 差评路由：1-3 星反馈按店路由到各自邮箱，邮箱缺失时落后台待办而非静默丢弃；
4. 二维码可靠性：容错级 H + 纯 SVG 输出，保证印刷尺寸缩放与油污磨损后仍可识别。