企业官网建设流程全解析

1. 从“什么都能干”到“干得漂亮”：Skills机制的前世今生

1.1 大模型“会说话”不等于“会做事”

如果你最近玩过Claude Agent、Codex这类编程智能体，大概会有一种奇妙的感觉：同一个模型，在A手里是“神队友”，写代码条理清晰、改Bug一针见血；换到B手里就变成“新手实习生”，问一句答一句，你不催它就不动，甚至会在同一个错误上反复打转。模型还是那个模型，差距出在哪儿？

我的答案是：差距不在模型，在人。更准确地说，在“人有没有给Agent准备好一套趁手的Skills”。

这里说的Skills，不是简历上写的“熟练掌握某某技术”那种个人能力，而是近半年在AI Agent圈子里快速火起来的一个特定概念——给Claude Agent、Codex这类编程智能体准备的“技能包”。它本质上是把一套可复用的方法论、操作流程、脚本模板打包成结构化文件，放进项目的skills目录里。Agent在执行任务时会像翻参考手册一样读取这些文件，照着你定好的流程去思考、去调用、去输出。

社区里有篇很火的文章叫《Claude Agent Skills: A First Principles Deep Dive》，标题起得挺学术，读完你会发现核心就一句话：Skills是对“模型能力”和“任务结果”之间那道鸿沟的工程化填补。我自己最初看到这个词组时，第一反应是“这不就是预设Prompt吗”，但真正用了一段时间、自己也动手写过几个Skills之后，才意识到这里面的设计思路比单纯写Prompt深得多。

我们得承认一个现实：大模型本质上是一个“会说话”的系统，它擅长的是生成看起来合理的文本，而不是稳定地执行一套流程。哪怕你告诉它“先分析需求，再写代码，最后跑测试”，它也可能因为上下文太长而把中间某一步漏掉，或者因为某句话说得不够明确，就自己发挥发挥走偏了。Skills要解决的，正是这种“漫谈式执行”的不稳定性——它把一套过程固化下来，让模型每次启动任务时都能回到同一条轨道上。

1.2 与Prompt、MCP的分工边界

聊Skills之前，得先把几个容易混的概念捋清楚。这段时间社区里讨论Agent的人很多，但很多朋友把Prompt、MCP（Model Context Protocol，模型上下文协议）、Skills混在一锅粥里煮，聊着聊着就乱了。我自己的理解是这样的：

• Prompt是“对话策略”：你告诉模型“你是一个资深前端工程师，请帮我写一个React组件”，这是在当下这一次对话中调整模型的姿态。它的作用是临时的、上下文相关的，换一个会话就得重新说。
• MCP是“能力接口”：它解决的是模型“能不能调用外部工具”的问题，比如读文件、查数据库、调API。MCP定义了工具长什么样、参数怎么传，但没规定“先调哪个后调哪个”，也没规定“调用完怎么决定下一步”。
• Skills是“业务方法论”：它解决的是模型“知道该怎么做才靠谱”的问题。Skills里既包含流程指引，也可以捆绑相关的脚本和模板，让模型在需要时能按步骤执行。

打个不那么严谨但很好懂的比方：Prompt像是给一个刚入职的顾问做briefing，告诉他客户是谁、目标是什么；MCP像是给他配齐了电脑、电话、打印机这些办公设备；Skills则是把公司沉淀下来的“项目交付SOP”递到他手里，告诉他“按照这个流程走，你能少踩很多坑”。三者各管一段，谁也替代不了谁。

明白了这层边界，再去看Skills的设计，很多困惑就迎刃而解了——为什么Skills要放在项目目录里而不是写进系统提示词？因为它要跟着项目走，换一个项目就是换一套SOP，而不是靠人肉复制粘贴。为什么Skills里要允许捆绑脚本？因为有些流程本来就该用代码固化，比如解析一个JSON、调用一个API，让模型现场写太不稳定，不如直接给它一个写好的工具。

2. 拆开Skills的“黑盒”：目录结构与核心文件解析

2.1 一份典型Skills的目录长什么样

要说清楚Skills怎么用，最直接的办法就是拆一个真实的包看看。我这边有一份自己常用的Skill，名字叫analyze-doc，功能是帮我对项目里的技术文档做结构化审读。它的目录结构长这样：

