企业官网建设流程全解析

1. 从“能用”到“好用”：40个Skill带来的认知颠覆

我大概是在三个月前开始认真折腾 Claude Code 的。当时的状态跟很多人一样——装好、跑通、能对话、能改代码，觉得已经“会用”了。直到有一次，我把自己积累的四十来个 Skill 一次性挂上去，跑了一个完整的重构任务，才发现之前那些用法基本等于拿高射炮打蚊子，工具的能力连三成都发挥出来。

这篇文章不打算讲“Claude Code 是什么”这种入门问题，网上已经够多了。我想聊的是：Skill 这个东西到底改变了什么，为什么数量堆到一定程度之后会产生质变，以及怎么从零开始搭建一套真正能提升日常效率的 Skill 体系。如果你已经在用 Claude Code，但还停留在“打开终端、输入需求、等结果”的阶段，那这篇内容应该能帮你省下不少摸索时间。

先说结论：Skill 不是插件，不是提示词模板，更不是简单的“快捷指令”。它更像是给 Agent 装上一套可组合的专业能力模块。单个 Skill 的价值有限，但当它们形成体系之后，Claude Code 的行为模式会发生根本性变化——从“你问什么它答什么”变成“它知道该在什么时候做什么”。

2. Skill 到底是什么：拆开看它的运行机制

2.1 从 SKILL.md 说起：一个被严重低估的文件

很多人第一次接触 Skill 的时候，注意力都放在“怎么装”上面，反而忽略了最核心的东西——SKILL.md这个文件本身。我见过不少人的 Skill 目录里塞了一堆文件，但SKILL.md写得跟 README 一样潦草，结果就是 Skill 加载了但根本不生效，或者行为完全不符合预期。

SKILL.md的本质是一份给 Agent 看的说明书。它需要回答三个问题：这个 Skill 是干什么的、什么时候该用它、用了之后具体怎么做。这三个问题对应到文件结构里，就是描述、触发条件和执行指令。

我自己的写法是这样的：

--- name: code-review description: 对指定文件或目录进行结构化代码审查，输出问题清单和改进建议 trigger: 当用户提到"审查""review""检查代码质量"时激活 --- ## 执行步骤 1. 读取目标文件，识别语言和框架 2. 按以下维度逐项检查： - 命名规范与可读性 - 错误处理完整性 - 边界条件覆盖 - 性能隐患 3. 输出格式：按严重程度分级，每条附带行号和修改建议

关键点在于trigger字段。很多人不写这个，导致 Skill 要么永远不触发，要么乱触发。我的经验是，触发条件要写得具体但不死板，用自然语言描述场景，而不是硬编码关键词匹配。

2.2 Skill 和 Agent 的区别：别再搞混了

热搜里有个词条是“skill和agent的区别”，说明这个问题困扰了不少人。我用一个类比来解释：

• Agent是一个员工，有自主决策能力，能规划任务、调用工具、根据反馈调整策略。
• Skill是这个员工掌握的某项技能，比如“写单元测试”“做代码审查”“生成 API 文档”。

一个 Agent 可以挂载多个 Skill，就像一个人可以会多种技能。子 Agent 则是另一个员工，有自己的 Skill 集合和独立上下文。主 Agent 可以把任务分派给子 Agent，子 Agent 完成后把结果交回来。

这个架构带来的最大好处是上下文隔离。举个例子：你让主 Agent 做一次全项目重构，如果所有分析都在主上下文里跑，很快就会把窗口撑爆。但如果把“分析模块 A”派给子 Agent，它在自己的上下文里完成分析，只把结论返回给主 Agent，主上下文的消耗就小得多。

2.3 为什么是40个：数量堆叠背后的质变逻辑

有人可能会问：装那么多 Skill 干嘛？装几个常用的不就行了？

我一开始也是这么想的。但实际用下来发现，Skill 之间存在组合效应。单个 Skill 解决单点问题，但当你有了一套覆盖完整工作流的 Skill 之后，Agent 能做的事情就从“执行指令”变成了“完成项目”。

打个比方：你有一个“写代码”的 Skill，那 Agent 就是个码农。你再加上“代码审查”“写测试”“生成文档”“性能分析”这几个 Skill，Agent 就变成了一个能独立交付的小团队。再加“需求拆解”“任务规划”“进度追踪”，它就能接一个完整项目了。

