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 开发者习惯的路线：

1. 不引入复杂外部框架。
2. 尽量依赖 VBA 原生能力和常见系统组件。
3. 把复杂逻辑封装在单独模块中。
4. 把“可运行”放在“架构炫技”前面。

这个思路很务实。因为对多数 Access 场景来说，真正重要的不是抽象多优雅，而是能否快速导入、快速配置、快速验证。

三、技术原理分析：它为什么能在 Access 里跑出 AI 体验

这个项目最值得讲的地方，不是界面，而是我对几个关键问题的处理思路。

1. 请求构造：不用手拼 JSON，降低出错率

我没有直接字符串拼接 JSON，而是使用字典和集合构造请求体，再通过 JsonConverter 统一序列化。

这样做有两个好处：

1. 避免引号转义、换行符和特殊字符处理不稳。
2. 后续扩展模型参数时更容易维护。

请求体核心思路大致如下：

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 接口里的流式返回。我采用的方案是：

1. 先把请求体写入临时 JSON 文件。
2. 通过系统内置的 curl 发起请求。
3. 使用 SSE 方式接收模型的分段输出。
4. 将响应写入临时文件。
5. VBA 周期性轮询这个临时文件。
6. 从 data 行中提取 delta.content，实时刷新到窗体。

这个方案的优点非常明显：

方案点	价值
借助 curl	避开 VBA 对流式 HTTP 支持不足的问题
使用临时文件	简化进程间数据传递
轮询解析 SSE	在 Access 环境中实现近似实时输出
逐段刷新 UI	提升交互体验，避免“长时间无响应”

这其实是一个很典型的“老平台兼容现代接口”的工程思路：不硬碰硬，而是借系统已有工具把问题拆开。

3. 回退机制：没有流式环境，也能正常工作

我没有把方案绑死在单一路径上。

如果系统里找不到 curl，它会自动切换到同步请求模式，然后再叠加一个“打字机效果”，让结果不是一次性整块弹出来，而是逐段显示。

这一步很重要，因为很多企业环境并不统一：

1. 有的机器系统版本较旧。
2. 有的环境权限受限。
3. 有的客户端组件不完整。

如果没有这个回退方案，项目就只能在少数机器上表现良好。现在这种双通道设计，明显更适合真实业务场景。

4. Markdown 渲染：把模型输出从“文本”提升到“可读内容”

大模型返回的很多结果，本质上是带结构的 Markdown。如果只是原样塞进文本框，体验会比较差。

所以我在模块中实现了 Markdown 到 Access 富文本 HTML 的转换，支持的内容包括：

1. 标题。
2. 粗体、斜体、粗斜体。
3. 删除线。
4. 行内代码和代码块。
5. 有序列表和无序列表。
6. 引用块。
7. 水平线。
8. 链接和图片占位提示。

思路不是追求完整的 Markdown 标准覆盖，而是围绕 Access 富文本控件支持的 HTML 子集做适配。换句话说，追求的是"在 Access 里显示效果尽可能好"，而不是"实现一个完全体 Markdown 引擎"。

这是一种非常合理的取舍。

5. UTF-8 处理：这是很多 VBA 项目最容易忽略的坑

我在项目里专门处理了 UTF-8 读写问题，包括：

1. 使用 ADODB.Stream 读写 UTF-8 内容。
2. 写入时去掉 BOM。
3. 读取响应时做 UTF-8 到 VBA 字符串的转换。

这一点对中文用户非常关键。

如果没有这套处理，最常见的问题就是：

1. 提问里有中文时，请求内容异常。
2. AI 返回中文时，出现乱码。
3. 流式响应中断后，文本解析失败。

很多人做 Access 对接 API，最后不是死在接口文档，而是死在编码细节。所以我把这个问题在一开始就处理掉了。

四、实现步骤：如何把它接入自己的 Access 项目

第一步：导入两个基础模块

把下面两个模块导入到你的 Access 数据库中：

1. JsonConverter.bas
2. 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 = "https://api.deepseek.com/chat/completions"
Private Const API_MODEL As String = "deepseek-chat"

如果后续项目扩展到更多模型，这一段也会是最自然的配置入口。

第四步：一键生成 AI 问答窗体

在 VBA 立即窗口中运行：

CreateAIForm

执行后，项目会自动创建一个名为 frmAI 的窗体，并生成几个核心控件：

