过去一年多，AI Coding 工具（Claude Code、Codex 这些）逐渐从”帮我写点代码”变成了真正的团队成员。但有个问题一直卡着我：
AI 并不懂我的项目。
每次让它写点东西，总要多费不少口舌解释上下文。有没有办法让 AI 快速理解技术栈、项目结构、开发规范？答案就是 autoskills。
autoskills 是什么
一句话：它是个脚手架工具，给项目自动生成 AI 可读的 skills。
npx autoskills
跑一下，它会扫描项目（读 package.json、Gradle 配置之类的东西）、判断技术栈、然后生成一批 skills 文件写到项目里。
它装在哪？
不是全局装的。
很多人第一反应是”这工具是不是要全局安装”，其实不是。它是跟着项目走的——执行的时候临时用 npx 跑，但生成的文件会写进当前项目目录。
生成后的结构大概是这样：
your-project/
├── .claude/
│ └── skills/
│ ├── react.md
│ ├── node.md
│ └── testing.md
├── CLAUDE.md
skills 文件是可以提交到 git 的，团队其他人拉下来也能用。这是它和全局工具最大的区别。
为什么这个设计值得注意
用 AI Coding 工具写代码一段时间后，我发现几个痛点：
- AI 写出来的代码风格飘忽不定
- 不符合项目已有规范
- 每次新开对话都要从头解释项目背景
autoskills 解决的是”上下文沉淀”这件事。它把技术栈知识、最佳实践、常见用法这些信息，固化成 AI 能读懂的文件。
但它有短板
autoskills 再强，也有个天然局限：它只懂通用的技术知识，不懂你的业务。
alarm-domain 是什么、告警怎么触发和上报、系统整体架构长什么样、团队有哪些约定——这些 AI 没法自己猜出来。
所以正确的用法是：autoskills 负责通用的技术部分，你自己补充业务理解和架构规范。
进阶：构建分层 Skill 体系
如果只用 autoskills，用到的大概是 30% 的能力。
我目前的做法是把 skills 分成几层：
.claude/
├── skills/
│ ├── framework/ # autoskills 生成
│ ├── domain/ # 业务理解（自己写）
│ ├── architecture/ # 系统设计（自己写）
│ ├── coding/ # 代码规范（自己写）
│ └── ops/ # 排查/运维（自己写）
各层职责：
| 分类 | 作用 |
|---|---|
| framework | React / Spring / Node 等框架知识 |
| domain | 业务逻辑，最核心 |
| architecture | 系统设计思路 |
| coding | 代码风格规范 |
| ops | 排查问题的方法 |
我目前在写的有 alarm-domain skill、business-domain skill、code-review skill，都是属于 domain 和 coding 这两层。
这套东西建好之后，AI 不再只是”帮我写代码的工具”，而是”理解我项目的工程师”。差别挺大的。
相关资源
- GitHub 仓库：midudev/autoskills — 查看源码、文档和示例
- 官方网站：autoskills.sh — 获取最新信息和下载
用 AI Coding 一段时间后，我意识到真正的核心不是模型能力，而是上下文工程——怎么把项目知识结构化地沉淀下来，让 AI 能真正读懂。
autoskills 的价值本质上不是生成几个文件，而是帮你建立一套”AI 可读的工程知识体系”。
小结
autoskills：
- 适合做项目级 AI 能力注入
- 自动生成技术类 skills
- 不负责业务理解
用它 + 自己写的 skills，效果才是完整的。目标就是让 AI 变成一个既懂技术规范、又懂业务逻辑的长期队友。