analyze-doc/ ├── SKILL.md └── scripts/ └── extract_sections.py

就这么简单？对，就这么简单。一个Skills包的核心只有一个SKILL.md文件，剩下的都属于可选增强项。SKILL.md是技能的主控文件，Agent会优先读取它；scripts/目录用来放一些配套的脚本，模型在需要时可以调用这些脚本来辅助完成任务。

SKILL.md本身由两部分组成：开头是YAML格式的frontmatter元信息，正文是给Agent看的操作指引。我见过不少朋友第一次接触Skills时，拿过来一个包会习惯性地去翻里面的代码，这其实搞反了——对Agent来说，SKILL.md里的自然语言描述才是最重要的，脚本只是执行细节的补充。

2.2 SKILL.md的frontmatter与正文怎么写

SKILL.md的frontmatter不像写Jekyll博客那么简单，它里面的字段都有明确的语义。我对照官方文档和自己踩过的坑，把常用字段整理成了一张表：

正文怎么写，其实没有统一模板，但有两条经验我觉得放之四海而皆准。第一，用“步骤化”的语言描述流程，别用散文；第二，多用“验收标准”约束输出，别只说“分析一下”就完事。

拿我自己写的analyze-doc的正文举例，核心段落大概是这样的：

# 分析目标 - 提取文档中的核心观点，按优先级排序 - 标出至少3个可用数据支撑的论点 # 参考实现 1. 使用 scripts/extract_sections.py 解析文档结构 2. 对每个章节执行以下检查： - 是否有明确的小标题 - 论点与论据是否对应 3. 输出一份Markdown报告，包含：章节树、问题清单、优化建议

你会发现正文里有一个很关键的小设计——# 参考实现。这个叫reference implementation的段落，在Skills机制里承担着“两段式控制”的作用：它告诉Agent“这个流程是参考路径，你可以按它执行”，而不是“你必须一字不差地照做”。这样做的好处是：既给了模型足够的引导，又保留了它在实际执行时做局部调整的灵活性，避免流程僵化到没法用。

2.3 为什么用“参考实现”而不是“必须执行”

这里头有个挺值得琢磨的设计哲学。如果Skills把每一步都写死，一旦实际场景和设计时的假设稍有出入，Agent就被卡住了；但如果不给流程，Skills又退化成普通Prompt，失去了约束力。“参考实现”这个定位，本质上是把人机协作的分寸感做进了规范里。

我在写第一个Skills的时候吃过亏。当时我写了一个“代码安全扫描”技能，把每一步检查点列得特别细，比如“第1步：检查SQL拼接；第2步：检查文件上传；第3步：检查越权接口……”结果实际跑起来，Agent到了第2步就开始机械地往报告里堆东西，完全不会根据代码库的情况做取舍。后来我改成“参考实现”的写法，把步骤作为推荐路径而不是死命令，同时在末尾加了一句“如果检查中发现与上述步骤无关但明显异常的内容，请补充记录”，执行效果一下子就好起来了。

这个细节也让我更认同社区里的那句总结：Skills的定位不是“让模型变成自动化流水线”，而是“让模型在挂载了方法论之后，变成更有经验的操作员”。你要给模型一个框架，而不是一条铁轨。

3. 手把手开发一个“分镜写作文”Skills

3.1 为什么选择“分镜写作文”这个案例

前面讲了不少概念，光说不练容易让人心里发虚。这一节我拿一个真实场景走一遍全流程——开发一个叫storyboard-essay的Skills，专门用来写“分镜式作文”。我选的这个案例有三个考量：第一，它不需要依赖任何外部服务，只要一个文本模型就能跑，适合新手完整跟下来；第二，分镜这个概念不只在写作里用，拍短视频、做PPT、写营销文案都用得上，推理路径可以移植；第三，它相对容易出效果，写完你能比较直观地感觉到“挂技能”和“不挂技能”的差异。

什么叫分镜式作文？简单说，就是先建立“分镜表”——每个镜头里有画面、有动作、有情绪，再把分镜转写成文字段落。它的好处是让文章天然有画面感，告别“流水账”。传统写法和分镜式写法的差异，本质上是从“线性叙述”变成“视觉化构建”，文章的层次感和节奏感会明显不一样。

