1. 从“skills”这个词说起你最近一定被它刷屏了如果说 2025 年技术圈有什么词被提到了最多次我第一反应就是 “skills”。各大 AI 产品更新都在强调技能各路博主都在聊技能连招聘软件上都开始要求“具备 AI 技能”。但如果你仔细追问一句“skills 到底是什么”十个人能给你八种答案。有人说是给 AI 用的插件有人说是人的能力模型还有人说是某种 JSON 配置。我起初也被绕得晕头转向直到自己动手拆了几套方案、在真实工作流里试了两个月才把“skills”这个概念彻底嚼碎。这篇文章不打算讲虚的我就从一个实际干过、踩过坑、迭代过几个版本的人的角度把 AI 时代的 skills 拆给你看——既讲怎么定义和搭建一套给 Agent 用的技能包也讲在这个工具狂飙的年代个人该怎么把自己的能力栈做成真正可复用、可迁移的技能体系。先说清楚这里聊的 skills 主要有两条线。第一条线是面向 AI Agent 的“技能包”你可以把它理解成给 AI 助手外挂的一本本“操作手册工具箱”让模型在面对特定任务时不再瞎猜而是按你预设的方法论和工具链稳定输出。第二条线是面向我们自己的“技能栈”也就是在 AI 能完成大量基础工作的背景下一个人该保留什么、训练什么、包装什么才能不被工具替代反而把工具用得飞起。这两条线表面上是两码事内核却高度一致都是把“会做一件事”从玄学变成工程从一次性碰运气变成可复制、可迭代、可交付的资产。这篇文章适合谁看如果你是做 AI 应用开发、Agent 编排、自动化流程设计的工程师第一条线的目录结构、编写规范、调试方法可以直接抄如果你是产品经理、运营、自由职业者或者任何担心被 AI 冲击的职场人第二条线关于个人技能栈的拆解和构建方法能给你一份不那么焦虑的行动清单。两条线我都会给到基于真实操作的方案而不是那种收藏了再也没打开过的鸡汤清单。2. 我理解的 skills 到底是什么给 AI 的“武功秘籍”也是给自己的“能力地图”2.1 设备端技能包的本质预设行为框架而不是塞更多知识我最初对“skills”有个误解以为它跟 RAG检索增强生成差不多就是给 AI 多塞点资料让它回答得更准。实际动手才发现完全不是一回事。RAG 解决的是“知识缺失”问题模型不知道某件事你喂给它文档它就能结合上下文回答而 skills 解决的是“行为随意”问题模型知道该怎么做但它每次做的方式可能不一样质量不稳定而且不会调用你准备好的工具链。举个例子。让一个没有技能包的通用模型“帮我整理本周的周报”它可能会写一段还不错的文字但格式、详略、数据引用方式每次都有细微差异。如果你给它装上一个“周报生成技能”这个技能里写清楚了流程先读取本周的日程和任务记录再用统一的模板生成摘要然后按预设格式输出 Markdown 文件最后自动发送到指定文件夹。模型只是执行引擎真正体现你工作方法论的是技能包里的指令和参数。这就像你雇了一个能力很强但没经验的实习生。你不可能每次都说“你去把周报写了”就算完你得告诉他去哪拿数据、按什么结构写、写到什么程度、用什么格式交。Agent 的技能包本质上就是把“如何带实习生”的经验固化成文件以后不管换多少个实习生换哪种模型流程都不变。想通了这一点你就明白了为什么现在各大 Agent 平台都把技能机制当成核心卖点——模型会越来越强但“怎么做一件事”的方法论才是真正属于你的竞争壁垒。2.2 个人技能栈的重新定义AI 时代的能力单元从“知识量”变成“调用链”说完 AI 的技能包再看人的技能。很多人焦虑“AI 都会了我还能会什么”我觉得这个焦虑本身问错了方向。以前我们评价一个人靠的是“你懂多少”现在模型的知识量已经碾压人类比“知道什么”没有意义了。真正值钱的变成了“你能不能用工具把一个事从头到尾跑通”。这个“从头到尾跑通”的能力就是我要说的个人技能栈。你可以把它拆成三层来看。最底层是领域常识你知道业务是怎么运转的关键指标有哪些坑在哪里中间层是工具调用你会用哪些 AI 工具、自动化平台、传统软件把想法变成产出最顶层是拆解判断拿到一个模糊任务你能拆成几个小步骤知道哪一步该用 AI、哪一步必须人工、哪一步要停下来判断。三层合在一起才是完整的“做事能力”。举个例子你就明白了。同样是“给公司做一份竞品分析报告”一个只会用通用对话模型的同事可能会让 AI 直接生成一篇看起来很有道理但数据全是编的报告而具备完整技能栈的人会先规划信息源去哪些网站抓真实数据再确定分析框架从产品、价格、渠道、营销四个维度切入然后让 AI 帮你抓取和整理数据最后自己根据经验的判断写结论部分。整个过程里 AI 负责了 70% 的执行但那 30% 的规划和判断才是报告价值的核心。以前我们卖的是“把报告写出来”的能力现在要卖的是“设计一套报告生产线”的能力这就是技能栈升级的意义。3. 实操从零搭建一个可复用的 AI 技能包3.1 技能包的目录设计与文件结构理论说了不少直接上手。我以目前用得比较多的 Cluade 风格技能为例讲一套我自己验证过多次的最小可用结构。你先别管具体平台叫什么名字核心思想是通用的一个技能包就是一个文件夹里面有说明文档、有参考示例、有脚本工具三层结构各司其职。我习惯的目录长这样skill-name/ ├── SKILL.md # 技能说明触发条件、执行流程、注意事项 ├── reference/ # 参考资料模板、示例、领域知识 │ ├── template.md # 输出模板 │ └── examples/ # 优秀案例样本 └── scripts/ # 可执行工具脚本、接口调用、数据处理 ├── fetch_data.py # 数据采集脚本 └── format_output.py # 格式化输出脚本第一次搭的时候我犯了个错把所有内容全塞进一个超大 SKILL.md结果模型读起来非常吃力因为上下文长度有限技能说明太长反而挤占了真正干活的余地。后来我把“说明文档”和“参考内容”分离SKILL.md 只写最关键的行动指令控制在 200-400 行以内详细的模板和例子放进 reference 目录等执行到那一步再按需读取。这个调整效果立竿见影技能执行的准确率和效率都明显提升。这里的关键思维是技能包不是给模型“背课文”而是给模型“查手册”信息要分层存放按需加载。3.2 SKILL.md 的核心组成部分让模型一读就懂的编写规范如果你只打算记住一个文件那就记住 SKILL.md。它是一份标准的 Markdown 文档但它的写法跟普通文档截然不同。普通文档是给人读的讲究逻辑完整、措辞优美SKILL.md 是给模型读的讲究指令清晰、流程明确、边界清楚。我写了几十版之后总结出的关键结构如下表区块作用核心写作要点技能名称与描述让模型判断什么时候该调用这个技能写清楚适用场景、不适用场景别含糊触发条件定义动作启动的门槛说明是自主调用还是被动调用推荐自主场景执行步骤核心行动流程按顺序编号每一步描述动作产出物输出规范交付标准给模板、给格式、给质量要求避免自由发挥注意事项边界与禁忌写清楚什么不能做什么情况下要停下来问人举个例子我之前写过一个“会议纪要技能”第一步版本写得特别随意“记录会议要点并整理为纪要。”效果就是模型把对话记录抄了一遍毫无结构。后来我改成了这样执行步骤 1. 先读取完整的会议转写文本识别参与者和时间线。 2. 提取三大类信息决策事项明确结论、待办事项责任人截止时间、风险事项未决议题。 3. 按标准模板输出会议概况、决策摘要、待办清单、遗留问题。 4. 如果信息不足以判断责任人或结论标记为【待确认】严禁捏造。差别在哪里第一步版本只说了“做什么”没有说“怎么做”模型只能用它的本能后面的版本给出了处理顺序和判断标准模型就像拿到了流程图每一步的输出都在预期轨道上。写 SKILL.md 最忌讳的就是描述性语言太多而操作性不足记住你是给执行者下达作战命令不是写散文。3.3 scripts 目录的使用当逻辑不够代码来凑一开始我只用文本指令写技能后来发现有些活光靠模型“思考”搞不定比如精确计算、数据清洗、调用外部 API、操作文件系统。这时候就要在技能包里放真正的代码让模型在指令的引导下执行脚本而不是自己硬算。我给你看看我实际用过的一个例子给一个销售团队写的“线索评分技能”。SKILL.md 里定义了评分维度和流程但真正的分数计算没法让模型心算——它算不准。于是我在 scripts 里放了一个score_leads.py输入线索数据输出每个线索的分数和优先级。SKILL.md 里的执行步骤就变成“调用 score_leads.py 完成评分”模型只需要负责整理输入、运行脚本、解读输出就足够了。这就像是你给实习生配备了一个计算器你要教他的就变成了“什么数据输入进去、怎么解读算出来的结果”。但这里有个实操细节很多新手会忽略代码要写“防御性”一点因为最终执行代码的是模型它可能不按你的预期传参数。我吃过一次亏脚本里要求 JSON 输入字段名是company_name模型自作主张传成了company结果跑出错误。后来我在脚本头部加了一段参数校验字段名不匹配就自动尝试映射错误率就降下来了。考虑模型会犯低级错误并写代码时就把这些兜底掉是技能包工程里很重要的一环。3.4 技能包的迭代与版本管理把技能当代码一样维护技能包写出来不是一劳永逸的。我第一版“周报技能”用了不到两周就发现输出质量下降——原来团队的汇报格式改了模板却没更新。从那以后我把技能包当成正经代码来维护git 仓库管理、每次修改都记 changelog、大改动先跑测试样例再上线。迭代路径我是这么走的先在真实任务中试用几个周期记录模型在哪一步出了问题然后针对出问题的环节要么细化 SKILL.md 的指令要么补充 reference 里的示例要么改脚本逻辑改完跑一遍历史案例做回归看会不会影响原来正常的输出。这个“记录问题-修改文件-回归验证”的循环跑熟了之后技能包的稳定性会越来越好。我现在手里有六个常用技能包每个都迭代了十几个版本最开始的版本跟现在的版本已经完全不是同一个东西了。最让我意外的是迭代过程中我对“自己到底是怎么做这件事的”反而越来越清楚——很多平时凭直觉的工作方式被显性化之后我发现原来可以优化、可以标准化、可以教给别人。4. 一个完整的技能包实测案例从需求到交付的全过程4.1 需求定义将模糊诉求拆成可执行的动作光讲抽象方法论容易飘我拿一个实际做过的案例走一遍全流程。背景很简单一个做跨境电商的朋友每周要花半天时间整理竞品动态然后写成一份简报发到团队群里。他找到我说想用 AI 把这活儿自动化。如果只听到“帮我自动写个竞品简报”大多数人第一反应就是让 AI 直接写。但如果你认真拆解会发现这件事远没那么简单——“竞品动态”数据从哪来哪些平台的信息值得采集一周看一次还是一天看一次简报格式要求是什么发给谁看看完之后要做什么决策我把需求拆成了五个具体问题每个问题对应技能包里的一个模块设计。信息源锁定三家竞品的官网和社交媒体账号采集频率定为一周两次放在周二和周四早上参数上确定采集哪些字段——产品更新、价格变动、营销活动、用户反馈关键词输出格式是一页 A4 内的要点式简报分“重要变化”“趋势观察”“建议动作”三栏使用方式是完全自动化生成后自动存到指定网盘并推送通知。你看到了这一步“写一个竞品简报技能”已经变成了非常具体的工程需求剩下的就是按图索骥。4.2 分步实现写指令、配脚本、跑通闭环需求拆完之后我开始动手搭。SKILL.md 的核心指令写成了这样技能竞品动态简报生成器 触发每日定时任务执行或用户输入“生成竞品简报” 流程 1. 读取 config.json 中配置的竞品列表和信息源规则 2. 对每个信息源调用 fetch_updates.py 拉取最近的更新内容 3. 使用 summarize.py 对原始内容做摘要提取过滤掉无关信息 4. 合并所有摘要按模板生成简报 Markdown 文件 5. 输出结果并存储到指定目录 注意事项 - 只采集配置文件中列出的信息源不得自行扩展 - 摘要必须注明信息来源信息不确定时标注“待核实” - 模板中的“建议动作”栏目默认生成“暂不采取行动”避免过度解读scripts 目录里放了三个脚本fetch_updates.py负责抓取 RSS 和网页内容、summarize.py负责调用模型接口做摘要、generate_report.py负责拼装最终 Markdown。虽然这套东西的“AI 含量”看着不高——大部分代码都是传统的抓取和字符串处理——但正是这些确定性代码保证了每天输出的稳定性。AI 负责的是理解和归纳代码负责的是执行和交付各干各的活这个分工非常重要。跑通第一步时还出了个乌龙我把定时触发的配置搞错了时区结果是每天早上六点跑一遍我以为没触发实际上它偷偷跑了好几天。后来我养成了习惯凡是定时任务第一次跑完一定要查日志和输出物确认没问题再放手。另外我也学会了用加餐的方式先手动触发一次确认全链路通了再挂定时。别嫌这些检查啰嗦自动化流程里最贵的成本就是“你以为它在跑其实它早就坏了”。4.3 效果验证与迭代记录这个技能包上线后我记录了前六周的表现数据。需要人工干预的情况从第一周的 4 次降到了第六周的接近 0 次简报生成成功率稳定在 95% 以上输出质量方面朋友反馈“可以看”“偶尔会有小惊喜”三个模块里“趋势观察”的质量波动最大原因是模型对模糊信息的判断不稳定。针对这个痛点我在 reference 目录里增加了十几个历史案例都是之前判断比较准的输出相当于给模型喂了“好答案的样子”。加了这批示例之后质量波动明显变小。这个经验我觉得特别值得分享想让模型输出的质量稳定与其反复修改指令不如直接给它看几个优秀的输出范例。指令负责规定“不能做什么”范例负责示范“应该做成什么样”两个配合才能把模型的行为框在一个高质量区间内。后来我给这个技能继续迭代增加了一个“每周一自动给前一周的报告做归档”的功能以及一个简单的关键词趋势统计让简报从“资讯汇总”慢慢变成了“情报产品”。这就是我想说的技能包的真正价值——它不是把一个任务变成自动化工具而是把一个人处理信息的经验沉淀成了可以运行、可以复制、不断进化的资产。5. 常见问题与排查技巧实录5.1 技能不生效模型就是不听指令怎么办这是使用率最高的问题我一开始也经常碰到“写了那么详细的 SKILL.md模型怎么好像根本看见它”我排查这个问题的顺序是固定的。先看技能包有没有被正确装载——很多平台的技能系统是默认关闭的需要你在配置里显式开启再看 SKILL.md 的开头描述写得清不清楚因为模型判断“该不该启用这个技能”主要靠的就是开头那几行描述——如果描述写得太笼统模型会把它忽略掉最后检查指令里是否包含了模型“做不到”的事比如让它精确读取某个外部数据库而不提供任何工具——那它就只好用猜的。如果是文本指令层面的问题我通常用两个技巧解决。技巧一在 SKILL.md 里加一个“当任务涉及 XX 场景时必须使用本技能”的强触发句式把触发条件写成 if-then 的硬规则而不是软性的“可以参考”。技巧二在用户消息里加上一句“请先查看技能说明再开始执行”直接把模型的注意力引向技能文档。别小看这招实测下来启用率确实会高很多。5.2 输出质量不稳定同一个技能这次好下次差输出质量波动是常态尤其当你换模型版本或供应商接口的时候。我排查质量问题先区分是“流程错了”还是“内容差了”如果流程执行乱了说明指令里步骤不够清晰需要拆细或者加检查点如果流程对但内容不行那就往 reference 里补充更高质量的示例。记住质量的天花板。环境变化也是一个重要变量。同样一个技能包在 A 模型上表现尚可在 B 模型上效果打折这是非常普遍的现象。因为不同模型的指令遵循能力、格式偏好都有差异。我现在的做法是给技能包做“兼容层”在 SKILL.md 里增加一小段“模型适配说明”根据不同模型调整措辞风格比如有些模型吃“必须”这种强命令有些模型吃“请确保”这种礼貌指令。把适配工作写进技能文档能让你换模型时少掉一半头发。5.3 脚本执行报错模型不会用你写的工具模型调用脚本出错十有八九不是脚本本身的问题而是“路径没写对”或“参数传错了”。我踩过最典型的坑脚本的相对路径是相对于技能包所在的目录但模型执行时的工作目录可能完全不是那个位置结果文件读写失败。解决方案是脚本内部先用自己的绝对路径做基准别依赖运行时的工作目录。另一个坑是模型喜欢自由发挥地改参数比如我规定fetch_updates.py的--days参数传 3它偏要传 7。解决办法是在脚本入口做严格的参数校验如果模型传了不在允许集合里的值就直接报错并输出帮助信息。用代码强行锁死边界别指望模型自觉。5.4 常见问题速查表现象可能原因快速排查与解决技能完全没被执行技能未开启 / 触发描述不清晰确认平台配置已开启强化 SKILL.md 开头的触发条件写清 if-then 硬规则技能执行了但输出太泛SKILL.md 里“怎么做到”不够具体增加执行步骤编号每步写明动作产出物补充输出模板同技能输出忽好忽坏参考示例不足 / 模型版本变化在 reference 里增加历史优秀案例写一段模型适配说明脚本报错找不到文件运行时工作目录不一致脚本内使用绝对路径或基于自身位置计算路径定时任务没按预期跑时区配置错误 / 日志没开首次部署先手动触发验证再挂定时检查时区设置并保留日志数据抓取不全目标网站结构变更把抓取逻辑做成插件式定期检查信息源是否正常工作配置来源数量时留冗余6. 从“用技能的人”到“造技能的人”——个人能力升级路径6.1 盘点你的高频任务找到技能化的优先选择讲完了技术上的技能包我想跟你聊聊作为个人我们到底该怎么在这个 AI 遍地走的时代保持竞争力。我的核心观点是把 AI 当成需要你管理的外包团队你作为“技能架构师”负责设计每个人Agent的职责和操作手册。那怎么入门从盘点你自己的高频工作开始。打开你的日历和任务清单找出过去一周重复出现三类以上的任务写周报、回复常规邮件、整理数据、做PPT、做会议纪要、调研背景资料……任何“你做得熟、可流程化、花时间”的事情都在技能化候选名单上。判断优先级有个标准频率高、耗时多、产出物标准化程度高——满足这三个条件就先从它开始。比如你每周要花两个小时做周报那你花半天把周报流程技能化两个月后你就把时间省回来了。具体落地上我建议你从最简单的“一人技能”开始不搞复杂的平台功能就用通用 AI 工具创建自定义指令或提示词模板把你的工作流程写进去。我在自己电脑上建了一个“我的技能库”文件夹每个技能就是一个 Markdown 文件遇到高频任务就在里面调用对应文件作为提示词。一个月下来我发现自己大部分的重复劳动都已经有了“标准作业程序”这不仅省时间更重要的是我脑子里的混乱感和焦虑感消失了——以前工作老觉得事情多但理不清现在已经把“做事”变成了“查说明书执行”。6.2 学会设计“人机协作的检查点”而不是追求全自动很多人一听到自动化、技能化第一反应就是“要全部跑通完全不用人管”。这个目标不光难实现而且也不该追求。AI 自动化真正厉害的地方在于“二八原则”它能替代你流程中 80% 的执行时间但那 20% 的判断节点必须由人来掌握。千万不要把这 20% 也拱手让出去因为那才是你的价值所在。怎么设计检查点我自己的经验是在流程里故意设置三到四道“人工审批闸门”。比如在重要决策场景只负责生成选项由你来拍板选哪个方向继续拆解在对外输出场景只负责写初稿检查和定稿必须由你亲自过手在数据敏感场景只负责整理不负责最终核验关键数字你一定要复核。这样做的好处有两方面一是保证输出质量避免 AI 的小失误直接砸了你的招牌二是你会对这套流程始终有掌控感和理解力不会被工具带偏。说白了技能化的终极目标不是解放你自己而是解放你的时间、提升你的杠杆、放大你的判断力。工具负责把“你已经懂的东西”跑得更快人则负责把“你还想搞清楚的东西”持续推进。未来最理想的工作状态不是一大堆 Agent 在你不在场的情况下把工作做完给你个结果而是你像一位图纸设计师加监理设计系统、指定标准、巡视关键节点、对最终产品负责。这个角色画像才是 AI 时代的“技能高手”。6.3 用个人技能库给职场叙事增加硬通货最后聊一个比较现实的问题技能化怎么变成你职场上的竞争力我观察身边混得比较好的同事和朋友他们都有个共通点——不只是“会做事”而是“能讲清楚自己怎么做事”。技能化天生就在帮你干这件事因为你把经验写成了结构化的流程和参数你的工作方法从“独特的直觉”变成了“可复用的资产”这在沟通、协作、面试的场景里都是巨大的加分项。比如你面试时说“我熟悉内容运营”人家只能得到一个模糊印象如果你说“我搭了一套内容选题技能库包含 5 个细分场景的 SOP、19 个参数化的选题判断标准用它让选题会议从 2 小时压缩到 40 分钟”这个说服力就完全不一样了。前者是“我会做事”后者是“我能把事做成系统”而后者才是高阶岗位真正需要的能力。我的建议很朴素花一个周末的时间把你自己最拿手的三项工作写成技能文档。不是为了给别人看纯粹是逼自己把工作方法看清楚。你在写的过程中大概率会发现原来自己还有这么多隐性的判断可以沉淀成标准——这个过程本身就是一次高质量的自我复盘。我在实操中最深的一个体会是技能化不是一个“做完了就结束”的工程它是一个持续进行时。今天你觉得完美的流程三个月后可能就被更好的工具或方法颠覆了。但只要你保持“把自己的工作显性化、工程化”的习惯你就永远能站在工具的肩膀上而不是被工具牵着走。如果你也正在尝试构建自己的技能包或技能库欢迎按着这篇文章里的路径先跑一版遇到具体问题慢慢调。毕竟技能这个东西光看文章是学不来的动手做一版、坏掉一次、修好一次——那才是真正属于你自己的技能。
1. 从“skills”这个词说起你最近一定被它刷屏了如果说 2025 年技术圈有什么词被提到了最多次我第一反应就是 “skills”。各大 AI 产品更新都在强调技能各路博主都在聊技能连招聘软件上都开始要求“具备 AI 技能”。但如果你仔细追问一句“skills 到底是什么”十个人能给你八种答案。有人说是给 AI 用的插件有人说是人的能力模型还有人说是某种 JSON 配置。我起初也被绕得晕头转向直到自己动手拆了几套方案、在真实工作流里试了两个月才把“skills”这个概念彻底嚼碎。这篇文章不打算讲虚的我就从一个实际干过、踩过坑、迭代过几个版本的人的角度把 AI 时代的 skills 拆给你看——既讲怎么定义和搭建一套给 Agent 用的技能包也讲在这个工具狂飙的年代个人该怎么把自己的能力栈做成真正可复用、可迁移的技能体系。先说清楚这里聊的 skills 主要有两条线。第一条线是面向 AI Agent 的“技能包”你可以把它理解成给 AI 助手外挂的一本本“操作手册工具箱”让模型在面对特定任务时不再瞎猜而是按你预设的方法论和工具链稳定输出。第二条线是面向我们自己的“技能栈”也就是在 AI 能完成大量基础工作的背景下一个人该保留什么、训练什么、包装什么才能不被工具替代反而把工具用得飞起。这两条线表面上是两码事内核却高度一致都是把“会做一件事”从玄学变成工程从一次性碰运气变成可复制、可迭代、可交付的资产。这篇文章适合谁看如果你是做 AI 应用开发、Agent 编排、自动化流程设计的工程师第一条线的目录结构、编写规范、调试方法可以直接抄如果你是产品经理、运营、自由职业者或者任何担心被 AI 冲击的职场人第二条线关于个人技能栈的拆解和构建方法能给你一份不那么焦虑的行动清单。两条线我都会给到基于真实操作的方案而不是那种收藏了再也没打开过的鸡汤清单。2. 我理解的 skills 到底是什么给 AI 的“武功秘籍”也是给自己的“能力地图”2.1 设备端技能包的本质预设行为框架而不是塞更多知识我最初对“skills”有个误解以为它跟 RAG检索增强生成差不多就是给 AI 多塞点资料让它回答得更准。实际动手才发现完全不是一回事。RAG 解决的是“知识缺失”问题模型不知道某件事你喂给它文档它就能结合上下文回答而 skills 解决的是“行为随意”问题模型知道该怎么做但它每次做的方式可能不一样质量不稳定而且不会调用你准备好的工具链。举个例子。让一个没有技能包的通用模型“帮我整理本周的周报”它可能会写一段还不错的文字但格式、详略、数据引用方式每次都有细微差异。如果你给它装上一个“周报生成技能”这个技能里写清楚了流程先读取本周的日程和任务记录再用统一的模板生成摘要然后按预设格式输出 Markdown 文件最后自动发送到指定文件夹。模型只是执行引擎真正体现你工作方法论的是技能包里的指令和参数。这就像你雇了一个能力很强但没经验的实习生。你不可能每次都说“你去把周报写了”就算完你得告诉他去哪拿数据、按什么结构写、写到什么程度、用什么格式交。Agent 的技能包本质上就是把“如何带实习生”的经验固化成文件以后不管换多少个实习生换哪种模型流程都不变。想通了这一点你就明白了为什么现在各大 Agent 平台都把技能机制当成核心卖点——模型会越来越强但“怎么做一件事”的方法论才是真正属于你的竞争壁垒。2.2 个人技能栈的重新定义AI 时代的能力单元从“知识量”变成“调用链”说完 AI 的技能包再看人的技能。很多人焦虑“AI 都会了我还能会什么”我觉得这个焦虑本身问错了方向。以前我们评价一个人靠的是“你懂多少”现在模型的知识量已经碾压人类比“知道什么”没有意义了。真正值钱的变成了“你能不能用工具把一个事从头到尾跑通”。这个“从头到尾跑通”的能力就是我要说的个人技能栈。你可以把它拆成三层来看。最底层是领域常识你知道业务是怎么运转的关键指标有哪些坑在哪里中间层是工具调用你会用哪些 AI 工具、自动化平台、传统软件把想法变成产出最顶层是拆解判断拿到一个模糊任务你能拆成几个小步骤知道哪一步该用 AI、哪一步必须人工、哪一步要停下来判断。三层合在一起才是完整的“做事能力”。举个例子你就明白了。同样是“给公司做一份竞品分析报告”一个只会用通用对话模型的同事可能会让 AI 直接生成一篇看起来很有道理但数据全是编的报告而具备完整技能栈的人会先规划信息源去哪些网站抓真实数据再确定分析框架从产品、价格、渠道、营销四个维度切入然后让 AI 帮你抓取和整理数据最后自己根据经验的判断写结论部分。整个过程里 AI 负责了 70% 的执行但那 30% 的规划和判断才是报告价值的核心。以前我们卖的是“把报告写出来”的能力现在要卖的是“设计一套报告生产线”的能力这就是技能栈升级的意义。3. 实操从零搭建一个可复用的 AI 技能包3.1 技能包的目录设计与文件结构理论说了不少直接上手。我以目前用得比较多的 Cluade 风格技能为例讲一套我自己验证过多次的最小可用结构。你先别管具体平台叫什么名字核心思想是通用的一个技能包就是一个文件夹里面有说明文档、有参考示例、有脚本工具三层结构各司其职。我习惯的目录长这样skill-name/ ├── SKILL.md # 技能说明触发条件、执行流程、注意事项 ├── reference/ # 参考资料模板、示例、领域知识 │ ├── template.md # 输出模板 │ └── examples/ # 优秀案例样本 └── scripts/ # 可执行工具脚本、接口调用、数据处理 ├── fetch_data.py # 数据采集脚本 └── format_output.py # 格式化输出脚本第一次搭的时候我犯了个错把所有内容全塞进一个超大 SKILL.md结果模型读起来非常吃力因为上下文长度有限技能说明太长反而挤占了真正干活的余地。后来我把“说明文档”和“参考内容”分离SKILL.md 只写最关键的行动指令控制在 200-400 行以内详细的模板和例子放进 reference 目录等执行到那一步再按需读取。这个调整效果立竿见影技能执行的准确率和效率都明显提升。这里的关键思维是技能包不是给模型“背课文”而是给模型“查手册”信息要分层存放按需加载。3.2 SKILL.md 的核心组成部分让模型一读就懂的编写规范如果你只打算记住一个文件那就记住 SKILL.md。它是一份标准的 Markdown 文档但它的写法跟普通文档截然不同。普通文档是给人读的讲究逻辑完整、措辞优美SKILL.md 是给模型读的讲究指令清晰、流程明确、边界清楚。我写了几十版之后总结出的关键结构如下表区块作用核心写作要点技能名称与描述让模型判断什么时候该调用这个技能写清楚适用场景、不适用场景别含糊触发条件定义动作启动的门槛说明是自主调用还是被动调用推荐自主场景执行步骤核心行动流程按顺序编号每一步描述动作产出物输出规范交付标准给模板、给格式、给质量要求避免自由发挥注意事项边界与禁忌写清楚什么不能做什么情况下要停下来问人举个例子我之前写过一个“会议纪要技能”第一步版本写得特别随意“记录会议要点并整理为纪要。”效果就是模型把对话记录抄了一遍毫无结构。后来我改成了这样执行步骤 1. 先读取完整的会议转写文本识别参与者和时间线。 2. 提取三大类信息决策事项明确结论、待办事项责任人截止时间、风险事项未决议题。 3. 按标准模板输出会议概况、决策摘要、待办清单、遗留问题。 4. 如果信息不足以判断责任人或结论标记为【待确认】严禁捏造。差别在哪里第一步版本只说了“做什么”没有说“怎么做”模型只能用它的本能后面的版本给出了处理顺序和判断标准模型就像拿到了流程图每一步的输出都在预期轨道上。写 SKILL.md 最忌讳的就是描述性语言太多而操作性不足记住你是给执行者下达作战命令不是写散文。3.3 scripts 目录的使用当逻辑不够代码来凑一开始我只用文本指令写技能后来发现有些活光靠模型“思考”搞不定比如精确计算、数据清洗、调用外部 API、操作文件系统。这时候就要在技能包里放真正的代码让模型在指令的引导下执行脚本而不是自己硬算。我给你看看我实际用过的一个例子给一个销售团队写的“线索评分技能”。SKILL.md 里定义了评分维度和流程但真正的分数计算没法让模型心算——它算不准。于是我在 scripts 里放了一个score_leads.py输入线索数据输出每个线索的分数和优先级。SKILL.md 里的执行步骤就变成“调用 score_leads.py 完成评分”模型只需要负责整理输入、运行脚本、解读输出就足够了。这就像是你给实习生配备了一个计算器你要教他的就变成了“什么数据输入进去、怎么解读算出来的结果”。但这里有个实操细节很多新手会忽略代码要写“防御性”一点因为最终执行代码的是模型它可能不按你的预期传参数。我吃过一次亏脚本里要求 JSON 输入字段名是company_name模型自作主张传成了company结果跑出错误。后来我在脚本头部加了一段参数校验字段名不匹配就自动尝试映射错误率就降下来了。考虑模型会犯低级错误并写代码时就把这些兜底掉是技能包工程里很重要的一环。3.4 技能包的迭代与版本管理把技能当代码一样维护技能包写出来不是一劳永逸的。我第一版“周报技能”用了不到两周就发现输出质量下降——原来团队的汇报格式改了模板却没更新。从那以后我把技能包当成正经代码来维护git 仓库管理、每次修改都记 changelog、大改动先跑测试样例再上线。迭代路径我是这么走的先在真实任务中试用几个周期记录模型在哪一步出了问题然后针对出问题的环节要么细化 SKILL.md 的指令要么补充 reference 里的示例要么改脚本逻辑改完跑一遍历史案例做回归看会不会影响原来正常的输出。这个“记录问题-修改文件-回归验证”的循环跑熟了之后技能包的稳定性会越来越好。我现在手里有六个常用技能包每个都迭代了十几个版本最开始的版本跟现在的版本已经完全不是同一个东西了。最让我意外的是迭代过程中我对“自己到底是怎么做这件事的”反而越来越清楚——很多平时凭直觉的工作方式被显性化之后我发现原来可以优化、可以标准化、可以教给别人。4. 一个完整的技能包实测案例从需求到交付的全过程4.1 需求定义将模糊诉求拆成可执行的动作光讲抽象方法论容易飘我拿一个实际做过的案例走一遍全流程。背景很简单一个做跨境电商的朋友每周要花半天时间整理竞品动态然后写成一份简报发到团队群里。他找到我说想用 AI 把这活儿自动化。如果只听到“帮我自动写个竞品简报”大多数人第一反应就是让 AI 直接写。但如果你认真拆解会发现这件事远没那么简单——“竞品动态”数据从哪来哪些平台的信息值得采集一周看一次还是一天看一次简报格式要求是什么发给谁看看完之后要做什么决策我把需求拆成了五个具体问题每个问题对应技能包里的一个模块设计。信息源锁定三家竞品的官网和社交媒体账号采集频率定为一周两次放在周二和周四早上参数上确定采集哪些字段——产品更新、价格变动、营销活动、用户反馈关键词输出格式是一页 A4 内的要点式简报分“重要变化”“趋势观察”“建议动作”三栏使用方式是完全自动化生成后自动存到指定网盘并推送通知。你看到了这一步“写一个竞品简报技能”已经变成了非常具体的工程需求剩下的就是按图索骥。4.2 分步实现写指令、配脚本、跑通闭环需求拆完之后我开始动手搭。SKILL.md 的核心指令写成了这样技能竞品动态简报生成器 触发每日定时任务执行或用户输入“生成竞品简报” 流程 1. 读取 config.json 中配置的竞品列表和信息源规则 2. 对每个信息源调用 fetch_updates.py 拉取最近的更新内容 3. 使用 summarize.py 对原始内容做摘要提取过滤掉无关信息 4. 合并所有摘要按模板生成简报 Markdown 文件 5. 输出结果并存储到指定目录 注意事项 - 只采集配置文件中列出的信息源不得自行扩展 - 摘要必须注明信息来源信息不确定时标注“待核实” - 模板中的“建议动作”栏目默认生成“暂不采取行动”避免过度解读scripts 目录里放了三个脚本fetch_updates.py负责抓取 RSS 和网页内容、summarize.py负责调用模型接口做摘要、generate_report.py负责拼装最终 Markdown。虽然这套东西的“AI 含量”看着不高——大部分代码都是传统的抓取和字符串处理——但正是这些确定性代码保证了每天输出的稳定性。AI 负责的是理解和归纳代码负责的是执行和交付各干各的活这个分工非常重要。跑通第一步时还出了个乌龙我把定时触发的配置搞错了时区结果是每天早上六点跑一遍我以为没触发实际上它偷偷跑了好几天。后来我养成了习惯凡是定时任务第一次跑完一定要查日志和输出物确认没问题再放手。另外我也学会了用加餐的方式先手动触发一次确认全链路通了再挂定时。别嫌这些检查啰嗦自动化流程里最贵的成本就是“你以为它在跑其实它早就坏了”。4.3 效果验证与迭代记录这个技能包上线后我记录了前六周的表现数据。需要人工干预的情况从第一周的 4 次降到了第六周的接近 0 次简报生成成功率稳定在 95% 以上输出质量方面朋友反馈“可以看”“偶尔会有小惊喜”三个模块里“趋势观察”的质量波动最大原因是模型对模糊信息的判断不稳定。针对这个痛点我在 reference 目录里增加了十几个历史案例都是之前判断比较准的输出相当于给模型喂了“好答案的样子”。加了这批示例之后质量波动明显变小。这个经验我觉得特别值得分享想让模型输出的质量稳定与其反复修改指令不如直接给它看几个优秀的输出范例。指令负责规定“不能做什么”范例负责示范“应该做成什么样”两个配合才能把模型的行为框在一个高质量区间内。后来我给这个技能继续迭代增加了一个“每周一自动给前一周的报告做归档”的功能以及一个简单的关键词趋势统计让简报从“资讯汇总”慢慢变成了“情报产品”。这就是我想说的技能包的真正价值——它不是把一个任务变成自动化工具而是把一个人处理信息的经验沉淀成了可以运行、可以复制、不断进化的资产。5. 常见问题与排查技巧实录5.1 技能不生效模型就是不听指令怎么办这是使用率最高的问题我一开始也经常碰到“写了那么详细的 SKILL.md模型怎么好像根本看见它”我排查这个问题的顺序是固定的。先看技能包有没有被正确装载——很多平台的技能系统是默认关闭的需要你在配置里显式开启再看 SKILL.md 的开头描述写得清不清楚因为模型判断“该不该启用这个技能”主要靠的就是开头那几行描述——如果描述写得太笼统模型会把它忽略掉最后检查指令里是否包含了模型“做不到”的事比如让它精确读取某个外部数据库而不提供任何工具——那它就只好用猜的。如果是文本指令层面的问题我通常用两个技巧解决。技巧一在 SKILL.md 里加一个“当任务涉及 XX 场景时必须使用本技能”的强触发句式把触发条件写成 if-then 的硬规则而不是软性的“可以参考”。技巧二在用户消息里加上一句“请先查看技能说明再开始执行”直接把模型的注意力引向技能文档。别小看这招实测下来启用率确实会高很多。5.2 输出质量不稳定同一个技能这次好下次差输出质量波动是常态尤其当你换模型版本或供应商接口的时候。我排查质量问题先区分是“流程错了”还是“内容差了”如果流程执行乱了说明指令里步骤不够清晰需要拆细或者加检查点如果流程对但内容不行那就往 reference 里补充更高质量的示例。记住质量的天花板。环境变化也是一个重要变量。同样一个技能包在 A 模型上表现尚可在 B 模型上效果打折这是非常普遍的现象。因为不同模型的指令遵循能力、格式偏好都有差异。我现在的做法是给技能包做“兼容层”在 SKILL.md 里增加一小段“模型适配说明”根据不同模型调整措辞风格比如有些模型吃“必须”这种强命令有些模型吃“请确保”这种礼貌指令。把适配工作写进技能文档能让你换模型时少掉一半头发。5.3 脚本执行报错模型不会用你写的工具模型调用脚本出错十有八九不是脚本本身的问题而是“路径没写对”或“参数传错了”。我踩过最典型的坑脚本的相对路径是相对于技能包所在的目录但模型执行时的工作目录可能完全不是那个位置结果文件读写失败。解决方案是脚本内部先用自己的绝对路径做基准别依赖运行时的工作目录。另一个坑是模型喜欢自由发挥地改参数比如我规定fetch_updates.py的--days参数传 3它偏要传 7。解决办法是在脚本入口做严格的参数校验如果模型传了不在允许集合里的值就直接报错并输出帮助信息。用代码强行锁死边界别指望模型自觉。5.4 常见问题速查表现象可能原因快速排查与解决技能完全没被执行技能未开启 / 触发描述不清晰确认平台配置已开启强化 SKILL.md 开头的触发条件写清 if-then 硬规则技能执行了但输出太泛SKILL.md 里“怎么做到”不够具体增加执行步骤编号每步写明动作产出物补充输出模板同技能输出忽好忽坏参考示例不足 / 模型版本变化在 reference 里增加历史优秀案例写一段模型适配说明脚本报错找不到文件运行时工作目录不一致脚本内使用绝对路径或基于自身位置计算路径定时任务没按预期跑时区配置错误 / 日志没开首次部署先手动触发验证再挂定时检查时区设置并保留日志数据抓取不全目标网站结构变更把抓取逻辑做成插件式定期检查信息源是否正常工作配置来源数量时留冗余6. 从“用技能的人”到“造技能的人”——个人能力升级路径6.1 盘点你的高频任务找到技能化的优先选择讲完了技术上的技能包我想跟你聊聊作为个人我们到底该怎么在这个 AI 遍地走的时代保持竞争力。我的核心观点是把 AI 当成需要你管理的外包团队你作为“技能架构师”负责设计每个人Agent的职责和操作手册。那怎么入门从盘点你自己的高频工作开始。打开你的日历和任务清单找出过去一周重复出现三类以上的任务写周报、回复常规邮件、整理数据、做PPT、做会议纪要、调研背景资料……任何“你做得熟、可流程化、花时间”的事情都在技能化候选名单上。判断优先级有个标准频率高、耗时多、产出物标准化程度高——满足这三个条件就先从它开始。比如你每周要花两个小时做周报那你花半天把周报流程技能化两个月后你就把时间省回来了。具体落地上我建议你从最简单的“一人技能”开始不搞复杂的平台功能就用通用 AI 工具创建自定义指令或提示词模板把你的工作流程写进去。我在自己电脑上建了一个“我的技能库”文件夹每个技能就是一个 Markdown 文件遇到高频任务就在里面调用对应文件作为提示词。一个月下来我发现自己大部分的重复劳动都已经有了“标准作业程序”这不仅省时间更重要的是我脑子里的混乱感和焦虑感消失了——以前工作老觉得事情多但理不清现在已经把“做事”变成了“查说明书执行”。6.2 学会设计“人机协作的检查点”而不是追求全自动很多人一听到自动化、技能化第一反应就是“要全部跑通完全不用人管”。这个目标不光难实现而且也不该追求。AI 自动化真正厉害的地方在于“二八原则”它能替代你流程中 80% 的执行时间但那 20% 的判断节点必须由人来掌握。千万不要把这 20% 也拱手让出去因为那才是你的价值所在。怎么设计检查点我自己的经验是在流程里故意设置三到四道“人工审批闸门”。比如在重要决策场景只负责生成选项由你来拍板选哪个方向继续拆解在对外输出场景只负责写初稿检查和定稿必须由你亲自过手在数据敏感场景只负责整理不负责最终核验关键数字你一定要复核。这样做的好处有两方面一是保证输出质量避免 AI 的小失误直接砸了你的招牌二是你会对这套流程始终有掌控感和理解力不会被工具带偏。说白了技能化的终极目标不是解放你自己而是解放你的时间、提升你的杠杆、放大你的判断力。工具负责把“你已经懂的东西”跑得更快人则负责把“你还想搞清楚的东西”持续推进。未来最理想的工作状态不是一大堆 Agent 在你不在场的情况下把工作做完给你个结果而是你像一位图纸设计师加监理设计系统、指定标准、巡视关键节点、对最终产品负责。这个角色画像才是 AI 时代的“技能高手”。6.3 用个人技能库给职场叙事增加硬通货最后聊一个比较现实的问题技能化怎么变成你职场上的竞争力我观察身边混得比较好的同事和朋友他们都有个共通点——不只是“会做事”而是“能讲清楚自己怎么做事”。技能化天生就在帮你干这件事因为你把经验写成了结构化的流程和参数你的工作方法从“独特的直觉”变成了“可复用的资产”这在沟通、协作、面试的场景里都是巨大的加分项。比如你面试时说“我熟悉内容运营”人家只能得到一个模糊印象如果你说“我搭了一套内容选题技能库包含 5 个细分场景的 SOP、19 个参数化的选题判断标准用它让选题会议从 2 小时压缩到 40 分钟”这个说服力就完全不一样了。前者是“我会做事”后者是“我能把事做成系统”而后者才是高阶岗位真正需要的能力。我的建议很朴素花一个周末的时间把你自己最拿手的三项工作写成技能文档。不是为了给别人看纯粹是逼自己把工作方法看清楚。你在写的过程中大概率会发现原来自己还有这么多隐性的判断可以沉淀成标准——这个过程本身就是一次高质量的自我复盘。我在实操中最深的一个体会是技能化不是一个“做完了就结束”的工程它是一个持续进行时。今天你觉得完美的流程三个月后可能就被更好的工具或方法颠覆了。但只要你保持“把自己的工作显性化、工程化”的习惯你就永远能站在工具的肩膀上而不是被工具牵着走。如果你也正在尝试构建自己的技能包或技能库欢迎按着这篇文章里的路径先跑一版遇到具体问题慢慢调。毕竟技能这个东西光看文章是学不来的动手做一版、坏掉一次、修好一次——那才是真正属于你自己的技能。
