企业官网建设流程全解析

如果你最近在关注 AI 智能体相关话题，一定频繁看到 Skills 这个词。从 Claude Code、Codex，到各类智能体工作台工具，都在强调“给智能体加技能”。很多开发者的第一反应是：这跟插件有什么区别？装上之后真的能提升效果吗？会不会只是换个名字炒概念？

这篇文章先不急着下结论，我会把 Skills 的概念、配置方式、常见玩法讲清楚，再整理 8 个实用性较高的 Skills 方向，附上可直接套用的配置示例。无论你用的是 workbuddy、Claude Code，还是 Codex，思路都是通用的。文末还会给出常见故障排查和工程落地建议，新手也可以照着一步步操作。

1. AI 智能体与 Skills：先理解它是什么

1.1 从“会聊天”到“会干活”

早期的 AI 助手更多承担问答任务，你问一句，它答一句。后来出现了 RAG（检索增强生成）、Function Calling（函数调用），AI 开始能查文档、调接口、操作工具。再往后发展，AI 智能体不仅仅完成一次对话，而是把多个步骤串联起来，主动规划、调用工具、检查结果，最后输出一份完整成果。

举个例子，传统聊天机器人只能回答“Spring Boot 怎么配置多数据源”。而一个具备工程能力的智能体会这样做：

• 先搜索本地项目里现有的数据源配置；
• 再读取依赖文件，确认 Spring Boot 版本；
• 搜索常见多数据源方案；
• 生成配置代码和注意事项；
• 把结果整理成一篇可以放进项目文档的说明。

这一步一步的过程，就是智能体在工作流中执行任务。而“执行任务”不能只靠大模型的参数记忆，还需要复用一些外部能力。Skills 就是在这样的背景下出现的。

1.2 Skills：给智能体的“岗位说明书”

Skills 是一组结构化的指令、示例、代码片段和规则，它们被放到特定目录或配置文件中，让智能体在需要时读取并使用。

我们可以把它理解为“岗位说明书”：

• 说明这个技能负责什么场景；
• 说明调用时应该按什么步骤执行；
• 说明代码生成规范、输出格式、注意事项；
• 必要时附带参考示例、测试用例或目录结构。

比如你希望 AI 在写前端代码的时候统一使用 TypeScript 风格，那就给智能体一个frontend-development的 Skill，里面写好代码规范。当用户提出“帮我写一个表格组件”时，智能体会自动读取该 Skill，然后按照规范生成代码，而不是凭模型默认喜好来写。

1.3 Skills 与插件的区别

很多人会混淆 Skills、插件（Plugin）和工具（Tool）这三个概念。

• 工具（Tool）：一般是可执行函数，例如天气查询接口、数据库连接模块、文件读写函数。
• 插件（Plugin）：通常是针对某一平台或应用的扩展能力，比如浏览器插件、IDE 插件，往往带 UI 或独立运行时。
• Skills：更偏向“指令 + 知识 + 示例”，它不一定有独立运行环境，而是指导智能体如何调用工具、如何写代码、如何遵循规范。

简单来说，Skills 是“教 AI 怎么做”，工具是“让 AI 能动手做”，插件是“做成一个独立包”。

1.4 为什么 Skills 能提智

大模型的上下文窗口有限，不可能把所有行业规范、框架用法、团队约束都塞进每一次对话里。Skills 的价值在于按需加载。平时不占上下文，只有当任务匹配时才会读取。这样既节省 token，又能保证回答更贴合你的项目实际。

另外一个价值是可复用。一个写好的 SQL 优化 Skill，可以给团队里所有人共享，换模型、换工具时也能迁移使用。这也是为什么越来越多智能体工具开始支持 Skills 配置。

2. 环境准备与目录约定

2.1 你需要的工具

Skills 的配置方式在不同工具中略有差异，但核心逻辑一致。本文以目前常见的几种场景为例：

• workbuddy 类的智能体工具：它们通常提供可视化界面，支持用户创建自己的 Skills 并启用；
• Claude Code / Codex 这类命令行工具：它们一般约定专用目录存放 Skills，比如.claude/skills/或.codex/skills/；
• 自建智能体框架：可以在代码中定义技能注册表，通过加载目录下的 Markdown 文件来生效。

不同工具的版本差异较大，本文侧重通用思路，具体路径和参数需要结合你使用的工具版本进行调整。

2.2 版本说明

这里要注意一个事实：AI 相关工具迭代非常快，Skills 的配置格式也会变化。建议按这套通用规范来创建目录：

