企业官网建设流程全解析

做 AI 内容自动化这段时间，我把大部分工作流都从“打开一个网页、复制粘贴”改成了“交给代理去跑”。刚开始只是图省事，后来发现真正拉高上限的，不是模型本身，而是给模型配的那些可复用能力——也就是现在圈子里统称的 Skills。

如果你也关注 Claude Agent Skills、Codex skills 或者 agent skills 测试这类话题，应该会注意到一个现象：大家讨论重点已经从“哪个模型强”变成了“怎么让模型稳定地把一件事做完”。Skills 就是这一波变化里的核心载体。它不改变模型权重，却能在运行时给模型一份“操作手册”，让它在特定场景里表现得像一位老手，而不是一个偶尔超常发挥的聊天窗口。

这篇文章不打算写成文档复读，我会从第一性原理出发，把 Skills 是什么、为什么会出现、怎么开发、装到哪、踩过哪些坑，一次性讲透。适合正在用 Claude Code、Codex、IDE 插件做开发、写文档、做数据分析的人，也适合想自己写 Skills 给团队用的进阶玩家。无论你是第一天听说这个名词，还是已经装了一堆技能包但感觉效果飘忽，下面这些内容都能给你一些可落地的参考。

1. 换个视角理解 Skills：AI 代理的“技能包”是什么

1.1 从第一性原理拆解 Skills 机制

先说结论：Skills 本质上是一种极简封装——一个 SKILL.md 说明文档，加若干个可选目录（scripts、reference、assets）。SKILL.md 用 YAML frontmatter 描述技能的名称、触发条件和能力边界，正文部分则是一段写给模型看的操作手册。模型读到这份手册后，就能知道自己什么时候该调用它、调用之后按什么步骤执行。

这个设计的第一性原理在于：语言模型本身并不知道你的仓库结构、不懂你的周报格式、也记不住你团队的分支命名规范。你当然可以把这些信息全部塞进系统提示词，但对话一长就会稀释、会覆盖、会互相打架。Skills 的做法是把“某类任务的标准做法”独立成一个文件，放在模型能按需读取的位置，由模型根据当前任务主动去加载。相当于给模型准备了一整排抽屉，每个抽屉外面贴了标签，它看见标签匹配就去拉开，而不是要求它把整排抽屉都背下来。

你可以把它理解成新员工入职时拿到的一本 SOP 手册。手册不会强迫人每一步都翻，但遇到手册里写过的情形，翻出来照做，出错概率会小很多。模型也一样：当用户请求和某个 Skill 的 description 高度相关时，主代理会读取对应的 SKILL.md，然后按里面的流程执行。这个“按需加载”的机制，比把全部规则常驻在上下文里要经济得多。

1.2 为什么 Skills 能解决“下一跳预测”的痛点

语言模型生成文本的本质是预测下一个 token。训练得再好，它在具体业务场景里也天然缺乏三层信息：第一，外部世界的实时状态（今天仓库有哪些新的提交）；第二，任务执行的标准流程（你们团队的周报必须按哪几个模块写）；第三，输出格式的硬性约束（必须给出 Markdown 表格还是 JSON）。没有这些信息，模型只能靠“常识”去猜，猜就会飘，就会产出格式正确但内容不对的东西。

Skills 巧妙的地方在于：它把第二层和第三层做成了静态资产，把第一层留给脚本动态获取。比如一个“Git 周报摘要”Skill，SKILL.md 里写清楚“先运行 git log 拿最近七天提交，再按模块归并，最后按模板输出”，这就把流程定死了；而提交内容本身是由脚本实时拉取的，不会过期。模型要做的事情只剩下一件：理解任务、按手册执行、把结果整理输出。你不需要再花二十行提示词去描述“要总结 git log”，也不需要反复纠正模型“上次那个格式不对”。

我以前总觉得“模型懂得够多了，不需要额外教”，后来实测下来，凡是把流程固化到 Skill 里的任务，稳定性明显高于靠对话里临时提示的任务。原因很简单：临时提示是概率性的，模型每次读到的上下文略有不同，输出就会漂移；Skills 则把成功路径写成了确定性步骤，模型只有按步骤走路，路就走不偏。

1.3 和 Prompt、插件、微调的本质区别

很多人第一次接触 Skills，会下意识拿它和 Prompt 比较，或者和插件、微调混在一起。我帮你把这四者的边界划清楚：

