一、前言

当下AI辅助写SQL工具层出不穷，但路线各有不同。其中一类是IDE集成式AI编程工具——它们嵌入开发环境，能读取项目本地文件、理解表结构、依据上下文生成代码。CodeBuddy（腾讯云AI代码助手）即属此类，可作为独立IDE使用，也可作为VS Code或JetBrains插件安装。

然而，直接让工具输出原生多层嵌套SQL，可读性差、审计困难，业务逻辑稍有变化就要重新生成，难以做到“放心交付”。

当我们把目光从“让AI写最终SQL”转向“让AI写结构化中间脚本”时，一条更稳健的落地路径出现了：CodeBuddy生成SQLazy的分步脚本（.nspl），再用后者负责调试并编译生成最终SQL。

本文完整拆解这套工作流的实操步骤、交互话术、工具配合方法，并用三组从易到难的业务案例展示如何把AI辅助能力落实到生产级数据查询中。

二、两大工具核心互补能力

CodeBuddy核心能力

CodeBuddy是腾讯云AI代码助手，在本工作流中发挥三个关键作用：

读取项目本地知识库

CodeBuddy能读取项目根目录的.codebuddy/CODEBUDDY.md——这是一个“全局规约文件”，集中定义了全部表结构、输出流程、SQLazy格式规范、硬性约束，并声明了所有SQLazy函数/功能文档的加载路径。用户在聊天框通过/sqlazy规划 业务需求触发任务时，AI以CODEBUDDY.md为核心规约，以函数/和功能/下的文档为语法字典，以自然语言需求为业务口径，三者结合生成合规的SQLazy脚本。

主动提问消除需求歧义

面对复杂需求（如“向前看”时间回溯、快照覆盖范围），CodeBuddy会在动手前主动向人确认关键边界（日期范围、取数逻辑、空值处理、同一组合是否存在多条记录等）。这极大降低了“AI自以为是”带来的返工成本。

定向输出合规SQLazy分步命令

CodeBuddy被约束为只输出符合SQLazy语法规范的.nspl脚本（三列制表符格式、每步单功能、语句不换行），而不是直接生成原生SQL。这相当于把AI的输出限定在一个“可读、可审、可回放”的中间层。

SQLazy核心承载价值

SQLazy配有专属IDE用于编写与执行.nspl脚本。其核心价值在于：

单步单一逻辑，业务语义直观

以分段 CL; 变小; 命名 上涨段为例——在原生SQL中，实现“收盘价上涨则归入同一段，下跌则新开一段”的逻辑，需要用到LAG窗口函数取前值、CASE WHEN判断拐点、嵌套SUM()OVER()生成段号，写出来往往是一长串嵌套窗口函数。而SQLazy只需一行分段指令，业务意图一目了然。整份脚本读下来，像是在读业务操作清单，而非解析SQL语法树，这才是“人工逐行审核门槛极低”的真实含义。所谓“分层”，指每一行即一步，上一步的输出是下一步的输入，逻辑完全摊开。

一份脚本，多数据库编译

.nspl脚本编译后可自动生成标准SQL（支持MySQL、PostgreSQL、Oracle等），彻底告别“切换数据库要重写SQL”的噩梦。

内置小数据验证环境

SQLazy专属IDE支持导入手工测试数据集，分步运行并比对预期结果，做到“问题在源头发现，不在生产层暴露”。

三、操作流程

流程是整套工作法的骨架，后续所有案例均按此顺序执行。

3.1 前置知识库准备

本工作区采用以下目录结构：

project_root/

├── .codebuddy/

│ ├── CODEBUDDY.md # 核心规约：表结构、输出流程、格式规范、硬性约束、函数/功能加载路径

│ └── commands/

│ └── sqlazy规划.md # 命令入口：/sqlazy规划触发，继承CODEBUDDY.md全部规则

├── nsql/ # 交付目录：每次任务产出的.nspl脚本文件存放于此

├── 函数/ # 89个函数文档（由CODEBUDDY.md自动加载）

└── 功能/ # 19个功能文档（由CODEBUDDY.md自动加载）

在CodeBuddy中打开该项目目录（独立IDE直接打开文件夹；VS Code/JetBrains插件则打开对应项目），AI即可自动索引全部上下文。

3.2 固定标准交互方式

触发命令：在聊天框输入/sqlazy规划加上业务需求。

/sqlazy规划 计算股票代码为100046的股票，最长连续上涨了多少天？

