这次把最近做的一组实测对比整理成文字版。主题很直接在 Access 数据库开发这个偏传统、偏办公的场景里ChatGPT、Gemini、Claude 到底哪个真正好用。网上关于这三个工具的对比很多但多数集中在写 Python、写网页、处理长文本真正拿一套 Access 业务系统去实测的很少。我的看法是AI 写 Access 代码这件事核心不在于“能不能写”而在于“给出来的东西能不能拿到 Access 里直接用”。这次我模拟了一个客户订单管理系统从零建设的过程用三个工具分别完成表结构设计、SQL 查询、VBA 自动化、窗体报表说明和错误排查按“能直接使用、修改后可用、不能使用”三档来评分。先说结论ChatGPT 更适合做方案拆解和错误解释Claude 在连续写 VBA 代码块时质量最稳Gemini 的响应速度快、表达简洁但在复杂 Access 细节上容易把话说得太满。下面把整个测试过程和判断标准展开。1. 为什么选 Access 数据库开发来测 AI 工具1.1 Access 项目并没有消失反而是很好的“AI 试金石”很多开发者觉得 Access 是老古董但实际在中小企业、部门级系统、教学和办公场景里Access 仍然大量存在。理由很简单有 Office 就能用、建表快、窗体报表方便、不需要单独部署数据库服务。也正因为这样Access 开发有一个特点需求大多来自业务人员开发方式混合了图形化界面、SQL 和 VBA很多资料还是十年前甚至二十年前的老教程。这种环境对 AI 来说是一种压力测试。如果 AI 能把 Access 这类“古老但真实”的开发任务处理好那它在其他更规范、更主流的开发场景里至少不会出现“完全不会”的情况。反过来如果 AI 只会写 Python、写网页遇到 Access 的 VBA 对象模型、查询设计器、窗体事件很可能给出漂亮但无法运行的答案。所以这次对比不是追逐热点而是想看这三个工具在真实办公开发里的下限和上限。1.2 这次对比的具体任务设计我模拟的案例是一个客户订单管理系统包含客户表、产品表、订单主表、订单明细表。任务覆盖了产品经理、数据分析、后端开发、桌面端开发四类工作表结构设计SQL 多表统计查询VBA 批量导入 Excel 数据订单录入窗体设计VBA 运行时错误排查每次提问使用相同的中文描述不附加额外提示观察输出是否完整、是否与 Access 语法兼容、是否考虑文件路径、权限、空值、重复数据等现实因素。这里有一点很关键真实开发中用户不会给 AI 一份规范到位的需求文档更多是直接说“我要做一个订单管理库”“把 Excel 导进去”。所以我把提问方式也保持成偏真实的用户口吻而不是面试题式的标准 Prompt。2. 测试前的环境、任务输入和评分标准2.1 我使用的运行环境一篇文章如果把环境写清楚排错会容易得多。我这次在 Windows 11 上使用 Microsoft 365 版本的 Access数据库文件先放在本地目录。如果你还在用 Office 2016 或 2019很多操作逻辑相同但 VBA 里的对象模型差异不大遇到个别属性不兼容时再单独查版本差异。AI 工具方面ChatGPT 使用 Web 对话和本地 CLI 两种方式Gemini 使用 Web 对话Claude 使用 Web 对话和本地命令工具。三个工具的模型版本会不定期更新所以这里不聚焦某一个具体版本只描述同一时间段内的表现。这类评测最怕的是把版本说得太死因为模型更新很快结论可能过一个月就变了。2.2 输入任务的方式给 AI 提 Access 问题时任务描述是否包含表结构、字段类型、期望结果、报错信息会直接影响答案质量。我这次都采用偏真实的用户口吻“我要做一个客户订单管理 Access 数据库。”“用 VBA 把 Excel 数据导入到订单明细表如果订单号加产品编号已经存在就跳过。”“查询每个客户的订单总额和订单数量结果按金额从高到低。”“执行更新查询时提示‘操作必须使用一个可更新的查询’是什么原因”没有额外加“请使用最佳实践”这类提示词。原因很简单实际工作中使用者就是直接把业务需求发给 AI很少有人能写出完美的提示词。如果 AI 在不够标准的输入下都能给出可运行结果那才是真正可用的助手。2.3 三档评分标准我给每个任务设定了三档评分能用复制到 VBA 编辑器或者查询设计器不需要大改就能运行。改一下能用需要修正表名、字段名、连接条件或者手动补引用、补错误处理。不能用返回的是伪代码、Python 代码、明显与 Access 无关的 MySQL 语法或者给出的代码在 Access VBA 里无法编译。评分时我会特别关注“是否能直接落地”。AI 生成的代码再漂亮如果复制进去第一次运行就报错那在实际开发里就是不能用的至少需要二次加工。3. 五个开发场景的实测记录3.1 场景一表结构设计先让三个工具设计客户订单管理系统的表结构要求包含客户、产品、订单、订单明细。ChatGPT 给出的方案比较清晰包含主键、外键关系、字段类型建议客户表和订单表之间用客户ID关联订单明细表和产品表通过产品ID关联。它还补了索引建议这一点对 Access 查询性能有帮助。Gemini 的输出更快但结构更粗外键关系和索引建议较少更像一个简版草案。Claude 的答案最接近完整设计文档把每个字段的用途、允许空值、默认值也写了适合直接照着建表。不过在表设计阶段三个工具都默认使用自动编号作为主键没有主动提示 Access 中“自动编号字段是长整型不是文本型”的细节。在开发中这类细节需要手动确认。另一个容易忽略的点是字段命名规范。AI 生成字段名时经常喜欢用 Name、User、Date 这类词实际在 Access 中容易和保留字冲突后面我会单独说。3.2 场景二SQL 多表统计查询我给的查询任务是统计每个客户的订单总额、订单数量、最近下单日期输出客户名称、总额、数量、最近日期按总额降序排序只显示已经下单的客户。这里主要看 AI 是否会用 GROUP BY、SUM、COUNT、MAX以及是否处理 JOIN。ChatGPT 给出的 SQL 是标准 Access 方言字段名加了中括号能直接放到查询设计器。Gemini 给出的 SQL 同样能运行但少了“只显示已下单客户”的 INNER JOIN 条件后续我追问后它才补上。Claude 给出了完整 SQL还额外提示“如果订单状态字段存在建议加 WHERE 过滤已审核订单”。对于开发来说Claude 这次最省事。这里需要提醒一点Access 的 SQL 方言和 SQL Server、MySQL 并不完全一样。AI 偶尔会混用语法比如把 TOP 写成 LIMIT或者使用 Access 不支持的函数。遇到这种情况不能直接怀疑 AI 不会写而是要在输入里说明“这是 Microsoft Access 数据库不是 MySQL”。3.3 场景三VBA 批量导入 Excel 数据VBA 是 Access 开发里最考验 AI 的部分。任务描述要把 Excel 里的订单明细导入 Access 的订单明细表Excel 列包括订单号、产品编号、数量、单价如果订单号加产品编号已经存在则跳过。ChatGPT 给出的代码结构完整有 DoCmd.TransferSpreadsheet 和逐行读取两种方案并解释了两种方案的取舍。但逐行读取方案里对“跳过重复”的判断不够精确只检查订单号没有检查订单号加产品编号的组合。Gemini 给出的代码比较简洁但错误处理较少如果 Excel 里有空行代码会直接报错。Claude 给出的代码最完整包含了错误处理、空行跳过、事务回滚还提醒“如果数据量很大逐行读会很慢建议先用追加查询导入临时表再处理重复”。这一点非常符合 Access 实际开发中“先传临时表再清洗”的通用做法。大批量导入时逐行读 Recordset 的效率很低几千行可能就要等很久。更稳妥的方案是先用 DoCmd.TransferSpreadsheet 把整个 Excel 表导入到一个临时表再用追加查询把临时表里的数据合并到正式表同时处理重复。AI 能主动给出这个思路说明它对 Access 的性能特征有理解。3.4 场景四订单录入窗体和按钮事件Access 里很多开发不是写纯代码而是做窗体。我让 AI 设计一个“订单录入窗体”要求功能包括选择客户、添加明细、自动计算合计、保存订单和明细。三个工具在这个任务上都给出了方向性建议主窗体绑定订单主表子窗体绑定订单明细表用“订单ID”作为主链接字段。但代码层面差异很大。ChatGPT 给出的 Form_BeforeUpdate 事件逻辑比较清楚但把“合计金额”计算放在窗体关闭时才更新用户体验一般。Gemini 给出的窗体结构说明过于简单更适合当作草图。Claude 直接给了子窗体 AfterUpdate 事件示例把合计金额实时刷新写在代码里。需要说明的是窗体设计本身有很大一部分在 Access 的图形界面里完成AI 只能给字段布局思路和关键事件代码这一点不要期待 AI 直接把整个窗体生成出来。更合理的用法是先让 AI 给出窗体需要的字段和事件清单然后在 Access 设计视图里手工拖控件再让 AI 补事件代码。这样比直接让 AI“生成整个窗体”更可控。3.5 场景五运行时错误排查Access 开发最让人头疼的是 VBA 运行时错误。我故意构造了一个常见报错让 AI 解释执行更新查询时提示“操作必须使用一个可更新的查询”。这个错误在 Access 里非常常见原因通常是查询涉及多表连接导致无法更新或者数据库文件目录没有写权限或者查询结果集来自聚合查询。ChatGPT 对错误原因分析最全面列出了表连接、权限、查询类型三种原因并给出了逐步排查顺序。Gemini 的回答偏短解释了“可更新的查询”在 Access 中的含义但排查顺序不如 ChatGPT 细。Claude 回答中包含了一个容易忽略的点如果 ORDER BY 或 GROUP BY 字段中包含计算字段也可能导致结果集不可更新这确实是我在实测中遇到过的情况。这类排错上三个工具都能帮上忙但能不能覆盖完整取决于你给出的报错信息有多完整。如果你只贴一句“报错了”AI 也只能给你一个通用回答。如果能把完整的错误文字、操作步骤、涉及的表字段都贴出来AI 给到可用建议的概率会高很多。场景ChatGPTGeminiClaude表结构设计完整索引建议好结构较粗最详细适合直接建表SQL 统计查询Access 方言准确简洁但遗漏条件最省事主动补过滤条件VBA 批量导入方案多细节有偏差代码简洁但容错弱代码最完整性能建议到位窗体和事件能给出事件逻辑更像草图事件代码最细错误排查覆盖最全偏短能指出冷门原因4. AI 生成 Access 代码最容易翻车的四个细节4.1 保留字和字段名冲突Access 本身有一批保留字例如 Name、Date、Level、User、Password、Description直接用这些作字段名查询可能报语法错误。AI 生成 SQL 时经常不主动避让。我测试“付款日期”字段用的字段名是 PayDate这样没有问题如果直接用 Date一次查询就报错。建议在让 AI 写 SQL 之前先自己确认字段名没有使用保留字。可以给 AI 一段真实表结构让它基于真实字段名写代码。直接让它“猜”表结构很容易生成一个看起来合理但落不了地的方案。4.2 VBA 代码缺少引用和错误处理AI 给 VBA 代码时经常省略“引用项”的说明比如使用 DAO 需要勾选 Microsoft DAO Object Library或者使用 ADO 需要对应 ActiveX Data Objects。如果你在标准模块里使用 CurrentDb、Recordset 而没有提前设置引用低版本 Office 可能直接编译失败。另一个问题是错误处理。AI 生成的代码经常是“理想状态版本”没有考虑表是空的、Excel 里有空行、字段值是 NULL、日期格式不统一这些情况。所以拿到 AI 生成的 VBA 代码后不要直接拿去生产环境先补三层东西错误捕获、空值判断、事务处理。4.3 文件路径、只读状态和权限才是很多“Access 错误”的元凶Access 开发不是只写代码。数据库文件放在共享盘、OneDrive 同步目录、系统盘 Program Files 目录行为会不一样。AI 给的代码通常只处理逻辑不会主动考虑路径权限。比如常听到的“Access denied for user rootlocalhost”本质上和 Access 无关这是把 MySQL 或 MariaDB 的用户名密码搞混了。如果在 Access 项目中看到类似“权限被拒绝”的提示应该先看是不是数据库文件本身处于只读状态、目录没有写权限、或者共享盘锁定了文件。先处理环境再去改代码。很多人在这类问题上反复折腾代码最后发现只是文件被同步工具锁住了。4.4 老版本 Office 和系统环境兼容性AI 训练数据中包含的 Access 知识很多来自老版本给出的代码有时用了 Access 2007 以上的新属性有时又是旧版写法。比如 CurrentDb 在较新版本中没问题但如果你的 Office 版本较老某些对象属性会缺失。如果你在 Windows 桌面运行时遇到进程崩溃、内存访问冲突等问题比如任务管理器里 Access 进程直接退出这类问题通常不是 AI 能解决的。优先检查 Office 补丁是否更新、数据库文件所在磁盘剩余空间是否充足、是否安装了不兼容的第三方加载项。我遇到过一些进程崩溃最后定位到是旧版输入法插件干扰和数据库本身没有关系。遇到这一类问题要把关注点从代码转到运行环境。5. 测试过程中遇到的三类工具侧问题5.1 本地客户端启动报错这次测试过程中ChatGPT 的命令行客户端出现过启动报错提示找不到 codex cli 二进制文件。这类问题首先不要怀疑账号先看安装目录是否在 PATH 环境变量中或者重新执行安装命令。如果提示 config.toml 无法加载通常说明本地配置文件格式有问题建议备份并重命名配置目录重新初始化。Claude 的命令行工具在 Windows 的 PowerShell 里容易报“claude 不是可识别的 cmdlet”。这不是功能问题而是安装后没有把工具所在目录加入 PATH或者安装不完整。解决方式很简单重新打开终端、确认安装目录、手动执行完整路径或者重新安装。排查这类问题时按“环境变量 安装完整性 配置格式”的顺序走比反复重装更有效。5.2 模型选择或配置错误本地使用 Claude 这类工具时经常会遇到“所选模型不存在或无权访问”的提示。这种错误常见原因有三个模型名称写错大小写或标点不一致。登录账号的套餐不包含该模型。本地配置缓存了旧模型列表。建议先运行模型列表命令查看当前可用项再对比配置里的名称不要凭记忆填。如果配置完仍报错可以重启终端或者清掉本地缓存再试。有些第三方模型名称看起来像官方模型实际上只在特定渠道下可用这类情况需要回到工具配置本身去确认。5.3 Web 对话的常见提示Gemini 在 Web 对话中有时候会返回“出了点问题”或无输出。我先检查网络状态和浏览器缓存然后刷新页面重试一般能恢复。如果页面提示功能不可用也可能是当前浏览器、账号类型或使用环境限制这些不是代码问题不能靠改 Access 项目解决。ChatGPT 的 Web 端偶尔出现“token 刷新失败”或“登录过期”通常是登录状态失效退出重新登录即可。这类平台侧问题会影响对比测试的连续性但不影响对模型能力的评估。遇到这种情况不要急着下结论说某个工具不行先把平台状态恢复正常再继续测试。6. 这种场景下我的选择和工作流6.1 三个工具各自适合的环节综合这次实测我给出的分工建议是ChatGPT 放在需求分析和错误排查环节。它在分析一个报错可能原因时覆盖最全适合你手里有一个具体错误信息、需要快速定位方向。Gemini 用来做初稿和快速概览。生成表结构、简单 SQL 时会比较快但要把代码放到生产库之前必须人工补细节。Claude 在连续写代码块、特别是 VBA 和复杂 SQL 时表现最稳。如果你希望少改代码可以优先让 Claude 写主体逻辑再让 ChatGPT 做代码审查。这一分工不是固定不变。模型更新很快不同时间点各自的表现可能会有变化。更合理的方式是同一个任务先用两个工具各生成一版交叉对比再决定用哪一版作为基础。6.2 一套更稳的 AI 辅助开发流程我的建议是分四步走先让 AI 输出完整的表结构设计你在 Access 中把表建好并把真实字段名发给 AI。再让 AI 写 SQL 查询跑通后存入查询对象作为后续 VBA 的数据源。写 VBA 时先让 AI 给出最小版本功能跑通后再加错误处理、空值判断和事务控制。最后让 AI 解释错误信息不要让它猜整个数据库的设计意图。报错时把完整错误文字、操作步骤、涉及字段都贴给它。整个过程中数据库文件一定要在本地先跑通再考虑放到共享目录。很多人喜欢一上来就把 AI 生成的代码放到共享数据库里测试结果一报错其他同事也在用同一个库问题就不好定位了。6.3 不推荐 AI 介入的情况需要强调一点不要在还没有设计清楚需求时直接让 AI 生成整个 Access 系统。如果业务流程本身就有漏洞AI 生成的表结构和代码会把这些漏洞放大。表设计不合理后面所有查询和窗体都要跟着改代价远大于让 AI 重写一段代码。另外涉及大量原数据库数据迁移、关键财务数据变更时先人工审核表关系和更新逻辑再让 AI 辅助写脚本。AI 可以做开发助手但数据库的完整性、备份、回滚计划仍然要人来定。尤其是删除语句、更新语句不要直接拿 AI 给的代码在生产库上试。先在备份库上跑一遍确认影响行数符合预期再考虑正式执行。这次对比跑完之后我最大的感受是ChatGPT、Gemini、Claude 在 Access 数据库开发里不是谁替代谁的关系而是每个环节各有顺手和不顺手的部分。真正能提升开发效率的不是“选一个最强 AI”而是把需求描述、代码生成、错误解释、人工复核拆开分别交给合适的工具。如果你也打算用 AI 辅助 Access 开发我建议先把一个简单的客户表建好跑通一条查询再让 AI 帮你写第一个 VBA 导入脚本。单点跑通之后整条流程会顺很多。
