AccessAI 重磅更新:支持 DeepSeek V4 及数据库对象分析,气泡对话更智能

作者:本站 来源:本站

2026-05-05 15:38 1299阅读

AccessAI 重磅更新:支持 DeepSeek V4 及数据库对象分析,气泡对话更智能

各位开发者朋友们好!

版权声明

在正式介绍之前,先做一个统一说明:

EdonSoft Development Framework 框架,以及本公众号发布的全部相关文章、说明内容、经验分享与后续更新,均归属于易登软件。

也请大家在了解、下载、交流和传播时注意识别官方来源,避免与非官方内容混淆,以免获取到不准确的信息。


测试版发布通知

上周,EdonSoft Development Framework 框架已经发布了测试版本。目前我已经根据测试反馈修正了一些问题,后续也会持续更新和完善。

欢迎大家下载试用,并把使用过程中遇到的问题、改进建议反馈给我。如果想加入交流群,可以在文末扫码添加。

下载地址:
http://www.edonsoft.com/access-framework


前面我介绍过 accessAI 这个开源项目:它可以让 Microsoft Access 通过 VBA 调用 AI 大模型,并且支持流式输出、Markdown 渲染和一键生成问答窗体。

最近这个项目又做了一轮更新。

如果说最早的版本解决的是“Access 能否接入 AI”的问题,那么这次更新更接近另一个问题:Access 接入 AI 之后,能否真正变成一个可长期使用的业务工作台。

这次更新不是简单把接口地址换一下,而是围绕实际使用场景补上了几个关键能力:多模型切换、DeepSeek V4 Flash / Pro 支持、System Prompt 配置、历史会话管理、数据库对象分析,以及更接近现代聊天工具的对话样式和 WebBrowser HTML 气泡对话模式。

项目地址仍然是:

https://github.com/miaowei2/accessAI



01

这次更新解决了什么问题


Access 接入 AI 的第一步,通常只是做一个“提问框 + 回答框”。

这个阶段能证明技术可行,但还不够贴近真实业务。因为在实际项目里,用户往往会遇到这些问题:

  1. 不同任务适合不同模型,不能只写死一个模型。
  2. 同一次业务沟通需要保留上下文,不能每次都重新开始。
  3. 用户关闭数据库后,希望还能查到之前的 AI 对话。
  4. AI 不应该只回答自由文本问题,还应该能分析当前 Access 数据库里的表和查询。
  5. 如果企业已经有自己的 OpenAI 兼容网关,也希望可以直接接入。

这次 accessAI 的更新,基本就是围绕这些问题展开的。

更新方向

说明

多模型支持

支持 DeepSeek V4 Flash、DeepSeek V4 Pro、通义千问、文心一言、Kimi

自定义端点

可以配置任意 OpenAI 兼容 API 的 URL、Key 和模型名

System Prompt

在窗体中配置系统提示词,统一控制 AI 的角色和回答规则

对话历史

自动保存到

tblChatHistory

,关闭数据库后仍可查看

历史管理窗体

通过

frmChatHistory

浏览、加载、删除历史会话

数据库对象分析

选择表或查询后,自动读取字段结构、记录数和前 30 行样例数据交给 AI 分析

对话样式升级

用户消息和 AI 消息分区显示,支持实时输出时的光标效果

双对话模式

保留 Access 富文本模拟气泡模式,并新增 WebBrowser HTML 真气泡模式

这些能力叠加之后,accessAI 就不只是一个演示性质的 AI 问答窗体,而是更像一个可以嵌入业务系统的 AI 辅助模块。

尤其是这次对对话界面的处理,已经不再是简单把 AI 返回文本塞进一个文本框,而是开始区分“用户消息”“AI 回复”“流式生成中内容”“历史会话内容”等不同状态。对 Access 项目来说,这一步很重要,因为用户看到的不是底层 API,而是窗体里的交互体验。



02

多模型切换:同步支持 DeepSeek V4 的 Flash 和 Pro


这次最直接的变化,是项目跟进 DeepSeek V4 更新,模型下拉框增加了两个更明确的 V4 模型档位:

  1. DeepSeek Flash
  2. DeepSeek Pro

模块中的配置也同步更新:

