1. 项目概述从“猜谜”到“执行”的智能体技能设计革命最近在琢磨一个事儿我们花大价钱调用大模型API结果很多时候模型都在那儿“猜”我们想让它干嘛。让它写个FastAPI接口它可能先花几百个token去回忆路由定义的最佳实践让它生成一份技术报告它又得从头构思报告的结构和语气。这种“重复造轮子”式的思考是项目里token消耗的隐形杀手也是智能体行为不可控、输出质量参差不齐的根源。这问题其实谷歌的工程师们早就注意到了。最近深入研究了一下谷歌ADKAgent Development Kit团队的专家Lavi Nigam分享的实战经验他提炼出了一套名为“SKILL.md设计模式”的方法论。这套东西不是什么高深的理论而是五个可以直接抄作业的生产级模式核心目标就俩精准触发智能体的正确行为同时把没必要的token浪费砍到最低。简单来说传统的提示工程Prompt Engineering像是在给一个非常聪明但缺乏经验的新手下达模糊指令结果它可能用80%的精力去理解“潜规则”只用20%的精力干活。而这套SKILL.md模式则是为这位新手配备了一套标准化的“工作手册”和“工具包”。当需要处理特定任务时智能体不再是凭空猜测而是直接调用对应的“技能包”里面已经封装好了这个领域的所有规则、模板和检查清单。这样一来它就能立刻进入“专家模式”把全部算力用在刀刃上。对于开发者而言这意味着三件事第一智能体的行为变得可预测、可管理输出质量稳定第二团队协作时技能的定义和书写有了统一规范沟通成本大大降低第三也是最重要的通过“渐进式知识加载”只在需要时才加载具体的规则或模板能戏剧性地减少上下文窗口的占用从而降低token消耗和API成本。接下来我们就逐一拆解这五个能立刻用起来的模式。2. 五大核心技能设计模式深度解析2.1 模式一工具封装者——让智能体秒变领域专家核心思路与适用场景“工具封装者”模式是这五个模式中最基础、也最常用的一种。它的核心思想是知识封装与即时应用。我们不再在每次提示词里罗列冗长的规则而是将这些规则、惯例、最佳实践写在一个独立的规范文件如conventions.md里。SKILL.md文件只做两件事定义何时触发这个技能以及告诉智能体去加载和应用哪个规范文件。这特别适合那些有明确“规矩”的领域。比如你们团队有一套严格的FastAPI路由命名规范、响应模型定义标准或者公司在使用Terraform时对资源命名、模块结构有统一要求又或者是数据库查询优化、内部API设计指南等。这些知识是静态的、共识性的但让模型每次临时回忆既低效又容易出错。文件结构与运作机制它的目录结构极其简洁my-skill/ ├── SKILL.md # 技能入口触发关键词 加载指令 └── references/ └── conventions.md # 具体的领域规则和最佳实践SKILL.md文件就像一个轻量级的调度器。它的description字段至关重要因为这是智能体用来匹配用户请求的“搜索索引”。这里必须包含具体、明确的业务关键词。例如如果你的技能是关于FastAPI的description里就一定要有 “FastAPI”, “routing”, “dependency injection”, “Pydantic models” 等词。过于模糊的描述会导致技能无法被正确触发。一个实战案例FastAPI专家模式假设我们要创建一个“FastAPI代码规范专家”技能。首先我们在references/fastapi-conventions.md文件中详细定义规则例如所有路由路径使用小写字母和连字符如/api/v1/user-profiles。响应模型必须显式定义并使用response_model参数。依赖注入函数需包含完整的类型提示和文档字符串。错误处理应使用FastAPI的HTTPException并包含明确的错误码和信息。然后对应的SKILL.md文件如下--- name: fastapi-expert description: 当用户需要编写FastAPI代码、定义路由或使用依赖注入时触发。帮助生成符合团队内部最佳实践的FastAPI代码。 --- # FastAPI专家模式 ## 激活规则 1. 加载参考文档references/fastapi-conventions.md 2. 确保所有生成的FastAPI代码严格遵守该文档中定义的约定。当用户提出“帮我写一个用户登录的API端点”时智能体识别到“FastAPI”、“API端点”等关键词触发此技能。它首先加载轻量级的SKILL.md指令然后按指令去加载fastapi-conventions.md文件中的具体规则随后生成的代码就会天然符合团队规范无需在每次对话中重复灌输规则。关键心得description字段的撰写是门艺术。要站在用户的角度思考他们会用什么词来提问同时避免过于宽泛。比如“写代码”就太泛而“写FastAPI路由代码”就精准得多。这是确保技能在正确时机被激活的第一道闸门。2.2 模式二生成器——在创意与规范间取得平衡核心思路与适用场景当你的需求不仅仅是遵守规则还需要产出结构高度一致的文档或内容时“生成器”模式就该上场了。它解决了“既有固定格式要求又需保证内容质量”的矛盾。其核心在于分离“结构”与“风格”assets/目录下的模板文件定义了输出的骨架必须有哪些章节、段落而references/目录下的风格指南则控制了填充骨架的血肉用什么语气、格式、术语。这个模式适用于所有需要标准化输出的场景。例如技术分析报告、API参考文档、标准化的Git提交信息、智能体脚手架代码、周报/月报模板等。选择此模式意味着你对结构一致性的要求高于对内容创造性的要求。它确保无论谁或哪个智能体来执行产出的文档在形式上都是统一的极大方便了后续的归档、审阅和自动化处理。文件结构与双轨控制典型的目录结构如下my-skill/ ├── SKILL.md ├── assets/ │ └── report-template.md # 输出结构模板规定章节 └── references/ └── style-guide.md # 语气与格式风格指南assets/report-template.md可能长这样# [此处填入报告标题] ## 1. 概述 - **背景**[...] - **目标**[...] ## 2. 核心分析 - **数据**[...] - **发现**[...] ## 3. 结论与建议 - **主要结论**[...] - **后续行动**[...]而references/style-guide.md则规定使用客观、专业的语气避免主观臆断。数据部分优先使用表格呈现。建议部分使用“建议1...”的列表形式每条建议以动词开头。专业术语需与公司术语表保持一致。运作流程与优势当技能被触发后智能体首先理解用户需求的核心内容然后按照模板的结构将内容填充到对应的章节中并在此过程中严格遵守风格指南的要求。这样做的好处是即使面对一个复杂报告的需求智能体也无需消耗token去“构思报告该怎么写”它只需要专注于“如何把已有信息填入既定格式”并确保表达方式符合要求。这既提升了效率又保证了质量的下限。实操要点模板的设计要足够灵活在保持结构的同时为可变内容留下清晰的位置标识如[此处填入...]。风格指南则应具体最好能给出正面和反面的例子让智能体有更明确的参照。例如与其说“语气要专业”不如说“应使用‘经分析表明’而非‘我觉得’”。2.3 模式三审查者——将质量检查流程化与标准化核心思路与适用场景“审查者”模式的核心是分离“检查项”与“检查方法”。它将“要检查什么”一份详尽的检查清单和“如何进行检查与报告”一个审查协议解耦。SKILL.md文件定义了审查的流程和报告格式而references/下的检查清单文件则列出了所有需要核对的规则并按严重性分组。这种模式威力巨大因为它使得同一个“审查”技能框架只需更换不同的检查清单就能瞬间变为针对不同目标的审查专家。它完美适用于所有需要基于明确标准进行评价、打分或审计的任务。例如代码审查检查编码规范、安全漏洞、Python类型注解完整性检查、异常处理完备性评估、内容审核技术文档格式、术语一致性、API文档审查参数描述、示例代码等。文件结构与输出范式结构依然清晰my-skill/ ├── SKILL.md # 审查协议如何加载、应用、报告检查清单 └── references/ └── review-checklist.md # 检查清单按严重性分组的规则列表SKILL.md中的审查协议会指令智能体“加载指定的检查清单逐项评估目标内容并按照以下格式输出发现的问题”。而输出的格式通常是标准化的例如等级含义示例❌ 错误必须修复影响功能或安全SQL注入风险、未处理的异常、硬编码密钥⚠️ 警告建议修复影响代码质量缺少类型提示、命名不规范、函数过于复杂ℹ️ 提示可选的改进建议注释不完整、逻辑可提取为独立函数一个安全审计技能的构建实例假设我们要构建一个“基础安全审计”技能。我们在references/security-checklist.md中定义清单❌ 错误检测到疑似硬编码的密码或API密钥发现未经参数化处理的SQL查询字符串。⚠️ 警告输入验证缺失错误信息可能泄露系统内部细节。ℹ️ 提示建议使用更安全的哈希算法敏感日志未脱敏。当对一段代码运行此技能时智能体会像一位安全专家一样逐条核对清单并将发现的问题归类到上述三个严重性等级中输出。这种结构化的输出让开发者能快速定位高危问题极大提升了审查效率和行动针对性。经验之谈检查清单的编写质量直接决定审查效果。规则应尽可能具体、可操作。避免“代码要清晰”这样的模糊描述而应写成“单个函数长度不应超过50行”或“循环嵌套深度不应超过3层”。同时合理划分严重性等级是关键避免将所有问题都标为“错误”导致重点被淹没。2.4 模式四反转者——让智能体学会提问而非臆测核心思路与适用场景前三个模式主要优化了智能体“执行”任务的方式而“反转者”模式则彻底改变了交互的启动方式。它的核心思想是角色反转由智能体主动提问来驱动对话。在技能开始时智能体不立即开始构建或生成内容而是根据预设的问题列表主动向用户提问以收集完成任务所必需的关键上下文信息。这个模式专治智能体的“盲目假设”和“自以为是”。当任务成功与否高度依赖于一些模糊的、个性化的、或未在初始请求中阐明的信息时就必须使用此模式。典型场景包括项目需求收集、系统故障诊断引导、基础设施配置向导、生成定制化报告前的信息收集等。它能有效防止智能体基于不完整或错误的假设生成大量无用输出从而从源头上减少token浪费。三阶段流程与控制指令一个完整的反转者模式技能通常遵循“提问-收集-执行”的三阶段流程提问阶段智能体根据SKILL.md中的定义提出一系列结构化问题。收集阶段等待并解析用户的回答。执行阶段基于收集到的完整信息开始执行核心任务可能是调用另一个生成器或工具封装者技能。这里有一个必须明确写在SKILL.md中的关键控制指令DO NOT start building until all phases are complete.在所有阶段完成前切勿开始构建。这条指令是防止智能体“抢跑”的保险丝。实战项目需求收集专家假设我们创建一个“软件项目需求收集”技能。其SKILL.md的核心部分如下# 项目需求收集专家 你是一个经验丰富的产品分析师。在开始任何方案设计前你必须首先澄清以下关键信息。请依次提问并等待用户逐一回答。 **核心指令在收集到以下所有信息之前绝对不要开始设计解决方案或编写代码** 1. 项目的主要目标是什么要解决用户什么核心痛点请用一句话概括 2. 目标用户是谁例如内部员工、特定年龄段的消费者、开发者 3. 有哪些必须实现的**核心功能**请列出至少3项 4. 是否有必须遵循的技术栈或集成约束例如必须使用Python必须与XX系统对接 5. 项目预期的里程碑或截止日期是什么 *请依次提出上述问题并在获得每个问题的明确答复后再继续下一个。*通过这种方式智能体引导用户完成一次结构化的需求访谈确保后续所有工作都建立在坚实、清晰的基础上避免了因误解需求而导致的返工和资源浪费。避坑指南问题的设计要循序渐进从宏观到微观。避免一次性抛出所有问题这会让用户感到压力。可以设计成交互式的根据上一个问题的答案动态决定下一个问题的深度。例如当用户说“目标用户是开发者”时下一个问题可以深入问“是前端、后端还是全栈开发者”2.5 模式五流水线——为复杂任务构建严格的工作流核心思路与适用场景“流水线”模式是五个模式中最强大、也最复杂的一个用于管理具有严格顺序依赖关系的多步骤任务。它将一个复杂的业务流程分解为一系列离散的步骤并在步骤之间设立明确的“关卡”。每个关卡都有一个必须满足的“继续条件”只有当前步骤成功完成且条件满足流程才能进入下一步。这就像在软件开发中的CI/CD流水线代码必须通过编译、测试、代码审查等多个关卡才能部署。此模式适用于任何步骤环环相扣、且中间需要人工确认或自动验证的场景。例如代码文档生成解析代码 - 用户确认 - 生成文档 - 质量检查、数据清洗管道去重 - 格式化 - 验证 - 输出、代码部署工作流代码审查 - 自动化测试 - 构建发布 - 线上验证、多级审批流程等。文件结构与关卡控制流水线模式的目录结构最为完整因为它可能综合运用前几种模式my-skill/ ├── SKILL.md # 步骤定义 关卡控制逻辑 ├── references/ # 各步骤的参考规范可能包含检查清单、风格指南 ├── assets/ # 输出模板 └── scripts/ # 可选的自动化脚本如调用外部工具SKILL.md是流水线的“总控程序”。每个步骤的定义都遵循一个包含“关卡”的模板## 步骤 N: [步骤名称] [步骤的具体描述和操作指令] *关卡在满足 [某个具体条件] 之前**切勿**进入步骤 N1* *如果任何步骤被跳过或失败则不要继续。*关卡条件的类型关卡条件是流水线的精髓常见的有用户确认直到用户明确批准当前结果质量验证直到代码审查通过所有❌错误项检查数据就绪直到输入数据通过完整性校验外部信号直到收到构建成功的通知一个简单的文档生成流水线示例## 步骤1: 解析代码结构 分析提供的源代码文件提取所有公开的类、函数及其签名、参数和返回值类型。 *关卡完成解析并列出所有找到的组件等待用户确认列表是否完整准确。* ## 步骤2: 生成草稿文档 根据步骤1确认的列表为每个组件生成初步的文档草稿。 *关卡草稿生成完毕等待用户审阅。* ## 步骤3: 应用格式规范 加载 references/doc-style-guide.md将步骤2的草稿格式化为公司标准。 *关卡格式化完成并自动运行 scripts/spell-check.js 进行拼写检查直到无错误。* ## 步骤4: 最终输出 将格式化后的文档按照 assets/api-doc-template.md 的模板组装成最终文档。这个流水线确保了没有用户的确认就不会生成文档没有通过拼写检查就不会最终输出。每一步都坚实可靠。设计心得设计流水线时最难的是确定步骤的粒度。步骤太粗关卡失去意义步骤太细流程会显得繁琐。一个好的原则是每一个步骤都应该产生一个明确的、可验证的中间产物而关卡就是对这个产物的质量门禁。同时务必在SKILL.md开头强调“任何步骤失败则停止”的总原则防止错误累积。3. 模式选择与组合实战指南3.1 如何选择正确的起点快速决策指南面对一个具体的任务如何从这五个模式中选出最合适的一个作为起点你可以遵循下面这个快速决策流程问自己第一个问题我的主要目的是让智能体掌握并应用一套固定的知识或规则吗如果是- 选择 工具封装者。这是最轻量、最直接的模式适用于封装团队惯例、工具库规范、API设计准则等静态知识。复杂度低见效快。如果否问第二个问题我是否需要智能体产出结构高度固定、格式统一的文档或内容如果是- 选择 生成器。当你对报告、文档、消息的章节、段落顺序有严格要求时这个模式能保证输出的一致性。它平衡了结构约束与内容创作。如果否问第三个问题我的任务本质上是根据一套标准对现有内容进行评审、打分或审计吗如果是- 选择✅ 审查者。这个模式将“检查清单”与“检查流程”分离非常适合代码审查、安全扫描、内容质检等评估类任务。输出通常是分等级错误/警告/提示的问题列表。如果否问第四个问题智能体在开始工作前是否必须从用户那里获取一些关键的、非预设的上下文信息如果是- 选择❓ 反转者。这个模式能有效防止智能体“瞎猜”通过先提问的方式确保后续所有工作都基于准确的信息。适用于需求收集、故障诊断等场景。如果以上都不是或者任务明显包含多个有严格顺序的步骤且步骤间存在依赖关系- 选择 流水线。这是最复杂的模式用于编排多步骤工作流并在步骤间设置强制性的“关卡”如用户确认、质量检查。给新手的建议如果你不确定永远从“工具封装者”开始。它最简单能让你快速体会到将知识外化的好处。当你发现需要固定输出格式时再升级到“生成器”当需要增加评审能力时再引入“审查者”模式。渐进式地构建你的技能库。3.2 模式组合的最佳实践与高级技巧在实际的生产系统中复杂的业务需求往往需要组合多个模式形成更强大的解决方案。单一模式可能只解决一个环节的问题而组合模式能覆盖端到端的业务流程。常见的黄金组合流水线 审查者这是质量控制的标准范式。在一个生成或处理流程的末尾设置一个审查步骤作为关卡。例如在“代码生成流水线”的最后一步加入一个“代码安全与规范审查”技能只有审查通过无❌级错误流水线才算完成。这确保了输出物的质量下限。生成器 反转者先收集后生成。这是制作个性化报告的完美组合。首先使用“反转者”技能通过一系列问题收集用户的特定需求、偏好和数据然后将收集到的信息传递给“生成器”技能填充到预设的模板中生成一份完全定制化的报告。这避免了生成通用报告后再进行大量修改的浪费。流水线 反转者 生成器这是一个完整的端到端业务流。文章开头提到的“电商选品”案例就是典范。Step 1用“反转者”收集用户需求预算、受众等Step 2可以内嵌一个“审查者”来评估潜在产品Step 3设置关卡等待用户确认Step 4用“生成器”产出最终选品报告。整个流程逻辑严密用户参与感强输出质量高。组合时的关键设计原则明确职责边界每个技能模块应该只做好一件事。让“反转者”专注提问让“生成器”专注填充模板让“审查者”专注检查。通过“关卡”传递数据在流水线模式中上一个步骤的输出如收集到的需求、生成的草稿应作为上下文清晰地传递给下一个步骤。可以在SKILL.md中用类似“使用步骤1中收集到的需求信息”来指明。保持技能可复用设计时尽量让每个技能如一个独立的“审查者”本身是完整且可复用的。这样它既可以单独使用也可以被轻松地嵌入到不同的流水线中。3.3 实现极致效率渐进式知识加载策略这是谷歌这套方法论中降低Token消耗最核心、最有效的技术。其原理很简单不要一次性把所有知识都塞进模型的上下文窗口而是按需加载。让我们拆解一个组合技能如上述电商选品流水线的Token加载过程阶段加载的内容大致Token成本说明技能激活时SKILL.md中的描述和基础指令~100 tokens仅加载最轻量的“技能索引”和流程概览。模型只知道有个“选品流水线”以及第一步该干嘛。执行步骤1反转者步骤1的详细提问脚本~50-100 tokens加载如何提问的指令。此时还不需要产品评估标准或报告模板。执行步骤2审查者加载references/product-evaluation-checklist.md按文件大小而定仅在需要评估产品时才加载具体的评估清单。如果第一步发现用户需求不匹配可能直接跳过此步这份清单的Token就省下了。执行步骤4生成器加载assets/selection-report-template.md按文件大小而定仅在生成最终报告时才加载模板。如果流程在前几步中止这份模板的Token同样被节省。与传统方式的对比传统做法可能在一个超长的提示词中同时包含提问话术、评估清单和报告模板。即使流程在第一步后就结束后面两部分内容的Token也已经消耗且无法收回。而渐进式加载确保了为每一步操作支付的Token成本都精确地用于该步骤的实际执行避免了巨大的前期浪费。对于包含大量参考文档的复杂技能这种节省是指数级的。高级技巧为了最大化渐进式加载的效益在编写references/和assets/下的文件时也要注意内容的模块化和简洁性。将大的文档拆分成逻辑独立的小文件使得加载更加精准。例如将“安全审查清单”拆分为“输入验证清单”、“加密清单”、“错误处理清单”这样在审查不同侧重点的代码时可以加载更相关的部分。4. 从理论到实践构建一个电商选品流水线全案例现在让我们将上述所有模式融合亲手构建一个文章开头提到的“电商选品流水线”实战案例。这个案例将串联“反转者”、“审查者”、“生成器”三种模式并由“流水线”模式进行总控。4.1 场景定义与技能设计业务场景作为一个电商运营或选品人员你需要从海量商品中筛选出有潜力的产品。这个过程通常包括明确选品目标如受众、预算、根据一套标准初步评估产品、与团队或自己确认评估结果、最后形成一份结构化的选品报告。技能设计目标创建一个智能体技能引导用户完成上述完整流程确保每一步都基于充分的信息和确认最终产出一份高质量、标准化的报告。4.2 目录结构与文件职责首先创建我们的技能目录ecommerce-product-selector/结构如下ecommerce-product-selector/ ├── SKILL.md # 核心流水线总控指令 ├── references/ │ └── product-evaluation-checklist.md # 审查者模式产品评估标准 └── assets/ └── selection-report-template.md # 生成器模式最终报告模板每个文件扮演不同角色SKILL.md是整个技能的大脑定义了四个步骤的流程、关卡以及何时调用其他文件。references/product-evaluation-checklist.md是技能的知识库封装了“好产品”的评估维度。assets/selection-report-template.md是技能的产出模具规定了报告长什么样。4.3 核心文件实现详解1. 产品评估检查清单 (references/product-evaluation-checklist.md)这份清单是“审查者”模式的灵魂它必须具体、可衡量。我们按严重性等级来组织# 电商产品评估标准清单 请根据以下标准对候选产品进行评分并将问题归类。 ## ❌ 致命缺陷一票否决 - **法律与合规风险**产品是否存在侵权专利、商标、版权、安全认证缺失、或违反目标市场法规的风险 - **供应链硬伤**最小起订量是否远超预算供货周期是否不稳定60天是否为单一货源且无替代供应商 - **利润空间为负**初步估算售价 - 采购成本 - 平台佣金 - 物流费 - 税费后毛利率是否低于5% ## ⚠️ 高风险项需重点评估 - **市场竞争度**在目标平台如亚马逊、Shopify上同类产品是否已存在大量高度相似、排名靠前的竞品 - **产品差异化难度**产品是否属于完全通用的“白牌”商品难以通过包装、功能微创新或营销形成差异化 - **物流复杂度**产品是否易碎、超大、超重或属于危险品导致物流成本高昂或仓储困难 - **季节性波动**产品需求是否具有极强的季节性可能导致长期库存积压 ## ✅ 潜在优势项加分项 - **趋势与热度**社交媒体如TikTok, Instagram或谷歌趋势是否显示该产品关键词搜索量近期呈上升趋势 - **受众明确**产品是否针对一个需求明确、有付费意愿的利基受众群体 - **附加价值空间**产品是否易于组合销售、提供订阅服务或搭配高利润配件 - **用户口碑基础**类似产品在现有平台上的平均评分是否高于4.3星满分5星2. 选品报告模板 (assets/selection-report-template.md)这份模板是“生成器”模式的骨架它定义了最终输出的结构# 电商产品选品分析报告[产品名称] **报告生成日期** [日期] **目标市场** [来自步骤1] ## 一、选品需求摘要 - **目标受众** [来自步骤1] - **预算范围** [来自步骤1] - **品类偏好** [来自步骤1] ## 二、产品评估详情 ### 2.1 基础信息 - **产品名称/链接** [产品信息] - **采购成本** [成本信息] - **预估售价** [售价信息] - **预估毛利率** [计算过程与结果] ### 2.2 评估结果概览 此处自动汇总根据检查清单识别的❌、⚠️、✅项数量 ### 2.3 关键发现与风险分析 - **致命缺陷分析** [逐条分析❌项若无可写“无”] - **高风险项分析** [逐条分析⚠️项及其缓解可能性] - **核心优势分析** [阐述✅项带来的市场机会] ## 三、综合建议与下一步行动 - **总体推荐度** 例如推荐 / 谨慎推荐 / 不推荐 - **主要决策依据** [综合上述分析给出1-2条核心决策理由] - **建议的下一步** 1. [行动项1如联系3家备用供应商核实供货能力] 2. [行动项2如制作小批量样品进行用户体验测试]3. 流水线总控文件 (SKILL.md)这是最核心的文件它将所有部分串联起来--- name: ecommerce-product-selector description: 帮助进行电商产品选品、市场分析、利润计算并生成标准选品报告。当用户需要寻找或评估电商产品时触发。 metadata: pattern: Pipeline domain: E-commerce --- # 电商产品选品工作流 你是一名专业的电商产品选品专家。请严格按照以下顺序执行步骤不得跳跃。 **核心规则在完成所有阶段之前切勿开始生成产品选品方案如果任何步骤被跳过或失败则不要继续。** ## 步骤1收集需求反转者模式 主动向用户提问以收集选品背景信息。请按顺序提出以下问题并等待用户对每个问题作出回答 1. 本次选品的目标受众是谁例如北美25-34岁都市女性、家居DIY爱好者 2. 单件产品的预算成本范围是多少你期望的毛利率是多少 3. 是否有特别关注的品类或已有的供应链优势 4. 主要计划在哪个或哪些电商平台销售 *关卡必须获得用户对以上所有问题的明确答复后方可进入步骤2。如果用户无法提供任何一项信息请友好地说明该信息对后续评估至关重要并尝试引导其给出估算或范围。* ## 步骤2评估产品审查者模式 现在请用户提供1-3个待评估的具体产品信息如名称、链接、初步了解的采购价等。 针对每一个产品执行以下操作 1. 加载并应用评估标准references/product-evaluation-checklist.md 2. 根据清单中的每一条标准分析该产品。将发现的问题或优势归类为 ❌ 致命缺陷、⚠️ 高风险项 或 ✅ 潜在优势项。 3. 为每个产品提供一份简明的评估小结。 *关卡完成对所有指定产品的评估分析后进入步骤3。* ## 步骤3用户确认流水线关卡 向用户清晰展示步骤2的评估结果。对于每个产品列出其主要的❌、⚠️、✅项。 然后询问用户“基于以上初步分析您希望针对哪个产品继续深入并生成完整的选品报告” *关卡必须获得用户明确指定一个产品后方可进入最终步骤。如果用户想评估新的产品则返回步骤2。* ## 步骤4生成最终报告生成器模式 针对用户确认的产品生成最终报告 1. 加载报告模板assets/selection-report-template.md 2. 将步骤1收集的需求信息、步骤2对该产品的详细评估结果严格填充到模板的对应部分。 3. 确保报告格式工整分析逻辑连贯并最终给出明确的“综合建议与下一步行动”。 报告生成后将其完整呈现给用户。4.4 技能运作流程与价值分析当用户触发此技能时将经历以下交互需求澄清智能体化身“顾问”先问清预算、受众等关键问题。这避免了它基于错误假设推荐奢侈品给预算有限的用户。专业评估智能体化身“分析师”用专业的检查清单扫描产品识别出看不见的风险如侵权风险和潜在机会。决策确认智能体化身“协调者”将评估结果可视化让用户参与决策选择深入分析的对象。报告生成智能体化身“助理”将前几步的所有信息合成一份结构专业、内容翔实的标准报告。这个案例的价值在于降低浪费如果用户在第一步就说“预算只有10美元”那么所有高价产品的评估Token都被省下了。渐进式加载在此充分发挥作用。提升质量通过清单和模板确保了评估的全面性和报告的专业性不依赖模型临时发挥。流程可控明确的关卡让用户始终掌控流程智能体只是引导和执行的工具而非“黑盒”。可复用与扩展评估清单和报告模板可以独立更新。例如可以轻松创建一份针对“宠物用品”的专属评估清单替换掉通用清单就能快速得到一个垂直领域的选品专家。5. 实施路线图与常见陷阱规避5.1 从零开始的技能建设路线图构建一套高效的智能体技能库并非一蹴而就。遵循一个循序渐进的路线图可以让你用最小的代价获得最大的收益。第一阶段知识沉淀工具封装者目标将团队内部的隐性知识显性化。行动从最常被问到的领域开始比如“我们团队的Python代码风格指南是什么”或“部署到AWS的合规检查有哪些”将这些零散的知识整理成结构化的Markdown文档放入references/目录。创建一个最简单的SKILL.md描述触发条件并指令加载对应的参考文档。产出你的第一个“工具封装者”技能。现在任何新成员或智能体都能瞬间获得团队积累的领域知识。第二阶段输出标准化生成器目标统一经常需要产出的文档格式。行动找出那些需要反复编写、且格式固定的文档如“事故复盘报告”、“API设计文档”、“项目周报”。为每种文档创建一个模板文件放入assets/目录明确章节和占位符。可以结合第一阶段在references/中添加该文档的写作风格指南如语气、术语。更新或新建SKILL.md指令智能体在触发时先收集必要信息可结合简单反转然后填充模板。产出你的第一个“生成器”技能。从此这类文档的产出质量和一致性大幅提升。第三阶段质量门禁审查者目标为关键产出物增加自动化质量检查。行动为最重要的产出环节定义检查清单。例如代码合并前的“代码审查清单”内容发布前的“合规检查清单”。创建“审查者”技能加载清单并对指定内容进行评审。可以将此技能作为“流水线”的一个关卡例如在“生成器”产出文档后自动触发“审查者”进行检查。产出一个自动化的质量守门员确保输出物符合最低标准。第四阶段流程编排流水线目标将复杂的多步骤工作流自动化、标准化。行动梳理一个你或团队经常执行的、包含多个步骤和确认环节的复杂流程。将其分解为离散的步骤并为每个步骤选择合适的子模式反转、生成、审查。在步骤间设计明确的“关卡”条件。编写总的SKILL.md来编排整个流水线。产出一个端到端的自动化智能工作流如从需求收集到报告生成的完整选品流程。5.2 十大常见陷阱与避坑指南在设计和实施这些模式时一些常见的错误会显著降低技能的效果。陷阱一技能描述过于模糊问题description字段写“帮助写代码”导致技能无法被精准触发或者被错误触发。解法使用具体的技术栈、场景和动作关键词。例如“当用户需要编写FastAPI的CRUD接口并遵循RESTful规范时触发”。陷阱二检查清单或模板过于笼统问题清单里写“代码要高效”模板里写“写一段分析”。这种模糊要求对智能体毫无帮助。解法清单要可操作“函数圈复杂度不应超过15”模板要具体“## 性能分析必须包含QPS图表和平均响应时间数据”。陷阱三在流水线中缺失关键关卡问题步骤间没有设置确认或验证环节导致错误一路传递到最后。解法在每一个可能产生歧义或需要外部输入的步骤后设置明确的关卡。例如在“生成方案草稿”后必须设置“等待用户确认草稿”的关卡。陷阱四一次性加载所有知识问题在SKILL.md开头就用巨大篇幅嵌入所有规则和模板导致Token成本高昂且大部分内容可能用不上。解法严格遵守渐进式加载。只在SKILL.md中描述流程将具体的规则references/和模板assets/通过load_skill_resource在需要时才加载。陷阱五忽视技能的单一职责问题试图让一个技能做太多事情比如一个技能既负责提问收集需求又负责详细分析还负责生成三种不同格式的报告导致技能逻辑复杂难以维护和触发。解法遵循单一职责原则。拆分成多个小技能。例如“需求收集器”、“某领域分析师”、“报告生成器”。它们可以通过流水线组合也可以单独调用。陷阱六模板缺乏灵活性问题报告模板过于僵化某个章节没有内容时智能体会生硬地留空或填入“无”影响可读性。解法在模板中使用条件性说明。例如“## 风险分析[如果步骤2评估中存在❌或⚠️项则在此详细列出否则本节可写‘未发现重大风险’]”。这需要智能体有一定的逻辑判断能力但通过清晰的指令可以引导。陷阱七没有处理异常路径问题技能设计只考虑了“理想路径”当用户回答“我不知道预算”或审查发现致命缺陷时技能不知道该如何继续或优雅终止。解法在SKILL.md的关键决策点设计分支逻辑。例如“如果用户无法提供预算则询问一个可接受的价格区间如低、中、高并基于此进行后续评估。” 或 “如果评估发现❌致命缺陷则直接向用户提示此风险并询问是否继续评估其他方面或终止流程。”陷阱八技能间数据传递不清晰问题在流水线中步骤2需要用到步骤1的结果但指令中没有明确说明导致智能体丢失上下文。解法在SKILL.md中显式地说明数据流向。例如在步骤2的指令中写明“使用步骤1中用户提供的目标受众信息来评估产品的市场匹配度。”陷阱九忽略了技能的维护成本问题创建了大量技能但团队规范、评估标准更新后对应的references/文件没有同步更新导致技能输出过时甚至错误。解法将技能相关的参考文件纳入团队的知识管理或版本控制系统如Git。建立简单的更新机制当核心规范变更时责任人需要同步更新对应的技能资源文件。陷阱十为不存在的需求过度设计问题盲目追求复杂的流水线模式为一个简单的任务设计了多个步骤和关卡反而降低了效率。解法始终从最简单的“工具封装者”模式开始评估。只有当简单模式无法满足需求如需要固定格式、需要评审、需要多步骤时才逐步升级到更复杂的模式。记住最适合的模式才是最好的模式。这套来自谷歌工程师实战总结的SKILL.md设计模式其精髓不在于技术的复杂性而在于思维的转变从让模型“猜”和“编”转变为为模型提供精确的“工具”和“流程”。它本质上是一种更高级的、结构化的提示工程。通过将人类专家的知识、工作流程和判断标准封装成可复用的技能模块我们不仅大幅提升了大模型在专业任务上的可靠性和输出质量更重要的是通过渐进式知识加载等技巧实现了成本的精打细算。开始尝试为你团队最高频、最耗时的任务设计第一个技能吧从封装一份简单的代码规范开始你会立刻感受到它带来的效率提升和心智负担的降低。
SKILL.md设计模式：五大技能封装策略，精准控制智能体行为与降低Token成本
发布时间：2026/5/28 21:30:17
1. 项目概述从“猜谜”到“执行”的智能体技能设计革命最近在琢磨一个事儿我们花大价钱调用大模型API结果很多时候模型都在那儿“猜”我们想让它干嘛。让它写个FastAPI接口它可能先花几百个token去回忆路由定义的最佳实践让它生成一份技术报告它又得从头构思报告的结构和语气。这种“重复造轮子”式的思考是项目里token消耗的隐形杀手也是智能体行为不可控、输出质量参差不齐的根源。这问题其实谷歌的工程师们早就注意到了。最近深入研究了一下谷歌ADKAgent Development Kit团队的专家Lavi Nigam分享的实战经验他提炼出了一套名为“SKILL.md设计模式”的方法论。这套东西不是什么高深的理论而是五个可以直接抄作业的生产级模式核心目标就俩精准触发智能体的正确行为同时把没必要的token浪费砍到最低。简单来说传统的提示工程Prompt Engineering像是在给一个非常聪明但缺乏经验的新手下达模糊指令结果它可能用80%的精力去理解“潜规则”只用20%的精力干活。而这套SKILL.md模式则是为这位新手配备了一套标准化的“工作手册”和“工具包”。当需要处理特定任务时智能体不再是凭空猜测而是直接调用对应的“技能包”里面已经封装好了这个领域的所有规则、模板和检查清单。这样一来它就能立刻进入“专家模式”把全部算力用在刀刃上。对于开发者而言这意味着三件事第一智能体的行为变得可预测、可管理输出质量稳定第二团队协作时技能的定义和书写有了统一规范沟通成本大大降低第三也是最重要的通过“渐进式知识加载”只在需要时才加载具体的规则或模板能戏剧性地减少上下文窗口的占用从而降低token消耗和API成本。接下来我们就逐一拆解这五个能立刻用起来的模式。2. 五大核心技能设计模式深度解析2.1 模式一工具封装者——让智能体秒变领域专家核心思路与适用场景“工具封装者”模式是这五个模式中最基础、也最常用的一种。它的核心思想是知识封装与即时应用。我们不再在每次提示词里罗列冗长的规则而是将这些规则、惯例、最佳实践写在一个独立的规范文件如conventions.md里。SKILL.md文件只做两件事定义何时触发这个技能以及告诉智能体去加载和应用哪个规范文件。这特别适合那些有明确“规矩”的领域。比如你们团队有一套严格的FastAPI路由命名规范、响应模型定义标准或者公司在使用Terraform时对资源命名、模块结构有统一要求又或者是数据库查询优化、内部API设计指南等。这些知识是静态的、共识性的但让模型每次临时回忆既低效又容易出错。文件结构与运作机制它的目录结构极其简洁my-skill/ ├── SKILL.md # 技能入口触发关键词 加载指令 └── references/ └── conventions.md # 具体的领域规则和最佳实践SKILL.md文件就像一个轻量级的调度器。它的description字段至关重要因为这是智能体用来匹配用户请求的“搜索索引”。这里必须包含具体、明确的业务关键词。例如如果你的技能是关于FastAPI的description里就一定要有 “FastAPI”, “routing”, “dependency injection”, “Pydantic models” 等词。过于模糊的描述会导致技能无法被正确触发。一个实战案例FastAPI专家模式假设我们要创建一个“FastAPI代码规范专家”技能。首先我们在references/fastapi-conventions.md文件中详细定义规则例如所有路由路径使用小写字母和连字符如/api/v1/user-profiles。响应模型必须显式定义并使用response_model参数。依赖注入函数需包含完整的类型提示和文档字符串。错误处理应使用FastAPI的HTTPException并包含明确的错误码和信息。然后对应的SKILL.md文件如下--- name: fastapi-expert description: 当用户需要编写FastAPI代码、定义路由或使用依赖注入时触发。帮助生成符合团队内部最佳实践的FastAPI代码。 --- # FastAPI专家模式 ## 激活规则 1. 加载参考文档references/fastapi-conventions.md 2. 确保所有生成的FastAPI代码严格遵守该文档中定义的约定。当用户提出“帮我写一个用户登录的API端点”时智能体识别到“FastAPI”、“API端点”等关键词触发此技能。它首先加载轻量级的SKILL.md指令然后按指令去加载fastapi-conventions.md文件中的具体规则随后生成的代码就会天然符合团队规范无需在每次对话中重复灌输规则。关键心得description字段的撰写是门艺术。要站在用户的角度思考他们会用什么词来提问同时避免过于宽泛。比如“写代码”就太泛而“写FastAPI路由代码”就精准得多。这是确保技能在正确时机被激活的第一道闸门。2.2 模式二生成器——在创意与规范间取得平衡核心思路与适用场景当你的需求不仅仅是遵守规则还需要产出结构高度一致的文档或内容时“生成器”模式就该上场了。它解决了“既有固定格式要求又需保证内容质量”的矛盾。其核心在于分离“结构”与“风格”assets/目录下的模板文件定义了输出的骨架必须有哪些章节、段落而references/目录下的风格指南则控制了填充骨架的血肉用什么语气、格式、术语。这个模式适用于所有需要标准化输出的场景。例如技术分析报告、API参考文档、标准化的Git提交信息、智能体脚手架代码、周报/月报模板等。选择此模式意味着你对结构一致性的要求高于对内容创造性的要求。它确保无论谁或哪个智能体来执行产出的文档在形式上都是统一的极大方便了后续的归档、审阅和自动化处理。文件结构与双轨控制典型的目录结构如下my-skill/ ├── SKILL.md ├── assets/ │ └── report-template.md # 输出结构模板规定章节 └── references/ └── style-guide.md # 语气与格式风格指南assets/report-template.md可能长这样# [此处填入报告标题] ## 1. 概述 - **背景**[...] - **目标**[...] ## 2. 核心分析 - **数据**[...] - **发现**[...] ## 3. 结论与建议 - **主要结论**[...] - **后续行动**[...]而references/style-guide.md则规定使用客观、专业的语气避免主观臆断。数据部分优先使用表格呈现。建议部分使用“建议1...”的列表形式每条建议以动词开头。专业术语需与公司术语表保持一致。运作流程与优势当技能被触发后智能体首先理解用户需求的核心内容然后按照模板的结构将内容填充到对应的章节中并在此过程中严格遵守风格指南的要求。这样做的好处是即使面对一个复杂报告的需求智能体也无需消耗token去“构思报告该怎么写”它只需要专注于“如何把已有信息填入既定格式”并确保表达方式符合要求。这既提升了效率又保证了质量的下限。实操要点模板的设计要足够灵活在保持结构的同时为可变内容留下清晰的位置标识如[此处填入...]。风格指南则应具体最好能给出正面和反面的例子让智能体有更明确的参照。例如与其说“语气要专业”不如说“应使用‘经分析表明’而非‘我觉得’”。2.3 模式三审查者——将质量检查流程化与标准化核心思路与适用场景“审查者”模式的核心是分离“检查项”与“检查方法”。它将“要检查什么”一份详尽的检查清单和“如何进行检查与报告”一个审查协议解耦。SKILL.md文件定义了审查的流程和报告格式而references/下的检查清单文件则列出了所有需要核对的规则并按严重性分组。这种模式威力巨大因为它使得同一个“审查”技能框架只需更换不同的检查清单就能瞬间变为针对不同目标的审查专家。它完美适用于所有需要基于明确标准进行评价、打分或审计的任务。例如代码审查检查编码规范、安全漏洞、Python类型注解完整性检查、异常处理完备性评估、内容审核技术文档格式、术语一致性、API文档审查参数描述、示例代码等。文件结构与输出范式结构依然清晰my-skill/ ├── SKILL.md # 审查协议如何加载、应用、报告检查清单 └── references/ └── review-checklist.md # 检查清单按严重性分组的规则列表SKILL.md中的审查协议会指令智能体“加载指定的检查清单逐项评估目标内容并按照以下格式输出发现的问题”。而输出的格式通常是标准化的例如等级含义示例❌ 错误必须修复影响功能或安全SQL注入风险、未处理的异常、硬编码密钥⚠️ 警告建议修复影响代码质量缺少类型提示、命名不规范、函数过于复杂ℹ️ 提示可选的改进建议注释不完整、逻辑可提取为独立函数一个安全审计技能的构建实例假设我们要构建一个“基础安全审计”技能。我们在references/security-checklist.md中定义清单❌ 错误检测到疑似硬编码的密码或API密钥发现未经参数化处理的SQL查询字符串。⚠️ 警告输入验证缺失错误信息可能泄露系统内部细节。ℹ️ 提示建议使用更安全的哈希算法敏感日志未脱敏。当对一段代码运行此技能时智能体会像一位安全专家一样逐条核对清单并将发现的问题归类到上述三个严重性等级中输出。这种结构化的输出让开发者能快速定位高危问题极大提升了审查效率和行动针对性。经验之谈检查清单的编写质量直接决定审查效果。规则应尽可能具体、可操作。避免“代码要清晰”这样的模糊描述而应写成“单个函数长度不应超过50行”或“循环嵌套深度不应超过3层”。同时合理划分严重性等级是关键避免将所有问题都标为“错误”导致重点被淹没。2.4 模式四反转者——让智能体学会提问而非臆测核心思路与适用场景前三个模式主要优化了智能体“执行”任务的方式而“反转者”模式则彻底改变了交互的启动方式。它的核心思想是角色反转由智能体主动提问来驱动对话。在技能开始时智能体不立即开始构建或生成内容而是根据预设的问题列表主动向用户提问以收集完成任务所必需的关键上下文信息。这个模式专治智能体的“盲目假设”和“自以为是”。当任务成功与否高度依赖于一些模糊的、个性化的、或未在初始请求中阐明的信息时就必须使用此模式。典型场景包括项目需求收集、系统故障诊断引导、基础设施配置向导、生成定制化报告前的信息收集等。它能有效防止智能体基于不完整或错误的假设生成大量无用输出从而从源头上减少token浪费。三阶段流程与控制指令一个完整的反转者模式技能通常遵循“提问-收集-执行”的三阶段流程提问阶段智能体根据SKILL.md中的定义提出一系列结构化问题。收集阶段等待并解析用户的回答。执行阶段基于收集到的完整信息开始执行核心任务可能是调用另一个生成器或工具封装者技能。这里有一个必须明确写在SKILL.md中的关键控制指令DO NOT start building until all phases are complete.在所有阶段完成前切勿开始构建。这条指令是防止智能体“抢跑”的保险丝。实战项目需求收集专家假设我们创建一个“软件项目需求收集”技能。其SKILL.md的核心部分如下# 项目需求收集专家 你是一个经验丰富的产品分析师。在开始任何方案设计前你必须首先澄清以下关键信息。请依次提问并等待用户逐一回答。 **核心指令在收集到以下所有信息之前绝对不要开始设计解决方案或编写代码** 1. 项目的主要目标是什么要解决用户什么核心痛点请用一句话概括 2. 目标用户是谁例如内部员工、特定年龄段的消费者、开发者 3. 有哪些必须实现的**核心功能**请列出至少3项 4. 是否有必须遵循的技术栈或集成约束例如必须使用Python必须与XX系统对接 5. 项目预期的里程碑或截止日期是什么 *请依次提出上述问题并在获得每个问题的明确答复后再继续下一个。*通过这种方式智能体引导用户完成一次结构化的需求访谈确保后续所有工作都建立在坚实、清晰的基础上避免了因误解需求而导致的返工和资源浪费。避坑指南问题的设计要循序渐进从宏观到微观。避免一次性抛出所有问题这会让用户感到压力。可以设计成交互式的根据上一个问题的答案动态决定下一个问题的深度。例如当用户说“目标用户是开发者”时下一个问题可以深入问“是前端、后端还是全栈开发者”2.5 模式五流水线——为复杂任务构建严格的工作流核心思路与适用场景“流水线”模式是五个模式中最强大、也最复杂的一个用于管理具有严格顺序依赖关系的多步骤任务。它将一个复杂的业务流程分解为一系列离散的步骤并在步骤之间设立明确的“关卡”。每个关卡都有一个必须满足的“继续条件”只有当前步骤成功完成且条件满足流程才能进入下一步。这就像在软件开发中的CI/CD流水线代码必须通过编译、测试、代码审查等多个关卡才能部署。此模式适用于任何步骤环环相扣、且中间需要人工确认或自动验证的场景。例如代码文档生成解析代码 - 用户确认 - 生成文档 - 质量检查、数据清洗管道去重 - 格式化 - 验证 - 输出、代码部署工作流代码审查 - 自动化测试 - 构建发布 - 线上验证、多级审批流程等。文件结构与关卡控制流水线模式的目录结构最为完整因为它可能综合运用前几种模式my-skill/ ├── SKILL.md # 步骤定义 关卡控制逻辑 ├── references/ # 各步骤的参考规范可能包含检查清单、风格指南 ├── assets/ # 输出模板 └── scripts/ # 可选的自动化脚本如调用外部工具SKILL.md是流水线的“总控程序”。每个步骤的定义都遵循一个包含“关卡”的模板## 步骤 N: [步骤名称] [步骤的具体描述和操作指令] *关卡在满足 [某个具体条件] 之前**切勿**进入步骤 N1* *如果任何步骤被跳过或失败则不要继续。*关卡条件的类型关卡条件是流水线的精髓常见的有用户确认直到用户明确批准当前结果质量验证直到代码审查通过所有❌错误项检查数据就绪直到输入数据通过完整性校验外部信号直到收到构建成功的通知一个简单的文档生成流水线示例## 步骤1: 解析代码结构 分析提供的源代码文件提取所有公开的类、函数及其签名、参数和返回值类型。 *关卡完成解析并列出所有找到的组件等待用户确认列表是否完整准确。* ## 步骤2: 生成草稿文档 根据步骤1确认的列表为每个组件生成初步的文档草稿。 *关卡草稿生成完毕等待用户审阅。* ## 步骤3: 应用格式规范 加载 references/doc-style-guide.md将步骤2的草稿格式化为公司标准。 *关卡格式化完成并自动运行 scripts/spell-check.js 进行拼写检查直到无错误。* ## 步骤4: 最终输出 将格式化后的文档按照 assets/api-doc-template.md 的模板组装成最终文档。这个流水线确保了没有用户的确认就不会生成文档没有通过拼写检查就不会最终输出。每一步都坚实可靠。设计心得设计流水线时最难的是确定步骤的粒度。步骤太粗关卡失去意义步骤太细流程会显得繁琐。一个好的原则是每一个步骤都应该产生一个明确的、可验证的中间产物而关卡就是对这个产物的质量门禁。同时务必在SKILL.md开头强调“任何步骤失败则停止”的总原则防止错误累积。3. 模式选择与组合实战指南3.1 如何选择正确的起点快速决策指南面对一个具体的任务如何从这五个模式中选出最合适的一个作为起点你可以遵循下面这个快速决策流程问自己第一个问题我的主要目的是让智能体掌握并应用一套固定的知识或规则吗如果是- 选择 工具封装者。这是最轻量、最直接的模式适用于封装团队惯例、工具库规范、API设计准则等静态知识。复杂度低见效快。如果否问第二个问题我是否需要智能体产出结构高度固定、格式统一的文档或内容如果是- 选择 生成器。当你对报告、文档、消息的章节、段落顺序有严格要求时这个模式能保证输出的一致性。它平衡了结构约束与内容创作。如果否问第三个问题我的任务本质上是根据一套标准对现有内容进行评审、打分或审计吗如果是- 选择✅ 审查者。这个模式将“检查清单”与“检查流程”分离非常适合代码审查、安全扫描、内容质检等评估类任务。输出通常是分等级错误/警告/提示的问题列表。如果否问第四个问题智能体在开始工作前是否必须从用户那里获取一些关键的、非预设的上下文信息如果是- 选择❓ 反转者。这个模式能有效防止智能体“瞎猜”通过先提问的方式确保后续所有工作都基于准确的信息。适用于需求收集、故障诊断等场景。如果以上都不是或者任务明显包含多个有严格顺序的步骤且步骤间存在依赖关系- 选择 流水线。这是最复杂的模式用于编排多步骤工作流并在步骤间设置强制性的“关卡”如用户确认、质量检查。给新手的建议如果你不确定永远从“工具封装者”开始。它最简单能让你快速体会到将知识外化的好处。当你发现需要固定输出格式时再升级到“生成器”当需要增加评审能力时再引入“审查者”模式。渐进式地构建你的技能库。3.2 模式组合的最佳实践与高级技巧在实际的生产系统中复杂的业务需求往往需要组合多个模式形成更强大的解决方案。单一模式可能只解决一个环节的问题而组合模式能覆盖端到端的业务流程。常见的黄金组合流水线 审查者这是质量控制的标准范式。在一个生成或处理流程的末尾设置一个审查步骤作为关卡。例如在“代码生成流水线”的最后一步加入一个“代码安全与规范审查”技能只有审查通过无❌级错误流水线才算完成。这确保了输出物的质量下限。生成器 反转者先收集后生成。这是制作个性化报告的完美组合。首先使用“反转者”技能通过一系列问题收集用户的特定需求、偏好和数据然后将收集到的信息传递给“生成器”技能填充到预设的模板中生成一份完全定制化的报告。这避免了生成通用报告后再进行大量修改的浪费。流水线 反转者 生成器这是一个完整的端到端业务流。文章开头提到的“电商选品”案例就是典范。Step 1用“反转者”收集用户需求预算、受众等Step 2可以内嵌一个“审查者”来评估潜在产品Step 3设置关卡等待用户确认Step 4用“生成器”产出最终选品报告。整个流程逻辑严密用户参与感强输出质量高。组合时的关键设计原则明确职责边界每个技能模块应该只做好一件事。让“反转者”专注提问让“生成器”专注填充模板让“审查者”专注检查。通过“关卡”传递数据在流水线模式中上一个步骤的输出如收集到的需求、生成的草稿应作为上下文清晰地传递给下一个步骤。可以在SKILL.md中用类似“使用步骤1中收集到的需求信息”来指明。保持技能可复用设计时尽量让每个技能如一个独立的“审查者”本身是完整且可复用的。这样它既可以单独使用也可以被轻松地嵌入到不同的流水线中。3.3 实现极致效率渐进式知识加载策略这是谷歌这套方法论中降低Token消耗最核心、最有效的技术。其原理很简单不要一次性把所有知识都塞进模型的上下文窗口而是按需加载。让我们拆解一个组合技能如上述电商选品流水线的Token加载过程阶段加载的内容大致Token成本说明技能激活时SKILL.md中的描述和基础指令~100 tokens仅加载最轻量的“技能索引”和流程概览。模型只知道有个“选品流水线”以及第一步该干嘛。执行步骤1反转者步骤1的详细提问脚本~50-100 tokens加载如何提问的指令。此时还不需要产品评估标准或报告模板。执行步骤2审查者加载references/product-evaluation-checklist.md按文件大小而定仅在需要评估产品时才加载具体的评估清单。如果第一步发现用户需求不匹配可能直接跳过此步这份清单的Token就省下了。执行步骤4生成器加载assets/selection-report-template.md按文件大小而定仅在生成最终报告时才加载模板。如果流程在前几步中止这份模板的Token同样被节省。与传统方式的对比传统做法可能在一个超长的提示词中同时包含提问话术、评估清单和报告模板。即使流程在第一步后就结束后面两部分内容的Token也已经消耗且无法收回。而渐进式加载确保了为每一步操作支付的Token成本都精确地用于该步骤的实际执行避免了巨大的前期浪费。对于包含大量参考文档的复杂技能这种节省是指数级的。高级技巧为了最大化渐进式加载的效益在编写references/和assets/下的文件时也要注意内容的模块化和简洁性。将大的文档拆分成逻辑独立的小文件使得加载更加精准。例如将“安全审查清单”拆分为“输入验证清单”、“加密清单”、“错误处理清单”这样在审查不同侧重点的代码时可以加载更相关的部分。4. 从理论到实践构建一个电商选品流水线全案例现在让我们将上述所有模式融合亲手构建一个文章开头提到的“电商选品流水线”实战案例。这个案例将串联“反转者”、“审查者”、“生成器”三种模式并由“流水线”模式进行总控。4.1 场景定义与技能设计业务场景作为一个电商运营或选品人员你需要从海量商品中筛选出有潜力的产品。这个过程通常包括明确选品目标如受众、预算、根据一套标准初步评估产品、与团队或自己确认评估结果、最后形成一份结构化的选品报告。技能设计目标创建一个智能体技能引导用户完成上述完整流程确保每一步都基于充分的信息和确认最终产出一份高质量、标准化的报告。4.2 目录结构与文件职责首先创建我们的技能目录ecommerce-product-selector/结构如下ecommerce-product-selector/ ├── SKILL.md # 核心流水线总控指令 ├── references/ │ └── product-evaluation-checklist.md # 审查者模式产品评估标准 └── assets/ └── selection-report-template.md # 生成器模式最终报告模板每个文件扮演不同角色SKILL.md是整个技能的大脑定义了四个步骤的流程、关卡以及何时调用其他文件。references/product-evaluation-checklist.md是技能的知识库封装了“好产品”的评估维度。assets/selection-report-template.md是技能的产出模具规定了报告长什么样。4.3 核心文件实现详解1. 产品评估检查清单 (references/product-evaluation-checklist.md)这份清单是“审查者”模式的灵魂它必须具体、可衡量。我们按严重性等级来组织# 电商产品评估标准清单 请根据以下标准对候选产品进行评分并将问题归类。 ## ❌ 致命缺陷一票否决 - **法律与合规风险**产品是否存在侵权专利、商标、版权、安全认证缺失、或违反目标市场法规的风险 - **供应链硬伤**最小起订量是否远超预算供货周期是否不稳定60天是否为单一货源且无替代供应商 - **利润空间为负**初步估算售价 - 采购成本 - 平台佣金 - 物流费 - 税费后毛利率是否低于5% ## ⚠️ 高风险项需重点评估 - **市场竞争度**在目标平台如亚马逊、Shopify上同类产品是否已存在大量高度相似、排名靠前的竞品 - **产品差异化难度**产品是否属于完全通用的“白牌”商品难以通过包装、功能微创新或营销形成差异化 - **物流复杂度**产品是否易碎、超大、超重或属于危险品导致物流成本高昂或仓储困难 - **季节性波动**产品需求是否具有极强的季节性可能导致长期库存积压 ## ✅ 潜在优势项加分项 - **趋势与热度**社交媒体如TikTok, Instagram或谷歌趋势是否显示该产品关键词搜索量近期呈上升趋势 - **受众明确**产品是否针对一个需求明确、有付费意愿的利基受众群体 - **附加价值空间**产品是否易于组合销售、提供订阅服务或搭配高利润配件 - **用户口碑基础**类似产品在现有平台上的平均评分是否高于4.3星满分5星2. 选品报告模板 (assets/selection-report-template.md)这份模板是“生成器”模式的骨架它定义了最终输出的结构# 电商产品选品分析报告[产品名称] **报告生成日期** [日期] **目标市场** [来自步骤1] ## 一、选品需求摘要 - **目标受众** [来自步骤1] - **预算范围** [来自步骤1] - **品类偏好** [来自步骤1] ## 二、产品评估详情 ### 2.1 基础信息 - **产品名称/链接** [产品信息] - **采购成本** [成本信息] - **预估售价** [售价信息] - **预估毛利率** [计算过程与结果] ### 2.2 评估结果概览 此处自动汇总根据检查清单识别的❌、⚠️、✅项数量 ### 2.3 关键发现与风险分析 - **致命缺陷分析** [逐条分析❌项若无可写“无”] - **高风险项分析** [逐条分析⚠️项及其缓解可能性] - **核心优势分析** [阐述✅项带来的市场机会] ## 三、综合建议与下一步行动 - **总体推荐度** 例如推荐 / 谨慎推荐 / 不推荐 - **主要决策依据** [综合上述分析给出1-2条核心决策理由] - **建议的下一步** 1. [行动项1如联系3家备用供应商核实供货能力] 2. [行动项2如制作小批量样品进行用户体验测试]3. 流水线总控文件 (SKILL.md)这是最核心的文件它将所有部分串联起来--- name: ecommerce-product-selector description: 帮助进行电商产品选品、市场分析、利润计算并生成标准选品报告。当用户需要寻找或评估电商产品时触发。 metadata: pattern: Pipeline domain: E-commerce --- # 电商产品选品工作流 你是一名专业的电商产品选品专家。请严格按照以下顺序执行步骤不得跳跃。 **核心规则在完成所有阶段之前切勿开始生成产品选品方案如果任何步骤被跳过或失败则不要继续。** ## 步骤1收集需求反转者模式 主动向用户提问以收集选品背景信息。请按顺序提出以下问题并等待用户对每个问题作出回答 1. 本次选品的目标受众是谁例如北美25-34岁都市女性、家居DIY爱好者 2. 单件产品的预算成本范围是多少你期望的毛利率是多少 3. 是否有特别关注的品类或已有的供应链优势 4. 主要计划在哪个或哪些电商平台销售 *关卡必须获得用户对以上所有问题的明确答复后方可进入步骤2。如果用户无法提供任何一项信息请友好地说明该信息对后续评估至关重要并尝试引导其给出估算或范围。* ## 步骤2评估产品审查者模式 现在请用户提供1-3个待评估的具体产品信息如名称、链接、初步了解的采购价等。 针对每一个产品执行以下操作 1. 加载并应用评估标准references/product-evaluation-checklist.md 2. 根据清单中的每一条标准分析该产品。将发现的问题或优势归类为 ❌ 致命缺陷、⚠️ 高风险项 或 ✅ 潜在优势项。 3. 为每个产品提供一份简明的评估小结。 *关卡完成对所有指定产品的评估分析后进入步骤3。* ## 步骤3用户确认流水线关卡 向用户清晰展示步骤2的评估结果。对于每个产品列出其主要的❌、⚠️、✅项。 然后询问用户“基于以上初步分析您希望针对哪个产品继续深入并生成完整的选品报告” *关卡必须获得用户明确指定一个产品后方可进入最终步骤。如果用户想评估新的产品则返回步骤2。* ## 步骤4生成最终报告生成器模式 针对用户确认的产品生成最终报告 1. 加载报告模板assets/selection-report-template.md 2. 将步骤1收集的需求信息、步骤2对该产品的详细评估结果严格填充到模板的对应部分。 3. 确保报告格式工整分析逻辑连贯并最终给出明确的“综合建议与下一步行动”。 报告生成后将其完整呈现给用户。4.4 技能运作流程与价值分析当用户触发此技能时将经历以下交互需求澄清智能体化身“顾问”先问清预算、受众等关键问题。这避免了它基于错误假设推荐奢侈品给预算有限的用户。专业评估智能体化身“分析师”用专业的检查清单扫描产品识别出看不见的风险如侵权风险和潜在机会。决策确认智能体化身“协调者”将评估结果可视化让用户参与决策选择深入分析的对象。报告生成智能体化身“助理”将前几步的所有信息合成一份结构专业、内容翔实的标准报告。这个案例的价值在于降低浪费如果用户在第一步就说“预算只有10美元”那么所有高价产品的评估Token都被省下了。渐进式加载在此充分发挥作用。提升质量通过清单和模板确保了评估的全面性和报告的专业性不依赖模型临时发挥。流程可控明确的关卡让用户始终掌控流程智能体只是引导和执行的工具而非“黑盒”。可复用与扩展评估清单和报告模板可以独立更新。例如可以轻松创建一份针对“宠物用品”的专属评估清单替换掉通用清单就能快速得到一个垂直领域的选品专家。5. 实施路线图与常见陷阱规避5.1 从零开始的技能建设路线图构建一套高效的智能体技能库并非一蹴而就。遵循一个循序渐进的路线图可以让你用最小的代价获得最大的收益。第一阶段知识沉淀工具封装者目标将团队内部的隐性知识显性化。行动从最常被问到的领域开始比如“我们团队的Python代码风格指南是什么”或“部署到AWS的合规检查有哪些”将这些零散的知识整理成结构化的Markdown文档放入references/目录。创建一个最简单的SKILL.md描述触发条件并指令加载对应的参考文档。产出你的第一个“工具封装者”技能。现在任何新成员或智能体都能瞬间获得团队积累的领域知识。第二阶段输出标准化生成器目标统一经常需要产出的文档格式。行动找出那些需要反复编写、且格式固定的文档如“事故复盘报告”、“API设计文档”、“项目周报”。为每种文档创建一个模板文件放入assets/目录明确章节和占位符。可以结合第一阶段在references/中添加该文档的写作风格指南如语气、术语。更新或新建SKILL.md指令智能体在触发时先收集必要信息可结合简单反转然后填充模板。产出你的第一个“生成器”技能。从此这类文档的产出质量和一致性大幅提升。第三阶段质量门禁审查者目标为关键产出物增加自动化质量检查。行动为最重要的产出环节定义检查清单。例如代码合并前的“代码审查清单”内容发布前的“合规检查清单”。创建“审查者”技能加载清单并对指定内容进行评审。可以将此技能作为“流水线”的一个关卡例如在“生成器”产出文档后自动触发“审查者”进行检查。产出一个自动化的质量守门员确保输出物符合最低标准。第四阶段流程编排流水线目标将复杂的多步骤工作流自动化、标准化。行动梳理一个你或团队经常执行的、包含多个步骤和确认环节的复杂流程。将其分解为离散的步骤并为每个步骤选择合适的子模式反转、生成、审查。在步骤间设计明确的“关卡”条件。编写总的SKILL.md来编排整个流水线。产出一个端到端的自动化智能工作流如从需求收集到报告生成的完整选品流程。5.2 十大常见陷阱与避坑指南在设计和实施这些模式时一些常见的错误会显著降低技能的效果。陷阱一技能描述过于模糊问题description字段写“帮助写代码”导致技能无法被精准触发或者被错误触发。解法使用具体的技术栈、场景和动作关键词。例如“当用户需要编写FastAPI的CRUD接口并遵循RESTful规范时触发”。陷阱二检查清单或模板过于笼统问题清单里写“代码要高效”模板里写“写一段分析”。这种模糊要求对智能体毫无帮助。解法清单要可操作“函数圈复杂度不应超过15”模板要具体“## 性能分析必须包含QPS图表和平均响应时间数据”。陷阱三在流水线中缺失关键关卡问题步骤间没有设置确认或验证环节导致错误一路传递到最后。解法在每一个可能产生歧义或需要外部输入的步骤后设置明确的关卡。例如在“生成方案草稿”后必须设置“等待用户确认草稿”的关卡。陷阱四一次性加载所有知识问题在SKILL.md开头就用巨大篇幅嵌入所有规则和模板导致Token成本高昂且大部分内容可能用不上。解法严格遵守渐进式加载。只在SKILL.md中描述流程将具体的规则references/和模板assets/通过load_skill_resource在需要时才加载。陷阱五忽视技能的单一职责问题试图让一个技能做太多事情比如一个技能既负责提问收集需求又负责详细分析还负责生成三种不同格式的报告导致技能逻辑复杂难以维护和触发。解法遵循单一职责原则。拆分成多个小技能。例如“需求收集器”、“某领域分析师”、“报告生成器”。它们可以通过流水线组合也可以单独调用。陷阱六模板缺乏灵活性问题报告模板过于僵化某个章节没有内容时智能体会生硬地留空或填入“无”影响可读性。解法在模板中使用条件性说明。例如“## 风险分析[如果步骤2评估中存在❌或⚠️项则在此详细列出否则本节可写‘未发现重大风险’]”。这需要智能体有一定的逻辑判断能力但通过清晰的指令可以引导。陷阱七没有处理异常路径问题技能设计只考虑了“理想路径”当用户回答“我不知道预算”或审查发现致命缺陷时技能不知道该如何继续或优雅终止。解法在SKILL.md的关键决策点设计分支逻辑。例如“如果用户无法提供预算则询问一个可接受的价格区间如低、中、高并基于此进行后续评估。” 或 “如果评估发现❌致命缺陷则直接向用户提示此风险并询问是否继续评估其他方面或终止流程。”陷阱八技能间数据传递不清晰问题在流水线中步骤2需要用到步骤1的结果但指令中没有明确说明导致智能体丢失上下文。解法在SKILL.md中显式地说明数据流向。例如在步骤2的指令中写明“使用步骤1中用户提供的目标受众信息来评估产品的市场匹配度。”陷阱九忽略了技能的维护成本问题创建了大量技能但团队规范、评估标准更新后对应的references/文件没有同步更新导致技能输出过时甚至错误。解法将技能相关的参考文件纳入团队的知识管理或版本控制系统如Git。建立简单的更新机制当核心规范变更时责任人需要同步更新对应的技能资源文件。陷阱十为不存在的需求过度设计问题盲目追求复杂的流水线模式为一个简单的任务设计了多个步骤和关卡反而降低了效率。解法始终从最简单的“工具封装者”模式开始评估。只有当简单模式无法满足需求如需要固定格式、需要评审、需要多步骤时才逐步升级到更复杂的模式。记住最适合的模式才是最好的模式。这套来自谷歌工程师实战总结的SKILL.md设计模式其精髓不在于技术的复杂性而在于思维的转变从让模型“猜”和“编”转变为为模型提供精确的“工具”和“流程”。它本质上是一种更高级的、结构化的提示工程。通过将人类专家的知识、工作流程和判断标准封装成可复用的技能模块我们不仅大幅提升了大模型在专业任务上的可靠性和输出质量更重要的是通过渐进式知识加载等技巧实现了成本的精打细算。开始尝试为你团队最高频、最耗时的任务设计第一个技能吧从封装一份简单的代码规范开始你会立刻感受到它带来的效率提升和心智负担的降低。
相关文章
无蜂窝大规模MIMO中AP开关策略：能效优化原理与工程实践
1. 项目概述：绿色无蜂窝大规模MIMO的能耗挑战与机遇 在5G向6G演进的路上，我们通信工程师面临着一个日益尖锐的矛盾：用户对无处不在、极致速率体验的渴求，与网络基础设施日益增长的能耗及运营成本之间的矛盾。传统的蜂窝网络架构&a…
【Sora 2视频可视化黄金法则】：NASA/JPL工程师亲授——如何让时间序列误差在0.8秒内完成视觉归因
更多请点击： https://codechina.net 第一章：Sora 2视频可视化黄金法则的底层逻辑与NASA/JPL工程语境 Sora 2并非仅是生成式AI的迭代升级，而是将时空建模、物理一致性约束与任务导向型可视化深度融合的工程范式跃迁。其“黄金法则”根植于NAS…
别再用静态TOTP了！Gemini自适应MFA如何通过实时风险评分动态升降认证强度——实测拦截率提升92.6%
更多请点击： https://intelliparadigm.com 第一章：Gemini多因素认证方案的演进背景与核心价值 随着云原生架构普及与零信任安全模型落地，传统基于静态口令的单因素认证已无法应对日益复杂的攻击面。Gemini多因素认证（MFA…
LabVIEW TCP/IP实战：5分钟搭建一个跨平台数据采集系统（Windows到树莓派）
LabVIEW与树莓派跨平台数据采集：5分钟构建工业级TCP/IP通信系统在工业自动化和物联网领域，数据采集系统的跨平台兼容性一直是开发者面临的挑战。当Windows平台强大的LabVIEW遇上Linux生态的树莓派，通过TCP/IP协议构建的通信桥梁，能…
Paraview可视化性能优化：Glyph过滤器里Stride和Seed怎么调，才能又快又清晰？
Paraview可视化性能优化：Glyph过滤器参数调优实战指南在科学计算可视化领域，处理千万级网格点的CFD或FEA结果时，Glyph过滤器的性能问题常常成为工程师的痛点。当数据量达到百万甚至千万级别，默认参数下的箭头渲染不仅会导致界面卡…
LLM应用安全实践：构建多层防御体系应对提示词注入与数据泄露
1. 项目概述：为什么LLM应用需要一个专属的“防火墙”？如果你正在开发或部署基于大语言模型的应用，无论是智能客服、代码助手还是内容生成工具，你可能已经意识到一个严峻的现实：你的应用正暴露在一个全新的、传统安全工…
AI编码助手实战：从效率提升到思维转变的开发者指南
1. 从“魔法棒”到“副驾驶”：我的AI编码助手实战心路第一次把AI生成的代码直接复制进项目时，那种感觉就像拿到了一把魔法棒。我用的工具是Cursor，当时的需求是给一个用户权限校验模块写几个单元测试。按照过去的习惯，我得先理清各…
从零构建环境式AI医疗文书助手：技术架构、成本与实战指南
1. 项目概述：为什么“环境式AI医疗文书助手”是下一个蓝海最近几年，如果你和医疗圈的朋友聊过天，或者自己有过就医经历，一定会对医生在问诊时埋头敲键盘的场景印象深刻。医生一边要倾听患者描述，一边要分神在电子病历系…
30分钟构建带持久化记忆的Claude智能体：从向量检索到个性化AI助手
1. 项目概述：为什么我们需要一个有记忆的AI助手？最近在捣鼓AI应用开发，发现一个挺普遍的问题：无论是用Claude的API，还是其他大模型，每次对话都像是“初次见面”。你告诉它你的名字、喜好、项目背景…
大模型核心加速器：KV Cache 如何将 O(n²) 计算复杂度降至 O(n)？
KV Cache 是大模型自回归生成任务的关键优化技术，通过“空间换时间”策略缓存历史 Key 和 Value 向量，将推理复杂度从 O(n) 降至 O(n)。文章阐述了语义缓存与前缀精确匹配两种核心范式，深入分析了 KV Cache 的技术底层原理、工程化应用及规模…
物流系统如何打通信息孤岛？哲盟软件系统：一键打通内外部数据壁垒
在数字化转型加速的今天，物流企业面临的最大痛点之一就是信息孤岛——ERP、电商平台、智能硬件、OMS/TMS/WMS等系统各自为政，数据无法自由流转，导致人工操作繁琐、效率低下、出错率高。特别是在跨境物流领域，亚马逊、Shopee、TikT…
Windows Defender终极恢复指南：5种强力方法解决禁用问题
Windows Defender终极恢复指南：5种强力方法解决禁用问题 【免费下载链接】no-defender A slightly more fun way to disable windows defender firewall. (through the WSC api) 项目地址: https://gitcode.com/GitHub_Trending/no/no-defender 当你的Windo…
施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录
更多请点击： https://codechina.net 第一章：施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录 在华北某大型地铁盾构施工现场，一套轻量化AI Agent系统于2024年Q2完成全栈部署ÿ…
附录 B：术语表
本术语表面向“从 MM 到 HMM”专栏阅读过程中的快速查阅。它不是内核 API 手册，而是把文章中反复出现的概念放到同一张地图上：先给出直观含义，再说明它在 Linux MM/HMM 语境里的作用。建议阅读方式： 初读专栏时，把它当…
Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表·行业首曝）
更多请点击： https://kaifayun.com 第一章：Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表行业首曝） Midjourney 的渐变美学并非传统插值实现，而是由其隐式神经渲染器（Implicit Neu…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…