嘿，朋友，你有没有试过让 AI 来写 Android 代码？

说实话，2026 年了AI 写代码这事儿Yi经不是什么新鲜事。但问题是你给它喂的上下文够不够好？这才是关键。就像你跟它说“帮我写个登录页”，它可Neng直接给你整出一个完整的电商系统来哈哈。

我们团队Zui近在搞一个 Android 组件化项目，想让 AI 来帮我们写代码，结果发现——不对不对，应该是：AI 真的Neng帮上忙吗？

AI 写代码，上下文是命门

先说个大实话：AI 的Neng力，真的不是无限的。它强不强？当然强。但你得给它合适的上下文，不然它就像个刚进公司实习的小朋友，啥dou不懂，全靠猜。

我们一开始也是这么干的，结果呢？AI 写出来的代码，kan着还行，但一跑起来就各种问题。为啥？因为它不知道我们项目里那些“潜规则”。

比如我们项目里有个叫 ImageLoader 的类，AI 却随口编了个 ImageUtils.load，你懂的，这玩意儿根本不存在。等你 review 完了才发现，害，白忙活。

规则体系才是王道

所以我们后来搞了一套规则体系，专门告诉 AI：你不是不会猜吗？那我直接把规则写清楚，你照着Zuo就行。

我们搞了个叫 AGENTS.md 的文件，放在项目根目录，告诉 AI 这个项目长啥样，什么情况下该读哪份规则。这玩意儿就像个“调度器”，不是让你把所有规则dou塞给 AI，而是按需加载，省上下文窗口，还Neng保证规则不乱。

比如用户说“这个页面的生命周期类似 page_start，但跟埋点无关”，AI 就别去触发埋点规则了。我们搞了个“否定场景过滤机制”，关键词匹配只是初筛，还得结合用户意图Zuo二次判断。比如关键词出现在否定语境、类比语境、Yi关闭语境中时就不触发。

这设计让误触发率明显下降。geng重要的是用户觉得 AI 是在“理解”他们，而不是机械响应。这体验，直接拉满了。

规则分层，让 AI 真正“懂”项目

我们把规则分成了三层：

调度层就是那个 AGENTS.md，告诉 AI 什么时候该读哪份规则。

约束层比如 car_project_rule.md，定义了项目开发的主规则，包括架构、命名、反模式啥的。

参考层比如 references/ 和 skills/，记录项目里真实存在的类名、方法名、路径、依赖关系，还有各种技Neng文档，比如埋点、性Neng优化啥的。

这样分层的好处是啥？就是让 AI 真正知道项目长啥样，而不是靠猜。比如你让它写个页面它就知道该用哪个类、哪个方法，而不是自己瞎编。

AI 写代码的“反幻觉”机制

AI Zui容易犯的错是“幻觉”——就是它自己编一些项目里根本不存在的类名、方法名。我们怎么解决的？

我们搞了个 references/ 目录，每个模块一份文档，记录真实存在的类名、方法名、路径。比如基础库模块，它的文档会列出 application/arouter/data/amber/widget/utils/ 等所有子目录，以及每个目录下的关键类名和职责。

这样 AI 就不会自己瞎编了。我们还搞了个 conventions.md，用“错误示例 vs 正确示例”的方式，告诉 AI 什么不NengZuo。比如“不要硬编码 dp/sp 值”、“不要用 Gson 而非 GsonUtil”。

这种“反面教材”式的呈现，对 AI 的效果比纯正向陈述geng好——AI geng容易记住“不要这样Zuo”的明确边界。

自查清单 + 自动化测试 = 稳定输出

我们还搞了个自查清单，每份规则文档末尾dou有一份可验证的检查点。比如：

是否使用了 Gson 而非 GsonUtil

是否硬编码了 dp/sp 值

这些检查点Ke以Zuo成 lint 规则或自定义脚本，AI 生成代码后立即检查，不依赖 AI 的“自觉”。这样就Neng保证生成的代码质量。

自查清单还有一个额外的好处：它Ke以作为团队 Code Review 的辅助 checklist，人机共用。你懂的，这玩意儿就是让 AI 和人用同一套标准。

规则冲突？我们也有招

项目里同时有通用编码规范、TV 焦点规则、埋点规范、性Neng规范，每次dou全量加载，AI 容易把不同规则搅在一起。我们怎么解决的？

我们搞了个“规则优先级”机制。比如 car_project_rule 和 tv_focus_rule 对同一件事有不同约束时AI 会自行判断优先级。一旦规则多了冲突不可避免，需要一套显式的优先级或合并机制。

我们还搞了个 Git Hook，每次 git commit 后会记录本次提交的信息。这样Zuo的目的有三：

记录规则使用情况

记录 AI 生成代码的修改轮次

记录不同规则加载方案的效果对比

这个设计目前还比较轻量，但方向是对的——规则体系本身也需要迭代，而迭代需要数据。

一下

回顾Zui近的实践，我们认为一个核心认知是：AI 辅助开发的效果，上限不是模型的Neng力，而是你给它的上下文设计。

我们出的这套三层体系+ 否定词保护 + References 反幻觉 + 自查清单闭环，是这个思路的一个具体实践。它不是银弹，但确实让 AI 在复杂 Android 项目中的可用性提升了一个台阶。

这些点的优先级取决于团队规模和 AI 使用深度。小团队Ke以先忽略，几十人的团队可Neng需要认真考虑。

Zui后咱就是说AI 写代码这事儿，2026 年真的可行吗？

答案是：可行，但前提是——你得给它一个靠谱的规则体系，让它知道该怎么Zuo，而不是瞎猜。

---