企业官网建设流程全解析

1. 为什么“把做法交给 AI”这件事，值得单独搞一个概念

先聊一个大家应该都经历过的场景：你花了大半天时间，喂给 AI 一堆背景信息、设定好角色、手把手教它“按步骤来”“先做这个再做那个”“这个说法不对，换个口径”……终于调出了一个满意的回答模板。隔了一周，换了一个新会话，AI 又变回了那个“一问三不知”的机器人。你只好把之前的提示词翻出来，复制、粘贴、微调，再折腾一遍。

我之前很长一段时间就是这么过的。直到我开始认真用那些带“Skill”概念的工具和平台，才意识到一个问题：我们一直在“教” AI 做某件事，但从来没想过，把教过的内容沉淀成一份“可复用的做法”。这个“可复用的做法”，正是 Skill 的核心。

很多人第一次看到 Skill 这个词，第一反应是“这不就是提示词吗？换了个名字而已”。说实话，我从接触这个概念到真正理解它的价值，也花了很长时间。但用久了你会发现：Skill 和提示词，完全不是一个层面的东西。

简单来说，提示词是你对 AI 的一次“指令”，它随着会话结束就消失了；而 Skill 是你对 AI 的一种“能力注入”——你把一套做法、判断标准、执行步骤、输出形式打包成一个独立的功能模块，以后无论开多少个新会话，只要调用这个 Skill，AI 立刻就“会”做这件事了，而且是按你沉淀下来的那套标准做法来执行。

可以这样理解：提示词等于你临时交代别人“这次帮我这么干”；Skill 等于你给这个人一份“SOP 手册”，告诉他以后遇到这类活儿，永远按这个流程走。一个是战术层面的指令，一个是打法层面的沉淀。

这篇文章我打算把这个概念拆透，包括它的构成、设计方法、实战过程、常见坑，以及它对个人和团队到底意味着什么。如果你已经厌倦了每次重复调教 AI，或者你想在团队里推行一套统一、高效的 AI 用法，这篇文章值得你花十分钟读完。

2. Skill 的本质：把“隐性经验”变成“显性能力”

要理解 Skill，得先看它解决的是什么问题。

2.1 为什么“临时教”AI 这么累

用过 AI 对话的人应该都有体会：AI 很聪明，但它和你不在一个语境里。你知道自己想要什么，它不知道。你懂你这行的术语、标准、坑，它不懂。于是你得解释。更麻烦的是，同样是“写一封邮件”，对内对外、对上级对平级、正式场合还是轻松场合，写法完全不一样，你得一句一句地教。

这种“临时教学”的模式有几个明显的痛点：

• 每次都要从零开始，浪费大量时间在重复的描述上；
• 你表达得不够精确，AI 就瞎发挥，结果不可控；
• 你脑海里的经验、套路、偏好，AI 完全感知不到，输出质量完全取决于你当时的心情和表达水平；
• 把同一个任务交给另一个同事做，对方也未必能复现你的效果，因为你的经验在你脑子里。

一句话：经验没有被结构化，自然无法被复用。

2.2 Skill 到底改变了什么

Skill 做的事情，本质上是对“AI 能力”进行了一次模块化封装。它把你处理某一类任务时用到的所有要素——背景知识、执行步骤、判断规则、样例、输出模板——集中打包，变成一个可以被随时调用、反复使用、方便分享的独立单元。

我举个具体例子你就明白了。假设你是一个做用户研究的人，经常需要整理访谈记录，提炼“用户痛点”。如果临时跟 AI 说“帮我把这段访谈记录整理成痛点清单”，AI 大概率只会给你列几条干巴巴的描述，什么“用户觉得操作复杂”“用户希望更简洁”这种，根本没法直接用。但是如果你设计一个“访谈记录分析 Skill”，里面写清楚了：痛点必须在哪几个维度上归因、每条结论必须带原文摘录作为证据、同一问题重复出现多次必须标注频次和强度、优先级怎么排序、输出格式是什么……那么只要调用这个 Skill，AI 就会严格按这套标准来工作，出来的成果直接可以贴进报告里。