• Prompt 是一次性上下文。你把它写在系统提示里，模型每次请求都要处理它，对话一长还会被后续内容稀释。Skills 是模块化资产，只有 description 被命中时才加载，不占常驻上下文。
• 插件是外挂执行体。典型如 MCP server、OpenAPI 端点、浏览器扩展，它们通常有独立的运行时和 API。Skills 不一定包含代码，它可以只是一份指令文档；即便包含脚本，那也只是辅助执行，核心驱动仍然是模型本身。
• 微调改的是模型权重。需要准备数据集、训练、评估，成本高、迭代慢，改起来要重新训。Skills 改的是运行时上下文，零训练开销，改完一个 Markdown 文件立即生效，非常适合流程频繁调整的业务场景。

从工程角度看，Skills 更像是一个“轻量中间层”。它不替代插件，反而可以指挥插件——Skill 的正文里完全可以写“调用某个 MCP 工具获取数据”。它也不替代微调，但在绝大多数业务场景里，你根本不需要微调，一个写清楚步骤的 Skill 就能把 90% 的问题解决掉。

2. Skills 生态与市场：去哪里找、怎么选

2.1 官方市场与社区仓库

Skills 的火爆带来了大量分发渠道。最权威的是官方维护的仓库（比如 anthropics/skills 这类项目），里面收录了不少经过验证的通用技能，适合作为起步参考。官方仓库价值在于：每个 Skill 的写作风格统一、结构规范，你可以直接看它们的 SKILL.md 是怎么组织语言、怎么写 description 的，这对培养自己的 Skill 写作手感特别有用。

社区方面，GitHub、Twitter 和各技术社区里已经出现了大量聚合清单，随便搜“awesome-claude-skills”“skills 大全”就能找到几十个整理好的仓库。质量参差不齐，有的确实好用，有的只是把一段普通提示词改了个后缀就发上来。我的建议是：下载平台不是关键，关键是你会不会筛。后面我会单独写一套筛选标准。

除了外部仓库，很多代理工具自己会内置一批 Skills。比如 Claude Code 默认就带了一些基础技能，像是文件编辑、代码搜索、终端操作这些，不需要你额外安装。Codex 也有自己的一套内置能力。你要做的第一件事，其实是先摸清楚手头工具已经有什么，避免重复造轮子。

2.2 值得关注的优质 Skills 类型

虽然具体 Skill 名单更新很快，但有一些类型经过了大量用户验证，属于“装了就不想卸”的级别。我按使用频率整理如下：

• 代码审查类：让代理基于本地 diff 做逐文件审查，检查潜在的边界条件、错误处理和风格问题。比直接复制代码给模型再问“有什么问题”要严谨得多，因为它能结合 git 历史和项目上下文。
• 长文写作类：这类 Skill 适合写论文、写技术方案、写工作文档。它们通常会把“提纲-逐节展开-统一术语-检查逻辑链”这套流程固化下来，避免模型一次性输出失控。热搜里的 workbuddy skills 写论文、codex 写论文的 skills 基本都属于这个范畴。
• 数据分析类：封装从 CSV/JSON/数据库取数、清洗、统计、出图的标准流程，适合每周固定要和报表打交道的人。
• Git 工作流类：统一 commit 规范、分支命名、merge 策略，团队用了之后 commit 历史会整洁很多。
• 综合增强包：这类代表是社区里非常流行的 superpowers 系列。它的设计哲学是给代理一组“元能力”，比如系统化思考、编辑规划、任务拆解，而不是绑定某个具体场景。如果你装了之后感觉“代理变聪明了”，原理就在这里——它把解决问题的通用策略写成了指令手册，模型照着执行，自然显得更有章法。

2.3 选型判断标准：别被星星数欺骗

我见过太多人看到 GitHub 上几千星的项目就往下拉，装了三个之后发现互相冲突，最后全部删掉。选一个 Skill 之前，我建议你按下面这四条标准逐一过一遍：

