事情是从几个很基础的单词开始的

最近使用多邻国浅学了一下日语。

最开始学到的词都很基础：

すし
みず
ごはん
おちゃ
ください

词汇量不多，我却很快发现了一件有点可惜的事。

五十音会在不同单词里反复出现。例如我明明已经在「すし」里见过「し」，后来遇到带有「し」的新词时，却不一定能马上想起它。背单词时，我的注意力总在新词上，之前学过的词依然安静地躺在列表里。

当时我冒出的第一个想法很简单：

能不能让每一个假名，都找到我以前学过的对应词汇？

以后输入「し」，我就能看到所有包含「し」的旧词；输入一个新单词时，也能顺便把相关的旧词带出来。

我觉得这样学一个新词，就不只是在词汇表里增加一行，还会顺手复习一批旧词。

这个念头出现时，我并没有马上开始写代码。因为我只有一个模糊的使用场景，还不知道它最后应该长成什么样。

于是我先去找 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