该命令触发后，CodeBuddy自动继承CODEBUDDY.md中的全部规则，无需重复声明。

完整需求输入时，建议把涉及的表字段、关联关系、分组维度、时间范围一次性写清楚。例如：

/sqlazy规划 对发票表i（含字段invoiceid、amount、projectid）与项目表p（含字段id、projectid、accountcode）以projectid为关联键进行关联，为关联结果新增分账字段splitamount，实现按项目下账户数量分摊金额且总额守恒的分账逻辑：以projectid为分组维度，将对应发票的amount金额分配给该项目下的所有账户；组内按accountcode升序排序后，第2至第N个账户的splitamount按「amount/账户总数」计算并保留2位小数；排序后的第1个账户承担尾差，其splitamount为「原发票amount减去其余账户splitamount之和」，保证同一发票对应项目下所有账户的splitamount总和与原发票amount完全一致。

3.3 接收CodeBuddy输出SQLazy分步脚本

CodeBuddy接收到需求后，直接输出符合规范的.nspl脚本。示例：

t1	stock	筛选 (CODE 等于 100046)
t2		排序 DT
t3		分段 CL; 变小; 命名 上涨段
t4		汇总 计数 命名 段天数; 分组 上涨段
t5		汇总 段天数 最大 命名 最长连续上涨天数

接收后即可进入验证环节。

3.4 用测试数据集验证

这是整条链路中最关键的验证动作，所有问题（语法错误、逻辑偏差、边界遗漏）都会在这一步暴露：

针对当前需求构造少量有代表性的测试数据，手工计算出期望结果；

在SQLazy专属IDE中导入测试数据，逐条运行脚本的各步，对比中间结果与手工期望；

若发现偏差，有两种修正路径可选：

手工直接修改：若问题明确（如判据用错、分组字段遗漏），直接在SQLazy专属IDE中修改脚本，重新运行验证。适合逻辑清晰、改动范围小的情况。

反馈CodeBuddy继续修正：将测试数据集、期望结果与实际错误结果一并发回CodeBuddy，附上问题描述，让AI重新生成修正后的脚本。适合逻辑复杂、需要重新推理的情况，或需要保留完整对话记录供后续审计。

两种方式各有适用场景，实践中根据问题复杂度和个人习惯选择即可。

修正完成后，重新运行验证。

3.5 编译生成生产SQL

当测试数据验证通过后，在SQLazy专属IDE中点击“编译”，选择目标数据库类型（MySQL/PostgreSQL/Oracle等），即可一键生成可上线的SQL脚本。此时AI初稿经过小数据验证，已具备投产条件。

四、案例实操演示

以下三个案例从易到难，完整复现从需求到验证的全过程。

案例一：股票最长连续上涨天数统计

需求：

/sqlazy规划 计算股票代码为100046的股票，最长连续上涨了多少天？

执行过程：

CodeBuddy按核心规约输出如下脚本：

t1	stock	筛选 (CODE 等于 100046)
t2		排序 DT
t3		分段 CL; 变小; 命名 上涨段
t4		汇总 计数 命名 段天数; 分组 上涨段
t5		汇总 段天数 最大 命名 最长连续上涨天数

人工核对：分组字段正确、排序方向正确、分段条件“变小”符合“连续不跌即同一上涨段”的业务定义。

在SQLazy专属IDE中，打开这个文件，直接运行验证，编译生成对应数据库SQL。

结论：简单统计类需求，AI一次过，仅需人工核对分组字段和排序方向。

案例二：发票按账户分摊、总额守恒

需求：

/sqlazy规划 对发票表i（含字段invoiceid、amount、projectid）与项目表p（含字段id、projectid、accountcode）以projectid为关联键进行关联，为关联结果新增分账字段splitamount，实现按项目下账户数量分摊金额且总额守恒的分账逻辑：以projectid为分组维度，将对应发票的amount金额分配给该项目下的所有账户；组内按accountcode升序排序后，第2至第N个账户的splitamount按「amount/账户总数」计算并保留2位小数；排序后的第1个账户承担尾差，其splitamount为「原发票amount减去其余账户splitamount之和」，保证同一发票对应项目下所有账户的splitamount总和与原发票amount完全一致。

执行过程：

AI收到需求后，主动推导出守恒公式：

第1账户分摊额 = amount - (N-1) * round(amount/N, 2)

其余账户 = round(amount/N, 2)

输出脚本：

