拆解智能体Skill：从日报生成到自定义设计全流程

如果你在某个智能体平台里，看到一个“日报 skill”能自动把一天的工作浓缩成三段式日报，大概会和我一样好奇：它到底是靠什么魔法完成的。我第一次拿到这样一个日报 skill 时，第一反应不是用它，而是把它拆开——我想知道一个 skill 到底是怎样“长”出来的，知道它的骨架之后，是不是自己也能照着设计一个。

说实话，一开始我以为 skill 背后有什么了不得的算法，拆完才发现，它本质上就是一套被封装好的“小业务流程”：一段触发词、几个输入槽位、一份提示词模板，再加一点兜底逻辑。这些东西组合起来，就能让助手从一个“什么都会但什么都不精”的通用对话模型，变成一个“专门干某件事”的可靠工具。今天我就用日报 skill 当案例，从外到里拆一遍，把它的每个零件都摊开给你看。看完你会发现，设计一个 skill 的门槛没有想象中高，真正难的只有一件事：你有没有把用户要的东西想清楚。

1. 一台“会写日报”的机器，是怎么让我起了拆解心思的

先说那个让我产生拆解冲动的场景。某个工作日的晚上，我打开常用的智能体应用，顺手点了一个叫“日报生成”的技能，对着它说了句“今天做了三件事，上午开会，下午改了两个 bug，明天要发版”。它回答了一句“好的，请稍等”，然后真的给我吐出了一份工整的日报：分成了“今日完成”“存在问题”“明日计划”三个小节，还自动把“改 bug”这种口语化描述整理成了“完成两处缺陷修复”。三秒钟，事情就结束了。我盯着那段输出愣了几秒：这家伙到底是怎么知道日报该这么写的？它又是怎么保证每次格式都这么统一的？

如果只是好用，我大概不会深究。真正让我好奇的是它的“稳定感”。我连续试了几次不同风格的说法——有的很啰嗦，有的只给关键词，有的故意不说清楚日期——它的输出格式都几乎没有变化。通用聊天的情况下，同一个问题问十遍，可能就是十种答案；但用这个 skill，十次测试得到的是九次同构的答案。这说明它不是靠大模型“临场发挥”，而是有一层固定流程在背后兜底。这层流程，就是 skill 的骨架。

后来我才逐渐理解，可以把 skill 想象成餐厅后厨里的一张“套餐卡”。烤箱还是那个烤箱，食材还是那堆食材，但套餐卡规定了：前菜几道、主菜用什么酱汁、出餐顺序是什么。只要客人点了这个套餐，厨房就按固定路线走，出来的菜自然不会太离谱。智能体平台上的 skill 也一样：大模型是后厨，skill 是那套餐单，用户是点菜的客人。

这种理解对我的帮助非常大。以前我总觉得“让 AI 帮我写日报”是一件全凭缘份的事，得靠我把提示词写得特别完整才行；但有了 skill 的概念之后，我发现主动权其实在“设计套餐卡”的人手里——也就是 skill 的设计者。一个好的设计，能让一个表达能力很差的用户也得到一份体面的日报；一个粗糙的设计，哪怕用户提示词写得再细，也可能被模型带偏。于是我开始认真琢磨：一个 skill 到底由哪些零件组成，每个零件分别解决什么问题。

这篇文章想分享的，就是完整的拆解过程。我默认你看过一些智能体产品，用过“技能”“插件”“助手”这类功能，但你不需要懂编程，不需要会写代码。我会把日报 skill 拆成零件，再用它当样本，一步步演示怎么设计属于自己的 skill。整个过程会涉及一些提示词和配置层面的东西，但我会尽量用大白话讲透。

2. 大卸八块：日报 skill 的五个核心零件

台面上看，skill 是一个“打开就能用”的按钮。台面下，它其实是五个零件拼装起来的。我花了一段时间反复观察、测试，最后把日报 skill 拆成了这五层：触发层、输入层、编排层、生成层、承接层。下面一层一层说。

2.1 触发层：它怎么知道用户想写日报

任何 skill 都需要一个“开关”。用户可能说“帮我写今日日报”“把今天的工作总结一下”“生成日报”，也可能直接说“日报”。触发层要做的，是从这些五花八门的表达里识别出同一个意图：用户想生成一份日报。

我观察到的实际做法是，skill 配置里会维护一组触发词和触发规则，比如：

• 关键词：日报、今日总结、工作总结、daily report
• 意图条件：请求中包含“写”“生成”“总结”等动作词，同时时间指向“今天/今日/当天”
• 排除条件：如果用户说的是“日报数据给我看一下”，那可能触发的是另一个查询类技能，而不是生成类技能

