技术群里有人问了一个很典型的问题：
怎么让 AI 写界面的时候直接用 MyTextView，而不是默认给你来个 TextView？
这类问题，靠多补几句提示词 usually 没什么用。
因为问题不在于 AI 听不听话，而在于：
它根本不知道你这个项目的默认写法是什么。
所以更有效的做法，不是每次临时提醒，而是把项目规则整理成一套 skill，让 AI 在写代码前就先进入你的项目语境。
先简单说一下：SKILL.md、AGENTS.md、CLAUDE.md 是什么关系
不用把这几个名字想得太复杂，简单理解就行。
SKILL.md：写给 AI 的开发规则，重点是“这类代码应该怎么写”AGENTS.md：更像项目协作说明，告诉 AI 这个仓库怎么工作、代码放哪、优先看什么CLAUDE.md：某些特定 AI 工具会读取的规则文件，知道有这么个东西就够了
实际落地时，最值得认真写的还是 skill。
因为真正决定 AI 会不会写出 MyTextView 的，不是文件名，而是你有没有把规则、示例、校验写清楚。
skill 不要一上来就写成百科全书
很多人一想到给 AI 写规范，就容易走进一个大坑：
想先整理出一套完整到滴水不漏的项目规则，再开始用。
结果往往是：
- 想得很多
- 写得很慢
- 迟迟没开始
更实用的方式其实很简单：
先写一套最小可用的 skill，让 AI 先跑起来。
先把最痛的问题解决掉，比如：
- 不要再生成
TextView - 不要写死字符串
- 不要重复造轮子
- 不要绕过项目已有封装
skill 最开始不用大而全，先小而准。
一个常见的 skill 目录可以怎么放
比如可以这样组织：
.ai/ skills/ android/ SKILL.md examples.md checklist.md
这套结构就很适合 Android 项目，也很好理解。
1. SKILL.md
放规则本体。
也就是告诉 AI：
- 哪些必须做
- 哪些禁止做
- 默认优先什么
- 遇到例外情况怎么办
2. examples.md
放正反示例。
规则只告诉 AI“原则”，示例才告诉 AI“长什么样”。
很多时候 AI 之所以写偏，不是它没看规则，而是它不知道正确代码具体长什么样。
3. checklist.md
放生成后的自检清单。
也就是让 AI 在输出前自己再过一遍：
- 有没有用了不该用的控件
- 有没有写死资源
- 有没有复用现有实现
- 有没有偏离目录结构
这一步很像给 AI 装了个出门前安检门，能拦下不少低级偏差。
先看最核心的：SKILL.md 怎么写
原则就一句话
只写规则，不写空道理。
不要在里面写太多“为了提升代码一致性”“为了增强可维护性”这种大话。
AI 真正需要的是：
你到底要它怎么做。
一个最直接的实战例子
如果你最痛的点就是 AI 总写原生控件，那第一条 skill 就直接这么写：
## 基础控件使用规则项目中已有统一基础控件封装，新增 UI 时必须优先使用项目控件。强制要求：- 文本显示使用 `MyTextView`，禁止使用 `TextView`- 文本输入使用 `MyEditText`，禁止使用 `EditText`- 图片显示使用 `MyImageView`，禁止使用 `ImageView`- 按钮使用项目按钮控件，禁止使用系统 `Button`例外情况：- 第三方 SDK 强制要求原生控件- 用户明确指定使用原生控件默认情况下，一律优先使用项目控件。
这条规则有个很重要的特点：
它不是建议，是动作要求。
AI 看这种内容，比看一堆抽象原则更容易执行。
再看 examples.md 怎么写
很多人只写规则，不写示例。
结果就是 AI 虽然知道“要用项目控件”，但真正生成 XML 的时候，手一滑还是写成了 TextView。
这时候示例就很重要。
因为示例不是讲道理，是直接给模板。
比如可以这样写：
## 正确示例：文本控件```xml<com.xxx.widget.MyTextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/home_title" />
错误示例：禁止直接使用系统控件
<TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="首页" />
这里一举两得，顺手还把“不能写死字符串”也示范出来了。再比如输入框也可以补一条：```md## 正确示例：输入控件```xml<com.xxx.widget.MyEditText android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="@string/search_hint" />
错误示例
<EditText android:layout_width="match_parent" android:layout_height="wrap_content" android:hint="请输入内容" />
你会发现，examples 的作用很像给 AI 发参考答案。规则告诉它方向，示例告诉它姿势。---## `checklist.md` 怎么写这一层很多人最容易漏。但它其实特别好用。因为很多错误不是 AI 不会，而是它生成时没再检查一遍。所以 checklist 最好写成这种风格：```md## 输出前检查在输出代码前，请逐项确认：- 是否使用了 `MyTextView` / `MyEditText` / `MyImageView`- 是否直接使用了 `TextView` / `EditText` / `ImageView`- 是否存在写死字符串- 是否优先复用了项目已有组件- 是否遵循当前模块目录结构如果存在不符合项，先修正，再输出最终代码。
这类写法的关键，不是“提醒”AI，而是让它把检查动作当成输出流程的一部分。
很多时候，加一份 checklist，生成结果会稳不少。
skill 里除了控件规则，还可以写什么
当你把第一条“必须用 MyTextView”跑顺之后，就可以继续往里补。
最常见的几类内容有这些：
1. 复用规则
## 复用规则实现新页面、新弹窗、新列表项前，先搜索项目中是否已有类似实现。要求：- 优先复用已有页面结构- 优先复用已有 Adapter / ViewHolder- 优先复用已有 Dialog / Popup- 若已有实现可扩展，优先扩展，不要重复造轮子
2. 资源规则
## 资源使用规则禁止在代码或 XML 中写死资源。要求：- 文案使用 strings.xml- 颜色使用 color 资源- 尺寸使用 dimen- 不要硬编码 magic number
3. 基础能力接入规则
## 基础能力接入规则以下能力必须优先使用项目已有封装：- 网络请求- 图片加载- 日志- 埋点禁止绕过现有封装自行实现。
4. 目录结构规则
## 目录结构规则新增页面、组件、适配器、弹窗时，必须遵循项目当前目录结构。要求：- 页面代码放到对应 feature 模块- 通用组件放到 common/widget- 工具类放到已有 utils 或对应基础模块不要随意创建新的目录层级。
你不需要一次写完这些。
哪条最痛，就先补哪条。
验证 skill 怎么写，别只停在“写完”
很多人把文件一放就结束了，然后说 skill 没效果。
其实 skill 写完之后，最好立刻做一次验证。
最简单的验证方法就是找一个你最常见的开发场景，直接拿它试。
比如：
验证场景 1
让 AI 写一个带标题和输入框的搜索栏 XML。
你要看的是：
- 它是不是用了
MyTextView - 它是不是用了
MyEditText - 它有没有写死字符串
验证场景 2
让 AI 写一个 RecyclerView item。
你要看的是：
- 它有没有先参考已有 item 风格
- 它有没有遵守资源规则
- 它有没有乱造新的控件和工具类
验证场景 3
让 AI 写一个新页面。
你要看的是：
- 它有没有按目录结构放代码
- 它有没有优先复用已有组件
- 它有没有绕过项目基础封装
验证 skill 的关键不是看它“懂不懂”，而是看它“会不会在真实任务里照着做”。
如果没做到，不用推翻重写，直接补。
比如你发现它总是漏掉目录结构，那就加一条目录规则，再在 checklist 里加一条目录检查。
如果你发现它还是会偶尔写 TextView，那就在 examples 里再补两组正反示例。
这个过程不是一次定稿，更像连续调参。
话说回来，最省力的方式还是先让 AI 生成一版
很多人卡住的根源，是总觉得这套东西得自己从零整理。
其实完全没必要。
更高效的顺序应该是：
第一步：先让 AI 帮你生成一套基础版
你可以直接给它一句：
这是一个 Android 项目，请帮我生成一套 skill 目录，包含
SKILL.md、examples.md、checklist.md。重点约束基础控件、资源使用、复用规则、目录结构。先写基础版，不用太完善。
这样你会先拿到一个可以用的雏形。
第二步：拿去真实写代码
不要停留在“看看文档”。
直接让 AI 去写：
- XML
- 自定义 View
- RecyclerView item
- 页面布局
- 功能模块
第三步：记录它写偏的地方
比如：
- 还在写
TextView - 还在写死字符串
- 没复用现有实现
- 新建了不该建的工具类
- 目录放错位置
第四步：把这些问题补回 skill
发现什么问题，就补什么规则。
- 规则补进
SKILL.md - 正反示例补进
examples.md - 输出前检查补进
checklist.md
慢慢地，这套东西就会越来越像你们项目自己的“AI 开发习惯包”。
最后
所以，怎么让 AI 按你的风格写代码？
不是一开始就憋一份完美规范。
而是：
先让 AI 生成一套大概的代码风格规则。
先用起来。 先在真实开发里暴露问题。 再把这些问题按规范一点点补回去。
最后形成的，就不是一份泛泛的模板， 而是一套真正贴着你项目、贴着你个人写法的 skill。
它会越来越懂：
- 什么时候该用
MyTextView - 什么时候不能乱造轮子
- 什么时候必须走项目封装
- 你们项目里的“正确写法”到底长什么样
这套东西不是一次写出来的。
它是在你一次次使用 AI、一次次修规则的过程中，慢慢长出来的。
等它长成之后，AI 写出来的代码，就不只是“能跑”，而是会越来越像你们项目里原本的人写的。
互动一下
你现在最想先约束 AI 的是哪一类问题？
是总写 TextView，还是乱建工具类，或者老是不按项目目录放代码？
可以直接丢一个你项目里的实际场景，我帮你把它改成一条能直接放进 skill 的规则。