40 这个数字不是硬性标准，但它大致对应了一个完整开发流程所需的技能覆盖面。我自己的分类是这样的：

这个分类不是死的，你可以根据自己的工作内容调整。核心原则是：覆盖你日常工作中重复出现的所有环节。

3. 搭建 Skill 体系的完整实操流程

3.1 环境准备：从零到能跑

如果你还没装 Claude Code，先把基础环境搞定。Ubuntu 下的安装流程大致是这样：

# 确认 Node.js 版本不低于 18 node -v # 全局安装 npm install -g @anthropic-ai/claude-code # 验证安装 claude --version

Windows 用户建议走 WSL，原生环境的兼容性偶尔会有问题。VSCode 用户可以直接在集成终端里跑，配合 Claude Code 的 VSCode 扩展体验更好。

安装完成后，Skill 的存放位置有两个选择：

• 全局目录：~/.claude/skills/，所有项目共享
• 项目目录：.claude/skills/，仅当前项目生效

我的建议是：通用型 Skill 放全局，项目专用的放项目目录。这样既保证复用性，又避免不同项目的 Skill 互相干扰。

3.2 手动安装 GitHub 上的 Skill：详细步骤

热搜里“claude code怎么手动装github上的skills”这个问题出现频率很高，我把自己常用的流程写一下。

假设你在 GitHub 上看到一个 Skill 仓库，比如awesome-skill/code-review，安装步骤如下：

# 1. 进入全局 Skill 目录 cd ~/.claude/skills/ # 2. 克隆仓库 git clone https://github.com/awesome-skill/code-review.git # 3. 检查目录结构 ls code-review/ # 应该能看到 SKILL.md 以及可能的辅助脚本 # 4. 如果 SKILL.md 不在根目录，需要调整位置 # 有些仓库会把文件放在 src/ 或 skill/ 子目录下

这里有个坑：不是所有 GitHub 上的 Skill 仓库都遵循标准结构。有些是给其他工具用的，有些是半成品。装之前先看SKILL.md的内容，确认触发条件和执行逻辑符合你的需求。

装完之后，重启 Claude Code 或者执行一次刷新命令，让 Skill 被加载。验证方法是问 Agent：“你现在有哪些可用的 Skill？”它应该能列出你刚装的那个。

3.3 写一个自己的 Skill：从需求到落地

市面上的 Skill 不一定完全贴合你的需求，自己写是最靠谱的。我拿一个实际例子来演示——“变更日志生成”Skill。

需求场景：每次发版前，需要根据 Git 提交记录生成格式化的变更日志。

第一步，确定触发条件。我希望在我说“生成变更日志”“整理 release notes”的时候激活。

第二步，定义执行逻辑。需要读取 Git log、按类型分类、格式化输出。

第三步，写SKILL.md：

--- name: changelog-generator description: 根据 Git 提交记录生成结构化变更日志 trigger: 用户提到"变更日志""changelog""release notes""发版说明"时激活 --- ## 前置检查 - 确认当前目录是 Git 仓库 - 确认有至少一条提交记录 ## 执行步骤 1. 执行 `git log --oneline --since="last tag"` 获取提交列表 2. 按以下规则分类： - feat: 新功能 - fix: 问题修复 - refactor: 重构 - docs: 文档更新 - chore: 杂项 3. 输出格式： ## [版本号] - [日期] ### 新功能 - 描述（对应 commit hash） ### 问题修复 - 描述（对应 commit hash） ## 注意事项 - 如果提交信息不符合规范，标注出来提醒用户 - 合并提交默认跳过

写完保存到~/.claude/skills/changelog-generator/SKILL.md，重启生效。

这个 Skill 我从写到用熟大概花了半小时，但之后每次发版至少省了十五分钟的手动整理时间。投入产出比极高。

3.4 子 Agent 的配置与调度

子 Agent 是 Skill 体系里的进阶玩法。配置方式是在项目目录下创建.claude/agents/文件夹，每个子 Agent 一个配置文件。

--- name: test-writer description: 专门负责编写单元测试的子 Agent skills: - test-generation - mock-helper - coverage-check --- 你是一个测试工程师，只负责编写和优化单元测试。 不要修改业务代码，如果发现业务代码有问题，报告给主 Agent。