这个区别就是：前者像你找了一个啥都不懂的实习生，手把手教了三十分钟，勉强干了个 60 分的活；后者像你把一个资深分析师的思维流程复制了一份给 AI，它一上来就能干 80 分以上的活。

2.3 和 Workflow、Agent 到底有什么区别

既然聊 Skill，就绕不开另外两个高频词：Workflow 和 Agent。我刚开始也经常把这三个弄混，用多了才发现它们各有侧重。

• Prompt（提示词）：一次性的对话指令，用完即弃，适合零散、目标单一的需求；
• Skill（技能）：可复用的“专业能力包”，解决的是“AI 擅长某类任务”的问题，可以被任意工作流、任意 Agent 调用；
• Workflow（工作流）：流程编排，解决的是“多个步骤如何串联”的问题，比如先做 A，再判个条件，走 B 分支还是 C 分支，最后汇总到 D；
• Agent（智能体）：更完整的自主系统，感知环境、做决策、调用工具、执行行动，Skill 在其中充当某一个专业模块。

我自己的理解是：Workflow 管流程，Skill 管质量。Workflow 决定 AI 走哪条路，Skill 决定它在某一段路上走得专不专业。所以三样东西并不是竞争关系，而是互补关系——真正复杂的场景里，你大概率需要把它们混着用。

3. Skill 的内部构造：入口、指令、知识、校验一个都不能少

概念讲清楚了，下面说说实操层面：一个高质量 Skill，到底由哪些部分构成。

我现在设计 Skill 的时候，基本上按五层结构来拆。这五层可以说是缺一不可。

3.1 第一层：能力入口——“什么需求会触发这个 Skill”

AI 模型本身并不知道你定义了哪些 Skill。当你在对话框里发出一条指令时，底层机制会先做一道“匹配题”：根据你的输入和系统中已有 Skill 的描述信息做相关度匹配，匹配上了才调用。这在类 RAG（检索增强生成）的机制或者 LLM 的“工具调用”机制中很常见。

所以为了让 AI 能“知道”什么时候该用这个 Skill，你需要给它一个非常清晰的入口信息：这个 Skill 解决什么问题、触发的关键词有哪些、什么任务属于它的职责范围。

举个例子，我之前做过一个“会议纪要整理 Skill”。它的入口描述我写的是：“当用户提供一段会议录音文字稿，并要求整理会议纪要、提取决策结论、生成待办事项时，使用此技能”。这几句话不是废话，它负责让系统在合适的时机把对应的 Skill 调出来。

入口写得太窄，AI 该触发的时候不触发；写得太宽，AI 什么任务都往这个 Skill 里塞，输出出来人不对题。这个度需要反复调。

3.2 第二层：指令主体——“这个任务按什么流程做”

这是 Skill 的核心骨架。你要告诉 AI 处理这一类任务的完整步骤。理想情况下，每一段指令都要做到：明确、可执行、有顺序要求。

以会议纪要为例，参考结构大致是：

1. 先通读全文，识别讲话角色和话题主线；
2. 把内容按议题归类，提取各部分的关键结论；
3. 标注每条结论对应的负责人和截止时间（如有提及）；
4. 按“议题背景—讨论过程—最终结论—待办事项”的结构组织输出。

这层设计得好不好，直接决定了 AI 给出的成果是“有条理的专业交付”还是“散装信息拼盘”。我建议你在设计这层时，把自己代入“一个资深从业者带新人”的角色，把你平时做事时脑子里自然而然在走的流程，一步不落地写出来，哪怕你觉得“这不是明摆着的嘛”。

3.3 第三层：知识背景——“做这件事需要知道哪些常识”

