怎么写一个「给项目用的」AI Skill?从提示词到可复用工程模板
从零散提示词到可复用工程资产,作者分享封装AI Skill的方法论,附通用模板直接套用,解决项目复用难题。
核心内容:
- “给项目用的”Skill定义及三级分类
- L3 Skill的四个判定标准(输入输出、配置分离等)
- 通用工程结构:五个文件定天下的模板框架

上个月发了 Skill #3(AI 回归测试)后,后台收到不少类似的问题:
"提示词写得挺好,但放我项目里怎么改?"
"一个 Skill 好几个文件,有没有标准结构?"
"团队里怎么交接?新人拿到手直接能跑吗?"
最典型的是读者小Y:他照着网上的提示词把登录流程跑通了,结果一换测试环境,提示词里写死的 URL 和账号全废了,又回来问我怎么迁移。
这些问题其实指向同一件事:
把「一段好用的提示词」升级成「一个可交接、可复用、可迭代的工程资产」。
今天这篇文章,把过去几个月封装十几个 Skill 的经验,整理成一个通用方法论。文末会给你一个空白模板,套到任何项目里都能用。
一、先定义:什么是「给项目用的」Skill?
不是会写提示词就叫 Skill。
自己把 Skill 分三级:
| 级别 | 形态 | 问题 | 复用性 |
|---|---|---|---|
| L1 | 聊天记录里的一段提示词 | 过几天找不到、改不动、换模型效果变差 | 低 |
| L2 | 项目里的 prompt.md |
有文件,但和代码、配置、入口各玩各的 | 中 |
| L3 | 独立工程包(配置 + 提示词 + 入口 + 示例) | 新人按 README 三步跑通,改配置就能复用 | 高 |
只有 L3 才算「给项目用的 Skill」。
二、L3 Skill 的四个判定标准
在你动手封装之前,先用这四条卡一下:
① 有明确的输入输出
不是「帮我测一下」这种模糊目标,而是:
- 输入:Bug 描述 + 复现账号 Cookie + 期望行为
- 输出:回归结论文本 + 是否通过
输入输出定死了,Skill 才不会「看心情发挥」。
② 配置和逻辑分离
URL、账号、选择器、模型参数,全部抽到 config.py 或 config.yaml。同一套 Skill,A 项目改三行配置就能跑,B 项目改另外三行也能跑。
③ 自带「调用说明书」
不是只给人看,而是给 AI Agent 看。习惯写一个 skill.yaml,里面写清楚:
- 这个 Skill 解决什么问题
- 需要什么参数
- 执行步骤是什么
- 每一步调用哪个脚本
这样无论是 Trae、Claude Code 还是你自己写的 Agent,都能直接读这个说明书来调用。
④ 有最小可运行示例
新人第一次用,不应该先读完整文档。给他一个 examples/ 目录,里面是一个能直接跑的最小案例。跑通了,再回来看完整结构。
三、通用工程结构:五个文件定天下
现在的 Skill 都用同一套骨架,不论功能是回归测试、代码审查还是配置生成:
skill_template/
├── README.md # 3 分钟跑通 + 复用指南
├── skill.yaml # AI Agent 调用说明书
├── prompt_template.md # 给 LLM 看的标准提示词
├── config.py # 项目相关配置(URL、账号、模型参数)
├── main.py # Skill 入口:读取输入 → 调 LLM → 输出结果
├── run.sh # 一键运行脚本
└── examples/ # 最小可运行示例
└── demo_01/
├── input.json
└── expected_output.txt
这五个核心文件的分工很明确:
| 文件 | 给谁看 | 作用 |
|---|---|---|
skill.yaml |
AI Agent / 自动化工具 | 说明 Skill 的能力、参数、步骤 |
prompt_template.md |
LLM | 约束输出格式和质量 |
config.py |
人类开发者 | 抽离项目变量 |
main.py |
人类 / Agent | 执行入口 |
examples/ |
新人 | 降低第一次使用门槛 |
四、案例拆解:Skill #3 为什么能直接抄?
7 月 8 号那篇《AI 回归测试能自动关单吗?》里的 Skill #3,就是按上面这个骨架封装的。拆开来看:
skill.yaml
yamlname:ai_regression_test
description:基于双账号Cookie复现Bug并验证修复
parameters:
bug_description:string
bug_user_cookie:string
fixed_user_cookie:string
steps:
-load_context
-reproduce_bug
-verify_fix
-generate_report
prompt_template.md
- 只编写本次 Bug 对应的断言与增量校验
- 基础操作复用已有
pages/下的方法 - 测试函数最后调用
generate_result()输出标准化结论
config.py
main.py
generate_result() 输出结论。
examples/demo_01/
再放一个真实案例:给支付团队做的「接口契约校验」Skill
光说回归测试,你可能觉得离自己远。再放一个给支付团队做的 Skill,场景完全不同。
他们每次改接口,前端经常在某个字段改名之后崩掉。封装的 Skill,输入是「PR 的 diff + 涉及的接口文档」,输出是「哪些字段被改动、是否破坏前端契约、建议补哪些断言」。
第一版直接翻车了:把整个 OpenAPI 文档(800 多行)全塞进提示词,想让模型「全局理解」。结果模型经常幻觉出不存在的字段,还顺手把不相关的端点也改了,误报率接近三成。
这就是前面「坑 1」活生生的例子。修法很简单——提示词里只留「不变的三条约束」,把本次 diff 涉及的那一个端点的 schema 作为参数单独注入。提示词从 800 行缩到 40 行,误报率直接掉到个位数。
这个案例想说明一件事:
L3 Skill 的威力不在提示词多长,而在「配置和逻辑分离」做得干不干净。
这就是 L3 Skill 的妙处:
结构通用,例子具体,改配置就能迁移。
五、三步封装法:从提示词到工程包
不管你的 Skill 是解决什么问题,都可以按下面三步走。
第一步:把「一次成功」固化成 SOP
先别想着封装。先手动把这件事成功做一次,然后记录下来:
- 我输入了什么?
- 我对 AI 说了什么?
- AI 返回了什么?
- 我改了哪几行代码让它跑通?
- 最终输出格式长什么样?
这一步产出的是 prompt_template.md 的初稿。
第二步:把「可变部分」抽到 config
问自己:如果换到另一个项目,哪些东西一定会变?
- 系统 URL
- 测试账号
- 元素选择器
- 模型名称 / API Key
- 输出目录
全部放进 config.py。原则是:
同一类 Skill,只改配置就能跑第二次。
第三步:补全「说明书 + 示例 + 入口」
- 写
skill.yaml,让 Agent 能自动调用 - 写
README.md,让人类 3 分钟跑通 - 准备
examples/,让新人有地方下手 - 写
main.py/run.sh,把调用路径锁死
做完这三步,用三句话自检一下你的 Skill 是不是 L3:
- 新人拿到手,不看你,能照 README 3 分钟跑通吗?
- 换个项目,只改
config.py就能复用吗? - 别人调它,拿到的是不是固定格式的标准化输出?
三条都答「是」,才算真正脱手。
六、两个常见坑
坑 1:提示词越写越长
很多人第一次封装 Skill,会把所有 edge case 都写进提示词。结果提示词 2000 字,模型反而抓不住重点。
正确做法
坑 2:没有标准化输出
AI 每次返回结论格式不一样,后续接自动化脚本就很痛苦。
正确做法
main.py 里固定输出函数。比如:
pythondef generate_result(is_pass: bool, bug_desc: str) -> str:
if is_pass:
return f"回归结论:{bug_desc} 已修复,自动化用例执行通过。"
return f"回归结论:{bug_desc} 未修复,自动化校验捕获异常。"
输出格式一旦标准化,Skill 才能被其他工具调用。
七、配套源码包:空白模板直接套
这篇文章的源码包是一个
AI Skill 工程模板
skill_template_v1.0/
├── README.md # 5 步跑通 + 复用指南
├── skill.yaml # 通用 Skill 调用说明书模板
├── prompt_template.md # 通用提示词模板(含约束范式)
├── config.py # 配置模板(URL / 模型 / 输出路径)
├── main.py # 标准入口:读取输入 → 调 LLM → 输出结果
├── run.sh # 一键运行
└── examples/
└── demo_regression/ # 一个可运行的最小示例
├── input.json
└── README.md
拿到后建议先做一件事:
把 examples/demo_regression/ 改成你自己项目的一个真实场景。
八、写在最后
AI Skill 不是越复杂越好。好的 Skill 像一把螺丝刀:结构简单、边界清楚、拿到就能用。
今天这个方法论 + 模板,核心就一句话:
把提示词工程化,而不是把工程提示词化。
-
- 关于宇宙的好的网名有哪些
- 角色扮演 | 1
- 网名