我要投稿

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

发布日期：2026-04-26 08:27:54 浏览次数： 1533

作者：架构与方法

微信搜一搜，关注“架构与方法”

第二篇里，我用 Claude Code 做了一个数据库慢查询分析前处理 demo：把原本大约 25 分钟的慢查询分析前处理，压缩到 2 分钟左右。
但做完之后，我很快意识到：一个 Skill 能跑起来，不等于它已经可用。

摘要

这篇文章继续补上第二篇之后的"半步"：如果一个 Skill 已经能跑起来，接下来它怎样才算工程上站得住？在我看来，真正的差距不只在功能本身，还在于粒度边界、权限、安全、沙箱、审批、灰度、输入输出、建议边界和失败策略这些看不见的工程化约束。

说明：本文内容主要基于我个人在业余时间的学习、搭建与思考，属于个人技术探索，不涉及实际工作中的具体项目、业务与生产实践。文中提到的 demo、流程和判断，更多用于验证思路与方法。

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

它做的事情并不复杂：

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

比如：

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

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

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

一个 Skill 能跑起来，不等于它已经可用。

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

如果这个慢查询分析能力包明天真的要被反复使用，它还缺什么？

demo 阶段，我们很容易高估它

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

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

帮我分析下面这条 SQL 为什么慢，并给出优化建议。

再贴一段 SQL：

select *
from orders
where user_id = 10001
order by created_at desc
limit 20;

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

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

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

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

原因很简单：

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

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

这就是 demo 和可用之间的第一道分界线：
demo 证明这个方向能跑；可用要求这个结果能被信任。

Skill 不是 SOP：先把粒度说清楚

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

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

慢查询分析不是一个单一 Skill，而是一个场景 / SOP。

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

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

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

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

现象 / 告警
-> 根因分类
-> SOPTemplate
-> HealingPlan
-> HealingStep
-> Action
-> Skill / Executor

也就是说：

层级关系对照

层级	作用	慢查询场景中的例子
现象 / 场景	问题入口	慢查询、SQL 执行慢
SOPTemplate	处理模板	慢查询分析流程
HealingPlan / Plan	本次实例化计划	针对这条 SQL 的分析计划
HealingStep	分步动作	查结构、查索引、看执行计划
Action	标准动作定义	parse_sql、read_schema、read_indexes、analyze_explain
Skill / Executor	动作背后的执行实现	解析 SQL、读取元数据、分析执行计划

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

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

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

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

一句话概括：
SOP 是剧本，Plan 是本次安排，Step 是分镜头，Action 是标准动作，Skill / Executor 是动作背后的执行能力。

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

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

因为我们还要继续追问：

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

口径区分对照

口径	Skill 指什么	更接近本文哪一层
平台口径	一个包含说明、工具和资源的能力目录	能力包
工程口径	某个标准 Action 背后的可复用执行能力	Skill / Executor

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

先规格化，再自动化。

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

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

可用的能力包，首先要有一个"形状"

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

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

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

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

slow-query-analysis/
├── sop.yaml # 慢查询分析处理模板
├── plan_template.yaml # 分步计划模板
├── actions/
│ ├── parse_sql.yaml # 标准动作定义
│ ├── read_schema.yaml
│ ├── read_indexes.yaml
│ ├── analyze_explain.yaml
│ └── generate_advice.yaml
├── skills/
│ ├── read_indexes/ # Action 背后的执行实现
│ └── analyze_explain/
├── prompts/
│ └── advice_format.md # 建议输出格式约束
├── examples/
│ ├── input.json # 输入样例
│ └── output.json # 输出样例
└── tests/
└── slow_query_cases.md # 典型慢查询样例

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

慢查询分析不再只是"让 AI 帮我回答一个问题"。它开始变成一个可以维护、可以复用、可以验证的能力包。

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

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

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

如果真要落地，我会从一个最小 Action 开始

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

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

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

比如：

analyze_explain
这个 Action 只做一件事：解析执行计划，提取关键特征，输出初步风险判断。

它的输入可以先定义成：

{
"db_type": "mysql",
"sql_summary": {
"tables": ["orders"],
"filters": ["user_id = ?"],
"order_by": ["created_at desc"],
"limit": 20
},
"indexes": [
"PRIMARY KEY (id)",
"KEY idx_user_id (user_id)"
],
"explain": {
"type": "ref",
"key": "idx_user_id",
"rows": 120000,
"extra": "Using where; Using filesort"
}
}

输出可以先固定为：