我这个Skills的设计目标是：给定一个作文题目，Agent能先输出分镜表，再输出完整的成文。分镜表最少8个镜头，每个镜头要包含场景、动作、细节。更重要的是，我要让它避免“套用万能作文模板”的油腻感，所以在流程里专门加了一步“针对题目关键词做意象联想”。

3.2 搭建目录与编写SKILL.md

我先把目录建出来：

mkdir -p storyboard-essay/scripts cd storyboard-essay

然后编辑SKILL.md。先说frontmatter，我实际用的是：

--- name: storyboard-essay description: 根据给定命题，先规划分镜再撰写带画面感的叙事作文。适用于语文作文、创意写作、故事创作等场景。 ---

注意我的description里没有写“写作文”这种笼统的词，而是写了“分镜”“画面感”“叙事”这些可以匹配任务场景的关键词。经验告诉我，Agent对“什么时候该用这个技能”的判断，主要靠description做语义匹配——你要是写得太泛，模型容易在不需要的时候也去调它；写得太窄，该用的时候又不会触发。

正文部分，我完整贴出来供参考：

# 目标 针对给定的作文题目，生成一篇不少于800字的叙事作文，核心特征是“有画面感”。 # 参考流程 1. 提取题目关键词，列出3个可用的核心意象。 2. 设计分镜表，不少于8个镜头，每个镜头包含： - 场景设定：时间、地点、环境气氛 - 主体动作：画面中的核心动态 - 细节点缀：一个可被“看见”的小细节 3. 检查分镜的逻辑连贯性：镜头之间是否有转折或递进？如果没有，调整顺序。 4. 根据分镜表逐镜头撰写正文，禁止直接罗列分镜内容。 5. 输出后检查：是否每个镜头都对应到了正文中的一段？未对应的，在定稿前补充。 # 验收标准 - 全文没有“首先”“然后”“最后”式流水账连接词。 - 至少有2处用五感描写（视觉之外的听觉、嗅觉、触觉等）。 - 结尾要有意象回扣，而非空泛抒情。

写完SKILL.md，我顺手加了一个scripts/generate_outline.py，作用是帮你把分镜表转成初步的内容提纲。这个脚本并不复杂，几十行就能完成——主要是为了演示“Skills可以带脚本”这件事。虽然这段脚本会让Skill包体积变大，但对于需要固定格式输出的场景，这种提取细节的思路真的能让输出稳定很多。

3.3 安装、注册与验证

目前主流的安装方式是把Skills目录放进项目的.claude/skills/目录下，比如：

my-project/ ├── .claude/ │ └── skills/ │ └── storyboard-essay/ │ ├── SKILL.md │ └── scripts/ │ └── generate_outline.py └── ...

装完之后怎么验证？我习惯的做法是开一个干净的新会话，只给出一句话：“请用storyboard-essay技能，以‘雨天的站台’为题写一篇作文。”然后观察两个东西：第一，模型有没有主动引用SKILL.md里的内容；第二，生成的文章是不是按分镜结构展开的。如果模型无视技能直接开写，那多半是description写得不够清晰，或者目录放错了位置。

如果模型确实读了技能但效果不理想——比如分镜表只列了5个镜头，或者正文段落和分镜对不上——那八成是“验收标准”写得不够细，需要再补几条更明确的硬约束。这个“写技能、跑一次、改描述”的循环，我每个技能至少会调三轮以上，急不来。

3.4 调试Skills时最容易忽略的三件事

第一，SKILL.md的排版一定要干净。模型解析Markdown的能力很强，但你如果把它写得层层嵌套、标题乱跳，模型提取要点时也会“读晕”。标题层级清晰、每段落短小精悍，是让模型快速吃透流程的关键。

第二，别把大段示例文本堆在步骤里。有些朋友写Skills时特别“大方”，每个步骤下面都贴一大段示例代码，结果是技能文件动辄几百行，模型读起来费劲，还会干扰它对本项目上下文的注意力。示例是用来定向的，一个步骤最多一个，点到为止就够了。

