新款 MacBook Pro 的新闻弹窗跳出来时，我正卡在本地知识库的模糊匹配算法上。M3芯片？跑分再高，也解不了我手头这个“人肉客服”的毒。去年裁掉整个团队后，我给自己挖了个新坑：用Python脚本彻底替代那个需要我24小时待命、回复客户重复问题的微信。
不是大模型，没那个预算，也没那个算力。我的方案土得掉渣：一个本地SQLite数据库，里面存了几百条标准问答对，每条记录关联一堆关键词和权重。核心逻辑是关键词的“加权命中”和“意图排除”。比如客户问“课程怎么退款”，脚本会拆出“课程”、“退款”两个词，分别去知识库里匹配。光匹配上还不行，“退款”这个词权重极高，但必须排除掉“如何申请退款政策”这种只是询问流程而非真正要退款的意图。我写了个简单的排除词列表，命中主关键词的同时如果也命中了排除列表里的词，就降权处理。
这玩意儿最恶心的部分是处理同义词和错别字。我建了个同义词映射表，把“怎么”、“如何”、“咋”都映射到同一个标识符。错别字更头疼，用的是Python的difflib库做序列匹配，设定一个相似度阈值，超过80%就认为是同一个词。但阈值调高了漏判，调低了误判，调试那几天我感觉自己像个在给机器做语文听写的班主任。
今天下午的突破是把“上下文记忆”加进去了。很简单，就是给每个会话ID在内存里存上最近三条交互记录。如果用户上一条问的是“Python进阶课大纲”，紧接着发来一个“多少钱”，脚本会优先去匹配“Python进阶课价格”这条知识，而不是泛泛的“课程价格”。就这点逻辑，花了我整整四个小时调试边界条件，比如用户突然换话题了该怎么清空上下文。
搞完测试，跑起来倒是挺快，M1芯片都绰绰有余。我盯着命令行里滚动的匹配日志，突然觉得，所谓超级个体，不是一个人干十个人的活，而是把十个人的工作流抽象成十个“逻辑节点”。一个节点是关键词匹配，一个节点是上下文管理，一个节点是应答模板渲染。每个节点都是一段可以独立优化、替换的代码。员工会累，会抱怨，会离职，但逻辑节点不会，它只会在你改进算法后，沉默地跑得更快。
M3能让编译速度提升百分之多少，我不关心。我只关心我的脚本能不能再减少百分之一的人工干预。肉身有限，代码不朽。这才是我的跑分。