• description 质量：这是最重要的指标。一份好的 description 会写清楚“什么时候用、什么时候不用、输入是什么、输出是什么”。如果 description 写得含糊笼统，比如“帮助用户完成各种任务”，那这个 Skill 大概率会让模型频繁误触发。
• 依赖复杂度：看它除了 SKILL.md 之外，还要不要装 Python 依赖、要不要调外部 API、要不要开额外的服务。依赖越多，出问题的概率越大。轻量的 Skill 通常只靠模型和几个命令行工具就能跑，出了问题也容易排查。
• 输出格式与你的场景是否匹配：同样是周报 Skill，有人输出纯文本，有人输出 Markdown 表格，有人要求贴工单编号。你需要的不是“最好的”，而是“和你的工作流兼容度最高的”。
• 维护活跃度：看最近一次提交是什么时候，Issues 里有没有人反馈同类问题。AI 领域变化太快，一个半年没更新的 Skill，很可能已经跟不上新模型的指令遵循能力。

另外还有一条很多人忽略：先看 SKILL.md 正文是怎么写的。如果正文里大量使用“你应该”“你可以尝试”这类模糊用词，说明作者自己也没想清楚执行路径。真正好的 Skill 正文，应该像菜谱一样——第一步干什么、第二步干什么、遇到分支情况怎么处理，全部明确。

3. 亲手做一个 Skills：开发流程全解

3.1 Skill 的目录结构与核心文件

与其整天找别人的 Skill，不如自己写一个。写一个属于自己的 Skill 其实不难，目录结构通常长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ └── parse_git_log.py └── reference/ └── weekly-template.md

核心只有两个东西：SKILL.md 是入口，scripts 和 reference 是辅助。SKILL.md 的 frontmatter 至少要有 name 和 description 两个字段，有些工具还支持 allowed-tools 之类的可选项，用来限制这个 Skill 能调用哪些外部工具。正文部分就是给模型看的操作手册，写得越具体越好。

写正文有个技巧：把它当成“在给一个聪明但没经验的实习生写任务说明书”。你不能只写“分析提交记录”，要写清楚“先运行什么命令、拿到什么格式的数据、按什么原则做归并、输出什么结构”。模型不是不懂命令，而是不懂你的组织惯例，你越具体，它发挥越稳定。

3.2 从零开发一个“Git 周报摘要”Skill

直接上个例子。假设你每周都要写周报，要从 git 提交记录里整理本周变更，以前是手动翻 log，现在做一个 Skill 让代理替你干。SKILL.md 可以写成这样：

--- name: git-weekly-summary description: 基于当前 Git 仓库的提交记录生成周报摘要。当用户要求整理本周提交、写工作周报、复盘迭代进度，或想了解最近一周代码变动时使用。 --- # Git 周报摘要 这个技能帮助用户从当前仓库的 Git 历史中提取最近七天的提交，并按模块、类型统计变更，输出适合直接贴进周报的 Markdown 摘要。 ## 执行步骤 1. 先运行 `git log --since="7 days ago" --pretty=format:"%h|%an|%ad|%s" --date=short`，获取最近一周的提交列表。 2. 用 `scripts/parse_git_log.py` 解析原始日志，按模块归并同类提交。 3. 如果仓库内存在 `docs/weekly-template.md`，按模板格式输出；否则按下面的默认结构输出。 4. 只输出变更事实，不额外编造提交人身份或具体改动细节。 默认输出结构： - 本周变更概览：总提交数、涉及模块数、活跃开发者数 - 按模块分类：前端 / 后端 / 数据 / 文档 / 其他 - 关键提交：列出 3 条最重要的提交，说明为什么重要 - 风险与遗留：包含尚未合并的分支、未完成的重构等

配套的解析脚本不需要多复杂，核心是从管道里读入 git log 的输出，按分隔符切分，再做简单归类：

#!/usr/bin/env python3 import sys from collections import defaultdict def classify(message): if "feat" in message: return "功能" if "fix" in message: return "修复" if "docs" in message: return "文档" return "其他" def main(): lines = sys.stdin.read().strip().splitlines() buckets = defaultdict(list) for line in lines: parts = line.split("|") if len(parts) < 4: continue commit_hash, author, date, message = parts[:4] module = classify(message) buckets[module].append({"hash": commit_hash, "message": message, "date": date}) for module, commits in buckets.items(): print(f"## {module}") for c in commits: print(f"- {c['date']} {c['message']} ({c['hash']})") if __name__ == "__main__": main()

你可能会问，分类逻辑写在脚本里还是写进 SKILL.md 正文里？我的习惯是：凡是涉及文本处理的逻辑尽量写在正文里，让模型判断“这条提交属于前端还是后端”，灵活度高；凡是需要精确计算、批量循环的，才落到脚本。模型擅长理解语义，脚本擅长批量处理，两者配合才是最优解。