很多专业任务不能光靠流程干活，还需要背景知识支撑。比如“用户访谈痛点分析”，AI 你得告诉它：什么叫真痛点（用户明确表达的不满或损失）、什么叫伪痛点（用户嘴上说说但实际愿意付出代价跨越的困难）、什么算隐性痛点（用户没直接说但通过行为能推断出的）。这些判断标准如果不提前塞给 AI，它只能靠语感瞎蒙。

知识层写得越扎实，AI 输出的专业感就越强。甚至可以说，同一个 Skill，专业人士写出来的和普通人写出来的，效果可能差好几个档次。因为真正有价值的是那些行内人才懂的默会知识，你把它们显性化了，AI 自然就更“懂行”。

还有一个细节：知识层不要只写正向规则，还要写“反例”。比如说“优先级排序时，不要根据用户抱怨的激烈程度排序，而是根据问题发生的频率和影响面排序”，这种“不要做什么”的指令，能有效压制 AI 最常用的一些“一看就不专业”的套路化处理方式。

3.4 第四层：示例数据——“好 和坏，各来一两个”

现在的模型普遍对 Few-Shot 样例非常敏感。你在 Skill 里放几个完整的输入输出示例，它就能非常精准地把握你要的格式和深度。

这里我要特别强调：我在做 Skill 的过程中发现，单放高质量示例还不够，必须配一个“反面案例”。给 AI 看一个“低于平均水平（结尾的那版输出），再告诉它为什么不行，相当于直接拉低了它的出错的概率。这种“对比学习”的效果比单纯教它怎么做来得更直观。

反面案例也不用多，一个就够了。关键是讲清楚差在哪：格式混乱？结论没有依据？遗漏了关键信息？这些点评本身就是给 AI 立的规矩。

3.5 第五层：输出约束——“成果长什么样才算交付合格”

最后一层是定义输出格式和质量标准。你最好能直接给出 Markdown 模板、表格结构、甚至字段级别的定义。

例如会议纪要我给的输出模板可能是这样的：

# 会议纪要：{会议主题} ## 会议信息 - 时间：{时间} - 参与人：{参与人} ## 议题讨论 ### 议题一：{议题名称} - **背景**：{背景描述} - **讨论要点**：{关键论点} - **结论**：{最终结论} ## 待办事项 | 事项 | 负责人 | 截止时间 | |------|--------|----------| | {事项描述} | {姓名} | {日期} |

别小看输出约束这一层。AI 模型的能力再强，没有交付标准的约束，它就会按自己的“平均审美”来输出——你得到的一定不是差的，但也不是好的，就是“平均”。把交付标准写死在 Skill 里，输出的质量下限就被兜住了。

提示：不用追求一次就把五层全部写完美。先写一个 60 分的版本，放在真实场景里跑几天，哪里不行补哪里，Skill 是需要持续迭代的“活”产品，不是写完就结束的文档。

4. 从零做一个 Skill：以“项目复盘专家”为例走一遍全流程

上面讲的算是“静态拆解”——Skill 是什么、由什么构成。这一章我带你完整走一遍从想法到落地的全流程。为了让过程具体可感，我用一个虚构的例子：“项目复盘专家” Skill。

4.1 第一步：定位目标，明确使用场景

做任何事情之前，先问自己三个问题：这个 Skill 是给谁用的？什么场景下用？希望达到什么效果？

“项目复盘”这个场景我很熟。以前带项目的时候，每次复盘会要开一下午，会后整理复盘纪要又得花半天。很多项目明明踩了坑，但因为复盘文档写得烂，经验教训根本沉淀不下来，同样的坑换一个项目又踩一遍。

所以我设计这个 Skill 的目标就两个：一是把项目复盘从“开会聊聊天”变成“结构化沉淀”，二是让生成的复盘报告可以直接进入知识库，方便后续检索。

我当时定的使用场景是：用户提供一段项目基本信息和复盘素材（比如进度数据、成员反馈、问题列表），Skill 自动生成一份完整的结构化复盘报告。

4.2 第二步：搭骨架，写“核心指令流”

