企业官网建设流程全解析

Claude Code 用了大半年，我最深的体会是：决定它上限的不是模型本身，而是你给它配了什么样的 Skill。Skill 这东西，最初我以为就是给 Claude 加几段提示词，结果真正开始整理技能包之后，才发现它背后是一整套关于“能力封装、触发机制、上下文预算”的工程问题。装少了不够用，装多了它反而会犯迷糊。后来我把自己常用的十七个技能统一做成了一份“一键安装”清单，脚本一跑，所有技能包自动就位，新电脑迁移环境再也不用一个一个手动折腾了。

这篇博文把我这段实践的完整沉淀写下来：17 个亲测好用的 Skill 清单，按使用场景分组，每个都写清楚定位、适用场景和实测感受；一份我自己在用的“一键安装全部”脚本，manifest 驱动、支持幂等重跑、带校验；另外还有几个让我真正掉过坑的问题，比如同名覆盖、上下文被吃、脚本乱跑，都附了完整的排查思路。不管你是刚接触 Claude Code 的新手，还是已经把它当主力开发工具的老手，这份清单应该都能让你少走不少弯路。

1. Skill 到底是什么：先搞清楚这套玩法再动手

1.1 Skill 和普通 Prompt 模板的差别

很多人第一次接触 Skill，脑子里第一个念头是：这不就是一段写在 Markdown 里的高级提示词吗？说实话，我第一次也是这么想的，于是直接把常用的工作流写成几百行的 prompt，塞进系统提示或项目说明文档里。效果不能说没有，但极不稳定——Claude 处理简单对话时还能记得，任务一复杂或上下文一长，那套提示词就像被遗忘在角落里的说明书，模型完全想不起来去翻。

Skill 和 Prompt 之间最本质的差别在于结构化和可执行性。一个标准的 Skill 不仅仅是文字，它是一整个目录，目录里有 SKILL.md 入口文件，还可以挂 rules、scripts、examples、references 这些辅助资源。SKILL.md 描述了技能的目标、触发条件、执行步骤、输出规范和常见陷阱；配套脚本则能在 Claude 需要时真实执行，比如解析日志、生成测试数据、批量重构重命名。Prompt 是教它“应该怎么做”，Skill 是让它“拥有做这件事的工具和流程”。

打个比方：Prompt 像是你在副驾上给司机指路，能不能走到全看司机心情和路况；Skill 则像是给司机装了一套带地图、路况提醒和行车记录仪的导航系统，它自己知道什么时候该导航、怎么走更稳。这也是为什么同一个任务，有 Skill 和没 Skill 的完成质量差了一大截。

1.2 一个 Skill 的目录结构长什么样

下面是我从社区优秀 Skill 里总结出来的共性结构，以嵌入式开发场景为例：

skills/ stm32-firmware-helper/ SKILL.md rules/ hal-usage-rules.md scripts/ parse_register_map.py generate_flash_layout.py examples/ gpio-blink/ references/ peripheral-list.md

SKILL.md 是主入口，模型会先读它；rules 放强约束规则，比如“禁止在中断回调里做耗时操作”这种芯片级经验；scripts 放可执行脚本，让 Claude 不只是“说”，还能真正帮你算、帮你改、帮你生成；examples 和 references 是给模型参考和查证的资料库。

目录内部的资源不是必须全都有，但 SKILL.md 是必须的，而且它的开头一段 description 极其重要。社区里维护得好的技能包，SKILL.md 通常遵守同一套写作套路：第一段讲清是什么、解决什么问题；第二段列使用场景，越具体越好；第三段写工作流程和输出要求；最后补一段“不要使用该技能的情况”，给模型做负向约束。负向约束这块很多人偷懒不写，但实测下来它恰恰是减少错误调用的关键。

1.3 Skill 的加载与触发机制：描述即命运

Claude Code 启动会话时，会扫描用户全局目录、项目目录以及插件注册的多个 skill 位置，把每个 SKILL.md 里的描述信息做一次摘要注入。注意，它不是把全文引进去——那样上下文早就爆了——而是维护一份“技能摘要索引”。模型面对用户任务时，先根据摘要判断是否需要调用某个技能，如果需要，再把完整的 SKILL.md 与配套文件加载进来。