t1	i	拼接 projectid; 关联表 p; projectid; 拼接列 accountcode; 内连接
t2		计算列 accountcode, 计数, 命名 acc_cnt; 分区 invoiceid
t3		排名 accountcode; 命名 rk; 分区 invoiceid
t4		计算列 条件(rk = 1 则 (amount - (acc_cnt - 1) * round(amount / acc_cnt, 2)) 否则 round(amount / acc_cnt, 2)), 命名 splitamount
t5		导出表 invoiceid, amount, projectid, accountcode, splitamount

人工核对：拼接中显式写出了关联列名，分组维度用invoiceid保证每张发票独立分摊，正确。

在SQLazy专属IDE中完成验证，编译生成对应数据库SQL。

结论：AI能自主推导守恒公式并分层实现，人工只需核对关联键和分区字段。

案例三：用户每日状态时序快照

需求：

/sqlazy规划 根据当前状态表和状态变化历史表，为2024-03-01至2024-03-14内的每一天生成每个user_id、organisation_id的状态快照。organisation_user_link表保存当前状态，包括status_id、stopped_reason_id和dossier_created；organisation_user_link_status_history表记录状态变化历史，history_time表示状态变化生效时间。对于2024-03-01至2024-03-14内的每一天，status_id和stopped_reason_id应表示该日期对应的有效状态；如果当天存在状态变化，则使用当天状态变化记录中的值；如果当天不存在状态变化，则使用该日期之后最近一次状态变化记录中的值；如果该日期之后不存在可用的历史状态，则使用organisation_user_link表中的当前状态。最终输出date、user_id、organisation_id、status_id、stopped_reason_id和dossier_created，结果按照date降序排序，同一天内按照user_id、organisation_id升序排序。

执行过程：

CodeBuddy先主动提出三个澄清问题（向前看还是向后看？覆盖哪些组合？同日多条变化怎么处理？），人回答后生成如下初稿：

t_dates		列表 头 2024-03-01, 尾 2024-03-14; 间隔 1; 天; 命名 d
t_link_combos	organisation_user_link	导出表 user_id, organisation_id; 唯一值
t_hist_combos	organisation_user_link_status_history	导出表 user_id, organisation_id; 唯一值
t_combos	t_link_combos	集合 并; t_hist_combos
t_snap	t_dates	扩展 t_combos 拼接列 user_id, organisation_id
t_hist	t_snap	拼接 user_id, organisation_id; 关联表 organisation_user_link_status_history;user_id, organisation_id 拼接列 history_time, status_id 命名 h_status_id, stopped_reason_id 命名 h_stopped_reason_id; 条件 (history_time >= d@)
t_pr	t_hist	计算列 条件(history_time < (d 偏移 1 日) 则 0 否则 1), 命名 pr
t_best	t_pr	排名 pr, history_time; 前; 1; 分区 d, user_id, organisation_id
t_link	t_best	拼接 user_id, organisation_id; 关联表 organisation_user_link;user_id, organisation_id 拼接列 status_id 命名 l_status_id, stopped_reason_id 命名 l_stopped_reason_id, dossier_created
t_final	t_link	计算列 条件(h_status_id 非空 则 h_status_id 否则 l_status_id), 命名 status_id; 条件(h_stopped_reason_id 非空 则 h_stopped_reason_id 否则 l_stopped_reason_id), 命名 stopped_reason_id
t_out	t_final	导出表 d 命名 'date', user_id, organisation_id, status_id, stopped_reason_id, dossier_created
t_sorted	t_out	排序 'date' 降序, user_id, organisation_id

用以下测试数据验证。当前状态表 organisation_user_link：

id	user_id	organisation_id	status_id	stopped_reason_id
1	3	73	2
2	9	1199	4	5

历史变化表 organisation_user_link_status_history：

history_time	user_id	organisation_id	status_id	stopped_reason_id
2024-03-11 12:05:30	3	73	1
2024-03-08 11:15:35	3	73	3
2024-03-05 13:25:40	3	73	4	3
2024-03-13 02:07:10	9	1199	1
2024-03-11 02:07:10	9	1199	2

实际执行结果（节选，仅展示出问题的行）：

date	user_id	organisation_id	status_id	stopped_reason_id
2024-03-13	9	1199	1	5
2024-03-12	9	1199	1	5
2024-03-11	9	1199	2	5
2024-03-10	9	1199	2	5

