Access数据库开发实战：ChatGPT、Gemini、Claude对比评测

在实际业务中，Access 数据库开发仍然是一块非常依赖经验的领域。它并不是语法多么复杂，而是 SQL 方言、VBA 对象模型、窗体报表的交互逻辑，以及桌面数据库特有的各种运行时报错混在一起，新手容易卡住，老手靠经验快速绕过。最近我把 ChatGPT、Gemini、Claude 三款主流 AI 对话助手拉进同一个 Access 库存管理项目里，用相同的表结构需求、相同的 SQL 查询任务、相同的 VBA 排错问题做了一组真实使用体验对比。文章不会只给出“谁更强”的结论，而是把每个任务的表现、修改成本、典型报错和排查思路记录下来。如果你也在用 Access 维护业务系统，或者正准备让 AI 帮你写查询和 VBA 代码，这套对比过程和提示词模板可以直接复制到自己的工作流里。

1. 为什么拿 Access 数据库开发做 AI 对比测试

1.1 Access 开发场景的特殊性

Access 常被看作“Excel 的升级版”，但真正进入开发阶段后，它涉及的东西比表格复杂得多。一个稍微完整的 Access 系统，通常包含表设计、查询对象、窗体、报表、宏和 VBA 模块。这里面任何一层都可能出问题：表关系设置错误导致查询结果翻倍，VBA 中忘记判断记录集是否为空导致运行时错误 3021，直接在报表里写复杂 SQL 导致性能缓慢。

这些特点让 Access 成为测试 AI 编程能力的好场景：

• 技术栈偏老，公开语料丰富，AI 对 Access 语法并不陌生。
• 出错点非常具体，容易被复现和验证。
• 修复成本低，适合反复让 AI 修改代码。
• 中文业务需求多，能同时考察 AI 的理解能力。

如果只是让 AI 生成一段 Python 或 Java 代码，三款工具的差距往往不明显。放到 Access 这个“方言味很重”的场景里，模型的差异就会被放大，尤其是 SQL 方言、VBA 对象模型和排错思路这几个维度。

1.2 三款工具参与对比的方式

本次对比不是单纯“问一句话”，而是把 AI 当作一名可以连续对话的开发助手。每轮任务都使用相同的业务背景和提示词，记录三轮结果，重点看稳定性。

• ChatGPT 采用网页对话方式，同时也覆盖 Codex CLI 的常见问题。
• Gemini 采用网页对话方式，个别任务通过 API 补充验证。
• Claude 采用网页对话方式，同时记录 Claude Code 在本地开发环境中的表现。

注意：这三款工具的可访问性和可用的模型版本会随时间变化，不同地区、不同账号的体验可能有差异。下面记录的是本次任务集下的抽样结果，不代表模型在所有场景下的绝对能力。

1.3 对比的评分口径

评分不只关注“第一次回答对不对”，而是看完整使用成本。如果第一版代码不能跑，但修改一次后能用，也算可用；如果反复强调 Access 方言后仍然生成 SQL Server 语法，则算可运行性差。

评分维度包括：

• 正确性：字段、表关系、语法是否准确。
• 可运行性：代码放到 Access/VBA 环境后能否直接执行。
• 解释质量：错误说明是否清晰，新手能否看懂。
• 修改成本：需要几次追问、多少次修正才能达到可用状态。
• 中文理解：中文业务需求是否能被准确翻译成字段和逻辑。

这样评分，比单纯比较“谁生成的代码更长”更有实战意义。

2. 对比测试环境、任务集和评分口径

2.1 测试用业务背景

为了模拟真实场景，我设计了一个小型仓库管理系统作为测试项目。项目使用.accdb格式，不连接外部 SQL Server，所有数据都存放在 Access 本地数据库中。

初始表结构如下：

需求是新增入库单和出库单两张业务表，然后实现以下功能：

1. 新增入库表和出库表，字段包含日期、数量、单价、供应商，并与产品表关联。
2. 统计每个产品近 30 天的入库总数、出库总数。
3. 编写 VBA 过程，把临时表中的入库数据批量更新到库存表。
4. 使用 ADO 参数化查询删除某日期之前的入库记录。
5. 对一段报 3021 错误的 VBA 代码进行解释和修复。

这套任务覆盖了 Access 开发中最常见的五类工作：表设计、查询 SQL、VBA 数据操作、ADO 参数化、排错修复。

2.2 Access 版本和开发环境

