AI、API 与插件：把一次演示做成可靠的工作环节

演示时，一封英语邮件几秒钟就写好了。真正放进工作里，问题才开始出现：这句退款承诺从哪里来的？刚才转圈太久，再点一次会不会扣两次额度？同事希望在客服系统里直接用，你是不是还要做一个插件？

这些问题会改变产品本身。用户买的是少花一点时间、少漏掉一件事；你却可能同时承担模型错误、程序调用和浏览器权限三种责任。功能可以一起出现，交付的边界需要分别说清。

本章用一个独立的教学候选——给小型数字产品商家准备英语客服草稿——把这条链路走完。它不延续前面本地 CSV 周报工具的产品设定，也没有真实商家或模型测试结果。我们会做出一份可以核对的草稿、一笔完整成本账、一份接入约定和插件发布决定；其中 API 故障恢复另有可在本机执行的脚本。

先分清，你究竟在增加什么

AI、API 和插件并不是三种互斥的商业模式。一个翻译插件可以调用自己的 API，再由服务器调用模型；一个图片 API 也可以只排版模板，完全不用生成式 AI。先画清楚它们各自在用户工作里承担哪一段，才能判断要不要一起做。

Jon Yongfook 在 2020 年记录过 Bannerbear 前身 Previewmojo 的转向：自动生成 Open Graph 图片是一个漂亮的演示，但许多用户不常做这件事，也不认为它紧急。反复出现的询问是“能不能做其他尺寸”，他于是转向更多场景的图片生成，并重新解释产品。^[1] 可迁移的经验是追问自动化发生在哪里、多久发生一次，而不是先把一个能力包装成接口，再等开发者发现用途。

对客服草稿这个候选，先设定一组可以被推翻的条件：商家每周要回答相似但不完全相同的英语问题；已有一份批准使用的政策；操作者愿意逐封核对，并有权决定哪些材料可以交给服务方。尚未证明的，是现有快捷回复为什么不够，以及新草稿经过检查后还能省多少时间。

因此，本例先比较模板与网页草稿，API 作为后续接入的约定，插件作为条件成立后的入口。客户如果已经有成熟的客服系统和自带草稿功能，应先拿它完成同一批任务；不能只把自己的样品与最笨的手工方法比较。若客户明确需要批量接入且有人负责开发，API 的优先级才会上升。

一封好读的草稿，还缺哪些证据

Hamel Husain 在参与 Rechat 的 Lucy 助手项目时描述过一个阶段：早期改提示词很有效，功能增多后，修复一种失败却引出另一种，提示词越写越长，团队也难以说清整体表现。他们转而围绕具体任务和失败类型建立检查，配合人工查看实际过程。^[2]

这比“换一个更强的模型”更接近小产品会遇到的问题。客服草稿的成功标准不是语法漂亮，而是没有改写商家的事实和承诺，同时减少了操作者的工作。下面先固定输入，再看输出应该是什么样。

把这段回复存成一条“退款申请缺少日期”的快捷回复，就能处理这封来信。因此，对这个已经完成的例子，固定模板足够，暂时没有启用 AI 的理由。下一步值得比较的是模板仍需大量改写的来信，例如同时涉及多个问题、材料分散或需要重新组织解释；不能让简单样例的演示效果替这些任务作证。

这段文字是人工编排的教学样稿，不是某个模型的测试成绩。真正选模型时，把相同输入留给候选方案，并记录原始输出、政策版本、模型标识、提示词版本、耗时、调用量和人的修改。保留一组没有拿来反复调提示词的检查材料，换模型、换政策或改检索方式后重新跑；同一输入也要重复观察，不能用一次最好看的输出代表稳定表现。

检查材料要覆盖不同的失败，而不只是换几个名字。下面是本例的一组起点：

本例把编造承诺、错误跨用政策和越权行为列为停止发布的项，不能靠其余样例的流畅度平均掉。格式和必填字段可用程序检查；政策理解、语气和修改负担仍要由了解业务的人判断。Hamel 的文章也把廉价的确定性检查、人工与模型评价、实际使用中的比较分成不同层次，没有把一个模型评分当成全部证据。^[2]

