Claude Code 项目级 Skills 怎么设计：别把所有提示词都写成技能

Claude Code Skills 很有用，但它不是“长提示词收藏夹”。如果你把每个临时任务都写成 Skill，项目很快会变成一堆互相冲突、没人维护的规则文件。

真正适合写成 Skill 的，是那些会反复发生、步骤稳定、边界明确、需要一致执行标准的项目流程。

Skill 不是长提示词

普通提示词解决一次任务，Skill 解决一类重复任务。

比如：

1	帮我检查这篇文章的 SEO。

这是普通提示词。

但如果你每次都要说：先看 frontmatter、再查 title/description、再检查内链、再跑构建、最后输出清单，那就适合写成 Skill。

Prompt、CLAUDE.md、Skill、Hook 怎么分工

工具	适合什么	不适合什么
普通 Prompt	一次性任务、临时问题	长期项目规则
CLAUDE.md	项目背景、编码规范、禁区	复杂执行流程
Skill	重复流程、固定步骤、审查标准	所有小任务
Hook	自动触发低风险验证	自动业务修改、自动发布

如果只是告诉 Claude “这个项目用 Astro”，写进 CLAUDE.md；如果是每次都要按一套步骤检查内容质量，写成 Skill；如果是改文件后提醒跑构建，用 Hook。

什么时候该创建项目级 Skill

满足下面三条，才考虑写 Skill：

这个任务会反复出现；
每次步骤基本一致；
结果需要统一标准。

典型例子：

代码审查；
SEO 内容检查；
发布前构建验证；
安全边界审查；
新文章 Brief 检查；
站点内链检查。

如果任务每次都不一样，Skill 反而会限制判断。

什么时候不要创建 Skill

不要为了“显得高级”写 Skill。

不适合：

一次性问题；
需求还没稳定；
只有一两步；
需要大量人工判断；
只是某篇文章的临时要求；
和现有 Skill 功能重叠。

Skill 越多，选择成本越高。团队需要的是少数稳定 Skill，而不是几十个半成品。

一个好 Skill 的最小结构

一个可维护 Skill 至少要写清楚五件事：

部分	要回答的问题
Trigger	什么时候使用？
Inputs	需要用户提供什么？
Steps	按什么顺序执行？
Boundaries	不能做什么？
Verification	怎么判断完成？

如果没有边界和验证，这个 Skill 只是包装过的提示词。

示例：内容 SEO 检查 Skill

---
name: content-seo-check
description: Use when checking a finished article before publishing.
---

When invoked:
1. Read the target article.
2. Check title, description, H1/H2, internal links, source links, and FAQ.
3. Check whether the article satisfies the assigned brief.
4. Do not rewrite the article unless the user explicitly asks.
5. Output: pass items, issues, recommended fixes, and manual checks.

注意第 4 条。检查 Skill 不应该默认改文章，否则很容易把诊断变成大改。

示例：项目构建验证 Skill

---
name: project-build-verify
description: Use after source files change and the user asks to verify the project.
---

When invoked:
1. Detect the project type from package.json.
2. Run the correct build command.
3. If build fails, summarize the first real error.
4. If build passes, check the expected output path.
5. Do not deploy, push, or submit URLs.

这个 Skill 的核心不是“跑命令”，而是确保结果可解释。

Skill 和 Hook 不要混用

Hook 是自动触发，Skill 是主动调用。两者边界不同。

需求	更适合
每次改文件后提醒跑测试	Hook
用户说“帮我检查 SEO”	Skill
提交前扫描 secret	Hook
写完文章后做发布前检查	Skill
自动部署	都不建议默认自动

不要用 Hook 自动执行复杂业务判断，也不要用 Skill 做本来应该自动化的低风险提醒。

项目级 Skill 维护清单

每个 Skill 至少每月检查一次：

触发条件是否仍然准确；
是否和其它 Skill 重复；
是否包含过期命令；
是否会越权修改文件；
是否默认做外部可见动作；
输出格式是否稳定；
是否有用户多次纠正但未固化。

如果一个 Skill 半年没人用，可以删掉或合并。

团队怎么引入 Skill

小团队推荐从 3 个开始：

code review；
build verification；
content / SEO check。

等这三个稳定后，再考虑安全审查、发布前检查、站点专项规则。

不要让每个人随手创建 Skill。最好有一个规则：新增 Skill 前先说明它解决哪个重复任务，和已有规则有什么不同。

和已有 Claude Code 内容怎么配合

如果你还没理解 Claude Code 的整体能力，先看 Claude Code 完全指南。

如果你想了解 Skills 基础写法，看 Claude Skills 实战指南。

如果你关心自动验证，可以看 Claude Code Hooks 实战和 Claude Code 验证清单。

FAQ

每个常用提示词都应该变成 Skill 吗？

不应该。只有重复、稳定、需要统一执行标准的流程才适合 Skill。

Skill 可以自动改文件吗？

可以，但必须明确边界。审查类 Skill 默认不应改文件；执行类 Skill 应先说明影响范围。

项目里 Skill 越多越好吗？

不是。Skill 多了会增加选择和维护成本。少量高质量 Skill 更适合团队协作。

总结

Claude Code 项目级 Skills 的目标，是把重复工程流程变得稳定，而不是把所有提示词都存起来。先用 CLAUDE.md 管项目规则，用普通 Prompt 处理一次性任务，再把高频、稳定、有边界的流程沉淀成 Skill。这样 Skills 才会提高交付质量，而不是制造新的规则混乱。