北京
“Fictional Store sells Rice at Rs 50 per Kg.”这句读起来平平无奇的英文文案，是一个本地小模型在3.8秒内生成的。输入只有两条：店名，和一句报价事实——大米每公斤50卢比。
这个原型叫 DukaanDraft，一个只支持英文的实验性工具，把街边小店的促销事实，变成一段可以编辑的帖子草稿。流程很朴素：填店名和优惠事实，生成改写，拿结果和原始事实对照，改，复制。没有任何内容会被自动发布。
但真正值得聊的，是它暴露出来的问题，而不是它跑得多快。
正方：本地小模型够用了
支持这套方案的理由很直接。模型是 SmolLM2-360M-Instruct，用的是 ONNX 社区转换版本，量化后在 Node 的 CPU 上跑，不经过任何托管推理接口。不需要 API key，不需要注册新账号，模型文件从 Hugging Face 下载，店铺文本在本机处理。
应用代码是 MIT 协议，模型权重保留自己的 Apache-2.0 协议。这意味着别人可以下载、按公开文档检查、在本地运行，也可以直接改工作流或者换掉模型，不用从零开始。开放权重让这个想法可以在没有推理服务账号、没有按次计费依赖的前提下被验证。
技术栈也刻意压得很薄：表单用纯 HTML 和 JavaScript，一个小的 Node HTTP 服务器，加上 Transformers.js 做本地推理。服务器只监听本地回环地址，只接受同源的本地浏览器请求。用 Node.js 20+ 跑 npm install 和 npm start，再打开 127.0.0.1:8787 就能用。原型在 Linux 上用 Node 22 测过，没有公开部署。
反方：它会自己加戏
问题就出在“小”上。界面把原始事实放在可编辑草稿的下方，旁边配了一句警告：每一条说法都要核对。这不是客套话——在其他测试里，模型给内容加上了“affordable”（实惠）这样的词，还改过店名。
一个小模型，依然会编造细节。所以人工复核在这个产品里是流程的一部分，不是事后补丁。作者自己写得很清楚：小模型容易上手，但不等于准确到可以替店铺写公开声明。
还有几个现实门槛。首次使用要下载模型权重，体积是几百 MB；模型加载需要足够的空闲内存。作者明确说了，这不是“只用手机”或“低内存设备”能扛的承诺。3.8秒也只是测试电脑上的一次测量结果，不构成性能保证。
界面上那几个目的地标签——WhatsApp、Google Business Profile、Instagram——目前只用来整理草稿，还不会改变模型的提示词。
我的判断
这个原型最诚实的地方，是它没有假装自己是一门生意。作者把副业设想写成“一个待验证的想法”：面向本地小店的、带人工复核的文案代写服务。没有客户数据，没有收入数据，也没有付费意愿的结论。
下一步该做什么，作者也给了方向：找真实店主测试，统计事实错误的频率，看这种带复核的写作服务到底能不能省下足够多的时间，让他们愿意掏钱。
至于早前探索过的托管 API 和纯浏览器推理两条路线，没有被验证为可行，也就没有进入最终版本。范围被刻意收窄：英文改写、可编辑结果、原始事实对照、一个明确的复制动作。
所以现在的 DukaanDraft，是一个能跑起来的本地实验，带着一道清晰的复核关卡。它离商业产品还有距离，但它把“小模型能干什么、不能干什么”这件事，摆得比很多demo都清楚。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
