企业官网建设流程全解析

过去大半年，我几乎把所有重复性的AI协作流程都改造成了Skills。起因很朴素：我再也受不了每次开新对话都要重新粘贴一大段提示词了。分镜要贴分镜规则，写论文要贴论文规范，做前端要贴组件约束——贴完还得担心模型有没有真正遵守。把流程打包成Skill之后，模型在规划阶段就能发现“这里有现成的技能可用”，然后自己完成装载、执行和迭代。这个转变最让我意外的不是省了多少时间，而是Agent的行为方式真的不一样了：它不再是一个每次都要从头教的实习生，而是一个带着工具箱、知道自己该干什么的熟练工。

这篇文章写给两类人：一是被提示词工程搞得心力交瘁、想寻找更结构化方案的人；二是已经在用Claude或Codex但还没碰过Skills、想了解它到底解决了什么的人。我不打算泛泛讲概念，而是从第一性原理拆一下Skills在系统里到底做了什么，再拿我实测的Claude、Codex和开源社区方案做个横评，最后手把手带你把一个可用的分镜Skill从零搭出来。全程都是真实操作，踩过的坑也会讲清楚。

1. 一个看似轻量的功能，为什么能改变Agent的使用方式

1.1 从“复制提示词”到“技能装载”的范式变化

先说说我之前的工作流有多蠢。做动漫分镜的时候，我有大概两千字的分镜规范，包含景别定义、运镜规则、台词格式、情绪标注方式。每次开新对话，第一件事就是把规范贴进去，然后再贴小说原文，再补一句“按上述规范输出分镜”。这中间有大量的重复劳动，更麻烦的是模型经常“贴完就忘”——对话一长，它就开始自己发挥，景别叫法混乱，台词格式变形，最后我还要人工改一遍。

这个问题在写论文、做前端组件、做数据分析时一模一样。你每次都要重新解释背景、规则、输出格式，而模型每次都是“第一次听说”。如果把这些东西固化成文件，让模型在需要的时候自己去读、自己去遵守，情况就完全不同了。Skills解决的就是这个：它把规则、示例、工作流程打包成一个可命名的单元，模型通过一段简短的描述就知道“这个技能是干什么的、什么时候该用”，然后自动把对应的指令和资源加载进来。

我用一个很糙的类比来理解它：普通提示词是“你每次给临时工手写一份作业要求”；Skills是“你给这个员工发了一本岗位手册，他上岗前自己翻”。前者靠你重复劳动，后者靠系统结构化。

1.2 Skills不是插件，也不是MCP，它到底算什么

很多人第一次接触Skills会陷入一个误区：把它当成插件或者MCP（Model Context Protocol）的替代品。我一开始也这么想过，后来实测下来发现根本不是一回事。我做了个简单的对比：

这个表格想说明一件事：MCP解决的是“Agent能碰到什么”，Skills解决的是“Agent知道该怎么干”。前者是触手，后者是大脑里的工作程序。两者可以配合，比如Skill里可以规定“需要查天气时调用weather MCP工具”，但就算没有MCP，一个纯指令型Skill也完全能工作。

想通这一点之后，我对Skills的定位就清晰多了：它是Agent行为塑造层的东西，而不是工具集成层的东西。这个认知直接影响了我后面做Skill时的设计思路——我该重点打磨的是规则、流程和示例，而不是纠结要不要给它挂个API。

2. 第一性原理拆解：Agent Skills究竟在系统里做了什么

2.1 声明式元数据驱动的能力发现机制

Skills底层依赖一个很关键的设计：Agent在规划阶段会扫描所有可用的Skill，根据描述信息判断当前任务是否匹配。所以SKILL.md开头的YAML元数据（name和description）不是摆设，它是整个技能发现机制的入口。

我见过不少人写description写得特别随意，比如“用于生成分镜脚本”。这句话对模型来说信息量是不够的。模型是在什么场景下会考虑用这个技能？如果用户只是想简单描述一个画面，该不该触发？如果用户给了一整本小说，该不该触发？我在实测中总结出，一个好的description应该包含：触发场景、输入要求、输出承诺。比如：