测试使用的环境是 Windows + Microsoft Access 2016 及以上版本。Access 本身的版本会影响部分对象名称和默认设置，例如新版中的Date()函数行为、CurrentDb与CodeDb的差异。实测前建议先确认自己的 Access 版本，避免把不同版本的差异误判为 AI 生成的错误。

如果要在本地跑通 AI 生成的 VBA 代码，推荐先做两项准备：

• 在 Access 中启用“信任对 VBA 项目对象模型的访问”。
• 测试时把数据库副本放在本地目录，不要直接在共享盘或远程桌面上运行。

这两点能避免很多“代码看起来没问题，但每次运行都报错”的干扰。

2.3 统一的任务提示词

对比时使用统一前缀，确保三款工具拿到相同上下文：

你现在是一名熟悉 Microsoft Access 桌面数据库开发的工程师。 项目使用 .accdb 格式，后台没有 SQL Server。 请在所有 SQL 中使用 Access 支持的语法，不要使用 datetime、IDENTITY、N'...' 等 SQL Server 写法。

这个前缀很重要。直接让 AI 写 Access SQL，得到的可能是 T-SQL；声明 Access 方言后，正确率会明显提升。后续任务都在这段前缀之后追加具体需求。

2.4 对比结果的记录方式

每轮测试记录三样东西：第一次输出是否可用、需要修改几次、典型错误是什么。通过这种“反复追问”的方式，可以判断工具是否真正理解 Access 的开发场景，而不只是背了一段代码。

3. 五个 Access 任务里的真实表现记录

3.1 任务一：生成入库表和出库表结构

提示词：

现有 tblProduct(ProductID, ProductName, CategoryID) 和 tblSupplier(SupplierID, SupplierName)。 需求：新增入库表和出库表，记录每笔出入库。 要求：给出 Access 支持的字段类型，主键使用自动编号，外键加索引，提供创建表的 SQL。

三款工具第一轮都能生成基本可用的表结构，差别主要在字段细节上。

ChatGPT 生成的版本最完整，除了常规的 InboundID、ProductID、InboundDate、InboundQty 之外，还补充了 UnitPrice、Remark、CreateBy 等字段，并对外键字段加了索引。它还会额外提示：如果数量字段需要参与汇总计算，不要使用“文本”类型；单价字段在 Access 中使用“货币”类型比“数字”更合适。

Gemini 对中文需求的还原很自然，会把“顺便记录经办人”这类隐含信息补进去。但它第一轮把AUTOINCREMENT写成了IDENTITY(1,1)，需要第二次追问才改成 Access 的自动编号语法。这说明它不是不熟悉 Access，而是在混合多种数据库知识时优先输出了 SQL Server 写法。

Claude 的 DDL 生成最“克制”，只生成需求点名的字段，不会随意扩展。它给出的字段类型描述非常准确，例如“长整型”“货币”“短文本”，很适合给不太懂类型的业务人员看。不过它同样需要在提示词里强调“Access 方言”才能避免误用NVARCHAR。

第一轮总结：三个工具都能完成表设计，但 ChatGPT 的默认输出最接近“可用状态”，Gemini 需要一次修正，Claude 正确率高但字段需要人工补充扩展需求。

3.2 任务二：统计近 30 天出入库数量

提示词：

统计每个产品近 30 天的入库总数和出库总数，以“产品编号、产品名称、入库总量、出库总量”四列输出。

这个任务的关键是验证 Access SQL 的方言细节。Access 中日期函数是Date()，条件表达式常用IIf，而不是CASE WHEN。如果 AI 写成GETDATE()或ISNULL()，在 Access 查询对象中无法直接执行。

ChatGPT 生成的 SQL 在第二轮修正后可用：

SELECT p.ProductID, p.ProductName, SUM(IIf(i.InboundDate >= Date() - 30 And i.InboundDate <= Date(), i.InboundQty, 0)) AS Inbound30, SUM(IIf(o.OutboundDate >= Date() - 30 And o.OutboundDate <= Date(), o.OutboundQty, 0)) AS Outbound30 FROM (tblProduct AS p LEFT JOIN tblInbound AS i ON p.ProductID = i.ProductID) LEFT JOIN tblOutbound AS o ON p.ProductID = o.ProductID GROUP BY p.ProductID, p.ProductName;

这里有一个非常重要的坑：当入库表和出库表同时与产品表 LEFT JOIN 时，会产生笛卡尔积的中间结果。某个产品有 3 条入库记录和 2 条出库记录，汇总行会变成 6 条中间行，最终 SUM 值翻倍。