这意味着描述字段写得好不好，直接决定了你装的技能能不能被“翻牌”。我见过不少技能包，功能强大，但描述写得含糊，结果安装之后半年没被调用过一次。描述里至少要包含三块：这个技能解决什么问题、在什么场景下触发、输出风格或格式是什么，最好还能带上几个负面用例，明确告诉模型“当用户只是想闲聊时，不要调用本技能”。

另外一个很多人忽略的点是技能优先级：项目级 skill 会覆盖全局同名 skill，plugin 注册进来的 skill 又和这两者有先后之分。如果你的技能分布在不同层，命名时一定要做隔离，不然大概率会遇到“装了新技能，旧技能突然失联”的玄学问题。

1.4 Skill、Plugin、MCP 的分工，别再混为一谈

社区里讨论 Skill 时总绕不开另外两个词：Plugin 和 MCP。我把它们的边界理一下，这套理解帮我在配置环境时少踩了很多坑。

Plugin 是分发单元，你可以把它理解成应用商店里的 App。一个 Plugin 可以把多个 Skill、一条或多条命令、一组 MCP server 配置打包在一起，通过配置文件一次性派发给 Claude Code。Skill 是能力描述与执行流程，核心解决“该怎么做”；MCP 则解决“能调用什么”，把外部工具和数据通道接到 Claude 上，比如读取数据库、操作文件、调 API。

三者配合起来的典型玩法是：Plugin 负责分发，里面注册了一个数据库 MCP server，同时配一个负责数据库工单的 Skill。Skill 告诉 Claude“接到数据库操作任务时，先通过 MCP 连接查询元数据，再按照团队规范生成 SQL，最后用 review 脚本检查高危语句”。光有 MCP，Claude 只是个“能操作数据库的助手”；加上 Skill 之后，它才变成“一个懂规矩、有流程、会自查的资深 DBA”。

2. 17 个亲测 Skill 清单：从开发提效到生活搭子的全场景实测

下面这 17 个技能是我从两个维度筛出来的：一个是真实使用频率，一个是“替换成普通 prompt 后效果差距是否明显”。把那些只有描述、没有配套脚本和结构化规则的伪 Skill 全部剔除后，剩下这些我按使用场景分成四组，先说定位总览，再逐个讲实测感受。

2.1 开发与工程类：写代码这件事，先让它学会套路

code-sage 解决的是“读大型项目”的视野问题。装它之前，我让 Claude 读一个中大型仓库，它经常从入口文件开始逐行讲，讲了半天还在外围转悠，核心模块反而没抓到。装上之后，它读取的方式明显像有经验的工程师：先扫目录、再读构建配置、识别依赖关系、定位核心入口，最后用分层列表输出架构说明。尤其处理那些没有文档的旧项目，这个技能能帮你省下一个下午。

commit-msg-writer 的价值在于约束。很多人觉得让 AI 写 commit message 是小菜一碟，实际上它写出来的往往过于“宏大叙事”，什么“完善系统功能”“优化业务逻辑”，等于啥也没说。这个 Skill 内置了一套提交规范，会真实去解析git diff，再按 type、scope、subject、body 的结构组织信息，每行不超过 72 字符，动词开头，把改动范围写清楚。

code-reviewer 是我用得最频繁的一个。它不像普通提示词那样只给“代码风格建议”，而是按安全、性能、可读性、边界条件四个维度逐项检查 diff，每条意见都标注严重级别，重要问题直接给出修改后的代码片段。我试过拿同一个 PR 让它和裸 Claude 分别 review，差距非常明显：裸 Claude 会客气地说“整体不错，建议优化命名”，code-reviewer 会直接指出并发场景下的竞态条件。

test-craftsman 做单元测试和测试数据生成。它对 pytest 系的适配很好，能根据函数签名自动生成边界值用例，还会补上 mock 数据。refactor-guard 则侧重重构安全网：它会先分析待重构代码的调用关系，列出所有受影响的地方，再分步执行重构，每一步都建议跑一遍测试验证行为是否保持一致。这个技能让我在重构老模块时安心很多。

2.2 质量与运维类：让它在出问题时更可靠

bug-hunter 专门对付那种“看不出为什么错”的玄学问题。它的工作流很清晰：先要求用户提供完整错误栈或最小复现步骤，再列假设，逐个排除，每轮排查后必须总结当前证据和下一步计划。用过一次你就知道，它最大的优点是克制——不瞎猜，不被某个表面现象带偏。

