写 Android 需求最怕什么怕 AI 拍着胸脯给你一段看起来无懈可击的代码接手过来一跑就崩。最近我把 Harness Engineering 的思路搬到 AI 辅助 Android 开发上实测了几周翻车率肉眼可见地降下来了。这篇就聊聊我怎么做约束、怎么定提示词、怎么把构建和测试接进流程以及在真实项目里用 AI 搞 Android 开发时踩过的几个坑。先交代一下背景我日常的活儿大头就是 Android 客户端从权限申请到生命周期管理、从 Gradle 构建到各种厂商 ROM 适配事杂且碎。之前直接用 AI 对话窗口帮我写业务代码最崩溃的一次是让它给我补一个“录音权限申请”的小模块结果它顺手把我 Activity 的布局文件改了一版还偷偷加了个网络请求一跑直接崩。那之后我开始认真研究怎么“驾驭”AI 而不是“被 AI 带着走”Harness Engineering 就是这个阶段最大的收获。它不神秘核心就一句话给 AI 戴好缰绳再让它撒开蹄子跑。这篇内容适合三类人想用 AI 提效但总在返工的 Android 开发、刚接手 AI Agent 工作流概念但不知道怎么落地到具体工程的开发者以及那些对“AI 生成代码到底靠不靠谱”持怀疑态度的技术管理者。我会把这套方法拆成可以直接抄作业的模板和命令不用你再去翻一堆英文文档。1. Harness Engineering 是什么先把它揉碎了再说1.1 别被名字吓到它解决的是 AI 产出的“不可控”问题Harness 这个词的本意是“马具、挽具”放在工程语境里就很形象了——马虽然力气大跑得快但你得给它套上嚼子和缰绳它才能按照你想要的路线走。Harness Engineering 说白了就是一套“给 AI 套缰绳”的方法论专门用来处理大模型产出不稳定、容易一本正经地胡说八道、以及经常忘记上下文约束这类问题。我发现很多人对 AI 编程最大的误解是把大模型当成一个“无所不知的编译器”你给它一句话它就该吐出来一段完美的代码。但实际上大模型本质上是“概率语言模型”它是在预测当前上下文下最可能出现的后续内容它并不真正理解你的 Android 工程结构也不清楚你有没有处理异常分支更不知道你项目的 minSdk 到底是多少。你说一句“帮我写个录音功能”它可能默认给你用 MediaRecorder可你的需求其实是想拿到原始 PCM 数据做实时分贝分析这就是“不可控”的第一个来源。Harness Engineering 的思路恰恰是反向操作既然 AI 天然不稳定那我们就通过工程手段把它不稳定带来的风险锁死在可控范围内。具体来说就是四件事输入侧做约束、过程侧做编排、输出侧做验证、闭环侧做反馈。每一件我都单独展开说这套框架放到 Android 开发里几乎是无缝对接。1.2 从“让 AI 自由发挥”到“给 AI 铺轨道”我最早用 AI 写代码就是打开一个聊天窗口把需求往那一扔等它输出。这种“自由发挥”式用法的问题在于你和 AI 之间缺少一个明确的“阶段划分”。它在你还不确定方案的情况下就把代码全写了一旦方案选型不对后面全是无用功。Harness Engineering 的做法完全不同它要求你把一个大任务拆成一段段有明确输入输出的小步骤每一步都设置检查点。拿 Android 开发来说一个完整需求应该过这样几条轨道需求澄清阶段AI 先用自然语言复述它理解的业务需求包括涉及的页面、交互、边界条件你要检查它有没有理解偏。技术方案阶段AI 输出实现方案包括用到的 API、权限声明、线程模型、生命周期处理你要评审方案是否合理而不是急着看代码。代码生成阶段在方案确认后才让 AI 按模块生成具体代码并且要求它遵循你给定的代码风格和已有工程结构。验证反馈阶段把 AI 生成的代码跑进构建、单测、lint、真机冒烟测试把报错信息原样贴回去让它修直到全部通过。这套流程本质上和传统开发没什么区别需求评审、技术设计、编码、测试一步不少。只是原来这些动作靠人和文档现在靠提示词和工具链把 AI 限制在轨道里。我实测下来最大的好处是即使 AI 到底层代码还在犯蠢你至少能早早在方案阶段就发现而不是等它写完几百行代码再推倒重来。1.3 为什么这套思路在 Android 开发里特别对路Android 开发大概是当前所有客户端技术栈里“隐性约束”最多的一类。Gradle 构建脚本、AndroidManifest 里的权限声明、Activity 和 Fragment 的生命周期、进程被杀之后的恢复机制、不同厂商 ROM 对后台的限制、targetSdk 升级引入的新行为变更……这些东西密密麻麻任何一个弄错都是运行时才能暴露的雷。偏偏大模型在生成代码时最不擅长的就是“记得住这些边界”。我试过让 AI 给我生成一个 “Android 13 上请求通知权限”的代码它给我写出了 NotificationManagerCompat.requestPermission 这种压根不存在的 API还一本正经地加了注释说“这是 Android 13 新增的用法”。这就是典型的“幻觉”它训练数据里见过 Android 13 权限相关的内容但没有精确到 API 名于是自己编了一个。如果你不用 Harness Engineering 的约束流程这种幻觉代码很容易混进工程里。但如果你强制 AI 先写方案、再锁定 API 级别和权限声明、最后过构建检查这类问题在编译期就会被拦截下来。这也解释了为什么同一个大模型有人拿它写 Android 需求天天救火有人却能把需求快速落地——差别不在模型在有没有给模型套上适合 Android 生态的缰绳。2. AI 做 Android 需求最常见的三类翻车现场2.1 翻车场景一需求理解发散AI 自己给自己“加戏”这是我最早期踩得最狠的坑。需求明明只说了“在设置页加一个开关控制某个功能的启停”AI 上来就给你重排了页面布局给按钮加了动画还顺手定义了好几个你用不到的 ViewModel。这些“加戏”看起来是加分项实际上在真实工程场景里是灾难——你没法确定它改动了哪些你没注意到的文件更没法保证它新增的东西符合你的产品规范。问题根源在于提示词里只给了“做什么”没给“不做什么”。大模型在生成内容时天然的倾向是“尽量完整”它会把一个简单需求脑补成一整套方案。对应到 Harness Engineering 的输入侧约束你必须在需求描述里显式声明不改动哪些文件、不引入哪些依赖、不新增与需求无关的 UI 样式、不做超过当前场景的设计抽象。没有这些“负面约束”AI 一定会飘。我见过不少团队的 AI 辅助开发流程里根本没有这一步提示词写得非常口语化什么“帮我改一下这个页面”AI 当然只能猜。猜对了是运气猜错了是常态。所以第一条教训就是明确划出边界比描述目标更重要。2.2 翻车场景二Android 生态约束被无视API 乱用到离谱Android 的生态约束可以写成一本书版本碎片化、权限模型变更、后台执行限制、Activity 启动模式、Fragment 重建机制、资源命名规范、Gradle 依赖冲突……每一条都能让 AI 生成一段看起来正确但实际无法运行的代码。举几个我实际遇到过的例子。第一个是权限模型AI 在生成录音、定位、通知相关代码时经常只写 Manifest 声明忘了 Android 6.0 之后必须动态申请权限就算记得动态申请也经常没处理用户拒绝和“不再询问”的情况。第二个是后台服务限制让它生成一个后台播放录音的服务它直接给你写个普通 Service 然后 onStartCommand 里开个死循环完全没考虑 Android 8.0 之后启动后台服务受限、Android 14 之后前台服务必须声明类型的约束。第三个是 API 兼容性它默认 targetSdk 是旧版本直接用了已经废弃的 API编译期还好上了新设备就崩。这些问题的共性在于AI 只“知道”这些 API 存在的片段但不知道在你的工程上下文里该用哪一个版本、该配什么权限、该做哪些兜底。所以你必须在提示词和验证流程里把“Android 生态上下文”固定住——比如把 targetSdk、minSdk、相关官方文档摘要、工程里的权限声明统统喂给它同时把构建和静态检查作为硬性关卡。这样才能把“常识性的幻觉”挡在门外。2.3 翻车场景三验证全靠肉眼回归测试形同虚设第三个翻车点其实是最要命的因为它直接决定了 AI 能不能稳定生产力——没有自动化验证闭环AI 每改一次代码你都要人工把整个 App 点一遍改多了人必然疲劳疲劳了就会漏测。我见过很多用 AI 写代码的开发者流程是让 AI 改代码 → 人工跑一遍编译 → 编译过了 → 自己手动点几下 → 没问题收工。但这个流程有个巨大的漏洞编译过只能说明语法和类型没问题说明不了逻辑正确、更说明不了兼容性达标。AI 改了一个工具类的判断逻辑编译过了但那三个调用点可能全炸了你没点到的页面就是炸弹。Harness Engineering 最核心的实践之一就是“让验证成为流程的一部分而不是事后行为”。放到 Android 工程里至少要包含三层单元测试覆盖纯逻辑比如分贝换算、数据解析、状态机流转、Android 特定测试覆盖组件交互比如权限弹窗、Activity 启动参数、真机冒烟覆盖关键路径比如录音开关能不能亮起来。这三层都跑到AI 的改动才算通过验收。不做这一步所谓的“AI 提效”只是在给未来埋雷。2.4 为什么这些翻车可以避免这三类翻车本质上都不是“AI 能力不够”而是“工程流程缺失”。你带着 Chat 聊天的思维用 AI得到的必然是聊天级别的可靠性你带着工程化的思维用 AIAI 才能产出工程级别的结果。你想一下传统开发流程为什么不容易翻车因为有需求评审、设计评审、CR代码评审、CI 流水线、测试用例。这些环节没有一个是依赖“某个人特别强”的靠的是机制把错误拦截住。AI 辅助开发完全可以沿用这套机制只是把原来写代码的那个人换成了 AI评审和执行的标准一点都不能降。Harness Engineering 做的就是把这套机制显性化变成你调用 AI 之前的固定动作。所以我现在的心态已经变了我不再追求“让 AI 一次性写对”而是追求“让 AI 在约束和验证的双重轨道里快速迭代到正确”。一次写不对外太正常了关键是怎么低成本地让它修正而不是让它带着错误一路狂奔到离题万里。3. 我的四层约束体系用 Harness Engineering 管 Android 需求3.1 第一层约束输入侧——把需求“喂”给 AI 的正确姿势输入侧约束是所有约束里投入产出比最高的一个你只需要在敲提示词的时候多花两分钟后续的返工成本能省下一大半。我现在给 AI 下需求基本用下面这套结构化模板你可以直接复制改一下项目信息就能用。【角色】你是一名熟悉 Android 生态的高级开发工程师擅长 Kotlin/Java熟悉 Gradle、生命周期、权限模型、常见兼容性问题。 【目标】实现一个功能xxx一句话说清。 【页面入口】该功能挂在 MainActivity 的某个按钮上可附文件路径。 【边界——必须做】 1. 使用 Android 官方推荐的 API优先考虑 targetSdk 34 兼容性。 2. 需要动态申请的权限给出完整申请流程并处理拒绝场景。 3. 处理生命周期页面不可见时暂停资源占用销毁时释放资源。 【边界——禁止做】 1. 不要修改与需求无关的文件。 2. 不要引入新的第三方依赖除非我明确允许。 3. 不要在布局里新增复杂自定义控件保持和现有风格一致。 【工程上下文】 - 项目 minSdk: 24targetSdk: 34语言: Kotlin。 - 相关文件附上需要参考或修改的具体文件路径。 - 依赖列表粘贴 build.gradle 里的核心依赖。 【输出要求】 1. 先输出技术方案说明你打算用什么 API、什么线程模型等确认后再写代码。 2. 代码带注释关键权限和兼容处理单独用注释标出来。 3. 最后列出自测清单你预估哪些点可能出问题建议我怎么测。这套模板看起来啰嗦但它每一段都有明确作用。角色设定让 AI 默认带上 Android 开发的专业视角边界里的“必须做”是给 AI 划底线“禁止做”是防它加戏工程上下文能显著降低 AI 用错 API 版本的概率输出要求强制它“先方案后代码”这正好卡住了前面说的返工最大来源。我建议你把这份模板存成 snippet每次新需求直接改小标题下的内容比每次临时想提示词稳定得多。3.2 第二层约束工具侧——让 AI 活在 Android Studio 的上下文里输入侧约束做好之后工具侧也要选对。我不太推荐在通用聊天窗口里让 AI 帮你写完整的 Android 功能因为通用对话窗口没有你的工程上下文你每次都要手动贴文件、贴依赖、贴 Manifest既累又容易贴漏。现在比较好的做法是把 AI 放进 Android Studio 里面让它直接感知当前工程结构。我自己主力用的是 Android Studio 内置的 AI 助手比如 Gemini Code Assist 或者同类的 IDE 内 AI 编码插件。这类工具最大的优势是能通过 IDE 的上下文索引直接引用你当前打开的文件、当前 Module 的依赖、甚至项目里已有的类。我在提示词里写了“参考AudioRecorderManager.kt里的封装”它真的能去读那个文件然后按你的封装风格来写而不是凭空生成一个风格迥异的实现。工具侧还有一个容易忽略的细节上下文选择。很多 AI 编码插件默认会抓取整个仓库作为上下文这在大型项目里会导致两个问题一是 token 成本高二是 AI 容易被无关代码带偏。我习惯在发起任务前先把当前分支、关键文件、相关目录结构在插件里框选好让 AI 只基于这部分上下文作答。比如我只让它改app/src/main/java/com/example/audio/下的代码就不给它看network/模块的内容这能明显降低“串味”。注意IDE 内 AI 插件再好也别让它自动改一堆文件然后直接提交。我给自己定的规矩是让 AI 用“建议模式”产出代码我逐个文件 review 之后再手动合并进去。有人觉得这样不够“自动化”但在我看来自动提交是翻车的高发姿势。3.3 第三层约束执行侧——构建、单测、lint 一个都不能少前两层约束解决的是“AI 想不想跑偏”的问题第三层解决的是“AI 跑偏了能不能被拦住”。执行侧约束的核心就一条AI 改完代码之后必须通过你项目里的自动化检查否则不算完。我在团队的 Android 工程里维护了一个简单的脚本./check.sh内容大体是这样#!/bin/bash # 一键执行 AI 改动后的检查流程 ./gradlew assembleDebug if [ $? -ne 0 ]; then echo 构建失败请让 AI 修正编译错误 2 exit 1 fi ./gradlew testDebugUnitTest if [ $? -ne 0 ]; then echo 单元测试失败请让 AI 查看失败的用例 2 exit 1 fi ./gradlew lintDebug if [ $? -ne 0 ]; then echo Lint 扫描出问题请让 AI 查看报告 2 exit 1 fi echo 全部检查通过可以进入真机验证这个脚本我一天可能跑几十次因为 AI 每次给我产出我都会先让它自己在本地把这三道关卡跑通它说“通过了”我再用脚本验证一遍。这里有个实操小技巧当构建或单测报错时你直接把终端里的报错日志贴给 AI然后再附一句话“根据报错修复你的代码不要改其他部分”会比你自己去改快得多。AI 对报错的跟进能力其实很强问题在于很多上下文在报错时已经断了所以保持同一轮对话连续贴报错很重要。至于 lint很多用 AI 的开发者会忽略它觉得是可有可无的代码规范检查。但 Android 的 lint 其实内置了大量“潜在 bug”检测比如忘记权限检查、错误使用 API、资源安全问题等等。它不只是风格检查还带着一部分静态分析的作用。所以我强烈建议AI 生成的代码必须过 lint过了基本能防住一大半低级错误。3.4 第四层约束验收侧——把关键路径变成可重复的自动化资产构建、单测、lint 都过了只代表“静态上没有明显问题”不代表“用户真的能正常使用”。Android 开发有大量问题是编译器和单测都发现不了的权限弹窗的 UI 流程、Activity 冷启动时的状态恢复、真机上音频设备的行为差异、不同分辨率下的布局适配……所以第四层约束是在真机或模拟器上建立“可重复的关键路径验证”。我给自己维护了一份“黄金冒烟用例清单”每次 AI 动完代码我不靠记忆去点而是照着清单一项项过比如首次启动授予权限后核心页面能正常打开。拒绝权限后App 不崩溃有友好提示。退出首页再重新进入数据能正确加载。横竖屏旋转后界面状态不丢失。杀掉 App 进程再冷启动不出现异常闪退。如果你的团队自动化程度高一点可以把这些路径写成 Compose UI Test 或 UIAutomator 的用例跑在 Firebase Test Lab 或者本地模拟器上。这样 AI 每次改动都可以触发一次回归完全不需要人盯着点屏幕。我个人的经验是哪怕自动化用例只覆盖 20% 的关键路径也比 100% 靠人肉点要有用得多因为它能稳定兜住最核心的那几条业务逻辑是最容易建立也最值得建立的投资。4. 一次完整实操用 AI 开发 Android 麦克风声强计模块4.1 需求描述与 Harness 设计光讲方法论还是虚的我拿最近一个真实需求走一遍完整流程给你看。这个需求是在 App 内加一个“麦克风声强计”功能用户点击按钮后开始录音界面实时显示当前环境分贝值再点一下停止。看起来很简单对吧但我故意不直接甩给 AI而是先按 Harness 流程设计约束。先拆解这个需求里的隐性约束第一麦克风录音属于敏感权限必须处理 Android 6.0 的动态权限请求、用户拒绝、以及 Android 14 上可能涉及的前台服务类型声明第二分贝计算需要拿到音频原始数据用 AudioRecord 比 MediaRecorder 更合适但 AudioRecord 的初始化有 bufferSize 的概念采样率兼容性也要处理第三实时刷新 UI 不能在主线程做耗时操作也不能在页面退出之后继续持有录音实例必须处理生命周期第四真机上麦克风有可能被其他应用占用所以要处理初始化失败的回退逻辑。这些约束我在提示词里全部显式写清楚然后让 AI 先出方案而不是先出代码。这一步很关键因为方案决定了后续所有代码的方向一旦方向错了后面写得再漂亮也是白搭。4.2 提示词怎么写把约束写进上下文我实际发给 AI 的提示词大概是这样的简化版但结构完整【角色】你是资深的 Android 工程师熟悉 Kotlin、AudioRecord、权限模型、生命周期。 【背景】我们的 Android 工程 minSdk 24targetSdk 34用 Kotlin。这次要新增一个“声强计”模块。 【需求】 1. 界面一个悬浮按钮控制开始/停止上方一个 TextView 实时显示分贝值例如 65.3 dB。 2. 开始后调用麦克风录音每 100ms 计算一次声强并更新 UI。 3. 停止后释放资源按钮恢复初始状态。 【硬性约束】 1. 使用 AudioRecord 获取 PCM 数据不要用 MediaRecorder。 2. 录音需要 RECORD_AUDIO 权限动态申请必须处理拒绝和不再询问跳设置页流程。 3. 页面 onPause 时停止录音onDestroy 时释放所有资源。 4. 分贝换算公式基于当前数据块均方根RMS参考满幅 32767 映射到 0~100 dB 左右。 5. 处理 AudioRecord 初始化失败返回错误提示不崩溃。 【工程上下文】 - 复用一个已有的工具类 PermissionHelper它提供 checkAndRequest(activity, permission, callback) 方法。 - UI 部分使用传统的 View 系统项目里没有 Compose。 【输出要求】 先给出技术方案包含线程模型、AudioRecord 参数选择、生命周期绑定方式等待我确认后再写代码。注意看这里我没有用“你看着办”这种模糊话术每一个约束都对应一个潜在的翻车点。比如“不要用 MediaRecorder”是因为 MediaRecorder 虽然也能拿到振幅但拿不到原始 PCM实时计算分贝不如 AudioRecord 灵活“分贝换算公式基于 RMS”是帮 AI 定死算法省得它给你各种花式实现。输入侧约束越具体AI 的产出就越容易被验证。4.3 让 AI 先出方案再出代码价值有多大这个需求我按流程让 AI 先出方案它交出来的第一版方案里有一个典型问题它想在 Activity 的 onResume 里自动开始录音理由是这样页面一回来就继续显示分贝。这个想法单独看没毛病但结合需求就错了——我们是要用户手动点击按钮才开始录音你 onResume 自动录音用户体验完全乱了而且权限还没授予的情况下直接启动录音分分钟崩溃。这个坑如果在代码阶段才暴露你需要从几百行代码里定位逻辑问题但因为在方案阶段就发现你只需要让它把“录音的启停完全由按钮控制”写清楚就行。我算过一下先方案后代码的整体耗时和直接让 AI 生成代码再修 bug 的耗时相比前期大概多花 10 分钟后期能省下 1~2 个小时的调试时间。这笔账怎么算都划算。方案确认之后AI 生成的代码进入工程基本顺利整体质量也比我第一次裸聊式用法高了一大截。我能明显感觉到给 AI 的上下文里有了“PermissionHelper 工具类”这个信息之后它写的权限申请逻辑不再是凭空造轮子而是主动去调用已有的方法。这就是工程上下文对生成质量的直接提升。4.4 代码落地与构建验证复盘AI 生成的最终实现里核心的分贝计算部分长这样我稍微整理了一下private fun calculateDb(audioData: ShortArray): Double { var sum 0.0 for (sample in audioData) { sum sample * sample } val rms sqrt(sum / audioData.size) return if (rms 0) { val db 20.0 * log10(rms / 32767.0) (db 100.0).coerceIn(0.0, 100.0) } else { 0.0 } }这个实现逻辑是对的RMS 除以短整型最大幅值得到归一化结果再通过 20 倍 log10 换算成分贝最后偏移到 0~100 dB 的显示区间。但这里藏着一个性能隐患频繁创建 ShortArray、频繁做 sqrt 和 log10 计算如果在主线程循环里跑容易卡 UI。所以我让它在子线程里做计算把结果通过 Handler 或 runOnUiThread 抛回 UI 更新这个调整也是我在 review 时注意到的。整个流程走完构建脚本跑过、单测补了两个一个算分贝换算、一个测权限拒绝分支、真机验证了录音和显示逻辑这个模块差不多花了我一个下午。对比之前让 AI 直接写的混乱代码这次几乎是稳步推进没有出现大返工。这四层约束的威力在一次完整需求里体现得非常清楚。5. 工具链怎么配AI 编程不是只能靠一个聊天窗口5.1 主流 AI 编程工具的组合打法聊完流程再说说工具。我知道很多人的困惑是网上推荐的 AI 编程工具那么多到底选哪个其实没有绝对最好只有“组合起来最顺手”。我自己现在的工具组合是按任务类型分的不押注在单一工具上。先看一张对比表是我个人使用感受不构成权威评测工具适用场景对 Android 工程上下文感知注意点Android Studio 内置 AIGemini Code Assist / Studio Bot 等修改当前工程代码、生成模块代码较强能感知项目文件、依赖依赖 IDE 版本旧版本功能弱GitHub Copilot代码补全、单文件生成一般主要看当前文件和索引长对话能力弱方案设计不太行Continue 等开源 IDE 插件自定义模型接入、隐私敏感项目中取决于索引配置需要自己调配置上手有成本Cursor / 其他 AI 编辑器通用代码逻辑、非 Android 工程弱脱离 Android Studio 环境不太建议在 Android 主流程里当主力通用大模型聊天窗口方案设计、代码审查、报错分析无需要手动喂上下文适合做“智库”不适合直接产工程代码我的核心观点是Android 项目主力还是 Android Studio所以 AI 主流程最好也活在 Android Studio 里。那些脱离 IDE 的 AI 聊天窗口更适合用来做方案讨论、代码 review、或者处理棘手的编译报错——因为它可以获取“外部知识”比如查一个新 API 的官方用法再让你把结论带回 IDE 里去落地。如果你是刚开始接触 AI 辅助 Android 开发我的建议是先别急着上全家桶就把 Android Studio 里自带的 AI 助手用熟配合一个通用大模型窗口做方案咨询已经能覆盖我前面讲的 80% 场景。工具不是越多越好而是要能嵌入你现有的工作流闭环。5.2 我实际落地的一套低摩擦配置具体到落地我现在每天实际在用的流程是这样的第一步开 Android Studio在当前工程文件里唤起 AI 助手用我上面那套结构化的提示词模板发起需求。这里的要点是提前框定上下文我一般会在 prompt 里明确写“参考app/src/main/java/...下的某个类”这样它能直接读到代码风格和已有封装。第二步得到 AI 方案后我先自己快速审一遍主要看三点用到的 API 是否在我的 minSdk/targetSdk 范围内、线程模型是否符合项目规范、有没有打招呼就引入新依赖。审完再让它展开写代码。第三步把 AI 生成的代码合并进工程立刻跑./check.sh。如果挂了把报错原样贴回对话让它修循环几轮直到全绿。这个过程我很少手动顺手改 AI 的编译错误因为那样反而打断了“让 AI 学会改自己 bug”的循环。第四步上真机跑冒烟路径直接验证 UI 与交互。这一步目前机器替代不了人但可以靠“黄金用例清单”压缩时间。这套配置的成本很低没有额外买什么付费 API也没有复杂的 Agent 框架。在我看来很多团队一上来就整复杂 Agent、自动执行任务、自动提 PR步子容易扯到。先把手动闭环跑通再考虑自动化才是比较稳的路径。翻车率低的关键永远是约束和验证不是工具本身有多智能。6. 常见问题与排坑实录每次都有人问我这些6.1 AI 生成代码经常编译不过API 根本不存在这是被问得最多的问题。表现非常典型AI 给你写了个NotificationManagerCompat.requestPermission你满怀期待地编译结果报错找不到符号。原因前面说过大模型对 API 的记忆存在“幻觉”它知道 Android 13 引入了通知运行时权限但把具体调用方式记串了。解决方法是“两头堵”提示词里要求它“所有 API 必须是 Android SDK 真实存在的不确定时先查官方文档”同时让它写明“API level 要求”。然后构建拦截——编译不过就直接把报错贴回去让它自己查。这样来回一两次AI 会收敛到正确实现。另一个操作细节是如果你的工程有较大的依赖库建议在提示词里明确“优先使用 androidx 系列 API”避免它生成一堆已经废弃的旧库代码。6.2 单测和 lint 都过了一装到真机上就闪退这个坑特别坑因为它意味着自动化关卡全部失灵。我遇到过一次AI 生成的录音功能在 JVM 单测里跑得好好的一上模拟器点击就开始崩溃。后来定位发现权限请求回调里的 context 被它当成 Activity 使用单测里我们 mock 了 Context 所以没炸真机上却因为类型转换失败直接崩溃。这类问题的根因是 JVM 单测覆盖不到 Android Framework 的真实行为。对策有几个方向一是针对 Activity、Fragment 交互用 Robolectric 或 instrumented test让测试跑到真实的 Android 环境里二是无论如何都必须有真机冒烟这一步哪怕只是在本地模拟器上手动点一遍。我的原则是自动化检查能挡住 60% 的低级错误真机验证负责挡剩下的 40%两者不能互相替代。6.3 AI 把需求理解偏了越补越乱怎么办连续对话里最常见的情况AI 第一次理解错了你在后面纠正它改了前边又把后边搞坏了来回几次上下文越来越乱最后整段代码没法看。这时候不要恋战直接“重置对话”把需求重新按模板完整喂一遍但这次可以把上一次的错误作为“负面示例”写进去让它明确知道“上次你用了 MediaRecorder 方案这次必须用 AudioRecord”。另外一个我经常用的技巧是在需求描述里要求 AI 先输出“需求理解摘要”你确认它理解正确之后再让它继续往下写。这就像传统开发里的“需求确认环节”把沟通误差在早期消灭成本最低。如果发现它摘要都理解偏了那就直接证明约束写的还不够清晰回去改提示词比继续生成代码有意义得多。6.4 AI 改需求时容易改坏已有功能怎么防AI 在改一处代码的时候经常“顺手”把原本正常工作的逻辑也给改了。最典型的场景你让它修 A 方法的 bug它觉得 B 方法写得不优雅顺手重构了结果 B 方法在你的核心链路里一改全崩。防这个问题的思路是强约束 版本管理双管齐下。提示词里我会加一句硬性要求“只能修改定位到的问题代码其他逻辑保持原样如果认为其他代码有问题先在方案里提出不要直接改。”然后在版本控制层面我要求 AI 每一个完整的改动必须生成独立 commit并且 commit message 写清楚“本次改动目标是什么、改了哪些文件”。这样即使它真改坏了我也可以精准回滚。最后再靠 diff review 把关凡是看到与需求无关的改动一律打回。这几点坚持下来AI 对存量代码的“误伤率”能降到很低。最后再分享一个我个人的切身体会AI 写 Android 代码翻不翻车关键不只是模型强不强而是你有没有给它搭好一条带护栏的跑道。把需求边界划清楚、把 Android 生态约束喂进去、把构建测试做成硬关卡、把关键路径变成固定验收动作这四件事做完AI 真的能帮你把大量重复性需求稳定吃掉。我现在日常里一些简单页面、工具类、单元测试已经可以放心交给 AI 打底我再 review 一层就能发版。剩下的时间省下来可以去啃那些 AI 目前还搞不定的复杂架构和疑难 bug。这套“缰绳”你尽早套上就能尽早从跟 AI 翻车搏斗中抽出身来。
用 Harness Engineering 给 AI 套缰绳：Android 开发翻车率降下来
写 Android 需求最怕什么怕 AI 拍着胸脯给你一段看起来无懈可击的代码接手过来一跑就崩。最近我把 Harness Engineering 的思路搬到 AI 辅助 Android 开发上实测了几周翻车率肉眼可见地降下来了。这篇就聊聊我怎么做约束、怎么定提示词、怎么把构建和测试接进流程以及在真实项目里用 AI 搞 Android 开发时踩过的几个坑。先交代一下背景我日常的活儿大头就是 Android 客户端从权限申请到生命周期管理、从 Gradle 构建到各种厂商 ROM 适配事杂且碎。之前直接用 AI 对话窗口帮我写业务代码最崩溃的一次是让它给我补一个“录音权限申请”的小模块结果它顺手把我 Activity 的布局文件改了一版还偷偷加了个网络请求一跑直接崩。那之后我开始认真研究怎么“驾驭”AI 而不是“被 AI 带着走”Harness Engineering 就是这个阶段最大的收获。它不神秘核心就一句话给 AI 戴好缰绳再让它撒开蹄子跑。这篇内容适合三类人想用 AI 提效但总在返工的 Android 开发、刚接手 AI Agent 工作流概念但不知道怎么落地到具体工程的开发者以及那些对“AI 生成代码到底靠不靠谱”持怀疑态度的技术管理者。我会把这套方法拆成可以直接抄作业的模板和命令不用你再去翻一堆英文文档。1. Harness Engineering 是什么先把它揉碎了再说1.1 别被名字吓到它解决的是 AI 产出的“不可控”问题Harness 这个词的本意是“马具、挽具”放在工程语境里就很形象了——马虽然力气大跑得快但你得给它套上嚼子和缰绳它才能按照你想要的路线走。Harness Engineering 说白了就是一套“给 AI 套缰绳”的方法论专门用来处理大模型产出不稳定、容易一本正经地胡说八道、以及经常忘记上下文约束这类问题。我发现很多人对 AI 编程最大的误解是把大模型当成一个“无所不知的编译器”你给它一句话它就该吐出来一段完美的代码。但实际上大模型本质上是“概率语言模型”它是在预测当前上下文下最可能出现的后续内容它并不真正理解你的 Android 工程结构也不清楚你有没有处理异常分支更不知道你项目的 minSdk 到底是多少。你说一句“帮我写个录音功能”它可能默认给你用 MediaRecorder可你的需求其实是想拿到原始 PCM 数据做实时分贝分析这就是“不可控”的第一个来源。Harness Engineering 的思路恰恰是反向操作既然 AI 天然不稳定那我们就通过工程手段把它不稳定带来的风险锁死在可控范围内。具体来说就是四件事输入侧做约束、过程侧做编排、输出侧做验证、闭环侧做反馈。每一件我都单独展开说这套框架放到 Android 开发里几乎是无缝对接。1.2 从“让 AI 自由发挥”到“给 AI 铺轨道”我最早用 AI 写代码就是打开一个聊天窗口把需求往那一扔等它输出。这种“自由发挥”式用法的问题在于你和 AI 之间缺少一个明确的“阶段划分”。它在你还不确定方案的情况下就把代码全写了一旦方案选型不对后面全是无用功。Harness Engineering 的做法完全不同它要求你把一个大任务拆成一段段有明确输入输出的小步骤每一步都设置检查点。拿 Android 开发来说一个完整需求应该过这样几条轨道需求澄清阶段AI 先用自然语言复述它理解的业务需求包括涉及的页面、交互、边界条件你要检查它有没有理解偏。技术方案阶段AI 输出实现方案包括用到的 API、权限声明、线程模型、生命周期处理你要评审方案是否合理而不是急着看代码。代码生成阶段在方案确认后才让 AI 按模块生成具体代码并且要求它遵循你给定的代码风格和已有工程结构。验证反馈阶段把 AI 生成的代码跑进构建、单测、lint、真机冒烟测试把报错信息原样贴回去让它修直到全部通过。这套流程本质上和传统开发没什么区别需求评审、技术设计、编码、测试一步不少。只是原来这些动作靠人和文档现在靠提示词和工具链把 AI 限制在轨道里。我实测下来最大的好处是即使 AI 到底层代码还在犯蠢你至少能早早在方案阶段就发现而不是等它写完几百行代码再推倒重来。1.3 为什么这套思路在 Android 开发里特别对路Android 开发大概是当前所有客户端技术栈里“隐性约束”最多的一类。Gradle 构建脚本、AndroidManifest 里的权限声明、Activity 和 Fragment 的生命周期、进程被杀之后的恢复机制、不同厂商 ROM 对后台的限制、targetSdk 升级引入的新行为变更……这些东西密密麻麻任何一个弄错都是运行时才能暴露的雷。偏偏大模型在生成代码时最不擅长的就是“记得住这些边界”。我试过让 AI 给我生成一个 “Android 13 上请求通知权限”的代码它给我写出了 NotificationManagerCompat.requestPermission 这种压根不存在的 API还一本正经地加了注释说“这是 Android 13 新增的用法”。这就是典型的“幻觉”它训练数据里见过 Android 13 权限相关的内容但没有精确到 API 名于是自己编了一个。如果你不用 Harness Engineering 的约束流程这种幻觉代码很容易混进工程里。但如果你强制 AI 先写方案、再锁定 API 级别和权限声明、最后过构建检查这类问题在编译期就会被拦截下来。这也解释了为什么同一个大模型有人拿它写 Android 需求天天救火有人却能把需求快速落地——差别不在模型在有没有给模型套上适合 Android 生态的缰绳。2. AI 做 Android 需求最常见的三类翻车现场2.1 翻车场景一需求理解发散AI 自己给自己“加戏”这是我最早期踩得最狠的坑。需求明明只说了“在设置页加一个开关控制某个功能的启停”AI 上来就给你重排了页面布局给按钮加了动画还顺手定义了好几个你用不到的 ViewModel。这些“加戏”看起来是加分项实际上在真实工程场景里是灾难——你没法确定它改动了哪些你没注意到的文件更没法保证它新增的东西符合你的产品规范。问题根源在于提示词里只给了“做什么”没给“不做什么”。大模型在生成内容时天然的倾向是“尽量完整”它会把一个简单需求脑补成一整套方案。对应到 Harness Engineering 的输入侧约束你必须在需求描述里显式声明不改动哪些文件、不引入哪些依赖、不新增与需求无关的 UI 样式、不做超过当前场景的设计抽象。没有这些“负面约束”AI 一定会飘。我见过不少团队的 AI 辅助开发流程里根本没有这一步提示词写得非常口语化什么“帮我改一下这个页面”AI 当然只能猜。猜对了是运气猜错了是常态。所以第一条教训就是明确划出边界比描述目标更重要。2.2 翻车场景二Android 生态约束被无视API 乱用到离谱Android 的生态约束可以写成一本书版本碎片化、权限模型变更、后台执行限制、Activity 启动模式、Fragment 重建机制、资源命名规范、Gradle 依赖冲突……每一条都能让 AI 生成一段看起来正确但实际无法运行的代码。举几个我实际遇到过的例子。第一个是权限模型AI 在生成录音、定位、通知相关代码时经常只写 Manifest 声明忘了 Android 6.0 之后必须动态申请权限就算记得动态申请也经常没处理用户拒绝和“不再询问”的情况。第二个是后台服务限制让它生成一个后台播放录音的服务它直接给你写个普通 Service 然后 onStartCommand 里开个死循环完全没考虑 Android 8.0 之后启动后台服务受限、Android 14 之后前台服务必须声明类型的约束。第三个是 API 兼容性它默认 targetSdk 是旧版本直接用了已经废弃的 API编译期还好上了新设备就崩。这些问题的共性在于AI 只“知道”这些 API 存在的片段但不知道在你的工程上下文里该用哪一个版本、该配什么权限、该做哪些兜底。所以你必须在提示词和验证流程里把“Android 生态上下文”固定住——比如把 targetSdk、minSdk、相关官方文档摘要、工程里的权限声明统统喂给它同时把构建和静态检查作为硬性关卡。这样才能把“常识性的幻觉”挡在门外。2.3 翻车场景三验证全靠肉眼回归测试形同虚设第三个翻车点其实是最要命的因为它直接决定了 AI 能不能稳定生产力——没有自动化验证闭环AI 每改一次代码你都要人工把整个 App 点一遍改多了人必然疲劳疲劳了就会漏测。我见过很多用 AI 写代码的开发者流程是让 AI 改代码 → 人工跑一遍编译 → 编译过了 → 自己手动点几下 → 没问题收工。但这个流程有个巨大的漏洞编译过只能说明语法和类型没问题说明不了逻辑正确、更说明不了兼容性达标。AI 改了一个工具类的判断逻辑编译过了但那三个调用点可能全炸了你没点到的页面就是炸弹。Harness Engineering 最核心的实践之一就是“让验证成为流程的一部分而不是事后行为”。放到 Android 工程里至少要包含三层单元测试覆盖纯逻辑比如分贝换算、数据解析、状态机流转、Android 特定测试覆盖组件交互比如权限弹窗、Activity 启动参数、真机冒烟覆盖关键路径比如录音开关能不能亮起来。这三层都跑到AI 的改动才算通过验收。不做这一步所谓的“AI 提效”只是在给未来埋雷。2.4 为什么这些翻车可以避免这三类翻车本质上都不是“AI 能力不够”而是“工程流程缺失”。你带着 Chat 聊天的思维用 AI得到的必然是聊天级别的可靠性你带着工程化的思维用 AIAI 才能产出工程级别的结果。你想一下传统开发流程为什么不容易翻车因为有需求评审、设计评审、CR代码评审、CI 流水线、测试用例。这些环节没有一个是依赖“某个人特别强”的靠的是机制把错误拦截住。AI 辅助开发完全可以沿用这套机制只是把原来写代码的那个人换成了 AI评审和执行的标准一点都不能降。Harness Engineering 做的就是把这套机制显性化变成你调用 AI 之前的固定动作。所以我现在的心态已经变了我不再追求“让 AI 一次性写对”而是追求“让 AI 在约束和验证的双重轨道里快速迭代到正确”。一次写不对外太正常了关键是怎么低成本地让它修正而不是让它带着错误一路狂奔到离题万里。3. 我的四层约束体系用 Harness Engineering 管 Android 需求3.1 第一层约束输入侧——把需求“喂”给 AI 的正确姿势输入侧约束是所有约束里投入产出比最高的一个你只需要在敲提示词的时候多花两分钟后续的返工成本能省下一大半。我现在给 AI 下需求基本用下面这套结构化模板你可以直接复制改一下项目信息就能用。【角色】你是一名熟悉 Android 生态的高级开发工程师擅长 Kotlin/Java熟悉 Gradle、生命周期、权限模型、常见兼容性问题。 【目标】实现一个功能xxx一句话说清。 【页面入口】该功能挂在 MainActivity 的某个按钮上可附文件路径。 【边界——必须做】 1. 使用 Android 官方推荐的 API优先考虑 targetSdk 34 兼容性。 2. 需要动态申请的权限给出完整申请流程并处理拒绝场景。 3. 处理生命周期页面不可见时暂停资源占用销毁时释放资源。 【边界——禁止做】 1. 不要修改与需求无关的文件。 2. 不要引入新的第三方依赖除非我明确允许。 3. 不要在布局里新增复杂自定义控件保持和现有风格一致。 【工程上下文】 - 项目 minSdk: 24targetSdk: 34语言: Kotlin。 - 相关文件附上需要参考或修改的具体文件路径。 - 依赖列表粘贴 build.gradle 里的核心依赖。 【输出要求】 1. 先输出技术方案说明你打算用什么 API、什么线程模型等确认后再写代码。 2. 代码带注释关键权限和兼容处理单独用注释标出来。 3. 最后列出自测清单你预估哪些点可能出问题建议我怎么测。这套模板看起来啰嗦但它每一段都有明确作用。角色设定让 AI 默认带上 Android 开发的专业视角边界里的“必须做”是给 AI 划底线“禁止做”是防它加戏工程上下文能显著降低 AI 用错 API 版本的概率输出要求强制它“先方案后代码”这正好卡住了前面说的返工最大来源。我建议你把这份模板存成 snippet每次新需求直接改小标题下的内容比每次临时想提示词稳定得多。3.2 第二层约束工具侧——让 AI 活在 Android Studio 的上下文里输入侧约束做好之后工具侧也要选对。我不太推荐在通用聊天窗口里让 AI 帮你写完整的 Android 功能因为通用对话窗口没有你的工程上下文你每次都要手动贴文件、贴依赖、贴 Manifest既累又容易贴漏。现在比较好的做法是把 AI 放进 Android Studio 里面让它直接感知当前工程结构。我自己主力用的是 Android Studio 内置的 AI 助手比如 Gemini Code Assist 或者同类的 IDE 内 AI 编码插件。这类工具最大的优势是能通过 IDE 的上下文索引直接引用你当前打开的文件、当前 Module 的依赖、甚至项目里已有的类。我在提示词里写了“参考AudioRecorderManager.kt里的封装”它真的能去读那个文件然后按你的封装风格来写而不是凭空生成一个风格迥异的实现。工具侧还有一个容易忽略的细节上下文选择。很多 AI 编码插件默认会抓取整个仓库作为上下文这在大型项目里会导致两个问题一是 token 成本高二是 AI 容易被无关代码带偏。我习惯在发起任务前先把当前分支、关键文件、相关目录结构在插件里框选好让 AI 只基于这部分上下文作答。比如我只让它改app/src/main/java/com/example/audio/下的代码就不给它看network/模块的内容这能明显降低“串味”。注意IDE 内 AI 插件再好也别让它自动改一堆文件然后直接提交。我给自己定的规矩是让 AI 用“建议模式”产出代码我逐个文件 review 之后再手动合并进去。有人觉得这样不够“自动化”但在我看来自动提交是翻车的高发姿势。3.3 第三层约束执行侧——构建、单测、lint 一个都不能少前两层约束解决的是“AI 想不想跑偏”的问题第三层解决的是“AI 跑偏了能不能被拦住”。执行侧约束的核心就一条AI 改完代码之后必须通过你项目里的自动化检查否则不算完。我在团队的 Android 工程里维护了一个简单的脚本./check.sh内容大体是这样#!/bin/bash # 一键执行 AI 改动后的检查流程 ./gradlew assembleDebug if [ $? -ne 0 ]; then echo 构建失败请让 AI 修正编译错误 2 exit 1 fi ./gradlew testDebugUnitTest if [ $? -ne 0 ]; then echo 单元测试失败请让 AI 查看失败的用例 2 exit 1 fi ./gradlew lintDebug if [ $? -ne 0 ]; then echo Lint 扫描出问题请让 AI 查看报告 2 exit 1 fi echo 全部检查通过可以进入真机验证这个脚本我一天可能跑几十次因为 AI 每次给我产出我都会先让它自己在本地把这三道关卡跑通它说“通过了”我再用脚本验证一遍。这里有个实操小技巧当构建或单测报错时你直接把终端里的报错日志贴给 AI然后再附一句话“根据报错修复你的代码不要改其他部分”会比你自己去改快得多。AI 对报错的跟进能力其实很强问题在于很多上下文在报错时已经断了所以保持同一轮对话连续贴报错很重要。至于 lint很多用 AI 的开发者会忽略它觉得是可有可无的代码规范检查。但 Android 的 lint 其实内置了大量“潜在 bug”检测比如忘记权限检查、错误使用 API、资源安全问题等等。它不只是风格检查还带着一部分静态分析的作用。所以我强烈建议AI 生成的代码必须过 lint过了基本能防住一大半低级错误。3.4 第四层约束验收侧——把关键路径变成可重复的自动化资产构建、单测、lint 都过了只代表“静态上没有明显问题”不代表“用户真的能正常使用”。Android 开发有大量问题是编译器和单测都发现不了的权限弹窗的 UI 流程、Activity 冷启动时的状态恢复、真机上音频设备的行为差异、不同分辨率下的布局适配……所以第四层约束是在真机或模拟器上建立“可重复的关键路径验证”。我给自己维护了一份“黄金冒烟用例清单”每次 AI 动完代码我不靠记忆去点而是照着清单一项项过比如首次启动授予权限后核心页面能正常打开。拒绝权限后App 不崩溃有友好提示。退出首页再重新进入数据能正确加载。横竖屏旋转后界面状态不丢失。杀掉 App 进程再冷启动不出现异常闪退。如果你的团队自动化程度高一点可以把这些路径写成 Compose UI Test 或 UIAutomator 的用例跑在 Firebase Test Lab 或者本地模拟器上。这样 AI 每次改动都可以触发一次回归完全不需要人盯着点屏幕。我个人的经验是哪怕自动化用例只覆盖 20% 的关键路径也比 100% 靠人肉点要有用得多因为它能稳定兜住最核心的那几条业务逻辑是最容易建立也最值得建立的投资。4. 一次完整实操用 AI 开发 Android 麦克风声强计模块4.1 需求描述与 Harness 设计光讲方法论还是虚的我拿最近一个真实需求走一遍完整流程给你看。这个需求是在 App 内加一个“麦克风声强计”功能用户点击按钮后开始录音界面实时显示当前环境分贝值再点一下停止。看起来很简单对吧但我故意不直接甩给 AI而是先按 Harness 流程设计约束。先拆解这个需求里的隐性约束第一麦克风录音属于敏感权限必须处理 Android 6.0 的动态权限请求、用户拒绝、以及 Android 14 上可能涉及的前台服务类型声明第二分贝计算需要拿到音频原始数据用 AudioRecord 比 MediaRecorder 更合适但 AudioRecord 的初始化有 bufferSize 的概念采样率兼容性也要处理第三实时刷新 UI 不能在主线程做耗时操作也不能在页面退出之后继续持有录音实例必须处理生命周期第四真机上麦克风有可能被其他应用占用所以要处理初始化失败的回退逻辑。这些约束我在提示词里全部显式写清楚然后让 AI 先出方案而不是先出代码。这一步很关键因为方案决定了后续所有代码的方向一旦方向错了后面写得再漂亮也是白搭。4.2 提示词怎么写把约束写进上下文我实际发给 AI 的提示词大概是这样的简化版但结构完整【角色】你是资深的 Android 工程师熟悉 Kotlin、AudioRecord、权限模型、生命周期。 【背景】我们的 Android 工程 minSdk 24targetSdk 34用 Kotlin。这次要新增一个“声强计”模块。 【需求】 1. 界面一个悬浮按钮控制开始/停止上方一个 TextView 实时显示分贝值例如 65.3 dB。 2. 开始后调用麦克风录音每 100ms 计算一次声强并更新 UI。 3. 停止后释放资源按钮恢复初始状态。 【硬性约束】 1. 使用 AudioRecord 获取 PCM 数据不要用 MediaRecorder。 2. 录音需要 RECORD_AUDIO 权限动态申请必须处理拒绝和不再询问跳设置页流程。 3. 页面 onPause 时停止录音onDestroy 时释放所有资源。 4. 分贝换算公式基于当前数据块均方根RMS参考满幅 32767 映射到 0~100 dB 左右。 5. 处理 AudioRecord 初始化失败返回错误提示不崩溃。 【工程上下文】 - 复用一个已有的工具类 PermissionHelper它提供 checkAndRequest(activity, permission, callback) 方法。 - UI 部分使用传统的 View 系统项目里没有 Compose。 【输出要求】 先给出技术方案包含线程模型、AudioRecord 参数选择、生命周期绑定方式等待我确认后再写代码。注意看这里我没有用“你看着办”这种模糊话术每一个约束都对应一个潜在的翻车点。比如“不要用 MediaRecorder”是因为 MediaRecorder 虽然也能拿到振幅但拿不到原始 PCM实时计算分贝不如 AudioRecord 灵活“分贝换算公式基于 RMS”是帮 AI 定死算法省得它给你各种花式实现。输入侧约束越具体AI 的产出就越容易被验证。4.3 让 AI 先出方案再出代码价值有多大这个需求我按流程让 AI 先出方案它交出来的第一版方案里有一个典型问题它想在 Activity 的 onResume 里自动开始录音理由是这样页面一回来就继续显示分贝。这个想法单独看没毛病但结合需求就错了——我们是要用户手动点击按钮才开始录音你 onResume 自动录音用户体验完全乱了而且权限还没授予的情况下直接启动录音分分钟崩溃。这个坑如果在代码阶段才暴露你需要从几百行代码里定位逻辑问题但因为在方案阶段就发现你只需要让它把“录音的启停完全由按钮控制”写清楚就行。我算过一下先方案后代码的整体耗时和直接让 AI 生成代码再修 bug 的耗时相比前期大概多花 10 分钟后期能省下 1~2 个小时的调试时间。这笔账怎么算都划算。方案确认之后AI 生成的代码进入工程基本顺利整体质量也比我第一次裸聊式用法高了一大截。我能明显感觉到给 AI 的上下文里有了“PermissionHelper 工具类”这个信息之后它写的权限申请逻辑不再是凭空造轮子而是主动去调用已有的方法。这就是工程上下文对生成质量的直接提升。4.4 代码落地与构建验证复盘AI 生成的最终实现里核心的分贝计算部分长这样我稍微整理了一下private fun calculateDb(audioData: ShortArray): Double { var sum 0.0 for (sample in audioData) { sum sample * sample } val rms sqrt(sum / audioData.size) return if (rms 0) { val db 20.0 * log10(rms / 32767.0) (db 100.0).coerceIn(0.0, 100.0) } else { 0.0 } }这个实现逻辑是对的RMS 除以短整型最大幅值得到归一化结果再通过 20 倍 log10 换算成分贝最后偏移到 0~100 dB 的显示区间。但这里藏着一个性能隐患频繁创建 ShortArray、频繁做 sqrt 和 log10 计算如果在主线程循环里跑容易卡 UI。所以我让它在子线程里做计算把结果通过 Handler 或 runOnUiThread 抛回 UI 更新这个调整也是我在 review 时注意到的。整个流程走完构建脚本跑过、单测补了两个一个算分贝换算、一个测权限拒绝分支、真机验证了录音和显示逻辑这个模块差不多花了我一个下午。对比之前让 AI 直接写的混乱代码这次几乎是稳步推进没有出现大返工。这四层约束的威力在一次完整需求里体现得非常清楚。5. 工具链怎么配AI 编程不是只能靠一个聊天窗口5.1 主流 AI 编程工具的组合打法聊完流程再说说工具。我知道很多人的困惑是网上推荐的 AI 编程工具那么多到底选哪个其实没有绝对最好只有“组合起来最顺手”。我自己现在的工具组合是按任务类型分的不押注在单一工具上。先看一张对比表是我个人使用感受不构成权威评测工具适用场景对 Android 工程上下文感知注意点Android Studio 内置 AIGemini Code Assist / Studio Bot 等修改当前工程代码、生成模块代码较强能感知项目文件、依赖依赖 IDE 版本旧版本功能弱GitHub Copilot代码补全、单文件生成一般主要看当前文件和索引长对话能力弱方案设计不太行Continue 等开源 IDE 插件自定义模型接入、隐私敏感项目中取决于索引配置需要自己调配置上手有成本Cursor / 其他 AI 编辑器通用代码逻辑、非 Android 工程弱脱离 Android Studio 环境不太建议在 Android 主流程里当主力通用大模型聊天窗口方案设计、代码审查、报错分析无需要手动喂上下文适合做“智库”不适合直接产工程代码我的核心观点是Android 项目主力还是 Android Studio所以 AI 主流程最好也活在 Android Studio 里。那些脱离 IDE 的 AI 聊天窗口更适合用来做方案讨论、代码 review、或者处理棘手的编译报错——因为它可以获取“外部知识”比如查一个新 API 的官方用法再让你把结论带回 IDE 里去落地。如果你是刚开始接触 AI 辅助 Android 开发我的建议是先别急着上全家桶就把 Android Studio 里自带的 AI 助手用熟配合一个通用大模型窗口做方案咨询已经能覆盖我前面讲的 80% 场景。工具不是越多越好而是要能嵌入你现有的工作流闭环。5.2 我实际落地的一套低摩擦配置具体到落地我现在每天实际在用的流程是这样的第一步开 Android Studio在当前工程文件里唤起 AI 助手用我上面那套结构化的提示词模板发起需求。这里的要点是提前框定上下文我一般会在 prompt 里明确写“参考app/src/main/java/...下的某个类”这样它能直接读到代码风格和已有封装。第二步得到 AI 方案后我先自己快速审一遍主要看三点用到的 API 是否在我的 minSdk/targetSdk 范围内、线程模型是否符合项目规范、有没有打招呼就引入新依赖。审完再让它展开写代码。第三步把 AI 生成的代码合并进工程立刻跑./check.sh。如果挂了把报错原样贴回对话让它修循环几轮直到全绿。这个过程我很少手动顺手改 AI 的编译错误因为那样反而打断了“让 AI 学会改自己 bug”的循环。第四步上真机跑冒烟路径直接验证 UI 与交互。这一步目前机器替代不了人但可以靠“黄金用例清单”压缩时间。这套配置的成本很低没有额外买什么付费 API也没有复杂的 Agent 框架。在我看来很多团队一上来就整复杂 Agent、自动执行任务、自动提 PR步子容易扯到。先把手动闭环跑通再考虑自动化才是比较稳的路径。翻车率低的关键永远是约束和验证不是工具本身有多智能。6. 常见问题与排坑实录每次都有人问我这些6.1 AI 生成代码经常编译不过API 根本不存在这是被问得最多的问题。表现非常典型AI 给你写了个NotificationManagerCompat.requestPermission你满怀期待地编译结果报错找不到符号。原因前面说过大模型对 API 的记忆存在“幻觉”它知道 Android 13 引入了通知运行时权限但把具体调用方式记串了。解决方法是“两头堵”提示词里要求它“所有 API 必须是 Android SDK 真实存在的不确定时先查官方文档”同时让它写明“API level 要求”。然后构建拦截——编译不过就直接把报错贴回去让它自己查。这样来回一两次AI 会收敛到正确实现。另一个操作细节是如果你的工程有较大的依赖库建议在提示词里明确“优先使用 androidx 系列 API”避免它生成一堆已经废弃的旧库代码。6.2 单测和 lint 都过了一装到真机上就闪退这个坑特别坑因为它意味着自动化关卡全部失灵。我遇到过一次AI 生成的录音功能在 JVM 单测里跑得好好的一上模拟器点击就开始崩溃。后来定位发现权限请求回调里的 context 被它当成 Activity 使用单测里我们 mock 了 Context 所以没炸真机上却因为类型转换失败直接崩溃。这类问题的根因是 JVM 单测覆盖不到 Android Framework 的真实行为。对策有几个方向一是针对 Activity、Fragment 交互用 Robolectric 或 instrumented test让测试跑到真实的 Android 环境里二是无论如何都必须有真机冒烟这一步哪怕只是在本地模拟器上手动点一遍。我的原则是自动化检查能挡住 60% 的低级错误真机验证负责挡剩下的 40%两者不能互相替代。6.3 AI 把需求理解偏了越补越乱怎么办连续对话里最常见的情况AI 第一次理解错了你在后面纠正它改了前边又把后边搞坏了来回几次上下文越来越乱最后整段代码没法看。这时候不要恋战直接“重置对话”把需求重新按模板完整喂一遍但这次可以把上一次的错误作为“负面示例”写进去让它明确知道“上次你用了 MediaRecorder 方案这次必须用 AudioRecord”。另外一个我经常用的技巧是在需求描述里要求 AI 先输出“需求理解摘要”你确认它理解正确之后再让它继续往下写。这就像传统开发里的“需求确认环节”把沟通误差在早期消灭成本最低。如果发现它摘要都理解偏了那就直接证明约束写的还不够清晰回去改提示词比继续生成代码有意义得多。6.4 AI 改需求时容易改坏已有功能怎么防AI 在改一处代码的时候经常“顺手”把原本正常工作的逻辑也给改了。最典型的场景你让它修 A 方法的 bug它觉得 B 方法写得不优雅顺手重构了结果 B 方法在你的核心链路里一改全崩。防这个问题的思路是强约束 版本管理双管齐下。提示词里我会加一句硬性要求“只能修改定位到的问题代码其他逻辑保持原样如果认为其他代码有问题先在方案里提出不要直接改。”然后在版本控制层面我要求 AI 每一个完整的改动必须生成独立 commit并且 commit message 写清楚“本次改动目标是什么、改了哪些文件”。这样即使它真改坏了我也可以精准回滚。最后再靠 diff review 把关凡是看到与需求无关的改动一律打回。这几点坚持下来AI 对存量代码的“误伤率”能降到很低。最后再分享一个我个人的切身体会AI 写 Android 代码翻不翻车关键不只是模型强不强而是你有没有给它搭好一条带护栏的跑道。把需求边界划清楚、把 Android 生态约束喂进去、把构建测试做成硬关卡、把关键路径变成固定验收动作这四件事做完AI 真的能帮你把大量重复性需求稳定吃掉。我现在日常里一些简单页面、工具类、单元测试已经可以放心交给 AI 打底我再 review 一层就能发版。剩下的时间省下来可以去啃那些 AI 目前还搞不定的复杂架构和疑难 bug。这套“缰绳”你尽早套上就能尽早从跟 AI 翻车搏斗中抽出身来。