企业官网建设流程全解析

最近这半年，我做的一件事的频率开始变得非常高：把各种“一次性提示词”改造成可以反复调用的 Skills。最初只是为了解决一个特别琐碎的问题——我让 AI 助手帮我写周报，但它每次都问我“什么格式”“要不要数据”“昨天开会内容算不算”。我把要求一条条补进去，提示词越攒越长，改一个标点都担心效果跑偏。后来我开始系统性地整理这些提示词，把它们拆开、命名、加参数、规定输入输出。这就是所谓的 Skills：把一次性的临时指令，变成一个带结构的、可复用的技能包。

这件事做到现在，我已经在本地维护了二三十个大小不一的 Skills，覆盖周报、会议纪要、代码评审、需求拆解等场景。这篇文章就围绕“开发各种 Skills”这条主线展开，讲讲我是怎么从零设计一个技能包、怎么写指令正文、怎么调试踩坑，以及发布给他人复用前需要想清楚的问题。如果你正处在“AI 助手有点好用但还不够稳”的阶段，这篇文章应该能帮上忙。

1. 先想清楚一件事：Skills 究竟解决了什么痛点

很多刚接触这个概念的人，都会把它理解成“不就是一段写好了的提示词吗？”这话对了一半。如果只是把一句“帮我写周报”扩展成“你是一个周报助手，要包含本周完成、下周计划、风险阻塞三部分”，那确实还停留在提示词层面。Skills 和普通提示词最本质的区别，在于它把“经验”变成了“结构”。

我说个很典型的场景。以前我写提示词，从第一版到第十版，靠的是“感觉不对就加一句”。比如 AI 生成的周报里出现了我没干过的事，我就加一条“只能基于提供的日志生成，不得编造”；它把上周的数据混进来了，我又加一条“只统计本周内容”。等到第十版的时候，这段提示词已经有两屏那么长，模型读起来累，我自己维护起来更累。更麻烦的是，同一个任务在不同的项目里要用，就得把这段文字复制好几份，改一处忘了改另外几处，版本混乱得一塌糊涂。

Skills 解决的就是这件事。它不只是一段文字，而是一个封装好的单元，包含触发方式、参数定义、执行规则、输出格式、边界条件。你可以把它理解成工具箱里的一把螺丝刀：不是随手捡来的一块铁片，而是有规格、有握柄、知道该旋哪种螺丝的专用工具。你只需要喊一声“用周报技能”，它就知道该拿哪把刀、按什么顺序干活。

从使用体验上说，Skills 带来的四个好处是我真正体会到了的：

• 一致性和可复现性：同一个技能，不管今天用还是明天用，输出结构基本稳定，不会因为“今天心情好就多写两段”。
• 可维护性：想调整技能，只需要改一处文件，所有调用它的地方都会生效，不需要到处复制粘贴。
• 可组合性：多个小技能可以串成一条流程。比如“会议纪要整理”加“待办事项提炼”，合在一起就是一个更复杂的工作流。
• 可分享性：技能包本身是个独立文件，发给别人就能用，不需要对方理解你的整套提示词体系。

所以在开发各种 Skills 之前，我建议你先想清楚：你不是在“写提示词”，而是在“封装一门手艺”。这门手艺的边界是什么、输入是什么、输出是什么、在什么情况下会失效——这些问题想得越清楚，后面写起来越顺手。

2. 从需求到结构：把“想做的事”拆成一个好技能包

我见过不少人写技能，第一步就是在对话框里让 AI 生成一段完整指令，然后存下来完事。这样做出来的东西，运气好能用两三次，运气不好第二周就失灵了。原因很简单：你没有先拆需求，就直接写了实现。开发 Skills 的第一步，应该是把一个模糊的“我希望它能帮我做事”，拆成一个结构清晰的技能包骨架。

2.1 一个技能包到底由哪几块组成

我在实际维护中总结下来，一个能长期稳定使用的技能包，至少包含五个部分：

第一是触发方式。也就是你用什么方式唤起它。最常见的是斜杠命令，比如/weekly-report，也有一些工具允许你用自然语言描述触发条件。名字要短、要能代表这个技能的用途，别起一个自己都看不懂的缩写。

第二是参数定义。这是很多人会忽略的。技能不是每次都处理一模一样的输入，你得告诉模型：哪些参数是可变的、每个参数允许什么值、缺省时怎么处理。比如周报技能，可能需要period（周期）、tone（口吻）、includeMetrics（是否包含量化指标）这几个可变项。

第三是指令正文。也就是技能的核心逻辑。这个部分要写清楚角色的定位、执行的步骤、输入的来源、输出的格式，以及绝对不能做的事。

第四是边界规则。技能不是万能的，你要在指令里写明“什么情况应该停下来反问用户”，而不是让它硬着头皮瞎编。