' DeepSeek
Private Const DS_KEY   As String = "你的-DeepSeek-Key"
Private Const DS_URL   As String = "https://api.deepseek.com/chat/completions"
Private Const DS_FLASH_MODEL As String = "deepseek-v4-flash"
Private Const DS_PRO_MODEL   As String = "deepseek-v4-pro"


这样做的好处很明显。

模型选择

更适合的场景

DeepSeek Flash(V4)

日常问答、简单文本整理、轻量辅助

DeepSeek Pro(V4)

稍复杂的分析、代码解释、业务逻辑推理

通义千问

国内企业环境、阿里云生态

文心一言

百度千帆生态或已有百度云配置的企业

Kimi

长文本阅读、资料整理类任务

自定义

企业内网模型网关、第三方 OpenAI 兼容服务

从代码实现上看,模型配置被统一放进 GetProviderConfig 过程里处理。窗体上用户选择模型,模块再根据选择结果返回对应的 URL、Key 和 Model。

Private Sub GetProviderConfig(ByVal sProvider As String, _
                              ByRef sUrl As String, _
                              ByRef sKey As String, _
                              ByRef sModel As String)
    Select Case sProvider
        Case "DeepSeek Flash"
            sUrl = DS_URL: sKey = DS_KEY: sModel = DS_FLASH_MODEL
        Case "DeepSeek Pro", "DeepSeek"
            sUrl = DS_URL: sKey = DS_KEY: sModel = DS_PRO_MODEL
        Case "通义千问"
            sUrl = QW_URL: sKey = QW_KEY: sModel = QW_MODEL
        Case "文心一言"
            sUrl = WX_URL: sKey = WX_KEY: sModel = WX_MODEL
        Case "Kimi"
            sUrl = KM_URL: sKey = KM_KEY: sModel = KM_MODEL
        Case "自定义"
            ' 从窗体输入框读取自定义 API 配置
        Case Else
            sUrl = DS_URL: sKey = DS_KEY: sModel = DS_PRO_MODEL
    End Select
End Sub

这里还有一个兼容性细节:旧的 DeepSeek 仍然会映射到 DeepSeek Pro。这对已经导入过旧版窗体或保存过旧配置的用户比较友好,不需要因为名称变化就全部重建。



03

System Prompt:让 AI 回答更像“系统的一部分”


很多人第一次接入 AI,只关注用户问题本身。但在企业系统里,更重要的是让 AI 按照固定角色回答。

例如:

  1. 让 AI 扮演采购数据分析助手。
  2. 让 AI 只根据当前表格内容回答,不要编造数据。
  3. 让 AI 输出 Access SQL,而不是其他数据库语法。
  4. 让 AI 回答时使用简体中文,并按业务人员能理解的方式说明。

这类要求不适合每次都让用户手工输入,更适合放到 System Prompt 中统一控制。

新版 accessAI 在主窗体上增加了系统提示词输入框,并在构造请求体时把它作为第一条 system 消息加入 messages 集合。

If Len(Trim$(sSystemPrompt)) > 0 Then
    Set oMsg = CreateObject("Scripting.Dictionary")
    oMsg.Add "role", "system"
    oMsg.Add "content", Trim$(sSystemPrompt)
    colMessages.Add oMsg
End If

这个设计很实用。因为 Access 系统经常不是给开发人员用,而是给财务、仓库、采购、生产、客服等业务部门使用。System Prompt 可以把开发者对业务规则的理解预先写进去,让普通用户不必了解提示词工程,也能得到相对稳定的回答。





04

历史会话持久化:AI 对话不再随着窗体关闭而丢失


早期 AI 问答窗体通常只保留当前内存里的上下文。一旦关闭窗体或重新打开数据库,对话就没有了。

这在演示时问题不大,但在真实业务里不太够用。

新版 accessAI 增加了 tblChatHistory 表,用来保存每一次用户提问和 AI 回答。每条记录会保存会话 ID、模型提供商、角色、内容和时间等信息。

同时,项目提供了 frmChatHistory 历史记录窗体,可以完成三件事:

操作

作用

浏览历史会话

查看最近的 AI 对话记录

加载会话

把历史对话重新加载到当前上下文

删除会话

清理不再需要的历史记录

这一步让 accessAI 从“临时问答工具”向“可追溯的业务辅助工具”推进了一步。

