企业官网建设流程全解析

最近我把一个“日报汇总”的 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。这个设计要提前定清楚，不然后面接数据流的会很痛。

第四个是版本号。别小看version，Skill 是要迭代的。改一次 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，体验立刻差了一个量级。

我整理了一个排查顺序，建议按这个顺序来找问题：

5.2 三个我实际踩过的坑

这里分享三个比较典型的踩坑经历。

第一个是轻视触发词。我最开始做日报 Skill 时，description里只写了“日报”两个字。结果用户说“整理一下今天干了啥”，Skill 完全没反应。后来我把描述改成“将零散工作记录整理成结构化日报，包含今日完成、明日计划、风险与求助。当用户提到写日报、总结今天工作、整理 daily report 时使用”，触发率才明显提升。

第二个是输入校验太弱。有一次我拿一个“明显是一篇公众号文章”的内容测试，模型竟然把文章里的内容当成工作记录，生成了一份看起来合理但完全虚构的日报。这给我提了个醒：不是所有文本都适合作为日报输入。后来我在兜底规则里特别加了一条：如果输入内容中出现了和“工作记录”特征不符的内容，优先反问用户确认，而不是直接转。

第三个是输出过度正式。我一开始对模型的要求是“使用正式书面语”，结果生成出来的日报变成了领导发言稿：“本人积极推动首页改版工作，有效提升了用户体验。”这种日报放到团队群里自己都想抠个洞钻进去。后来我把规则改成“语气客观、不夸大、每条不超过 50 字”，输出才回归正常人话。

5.3 什么时候不该用 Skill

Skill 不是银弹，有些场景我反而不建议用 Skill。

第一种是场景太简单。比如“把一句谢谢翻译成英文”“帮我想一个标题”，这种一次性、轻量、不需要结构化的请求，直接用 Prompt 更快，没必要做成 Skill。

第二种是需求变动极频繁且没有稳定规则。如果你老板每天对日报格式的要求都不一样，今天要求三栏，明天要求五栏，后天又要加一个表格，你维护 Skill 的成本远高于每次手写 Prompt。这种时候，稳定的格式才是 Skill 的前提，没有格式就谈不上固化。

第三种是没有稳定的输入来源。如果一个 Skill 每次都需要用户手动整理超大量的基础数据，那它创造的价值就很有限。真正有价值的 Skill 必须解决“数据从哪里来”的问题，要么接工具、要么接数据库、要么至少让用户输入过程变得足够简单。

还有一个判断标准可以分享：如果一个任务你只用一次就再也不做，别做 Skill；如果一个任务你每周要做两次以上，且每次处理方式相似，那就值得做一个 Skill。这就是它区别于普通 Prompt 的核心价值。

最后再分享一点我个人的经验。Skill 设计的真正难点，不在于写出一段精妙的提示词，而在于把“输入怎么来、过程怎么走、输出长什么样、出错了怎么办”这四件事想清楚。我第一次拆开日报 Skill 的时候，也有一种“原来如此”的感觉，它本质上就是把我们日常做事的方法论，翻译成一套机器能稳定执行的规格。你现在就可以从手头最简单的一个重复性任务开始，试着把它定义成一个 Skill，等跑通一次之后再回来看这个日报 Skill，你会发现它一点都不神秘。