Reply Desk：小商家评论回复助手，数据不出本机

小商家的评论困境与一次 Hacktoberfest 尝试

开在街角的奶茶店、理发店、诊所、辅导班和家庭烘焙，它们的生意越来越依赖于 Google 和 Zomato 上的评价。回复每一条评论对生意有帮助，但柜台后面的人根本没有时间去做这件事。更糟糕的是，真正重要的评论——"食物里发现了一根头发""店员态度很差"——往往被二十条"奶茶好喝！"淹没。

在 Hacktoberfest 开源 AI 挑战赛第二周"副业"赛道中，开发者 Yash11778 提交了 Reply Desk，一个专门解决这个问题的浏览器端评论回复助手。它的核心理念非常直接：顾客的原话永远不离开柜台。

Reply Desk 项目来源页

Reply Desk 解决的三件事

Reply Desk 的功能可以概括为三个动作：

把紧急评论置顶。 涉及食品安全、健康、金钱和员工行为的投诉会被标记为 "Today"，粘贴进来的瞬间就会跳到最前面。
识别每条评论的情绪： 正面、混合还是负面。
用店主的语气起草回复，署上店主本人的名字。不满意的顾客会被引导到店主自己的联系方式（比如 WhatsApp 号码），而不是在公开场合争论。

店主只需要阅读、微调、复制、发布。如果情绪判断错了，点击正确的那个按钮，系统就会重新起草。

所有这一切都运行在一个开源权重的模型 Gemma 3 1B 上，完全在浏览器标签页内完成。不需要账号、不需要 API key、不需要服务器、不上传任何数据。

实际输出效果：一台没有 GPU 的笔记本

最有说服力的部分来自真实测试输出。在一台完全没有 GPU的笔记本上（纯 CPU，浏览器内运行），为一家虚构的咖啡馆 "Chai Point Corner" 和它的店主 "Priya" 生成的结果如下：

评论： 我的 poha 里发现了一根头发。太恶心了。我要退款。 标记： Today：食物中发现异物 · 情绪： 负面 回复： 我真诚地为您的 poha 带来的不愉快体验道歉。非常抱歉您的体验如此令人失望。请直接通过 98765 43210 联系我，以便我们进一步讨论并妥善解决。我重视您的反馈，也希望确保您满意。 —— Priya

评论： 等了两份三明治 25 分钟，我问的时候柜台那个人还很粗鲁。 标记： Today：员工行为 · 情绪： 负面 回复： 感谢您的反馈。我真诚地为延迟以及您在我们员工那里的遭遇道歉。我想向您保证，我会立即调查此事。请直接通过 98765 43210 联系我，以便我们进一步讨论。 —— Priya

评论： 环境不错，店主阿姨很友好。不过三明治有点湿。 情绪： 混合 回复： 很遗憾听到您有失望的经历。感谢您的反馈。我一定会考虑您关于三明治的意见，并进一步调查以了解哪里出了问题。 —— Priya

这些回复算不上文采斐然，也不需要是。它们礼貌、具体、有署名，而且从不编造折扣或虚假电话号码——这一点花了开发者不少功夫。第三条也说明为什么店主需要发布前阅读：它跳过了感谢"友好的店主阿姨"这部分，而人类五秒钟就能补回来。

Gemma 3 1B 是 Google 于 2025 年发布的 Gemma 系列第三代开源权重语言模型中的最小版本，参数量约 10 亿。相比动辄数百亿参数的大模型，1B 级别模型的优势在于体积小、推理快、可在消费级硬件甚至浏览器中运行，代价是推理能力和指令遵循能力明显更弱——它更容易忽略复杂格式要求，也更容易在模棱两可的输入上给出摇摆的判断。文章中对它的两处使用（判断情绪是混合还是负面、起草回复）都刻意压低了任务复杂度，正是对这一特性的适配。

