有段时间我特别烦一件事每周五都要把本周改过的代码、踩过的坑、下周计划整理成一份周报。后来我索性让 AI 来干结果发现每次都得重新交代一遍背景“我是做什么的”“这个项目是什么”“周报要几段”“语气要什么风格”。交代完它输出的东西还是经常跑偏。那段时间我一直在想问题出在哪后来我认真研究了一下才意识到根本症结在于我一直给 AI 的是“一次性提示”而不是“可复用的 skills”。所谓 skills简单说就是把一类任务的处理方法固化下来让它成为 AI 能随时调用的标准操作流程。这跟人很像——我们不会每次做饭都重新发明菜谱而是积累了“做番茄炒蛋”这个技能下次进厨房直接调用。本篇内容就是围绕 skills 这个概念展开的我会从它的价值说起拆解一个标准 skill 的内部结构再带你把“周报生成器”从零搭出来最后分享我调试技能时踩过的三个隐蔽坑以及怎么把零散技能组织成个人能力库。不管你是刚接触这个概念的新手还是已经被“每次重写提示词”折磨了一阵子的老玩家这篇内容都能直接拿去做落地参考。1. 我第一次正视“skills”不是提示词写不好而是没有把任务模块化1.1 从一次“失败”的会议纪要任务说起当时我负责一个小项目组每周有两次例会会上聊需求、聊排期、聊风险。我试过把录音丢给 AI 转文字然后把“转写文本”丢给 AI 让它写纪要。第一次的结果还算能用但第二次、第三次就开始离谱了有时候它把“讨论”和“决定”混在一起有时候自己加工出一堆会上根本没提过的结论有时候又把三个并列的事项合并成一个看起来像模像样实际已经失真了。我一开始以为是自己提示词写得不够好于是拼命加限定语“请务必只基于文本”“不要添加任何原文没有的信息”“请列出所有事项”……加到最后提示词本身就有三四百字反而把模型绕晕了。直到我接触“skills”这个思路才恍然大悟我缺的从来不是“更长的提示词”而是一套把输入、处理、输出都定死的可复用技能。1.2 一次性提示 vs 可复用技能的真正差异一次性提示词最大的问题在于“每次都得从头解释”。你这次告诉它你是项目经理下次它又忘了这次教它“风险要标 P0/P1/P2”下次它可能就按“高/中/低”来写。你每次都在跟它的“失忆”对抗。而 skills 的本质是把任务边界、输入要求、执行步骤、输出格式全部固化成一个独立模块。这就像你给团队写了一份标准作业指导书新员工拿过来照着做就能交出 60 分以上的结果再叠加反馈迭代能做到 90 分。我做了个简单对比把区别讲得更直白一点维度一次性提示词可复用 skills任务定义每次重新描述固定字段触发即用背景知识每次重复喂内置在技能描述里执行步骤靠模型临场发挥SOP 明确逐步执行输出格式每次都变模板固定微调即可改进方式改提示词后所有场景都受影响只改这个技能不影响其他任务这个对比是我踩了无数坑之后才总结出来的。你也可以理解为提示词是“临时工”每次上岗都要重新交代规则skill 是“老员工”按一下按钮就知道该干什么、干到什么标准。1.3 什么场景下skills 的收益最大我自己的体感是凡是“输入结构相对固定、输出格式要求明确、你希望每次结果都稳定”的任务都值得做成 skill。比如总结周报、整理会议纪要、做代码评审、翻译并润色文案、把长文拆成多平台发布稿这些任务天然就是 structure 化的最适合模块化。反过来那些开放式、发散性的任务比如“帮我策划一个营销活动创意”“头脑风暴十个选题”就不太适合做成 skill。因为这类任务的价值恰恰在于随机性和多样性你要是把它固化成模板反而会抹掉灵活性。这也是我后来给自己定的一个判断标准先问“这个任务的结果我希望它每次都一样还是希望它每次都不同”。想要稳定就奔着 skill 去想要发散那就别过度设计。2. 拆解一个可复用 skill 的内部骨架五个让你少掉头发的设计维度2.1 菜谱思维为什么技能要像一道菜的工序一样清晰聊到具体设计之前我想先用一个特别日常的东西打比方做菜。一道菜谱通常包含什么适合什么场景家常/宴客、需要哪些食材主料/辅料、按什么顺序处理先切后炒、先腌后炸、火候怎么控制大火快炒、小火慢炖、最后装盘是什么样。一个 skill 的结构几乎一模一样触发条件对应“适合什么场景”输入参数对应“需要哪些食材”执行流程对应“按什么顺序处理”参数与边界对应“火候怎么控制”输出模板对应“最后装盘是什么样”。我一开始设计 skill 时老想着“让 AI 自由发挥”结果就是自由过头。后来把菜谱思维套进去每个技能都按这五个维度来写质量立刻上了一个台阶。2.2 骨架一意图与触发条件这是 skill 的“门卫”决定的是什么时候该调用这个技能什么时候不该调用。很多新手做技能时根本不写触发条件结果 AI 把技能当成了万能助手用户聊到任何事情都想往里套。我自己的做法是写两类触发指令正向触发词和排除项。正向的比如“包含‘周报’‘本周工作’‘写周报’等关键词时调用”排除项比如“当用户要求的是月报、季度总结、年度复盘时不要调用周报技能”。为什么排除项这么重要因为模型很容易“从一个极端走到另一个极端”你教会它周报怎么写它就恨不得你把月度汇报也按周报格式来。有了排除项相当于给技能画了一条护城河明确告诉模型这不是你的活儿别管。2.3 骨架二输入参数与校验规则第二个维度是输入。一个技能要想稳定输出必须先定义清楚“我需要用户提供什么信息”。拿周报技能来说输入至少应该包括本周完成事项、本周遇到的问题、下周计划。这三个是我的必填项。但只是列出输入还远远不够还要写校验规则。比如如果用户只是说“帮我写周报”但没有给具体事项那 AI 应该怎么办我踩过坑后的标准做法是“当用户未提供本周完成事项时先主动询问不要编造。”这个规则看起来简单实际特别关键。因为 AI 在没人打断它的情况下很容易自动脑补出一条“本周优化了系统性能提升了用户体验”这种看似正确实则空泛的内容。一旦你把“缺了必填项就必须询问”写进技能输出质量会有质的改变。2.4 骨架三执行步骤SOP第三步是定义技能的内部执行流程。这是最容易被忽略、却影响最大的一块。很多人设计 skill 时只写了输入和输出中间过程完全交给模型自由发挥。这就好比你告诉厨师“来一道番茄炒蛋”但不说要不要放葱、番茄要不要去皮、蛋液要不要加盐结果每次端上来的菜味道都不一样。我的做法是把中间步骤拆成 3 到 5 步。以周报为例第一步将用户提供的所有事项按“完成/进行中/未开始”分类第二步对每项总结提取至少一个可量化的结果第三步把问题单列并为每个问题标注影响范围第四步写下周计划要求每条计划对应一个目标第五步按模板输出。每写一步我都会问自己这一步是不是必须的它是否在帮模型“少犯某个具体错误”如果找不到理由就删掉。步骤宁少但精太多反而会拖慢响应、增加翻车概率。2.5 骨架四输出模板与质量校验输出模板是最后一个能大幅提升稳定性的设计点。我的习惯是先把“理想中的最终结果”用示例写出来然后把示例内容替换成字段。打个比方你先请一位资深同事写一份示范周报然后让技能去模仿它的结构、语气和篇幅。这就是给模型一个“标准答案”它不是凭空发挥而是在框架内填空。写完输出模板之后还要加一个“自检清单”。比如所有“完成事项”是否都来自用户输入是否包含空泛的套话每条下周计划是否都有明确行动动词让 AI 在输出前自己检查一遍。这一步相当于质量门禁能拦截掉相当一部分低质量结果。3. 从零搭建自己的第一个 skill以“周报生成器”为例的完整实操3.1 先定场景为什么选周报而不是会议纪要如果你从来没做过 skill我强烈建议第一个从周报入手不要选会议纪要。原因是周报的输入边界更清晰用户只需要提供“这周干了什么、遇到什么问题、下周做什么”而会议纪要往往涉及讨论逻辑、参会人、决策链复杂度和歧义性都高得多。之前我带过一位新人一上来就想把“月度经营分析会纪要”做成 skill结果光是“决策事项的归属人”这个问题就反复折腾了一下午。后来换成周报一个小时内就跑通了整个流程甚至已经能稳定输出。这个对比其实说明了一个通用原则第一个 skill 的选择决定了你对这个概念的第一感受。选一个足够简单、频次足够高的任务才能让你在正反馈中快速入门。我的周报场景很简单每周五下午我需要对这一周的工作做一个复盘内容发给团队格式固定为“本周完成 / 风险与问题 / 下周计划”三段式。3.2 周报技能 v1.0 的完整定义我先给出我自己设计的周报 skill 定义你可以直接抄走再按自己团队的语境微调。这里我用的是通用描述格式不依赖任何特定平台目的在于展示结构name: summarize_weekly_report version: 1.0 description: 用于把零散的本周工作记录整理成一份结构清晰的周报。 输入为本周完成事项、遇到的问题、下周计划等原始记录 输出为三段式周报符合团队日常同步需求。 trigger: when: 用户提到“周报”“写周报”“本周总结”等关键词 exclude: 月报、季度总结、年度复盘、项目复盘 inputs: - name: completed_tasks required: true description: 本周实际完成的事项可以是列表或自然语言 - name: risks_or_problems required: false description: 本周遇到的问题、风险、阻碍 - name: next_week_plan required: true description: 下周计划期望输出为行动型条目 rules: - 不得编造不在输入中的完成事项 - 当 completed_tasks 缺失时必须先向用户询问不得直接猜测 - 量化优先完成事项中如有可量化的结果必须保留 - 问题与风险应说明影响范围避免泛泛而谈 - 下周计划必须以动词开头如“完成”“推进”“交付” steps: 1. 将输入按“完成 / 进行中 / 未开始”拆成三类统一为简短条目 2. 逐条检查“完成”事项补充量化结果或前后对比 3. 将风险问题单列按“描述 影响 当前状态”结构整理 4. 把下周计划逐条改写为“动词 对象 预期结果”格式 5. 按下方 output 模板输出替换占位符内容 output: 格式: 三个二级分段标题分别为“本周完成”“风险与问题”“下周计划” 模板: | ### 本周完成 {{ 完成事项列表 }} ### 风险与问题 {{ 问题列表每条含描述、影响、状态 }} ### 下周计划 {{ 行动型计划列表 }} quality_check: - 所有完成事项是否能在输入中找到依据 - 是否出现“持续优化”“不断提升”等无信息量套话 - 下周计划是否每条都能作为下周的验收标准这个文件看起来有点长但你仔细看会发现每一个字段都在做同一件事压缩不确定性。3.3 测试方法三个输入场景一次跑完定义写完后不要急着投入真实使用先做一轮人工测试。我习惯准备三个测试输入第一个是“正常输入”尽可能完整地提供三项内容验证标准流程是否顺畅第二个是“缺字段输入”只丢一句话“帮我写周报”后面什么都不给验证它会不会主动询问而不是编造第三个是“干扰输入”在正常输入里故意混入“隔壁组下周要发布新版本”这类无关信息验证技能会不会把它误解为“完成事项”。我实际测试时v1.0 版本就栽在了第三个场景上。模型把“隔壁组发布新版本”当成了本周完成事项写了进去因为我的 rules 只写了“不得编造”没写“过滤无关主体信息”。这个 bug 直接影响输出准确性我后来在 rules 里加了一条“仅保留第一人称视角内、明确与本组相关的事项”问题才解决。3.4 一次真实迭代记录从“能跑”到“好用”跟着这个案例做下来的朋友大概率会经历我走过的这个阶段v1.0 能输出但总感觉“差点意思”。我当时看到的问题是完成事项压缩太狠原本输入里生动的工作记录被压成了干巴巴的十个字丢掉了原始语气里的上下文。于是我在第二步 rules 里加了一条“保留关键上下文与前置背景”rules: - 每条完成事项需保留背景触发词如“因线上告警”“应运营需求”让读者知道为什么做了这件事这一改效果立竿见影。同样是“修复导航栏适配问题”v1.0 输出的是“修复导航栏适配”v1.1 输出的是“因线上用户反馈导航栏在移动端错位完成修复覆盖三类机型”。后者的信息量不是一个量级的。这条迭代经验后来被我推广到了所有技能里压缩不等于删掉背景真正有价值的周报是把“为什么做”和“做了什么”放在一起。4. 调试技能时最容易翻车的三个隐蔽问题现象、定位链路、修复方案4.1 过度响应技能被当成万能助手什么请求都往上套现象很容易辨认你本来做了一个“周报生成器”结果用户说“帮我把这篇文章润色一下”它居然也先用周报格式输出了一遍。你问它为什么它的解释是“我识别到这是一项需要整理的文本任务于是调用了文本整理技能”。我当时定位这个问题的链路是这样的先回顾触发条件发现我写的正向词里有“整理”“总结”这类高频词而周报技能的 description 里也包含“总结”二字导致模型把一切都和“总结”建立了关联。修复方案是三层第一在 trigger 里把高频通用词删掉只保留“周报”“本周”“本周工作”并增加排除项“任何非周报场景的文本处理不得调用本技能”第二在 description 开头加一句“本技能仅用于周报场景不适用于其他文本整理任务”第三在 rules 里补充“当用户请求明显与周报无关时直接礼貌地搬出本技能的适用范围并停止调用”。从这里开始我才真正明白技能的触发词不是越多越好词义越大气越容易被误召。范围小一点才不容易被滥用。4.2 参数幻觉用户没给的信息AI 默默脑补了有一次我测试“周报生成器”只给了一句话“本周处理了客户投诉。”结果输出里写“处理了 12 起客户投诉”还煞有介事地写了“其中 8 起已闭环”。我当场愣住了因为输入里根本没有“12”这个数字。排查过程很有意思模型的训练语料里“处理客户投诉”往往伴随一组数据所以它在做文本续写时下意识把统计数字补了进来。这不是它故意骗我而是生成机制里“流畅性优先”带来的副作用。我从这个经历里总结出一个教训凡是输入中没有量化数字的任务输出里但凡出现数字都要打上高亮怀疑标记。对应的修复手段也很明确在 skill 里定义一个“未知数据标记符”规则写清楚“未提供的量化信息一律标记为 N/A不得自行生成”并在输出模板的示例里展示这种 N/A 的写法。模板示例本身就是最好的约束模型会照着示例的样子写出 N/A而不是编一个数字出来。4.3 上下文污染多个技能互相串味输出风格“一家亲”这个坑是我做了一堆技能之后才踩到的。那时我已经有了周报、会议纪要、日报三个技能有一天突然发现周报输出里出现了会议纪要的措辞“经讨论决定如下……”我一开始以为是模型状态问题重启之后还在。后来单独跑周报技能完全正常单独跑会议纪要技能也完全正常但只要连续跑两个以上技能后面的输出就会带上前面的风格。定位到根因之后我才反应过来模型在会话里会保留上文风格偏好如果前面刚跑完会议纪要“措辞正式、带决策语气”的惯性会被带到下一个任务里。尤其是同一个会话里连续调用多个 skill 时上下文污染几乎是必然的。我的修复方案是给每个技能加一个“结束标记”输出完正文后自动追加一行“本次技能执行结束以上输出遵循周报格式规范”。这个看似画蛇添足的标记实际上是在帮模型主动切换回“普通状态”。实测里效果很明显串味问题从大概率出现变成了偶发小概率事件。然后我又做了一个更彻底的策略不同场景的 skill 不要放在同一个会话里连续跑。宁可新开对话也不要偷懒在一个窗口里串联多个任务。因为即使加了结束标记 AI 仍然有记忆惯性新开对话的成本远低于清理上下文污染的代价。5. 把零散 skills 组织成个人能力库我的分层策略与维护心得5.1 技能树从“会用”到“有自己的体系”当你手里攒了七八个技能之后下一个问题就是管理。最开始我就是把一堆 skill 文件堆在同一个目录里结果用的时候想不起来自己都有哪些技能更别提哪个版本能用。后来我参考了“技能树”的思路把所有技能按用途分成了三层。最底层是基础型技能负责通用文本处理比如统一摘要、结构化列表、去口语化中间层是场景型技能面向具体场景比如周报生成、会议纪要、代码评审最顶层是决策辅助型技能比如“问题优先级排序”“风险分析框架”这类技能通常本身不直接产出文案而是帮我把信息拆解出关键判断。这个分层给我的最大感受是当我要处理新任务时先判断它是哪一层然后决定是找一个现成技能还是组合两层技能。大多数时候都不用从零写新技能而是把基础型和场景型拼在一起用省了大量重复设计的时间。5.2 命名与版本请像管理代码一样管理你的技能任何东西只要进入迭代就要做版本管理。我给技能定下的命名规范是“动词 对象 用途后缀”比如summarize_weekly_report、generate_meeting_minutes、review_pull_request。这样做的原因很直白过了一个月你再回来看目录一眼就能明白这是干什么的而不用点开文件读一遍 description。版本方面我坚持在 skill 文件里放一个version字段每一次改动都升级一个小版本并在文末注释里记一句“为什么改”。比如# v1.2 修复参数幻觉新增 N/A 标记规则。这个方法你听起来可能觉得多余但等你改完一个技能、三个月后再回头排查问题时就会明白这条注释的价值它能帮你保住大量重新理解代码的时间。我曾有过一次惨痛经历周报技能改了三版没有做任何记录结果团队里有人反馈“新版摘要太口语化了”我却完全想不起是哪个版本、哪条规则造成了这个问题。后来老老实实补上了版本备注才在五分钟内定位到了改动源头。5.3 做减法的时机警惕“技能囤积症”这里我要泼一盆冷水技能不是越多越好。我一度陷入收集癖每周都给自己写一个新 skill但实际高频使用的其实就那么五六个。大量“一次性任务”被我硬做成了 skill浪费了不少时间而且给目录增加了噪音。后来我定了个简单粗暴的规则一个 task 如果连续两周都没有被复用就把它归档不删但也不留在活跃目录里。这听起来很反直觉本来辛苦做出来的东西怎么说不活跃就不活跃了。但归档其实意味着一种取舍把真正的力气集中在一小批反复使用的技能上不断打磨它们的边界和示例让它们“一提就准”。我这段时间最大的体会是一个好的技能库不是大而全而是少而精。与其每多一个任务就新造一个 skill不如把通用的、频繁的场景打磨成真正能扛事的模块。你会发现真正经常用的那个技能每次迭代都给你省下最多的时间。