第三，脚本的报错信息要友好。Skills里捆绑的脚本可能被模型在“非预期场景”下调用，如果脚本报了看不懂的错，模型会卡在那个错误上反复兜圈子。我现在的习惯是：脚本被不满足前置条件时，直接给提示“请检查输入格式后再调用”，让模型能自己纠错往下走。

4. Skills从哪里找：官方市场与第三方下载平台

4.1 官方渠道与正规安装

聊完自己开发，再说说怎么“借力”。现在Skills的生态已经比半年前热闹多了，各类下载平台和合集像雨后春笋一样冒出来。我这里只谈正规渠道，避免水货和隐私风险。

官方层面，Claude现在做了Skills的官方市场等分发渠道，你可以在受支持的环境里直接浏览、安装社区提交的Skills，也可以把别人分享的Skills包下载后放进项目目录使用。官方渠道的好处是有人审核、规范统一，踩雷概率低。

GitHub上也有几个组织在维护Skills合集，比如Anthropic官方组织下就有不少参考实现，另外editors和社区维护的awesome-claude-skills这类列表也值得关注。我找新技能的固定动作是：先逛官方市场，再刷GitHub的awesome类列表，最后才去看个人博客或社交平台上的零散分享。

4.2 第三方平台与社区合集

除了官方渠道，这几年也冒出了不少第三方的Skills下载站和导航站。有的是把GitHub上的Skills包做了索引和分类，有的直接提供“一键安装”的功能。这类平台的价值在于聚合搜索方便——你用关键词“分镜”“论文”“代码审查”一搜，就能找到好几个待选项。

得提醒一句：第三方平台鱼龙混杂，下载之前务必做几个检查。第一，优先选有源码链接、可以直接看内容的包；第二，警惕那些声称“效果神奇”但SKILL.md写得稀烂的包，原理上讲效率不会好到哪里去；第三，凡是要求你填入私密token、API Key的Skills，建议直接拉黑。我用第三方平台下载的一致性准则是：不管发布者吹得多猛，拿到手先看SKILL.md的质量，再决定要不要用。

4.3 试技能的“三无原则”

我自己的习惯是，不管从哪个渠道拿到一个新技能，第一轮试用都按“三无原则”来：无隐私、无脏数据、无长链调用。

“无隐私”很好理解——不要在真实项目里试，建一个临时目录，放点脱敏数据再测。“无脏数据”是说输入数据用干净的样例，免得测试失败时说不清是技能的问题还是数据的问题。“无长链调用”是我后补的一条：先给一个尽量简单、不需要调用外部服务的任务，验证主流程能跑通，然后再叠加脚本、API之类的外部依赖。如果一个技能在主流程跑通之前就搞出一堆外部调用，出问题时排查成本会比较大，划不来。

我还遇到过一种情况：同一个技能，在A环境跑得好好的，换到B环境就“失灵”。后来排查发现是环境变量和依赖没对齐——比如脚本里用了某个Python库，在A环境装了，在B环境没装。所以拿到带脚本的Skills，检测一下依赖是否齐全，再谈“好不好用”这个命题。

5. Skills常见问题与排查实录

5.1 技能加载了但“没生效”怎么办

这个问题我在各种群里见过的频率最高：用户明明把Skills放进了目录，但模型跑起来完全不理会，文章还是按老套路写。遇到这种情况，别急着怀疑人生，按顺序排查这三件事。

第一，检查路径。Claude Agent读取的是.claude/skills/目录，Codex则有自己的约定目录——不同工具读的路径不一样，放错位置等于白放。确认一下你的工具到底认哪个目录，别把Skills放在外层让它找不到。第二，检查description。我刚说过，模型是用description做语义匹配来决定是否使用技能的，如果你的description写的是“关于写作文的方法论”，模型在半路可能根本意识不到“现在该用这个技能”。改成“当用户要求撰写带有画面感的作文时使用本技能”这类带触发场景的描述，效果会好很多。第三，检查“亲和力”问题。当前主流方案会根据描述与用户请求的相关度来决定是否触发某个技能，有些框架还允许在对话里指定强制启用。实在不行，在对话里直接说“请使用storyboard-essay技能”是最稳妥的触发方式。