log-miner 是针对日志分析的。它内置了一套日志解析脚本，能自动从大文件里提取异常上下文、时间线、关键报错，然后按“现象—原因—影响—建议”的结构输出分析报告。处理几百 MB 的日志文件时，脚本会先切片再按关键字过滤，实测比直接把日志糊给 Claude 喂上下文要省太多 token。

api-mcp-bridge 解决的是 API 对接的重复劳动：给一个 OpenAPI 文档或接口定义，它能生成调用的 Python 封装、错误处理逻辑和类型定义，还能把工具包装成 MCP server 的格式，方便 Claude Code 直接调用。db-schema-migrator 则面向数据库变更：读现有 schema，生成迁移脚本，并且会检查破坏性操作，比如删表、删列、改类型，它都会在脚本注释里给足警告。

2.3 垂类领域类：遇到专业软件和平台时，通用技能完全失灵

通用 AI 在嵌入式领域容易说外行话，stm32-firmware-helper 则把“嵌入式老手”的规则固化成了文档。它的 rules 里内置了“中断服务函数要短小”“避免在 ISR 里调用 HAL_Delay”“宏定义加头文件防护”这类实战守则，scripts 里还带了寄存器映射解析脚本。实测让它生成 STM32 的 GPIO 初始化代码，会比裸 Claude 多考虑时钟使能、引脚复用、上下拉配置这些细节。

ros-env-pack 是给 ROS 开发者的救星。用过 ROS 的人都知道，环境配置的痛点在于 source 多个 setup 文件、依赖冲突、catkin 和 colcon 两套构建体系来回切换。这个 Skill 参考了社区里广泛使用的一键配置脚本思路，内置环境检查脚本，跑完会输出一份针对当前机器的配置建议和排错指引，比如哪几个依赖缺失、哪条环境变量路径不对。

keil-workspace-assistant 管理 Keil/MDK 工程。Keil 的工程文件本质是 XML，让模型直接改很容易把结构改坏，这个 Skill 里放了一个专门处理 uvprojx 增删改的 Python 脚本，还处理了中文路径和编码问题。long-context-guard 是我在 Claude Code 进入 1M 上下文时代之后最依赖的技能：它不追求把所有内容塞进上下文，而是先对超长内容做分块摘要，提取关键决策，维护一份“上下文地图”，再让主任务基于地图工作，避免模型被海量信息淹没。

2.4 内容与生活类：工具之外的日常搭子

de-ai-fy 解决一个很多人的痛点：AI 写出来的东西一眼假。它内置了一份高频 AI 腔词汇表，硬编码在规则里，包括“首先、其次、最后”“综上所述”“赋能”“抓手”这类词，并提供多个重写演示。实测最实用的功能是“保持口语化”和“乱序表达”，改写后的文字像人话多了。

dog-counselor 是我做方案评审时的习惯工具。它会扮演不同立场的顾问，比如一个只关心成本的财务、一个专门挑漏洞的研发、一个盯交付时间的项目经理，用答辩方式把方案的漏洞逼出来。workbuddy 则更像敏捷开发里的 co-worker，帮你把大任务拆成可执行的小步，再按优先级排好。我用它来管理一周的工作清单，比待办事项 App 更灵活。

lesson-planner 是面向教师的备课技能，按课程标准生成教案框架、课堂活动设计和分层作业。实测比通用 prompt 强的点在于它内置了教学设计框架，不是简单堆知识点，而是按照导入、讲解、互动、巩固、评估的课堂结构组织内容，还支持一键调整课时长度。

3. 一键安装全部：manifest 驱动的幂等安装脚本

3.1 为什么不用手动方式

如果你只有三五个 Skill，手动复制到目录完全没问题。但技能超过十个之后，手动的维护成本会迅速失控：Skill 更新了要重新拉，新机器要重新配，装错目录还找不到问题在哪。社区里虽然有一些“合集仓库”，但很多人是直接git clone一堆 repo 到 skills 目录，没有版本管理、没有校验、没有冲突处理，装完一堆坏包都不知道。

我的做法是维护一份 manifest 清单，配合一个幂等的安装脚本。所谓幂等，就是脚本可以反复执行，重复运行不会产生脏数据。这是后端同学最熟悉的设计思路，用在 Skill 管理上一样好使。整个安装过程从“手动逐个整理”变成“一条命令跑完”，换新电脑时省下的时间非常可观。