这个层设计得好的标志是：该触发的时候不漏，不该触发的时候不抢。我以前就踩过类似的坑，在另一个项目里设了过于宽泛的触发词，结果用户提到“日报”两个字就被抢答，连“你昨天说的日报我看了”这种句子都拦截下来了。所以触发词一定要尽量具体，而且要搭配动作词一起判断。

2.2 输入层：它需要向用户要什么信息

触发成功之后，skill 面临的问题是：信息够不够生成一份日报。日报最基础的信息是什么？今天做了哪些事。但光有这个还不够，一份合格的工作日报通常还包含问题、计划、协作对象等。所以输入层会定义若干“槽位”，也就是它需要收集的参数。

日报 skill 的槽位一般长这样：

这里有一个很关键的取舍：槽位太少，用户一句话就能说完，但输出质量不高；槽位太多，用户需要回答一堆问题，体验会烦。我见过一个翻车案例，某个日报 skill 一口气向用户问了七个问题，包括“你的团队目标是什么”“今天心情如何”，用户直接答不下去了。好的输入层设计通常只保留三到四个核心槽位，其余全部设为可选，让用户自愿补充。

2.3 编排层：整件事按什么顺序推进

有了输入，还要有流程顺序。编排层相当于这条 skill 的“导演”，它决定用户说完“帮我写日报”之后，助手第一步干什么、第二步干什么、每步之间怎么衔接。

日报 skill 的典型编排是：

1. 接收请求，判断触发
2. 检查必填槽位是否齐全
3. 如果缺失，用一次反问收集信息，不要连环问
4. 信息齐全后，进入生成阶段
5. 输出结果后，主动询问是否需要修改

编排层之所以重要，是因为它决定了 skill 的“性格”。有的 skill 给人一种“很聪明但很着急”的感觉，就是因为编排层少了确认环节，用户刚说了两三句话，它就擅自把日报发出来了，结果一半信息是猜的。有的 skill 又给人一种“话太多”的感觉，每一步都要解释半天。平衡的做法是：关键信息缺失时反问一次，非关键信息缺失时用默认值兜底，生成之后提供修改入口。

2.4 生成层：提示词模板和输出结构

这一层是 skill 最接近“内容”的部分。前面几层收集的信息，最终都要交给生成层处理。生成层的核心是一份精心设计过的提示词模板，模板里规定了角色、任务、输入变量、输出格式、约束条件。

我拆解过的日报 skill，其提示词模板基本是这种结构化的写法：

你是一名个人助理，负责为用户生成工作日报。 用户提供了以下信息： - 日期：{date} - 今日事项：{tasks} - 存在问题和风险：{issues} - 明日计划：{plan} 请严格按照以下格式输出日报： ### 今日完成 （将用户的原始描述整理成简洁条目，保持原意，不添加未提及的内容） ### 存在问题 （如果没有问题，则写“无”） ### 明日计划 （如果没有计划，则写“暂无明确安排”） 注意： 1. 不要编造用户未提及的事实； 2. 每条内容不超过一行； 3. 保持语气客观中性。

看到这个模板，你大概就明白了：skill 的“聪明”其实一半来自这种强约束。它不指望大模型自由发挥，而是用格式把输出框住，让模型在框架内做整理工作。这就像一个厨师虽然有自由发挥的空间，但菜品必须按套餐卡上的三道菜来出。

2.5 承接层：生成完之后怎么继续对话

最后一个零件，也是最容易被新手忽略的。生成日报不是终点，用户很可能紧接着说“再把第三段改一下”“把明日计划去掉”“换成表格形式”。如果 skill 没有承接层，这段后续请求就会变成一场灾难——助手会忘记刚才生成过什么，重新跑一遍流程。

一个完整的日报 skill，在输出结果后应该保持“上一轮上下文”，让用户可以对刚生成的日报进行追加修改。我测试的时候就试过，生成完日报后紧接着说“把第三点改一下”，做得好的 skill 会准确找到第三点并修改，做得差的 skill 会问我“第三点是什么”，宛如失忆。

到这里，五个零件就齐了。它们分别是开关、原料、流程、配方、售后。任何一个零件缺失，skill 都会显得不完整。接下来，我带你跟着一个真实的日报 skill 从头到尾走一遍，看看这些零件是怎么协同工作的。

3. 跟着我走一遍日报 skill 的完整“生命周期”