例如在实际业务中,一个采购异常、一个客户投诉、一次生产质量分析,可能都需要多轮问答。保留历史会话后,后续复盘、继续追问、交接给同事都会方便很多。



05

数据库对象分析:让 AI 直接读懂当前 Access 数据库


这次更新里,我认为最有业务价值的功能,是数据库对象分析。

新版窗体中可以选择当前数据库里的表或查询。点击“分析数据”后,模块会自动读取:

  1. 对象名称。
  2. 字段结构。
  3. 记录数量。
  4. 前 30 行样例数据。

然后把这些内容拼成 Markdown 上下文,交给 AI 分析。

也就是说,用户不需要手工复制字段名,不需要自己写一段说明,也不需要先把表导出到 Excel。只要在窗体中选择一个对象,accessAI 就会把当前 Access 数据库中的结构信息和样例数据整理好,再连同用户的问题一起发送给 AI。

默认问题是:

请分析这个数据对象的业务含义、关键字段、数据质量问题、可分析方向,并给出建议的 Access SQL 查询。 

这个功能非常适合几类场景:

场景

示例

接手旧系统

快速理解某张表大概记录什么业务

数据质量检查

找出空值、异常值、字段含义混乱等问题

报表设计

让 AI 给出可分析方向和查询建议

用户培训

帮助业务人员理解数据结构和字段用途

以前 Access 开发者接手一个老数据库,往往要先看表名、字段名、查询关系,再人工推断业务含义。现在可以先让 AI 读一遍结构和样例数据,生成一个初步分析,再由开发者判断和修正。

它不会替代开发者,但可以明显缩短“读库”的时间。

从实现思路看,这个功能主要分成四步。

第一步:自动列出当前数据库对象

窗体中的“数据对象”下拉框会读取当前数据库里的用户表和查询,并用 表: xxx、查询: xxx 的形式显示出来。

这样做的好处是,用户不需要记住对象名称,也能直接从列表里选择要分析的数据源。

第二步:读取字段结构和记录数

选择对象后,模块会先读取该对象的总记录数,再通过空结果集读取字段结构。字段信息会整理成 Markdown 表格,包括字段名、DAO 数据类型和字段大小。

例如生成的上下文大致会包含这类内容:

## 数据对象
- 名称:Orders
- 类型:Table
- 记录数:1280
- 样例行数:30

## 字段结构
| 字段 | 类型 | 大小 |
|---|---|---:|
| OrderID | Long | 4 |
| CustomerName | Short Text | 255 |


第三步:读取前 30 行样例数据

字段结构只能说明“有什么字段”,但不能说明“数据长什么样”。所以模块还会读取前 30 行样例数据,并同样整理成 Markdown 表格。

这里有几个细节处理:

  1. 空值会显示为 (Null)。
  2. 日期会格式化为 yyyy-mm-dd hh:nn:ss。
  3. 单元格里的换行会转为空格,避免破坏 Markdown 表格。
  4. 内容过长时会截断,避免一次请求塞入过多文本。

这些处理看起来不复杂,但对真实数据很有必要。企业系统里的备注、说明、地址、异常描述等字段经常很长,如果不做清理,AI 上下文会很乱。

第四步:把问题和数据上下文一起发送给 AI

如果用户没有输入具体问题,系统会使用默认分析问题:

请分析这个数据对象的业务含义、关键字段、数据质量问题、可分析方向,并给出建议的 Access SQL 查询。 

如果用户自己输入了问题,例如“帮我找出这张表适合做哪些月度统计”,系统就会把用户问题放在前面,再附加字段结构和样例数据。

这使得 AI 的回答不再是泛泛而谈,而是基于当前 Access 数据库对象来分析。



06

对话样式升级:从文本框结果到气泡式聊天体验


这次更新里,界面体验变化也比较明显。

早期版本更像传统工具窗体:上方输入问题,下方显示结果。新版开始按“对话”的方式组织内容,用户消息和 AI 回复会分开显示,历史消息也会被重新渲染成完整对话。

目前项目里保留了两套对话显示方案。

两种模式的定位不一样。

模式

创建方法

特点

Access 富文本模拟气泡模式

CreateAIForm

依赖少,兼容性更好,适合大多数 Access 环境

WebBrowser HTML 真气泡模式

CreateAIWebForm