3.3 调试与本地验证技巧

写完一个 Skill，别急着扔进正式工作流。先做三轮验证：

第一轮验证结构：检查目录名、文件名是否规范。SKILL.md 必须是这个精确文件名，大小写敏感；目录名通常用连字符分隔的小写字母，不要用空格。任何一个不对，代理工具压根扫描不到。

第二轮验证触发：把任务描述得和 description 高度一致，看看模型能不能正确读取 SKILL.md。如果它读了但没按步骤做，大概率是正文指令不够清晰。反之如果它压根没触发，说明 description 写得和用户请求匹配不上。

第三轮验证输出：用一个规模较小的真实任务测试。比如“只看最近两天的提交，别给我完整周报，给我几条关键变更就行”，这样可以快速确认脚本能跑通、输出格式能接受，避免一上来就处理大数据量导致错误难定位。

调试时如果有日志系统，打开 verbose 模式观察模型是否加载了对应的 SKILL.md。比如 Claude Code 的调试日志里能看到它读取了哪个 skill 文件，如果你的 skill 没出现在日志里，基本可以断定是路径或描述问题，不用去改实现。

4. 安装、引入与日常使用

4.1 不同工具下的安装方式

Skills 的安装方式高度依赖你使用的代理工具，但底层逻辑是统一的：把 Skill 目录放进工具指定扫描的 skills 路径下即可。目前主流工具一般支持两种级别：

• 用户级：放在用户主目录下，例如~/.claude/skills/或~/.codex/skills/。放这里对所有项目全局生效。
• 项目级：放在当前项目的.claude/skills/或.codex/skills/目录下。放这里只会在这个仓库里生效，适合团队按项目定制技能。

如果你用的是 IDE 里的 AI 插件，一般在设置面板里能找到 skills 目录的配置项，原理一样。我习惯把通用技能放用户级，比如周报、代码审查、文档整理；把和具体业务耦合很深的技能放项目级，比如“这个项目特有的数据导出格式说明”。这样切换到不同项目时，代理自然加载对应业务技能，不会一个仓库背着所有项目的包袱。

安装步骤本身没有技术含量，就是复制粘贴、建目录、放文件。真正需要在意的点在于：安装之后要重启一下你的代理工具或者重新加载会话，很多工具不会热扫描新的 SKILL.md。我曾经装完技能发现完全不生效，折腾了半小时，最后发现只是没重开会话。

4.2 权限控制、上下文与安全边界

Skills 的触发是“软触发”，它不像传统程序有严格的权限控制，本质上是模型靠 description 猜的。这就带来两个必须注意的问题。

第一，description 写得太宽，会导致误触发。比如你写“帮助用户处理文件”，那用户只要提到任何一个文件，模型都可能加载这个技能，结果就是上下文里塞满无关指令，回复反而变笨。正确做法是给 description 加上明确的边界条件，比如“仅在用户要求生成 Git 周报时使用，不处理其他 git 变更查询”。别担心写太长，description 本身就是在教模型如何做判断。

第二，Skill 内部可以调用脚本，而脚本会在本地执行。这相当于把你的机器暴露给模型，所以必须警惕 Skill 里有没有可疑命令。从网上下载的 Skill，安装前打开 scripts 目录看一遍，重点看有没有删除命令、有没有上传数据的网络请求。官方或高信任度社区的 Skill 一般没问题，但顺手看一眼成本很低，别跳过。

还有一条安全习惯：不要把 API Key、数据库密码写进 SKILL.md 或 reference 文件。Skills 可能会被复制、分享、提交到公开仓库，一旦泄露就是事故。需要密钥的 Skill，应该从环境变量读取，而不是写死。

4.3 在工作流中的实际用法

Skills 装好之后，使用体验相当自然——你不需要敲什么魔法命令，只要正常提需求，模型判断命中了就会自动调用。比如你往项目里装了一个代码审查 Skill，然后说“帮我 review 一下当前分支的改动”，代理就会主动去加载审查技能，依步骤走完整套流程。

如果你想更主动地控制，很多工具也支持显式引用某个 Skill，比如@skill名的形式，或者通过命令面板浏览已安装技能列表。这个主动调用方式在“我知道自己就是要用这个技能”的场景下特别有用，能跳过模型理解判断那一环，减少误触发的可能性。