拆分完毕，光看零件还是不够，得看它们怎么运转。我模拟一次完整的日报生成过程，每一步对应前面提到的哪个零件，我会顺手标出来。这比单纯罗列概念直观得多。

3.1 从一句“帮我写今日日报”开始

假设用户一上来只说了一句：“帮我写今日日报。”没有提任何具体事项。

触发层立刻命中：这是一句明确的日报生成请求。但输入层马上发现，必填槽位里的“今日事项”是空的。如果这时候 skill 直接带着空信息去生成，就会出现典型的“AI 幻觉日报”——它东拼西凑给你编一些内容，你看了只会觉得莫名其妙。

所以编排层介入，决定先问一个问题，而不是直接生成。它的反问是这样的：

“好的，正在为你生成今日日报。请先告诉我：今天你完成了哪些主要工作？如果有明日安排，也可以一并告诉我。”

这个反问有几个细节：一次只问最核心的信息；把“明日安排”做成追加选项而不是强制要求；措辞里给了用户一个回答模板的暗示——“完成了哪些主要工作”，大多数用户会顺着这个句式去列举。

3.2 参数确认环节的应对策略

用户接着回答：“上午和某合作方对了需求，下午把上周那个报表重做了一版，另外还改了两个小 bug。”

这里输入层会做一次信息解析：把用户的话拆成条目，识别出“对需求”“重做报表”“改 bug”三个事项。现在必填槽位齐了，但可选槽位“明日计划”还是空的。编排层没有选择继续追讨明日计划，而是用了一个轻量级的补问：“需要把明日计划补充进日报吗？如果没有，我就写‘暂无明确安排’。”

这种“给一个默认选项”的做法非常聪明。用户的认知负担很低——不想填就说没有，想填就直接说内容。对比之下，很多业余 skill 的编排是“我问你答，问到你烦为止”，两者高下立判。

3.3 生成日报的内部逻辑

信息齐全后，生成层开始干活。它把解析好的条目填进提示词模板，交给大模型整理。我实际操作时看到的内部过程大致是这样的：

• 用户原文“改了两个小 bug”被整理成“修复两处线上缺陷”
• “和某合作方对了需求”被整理成“与某合作方完成需求对齐会议”
• 表述变得更书面化，但没有增加任何新事实
• 输出严格按照“今日完成 / 存在问题 / 明日计划”三节走

我特意把“存在问题”留空了，想看看 skill 会怎么处理。结果它输出的是“暂无发现需要披露的问题”，而不是自作主张猜测可能存在的问题。这一点我要专门夸一下：日报最忌讳的就是把“可能的风险”写成“已经发生的故障”，skill 这里没有越界。

3.4 输出成品的形态

生成结果的最终形态是这样的：

### 今日完成 1. 与某合作方完成需求对齐会议，明确下一阶段交付优先级。 2. 重做上周报表，更新数据口径，补充同比/环比对比。 3. 修复两处线上缺陷，回归验证通过。 ### 存在问题 暂无发现需要披露的问题。 ### 明日计划 明日暂无明确安排。

注意几个结构特征：条目用短句，每条大致保持“动作 + 对象 + 结果”的句式；没有使用过于夸张的形容词；明日计划没有信息时没有硬编造。这些本质上都是提示词模板里的约束在起作用。

3.5 学会请求修订

生成完毕，承接层该出场了。系统会在日报下方追加一句提示：“如需调整格式或补充内容，直接告诉我即可。”

我测试了两种修订请求。第一种是“把日报改成表格”；第二种是“把第一点改得再具体一点”。第一种请求需要把整份日报结构重排，第二种请求需要定位到第一条内容做局部改写。做得好的 skill 这两种都能接住，因为承接层保留了上一轮的生成上下文，并且知道“改第一点”对应的是结果结构里的第一个条目。

跑完这一整个流程，你会发现一个 skill 的“靠谱感”不是某个单一环节带来的，而是每一层各司其职的结果：触发层判断对时机，输入层收集对信息，编排层选择了合适的追问策略，生成层控制住输出格式，承接层提供修改闭环。任何一环崩了，用户的体感都会明显下降。

4. 从拆到建：自己设计一个 skill 的六个实操步骤

拆完了，接下来讲怎么建。如果你也想设计一个自己的 skill，不用管平台的配置界面长什么样，核心方法论是一致的。我自己做了几个 skill 之后，沉淀出一套六个步骤的打法，分享给你。

4.1 先写“一句话定义”

