我现在理解的 skill，不是某个神秘功能，也不是所有 AI 检查都会自动触发的东西。
它更像是一套提前写好的做事流程。普通规则告诉 AI：“这个项目应该怎么写”；skill 告诉 AI：“遇到这种任务时，应该按什么步骤做”。
比如代码检查 skill，会让 AI 按固定维度看逻辑、安全、测试、异常情况；debug skill 会提醒 AI 先复现、读错误、找根因，而不是一上来就改代码；grill me skill，则不是帮你写方案，而是不断追问你，把想法问清楚。
skill 不能保证 AI 一定正确，但可以让 AI 更守规矩，不要每次都凭感觉发挥。
一、skill 不是所有检查都会自动触发
我之前有个疑问：Cursor 平时帮我改完代码后，会做一些检查，那这些检查是不是用了 code review skill？
答案其实不是。
日常改代码时，Cursor 更多是按几类规则工作。
- 项目里的规则。比如
.cursor/rules、AGENTS.md。这些规则告诉 AI：这个项目怎么写代码，目录边界在哪里，组件风格是什么，哪些文件不要乱动。 - Agent 自己的通用要求。比如改完代码后看一下诊断、确认引用有没有问题、不要随便提交、尽量保持最小改动。这类东西是 AI 工具自己的工作规范。
- 临时对话要求。比如我明确说：“只改 user 端，不要动 admin”，“不要重构”，“先给方案再改”。这些都会影响它这一次怎么做。
所以，平时看到的“改完检查”，很多时候只是普通自检，不是某个 skill 在背后自动跑。
比如改完一个组件后，它可能会看一下 ReadLints，确认有没有 ESLint 或类型报错。也可能搜索一下引用，确认变量名有没有漏改。但它通常不会每次都主动跑完整的 pnpm lint、tsc、测试套件，更不会默认进入完整 code review 流程。
这点挺重要。因为如果我以为“AI 改完代码 = 自动做了完整检查”，其实会高估它做过的事情。
二、什么时候适合用 skill
我现在觉得，不是所有任务都要用 skill。有些小改动，用项目规则和基本检查就够了。强行上 skill，反而会变重。下面这些情况就很适合用 skill：
1. 需求还没想清楚时
比如领导让做一个新功能，但只知道大概方向。这时如果直接让 AI 写方案，它很容易顺着我说，生成一套看起来完整但没经过追问的东西。这时就适合用 grill me。
grill me 的作用不是帮我写方案，而是反过来拷问我：
- 你为什么要做这个？
- 给谁用？
- 不做会怎么样？
- 成功标准是什么？
- 哪些限制不能碰？
- 你现在是不是把手段当成目标了？
有时候被问几轮之后，我会发现自己原来的想法其实很虚。这个过程不舒服，但挺有用。
2. 改动比较大，准备提交前
如果涉及业务逻辑、状态流转、权限、接口、数据结构，我就更适合让 AI 用代码检查类 skill 走一遍。比如可以说：
用 code review 的方式检查这次改动，重点看逻辑错误、安全问题、测试遗漏。先不要改代码，只给结论。
这比单纯说“帮我看看有没有问题”要好。因为“看看有没有问题”太宽泛，AI 很可能只给一些泛泛的评价。但如果指定 code review 方式，它会更容易按维度检查。
3. bug 原因不明确时
debug 这件事最怕 AI 乱猜。有些 AI 一看到报错，就会立刻说“可能是这里”，然后开始改。第一次没修好，再试第二个地方，最后代码越来越乱。所以遇到真正的 bug，我会更倾向于让它用 debug 类 skill：
用系统化 debug 的方式排查，先复现问题和找根因，不要直接改代码。
这句话很关键。因为我不是要它马上修，而是先搞清楚为什么坏。
三、skill 和项目规则不冲突
skill 和项目规则不是互相替代的关系。
项目规则管的是“这个项目应该怎么写”
比如：
- 哪个目录放页面
- 哪个目录放组件
- 主题变量怎么用
- user 和 admin 项目不能混改
- ViewModel 怎么组织
- API 怎么封装
skill 管的是“这类任务应该怎么做”
比如：
- 做 code review 时看哪些问题
- debug 时先查什么再修什么
- 写方案时先问什么
所以实际使用时，最好是两个一起用。
按这个项目的 Cursor rules 改代码，改完后用 code review 思路检查，但不要扩大改动范围。
这句话就同时约束了项目风格和工作流程。
四、不想正式用 skill 时，可以直接给提示词
有时候我不想那么正式，不想调用某某 skill。这时可以直接给 AI 一个做事方式，我最常用的是：
先脑爆，再约束梳理。
这个很好用。“先脑爆”就是先不要急着给标准答案，把可能性多打开一点。“再约束梳理”就是回到现实，按时间、成本、技术难度、当前资源做筛选。
比如想功能时，可以说：
先脑爆这个功能的可能做法，再按开发成本和用户价值排序。
想项目方向时，可以说：
先脑爆，再约束梳理，最后给我一个最小可执行版本。
这个提示词不复杂，但比直接问“我该怎么做”好很多。
五、一些好用的轻量提示词
除了“先脑爆，再约束梳理”，我还会用几种简单说法。
1. 先问我，不要直接给方案
适合需求还不清楚的时候。
先问我 5 个关键问题，不要直接给方案。
这可以避免 AI 一上来就脑补需求。
2. 先指出风险，再给建议
适合做技术方案或产品决策。
先指出这个方案的风险，再给优化建议。
这样 AI 不会只顺着你夸。
3. 只做最小改动
适合改代码。
只做最小改动，不要顺手重构。
这个非常实用。很多 AI 最大的问题不是不会改，而是太爱多改。
4. 先复述我的需求
适合任务比较复杂的时候。
先复述你对需求的理解，我确认后再开始。
这样可以提前发现理解偏差。
5. 先列验收标准
适合开发任务。
先列出这次任务的验收标准，再开始实现。
如果没有验收标准，AI 改完后很难判断到底算不算完成。
6. 不要写得太像 AI
适合写周报、复盘报告。
用我的口吻写，少一点套话，多一点真实使用场景。
这比“写得自然一点”更明确。
六、我现在会怎么用 skill
现在我对 skill 的使用方式比较简单。小任务，不一定用。复杂任务，最好用。容易跑偏的任务，一定要用。
比如：
- 想需求：用
grill me - 提交前检查：用 code review 类 skill
- 排查 bug：用 debug 类 skill
- 写文章：用写作类 skill
- 做长期项目：把固定流程沉淀成自己的 skill
不要把 skill 当成魔法。它不能保证 AI 一定正确。它只是让 AI 按更稳定的方式工作。真正重要的还是我们自己要知道：这次任务需要什么级别的检查，什么地方必须验证，什么地方不能让 AI 自己发挥。
七、最后
我现在觉得，AI 用得好不好，不只看你用了哪个工具，也看你会不会给它安排流程。skill 则是把一些好用的方法保存下来，让 AI 下次还按这个方式做。对我来说，skill 的价值不是让 AI 显得更高级，而是让它更守规矩、更可控，也更像一个能长期配合的工作助手。
