数据库 AI Skill 不是 Prompt：从 demo 到可用，中间差的是工程化

第二篇里，我讲了一个慢查询分析前处理 demo。

它做的事情并不复杂：

把 DBA 在慢查询前处理里那些重复动作，先让 AI 接过去一部分。

比如：

• 整理 SQL
• 查看表结构
• 查看索引
• 分析执行计划
• 输出一份初步判断

这个 demo 跑通之后，效果还不错。原来大约 25 分钟的前处理，压到了 2 分钟左右。

但做完之后，我很快意识到另一个问题：

这句话如果只停留在概念上，会显得有点虚。所以这篇我不想继续讲大而全的方法论，而是换一个更具体的问题：

慢查询分析前处理 demo，通常可以很快做出来。

最简单的形式，可能就是一句话：

再贴一段 SQL：

AI 很可能会给出一组看起来还不错的建议：

• 需要查看执行计划
• 可能缺少联合索引
• 关注扫描行数是否过大
• order by created_at 可能触发排序
• 可以考虑 (user_id, created_at) 这样的索引方向

如果只是做 demo，这已经足够让人兴奋。因为它确实接住了一部分重复分析动作。

但如果站在 DBA 的角度，这个答案其实还不能直接用。

原因很简单：

它不知道表结构。
它不知道现有索引。
它不知道执行计划。
它不知道数据分布。
它不知道这个 SQL 的调用频率。
它也不知道这个表的写入压力。

所以它给出的"建议"，更像一个方向。不是一个可以直接进入决策链路的结论。

在继续讲 Skill 工程化之前，我觉得还需要先补一个概念边界。

前面为了方便表达，我一直在说"把慢查询分析做成一个 Skill"，但严格来说，这个说法不够准确。

SOP 更像一套处理模板，描述某类问题通常应该怎么处理。它可能包含判断、分支、前置检查、执行步骤、验证步骤和回滚步骤。

而 Action 更像其中某一步允许调用的标准动作。

Skill / Executor 则是这个 Action 背后的具体执行能力。

如果放到一个更完整的系统里，这条链路更应该是：

也就是说：

所以，一个 SOP 不应该简单等于一个 Skill。一个 Skill 也不应该试图包下整个 SOP。

以慢查询分析为例，完整 SOP 里可能包含：

• 收集 SQL 与时间范围
• 查询表结构
• 查询索引
• 获取执行计划
• 提取关键特征
• 生成初步建议
• 人工复核

这些步骤里，有些会映射成 Action，再由对应能力执行；有些只是流程判断，有些必须留给人。

这里需要额外说明一下。很多平台也会把一整个能力目录称为 Skill，比如 OpenClaw 这类工具就经常会说"已经帮你创建了 Skill"。

这个叫法没有问题，它是平台口径下的 Skill。但如果放到数据库工程化场景里，只说"创建了一个 Skill"还不够。

因为我们还要继续追问：

• 这个 Skill 是一个场景能力包？
• 还是某个 Action 背后的执行能力？
• 它包含 SOP 吗？
• 它能不能拆出标准 Action？
• 哪些部分可以自动执行，哪些部分必须人工确认？

这背后的逻辑其实很简单：

如果把整个 SOP 都压成一个 Skill，这个 Skill 很快就会变得过大、过重、难以复用，也难以审计。

这也是为什么我认为，谈 Skill 工程化之前，必须先把它的粒度和边界说清楚。

如果慢查询分析这个场景想从 demo 往前走，我觉得它至少不能只是一段 Prompt。

它应该开始有一个基本的工程形态。

这里我不再把它命名成 slow-query-skill，而是更倾向于把它看成一个场景化能力包。

能力包不是一个更大的 Skill。它更像是把 SOP + Plan 模板 + Action 定义 + Skill 实现 + 样例 + 测试 放在一起的交付形态：

这个目录不复杂。但它传递了一个关键变化：

这里面最关键的不是文件数量，而是这些问题被显式写出来了：

• 这个场景适合处理什么问题？
• 它会走哪套 SOP？
• 本次执行会生成什么 Plan？
• 每一步对应什么 Action？
• 每个 Action 由哪个 Skill / Executor 实现？
• 每个 Skill / Executor 需要哪些输入？
• 每个 Skill / Executor 不能做哪些动作？
• 失败时应该怎么降级？

一旦这些问题没有被写清楚，它就很容易停留在 demo 状态。看起来能用，但每次用出来的结果都不太一样。

如果真要把这件事落地，我不会一上来就做一个完整的"慢查询分析 Skill"。

