1. 项目概述当AI的记忆系统“失语”时如果你和我一样深度依赖AI助手来管理日常工作流和记忆那你肯定遇到过这种让人血压飙升的场景你明明记得上周才跟AI助手详细交代过某个项目的关键信息比如“老婆刚怀孕我们选定了广东省妇幼保健院天河院区”但今天你问它“我老婆怀孕要去哪个医院来着”它却一脸无辜地告诉你“抱歉我在记忆中没有找到相关信息”。那一刻你恨不得对着屏幕大喊“我明明跟你说过啊”这不是你的幻觉也不是AI在偷懒。问题的根源很可能出在它背后那个负责“记忆”搜索的底层引擎——SQLite的FTS5全文搜索引擎上。更具体地说是FTS5默认的unicode61分词器在处理中文时存在一个相当“愚蠢”的缺陷它会把连续的中文字符全部当成一个完整的“词”来处理。于是“老婆刚怀孕选定广东省妇幼保健院”在它的索引里就变成了一个长达十几个字的、不可分割的超级大词条。当你搜索“怀孕”这个关键词时FTS5会去索引里找完全匹配“怀孕”的词条自然一无所获。我最近在折腾OpenClaw这个AI Agent框架时就深陷这个泥潭。OpenClaw使用FTS5结合向量搜索RAG来构建记忆系统理论上很先进但中文搜索的命中率实测只有惨不忍睹的55%几乎是个“半残废”状态。经过一番刨根问底我找到了问题的症结并摸索出了一套零代码修改、纯配置和脚本优化的解决方案成功将中文记忆搜索的命中率从55%拉到了100%。这篇文章就是把我踩过的坑、试过的错和最终验证有效的“药方”完整记录下来分享给所有受困于AI中文记忆搜索的同行们。无论你是AI应用开发者、Prompt工程师还是单纯想让自己用的AI助手变得更“聪明”的极客这套方法都能帮你把那个“记不住事”的AI变成一个真正靠谱的“第二大脑”。2. 核心问题拆解FTS5的“中文失语症”要解决问题首先得把问题看清楚。OpenClaw的记忆搜索本质是一个混合搜索系统它既用向量模型计算语义相似度理解你“在说什么”也用FTS5进行关键词全文匹配精确匹配你“说了什么词”。理想情况下两者互补召回效果应该很好。但问题就出在FTS5这个“关键词匹配”环节对中文彻底失效了。2.1 FTS5分词器的工作原理与缺陷SQLite FTS5提供了几种分词器OpenClaw默认使用的是unicode61。这个分词器的设计初衷是处理Unicode文本它的基本规则是根据Unicode字符类别来切分。对于英文等使用空格分隔单词的语言它工作良好。但对于中文、日文等不使用空格分隔的东亚语言它的逻辑就很简单粗暴将所有连续的“字母类”字符包括汉字视为一个单一的token。这意味着什么我们来看一个实际的例子。假设你的记忆文件里有一句话“元宝老婆刚怀孕”。在unicode61分词器看来这7个汉字是一个连续的字母序列因此它会被索引为一个完整的token元宝老婆刚怀孕。-- 假设这是FTS5虚拟表内部的词汇表 -- 原文“元宝老婆刚怀孕”在索引中只对应一个词条 token: 元宝老婆刚怀孕, doc_count: 1当你搜索“怀孕”时FTS5执行的是精确的token匹配。它会在词汇表里查找token等于“怀孕”的记录。显然它找不到因为词汇表里只有元宝老婆刚怀孕没有独立的怀孕。所以搜索结果是零。注意这里有一个常见的误解认为FTS5是“模糊匹配”或“包含匹配”。实际上FTS5的MATCH操作默认是token级的精确匹配。虽然它支持前缀匹配怀孕*和短语匹配但对于被错误合并的token这些高级操作也无能为力。2.2 问题复现与数据证据光说理论不够直观我写了一个简单的诊断脚本来验证。脚本会直接查询OpenClaw记忆数据库的FTS5词汇表看看它到底把我们的中文记成了什么样子。# 使用sqlite3命令行工具连接记忆数据库 sqlite3 ~/.openclaw/workspace/memory.db # 查询FTS5辅助表查看实际存储的token SELECT term, doc FROM chunks_fts WHERE term MATCH 怀孕;查询结果令人沮丧果然是空的。进一步查看词汇表中一些长中文句子的存储情况记忆原文FTS5 实际存储的 Token问题分析元宝老婆刚怀孕元宝老婆刚怀孕7字合一无法搜索“老婆”、“怀孕”等子词选定广东省妇幼保健院天河院区选定广东省妇幼保健院天河院区13字合一无法搜索“广东”、“妇幼”、“医院”也叫刘二虎也叫刘二虎5字合一无法搜索“刘二虎”这个人名这张表清晰地揭示了问题所有连续的中文字符都被“粘”在了一起导致基于子词的搜索完全失效。这解释了为什么你的AI对你说过的话“充耳不闻”——它的关键词索引根本就是错的。2.3 混合搜索中的权重困境在OpenClaw的默认配置中向量搜索和全文搜索的权重可能是均衡的例如各占0.5。当FTS5这一半完全失效时整个搜索系统的压力就全压在了向量模型上。这对于使用本地小模型如qwen3-embedding:0.6b的用户来说尤为致命。小模型的语义理解能力有限对于“医院”和“妇幼保健院”这种高度相关的词它能给出不错的相似度分数但对于“怀孕”和“老婆刚怀孕选定广东省妇幼保健院”这种长短文本的匹配小模型很容易给出偏低的分数。如果这个分数低于搜索配置中的最小阈值minScore即使向量搜索认为它相关也会被过滤掉最终导致“零召回”。所以我们面临的是一个双重困境FTS5关键词匹配瘫痪向量搜索独木难支且受限于小模型能力。解决方案必须双管齐下一是修复或绕过FTS5的中文索引问题二是调整搜索策略以适应小模型的特点。3. 解决方案总览三层优化策略我采取的方案可以概括为“三层优化”分别从写入时、搜索时和维护时三个环节入手形成一个完整的优化闭环。这套方案的核心原则是零侵入性不修改OpenClaw的一行源代码完全通过配置、Prompt工程和外部脚本实现。写入时优化 (源头治理) ↓ 改造 memoryFlush 的 Prompt让AI写入格式规范的记忆。 核心自动添加标签(Tags)、中文关键词空格分隔、控制文件体积。 ↓ 搜索时优化 (策略调整) ↓ 调整OpenClaw的搜索配置参数。 核心提高向量权重、减小文本块大小、降低相关度阈值、启用去重。 ↓ 维护时优化 (定期保养) ↓ 通过Cron任务定期执行脚本。 核心压缩历史大文件、为旧文件补标签、清理存档、重建索引。这个策略的逻辑在于既然我们无法改变FTS5分词器的底层行为那就改变喂给它的“食物”。我们在写入阶段就预先将中文内容处理成FTS5能正确消化的格式通过空格分词和标签。同时在搜索阶段我们降低对FTS5的依赖更相信向量模型并通过参数调优让小模型发挥更好。最后通过定期维护来保持整个记忆库的整洁和高效。4. 实操步骤一诊断现有记忆库在开始优化之前强烈建议先对现有的记忆库进行一次全面诊断。这能帮你了解问题的严重程度并量化优化后的效果。我已经将诊断工具打包成了一个脚本。4.1 运行诊断脚本首先克隆本项目的仓库并运行诊断脚本。git clone https://github.com/abczsl520/openclaw-memory-cn.git cd openclaw-memory-cn ./scripts/diagnose.sh这个脚本会自动定位你的OpenClaw工作空间并检查以下几个关键方面FTS5中文分词Bug验证随机抽样记忆内容模拟搜索给出预估的中文搜索失败率。大文件扫描列出体积过大默认8KB的记忆文件。过大的文件在分割成文本块chunk时可能包含过多无关信息稀释关键内容。标签缺失检查检查projects/目录下的项目记忆文件是否缺少!-- tags: ... --格式的标签。标签是后续优化中提升搜索精度的关键。索引健康度检查SQLite索引是否需要重建。脚本运行后你会看到一个清晰的报告类似下面这样 OpenClaw 中文记忆库诊断报告 [!] 发现FTS5中文分词问题 抽样测试显示约 58% 的中文关键词搜索可能因分词问题失败。 例如记忆“讨论云服务器部署方案”无法通过“云服务器”检索到。 [!] 发现大体积记忆文件8KB /home/user/workspace/memory/projects/项目A总结.md (12.4KB) /home/user/workspace/memory/lessons/一次失败的调试.md (9.8KB) 建议大文件可能导致chunk信息不聚焦影响搜索精度。 [✓] 标签覆盖检查 projects/ 目录下 85% 的文件已包含标签15% 缺失。 建议为缺失文件补充标签以提升搜索命中率。 [ ] 索引状态正常。4.2 解读诊断结果高失败率证实了FTS5问题的普遍性这是我们要解决的核心。大文件这些是“优化潜力股”。压缩它们不仅能节省空间更能让后续的向量嵌入更加精准。想象一下一个500字的文本块和一个5000字的文本块都去匹配“医院”这个词前者显然更相关。缺失标签标签是我们为FTS5提供的“精确制导”关键词。缺失标签意味着这部分记忆只能依赖效果不佳的全文搜索和语义搜索召回率大打折扣。拿到这份诊断报告你就对自己的记忆库健康状况有了底。接下来我们就可以有针对性地进行“治疗”了。5. 实操步骤二优化记忆写入格式治本之策优化搜索的前提是优化被搜索的内容。最有效的方法是从源头——即AI助手通过memoryFlush动作写入记忆的环节——进行干预。我们需要修改OpenClaw中memoryFlush指令的Prompt让AI在写日记或总结时就按照我们想要的格式来。5.1 理解memoryFlush的默认行为默认情况下OpenClaw的memoryFlush可能只是一个简单的指令如“将以上对话总结并存入记忆”。AI会自由发挥生成一段连贯但未结构化的文本。这样的文本直接丢给FTS5就会产生我们之前看到的分词问题。5.2 应用优化后的Prompt配置本项目提供了一个优化版的Prompt配置文件。这个Prompt做了三件关键事强制添加标签Tags要求AI在记忆内容的第一行以HTML注释的形式添加!-- tags: 关键词1, 关键词2 --。这些标签会作为独立的、高权重的文本块被索引完美绕过中文分词问题。因为标签中的逗号或空格能被FTS5正确识别。关键词空格分隔在记忆正文中提示AI在重要的中文名词、短语之间有意识地加入空格。例如“选定广东省妇幼保健院”写成“选定 广东省 妇幼保健院”。这样FTS5就能将“广东”、“妇幼保健院”等作为独立token索引。控制输出长度要求AI将记忆内容控制在5KB以内。过长的记忆在后续处理时会被强制分割可能破坏逻辑完整性。由AI主动精简效果更好。应用这个配置非常简单# 进入项目目录 cd openclaw-memory-cn # 使用openclaw的config patch命令应用配置 openclaw config patch config/memory-flush-prompt.json这个命令会更新你OpenClaw的配置。之后每当AI执行memoryFlush它都会遵循新的、更结构化的Prompt来书写记忆。实操心得修改Prompt后最好主动触发一次memoryFlush来测试效果。你可以对AI说“请将我们刚才关于XX项目的讨论总结一下存入记忆。”然后检查生成的记忆文件看是否包含了正确的标签格式和空格分隔。这个过程可能需要一两次微调你可以根据AI的输出风格稍微修改Prompt中的示例来达到最佳效果。5.3 为历史文件批量补标签新的Prompt只对未来的记忆生效。对于历史记忆库中那些缺少标签的projects/文件我们需要进行“考古”和“贴标签”。手动操作太累我写了一个Python脚本来自动化处理。# 脚本会扫描指定目录下的所有.md文件 # 尝试从文件名和内容中提取关键词并添加tags行 python3 scripts/add-tags.py ~/path/to/your/workspace/memory/projects/ # 如果你想更谨慎可以先使用--dry-run预览将要做的更改 python3 scripts/add-tags.py ~/path/to/your/workspace/memory/projects/ --dry-run这个脚本的工作原理和注意事项提取关键词脚本会分析文件名例如搭建个人邮件服务器.md和文件的前几行内容提取可能的关键词如“邮件服务器”、“Postfix”、“Dovecot”。智能去重它会过滤掉“的”、“了”、“和”等无意义的停用词。安全写入默认情况下它只对完全没有!-- tags:开头的文件进行修改。如果文件已有标签脚本会跳过避免覆盖。备份建议虽然脚本很安全但在对大量历史文件操作前建议先备份memory/projects/目录。运行完脚本后打开几个项目文件看看应该会在文件顶部看到新添加的标签行。这些标签将成为后续搜索的“快捷入口”。6. 实操步骤三调整搜索与分块参数效果强化源头数据格式优化了接下来要调整“搜索引擎”本身让它更好地理解这些数据。我们需要调整OpenClaw中关于记忆搜索的一系列配置参数。核心思路是鉴于FTS5中文搜索不可靠让向量搜索承担主要责任同时通过优化分块Chunking策略帮助能力相对较弱的本地小模型更好地工作。6.1 关键参数解析与配置本项目提供了一个调优后的搜索配置文件config/memory-search.json。让我们深入看看其中几个关键参数为什么这么设{ memory: { search: { vectorWeight: 0.75, textWeight: 0.25, minScore: 0.15, halfLifeDays: 90, mmrLambda: 0.7 }, chunking: { tokens: 250, overlap: 60 } } }vectorWeight: 0.75/textWeight: 0.25为什么这是最核心的调整。因为FTS5对应textWeight的中文分词是坏的我们必须大幅降低它的权重让向量搜索对应vectorWeight主导。0.75:0.25这个比例意味着搜索结果的相关度排序75%由向量相似度决定25%由关键词匹配决定。这样即使关键词匹配不上只要语义相关依然能被找出来。chunking.tokens: 250/chunking.overlap: 60为什么默认的chunk大小比如512或1024 tokens对于qwen3-embedding:0.6b这类小模型来说太大了。一个大chunk包含的信息太多嵌入embedding后的向量会变成一个所有信息的“平均”表示导致搜索“医院”时一个既讨论了医院又讨论了幼儿园、超市的chunk其向量可能无法突出“医院”的特征。将chunk缩小到250个tokens约125个汉字让每个chunk的内容更聚焦。60个tokens的重叠则保证了上下文不会因分割而断裂。计算示例一段1000字的文本按512分块可能得到2个块。按250分块重叠60则可能得到类似[0-250], [190-440], [380-630], [570-820], [760-1000]5个块。搜索“医院”时如果医院信息只出现在第300-400字的位置它在第二个块(190-440)中就是核心信息该块的向量对“医院”的表征就会非常强更容易被检索到。minScore: 0.15为什么小模型生成的向量相似度分数普遍偏低。两个高度相关的文本大模型可能打出0.8分小模型可能只有0.4分。如果保持默认的较高阈值如0.5会过滤掉大量实际上相关的结果。适当降低阈值可以“网开一面”提高召回率。0.15是一个经验值你可以根据测试结果微调。mmrLambda: 0.7为什么MMR最大边际相关性算法用于在返回结果中平衡相关性与多样性。lambda值接近1偏向多样性接近0偏向相关性。设为0.7是在保证结果相关的前提下适度避免返回内容重复度过高的chunk。例如同一件事在不同日志中被多次提及MMR可以帮助只返回最具代表性的一条。halfLifeDays: 90为什么时间衰减因子。这个参数决定了旧记忆的分数会随时间推移而降低。设为90天意味着一个90天前的记忆其相关性分数会打对折。对于项目记忆这类需要长期参考的内容设置较长的半衰期是合理的确保它们不会过快被遗忘。6.2 应用搜索配置应用配置同样简单openclaw config patch config/memory-search.json应用后OpenClaw的记忆搜索行为就会立即按照新的参数执行。你可以马上进行一次搜索测试感受变化。注意事项这些参数是针对qwen3-embedding:0.6b这类百兆级别的本地小模型优化的。如果你使用的是更强的本地模型如nomic-embed-text或云端API如text-embedding-3-large可能需要调整。特别是vectorWeight可以调低如0.6minScore可以调高如0.3因为模型能力更强FTS5的辅助作用和分数可靠性都更高。7. 实操步骤四压缩、清理与重建索引系统维护经过前两步新记忆的写入和搜索都已优化。但对于历史积累的、体积庞大的旧记忆文件它们仍然占据着空间并以低效的大chunk形式影响着搜索精度。此外为旧文件添加了标签后也需要重建索引才能生效。这就需要第三步系统维护。7.1 压缩膨胀的日志文件每日日志很容易写得过长特别是AI在详细记录对话时。我编写了一个compress-logs.py脚本它能智能地压缩文本文件。# 压缩memory目录下所有大于5KB的.md文件 python3 scripts/compress-logs.py ~/path/to/your/workspace/memory/ --max-kb 5 # 你也可以指定其他目录和大小阈值 python3 scripts/compress-logs.py ~/workspace/memory/lessons/ --max-kb 8脚本工作原理使用tiktoken库或类似方法精确计算token数。对于超限的文件它调用本地LLM通过Ollama默认使用qwen2.5:7b进行摘要压缩。Prompt类似于“请将以下文本压缩到原来长度的60%左右保留所有关键事实、决定和联系人信息。”将压缩后的文本写回原文件并在文件开头添加!-- 已压缩 --的标记。踩坑记录早期版本我尝试用简单的规则删除“的、了、呢”等词效果很差破坏了技术术语和逻辑。改用LLM进行语义压缩后效果提升巨大既能缩减体积又能保留核心信息。这是维护环节性价比最高的一步。7.2 执行全面清理cleanup.sh脚本是一个清理工具箱它集成了几个常用操作# 授予执行权限并运行 chmod x scripts/cleanup.sh ./scripts/cleanup.sh ~/path/to/your/workspace/memory/它会删除临时文件清理.tmp、.bak等垃圾文件。归档旧日志将超过30天的每日日志移动到archive/文件夹。你可以通过修改脚本中的DAYS变量来调整保留策略。可选清理archive如果你在cron-job.json中设置了更激进的策略它还可以定期清空archive/文件夹实现滚动备份。7.3 重建记忆索引这是让所有优化生效的最后一步。无论是添加了新标签还是压缩/删除了文件都需要重建FTS5和向量的索引。openclaw memory index --force--force参数会强制重新生成所有索引即使文件没有变化。在首次优化或进行大规模改动后建议使用此参数。7.4 设置自动化维护任务Cron手动运行维护脚本太麻烦最好能自动化。OpenClaw支持Cron任务。你可以将维护任务打包成一个定期执行的命令。查看本项目templates/cron-job.json文件的内容。在OpenClaw的Web UI或配置文件中添加一个新的Cron任务。任务内容就是顺序执行压缩、清理和重建索引的命令例如设置为每周日凌晨2点执行。// 示例在OpenClaw的 config.json 中添加cron任务 { cron: [ { schedule: 0 2 * * 0, command: cd /path/to/openclaw-memory-cn python3 scripts/compress-logs.py ~/workspace/memory/ --max-kb 5 ./scripts/cleanup.sh ~/workspace/memory/ openclaw memory index --force, description: Weekly memory maintenance } ] }设置好后你就可以忘掉维护这件事系统会在后台自动保持记忆库的健康状态。8. 效果验证与性能对比理论说再多不如看实际效果。我在自己的OpenClaw环境2026.3.2版本qwen3-embedding:0.6b嵌入模型约80个记忆文件上进行了严格的A/B测试。测试方法构建测试集从记忆库中提取20个真实的中文查询涵盖人名、项目名、技术概念、地点等如“刘二虎”、“邮件服务器配置”、“广东省妇幼保健院”。基准测试优化前使用OpenClaw默认配置进行搜索记录Top-1和Top-5的命中情况、检索分数并检查是否有零召回查询。优化实施应用本项目的全部优化配置和脚本。对比测试优化后在同一测试集上再次搜索记录相同指标。测试结果对比表评估指标优化前 (默认配置)优化后 (本方案)提升幅度中文搜索命中率 (Top-1)55% (11/20)100% (20/20)82%零召回查询数量10个0个彻底解决平均检索最高分0.670.8019%记忆库总体积~780 KB~460 KB-41%索引重建时间~12秒~8秒-33%结果分析命中率100%这不仅是数字上的提升更是体验上的质变。所有查询都能找到相关记忆AI不再“失忆”。这主要归功于标签系统和向量搜索权重提升。标签提供了精确匹配的通道而强化向量搜索则弥补了FTS5的缺陷。零召回归零之前有半数查询完全搜不到任何结果现在全部消失。这验证了minScore降低和chunking策略优化的有效性让小模型也能发挥出足够的召回能力。相关性分数提升平均最高分从0.67提升到0.80。这说明返回的结果不仅“有”而且“更相关”。这得益于更小的chunk使得向量表示更聚焦以及MMR去重让排名靠前的结果质量更高。体积显著减小文件压缩策略效果立竿见影整体体积下降了41%。更小的文件意味着更快的读取速度和更精准的chunk分割。索引更快体积减小和内容优化也带来了索引重建时间的减少。这个对比清晰地表明整套优化方案不是“安慰剂”而是切实解决了中文搜索的核心痛点并在多个维度上提升了系统性能。9. 常见问题与排查技巧在实施和后续使用过程中你可能会遇到一些问题。这里记录了一些常见情况和解决方法。9.1 搜索效果提升不明显检查配置是否生效运行openclaw config get memory确认vectorWeight、chunking.tokens等参数已更新为本方案建议的值。确认标签已添加并索引找一个你确信加了标签的项目文件用文本编辑器打开确认第一行有!-- tags: xxx --。然后在OpenClaw中搜索标签里的某个关键词最好是英文或加了空格的中文看是否能命中该文件。如果不行尝试运行openclaw memory index --force重建索引。检查嵌入模型确保你使用的嵌入模型与本方案适配。本方案主要针对qwen3-embedding:0.6b这类小模型优化。如果你用的是其他模型可能需要调整minScore和vectorWeight。可以尝试将minScore逐步调低如0.1测试。记忆文件质量过于冗长、杂乱、包含大量无关信息的记忆文件即使优化后效果也有限。坚持使用优化后的memoryFlushprompt并定期运行压缩脚本。9.2 运行脚本时出现权限或路径错误“命令未找到openclaw”确保openclaw命令行工具已正确安装且在系统PATH中。你可以使用绝对路径例如/usr/local/bin/openclaw config patch config.json。Python脚本依赖错误确保已安装必要的Python库如tiktoken。可以运行pip install tiktoken来安装。如果使用Ollama接口压缩日志还需要requests库。“目录不存在”诊断和脚本中的默认路径是~/workspace/memory/。请根据你实际的OpenClaw工作空间路径进行修改。你可以通过openclaw config get workspace查看工作空间路径。9.3 应用配置后AI行为异常memoryFlush格式不对检查应用的memory-flush-prompt.json文件内容是否正确。最可能的原因是Prompt的格式不对导致AI无法理解。可以尝试在OpenClaw的Web UI中手动触发一次memoryFlush观察输出的记忆文件格式。如果不符合预期可能需要微调Prompt中的示例部分。Cron任务未执行检查OpenClaw的日志看是否有Cron任务执行失败的记录。确保Cron命令中的路径都是绝对路径并且OpenClaw服务在持续运行。9.4 如何针对其他语言如日文、韩文优化本方案的核心问题是FTS5unicode61分词器对非空格分隔语言失效。日文和韩文同样受此影响甚至更复杂日文混合汉字、假名韩文有空格但规则不同。测试验证你可以用日文/韩文内容创建测试记忆然后搜索其中的子词验证是否也存在召回失败的问题。方法同上。解决方案本方案的标签Tags优化和提高向量权重策略是语言无关的同样有效。对于正文分词可以在对应语言的memoryFlushprompt中要求AI在单词之间插入空格日文或遵循韩文的空格规范。更高级的方案是集成外部分词库如MeCab for Japanese, KoNLPy for Korean但这需要修改OpenClaw代码超出了本“零代码”方案的范围。9.5 方案适用于其他AI框架或笔记软件吗核心原理通用FTS5的中文分词问题是SQLite层面的任何使用SQLite FTS5且未做中文优化的软件如某些笔记软件的搜索功能都可能遇到。方案部分迁移标签法在任何支持文件头元数据如YAML front matter或自定义属性的系统中为文件添加关键词标签都是提升搜索精度的通用技巧。写入时分词在内容创作时主动加入空格是应对低级分词器的有效Workaround。小Chunk策略对于任何基于向量检索的系统RAG当使用较小能力的嵌入模型时缩小chunk大小都能提升精度。配置部分不通用本文中具体的OpenClaw配置参数vectorWeight,minScore等是框架特定的无法直接套用。但调整权重、分块、阈值的思想是相通的。这套组合拳打下来我的OpenClaw记忆系统终于从“中文废物”变成了“可靠伙伴”。整个过程没有动一行核心代码全部通过配置、Prompt和外部脚本实现充分体现了在现有系统上进行“外科手术式”优化的思路。最大的体会是面对AI应用中的问题不要轻易归咎于模型能力很多时候是基础设施如搜索、分词的坑。找准痛点用工程化的方法去填补往往能收获奇效。现在我终于可以放心地对我的AI助手说“嘿还记得我们上次讨论的那个问题吗”并且确信它能给我一个满意的回答。