1. 从“skills”这个热词说起它到底是什么最近半年不管是在技术社区、AI 工具群还是开发者闲聊里“skills”这个词出现的频率高得离谱。你随便翻翻热搜词就能看到一堆Agent Skills、codex skills、claude agent skills、skills 推荐、skills 大全、skills 开发……乍一看像是某个新出的插件市场又像是某个框架的功能模块。但如果你真去搜会发现它没有一个统一的官方定义不同人嘴里的“skills”指的甚至不是同一个东西。我先把话说清楚在当前语境下skills 绝大多数时候指的是“给 AI Agent 挂载的能力单元”。你可以把它理解成给一个通用助手装上的“技能包”——装上“查天气”的 skill它就会查天气装上“读 PDF”的 skill它就能解析文档装上“操作浏览器”的 skill它就能自动点按钮、填表单。它本质上是一组封装好的指令、工具调用逻辑和上下文约束让 Agent 在特定任务上从“能聊”变成“能干”。这件事为什么值得单独拿出来讲因为过去一年大家用 AI 的方式发生了明显变化。早期是“我问它答”后来是“我给它一段代码让它改”现在是“我给它一个目标它自己拆步骤、调工具、跑流程”。而 skills 就是支撑这第三步的基础设施。没有 skills 的 Agent 像个什么都懂一点但什么都干不利索的实习生有了 skills它才像个能真正交付结果的老手。这篇文章适合谁看三类人第一类是想搞明白 skills 到底是什么、值不值得投入时间学的前端和全栈开发者第二类是已经在用 codex、claude 这类工具想通过 skills 把重复劳动自动化的人第三类是想自己开发 skills、做内部工具链集成的团队技术负责人。我会从设计思路、核心机制、实操步骤、常见坑四个层面把它拆开讲尽量做到你看完就能上手写一个自己的 skill。需要提前说明的是skills 生态目前还在快速变化期不同平台比如 Google Cloud 的 Agent 体系、各类 CLI 工具、各家 AI 编程助手对 skills 的实现细节不完全一样。我会以最常见的“基于文件系统的 skill 定义 Agent 运行时加载”这套模式为主线来讲因为这是目前兼容性最好、也最容易自己动手实现的方式。具体到你用的平台参数和目录结构可能有差异但核心逻辑是通的。2. 整体设计思路为什么 skills 要这么设计2.1 核心问题通用 Agent 的“样样通、样样松”要理解 skills 的设计得先理解它要解决什么问题。一个没有挂载任何 skills 的通用 Agent它的能力边界是由训练数据和基础工具比如读写文件、执行命令决定的。你让它“帮我部署一个前端项目”它可能会给你一段通用的部署命令但它不知道你的项目用的是 Vite 还是 Webpack不知道你的构建产物目录是 dist 还是 build不知道你的环境变量怎么注入。结果就是它给的答案“看起来对跑起来错”。这就是通用 Agent 的核心矛盾它的知识是泛化的但真实任务是具体的。你不可能指望一个模型把所有项目的所有细节都记住那既不现实也没必要。正确的做法是把“具体任务的知识和操作流程”从模型里剥离出来做成可插拔的模块需要的时候再加载。这就是 skills 的设计出发点。打个比方通用 Agent 像是一个刚入职的高材生脑子好使但不懂你们公司的规矩。skills 就像是公司的 SOP 手册和工具箱他接手什么任务就翻对应的手册、拿对应的工具。手册写得越清楚他干得越靠谱。2.2 方案选型为什么是“文件 描述”而不是“硬编码”目前主流的 skills 实现几乎都采用了一种模式每个 skill 是一个独立目录里面有一个描述文件通常是 Markdown 或 YAML说明这个 skill 叫什么、什么时候用、怎么用再配合可选的脚本或资源文件。Agent 在运行时扫描这些目录根据当前任务匹配对应的 skill然后把 skill 的内容注入到自己的上下文里。为什么选这种方案我总结了几个关键考量第一解耦。skill 的定义和 Agent 的运行时是分开的。你改一个 skill 不需要重新训练模型也不需要改 Agent 的核心代码。加一个新 skill 就是加一个目录删一个 skill 就是删一个目录。这种解耦让 skills 生态可以快速扩张。第二可读可审。skill 的描述文件是纯文本人和模型都能读。这意味着你可以 review 一个 skill 到底让 Agent 干什么避免黑盒行为。对于团队协作来说这一点极其重要——你不能让一个来路不明的 skill 悄悄改你的生产环境。第三渐进式加载。Agent 不需要一次性把所有 skill 的内容都塞进上下文那样 token 会爆炸而是先看 skill 的“摘要描述”判断当前任务需不需要它需要再加载完整内容。这就像你先看书的目录决定翻哪一章而不是把整本书背下来。第四跨平台复用。因为 skill 本质上是文本 脚本理论上可以在不同 Agent 平台之间迁移。今天你在 A 工具里写的 skill明天换个工具稍微改改描述格式就能用。虽然目前还没做到完全标准化但方向是对的。2.3 和传统“插件/工具调用”的区别很多人会把 skills 和传统的 function calling、插件系统混为一谈。它们确实有重叠但侧重点不同。传统的工具调用重点是“给模型一个函数签名让它知道有这么个函数可以调”。比如你注册一个get_weather(city)函数模型知道要查天气就调它。但模型不知道“什么时候该查天气”“查完天气之后该干什么”“如果城市名是中文怎么办”。这些“流程性知识”不在函数签名里。skills 补的恰恰是这块。一个 skill 不只是告诉你“有个工具叫 X”而是告诉你“遇到 Y 场景时按 A→B→C 的步骤做注意 D 这个坑如果出错就检查 E”。它是工具 流程 约束的打包。所以你可以理解为工具调用是“零件”skills 是“装配说明书 零件盒”。这个区别在实际使用中非常明显。我试过让 Agent 只靠工具调用去完成一个多步骤任务它经常在中间步骤跑偏但给它挂一个写清楚流程的 skill成功率明显上升。原因很简单模型不缺能力缺的是“在具体场景下该怎么做的确定性指引”。3. 核心细节解析一个 skill 到底由什么组成3.1 描述文件skill 的“身份证”和“说明书”一个 skill 最核心的部分就是它的描述文件。不同平台叫法不同有的叫SKILL.md有的叫skill.yaml有的叫manifest.json但内容结构大同小异。我以最常见的 Markdown 格式为例拆解一下它应该包含哪些字段。名称nameskill 的唯一标识通常用短横线连接的英文小写比如pdf-parser、browser-automation。这个名字要能一眼看出它是干什么的别起my-skill-1这种名字过两天你自己都忘了。描述description这是最关键的一个字段。它不是写给人看的宣传语而是写给 Agent 看的“触发条件”。Agent 会根据这段描述判断当前任务要不要加载这个 skill。所以描述里必须包含这个 skill 能做什么、什么场景下用、有什么前置条件。我见过很多人把 description 写成“这是一个很好用的 PDF 处理工具”这种描述对 Agent 来说几乎没用。正确的写法应该像这样description: 当用户需要从 PDF 文件中提取文本、表格或图片时使用此 skill。 支持扫描版 PDF 的 OCR 识别。前置条件系统需安装 poppler-utils。 不适用于加密 PDF遇到加密文件应先提示用户解密。你看这段描述里包含了触发场景提取 PDF 内容、能力边界支持 OCR、前置条件需要 poppler、排除情况加密 PDF。Agent 读完就知道该不该用它、用了之后要注意什么。指令正文instructions描述之后是具体的操作指令。这部分是给 Agent 的“操作手册”要写清楚步骤、参数、注意事项。好的指令正文应该像给一个新同事写的交接文档——具体、可执行、有例子。元数据metadata可选字段比如版本号、作者、依赖项、适用平台等。团队内部使用时这些信息对管理很有帮助。3.2 脚本与资源让 skill 真正“能干活”光有描述和指令还不够很多 skill 需要实际执行代码。这时候就要用到脚本文件。常见的做法是在 skill 目录下放一个scripts/文件夹里面放 Python、Shell 或 Node 脚本然后在指令正文里告诉 Agent 什么时候调用哪个脚本、传什么参数。这里有个设计上的关键选择是让 Agent 直接执行脚本还是让 Agent 根据指令自己生成代码两种方式各有优劣。直接执行预置脚本的好处是稳定、可测试、结果可预期。你写了一个extract_pdf.py每次调用行为一致不会因为模型状态波动而出错。缺点是灵活性差遇到脚本没覆盖的情况就抓瞎。让 Agent 自己生成代码的好处是灵活能处理各种边界情况。缺点是稳定性差同样的任务两次执行可能结果不同而且生成的代码可能有 bug。我的经验是核心流程用预置脚本边缘情况让 Agent 自己发挥。比如 PDF 提取这个 skill主流程用脚本保证稳定但如果遇到特殊格式的 PDF指令里可以写“如果脚本报错尝试分析 PDF 结构并手动提取”。这样既有稳定性又有兜底能力。3.3 加载机制Agent 是怎么“找到”skill 的理解加载机制你才能写出容易被正确触发的 skill。目前主流的加载流程大致是这样的Agent 启动时会扫描预定义的 skill 目录比如~/.agent/skills/或项目根目录下的.skills/读取每个 skill 的描述文件但只读取名称和描述部分不加载完整内容。这就像建立了一个索引。当用户提出一个任务时Agent 先用自己的判断力或者一个专门的匹配步骤去比对任务和 skill 描述找出可能相关的 skill。然后加载这些 skill 的完整指令注入到当前上下文里。最后按照指令执行任务。这个机制带来几个实操上的启示第一描述要精准不能太宽泛。如果你的 skill 描述是“处理各种文件”那它会在几乎所有任务里被触发反而干扰 Agent 判断。描述要窄到“只在真正需要时才触发”。第二skill 数量不宜过多。虽然理论上可以挂几百个 skill但实际使用中skill 太多会导致匹配准确率下降。我建议单个项目或单个 Agent 配置下常用 skill 控制在 10-20 个以内其余的需要时再手动指定。第三命名和描述要有区分度。如果你有两个 skill 都涉及“数据处理”Agent 很容易搞混。要么合并成一个要么在描述里写清楚各自的适用边界。3.4 上下文注入skill 内容是怎么影响 Agent 行为的当 skill 被加载后它的指令正文会被注入到 Agent 的上下文里。这里有个细节很多人忽略注入的位置和方式会影响效果。如果 skill 内容被放在系统提示system prompt里它的约束力最强Agent 会把它当作“必须遵守的规则”。如果放在用户消息附近它的约束力弱一些更像“参考建议”。大多数平台会把 skill 内容作为系统级指令注入因为 skill 的本质就是“在特定场景下必须遵守的操作规范”。但这也带来一个问题多个 skill 同时加载时可能冲突。比如 skill A 说“输出用 JSON 格式”skill B 说“输出用 Markdown 格式”Agent 就懵了。所以写 skill 时要注意尽量不要定义全局性的输出格式约束而是把格式要求限定在 skill 自己的任务范围内。我踩过的一个坑早期我写了一个“代码审查”skill里面要求“所有输出必须包含行号”。结果这个 skill 被加载后Agent 在干别的任务时也带着行号输出非常别扭。后来我改成“在执行代码审查任务时输出需包含行号”问题就解决了。约束要绑定到场景不要做成全局规则这是写 skill 的一条重要经验。4. 实操过程从零写一个能用的 skill4.1 环境准备与目录结构假设你要为一个前端项目写一个“自动部署”skill。先确定 skill 存放位置。常见的有两种全局目录所有项目共享和项目目录只对当前项目生效。我建议项目相关的 skill 放项目目录通用工具类 skill 放全局目录。以项目目录为例结构大概是这样your-project/ ├── .skills/ │ └── deploy-frontend/ │ ├── SKILL.md │ ├── scripts/ │ │ ├── build.sh │ │ └── deploy.sh │ └── references/ │ └── env-config.md ├── src/ └── package.json.skills/是约定的 skill 根目录deploy-frontend是 skill 名里面的SKILL.md是描述文件scripts/放执行脚本references/放参考文档比如环境变量说明。这里有个实操细节目录名和 SKILL.md 里的 name 字段保持一致。有些平台的加载器会校验这个一致性不一致可能直接忽略。我一开始没注意改了半天没生效后来才发现是名字对不上。4.2 编写 SKILL.md把“怎么做”写清楚下面是我实际在用的一个部署 skill 的 SKILL.md 内容我把它拆开讲。--- name: deploy-frontend description: 当用户需要将前端项目构建并部署到测试或生产环境时使用。 适用于 Vite 和 Webpack 项目。前置条件项目根目录有 package.json 且已配置好 .env.production 文件。不适用于首次部署首次部署需手动配置服务器。 --- # 前端项目部署 ## 使用场景 用户说“部署一下”“发到测试环境”“上线”等且当前目录是前端项目根目录。 ## 执行步骤 1. 确认当前目录有 package.json没有则报错退出。 2. 检查 .env.production 是否存在不存在则提示用户先配置。 3. 执行构建运行 scripts/build.sh。 4. 构建成功后运行 scripts/deploy.sh 上传产物。 5. 部署完成后输出访问地址和本次构建的 commit hash。 ## 注意事项 - 构建失败时不要重试直接把错误日志输出给用户。 - 部署脚本需要 SSH 权限如果报权限错误提示用户检查密钥配置。 - 生产环境部署前必须二次确认测试环境不需要。这份文件里frontmatter 部分两个---之间是元数据Agent 用它来判断是否加载。正文部分是加载后执行的指令。写指令时有几个要点步骤要编号顺序要明确。不要写“先构建然后部署”要写“1. 构建 2. 部署”。模型对编号步骤的执行准确率明显高于自然语言描述。每步要有明确的成功/失败判断。比如“构建成功后执行部署”而不是“构建并部署”。这样 Agent 知道构建失败时不该继续。注意事项单独列出来。这些是容易出错的点单独成节能让 Agent 更重视。4.3 脚本编写稳定性的关键build.sh的内容大概是这样#!/bin/bash set -e # 检查必要文件 if [ ! -f package.json ]; then echo ERROR: package.json not found exit 1 fi # 安装依赖如果 node_modules 不存在 if [ ! -d node_modules ]; then npm install fi # 执行构建 npm run build # 检查构建产物 if [ ! -d dist ] [ ! -d build ]; then echo ERROR: build output directory not found exit 1 fi echo BUILD_SUCCESS几个关键点set -e让脚本遇到错误立即退出避免错误累积每一步都有明确的错误输出方便 Agent 判断最后输出BUILD_SUCCESS作为成功标志Agent 可以据此判断。deploy.sh类似核心是上传产物并输出结果。这里我不展开具体上传逻辑因为不同团队用的方式不同scp、rsync、对象存储 SDK 等但结构是一样的检查前置条件 → 执行操作 → 输出明确结果。提示脚本里的输出信息要结构化比如用ERROR:和SUCCESS:前缀。Agent 解析这些前缀比解析自然语言更可靠。我试过让脚本输出中文描述Agent 经常理解偏差改成固定前缀后判断准确率大幅提升。4.4 测试与迭代怎么知道 skill 写得好不好skill 写完不是就完事了必须测试。我的测试方法分三步第一步单独测脚本。脱离 Agent直接在终端跑build.sh和deploy.sh确认脚本本身没问题。这一步能排除大部分低级错误。第二步触发测试。让 Agent 执行一个应该触发这个 skill 的任务看它有没有正确加载。如果没加载检查 description 是不是写得太窄或太宽。我一般会准备 5-10 个不同表述的测试语句比如“部署一下”“发到测试环境”“帮我上线”看哪些能触发、哪些不能。第三步边界测试。故意制造异常情况比如删掉.env.production、改坏package.json看 Agent 有没有按照注意事项里的要求处理。这一步最能暴露 skill 的健壮性问题。迭代时我习惯在 SKILL.md 里维护一个“变更记录”小节记下每次改了什么、为什么改。比如“v2: 增加生产环境二次确认因为上次误部署到生产”。这样过几个月回头看能快速回忆起当时的考量。4.5 一个完整的触发流程演示假设用户在项目目录下对 Agent 说“帮我把这个项目部署到测试环境。”Agent 的处理流程大致是扫描.skills/目录读取所有 skill 的 name 和 description。比对任务和描述发现deploy-frontend的描述里有“部署到测试或生产环境”匹配成功。加载deploy-frontend/SKILL.md的完整内容。按照指令步骤执行检查 package.json → 检查 .env.production → 运行 build.sh → 运行 deploy.sh → 输出结果。如果中间任何一步失败按照注意事项处理。整个过程里Agent 不需要“理解”部署的原理它只需要按照 skill 里的确定性指令执行。这就是 skills 的核心价值把需要判断的事情提前判断好让 Agent 在运行时只做执行。5. 常见问题与排查技巧实录5.1 skill 不触发怎么办这是最高频的问题。你写了一个 skill但 Agent 就是不用它。排查思路按顺序来先检查目录位置。不同平台扫描的目录不同有的扫~/.config/agent/skills/有的扫项目下的.skills/。确认你的 skill 放在正确位置。我遇到过有人把 skill 放在skills/而不是.skills/差一个点完全不生效。再检查 frontmatter 格式。YAML 格式对缩进和符号很敏感。name:后面要有空格字符串不要用特殊字符冒号后面如果内容包含冒号要加引号。这些细节错了解析直接失败。然后检查 description 的匹配度。把 description 读一遍问自己如果我是 Agent看到这个描述会在什么情况下用它如果描述太抽象比如“处理数据”Agent 匹配不上如果太具体比如“处理 2024 年 3 月的销售数据”又匹配不到别的场景。好的描述是“场景 能力 边界”的组合。最后检查是否有冲突 skill。如果你有两个 skill 描述相似Agent 可能选了另一个。临时把其他 skill 移走看目标 skill 能不能触发能的话就是冲突问题。5.2 脚本执行失败的排查顺序脚本失败的原因很多我整理了一个排查表按出现频率排序问题现象可能原因排查方法权限拒绝脚本没有执行权限chmod x scripts/*.sh命令找不到依赖未安装或 PATH 不对在脚本里用绝对路径或先which检查路径错误脚本用了相对路径但执行目录不对脚本开头cd $(dirname $0)/..切到项目根环境变量缺失Agent 执行环境没有加载 .env在脚本里显式 source 环境文件输出解析失败脚本输出格式和 Agent 预期不符统一用固定前缀如ERROR:SUCCESS:我踩过最坑的一个脚本在终端跑没问题Agent 跑就失败。查了半天发现是 Agent 执行脚本时的工作目录不是项目根目录导致相对路径全错。后来在脚本开头加了cd $(dirname $0)/..问题解决。永远不要假设脚本的执行目录这是血泪教训。5.3 多个 skill 冲突的处理当项目变大skill 变多冲突几乎不可避免。常见的冲突类型有三种触发冲突两个 skill 描述相似Agent 不知道选哪个。解决办法是合并或者在一个 skill 的描述里明确写“不适用于 XX 场景那种情况用另一个 skill”。指令冲突两个 skill 都加载了但指令矛盾。比如一个说“输出 JSON”一个说“输出 Markdown”。解决办法是把格式约束限定在各自任务范围内不要做全局约束。资源冲突两个 skill 都要用同一个端口、同一个临时文件。解决办法是在 skill 里约定好资源命名空间比如临时文件加 skill 名前缀。我的经验是skill 数量超过 15 个时就要开始做分组管理。按功能域分成不同目录比如skills/deploy/、skills/data/、skills/review/然后配置 Agent 按需加载某个组。这样既控制了单次加载数量又保持了组织清晰。5.4 性能与 token 消耗的平衡skill 加载是要消耗 token 的。一个写得详细的 skill指令正文可能有两三千字加载进来就是几千 token。如果一次加载五六个 skilltoken 消耗很可观。优化思路有几个描述精简正文详细。描述部分用于匹配要短控制在两三句话正文部分加载后才读可以详细。这样匹配阶段消耗少只有真正需要时才加载详细内容。拆分大 skill。如果一个 skill 的指令超过 5000 字考虑拆成多个小 skill按子场景触发。比如“部署”可以拆成“构建”“上传”“验证”三个 skill。用引用代替内联。如果 skill 里有大段参考文档比如 API 说明不要直接写在 SKILL.md 里而是放在references/目录在指令里写“需要时读取 references/api.md”。这样默认不加载需要时才读。实测下来经过优化的 skill 组合token 消耗能降低 40% 左右而任务成功率基本不变。这个投入是值得的。5.5 安全边界skill 能做什么、不能做什么最后说一个容易被忽略但很重要的问题skill 的权限边界。skill 本质上是给 Agent 的指令Agent 会按照指令执行操作。如果 skill 里写了“删除 dist 目录”Agent 就会删。如果 skill 里写了“把文件上传到某个地址”Agent 就会传。所以skill 的编写者实际上掌握了 Agent 在这个场景下的操作权限。这意味着几件事不要用来路不明的第三方 skill尤其是涉及文件操作、网络请求、凭证使用的团队内部要有 skill review 机制新 skill 上线前至少一个人看过skill 里的敏感操作删除、上传、改配置要加确认步骤不要静默执行。我自己的做法是所有涉及写操作的 skill指令里都加一条“执行前向用户确认操作内容”。虽然多一步交互但避免了误操作。这个习惯帮我挡过好几次潜在事故。6. 进阶方向skill 生态还能怎么玩6.1 skill 的组合与编排单个 skill 解决单点问题但真实任务往往是多步骤的。比如“把项目部署到测试环境并跑一遍冒烟测试”这涉及部署 skill 和测试 skill。目前大多数平台还不支持 skill 自动编排但你可以手动实现写一个“上层 skill”在指令里写“先加载 deploy-frontend 执行部署再加载 smoke-test 执行测试”。这种编排 skill 的关键是定义清楚 skill 之间的接口上一个 skill 输出什么下一个 skill 需要什么输入。比如部署 skill 输出访问地址测试 skill 需要这个地址作为输入。在编排 skill 里把数据流转写清楚Agent 就能串起来。6.2 从个人 skill 到团队 skill 库个人用 skill怎么方便怎么来。但团队用 skill就要考虑标准化。我们团队的做法是建了一个内部 skill 仓库每个 skill 有固定的目录结构、必填的元数据字段、统一的脚本输出格式。新 skill 提交要过 CI 检查确保格式合规。这样做的好处是 skill 可以跨项目复用。比如“代码审查”skill在 A 项目写好B 项目直接引用不用重写。坏处是前期规范成本高小团队可能觉得没必要。我的建议是三个人以下随便写三个人以上就要定规范否则后期维护会很痛苦。6.3 skill 的版本管理与回滚skill 也是代码也需要版本管理。最基本的要求是skill 目录纳入 git每次修改有 commit message重要变更打 tag。这样出问题时能快速回滚到上一个可用版本。更进一步的做法是给 skill 加版本号字段在 SKILL.md 的 frontmatter 里写version: 1.2.0。Agent 加载时可以记录用了哪个版本出问题时方便定位。我们团队还做了一个简单的 skill 变更日志每次改完在CHANGELOG.md里记一笔谁改的、改了什么、为什么改。这个习惯在排查“为什么昨天还好好的今天就不行了”这类问题时特别有用。6.4 跨平台 skill 的适配思路如果你同时用多个 AI 工具可能会想“能不能写一次 skill到处都能用”。目前还做不到完全通用但可以做到“核心逻辑复用适配层薄”。具体做法是把 skill 的核心指令和脚本抽出来放在一个共享目录然后针对每个平台写一个薄的适配文件只处理平台特有的元数据格式和加载约定。这样核心逻辑只维护一份适配层改动量很小。我试过用这种方式在三个不同工具之间共享一套 skill核心脚本完全复用适配文件每个只有十几行。虽然前期要摸清各平台的差异但长期看省了很多重复劳动。7. 我个人的一些实操体会写了这么多最后分享几个我在实际使用中攒下来的零碎经验都是文档里不会写但很实用的。skill 的 description 值得反复打磨。我有个 skill 改了七版 description触发准确率从 60% 提到 95%。每次改完拿一批测试语句跑一遍记录哪些触发了、哪些没触发慢慢就摸到规律了。这个投入绝对值得因为触发不准的 skill 等于不存在。脚本输出用英文前缀别用中文。我试过错误和ERROR:两种后者被 Agent 正确解析的概率明显更高。可能是模型对英文标记的识别更稳定。同理成功标志用SUCCESS警告用WARN统一格式。skill 里少用“如果……就……”的复杂分支。模型处理多级条件判断时容易出错。如果逻辑复杂宁可拆成多个 skill或者把判断逻辑写进脚本里让脚本输出明确的结果Agent 只做简单判断。定期清理不用的 skill。我每季度会 review 一次 skill 目录把三个月没触发过的 skill 归档。skill 不是越多越好冗余的 skill 会干扰匹配还会增加维护负担。新 skill 先在小范围试。别一上来就全团队推广先自己用一周再拉一两个人用收集反馈改几轮稳定了再推广。我见过太多“写的时候觉得完美用起来一堆问题”的 skill。把 skill 当产品做不是当脚本写。脚本只关心“能不能跑通”skill 要关心“Agent 能不能正确理解和使用”。这两者的标准不一样。多站在 Agent 的角度想“它看到这段指令会怎么理解”比站在自己的角度想“我写得清不清楚”更重要。这个领域变化很快今天的最佳实践明天可能就过时了。但底层逻辑是不变的把确定性的知识固化下来让 Agent 在确定性上执行在不确定性上发挥。抓住这条主线具体的技术细节怎么变都能跟上。