这里期望这些行的 stopped_reason_id 为空，因为历史记录中本来就是空的。但实际结果却显示当前表的兜底值 5。

经审核，问题出在两处逻辑设计：

问题一：候选过滤位置不当

t_hist中直接写了：条件 (history_time >= d@)，将日期条件放在了拼接步骤内部。拼接的条件是对关联后的整行结果做过滤，当某天某组合没有匹配的历史记录时，左连接会生成一行空记录，但随后被该条件过滤掉，导致这些行整行消失。

修正：将日期条件移出拼接，改为新增t_cand步骤，用计算列打标记：

步骤	改前	改后
t_hist	拼接 ...; 条件 (history_time >= d@)	拼接 ...（移除条件，拼接全部历史）
新增 t_cand	—	计算列 条件(history_time >= d 则 1 否则 0), 命名 is_cand
t_best	排名 pr, history_time; 前; 1; 分区 d, user_id, organisation_id	排名 is_cand 降序, history_time 升序; 前; 1; 分区 d, user_id, organisation_id

问题二：最终取值判据用错

t_final中写成了：

条件(h_stopped_reason_id 非空 则 h_stopped_reason_id 否则 l_stopped_reason_id)

当历史记录存在但stopped_reason_id为空时，判据把“字段为空”误判为“没有历史”，错误回退到当前表值。

修正：以is_cand=1统一判断“是否命中历史记录”：

步骤	改前	改后
t_final	条件(h_stopped_reason_id 非空 则 h_stopped_reason_id 否则 l_stopped_reason_id)	条件(is_cand = 1 则 h_stopped_reason_id 否则 l_stopped_reason_id)

修正后的完整脚本：

t_dates		列表 头 2024-03-01, 尾 2024-03-14; 间隔 1; 天; 命名 d
t_link_combos	organisation_user_link	导出表 user_id, organisation_id; 唯一值
t_hist_combos	organisation_user_link_status_history	导出表 user_id, organisation_id; 唯一值
t_combos	t_link_combos	集合 并; t_hist_combos
t_snap	t_dates	扩展 t_combos 拼接列 user_id, organisation_id
t_hist	t_snap	拼接 user_id, organisation_id; 关联表 organisation_user_link_status_history; user_id, organisation_id; 拼接列 history_time, status_id 命名 h_status_id, stopped_reason_id 命名 h_stopped_reason_id
t_cand	t_hist	计算列 条件(history_time >= d 则 1 否则 0), 命名 is_cand
t_best	t_cand	排名 is_cand 降序, history_time 升序; 前; 1; 分区 d, user_id, organisation_id
t_link	t_best	拼接 user_id, organisation_id; 关联表 organisation_user_link; user_id, organisation_id; 拼接列 status_id 命名 l_status_id, stopped_reason_id 命名 l_stopped_reason_id, dossier_created
t_final	t_link	计算列 条件(is_cand = 1 则 h_status_id 否则 l_status_id), 命名 status_id; 条件(is_cand = 1 则 h_stopped_reason_id 否则 l_stopped_reason_id), 命名 stopped_reason_id
t_out	t_final	导出表 d 命名 'date', user_id, organisation_id, status_id, stopped_reason_id, dossier_created
t_sorted	t_out	排序 'date' 降序, user_id 升序, organisation_id 升序

修正后重新运行，28 行全部符合期望。节选关键行：

2024-03-13,9,1199 → 1,空（命中 03-13 历史，stopped_reason_id 正确保留为空）

2024-03-12,9,1199 → 1,空（无当天变化，取 03-13 未来变化，理由为空）

2024-03-11,9,1199 → 2,空（当天变化，理由为空）

结论：面对复杂需求，AI能澄清歧义并生成初稿，但复杂逻辑的设计仍然可能出错——这是大模型推理的共性局限，不会因换了CodeBuddy而消失。测试数据验证能把这类错误拦截在源头，确保不流入生产。

五、总结

本套CodeBuddy + SQLazy组合拳的本质是把AI的不确定性控制在中间层，让确定性引擎（SQLazy专属IDE）和测试数据验证成为最后两道门。

CodeBuddy负责：理解需求、澄清歧义、生成结构化nspl初稿；

SQLazy专属IDE负责：语法校验、小数据对账、跨库编译；

人工负责：核对关键业务口径、根据测试结果修正逻辑偏差。

三者结合，使得“让AI写查询”不再是开盲盒，而是可预测、可审计、可回放的可控工程。