控件	作用
txtQ	输入问题
btnAsk	提交问题
lblMsg	显示状态
txtAnswer	显示 AI 返回结果
这个过程很适合做演示，也很适合做快速验证。对于很多开发者来说，这一步已经足够说明问题了：Access 窗体不仅能接 AI，而且能在几分钟内搭出可用界面。

如果你要把 AI 生成的格式化说明、帮助文档、规则解释直接展示给用户，这个能力很实用。

运行效果

五、实际业务里可以怎么用

我认为这个项目最有价值的地方，不是"做一个 AI 聊天窗体"，而是可以嵌进现有业务系统里。

下面列几个更贴近业务的应用方向。

场景一：单据录入辅助

在采购单、入库单、售后记录、客户拜访记录等表单中，用户录入完基础信息后，可以让 AI 自动补充：

1. 备注说明。
2. 风险提示。
3. 标准化描述。
4. 后续处理建议。

这类需求本质上不需要复杂对话，只要把当前表单字段拼成一段提示词即可。

场景二：知识问答入口

如果 Access 系统本身就是某个部门的工作平台，那么可以把 AI 问答作为一个“业务帮助入口”，例如：

1. 这个字段应该怎么填。
2. 这个异常状态是什么意思。
3. 这张单据的流程下一步是什么。
4. 这个查询条件应该如何组合。

从用户体验上说，这比翻帮助文档更直接。

场景三：报表解读与总结

很多 Access 系统里已经有现成查询和统计报表。把报表结果拼成结构化文本后，可以交给 AI 做：

1. 本月数据摘要。
2. 异常点说明。
3. 趋势概括。
4. 管理层汇报草稿。

这类场景不一定要求完全自动化，但作为“初稿生成器”非常合适。

场景四：文本规范化处理

对于售后记录、巡检记录、客服备注、生产异常说明这类自由文本字段，AI 可以承担：

1. 语句润色。
2. 内容归纳。
3. 标准术语替换。
4. 风险标签提取。

Access 在企业里经常承担轻量信息系统角色，而这些文本处理需求又恰好非常高频。

六、总结

做这个项目的意义，不只是"让 Access 也能调用 AI"，而是想证明一件事：

老平台并不等于落后平台，关键在于是否有人愿意用合适的方式，把新能力嫁接进去。

本文涉及的核心技术点，可以归纳为 5 个方面：

1. 使用 VBA 构造标准聊天请求，并通过 JSON 序列化降低错误率。
2. 使用 curl + SSE 在 Access 中实现流式输出体验。
3. 通过同步回退 + 打字机效果，兼顾不同 Windows 环境。
4. 将 Markdown 转为 Access 富文本 HTML，提升结果可读性。
5. 通过自动建窗体，降低 AI 功能接入和演示成本。

如果你本身就在做 Access 开发，欢迎试一下这个项目。我想展示的不是某个孤立技巧，而是一条比较完整的落地路径：如何在不重写系统的前提下，为 Access 项目补上 AI 能力。

测试环境建议参考：

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

---

参考资料

1. DeepSeek 平台：https://platform.deepseek.com/
2. VBA-JSON：https://github.com/VBA-tools/VBA-JSON

---

完整源码

项目已开源，欢迎 Star：

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

包含：

• Module_Markdown.bas — 核心模块（AI 调用 + Markdown 渲染 + 窗体生成）
• JsonConverter.bas — JSON 解析模块
• AI.accdb — 示例数据库，导入即可体验

下载后直接导入即可使用，无需任何额外配置。

---

写在最后

Access 虽然"老"，但在中小企业、政府机关、制造业中依然有着广泛的应用。很多运行多年的 Access 系统，承载着核心业务数据，短期内不可能迁移到其他平台。

与其等着被淘汰，不如用技术手段给它接上新能力。AI 大模型的接入看似门槛高，但 accessAI 已经把核心链路跑通了——两个模块、一行命令、几分钟就能在你的 Access 系统里跑出一个 AI 问答功能。

如果你的团队正在使用 Access，或者你是一名 Access 开发者，欢迎试用这个开源工具。 如果觉得有用，请帮忙转发给更多需要的人。

在 Access 开发中遇到任何问题，也欢迎在公众号后台留言交流。我会持续分享 Access 实战技巧和开源工具，帮助大家把这个"老伙计"用得更顺手。