最近我把一个“日报汇总”的 Skill 拆开来看突然发现它并没有我想象中那么神秘。就是一个名字、一段描述、几个输入参数、一条主提示词、一个输出模板外加一堆边界处理合在一起就成了大家口中“很专业”的 Skill。这篇文章就用这个日报 Skill 当案例带你把它从里到外拆一遍顺便把“如何设计一个自己的 Skill”的方法也交代清楚。适合正在折腾 AI 工作流、提示词工程、智能体应用的开发者也适合那些一直用 AI 工具整理工作内容、但不知道背后机制的朋友。1. 先搞清楚Skill 和普通 Prompt 到底差在哪1.1 一个“日报”场景两种做法先说一个很常见的场景每天下班前你要把当天干的事情整理成一份日报。传统做法是打开某个 AI 助手手打一段 Prompt“帮我把今天的工作总结成日报包含今日完成、明日计划、风险问题”然后把白天记的流水账粘贴进去。这个流程能用但每次都要重新写 Prompt、重新调格式、重新提醒 AI“别编造内容”非常累。Skill 的做法完全不一样。你定义一个叫daily_report_builder的技能提前把 Prompt、输入参数、输出格式、兜底策略全部写好。以后只需要说一句“写日报”再把零散记录丢过去AI 就会自动走完一套流程。用户看到的是“一句话触发、结果稳定输出”背后其实是一个结构化的定义文件在起作用。这两种做法的差距本质上是“临时手写”和“固化工具”的差距。手写 Prompt 像每次做饭都凭感觉放盐而 Skill 像一份标准化菜谱原料、用量、火候全写好了谁来做都不会跑偏太远。这也是为什么现在主流 AI 助手和智能体平台都在推“技能”这个概念因为它把不可控的对话变成了可控的任务执行。1.2 Skill 的典型构成五个核心模块把那个日报 Skill 拆开之后我发现一个 Skill 通常由五个模块构成元信息包含名字、描述、版本、作者。这部分决定了这个技能“叫什么、干什么用、什么时候该被唤醒”。输入参数定义声明这个技能需要哪些输入比如原始工作记录、报告风格、是否需要量化指标。每个参数要标清类型、是否必填、默认值。处理逻辑核心是主提示词模板可能还有其他步骤定义比如先清理输入、再分类、最后生成正文。输出格式定义生成结果的结构可以是纯文本、Markdown 模板也可以是 JSON 数据结构。纠错与兜底策略处理各种异常情况比如输入为空、内容格式混乱、用户把无关文章粘贴了进来。我在拆解时最大的感受是Skill 不是“一个提示词”而是一个“提示词 规则 异常处理”的打包集合。如果只写一段提示词而不定义输入输出和边界那它充其量是个不错的 Prompt还称不上 Skill。1.3 为什么需要 Skill可复用、可共享、可维护有人可能会问我用一段精心打磨的 Prompt 不就行了吗为什么非要包装成 Skill我自己的体会是Skill 带来四个实实在在的好处。第一是可复用。同一个日报 Skill我今天能用明天能用换到另一个项目、另一个对话窗口也能用不用每次复制粘贴。第二是可共享。我把这个 Skill 文件发给同事他拿过去直接就能用哪怕他完全不懂提示词怎么调。第三是可维护。如果老板突然要求日报里多一栏“本周累计进度”我只需要改 Skill 定义里的模板部分所有调用它的场景都会同步生效。第四是可评估。因为 Skill 的输入输出都是定了的我可以拿固定的一批测试用例反复跑看改完之后效果是变好还是变差。一句话总结Prompt 是一段话Skill 是一个工具。工具的价值不在于它有多聪明而在于它稳定、可复制、可改进。2. 拆解一个“日报汇总 Skill”从输入到输出2.1 当我们说“日报”时我们要的是什么先别急着写代码得想清楚日报这个场景的本质是什么。很多人写日报是在记流水账早上开了会、下午改了个 bug、晚上加班。这种日报对读者来说毫无价值因为读者真正想知道的只有三件事今天有什么进展、遇到了什么阻碍、明天打算怎么干。所以一个合格的日报 Skill目标不是“把用户的记录变成通顺的句子”而是“把用户的记录变成结论先行的结构化汇报”。它必须能识别出哪条信息属于“今日完成”、哪条属于“风险求助”、哪些信息可以合理地推导为“明日计划”。这个目标看似简单但直接决定了主提示词怎么写、输出模板怎么设计。我当时拆解这个日报 Skill 时发现它的所有设计都是围绕这个目标展开的。比如“今日完成”部分要求每条写成“做了什么 结果或进展”就是为了避免只写“改了 bug”却不说改到什么程度。又比如“明日计划”部分要求只能基于今日记录推导不能凭空捏造这也是为了守住日报的底线。2.2 一个 Skill 的完整清单下面就是我当时拆解出来的一份日报 Skill 定义格式上做了简化但结构是完整的。不同平台的定义方式可能叫 YAML、JSON 或者专用 Schema思路是一致的。name: daily_report_builder description: 将零散的工作记录整理成结构化日报包含今日完成、明日计划、风险与求助。当用户提到写日报、总结工作、daily report 时使用。 version: 1.1.0 inputs: - name: daily_notes type: string required: true description: 用户输入的原始工作记录支持换行、无序列表、口语化表达 - name: style type: string required: false default: standard description: 输出风格可选 standard / simple / detail - name: include_risk type: boolean required: false default: true description: 是否单独列出风险与求助板块 prompt_template: | 你是企业办公场景下的日报撰写助手。 你的任务是把用户提供的零散工作记录整理成一份结构化日报。 日报必须包含三个部分 ## 今日完成 ## 明日计划 ## 风险与求助 规则 1. 今日完成中的每一条写清楚“做了什么 结果或进展”。 2. 明日计划只能从今日记录中合理推导不能凭空编造。 3. 没有提到的任务不要补全。 4. 每条描述控制在 50 字以内语气客观不夸大功劳。 用户原始记录 {{daily_notes}} output_template: | ## 今日完成 {{今日完成列表}} ## 明日计划 {{明日计划列表}} ## 风险与求助 {{风险与求助列表}} fallback_rules: - if: daily_notes 为空或字数小于 10 then: 回复“请先提供今天的工作记录最少一两句话都行” - if: daily_notes 明显不是工作记录例如整段文章 then: 回复“这段内容看起来不像是今天的工作记录请重新描述”这份清单就是那个日报 Skill 的核心。你把它保存成文件挂载到支持 Skill 的 AI 平台里它就可以被调用。2.3 核心字段背后的设计意图有几个字段我觉得特别值得展开讲因为它们容易被忽略但决定了 Skill 好不好用。第一个是description。这个字段看起来只是介绍实则是 Skill 被“唤起”的关键。AI 会拿用户的输入和各个 Skill 的 description 做匹配匹配上了才触发这个 Skill。如果 description 写得太窄只写“日报”用户说“把今天的工作汇总一下”就触发不了写得太宽什么场景都触发又会误伤。我见过很多效果差的 Skill问题就出在 description 没写好。第二个是inputs里的required和校验规则。日报场景里daily_notes是必填的但用户可能只丢一句“今天很忙”过来。如果不做校验模型就会硬生生生成一份全是废话的日报。加了 fallback_rules 之后它会让模型先追问而不是硬编。第三个是output_template。日报的输出如果只是给人类看纯文本 Markdown 就行如果还要被其他系统读取那最好直接输出 JSON。这个设计要提前定清楚不然后面接数据流的会很痛。第四个是版本号。别小看versionSkill 是要迭代的。改一次 Prompt、调一次模板都算新版本。没有版本号你根本不知道线上跑的是哪一版出了问题也不好回溯。2.4 执行流程从“随便几句话”到“正式日报”光看定义可能还是有点抽象我走一遍执行流程就清楚多了。假设用户输入的是“今天早上开了个产品评审会下午改了首页登录的 bug花了好久总算修好了。然后写了一下接口文档帮新同学配了开发环境。快下班的时候发现分页还有个小 bug 没解决。”Skill 执行的第一件事是判断意图。如果某平台支持自动触发它会先看这段输入和daily_report_builder的描述匹不匹配匹配成功就走进这个 Skill。接下来进入分类和整理环节这一步主要由主提示词驱动模型把“开评审会”归到“今日完成-会议沟通”“改登录 bug”归到“今日完成-功能修复”“写接口文档”归到“今日完成-文档建设”“帮新同学配环境”归到“今日完成-团队协助”“分页 bug 未解决”归到“风险与求助”。然后模型按照输出模板生成日报## 今日完成 - 完成首页登录 bug 修复问题已解决并通过自测 - 撰写接口文档覆盖核心接口定义与调用示例 - 协助新同学完成开发环境配置已可正常启动项目 - 参加产品评审会确认了下一阶段首页改版方向 ## 明日计划 - 继续修复分页 bug排查数据加载异常原因 - 补充接口文档中异常场景说明 - 跟进评审会遗留问题确认技术方案 ## 风险与求助 - 分页模块存在一处未解决 bug预计影响列表查询稳定性需要进一步排查可以看到模型没有把“下午改 bug 花了好久”这种冗长表达直接抄进日报而是整理成“完成首页登录 bug 修复问题已解决并通过自测”。它还从“快下班时发现分页 bug 没解决”合理推导出“明日计划-继续修复分页 bug”。这一步就是 Skill 相对于普通 Prompt 的溢价所在它不是简单重写而是有结构地重构。这里我也想强调一句Skill 本身并没有魔法。它底层还是一个语言模型Skill 提供的只是架子和约束。模型生成“明日计划”的能力来自它对场景的理解和训练Skill 负责把这种理解引导到正确的输出形状上。3. 自己动手设计一个 Skill从需求到落地3.1 第一步明确场景边界别贪心我第一次设计 Skill 的时候犯过一个错误就是想把所有办公场景全塞进一个 Skill 里。结果发现要同时处理日报、周报、会议纪要、项目复盘功能越多Prompt 越混乱最终哪个都做不好。正确的做法是先画一条清晰的边界。一个 Skill 只解决一个连贯的小任务。比如我们要做的这个定位就是一句话“把用户的零散工作记录整理成结构化日报”。会议纪要是另一个任务周报可以是日报的长周期聚合但那应该是另一个 Skill 或者基于日报数据做的扩展功能不应该硬塞进来。边界定了之后还要想清楚谁在用这个 Skill、在什么场景下用。它可能是给自己用的私人技能那要求就是“省事、结果够用就行”也可能是给整个团队用的那就得考虑不同人的输入习惯输出格式要更严格。场景不同设计取舍完全不同。3.2 第二步定义输入参数和校验规则边界明确之后下一步是列输入参数。我建议参数数量控制在 3 个以内最好 2 个因为参数越多用户填起来越烦模型也更容易在调用时传错。日报 Skill 的第一版我只定义了三个参数daily_notes必填用户粘贴的原始记录string 类型。style可选默认standard支持simple和detail两种变体。include_risk可选默认true决定要不要单独列出风险板块。参数定好了还得加一条校验规则就是daily_notes字数少于 10 的时候不要让模型硬编而是让 Skill 主动追问。这一步看着小实际影响很大。没有它用户输入“今天做了很多事”的时候模型会生成一堆诸如“今天处理了多项事务”的正确废话。有了它模型会说“请提供一下具体的工作项哪怕列几个关键词都行”。这两种体验差别非常明显。3.3 第三步写主提示词模板主提示词是 Skill 的灵魂。很多人的提示词只有一句话“帮我整理日报”这远远不够。一份合格的 Skill 主提示词应该包含角色定位、任务目标、处理规则、输出约束、输入占位符。我当时用的模板基本长这样你是企业办公场景下的日报撰写助手。你的任务是把用户提供的零散工作记录整理成一份结构化日报。 日报必须包含三个部分 ## 今日完成 ## 明日计划 ## 风险与求助 规则 1. 今日完成中的每一条写清楚“做了什么 结果或进展”不要直接复制原文。 2. 明日计划只能从今日记录中合理推导不能凭空编造。 3. 没有提到的任务不要补全不确定的信息用“待确认”标注。 4. 每条描述控制在 50 字以内语气客观不夸大不写“领导发言稿”。 用户原始记录 {{daily_notes}}我自己特别在意第 3 条规则。模型有个毛病它倾向于把事情说得圆满你只做了两件事它能给你编出五件事。在日报场景里这种“脑补”非常危险一旦老板信了你可能就得真的去干那件事。所以我在模板里专门放了一句“没有提到的任务不要补全”。这个模板还隐含了一个设计点它要求把“结果或进展”写出来。原因是很多人的原始记录里只写了“做了什么”没写“做成什么样”。模型要做的不仅是整理还要提取出结果信息。如果原始记录里确实没有结果模型就把它标成“进行中”而不会强行说“已完成”。3.4 第四步设计输出格式与兜底逻辑输出格式可以有两种选择。第一种是直接输出 Markdown 文本适合“人看一眼就完事”的场景。第二种是输出结构化 JSON适合日报还要被其他系统消费的场景。如果后续想把日报发到群机器人、同步到项目管理工具JSON 更好用因为下游系统可以直接解析字段。我建议在第一版里先用 Markdown因为用户感知最直观等确认稳定了再改成 JSON 输出或者加一个output_format参数让用户选。兜底逻辑则是另一个容易忽略但必须有的部分。至少要有三条兜底规则输入为空或者太短要求用户补充。输入明显不是工作记录提醒用户重新输入不要硬转。输入包含敏感或无关键内容忽略并在日报末尾注明“有部分内容不适合写入日报已忽略”。兜底逻辑不是让模型生成更多内容而是让它学会“不知道就说不知道、不合适就不做”。这一步决定了 Skill 在真实环境里的稳定性因为真实用户绝不会规规矩矩地按你设计的格式输入。3.5 第五步小规模测试与迭代Skill 写完之后不要直接上线先小规模测。我当时准备了三类测试用例。第一类是正常输入例如上面那段“开评审会、改 bug、写文档、帮新同学配环境”的记录用来确认主流程能跑通。第二类是边界输入比如只写“今天很忙”这种极短输入或者贴一整段文章进来。第三类是风格变体比如用户用英文夹杂中文、整段没有换行、用口头语表达。每类准备 5 条左右一共 15 条跑一遍把每条输出都看一遍找出规律性的问题。测试结果出来之后大概率会发现两个问题一是某些分类放错了比如把“开会”放到了明日计划里二是语气偶尔偏夸张。这些问题不用急着改输出模板而是要在主提示词里加规则约束。测试-修改-再测试循环两三轮之后Skill 的稳定性会明显提升。4. 进阶让 Skill 真正好用而不只是“能跑”4.1 数据来源与工具调用的接法如果日报 Skill 只能处理用户手动粘贴的内容它已经可以用了但离“真正好用”还差一步。更好用的日报 Skill 应该能自动拉数据比如当天提交的代码记录、在项目系统里处理的任务、参加的会议日程。要实现这一点Skill 里需要加“工具调用”的定义。以代码提交记录为例可以定义一个叫list_git_commits的工具参数是时间范围返回值是提交列表。Skill 在执行时先调用这个工具拿到数据再把数据和用户手动输入的东西一起塞进主提示词。这样日报就比别人手写多了“事实依据”。这里有一个坑我踩过工具返回的数据可能非常长比如一天几十次提交每条都带 commit message、文件变更、作者信息塞给模型会占用大量上下文还容易干扰重点。所以工具层要做一次提炼只提取“项目名、改动内容、关键结果”这些信息其他一律过滤掉。工具调用失败也要处理不要直接把错误信息抛给用户而是降级为“继续使用用户手动输入的内容生成日报但在末尾标注数据拉取失败”。4.2 多轮对话状态日报 Skill 的“记忆”你可能会说日报内容那么多用户一次说不完怎么办有经验的 Skill 设计会利用“多轮对话状态”来解决这个问题。我见过一个做得不错的处理方式思路是这样的Skill 内部维护一个collected_notes变量。用户第一次说“早上开了评审会”Skill 把它存进变量用户第二次说“下午修了两个 bug”Skill 再把这条追加进去。等到用户说“生成日报”的时候Skill 才把累积的所有内容一次性整理成日报。示例对话是这样用户写日报。Skill好的请逐条告诉我今天做了什么或者直接把工作记录粘贴给我。用户早上开了产品评审会。Skill已记录。还有其他内容吗用户下午改了登录页 bug修好了。Skill已记录。需要现在生成日报吗用户生成吧。Skill 输出完整日报。这个设计的价值在于它尊重了人类的真实输入习惯。不是每个人都像写汇报材料一样一次性把所有信息排好很多人习惯想到一条说一条。多轮状态让 Skill 能够“边聊边记”体验非常自然。实现上多轮状态可以放在平台提供的 Skill 会话变量里也可以靠上层应用维护。关键是在主提示词里把“已收集的信息”作为一个上下文变量传入并明确告诉模型“以下内容是你之前收集的如果新内容与旧内容重复不要重复写入。”4.3 异常输入处理空日报、超长日报、多人日报再聊几种我在真实使用中遇到的异常情况以及应对思路。第一种是用户确实没干活或者不想写日报。这不算 bug但 Skill 不能硬生成。我处理的策略是识别用户输入中是否有“今天没干什么”这类表述如果有就输出一个极简日报模板今天完成写“无重大进展主要在排查问题/日常维护”让用户自己去改。千万不能让模型编造具体事项。第二种是输入超长。用户可能把一周的工作记录全贴进来了Skill 生成的日报就会特别长。解决方案是在主提示词里加一条规则“如果内容超过 8 条合并同类型任务保留最重要的 5 条并在日报末尾加一栏‘其他事项’用于放置剩余条目。”第三种是多人日报。如果用户不是给自己写日报而是帮团队写周报输入里可能混着“我做了什么”和“某某做了什么”。这种场景需要在参数里增加一个role字段并在主提示词中明确标识“请区分‘我’与‘团队’的实体不要把别人的事项写成自己的成就。”这一步看似细节但一旦搞混后果相当尴尬。5. 常见问题速查与踩坑记录5.1 我的 Skill 为什么“看起来没问题但效果差”我接触过不少自己设计 Skill 的人他们最常问的问题是定义都写好了结构也没错为什么跑起来效果就是不理想我总结了一下原因集中在四个地方。一是description写得太抽象。比如写“用于日报生成”这不够模型无法准确判断触发边界。二是主提示词太单薄。只有一句“帮我生成日报”没有规则、没有格式约束、没有结果要求模型自然自由发挥。三是没有兜底。遇到用户输入不规范时Skill 直接硬转生成一些看起来很通顺但没依据的内容。四是输出格式和用户预期不一致。模板里设计的是 JSON用户却期待看到漂亮的 Markdown体验立刻差了一个量级。我整理了一个排查顺序建议按这个顺序来找问题排查点常见问题检查方式description描述过窄或过宽触发不准用 5 种不同说法测试是否触发输入参数必填参数没设好用户不知道填什么看对话中被问到的次数主提示词规则太少或太模糊跑一遍边界输入观察输出输出模板格式和用户预期不一致让用户亲自看一次输出兜底逻辑异常输入无响应或硬编故意用非工作内容输入测试5.2 三个我实际踩过的坑这里分享三个比较典型的踩坑经历。第一个是轻视触发词。我最开始做日报 Skill 时description里只写了“日报”两个字。结果用户说“整理一下今天干了啥”Skill 完全没反应。后来我把描述改成“将零散工作记录整理成结构化日报包含今日完成、明日计划、风险与求助。当用户提到写日报、总结今天工作、整理 daily report 时使用”触发率才明显提升。第二个是输入校验太弱。有一次我拿一个“明显是一篇公众号文章”的内容测试模型竟然把文章里的内容当成工作记录生成了一份看起来合理但完全虚构的日报。这给我提了个醒不是所有文本都适合作为日报输入。后来我在兜底规则里特别加了一条如果输入内容中出现了和“工作记录”特征不符的内容优先反问用户确认而不是直接转。第三个是输出过度正式。我一开始对模型的要求是“使用正式书面语”结果生成出来的日报变成了领导发言稿“本人积极推动首页改版工作有效提升了用户体验。”这种日报放到团队群里自己都想抠个洞钻进去。后来我把规则改成“语气客观、不夸大、每条不超过 50 字”输出才回归正常人话。5.3 什么时候不该用 SkillSkill 不是银弹有些场景我反而不建议用 Skill。第一种是场景太简单。比如“把一句谢谢翻译成英文”“帮我想一个标题”这种一次性、轻量、不需要结构化的请求直接用 Prompt 更快没必要做成 Skill。第二种是需求变动极频繁且没有稳定规则。如果你老板每天对日报格式的要求都不一样今天要求三栏明天要求五栏后天又要加一个表格你维护 Skill 的成本远高于每次手写 Prompt。这种时候稳定的格式才是 Skill 的前提没有格式就谈不上固化。第三种是没有稳定的输入来源。如果一个 Skill 每次都需要用户手动整理超大量的基础数据那它创造的价值就很有限。真正有价值的 Skill 必须解决“数据从哪里来”的问题要么接工具、要么接数据库、要么至少让用户输入过程变得足够简单。还有一个判断标准可以分享如果一个任务你只用一次就再也不做别做 Skill如果一个任务你每周要做两次以上且每次处理方式相似那就值得做一个 Skill。这就是它区别于普通 Prompt 的核心价值。最后再分享一点我个人的经验。Skill 设计的真正难点不在于写出一段精妙的提示词而在于把“输入怎么来、过程怎么走、输出长什么样、出错了怎么办”这四件事想清楚。我第一次拆开日报 Skill 的时候也有一种“原来如此”的感觉它本质上就是把我们日常做事的方法论翻译成一套机器能稳定执行的规格。你现在就可以从手头最简单的一个重复性任务开始试着把它定义成一个 Skill等跑通一次之后再回来看这个日报 Skill你会发现它一点都不神秘。