--- name: storyboard-generator description: 当用户提供小说章节、剧本片段或叙事性文字，并希望转换为分镜脚本时使用。输入需要包含场景发生的段落；输出为结构化分镜表，含景别、运镜、台词、情绪标注。 ---

这样模型在读到用户消息时，就能比较准确地判断“现在是不是该调用这个技能”。description写得太宽，模型会在不该用的时候强行用；写得太窄，模型又会错过该用的时机。这个度需要反复测试，我后面会详细讲。

2.2 指令注入的深度：模型是怎么被“改变”的

当模型决定使用某个Skill时，SKILL.md的正文部分会被注入到模型的上下文里。这个注入不是简单叠加一段用户消息，而是作为一种类似系统指令的存在，影响模型后续的推理和行为。这意味着，Skill对你的整个工作流有持续的约束力，而不是像普通提示词那样贴完就淹没在长对话里。

我做了个小实验来验证这个差异：同一个对话里，我先用普通提示词定义了一种输出格式，然后聊了十几轮无关话题，最后再让它按那个格式输出——结果格式已经歪了。但我在Claude里装了一个Skill，同样聊了十几轮，再触发相关任务时，模型输出的格式和规范依然稳定。原因就在于Skill的指令在上下文中的权重与普通用户消息不同，它更像一层常驻的“职业素养”。

这个特性非常实用，尤其是做长流程任务时。比如用Codex写论文，从摘要、引言到结论，中间要经过很多轮对话，如果靠普通提示词约束，早就在某一步就跑偏了；但打包成Skill后，模型全程都记得“自己是按学术写作规范工作的”，章节结构、引用格式、论证节奏都会保持一致。

2.3 资源文件与few-shot示例：让技能可复用

SKILL.md解决的是“规则”问题，但如果只有规则，模型很多时候还是不知道“好”的标准是什么。这时候就需要资源文件。我习惯在Skill目录下放一个resources文件夹，里面装模板、术语表、范例输出。模型在需要时会主动去读这些文件，相当于给了它几个高质量的参考样本。

这其实就是few-shot的思想，只不过不再局限于对话上下文里塞几条示例，而是以文件形式挂在技能背后。我做个分镜Skill时，在里面放了一份完整的分镜表模板和一篇示例输出。实测效果非常明显：没有示例时，模型输出的分镜表虽然格式对，但镜头之间的逻辑衔接很差；有了示例后，它学会了按“场景建立→人物动作→情绪特写→节奏切分”的顺序来组织镜头，输出质量直接上了个台阶。

2.4 从被动到主动：Agent形态的关键变化

前面说的都是技术机制，这一节我想聊一个更抽象但很重要的变化：Skill会让Agent从“被动响应”变成“主动提案”。

以前用聊天式AI，流程完全由用户主导，你问一句它答一句。但当你装了一批设计良好的Skill后，模型开始学会“抢活”了。比如我给它一段小说原文，它会先判断这个场景需要什么风格的分镜，然后主动说“检测到这是一段高情绪冲突场景，建议使用storyboard-generator技能，并突出节奏切分”。它不再只是回答你的问题，而是像一个真正的工作伙伴在提方案。

这个变化是怎么发生的？我理解是Skill的description给了模型一个“能力清单”，而长对话给了它上下文，让它可以结合两者做规划。当模型发现自己手里的工具正好匹配用户需求时，它就会进入“技能应用模式”。对于重度用户来说，这个变化的意义很大：你不需要再精确地发号施令，只要给出原始材料，Agent自己会知道该用哪把刀。

3. 实测横评：Claude、Codex与GitHub上开源方案的真实差异

3.1 Claude官方市场与本地安装实测

Claude的Skill生态是目前最成熟的，官方市场里已经有不少经过验证的技能可以直接装。安装流程很顺：在Agent配置界面进入技能市场，找到合适的Skill，一键安装，然后就能在对话里触发。我装了官方推荐的数据分析类和文档处理类Skill，体验还算稳定。

不过我更推荐关心行为的工程师自己去写Skill，而不是完全依赖市场。官方市场的Skill为了通用性，通常会把规则写得比较宽泛。比如市场里某个分镜Skill，它对景别的定义就是标准术语，但如果你所在团队的规范里有一套自己约定俗成的叫法，比如“大特写”和“微距镜头”的区别，官方Skill就没法满足。这种时候，自建Skill的成本很低，收益反而更高。

