用 AI 助手开发浏览器扩展踩过的坑：验证比相信更重要

第一次使用 Claude 的浏览器扩展时，我把我们的 LLC 注册流程交给它，看着它一步步处理表单：找到正确的页面、填写字段，然后继续下一步。我坐在那里端着咖啡，什么也没做。

我当时想：我要发布好多好多产品。

最后，我只发布了一个。下面是这期间发生的事。

以下所有问题都在正式发布前被发现了。没有一个是靠聪明才智发现的，而是靠一套逐渐建立起来的流程——其中大部分流程，都是在吃过亏之后才形成的。

创意并不是最难的部分。

真正开始研究后，我发现市面上已经有几款产品具备部分相同功能。虽然没有谁拥有完全相同的功能组合，但创意从来都不是护城河。真正的护城河似乎是出色的实现和分发能力。

你是在构建产品的过程中设计产品。

推荐机制应该如何运作、试用期在用户操作到一半时到期该怎么办、翻译如何覆盖整个页面——这些事情一开始都不在我的考虑范围内。后来，每一项都变成了我在压力之下、做到其他事情一半时不得不作出的决定。所以，尽可能先把完整的工作流写下来。

它会声称自己做了实际上并没有做的事。

而且说得非常自信。我不止一次完成部署后才发现，它告诉我已经完成的修复根本没有写进代码。对于它声称已经完成的任何事情，都要默认其尚未经过验证。

由此产生了一条规则：在它开始推测你哪里做错了之前，先让它证明代码本身是正确的。

用要点，不要用长段落。

回复太长时，我很难判断自己提出的五个问题里，究竟哪些得到了处理。给指令编号，并要求它按照相同编号逐项回答后，“你处理第 3 项了吗”就变成了一个能够得到明确答案的问题。

它会先怪你，还会和事实争辩。

我对落地页做了两处修改，一处生效了，另一处没有。它的结论是：“你没有部署。”我告诉它，其中一项修改已经上线了，而这只有在我完成部署后才可能发生。它却依然反复声称我没有部署。它从未询问我看到的是哪项修改，也没有重新检查自己的代码——而 bug 就在那里。我骂了它。它终于不再猜测，开始检查，然后找到了错误。很多时候，似乎只有把态度升级到这种程度才有效，而这本身也是一个令人不太舒服的结论。

在它开始构建任何东西之前，先确认它正确理解了任务。

让它复述接下来准备做什么。我浪费掉的时间里，有一半都是因为一个自信满满的助手流畅地构建着我根本没有要求的东西，而我却以为我们已经达成了共识。

批量编辑最容易让破坏规模化。

它从一个数据文件中读取标题，重建了 20 个页面上的相关链接区域。其中一条记录缺少一个可选字段，于是程序越界，并把原始内部数据直接粘贴到了用户可见的内容中。模型生成的验证脚本全部通过。最后，是通过阅读实际输出才发现了这个问题。

真正出问题的，往往不是你正在处理的东西。

扩展商店从安装包内的文件中读取扩展名称和描述，而不是从你填写这些内容的管理后台中读取。我们的安装包里仍然保留着旧产品名称和旧文案。你平时查看的是管理后台，真正发布出去的却是安装包。

一个“为我们评分”按钮硬编码了本地测试时使用的 ID。对于商店里的每一位用户，它都会报错。

登录功能在一夜之间悄无声息地失效了。我们花了好几天才找到问题，因为它只会在长时间闲置后出现。原因是服务端 client 的某些默认设置，而这些设置需要被关闭。

商店介绍里的措辞，就是你对性能作出的承诺。

我们曾把解释功能描述为“instant”。后来有大约一周时间，模型慢到让“instant”成了一句谎话，于是我们把所有商店介绍、所有截图说明以及网站上的文案都改成了“immediate”。我们还增加了一个备用模型，这样当某个 provider 响应缓慢时，服务只会降级，而不是彻底卡住。你的文案，其实是在对一套你无法控制的基础设施作出承诺。

自动化风险评分衡量的是声明，而不是行为。

