AI 写 Android 代码老翻车？我把移动端的 Harness 系统开源了
Harness Engineering · 移动端 AI 编程 · 开源工具
AI 帮我写的第一个 RecyclerView Adapter，编译过了，运行崩了。
找了一圈原因------它在 Adapter 里直接持有了 Activity 的引用，还自己 new 了一个 Handler。更离谱的是，它给 Item 设点击事件的时候手写了一个 Intent(context, TargetActivity::class.java)，完全无视项目里用 ARouter 管理路由的约束。我让它改个列表页，它顺带把模块依赖方向给我干反了。
真的，你花十分钟 review 出来的问题，比你自己写这个页面花的时间还多。
那之后我开始往项目里加规则文件------"用 ARouter，禁止直接 new Intent""数据层走 Repository 模式""Fragment 用 viewLifecycleOwner"。效果立竿见影，AI 的代码从"每行都要查"变成了"扫一眼就能过"。后来几个项目做下来，Android、iOS、鸿蒙都碰过，发现每次都在重复同一件事，就抽成了一个 CLI 工具。
最近打开技术社区，满屏 Harness Engineering。看完发现，我干的好像就是这个。
Harness 是啥，跟移动端开发有什么关系
Mitchell Hashimoto 最先提的，后来 OpenAI 和 Anthropic 各实践了一遍，到今年已经是圈内共识：Prompt Engineering 管"说什么"，Context Engineering 管"看什么"，Harness Engineering 管"在什么约束下运行"。
翻译成人话：模型是引擎，Harness 是缰绳。你不给马上缰绳，它力气再大也是乱冲。
Harness 的核心定义特别直白：Agent 每犯一个错，就加一条约束让它再也不会犯同样的错。 听起来像废话，关键在"工程化"------不是靠人脑记、口口相传，而是把约束写进 AI 每次运行都必须经过的检查点。
有团队做过对比：底层模型不动，只加 Harness（预检清单、循环检测、推理预算策略），Terminal Bench 从 52.8% 拉到 66.5%，排名从 30 跳到第 5。比换更大模型的效果还明显。
但 Harness 的讨论大多在通用编程层面。移动端的情况要惨烈得多。
通用编程的约束是"别写 SQL 注入""别搞内存泄漏"，这些东西模型训练数据里有，你提醒一句基本管用。移动端的约束全是项目特定的------你的项目用 ARouter 还是 Navigation、用 MVVM 还是 MVI、Retrofit 的 BaseResponse 字段名叫什么、RecyclerView 的 Adapter 继承哪个基类------这些信息不在任何模型的训练数据里。你如果不告诉它，它就只能猜。猜错了你买单。
对比一下：Web 端的约束密度相对低，很多通用规则就能覆盖；移动端几乎每一行代码都踩在项目特定的上下文上。 前者手写一份 CLAUDE.md 大概够用，后者光靠人脑记不住，靠手写维护不起。
ai_scaffold：移动端的 Harness
工具叫 ai_scaffold，已经发在 npm 上。名字叫 scaffold，干的事是 harness------取名的时候这个词还没火，现在改也来不及了。
工作方式两阶段。
先 CLI 扫。 npx ai-scaffold-pro 执行，十秒。读你项目根目录的特征文件------settings.gradle 就是 Android，检测到 NDK 还会追记 C++ 版本和 JNI 依赖，pubspec.yaml 就是 Flutter，hvigor-config.json5 就是鸿蒙。一个纯 package.json 的项目，能自动区分是 Next.js、React 还是 Node 后端。然后问你几个问题------用什么 AI 工具（Claude Code / Qoder / Codex / OpenCode 四选一）、项目名是啥、构建命令。完了在你的项目里生成一套骨架目录，规则、Agent、Hook、References 全部就位。
然后 AI 填。 把项目在 Claude Code 里打开（Qoder、Codex、OpenCode 也行），说一句"按 SKILL.md 初始化"。AI 开始读你的源码、理解架构、然后把骨架里的模板占位符全部替换成定制内容。
手写一份能覆盖这些场景的 CLAUDE.md，通常需要半天到一天，还得反复调试。ai_scaffold 的流程是十分钟跑完骨架，AI 再花几分钟填充------而且生成的内容是根据你项目的实际依赖动态定制的，不是一份通用模板。
说几个具体例子：
- 检测到你的
build.gradle.kts里有com.alibaba:arouter依赖，规则里自动加上"跨模块通信必须走 ARouter，禁止直接 new Intent 跳转"。没检测到？这条不出现。开头那个翻车故事里，AI 手写 Intent 跳转就是因为缺了这条约束。 - 检测到 NDK，生成的规则自动多出一整章 JNI 引用管理（
DeleteLocalRef时机、全局引用释放、线程安全），还额外生成一个cpp-memory-reviewAgent 专门扫 C++ 内存安全问题。没检测到 NDK 的项目完全不会看到这些，不会用无关规则污染你的上下文。 - 检测到 CodeGraph 已安装，框架切轻量模式------结构探索交给 CodeGraph 的
codegraph_explore工具（不耗 token），References 只保留语义内容（这个模块为什么这样设计、怎么用、踩过什么坑）。没装 CodeGraph？CLI 问你要不要现在装。
跟 lint 不一样。Lint 管"你写错了"，这个管"AI 不许这么干"。前者是代码质量工具，后者是行为约束系统。
跟 CodeGraph 搭着用
做第一版的时候，发现了很蠢的事：AI 为了找一个类的定义，要翻四五次文件。一个 40 模块的 Android 项目，光定位文件就能烧掉几万 token------而你实际想让 AI 做的工作还没开始。
CodeGraph 是个预索引的代码关系图工具，本地做结构化搜索，查类定义、方法签名、调用关系，跟 IDE 里按 Ctrl+Click 差不多快。我把它集成进 ai_scaffold 的逻辑很简单：
- 你装了 CodeGraph → 框架切轻量模式，结构探索零 token，References 只存语义信息
- 你没装 → CLI 问要不要装，确认了就自动执行安装，拒绝就切回完整模式
背后的想法：别假装一个工具什么都能干。 结构信息放 CodeGraph，语义信息放 References，约束规则放 Harness。各管各的，合在一起是完整体系。
跟 openspec、superpowers 的关系
被问最多的问题，统一说清楚。
openspec 管"做什么"------spec 驱动，保证方向正确。superpowers 管"怎么做"------TDD、multi-agent review 提升执行质量。ai_scaffold 管"在哪跑"------在一切开始之前，让 AI 先认识你的项目。
三个东西可以同时用，不互斥。但它们的位置是有先后顺序的：应该先跑 ai_scaffold 建好规则基础设施，再让 openspec 管需求，superpowers 管质量。
但如果你是纯 Web 前端，真不一定需要。 Web 项目的平台特定约束密度远低于移动端------没有"RecyclerView Adapter 必须 ViewBinding""Fragment 用 viewLifecycleOwner""ARC 下 retain cycle 必须 weak self"这类密密麻麻的领域知识。一个手写的 CLAUDE.md 可能就够用。
说点真话
开源项目的文章容易写得像销售页。列一下目前的短板，你看了再决定试不试。
平台模板不够均匀。 Android 和 iOS 的规则最完善------我在这些平台踩的坑够多。鸿蒙、Flutter、RN 的模板相对薄。鸿蒙开发者用了可能会觉得一般。接下来的计划是拉社区贡献者进来，靠一个人踩坑永远覆盖不全。
References 没有质量校验。 AI 读源码生成的模块文档可能遗漏 KDoc 没写但代码逻辑里实际存在的设计意图。规划中的是加一层抽查机制------生成完之后抽 20% 的模块让 AI 自检，对比源码验证覆盖率。
没有效果度量。 规则跑起来之后，AI 代码质量到底改善了多少？Agent 触发多少次？拦截多少次违规？目前只有 Hook 脚本做简单的文件修改计数。下一步想做的是把 Hook 采集的数据汇总成报告，至少让你看到"这条规则被触发了 12 次"这种粒度。
还有一个 Harness 圈子里正在吵的问题：这些东西两年内会不会被模型吃掉？
Anthropic 已经在拆自己搭的组件了------Context Reset 删了，Sprint Contract 也拆了。逻辑是：模型每次升级，都意味着有些之前靠外部约束解决的问题，模型自己能处理了。那对应的约束就该消失。
所以一个 Harness 系统最重要的能力，可能不是"加了多少约束"，而是"知道什么时候该拆哪个"。追踪模型能力的边界变化，动态调整约束层厚度。
这个能力，ai_scaffold 目前还做不到。但这也是我想做效果度量的原因------没有数据，就无法判断哪些约束在失效。
试试看
Harness 讨论很多，但真正把移动端 Harness 做成能跑的工具的，不多。
ai_scaffold 不是看了理论之后照着做的------是被 AI 在项目里坑了半年，自己摸索出来的。后来发现这条踩出来的路恰好叫 Harness，就开源了。
如果你在 Android / iOS / 鸿蒙项目里用 AI 写代码，且被它的"自由发挥"折磨过------试试。如果已经在用 openspec 或 superpowers------叠上去，不冲突。如果是纯 Web 前端------可能不需要，别为了用工具而用工具。
npx ai-scaffold-pro项目地址： github.com/Jorgejie/ai...
npm： ai-scaffold-pro
跑完之后，把你项目的规则目录结构截图发到 issue 里------我想看看不同项目的约束差异到底有多大。踩坑的人越多，姿势越丰富，方向才越清楚。
本文首发于 GitHub，转载请联系作者。