自动回复是微信机器人上线率最高的功能，但"能回"和"回得准"是两件事。工程上有两种主流实现：关键词匹配和LLM理解。它们不是二选一，成熟方案往往是两者分层组合。这篇把两条路线讲透，并给出生产推荐架构。

参考资料WTAPI框架
接口字段见api文档weiti.apifox.cn 。

一、关键词匹配：确定性高，覆盖有限

逻辑是"用户说了什么→命中哪条规则→回复什么"。优点是确定性100%，命中规则一定回固定话术，不会胡说；缺点是用户表达稍有变化就匹配不上。

工程实现分三档：精确匹配（字典查表）、包含匹配（关键词包含判断）、正则匹配（处理带参数指令如"查订单123"）。

适用场景：菜单式客服、指令式机器人、FAQ高频问题。这些场景用户表达收敛，关键词匹配成本最低、最可控。

二、LLM理解：覆盖广，但有不确定性

逻辑是把用户消息和上下文丢给大模型生成回复。优点是用户随便怎么说都能理解，覆盖长尾问题；缺点是回复不确定、可能幻觉、有token成本、响应慢。WTAPI官方文档提到支持接入ChatGPT、文心一言、自研NLP等大模型。

适用场景：开放式咨询、售前问答、情绪安抚类对话。这些场景用户表达发散，关键词规则维护不过来。

三、分层组合：先规则后模型

生产环境推荐架构是分层路由，不要一上来就调LLM：

def generate_reply(instance_id, from_wxid, content):
    # 第一层：关键词规则（快、准、免费）
    reply = match_reply(content)
    if reply:
        return reply, "rule"

    # 第二层：FAQ知识库检索（语义相似匹配）
    faq = faq_search(content)
    if faq and faq.score > 0.85:
        return faq.text, "faq"

    # 第三层：LLM兜底（覆盖长尾）
    return llm_chat(instance_id, from_wxid, content), "llm"

三层各自承担不同流量：规则层拦截80%高频问题，FAQ层拦截15%相似问法，LLM只处理剩下5%的长尾。既保证确定性，又控制LLM成本。

四、两个工程细节

回复来源要打标，记录是rule/faq/llm哪种来源，便于后续分析。发现某类问题LLM命中率高但规则没覆盖，就把它沉淀成规则，逐步把LLM流量转移到规则层。

LLM回复要审核，输出过一遍敏感词和业务红线词，命中用兜底话术替换，不能让模型自由发挥到合规风险上。

五、选型建议

日咨询量小、问题固定，纯关键词匹配就够，别上LLM；咨询量大、问题发散，三层组合，LLM兜底；强合规行业（金融、医疗），规则为主，LLM只做意图识别不做直接回复。技术选型服务于业务，不是越新越好。