Transformers.js 是 Hugging Face 推出的 JavaScript 库，让原本只能在 Python 中运行的 Transformer 模型可以直接在浏览器或 Node.js 里加载和推理。它依赖 ONNX Runtime Web（onnxruntime-web） 作为底层执行引擎，把 PyTorch 导出的 ONNX 模型在浏览器里跑起来，可选用 WebGPU 或 WASM 作为后端。

Web Worker 是浏览器提供的后台线程机制，脚本在其中运行时不阻塞主线程的 UI 渲染。模型加载和推理都很耗时，放在 Worker 里可以避免粘贴评论后页面卡死。

技术架构：一图看懂

项目的处理流程设计得相当清晰：

粘贴评论 ──► 按空行分割
         ──► 关键词检查：紧急吗？（即时，不用模型）
         ──► 有投诉词吗？否 ──► 正面（不用模型）
                             是 ──► Gemma：混合还是负面？
         ──► Gemma：根据情绪用对应 prompt 起草回复
         ──► 清理：去掉闲聊、占位符、重复署名

模型通过 Transformers.js 在 Web Worker 中运行，使用 onnx-community/gemma-3-1b-it-ONNX。WebGPU 上使用 4-bit 权重，CPU 上使用 8-bit。

教训一：给 1B 模型一个任务，而不是三个

开发者最初的 prompt 要求 Gemma 同时完成情绪分类、紧急标记和回复撰写，并且要遵守固定格式。结果模型完全无视格式，写出类似 **First line: POSITIVE** 这样的东西。对于一条真实投诉，它还写出了：

请直接通过 [Priya 的电话号码或邮箱] 联系 Priya

两个改动解决了问题：每个任务一个 prompt，分类和回复分开；每种情绪一个 prompt，"如果评论不好就道歉"会让它对着满意的顾客也道歉。所以代码先确定情绪，每种情绪有自己的单行指令：

const TASK: Record<Mood, (b: Business) => string> = {
  positive: () => '感谢他们的评论。',
  mixed: () => "感谢他们提到的好的部分，并直白地说你会关注他们不喜欢的地方。",
  negative: (b) => `只道歉一次，不找借口，请他们通过 ${b.contact} 联系你以便弥补。`,
};

店主的真实联系方式被传入，prompt 中明确写着"不要编造电话号码、邮箱、折扣或承诺"。之后一个小的清理流程会去掉方括号中的内容、"Okay, here's a reply:" 之类的开场白、markdown 格式以及重复的署名。

教训二：能用词表的地方就别用模型

漏掉食品安全投诉是唯一真正严重的错误，所以紧急判断用的是纯关键词列表——头发、蟑螂、生病、食物中毒、不新鲜、退款、粗鲁等等。它可预测、即时，而且让紧急卡片在模型还没加载完时就出现在顶部。

明显开心的评论也是一样。CPU（8-bit）版本喜欢模棱两可，把"附近最好喝的 masala chai！！"归为"混合"。现在，没有任何投诉词（but, though, cold, slow, rude, not...）的评论直接判定为正面，不需要问模型。Gemma 只负责决定困难的情况：混合还是负面。

教训三："浏览器内运行"是有细则的

让无 GPU 路径正常工作需要三个修复，都是通过实际运行而不是读文档发现的：

4-bit 版本在 CPU 上崩溃： Could not find an implementation for GatherBlockQuantized。onnxruntime-web 的 WASM 后端没有这个 kernel，所以 CPU 路径改为加载 8-bit 版本。
8-bit 版本随后 404： 模型仓库的配置说权重在外部数据文件中，这对其他版本成立，但 int8 是自包含的单文件。传入 use_external_data_format: { 'model_int8.onnx': 0, … } 解决了问题。
它只跑在一个 CPU 核心上。 WASM 线程需要 SharedArrayBuffer，而这需要页面跨源隔离。vite.config.ts 中两个头（Cross-Origin-Opener-Policy: same-origin、Cross-Origin-Embedder-Policy: credentialless）让它用上了所有核心。credentialless 在这里很关键，因为它让 Hugging Face CDN 下载继续工作，而不需要那个服务器发送额外的头。

