说实话，现在的AI编程助手有时候挺让人抓狂的。你让它写个功Neng，它确实Neng跑，但那个代码风格……简直就像是刚毕业的实习生和十年老程序员混合双打写出来的。上周我就遇到这么个事儿，我想给“我的订单”页面加个下拉刷新，结果AI给我生成了一堆Neng跑但完全不符合我们团队架构的代码。这让我意识到，光有AI还不够，你得学会怎么“调教”它。

今天咱们不聊虚的，直接来点硬核的。怎么通过Rule、Skill和上下文工程，把AI从一个“只会写Hello World”的菜鸟，变成懂你项目架构、懂你代码风格的“资深搭档”。这不仅仅是效率提升的问题，这是关于如何释放十倍软件生产力的关键。

一、 Rule定规范：别让AI“自由发挥”

hen多开发者用AI的方式太简单粗暴了：直接把需求扔进去，然后期待奇迹发生。但现实往往是AI生成的代码虽然语法没问题，但充满了“异域风情”。比如在一个标准的Clean Architecture Android项目里它可Neng会直接在ViewModel里写网络请求，或者用你早就弃用的LiveData。

这时候，Rule 就派上用场了。Rule的核心作用，就是给AI划定“红线”和“底线”。

1. 分层治理：全局与局部

我在实战中发现，Rule不Neng一锅粥地写在同一个文件里。我现在的Zuo法是分两层：

第一层：根目录定团队规范。 这是所有代码必须遵守的“宪法”。比如强制使用Kotlin Coroutines，禁止LiveData，必须使用Hilt依赖注入。这部分规则放在项目根目录，无论是Cursor的`.cursorrules`还是Claude Code的`CLAUDE.md`，每次AI启动任务时dou会自动加载。成本几乎为零，但Neng保住代码的下限。

第二层：子目录定模块约定。 这就像是“地方法规”。比如你的`feature/cart`购物车模块可Neng采用了乐观geng新模式，而`feature/order`订单模块涉及分页逻辑。Ru果在根目录Rule里写死所有细节，AI在处理网络层代码时可Neng会莫名其妙地给你加个`@HiltViewModel`。所以把特定模块的规则放在子目录下按需加载，精准打击。

2. “禁止项”比“推荐项”geng管用

这里有个血泪教训：Rule里要写“不要Zuo什么”，而不只是“要Zuo什么”。

我Zui开始只写了“请使用StateFlow”，结果AI在某些场景下还是偷偷用了LiveData。为什么？因为它的训练数据里LiveData的例子太多了那是它的“舒适区”。后来我把Rule改成了“禁止使用LiveData，必须使用StateFlow”，违规率直接从30%降到了接近0。AI就像个调皮的孩子，你跟它说“建议吃蔬菜”，它可Neng还是会去拿糖；你直接说“不准吃糖”，效果反而立竿见影。

3. 工具选型：谁Zui听话？

聊了理论，来点真实的对比。我在同一个Android项目上，分别用Cursor、Claude Code、GitHub Copilot跑了一个月。

我的结论可Neng有点争议：Claude Code在遵守Rule方面Zuo得Zui好，但它的IDE集成体验不如Cursor丝滑。Copilot的`copilot-instructions.md`经常被“无视”，特别是当你的指令和它训练数据里的常见模式冲突时它那种“我不要你觉得，我要我觉得”的劲儿真的hen上头。

所以我的Zui优解是：Cursor配Claude后端。既享受了Cursor流畅的交互体验，又利用了Claude强大的指令遵循Neng力。这简直是黄金搭档。

二、 Skill封装任务：把重复劳动变成“一键生成”

Rule解决了“代码风格”的问题，但还有一个痛点：有些任务你每天dou在Zuo，每次dou要跟AI解释一遍流程。比如“给这个功Neng加个新的API接口”，你得说：先在ApiService加定义，再写Repository实现，然后写UseCase封装，再去DI模块绑定，Zui后写单测。六个步骤，每次dou像复读机。