使用 HTML/CSS 渲染,界面更接近现代聊天工具

1. Access 富文本模式:用有限标签模拟聊天气泡

Access 富文本控件支持的 HTML 标签非常有限,不能像浏览器那样自由设置圆角、阴影和复杂布局。所以项目没有强行追求完整网页效果,而是采用更稳妥的方式:

消息类型

展示方式

用户消息

右对齐,使用主题色标识“我”

AI 回复

左对齐,使用灰色标识“AI”

流式输出中

AI 回复后追加一个蓝色光标块,表示内容仍在生成

历史消息

从内存或数据库重新构建完整对话 HTML

它的核心思路不是“做一个漂亮网页”,而是在 Access 富文本能力范围内,把对话关系表达清楚。

例如用户消息会通过右对齐显示,AI 消息通过左对齐显示。这样即使没有真正的圆角气泡,用户也能快速区分哪段是自己问的、哪段是 AI 回答的。

2. WebBrowser 模式:用 HTML/CSS 渲染真正的气泡界面

如果当前 Access 环境支持 Microsoft Web Browser ActiveX 控件,就可以使用 CreateAIWebForm 创建 WebBrowser 对话窗体。

这个模式会把对话内容渲染成完整 HTML 页面,并通过 CSS 控制布局、颜色、头像和气泡样式。

元素

样式设计

页面背景

浅灰蓝背景,降低长时间阅读疲劳

AI 消息区

左侧显示,浅蓝辅助背景,左边框强调

用户消息区

右侧显示,浅绿色辅助背景,右边框强调

用户气泡

蓝色气泡,白色文字

AI 气泡

白色气泡,浅蓝边框,适合显示 Markdown 内容

头像标识

使用“我”和“AI”两个文本头像,避免额外图片依赖

流式生成

使用闪烁光标样式提示 AI 正在输出

这套方案的视觉效果更接近常见的网页聊天工具。用户消息靠右,AI 消息靠左,气泡之间有留白,长文本、列表、代码块和 Markdown 转换后的内容也更容易阅读。

3. 两种模式共享同一套对话数据

这次更新比较好的地方,是显示模式和对话数据没有绑死。

无论是 Access 富文本模式,还是 WebBrowser 气泡模式,底层都使用同一套对话历史集合和同一张 tblChatHistory 表。用户发送问题后,系统会把用户消息加入历史;AI 回复完成后,再把助手消息写回历史,并重新渲染整段对话。

这样做有两个好处:

  1. 切换显示方式时,不需要重新设计 AI 调用逻辑。
  2. 加载历史会话时,可以直接根据历史记录重建对话界面。

默认仍然建议先使用:

CreateAIForm 

如果你希望体验 HTML 气泡对话界面,可以再执行:

CreateAIWebForm 

需要注意的是,WebBrowser 模式依赖 Microsoft Web Browser ActiveX 控件。不同 Windows 和 Office 环境下,ActiveX 控件注册状态可能不完全一致。如果自动创建失败,可以在窗体设计视图中手工添加该控件,并把控件名称改为 wbChat。

这个取舍比较符合 Access 项目的现实情况:优先保证可用,再给需要更好界面的用户提供增强方案。





07

如何升级使用新版 accessAI


如果你是第一次使用,可以按下面步骤操作。

第一步:下载项目

打开 GitHub 项目:

https://github.com/miaowei2/accessAI

下载后可以直接查看示例数据库 AI.accdb,也可以把模块导入自己的数据库。

第二步:导入模块

在 VBA 编辑器中导入:

  1. JsonConverter.bas
  2. Module_Markdown.bas

其中 JsonConverter.bas 负责 JSON 解析,Module_Markdown.bas 负责 AI 调用、Markdown 渲染、窗体生成、历史会话和数据库对象分析。

第三步:添加引用

在 VBA 编辑器中打开:

工具 → 引用

勾选:

Microsoft Scripting Runtime 

第四步:配置 API Key

打开 Module_Markdown.bas,根据自己要使用的模型修改 Key。

' DeepSeek Private Const DS_KEY   As String = "你的-DeepSeek-Key" ' 通义千问 Private Const QW_KEY   As String = "你的-通义千问-Key" ' 文心一言 Private Const WX_KEY   As String = "你的-文心一言-Key" ' Kimi Private Const KM_KEY   As String = "你的-Kimi-Key" 