为什么开源在这里至关重要

开发者认为，开源不是理想主义，而是商业模式成立的前提：

隐私就是产品。 评论里带着顾客的姓名、电话号码，以及对被点名员工的投诉。"顾客的话永远不离开这台电脑"是一个真正能兑现的承诺，因为没有服务器可去。
每条回复零成本。 托管模型按 token 收费，永无止境。这里店铺自己的笔记本干活，所以 ₹199/月的定价没有被 API 账单吃掉。托管模型还会迫使他计量使用量，而"无限回复"对店主来说好卖得多。
没有锁定。 没有 API key 可泄露，没有供应商涨价或弃用模型。如果出现更好的小型开源模型，替换只需要改一行（worker.ts 中的 MODEL）。
离线也能用。 模型缓存后，网络时断时续的店铺也能正常使用。

API 计费与边际成本 是理解这里的商业模式的关键区别。调用托管大模型 API 时，每生成一段文本就产生一次费用，费用随用户量线性增长，因此「无限回复」在托管方案下几乎不可能定价。而把开源权重模型下载到用户自己的设备上运行，推理成本由用户的 CPU/GPU 和电费承担，服务方在模型发布后不再有单次调用成本，边际成本趋近于零，这正是 ₹199/月这种低价套餐得以成立的前提。「零锁定」也源于同一逻辑：开源权重可以自由下载、替换、本地缓存，厂商停止维护或涨价都不会让产品失效。

目标用户与定价逻辑

这个工具瞄准的是永远不会为"AI"付费的咖啡馆老板，但他们会为"每条评论两分钟内回复，你再也不会漏掉一条投诉"每月付 ₹199–299。同样适用于管理十家本地店铺列表的小型代理机构。

定价之所以成立，正是因为开源模型——这也是前面单独成节的"Why Open Matters"的核心逻辑。

下一步计划

项目 MIT 许可，TypeScript 和 Vite 构建，没有框架，约 9 kB 应用代码加上模型运行时。开发者列出的后续方向包括：

印地语、马拉地语和 Hinglish 回复，因为很多评论是这样写的，这需要更大或微调过的模型。
按商家的语气示例： 粘贴三条你写过的回复，让它模仿。
每周摘要： "这周有 4 个人提到服务慢"。

在一个大模型动辄需要数据中心支撑的叙事里，Reply Desk 提供了一个反向案例：把合适的小模型放到合适的位置，用词表处理确定性任务，用模型处理模糊判断，用浏览器隔离替代服务器信任——这或许才是小商家真正用得起的 AI 形态。

背景补充

这里涉及的几个底层概念值得说明。量化（Quantization） 指把模型权重从 16 位浮点压缩到 8 位整数（int8）或 4 位（4-bit），以大幅降低显存占用和内存带宽需求，代价是精度略有损失。WebGPU 后端对 4-bit 量化有专门的低比特 kernel 支持，而 WASM 后端没有，这正是第 1 个问题中 GatherBlockQuantized 算子找不到实现的原因。

ONNX 外部数据格式 指大型模型的权重不放在 .onnx 主文件里，而是拆分到独立的 .onnx_data 文件中，加载时按需读取。当一个仓库里只有部分模型采用这种布局时，库的默认推断就可能出错，需要手动指定哪些文件是自包含的单文件。

SharedArrayBuffer 与跨源隔离 是浏览器安全模型的一部分。SharedArrayBuffer 允许多个线程共享同一块内存，是 WASM 多线程的前提；但由于它可以被用于 Spectre 类侧信道攻击，浏览器要求页面满足「跨源隔离」条件才允许使用它。要达成这个条件，服务器必须同时发送 Cross-Origin-Opener-Policy 和 Cross-Origin-Embedder-Policy 两个响应头，且后者的 require-corp 值会阻止未携带相应头的第三方资源加载——credentialless 是一个更宽松的取值，允许这些跨源下载继续进行。