AccessAI 重磅更新:支持 DeepSeek V4 及数据库对象分析,气泡对话更智能
作者:本站 来源:本站
2026-05-05 15:38 1299阅读
各位开发者朋友们好!
版权声明
在正式介绍之前,先做一个统一说明:
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 的第一步,通常只是做一个“提问框 + 回答框”。
这个阶段能证明技术可行,但还不够贴近真实业务。因为在实际项目里,用户往往会遇到这些问题:
- 不同任务适合不同模型,不能只写死一个模型。
- 同一次业务沟通需要保留上下文,不能每次都重新开始。
- 用户关闭数据库后,希望还能查到之前的 AI 对话。
- AI 不应该只回答自由文本问题,还应该能分析当前 Access 数据库里的表和查询。
- 如果企业已经有自己的 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 模型档位:
- DeepSeek Flash
- 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 按照固定角色回答。
例如:
- 让 AI 扮演采购数据分析助手。
- 让 AI 只根据当前表格内容回答,不要编造数据。
- 让 AI 输出 Access SQL,而不是其他数据库语法。
- 让 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 数据库
这次更新里,我认为最有业务价值的功能,是数据库对象分析。
新版窗体中可以选择当前数据库里的表或查询。点击“分析数据”后,模块会自动读取:
- 对象名称。
- 字段结构。
- 记录数量。
- 前 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 表格。
这里有几个细节处理:
- 空值会显示为 (Null)。
- 日期会格式化为 yyyy-mm-dd hh:nn:ss。
- 单元格里的换行会转为空格,避免破坏 Markdown 表格。
- 内容过长时会截断,避免一次请求塞入过多文本。
这些处理看起来不复杂,但对真实数据很有必要。企业系统里的备注、说明、地址、异常描述等字段经常很长,如果不做清理,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 回复完成后,再把助手消息写回历史,并重新渲染整段对话。
这样做有两个好处:
- 切换显示方式时,不需要重新设计 AI 调用逻辑。
- 加载历史会话时,可以直接根据历史记录重建对话界面。
默认仍然建议先使用:
CreateAIForm 如果你希望体验 HTML 气泡对话界面,可以再执行:
CreateAIWebForm 需要注意的是,WebBrowser 模式依赖 Microsoft Web Browser ActiveX 控件。不同 Windows 和 Office 环境下,ActiveX 控件注册状态可能不完全一致。如果自动创建失败,可以在窗体设计视图中手工添加该控件,并把控件名称改为 wbChat。
这个取舍比较符合 Access 项目的现实情况:优先保证可用,再给需要更好界面的用户提供增强方案。

07
如何升级使用新版 accessAI
如果你是第一次使用,可以按下面步骤操作。
第一步:下载项目
打开 GitHub 项目:
https://github.com/miaowei2/accessAI
下载后可以直接查看示例数据库 AI.accdb,也可以把模块导入自己的数据库。
第二步:导入模块
在 VBA 编辑器中导入:
- JsonConverter.bas
- 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
注意点
- 流式输出依赖系统内置 curl.exe,通常 Windows 10 1803 及以上版本自带;没有 curl 时会自动使用同步请求 + 打字机效果。
- WebBrowser 模式依赖 ActiveX 控件,不同 Office 环境中可能需要手工添加控件。
- 自定义 API 端点要求服务兼容 OpenAI Chat Completions 格式,否则请求体和返回解析可能需要调整。
- 数据库对象分析会读取样例数据,实际使用时要注意敏感字段和隐私数据,不建议把未经脱敏的核心业务数据发送到外部模型。
- tblChatHistory 会保存对话内容,如果数据库要交付给客户或第三方,建议先清理历史记录。
09
总结
这次 accessAI 的更新,重点不是“多加了几个按钮”,而是把 Access 接入 AI 的使用链路补完整了。
核心变化可以概括为 6 点:
- 跟进 DeepSeek V4 更新,支持 Flash / Pro 两个模型档位,模型选择更清晰。
- 支持通义千问、文心一言、Kimi 和自定义 OpenAI 兼容端点。
- 增加 System Prompt,让 AI 回答更符合系统角色和业务规则。
- 升级对话样式,支持 Access 富文本模拟气泡和 WebBrowser HTML 真气泡两种显示模式。
- 增加历史会话持久化和历史管理窗体,让对话可以保存、加载和追溯。
- 增加数据库对象分析,让 AI 可以基于当前 Access 表和查询给出结构化分析建议。
如果你已经看过上一篇 accessAI 的介绍,可以把这次更新理解为从“能调用 AI”升级到“能在 Access 系统里管理和使用 AI”。
这也是我更看重的方向:不是为了做一个孤立的聊天窗口,而是让 AI 能自然进入原有的业务系统、数据表、查询和工作流。
测试环境建议参考:
- Microsoft Access 2010 及以上版本,推荐 Access 2016、2019、365。
- Windows 7 及以上。
- 如需更好的流式体验,建议 Windows 10 1803 及以上。
完整源码
项目已开源,欢迎 Star:
GitHub 地址:
https://github.com/miaowei2/accessAI
包含:
- AI.accdb:示例数据库,包含已导入模块和窗体
- Module_Markdown.bas:核心模块,负责 AI 调用、Markdown 渲染、窗体生成、历史管理和数据库对象分析
- JsonConverter.bas:JSON 解析模块
- README.md:项目说明和快速开始文档
下一篇
相关阅读