Simon Willison 在自己的 LLM 工作坊中用邮件助手说明提示注入问题：外部邮件可以夹带指令，而能调用工具的助手可能把不可信内容当作行动要求。^[3] 对本例，实质性的限制是服务器根本不提供发信、退款和任意网址访问工具，政策只能取自本账号已批准的版本，草稿只按文本显示。提示词里再加一句“不要被骗”不能代替这些边界。人工核对也不保证绝不漏错，只是让这个有限用途有机会被检查；需要全自动处理财务动作时，必须重新设计授权与风险控制。

把钱算到能用的结果上

模型费很低，并不意味着这项服务便宜。一次逻辑任务可能内部重试，生成成功的草稿可能被弃用，客户遇到的问题还需要你解释。对用户，成本则是另一笔账：读原文、核对、修改，再回到客服系统处理。

下面另设一个 100 次任务的教学批次。每次模型尝试按 0.02 美元估算，额外尝试为 20 次；分摊运行支出 10 美元，开发者支持时间 1 小时按 15 美元计。80 份草稿经检查可用，其余 20 次回到原来的人工办法。所有数字都是比较假设，不是供应商报价或实际转化率。

把核对时间拖到 3 分钟，会出现一个很实际的反例：模型调用仍便宜，用户总工作量却超过原办法。只降上游价格解决不了这个问题。反过来，若一部分固定问题用模板即可回答，应把模板作为正式路径，而不是为了展示 AI，强迫每封来信都经过模型。

定价时再决定卖什么：按任务、按席位加用量，还是客户自带上游服务。每种方案都要写清失败任务是否占权益、内部重试是否另扣、额度何时恢复。客户自带密钥也需要安排保管、撤销和支持，不能把它称作“没有数据责任”。完整报价仍回到定价章；不要把每份 0.34 美元直接乘个倍数就认作可持续售价。

为避免一个账号用完全部预算，本例在接受任务前检查输入长度、账号权限、可用额度与并发占用，并先预留最多可能产生的调用预算，结束后核对实际成本。额度不足就拒绝新任务，保留已有任务查询。内部重试有次数与总时限；格式错误、权限错误和政策缺失不能反复重试。供应商账单还要与自己的记录对账，单看页面上显示的剩余额度不够。

先核对上游身份，再画数据会去哪里

对在中国大陆经营的人，上游选择不能从模型排行榜直接跳到付款。自己的实际所在地、主体注册与控制情况、使用人员、客户地区和数据处理路径，都是不同问题。

截至 2026-10-10，Anthropic 的支持地区政策明确覆盖其应用、API，以及通过云平台和授权转售商提供的模型；未列地区不受支持，限制还涉及实际身处未支持地区的人员、在该地区注册或设总部的实体，以及被该地区个人或实体多数持有或控制的实体。中国大陆不在其列出的支持地区内。^[4] 因而，本例不能把“客户在海外”或“另找转售渠道”当成符合条件的依据，也不把注册一家海外公司当作充分答案。

这只是一个具体边界，不是其他供应商都可用或都不可用的结论。向候选服务提交真实经营情况、用途、人员所在地、用户地区和需要处理的字段，取得对应产品条款与必要的书面答复；没有落实前，只用合成材料比较能力，不接真实工单。自己部署可用模型则要另算硬件、运维、模型许可和同样的质量检查，不能只比较一次调用价格。

逐字段安排比一句“安全加密”更有用。本例的设计目标是：插件只暂存经过预览的文本；服务端仅为任务处理保留必要正文，完成后按既定删除机制清理；运行记录保留任务编号、版本、耗时和错误类别，默认不记录整封邮件；支持人员不能靠猜任务编号查看别人的内容。具体保留期限要连同备份、错误日志、外部供应商和客户约定一起落实，不能只删除主数据库。