写核心指令流的时候，我的习惯是先写“流程骨架”，再逐行细化。

以项目复盘为例，参考的流程写出来是这样：

1. 先分析项目的基础背景：项目目标是什么、周期多长、资源投入有哪些；
2. 从用户提供的素材中提炼“关键事件时间线”，标注每个事件对项目进程的影响；
3. 分类梳理“做得好”与“待提升”的事项：目标达成度、进度管理、团队协作、技术方案、外部依赖等维度；
4. 针对每一个“待提升”事项，追溯根因——区分是流程问题、人员问题、决策问题还是不可控的外部因素；
5. 输出结构化复盘报告，沉淀可复用的行动项。

你看这个流程写出来之后，AI 做的事情其实和资深项目主管复盘时的路径是一致的：先看整体、理顺经过、分维度评价、归因、再输出行动项。你只需要把它从“脑子里想”变成“提示词里的流程”，这就是核心的最大一步。

4.3 第三步：补充知识背景和判断标准

光有流程还不够，AI 需要知道“什么叫好，什么叫问题”。在这一步我把一些关于复盘的“专业常识”写进去。

例如我会明确告诉 AI：归纳原因时，要区分“直接原因”和“根本原因”，不要只停在表面。比如项目延期，直接原因可能就是“联调时间不够”，但根本原因可能是“需求评审阶段没有拉齐接口规范”。AI 如果不知道做“根因分析”这一层，它输出的只会是一堆表面现象的罗列。

我还给它提供了“原因分类维度表”：

这些背景知识写进去之后，AI 做归因时就不再是“随口一说”，而是按一个分析框架来展开。

4.4 第四步：写示例 + 反例，这一步千万别偷懒

示例是这一套流程里最费时间、但回报也最明显的工作。

我当时的做法是拿一个真实复盘报告（脱敏处理后）作为正例，从“标题层级”“归纳口径”“行动项颗粒度”三个角度做了注释。又专门虚构了一个“反面示例”放在后面：这份反面报告把复盘写成了“流水账”，只有时间线没有分析，只有“下次注意”没有具体行动项，并且逐个说明了它不合理的原因。

为什么反例有用？因为大模型的训练数据里有海量的水货复盘文档，“平均输出”的水平就是那种“流水账 + 空话”，如果你只用正例来教，相当于让 AI 既要打破原有语境、还要模仿你的范例，它得花不少力气才能完全摆脱原始风格的“惯性”。给了一个反例并明确“不要往这个方向写”，等于帮它做了一次“锚定”，直接把你不需要的选项排除掉了。

4.5 第五步：定义输出格式，并做实际跑测

最后一步是把输出格式固定下来。我沿用了一套经典的复盘报告结构：

# 《{项目名称}》项目复盘报告 ## 一、项目概况 （目标、时间、投入） ## 二、关键事件时间线 （以时间顺序列出里程碑事件与偏差） ## 三、核心成果与不足 （分维度：目标达成、进度、协作、方案等） ## 四、根因分析 （基于事实逐项归因，明确直接原因与根本原因） ## 五、经验沉淀与行动项 （接下来做什么？谁负责？什么时间完成？）

模板定好之后，我在不同工具里分别跑了几轮测试，输入不同的项目素材，看看输出的结果是否符合预期。这个过程一定要做，因为写的时候你觉得思路通，实际跑起来模型还是会给你“意外惊喜”。

注意：做测试时，不要只拿一个顺利的、规范的素材喂进去。要专门准备几个“刁钻”的输入：比如素材里信息非常零散、上下文不完整甚至相互矛盾。测试的目的不是证明你的 Skill 好用，而是发现它在什么极限场景下会“崩”。

5. 实战后的避坑清单：这些是我踩过的坑

Skill 的好处是用得越久越明显，但前面的路也谈不上顺畅。我把自己踩过的和见过别人踩过的坑整理了一份清单，按“高发程度”排列，你看看有没有同感。