skills/ ├── code-review/ │ ├── SKILL.md │ └── examples/ ├── web-search/ │ ├── SKILL.md │ └── prompts/ └── office-doc/ ├── SKILL.md └── templates/

核心是 SKILL.md 文件，一般包含 YAML 格式的 frontmatter 和 Markdown 正文。frontmatter 用来声明技能名称、描述、适用场景，正文用来写操作步骤和规则。

2.3 准备环境

这不是传统软件开发，不需要安装大型 SDK。你只需要：

• 一个支持 Skills 的智能体工具；
• 一个用于存放技能文件的目录；
• 一个文本编辑器；
• 如果涉及自动写代码，建议准备一个测试项目目录。

示例环境以通用目录为例，不限定操作系统。Windows、macOS、Linux 都可以，只需要注意路径分隔符。

3. 八个高价值 Skills 方向与配置思路

这 8 个方向覆盖了开发者日常最常遇到的场景：写代码、查资料、办公处理。下面每个方向都会说明适用场景、推荐配置内容和一个可参考的 SKILL.md 片段。

3.1 自动写代码：把生成逻辑“框”住

自动写代码是很多开发者最先接触的 Skills 场景。如果只是让 AI 直接生成代码，往往会出现风格不统一、缺少异常处理、依赖版本混乱等问题。写一个代码生成类 Skill，可以帮助智能体明确以下几点：

• 项目语言和框架版本；
• 代码风格、命名规范；
• 必须包含哪些模块；
• 禁止使用哪些不安全的写法；
• 生成完成后要给出运行和测试建议。

假设我们创建一个python-backend-dev的 Skill，配置可以这样写：

--- name: python-backend-dev description: 用于生成 Python 后端接口代码，遵循项目既有风格。 --- # Python 后端开发技能 ## 适用场景 - 编写 FastAPI / Flask 接口 - 添加数据库模型 - 编写单元测试 ## 代码规范 1. 类型注解必须完整。 2. 函数命名使用下划线小写。 3. 依赖版本以项目 requirements.txt 为准。 4. 涉及数据库操作时，必须使用事务并捕获异常。 5. 不做任何绕过安全校验的编写建议。 ## 输出要求 - 先给出文件路径，再给出代码。 - 关键逻辑需要加注释说明。 - 最后补充简单运行方式和测试命令。

这样的 Skill 一旦被智能体加载，它生成的代码就不会天马行空，而是贴合团队规范。

3.2 查资料：把搜索流程固定下来

“AI 能查资料”并不稀奇，但查到的资料质量参差不齐。很多智能体只是凭训练数据回答，或者抓取到过时信息。查资料类 Skills 可以用来约束信息检索流程：

• 先明确信息需求和关键词；
• 优先从指定文档站、官方仓库、可信社区获取；
• 对搜索结果进行时间筛选；
• 输出时标注信息来源。

示例：

--- name: research-and-search description: 用于高质量信息查询，优先官方文档与可信来源。 --- # 查询资料技能 ## 执行流程 1. 拆解问题中的关键词，列出中英文检索词。 2. 搜索官方文档、GitHub 仓库、技术社区。 3. 对比多个来源，筛选发布时间最近的内容。 4. 记录来源 URL。 ## 禁止行为 - 不编造不存在的函数或版本号。 - 不把来源不明的回答当作确定事实。 - 不把 AI 生成内容标注为官方文档。 ## 输出模板 - 结论摘要 - 关键论据 - 参考来源

有了这个 Skill，智能体在回答框架问题时，就不会随口给出过时 API。

3.3 办公文档：让输出格式统一

办公场景的 Skills 通常用于日报、周报、PPT 大纲、会议纪要、邮件回复。很多工具默认输出的内容偏长、偏口语化，给到领导或客户并不合适。一个office-docSkill 可以强制输出格式：

--- name: office-doc description: 负责生成标准化的办公文档内容。 --- # 办公文档技能 ## 日报/周报格式 - 今日完成 - 遇到的问题 - 明日计划 - 风险提醒 ## 会议纪要格式 - 会议主题 - 参会角色 - 结论 - 待办事项（责任人与截止时间） ## 语言要求 - 使用书面语，避免口语化表达。 - 不夸大成果，用数据支撑结论。 - 邮件正文控制在 200 字以内。

这类 Skill 很适合非技术岗用户，也让 AI 智能体在办公场景中更“像人”。

3.4 前端开发：统一组件与样式风格