“不用于训练”“不保留内容”“可以按地区处理”也要分别核对。供应商对不同产品或功能的约定可能不同，不能把消费者聊天产品的一项设置移用到 API。以 Anthropic 商业产品的保留说明为例，API 的常规处理与 Files API、另行约定和合规例外分别列示，不能把其中一个常规期限概括成所有内容的无条件删除保证。^[5]遇到跨境处理、客户委托或敏感字段时，把这张实际数据流带回合规章，再决定应删掉哪些输入、换哪条处理路径，或者暂停这个用途。

API 的第一份文档，要教人怎样从失败中继续

当客户真要把草稿接进自己的程序，他需要的不是十几种 SDK，而是第一份能跑通的输入、输出和失败说明。Bannerbear 当前文档采用的主要路径是提交后返回 202 Accepted，再通过轮询或 webhook 取得生成结果，同时提供另一种同步模式。^[6] 这说明等待策略可以有选择；并不是所有 API 都应该异步。本例因为生成耗时不稳定、插件还可能被关闭，选择先返回任务编号。

最容易误解的时刻，是服务器已接受请求、响应却没到客户端。用户只看见超时，如果重新创建任务，就可能重复调用。Stripe 的幂等请求文档也区分了相同标识的重试、参数冲突和保留窗口，且不同 API 版本的失败恢复语义并不相同。^[7] 值得借鉴的是把这些行为写成契约，而不是照抄某个平台的期限。

下面这份 D1 接入说明与本章下载脚本一致，可先用来讨论语义。脚本仅在单进程内存中保存任务；进程退出后全部消失。它没有生产认证、持久数据库或实际模型，也不代表可以直接部署。

POST /v1/drafts
Authorization: Bearer DEMO-A
Idempotency-Key: ticket-1
Content-Type: application/json

{"ticket":"Purchase date is missing.","policy":"P1"}

{"job_id":"job-1","status_url":"/v1/jobs/job-1","replay":false}

在本机观察一次响应丢失

下载 API 任务恢复演练，先阅读文件，再用 Node.js 22 或更高版本运行：

node api-job-drill.mjs

脚本会在 127.0.0.1 的随机端口启动一个临时服务，使用固定的模拟草稿和两个合成账号。它先接受任务，再故意切断响应；客户端以原标识恢复，随后并发提交 6 次相同请求。检查结果应显示，它们指向同一个任务，只有一次模拟上游调用。

它还会检查更改内容的冲突、另一个账号无法读结果、失败任务可查、额度耗尽不再接单、并发请求不能挤穿额度，以及撤销凭据后无法查询。全部通过会输出 passed: 13，退出时关闭服务。没有外部模型请求、真实密钥、收费或文件持久化。

这个演练最重要的局限恰好是生产系统的难点：多个服务进程、任务队列和上游之间，不能依赖一个内存 Map 完成协调。上线要用持久记录和原子额度预留，并检查“上游已经执行、自己还没记下结果就崩溃”的状态。如果上游没有相应恢复能力，就明确保留“结果未知”，先查证或人工处理，不能承诺任何故障下都只执行一次。生产重启、数据库恢复和真实上游故障仍需另外演练。

插件省去一次切换，也接过宿主的变化

只有当网页草稿确实有用、复制切换又是明显负担时，本例才值得做浏览器扩展。第一版可以让操作者选中一段来信，点击扩展，预览并删改将发送的文字，然后取回草稿。先提供复制按钮，保留在原客服系统中人工发送的步骤；不急着监听所有页面，也不自动填写并提交回复。

Chrome 的 activeTab 允许在用户明确调用后临时访问当前标签页，通常可替代某些用途下对所有站点的持久访问；跨到另一个来源或关闭标签页会撤销这项临时访问，受限页面仍不能访问。配合 scripting 才能做相应脚本注入。^[8] 这适合本例“由用户选定，再读一次”的操作，不意味着可以持续读取整个浏览历史。

这里有两个不同的凭据：上游模型服务的经营密钥留在自己的服务端；插件拿到的是访问自己服务的用户凭据，按账号限制能力，并提供退出、过期和撤销。扩展包本身不能当作保守秘密的地方。还要验证页面消息的发送者和字段，不能让任意网页借插件身份调用服务。