三款工具在第一轮都没有主动说明这个数据膨胀问题。追问后才各自给出了优化方案：先分别做子查询汇总，再 JOIN。

推荐优化后的写法：

SELECT p.ProductID, p.ProductName, Nz(in30.TotalInbound, 0) AS Inbound30, Nz(out30.TotalOutbound, 0) AS Outbound30 FROM (tblProduct AS p LEFT JOIN ( SELECT ProductID, SUM(InboundQty) AS TotalInbound FROM tblInbound WHERE InboundDate >= Date() - 30 GROUP BY ProductID ) AS in30 ON p.ProductID = in30.ProductID) LEFT JOIN ( SELECT ProductID, SUM(OutboundQty) AS TotalOutbound FROM tblOutbound WHERE OutboundDate >= Date() - 30 GROUP BY ProductID ) AS out30 ON p.ProductID = out30.ProductID;

这个案例说明，判断 AI 生成的 SQL 是否可用，不能只看语法，还要看数据语义。生成代码后自己跑一遍真实数据永远是最可靠的验证方式。

3.3 任务三：VBA 批量更新库存并支持事务

提示词：

写一段 Access VBA，遍历临时表 tblTempInbound 中的入库记录，把每个产品的数量累加到 tblStock 中。 要求使用 DAO 事务，发生错误时回滚，并在界面上提示失败原因。

这个任务考察的是 VBA 对象模型。三款工具都能写出基本逻辑，区别表现在错误处理和对边界情况的考虑。

ChatGPT 的代码完整度最高，包含BeginTrans、CommitTrans、Rollback，并判断记录集是否为空，避免在 EOF 上读字段。以下是经过整理后的典型版本：

Sub BatchUpdateStock() Dim db As DAO.Database Dim rsTemp As DAO.Recordset Dim rsStock As DAO.Recordset Dim wrk As DAO.Workspace Set db = CurrentDb Set wrk = DBEngine.Workspaces(0) Set rsTemp = db.OpenRecordset("SELECT ProductID, InboundQty FROM tblTempInbound", dbOpenDynaset) If rsTemp.EOF Then MsgBox "临时表没有数据。" Exit Sub End If wrk.BeginTrans On Error GoTo TransError Do Until rsTemp.EOF Set rsStock = db.OpenRecordset( _ "SELECT * FROM tblStock WHERE ProductID=" & rsTemp!ProductID, _ dbOpenDynaset) If rsStock.EOF Then rsStock.AddNew rsStock!ProductID = rsTemp!ProductID rsStock!StockQty = rsTemp!InboundQty rsStock.Update Else rsStock.Edit rsStock!StockQty = rsStock!StockQty + rsTemp!InboundQty rsStock.Update End If rsStock.Close rsTemp.MoveNext Loop wrk.CommitTrans MsgBox "库存更新完成。" rsTemp.Close Set rsStock = Nothing Set rsTemp = Nothing Set db = Nothing Exit Sub TransError: wrk.Rollback MsgBox "更新失败，已回滚：" & Err.Description Set rsStock = Nothing Set rsTemp = Nothing Set db = Nothing End Sub

Gemini 对“事务”的理解很到位，但生成的第一版代码没有考虑“库存表中还没有该产品”的情况，直接调用rsStock.Edit，会得到“当前记录不存在”的错误。我要求补充AddNew分支后才完整。

Claude 的代码风格偏向防御式，它会主动添加记录集关闭逻辑，并建议在循环中及时MoveNext，避免死循环。但它第一版把dbOpenDynaset写成了RecordsetTypeConstants.dbOpenDynaset，虽然不是致命错误，却不够直接。

这个任务的核心结论是：VBA 生成能力三家都在线，但“没有库存记录时的新增分支”和“事务回滚后的对象清理”是 AI 容易漏掉的两点，人工审查时必须重点检查。

3.4 任务四：ADO 参数化删除旧数据

提示词：

用 ADO 写一段 VBA，删除 tblInbound 中 InboundDate 早于指定日期的记录。 要求必须使用参数化查询，不能通过字符串拼接日期。

这个任务的价值在于安全性和性能。参数化查询能避免日期格式在不同系统区域设置下的解析错误，也能降低把用户输入直接拼进 SQL 带来的风险。

三款工具都能写出基本结构，ChatGPT 和 Claude 的版本几乎可以直接运行：