很多人设计 skill 上来就写提示词，这是大忌。你连“这个 skill 到底解决什么问题”都没想清楚，怎么写都别扭。我的习惯是先用一句话定义它，格式是“在什么场景下，帮什么人，把什么输入变成什么输出”。

拿日报 skill 举例，一句话定义可以是：在每天下班时，帮普通上班族，把零散的工作记录变成结构化日报。这句话看着简单，但它能逼你做出几个关键决策：场景是“下班时”，说明信息可能不完整，需要追问；人群是“普通上班族”，说明界面要口语化，不能太技术范；输出是“结构化日报”，说明格式约束是第一位的。

如果你写出来的这句话需要三分钟才能讲完，那说明你想做的可能不是一个 skill，而是一个产品。先把范围切小，再谈设计。

4.2 画出最小流程

一句话定义清楚后，画流程。不需要复杂的流程图，就画“开始—步骤—结束”的最小路径。日报 skill 的最小路径就是：

用户说“写日报” → 问今日做了什么 → 用户回答 → 套模板输出。就这么简单。其他一切功能，比如格式切换、问题追问、版本回退，都是后续加戏，不是首版该考虑的事。

这一步的目的是让你把注意力放在“主干”上。很多 skill 失败的根源不是功能太少，而是首版就塞了太多边角功能，导致每条路径都打磨不到位。先让最小流程跑起来，再逐步加分支。

4.3 定义触发词和必填参数

接着细化输入。我给自己的技能设计一般会做一张表，列出每个参数：

触发词我一般会写至少三组：直接呼唤型（“写日报”“生成日报”）、场景描述型（“总结一下今天的工作”）、缩写型（“daily report”“日报生成”）。写完加一条排除规则：如果用户想查看历史日报，不应该触发本技能。

4.4 写出第一版提示词模板

然后才是写提示词。建议你一开始就采用结构化模板，不要用大白话写一大段。结构化的好处是容易迭代，输出了问题你能精准定位是哪个部分没约束住。

第一版可以不用很完美。我自己的日报 skill 第一版其实很粗糙：输出格式只写了“列三条”，没规定每条的字数上限，结果生成出来的内容有长有短，看着很不整齐。后来我在模板里加了“每条不超过一行”“按‘动作 + 对象 + 结果’句式”这两个约束，输出质量才稳定下来。

模板写完之后，找一个真实场景跑一遍，然后准备修复问题。请务必接受一个现实：第一版提示词一定会输错一两次才会变好用，这很正常。

4.5 小范围测试与补“防呆”逻辑

很多 skill 设计者有个坏毛病：只用正常输入测试。我建议你做一轮“故意刁难测试”，专门输入边缘条件，看系统会不会崩、会不会胡说。比如：

• 用户什么都提供：只见“帮我写日报”就不吭声了 → 编排层应该用一次追问兜底
• 用户信息太少：“今天还行” → 生成层需要输出“今日无重大事项”而不是编造
• 用户信息过多：一口气说了十件事 → 生成层需要合并相似条目，不能照单全收变成流水账
• 用户给的是明天的信息：日期写明天，内容却是未来计划 → 输入层需要识别时间错位

这些边界条件每个都需要一条“防呆”规则。补的时候不用想太多，每条规则就是一个 if 判断：什么条件出现，就走什么分支。补完之后再做第二轮测试，直到输出稳定。

4.6 迭代记录：从“能用”到“好用”

最后一步是迭代。我强烈建议你用文档记录每一次修改的动机和结果，哪怕只有三行。比如我自己的日报 skill 迭代历史是这样的：

v1：输出格式不稳定，长句短句混杂。修复：提示词增加“每条不超过一行”约束。 v2：用户说“今天也就那样”被直接生成日报。修复：加入一条防呆规则，当输入信息量过少时，先用默认句式兜底。 v3：用户想把日报复制到文档里，但 Markdown 符号被原样复制进去了。修复：输出时减少装饰性符号，改用纯文本编号。

这些记录看着琐碎，但它们才是 skill 从“能跑”到“好用”的真正台阶。

5. 当我开始自己设计 skill 之后：几个认知和边界

自己动过手之后，很多看法都变了。最初我以为 skill 就是“高级提示词”，后来发现它更像一种产品设计；最初我以为 skill 越多越好，后来发现不是每个需求都适合做成 skill。这个部分聊几个认知层面的东西，顺便说说我实测中翻过的车。

5.1 好 skill 的三个可验证特征

如果让我用一个标准检验一个 skill 好不好，我会在完全不看配置的情况下连测五次，然后看三个特征：

