周三下午，一个销售经理在咖啡厅等客户。手机响了，客户催问订单进度。他打开Telegram，给机器人发了条消息："查一下EXP-0090"。三秒后回复："状态：待发货，预计本周出库。"他又打了一句："改成已确认"，搞定。全程没开电脑，没登CRM。
这是DB_consult_bot的设计场景。开发者想解决一个被忽视的日常痛点：大量轻量级的数据操作，却被困在重型系统里。查个字段、改个状态，要开浏览器、输账号、导航三层菜单、确认保存。这些动作在手机上尤其折磨。
Telegram成了突破口。它自带Bot API，消息即界面，用户零学习成本。但真正的工程挑战在后方：怎么让自然对话对接结构化数据库？
架构分了五层。最前是Telegram Bot API，负责收发消息。中间用Express.js+TypeScript搭后端，处理长轮询（long polling）。核心交给n8n——这个自动化平台在这里充当"翻译官"，把用户的口语化指令转成SQL查询。最后数据库返回结果，原路折返。开发者还配了一套React+Vite+Tailwind的本地管理界面，用Zustand管状态，方便调试和监控。
具体流程是这样：用户发消息→Express服务器接收→转发n8n webhook→AI Agent解析意图→执行查询或更新→返回自然语言回复。全程有"typing..."状态提示，避免用户以为卡死。
两个技术细节值得关注。一是上下文记忆：系统按聊天会话缓存最后查询的案卷编号，所以用户可以说"改状态为已开票"，而不用重复EXP-0090。二是防重复响应：开发阶段同时启动多个服务器实例时，用本地锁机制避免一条消息触发多次回复。
代码结构按模块拆分。src/modules下分app、chat、expedientes、server四大块，chat里再隔离telegram层。这种分层让后期替换平台（比如从Telegram迁到WhatsApp）只需改动接口层。
最终交互极简。用户："找案卷EXP-0090"。Bot："已找到，当前状态：处理中，负责人：张经理"。用户："状态改成已完成"。Bot："已更新。"对话即操作，操作即记录。
这个方案的聪明之处，在于用现有基础设施拼凑出"对话式数据库"体验，而不是从头造轮子。n8n负责流程编排，Telegram提供触达，Express做轻量网关。没有大模型训练成本，没有专有硬件，核心代码量控制在可维护范围。
适用场景也很明确：内部管理、案卷追踪、轻量级CRM替代——任何"查改操作比看报表更频繁"的上下文。它的边界同样清晰：复杂查询、批量操作、权限细分仍需专业系统。但在"移动场景+高频轻操作"这个切片里，它提供了一个足够好的答案。
热门跟贴