【HugLang】产品日记3.21

我上一篇是《我心中的一团锦绣》，如果把"心中的锦绣"实例化我想就是HugLang了。

HugLang是一个通过AGC去学习语言的APP，也是我至今为止设计的操刀的最复杂，最用心，最认真的作品。

这一周HugLang更新了十余次，WakaTime工作时间是30h，平均每天是4-5个小时，当然因为它只记录的是在编译器工作的时间，但也大差不差。说实话我对这个时间不是很满意。

WakaTime

让我们来反思一下我的时间都去了哪里，每天12点上床，我会在床上玩2个小时左右手机，社交时间+小郭去看病+见人等等都是事件型时间支出。但其实其他大多数时间我都是坐在电脑面前的。可惜苹果没有了ManicTime，没法详细的记录我的屏幕活动时间了。

所以我的优化方向应该是，每晚睡前玩手机的时间。它的解决方案有两种，第一种是晚点上床，第二种是早点睡。

策略：以后睡前不带手机上床，如果不想上床就再工作一会。我会在下次周记里给予策略的执行度和反馈。

关于HugLang，HugLang目前进度还是属于早期阶段。上周把小郭写的代码重构了一遍，几千行代码糊在一个文件，而且还很多Bug，基本不可用。RN有很多坑，但是也有很多“包”去解决，解决坑的往往不是一个json配置项，而是一个“包”。比如安卓和IOS的阴影问题，就挺掉头发的。但是技术栈目前已经定下来了，选择RN+Fastify，不懂为什么很多前端要选FastAPI，速度被TS吊着打，你这FastAPI真的Fast吗？前端可以不注重性能优化，但是ToC的后端，性能===服务器配置===金钱。移动端框架也纠结了很多，但还是RN，什么Weex，还有字节新出的那个框架，本质上都是RN。只有RN和JS bridge这两种方案，要不就纯Web，要不就是RN。

最近新想到HugLang的理念是，“你只需要对话，剩下的交给我们。”也就是说把用户的行为进行简化，用户只需要聊天，不用手动操作他想通过聊天去学哪些生词，这是一种优雅的解决方案。这背后所需要的是两个，第一个是对它此刻该单词的学习情况的了解，第二个是对每次学习完成后的成果量化。

而具体到实现上需要解决的事两个问题，第一个问题是什么时候我的单词应该出现在对话里？第二个问题是我该如何量化用户通过对话对单词的学习状况？

前者是有两个准则可以依据的，第一种是根据概率去计算的，用户不会的概率越大的单词越应该出现。第二种是根据复习价值去计算的，根据艾宾浩斯遗忘曲线，越到后面单词复习的价值越高。其实回归他们的本质就是“新词”和“复习”的过程，这两者必然不可以缺一存一，而是应该并行存在的。最好的方式是动态维持一个表格，最具有复习价值和最可能不会的，但其实最具有复习价值这个是一个抽象的概念呢，因为它定义了一个复合名词——“复习价值”。

什么是复习价值？是单次复习可以保留最长遗忘时间的单词？是用户觉得他已经学会的单词还是模糊不清的单词，还是一点印象都没有单词？根据二八定则，我们要付出20%的努力拿到80%的效果。所以模糊不清的单词是最具有复习价值的单词，因为这是它正在完成它的20%。所以最有复习价值的单词，我想应该是模糊不清的单词。

所以我们选单词进入Prompt中，应该要依据两个原则，第一个原则是最具有复习价值的单词，第二个原则是新单词。但是它也需要讲究资产配比的，如果我们一味的学习模糊不清的单词，那就没有复习这一说了，合适的单词配置比例也是需要的，同时需要的还有语意，合适的语意是80%的工作，暂时不用考虑，因为它不是关键。或许我们增加一个Prompt就可以了，相信AI。

这是其中一个核心理念之一。

如果说另外的核心理念，我想可定制化内容和场景也是很重要的，我后端需要引入一个翻译的API，让我的翻译速度相对快一些。这个翻译主要是为了实现，Prompt的连续对话，因为如果你用中文的prompt要求输出英文，会出现中文（取决于你的模型）。

如果用营销话语来说就是，我们的卖点：“你只需要聊天，剩下的交给我们。”“丰富的插件社区，你可以和任何场景的任何人对话。”“娱乐化学习，边聊天边学习。”
未来扩展的方向可以是AI狼人杀，AI剧本杀，海龟汤，桌游等等...这就是大方向，你要做一款学习软件还是做一款社交软件？我是父集，他们是子集。

这周的工作安排一下，这周去做聊天页，然后做的过程中会完成以下工作，流程分先后：

1. 数据逻辑流程确认

2. 数据格式（插件市场，聊天页，前端数据库，后端数据库，历史记录）确认

3. 后端搭建聊天页功能API（流式/非流式传输API）（Prompt合成策略-插件+语言学习（可以暂时空置））

4. 前端流式传输完成

5. 对话记录查看

6. 插件市场查看

7. 推荐算法API实现