• 透明：用户能感知到这个 skill 在收集什么信息、下一步要做什么，而不是黑盒操作。日报 skill 会明确告诉你“我需要今日事项才能生成”，这就是透明。
• 可预期：相同结构的输入，得到的输出结构基本稳定。第一次和第五次生成日报，格式应该保持统一，而不是一次列表一次散文。
• 可修正：生成结果之后，用户有明确的渠道继续调整，而不是拿到一份“最终解释权归 AI”的交付物。

这三个特征不是抽像概念，它们分别对应承接层、生成层和编排层的设计好坏。如果你的 skill 测试中这三个特征的表现都很好，那基本可以上线。

5.2 什么场景不适合做成 skill

再说一个反常识的体会：不是所有需求都适合做成 skill。我自己就做过几个半途而废的技能，总结出三类不适合：

• 强主观判断型：比如“帮我决定今天中午吃什么”，用户的主观偏好太重，skill 设计得再好也难让人满意。
• 高频临时需求型：比如“随手翻译一段话”，用户的需求每次都不同，用通用对话即可，做成 skill 反而多了启动成本。
• 需要外部实时数据型：比如“查一下我快递到哪了”，如果 skill 没有对接相关数据接口，就只能在里面用提示词编造信息，这是最糟糕的体验。

我做日报 skill 之所以顺利，是因为日报的结构几乎固定、事实完全由用户提供、输出格式明确，这三点恰好是 skill 最容易发挥效力的场景。

5.3 我实测中遇到的最“蠢”翻车场景

讲一个具体的翻车经历。某次我把日报 skill 的追问逻辑设成了“用户每缺一项信息就问一次”，原意是想把信息收集得更完整。结果实测时，用户回答完“今日事项”之后，系统问“你有问题要写吗”，用户说“没有”，系统又问“明天有计划吗”，用户开始不耐烦。连续三个追问之后，用户直接来了一句“你就随便写吧”。

这次翻车让我明白了一个道理：编排层不应该追求“信息最大化”，而应该追求“体验最优化”。当用户表现出不耐烦倾向时，合理的应对是停止追问，启用默认值，尽快产出结果。后来我的日报 skill 把追问次数上限设置成了两次，超过就自动兜底，再没出过这个问题。

还有一个翻车点是日期处理的时区问题。某次测试我在当天晚上十一点触发日报，系统生成的日期正确；但同样的话在凌晨零点一分触发，日期却跳成了“明天”。排查之后才发现，输入层用了“当前时间加一天”的错误逻辑，修复成直接取系统日期字段后就好了。这类问题特别隐蔽，如果你设计的 skill 涉及日期，一定要专门测几个跨天的时间点。

5.4 更进一步：skill 之间的协作与生态

日报 skill 拆完了，设计方法也给了，最后聊一点展望：skill 和 skill 之间是可以协作的，这份日报数据也可以沉淀下来做更多事。

我目前在自己的工作流里，就把“日报 skill”和另一个“周报 skill”串在一起用。日报输出的是一个固定格式的文本，周报 skill 会读取这一周内所有日报的文本，然后用模板压缩成一份周报。因为两份 skill 都用了相近的“动作 + 对象 + 结果”句式，周报整合起来几乎没有障碍。如果将来再把日报输出同步到一张表格里，月初做“月度回顾”的时候，那条技能也能直接消费这些数据。

这意味着什么？意味着 skill 的本质不是一个孤立的“小助手”，而是一个可重复调用的功能单元。你设计的每一个 skill，都可以成为下一个 skill 的输入来源。当初设计日报 skill 时多花一点心思把输出结构定得规范，后面就能省下一大堆二次处理的工作。

坦白讲，我拆解日报 skill 之前，一直觉得设计一个技能是种技术活，要会配置、会调接口、会优化模型参数。拆完之后才发现，真正的难点不在“技术”，而在“定义”——你把场景定义得多清楚，把边界画得多准确，把输出约束得多规范，skill 就展示出多大的价值。大模型还是那个大模型，变的是你包在它外面的那层“套餐卡”。

对我个人来说，最大的收获是建立了一种拆解思维：遇到一个好用的智能体功能，我不再只会“哇”，而是会下意识地想，它的触发层是怎么写的、输入层收集什么、编排层怎么决定追问的节奏、生成层靠什么约束格式、承接层如何接住修改请求。你也完全可以带着这套框架，去拆下一个你觉得好用的 skill。拆完一个，你就会发现，原来一个 skill 真的就长这样，而你，也真的能设计一个。