夜雨聆风
很多人一提 AI 写 App，第一反应是：给它一段需求，让它改代码，让它跑一下 build，没报错就算完成。
这在小项目里可能能用。但只要进入真实 Android App 开发，事情就没那么简单了。
Android App 不是一个普通脚本，也不是一个网页组件。它有 Gradle、JDK、Android SDK、Manifest、权限、生命周期、UI 适配、数据库迁移、网络状态、签名配置、发布渠道、设备碎片化。
所以，Android App 的 Agent Harness，不能只是一句：“改完以后跑一下 build。”这太薄了。
真正可用的 Android Harness，要解决的不是“AI 能不能写代码”，而是：AI 能不能在清楚边界里，稳定、安全、可验证地交付 App 改动。
一、什么是 Android 开发 Harness？
Harness 可以理解成 Agent 的运行底座。Prompt 告诉 Agent 要做什么，Harness 告诉 Agent 怎么安全地做。
在 Android 项目里，一个好的 Harness 至少要告诉 Agent：这个项目是什么架构，有哪些模块，用的是 Compose 还是 XML，依赖怎么管理，构建命令是什么，测试命令是什么，哪些文件不能碰，哪些改动必须人工确认，怎么判断任务完成，怎么处理失败和回滚。
如果没有 Harness，Agent 就只能靠猜。它可能乱改 Gradle，可能乱加依赖，可能改 Manifest 权限，可能碰签名配置，可能把 UI 写得能编译但不能用，可能修了一个 bug，又引入一个生命周期问题。
所以 Android Harness 的本质，是给 AI 开发者画边界、给验证流程立规矩、给长期交付留状态。
二、最小可用 Harness 长什么样？
一个最小可用的 Android Harness，可以从几份文件开始：android_project.md、commands.md、task_contract.md、quality_gates.md、review_checklist.md。
android_project.md 告诉 Agent 项目是什么。比如语言是 Kotlin，UI 是 Jetpack Compose，架构是 MVVM，依赖注入用 Hilt，网络用 Retrofit，数据库用 Room。还要写清楚模块结构。
commands.md 告诉 Agent 怎么构建和测试，比如 ./gradlew :app:assembleDebug、./gradlew testDebugUnitTest、./gradlew lintDebug、./gradlew ktlintCheck、./gradlew detekt。
task_contract.md 告诉 Agent 每次任务怎么做：先读项目说明，再识别影响模块，只做最小必要修改，不改无关文件，不新增依赖，不改 SDK 版本，不改签名配置，改完必须跑检查。
quality_gates.md 定义完成标准：Build 必须通过，Unit Test 必须通过，Lint 不能新增 fatal，不能改生成文件，不能改无关文件，UI 改动要检查小屏和深色模式，数据库改动必须说明 migration。
review_checklist.md 则用于复查。尤其是 Android 这种运行时问题很多的平台，能编译不代表没问题。
三、为什么最小 Harness 还不够？
如果只是单 Agent、单任务、人工触发，上面这套已经能用了。比如让 Agent 修一个 UI bug，改一个列表刷新问题，补一个 ViewModel 单测，调整一个接口字段。
但如果你想让 Agent 进入更真实的开发流程，比如长期任务、并行任务、CI 接入、半自动交付，那就不够了。
因为 Android 项目有几个特别麻烦的问题：环境不一致、设备碎片化、权限和隐私敏感、UI 需要真实验收、发布配置风险极高、数据库和本地数据不能随便动、多 Agent 容易改同一批文件、长任务不能只靠一次会话记忆。
所以完整版 Android Harness，还需要继续补几层。
四、完整版要补十层
第一层是环境锁定。JDK、Gradle、AGP、Kotlin、compileSdk、minSdk、targetSdk、NDK、Android Studio、模拟器镜像版本，都应该写进 environment.md。
第二层是风险分级。改一个按钮文案，和改登录权限，不是一个风险等级。低风险可以自动推进，高风险必须人工确认。
第三层是测试矩阵。Android 不能只跑一个 build，更完整的测试矩阵应该包括 Debug build、Unit test、Lint、Ktlint / Detekt、Instrumented test、Screenshot test、Compose UI test、Release build smoke test、Baseline Profile 检查。
第四层是设备矩阵。小屏、大屏、低版本 Android、当前主流 Android、深色模式、中文、英文、横竖屏，都可能影响体验。
第五层是 UI 验收。Android UI 不是能编译就行，尤其是 Compose 或 XML 页面修改，必须看效果。
第六层是安全与隐私边界。不能记录 Token，不能把用户隐私写进日志，不能无理由新增权限，不能把敏感数据明文落盘，不能绕过证书校验。
第七层是发布边界。不允许自动发版，不允许自动上传应用市场，不允许擅自修改 signing config，不允许擅自修改 versionCode / versionName。
第八层是状态和记忆。长任务必须有 progress.md、loop_state.md、known_issues.md、test_results.md。
第九层是并行隔离。多个 Agent 同时做 Android 开发，就必须用 Worktree 或分支规范。
第十层是回滚机制。Agent 改代码必须可回滚，任务开始前记录状态，任务结束后输出 diff、测试结果和剩余风险。
五、测试矩阵和设备矩阵，是 Android 的硬要求
一个好的 Harness，不是每次都跑最重测试，而是知道什么任务该跑什么测试。
如果只是改纯 Kotlin 工具函数，跑 unit test 可能够了。如果改 UI，就要跑截图或 UI 测试。如果改数据库，就要跑 migration 测试。如果改网络，就要检查错误态、空态、超时态。如果改 release 配置，就必须人工审查。
设备矩阵也一样。Agent 不一定能自动覆盖所有设备，但它必须知道什么场景需要设备验证、什么验证没跑、剩余风险是什么。
这比一句“已完成”可靠得多。
六、安全、隐私和发布边界，必须单独成章
Android App 和用户设备、权限、数据关系太近。所以安全与隐私必须单独成章。
Harness 里要明确：不能记录 Token，不能把用户隐私写进日志，不能无理由新增权限，不能把敏感数据明文落盘，不能绕过证书校验，不能随便读取剪贴板，不能扩大定位、相册、麦克风、蓝牙、通知权限，不能提交密钥、证书、打包凭据。
发布相关的东西也必须特别严格。Agent 可以准备 release notes，可以生成变更摘要，可以检查构建是否通过，可以提醒哪些配置需要人工确认。
但不能自己发布。这是边界。
七、状态、并行和回滚，决定 Harness 能不能长跑
如果只是一次任务，Harness 文件够用。但如果要做长任务，就必须有状态文件。
这些文件记录当前做到哪、已经改了什么、失败过什么、哪些测试通过、哪些测试没跑、哪些风险还没处理、下一轮应该继续哪里。
否则 Agent 一旦换会话，就会失忆。长任务不能靠聊天上下文，长任务必须靠外部状态。
如果多个 Agent 同时做 Android 开发，就必须考虑隔离。每个 Agent 一个独立工作区，每个任务一个分支，每个任务声明影响模块，不要多人同时改同一个核心文件，合并前统一跑测试和 review。
真正的 Harness，不只是让 Agent 往前冲，还要保证它能停下来、退回来、说清楚。
结语：Android Harness 的目标不是让 AI 更自由，而是让 AI 更可靠
一个 Android App 开发的 Harness，怎样才算完善？我的判断是：最小版可以支持单 Agent、单任务、人工触发；但完整版要支持环境锁定、风险分级、测试矩阵、设备矩阵、UI 验收、安全隐私边界、发布边界、状态记忆、并行隔离、回滚机制。
这才是可以进入真实 Android 项目的 Agent Harness。
AI 写代码不是难点。真正难的是：它改得对不对，跑得稳不稳，有没有越界，能不能验证，能不能回滚，能不能长期接着干。
Android App 开发的 Harness，本质上不是一套提示词。它是一套工程纪律。
Prompt 告诉 AI 要做什么。Harness 告诉 AI：在真实工程里，怎样安全地把事情做完。