主 Agent 在遇到测试相关任务时，会自动把工作分派给这个子 Agent。你也可以手动指定：“让 test-writer 给这个模块写测试。”

子 Agent 的核心价值在于职责单一。一个什么都干的 Agent 往往什么都干不好，但一个只写测试的 Agent，在这个领域里的表现会稳定得多。

4. 40个Skill的实战编排：一个完整项目复盘

4.1 项目背景与Skill组合策略

上个月我接了一个活：把一个跑了三年的 Python 数据处理项目从 Python 3.8 迁移到 3.12，同时把散落在各处的工具函数整理成独立包，补上缺失的测试和文档。

这种任务如果纯手工做，保守估计两周。我用了大概三天，其中大部分时间是在做决策和验证，实际执行基本交给了 Claude Code。

我挂载的 Skill 组合是这样的：

• 规划类：需求拆解、任务排期、风险评估
• 代码类：依赖分析、兼容性检查、重构助手、包结构生成
• 质量类：单元测试生成、集成测试生成、代码审查、类型检查
• 文档类：API 文档生成、迁移指南生成、变更日志
• 工具类：Git 批量操作、CI 配置更新、依赖版本锁定

总共 38 个 Skill，加上两个项目专用的自定义 Skill，凑了 40 个。

4.2 关键环节：依赖分析与迁移路径规划

第一步是让 Agent 分析现有依赖。这里用到了“依赖分析”Skill，它会扫描requirements.txt和实际 import 语句，找出：

• 哪些包在 3.12 下有不兼容版本
• 哪些包已经停止维护
• 哪些包有更好的替代品

输出是一张表格，按风险等级排序。我拿到结果后，让“任务排期”Skill 生成迁移计划，把工作拆成可并行的小任务。

这一步的注意事项：不要让 Agent 直接改代码。先分析、再规划、最后执行，这个顺序不能乱。我见过有人一上来就让 Agent “把项目升级到 3.12”，结果改了几百个文件，一半是错的，回滚都费劲。

4.3 批量重构：子 Agent 并行处理的实践

迁移计划里有一项是“把所有os.path操作替换为pathlib”。这个任务涉及 60 多个文件，如果串行处理，主 Agent 的上下文很快就不够了。

我的做法是：按模块拆成 6 组，每组派一个子 Agent 处理。每个子 Agent 挂载“重构助手”和“代码审查”两个 Skill，独立完成修改和自检，只把修改摘要返回给主 Agent。

主 Agent 收到 6 份摘要后，统一做一次全局审查，确认没有遗漏和冲突。

这个模式的关键在于子 Agent 的上下文是独立的。每个子 Agent 处理 10 个文件，上下文消耗可控，而且它们之间互不干扰。如果全部塞给主 Agent，光是读取文件内容就能把窗口撑爆。

4.4 质量保障：测试与审查的自动化闭环

重构完成后，让“单元测试生成”Skill 给新增的包写测试。这里有个技巧：先让 Agent 分析现有测试的写法，然后按照同样的风格生成新测试。这样出来的测试代码风格统一，不会出现“一半 pytest 一半 unittest”的尴尬局面。

测试跑完后，用“代码审查”Skill 做一次全面检查。我配置的审查规则包括：

• 函数长度不超过 50 行
• 每个公开函数必须有 docstring
• 异常处理不能裸except
• 类型注解覆盖率不低于 80%

审查结果按文件分组，每条问题附带行号和修改建议。我抽查了其中 20 条，准确率大概在 85% 左右。剩下 15% 是误报，主要是 Agent 对某些业务逻辑的理解偏差。这个比例可以接受，人工过一遍就行。

5. 踩坑记录与常见问题排查

5.1 Skill 不生效的几种典型情况

这是最高频的问题。我整理了一张排查表：

我遇到最多的是 trigger 写得太宽泛。比如写“当用户提到代码时激活”，结果几乎每轮对话都会触发。后来改成“当用户要求审查、重构或分析代码质量时激活”，就精准多了。

5.2 上下文爆炸：什么时候该用子 Agent

上下文窗口是有限资源。我总结了一个简单的判断标准：

• 任务涉及文件数超过 10 个：考虑拆给子 Agent
• 任务需要读取大量参考文档：子 Agent 独立处理
• 任务之间没有依赖关系：并行派发
• 任务需要多轮迭代：子 Agent 在自己的上下文里迭代，只返回最终结果