前端项目最容易出现的问题是组件风格不统一。有的地方写函数组件，有的地方写类组件；样式有的用 Tailwind，有的用 CSS Modules。前端开发类 Skill 的目标就是把这些规则固定下来。

--- name: frontend-development description: 前端组件开发规范，统一技术选型与代码风格。 --- # 前端开发技能 ## 技术栈 - React 18 + TypeScript - 样式方案：Tailwind CSS，特殊情况使用 CSS Modules - 状态管理：Zustand ## 组件要求 1. 组件必须使用函数式写法。 2. props 必须定义 interface 类型。 3. 组件文件默认导出。 4. 涉及异步请求时，给出 loading 与 error 状态处理。 ## 代码示例 ```tsx // components/UserCard.tsx interface UserCardProps { name: string; email: string; } export default function UserCard({ name, email }: UserCardProps) { return ( <div className="rounded-md border p-4"> <h3>{name}</h3> <p>{email}</p> </div> ); }

这个 Skill 对团队协作特别有用，新成员让 AI 生成代码时，也能一键对齐团队规范。 ### 3.5 测试用例：覆盖边界条件 测试是很容易被忽略、但又极其考验细节的场景。很多 AI 写测试只会写“正常路径”，对边界条件、异常输入、权限校验覆盖不足。测试类 Skills 可以提高用例质量： ```markdown --- name: test-case-writer description: 编写覆盖正常与异常场景的单元测试/接口测试用例。 --- # 测试用例技能 ## 要求 1. 每个函数至少包含：正常输入用例、边界输入用例、异常输入用例。 2. 测试命名遵循 test_函数名_场景 的规则。 3. 涉及文件读写时，使用临时目录并在 finally 中清理。 4. 涉及网络请求时，使用 mock，不实际发起调用。 ## 输出示例 - 测试文件路径 - 被测函数分析 - 用例表 - 完整代码

有了这个 Skill，AI 智能体在自动补测试时会更“较真”，这对后端项目质量提升非常明显。

3.6 学术研究：加速文献阅读与笔记整理

学术研究类 Skills 适合高校师生和做技术调研的开发者。它可以帮助智能体完成以下任务：

• 从 PDF 论文中提取核心问题、方法、实验数据；
• 对比多篇论文的异同；
• 整理文献综述大纲；
• 生成带有引用的读书笔记。

--- name: academic-research description: 用于论文阅读、文献综述和技术调研。 --- # 学术研究技能 ## 论文阅读输出模板 - 研究方向 - 核心问题 - 方法/模型 - 数据集 - 实验结果 - 局限性 ## 写作要求 - 不虚构引用文献。 - 参考文献格式统一。 - 综述部分区分“已有结论”与“个人分析”。

这类 Skills 能明显降低科研入门者的信息整理成本。

3.7 工作流搭建：把多步骤任务编排起来

AI 智能体的高阶用法是自动完成跨越多个工具的任务，比如：读取表格 → 数据清洗 → 生成图表 → 输出分析报告。这个过程中需要把每一步的操作逻辑定义清楚，工作流类 Skills 就能派上用场。

--- name: workflow-orchestrator description: 编排多步骤数据处理与生成任务。 --- # 工作流搭建技能 ## 通用流程 1. 读取用户输入，明确最终产物。 2. 拆解子任务，并确定依赖关系。 3. 为每个子任务选择合适的工具或 API。 4. 逐步执行并检查中间结果。 5. 汇总输出，附带说明与下一步建议。 ## 执行原则 - 每一步都要有可验证的输出。 - 遇到错误时先记录错误信息，再尝试回退方案。 - 涉及删除/覆盖操作时必须二次确认。

3.8 代码审查：抓住常见质量风险

最后一个非常推荐的是代码审查类 Skill。它可以让智能体按检查清单审查代码，而不是泛泛说“写得不错”。

--- name: code-review description: 按工程规范对代码进行质量审查。 --- # 代码审查技能 ## 检查清单 1. 是否包含明显的安全问题：SQL 注入、硬编码密钥、越权访问。 2. 异常处理是否合理，是否吞掉异常。 3. 是否有明显性能隐患：N+1 查询、无索引查询、循环内请求。 4. 命名是否清晰，函数职责是否单一。 5. 是否存在重复代码。 ## 输出格式 - 问题等级：高/中/低 - 问题定位：文件:行号 - 问题说明 - 修改建议

这个 Skill 适合在提交 PR 前让 AI 提前过一遍，能省下不少 reviewer 的时间。

4. 一次性配置 8 个 Skills 的实战流程

