企业官网建设流程全解析

我每天最不想碰的一件事，就是写日报。白天时间被会议、代码、沟通填满，到晚上真正要交日志的时候，反而说不清楚自己干了什么。后来我在智能体平台里折腾"skill"这个东西——把某一类任务的处理方式打包成一个可复用的功能单元，一次配置，长期生效。真正把一个日报skill拆开之后我才发现，它没那么神秘，本质上就是一套被结构化过的流程和规则，而且只要掌握方法，任何人都能自己设计一个。

这篇文章主要写给三类人看：第一类是像我一样每天要写周报月报的人，想用AI把这件事变得省心；第二类是想在自己常用的智能体工具里做点自动化、但不知道从哪下手的人；第三类是好奇"一个skill到底怎么设计"的同学。我会从问题场景讲到内部构造，再带你把一个日报skill完整做出来，最后聊聊我实测踩过的坑。

1. 日报这个场景，为什么特别适合做成一个skill

很多人觉得skill是高大上的东西，一听就想到复杂的配置、API、权限管理。实际上，skill解决的最朴素的痛点是：AI对话没有记忆，也没有"岗位说明书"。这意味着每次对话，它都要临时猜测你的意图、你的格式习惯、你的表达偏好。

1.1 通用prompt为什么总让人不满意

我一开始也试过，简单地和AI说"帮我写一份今天的日报"。结果它输出了一篇看起来很像样、但仔细一看全是空话的文字。后来我学聪明了，把要求写进prompt里，比如"要分今日完成、明日计划、风险阻塞三块"，输出确实好了一点。但新问题立刻出现：换一个场景、换一次对话，我又要把这些要求重新说一遍；某个要求忘了提，输出马上就飘。

本质原因在于，模型每次都在"猜"你想要的产出。它手里没有一份固定档案，记录着你的工作习惯、你的日报格式、你的关注点。日报这种高频、强结构化、和个人工作方式强绑定的任务，恰恰是"无档案状态"的最大受害者。

1.2 skill到底解决什么问题

如果用一句话概括，skill就是给AI的一份岗位说明书加操作手册。它把三样东西固定下来：

• 任务边界：什么时候该用这个能力，什么时候不该用；
• 输入格式：需要用户提供哪几条信息，每条信息长什么样；
• 输出规范：最终产出物用什么结构、什么语气、包含哪些字段。

有了这三样固定信息，AI就不需要从零理解你的要求，更像一位已经培训过的员工，拿到你的要点之后直接按规矩产出。日报skill就是把"如何生成日报"这件事，从一段临时对话升级成一套稳定流程。

1.3 日报的天然属性决定了它天生适合做skill

我自己拆过的几个任务里，日报是回报率最高的一个。原因是日报有几个天然属性：

1. 高频：几乎每个工作日都要用，一次设计、长期摊销；
2. 结构化：绝大多数日报都逃不开"做了什么、接下来做什么、有没有风险"这三板斧；
3. 信息源复杂：素材分散在聊天记录、项目看板、邮件里，需要人先梳理，再让AI整理；
4. 输出格式相对固定：不管今天做了什么，日报的骨架不会天天变。

换句话说，日报属于"套路足够明确、变化只在内容层面"的任务。这类任务最适合交给skill去处理。反过来，如果一个任务创造性极强、每次都不重样，做成skill反而会束缚AI的发挥。

2. 把一个skill摊开来看：内部到底有哪些零件

作为普通用户，我们在界面上看到的可能只是一个按钮、一个开关。但底下一个skill通常由几个零件组成，我把它们一个个拆开说清楚。

2.1 元信息：一个skill的"身份档案"

元信息一般包括名称、版本和描述。很多人在设计skill时最容易忽略description，但它恰恰是最重要的零件之一。

原因在于，多数智能体平台在收到用户请求时，会先根据每个skill的描述来判断"这个请求该不该用这个skill"。也就是说，description不是给人看的封面，而是给调度器看的路牌。

我给出一个反例和正例的对比：

反例：

description: 生成日报

正例：

description: 用于生成结构化的每日工作汇报日报。当用户提到"日报、每日汇报、今日总结、下班前日志"等场景时使用。输入为用户零散工作要点，输出为包含今日完成、明日计划、风险与阻塞的Markdown文档。不适用于生成周报、月报、项目复盘。

差别在哪？正例把触发条件、输入输出、不适用的边界都说清了。调度器拿到这段描述，命中率就会高很多。这一步看似简单，却是整个skill稳定性的地基。

