如何让AI生成符合你风格的代码，关于风格定制的深度实践
怎么让AI写界面的时候直接用MyTextView，而不是默认给你来个TextView？
这类问题，靠多补几句提示词通常没什么用。因为问题不在于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项目：
SKILL.md：放规则本体，告诉AI哪些必须做、哪些禁止做、默认优先什么、遇到例外情况怎么办
examples.md：放正反示例。规则只告诉AI“原则”，示例才告诉AI“长什么样”。很多时候AI之所以写偏，不是它没看规则，而是它不知道正确代码具体长什么样
checklist.md：放生成后的自检清单，让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="首页" />这里一举两得，顺手还把“不能写死字符串”也示范出来了。
再比如输入框：
## 正确示例：输入控件
```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最好写成这种风格：
## 输出前检查
在输出代码前，请逐项确认：
- 是否使用了 `MyTextView` / `MyEditText` / `MyImageView`
- 是否直接使用了 `TextView` / `EditText` / `ImageView`
- 是否存在写死字符串
- 是否优先复用了项目已有组件
- 是否遵循当前模块目录结构
如果存在不符合项，先修正，再输出最终代码。这类写法的关键，不是“提醒”AI，而是让它把检查动作当成输出流程的一部分。很多时候，加一份checklist，生成结果会稳不少。
skill里除了控件规则，还可以写什么
当你把第一条“必须用MyTextView”跑顺之后，就可以继续往里补。最常见的几类内容有这些：
1. 复用规则
## 复用规则
实现新页面、新弹窗、新列表项前，先搜索项目中是否已有类似实现。
要求：
- 优先复用已有页面结构
- 优先复用已有Adapter / ViewHolder
- 优先复用已有Dialog / Popup
- 若已有实现可扩展，优先扩展，不要重复造轮子2. 资源规则
## 资源使用规则
禁止在代码或XML中写死资源。
要求：
- 文案使用strings.xml
- 颜色使用color资源
- 尺寸使用dimen
- 不要硬编码magic number3. 基础能力接入规则
## 基础能力接入规则
以下能力必须优先使用项目已有封装：
- 网络请求
- 图片加载
- 日志
- 埋点
禁止绕过现有封装自行实现。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写出来的代码，就不只是“能跑”，而是会越来越像你们项目里原本的人写的。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！