因为这个粒度太大。它里面有 SOP、有计划、有步骤、有动作、有判断，也有人要参与复核。

更稳的方式，是先选一个最小 Action。

比如：

它的输入可以先定义成：

输出可以先固定为：

然后再补四件事：

• 权限：默认只读，不允许 DDL / DML
• 样例：准备成功样例、信息缺失样例、证据冲突样例、超时样例
• 失败策略：拿不到执行计划时，不生成确定结论
• 挂回流程：让慢查询 SOP 的某个 Step 调用这个 Action

这样做的好处是，它不需要一开始就把整个慢查询分析流程做完。

先把一个最小 Action 做稳，再逐步补 parse_sql、read_schema、read_indexes、generate_advice。

多个 Action 稳了之后，再回到 SOP 和 Plan 层做编排。

一个 Skill / Executor 要从 demo 走向可用，第一层要补的不是 Prompt 技巧，而是工程化底盘。

我现在会先看四条。

第一条，不是简单地说"所有 Skill 都只能只读"。

更准确的说法是：

比如慢查询分析里的这些原子能力：

• parse_sql
• read_schema
• read_indexes
• analyze_explain
• generate_advice

它们本质上都属于分析型或采集型能力。

它们可以：

• 解析 SQL
• 查询表结构
• 读取现有索引
• 分析执行计划
• 输出初步建议

但它们不应该默认：

• 修改数据
• 执行 DDL
• 创建索引
• 修改数据库参数
• 自动创建或修改其他 Skill

未来如果进入 DB Agent、自愈或者变更执行类场景，确实可能会出现"写权限"或"操作权限"。但那已经不是普通分析型 Skill 的默认权限，而应该进入更高风险等级的动作体系。

比如：

• 需要显式授权
• 需要审批流
• 需要审计日志
• 需要回滚路径
• 需要执行前预览
• 需要失败后的复盘能力

所以我会把数据库动作分成三层：

权限必须显式放开，不能默认拥有。

一个最小权限配置，大概可以长这样：

这段配置里，最重要的不是 readonly 这个词本身。而是它背后的原则：

对数据库来说，"分析"和"执行"不是一个风险等级。

分析慢一点，最多是效率问题。执行错了，可能就是生产事故。

Skill / Executor 不应该直接裸跑。它至少应该运行在一个可控环境里：

• 文件系统范围可控
• 网络访问可控
• 脚本资源使用可控
• 执行时长可控
• 出错后可中断
• 失败后可回收

沙箱的意义不只是安全。它还意味着你能限制它能看到什么、能改什么、能跑多久，也能在异常时把它停下来。

对数据库 Skill / Executor 来说，这一点尤其重要。因为数据库运维里很多动作不是简单的"对"或"错"，而是有风险级别的。

我现在越来越不愿意把 Skill / Executor 看成一次性生成物。

比如用 Claude Code 写一个能力，比较合理的方式不应该是：

更稳的方式应该是：

• 按统一规范编写
• 有明确的约束文档，比如 CLAUDE.md
• 通过 Git 管理版本
• 通过评审或审批确认边界
• 审批后再迁移到执行平台
• 变更要有记录
• 回退要有路径

这听起来比 demo 阶段重一些。但如果这些 Skill / Executor 未来要被反复调用，甚至成为 Agent 编排的一部分，这一步迟早绕不过去。

它们不是一次性脚本。它们可能影响后续诊断结论，也可能被多个 SOP 复用。

一个 Skill / Executor 写完之后，也不应该直接扩大范围使用。

更稳的路径应该是：

本地验证 → 沙箱运行 → 测试环境验证 → 小范围灰度 → 逐步扩大使用范围

这和传统系统发布没什么本质区别。只是过去我们发布的是代码、脚本、配置。现在发布的是一种"可被 AI 调用的能力"。

越是这样，越不能一步到位。

尤其在数据库场景里，哪怕只是分析型 Skill / Executor，也会影响人的判断。如果输出不稳定、建议过度、边界不清，就可能影响后续决策。

前面讲的是工程化底盘。但一个 Skill / Executor 真正好不好，还要看它本身的实现质量。

这里我不想展开太多 Prompt 技巧，而是只看五个问题。

demo 里，我们经常直接贴一条 SQL。但可用的分析流程，不能只接收一段 SQL。

更准确地说，每个 Skill / Executor 都应该知道自己拿到的上下文是什么。

比如 analyze_explain 这个能力，输入至少要包含：

有了这些信息，它才能做更稳定的判断。