第五是示例。最好带一两个输入和输出的对照实例，模型看过示例之后，理解指令的准确度会明显提升。

这五个部分，对应到文件结构里，就形成了我在下一节会详细说的最小目录模板。

2.2 拆技能：一个技能只做一件事，流程用编排解决

刚开始写技能，最容易犯的一个错误，就是想做一个“万能技能”，把所有相关任务都塞进去。比如希望周报技能同时完成“汇总日志”“分析风险”“生成下周计划”“顺便把周报翻译成英文发给老板”。这样的技能文件写出来很长，模型执行的时候注意力会被摊薄，经常出现顾头不顾尾的情况。

我的判断标准很简单：如果一个技能需要满足的前提条件超过三个，或者它的输出可以被明确拆成几个相互独立的部分，那就说明它太大了，应该拆开。

拿周报这件事举例，我会拆成这样两个技能：

乍一看好像多了一步，但实际上每一步都更可靠。log-summarizer只管把日志整理成规范结构，不用操心文风；weekly-report只负责把摘要升华成一篇完整周报，不用从一堆碎片里做归纳。两者串起来用，效果远好于一个“大而全”的技能。

当然，也有不需要拆的情况。如果任务是“把 Markdown 表格转成 CSV”，一个技能配一条核心规则就够用了，拆成两个反而增加调用成本。所以拆与不拆的权衡点在于：任务的复杂度是否超过了模型的单次稳定执行能力。超过了就拆，没超过就保持简单。

2.3 三个参数设计约束，让技能“看得懂也用得动”

参数是技能和外部世界的交互接口，设计得好不好，直接决定技能能不能在真实场景里被稳定调用。我在实践中总结出三个约束条件，每一次都让我少踩不少坑。

第一个约束是参数要少。能用两个参数解决的，绝不用三个。每多一个参数，模型在解析时就有多一层出错的可能。真实场景里，用户没有那么好的耐心去填五个参数再调用技能，默认值做到位更重要。

第二个约束是参数值要可枚举，尽量少让用户输入自由文本。拿tone这个参数来说，你定义成“正式、轻松”两个枚举值，模型就很容易理解；你定义成“写一段文字描述你想要的风格”，模型大概率会收到一个无法预期的东西。参数值越确定，技能输出越稳定。

第三个约束是每个参数都必须有默认值和示例。默认值保证用户不填也能跑，示例保证模型知道这个参数长什么样。一个参数缺了示例，模型就可能按自己的理解去发挥，发挥一次还好，发挥两次风格就跑偏了。

用这三条标准回头审视我最早写的几个技能，几乎所有“失灵”的问题，最后都能追溯到参数设计上。

3. 落地实现：写一个能稳定复用的 Skill 需要抠的细节

结构设计完了，接下来就是落地实现。这一步看起来像写文档，实际上非常考验对执行过程的推演能力。我见过很多人在这里翻车：明明每一步都写了，可技能跑起来就是不稳定。问题通常出在对执行细节的抠得不够。

3.1 目录结构：只用两个文件的轻量模板

我不太推荐一上来就搭复杂的目录结构。对于绝大多数场景，一个技能对应一个文件夹、里面放一到两个文件就够了。我一直用的最小模板是这样：

skills/ weekly-report/ SKILL.md examples/ 01-input.md 01-output.md

SKILL.md是这个技能的主文件，里面同时包含元信息、参数定义和指令正文。examples目录放置一组输入和输出样例，用来帮助模型理解任务形态。不要小看样例文件，在后面做回归测试时它们就是你的测试基准。

SKILL.md里我习惯用 YAML 头块加 Markdown 正文的结构。YAML 头块存参数之类的结构化信息，正文写指令逻辑。一个很典型的例子长这样：

--- name: weekly-report version: 1.2.0 description: 根据工作日志生成结构化周报，适合每周五下班前使用。 parameters: period: type: string required: false default: 本周 enum: [本周, 上周, 本月] tone: type: string required: false default: 正式 enum: [正式, 轻松] includeMetrics: type: boolean required: false default: true ---

注意，这个头块里我特意把版本号写进去了。你在本地自己用的时候可能觉得没必要，但一旦技能开始迭代，你会发现没有版本号，你根本分不清当前目录里的是旧逻辑还是新逻辑。

3.2 指令正文的五个要素和一条主线

正文部分是整个技能的核心。我把它拆成五个要素：角色定义、执行步骤、输入约束、输出格式、禁止行为。下面这个“周报生成器”的正文，就是按这条主线组织的：