Sub DeleteOldInbound(ByVal dtBefore As Date) Dim cn As ADODB.Connection Dim cmd As ADODB.Command Dim prm As ADODB.Parameter Set cn = CurrentProject.Connection Set cmd = New ADODB.Command With cmd .ActiveConnection = cn .CommandText = "DELETE FROM tblInbound WHERE InboundDate < ?" .CommandType = adCmdText Set prm = .CreateParameter("dtBefore", adDate, adParamInput, , dtBefore) .Parameters.Append prm .Execute End With Set prm = Nothing Set cmd = Nothing Set cn = Nothing MsgBox "已删除 " & cmd.RecordsAffected & " 条记录。" End Sub

这里要注意一个细节：cmd.RecordsAffected在Execute之后读取才有意义。如果把.Execute的结果赋给一个 Recordset，删除操作的返回值含义会不同。Claude 在回答中主动提示了这一点，解释质量更高。

Gemini 第一版使用的是Parameters.Append cmd.CreateParameter(...)，但在设置ActiveConnection之前就执行了参数追加，导致运行时报“对象无效”。调整顺序后代码可用。

3.5 任务五：排查 VBA 运行时错误 3021

提示词：

下面这段 Access VBA 偶尔弹出“运行时错误 3021”，请说明原因并给出修复代码： Dim rs As DAO.Recordset Set rs = CurrentDb.OpenRecordset("SELECT * FROM tblProduct WHERE ProductID=" & Me.txtProductID) rs.MoveFirst MsgBox rs!ProductName

运行时错误 3021 的全称是“当前记录不存在”，本质是从空记录集读取字段。当Me.txtProductID没有匹配记录时，rs已经是空记录集，此时访问rs!ProductName就会触发错误。

ChatGPT 的回复中规中矩，先解释了 3021 的含义，再给出判断EOF的修复方案。Gemini 的回答更口语化，直接指出“先判断有没有记录，再读字段”，对新手最容易理解。Claude 不仅给出修复代码，还会额外提醒：如果一次查询中涉及多行结果，需要在循环中同时判断BOF和EOF，避免循环边界问题。

推荐修复方式：

Dim rs As DAO.Recordset Set rs = CurrentDb.OpenRecordset( _ "SELECT * FROM tblProduct WHERE ProductID=" & Val(Me.txtProductID), _ dbOpenDynaset) If rs.EOF Then MsgBox "未找到该产品。" Else rs.MoveFirst MsgBox rs!ProductName End If rs.Close Set rs = Nothing

这个任务最能体现三款工具的差异：代码生成只是第一步，能否把错误原因讲清楚，才决定开发者能否真正学会。Claude 在解释类任务上优势明显。

4. 三款工具的定位差异与选型参考

4.1 总体评分对比

下面的分数仅代表本次五个任务三轮测试后的整理结果，目的是给你一个直观参考，而不是对模型能力的定论。

ChatGPT 的优点是稳定，连续三轮生成结果差异小，Access SQL 方言的贴合度最高。Gemini 的中文需求解读最自然，但第一版代码的“SQL Server 污染”出现频率明显更高。Claude 的排错解释和代码风格最好，但需要额外指定 Access 方言，并且部分对象常量写法偏冗长。

4.2 使用场景选型表

4.3 一个容易被忽略的差异：工具形态

很多人对比 AI 工具时只看网页对话，忽略了一个事实：真正影响开发效率的往往是使用形态。

ChatGPT 生态中的 Codex CLI 可以直接在终端里读取项目文件，也可以替代部分批量编码工作。Claude Code 同样可以执行终端命令、读取文件和修改代码。Gemini 的重点在长上下文和与 Google 产品的联动，作为“需求分析助手”比“终端编程助手”更顺手。

所以选型不应该简单回答“哪个更好”，而是要根据当前任务是“写一段代码”还是“扫描一批文件”。如果你是 Access 项目的维护者，最实际的组合可能是：网页端做设计和排错，CLI 工具做批量文件分析和重命名类操作。

5. 可以直接复制到项目里的提示词模板

5.1 表结构设计模板

你现在是 Microsoft Access 数据库开发专家，项目使用 .accdb 格式。 业务背景：... 现有表：... 需求：新增一张表，记录... 要求： 1. 字段类型只用 Access 支持的类型（短文本、长文本、数字、日期/时间、货币、是/否、OLE 对象、附件、自动编号）。 2. 主键使用自动编号。 3. 所有外键字段建议加索引。 4. 直接给出 CREATE TABLE 语句。 5. 不要使用 SQL Server 或 MySQL 的语法。

