用Gemma 4打造不胡编的Etsy文案生成器：读图写标题

从手工作坊到文案地狱：一个Etsy卖家的真实痛点

做手工副业的人大多有这样的体验：产品做出来很开心，写商品页却像受刑。Etsy对listing有一套硬性规则——标题不能超过140个字符且搜索词要前置，标签必须正好13个、每个不超过20个字符，描述还得读起来像人写的。对一个人打理店铺的卖家来说，这些限制叠加起来足以把周日晚上耗光。

开发者 casareanderson 就是这样的卖家，卖月亮海报和文字印刷品。他没有选择付费文案工具，而是用开源权重模型 Gemma 4 做了一个命令行工具 listwright：输入产品照片和一两句“真实事实”，输出标题、13个标签和三段式描述。

这个项目有意思的地方不在于“AI帮你写文案”——这类工具已经很多——而在于它对AI胡编问题的处理方式。

Etsy 的 listing 规则并非随意设定。标题 140 字符限制源于其搜索算法对长尾关键词的偏好——前 40 个字符权重最高，因此卖家被建议把最核心的搜索词放在最前面。13 个标签的上限则是平台为了平衡搜索精度与防滥用而设的硬性天花板，每个标签 20 字符的限制进一步压缩了表达空间。这些规则叠加，使得人工撰写一个合规且有效的 listing 通常需要 30 分钟以上。对于兼职卖家，这直接侵蚀了本已微薄的利润空间；而付费文案工具往往按月订阅，对月销个位数的店铺并不经济。这正是开源轻量工具出现的土壤。

三层判定机制：让模型说话，让规则把关

listwright 的核心设计是“生成与校验分离”。模型只负责写，一个纯 Python 写的检查器（rules.py）负责在用户看到结果之前做分类，输出三种状态：

• ready：符合 Etsy 的硬性限制，且没有说出用户没提供的信息
• confirm：出现了用户从未声明的数字，或 framed、handmade、personalised 这类带有承诺性质的词
• not ready：重试3次后仍违反硬规则，比如超长、标签数量不对、地名拼错

关键在中间那一档。作者在演示中用一个儿童字母印刷品举例：生成的标题和标签看起来都不错，但标签里混进了“personalized gift”和“custom name art”。这个产品其实不是定制品——买家自己买字母自己拼名字。在 Etsy 上，“personalised”意味着买家预期要发名字给卖家，一旦货不对板，就是一场尴尬的售后对话。检查器没有自作主张删掉它，而是把它标记为 confirm，交给人来判断。

这个取舍很务实。AI 从照片里读出的信息可能是真的（比如尺寸“A5 to A2”、年份“November 2027”），但用户没说，就不能默认可以写进 listing；而另一家店的 mockup 相框可能被误读成“arrives framed”，那就是实打实的退款风险。

在 Etsy 的语境下，“personalised”与“custom”并非同义词，而是有明确履约含义的承诺：卖家需在买家下单后收集其姓名、日期等信息并据此制作。若 listing 误用这些词，买家会预期收到定制沟通，而卖家若无法履约，则面临退款、差评乃至平台纠纷。同理，“framed”意味着商品包含画框，若实际只寄送印刷品，则构成描述不符。这类词汇在自动化文案中极易被模型“顺手”添加，因为它们在训练数据中常与礼品类商品共现。因此，检查器将它们列为风险词并触发人工确认，本质上是在生成式 AI 与交易责任之间设置一道安全闸。

实测数据：24次生成，0次失败，总成本不到半分钱

作者用自己店铺的12个真实 listing 做了测试，每个跑两次：一次喂完整描述作为事实，一次只给一句偷懒的话。结果是 24 次生成中有 17 次首次即为 ready，7 次进入 confirm，0 次失败，平均耗时 5.5 秒，总成本 0.0035 美元。

那 7 次 confirm 全部是合理提问。5 次来自“偷懒版”输入，模型从照片里读出了尺寸和日期——信息属实，但用户没提供，属于越界；另外 2 次就是前面那个“personalised”印刷品，两种事实输入各触发一次。

有意思的是成本结构。24 次草稿总共花了不到一美分，这意味着工具可以做成一次性买断或近乎零成本的托管服务，而不是必须按月收费来支付 API 账单。作者直言，即便做一个面向不想碰终端的卖家的廉价托管版，“几乎全是利润”。

检查器比模型更难写：三次踩坑记录