你是一个周报写作助手。你的任务是基于用户提供的原始工作日志，生成一篇结构完整的周报。 执行步骤： 1. 检查用户是否提供了原始日志。如果没有，列出需要补充的信息，不要自行编造。 2. 将日志内容按“本周完成”“下周计划”“风险与阻塞”三个模块归类。 3. 每个模块用条目式表达，每条不超过两行；优先保留有量化结果的内容。 4. 若日志缺少量化数据，在对应条目后标注“（数据待补充）”。 输入约束： - 只允许使用用户提供的信息，不得补充任何外部知识。 - 若用户提到“加上上周的数据”，请礼貌拒绝，本技能只处理当前周期的事务。 输出格式要求： - 使用 Markdown，用二级标题划分三个模块。 - 整体字数控制在 300 到 500 字之间。 - 结尾附上一句可直接粘贴到文档的开场白。 示例输入见 examples/ 目录。

这段正文里，每一步都在推演模型实际会经历的过程。“若用户提到‘加上上周的数据’请礼貌拒绝”这句，就是我之前被坑过后补上的——你不说清楚边界，模型就会自作主张把上周数据也合并进来。

写正文的另一个经验是：步骤不要用长段落来写，拆成编号步骤。教程式的“首先、其次、然后”很容易让模型丢失步骤顺序，但编号列表结合简洁的动作描述，执行效果会好很多。

3.3 上下文和记忆管理：别让技能背着太多包袱

技能在运行的时候，前面可能已经有很长的聊天记录。你之前和 AI 聊了天气、聊了代码、聊了周末安排，这时候突然调用周报技能，模型需要在一堆无关信息里找到你的技能指令。这是 Skills 运行不稳的重大隐患，很多时候问题不是出在技能本身，而是出在了上下文环境。

应对方法有三种。第一种，技能里尽量写“假设你只看到本次对话中用户提供的日志”，让模型忽略前面无关的历史聊天。第二种，把多轮对话里真正需要保留的信息，在技能里显式地要求“写入最终输出”，不要依赖模型从历史记录里找。第三种，如果工具实现允许，尽量给每个技能开一个独立会话，让技能在干净的环境里运行，效果会明显提升。

我自己在本地维护时，有一个很直观的经验：技能开头的“角色定义”和“执行步骤”最好控制在 10 条以内，超过这个量，模型对每条规则的执行完整度就会下降。与其用一个超长技能包，不如拆成几个短技能串联。这不是什么高深理论，就是注意力规律：指令越长，能精确执行的指令越少。

4. 实测翻车：我在调试技能时踩过的坑与排查链路

技能写得再好，不上真实场景跑一遍，你永远不知道自己错在哪。下面这几类问题，是我在调试各种 Skills 时反复遇到的，我把完整的排查链路和修复方案写出来，你以后遇到类似问题可以直接套。

4.1 现象一：同一个技能，怎么有时候灵有时候不灵

这是我遇到的第一个玄学问题。明明昨天用得好好的，今天再调，输出风格突然就变了，或者干脆没有按照指令走。

我先说排查顺序。

第一步，查触发有没有成功。有些工具里，你输入命令后不一定会真的调用技能，可能只是把这句话当成普通消息发给了模型。这个可以通过观察工具的调用日志来判断。如果你用的工具看不到日志，就在技能第一步写“先回复：已开始生成周报，正在整理日志……”，如果模型没有这样的反馈，那基本可以断定它压根没进入技能流程。

第二步，查命中的是不是最新版本。我自己就干过这样的事：改了技能文件，但运行时工具还在读取缓存里的旧版本。碰到这种情况，清缓存、重启客户端，或者检查文件路径是否指向了正确目录。

第三步，查上下文长度。如果前面聊了很久，模型处理能力槽被占满，技能指令就容易被“稀释”。这时候让用户开个新会话再调用，往往问题就消失了。

这条链路帮我解决了很多“时灵时不灵”的假象。每次看到技能异常，先别急着改指令，把这四步走一遍再说。

4.2 现象二：参数被吞掉，任务直接跑偏

参数解析问题是最隐蔽的一类坑，因为出错的不是模型，而是你设计技能时留下的歧义。

我发生过一个很典型的错误。设计会议纪要技能时，我写了一个attendees参数，说明是“参会人，逗号分隔”。实际调用时，我输入attendees=张三，李四，结果模型把“张三，李四”当成一个完整的人名，因为我的描述里既没说清用英文逗号还是中文逗号，也没给示例。最后生成的纪要我看了半天，“参会人：张三，李四”——就是说有一个叫“张三，李四”的人参加了会议。

这个问题的根源，是参数规范写得不够明确。修复方式也很简单，在参数描述里加上分隔符的硬性规定，再给一个示例。我在技能正文的“输入约束”一栏里加了一行：

attendees 参数：只接受英文逗号分隔的名称列表，示例：attendees=张三,李四,王五

从那以后，这个问题再没出现过。