如果你用的是Claude官网或者桌面端，本地安装Skill其实就是建一个文件夹的事：在配置目录下新建一个以技能命名的文件夹，里面放SKILL.md和resources，然后在配置里声明这个技能目录的位置。我第一次建的时候还担心要做各种注册，结果发现根本不需要——只要文件结构对了，Agent会自动扫描到。

3.2 Codex Skills：工程化工作流的正确用法

Codex的Skill机制和Claude类似，但因为它更侧重代码场景，我在里面跑的Skill主要以开发规范为主。我做了一个前端开发Skill，里面规定了组件命名规则、样式方案、测试要求。以前我给Codex描述一个页面需求，它写出来的代码风格和团队既有代码总有出入；装上Skill之后，它生成的组件从命名到目录结构都符合团队规范，直接被代码审查放行的概率高了很多。

写论文的Skill我也在Codex里试过。它的目录下放了一个academic_writing_guide.md，内容包含论文结构、引用格式、论证逻辑检查清单。我最喜欢的一个细节是：Skill里的资源文件会要求模型在生成每一章之后先自我检查一遍逻辑链，再输出给用户。这个“在输出之前先反思”的步骤，虽然看起来只是多了一道指令，但对学术写作的提升是实打实的——至少模型不会再给我生成那种“火车跑着跑着突然拐进一条岔路”的论证了。

Codex的Skills存放路径一般是在用户目录下的.codex/skills文件夹里，每个技能一个子文件夹，同样是SKILL.md加资源的组织方式。如果你之前配过Codex的AGENTS.md或者项目规则，你会发现Skills其实就是一种更细粒度、可组合的“按需加载规则”，两者搭配使用效果很好。

3.3 GitHub生态：从分镜到安全测试的典型样本

GitHub和各类下载平台上已经冒出来大量成熟Skills，我大致扫了一圈，按使用热度排个序的话，大概是：开发效率类、内容创作类、数据分析类、安全测试类。其中分镜类Skills的火爆程度超乎我预期，可能是最近动漫和短剧创作人群涌进来的原因。这些Skill的思路基本一致：把分镜规则、景别定义、镜头语言术语打包，让模型把文字内容自动拆解成可视化分镜。

“自动挖洞”方向的Skill也很有代表性，当然这里说的不是那种不分青红皂白乱扫的工具，而是把漏洞挖掘流程规范化的技能。GitHub上有个项目把资产收集、指纹识别、漏洞验证这几个阶段用SKILL.md串联了起来，模型会按阶段推进，每个阶段结束还会输出一份结构化的测试报告。这种安全方向的Skill和普通业务Skill有个很大的不同：它必须有严格的范围判定和授权校验逻辑，否则模型容易在错误的场景下做出危险动作。我也会在下一节讲，写这类Skill时，安全边界要先写进SKILL.md的第一条规则。

3.4 我实测下来踩过的几个Key坑

第一坑是description写得太泛导致乱触发。我给某个通用写作Skill写的描述是“帮助用户写作”，结果模型在用户要求列购物清单的时候都去调用它，反而把输出格式搞复杂了。后来我把描述改成了“当用户需要撰写长文、需要结构化段落和连贯修辞时使用”，误触发率明显下降。

第二坑是Skill里塞了过多指令导致模型“精神分裂”。我一开始追求大而全，把几十条规则都写进一份SKILL.md，结果模型的输出变得僵硬，每句话都像在照着规则念稿。后来我把指令精简到核心10条以内，把细节放进resources里让模型按需阅读，效果反而好了很多。核心逻辑是：指令文件负责引导方向，资源文件负责提供深度，别把两者混在一起。

第三坑是安装位置不对导致技能根本没被识别。Claude和Codex扫描的目录是固定的，如果你把Skill文件夹放错地方，它不会报错，但你的Skill永远也不会被加载。遇到“装了但完全没效果”的情况，第一件事不是检查内容，而是检查目录路径。

4. 手把手实现一个真正可用的Skill（分镜生成全流程）