5.1 命名和描述写得太随意，导致“该用时不用，不该用时乱用”

很多同学做 Skill 的时候，名字就两个字“翻译”或者“总结”，描述就一句话“用于翻译/总结”。这样写，AI 在匹配时根本判断不了你的 Skill 和其他普通功能有什么区别，结果就是：该触发的不触发、不该触发的时候瞎触发。

建议：名字和描述尽量按“触发意图 + 适用对象 + 核心能力”来写。比如“翻译：将中文技术文档翻译为地道英文版，保留术语一致性与文档格式”就比“翻译工具”好得多。描述中还可以带上两三个典型的触发词示例，帮模型把匹配精度往上拉。

5.2 指令太长，模型直接“疲劳”

见过不少初学者做的 Skill，恨不得把所有讲解和背景知识都塞进指令里，写了一两千行。意图很好，但模型对超长指令的注意力是有限的，塞得太多，关键信息反而被淹没。

我自己的经验是：指令主体保持“精炼的流程步骤 + 清晰的验收标准”，而把大段的背景解释放到知识层或者单独的参考文档里。如果有些内容属于“参考资料”性质的，可以单独存成文档，在 Skill 里引一下路径即可。

5.3 示例全都是“理想完美版”，缺少“低质量对照”

只给优质示例，AI 会默认所有任务都得“顶配输出”，结果在素材不充分的时候，它会硬着头皮编造细节来凑足格式。反过来，如果你给了它“素材不够的时候应该如何处理”的示例，它反而会很自然地做信息缺失标注，而不是瞎编。

这块我在做“问答分析”类的 Skill 时体会特别深，AI 面对不完整的用户反馈，第一反应是“脑补”。后来我在示例里专门加了一个案例：输入只有一句话“我觉得不好用”，输出必须标注“信息不足，建议补充追问”，效果立竿见影。

5.4 作用域不清晰：把“小技能”做成了“大杂烩”

一个 Skill 的职责边界要清晰。有些人希望一个 Skill 全干了，又要它做访谈分析，又要它写会议纪要，还要它生成行动计划。结果模型在调用时经常跑偏，输出结构也拧巴。

解决思路是：一个 Skill 只解决一个“任务簇”（一组强相关的子任务），如果你发现需求是“多任务组合”，用工作流把多个 Skill 串起来更稳、更好维护。分开的另一个好处是：单点升级时可以各改各的，而不会牵一发而动全身。

5.5 过度抽象：前面讲得很漂亮，实际完全落不了地

有一种写得特别华丽的 Skill，各种框架、术语、方法论，AI 执行的时候好似在课堂上背诵教科书，输出的东西全是大词、空话，没有结论。这种问题的根源就是：你写的“知识背景”太抽象，但“执行动作”不具体。

我的个人建议是：每个抽象维度后面都配一个具体判断动作。比如“评估进度风险”太抽象，得写“对比各里程碑节点的计划完成日期和实际完成日期，若偏差超过 15%，标记为高风险并在复盘中单列说明”。这样每一条背景知识都能落地，你回看的时候也会觉得可衡量。

6. Skill 怎么落地到日常工作流中：三种常见的运用姿势

设计好一个 Skill 只是第一步，真正让它产生价值的是“被持续使用”。聊几个我体验下来比较落地的用法，给不同使用习惯的朋友做个参考。

6.1 个人日常调用：把高频任务“技能化”

适合个人起步的操作方式，是挑一个你自己每周至少要干一次的重复任务，把它做成一个 Skill。比如：整理周报、读文章提炼要点、把碎片想法扩写成正式邮件。做的时候会很花时间，做成之后你每次只需要丢一段素材进去，它就按你的习惯把活干了。

我自己的“灵感整理”技能就是这么来的：以前看文献、看竞品截图，灵感来了一大堆但从不整理，时间一长全忘了。现在我把“从任意形式素材中提取关键信息、按领域归类、标注灵感来源、附一个下一步行动建议”做成了一个 Skill，每天花五分钟把零碎内容丢进去，它就自动产出整理后的结构化笔记，配合笔记软件直接归档。