处理参数问题时，还有一个通用原则：在技能里显式告诉模型，遇到无法解析的参数时应该怎么做。比如“如果用户输入的周期无法识别，默认使用本周，并在输出开头注明”。这比让模型自己猜测要稳妥得多。

4.3 建一个专属回归样本集，避免“改坏了好技能”

调试技能最大的风险，不是改不好，而是改好了 A 问题、搞坏了 B 功能。我早期就吃过这个亏，手痒把周报技能的口吻改得活泼了一点，结果三周后才发现，所有的量化指标都被模型顺手丢掉了。

后来我学到一个特别实用的方法：给常用技能建一个回归样本集。所谓回归样本集，其实就是一组固定的输入样本，每个样本带一个预期结果清单。每次改完技能，不需要实时聊天验证，直接把样本集跑一遍，检查输出是否符合预期。

比如周报技能的样本集包括：空日志、只有一条日志、日志全是会议记录、带明显量化数据的日志、用户要求只写本周的日志、用户上传了截图但没写文字的日志。每改一次技能，就用这六个样本跑一遍，任何一项输出跑偏，立刻就能发现，还特别容易定位是改坏了哪一行。

这个方法花不了多少时间，但效果立竿见影，尤其适合你维护了十几个技能之后再用。光靠脑子记住“之前是能用的”，那是对抗不了版本漂移的。

5. 从“我自己能用”到“别人也能用”：发布前的检查清单

技能开发到最后，大概率会面临一个问题：要不要把它分享给别人用。无论是同事、朋友，还是另一个设备上的自己，发布这件事都有一些经常被忽视的坑。技能在我自己手里运行得好，在别人手里翻车，这类事我见过太多了。

5.1 先写一份能力卡片，再谈分享

单独一个SKILL.md文件，对于作者本人来说是够用的，但别人拿到它，第一眼往往不知道这个技能该怎么用。所以我会建议，每个准备分享的技能，额外配一份能力卡片。它可以简单到只有几行：

技能名称：weekly-report 一句话说明：根据工作日志生成结构化周报 适用场景：每周五下班前，总结本周工作 输入参数：period（周期）、tone（口吻）、includeMetrics（是否含指标） 输出形态：Markdown 格式周报，三模块结构 已知限制：不包含跨项目汇总，不生成图表；需要用户提供原始日志

你会发现，写能力卡片的过程，也是倒逼自己梳理技能边界的过程。有时候写着写着就会发现，原来这个技能还有某些条件我没考虑过。那就在发布前先补上，而不是等别人踩坑了再修。

5.2 用版本化和同步习惯避免“我这能跑你那不行”

不同的工具对技能包的加载方式不太一样，有的需要你把文件夹放到指定目录，有的支持直接导入压缩包，还有的需要通过特定接口注册。发布之前务必确认清楚接收方的运行环境，不然就会陷入“我这儿明明没问题啊”的尴尬。

我自己的习惯是，维护技能的目录尽量纳入版本管理，每次改动写一条提交记录。版本号按1.2.0这样的语义化规则递增：功能新增升次版本，修复 bug 升补丁版本，破坏性变更升大版本。分享给别人时，直接发某个确定版本的完整目录，而不是“最新改过的那个文件夹”。

这一步听起来有点重，但对一个长期维护十几个技能包的人来说，是省心而不是费事。每次要改技能，我都能准确找到上一版在哪儿，这对定位回归问题非常有帮助。

5.3 发布前做一轮边界测试，把错误挡在门外

如果你的技能要发布给团队或朋友使用，先别急着铺开，先用最小范围做一轮灰度验证。找一两个人，让他们在不看你解释的情况下，只凭能力卡片和技能本身去调用，看能不能跑通。

这个过程几乎一定会暴露出问题：要么是参数描述不够清楚，要么是触发方式存在歧义，要么是某人用了偷偷加的中文标点把参数解析带崩了。没关系，这些都是可以在灰度阶段低成本修复的。等这些问题都修完，再放开给所有人用，后面基本就不会出现大规模翻车。

我在发布自己的第一批公开技能时，靠这个流程把三个明显缺陷挡在了门外。其中一个就是参数值本该是 “本周/上周”，但使用者输入了 “这周”，技能没能识别出来。修复方案是在参数说明里配上同义词映射，顺手把这个问题解决了。

开发各种 Skills 这件事，写到这儿，我的核心经验基本都交代完了。回头看，最开始吸引我的其实是“省事”，但真正做到后面才发现，它真正改变的是我和 AI 协作的方式。每一个技能都像是一个定义良好的接口，我不用每次重新解释需求，它也不用每次从零猜测意图。比较通用的建议是：不要怕第一个技能写得粗糙，先跑起来，再按我上面这套方法慢慢迭代。手里有几个趁手的 Skills 之后，你会慢慢发现，真正值得沉淀的并不是某一条指令，而是你对自己工作流的理解本身。