ChatWiki：把公众号做成 AI 客服与工作流入口的开源平台

公众号运营者缺的不是模型，是能把模型接进后台的那层胶水

通用大模型 API 已经很容易拿到，难的是把它接到公众号的实际动作上。用户在后台发一条私信、在文章下留一条评论、点一次自定义菜单，这些都是公众号平台的能力，但要把它们变成一次知识库检索加一次回复，中间需要处理消息类型分发、素材抓取、会话状态、人工接管这些琐事。ChatWiki 的定位就是这层胶水。README 把它写成面向微信生态的工作流自动化平台，目标是把每个公众号做成一个 AI agent。

目标用户是公众号运营方和技术支持方，不是终端提问的用户。仓库的前端是 Vue，后端是 Go 加 Python，这种组合通常意味着消息接入和调度用 Go 写，模型调用和文档处理用 Python 写。README 没有给出目录级的架构说明，所以这条推断只能算合理猜测，不能当成事实。

它和通用聊天机器人框架的区别在于默认假设。多数 RAG 框架的默认入口是一个 HTTP 接口或一个网页聊天框，ChatWiki 的默认入口是公众号后台事件。这个假设决定了它的节点类型、权限模型和部署形态。

消息进来之后发生了什么：触发器、节点、知识库三段

按 README 的描述，可以把它拆成三段。第一段是触发器，覆盖用户私信、评论、关注、取关、菜单点击这些场景。第二段是处理节点，包括回复私信、给粉丝打标签、生成草稿文章、发布文章。第三段是知识库，文档里提到支持 URL 读取、批量导入、API 接入、AI 分段、QA 分段、父子分段，还有知识图谱和混合向量检索。

存储层是 PostgreSQL16 加 pgvector 加 zhparser。pgvector 负责向量检索，zhparser 是中文分词扩展，这个组合说明检索不是纯向量，而是带中文分词的关键词与向量混合，README 里也写了 hybrid vector search。节点编排方面，文档提到会话工作流、插件工作流、双向 MCP、Agent 模式和用户交互。双向 MCP 的意思是既能接外部 MCP 服务，也能把工作流发布成 MCP 服务。

QA 知识库这块有个细节值得留意。文档说它会从上传的文档里自动抽取问答对，支持对未知问题自动聚类，还能从人工会话里总结常见问题。这意味着系统在后台持续跑聚类任务，不是纯静态索引。具体用什么算法、多久跑一次，材料里没有说明。

部署路径：docker compose 一条命令，但端口和默认口令要先处理

README 给出的社区版部署方式是 Docker。命令是这几步：先装 Docker，用 sudo curl -sSL https://get.docker.com/ | CHANNEL=stable sh；然后 git clone https://github.com/zhimaAi/chatwiki.git，进入 chatwiki/docker 目录；最后 docker compose up -d。访问地址是 IP 加端口，端口由环境变量 ${CHAT_SERVICE_PORT} 指定，默认 18080。

README 同时给出了默认用户名 admin 和默认密码 chatwiki.com@123。这两个值写在公开仓库里，任何部署后没有立即改口令的实例都是敞开的。文档没有说明首次登录是否强制改密，这一点需要部署者自己确认。

帮助文档还列了几条替代路径：安装助手、Docker 镜像站与离线安装、不用 Docker 部署、宝塔面板部署、1Panel 部署。模型提供方的配置和支持模型清单、本地模型部署、外部服务与推送通知的域名配置、大模型 API Key 的获取方式，都各自有一篇文档。也就是说，开箱可用只是第一步，真正决定能不能跑起来的是模型接入和外部域名这两块配置。

未认证公众号私信自动回复：这是它的差异点，也是最需要验证的一点

README 在产品定位部分用了 Industry First 这个说法，指的是未认证公众号也能自动回复私信，支持文本、语音、图片、小程序卡片、视频等消息类型。如果这个能力成立，它确实切中了一批没有认证资质但仍在运营的账号。