6.2 团队共享：统一团队产出标准

Skill 本质上是一个文本文件，天然适合分享。团队场景下，你可以把“项目复盘 Skill”“客户沟通邮件 Skill”“数据分析报告 Skill”这些内容沉淀并共享出去。

这里要给一个非常具体的建议：**Skill 共享不要再靠“把提示词复制到群里”这种方式了，看起来很高效，其实很快就版本混乱了你根本分不清哪份是最新的。**更稳的做法是放在团队的文档仓库里，每个人从仓库更新，改的人负责把变更日志写清楚。一个团队只要把 10 个左右的核心 Skill 管好，AI 使用水平的整体下限就会明显抬高。

6.3 作为 Agent 的“专业模块”：Skill 的更高阶玩法

如果你已经在玩 Agent，Skill 就更重要了。Agent 的规划、推理能力再强，也需要领域专业知识来支撑，否则它做出来的结果仍然很“通用”。

现在的常见做法是：Agent 先拆解任务目标，然后按需求调用一系列 Skill。比如做一个“竞品分析 Agent”，它可以调用“信息抓取 Skill”“数据对比分析 Skill”“报告生成 Skill”，每个 Skill 负责一个专业环节。

我个人的体会是，与其指望一个巨大的 Agent 无所不能，不如先把底层 Skill 的质量打磨好再组合。Skill 就是 Agent 世界的“专业工种证书”，Agent 是项目经理，Skill 是那个真正干活的专家。你手里专家多不多、专家专业不专业，决定了 Agent 的天花板。

7. 一个容易被忽略的设计心态：Skill 是你的“AI 分身”，不是“AI 说明书”

最后分享一个我在做了很多个 Skill 之后才悟出来的心得。

很多人设计 Skill 的时候，心态还是“我在给 AI 写说明书”——我把步骤列清楚，AI 照着做就行了。但实际用下来会发现，真正好用的 Skill，更像是你在“塑造一个 AI 分身”：一个了解你的标准、知道你的偏好、替你处理某一类具体事务的“数字替身”。

这就意味着两件事：

第一，它必须了解你的“口味”。比如同样的“写日报”，给 AI 塞一套“公司统一模板”你当然可以用，但如果再加一句“重点标出与昨日相比有进展的事项，用词简洁不用形容词”，它输出出来的东西才真正像“你写的日报”，而不是标准答案式的流水账。这种个人色彩画出来，Skill 才是“你的”。

第二，它必须能承接你“自己会做的但懒得重复的事”，而不只是“你根本不会做的事”。很多人做 Skill 总想挑战高难度任务，结果因为自己也不熟悉流程，写出来的指令自己都看不明白。真正顺手的选择，是从那些你已经熟练到形成肌肉记忆的任务开始，因为只有你最清楚“做好这件事”意味着什么。把你脑子里的“做法库”交给 AI，它的上限不会超过你的表达能力，但它的下限会离你很近。

我在实际使用中还有一个体会：Skill 设计得再好，也需要定期“回炉”。业务在变、模型在变、你自己的标准也在变。每隔一段时间，把你最常用的几个 Skill 拿出来，重新审视一遍指令、更新一遍示例、删掉过时的内容，这个过程本身就是对你个人方法论的重新梳理。哪怕不做任何修改，光是“重新读一遍自己设计的逻辑”，也是对思路的一次有效整理。

这个内容后续还可以扩展开来，比如把 Skill 组合成一套完整的工作流、给自己的 Skill 做自动测试、在团队里建立 Skill 评审机制等等。但核心思想不变：AI 时代，真正值钱的不再是“会用 AI”，而是“能不能把自己的专业做法，结构化成 AI 能反复使用的能力资产”。Skill 恰好就是这件事最直接的落地方式。