实际操作中，我会把一个复杂的分析任务拆成“主对话-子代理-Skill”三层结构。主对话负责理解大目标和分配任务，子代理执行具体步骤，Skills 则提供每一步的标准做法。比如我要分析一整个季度仓库的效能数据，会让主代理拆成“提交统计”“Review 分析”“发版记录”三个子任务，每个子任务各有一个 Skill 承接。这种组合拳打下来，单个 Skill 的指令都很简单，但合起来就能完成非常复杂的工作，而且每个环节都能独立调整、单独测试。

5. 常见问题与排查技巧实录

5.1 技能不生效的三大原因

我在实际使用中遇到最多的，就是“明明装了 Skill，模型就是不理我”。绝大多数情况逃不出这三个原因：

• 路径放错：Skill 目录没有放在工具扫描的范围里。用户级和项目级的目录别混淆，更别放在自己随手建的什么my-skills文件夹里然后指望代理能找到。
• SKILL.md 文件名不对：必须精确叫SKILL.md，全大写扩展名。写成skill.md或者SKILL.MD，扫描器很可能直接忽略。这个坑特别隐蔽，因为从系统文件列表上看两者差别很小。
• description 和用户请求对不上：你把 description 写成“分析代码”，用户说的是“帮我看看最近提交有什么问题”，语义距离太远，模型不知道该加载它。解决办法是用贴近用户原话的方式重写 description，甚至可以顺便把用户可能说的几种表达都列进去。

排查顺序建议：先用能看到技能列表的方式确认技能已被加载，再确认模型在日志里有没有读取 SKILL.md，最后才是检查 description 的匹配度。不要一上来就怀疑实现逻辑，绝大多数时候问题出在上游。

5.2 上下文过长和依赖冲突

另一个高频问题是：技能触发了，但表现反而不如不触发。这里有两类典型情况。

一类是 reference 目录里的资料太多太长，模型加载后上下文被大量参考内容挤占，导致实际处理任务的注意力变短。这个好解决，把 reference 里与你业务无直接关系的内容删掉，只保留必须的模板和规则；能被脚本动态读入的东西，就不要写死在 reference 里。

另一类是多个技能同时命中。比如你既有一个“文档撰写”技能，又有一个“工作总结”技能，用户说“帮我写一份本周工作总结”，两个 description 都匹配，模型可能加载两份互相矛盾的指令，结果两边不讨好。解决办法是给每个技能都加一条“排他性描述”，比如在写作技能里注明“如果用户明确要求生成工作总结，请使用周报摘要技能而非本技能”。这相当于在模型脑海里建立了一个小小的路由表。

5.3 避坑清单：七个容易忽略的细节

最后整理一份我踩过的坑，全是实操细节，照单规避能省不少时间：

• 目录名统一用连字符小写，不要用大写、空格、中文，跨平台兼容性会好很多。
• 脚本记得加可执行权限。Linux 和 macOS 下chmod +x是必须的，忘记这一步，代理每次调用都报 Permission denied。
• 不要在脚本里硬编码绝对路径。Skill 会被复制到不同机器、不同项目，用相对路径或者让脚本接受参数，才能保持可移植。
• 经常用 git 管理你的 skills 目录。改坏了一个 Skill 能随时回滚，比手工备份可靠得多。
• 从网上下载的 Skill，先看依赖再看描述，最后才决定要不要装。依赖过多的技能即便是好的，也容易被各种环境问题拖垮。
• 写 description 时，把“不做什么”也写进去。一条“不做什么”能省掉 80% 的误触发困扰。
• 模型更新后，Skill 的表现可能会变化。新模型对指令的遵循能力更强，以前写得模糊的 Skill 也许能跑通了，以前靠模糊描述实现的“灵活性”现在反而容易跑偏，所以要定期回头检查自己的技能库。

我自己在一次大版本模型更新后，发现之前精心调校的几个 Skill 全部“失效”，一开始以为坏了，后来发现是模型的默认行为变了，导致 Skill 里某些冗余步骤被绕过去。这种时候不要急着改 Skill，先跑一遍纯提示词对话对比一下，往往能定位到真正原因。

Skills 这个方向发展得很快，今天写的内容可能过半年又有新玩法。但底层的这套思维——把任务流程显性化、模块化、按需加载——不会过时。哪怕之后出现了更高效的技术，这套“把成功路径固化成资产”的做事方式，也依然值得你用在自己手头的任何 AI 工作流里。