3.2 manifest 驱动的安装器是怎么设计的

先看 manifest 文件，每一行是一个技能名和对应的 Git 仓库地址，可以用 TSV 格式，也可以用简单的空格分隔。我自己的清单长这样：

# name git_url code-sage https://github.com/example/claude-skill-code-sage commit-msg-writer https://github.com/example/claude-skill-commit-msg code-reviewer https://github.com/example/claude-skill-code-reviewer test-craftsman https://github.com/example/claude-skill-test-craftsman refactor-guard https://github.com/example/claude-skill-refactor-guard # ... 其余 12 个

安装脚本用 Bash 写，核心逻辑只有几十行：

#!/usr/bin/env bash set -euo pipefail SKILL_DIR="${HOME}/.claude/skills" MANIFEST="skill-manifest.tsv" mkdir -p "${SKILL_DIR}" install_skill() { local repo_url="$1" local dest_name="$2" local dest_path="${SKILL_DIR}/${dest_name}" if [ -d "${dest_path}/.git" ]; then echo ">>> 更新 ${dest_name}" git -C "${dest_path}" pull --ff-only || echo "!!! ${dest_name} 更新失败，继续执行" else echo ">>> 安装 ${dest_name}" git clone --depth 1 "${repo_url}" "${dest_path}" fi if [ -f "${dest_path}/SKILL.md" ]; then echo "OK ${dest_name}" else echo "WARN ${dest_name} 缺少 SKILL.md，可能不是有效技能" fi } while IFS=$'\t' read -r name url; do # 跳过空行和注释 [[ -z "${name}" ]] && continue [[ "${name}" == \#* ]] && continue install_skill "${url}" "${name}" done < "${MANIFEST}" echo "全部执行完毕，技能目录：${SKILL_DIR}"

逐个讲一下关键设计：

第一点是浅克隆。git clone --depth 1只取最新快照，不拉历史提交，省时间也省磁盘。对 Skill 这种会持续更新的资源，浅克隆完全够用。第二点是幂等更新逻辑：如果目标目录已经有.git存在，就执行git pull --ff-only，只做快进合并。如果你手动改过 skill 里的文件，快进失败时脚本不会强行合并，而是打印提示继续跑，避免把冲突搞成一团浆糊。

第三点是安装即校验。脚本每次装完都检查SKILL.md是否存在，缺了就输出 WARN。这一步看着简单，作用很大——有些仓库目录结构和标准不一致，README 说得天花乱坠，实际根本没有 SKILL.md，装上也是一个僵尸包。有了校验，至少能第一时间知道哪个包有问题。

3.3 从零跑通的完整流程

实际使用流程分四步。第一步，创建全局 skills 目录，如果之前没建过的话：

mkdir -p ~/.claude/skills

第二步，把 manifest 文件放在一个固定位置，我是放在~/.claude/skill-manifest.tsv，和 skills 目录同级。不建议放项目里，因为这是个全局资源，和新电脑同步走一套清单更合理。第三步，把上面的脚本存成install-skills.sh，加上执行权限，然后运行：

chmod +x install-skills.sh ./install-skills.sh

脚本会逐个拉取仓库，输出每个技能的安装状态。我在本地实测，17 个技能串行安装，从零到全部就位大概两分钟左右，主要是网络耗时，脚本本身的 CPU 开销可以忽略。第四步，重启 Claude Code 会话，让新的技能目录被扫描到。需要注意的是，Claude Code 一般只在会话启动时扫描技能目录，运行中装的技能不会立即生效。

3.4 安装完成后的验证三板斧

装完别急着开工，先花一分钟验证。第一板斧，看目录结构是否完整：

find ~/.claude/skills -name SKILL.md | sort

正常情况应该输出 17 个 SKILL.md 文件路径。哪一行少了，就是那个技能装失败了。第二板斧，在新会话里直接问 Claude：“你能加载哪些技能？”看它回答的列表里是否包含这 17 个的摘要。第三板斧，挑一个任务实际触发一次，比如让 code-reviewer 审查一段代码，看它是否真的读到了技能里的规则和脚本。我见过太多“目录有文件但技能不生效”的情况，所以三步验证一步都不能省。

