很多人做 Agent 项目，最容易讲成这样：
接了大模型。
加了工具调用。
封装了一些 Prompt。
支持多轮对话和任务执行。
听起来好像没问题，但真到大厂面试里，面试官往往不会只问这些表层能力。
他很可能继续追问一句：
你的 Agent 系统里面，Skill 是怎么编写的？ 你怎么保证一个 Skill 是高质量的？
这个问题一出来，很多人就容易卡住。
因为如果你只回答：
Skill 就是把常用 Prompt 封装起来。
这个答案基本不够。
在真正的 Agent 工程里，Skill 不是一段更长的提示词，也不是一个漂亮的 Prompt 模板。
它更像是一个可复用、可验证、可迭代的专家能力包。
一个高质量 Skill，至少要回答清楚几个问题：
所以，这道面试题真正考察的不是你会不会写 Prompt，而是你有没有能力把专家经验沉淀成系统能力。
一、面试官真正想听的，不是“我会写 Skill”
这道题表面上问的是 Skill，实际上考察的是 Agent 工程化能力。
可以拆成三层：
所以回答这个问题时，不要一上来就说“我会写 SKILL.md”。
更好的回答方式是：
我不会把 Skill 简单理解成 Prompt 模板，而是把它看成 Agent 系统中的可复用任务能力单元。 一个高质量 Skill 应该包含触发条件、专家决策逻辑、反模式约束、资源导航、模板脚本、验证闭环和持续迭代机制。 它的目标不是让 Agent 偶尔答得好，而是让 Agent 在一类任务上稳定、可控、可复用地完成工作。
这句话，就是这道题的核心答案。
二、第一步：不是写 Skill，而是判断任务值不值得 Skill 化
很多团队刚开始做 Agent 时，最容易犯一个错误：
什么任务都想封装成 Skill。
最后 Skill 越写越多，Agent 反而越来越难维护。
因为 Skill 不是免费的。
它需要写说明、配模板、放参考资料、维护脚本、做测试验证，还要随着业务变化持续迭代。
所以第一步不是写 Skill，而是判断：
这个任务到底值不值得做成 Skill？
一般可以从三个维度判断。
1. 任务里有没有专家判断？
如果一个任务，熟手和新手做出来差距很大，那它通常适合做成 Skill。
比如测试开发场景里：
这些任务不是简单执行步骤，而是包含大量经验判断。
新手可能只会根据需求写几个正常流程。
但有经验的测试开发会继续追问：
这些判断，才是 Skill 最值得沉淀的部分。
Skill 的价值，不是让 Agent “照着做”，而是让 Agent 具备接近专家的判断框架。
2. 任务是不是足够复杂？
如果一个任务一句 Prompt 就能说清楚，通常没必要做成 Skill。
比如：
帮我润色这段话。
这种任务直接写 Prompt 就够了。
但如果任务变成：
根据 PRD、接口文档、历史缺陷和业务规则，生成高质量测试用例，并标注优先级、风险点、自动化建议和验收标准。
这就明显复杂很多。
因为它涉及：
这种任务就很适合沉淀成 Skill。
3. 任务会不会反复出现？
Skill 的核心价值是复用。
如果一个任务只做一次，没必要封装。
但如果团队每天、每周都在做类似事情，就很值得 Skill 化。
比如：
这些任务一旦沉淀成 Skill，长期收益会非常明显。
可以总结成一个判断公式：
适合做成 Skill 的任务 =
反复出现
+ 足够复杂
+ 有专家判断
+ 对输出质量有要求
反过来，如果只是简单、低频、一次性的任务，就不要强行做成 Skill。
Skill 不是越多越好，能稳定解决高价值重复问题才重要。
三、第二步：Skill 不是把流程写长，而是把判断写清楚
很多人写 Skill，会犯一个很典型的问题：
把 Skill 写成一大段说明书。
里面写了很多背景、理念、注意事项，看起来很完整，但 Agent 真正执行时抓不住重点。
高质量 Skill 的关键不是写得多，而是写得准。
尤其要提取三类内容：
1. 提取专家决策树
Skill 最重要的价值，是告诉 Agent：
比如一个“测试用例生成 Skill”，不能只写：
根据需求生成测试用例。
这句话太泛了。
更好的写法应该是：
当需求描述包含完整业务流程时：
- 先生成主流程用例
- 再补充异常流程
- 最后补充边界、权限、数据一致性和幂等场景
当需求描述不完整时：
- 不要编造不存在的业务规则
- 先标记缺失信息
- 再基于已有信息生成可确认的用例草稿
当需求涉及支付、权限、资金、删除、审批时：
- 必须标记为高风险需求
- 必须补充回滚、审计、重复提交、异常中断场景
这才是真正有价值的 Skill。
因为它不是简单告诉 Agent 做什么，而是告诉 Agent 怎么判断。
2. 提取反模式：明确不要做什么
在 Agent 系统里，“不要做什么”往往比“要做什么”更重要。
因为大模型很容易为了完成任务而过度发挥。
比如：
所以 Skill 里必须明确反模式。
例如：
不要把来源不明的信息当成事实写进结果。
不要为了让答案完整，擅自补充不存在的业务规则。
不要在高风险操作中直接修改文件，必须先生成计划。
不要跳过验证步骤直接给最终结论。
不要只覆盖正常流程，必须补充异常、边界、权限和数据一致性场景。
不要输出无法执行、无法验证的空泛建议。
这类约束能明显降低 Agent 的幻觉和误操作。
尤其是在测试开发、代码修改、数据库变更、自动化执行这类场景里，反模式非常关键。
3. 提供模板和示例，保证输出稳定
如果任务对输出结构要求很高，就应该提供模板。
比如测试用例模板：
| 用例编号 | 场景类型 | 测试点 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 自动化建议 |
|---|---|---|---|---|---|---|---|
如果任务对表达风格、分析深度要求很高，就应该提供示例。
比如缺陷复盘 Skill 可以给出这样的结构：
## 一、问题现象
## 二、影响范围
## 三、复现路径
## 四、根因分析
## 五、风险等级
## 六、修复方案
## 七、回归验证点
## 八、后续预防措施
模板解决的是格式稳定。
示例解决的是表达稳定。
两者结合，才能让 Skill 的输出质量更可控。
四、第三步：写 Skill 指令时，要控制上下文成本
一个常见误区是：
Skill 写得越详细，效果越好。
其实不一定。
Skill 不是独占上下文的。
它要和系统提示词、用户输入、历史对话、工具说明、其他 Skill 一起共享上下文窗口。
如果 Skill 里塞满了模型本来就知道的通用知识，反而会浪费上下文。
例如下面这种内容价值就不高：
你是一个专业、严谨、负责的智能助手。
你需要认真分析用户需求。
你需要给出高质量回答。
这些话太通用了。
更值得写进 Skill 的，是任务特有的判断和边界：
当输入缺少业务规则时，不要自行补全。
必须先列出缺失信息，再基于已有内容生成可确认的结果。
涉及资金、权限、删除、审批类需求时，必须提升风险等级。
Skill 里真正值得保留的是：
其他通用废话，都应该删除。
五、第四步：高风险任务低自由度，分析任务高自由度
不同类型的 Skill，对 Agent 的自由度要求不一样。
不能所有任务都用同一种写法。
1. 高风险任务：必须降低自由度
比如：
这些任务不能让 Agent 自由发挥。
Skill 里必须明确要求：
执行任何修改前，必须先输出计划。
计划必须包含修改文件、修改原因、影响范围、验证方式和回滚方案。
未完成计划验证前，不得直接执行修改。
执行后必须运行验证命令。
验证失败必须停止，并输出失败原因和修复建议。
这类 Skill 的核心是：
先控风险，再做执行。
这也是面试里很加分的点。
因为它说明你不是简单“让 AI 干活”，而是知道如何控制 Agent 的行为边界。
2. 分析类任务：保留一定自由度
比如：
这些任务需要 Agent 有一定分析空间。
如果约束太死，反而会降低质量。
这类 Skill 更适合规定：
必须从风险、收益、成本、落地难度四个维度分析。
必须给出优先级。
不确定信息必须单独标注。
结论必须有依据，不能只给判断。
也就是说：
Skill 不是把 Agent 管死，而是根据任务风险，给它合适的边界。
六、第五步：复杂任务要配工作流，不要让 Agent 自己猜
如果一个任务链路比较长，只靠自然语言描述是不够的。
因为任务步骤越多，Agent 越容易漏。
比如“接口测试用例生成”这个任务，至少包含：
如果 Skill 里不写清楚工作流，Agent 很可能只生成一批表面用例。
更好的方式是把流程写成明确的执行链路。
这个流程的价值不在于画图，而在于让 Agent 明确：
七、第六步：Skill 要分层组织，不要全塞进一个文件
一个成熟 Skill，最好不要只有一个巨大的 SKILL.md。
更合理的结构是：
test-case-skill/
├── SKILL.md
├── references/
│ ├── checklist.md
│ ├── anti-patterns.md
│ └── examples.md
├── templates/
│ ├── test-case-template.md
│ └── risk-report-template.md
└── scripts/
├── validate_cases.py
└── extract_api_fields.py
不同文件承担不同职责。
这样做有几个好处：
这也是 Skill 工程化和普通 Prompt 最大的区别之一。
普通 Prompt 解决的是一次对话效果。
而 Skill 解决的是一类任务的稳定复用。
人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
八、第七步：一定要关注 Skill 的触发质量
很多人只关注 Skill 内容写得好不好，却忽略了一个更基础的问题：
Agent 能不能在正确的时候调用这个 Skill？
一个 Skill 如果触发不稳定，也很难算高质量。
常见问题有两类。
第一类是该触发时没触发。
比如用户明明输入了：
根据这个 PRD 帮我生成测试用例。
但 Agent 没有调用“测试用例生成 Skill”，而是直接用普通对话方式回答。
第二类是不该触发时乱触发。
比如用户只是想简单问一个测试概念，Agent 却误触发了复杂 Skill，开始输出一大堆流程和表格。
所以 Skill 的名称和描述非常重要。
它们不是摆设，而是 Agent 判断是否调用 Skill 的重要依据。
一个好的 Skill 描述，应该写清楚：
这个 Skill 用于根据 PRD、接口文档或业务需求生成结构化测试用例。
适用于需要输出测试场景、优先级、风险点和自动化建议的任务。
不适用于简单概念解释、单句润色或无需结构化测试设计的任务。
注意，这里不仅写了“什么时候用”，还写了“什么时候不用”。
这能减少误触发，提高 Skill 的稳定性。
九、第八步：验证闭环是高质量 Skill 的关键
很多 Skill 效果不稳定，不是因为写得不够长，而是因为没有验证闭环。
一个高质量 Skill，不能只写：
完成后输出结果。
而应该写成：
完成初稿后，必须根据 checklist 自检：
- 是否覆盖主流程
- 是否覆盖异常流程
- 是否覆盖边界条件
- 是否标注优先级
- 是否存在编造业务规则
- 是否存在无法验证的结论
- 是否给出自动化建议
如果检查不通过，必须先修正，再输出最终结果。
这就是反馈循环。
对于能脚本化验证的内容，最好交给脚本，不要完全依赖模型自检。
比如：
可以写一个简单的校验脚本：
import json
import sys
REQUIRED_FIELDS = [
"case_id",
"scenario",
"steps",
"expected_result",
"priority"
]
def validate_case(case):
missing = [field for field in REQUIRED_FIELDS if field notin case ornot case[field]]
return missing
def main(path):
with open(path, "r", encoding="utf-8") as f:
cases = json.load(f)
errors = []
for index, case in enumerate(cases, start=1):
missing = validate_case(case)
if missing:
errors.append({
"case_index": index,
"missing_fields": missing,
"fix_hint": "请补齐缺失字段，并确保 steps 和 expected_result 可执行、可验证。"
})
if errors:
print(json.dumps({
"status": "failed",
"errors": errors
}, ensure_ascii=False, indent=2))
sys.exit(1)
print(json.dumps({
"status": "passed",
"case_count": len(cases)
}, ensure_ascii=False, indent=2))
if __name__ == "__main__":
main(sys.argv[1])
脚本最好对 Agent 友好：
这就是工程化 Skill 和普通提示词模板的核心差别。
十、第九步：用评测集验证 Skill，而不是只看一次演示效果
很多 Skill 在演示场景里看起来很好，但换一个真实任务就失效。
这类 Skill 其实不算高质量。
验证 Skill，一般可以分四步。
1. 先建立基线
先不用 Skill，让 Agent 直接做一次真实任务。
记录它会犯哪些错误。
比如：
这些失败样本非常重要。
因为它们就是后续 Skill 的评测用例。
2. 根据失败样本提取 Skill 初稿
不要凭空写 Skill。
应该从真实失败里提炼规则。
| |
|---|
| |
| |
| |
| |
| |
| 优化 Skill 的 name 和 description |
这种 Skill 不是拍脑袋写出来的，而是从真实问题中长出来的。
3. 用新会话重新测试
为什么要用新会话？
因为旧会话里有大量上下文，可能会掩盖 Skill 本身的问题。
真正的测试方式应该是：
如果新会话里效果明显更好，说明 Skill 真的起作用了。
4. 持续迭代，直到结果稳定
Skill 不是一次写完的。
它应该像测试用例、自动化脚本、代码库一样持续迭代。
每次发现新问题，都要判断：
最终可以形成一个小型评测集。
比如“测试用例生成 Skill”，可以准备这些评测样本：
每次 Skill 更新后，都跑一遍评测集，看输出是否稳定。
真正高质量的 Skill，不是一次输出惊艳，而是多次执行稳定。
十一、面试时可以这样回答
如果面试官问：
你的 Agent 系统里 Skill 是怎么编写的？如何保证高质量？
可以这样回答：
我一般不会把 Skill 简单理解成 Prompt，而是把它看成 Agent 系统中的可复用专家能力单元。
我们写 Skill 通常分几个步骤。
第一步，先判断任务是否值得沉淀成 Skill。
如果一个任务反复出现、具备一定复杂度，并且里面有明显的专家判断，比如边界识别、风险判断、优先级取舍，那它就适合做成 Skill。反过来，如果一句 Prompt 就能完成，或者只是一次性任务，就没必要封装。
第二步，提取专家决策逻辑。
这里的重点不是把流程写长，而是把判断写清楚。比如什么情况下走方案 A，什么情况下切到方案 B，什么情况下需要停止或者补充信息。同时还会提取反模式，比如不能编造缺失信息，不能跳过验证，不能在高风险操作里直接执行修改。
第三步，编写简洁指令。
Skill 里不会重复写模型本来就知道的通用知识，而是只保留任务特有的触发条件、执行边界、质量标准、输出模板和资源导航。对于高风险任务，会降低 Agent 自由度；对于分析类任务，会保留一定自由度，只约束流程和质量标准。
第四步，配套工具和资源。
如果任务有固定输出格式，就放模板；如果有复杂规则，就放 references；如果有确定性检查，就放 scripts。比如测试用例生成 Skill，可以配测试用例模板、风险检查清单和字段完整性校验脚本。
第五步，验证触发质量和执行质量。
我们不仅看 Skill 执行后的结果，还会看它是否在正确场景触发，是否存在误触发，是否按预期流程调用工具和脚本，最终输出是否符合团队规范。
第六步，用真实任务持续迭代。
我们会先不用 Skill 跑一次真实任务，记录 Agent 的典型错误，作为基线和评测样本。然后写 Skill 初稿，再用新会话重新测试，看效果是否稳定提升。后续持续把失败样本沉淀进 Skill 的反模式、checklist、模板或验证脚本里。
所以我认为，高质量 Skill 的核心不是提示词写得漂亮，而是它能不能把专家经验沉淀下来，并且在真实任务里稳定提升 Agent 的执行质量。
十二、想让答案更有区分度，可以补这一句
很多人面试时只会说：
我们会写 Prompt、调参数、优化输出。
但你可以补一句更工程化的话：
我们评估 Skill 质量时，不只看单次输出效果，而是看它在不同输入、不同会话、不同边界条件下是否稳定。 一个 Skill 如果只能在演示样例里表现好，但换一个真实任务就失效，那它还不算高质量 Skill。
这句话很重要。
因为它把 Skill 从“Prompt 技巧”提升到了“工程质量”。
十三、总结：Skill 的本质，是把专家经验产品化
Agent 真正进入企业之后，不可能只靠一个万能 Prompt 解决问题。
企业需要的是：
Skill 的价值就在这里。
它把专家脑子里的经验，变成 Agent 可以重复调用的能力包。
所以，面试里谈 Skill，不要只讲怎么写提示词。
更好的表达是：
Skill 是 Agent 工程化里的能力沉淀机制。 它把专家决策、反模式、模板、工具、验证流程和迭代样本组织到一起，让 Agent 不只是能完成一次任务，而是能稳定完成一类任务。
这才是大厂面试官真正想听到的答案。
也是真正做过 Agent 工程落地的人，和只会写 Prompt 的人之间，最明显的差距。
粤ICP备14082021号
免费POC，
零成本试错