4.1 定义一个不宽不窄的Skill边界

很多人第一次动手做Skill，最容易犯的错误就是边界不对。我以分镜Skill为例，讲讲怎么定义边界。

你希望这个Skill处理什么样的输入？是小说章节还是短视频脚本？这两者的分镜逻辑完全不同——小说需要先做场景抽取和人物状态分析，短视频脚本更多是逐镜头的文字转译。如果把两者混在一个Skill里，模型会陷入“到底按哪套逻辑来”的纠结。我第一次做的时候就把两者混了，结果模型生成的镜头序列很不稳定。

正确的做法是先聚焦一个场景。我做的第一版只处理“小说章节转动漫分镜”，输入是连续的叙事段落，输出是带镜头编号、景别、运镜方式、角色动作、台词和情绪标注的分镜表。等这个版本跑稳了，再扩展第二个场景。Skill的迭代和软件一样，先做单点穿透，再做横向覆盖。

4.2 SKILL.md核心配置逐行拆解

下面是我实际在用的一个SKILL.md的结构，我把核心部分剥出来讲一下设计意图：

--- name: storyboard-generator description: 当用户提供小说原文、剧本片段或叙事性文本，并希望生成动漫分镜脚本时使用。输入应包含需要分镜的具体段落；输出为结构化分镜脚本，包含镜头编号、景别、运镜、角色动作、台词、情绪标注。 --- # 动漫分镜脚本生成 你是一名资深动漫分镜师，擅长将叙事文本转化为符合影视节奏的分镜脚本。 ## 工作流程 1. 阅读输入文本，提取场景、角色、情绪基调。 2. 根据情绪节奏决定镜头切分密度：平静场景3-5个镜头，情绪高潮场景可适当增加镜头数。 3. 输出分镜脚本，每个镜头严格遵循下述字段结构。 ## 输出格式 | 镜头号 | 景别 | 运镜 | 画面内容 | 角色动作 | 台词 | 情绪标注 | |---|---|---|---|---|---|---| | 1 | 全景 | 缓推 | 黄昏的街道 | 主角独自行走 | （无） | 孤独、压抑 | ## 硬性规则 - 景别只能用：大远景、远景、全景、中景、近景、特写、大特写。 - 运镜只能用：推、拉、摇、移、跟、升降、手持、固定。 - 情绪标注必须使用1-2个情绪词，禁止情绪描写句子。

关键设计有两个。第一，description里明确写了输入和输出，模型在规划阶段就能精准判断是否调用。第二，硬性规则控制了输出格式的“枚举范围”，这样无论怎么跑，模型都不会编出第三种景别叫法。表格结构比自然语言描述更约束模型，强烈建议能用表格定义的格式就用表格。

4.3 资源文件与示例设计

SKILL.md本身可以把规则说清楚，但“做得像不像资深分镜师”靠的是resources里的示例。我的目录结构长这样：

storyboard-generator/ ├── SKILL.md └── resources/ ├── shot_list_template.md ├── camera_terminology.md └── examples/ └── sample_storyboard.md

shot_list_template.md是空表模板，模型可以拿着它直接填空；camera_terminology.md里补充了一些进阶的镜头运用说明，比如“手持镜头适合表达慌乱感”“缓推适合制造压迫感”，这些不在SKILL.md里写死，否则指令太长；sample_storyboard.md则是我手工打磨的一个完整示例，包含8个镜头，展示从平静到高潮的节奏变化。我实测下来，模型在读取示例后，对节奏的把控明显比只读规则要好，它学会了在情绪转折时主动切近景和特写。

这里有一个细节：示例不要给得太“完美”。我给过一个满分示例，结果模型每次输出都往这个示例的结构上硬套，场景一变就显得生硬。后来我放了三份不同节奏的示例（慢节奏文戏、快节奏动作戏、内心独白戏），模型就有了更丰富的参考空间，输出适配性上升不少。

4.4 测试迭代与常见翻车现场

装好Skill之后一定要先做一轮边界测试。我会准备三组输入：一段日常对话文本、一段符合Skill目标的叙事段落、一段介于两者之间的模糊文本。第一组的预期是“不触发Skill”，第二组是“正常触发并高质量输出”，第三组看它会不会误判。

