很多人做 Agent 项目最容易讲成这样接了大模型。加了工具调用。封装了一些 Prompt。支持多轮对话和任务执行。听起来好像没问题但真到大厂面试里面试官往往不会只问这些表层能力。他很可能继续追问一句你的 Agent 系统里面Skill 是怎么编写的 你怎么保证一个 Skill 是高质量的这个问题一出来很多人就容易卡住。因为如果你只回答Skill 就是把常用 Prompt 封装起来。这个答案基本不够。在真正的 Agent 工程里Skill 不是一段更长的提示词也不是一个漂亮的 Prompt 模板。它更像是一个可复用、可验证、可迭代的专家能力包。一个高质量 Skill至少要回答清楚几个问题什么时候应该触发什么时候不应该触发任务应该按什么流程执行遇到边界情况怎么判断哪些行为禁止做输出结果如何验证失败以后如何修正和迭代所以这道面试题真正考察的不是你会不会写 Prompt而是你有没有能力把专家经验沉淀成系统能力。一、面试官真正想听的不是“我会写 Skill”这道题表面上问的是 Skill实际上考察的是 Agent 工程化能力。可以拆成三层考察点面试官真正想听什么任务抽象能力你能否判断什么任务适合 Skill 化专家经验沉淀能力你能否把人的判断规则写进 Skill质量保障能力你有没有验证、评测和迭代机制所以回答这个问题时不要一上来就说“我会写 SKILL.md”。更好的回答方式是我不会把 Skill 简单理解成 Prompt 模板而是把它看成 Agent 系统中的可复用任务能力单元。 一个高质量 Skill 应该包含触发条件、专家决策逻辑、反模式约束、资源导航、模板脚本、验证闭环和持续迭代机制。 它的目标不是让 Agent 偶尔答得好而是让 Agent 在一类任务上稳定、可控、可复用地完成工作。这句话就是这道题的核心答案。二、第一步不是写 Skill而是判断任务值不值得 Skill 化很多团队刚开始做 Agent 时最容易犯一个错误什么任务都想封装成 Skill。最后 Skill 越写越多Agent 反而越来越难维护。因为 Skill 不是免费的。它需要写说明、配模板、放参考资料、维护脚本、做测试验证还要随着业务变化持续迭代。所以第一步不是写 Skill而是判断这个任务到底值不值得做成 Skill一般可以从三个维度判断。任务里有没有专家判断如果一个任务熟手和新手做出来差距很大那它通常适合做成 Skill。比如测试开发场景里根据 PRD 生成测试用例判断接口测试覆盖是否充分分析线上缺陷根因评估自动化用例是否值得写Review 测试报告是否可信判断一次发版有没有高风险点这些任务不是简单执行步骤而是包含大量经验判断。新手可能只会根据需求写几个正常流程。但有经验的测试开发会继续追问有没有异常流程有没有边界条件有没有权限问题有没有数据一致性问题有没有幂等问题有没有灰度和回滚风险哪些场景适合自动化哪些场景反而不值得自动化这些判断才是 Skill 最值得沉淀的部分。Skill 的价值不是让 Agent “照着做”而是让 Agent 具备接近专家的判断框架。任务是不是足够复杂如果一个任务一句 Prompt 就能说清楚通常没必要做成 Skill。比如帮我润色这段话。这种任务直接写 Prompt 就够了。但如果任务变成根据 PRD、接口文档、历史缺陷和业务规则生成高质量测试用例并标注优先级、风险点、自动化建议和验收标准。这就明显复杂很多。因为它涉及输入信息抽取业务流程理解测试场景拆解风险识别优先级判断自动化价值评估输出格式约束质量自检这种任务就很适合沉淀成 Skill。任务会不会反复出现Skill 的核心价值是复用。如果一个任务只做一次没必要封装。但如果团队每天、每周都在做类似事情就很值得 Skill 化。比如每个需求都要写测试用例每次发版都要做风险评估每次接口变更都要补充自动化用例每次线上事故都要做缺陷复盘每次代码提交都要做质量 Review这些任务一旦沉淀成 Skill长期收益会非常明显。可以总结成一个判断公式适合做成 Skill 的任务 反复出现足够复杂有专家判断对输出质量有要求反过来如果只是简单、低频、一次性的任务就不要强行做成 Skill。Skill 不是越多越好能稳定解决高价值重复问题才重要。三、第二步Skill 不是把流程写长而是把判断写清楚很多人写 Skill会犯一个很典型的问题把 Skill 写成一大段说明书。里面写了很多背景、理念、注意事项看起来很完整但 Agent 真正执行时抓不住重点。高质量 Skill 的关键不是写得多而是写得准。尤其要提取三类内容专家决策树反模式约束模板和示例提取专家决策树Skill 最重要的价值是告诉 Agent什么情况下走方案 A什么情况下切到方案 B什么情况下必须停止什么情况下需要补充信息什么情况下只能给建议不能直接执行比如一个“测试用例生成 Skill”不能只写根据需求生成测试用例。这句话太泛了。更好的写法应该是当需求描述包含完整业务流程时先生成主流程用例再补充异常流程最后补充边界、权限、数据一致性和幂等场景当需求描述不完整时不要编造不存在的业务规则先标记缺失信息再基于已有信息生成可确认的用例草稿当需求涉及支付、权限、资金、删除、审批时必须标记为高风险需求必须补充回滚、审计、重复提交、异常中断场景这才是真正有价值的 Skill。因为它不是简单告诉 Agent 做什么而是告诉 Agent 怎么判断。提取反模式明确不要做什么在 Agent 系统里“不要做什么”往往比“要做什么”更重要。因为大模型很容易为了完成任务而过度发挥。比如为了让答案完整补充不存在的信息为了快速给结论跳过验证步骤为了显得专业写很多无法落地的套话为了执行任务直接修改高风险文件为了覆盖全面输出一堆没有优先级的内容所以 Skill 里必须明确反模式。例如不要把来源不明的信息当成事实写进结果。不要为了让答案完整擅自补充不存在的业务规则。不要在高风险操作中直接修改文件必须先生成计划。不要跳过验证步骤直接给最终结论。不要只覆盖正常流程必须补充异常、边界、权限和数据一致性场景。不要输出无法执行、无法验证的空泛建议。这类约束能明显降低 Agent 的幻觉和误操作。尤其是在测试开发、代码修改、数据库变更、自动化执行这类场景里反模式非常关键。提供模板和示例保证输出稳定如果任务对输出结构要求很高就应该提供模板。比如测试用例模板用例编号场景类型测试点前置条件操作步骤预期结果优先级自动化建议如果任务对表达风格、分析深度要求很高就应该提供示例。比如缺陷复盘 Skill 可以给出这样的结构一、问题现象二、影响范围三、复现路径四、根因分析五、风险等级六、修复方案七、回归验证点八、后续预防措施模板解决的是格式稳定。示例解决的是表达稳定。两者结合才能让 Skill 的输出质量更可控。四、第三步写 Skill 指令时要控制上下文成本一个常见误区是Skill 写得越详细效果越好。其实不一定。Skill 不是独占上下文的。它要和系统提示词、用户输入、历史对话、工具说明、其他 Skill 一起共享上下文窗口。如果 Skill 里塞满了模型本来就知道的通用知识反而会浪费上下文。例如下面这种内容价值就不高你是一个专业、严谨、负责的智能助手。你需要认真分析用户需求。你需要给出高质量回答。这些话太通用了。更值得写进 Skill 的是任务特有的判断和边界当输入缺少业务规则时不要自行补全。必须先列出缺失信息再基于已有内容生成可确认的结果。涉及资金、权限、删除、审批类需求时必须提升风险等级。Skill 里真正值得保留的是触发条件任务边界专家判断禁止行为输出模板工具导航验证方式其他通用废话都应该删除。五、第四步高风险任务低自由度分析任务高自由度不同类型的 Skill对 Agent 的自由度要求不一样。不能所有任务都用同一种写法。高风险任务必须降低自由度比如批量修改代码数据库迁移线上配置修改删除文件CI/CD 发布权限策略调整这些任务不能让 Agent 自由发挥。Skill 里必须明确要求执行任何修改前必须先输出计划。计划必须包含修改文件、修改原因、影响范围、验证方式和回滚方案。未完成计划验证前不得直接执行修改。执行后必须运行验证命令。验证失败必须停止并输出失败原因和修复建议。这类 Skill 的核心是先控风险再做执行。这也是面试里很加分的点。因为它说明你不是简单“让 AI 干活”而是知道如何控制 Agent 的行为边界。分析类任务保留一定自由度比如技术方案评估代码 Review测试策略设计需求风险分析内容选题策划这些任务需要 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.md写核心流程、触发条件、资源导航references/放详细规则、检查清单、反模式templates/放输出模板、报告模板、用例模板scripts/放确定性校验、格式检查、数据处理逻辑这样做有几个好处主文件更短规则更容易维护细节可以按需读取脚本负责确定性动作Agent 不需要每次都消耗大量上下文这也是 Skill 工程化和普通 Prompt 最大的区别之一。普通 Prompt 解决的是一次对话效果。而 Skill 解决的是一类任务的稳定复用。八、第七步一定要关注 Skill 的触发质量很多人只关注 Skill 内容写得好不好却忽略了一个更基础的问题Agent 能不能在正确的时候调用这个 Skill一个 Skill 如果触发不稳定也很难算高质量。常见问题有两类。第一类是该触发时没触发。比如用户明明输入了根据这个 PRD 帮我生成测试用例。但 Agent 没有调用“测试用例生成 Skill”而是直接用普通对话方式回答。第二类是不该触发时乱触发。比如用户只是想简单问一个测试概念Agent 却误触发了复杂 Skill开始输出一大堆流程和表格。所以 Skill 的名称和描述非常重要。它们不是摆设而是 Agent 判断是否调用 Skill 的重要依据。一个好的 Skill 描述应该写清楚这个 Skill 用于根据 PRD、接口文档或业务需求生成结构化测试用例。适用于需要输出测试场景、优先级、风险点和自动化建议的任务。不适用于简单概念解释、单句润色或无需结构化测试设计的任务。注意这里不仅写了“什么时候用”还写了“什么时候不用”。这能减少误触发提高 Skill 的稳定性。九、第八步验证闭环是高质量 Skill 的关键很多 Skill 效果不稳定不是因为写得不够长而是因为没有验证闭环。一个高质量 Skill不能只写完成后输出结果。而应该写成完成初稿后必须根据 checklist 自检是否覆盖主流程是否覆盖异常流程是否覆盖边界条件是否标注优先级是否存在编造业务规则是否存在无法验证的结论是否给出自动化建议如果检查不通过必须先修正再输出最终结果。这就是反馈循环。对于能脚本化验证的内容最好交给脚本不要完全依赖模型自检。比如Markdown 表格格式检查JSON Schema 校验文件命名规范检查测试用例字段完整性检查链接有效性检查代码格式检查单元测试执行可以写一个简单的校验脚本import jsonimport sysREQUIRED_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 missingdef main(path):with open(path, “r”, encoding“utf-8”) as f:cases json.load(f)errors [] for index, case in enumerate(cases, start1): 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_asciiFalse, indent2)) sys.exit(1) print(json.dumps({ status: passed, case_count: len(cases) }, ensure_asciiFalse, indent2))ifname “main”:main(sys.argv[1])脚本最好对 Agent 友好要求原因输出 JSONAgent 更容易解析错误信息带修复建议Agent 能根据反馈自行修正尽量幂等避免重复调用导致结果混乱明确成功/失败状态方便决定是否进入下一步能降级就降级避免一个小问题导致整个任务中断这就是工程化 Skill 和普通提示词模板的核心差别。十、第九步用评测集验证 Skill而不是只看一次演示效果很多 Skill 在演示场景里看起来很好但换一个真实任务就失效。这类 Skill 其实不算高质量。验证 Skill一般可以分四步。先建立基线先不用 Skill让 Agent 直接做一次真实任务。记录它会犯哪些错误。比如漏掉异常场景输出格式不稳定优先级判断混乱编造不存在的业务规则只给结论不给依据忽略高风险操作没有验证步骤输出内容无法执行这些失败样本非常重要。因为它们就是后续 Skill 的评测用例。根据失败样本提取 Skill 初稿不要凭空写 Skill。应该从真实失败里提炼规则。Agent 原始问题Skill 里应该补什么经常漏异常场景增加异常场景 checklist喜欢编造规则增加“不允许补全缺失业务规则”输出格式不稳定增加固定输出模板结果无法验证增加验证脚本或自检清单高风险操作直接执行增加“先计划再执行”机制触发不稳定优化 Skill 的 name 和 description这种 Skill 不是拍脑袋写出来的而是从真实问题中长出来的。用新会话重新测试为什么要用新会话因为旧会话里有大量上下文可能会掩盖 Skill 本身的问题。真正的测试方式应该是新建会话只加载 Skill输入真实任务看 Agent 是否能稳定完成对比没有 Skill 时的结果如果新会话里效果明显更好说明 Skill 真的起作用了。持续迭代直到结果稳定Skill 不是一次写完的。它应该像测试用例、自动化脚本、代码库一样持续迭代。每次发现新问题都要判断是不是触发条件不清楚是不是反模式没写进去是不是模板不够明确是不是需要脚本验证是不是任务本身不适合 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 的人之间最明显的差距。
字节面试题：Agent 里的 Skill 到底怎么做才算高质量？
很多人做 Agent 项目最容易讲成这样接了大模型。加了工具调用。封装了一些 Prompt。支持多轮对话和任务执行。听起来好像没问题但真到大厂面试里面试官往往不会只问这些表层能力。他很可能继续追问一句你的 Agent 系统里面Skill 是怎么编写的 你怎么保证一个 Skill 是高质量的这个问题一出来很多人就容易卡住。因为如果你只回答Skill 就是把常用 Prompt 封装起来。这个答案基本不够。在真正的 Agent 工程里Skill 不是一段更长的提示词也不是一个漂亮的 Prompt 模板。它更像是一个可复用、可验证、可迭代的专家能力包。一个高质量 Skill至少要回答清楚几个问题什么时候应该触发什么时候不应该触发任务应该按什么流程执行遇到边界情况怎么判断哪些行为禁止做输出结果如何验证失败以后如何修正和迭代所以这道面试题真正考察的不是你会不会写 Prompt而是你有没有能力把专家经验沉淀成系统能力。一、面试官真正想听的不是“我会写 Skill”这道题表面上问的是 Skill实际上考察的是 Agent 工程化能力。可以拆成三层考察点面试官真正想听什么任务抽象能力你能否判断什么任务适合 Skill 化专家经验沉淀能力你能否把人的判断规则写进 Skill质量保障能力你有没有验证、评测和迭代机制所以回答这个问题时不要一上来就说“我会写 SKILL.md”。更好的回答方式是我不会把 Skill 简单理解成 Prompt 模板而是把它看成 Agent 系统中的可复用任务能力单元。 一个高质量 Skill 应该包含触发条件、专家决策逻辑、反模式约束、资源导航、模板脚本、验证闭环和持续迭代机制。 它的目标不是让 Agent 偶尔答得好而是让 Agent 在一类任务上稳定、可控、可复用地完成工作。这句话就是这道题的核心答案。二、第一步不是写 Skill而是判断任务值不值得 Skill 化很多团队刚开始做 Agent 时最容易犯一个错误什么任务都想封装成 Skill。最后 Skill 越写越多Agent 反而越来越难维护。因为 Skill 不是免费的。它需要写说明、配模板、放参考资料、维护脚本、做测试验证还要随着业务变化持续迭代。所以第一步不是写 Skill而是判断这个任务到底值不值得做成 Skill一般可以从三个维度判断。任务里有没有专家判断如果一个任务熟手和新手做出来差距很大那它通常适合做成 Skill。比如测试开发场景里根据 PRD 生成测试用例判断接口测试覆盖是否充分分析线上缺陷根因评估自动化用例是否值得写Review 测试报告是否可信判断一次发版有没有高风险点这些任务不是简单执行步骤而是包含大量经验判断。新手可能只会根据需求写几个正常流程。但有经验的测试开发会继续追问有没有异常流程有没有边界条件有没有权限问题有没有数据一致性问题有没有幂等问题有没有灰度和回滚风险哪些场景适合自动化哪些场景反而不值得自动化这些判断才是 Skill 最值得沉淀的部分。Skill 的价值不是让 Agent “照着做”而是让 Agent 具备接近专家的判断框架。任务是不是足够复杂如果一个任务一句 Prompt 就能说清楚通常没必要做成 Skill。比如帮我润色这段话。这种任务直接写 Prompt 就够了。但如果任务变成根据 PRD、接口文档、历史缺陷和业务规则生成高质量测试用例并标注优先级、风险点、自动化建议和验收标准。这就明显复杂很多。因为它涉及输入信息抽取业务流程理解测试场景拆解风险识别优先级判断自动化价值评估输出格式约束质量自检这种任务就很适合沉淀成 Skill。任务会不会反复出现Skill 的核心价值是复用。如果一个任务只做一次没必要封装。但如果团队每天、每周都在做类似事情就很值得 Skill 化。比如每个需求都要写测试用例每次发版都要做风险评估每次接口变更都要补充自动化用例每次线上事故都要做缺陷复盘每次代码提交都要做质量 Review这些任务一旦沉淀成 Skill长期收益会非常明显。可以总结成一个判断公式适合做成 Skill 的任务 反复出现足够复杂有专家判断对输出质量有要求反过来如果只是简单、低频、一次性的任务就不要强行做成 Skill。Skill 不是越多越好能稳定解决高价值重复问题才重要。三、第二步Skill 不是把流程写长而是把判断写清楚很多人写 Skill会犯一个很典型的问题把 Skill 写成一大段说明书。里面写了很多背景、理念、注意事项看起来很完整但 Agent 真正执行时抓不住重点。高质量 Skill 的关键不是写得多而是写得准。尤其要提取三类内容专家决策树反模式约束模板和示例提取专家决策树Skill 最重要的价值是告诉 Agent什么情况下走方案 A什么情况下切到方案 B什么情况下必须停止什么情况下需要补充信息什么情况下只能给建议不能直接执行比如一个“测试用例生成 Skill”不能只写根据需求生成测试用例。这句话太泛了。更好的写法应该是当需求描述包含完整业务流程时先生成主流程用例再补充异常流程最后补充边界、权限、数据一致性和幂等场景当需求描述不完整时不要编造不存在的业务规则先标记缺失信息再基于已有信息生成可确认的用例草稿当需求涉及支付、权限、资金、删除、审批时必须标记为高风险需求必须补充回滚、审计、重复提交、异常中断场景这才是真正有价值的 Skill。因为它不是简单告诉 Agent 做什么而是告诉 Agent 怎么判断。提取反模式明确不要做什么在 Agent 系统里“不要做什么”往往比“要做什么”更重要。因为大模型很容易为了完成任务而过度发挥。比如为了让答案完整补充不存在的信息为了快速给结论跳过验证步骤为了显得专业写很多无法落地的套话为了执行任务直接修改高风险文件为了覆盖全面输出一堆没有优先级的内容所以 Skill 里必须明确反模式。例如不要把来源不明的信息当成事实写进结果。不要为了让答案完整擅自补充不存在的业务规则。不要在高风险操作中直接修改文件必须先生成计划。不要跳过验证步骤直接给最终结论。不要只覆盖正常流程必须补充异常、边界、权限和数据一致性场景。不要输出无法执行、无法验证的空泛建议。这类约束能明显降低 Agent 的幻觉和误操作。尤其是在测试开发、代码修改、数据库变更、自动化执行这类场景里反模式非常关键。提供模板和示例保证输出稳定如果任务对输出结构要求很高就应该提供模板。比如测试用例模板用例编号场景类型测试点前置条件操作步骤预期结果优先级自动化建议如果任务对表达风格、分析深度要求很高就应该提供示例。比如缺陷复盘 Skill 可以给出这样的结构一、问题现象二、影响范围三、复现路径四、根因分析五、风险等级六、修复方案七、回归验证点八、后续预防措施模板解决的是格式稳定。示例解决的是表达稳定。两者结合才能让 Skill 的输出质量更可控。四、第三步写 Skill 指令时要控制上下文成本一个常见误区是Skill 写得越详细效果越好。其实不一定。Skill 不是独占上下文的。它要和系统提示词、用户输入、历史对话、工具说明、其他 Skill 一起共享上下文窗口。如果 Skill 里塞满了模型本来就知道的通用知识反而会浪费上下文。例如下面这种内容价值就不高你是一个专业、严谨、负责的智能助手。你需要认真分析用户需求。你需要给出高质量回答。这些话太通用了。更值得写进 Skill 的是任务特有的判断和边界当输入缺少业务规则时不要自行补全。必须先列出缺失信息再基于已有内容生成可确认的结果。涉及资金、权限、删除、审批类需求时必须提升风险等级。Skill 里真正值得保留的是触发条件任务边界专家判断禁止行为输出模板工具导航验证方式其他通用废话都应该删除。五、第四步高风险任务低自由度分析任务高自由度不同类型的 Skill对 Agent 的自由度要求不一样。不能所有任务都用同一种写法。高风险任务必须降低自由度比如批量修改代码数据库迁移线上配置修改删除文件CI/CD 发布权限策略调整这些任务不能让 Agent 自由发挥。Skill 里必须明确要求执行任何修改前必须先输出计划。计划必须包含修改文件、修改原因、影响范围、验证方式和回滚方案。未完成计划验证前不得直接执行修改。执行后必须运行验证命令。验证失败必须停止并输出失败原因和修复建议。这类 Skill 的核心是先控风险再做执行。这也是面试里很加分的点。因为它说明你不是简单“让 AI 干活”而是知道如何控制 Agent 的行为边界。分析类任务保留一定自由度比如技术方案评估代码 Review测试策略设计需求风险分析内容选题策划这些任务需要 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.md写核心流程、触发条件、资源导航references/放详细规则、检查清单、反模式templates/放输出模板、报告模板、用例模板scripts/放确定性校验、格式检查、数据处理逻辑这样做有几个好处主文件更短规则更容易维护细节可以按需读取脚本负责确定性动作Agent 不需要每次都消耗大量上下文这也是 Skill 工程化和普通 Prompt 最大的区别之一。普通 Prompt 解决的是一次对话效果。而 Skill 解决的是一类任务的稳定复用。八、第七步一定要关注 Skill 的触发质量很多人只关注 Skill 内容写得好不好却忽略了一个更基础的问题Agent 能不能在正确的时候调用这个 Skill一个 Skill 如果触发不稳定也很难算高质量。常见问题有两类。第一类是该触发时没触发。比如用户明明输入了根据这个 PRD 帮我生成测试用例。但 Agent 没有调用“测试用例生成 Skill”而是直接用普通对话方式回答。第二类是不该触发时乱触发。比如用户只是想简单问一个测试概念Agent 却误触发了复杂 Skill开始输出一大堆流程和表格。所以 Skill 的名称和描述非常重要。它们不是摆设而是 Agent 判断是否调用 Skill 的重要依据。一个好的 Skill 描述应该写清楚这个 Skill 用于根据 PRD、接口文档或业务需求生成结构化测试用例。适用于需要输出测试场景、优先级、风险点和自动化建议的任务。不适用于简单概念解释、单句润色或无需结构化测试设计的任务。注意这里不仅写了“什么时候用”还写了“什么时候不用”。这能减少误触发提高 Skill 的稳定性。九、第八步验证闭环是高质量 Skill 的关键很多 Skill 效果不稳定不是因为写得不够长而是因为没有验证闭环。一个高质量 Skill不能只写完成后输出结果。而应该写成完成初稿后必须根据 checklist 自检是否覆盖主流程是否覆盖异常流程是否覆盖边界条件是否标注优先级是否存在编造业务规则是否存在无法验证的结论是否给出自动化建议如果检查不通过必须先修正再输出最终结果。这就是反馈循环。对于能脚本化验证的内容最好交给脚本不要完全依赖模型自检。比如Markdown 表格格式检查JSON Schema 校验文件命名规范检查测试用例字段完整性检查链接有效性检查代码格式检查单元测试执行可以写一个简单的校验脚本import jsonimport sysREQUIRED_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 missingdef main(path):with open(path, “r”, encoding“utf-8”) as f:cases json.load(f)errors [] for index, case in enumerate(cases, start1): 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_asciiFalse, indent2)) sys.exit(1) print(json.dumps({ status: passed, case_count: len(cases) }, ensure_asciiFalse, indent2))ifname “main”:main(sys.argv[1])脚本最好对 Agent 友好要求原因输出 JSONAgent 更容易解析错误信息带修复建议Agent 能根据反馈自行修正尽量幂等避免重复调用导致结果混乱明确成功/失败状态方便决定是否进入下一步能降级就降级避免一个小问题导致整个任务中断这就是工程化 Skill 和普通提示词模板的核心差别。十、第九步用评测集验证 Skill而不是只看一次演示效果很多 Skill 在演示场景里看起来很好但换一个真实任务就失效。这类 Skill 其实不算高质量。验证 Skill一般可以分四步。先建立基线先不用 Skill让 Agent 直接做一次真实任务。记录它会犯哪些错误。比如漏掉异常场景输出格式不稳定优先级判断混乱编造不存在的业务规则只给结论不给依据忽略高风险操作没有验证步骤输出内容无法执行这些失败样本非常重要。因为它们就是后续 Skill 的评测用例。根据失败样本提取 Skill 初稿不要凭空写 Skill。应该从真实失败里提炼规则。Agent 原始问题Skill 里应该补什么经常漏异常场景增加异常场景 checklist喜欢编造规则增加“不允许补全缺失业务规则”输出格式不稳定增加固定输出模板结果无法验证增加验证脚本或自检清单高风险操作直接执行增加“先计划再执行”机制触发不稳定优化 Skill 的 name 和 description这种 Skill 不是拍脑袋写出来的而是从真实问题中长出来的。用新会话重新测试为什么要用新会话因为旧会话里有大量上下文可能会掩盖 Skill 本身的问题。真正的测试方式应该是新建会话只加载 Skill输入真实任务看 Agent 是否能稳定完成对比没有 Skill 时的结果如果新会话里效果明显更好说明 Skill 真的起作用了。持续迭代直到结果稳定Skill 不是一次写完的。它应该像测试用例、自动化脚本、代码库一样持续迭代。每次发现新问题都要判断是不是触发条件不清楚是不是反模式没写进去是不是模板不够明确是不是需要脚本验证是不是任务本身不适合 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 的人之间最明显的差距。
