1. 一个skill到底长什么样
很多人以为skill是某种神秘的高阶玩法，得会编程才能碰。其实拆开看，一个skill就是“把一段固定的做事流程，打包成一个可复用的模板”。日报skill听起来很小，却是最好的解剖样本——因为它流程固定、输入简单、输出格式明确，几乎覆盖了设计任何skill都要面对的核心问题。
我拿一个日常一直在用的日报skill举例。它的任务很简单：用户把当天做的事、遇到的问题、明天的计划用大白话丢过来，skill负责整理成一份结构清晰、带结果导向、可向上汇报的日报。以前我每天手动写日报要磨十分钟，现在直接把零散笔记丢给skill，一分钟内拿到成稿，自己核对一遍就提交。这个过程看起来像“套模板”，但实际用下来你会发现，模板只是外壳，真正的功力全在skill内部的设计逻辑上。
1.1 先看日报skill的“外观”
一个skill在外观上通常由几个模块组成：名称、描述、触发规则、运行逻辑、输出模板、示例数据。日报skill的标配长这样：
- 名称：日报生成器
- 描述：根据用户提供的当日工作记录，生成一份结构完整、重点突出、符合汇报场景的日报
- 触发规则：当用户输入中包含工作内容、今日记录、日报等字眼，或直接投喂流水账时启用
- 运行逻辑：先清洗输入，再归类事项，再补充结果导向的描述，最后套用日报模板
- 输出模板：包含日期、今日完成、关键数据、问题与风险、明日计划、需协助事项
- 示例数据：提供3到5组输入输出配对，让模型照着理解
这个结构不是拍脑袋定的。名称和描述解决“什么时候该启用skill”；运行逻辑解决“怎么处理”；输出模板解决“长什么样”；示例数据解决“风格基准”。四者配合，skill才不会变成一个只会复读模板的文字机器。很多新手拿到一个现成的skill，看到一大段描述就以为全部内容是提示词堆出来的，这其实是误读。skill最高的价值，在于它把“隐性的做事方法”变成了“显性的执行流程”，让AI在每次使用时都稳定走同一套标准动作。
1.2 skill的底层三件套
我习惯把skill的内在拆成三件套：配置头、功能体、样例库。
配置头是给系统看的，作用是告诉大模型：你是谁、你擅长什么、在什么条件下激活。日报skill的配置头会写清楚“你是高效能助理，专注日报生成”。功能体是给流程看的，包含步骤清单，比如先判断输入是否有数据支撑、是否需要追问。样例库是给风格看的，让模型从示例中学会“结果导向”“简洁有力”的表达方式，而不是靠提示词反复说“请你写得专业一点”。
这三件套的复杂度完全取决于任务本身。日报skill可以很简单：一段标准提示词加一个模板就够了。但如果你想让它自动识别“某项目在推进过程中有延期风险”，并把风险写进今日问题模块，就得在功能体里增加判断分支。所以skill不是越大越好，而是刚好覆盖任务边界最好。换句话说，skill的本质是“把一次性的聪明，沉淀成可重复的标准动作”，它的价值不在于复杂，而在于稳定。
注意：配置头里不要写太多形容词。写“你是顶级专家”“你必须完美”这类话，模型并不会因此变强，反而会稀释真正有用的指令。把篇幅留给行为和边界，收益更高。我见过有人配置头写了一千字，全在夸角色厉害，结果实际跑下来输出毫无约束力，原因就是有效指令密度太低。
2. 日报skill的核心设计与为什么这样设计
日报这个场景看着简单，真要设计好，有两个绕不开的坎：输入极度不可控，输出又极度需要规范。用户可能发来一句话，也可能丢来一段六百字的流水账；日报读者可能是直属领导，也可能是跨部门协作方。设计skill时，所有关键决策几乎都是围绕这两个坎展开的。
2.1 输入端：先接住乱七八糟的输入
我把日报skill的输入处理分成三步：收集、清洗、分类。
收集阶段不过度解释用户原话，因为用户给的材料越原始越好，加工交给skill。清洗阶段要删掉口头语、无关吐槽、重复信息，比如“上午开会”“下午也开会”“会议真多”压缩成“全天参与项目对齐会议”。分类阶段把事项归到已有分类下，例如项目推进、会议沟通、文档产出、数据复盘。
这三个步骤必须在功能体里写清楚，而不是让模型自由发挥。我见过很多日报skill翻车，不是因为模板不好，而是输入处理过于随意。用户明明说了自己解决了某个bug，模型却把这条信息扔进了明日计划。原因就是功能体没有强制先做归类，模型凭着感觉乱放。你可以把输入处理理解成厨房里的备菜环节——菜不洗好切好，后面炒菜再厉害也会手忙脚乱。skill的输入处理越细致，最终输出才越干净。
2.2 输出端：模板是底线不是天花板
输出模板决定日报的骨架。我的通用模板分六块：日期、今日完成、关键数据、问题与风险、明日计划、需协助事项。每一块都有明确的填写规则。
比如今日完成要求按“动词+对象+结果”的结构写，禁止只写“处理了订单”这种没有结果的表达。关键数据必须来自用户输入，如果用户没提供数据，就写“暂无数据记录”，绝不能现编。
模板再往下，是表达级的规则：每条事项不超过两行；优先写结果再写过程；风险要和影响绑定，只写“有延期风险”不够，要写“可能导致联调延后两天”。这些细规则看着繁琐，却是日报能不能被直接拿去汇报的关键。skill生成的日报如果还要让用户再改一遍结构，那就失去意义了。我判断一个日报skill是否合格，标准只有一个：生成后用户能不能做到“核对数据，直接复制粘贴”。做不到，就说明模板设计还没到位。
2.3 为什么不要把逻辑全塞进提示词
新手最容易犯的错，是把所有规则一股脑写进一段超长提示词里。结果模型要么忽略后半段，要么在某些边界场景下自相矛盾。我的经验是，把逻辑拆成配置头、功能体、样例库三个层级，各管各的，互不干扰。
这里有一个特别反直觉的点：功能体里的步骤不要写太多。日报skill的功能体核心只有三步：识别输入中的事项、给每个事项打上“完成/风险/计划”标签、按模板重组。步骤一多，模型反而会在“执行步骤A时忍不住做步骤D”的状态里迷失。控制步骤数量，比把每一步描述到极限更重要。
另外，提示词里的规则如果超过一定量级，模型会倾向于“选择性地遵守”。这不是模型笨，而是指令出现了优先级混乱。所以我在设计时会刻意收敛规则数量，把高频规则放前面，低频规则放后面，再用样例做兜底。比如“禁止编造数据”这条规则，我不会只在功能体里写一遍，还会在样例库里专门放一个无数据输入的反例，让模型从两个层面同时记住这个原则。
3. 手把手设计一个日报skill：完整实操
接下来是实操部分。你可以按我的顺序，在任何一个AI对话工具里复现。我不依赖任何特定平台，用的是通用技能描述写法，你把它放进支持自定义技能的地方就能跑。整个过程大概需要四步，每步花十几分钟，整体一个下午足够。
3.1 第一步：写清“技能是一个人”
第一步先给skill立人设。日报skill是一段配置头，设计时先回答三个问题：它是谁、它对谁、它交付什么。我的写法长这样：
你是“日报管家”，一名擅长结构化表达的助理。你的服务对象是需要每日汇报工作的一线员工和管理者。你负责把用户提供的零散工作记录，加工成一份可直接提交的日报。这三句话同时解决了角色、服务对象、交付物三个信息。不要写“你是一个AI助手”，那等于什么都没说。模型需要的是一个具体的角色画像，越具体，后续行为的约束力越强。这个道理和带新人一样：如果你只跟新人说“你要努力工作”，他大概率不知道具体该做什么；但如果你说“你是质检员，负责把每件产品过三关，然后输出一份检查报告”，他立刻清楚自己的动作边界了。
3.2 第二步：定好输入输出协议
所谓协议，就是告诉skill什么时候工作、拿到什么、交出什么。配置头里要定义触发条件。
触发条件： 1. 用户输入包含今日工作、日报、工作记录、流水账等关键词。 2. 用户提供的内容是描述个人或团队当天发生的事项。 3. 用户没有明确提出其他任务类型时，默认进入日报生成流程。输出协议则直接给出模板骨架和填写规则。我建议在配置头里只放骨架，把更细致的填写规则放进功能体，避免配置头过长。触发条件这里有一个细节：覆盖场景要大于想象场景。因为用户不太可能每次都老老实实说“我来写日报”，更多时候是丢来一段“今天开了三个会，改了两个bug，下午一直在测接口”。你要让skill在这种口语化输入面前也能自动识别，所以触发条件里至少要有一个“内容本身包含当天事项描述”的兜底判断。
3.3 第三步：注入判断逻辑
功能体是skill真正干活的地方。日报skill的功能体，我建议按三个动作来设计。
动作一：清洗输入。删除口头语、无意义重复和情绪化表达。动作二：拆解事项。把整段输入拆成若干个独立事项，每个事项包含“时间/动作/对象/结果/风险”五个字段中尽可能多的信息。动作三：重组输出。把拆解好的事项填进模板，并在“需协助事项”中标记出确实需要别人配合的内容。
这一步技术上一点都不难，难的是拆解规则要写得边界清晰。比如“风险”字段，我规定它只能承接三类内容：可能延期的、可能出错的、需要资源支持的。其他内容一律不往风险里放。边界越清晰，模型越不会自由发挥。我见过有人把“用户抱怨了一句工作好累”也算成风险，这明显是功能体里缺少边界定义导致的问题。
3.4 第四步：给出样例与边界
样例库是很多设计者忽略的部分，但它恰恰是成本最低的“教学材料”。日报skill要有至少三组样例：
- 第一组：输入是流水账，输出是标准日报
- 第二组：输入是零散关键词，没有时间线，输出需要在今日计划中提示补全
- 第三组：输入包含了风险信息和跨部门协作需求，输出要体现问题与协助事项
样例不是给用户看的，是给模型看的。模型看到样例后，等于拿到了三个“标准答案”，在遇到相似场景时会优先模仿标准答案的结构和口吻。我用一个下午把样例从1组加到5组之后，日报输出质量提升非常明显，比改10版提示词都管用。
边界条件同样要写清楚。比如用户输入内容太少，不足以构成一份日报时，skill应该直接告诉用户“信息不足，请补充”，而不是强行编造。我会在功能体里加一条规则：如果输入少于三个有效事项，先向用户提问确认，再生成日报。
功能体示例（通用描述）： 1. 判断输入是否符合触发条件，不符合则询问用户是否切换到日报模式。 2. 清洗输入内容，去除无效表达。 3. 将输入拆解为独立事项，提取动作、对象、结果、风险。 4. 按模板生成日报：日期、今日完成、关键数据、问题与风险、明日计划、需协助事项。 5. 若有效事项少于3条，先追问用户补全，再输出日报。 6. 所有数据必须来自用户输入，禁止编造；无数据处写“暂无记录”。这一步做完，日报skill其实已经可以投入日常使用。你不需要把规则写得像一本手册，写得再多，模型也记不住，不如小步快跑，先跑通再迭代。
4. 从日报skill延伸到其他技能
日报skill跑顺之后，你会发现设计其他skill的思路完全一致。变化的是任务目标，不变的是“配置头+功能体+样例库”的铁三角。
4.1 工作总结skill：换汤不换药
工作总结skill在设计上几乎可以复用日报skill的全部能力，只需要把时间维度拉长，把输出模块换成季度总结、年度复盘。输入不再是当天流水账，而是阶段性的项目材料、数据截图文字版、问题记录。功能体增加一个维度：结果对比，比如目标达成率、同比变化。
我建议做这类skill时，把日报skill里的“问题与风险”模块扩展成“问题、原因、改进措施、下一步计划”四件事。模型对“原因”和“改进措施”的处理，需要额外加样例，因为它不像日报那样只是整理信息，而是多了一层分析动作。没有样例支撑的总结skill，很容易写出“做得好的地方继续保持，做得不好的地方需要改进”这种正确的废话。
4.2 会议纪要skill：把听众写进模板
会议纪要skill的难点在输出端，因为会议纪要的读者通常分为两类：参会者和未参会者。参会者需要行动项，未参会者需要背景和理解。设计时，我会在输出模板里增加“参会人共识”“遗留争议”“行动项Owner”三个模块。
这个设计思路其实也来自日报skill：先定义读者要什么，再倒推模板结构。不要一上来就写“会议纪要包含会议主题、时间、地点、参会人”这种流水账结构，那只是把会议记录换了个形式，没有增加任何信息密度。真正高质量的会议纪要skill，应该在功能体里加上一条：每个行动项必须包含负责人和截止时间，没有这两项的行动项等于没写。这条规则看着简单，却能极大提升纪要的可用性。
4.3 周报/OKR更新skill：借力日报数据
如果日报数据已经被结构化保存，周报skill可以直接引用日报中的“今日完成”和“关键数据”汇总生成。但在没有数据沉淀、只有对话记录的环境里，周报skill仍然需要靠用户输入来驱动。
这种情况下，我会把日报skill的“明日计划”模块改造成“下周关键目标”，同时增加一个“本周数据回顾”模块。功能体里的拆解逻辑不变，但输出模板要重新设计，因为周报的读者往往只看结果和风险，不想看每天重复的琐事。这个差异化设计的核心，是搞清楚输出模板到底为谁服务，而不是把所有信息都塞进去。设计任何skill之前，先问一句“这份输出给谁看、他要拿它做什么”，答案就是模板设计的出发点。
5. 常见问题与排查实录
设计日报skill的过程中，我踩过不少坑，也帮身边的同事排查过很多次不生效的问题。大部分问题的根子都在三个地方：触发条件、输入处理和输出约束。这里我把典型问题整理成一份速查表，方便你对号入座。
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| skill完全不生效，模型自由发挥 | 触发条件写得太窄 | 扩大触发条件覆盖范围，加兜底判断 |
| 输出格式混乱，模板不稳定 | 模板缺少字段示例 | 每个字段给一个示例值，降低理解成本 |
| 输入太乱，日报像流水账 | 功能体缺少清洗规则 | 增加过滤规则，设定事项数量上限 |
| 模型编造数据 | 没有强制数据来源约束 | 模板中标注数据来源，规则里明确禁止编造 |
| 风险信息被忽略 | 功能体分类边界不清 | 明确风险字段只承接三类内容 |
| 生成内容过于冗长 | 缺少表达级规则 | 增加“每条不超过两行”等约束 |
5.1 skill不生效，总是自由发挥
这是最常遇到的问题。表现是用户输入了日报素材，结果模型回了一段通用建议，完全不进技能流程。排查时先看触发条件写没写清楚，是不是只写了关键词，却没有考虑“用户用平常口吻描述当天工作”的情况。
我的处理办法是，把触发条件从“包含特定关键词”扩展成“满足以下任一情况时启用”，然后把“内容包含对当天具体事项的描述”也写进去。可以再加一句“如果不确定是否进入日报模式，优先进入日报模式”，给模型一个默认倾向。这样能覆盖大部分不触发的问题。另外，如果平台支持开关设置，记得把skill保持在开启状态，否则再好的配置都是白搭。
5.2 输出格式混乱，模板失效
模板失效通常是两个原因：一是模板里用中文描述格式，模型理解不了；二是模板没有给出具体的“填写示例”。解决方案就是把模板改成带字段名、带示例值的形式。
比如不要写“日期”，写日期：YYYY-MM-DD（例如：2026-01-15）。今日完成模块的示例写作“完成订单审批流程重构，推动联调验收通过”。模型在看到示例之后，格式稳定性会明显上升。这个方法看着笨，实测下来非常有效。模板示例不是给用户看的备注，而是给模型抓取的“格式锚点”，锚点越具体，输出越稳定。
5.3 输入内容太多太乱，日报二次加工
用户一次性丢来大量聊天记录或会议笔记，skill生成的日报经常显得杂乱。问题出在功能体没有对“输入上限”做说明，模型试图全部保留。我的排查经验是，在功能体里加一条“优先提取与工作结果相关的内容，过滤日常寒暄、通知转发和无关细节”。
同时给“事项数量”设一个上限，比如日报最多展示6到8条核心事项。超出的内容合并同类项，而不是全部平铺。这样日报的可读性会提升很多，也符合上级快速阅读日报的习惯。你会发现，限制数量反而是提升质量的手段，这也是skill设计与纯提示词生成之间一个明显区别。
5.4 模型编造数据，出现幻觉
模型在用户没有提供数据时，有时会自己补一个“处理了50个请求”“增长10%”之类的数字。这是AI生成内容最常见的幻觉问题，也是日报场景里最危险的问题，因为日报要向上汇报，假数据会带来信任风险。
我处理这类问题的办法很直接：在输出模板每个可能填数据的字段旁标注“数据来源：用户输入；如无，写‘暂无记录’”。在功能体中再加一句“禁止自行补充任何数字、百分比、完成量，所有数据以用户输入为准”。如果用户输入里确实没有数据，日报里一定要留白或写“暂无记录”，宁可难看也不能编。
提示：针对幻觉问题，样例库也要配合。在样例里故意放一组没有数据的输入，输出里明确展示“关键数据：暂无记录”，这样模型会把这个行为当成标准做法，而不是靠临场判断。实测下来，这种“规则+样例”双保险的处理方式，比单靠一条规则有效得多。
6. 实操心得与个人体会
拆解日报skill这件事，让我对“设计技能”有了比较完整的认识。最后分享三条心得。
6.1 迭代比一次写对更重要
我第一次做日报skill时，功能体洋洋洒洒写了两千字，结果实测效果比一段简洁的版本差很多。后来我才意识到，skill是在不断的输入输出测试中“长”出来的，不是在文档里“写”出来的。正确的做法是先用最简结构跑通，再根据失败案例逐步增加规则。
每次迭代只改一个变量。比如这次只优化“输入清洗”，下次只优化“风险模块”。如果一次改五个地方，出了问题根本没法定位。迭代周期建议是：先测三组代表性输入，记录每次失败点，然后集中修一个模块，再测五组，如此反复。这个过程你可能会重复好几轮，每轮看到的效果都是可感知的进步，这也是设计skill最有成就感的部分。
6.2 测试用例比技巧更重要
设计日报skill过程中，给我帮助最大的是五组固定测试用例。它们覆盖了流水账输入、碎片化关键词、带风险信息、带数据信息、信息不足五类场景。无论我如何改动功能体，都会拿这五组用例回归测试。
这套做法完全可以迁移到其他skill。先建立你自己的测试集，再去谈提示词技巧。因为技巧是包装，测试集是验收标准。没有验收标准的技能设计，本质上是在碰运气。很多时候我修完一版规则，感觉思路很清晰，但一跑测试用例就露馅，这就是测试集存在的价值——它能拦下你的自我感觉良好。
6.3 保持小边界，skill才有大价值
很多人在设计skill时容易陷入“什么都要管”的冲动，最后把一个日报skill做成全能助理。我的体会是，好的skill都是边界清晰的。日报skill只负责日报，不负责周报、不负责会议纪要、不负责工作计划，它的价值恰恰来自这种“窄而深”。
如果用户确实需要其他能力，可以通过触发条件和新技能去扩展，而不是把更多职责塞进同一个skill。边界清晰还有一个好处：测试范围可控，迭代速度快，出问题时也容易排查。日报skill是这样，其他skill也是这样。
在我实际使用中，最直观的收益是每天写日报的时间从十几分钟压缩到了两三分钟，而且提交前只需要核对一遍数据和风险项。这个变化不是因为我打字快了，而是因为我设计了一个真正可复用的skill。如果你也想做自己的第一个skill，从日报开始，是最不容易跑偏的选择。