使用这个模板后，AI 不太容易跑偏。如果输出的字段仍包含NVARCHAR或DATETIME，可以追加一句“请把以上语法改成 Access 查询支持的形式”，而不是重新描述需求。

5.2 SQL 查询模板

在 Access 中写一个查询，完成下面的统计： 业务字段：... 统计口径：... 输出列：... 要求： 1. 使用 IIF 而不是 CASE WHEN。 2. 日期条件使用 Date()。 3. 不允许使用 T-SQL。 4. 如果存在多表 JOIN 导致的重复统计，请先使用子查询聚合再 JOIN。

最后一条要求是从实测中得出的教训。AI 默认生成的 JOIN 汇总容易产生笛卡尔积，显式声明“先聚合再 JOIN”能大幅提高 SQL 的一次可用率。

5.3 VBA 代码生成模板

请编写 Access VBA 代码，完成以下需求： 功能：... 数据表：... 输入：... 输出：... 要求： 1. 使用 DAO 或 ADO 时，显式声明对象类型。 2. 如果操作可能有失败风险，使用事务 BeginTrans 和 Rollback。 3. 遍历记录集前必须判断 EOF，循环内必须调用 MoveNext。 4. 完成后释放 Recordset、Command、Connection 等对象。 5. 代码中添加必要注释，解释每一步在做什么。

这段提示词把 Access 开发中常见的十几类问题直接埋进去了，AI 生成的代码质量会明显高于裸提问。

5.4 排错模板

下面这段 Access VBA 代码运行时报错“错误编号：...，描述：...”。 请按顺序回答： 1. 错误触发的原因。 2. 代码中哪一行最容易触发该错误。 3. 给出修复后的完整代码。 4. 说明以后如何避免同类问题。 代码： ...

排错时千万不要只把错误代码发给 AI。把表结构和相关 SQL 查询一起贴上去，才能让 AI 理解数据形状。如果涉及客户数据，先脱敏，去掉真实姓名、手机号、金额等敏感字段。

6. 工具启动和配置报错排查清单

在真实开发过程中，很多同学还没开始用 AI，就先被工具安装和启动问题卡住。这一部分整理了三类高频问题，分别来自 ChatGPT 生态、Claude Code 和 Gemini。

6.1 Codex CLI 启动失败类报错

现象一：启动时提示chatgpt failed to start. unable to locate the codex cli binary. set codex cli path

这个报错的意思是系统找不到 codex 可执行文件，或者安装目录没有被加到 PATH 中。检查步骤：

1. 在终端执行where codex或which codex，确认可执行文件是否存在。
2. 如果命令找不到，检查安装目录是否存在 codex 二进制文件。
3. 把安装目录添加到系统 PATH，重新打开终端。
4. 如果工具本身提供CODEX_CLI_PATH或类似环境变量，手动指向二进制文件。

现象二：报错无法加载config.toml，并提示需要修复。

config.toml是命令行工具的配置文件，加载失败通常有三个原因：

• 文件路径不对，工具没有在预期位置找到文件。
• TOML 格式错误，例如缺少引号、多了中文标点，或编码不是 UTF-8。
• 配置的模型名称不被当前服务支持，例如把底层配置写成了不存在的模型名。

处理方式：备份原文件后，写一个最小化配置，只保留必填项，再逐步增加参数。不要直接删除配置文件，否则会丢失登录状态和模型设置。

6.2 Claude Code 安装后命令不可用

现象一：在 PowerShell 中执行claude，提示无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称，或命令行提示“不是内部或外部命令”。

这是典型的 PATH 问题。Claude Code 通过 npm 安装后，可执行文件会放在 npm 全局 bin 目录中。如果这个目录不在当前用户的 PATH 里，终端就找不到claude命令。

检查方式：

npm config get prefix

把输出目录下的bin或对应路径加入 PATH。例如 prefix 是C:\Users\username\AppData\Roaming\npm，就把这个目录加入系统环境变量，然后重新打开终端。

现象二：新用户注册后看到unfortunately, claude is not available to new users right now。

这个提示是服务端对账号状态或区域可用性的限制，不是本地安装的问题。先检查账号是否完成手机或邮箱验证，排除网络可达性后，如果仍然出现，说明当前账号暂未获得访问资格。这种情况下重新安装或修改配置没有意义。

6.3 Gemini 相关异常提示

现象一：浏览器提示gemini in chrome isn't available。

这个提示通常和浏览器版本、登录状态或者功能本身的灰度开放有关。处理思路是先换用独立页面或更新浏览器，再检查 Google 账号能否正常访问服务。

