一天时间：用 AI 做个英语词根查询工具
可能博客的读者还不知道我其实是个开发者。最近做了一个英语词根查询工具 JarFire，也是第一次尝试 AI 套壳类的应用开发。如果你也对这方面感兴趣，并且从未做过相关工作，这篇文章可能就适合你；如果你已经有相关知识，那么这篇文章而言对你就太简单了。
拆字法：用英语词根词缀学单词
第一次听说这种学习方式还是看了《旋元佑英文字彙》。 举个例子，单词 unabridged 含义是“未删节的”，它可以拆分成： un / abridge / ed 三部分
- 前缀 un-：不，非
- abridge 删节，缩短
- 后缀 -ed，表示过去分词形式
拆词后，对原词理解更深刻，而且还附赠了一个单词 abridge。 因此每次想要对新单词加深印象时，会用 ChatGPT 拆词，GPT-4o 之后它的效果很理想。 然而每次打开 ChatGPT，输入相同的提示词，总没有那么方便。于是突发奇想：我能不能用 API 尽快做一个英语单词词根词缀的查询工具？
最后花了一天时间完成原型，不得不感叹 AI 之强大。 以前创业也做过英语教育相关的产品，在没有 AI 的时代，这类工具需要大量人力、心力在数据整理、纠错、版权上。
本文分享下遇到的难点和解决方式。如果你在这方面有更好的实践方式，请分享给我补充。
PS，文章中的示例是：
词根词缀学单词 https://jarfire.org/zh-CN
挑战一：让 AI 输出 JSON 格式
总所周知，默认情况下 AI 会输出一堆废话。如何才能让程序也可以解析其中的内容？
- 首先可以在提示词中要求 AI 必须输出程序可使用的JSON格式。
- 其次，可以为 AI 提供输出样例模板。 它可以是 TypeScript、JSON、 YAML，关键处的位置也可以用伪代码，AI 也能理解。告诉它每个字段的含义。
- 最后，可以要求不输出 markdown 格式。部分模型无法生效的话，也可以正则替换。
这样得到的文本结果可 JSON.parse。
设置 response_format 是更好的方式
DeepSeek 2024/07/25 更新[1]，支持设置 response_format 参数为 json_object。 这是个 OpenAI 的 API 特性，其他模型亦有部分支持。开启后可更稳定输出 JSON 结果。
挑战二：异常检测
有了 JSON 格式数据后，还有另一个问题：异常数据怎么办？例如拆词工具可能会遇到的两个情况：
- 单词不存在
部分用户可能会随便填写内容，这个时候需要把这部分异常数据检测出来，并有合理提示。 - 单词单复数问题
单复数词又分几种情况- 常见词汇，复数应改成单数形式
- 部分词汇，复数也应是个合理的独立词汇，例如 analytics
- 部分单数形式的词汇看上去像复数，例如 news
- 单词不可拆解
例如 giraffe / apple。这个时候要特别小心 AI 的幻觉问题，避免它一本正经胡说八道。
预处理
单复数和单词不存在可以尽量通过非 AI 的形式格式化单词，提升查询速度，降低 API 调用次数。 或者可以用词典提前筛选出不可拆解单词并入库。
条件分支
还要为输出格式列举 case，并要求按情况返回不同格式数据。
挑战三：费用
上线一天后，看 Azure 的费用清单，才测试了几十个单词，开销就达到了 $0.5，要是覆盖常见词汇和不同语种解释，估计费用能上万。 因此做了一些优化。
精简 token
要保证在尽量少的 token 下实现效果，有一些技巧可以使用。 对于初学者，最简单的方式：
- 合并重复项：重复的文本可以替换，如果不方便删减，还可以用占位符代替。
- 不必要的标点可以删除。
可能还有一些更高级的做法，我还没有掌握。
风险控制
如果有人想要刷爆你的账单，他只要反复构造请求就可以了。因此还需要做一些风控。常见的控制方式：
- 云服务商的预算控制，设定消耗阈值以及警告
- 反爬虫措施、 QPS 流控
- 用户侧付费，设定免费额度。同时当心有人创建一堆免费试用帐号来为你刷量
更换模型
还可以测试不同模型的效果。目前看 GPT-4o、Claude 和国内一些模型效果均不错。 这是常见几个模型的价格参考：
一百万 token 基本都在几十元到上百元人民币左右。最便宜是 Deepseek，效果也不差，百万 token 才 1～2 元，因此我又更换到了 deepseek。
兼容性提示
同样的 prompt 在不同的模型里效果也不一样，直接替换可能会出现问题。新一代的模型通常效果更理想，不过价格也更贵。
挑战四：如何快速开发
这个挑战并不是 AI 套壳类应用所特有的。需要充分打磨自己的技术栈，采用成熟、生态完整的方案。我这次使用的是：
| 名称 | 类型 | 网址 |
|---|---|---|
| NextJS | TS 框架 | https://nextjs.org |
| Tailwind | CSS 框架 | https://tailwindcss.com |
| shadcn/ui | UI 组件 | https://ui.shadcn.com |
| FloatUI | UI 组件 | https://floatui.com |
| next-intl | 多语言组件 | https://next-intl-docs.vercel.app |
| drizzle | 数据库 ORM | https://orm.drizzle.team |
| neon | PostgreSQL 数据库托管 | https://neon.tech |
| vercel | 应用托管 | https://vercel.com |
如果访问量足够小的话，前期不产生费用；如果有一定访问量，也可以切到自建。 上面提到的也有一些替代方案，例如 netlify、cloudflare worker、fly.io 代替 vercel。 如果打算面向国内的用户，这方面就会有一些更难的挑战：
- 国内极少有免费托管应用/数据库
- 合规、备案，例如 AI 算法备案；同时也要留意生成的内容是否符合相关法规。
- 国内习惯用 App；如果是 PC 页面，往往浏览器比较旧，在兼容性上需要更多时间
FAQ 常见问题
超时问题
由于使用的 API 是一次性完整返回全部内容，因此从查询到解析完成通常会卡数十秒的时间。需要考虑：
- UI 交互需要让用户有足够预期
- 部分结果可以缓存，例如文章里的场景，单词都可以缓存或提前查询好，并入库。
如果是 nextjs 部署到应用平台，需要设置好 maxDuration.