这就是Skill 要解决的问题。Skill = 任务描述 + 步骤序列 + 上下文文件。把多步骤的开发流程封装成一句触发词。

实战配置：一个顶六个

来kan个实战例子。我给Claude Code写了一个自定义命令`new-feature`。用的时候只需要一句话：/new-feature Search com.app.search。

十秒钟，六个文件全部生成，而且代码风格和项目里其他模块完全一致。为什么？因为我在Skill里预设了步骤：

# .claude/commands/new-feature.md
创建新功Neng模块，参数：
- $FEATURE_NAME：功Neng名
- $PACKAGE：包路径
步骤：
1. 创建目录结构：ui, domain, data, di...
2. ViewModel 遵循根目录 CLAUDE.md 中的 MVI 模式
3. Screen 使用 Compose，指定 Design System 组件库路径
4. Repository 接口在 domain/，实现在 data/
5. Module 用 @InstallIn
6. 为 UseCase 生成单元测试

经过几个月的实战，这五个Skill的ROIZui高：

① new-feature创建完整功Neng模块。每次省30-45分钟脚手架时间。

② add-api新增API接口全链路。从手写15分钟压缩到2分钟。

③ compose-screen根据设计稿生成Compose页面。关键是指定好团队自己的AppButton、AppTopBar，而不是让AI瞎用Material3原生组件。

④ migrate-to-composeXML转Compose。这里有个坑，必须指定“保留原有业务逻辑，只改UI层”，否则AI会趁机重构你的ViewModel，改着改着就改出Bug了。

⑤ write-test生成单元测试。指定好测试风格。

三、 上下文工程：在Token预算里找平衡

好了现在AI有了你的规范，有了任务模板。但还差一个关键要素：它kan不到你的整个项目。

一个中大型Android项目轻松几万行代码。AI的上下文窗口再大——Claude 200K tokens、Gemini 1M tokens——也不可Neng把全部代码塞进去。何况塞进去也没用，信息太多等于噪音。上下文不是免费的，每一个塞进去的文件dou消耗Token，既有速度成本，也有金钱成本，还有质量成本。

所以我们需要上下文工程。我的策略是构建一个“上下文金字塔”，在AI完成任务所需的Zui小信息集合和上下文窗口容量之间找平衡。

L1：项目 Rule

根目录的CLAUDE.md或.cursor/rules。成本几乎为零，每次自动加载。这是地基。

L2：模块 Rule

子目录的规则文件。比如在`feature/cart/`下放一个CLAUDE.md，告诉AI这个模块用乐观geng新模式。这样AI在写购物车时既知道全局规范，也知道局部特性。

L3：相关文件引用

这是差距Zui大的一层。你要告诉AI：“写这个新ViewModel之前，先kan一下CartViewModel.kt的写法”。

手动`@`引用文件，或者在Skill里预设参考文件列表。我的经验L3的投入产出比Zui高。精心选择3-5个参考文件，比让AI漫无目的搜索全项目有效得多。比如让AI写新的Repository实现？给它Repository接口文件和一个Yi有的Impl参考就够了不需要把五个Impldou塞进去。

L4：全项目索引

用Cursor的codebase indexing或Claude Code的`codebase_search`工具。让AI自己搜索相关代码。效果好坏取决于你的项目结构和命名规范。Ru果命名乱七八糟，AI搜出来的东西可Neng也是南辕北辙。

四、 避坑指南：那些年我踩过的雷

写了大半年Rule，踩了不少坑，几条Zui痛的，希望Neng帮大家省点头发。

坑1：AI参考了错误的文件

有一次我让Claude Code写一个新的Repository，它自动搜索了项目里的相关文件Zuo参考——结果找到的是一个两年前的遗留模块，那个模块还在用RxJava。AI按RxJava风格写了一版，而我的Rule里完全没提“不要用RxJava”。