2.2 指令块：真正指挥模型干活的"操作手册"

指令块通常是skill里最大的一块内容。它是给执行时的模型看的，定义了角色、步骤、约束和补充规则。日报skill的指令可以这样设计：

1. 先判断用户输入的信息属于哪一类（已完成事项、明日计划、风险阻塞、数据指标）；
2. 对每一条信息做标准化精简，格式统一为"动作+对象+结果"；
3. 只允许使用用户提供的信息，不编造工作内容；
4. 如果用户给的信息过少，可以主动追问，而不是硬写。

这段指令看着简单，但没有它，模型就会自由发挥，输出就可能变成"天啊今天又是充实的一天"这类空话。

2.3 输入定义：告诉系统"用户需要填哪些信息"

skill需要一个清晰的输入定义，通常是一组字段。每个字段包含名称、类型、是否必填、说明和示例。它的作用是让调用端（聊天界面或配置界面）知道要引导用户提供什么。

日报skill的输入字段一般包括：

• 今日完成事项（必填，数组）；
• 明日计划（选填，数组）；
• 风险与阻塞（选填，数组）；
• 关键数据或指标（选填，字符串）。

有了字段定义，整个交互会变得更顺：用户不需要自己组织语言，只需要逐项填进去，甚至可以在聊天气泡里一条一条发。

2.4 输出模板：确保结果"长一个样"

输出模板定义了最终产出物的格式与结构。日报我会固定成四段式：

## 今日概览 一句话概括今天的主线成果 ## 今日完成 - 1. [项目A] 完成登录模块联调，修复3个阻塞缺陷 - 2. [活动B] 输出数据复盘初稿，待评审 ## 明日计划 - 1. [项目A] 联调通知模块，预计上午完成 - 2. [活动B] 根据评审意见修订复盘报告 ## 风险与阻塞 - 1. [项目A] 第三方接口文档延迟，依赖对方下周版本

固定模板的好处有两个：一是阅读者不需要每次适应新格式；二是AI的产出稳定，不会今天一个样、明天一个样。

2.5 工具与权限：如果skill需要接触外部数据

有些更完整的skill还会声明需要调用哪些工具或权限，比如读取日历、查询任务列表、把最终日报写入某个文档。这是skill和外界的接口层。如果平台不支持这些能力，一个务实的替代方案是让用户手动把素材粘贴进来，这也完全够用。工具能力属于加分项，不是必需项。

2.6 兜底逻辑：skill也要有"应急预案"

完善的skill还应该规定异常情况怎么处理。比如用户什么都没填就触发skill，应当追问"今天完成了哪些事？至少给我一条"；比如某个字段信息不明确，应当标为"待确认"，而不是自动替用户做主。这部分写成指令其实就几行，但能显著提升使用体验。

2.7 一个简化但完整的skill示例

把上面这些零件拼起来，一个简化版日报skill大概长这样：

name: daily_report_v2 description: 根据用户提供的当天工作要点生成结构化日报。仅在用户要求写日报/每日汇报/今日总结时使用。 version: 2.0 inputs: - field: done label: 今日完成事项 type: array required: true example: ["完成登录模块联调", "修复3个阻塞缺陷"] - field: plan label: 明日计划 type: array required: false - field: risk label: 风险与阻塞 type: array required: false output: format: markdown sections: - 今日概览 - 今日完成 - 明日计划 - 风险与阻塞 instructions: - step: 解析用户信息，按完成/计划/风险归类 - step: 将每条信息精简为"动作+对象+结果"，去掉口水话 - step: 缺失信息优先追问，不替用户编造 - step: 按要求渲染为Markdown日报

每个平台上的skill存储格式可能不一样，可能是JSON，可能是自然语言加参数，但骨架基本都逃不开这几个零件。理解了这套骨架，换到任何平台你都能快速上手。

3. 手把手搭一个日报skill：从需求一页纸到能跑起来

先不要急着写配置和指令。我自己的习惯是，先在一张纸上把需求写明白，再考虑技术实现。这个步骤花不了五分钟，但能帮你少走很多弯路。

3.1 第一步：写一张"需求一页纸"

设计skill前，先回答下面这张表里的问题：

这张表的作用是帮你锁定边界。很多skill做砸，不是因为实现复杂，而是因为需求没想清楚，最后设计出一个什么都能干、但干什么都一般的大杂烩。

3.2 第二步：设计输入字段，越少越好