我第一轮测试时翻了个车：一段用户闲聊的口语化文字触发了分镜Skill，模型给一段日常聊天配了8个镜头，非常滑稽。问题出在description里“叙事性文本”这个词太宽，聊天记录也是叙事。后来我把描述改成“用户提供小说章节、剧本片段等文学性叙事文本，且明确表示需要生成分镜时使用”，把触发场景收紧到带文学属性的输入，误触发才降下来。

迭代时不要只改文字描述，必要时要改示例文件。我发现模型特别喜欢模仿示例里的第一句话开头，所以我刻意让三份示例的开头方式不一样，防止输出产生固定套路。另外，如果你修改了SKILL.md，有些平台需要重启会话或者重新加载技能才能生效，别改完发现没变化就以为写错了。

5. Skills的边界、局限与下一步创作空间

5.1 选型判断：Skills、MCP、还是普通提示词

用了大半年Skills之后，我形成了一个简单的选型判断逻辑。

如果任务是一次性的，比如“帮我写封邮件”“解释一下这个概念”，普通提示词就够了，没必要建Skill。如果任务需要模型连接到外部系统、读写数据库、调用API，那该上MCP而不是Skills。如果任务是“一类工作”，有固定的规则、流程、输出格式，且你会反复做，那就值得做成Skill。还有第三种情况：任务既需要规则又需要外部数据，那就Skill加MCP组合，Skill负责行为约束，MCP负责能力供给。

拿我做论文Skill的经验来说：论文写作本身不需要外部系统，纯规则和示例就能搞定，所以一个纯Skills方案就够了。但我的竞品分析Skill就挂了MCP，因为它需要实时抓取资料，Skill部分负责分析框架，MCP部分负责搜数据。这个组合是目前我认为最优雅的Agent工作流组织方式。

5.2 我总结的五条经验法则

第一条：description比正文重要，花时间打磨触发条件，永远值得。一个触发精准但内容普通的Skill，比一个乱触发但内容精良的Skill有用得多。

第二条：Skill是“写给别人看的文档”，你要想象自己是那个第一次接触这个技能的模型，按照你写的说明书能不能做到位。写完后隔几天再读一遍，最能发现问题。

第三条：把规则分级。SKILL.md只放硬性规则和流程，柔性的经验、参考案例、扩展内容都放到resources里。混合在一起的结果就是模型的选择困难症。

第四条：版本管理要跟上。我吃过只改不记的亏，改了好几版SKILL.md之后都不知道哪个参数导致的输出变化。现在我会记录每次改动的原因和效果，这个清单比Skill本身还值钱。

第五条：多把Agent行为当作产品去打磨。Skills不只是技术方案，它是你给Agent立的工作规矩的综合体。好的规矩让Agent成为一个可靠的伙伴，坏的规矩让Agent变成一个听话的笨蛋。

5.3 下一步的创作空间

Skills现在还在很早期的阶段，官方市场、第三方平台都还像最开始的应用商店一样品类稀少。我比较看好的几个方向：一是垂直行业的Skill套件，比如医疗科普、法律文书、教育培训这类有行业规范的内容；二是“Skill组合”设计，通过多个Skill串联出一个完整流水线；三是个人知识库与Skills结合，把你的个人经验沉淀成可复用的行为模板。

我自己接下来的计划是把手头已经验证过的分镜、论文、前端组件三个Skill整理成一套“创作者工作流”，并在GitHub开源出来。我始终觉得，AI时代最值钱的不是模型，而是你教模型怎么干活的那一套方法论。Skills恰好就是这套方法论的载体，这也是我愿意花这么多篇幅来拆它的原因。

最后说点个人体会。从最初手动粘贴提示词，到如今各平台里躺着一排我亲手做的Skill，这种改变带来的不仅是效率提升，更是心态上的变化——我现在更愿意把复杂的、专业的事情交给Agent去做，因为我知道它的行为方式是被我定义过的，而不是每次都在自由发挥。如果你还没试过自己动手写一个Skill，我强烈建议你从手头最重复、最标准化的那个任务开始，把它变成你的第一个Skill。做成功的那一刻，你会觉得之前的提示词工程都白干了。