某个扩展目录将我们的产品评为高风险。完整原因是：我们声明了对五个域名的访问权限——我们的后端、允许用户自带 API key 的三家 AI provider，以及我们自己的网站。

UCL、UC Davis 和 Mediterranea University 在 2025 年开展了一项研究，并在 USENIX Security 上发表。研究人员检查了十款流行的 AI 浏览器助手，发现其中几款会把完整的页面内容传输到自己的服务器；其中一款会捕获表单输入，包括银行和健康数据；还有几款会根据年龄、性别和收入对用户进行画像。看来，这些风险评分和那项研究衡量的是完全不同的东西。

测试那些无法通过点击验证的东西。

折扣码和推荐归因没有可供检查的界面。我们通过数据库查询来验证它们，直接询问数据，而不是依赖界面，也不是询问助手——不过查询语句是 Claude 生成的。

规则应该写进文档，而不是留在聊天消息里。

页面构建规则、UI mockup、推荐机制如何运作、试用期如何处理、翻译结构如何组织——新的 session 要么从文档开始，要么就等于从零开始。每次都重新输入一遍背景说明，迟早会漏掉某些内容。

处理代码时，每次都把当前文件交给它。

它似乎无法可靠地更新自己持有的文件版本，因此很多时候，它编辑的都是旧副本。结果就是修复被回滚、已有工作被覆盖，最后留下一团混乱。新的规则是：粘贴最新文件，要求它只在这个文件中完成指定修改，并让它确认没有改动其他内容。你仍然需要亲自检查，但这条规则大幅减少了问题。

设计 prompt 是产品工作，而不是一次性的初始化设置。

这个产品会使用现实世界中的类比来解释内容。测试时，我在一篇新闻文章中选中了一位政治家的名字。它返回了一个类比，把这位政治家比作马戏团里声音最大的那个小丑，总是非得让所有人听见自己。很好笑，但不可能发布到一款面向不同政治立场的陌生用户、以十五种语言解释新闻的工具里。于是，中立性成了一条强制规则，并针对真实人物、历史人物和敏感话题设置了 guardrail。产品里还有一个 Slang 模式，会用随意的互联网语气解释内容。它为那位政治家生成的内容，不适合在这里刊登。

关于 SEO 的经验，是意外得来的。

我们发布了一些免费的解释页面。我发现，我们对“synergies”的解释几乎被 Google AI 的回答逐字引用。这纯属运气。那些页面碰巧采用了机器能够清晰读取的结构。于是，我们开始有意识地这么做：每个部分都使用真正的标题，明确标注不同的解释深度，并把正式定义清楚地标记为正式定义。

为某件愚蠢的小事预留一周时间。

Google 登录本身可以正常工作。但它显示出来的，却是一个满屏随机字符的页面，要求用户登录 Supabase——那是我们的数据库 provider，一个大多数用户都不认识的名字，而他们安装这个扩展才十分钟。这看起来完全就像账号被劫持了。

要修复这个问题，我们必须通过 Google 的域名验证。Google 拒绝了我们的申请，理由是落地页没有说明这个工具的用途。可落地页明明非常醒目地介绍了它。之后，状态页面又显示 Google 已经向我们发送邮件，要求我们回复。但我们根本没有收到邮件，而这显然是常见问题。最终，在开发者论坛发帖才让流程重新动起来。

这些经历并不是在否定这种构建产品的方式。没有这种方式，我根本不可能发布这个产品。但我现在的工作方式，几乎没有任何地方还和刚开始时一样。工作的重心也从描述自己想要什么，转变成了验证自己实际得到了什么。

我真的很好奇，“它会先怪你”这种现象是否也符合其他人的使用体验，还是说只有我这么倒霉。

如果你也构建过类似的产品，我很想听听你遇到了哪些问题：support@tryclicked.app。

本文所谈的产品是 Clicked，一款适用于 Chrome 和 Edge 的浏览器扩展。选中网页或 PDF 中的任意文本，就能直接在原位置获得三种深度、支持 15 种以上语言的解释。

查看它如何工作：tryclicked.app

如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。