在第一步基础上，把原始素材映射成结构化字段。我的原则是：能选填就不必填，能合并就合并。日报skill保留四个字段已经足够：

• done：今日完成事项列表；
• plan：明日计划列表；
• risk：风险与阻塞列表；
• note：补充说明或关键数据。

字段越多，用户填写的成本越高。如果你发现某个字段用户每次都填一样的内容，那它就应该被固化到指令里，而不是每次都让人重新敲一遍。

3.3 第三步：把输出模板钉死

这一步其实就是配置里的output部分。我会把模板的层级结构和长度限制写清楚。以日报为例：

• 今日概览：不超过两句话；
• 今日完成：最多8条，每条不超过30个字；
• 明日计划：最多5条；
• 风险与阻塞：最多3条，没有就写"暂无"。

限制条数和字数听起来有点较真，但正是这些数字才会让AI的输出保持克制。没有约束的模板，等于没有模板。

3.4 第四步：指令写成"动作序列"，而不是散文

写指令有个很容易踩的坑：把指令写成一段长篇大论，比如"请你扮演一位非常专业的产品经理……注意语言要正式……"这种写法的可执行性很差。

更好的做法是把它拆成一步一步的动作序列，每一步只做一件事。日报skill的核心动作其实就三步：

step 1: 解析。把用户发来的内容按"完成事项、明日计划、风险阻塞"三类拆分。 step 2: 提炼。将每条内容压缩为一句，格式固定为"动作 + 对象 + 结果/进展"。 step 3: 渲染。按输出模板生成Markdown日报，顺序固定为概览、完成、计划、风险。

如果想让输出质量再上一个台阶，可以在动作序列后面补一两个正例和反例。模型看过具体例子之后，对"什么算合格的句子"会更有把握。

3.5 第五步：定义参数schema，哪怕平台不强制

有些平台允许你给skill写一份JSON格式的参数说明。即使平台不强制，我也建议写一份，因为它是"输出模板"的机器可读版本，能让字段流转起来。

{ "type": "object", "properties": { "done": { "type": "array", "items": { "type": "string" }, "description": "今日完成事项，每项一句话" }, "plan": { "type": "array", "items": { "type": "string" }, "description": "明日计划事项" }, "risk": { "type": "array", "items": { "type": "string" }, "description": "风险与阻塞事项" }, "note": { "type": "string", "description": "其他补充，例如关键数据" } }, "required": ["done"] }

这段schema的作用很直观：只有一个必填字段，其余都是选填；每一项都是字符串数组。以后如果你想做周报自动汇总，这个schema可以直接被复用到下一个skill里。

3.6 第六步：先本地手工测一遍，再固化成skill

很多平台的skill创建之后可以直接在对话里测试。我的建议是，先用普通对话手动模拟一遍你的指令，看输出是否靠谱。因为指令和真实效果之间的差距，只有跑了才知道。我通常准备三个测试输入：

• 正常输入：包含完成、计划、风险三类信息；
• 最小输入：只有一条完成事项；
• 垃圾输入：一段毫无结构的意识流文字。

三个测试用例都满意后，再把它正式固化为skill。固化之后，再找同事或朋友实际用一周，收集真实反馈做第二轮迭代。只自己用，很容易陷入"我觉得挺好"的盲区。

4. 实测下来最容易翻车的5个地方

把一个skill跑起来不难，难的是让它在各种真实场景里都稳。我把自己实测过程中遇到的翻车点整理一下，你设计的时候可以直接避开。

4.1 description写得太宽，skill被"滥用"

我最早设计日报skill时，description写的是"生成汇报文本"。结果用户说"帮我写个周报"，它也会被触发，然后输出一份不伦不类的四不像。原因是描述里的"汇报"覆盖范围太大。

解决办法只有一个：写清楚触发边界和不适用范围。前面提到的"不适用于生成周报、月报、项目复盘"就是刻意加的边界话术，别嫌啰嗦。边界越清晰，调度越准确。

4.2 只给规则不给例子，输出总是差口气

指令里写了"精简为动作+对象+结果"，但模型在真实输出时经常给出"登录模块联调完成"这种缺少动作的描述，或者"完成了登录模块的联调工作并修复了若干缺陷以及优化部分体验"这种又长又不直观的句子。

后来我在指令里加了一个正例和一个反例：

正例："完成登录模块联调，修复3个阻塞缺陷" 反例："登录模块联调基本上完成了，几个崩溃问题也都弄好了，整体体验不错"

