很多 AI 助手只能完成“用户提问，模型回答”这一条简单链路。它们可以生成文字，却很难安全地调用私有服务、保存上下文、生成高质量图形，或者与企业协作平台形成真正可交互的工作流。
AiCat 的目标不是再做一个聊天窗口，而是打造一个以飞书为入口、以云端服务为大脑、以本地能力为工具箱的智能助手平台。目前它已经可以完成天气查询与分析、天气数据可视化、流程图和时序图生成、图形会话持续修改，并能够在 D2 与 PlantUML 之间自由选择渲染方式。
本文将从功能角度介绍 AiCat 的整体架构、设计优势，以及它未来可以扩展出的能力。
一、AiCat 当前能做什么
1. 在飞书中自然地使用 AI
用户不需要安装新的客户端，也不需要学习复杂的操作界面，只需直接与飞书机器人对话。例如：
- 查询北京明天的天气；
- 查看上海未来七天的天气趋势；
- 查询去年今天附近五天的历史天气；
- 生成一个用户登录流程图；
- 绘制包含 Controller、Service、Mapper 和数据库调用的方法级时序图；
- 在上一版图形上继续增加节点、修改布局或调整内容。
机器人收到消息后，会先显示“正在处理”的状态，再根据用户意图进入天气、图形或帮助等不同业务流程。需要用户选择时，则通过飞书交互卡片提供选项，而不是让用户记忆命令。
2. 理解自然语言中的日期和地点
天气查询看似简单，真正实现时却涉及大量语义问题。例如，“明天”“后天”“去年今天附近五天”都不是固定日期，必须结合当前日期和时区进行计算。
AiCat 使用“AI 语义识别 + 程序确定性校验”的方式处理这类问题：
- AI 负责理解用户想查询天气、历史数据还是未来趋势；
- 程序负责精确计算相对日期，避免模型把“明天”误判为“今天”；
- 地理编码服务将城市、区县或较详细的中文地址转换为经纬度；
- 用户首次确认的地点可以保存为默认地点，之后无需重复输入。
对于未来天气，系统调用预报数据源；对于过去日期，则自动切换到历史天气数据源。这让“去年同期天气如何”不再只是语言模型的猜测，而是基于真实数据的回答。
3. 让天气回答不仅有文字，还有图形
天气数据天然适合可视化。单纯返回一串最高温、最低温、降水量和风速，很难让用户快速形成直观判断。
AiCat 会根据查询范围生成不同形式的天气图片：
- 单日天气使用信息卡片，突出日期、天气状况、温度、降水和风力；
- 多日天气使用趋势图，同时展示最高温、最低温和降水变化；
- 历史天气也可以通过相同的视觉语言进行对比；
- 中文字体会随服务一起部署，避免出现方框、叉号或乱码。
文字适合给出结论，图形适合呈现趋势。二者结合，用户既能快速看懂，也能继续追问细节。
4. 生成真正符合语义的技术图形
AiCat 不只是把若干方框用箭头连接起来。它会先识别用户要求的图形类型，再生成对应语言的正确语法。
例如，用户要求“方法级登录时序图”时，系统会生成包含以下内容的真正时序图：
- 客户端或用户角色；
- Controller 方法调用；
- Service 业务方法；
- Mapper 或 Repository 数据访问；
- SQL 查询；
- 密码校验与 Token 生成；
- 成功和失败分支；
- 返回值及调用顺序。
对于 D2，系统会使用 sequence_diagram 语义；对于 PlantUML，则使用 participant、消息箭头和 alt/else/end 等时序图语法。渲染前后还会进行语法校验，失败时自动尝试修复，而不是直接把错误源码交给用户。
5. 支持 D2 和 PlantUML 两种图形引擎
新建图形时，飞书会弹出交互卡片，让用户选择渲染方式：
- D2：适合架构图、流程图、网络图和具有设计感的通用图形，默认采用 Orange Creamsicle 主题和 Sketch 手绘风格；
- PlantUML：适合时序图、类图、状态图等软件工程图形，语法成熟，表达严谨。
两种引擎由同一个图形接口统一调度。对云端业务来说，它们只是不同的 renderer 参数，因此未来增加新的图形引擎时，不需要重写整条业务链路。
6. 图形可以持续修改，而不是一次性生成
AiCat 会按照“用户 + 飞书会话”保存最近一次成功生成的图形及其元数据。用户可以继续说：
- 把数据库放到最下面；
- 增加 Redis 缓存；
- 把整体改成纵向布局；
- 改成标准风格，不要手绘；
- 给失败流程增加重试分支。
系统会在上一版完整图形的基础上修改，并保留未要求删除的内容。这种连续编辑体验，比每次重新描述整张图更接近一个真正的图形协作助手。
用户也可以发送“重置图形会话”等指令清除上下文，从一张全新的图开始。
二、整体架构
AiCat 采用“飞书入口 + 云端编排 + 本地执行 + 外部数据服务”的混合架构。
飞书层：统一的用户入口
飞书负责消息、图片、文件和交互卡片的呈现。AiCat 通过长连接接收事件，不要求用户访问额外页面。机器人还可以通过 Typing 状态告诉用户请求正在处理中，降低长耗时任务带来的等待焦虑。
云端层：理解、决策和业务编排
云端 FastAPI 服务是系统的核心大脑，主要负责：
- 识别消息属于天气、图形还是其他功能；
- 调用大模型理解自然语言并生成结构化结果；
- 校验日期、参数和图形语法；
- 保存用户地点、图形会话和消息处理状态；
- 调用外部数据接口；
- 将本地图形服务生成的图片上传并回复到飞书。
云端不直接执行大模型生成的系统命令。它只生成受约束的 D2 或 PlantUML 源码，再把源码交给专门的本地渲染接口处理。
本地层：执行需要本机资源的能力
本地能力服务运行在内网机器上，通过统一的 FastAPI 接口提供图形渲染、OCR 和翻译等能力。
D2 通过受限制的一次性 Docker 容器运行，渲染任务完成后清理临时文件；PlantUML 通过独立的 Jetty 服务生成 PNG 或 SVG。本地服务对云端使用 API Key 鉴权，并可通过 FRP 暴露受控入口，无需把 PlantUML 的 8080 端口直接开放到公网。
数据层：让助手拥有可控的记忆
系统使用数据库保存业务状态，包括：
- 用户与飞书身份的绑定关系；
- 用户默认天气地点；
- 最近一次图形源码、渲染器、主题、布局和版本号；
- 已处理的飞书事件，用于避免重复消费；
- 系统用户和管理数据。
这种记忆是结构化、可查询、可重置的，不依赖模型凭空记住所有历史对话。
三、一次图形生成请求是怎样完成的
以“画一个常规用户登录时的方法级时序图”为例：
- 飞书将用户消息发送给云端服务；
- 云端添加 Typing 状态，并判断这是一次新的图形请求；
- 机器人发送 Card 2.0 卡片，请用户选择 D2 或 PlantUML；
- 用户点击按钮后，云端收到卡片回调；
- DeepSeek 将自然语言转换为对应图形语言的完整源码；
- 云端检查源码是否使用了真正的时序图语法；
- 图形源码通过 HTTPS 和 API Key 发送到本地能力服务；
- 本地服务调用 D2 Docker 或 PlantUML Server 完成渲染；
- 如果渲染失败，云端把错误交给语法修复流程，并在限制次数内重新渲染；
- 成功后保存图形会话，将 PNG 预览上传到飞书；
- 用户可以继续基于这一版图形进行修改。
这条链路把模型擅长的“理解与生成”和程序擅长的“校验与执行”进行了明确分工。
四、这种架构的优点
1. 使用门槛低
飞书本身就是用户日常工作的入口。天气查询、图形生成和后续修改都通过自然语言完成，不需要另外学习专业绘图软件。
2. 云端和本地各司其职
云端适合处理消息接入、AI 调用、数据持久化和业务编排；本地适合运行 Docker、PlantUML、OCR 模型或访问局域网资源。混合部署避免了把所有能力强行放在同一台服务器上。
3. 私有能力无需直接暴露
云端只通过受控的 FRP 入口访问 localservice，PlantUML、Docker 和未来的内网服务仍然留在局域网内。统一的 API Key、超时和输入限制进一步缩小了暴露面。
4. AI 输出受到程序约束
模型负责把自然语言转成结构化意图或图形源码，但日期计算、参数范围、渲染器白名单、文件格式和网络访问都由程序控制。这比直接执行模型输出更稳定，也更安全。
5. 渲染引擎可以替换和扩展
D2 和 PlantUML 共用统一接口。业务层只关心图形源码、渲染器和输出格式，不关心底层容器如何运行。未来可以继续接入 Mermaid、Graphviz、C4-PlantUML 或企业内部绘图服务。
6. 功能可以按模块增长
天气、图形、OCR 和翻译都是独立能力模块。新增功能时可以按照“意图识别 → 业务服务 → 本地或外部执行器 → 飞书回复”的模式扩展，不需要推翻现有架构。
7. 会话记忆可控且可追踪
图形修改以版本号递增，最近一次成功源码会保存到数据库。相比完全依赖大模型上下文，这种方式更容易恢复、调试和重置，也为后续增加版本历史和多人协作打下基础。
五、未来可以扩展哪些功能
AiCat 的下一阶段重点不只是“接更多模型”，而是让现有架构承载更多真正有用的工作场景。
1. 图形能力继续升级
未来可以增加：
- 图形模板库：内置登录、支付、审批、订单、微服务、CI/CD 等常见模板；
- 更多图形类型：C4 架构图、ER 图、类图、状态机、部署图、组织架构图和思维导图；
- 智能引擎推荐：根据图形类型自动推荐 D2 或 PlantUML，同时保留人工选择；
- 局部修改能力：精确修改指定节点或分支，减少整图重绘造成的布局变化；
- 版本历史与对比：查看每次修改前后的源码和图片差异，并支持回滚；
- 导出能力：提供 PNG、SVG、PDF，以及可复制的 D2、PlantUML 源码；
- 团队模板：将审核通过的图形保存为团队标准模板；
- 从代码生成图形：读取项目结构、接口定义或调用链，自动生成架构图和时序图。
2. 天气助手从“查询”走向“主动服务”
在现有查询能力之上，可以继续增加：
- 每日天气卡片和上下班提醒；
- 暴雨、雷电、大风、高温等异常天气预警；
- 基于日历地点的出行天气提醒；
- 多城市对比和旅行天气规划；
- 历史同期气候对比；
- 空气质量、紫外线、花粉和穿衣指数；
- 用户自定义关注指标和提醒阈值。
这样，天气模块将从“问一次答一次”升级为具有个性化记忆的主动助手。
3. 接入企业知识和研发流程
AiCat 可以进一步连接企业内部知识与研发系统：
- 根据需求文档生成业务流程图；
- 根据接口文档生成系统时序图；
- 根据数据库结构生成 ER 图；
- 根据代码仓库生成模块依赖图；
- 总结 Git 提交、版本变更和发布风险；
- 把讨论结果自动整理为飞书文档；
- 从会议纪要提取任务并同步到项目管理系统。
这时，AiCat 将不再只是一个回答问题的机器人，而会成为连接文档、代码、数据和协作流程的工作入口。
4. 扩展更多本地 AI 能力
localservice 已经为本地能力提供了统一网关，未来可以继续接入：
- 本地大语言模型和向量检索；
- 私有文档问答；
- Whisper 语音转文字；
- 图片理解与表格识别；
- PDF 内容提取和总结；
- 视频字幕生成与内容检索；
- 局域网设备状态查询；
- 内部数据库的只读分析。
对于敏感数据，可以只在本地完成处理，云端仅负责转发任务和返回结果。
5. 从单助手演进为能力平台
随着功能增加，可以把每种能力描述为一个标准化工具，包含名称、输入参数、权限、执行位置和输出类型。AI 根据用户问题选择合适工具，系统则负责鉴权、执行、超时、审计和结果展示。
进一步还可以支持：
- 多步骤任务编排；
- 长任务进度卡片；
- 失败重试和断点恢复；
- 用户级和群组级权限；
- 调用次数、耗时和错误率统计；
- 不同 AI 模型的路由和降级；
- 插件式能力注册。
最终，天气、图形、OCR 和翻译都只是平台中的若干工具，新的能力可以像插件一样持续加入。
六、值得继续完善的方向
随着功能逐渐增多，系统还需要在工程层面持续增强：
- 将耗时任务放入任务队列，避免消息处理线程长时间阻塞；
- 为图形生成增加明确的进度状态，例如“正在生成源码”“正在渲染”“正在上传”；
- 为外部 API 和本地渲染器增加熔断、重试和降级策略；
- 完善结构化日志、调用链追踪和运行指标；
- 对用户上传内容和图形源码实施更严格的大小与语法限制；
- 对不同用户、群聊和功能设置独立权限；
- 对会话数据设置保留期限，并允许用户查看和删除个人数据。
这些改进不会改变 AiCat 的核心结构，但会让它更适合长期运行和多人使用。
结语
AiCat 的价值并不只在于接入了飞书、DeepSeek、D2 或 PlantUML，而在于它建立了一套可以持续生长的功能架构：飞书负责自然交互，云端负责理解和编排，本地服务负责安全执行，数据库负责可控记忆，外部服务负责提供真实数据。
在这套架构中，模型不是万能执行器，而是系统中的智能决策组件；图形、天气、OCR、翻译和未来的企业工具，也不是彼此割裂的功能，而是可以被统一调度的能力。
从一个能查天气、画图的飞书机器人出发，AiCat 完全可以继续成长为一个真正连接个人工作、企业知识和本地资源的智能助手平台。