只需要配置实际使用的模型。比如你只用 DeepSeek,就只改 DS_KEY 即可。

第五步:生成窗体

在立即窗口中执行:

CreateAIForm 

如果需要历史会话窗体,可以执行:

CreateHistoryForm 

如果需要 WebBrowser HTML 气泡模式,可以执行:

CreateAIWebForm 

生成后打开 frmAI,选择模型,输入问题即可使用。



08

注意点


  1. 流式输出依赖系统内置 curl.exe,通常 Windows 10 1803 及以上版本自带;没有 curl 时会自动使用同步请求 + 打字机效果。
  2. WebBrowser 模式依赖 ActiveX 控件,不同 Office 环境中可能需要手工添加控件。
  3. 自定义 API 端点要求服务兼容 OpenAI Chat Completions 格式,否则请求体和返回解析可能需要调整。
  4. 数据库对象分析会读取样例数据,实际使用时要注意敏感字段和隐私数据,不建议把未经脱敏的核心业务数据发送到外部模型。
  5. tblChatHistory 会保存对话内容,如果数据库要交付给客户或第三方,建议先清理历史记录。


09

总结


这次 accessAI 的更新,重点不是“多加了几个按钮”,而是把 Access 接入 AI 的使用链路补完整了。

核心变化可以概括为 6 点:

  1. 跟进 DeepSeek V4 更新,支持 Flash / Pro 两个模型档位,模型选择更清晰。
  2. 支持通义千问、文心一言、Kimi 和自定义 OpenAI 兼容端点。
  3. 增加 System Prompt,让 AI 回答更符合系统角色和业务规则。
  4. 升级对话样式,支持 Access 富文本模拟气泡和 WebBrowser HTML 真气泡两种显示模式。
  5. 增加历史会话持久化和历史管理窗体,让对话可以保存、加载和追溯。
  6. 增加数据库对象分析,让 AI 可以基于当前 Access 表和查询给出结构化分析建议。

如果你已经看过上一篇 accessAI 的介绍,可以把这次更新理解为从“能调用 AI”升级到“能在 Access 系统里管理和使用 AI”。

这也是我更看重的方向:不是为了做一个孤立的聊天窗口,而是让 AI 能自然进入原有的业务系统、数据表、查询和工作流。

测试环境建议参考:

  1. Microsoft Access 2010 及以上版本,推荐 Access 2016、2019、365。
  2. Windows 7 及以上。
  3. 如需更好的流式体验,建议 Windows 10 1803 及以上。

完整源码

项目已开源,欢迎 Star:

GitHub 地址:
https://github.com/miaowei2/accessAI

包含:

  • AI.accdb:示例数据库,包含已导入模块和窗体
  • Module_Markdown.bas:核心模块,负责 AI 调用、Markdown 渲染、窗体生成、历史管理和数据库对象分析
  • JsonConverter.bas:JSON 解析模块
  • README.md:项目说明和快速开始文档

下一篇

本文分享了一款名为 accessAI 的开源工具,帮助 Access 开发者利用 VBA 轻松集成 AI 大模型能力。它解决了原生不支持流式 HTTP 和 Markdown 的痛点,采用 curl+SSE 实现打字机效果,并内置 UTF-8 编码处理。只需导入两个模块即可生成智能问答窗体,支持 DeepSeek 等模型,适用于表单辅助、报表解读等场景,让老旧系统也能享受 AI 红利。

相关阅读

本文精选 20 个 Excel 核心公式,覆盖逻辑判断、多条件查找、统计汇总、文本处理及新版动态数组等功能。通过具体场景案例演示,帮助财务、HR 等岗位人员解决 80% 日常数据处理难题,大幅提升工作效率。建议收藏学习,按需调用。
本文分享了一款名为 accessAI 的开源工具,帮助 Access 开发者利用 VBA 轻松集成 AI 大模型能力。它解决了原生不支持流式 HTTP 和 Markdown 的痛点,采用 curl+SSE 实现打字机效果,并内置 UTF-8 编码处理。只需导入两个模块即可生成智能问答窗体,支持 DeepSeek 等模型,适用于表单辅助、报表解读等场景,让老旧系统也能享受 AI 红利。