1. 一个家长的技术突围：为什么要自己动手做AI英语工具孩子上小学三年级那会儿，英语成绩单拿回来，阅读理解错一半，单词默写全靠临时抱佛脚。我试过报班、买点读笔、下了一堆App，结果呢？报班一周两次，路上来回一个半小时，孩子累我也累；点读笔新鲜三天就吃灰；App倒是装了不少，但要么广告满天飞，要么内容跟学校教材对不上，孩子点两下就跑去玩别的了。后来我琢磨明白一件事：市面上的英语学习工具，绝大多数是给“想学英语的成年人”设计的，而不是给“需要被盯着学的孩子”设计的。成年人有自驱力，孩子没有。成年人能忍受枯燥的背单词界面，孩子三秒就划走了。成年人知道学英语有用，孩子只知道“这玩意儿不好玩”。那段时间我正好在做一个跟大语言模型相关的项目，天天跟API打交道。有天晚上陪孩子读绘本，他突然问我：“爸爸，这个单词怎么读？”我下意识掏出手机查，查完念给他听，他又问：“那这个句子是什么意思？”我又查。来回折腾了五六次，我突然意识到：我手里这些工具，完全可以串起来做一个专门给他用的东西。于是就有了这个项目——花了一个月时间，用vibe coding的方式，做了一个AI英语学习工具。所谓vibe coding，就是我不写传统意义上的“代码”，而是通过自然语言描述需求，让AI帮我生成代码、调试、优化。我不是专业程序员，但懂一些技术逻辑，能看懂代码，能判断AI生成的东西对不对。这种方式让我这种“半吊子技术家长”也能把想法落地。这个工具解决的核心问题就三个：第一，孩子读英语时遇到不会的单词和句子，能立刻得到解释和发音，不用等我查；第二，能根据他当前的水平自动生成适合他的练习内容，而不是从网上随便找；第三，能记录他哪些词错得多、哪些句型不熟，下次重点练这些。适合谁来参考？如果你也是家长，懂一点技术或者愿意学，想给孩子做一个专属的学习工具，这篇文章就是写给你的。如果你是对AI应用开发感兴趣的技术人，想看看一个非专业开发者怎么用vibe coding把想法变成产品，也能从这里找到不少实操细节。哪怕你只是想了解“AI+教育”到底能做成什么样，这篇文章里的思路和踩坑记录也值得一看。2. 整体设计思路：为什么这么搭，而不是那么搭2.1 核心需求拆解：孩子到底需要什么在动手之前，我花了大概一周时间观察孩子用现有工具时的行为。结论很明确：孩子需要的不是“功能多”，而是“响应快、内容准、不打断”。响应快，是指他遇到问题到得到答案之间的等待时间要短。超过三秒，注意力就跑了。内容准，是指解释要符合他的认知水平，不能给一个三年级孩子讲“现在完成时的延续性用法”。不打断，是指学习流程要连贯，不能查个单词就跳到一个新页面，然后被其他内容吸引走。基于这三点，我把工具的核心功能锁定在四个模块：即时查词与句子解析：孩子输入或拍照识别一个单词/句子，工具返回中文释义、音标、发音音频、例句，以及这个句子在语法上的简单拆解。分级阅读材料生成：根据孩子当前词汇量，用AI生成短篇阅读材料，生词率控制在5%到10%之间，既不太简单也不太难以致挫败。智能练习与错题追踪：针对他最近查过的词、做错的题，自动生成填空、选择、连线等练习，并记录错误频率。学习报告与家长视图：每周生成一份简单报告，告诉我他查了哪些词、错了哪些、进步在哪里。这四个模块不是拍脑袋想的，而是对应了“输入-理解-练习-反馈”这个学习闭环。少了任何一个，工具就变成玩具。2.2 技术选型：为什么用这套组合技术选型上，我考虑的核心因素是：开发速度要快、维护成本要低、孩子用起来要稳。前端我选了微信小程序。原因很简单：孩子没有自己的手机，但家里有iPad，微信小程序在iPad上跑得很流畅。而且小程序不用安装，点开就用，对家长来说省事。另一个考虑是，小程序天然支持语音输入和拍照，这两个功能对低龄孩子特别友好——他不用打字，直接说话或者拍课本就行。后端我用了云函数+云数据库的方案。具体来说，是某云服务商提供的小程序云开发能力。为什么不用传统服务器？因为我不想每个月去管服务器运维、证书续期、安全补丁这些事。云函数按调用次数计费，孩子一天用几十次，一个月下来成本几乎可以忽略。云数据库用来存孩子的查词记录、错题本、学习报告，省去了自己搭数据库的麻烦。AI能力这块，我接入了大语言模型的API和语音合成API。大语言模型负责释义、例句生成、阅读材料生成、语法解析；语音合成负责把单词和句子读出来。这里有个关键决策：我没有用本地的离线模型，因为离线模型在释义准确性和例句自然度上差太多，而且更新麻烦。用云端API虽然每次调用有成本，但胜在效果稳定、无需维护。提示：选择云服务时，一定要看清楚免费额度和计费方式。我一开始没注意，测试阶段频繁调用，差点产生一笔不小的费用。后来设置了每日调用上限和缓存机制，成本才降下来。2.3 为什么选择vibe coding而不是传统开发说实话，如果按传统方式开发，这个项目我可能三个月都做不完。我不是全职开发者，每天能投入的时间就是孩子睡着后的两三个小时。传统开发需要我写前端页面、写后端接口、处理数据库、调试兼容性，每一块都是坑。vibe coding的好处在于，我把精力集中在“描述清楚我要什么”上，而不是“怎么写代码”上。比如我要一个“查词结果卡片”，我就告诉AI：“做一个卡片，上面显示单词、音标、发音按钮、中文释义、两个例句，例句里这个单词要高亮。”AI会生成代码，我运行看效果，不对就继续描述哪里不对，让它改。这种方式的关键是：你要能判断AI生成的东西对不对。如果你完全不懂技术，AI给你一段有安全漏洞的代码你也看不出来。我的做法是，每次AI生成代码后，我会重点检查几个地方：API密钥有没有硬编码在前端、用户输入有没有做过滤、数据库读写权限有没有设对。这几项检查花不了几分钟，但能避免大问题。另一个经验是：把大需求拆成小需求，一次只让AI做一件事。比如“做一个查词功能”这个需求太大了，AI生成的代码往往一堆问题。我会拆成：“先做一个输入框和按钮”、“点击按钮后调用API并把结果显示在页面上”、“给结果加上发音按钮”。每一步都验证通过，再进入下一步。这样虽然步骤多了，但每一步都可控，出问题也容易定位。3. 核心功能实现：从查词到阅读生成的完整链路3.1 即时查词：三秒内给出孩子能懂的答案查词功能是整个工具使用频率最高的模块。孩子读绘本、做作业时遇到不会的词，打开小程序，输入或语音说出单词，三秒内看到结果。实现上，前端部分我让AI生成了一个简洁的输入界面：一个文本输入框、一个语音输入按钮、一个拍照按钮。语音输入用的是微信小程序自带的语音识别接口，拍照用的是微信的OCR接口。这两个接口都是现成的，调用很简单，省去了自己接第三方服务的麻烦。后端逻辑是这样的：用户输入单词后，云函数先查缓存。如果这个词最近查过，直接返回缓存结果，响应时间在200毫秒以内。如果没查过，调用大语言模型API，提示词是这样写的：你是一个英语老师，正在给一个小学三年级的学生解释单词。 请用最简单的语言解释这个单词的意思，给出两个例句，例句要贴近小学生的生活。 同时给出这个单词的音标和词性。 输出格式为JSON，包含字段：word, phonetic, partOfSpeech, meaning, examples。这个提示词我改了十几版。最初的版本AI会给出很复杂的解释，比如“abandon”会解释成“放弃，遗弃，抛弃，中止”，还附带一堆同义词。孩子看了更糊涂。后来我加了“用最简单的语言”和“贴近小学生的生活”这两个约束，效果好很多。现在“abandon”的解释是“不要了，丢下不管了”，例句是“I abandon my old toys. 我把旧玩具丢掉了。”发音部分，我用了语音合成API。这里有个细节：我对比了好几个发音源，最后选了一个语速偏慢、发音清晰的。孩子跟着读的时候，太快的发音他跟不上，太慢又显得奇怪。语速设置在0.8倍左右比较合适。注意：调用大语言模型API时，一定要设置超时时间和重试机制。我有一次遇到API响应慢，孩子等了十秒还没结果，直接把iPad扔沙发上了。后来加了超时设置，超过三秒就返回“网络有点慢，再试一次吧”，同时后台继续请求，下次点击时直接返回缓存结果。3.2 分级阅读材料生成：让生词率刚刚好阅读是英语学习里最难自动化的一部分。市面上的分级阅读材料要么太简单（孩子觉得无聊），要么太难（孩子挫败）。我想要的是一种“动态分级”：根据孩子最近查过的词、做错的题，判断他当前的词汇量水平，然后生成刚好比他水平高一点点的阅读材料。实现思路是这样的：云数据库里存了孩子最近30天查过的所有单词，以及每个单词的查询次数。查询次数越多，说明这个词他越不熟。同时存了他做错的练习题，错题里涉及的单词也标记为“薄弱词”。生成阅读材料时，云函数先取出这些薄弱词，然后调用大语言模型API，提示词如下：请生成一篇适合小学三年级学生阅读的英语短文，主题是[动物/食物/学校生活等]。 要求： 1. 短文长度80-120词。 2. 必须包含以下单词：[薄弱词列表]，每个单词至少出现一次。 3. 其他单词的难度不要超过小学四年级水平。 4. 短文要有趣，能吸引8-9岁孩子的注意力。 5. 输出格式为JSON，包含字段：title, content, newWords。这里的关键是“其他单词的难度不要超过小学四年级水平”这个约束。如果不加这个约束，AI会生成一堆超纲词，孩子读两句就放弃了。加了之后，生词率基本能控制在5%到10%之间，正好是“跳一跳够得着”的难度。生成后的短文会显示在小程序里，薄弱词用黄色高亮。孩子点击高亮词，直接弹出释义和发音，不用跳转页面。读完之后，下面会自动生成三道理解题，题目也是AI根据短文内容生成的。实操心得：AI生成的阅读材料偶尔会出现事实错误或者逻辑不通的地方。我的做法是，生成后先自己快速扫一遍，确认没有明显问题再给孩子用。虽然多花一分钟，但避免了孩子学到错误内容。另外，我设置了一个“重新生成”按钮，孩子觉得这篇没意思，可以换一篇。3.3 智能练习与错题追踪：把力气花在刀刃上练习模块的设计逻辑是：不追求题量，追求“每道题都有针对性”。具体来说，每次孩子完成阅读或查词后，系统会自动从错题本和薄弱词库里抽题。题型有三种：填空（给中文填英文）、选择（给英文选中文）、连线（英文和中文配对）。题目由AI生成，但生成时会带上“干扰项”的要求。比如填空题，AI会生成三个错误选项，这些错误选项不是随便造的，而是从孩子之前混淆过的词里选。错题追踪的实现比较直接：每次练习结果写入云数据库，记录题目、正确答案、孩子的答案、时间戳。云函数每天凌晨跑一次批处理，统计每个词的错误次数，错误次数超过阈值的词自动进入“重点薄弱词”列表，下次生成阅读材料和练习题时优先使用。这里有个细节值得说：我设置了“错误次数衰减”。如果一个词之前错了五次，但最近一周都没再错，它的权重会逐渐降低。这样做的原因是，孩子是在进步的，不能因为一个月前错过几次就永远把它当薄弱词。衰减周期设为7天，权重每天降低10%。3.4 学习报告与家长视图：让家长看到进步家长视图是我特意加的一个模块。原因很简单：如果我看不到孩子的学习数据，我就不知道这个工具到底有没有用，也不知道该在哪些方面帮他。报告每周生成一次，内容包括：本周查词数量、新增词汇、错题数量、正确率变化、阅读完成篇数。数据以简单的柱状图和折线图展示，不搞花哨的仪表盘。我最关心的是两个指标：一是“本周新查词数量”，如果这个数字持续下降，说明孩子阅读量不够；二是“错题重复率”，如果同一个词反复错，说明需要人工介入帮他专门记一下。报告生成后，会通过微信服务通知推送给家长。孩子看不到这个报告，避免给他造成压力。4. 实操过程：从零到一的关键步骤与参数4.1 环境准备与项目初始化第一步是注册小程序账号。去微信公众平台注册一个个人主体的小程序，流程很简单，填邮箱、验证、选类目。类目选“教育-在线教育”就行，个人主体也能过。注册完成后，拿到AppID，这是后续所有开发的基础。第二步是开通云开发。在小程序开发者工具里，点击“云开发”按钮，按提示开通。开通后会得到一个环境ID，这个ID要记下来，后面云函数和数据库都要用。云开发的免费额度是每月一定的调用次数和存储空间，对于个人项目来说完全够用。第三步是安装开发者工具。去微信官方下载稳定版，安装后扫码登录。新建项目时，选择“小程序-云开发”，填入AppID，模板选“JavaScript-基础模板”。这样初始化出来的项目已经包含了云函数和云数据库的基本结构，省去了自己搭框架的时间。提示：开发者工具的版本很重要。我有一次用了测试版，云函数上传一直失败，换成稳定版就好了。建议始终用官方标注的“稳定版”。4.2 数据库设计与关键字段云数据库用的是文档型数据库，类似MongoDB。我设计了四个集合：words集合：存查词记录。字段包括：openid（用户标识）、word（单词）、queryCount（查询次数）、lastQueryTime（最后查询时间）、meaning（释义缓存）。mistakes集合：存错题记录。字段包括：openid、word、questionType（题型）、wrongCount（错误次数）、lastWrongTime、weight（权重，用于衰减计算）。readings集合：存阅读记录。字段包括：openid、title、content、newWords（生词列表）、completed（是否完成）、score（理解题得分）。reports集合：存周报数据。字段包括：openid、weekStart、weekEnd、totalQueries、newWordsCount、accuracyRate、readingCount。数据库权限设置很关键。我把所有集合的权限都设为“仅创建者可读写”，这样每个用户只能看到自己的数据。云函数里操作数据库时，用cloud.database()获取引用，不需要额外鉴权，因为云函数天然有管理员权限。4.3 云函数编写与API调用我一共写了六个云函数：queryWord（查词）、generateReading（生成阅读）、generateExercise（生成练习）、submitAnswer（提交答案）、generateReport（生成报告）、dailyBatch（每日批处理）。以queryWord为例，核心逻辑是这样的：const cloud = require('wx-server-sdk') cloud.init() const db = cloud.database() exports.main = async (event, context) => { const { word } = event const openid = cloud.getWXContext().OPENID // 先查缓存 const cache = await db.collection('words') .where({ openid, word }) .get() if (cache.data.length > 0) { // 更新查询次数和时间 await db.collection('words').doc(cache.data[0]._id).update({ data: { queryCount: db.command.inc(1), lastQueryTime: new Date() } }) return { code: 0, data: cache.data[0] } } // 调用大语言模型API const result = await callLLM(word) // 写入数据库 await db.collection('words').add({ data: { openid, word, queryCount: 1, lastQueryTime: new Date(), meaning: result } }) return { code: 0, data: result } }调用大语言模型API时，我用的是HTTP请求。这里有个坑：云函数默认的超时时间是3秒，但大语言模型API有时候需要5秒以上。解决办法是在云函数配置里把超时时间改成20秒。改的地方在cloudfunctions/queryWord/config.json里，加上"timeout": 20。注意：API密钥绝对不能写在前端代码里。我一开始图省事，把密钥写在了小程序的JS文件里，后来意识到这样别人反编译小程序就能拿到密钥。正确做法是把密钥存在云函数的环境变量里，云函数运行时从环境变量读取。4.4 前端页面与交互细节小程序前端我做了四个页面：首页（功能入口）、查词页、阅读页、报告页。查词页的交互我改了好几版。最初是输入框+按钮，孩子要打字。后来发现他打字慢，就加了语音输入按钮。再后来发现他有时候在书上看到单词，懒得打字也懒得读，就加了拍照识别。现在三种输入方式并存，他爱用哪个用哪个。阅读页的排版也调过。最初字体太小，孩子看着费劲。后来把正文字号调到20px，行高1.8，生词高亮色从红色改成黄色（红色太刺眼，孩子说“像错题”）。理解题放在文章下面，做完一题自动跳下一题，不用手动翻页。报告页的图表用的是微信小程序自带的canvas组件。我让AI生成了一个简单的柱状图绘制函数，传入数据数组就能画出来。没有用第三方图表库，因为那些库体积大，加载慢，对于这种简单图表来说没必要。4.5 成本控制与性能优化成本主要来自两块：大语言模型API调用和语音合成API调用。我算过一笔账：孩子每天查词大概20次，生成阅读材料2篇，生成练习题10道。大语言模型API每次调用成本约0.01元，语音合成每次约0.002元。一天下来大概0.3元，一个月不到10元。这个成本完全可以接受。但测试阶段我吃过亏。有一次调试时循环调用API，一晚上跑了上千次，第二天收到账单提醒才发现。后来我加了三道防线：第一，云函数里设置每日调用上限，超过就返回“今日次数已用完”；第二，查词结果缓存24小时，同样的词不重复调用；第三，在云开发控制台设置费用预警，超过阈值发短信提醒。性能方面，最大的瓶颈是冷启动。云函数如果一段时间没被调用，下次调用时需要重新初始化，耗时可能达到2-3秒。解决办法是设置定时触发器，每10分钟调用一次“保活”函数，让云函数保持热状态。这个保活函数什么都不做，就是空跑一下，成本极低，但能显著提升响应速度。5. 常见问题与排查技巧实录5.1 查词结果不准确或超纲这是最常见的问题。表现是：AI给出的释义太复杂，或者例句里包含孩子没学过的词。排查思路：先看提示词是不是不够具体。我最初的提示词只说了“解释这个单词”，AI就会按成年人词典的方式解释。后来加了“给小学三年级学生”“用最简单的语言”“例句贴近小学生生活”这三个约束，准确率大幅提升。如果个别词还是不对，我会手动在数据库里加一条“覆盖记录”。比如“bank”这个词，AI解释成“银行”，但孩子读的绘本里是“河岸”的意思。我就在数据库里加一条：word=“bank”，context=“river”，meaning=“河岸”。下次查这个词时，云函数先查覆盖记录，有就直接返回，没有再调AI。实操心得：覆盖记录不用多，我到现在也就加了二十几条。但这二十几条覆盖了孩子最常遇到的歧义词，效果立竿见影。5.2 语音识别在嘈杂环境下失灵孩子有时候在客厅用，电视开着，语音识别就把电视声音也收进去了，识别结果乱七八糟。解决办法有两个：一是加一个“按住说话”的交互，而不是“点击开始、点击结束”。按住说话时，小程序只收录按住期间的声音，减少环境噪音干扰。二是加一个“确认识别结果”的步骤，识别出来的文字显示在输入框里，孩子确认无误再点查询。如果识别错了，他可以手动改。这两个改动都不大，但体验提升很明显。孩子现在用语音查词基本不会出错了。5.3 云函数调用超时前面提过，云函数默认超时3秒，大语言模型API有时候响应慢，就会超时。排查步骤：第一，去云开发控制台看云函数日志，确认是不是超时导致的失败。第二，如果是超时，去config.json里把timeout改成20秒。第三，如果改了还超时，说明API本身响应太慢，需要加降级策略——比如先返回缓存结果（如果有的话），同时后台继续请求，下次点击时直接返回。我还加了一个“重试”按钮。如果查询失败，页面上显示“再试一次”，孩子点一下重新请求。这个简单的按钮解决了很多偶发问题。5.4 数据库读写权限报错云数据库的权限设置很容易搞错。我一开始把权限设成了“所有用户可读”，结果测试时发现别的用户能看到我的数据。后来改成“仅创建者可读写”，但云函数里写入数据时又报权限错误。原因是：云函数默认有管理员权限，不受集合权限限制。但如果云函数里用了db.collection().where().get()这种查询，而集合权限是“仅创建者可读写”，云函数查出来的数据会带上创建者过滤条件。解决办法是在云函数里用cloud.database()获取的是管理员权限的数据库引用，查询时不需要加openid过滤，因为云函数本身已经通过cloud.getWXContext().OPENID拿到了当前用户的openid，手动过滤即可。这个坑我踩了两天才搞明白。建议新手一开始就把所有集合权限设为“仅创建者可读写”，然后在云函数里手动处理openid过滤，这样最稳妥。5.5 孩子用几天就不用了这是最致命的问题。技术上的问题都能解决，但孩子不用，一切白搭。我的应对策略是：第一，加“成就系统”。每查10个词得一颗星，每完成一篇阅读得两颗星，攒够星星可以换一个小奖励（比如周末多看20分钟动画片）。第二，加“连续打卡”。连续三天使用，报告里会显示“连续打卡3天”，孩子看到这个数字会有成就感。第三，让内容有趣。阅读材料的主题让孩子自己选，他最近喜欢恐龙，就多生成恐龙相关的短文。注意：奖励机制要适度。我一开始设的奖励太高，孩子为了得星星疯狂查词，查完也不看释义。后来把奖励调低，同时要求“查词后必须点发音听一遍才算有效”，才把行为拉回正轨。5.6 常见问题速查表问题现象可能原因排查方法解决方案查词无响应云函数超时查看云函数日志调大timeout至20秒释义太复杂提示词不够具体检查提示词加“小学生”“简单语言”约束语音识别错误环境噪音测试不同环境改按住说话+确认步骤数据库报错权限设置不当检查集合权限设为仅创建者可读写孩子不用了缺乏激励观察使用频率加成就系统和连续打卡API费用超预期重复调用查看调用日志加缓存和每日上限发音不自然语音合成参数不对试听不同参数语速调至0.8倍阅读材料超纲提示词约束不足检查生成内容加“不超过四年级水平”6. 后续扩展与个人体会这个工具目前跑了三个月，孩子的英语成绩从班里中游到了前十。但我觉得最大的收获不是分数，而是他现在遇到不会的词会主动去查，而不是等我回来问。这个习惯的养成，比多背几十个单词重要得多。后续我打算加两个功能。一个是“口语对话练习”，让孩子跟AI用英语聊几句，AI会根据他的水平调整对话难度。另一个是“单词复习提醒”，根据遗忘曲线，在合适的时间提醒他复习之前查过的词。这两个功能技术上都不难，难的是怎么做得不让孩子反感。如果你也想做类似的东西，我的建议是：先想清楚“孩子到底需要什么”，再想“技术上怎么实现”。不要反过来。我见过不少家长，技术很厉害，做了一堆功能，但孩子一个都不用。问题就出在需求没搞清楚。另外，不要追求完美。我的工具到现在还有bug，界面也不够精致，但孩子用得很开心。先让它跑起来，再慢慢改。vibe coding最大的好处就是改起来快，今天发现一个问题，晚上花半小时就能修好。最后分享一个小心得：让孩子参与进来。我有时候会问他“你觉得这个按钮放这里好不好”“这个颜色你喜欢吗”。他参与了设计，用起来就更上心。有一次他说“查完词能不能有个小星星飞出来”，我花了一个小时加上去，他高兴了好几天。这种参与感，比任何奖励机制都管用。
1. 一个家长的技术突围：为什么要自己动手做AI英语工具孩子上小学三年级那会儿，英语成绩单拿回来，阅读理解错一半，单词默写全靠临时抱佛脚。我试过报班、买点读笔、下了一堆App，结果呢？报班一周两次，路上来回一个半小时，孩子累我也累；点读笔新鲜三天就吃灰；App倒是装了不少，但要么广告满天飞，要么内容跟学校教材对不上，孩子点两下就跑去玩别的了。后来我琢磨明白一件事：市面上的英语学习工具，绝大多数是给“想学英语的成年人”设计的，而不是给“需要被盯着学的孩子”设计的。成年人有自驱力，孩子没有。成年人能忍受枯燥的背单词界面，孩子三秒就划走了。成年人知道学英语有用，孩子只知道“这玩意儿不好玩”。那段时间我正好在做一个跟大语言模型相关的项目，天天跟API打交道。有天晚上陪孩子读绘本，他突然问我：“爸爸，这个单词怎么读？”我下意识掏出手机查，查完念给他听，他又问：“那这个句子是什么意思？”我又查。来回折腾了五六次，我突然意识到：我手里这些工具，完全可以串起来做一个专门给他用的东西。于是就有了这个项目——花了一个月时间，用vibe coding的方式，做了一个AI英语学习工具。所谓vibe coding，就是我不写传统意义上的“代码”，而是通过自然语言描述需求，让AI帮我生成代码、调试、优化。我不是专业程序员，但懂一些技术逻辑，能看懂代码，能判断AI生成的东西对不对。这种方式让我这种“半吊子技术家长”也能把想法落地。这个工具解决的核心问题就三个：第一，孩子读英语时遇到不会的单词和句子，能立刻得到解释和发音，不用等我查；第二，能根据他当前的水平自动生成适合他的练习内容，而不是从网上随便找；第三，能记录他哪些词错得多、哪些句型不熟，下次重点练这些。适合谁来参考？如果你也是家长，懂一点技术或者愿意学，想给孩子做一个专属的学习工具，这篇文章就是写给你的。如果你是对AI应用开发感兴趣的技术人，想看看一个非专业开发者怎么用vibe coding把想法变成产品，也能从这里找到不少实操细节。哪怕你只是想了解“AI+教育”到底能做成什么样，这篇文章里的思路和踩坑记录也值得一看。2. 整体设计思路：为什么这么搭，而不是那么搭2.1 核心需求拆解：孩子到底需要什么在动手之前，我花了大概一周时间观察孩子用现有工具时的行为。结论很明确：孩子需要的不是“功能多”，而是“响应快、内容准、不打断”。响应快，是指他遇到问题到得到答案之间的等待时间要短。超过三秒，注意力就跑了。内容准，是指解释要符合他的认知水平，不能给一个三年级孩子讲“现在完成时的延续性用法”。不打断，是指学习流程要连贯，不能查个单词就跳到一个新页面，然后被其他内容吸引走。基于这三点，我把工具的核心功能锁定在四个模块：即时查词与句子解析：孩子输入或拍照识别一个单词/句子，工具返回中文释义、音标、发音音频、例句，以及这个句子在语法上的简单拆解。分级阅读材料生成：根据孩子当前词汇量，用AI生成短篇阅读材料，生词率控制在5%到10%之间，既不太简单也不太难以致挫败。智能练习与错题追踪：针对他最近查过的词、做错的题，自动生成填空、选择、连线等练习，并记录错误频率。学习报告与家长视图：每周生成一份简单报告，告诉我他查了哪些词、错了哪些、进步在哪里。这四个模块不是拍脑袋想的，而是对应了“输入-理解-练习-反馈”这个学习闭环。少了任何一个，工具就变成玩具。2.2 技术选型：为什么用这套组合技术选型上，我考虑的核心因素是：开发速度要快、维护成本要低、孩子用起来要稳。前端我选了微信小程序。原因很简单：孩子没有自己的手机，但家里有iPad，微信小程序在iPad上跑得很流畅。而且小程序不用安装，点开就用，对家长来说省事。另一个考虑是，小程序天然支持语音输入和拍照，这两个功能对低龄孩子特别友好——他不用打字，直接说话或者拍课本就行。后端我用了云函数+云数据库的方案。具体来说，是某云服务商提供的小程序云开发能力。为什么不用传统服务器？因为我不想每个月去管服务器运维、证书续期、安全补丁这些事。云函数按调用次数计费，孩子一天用几十次，一个月下来成本几乎可以忽略。云数据库用来存孩子的查词记录、错题本、学习报告，省去了自己搭数据库的麻烦。AI能力这块，我接入了大语言模型的API和语音合成API。大语言模型负责释义、例句生成、阅读材料生成、语法解析；语音合成负责把单词和句子读出来。这里有个关键决策：我没有用本地的离线模型，因为离线模型在释义准确性和例句自然度上差太多，而且更新麻烦。用云端API虽然每次调用有成本，但胜在效果稳定、无需维护。提示：选择云服务时，一定要看清楚免费额度和计费方式。我一开始没注意，测试阶段频繁调用，差点产生一笔不小的费用。后来设置了每日调用上限和缓存机制，成本才降下来。2.3 为什么选择vibe coding而不是传统开发说实话，如果按传统方式开发，这个项目我可能三个月都做不完。我不是全职开发者，每天能投入的时间就是孩子睡着后的两三个小时。传统开发需要我写前端页面、写后端接口、处理数据库、调试兼容性，每一块都是坑。vibe coding的好处在于，我把精力集中在“描述清楚我要什么”上，而不是“怎么写代码”上。比如我要一个“查词结果卡片”，我就告诉AI：“做一个卡片，上面显示单词、音标、发音按钮、中文释义、两个例句，例句里这个单词要高亮。”AI会生成代码，我运行看效果，不对就继续描述哪里不对，让它改。这种方式的关键是：你要能判断AI生成的东西对不对。如果你完全不懂技术，AI给你一段有安全漏洞的代码你也看不出来。我的做法是，每次AI生成代码后，我会重点检查几个地方：API密钥有没有硬编码在前端、用户输入有没有做过滤、数据库读写权限有没有设对。这几项检查花不了几分钟，但能避免大问题。另一个经验是：把大需求拆成小需求，一次只让AI做一件事。比如“做一个查词功能”这个需求太大了，AI生成的代码往往一堆问题。我会拆成：“先做一个输入框和按钮”、“点击按钮后调用API并把结果显示在页面上”、“给结果加上发音按钮”。每一步都验证通过，再进入下一步。这样虽然步骤多了，但每一步都可控，出问题也容易定位。3. 核心功能实现：从查词到阅读生成的完整链路3.1 即时查词：三秒内给出孩子能懂的答案查词功能是整个工具使用频率最高的模块。孩子读绘本、做作业时遇到不会的词，打开小程序，输入或语音说出单词，三秒内看到结果。实现上，前端部分我让AI生成了一个简洁的输入界面：一个文本输入框、一个语音输入按钮、一个拍照按钮。语音输入用的是微信小程序自带的语音识别接口，拍照用的是微信的OCR接口。这两个接口都是现成的，调用很简单，省去了自己接第三方服务的麻烦。后端逻辑是这样的：用户输入单词后，云函数先查缓存。如果这个词最近查过，直接返回缓存结果，响应时间在200毫秒以内。如果没查过，调用大语言模型API，提示词是这样写的：你是一个英语老师，正在给一个小学三年级的学生解释单词。 请用最简单的语言解释这个单词的意思，给出两个例句，例句要贴近小学生的生活。 同时给出这个单词的音标和词性。 输出格式为JSON，包含字段：word, phonetic, partOfSpeech, meaning, examples。这个提示词我改了十几版。最初的版本AI会给出很复杂的解释，比如“abandon”会解释成“放弃，遗弃，抛弃，中止”，还附带一堆同义词。孩子看了更糊涂。后来我加了“用最简单的语言”和“贴近小学生的生活”这两个约束，效果好很多。现在“abandon”的解释是“不要了，丢下不管了”，例句是“I abandon my old toys. 我把旧玩具丢掉了。”发音部分，我用了语音合成API。这里有个细节：我对比了好几个发音源，最后选了一个语速偏慢、发音清晰的。孩子跟着读的时候，太快的发音他跟不上，太慢又显得奇怪。语速设置在0.8倍左右比较合适。注意：调用大语言模型API时，一定要设置超时时间和重试机制。我有一次遇到API响应慢，孩子等了十秒还没结果，直接把iPad扔沙发上了。后来加了超时设置，超过三秒就返回“网络有点慢，再试一次吧”，同时后台继续请求，下次点击时直接返回缓存结果。3.2 分级阅读材料生成：让生词率刚刚好阅读是英语学习里最难自动化的一部分。市面上的分级阅读材料要么太简单（孩子觉得无聊），要么太难（孩子挫败）。我想要的是一种“动态分级”：根据孩子最近查过的词、做错的题，判断他当前的词汇量水平，然后生成刚好比他水平高一点点的阅读材料。实现思路是这样的：云数据库里存了孩子最近30天查过的所有单词，以及每个单词的查询次数。查询次数越多，说明这个词他越不熟。同时存了他做错的练习题，错题里涉及的单词也标记为“薄弱词”。生成阅读材料时，云函数先取出这些薄弱词，然后调用大语言模型API，提示词如下：请生成一篇适合小学三年级学生阅读的英语短文，主题是[动物/食物/学校生活等]。 要求： 1. 短文长度80-120词。 2. 必须包含以下单词：[薄弱词列表]，每个单词至少出现一次。 3. 其他单词的难度不要超过小学四年级水平。 4. 短文要有趣，能吸引8-9岁孩子的注意力。 5. 输出格式为JSON，包含字段：title, content, newWords。这里的关键是“其他单词的难度不要超过小学四年级水平”这个约束。如果不加这个约束，AI会生成一堆超纲词，孩子读两句就放弃了。加了之后，生词率基本能控制在5%到10%之间，正好是“跳一跳够得着”的难度。生成后的短文会显示在小程序里，薄弱词用黄色高亮。孩子点击高亮词，直接弹出释义和发音，不用跳转页面。读完之后，下面会自动生成三道理解题，题目也是AI根据短文内容生成的。实操心得：AI生成的阅读材料偶尔会出现事实错误或者逻辑不通的地方。我的做法是，生成后先自己快速扫一遍，确认没有明显问题再给孩子用。虽然多花一分钟，但避免了孩子学到错误内容。另外，我设置了一个“重新生成”按钮，孩子觉得这篇没意思，可以换一篇。3.3 智能练习与错题追踪：把力气花在刀刃上练习模块的设计逻辑是：不追求题量，追求“每道题都有针对性”。具体来说，每次孩子完成阅读或查词后，系统会自动从错题本和薄弱词库里抽题。题型有三种：填空（给中文填英文）、选择（给英文选中文）、连线（英文和中文配对）。题目由AI生成，但生成时会带上“干扰项”的要求。比如填空题，AI会生成三个错误选项，这些错误选项不是随便造的，而是从孩子之前混淆过的词里选。错题追踪的实现比较直接：每次练习结果写入云数据库，记录题目、正确答案、孩子的答案、时间戳。云函数每天凌晨跑一次批处理，统计每个词的错误次数，错误次数超过阈值的词自动进入“重点薄弱词”列表，下次生成阅读材料和练习题时优先使用。这里有个细节值得说：我设置了“错误次数衰减”。如果一个词之前错了五次，但最近一周都没再错，它的权重会逐渐降低。这样做的原因是，孩子是在进步的，不能因为一个月前错过几次就永远把它当薄弱词。衰减周期设为7天，权重每天降低10%。3.4 学习报告与家长视图：让家长看到进步家长视图是我特意加的一个模块。原因很简单：如果我看不到孩子的学习数据，我就不知道这个工具到底有没有用，也不知道该在哪些方面帮他。报告每周生成一次，内容包括：本周查词数量、新增词汇、错题数量、正确率变化、阅读完成篇数。数据以简单的柱状图和折线图展示，不搞花哨的仪表盘。我最关心的是两个指标：一是“本周新查词数量”，如果这个数字持续下降，说明孩子阅读量不够；二是“错题重复率”，如果同一个词反复错，说明需要人工介入帮他专门记一下。报告生成后，会通过微信服务通知推送给家长。孩子看不到这个报告，避免给他造成压力。4. 实操过程：从零到一的关键步骤与参数4.1 环境准备与项目初始化第一步是注册小程序账号。去微信公众平台注册一个个人主体的小程序，流程很简单，填邮箱、验证、选类目。类目选“教育-在线教育”就行，个人主体也能过。注册完成后，拿到AppID，这是后续所有开发的基础。第二步是开通云开发。在小程序开发者工具里，点击“云开发”按钮，按提示开通。开通后会得到一个环境ID，这个ID要记下来，后面云函数和数据库都要用。云开发的免费额度是每月一定的调用次数和存储空间，对于个人项目来说完全够用。第三步是安装开发者工具。去微信官方下载稳定版，安装后扫码登录。新建项目时，选择“小程序-云开发”，填入AppID，模板选“JavaScript-基础模板”。这样初始化出来的项目已经包含了云函数和云数据库的基本结构，省去了自己搭框架的时间。提示：开发者工具的版本很重要。我有一次用了测试版，云函数上传一直失败，换成稳定版就好了。建议始终用官方标注的“稳定版”。4.2 数据库设计与关键字段云数据库用的是文档型数据库，类似MongoDB。我设计了四个集合：words集合：存查词记录。字段包括：openid（用户标识）、word（单词）、queryCount（查询次数）、lastQueryTime（最后查询时间）、meaning（释义缓存）。mistakes集合：存错题记录。字段包括：openid、word、questionType（题型）、wrongCount（错误次数）、lastWrongTime、weight（权重，用于衰减计算）。readings集合：存阅读记录。字段包括：openid、title、content、newWords（生词列表）、completed（是否完成）、score（理解题得分）。reports集合：存周报数据。字段包括：openid、weekStart、weekEnd、totalQueries、newWordsCount、accuracyRate、readingCount。数据库权限设置很关键。我把所有集合的权限都设为“仅创建者可读写”，这样每个用户只能看到自己的数据。云函数里操作数据库时，用cloud.database()获取引用，不需要额外鉴权，因为云函数天然有管理员权限。4.3 云函数编写与API调用我一共写了六个云函数：queryWord（查词）、generateReading（生成阅读）、generateExercise（生成练习）、submitAnswer（提交答案）、generateReport（生成报告）、dailyBatch（每日批处理）。以queryWord为例，核心逻辑是这样的：const cloud = require('wx-server-sdk') cloud.init() const db = cloud.database() exports.main = async (event, context) => { const { word } = event const openid = cloud.getWXContext().OPENID // 先查缓存 const cache = await db.collection('words') .where({ openid, word }) .get() if (cache.data.length > 0) { // 更新查询次数和时间 await db.collection('words').doc(cache.data[0]._id).update({ data: { queryCount: db.command.inc(1), lastQueryTime: new Date() } }) return { code: 0, data: cache.data[0] } } // 调用大语言模型API const result = await callLLM(word) // 写入数据库 await db.collection('words').add({ data: { openid, word, queryCount: 1, lastQueryTime: new Date(), meaning: result } }) return { code: 0, data: result } }调用大语言模型API时，我用的是HTTP请求。这里有个坑：云函数默认的超时时间是3秒，但大语言模型API有时候需要5秒以上。解决办法是在云函数配置里把超时时间改成20秒。改的地方在cloudfunctions/queryWord/config.json里，加上"timeout": 20。注意：API密钥绝对不能写在前端代码里。我一开始图省事，把密钥写在了小程序的JS文件里，后来意识到这样别人反编译小程序就能拿到密钥。正确做法是把密钥存在云函数的环境变量里，云函数运行时从环境变量读取。4.4 前端页面与交互细节小程序前端我做了四个页面：首页（功能入口）、查词页、阅读页、报告页。查词页的交互我改了好几版。最初是输入框+按钮，孩子要打字。后来发现他打字慢，就加了语音输入按钮。再后来发现他有时候在书上看到单词，懒得打字也懒得读，就加了拍照识别。现在三种输入方式并存，他爱用哪个用哪个。阅读页的排版也调过。最初字体太小，孩子看着费劲。后来把正文字号调到20px，行高1.8，生词高亮色从红色改成黄色（红色太刺眼，孩子说“像错题”）。理解题放在文章下面，做完一题自动跳下一题，不用手动翻页。报告页的图表用的是微信小程序自带的canvas组件。我让AI生成了一个简单的柱状图绘制函数，传入数据数组就能画出来。没有用第三方图表库，因为那些库体积大，加载慢，对于这种简单图表来说没必要。4.5 成本控制与性能优化成本主要来自两块：大语言模型API调用和语音合成API调用。我算过一笔账：孩子每天查词大概20次，生成阅读材料2篇，生成练习题10道。大语言模型API每次调用成本约0.01元，语音合成每次约0.002元。一天下来大概0.3元，一个月不到10元。这个成本完全可以接受。但测试阶段我吃过亏。有一次调试时循环调用API，一晚上跑了上千次，第二天收到账单提醒才发现。后来我加了三道防线：第一，云函数里设置每日调用上限，超过就返回“今日次数已用完”；第二，查词结果缓存24小时，同样的词不重复调用；第三，在云开发控制台设置费用预警，超过阈值发短信提醒。性能方面，最大的瓶颈是冷启动。云函数如果一段时间没被调用，下次调用时需要重新初始化，耗时可能达到2-3秒。解决办法是设置定时触发器，每10分钟调用一次“保活”函数，让云函数保持热状态。这个保活函数什么都不做，就是空跑一下，成本极低，但能显著提升响应速度。5. 常见问题与排查技巧实录5.1 查词结果不准确或超纲这是最常见的问题。表现是：AI给出的释义太复杂，或者例句里包含孩子没学过的词。排查思路：先看提示词是不是不够具体。我最初的提示词只说了“解释这个单词”，AI就会按成年人词典的方式解释。后来加了“给小学三年级学生”“用最简单的语言”“例句贴近小学生生活”这三个约束，准确率大幅提升。如果个别词还是不对，我会手动在数据库里加一条“覆盖记录”。比如“bank”这个词，AI解释成“银行”，但孩子读的绘本里是“河岸”的意思。我就在数据库里加一条：word=“bank”，context=“river”，meaning=“河岸”。下次查这个词时，云函数先查覆盖记录，有就直接返回，没有再调AI。实操心得：覆盖记录不用多，我到现在也就加了二十几条。但这二十几条覆盖了孩子最常遇到的歧义词，效果立竿见影。5.2 语音识别在嘈杂环境下失灵孩子有时候在客厅用，电视开着，语音识别就把电视声音也收进去了，识别结果乱七八糟。解决办法有两个：一是加一个“按住说话”的交互，而不是“点击开始、点击结束”。按住说话时，小程序只收录按住期间的声音，减少环境噪音干扰。二是加一个“确认识别结果”的步骤，识别出来的文字显示在输入框里，孩子确认无误再点查询。如果识别错了，他可以手动改。这两个改动都不大，但体验提升很明显。孩子现在用语音查词基本不会出错了。5.3 云函数调用超时前面提过，云函数默认超时3秒，大语言模型API有时候响应慢，就会超时。排查步骤：第一，去云开发控制台看云函数日志，确认是不是超时导致的失败。第二，如果是超时，去config.json里把timeout改成20秒。第三，如果改了还超时，说明API本身响应太慢，需要加降级策略——比如先返回缓存结果（如果有的话），同时后台继续请求，下次点击时直接返回。我还加了一个“重试”按钮。如果查询失败，页面上显示“再试一次”，孩子点一下重新请求。这个简单的按钮解决了很多偶发问题。5.4 数据库读写权限报错云数据库的权限设置很容易搞错。我一开始把权限设成了“所有用户可读”，结果测试时发现别的用户能看到我的数据。后来改成“仅创建者可读写”，但云函数里写入数据时又报权限错误。原因是：云函数默认有管理员权限，不受集合权限限制。但如果云函数里用了db.collection().where().get()这种查询，而集合权限是“仅创建者可读写”，云函数查出来的数据会带上创建者过滤条件。解决办法是在云函数里用cloud.database()获取的是管理员权限的数据库引用，查询时不需要加openid过滤，因为云函数本身已经通过cloud.getWXContext().OPENID拿到了当前用户的openid，手动过滤即可。这个坑我踩了两天才搞明白。建议新手一开始就把所有集合权限设为“仅创建者可读写”，然后在云函数里手动处理openid过滤，这样最稳妥。5.5 孩子用几天就不用了这是最致命的问题。技术上的问题都能解决，但孩子不用，一切白搭。我的应对策略是：第一，加“成就系统”。每查10个词得一颗星，每完成一篇阅读得两颗星，攒够星星可以换一个小奖励（比如周末多看20分钟动画片）。第二，加“连续打卡”。连续三天使用，报告里会显示“连续打卡3天”，孩子看到这个数字会有成就感。第三，让内容有趣。阅读材料的主题让孩子自己选，他最近喜欢恐龙，就多生成恐龙相关的短文。注意：奖励机制要适度。我一开始设的奖励太高，孩子为了得星星疯狂查词，查完也不看释义。后来把奖励调低，同时要求“查词后必须点发音听一遍才算有效”，才把行为拉回正轨。5.6 常见问题速查表问题现象可能原因排查方法解决方案查词无响应云函数超时查看云函数日志调大timeout至20秒释义太复杂提示词不够具体检查提示词加“小学生”“简单语言”约束语音识别错误环境噪音测试不同环境改按住说话+确认步骤数据库报错权限设置不当检查集合权限设为仅创建者可读写孩子不用了缺乏激励观察使用频率加成就系统和连续打卡API费用超预期重复调用查看调用日志加缓存和每日上限发音不自然语音合成参数不对试听不同参数语速调至0.8倍阅读材料超纲提示词约束不足检查生成内容加“不超过四年级水平”6. 后续扩展与个人体会这个工具目前跑了三个月，孩子的英语成绩从班里中游到了前十。但我觉得最大的收获不是分数，而是他现在遇到不会的词会主动去查，而不是等我回来问。这个习惯的养成，比多背几十个单词重要得多。后续我打算加两个功能。一个是“口语对话练习”，让孩子跟AI用英语聊几句，AI会根据他的水平调整对话难度。另一个是“单词复习提醒”，根据遗忘曲线，在合适的时间提醒他复习之前查过的词。这两个功能技术上都不难，难的是怎么做得不让孩子反感。如果你也想做类似的东西，我的建议是：先想清楚“孩子到底需要什么”，再想“技术上怎么实现”。不要反过来。我见过不少家长，技术很厉害，做了一堆功能，但孩子一个都不用。问题就出在需求没搞清楚。另外，不要追求完美。我的工具到现在还有bug，界面也不够精致，但孩子用得很开心。先让它跑起来，再慢慢改。vibe coding最大的好处就是改起来快，今天发现一个问题，晚上花半小时就能修好。最后分享一个小心得：让孩子参与进来。我有时候会问他“你觉得这个按钮放这里好不好”“这个颜色你喜欢吗”。他参与了设计，用起来就更上心。有一次他说“查完词能不能有个小星星飞出来”，我花了一个小时加上去，他高兴了好几天。这种参与感，比任何奖励机制都管用。