后端与数据工程师经常要做「SQL 上线审查」这类事：检查上线 SQL 的风险：无条件更新、大事务、锁。每次都从头写提示词，结果时好时坏；把它做成智能体 Skill，就能让智能体每次按同一套步骤执行，输出结构也更稳定。

下面是把「SQL 上线审查」做成技能时最常见的 8 个问题，每条都给出改法。

1. 描述写成口号

智能体判断不出何时该用。改为“检查上线 SQL 的风险：无条件更新、大事务、锁；当用户提到SQL 上线审查时使用”。

2. 步骤太粗

只写“做好SQL 上线审查”。改为编号的具体动作：检查 WHERE 条件；估算影响行数；检查事务大小；建议分批执行。

3. 没有输出格式

每次交付的审查结论结构不同。在技能中给出固定标题或表头。

4. 没写缺信息怎么办

智能体自行补全，产生编造内容。明确要求先列出缺失项并提问。

5. 忽略领域规矩

例如没写「默认使用只读连接，任何写操作都要人工确认」。把这类底线写进约束段落。

6. 权限过大

把纯指令技能和带执行权限的工具混在一起。纯提示词能完成的就不要挂工具。

7. 长资料塞进正文

每次加载都很重，关键规则被淹没。把规范、模板拆到参考文件按需读取。

8. 改完不测

一次改多处又不回归测试。保留测试用例，每次修改后重跑。

一个自查办法

把技能交给一位没参与编写的同事，让他只看 SKILL.md（或规则文件）回答三个问题：什么时候用？输入什么？交付什么？答不上来的地方，就是需要补写的地方。

风险提示：属于高风险：涉及权限、个人信息或不可逆操作，Skill 只产出建议或草稿，执行前必须人工确认。

平台选择建议

同一个「SQL 上线审查」技能可以落在不同平台上，选择时主要看你在哪里工作、要不要执行代码、要不要接外部系统：

  • OpenAI Agents SDK：OpenAI Agents SDK 是一个轻量的智能体开发框架。详见OpenAI Agents SDK 版
  • GPTs：GPTs 是在 ChatGPT 中创建的定制版助手。详见GPTs 版
  • Gemini CLI：Gemini CLI 会读取项目中的 GEMINI.md 作为长期上下文。详见Gemini CLI 版

这个技能纯指令型，不需要额外脚本或外部连接，复制到大多数平台都能用，可据此排除不支持相应能力的平台。

智能体与人的分工

技能不是把工作全部交出去，而是把重复、机械的部分交给智能体，人把住判断和责任：

步骤智能体负责人负责
检查 WHERE 条件按指令完成并给出依据抽查关键处，确认无误
估算影响行数按指令完成并给出依据抽查关键处，确认无误
检查事务大小按指令完成并给出依据抽查关键处，确认无误
建议分批执行按指令完成并给出依据抽查关键处，确认无误
最终交付整理审查结论决定是否采用、是否对外

属于高风险：涉及权限、个人信息或不可逆操作，Skill 只产出建议或草稿，执行前必须人工确认。

准备一份好范例

在技能的参考资料里放一份你认可的审查结论范例，往往比多写十条规则更有效。好范例应当：

  • 来自真实工作，但已去除个人信息和敏感数据
  • 体现团队习惯的结构、措辞和详略程度
  • 包含一处“需人工确认”的标注示范，让智能体学会如何表达不确定
  • 篇幅适中，不要比平时的产出长太多

范例不必多，一到两份即可；太多范例反而会让智能体机械模仿某一份的细节。

延伸阅读

说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。