4. 实测中的坑：从选择困难到上下文预算失控

4.1 装了 30 个 Skill 之后，Claude 开始“选择困难”

有一段时间我装了一堆测试性质的 skill，总数直奔三十个。结果发现 Claude 的表现反而变差了：任务来了之后，它先花大量时间在思考该用哪个技能，有时候还出现错误调用——明明在写 commit message，它却去加载了代码审查技能。原因是技能摘要索引在数量过多时发生了混淆，模型对“什么时候该用哪个”的判断力急剧下降。

我的解决方案是分层管理：全局目录只放十几个高频通用的技能，项目级目录.claude/skills放和当前技术栈深度绑定的技能，比如 STM32 项目只放 stm32-firmware-helper。同时把每个 SKILL.md 的描述精简，增加负向约束，明确“当任务类型不是 XX 时，不要使用本技能”。调整之后，误调用的情况大为减少。

4.2 同名覆盖：全局技能悄无声息被项目技能顶掉

这是我踩过最隐蔽的坑。我在全局装了 code-reviewer，后来项目里也放了一个旧版本的同名技能，结果 Claude 一直加载项目里的旧版，全局的新规则完全没生效。区别在于：项目级优先级高于全局级，同名时项目技能会“吃掉”全局技能，而且 Claude Code 通常不会给任何提示。

从那以后，我要求在 manifest 里给跨层使用的技能统一命名，比如全局技能带global-前缀，项目技能带项目缩写前缀。另外，不要同一个技能既装全局又装项目，二选一。如果你确实需要不同版本的规则，那就用两个不同的目录名，而不是同名覆盖。

4.3 每个技能都在悄悄吃上下文预算

技能摘要索引不是免费的，每个 SKILL.md 的描述部分都会占用上下文预算。我实测过一个描述写得很长的技能，光是摘要就占掉了将近 2000 token，当时就惊了。30 个技能全装上，光技能描述可能就吃掉上万 token，这在 1M 上下文的时代听起来不多，但日常短任务根本不需要这么大的上下文，白白浪费还影响模型注意力。

解法很简单：每个 SKILL.md 的 description 精简到一两句话，控制在 300 字符以内，把详细规则全部下放到 references 目录或由脚本按需读取。另外可以观察哪些技能长期没有被触发，直接从 manifest 里删掉，保持精简。

4.4 不受信任的 Skill 可能真会跑代码

这是安全红线。Skill 里的 scripts 目录是真实的可执行脚本，Claude 会在对话过程中调用它们。如果你从不明来源拉了一个技能包，等于把一段未知代码交给了 AI 去执行，风险不必多说。我见过有些包里的脚本写得非常粗糙，甚至有直接把文件删掉的危险逻辑。

我的处理习惯是：只从可信维护者安装；新技能装完第一件事，先打开 scripts 目录逐个检查脚本内容；执行 Claude Code 时尽量不用 root 或管理员权限，给脚本设置独立临时目录，避免它对系统做全局修改。网上有些“合集一键脚本”默认会执行安装者提供的任意 shell 命令，这种建议谨慎使用，至少先读完脚本再跑。

4.5 Skill 不生效的完整排查链路

技能装了但不生效，是最常见的求助话题。我总结了六步排查法，每次按这个顺序基本都能定位问题。

第一步，检查目录位置。技能必须放在 Claude Code 扫描的目录下，全局是~/.claude/skills，项目是.claude/skills，放错位置一切白搭。第二步，检查 SKILL.md 是否存在且格式是否正确。用less打开看开头几行，确认 description 字段存在、YAML 或 TOML 元数据没写坏。第三步，检查命名冲突。全局和项目有没有同名技能，有冲突就先改名再试。第四步，重启会话并执行 Claude Code 自带的魔法命令，不同版本命令不一样，一般是/plugin或/skills，看加载列表里有没有目标技能。第五步，直接向模型提问“你有没有读到 XX 技能的描述内容”，如果它说不清楚，说明摘要索引根本没加载到。第六步，检查文件权限。目录和文件是否可读，Git 仓库有没有损坏，必要时删掉重新安装一次。

这六步走完，九成以上的问题都能定位。排错最忌讳上来就删目录重装，先确认问题出在哪个环节，才能真正解决。

5. 进阶玩法：把 Skill 调成自己的形状

5.1 改造现成 Skill 的四个切入点