{
"action": "analyze_explain",
"problem_type": "possible_sort_cost",
"evidence": [
"执行计划 key = idx_user_id",
"执行计划 rows = 120000",
"Extra 包含 Using filesort"
],
"risk_boundary": [
"当前信息不足以直接建议创建索引",
"需要结合数据分布、查询频率和写入压力判断"
],
"confidence": "medium",
"human_review_required": true
}

然后再补四件事：

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

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

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

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

这比一上来做一个"大而全的慢查询 Skill"更慢一点，但更可控。也更符合数据库场景的风险边界。

Skill / Executor 的四条基本法

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

我现在会先看四条。

1）默认最小权限，按风险分层

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

更准确的说法是：

分析型 Skill / Executor 默认只读；操作型 Skill / Executor 必须显式授权、审批、审计和可回滚。

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

• parse_sql
• read_schema
• read_indexes
• analyze_explain
• generate_advice

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

它们可以：

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

但它们不应该默认：

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

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

比如：

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

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

动作类型与策略分层

动作类型	示例	默认策略
分析型动作	解析 SQL、分析执行计划、整理建议	默认允许
采集型动作	查询表结构、索引、统计信息	受控允许
变更型动作	建索引、改参数、执行修复脚本	默认禁止，必须审批

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

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

name: read_indexes
version: 0.1.0
type: action_skill
mode: readonly
risk_level: low

allowed_actions:
- read_indexes
- read_metadata

blocked_actions:
- execute_dml
- execute_ddl
- create_index
- drop_index
- change_parameter

limits:
timeout_seconds: 30
network_access: false

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

Skill / Executor 的权限应该默认收紧，再按场景、风险和审批逐步放开。

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

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

一个 Skill / Executor 能不能在工程上站住，首先看它是不是默认安全。

2）必须在可隔离的环境里执行

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

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

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

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

一个 Skill / Executor 不只是"能运行"，还要"可限制、可回收、可审计"。

可运行只是起点，可隔离、可控制、可回收，才是工程化运行。

3）Skill / Executor 不是即时产物，而是受控交付物

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

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

想到一个需求，直接让 AI 生成，然后马上放到执行平台里跑。

更稳的方式应该是：

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

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

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

Skill / Executor 不应该是谁想到就谁直接上线，它应该像代码一样被管理。

4）上线要渐进，不要一步到位

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

更稳的路径应该是：

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

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

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

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

一个 Skill / Executor 的上线，不应该是"发布"，而应该是"逐步放开"。

实现质量：怎样才算写得好

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

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

1. 输入设计是否清楚

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

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

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

{
"db_type": "mysql",
"action": "analyze_explain",
"sql": "select * from orders where user_id = ? order by created_at desc limit 20",
"schema": {
"table": "orders",
"columns": ["id", "user_id", "status", "created_at", "amount"]
},
"indexes": [
"PRIMARY KEY (id)",
"KEY idx_user_id (user_id)"
],
"explain": {
"type": "ref",
"key": "idx_user_id",
"rows": 120000,
"extra": "Using where; Using filesort"
}
}

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

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

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

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

可以评估联合索引方向，但不能直接作为变更依据。

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

2. 步骤拆解是否合理

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

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

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

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

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

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

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

3. 输出结构是否稳定

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

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

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

{
"problem_type": "possible_missing_composite_index",
"summary": "当前 SQL 命中了 user_id 索引，但排序阶段出现 filesort，扫描行数偏大。",
"evidence": [
"执行计划 key = idx_user_id",
"执行计划 rows = 120000",
"Extra 包含 Using filesort",
"SQL 同时包含 user_id 条件和 created_at 排序"
],
"recommendation": {
"type": "index_review",
"content": "可以评估联合索引 (user_id, created_at) 是否适合该查询模式。",
"risk": "需要结合写入频率、索引选择性和现有索引冗余情况判断。"
},
"confidence": "medium",
"human_review_required": true
}

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

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

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

4. 建议边界是否收住

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

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

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

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

它可以说：

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

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

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

5. 可追溯性和性能是否可控

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

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

失败场景处理策略

场景	正确处理	不应该做的事
拿不到执行计划	只做 SQL 结构层面的初步判断	直接判断索引是否合理
缺少索引信息	提示需要补充现有索引	直接建议新增索引
缺少数据分布	降低置信度	假设字段选择性很高
执行超时	输出已完成步骤和失败原因	拼出完整报告
证据冲突	标记为人工复核	强行选择一个结论