Hi，大家好！
背景
AI 大模型已经渗透到各种开发平台，但 Access 这边一直没什么动静。原因也简单：VBA 没有原生的流式 HTTP 支持，没有 Markdown 渲染能力，中文编码处理也不省心。想在 Access 窗体里接入 AI，要自己啃一遍 HTTP 请求、JSON 拼装、SSE 解析和 UTF-8 编码的坑。
所以我做了 accessAI 这个工具库，把这些问题打包解决。两个 .bas 模块导入即可使用，支持流式输出、Markdown 富文本渲染和一键生成问答窗体，开箱即用。现在把它开源出来，源码见文末链接。
| 能力 | 说明 |
|---|
| AI 对话问答 | 在 Access 窗体中直接向 DeepSeek 提问 |
| 流式输出 | 通过 curl + SSE 实现实时逐字显示 |
| 降级兼容 | 没有 curl 环境时，自动退回同步请求 + 打字机效果 |
| Markdown 渲染 | 将模型返回的 Markdown 转成 Access 富文本 HTML |
| 自动建窗体 | 通过过程调用自动生成问答窗体和 Markdown 查看器 |
| UTF-8 支持 | 避免中文请求和中文响应出现乱码 |
这几个能力合在一起，意味着你可以在不推翻现有系统的前提下，为 Access 项目快速补上 AI 问答、文本生成和内容格式化展示能力。
目录里实际包含的核心内容并不多：
| 文件 | 作用 |
|---|
| AI.accdb | 示例数据库，包含已导入模块和窗体 |
| Module_Markdown.bas | 核心模块，负责 AI 调用、Markdown 渲染和窗体生成 |
| JsonConverter.bas | JSON 解析模块，基于 VBA-JSON |
| README.md | 项目说明和快速开始文档 |
从结构上看，它走的是一种很适合 Access 开发者的路线：
不引入复杂外部框架。
尽量依赖 VBA 原生能力和常见系统组件。
把复杂逻辑封装在单独模块中。
把“可运行”放在“架构炫技”前面。
这种设计思路很务实。因为对多数 Access 场景来说，真正重要的不是抽象多优雅，而是能否快速导入、快速配置、快速验证。
三、技术原理分析：它为什么能在 Access 里跑出 AI 体验
我的这个开源项目最值得讲的地方，不是界面，而是它对几个关键问题的处理。
1. 请求构造：不用手拼 JSON，降低出错率
项目里不是直接字符串拼接 JSON，而是使用字典和集合构造请求体，再通过 JsonConverter 统一序列化。
这样做有两个好处：
避免引号转义、换行符和特殊字符处理不稳。
后续扩展模型参数时更容易维护。
请求体核心思路大致如下：
Private Function BuildDeepSeekRequestBody(ByVal sQuestion As String, _
Optional ByVal bStream As Boolean = False) As String
Dim oRoot As Object
Dim oMsg As Object
Dim colMessages As Collection
Set oRoot = CreateObject("Scripting.Dictionary")
Set oMsg = CreateObject("Scripting.Dictionary")
Set colMessages = New Collection
oMsg.Add "role", "user"
oMsg.Add "content", sQuestion
colMessages.Add oMsg
oRoot.Add "model", API_MODEL
oRoot.Add "messages", colMessages
oRoot.Add "temperature", 0.7
oRoot.Add "max_tokens", 8192
If bStream Then oRoot.Add "stream", True
BuildDeepSeekRequestBody = JsonConverter.ConvertToJson(oRoot)
End Function
这段实现虽然不复杂，但非常关键。因为很多 Access 调用 Web API 的失败，并不是网络问题，而是 JSON 拼装细节导致的。
2. 流式输出：用 curl + SSE 绕开传统 VBA 的限制
Access 和 VBA 本身并不擅长处理现代 AI 接口里的流式返回。accessAI 采用的方案是：
这个方案的优点非常明显：
| 方案点 | 价值 |
|---|
| 借助 curl | 避开 VBA 对流式 HTTP 支持不足的问题 |
| 使用临时文件 | 简化进程间数据传递 |
| 轮询解析 SSE | 在 Access 环境中实现近似实时输出 |
| 逐段刷新 UI | 提升交互体验，避免“长时间无响应” |
这其实是一个很典型的“老平台兼容现代接口”的工程思路：不硬碰硬，而是借系统已有工具把问题拆开。
3. 回退机制：没有流式环境，也能正常工作
项目没有把自己绑死在单一方案上。
如果系统里找不到 curl，它会自动切换到同步请求模式，然后再叠加一个“打字机效果”，让结果不是一次性整块弹出来，而是逐段显示。
这一步很重要，因为很多企业环境并不统一：
有的机器系统版本较旧。
有的环境权限受限。
有的客户端组件不完整。
如果没有这个回退方案，项目就只能在少数机器上表现良好。现在这种双通道设计，明显更适合真实业务场景。
4. Markdown 渲染：把模型输出从“文本”提升到“可读内容”
大模型返回的很多结果，本质上是带结构的 Markdown。如果只是原样塞进文本框，体验会比较差。
accessAI 在模块中实现了 Markdown 到 Access 富文本 HTML 的转换，支持的内容包括：
标题。
粗体、斜体、粗斜体。
删除线。
行内代码和代码块。
有序列表和无序列表。
引用块。
水平线。
链接和图片占位提示。
它的思路不是追求完整的 Markdown 标准覆盖，而是围绕 Access 富文本控件支持的 HTML 子集做适配。换句话说，它追求的是“在 Access 里显示效果尽可能好”，而不是“实现一个完全体 Markdown 引擎”。
这是一种非常合理的取舍。
5. UTF-8 处理：这是很多 VBA 项目最容易忽略的坑
项目里专门处理了 UTF-8 读写问题，包括：
使用 ADODB.Stream 读写 UTF-8 内容。
写入时去掉 BOM。
读取响应时做 UTF-8 到 VBA 字符串的转换。
这一点对中文用户非常关键。
如果没有这套处理，最常见的问题就是：
提问里有中文时，请求内容异常。
AI 返回中文时，出现乱码。
流式响应中断后，文本解析失败。
很多人做 Access 对接 API，最后不是死在接口文档，而是死在编码细节。accessAI 把这个问题提前处理掉了。
四、实现步骤：如何把它接入自己的 Access 项目
第一步：导入两个基础模块
把下面两个模块导入到你的 Access 数据库中：
JsonConverter.bas
Module_Markdown.bas
其中，JsonConverter.bas 负责 JSON 解析，Module_Markdown.bas 是整个项目的核心。
第二步：添加 VBA 引用
在 VBA 编辑器中打开：
工具 → 引用
勾选下面这个引用：
Microsoft Scripting Runtime
这是项目里字典对象等功能所需的基础依赖。
第三步：配置 AI 接口参数
打开模块中的常量配置，把 API Key 改成你自己的。目前只调用了deepseek，后期我也会把其他的大模型接进来！
Private Const API_KEY As String = "你的 API Key"
Private Const API_URL As String = "
Private Const API_MODEL As String = "deepseek-chat"
如果后续项目扩展到更多模型，这一段也会是最自然的配置入口。
第四步：一键生成 AI 问答窗体
在 VBA 立即窗口中运行：
CreateAIForm
执行后，项目会自动创建一个名为 frmAI 的窗体，并生成几个核心控件：
| 控件 | 作用 |
|---|
| txtQ | 输入问题 |
| btnAsk | 提交问题 |
| lblMsg | 显示状态 |
| txtAnswer | 显示 AI 返回结果 |
运行效果
效果图为GIF动图，只截取了部分
下面列几个更贴近业务的应用方向。
场景一：单据录入辅助
在采购单、入库单、售后记录、客户拜访记录等表单中，用户录入完基础信息后，可以让 AI 自动补充：
备注说明。
风险提示。
标准化描述。
后续处理建议。
这类需求本质上不需要复杂对话，只要把当前表单字段拼成一段提示词即可。
场景二：知识问答入口
如果 Access 系统本身就是某个部门的工作平台，那么可以把 AI 问答作为一个“业务帮助入口”，例如：
这个字段应该怎么填。
这个异常状态是什么意思。
这张单据的流程下一步是什么。
这个查询条件应该如何组合。
从用户体验上说，这比翻帮助文档更直接。
场景三：报表解读与总结
很多 Access 系统里已经有现成查询和统计报表。把报表结果拼成结构化文本后，可以交给 AI 做：
本月数据摘要。
异常点说明。
趋势概括。
管理层汇报草稿。
这类场景不一定要求完全自动化，但作为“初稿生成器”非常合适。
场景四：文本规范化处理
对于售后记录、巡检记录、客服备注、生产异常说明这类自由文本字段，AI 可以承担：
语句润色。
内容归纳。
标准术语替换。
风险标签提取。
Access 在企业里经常承担轻量信息系统角色，而这些文本处理需求又恰好非常高频。
我认为这个项目最有价值的地方，不是"做一个 AI 聊天窗体"，而是可以嵌进现有业务系统里。下面列几个更贴近业务的应用方向。
使用 VBA 构造标准聊天请求，并通过 JSON 序列化降低错误率。
使用 curl + SSE 在 Access 中实现流式输出体验。
通过同步回退 + 打字机效果，兼顾不同 Windows 环境。
将 Markdown 转为 Access 富文本 HTML，提升结果可读性。
通过自动建窗体，降低 AI 功能接入和演示成本。
如果你本身就在做 Access 开发，这个项目很值得认真看一遍。它展示的不是某个孤立技巧，而是一条比较完整的落地路径：如何在不重写系统的前提下，为 Access 项目补上 AI 能力。
测试环境建议参考：
Microsoft Access 2010 及以上版本，推荐 Access 2016、2019、365。
Windows 7 及以上。
如需更好的流式体验，建议 Windows 10 1803 及以上。
参考资料
DeepSeek 平台：https://platform.deepseek.com/
VBA-JSON：https://github.com/VBA-tools/VBA-JSON
项目已开源，欢迎 Star：
GitHub 地址：https://github.com/miaowei2/accessAI
包含：
下载后直接导入即可使用，无需任何额外配置。
Access 虽然"老"，但在中小企业、政府机关、制造业中依然有着广泛的应用。很多运行多年的 Access 系统，承载着核心业务数据，短期内不可能迁移到其他平台。
与其等着被淘汰，不如用技术手段给它接上新能力。AI 大模型的接入看似门槛高，但 accessAI 已经把核心链路跑通了——两个模块、一行命令、几分钟就能在你的 Access 系统里跑出一个 AI 问答功能。
如果你的团队正在使用 Access，或者你是一名 Access 开发者，欢迎试用这个开源工具。 如果觉得有用，请帮忙转发给更多需要的人。
「Access 开发」 专注于 Microsoft Access 开发与企业级应用，提供以下服务：
📚 技术培训
Access VBA 从入门到精通（线上/线下）
Access + SQL Server 企业级开发实战
Access 系统性能优化与架构设计
💼 定制开发
企业 ERP/CRM/进销存等系统开发
旧系统升级与性能优化
🔧 技术支持
代码审查与重构建议
疑难问题远程诊断
一对一技术辅导
联系方式：
公众号后台留言
邮箱：will.miao@edonsoft.com
微信：edonsoft