用别人写的技能，最忌讳的是装完就用、永远不改。一个 Skill 是否顺手，和你的工作习惯强相关，所以下载下来的技能包通常要经过二次改造。我把切入点总结成四个位置。

第一是描述字段。把触发词改成自己习惯的表达方式，比如 code-reviewer 改成“当用户说‘帮我 review 一下’或‘看看这个 PR’时使用”，命中率会明显提升。第二是 rules。把团队的代码规范、提交规范、安全红线加进去，比任何通用守则都管用。第三是 scripts。结合自己的工程环境替换或新增脚本，比如给嵌入式技能加一个新的烧录校验脚本。第四是 examples。把自己真实项目里的优秀片段放进去，示例的质量决定了模型模仿的上限，通用的 demo 示例远不如自己的历史案例有参考价值。

5.2 自研最小 Skill：从一份 SKILL.md 开始

如果想练手，完全可以从写一个自己的最小技能开始。我建议选一个自己反复做的任务，比如“生成规范的中文 commit message”，然后照着这个模板写：

--- name: "中文提交信息生成" description: "在用户要求生成 git commit 信息或检查提交格式时使用。不要在纯聊天场景使用。" --- # 中文提交信息生成 ## 目标 根据仓库已有提交风格，生成简洁、明确的中文 commit message。 ## 工作流程 1. 运行 git diff --staged 获取改动内容 2. 分析改动类型：feat / fix / refactor / docs / test / chore 3. 提取改动涉及的文件和功能点 4. 生成单行主题（不超过 50 字）和多行正文 ## 输出格式 <type>(<scope>): <subject> <body> ## 注意事项 - 主题使用祈使句 - 正文说明改动的动机和影响，不要罗列文件清单 - 不要包含“更新”“优化”这类无信息量的词

写完 SKILL.md 放进~/.claude/skills/my-commit-helper/，重启会话就能用。整个过程十几分钟，比搭一个完整的插件轻量太多。跑通之后，再慢慢往里面加校验脚本、参考文档，最后把这个目录丢进自己维护的 Git 仓库，就成了一个完全可迁移的私人技能。

5.3 Skill 与 MCP 联动：从“会说”到“会做”

Skill 和 MCP 不是替代关系，真正的效果是在两者配合时出现的。举一个我常用的例子：数据库巡检。MCP server 提供数据库连接工具，让 Claude 能真的执行 SQL 查询；而一个巡检 Skill 负责编排流程——先查看表大小和索引，再查慢查询日志，最后按安全规范生成巡检报告。没有 MCP，Skill 只能给建议；没有 Skill，MCP 只能让 Claude 变成一台“会执行 SQL 的机器”，毫无章法。

在做 API 配置相关任务时也一样。Claude Code 本身支持通过环境变量和配置文件指向不同的 API 端点，社区里也有人写配置管理工具来切换不同的模型服务。我的习惯是把这些配置切换的细节封装成一个 Skill，让模型在需要换环境时按照固定步骤调整，而不是凭记忆乱改配置。

5.4 把 Skill 变成团队资产

技能包这东西，用多了之后你会发现它天然适合团队复用。代码风格审查规范、提交信息规范、发布前的检查清单、新人了解项目架构的指引，都可以做成 Skill 放进团队内部的 Git 仓库统一维护。配合 CI，还能在每次推送时自动检查 SKILL.md 的格式是否正确、描述是否超长、脚本是否有危险操作。

我现在的做法是，团队仓库里维护一份 manifest，新人入职只需要跑一次安装脚本，所有规范类、工具类技能自动就位。这比发一份几百页的 Wiki 文档要有效得多，因为技能是“嵌在工具里”的，新人用 Claude Code 干活时，规范会主动出现在该出现的地方。

最后说一点我自己的体会。Skill 这个东西，真正用起来之后你会发现它改变的不只是输出质量，而是你组织和沉淀知识的方式。以前我把多年的工程经验零散地存在笔记里，现在我把高频场景固化成 Skill 文件，随时可以复制到任何一台新电脑上，整个人的 AI 工作流也跟着迭代起来。如果你只装了一两个 Skill 还在试水，我的建议是先挑这 17 个里最贴合你日常任务的装起来，跑通之后再研究怎么 DIY 自己的技能包。别急着堆数量，先把每个技能用出效果来。