为什么需要 Skills

为什么需要 Skills

本节摘要:AI 模型的默认输出是「全互联网的平均水平」——它不知道你的项目用 FastAPI 还是 Flask,不知道你的团队用 tabs 还是 spaces,不知道你要求所有 API 返回统一格式。每次新对话,这些「规矩」都归零。Skills(项目规范文件)解决的就是这个问题:把你的编程经验、团队约定、框架偏好写成配置,让 AI 在每次生成时自动遵守。本节讲清痛点、定义价值、建立「一次配置,永久生效」的认知。

一、AI 的「默认行为」问题

打开一个全新的 AI 对话,说「帮我写一个用户注册接口」。你会得到什么?

可能是 Flask,可能是 Express,可能是 Spring Boot——取决于模型训练数据中哪个出现频率最高。即使你项目里全是 FastAPI 代码,AI 也不知道,因为你没告诉它。

更隐蔽的问题:

• 你团队要求「错误统一用自定义 AppError 类抛出」,AI 用了 try-catch
• 你项目用 Pydantic v2 语法,AI 给了 v1 的 class Config 写法
• 你要求「组件用函数式」,AI 写了个 class 组件
• 你的目录结构是 src/modules/user/,AI 把文件放在了 src/user/

每次遇到这些,你都得纠正:「不对,我们用 XXX」。下次新对话,又得重来。

二、「规范丢失」的代价

算一笔账:

• 每次新对话平均纠正 2~3 次风格/框架问题
• 每次纠正花 30 秒(描述 + 等 AI 重新生成)
• 一天开 5 个新对话
• 一天浪费:5 × 3 × 30s = 7.5 分钟
• 一年(250 工作日):约 31 小时

这还只是「纠正风格」的时间。如果算上「AI 不了解项目结构导致生成代码放错位置、用错依赖」的返工时间,翻三倍不止。

三、Skills 的价值定位

Skills(项目规范文件)的核心价值:

一次配置,永久生效:

• 把「我们用 FastAPI + Pydantic v2 + SQLAlchemy 异步」写进配置文件
• 从此每次对话,AI 自动知道技术栈,不需要你重复

团队共享,新人即用:

• 规范文件提交到 Git
• 新同事 clone 项目后,AI 自动遵守团队规范
• 不需要「口口相传」或「看 Wiki」

减少审查成本:

• AI 输出风格一致,审查时不用纠结「这行不符合规范」
• 把审查精力集中在逻辑正确性上

关键概念:Skills 不是「让 AI 更聪明」,而是「让 AI 更了解你」。模型的推理能力不变,但它的输出从「通用最优解」变成了「你的项目的最优解」。

四、Skills 的三种形态

不同工具对「项目规范」的实现方式不同,但本质一样:

共同机制:这些文件/配置的内容会在每次 AI 对话开始时,自动注入到模型的上下文中。AI 看到的「第一条消息」就是你的规范——所以它会「天然遵守」。

五、什么该写进 Skills

不是所有东西都适合写进规范文件。判断标准:

该写的(跨对话稳定不变的约定):

• 技术栈和版本(「React 18 + TypeScript 5 + Tailwind」)
• 代码风格(「函数式组件」「camelCase 变量」「2 空格缩进」)
• 目录结构(「页面放 src/pages/,组件放 src/components/」)
• 错误处理约定(「统一用 Result 模式」)
• 禁止事项(「不用 any」「不引入 lodash」)

不该写的(每次对话不同的信息):

• 具体任务描述(「今天要做登录功能」)
• 临时上下文(「刚才那个 bug」)
• 大段代码示例(会占用宝贵的上下文窗口)

💡 技巧:规范文件控制在 500~1500 字以内。太长了 AI 反而「记不住」(上下文窗口被规范占满,留给实际任务的空间就少了)。精炼、明确、可执行——像写 linter 规则一样写 Skills。

本节要点回顾

1. 核心痛点:AI 不知道你项目的规矩,每次新对话都从零开始
2. 代价量化:每天浪费 7+ 分钟在重复纠正风格/框架问题上
3. 价值定位:一次配置永久生效;团队共享新人即用;减少审查成本
4. 本质:不是让 AI 更聪明,而是让 AI 更了解你
5. 三种形态:.cursorrules / .windsurfrules / Custom Instructions,机制相同
6. 内容原则:写稳定约定(技术栈/风格/结构),不写临时信息;控制在 1500 字内

知道了「为什么」,下一节讲「怎么写」——.cursorrules 的具体机制和最佳实践。