最近看 Claude Code Skills 文档，最大的感受是：Skill 不应该写成“万能提示词”，而应该写成一个边界很清楚的小工具包。
官方文档：
我理解的 Skill
Skill = 一段可自动发现的说明 + 必要的脚本/模板/参考资料。
它适合沉淀那些你经常重复做、而且流程比较稳定的任务，例如：
- PR review
- 生成 changelog
- 检查论文格式
- 按项目规范写测试
- 根据设计稿实现页面
不适合把所有偏好一股脑塞进去。那样模型每次都要读一大坨，反而容易失焦。
最小结构
my-skill/
SKILL.md
scripts/
templates/
references/
SKILL.md 最关键的是 frontmatter：
---
name: pr-review
description: Review code changes for bugs, regressions, missing tests, and risky behavior. Use when the user asks for code review or pre-merge checks.
---
# PR Review
Read the diff first. Prioritize correctness issues over style.
Report findings with file path and line reference.
description 要写触发条件，不要只写“一个很强的 review 技能”。模型是靠描述判断什么时候加载的。
我建议的写法
一条 Skill 只做一类事：
- review 就只 review
- deploy 就只 deploy
- paper polish 就只处理论文
- screenshot 就只做截图和视觉检查
如果一个技能里同时写“审查、重构、部署、写文档”，最后就很容易变成大型玄学 prompt。
判断一个 Skill 好不好
我会看三点：
- 触发场景是否清楚。
- 输出格式是否稳定。
- 有没有可复用脚本或模板，而不是全靠模型临场发挥。
这个思路对 Codex 的 Agent Skills 也适用。后面我准备把常用的 review、Playwright 截图、项目初始化都整理成技能。
1 个帖子 - 1 位参与者
来源: LinuxDo 最新话题查看原文