作者坦承，把检查器写对比调用模型花的时间更长。他记录了三个具体的错误：

拼写检查的误报。 第一版把“includes”判成“included”的拼写错误，把“covers”判成“coders”。真实单词之间经常只差一个字母。最终方案是只检查句子中间出现的地名，因为拼错的小镇名字才是真正会让你丢掉搜索流量的错误——这个检查的起因是他的第一次测试运行把海报标成了“aberdene art”，没有任何机制拦下来。

把“你没给过我这个数字”当成错误回传给模型。 结果模型直接把从照片里读到的真实信息删掉了。现在的规则是：硬规则违规回传给模型重试，事实性声明则作为问题抛给用户。

否定句被误判。 “你拿到的是数字文件而不是实体印刷品”这句话因为包含“physical print”被标记为虚假声明。现在检查器会跳过否定语境。

还有一个明确的边界：listwright 不知道一个标签是不是好标签。它曾把一张月亮海报标成“astrology art”，货架完全错了。标签质量仍然需要人来判断。

拼写检查的难点在于自然语言中大量真实单词仅差一两个字母（如 includes/included、covers/coders），通用编辑距离算法会产生大量误报。listwright 的取舍是：放弃全句拼写检查，只针对地名做定向校验。原因是地名拼错会直接导致该 listing 在对应地理搜索中不可见，造成隐性流量损失，且模型对地名的幻觉率较高。实现上，检查器维护一个地名列表或调用轻量地理词库，仅当句子中间出现疑似地名且不在词库中时报警。这一策略牺牲了通用性，但精准覆盖了最高风险的错误类型，体现了“规则检查器应窄而深”的设计哲学。

开源模型的实际价值：一次驱动故障的说服力

作者原本计划全部跑在自己的小 GPU 机器上，照片不出门、没有订阅、没人能涨价。但就在写这篇文章的当天，一次没有重启的显卡驱动更新让 GPU 完全没被使用，Gemma 在本地卡了十分钟没有响应。

如果用的是闭源 API，这时候只能干等或者重写。因为是开放权重模型，他改了一个环境变量，指向同一 Gemma 4 家族的托管版本就继续了。演示数据来自托管的 26B 版本，他明确表示还没有在本地 8B 上重跑全部 24 个用例，所以不会声称两者效果一样。

这种“不夸大”的态度在 side project 写作里并不常见，但也正是它能被认真对待的原因。

开放权重模型（open-weight model）指模型参数可公开下载、允许本地部署和修改的模型，如 Gemma、Llama 系列。与闭源 API 相比，它的核心优势是自主可控：用户可选择本地运行以保护数据隐私，也可在需要时切换至同一模型家族的托管服务，而无需重写调用逻辑。listwright 通过兼容 OpenAI chat API 的抽象层实现了这种可移植性——默认指向本机 Ollama 的 gemma4，仅需修改环境变量即可切换至远程端点。这种设计将“模型”与“服务”解耦，使开发者能在成本、隐私和可靠性之间灵活权衡，尤其适合对数据出境敏感或网络不稳定的场景。

技术栈：三个文件与零依赖

实现上只有三个核心文件：

• model.py：向任何兼容 OpenAI chat API 且支持图像的服务发起一次调用，默认走本机 Ollama 的 gemma4，改一个环境变量即可切换后端
• draft.py：发送照片和事实，接收 JSON，交给检查器；硬规则违规时带上问题清单回传模型，最多重试3次
• rules.py：纯规则检查器，不含任何 AI，负责字符限制、标签数量、数字溯源、风险声称词表和地名拼写

安装方式是 pip install git+https://github.com/casareanderson/listwright，没有外部依赖，典型调用如下：

listwright draft photo1.jpg photo2.jpg --facts "Birmingham moon poster. Instant digital download."

这类工具的真正价值在哪

listwright 解决的并不是“AI 能不能写文案”，而是“AI 写了不该写的东西时怎么办”。把生成和校验拆成两层、让确定性规则守住事实边界、把模糊判断交还给人，这套模式可以迁移到很多面向交易场景的生成任务上——商品描述、房源文案、招聘 JD，凡是“说错一句就要赔钱”的地方都适用。

它的局限也很清楚：不知道标签好不好、只支持 Etsy 的规则、仅作者自己使用过。但对一个 Hacktoberfest 的副业项目来说，能在第一个下午就在真实店铺里找出真实问题，已经超过大多数同类尝试。

项目地址：https://github.com/casareanderson/listwright