5.2 技能包太大会拖慢响应吗

会，而且影响不小。每次Agent启动时都会把相关技能的内容读入上下文，你的技能包越大、SKILL.md越长，占用的上下文token就越多，留给实际任务的空间就越小。这就像在对话窗口里塞了一大段说明书，模型要一边读说明书一边干活，响应速度和输出质量都会受影响。

我的建议是：单个SKILL.md控制在几十行以内，能表达清楚流程就行。长内容应该拆到脚本或参考文件里，让模型按需去查，而不是一股脑全塞进去。用这个方法，我能让技能的上下文开销降到很小，同时保持完整的方法论结构。

另一个容易被忽略的点是：不是每个会话都需要加载全部Skills。尽量只保留当前项目真正需要的技能，把不常用的移到仓库根目录外的存档区，需要时再挂回来。这样能显著改善长对话场景下的体验。

5.3 真实场景中的“自动挖洞”与权限边界

搜索热词里有个“自动挖洞skills”，这里必须把边界说明白。安全测试类的Skills（比如自动探测漏洞、检查注入风险等）确实存在，而且效果不俗，但它的适用范围有严格前提——只能在你自己拥有授权的系统、测试靶场、CTF竞赛环境中使用。未经授权的探测行为在任何地区都属于违规操作，这不能被当成“炫技”的理由。

如果你对这类技能感兴趣，建议从CTF靶场或自己搭的测试环境练起。很多平台提供合法的漏洞靶场镜像，在里面跑技能既安全又能学到东西。用这种“合法靶场”的方式去接触技术，比任何“快捷方法”都稳妥得多。

5.4 技能使用频率不高、效果不稳定怎么办

有些Skills你写的时候脑子里是“星辰大海”，实际用起来却发现触发率低、输出质量飘忽。我的经验是：不是技能机制不行，是你选的场景不适合固化。

适合做成Skills的任务，需要满足两个条件：第一，流程相对固定，有明确的“怎么做”路径；第二，会重复发生，值得为此沉淀。反之，那些高度依赖当下对话情境、每次变化都很大的任务，靠Prompt临场发挥反而更好。

所以我现在对Skills的态度是“宁缺毋滥”。与其收藏一堆技能包，不如针对自己最高频的3到5个任务场景，认真打磨出几个真正好用的Skills。收藏夹吃灰的技能，和不存在没什么区别。

6. 写给想入坑Skills的你：一点个人心得

6.1 开发Skills的技术门槛不高，难点全在“定义问题”

我见过不少开发朋友问：“Skills的开发是不是需要精通底层Agent框架？”我的回答是：不需要，但需要你能把一个问题场景拆得很清楚。

Skills的技术骨架无非是Markdown加几个YAML字段，加一点脚本辅助，本质上是个“结构化文档”工程。真正考验人的是第一个环节——定义问题。你得想明白：你希望模型在什么场景下、按照什么流程、产出什么格式的结果？这个流程里哪些步骤必须约束、哪些步骤可以留白？

想清楚了再动手写，技能文件可以在半小时内搞定；想不清楚，写出来的就是一个披着Skills外衣的普通Prompt。跟做产品一样——先把需求搞清楚，再谈技术实现。

6.2 最后一招：如何持续保持Skills的“新鲜度”

Skills不是一次写完就完事的。模型在变，你的使用场景在变，技能也需要跟着迭代。我自己每过一两周都会把项目里的Skills翻出来审视一遍：“最近有没有在某个场景下反复给模型追加类似的指令？如果有，是不是该把这条经验固化进某个技能里？”

慢慢你会发现，当“给Agent追加临时指令”变成“打开以前的Skills改两行”时，你对Agent的“驾御感”就完全不一样了。这时候你再回头看那些躺在收藏夹里的所谓“万能技能”，反而会用一种更冷静的眼光去评判它们——真正好用的技能不是越多越好，而是越贴合自己的工作流越好。

Skills这个机制本质上是在提醒我们一件事：AI时代的能力，不完全取决于模型的进步，更取决于你有没有把自己的专业经验，翻译成模型能够理解和执行的“语言”。这件事，你可以从现在开始自己动手做起来。