作者：雪隐_上班了 本文欢迎分享、聚合讨论，但不接受整篇搬运。圈子不大，写文不易，急用可联系授权。
上集回顾
上回说到，我画了设计稿，又和AI聊了几个来回，整出了7张表的数据库设计。
表建好了，问题来了------
表里是空的。
就像你买了套房，装修方案都定好了，结果发现房子里连块砖都没有。
words表，作为整个App的核心数据源，里面一条单词都没有。没有数据，后面的学习进度、复习计划、每日打卡全是空中楼阁。
所以这一篇，咱们专门聊聊------
怎么给单词库塞满数据。
先解释一下这个表的设计
再看一眼这个words表：
sql
CREATE TABLE words (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
word VARCHAR(200) NOT NULL COMMENT '单词/词组/句型',
phonetic VARCHAR(200) NULL COMMENT '音标',
pos VARCHAR(20) NULL COMMENT '词性/phrase/pattern',
definition TEXT NOT NULL COMMENT '释义',
example TEXT NULL COMMENT '例句',
audio_url VARCHAR(500) NULL COMMENT '音频 URL',
type VARCHAR(20) NOT NULL DEFAULT 'word' COMMENT '类型: word/phrase/pattern',
is_custom TINYINT(1) NOT NULL DEFAULT 0 COMMENT '是否用户自定义',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY uk_word_pos (word, pos),
INDEX idx_word (word)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '单词库';注意到那个UNIQUE KEY uk_word_pos (word, pos)没？
这意味着：一个单词可以有多条记录，每个词性一条。
举个例子：
apple+n.→ 一条记录，释义是"苹果"apple+v.→ 另一条记录，释义是"（古语）说......"，虽然基本用不到
为啥这么设计？
因为我在背单词的时候，经常遇到"这个词我认识，但换了个词性就不认识了"的情况。
你看"book"，名词是"书"，动词是"预定"。
如果你只背了名词，看到"book a ticket"就懵了。
然后你骂骂咧咧地说："这单词我背过啊！怎么意思不一样！"
所以，一个词性一条记录，分开了才能精准打击。
这也意味着------如果我有5000个单词，平均每个词2到3个词性，那最终表里的数据就是1万到1.5万条，不是5000条。
5000个单词 × 3个词性 = 15000条记录。
这还没算词组和句型呢。
加上的话，直接奔着2万去了。
数据从哪儿来？我踩过的三个坑
表设计好了，数据怎么来？
方案一：免费API，白嫖失败
我首先想到的是api.dictionaryapi.dev，免费、无需注册、看起来非常美好。
结果呢？
前50个请求：丝滑。
第51个请求：慢了一点。
第100个请求：开始报错。
第200个请求："Rate limit exceeded"。
这感觉就像你进了自助餐厅，
前两盘菜随便拿，第三盘开始服务员盯着你看，
第四盘的时候直接把你的盘子收走了。
免费API，白嫖失败。
方案二：付费API，告辞
又看了看其他API------
一个月几十美元？
几百美元？
我掏出计算器算了一下：
这个月失业金......哦不对，我没领失业金。
这个月积蓄......算了不说了，说多了都是泪。
付费API，告辞。
方案三：OCR扫描词典？太折腾了
有人说：你可以用OCR扫描电子词典啊，然后提取数据。
我试了。
效果确实不错，但问题在于------
你得有一本高质量的电子词典。
扫描完了还得清洗数据，还得校对，还得......
这就像你想吃顿好的，
方案是：先养头猪，宰了，切了，腌了，再自己下厨。
好吃是好吃，但等吃到嘴的时候，已经饿过头了。
太折腾了。我选择放弃。
终极方案：让本地大模型给我打上万份工
最后我走了第一条路，但换了个姿势------
用本地大模型批量生成数据。
第一步：让DeepSeek给我列单词清单
我打开DeepSeek的网页，输入：
"给我生成一个5000个常用英语单词的JSON数组，格式是
["word1", "word2", ...]，从最简单的开始。"
AI噼里啪啦给我吐了一长串。
我复制出来，存成了一个words.json文件。
5000个单词，AI生成的时间：大概30秒。
我一个一个想的话：大概需要......一辈子。
第二步：本地LM Studio，让模型干活
然后我打开本地的LM Studio，加载了一个模型------
Tencent-Hunyuan/Hy-MT2-7B。
为什么选这个？
因为我的5060Ti 16G跑得动，
而且这个模型的中英文理解都不错。
至于那些70B的大模型，
我只能说：不是我不想用，是显卡不允许。
5060Ti：我尽力了，你别太过分。
第三步：写个程序，批量调用
我写了个简单的Node.js脚本，大概逻辑是：
- 读取
words.json，拿到5000个单词 - 每10个单词一组，发给本地LM Studio
- 提示词大概长这样：
css
请为以下每个单词生成释义，返回JSON格式。
每个单词的格式：{"单词": [{"pos": "词性", "definition": "释义", "example": "例句"}]}
注意：一个单词可能有多个词性，每个词性一条。
单词列表：["apple", "appear", ...]- 收到返回的JSON，解析成对象
- 插入数据库
5000个单词，平均每个词2-3个词性，
LM Studio吭哧吭哧跑了大概......
反正我泡了杯茶，刷了会儿短视频，回来就好了。
最终表里插入了1万多条记录。
第四步：音频链接？白嫖一个模版
audio_url这个字段怎么填？
我直接用了一个免费的公开接口：
ruby
https://api.dictionaryapi.dev/media/pronunciations/en/{单词}-us.mp3把{单词}替换成当前单词就行。
比如apple就是：
ruby
https://api.dictionaryapi.dev/media/pronunciations/en/apple-us.mp3注意：这个接口是dictionaryapi.dev的，
虽然他们API有请求限制，但音频文件本身是可以直接访问的。
这算不算白嫖？
算。
但我跑都跑了，你还能顺着网线来打我不成？
最终成果
一顿操作下来，我的words表里躺了1万多条数据。
有单词，有词组，有句型。
有音标，有释义，有例句。
有音频链接，有词性区分。
一个App的"弹药库"，就这么建好了。
接下来的学习进度、复习计划、每日打卡，都建立在它上面。
你可能会问：1万多条够吗？
当然不够。
但这事儿就跟吃饭一样，
你得先吃上第一口，再考虑吃饱。
后续再加词库、加用户自定义单词、加导入导出......
那都是后话了。
写在最后
这一篇其实没什么高深的技术，
核心就一句话：
用本地大模型，解决"没有数据"的问题。
思路比技术重要。
免费API不行，就换付费的，付费的嫌贵，就自己造。
自己造一个上万条数据的"单词工厂"，也是一条路。
这世界上的问题，
95%都能用"找替代方案"解决，
剩下5%用"找更多替代方案"解决。
所以，别在一棵树上吊死。
API不行就换模型，模型不行就换思路，思路不行就......
就先歇会儿，喝杯茶再说。
喜欢就点个赞 ，
觉得有用就评论 两句，
觉得我是在吹牛......那就看到最后，看我到底能不能做成。