模型看到这种对照之后，输出句子的质量和稳定性立刻上了一个台阶。例子是规则最好的解释器，这句话在skill设计里永远适用。

4.3 没有处理"用户什么都没给"的分支

有时候用户只扔过来一句"写个日报"，什么素材都不给。如果skill硬写，就只能编造内容，这是大忌。我的日报skill里专门写了一条兜底指令：

当用户未提供任何工作内容时，不生成日报，先追问："今天完成了哪些事？请至少提供一条，我会帮你整理。"

这条指令看似简单，却能避免最尴尬的"一本正经编日报"事故。

4.4 想把所有场景塞进一个skill，最后变成巨型prompt

skill的边界一旦画得太宽，指令就会越来越多，从日报、周报到年度总结都想管，最终配置文件可能上千行，输出质量反而下降。模型在复杂指令下的表现，通常不如在专注场景下的表现。

我的做法是：一个skill只解决一件明确的事。日报归日报，周报另建一个skill，两者可以通过同一份数据联动，而不是塞在一起。拆分之后，每个skill都更稳定，调试也更方便。

4.5 改来改去，都不知道哪一版是好的

设计skill的过程一定是要反复改的。但有段时间我改得多、记得少，最后分不清哪个版本是稳定的。后来我养成了一个习惯：每次大改前，把当前可用的版本存一份，文件名带上日期；并且在小范围内跑测试用例，用同一组输入对比新旧版本输出。

这个方法本质上和写代码时的版本管理一样，只是更轻量。你不需要什么复杂工具，建一个目录、按日期保存描述文件就够了。

5. 从日报skill走向技能包：一个可复用的设计骨架

当你亲手把日报skill做出来之后，你就会发现，它的价值不只是日报本身，更重要的是它背后那套设计骨架可以搬到很多任务上。

5.1 提炼通用的四步骨架

任何"信息整理类"任务，几乎都可以套用下面四步：

1. 收集：接收零散信息，尽量结构化；
2. 归类：判断信息属于哪个维度；
3. 提炼：压缩、去重、规范化表达；
4. 渲染：套用固定模板输出。

日报是这四个步骤最典型的例子：把碎片化的工作记录收集起来，归到完成、计划、风险三类，提炼成"动作+对象+结果"，再渲染成标准日报。周报、项目复盘、会议纪要清理，本质上都是同一套流程。理解了这一点，你设计的就不再是单个skill，而是一整个技能包。

5.2 骨架如何迁移到其他任务

拿周报来说，你只需要把输入字段从"今日完成"换成"本周完成"，把输出模板的"今日概览"换成"本周概览"，指令里的时间词从"今天"改成"本周"，一个新skill就出来了。

会议纪要skill的改造点又稍有不同：输入字段应该是"会议主题、参与人、讨论要点、待办事项"，输出模板则是"结论先行、按议题分组、待办标明负责人和截止时间"。骨架还是收集、归类、提炼、渲染四步，但每一层的具体规则要根据场景重写。

这种迁移方式有一个额外的好处：因为骨架一致，未来你可能可以把几个skill串起来，比如日报攒一周自动变成周报素材，周报攒一个季度变成季报素材。数据格式在设计时就对齐，后面做自动化就能省很多事。

5.3 skill设计的两条底线

最后分享两条我在实际使用中沉淀下来的体会，给后面要动手做skill的同学一些提醒：

第一，skill不能替你做决定，它只负责把决定表达得更清楚。比如日报里的"明天计划做什么"必须由你提供想法，skill不应该替你编计划。它能把你的想法整理得更体面，但代替不了你的思考。

第二，先做小再做大。不要一开始就追求一个无所不能的超级skill。从一个只有两个字段、三步指令的最小版本开始，跑顺了，再加字段、加步骤、加工具。小步快跑在skill设计里同样成立。

5.4 我的个人习惯

我自己的实操习惯是：每个skill都留一个"迭代日志"字段，记录每次改动的原因。比如"v2.0：新增risk字段是因为老板总问风险""v2.1：把条数限制加上，否则输出太长"。这些记录在你回看的时候会特别有价值，因为它们记录了设计决策的上下文。

如果你手上也有一个每天都要做的重复性任务，我建议你今天就试着把它拆成上面的结构，哪怕不用任何复杂平台，就用最普通的文本记录加指令，也能体验到"一套固定套路带来的稳定感"。skill这个概念的真正价值，不是让你崇拜技术，而是让你学会用结构化的方式，把重复的事情一次搞定。