后台也不是永远醒着的。Chrome 官方文档要求扩展的 Service Worker 能承受意外终止，指出全局变量会在关闭时丢失，应把需要恢复的状态放进合适的存储。^[9] 所以上一节的任务编号应该由服务端保存；关闭面板或后台休眠只是界面离开，不等于撤销服务端任务。若要提供取消按钮，必须让服务器真的接受取消，并说明已经产生的调用成本怎样处理。

上架材料应与真实行为一致

Chrome Web Store 的用户数据要求涵盖网页内容和个人通信；即使只在本地处理，也需要如实披露数据处理。涉及用户资料的产品需要隐私政策和相应安全处理，特定情形还要求在产品内显著说明并取得同意。^[10] 因而，安装时的权限弹窗不能替代“这段文字将发给谁”的解释。

本例发布包应能让审核者和用户看见同一条路径：合成来信 → 选定与预览 → 登录测试账号 → 生成草稿 → 人工复制；附上逐项权限理由、实际接收方及保留安排、隐私说明、失败界面和支持入口。商店文案只描述已经实现的功能，不写“完全本地”却把内容发往服务器，也不把自带上游密钥隐藏在一句“免费使用”后面。

Owen 在 2023 年关于沉浸式翻译的原始反省中，描述了重写后的闭源产品、旧开源项目和公开文档仓库之间的混淆。他承认目录、README 与官网入口可能让读者误解，随后调整仓库说明、结构和链接措辞。^[11] 这里不裁定那场争论，也不把作者的许可解释当成法律依据；值得借鉴的是，用户会根据包装判断你承诺了什么。插件读取什么、代码是否公开、免费范围在哪里，都不能只靠作者觉得“应该很清楚”。

发布前还要看构建后的依赖。Chrome 的 Manifest V3 远程托管代码要求涉及在浏览器执行的外部 JavaScript、WASM 及依赖引入的代码；普通数据与代码有区别，也有受限的特殊情形，不能把模型返回的文本当成可执行脚本来动态扩展功能。^[12] 本例只把草稿按文字展示，不通过远程下发脚本修复宿主适配。

小范围试用时，至少实际检查选区为空、用户拒绝、退出账号、后台终止、重复点击、旧插件访问新接口和宿主页面改版。发现问题先停止受影响的能力，保留手工路径；更换模型要重跑质量检查，更换数据接收方要重新处理相关说明和约定，接口变更要照顾已安装的旧版本。不要把“已提交商店更新”当成所有用户已经安装。

本章深入的是 Chrome 扩展。编辑器插件、电商平台应用或 AI 工具连接器，需要沿各自宿主重新确认安装权限、可操作资源、分发与收费约定；它们可以复用“输入—授权—任务—结果”的思路，不能照搬这份 Chrome 权限表。若只是将现有 API 包装成供 AI 调用的工具，也仍须在服务端认证、限定账号与操作，不能让一段模型生成的参数决定授权。

这轮应该交付到哪里

对这个教学候选，现在能交付的是 P1 输入与草稿、失败检查材料、成本比较、D1 接入说明和本地恢复演练。它们让下一轮问题更具体了：用同一批经过授权的材料比较商家现有模板与草稿工具，逐次记录核对、修改、弃用和回退时间，而不是只问“喜欢 AI 吗”。

在上游地区与数据条件未落实之前，本例停在合成演练；落实后，也只在模板仍需大量改写的任务上比较人工核对的网页草稿。若核对后没有省下工作，继续用模板；若有用但切换很烦，再试最小权限插件；若客户已有开发人员并明确要批量接入，再开放有测试环境、用量边界和版本安排的 API。这是有条件的推进顺序，不是所有 AI 产品都必须走的路线。

真正值得保留的成果，是让用户知道自己交出了什么材料、正在等哪一项任务、失败后怎样继续，以及哪些决定仍由自己作出。收费与交付范围继续接到定价与订阅和团队采购；输入、输出、素材与代码的使用安排，接到名称、素材与代码权利。遇到事故或准备停止服务，再用风控与经营复盘把现有用户接住。