下面以一个本地项目为例，演示如何把这些 Skills 一次性装进智能体工具。

4.1 创建目录结构

在项目根目录下创建skills文件夹：

mkdir -p skills/{code-review,research-and-search,office-doc,frontend-development,test-case-writer,academic-research,workflow-orchestrator,python-backend-dev}

执行后，目录结构如下：

skills/ ├── academic-research/ ├── code-review/ ├── frontend-development/ ├── office-doc/ ├── python-backend-dev/ ├── research-and-search/ ├── test-case-writer/ └── workflow-orchestrator/

4.2 创建 SKILL.md 文件

在每个子目录中放入一个 SKILL.md。以code-review为例：

cat > skills/code-review/SKILL.md << 'EOF' --- name: code-review description: 按工程规范对代码进行质量审查，输出问题等级与修改建议。 --- # 代码审查技能 ## 检查清单 1. 安全问题：SQL 注入、硬编码密钥、越权访问。 2. 异常处理是否合理。 3. 性能隐患：N+1 查询、无索引查询、循环内请求。 4. 命名与职责是否清晰。 5. 是否存在明显重复代码。 ## 输出格式 - 问题等级：高/中/低 - 问题定位：文件:行号 - 问题说明 - 修改建议 EOF

注意，直接复制命令时，不同操作系统的 shell 支持程度可能不一样。Windows 用户建议用编辑器创建文件，避免转义问题。

4.3 让智能体识别 Skills

不同工具的加载方式不同，但一般有两种方式：

方式一：放到工具的固定读取目录。例如某些命令行工具会读取项目下的.claude/skills或.codex/skills，我们可以把刚才创建的目录复制过去：

# 以 .claude/skills 为例，具体路径以你的工具说明为准 cp -r skills/* .claude/skills/

方式二：在工具的配置文件中手动声明。如果工具没有自动扫描目录，需要打开配置文件，把 skills 路径添加进去：

skills: - path: ./skills/code-review - path: ./skills/python-backend-dev - path: ./skills/research-and-search - path: ./skills/office-doc - path: ./skills/frontend-development - path: ./skills/test-case-writer - path: ./skills/academic-research - path: ./skills/workflow-orchestrator

配置完成后，重启工具，或执行重新加载命令，让 Skills 生效。

4.4 验证加载是否成功

最直接的验证方法是向智能体提问，例如：

请使用 code-review 技能，审查下面这段 Python 代码：

def get_user(username): conn = get_db_connection() query = "SELECT * FROM users WHERE username = '" + username + "'" cursor = conn.execute(query) return cursor.fetchone()

如果 Skills 配置正确，智能体会先给出问题等级，然后指出 SQL 注入风险，而不是只给一句“代码可以优化”。

4.5 实测效果观察

在真实使用中，你会发现加了 Skills 之后最明显的变化是：输出更“守规矩”了。

• 代码生成不再自由发挥，而是按照 SKILL.md 中的规范执行；
• 查资料时会主动检查来源和时间；
• 办公文档的输出结构更统一；
• 测试用例覆盖更全面；
• 代码审查结果更像资深工程师的 review 意见。

这里提醒一点：Skills 不是“装了就一定会 100% 生效”。它更像给智能体的一份强参考手册，具体效果还取决于模型能力和任务复杂度。

5. 常见问题与排查思路

5.1 智能体没有读取 Skills

5.2 上下文用量增长过快

Skills 本身按需加载，但如果某个 Skill 内容过长，每次触发都会占用大量 token。建议把 SKILL.md 控制在几百行以内，把详细示例放到 examples 子目录，让智能体按需读取。

5.3 不同工具的格式差异问题

如果你在 A 工具上写好了 Skills，换到 B 工具后不生效，大概率是 frontmatter 字段或目录结构不兼容。迁移时先查看目标工具的官方文档，确认字段名和路径。

5.4 Skills 内容泄露风险

如果 Skills 中包含公司内部规范，注意不要提交到公开仓库。必要时通过专用技能管理平台分享，或者在仓库中添加.gitignore忽略敏感目录。

5.5 提示词与 Skill 效果不一致

如果 SKILL.md 写得很好，但智能体不遵循，可能是模型在对话中被其他指令覆盖了。解决思路是：在核心任务描述中也要提及“请先查看并使用对应 Skill”，给智能体一个显式的触发信号。

6. 最佳实践与工程建议

6.1 命名与应用目录

Skills 的命名尽量使用连字符小写格式，例如code-review、>