但这里有两个问题需要分开看。一是这个能力依赖公众号平台的开放接口，接口策略由平台决定，不由 ChatWiki 决定。二是 README 的更新日志里出现过小程序卡片相关的修复，2026 年 8 月 28 日那条写着修复了微信客服应用知识库中小程序卡片无法正确返回的问题，同一批更新里还有一条把默认输出说明里的小程序卡片指令去掉了。这两条放在一起看，说明卡片类消息的支持在不同渠道之间并不一致，且有过调整。

所以判断这个项目是否适合你，第一步不是读文档，而是拿自己的公众号类型去试私信链路。文档里没有列出哪些公众号类型、哪些认证状态被覆盖，这个清单只能靠实测补上。

它不适合什么场景，以及跟 Dify 这类平台的取向差异

最明显的不适合场景是：你不运营公众号，也不需要微信侧的事件入口。这种情况下 ChatWiki 的触发器、粉丝标签、草稿发布这些节点对你没有价值，你承担的只是更重的部署负担。它的技术栈是 Go 加 Python 加 PostgreSQL，还要装 pgvector 和 zhparser 两个扩展，比一个单进程的 Python 服务要重。

另一个不适合的场景是把许可证合规放在第一优先级。仓库的 License 字段是 NOASSERTION，也就是没有声明一个标准许可证。README 里反复出现社区版这个说法，暗示存在商业版，但社区版到底能用到什么程度、多账号权限管理这类功能是否属于社区版，材料里没有说明。商业项目在采用前必须自己确认授权范围，这不是技术问题，是采购问题。

如果要找替代方案，Dify 是常被拿来对比的一个。两者都是工作流加知识库的形态，但取向不同：Dify 的入口是通用应用和 API，模型与工具生态更宽，不绑定某个内容平台；ChatWiki 把入口押在公众号事件上，换来的是私信、评论、菜单这些动作可以直接当触发器用。选哪个取决于你的流量从哪里来。如果你的用户本来就在公众号里提问，从 Dify 出发要自己写一层公众号消息适配；如果你的用户在其他渠道，ChatWiki 的微信节点就是负担。

维护节奏与升级成本：一个月三次版本，升级前要看清改了什么

从发布记录看，v2.9.1 在 2026 年 8 月 14 日，v2.9.2 在 8 月 28 日，v2.9.3 在 9 月 4 日，大致是两到三周一个版本。这个节奏说明项目在活跃维护，同时也意味着自建部署方需要跟着走。

更新日志的内容偏向修补和增量：9 月 4 日那一版包括 QA 知识库回收站增加一键清空、外部服务页面按阿里云风格重做 PC 和 H5、敏感词上限提高到 20000、修复部分 embedding 场景下 Context 没有传递的问题。8 月 28 日那一版包括产品库支持添加和回复商品卡片、修复微信客服应用知识库中小程序卡片无法返回的问题。

这些条目的共同点是，不少是渠道侧消息类型的兼容修复。对自建方来说，升级不是可选项：公众号平台的接口和消息格式会变，上游不改，你的实例迟早会在某类消息上出问题。升级成本主要在数据库迁移和配置兼容上，材料里没有给出迁移说明，所以升级前应该先看 UpdateLog.md 对应版本条目，再决定是否跟。

权限方面，README 提到三级权限体系，管理员、编辑、查看者，配合 IP 白名单和永久登录日志。多账号场景下的数据隔离由这套模型承担。默认口令写在公开仓库这件事，和 IP 白名单、登录日志是配套的，前者是风险，后者是缓解手段，但缓解手段需要主动开启才有意义。

编辑结论

ChatWiki 适合已经在运营微信公众号、需要把私信和评论接进知识库与自动化流程的团队，尤其是愿意自己维护 Docker 与 PostgreSQL 的技术方。它不适合只想接一个通用问答 API、不打算碰公众号后台权限的团队，也不适合把许可证合规放在第一位的商业项目，因为仓库标注的是 NOASSERTION，社区版与商业版的具体边界必须先去官网和帮助文档确认。上手前建议先验证三件事：docker compose up -d 后 ${CHAT_SERVICE_PORT} 默认 18080 是否可达、默认账号 admin 与密码 chatwiki.com@123 是否在首次登录后被强制修改、以及你所用的公众号类型能否走通私信自动回复这条链路。

官方来源

1. Issues
2. Project website
3. README
4. Releases
5. zhimaAi/chatwiki on GitHub