它可以知道 SQL 过滤条件是 user_id，当前只命中了 idx_user_id，扫描行数偏大，排序阶段出现了 Using filesort。

但即使这样，它也不能直接给出"应该建索引"的结论。因为还缺少数据分布、查询频率、写入压力、索引冗余等信息。

所以更合理的表达应该是：

输入设计的价值，不是让格式更好看。而是让它知道自己掌握了哪些证据，又缺了哪些证据。

一个 Skill / Executor 不能一口气做太多事。

如果一个能力同时负责查 SQL、查索引、看监控、做诊断、给建议、生成脚本、执行修复，那它看起来很强，但边界会很乱。

更好的方式，是让每一步都有明确目标。

比如慢查询分析的前处理，可以拆成：

1. parse_sql：识别 SQL 涉及的表、字段和条件
2. read_schema：查询表结构
3. read_indexes：查询现有索引
4. analyze_explain：解析执行计划并提取关键特征
5. generate_advice：生成初步建议和风险边界

每一步都应该能单独验证。

这比"一口气让 AI 分析一下"要稳定得多。

很多 AI 分析结果的问题，是写得很完整，但不好复用。

一大段自然语言，看起来像报告。但如果后面要进入审批、复核、工单、知识库，结构就不够清楚。

我更希望 generate_advice 这类能力输出类似这样的结果：

这里我最关心的不是 JSON 本身。而是输出里必须拆开几件事：

• 问题类型是什么
• 证据是什么
• 建议是什么
• 风险是什么
• 置信度如何
• 是否需要人工确认

这样它才不会把"方向性建议"包装成"最终结论"。

建议层很容易把话说得太满。

比如看到全表扫描，就直接建议加索引。看到扫描行数很大，就直接判断 SQL 有问题。看到连接数偏高，就输出一堆泛泛的优化建议。

这些建议不一定错，但可能不够聚焦，也可能越过了能力单元应该承担的边界。

所以我更倾向于让它输出"初步建议"，而不是"最终判断"。

它可以说：

• 可能的问题是什么
• 依据是什么
• 建议方向是什么
• 风险边界是什么
• 置信度如何

但最终要不要执行，仍然需要人判断。

建议不是越多越好，而是越聚焦越有价值。

一个 Skill / Executor 是否可用，不只看它成功时表现如何。更要看它信息不足、执行失败、上下文过长、步骤超时时会不会乱说。

我觉得数据库类能力至少要提前写清楚这些失败策略：

这张表看起来简单，但它决定了能力单元的可信度。

因为真实环境里，信息不完整是常态。

一个不成熟的能力，会在信息不足时继续生成答案。

一个更成熟的能力，应该明确告诉你：

这句话不炫技。但它对数据库工作很重要。

所以，一个能力单元写得好不好，不看它写了多少，而看它的输入、边界、输出和可追溯性是不是稳定。

到这里，其实可以回到最开始那个问题。

为什么一个能跑起来的能力单元，不等于它已经可用？

因为它们解决的是两类问题。

demo 关注的是：

• 流程通不通
• 能不能跑
• 能不能出结果
• 能不能验证想法

可用关注的是：

• 有没有边界
• 有没有约束
• 有没有审计
• 有没有灰度
• 有没有一致输出
• 能不能长期维护

这两者不是一个层级。

一个能跑起来的能力单元，解决的是"有没有"。一个可用的能力单元，解决的是"能不能长期可信地用"。

所以我现在越来越不愿意把 Skill 看成一个 Prompt。

Prompt 只是 Skill 里面的一部分。

如果一个能力单元要进入数据库工作流，它就必须被当成一个小型工程交付物来看。

它可以很轻。但不能没有边界。

它可以先只做辅助分析。但必须说清楚自己不能做什么。

它可以给建议。但必须把证据、风险和置信度一起交代清楚。

第二篇证明的是：

慢查询分析这个场景，可以被拆解成一组可复用的 Action，再由对应的 Skill / Executor 承接。

这篇想补的是：

它要真正变成一个可长期使用的能力体系，还要补哪些工程化基础。

从 demo 到可用，不只是补功能。更重要的是补：

• 粒度边界
• 权限边界
• 运行隔离
• 输入输出
• 失败策略
• 版本管理
• 审批灰度
• 可追溯性

只有当单个 Action 的定义清楚、单个 Skill / Executor 的边界、输入输出和发布机制先站住，后面谈 SOP 编排、多个 Skill 协同，才不会变成另一种失控。

所以第三篇其实不是绕开了 DB Agent。而是在补它前面必须有的一层基础。