现象二：API 调用报错或模型返回内容为空。

不同模型命名、配额和地区限制都可能影响 API 调用。严格来说，网页版和 API 是两条独立链路，网页版可用不代表 API 密钥必然可用。遇到问题先查 API 状态页、账号配额和模型名称是否拼错。

6.4 哪些问题其实出在提示词而不是工具

这一部分在实测中非常明显。不少“AI 生成代码不能用”的情况，源头是提示词没有说明数据库方言和运行环境。

同一个问题，不同提问方式得到的结果差别很大：

如果你发现工具表现不稳定，先不要急着换工具，试着把提示词里的“Access 方言声明”和“必须包含的容错逻辑”补全，再重测一轮。

7. 结论：把 AI 接入 Access 开发工作流的建议

7.1 我的最终选型建议

从本次实测来看，三款工具都能完成 Access 数据库开发中的基础任务，但各有擅长的环节。

如果项目时间紧、需要快速拿到可运行的 Access SQL 和表结构，ChatGPT 系的稳定性更有保障。如果需求本身是中文长文本，需要先梳理业务字段和表关系，Gemini 的理解能力更顺手。如果已经有一批 VBA 代码经常报错，需要解释原因并重写，Claude 的排错体验最好。

不要只锁定一个工具。真实工作流中，三个工具可以分工：

1. 需求梳理：交给 Gemini，把中文需求转成字段清单和表关系草图。
2. 表结构和 SQL 生成：交给 ChatGPT，生成第一版可运行代码。
3. VBA 代码重构和排错：交给 Claude，解释错误并写出防御式代码。
4. 终审和备份：全部由人工完成，在数据库副本上验证后再上正式环境。

这套流程利用了每款工具的强项，也把风险控制在了人工环节。

7.2 接入 AI 后仍要守住的红线

Access 往往承载着真实业务数据，使用 AI 辅助开发时，有几条约束必须明确：

第一，不要直接把包含真实客户信息的数据库丢给外部 AI。测试时复制结构、脱敏数据，只保留字段名和表关系即可。

第二，AI 生成的 SQL 和 VBA 不能直接在生产数据库上执行。先复制一份.accdb副本，在副本里验证结果。重点检查 DELETE 和 UPDATE 语句是否缺少 WHERE 条件。

第三，VBA 中涉及写操作时，必须检查是否有事务保护。AI 生成的代码经常忘记Rollback，一旦批量更新到一半报错，数据处于半更新状态，恢复成本很高。

第四，最终代码要有人工审查。AI 能把代码写出来，但只有熟悉业务的人能判断“为什么不能用笛卡尔积汇总”“为什么库存表可能没有该产品记录”。

7.3 对新手最有价值的练习方式

如果你是 Access 开发新手，不建议直接拿生产项目训练 AI。可以创建一个只有三张表的微型进销存数据库，按照下面的顺序练习：

1. 先让 AI 生成建表 SQL，人工检查字段类型。
2. 再让 AI 写统计查询，观察是否存在 JOIN 导致的数量翻倍。
3. 然后让 AI 写 VBA 批量更新，故意制造空记录和错误数据，看代码是否回滚。
4. 最后模拟常见运行时错误，让 AI 解释原因并修复。

每完成一个任务，记下“第一版不可用、追问后可用、完全不可用”三种结果。连续十几个任务后，你就会清楚每款工具的脾气，也能积累一套属于自己的提示词模板。

7.4 下一步可以扩展的方向

Access 不会消失，很多中小型业务系统仍然依赖它运行。AI 的介入让这个老技术栈获得了新的生产力。下一步可以尝试的方向包括：

• 用 Codex CLI 或 Claude Code 批量扫描现有 Access 项目中的 VBA 模块，分析重复代码和潜在错误。
• 让 AI 帮你把 Access 数据库迁移到 SQL Server 或 MySQL，生成字段映射和转换脚本。
• 结合 Access 的窗体设计，让 AI 生成按钮事件、下拉框联动、报表数据源等常见交互代码。
• 把日常维护中遇到的运行时报错整理成问题清单，配合 AI 做知识库，以后排错直接查。

实测中最重要的收获不是“哪款工具最强”，而是“如何用一套稳定的提示词和验证流程，让每款工具都发挥最大价值”。在 Access 开发这个具体场景里，工具之间的差距远小于使用方式之间的差距。把方言声明、事务保护、空值判断、备份验证这些开发习惯写进提示词，你会发现任何一款主流 AI 都能成为合格的项目助手。