利用AI将Telegram聊天记录转化为可查询知识库

```html

把三年的群聊记录变成可以随时提问的知识库：一条被忽略的变现路径

很多人不知道，自己手机里那些积累了几年的微信群、Telegram群聊，其实是一座沉睡的金矿。客户咨询记录、技术讨论、问题解答、案例分析……所有有价值的对话全埋在几千条消息里，想用的时候根本找不着。

有人就把这件事做成了一门生意：帮别人把杂乱的聊天记录整理成结构化的知识库，然后按文档收费。国内做类似的活儿，在闲鱼、猪八戒、淘宝服务上报价通常在500元到3000元之间，复杂的多群整合项目甚至能报到5000元以上。按1美元约合7.2人民币算，这个生意在海外对应的客单价大约是70到400美元，属于典型的轻资产、高毛利的知识服务。

整个流程的难点不在于收费，而在于数据清洗。导出文件格式不统一、消息体里混着富文本、日期格式各不一样、转发消息嵌套发送者……稍不注意就会把整个流程搞崩。下面把这套方法完整拆解一遍。

第一步：导出原始数据

Telegram的导出功能藏在两个客户端里，且格式完全不同：

• 桌面端（Windows/macOS）：导出一个JSON文件，结构是{name, messages: [{id, date, from, text, text_entities}]}
• Mac专属客户端：导出的是分页HTML文件，每个文件几MB，需要逐个解析

两种格式必须同时处理，因为不同用户习惯用不同客户端。

第二步：处理JSON里的「假字符串」

普通消息的text字段是字符串，比如"hello"。但只要消息里加了粗体、链接，text就变成了数组：

"text": ["see ", { "type": "bold", "text": "section 4" }, " first"]

这时候直接用String(msg.text)，会得到一串[object Object]，整条消息就废了。必须写一个递归函数，把数组里的每个run提取出来拼接：

function contentValueToString(v) {
 if (v === null || v === undefined) return '';
 if (Array.isArray(v)) {
 return v.map(x =>
 x && typeof x === 'object' && typeof x.text === 'string'
 ? x.text
 : contentValueToString(x)
 ).join('');
 }
 if (typeof v === 'object') return renderTree(v, 0, new WeakSet());
 return String(v);
}

这一步是整个数据清洗流程里最容易翻车的地方。

第三步：解析HTML的三个隐藏陷阱

HTML导出用正则和字符串切割就够了，不需要引入DOMParser。但有三个坑在小批量测试时根本看不出来：

• 发送者是黏性的：HTML只在每条消息第一次出现时打印发送者名字，后续连续消息只写日期和时间。要用一个游标变量记住上一个发送者。
• 转发消息嵌套原作者：被转发的消息里会嵌套一层<div class="forwarded body">，里面又写了一个发送者。匹配时必须从外层切，提取外层的from_name，否则就把原作者当成当前发送者了。
• 日期格式不统一：Mac客户端写的是9 September 2020, 18:44:51，桌面端写的是09.09.2020 18:44:51 UTC+01:00。两种格式都要兼容。

第四步：分块，让NotebookLM能吃下去

清洗完就该喂给AI了。这里很多人会用NotebookLM，因为它是目前公认最适合做知识库问答的工具。但NotebookLM有两个硬性限制：

• 每个notebook最多50个source
• 每个source文件最大500,000词

群聊一长，第二个限制先撞上。所以必须把消息按词数贪心装箱，每个文件控制在40万词以内，预留位置给后续追加。

关键技巧：分桶时要测量渲染后的Markdown长度，而不是原始文本长度。因为消息之间的分隔符、引用块、发送者前缀这些都会膨胀体积。

第五步：避免O(n²)的性能陷阱

最朴素的写法是：往桶里加一条消息，重新渲染一次，看看有没有超词数。这会导致每加一条都要遍历整个文件，时间复杂度是O(n²)，几千条消息直接卡死。

正确做法是用WeakMap缓存每条消息渲染后的Markdown长度，添加消息时只计算新增部分，整个装箱过程变成O(n)。三千条消息几秒钟就处理完了。

第六步：增量更新，而不是每次重跑

群聊每天都在长。客户下个月再导出一次，不可能让你从头处理一遍。朴素的设计是本地存一个「水位线」——记住最后处理的消息日期，过滤新消息。

但这种方案在迁移设备、客户端升级时容易丢状态。更可靠的做法是把状态存在目的地本身：每次导出时记录最后一条消息的ID和日期戳，存在NotebookLM的某个source里，或者存在外部的JSON清单里。这样无论换电脑还是换客户端，都能精确续上。

变现思路：怎么把这个流程变成持续订单

单次整理可以收500到3000元，但真正的钱在自动化：

• 把整套数据清洗脚本打包成工具，卖给有多个群需要管理的小红书博主、知识付费博主、跨境电商团队
• 提供订阅制服务：每月帮客户增量更新知识库，每月收费200到800元
• 针对特定行业（医美、法律、留学咨询）做垂直模板，客单价可以翻倍

国内的对应渠道很清晰：在闲鱼挂链接走小额订单，在猪八戒接企业客户，在淘宝服务做长期复购。把Telegram替换成微信群、QQ群、企业微信，方法完全通用。

为什么这件事值得做

大部分人面对杂乱的历史消息只会放弃，觉得「太乱了没法整理」。但只要把数据清洗、分块、增量更新这三件事跑通，沉睡三年的群聊就能变成随时可查的知识库。而愿意为「让信息可被搜索」付费的人，远比想象中多。这门生意的护城河不在技术，而在对格式细节的死磕——谁能把清洗做得干净彻底，谁就能把客单价做上去。