教训：遗留代码要么删掉，要么在`.claudeignore`或`.cursorignore`里屏蔽。把`build/`、`.gradle/`、`generated/`排除掉是常识，但我连`proguard-rules.pro`也排除了——因为AIkan到ProGuard规则会“灵感涌现”，开始帮你优化混淆配置，完全偏离正题。

坑2：Skill步骤太多导致中间出错

我写过一个7步的new-feature Skill，AI在执行到第5步时把第2步创建的文件包名写错了——因为上下文太长，它“忘记”了前面的步骤。

教训：单个SkillZui多5步。复杂任务拆成多个Skill链式执行。别贪多，AI的记性没你想的那么好。

坑3：Rule互相矛盾

根目录Rule写了“用Coroutines”，但数据库模块的Rule写了一个Room示例代码用了callback模式。AI在写数据库相关代码时就精神分裂了有时用协程有时用回调。

教训：模块Rule不Neng和根Rule矛盾，只Neng在根Rule基础上增加细节。Rule要有层级感，不Neng打架。

坑4：Rule不是越长越好

我一度把CLAUDE.md写到了2000多字。后来发现AI生成速度变慢了遵守度也没提高——信息过载。现在控制在500字以内，核心就那么几条，精简且明确。

教训：给模板，别给原则。说“代码要简洁”是废话，AI不知道你的“简洁”标准是什么。直接给一个你觉得好的ViewModel模板代码，比写十条原则有效十倍。AI是模式匹配的，给它模式它就Neng复现。

五、 持续迭代：让Rule和代码一起进化

Rule和Skill不是写一次就完事了。这是Zui重要的一步。

我团队现在有个习惯：每个PRRu果涉及到“手动修正了AI生成的代码”，就在PR description里标注一下修正了什么。每周五花30分钟回顾这些标注，geng新Rule。三个月下来我们的AI代码直接可用率从40%提升到了80%以上。

还有一个关键策略：写“项目地图”文件。

在根目录写一个`PROJECT_MAP.md`，用极短的篇幅描述项目结构和每个模块的职责。这个文件只有200 tokens，但它让AI对项目有了“鸟瞰图”。AI不会再把Repository放错目录，也不会在core/里创建业务逻辑。

# PROJECT_MAP.md
## 模块结构
app/          → 壳工程，只有 Application 和 MainActivity
feature/      → 业务功Neng模块
  cart/       → 购物车
  profile/    → 个人中心
core/
  network/    → Retrofit + OkHttp 配置
  database/   → Room 数据库
  designsystem/ → Compose 组件库
## 关键约定
- feature 之间通过 Navigation 解耦
- 数据流：Screen → ViewModel → UseCase → Repository → API

氛围编程与未来

我们常说“氛围编程”，这强调的是与AI的协同沟通。但我们不Neng盲目相信AI的输出，而是需要结合个人专业知识和经验进行谨慎评估，并在必要时进行修复。这种人机交互的模式，在AI编程元年不仅提升了开发者的编码效率，还大大减轻了大脑上下文切换的负担。

随着现代AI codingNeng力不断发展，开发者Ke以在明确架构设计和部署运维的前提下借助AI coding快速完成功Neng落地。简言之，就是让AI干脏活累活，我们负责把控方向和审美。

声明：这只是我个人在特定项目上的体验，不是严格基准测试。你的结论可Neng不同。但无论如何，尝试去配置你的Rule，封装你的Skill，管理你的上下文。这不仅仅是关于工具，geng是关于如何在AI时代重新定义“写代码”这件事。

下一篇我们聊一个geng有争议的话题：AI Code Review。AINeng不Neng当你的Code Reviewer？它的审查和人类Reviewer的审查有什么区别？我在团队里试了一个月AI自动Review——效果有惊喜，但也有意想不到的翻车。敬请期待。

—— 全文完 ——

---