学日语时冒出一个小念头,我和 GPT、Codex 一天把它做成了工具
事情是从几个很基础的单词开始的最近使用多邻国浅学了一下日语。最开始学到的词都很基础すし みず ごはん おちゃ ください词汇量不多我却很快发现了一件有点可惜的事。五十音会在不同单词里反复出现。例如我明明已经在「すし」里见过「し」后来遇到带有「し」的新词时却不一定能马上想起它。背单词时我的注意力总在新词上之前学过的词依然安静地躺在列表里。当时我冒出的第一个想法很简单能不能让每一个假名都找到我以前学过的对应词汇以后输入「し」我就能看到所有包含「し」的旧词输入一个新单词时也能顺便把相关的旧词带出来。我觉得这样学一个新词就不只是在词汇表里增加一行还会顺手复习一批旧词。这个念头出现时我并没有马上开始写代码。因为我只有一个模糊的使用场景还不知道它最后应该长成什么样。于是我先去找 GPT 聊了聊。GPT 做的第一件事不是给答案而是追问我把学习中的不便和最初的想法告诉 GPT我们先围绕这个想法反复讨论在与GPT讨论的过程中我逐渐意识到我最初想做的并不只是“输入「し」搜索旧词”。如果每次学习新词系统都能分析它和旧词之间的共同假名、连续片段再把这种联系保存下来那么持续增长的其实不是一张单词表而是一张属于我自己的词汇关系网络。这时候 KanaGraph 的方向才慢慢清楚每学习一个新词就找出它和旧词之间的联系让孤立的单词逐渐连成网络。这一阶段GPT 更像一个不断提问的产品搭档。它没有替我制造需求而是帮我把自己已经感觉到、却没有说清楚的问题摊开来看。模糊的想法是怎样变成一套具体规则的产品方向清楚以后下一步是让它变得可以实现。我们先讨论了最核心的问题怎样从一个假名片段快速找到旧词思路是把每个学过的单词拆成所有连续片段。例如「ごはん」可以拆成ご ごは ごはん は はん ん「ありがとう」则可以拆出あ、あり、ありが、ありがと、ありがとう り、りが、りがと、りがとう が、がと、がとう と、とう う这些片段提前整理好以后将来无论输入「りが」还是「ありが」系统都可以直接找到「ありがとう」不需要每次把所有单词重新检查一遍。后来我才知道这和搜索引擎里的倒排索引思路很接近。对我来说重要的不是记住这个名词而是它刚好解决了我的学习问题把“某个假名出现在哪些词里”提前记录下来。接着我们又把“两个词为什么相关”拆成了几条简单规则共同出现了多少个不同假名最长的共同连续片段有多长共同片段是否同时位于两个词的开头或结尾。比如ごはん / はな 共同假名は 属于比较弱的联系ありがとう / ありがたい 共同片段ありが 属于很强的联系我们还特意划了一条边界KanaGraph 当前只说明两个词在假名形态上有联系不会把它包装成语义关系。「いしゃ」和「すし」都包含「し」这可以成为一次复习提醒但不代表医生和寿司在词义上有关。到这里我原来那句“每一个假名都能找到学过的词”已经变成了一套可以交付的规则输入什么、怎样索引、怎样计算、怎样展示、数据如何保留都有了明确答案。这些不是我坐下来一次想完整的而是我把学习感受交给 GPT再通过一轮轮追问共同整理出来的。需求说清楚以后我把它交给了 Codex接下来才进入开发。我把前面整理出的完整方案交给 Codex。它负责把方案变成一个真正可以使用的网站而不是只给我几段示例代码。这一步里Codex 主要完成了几件事。第一搭出完整项目。首页可以录入假名、汉字和释义输入过程中会实时显示旧词另外还有词汇本、关系图和设置页面。用户数据只保存在自己的浏览器里不需要注册账号也不需要配置服务器。第二把前面讨论的规则真正写成程序。包括假名统一处理、连续片段索引、相似度计算、学习和删除词汇时的数据更新以及词汇较多时的查询限制。Codex 不只是把页面画出来也把这些藏在页面背后的行为连了起来。第三替项目做检查。例如「ごはん」和「はな」应该是弱联系「ありがとう」和「ありがたい」应该是强联系这些例子被写成测试。它还检查了词汇编辑、删除、导入导出、页面构建和一万词规模下的查询避免工具只在演示数据里能用。第四完成交付。Codex 整理了使用文档、自动检查流程和部署配置把代码提交到 GitHub。当天KanaGraph 就可以通过一个公开网址访问了。整个过程中我并不是逐行告诉 Codex 代码该怎么写。我做得更多的是确认这是不是我想要的学习方式哪些关系应该解释哪些功能现在不需要以及最后做出来的东西能不能真的用。GPT 帮我把“想做什么”问清楚Codex 负责把“已经说清楚的东西”实现、测试并交付。两者解决的是不同阶段的问题。真正让我觉得它有用是学习「いしゃ」的时候工具上线并不等于想法成立。最后还是得把自己的词放进去用。我把前两个学习阶段的词汇又在 KanaGraph 实践了一遍这些词汇会记录在词汇本学习「いしゃ」时系统一下找回了四个之前学过的词旧词共同出现的假名おちゃゃやさしいい、しすししくださいい看到「すし」的时候我的感受很明显。如果只是在普通单词表里学习「いしゃ」我几乎不会主动想到寿司。但系统把共同的「し」指出来以后「すし」立刻又从记忆里出现了一次。这些词的意思未必相关关系也有强有弱。可就在学习一个新词的几秒钟里四个旧词重新经过了我的注意力。那一刻我才觉得最开始那个很小的念头真的被用上了。我不再只是向单词表添加内容而是在让自己的词汇网络慢慢长大。词汇不再只是按时间排列的列表而是开始形成一张可以探索的关系网络。这一天也让我重新理解了“用 AI 做工具”从记录学习痛点、和 GPT 讨论到 Codex 完成代码、测试并部署 KanaGraph这些事情发生在同一天。以前做一个个人工具通常要先考虑自己会不会设计、会不会写前端、会不会处理数据、会不会部署。很多小需求往往就在这些门槛前停下来了因为它看起来“不值得专门开发”。AI 改变的不是人从此什么都不用做而是把“有一个具体需求”和“做出一个能用的工具”之间的距离缩短了很多。你不必先成为完整意义上的产品经理或全栈工程师才有资格解决自己的问题。你可以先从一个非常个人、甚至看起来很小的不便开始我背新词时总是想不起包含相同假名的旧词我整理资料时总在重复做同一个步骤我记录生活时现有软件的流程并不适合我我想用一种只有自己需要的方式查看数据。这类问题过去很难变成产品因为它们可能只服务一个人。现在“只服务自己”反而可以成为动手的充分理由。如果你也有类似的念头可以尝试下面这条路径。1. 先记录具体发生过的不便不要一开始就说“我想做一个很厉害的平台”。先写清楚某个时刻发生了什么你为什么觉得麻烦以及理想状态是什么。我的起点就只有一句话每一个假名都应该能找到我以前学过的对应词汇。2. 让 GPT 追问不要急着让它写方案把 GPT 当成一个帮助你整理思路的人。让它一次问一个问题直到目标、使用场景和最小功能都变得清楚。很多时候我们缺的不是答案而是还没有把自己的需求说到足够具体。3. 把已经收敛的方案交给 Codex当功能和边界说清楚后再让 Codex 进入项目负责实现、运行测试、修复问题、写文档和部署。描述得越清楚最终做出来的东西越像你的工具而不是 AI 随机生成的模板。4. 一定要放入自己的真实数据使用工具能打开只说明代码运行了。只有当它真的进入你的日常才知道问题有没有被解决。对我来说这个验证时刻就是输入「いしゃ」后再次看到「すし」。写在最后KanaGraph 仍然只是第一个版本。它没有词典、发音也不会替我记住单词。但它已经做到了我最初想要的事在学习新词时把以前学过的词重新带回来。更重要的是这次经历让我感受到一种新的可能。我们每天都会遇到只属于自己的小问题。过去只为一个人开发工具显得成本太高现在借助 GPT 和 Codex一个普通的想法也有机会在很短时间里变成真正能使用的东西。不一定要做一家公司的产品也不一定要先想清楚商业模式。能解决自己的问题已经是一个工具很好的开始。如果你也在学习日语可以直接打开 KanaGraph把自己学过的词放进去。只有换成你的真实词汇这张关系网络才会开始属于你。在线体验https://kanagraph.netlify.app/开源代码https://github.com/xieyongxin/KanaGraph