反过来，如果任务很简单，或者需要频繁与主 Agent 交互，就不要拆。拆分的开销也是成本。

5.3 Skill 版本管理与更新策略

Skill 写多了之后，版本管理就成了问题。我的做法是：

• 全局 Skill 目录用 Git 管理，每次修改都提交
• 项目专用 Skill 跟随项目仓库
• 定期清理不再使用的 Skill，避免加载时浪费资源

更新 Skill 时要小心：先在小项目上验证，再推到全局。我有一次改了一个“代码审查”Skill 的规则，结果在所有项目里都生效了，导致几个老项目的审查结果突然多出一堆无关问题。后来学乖了，改之前先备份，改之后先测试。

5.4 那些“看起来有用但实际鸡肋”的 Skill

装了 40 个之后，我发现有几类 Skill 使用频率极低：

• 过于通用的 Skill：比如“写代码”，这个不需要 Skill，Agent 本来就会
• 过于专用的 Skill：比如针对某个特定框架的某个特定版本的迁移，用一次就废
• 依赖外部服务的 Skill：比如需要调用某个 API 的，网络一波动就挂

真正高频使用的，往往是那些解决日常重复劳动的 Skill：生成测试、格式化输出、批量重命名、生成文档。这些才是值得花时间打磨的。

6. 从工具到工作流：Skill 体系的长期维护

6.1 建立自己的 Skill 库：分类与索引

当 Skill 数量超过 20 个之后，找起来就开始费劲了。我建议建一个索引文件，放在~/.claude/skills/INDEX.md，内容大致如下：

# Skill 索引 ## 代码类 - code-review: 代码审查 - refactor-helper: 重构助手 - test-generation: 测试生成 ... ## 文档类 - api-doc: API 文档生成 - changelog: 变更日志 ...

这个索引不参与 Agent 的运行，纯粹是给你自己看的。每次新增 Skill 时更新一下，找的时候一目了然。

6.2 团队协作：Skill 的共享与标准化

如果你在团队里推广 Claude Code，Skill 的标准化很重要。我的建议是：

• 建立团队共享的 Skill 仓库
• 制定 Skill 编写规范（命名、格式、触发条件写法）
• 定期 review 和合并大家的 Skill
• 新成员入职时，直接 clone 团队 Skill 库

这样能保证团队里每个人的 Agent 行为一致，减少“为什么你的 Agent 能做这个我的不能”这类问题。

6.3 持续迭代：根据使用反馈优化 Skill

Skill 不是写完就完了。我每个月会花半小时回顾一下：

• 哪些 Skill 这个月一次都没用过？考虑删除或合并
• 哪些 Skill 经常触发但结果不满意？需要优化执行逻辑
• 有没有新的重复劳动出现？需要新增 Skill

这个习惯坚持了三个月，我的 Skill 库从最初的 40 个精简到了 32 个，但实际效率反而更高了。因为留下的都是真正有用的，而且每个都经过反复打磨。

6.4 关于“Skill 原版无删减版”这类说法的澄清

网上偶尔能看到“Skill 原版无删减版”这种说法，我理解大家想要的是“完整、未经修改的官方或高质量 Skill”。但实际情况是，Skill 本身就没有什么“删减版”的概念。它就是一个 Markdown 文件加可能的辅助脚本，内容完全透明。

真正需要注意的是来源可靠性。从 GitHub 上 clone 别人的 Skill 时，看一眼SKILL.md里有没有奇怪的指令，比如要求 Agent 执行不明脚本、读取敏感文件之类的。这个跟装任何第三方工具一样，基本的警惕心要有。

我自己写 Skill 的原则是：只做我完全理解的事情。如果一个 Skill 的执行逻辑我看不懂，那就不用。宁可自己花时间写一个简单的，也不装一个黑盒的。

这套体系跑下来，最大的感受是：Claude Code 的上限不取决于模型本身，而取决于你怎么组织它的能力。40 个 Skill 不是终点，而是一个起点——当你习惯了这种工作方式之后，会自然而然地想“这个环节能不能也做成 Skill”，然后你的体系就会自己生长。我现在遇到重复劳动的第一反应已经不是“手动做”，而是“写个 Skill 让 Agent 做”。这个思维转变，可能比任何具体的技术细节都重要。