让 AI 写出一段代码，已经不难。难的是让它在正确的工程里完成修改，知道改动是否生效，在出错时找到原因，并且留下另一位开发者能够接手的结果。
这也是 Android 开发进入 Agent 阶段后，最值得重新思考的地方：我们究竟是在使用一个更强的代码补全工具，还是在搭建一条可观察、可验证、可追责的开发流程？
决定效率上限的，往往不是一次生成了多少代码，而是一次修改之后，能多快拿到可信的反馈。
从 Android CLI、子 Agent、IDE 语义能力到自然语言驱动的应用验证，这些能力看起来分散，实际上都在补齐同一个闭环：理解任务、实施修改、观察结果、定位问题、再次修正。
01
先消除环境里的不确定性
一个从零开始的 Android 任务，远不止"生成几个 Kotlin 文件"。它还包括安装 SDK、选择兼容的构建配置、创建工程、准备设备、找到构建产物，以及等待模拟器真正可用。
这些事情对熟练开发者不算困难，却很容易成为 Agent 的时间黑洞。它可能找到过时的下载入口，猜出一套不兼容的依赖版本，或者反复检查一个尚未启动完成的模拟器。
把这些步骤标准化，比让模型更努力地猜测更有效。
Android CLI 的价值就在这一层：通过面向 Agent 的命令行入口，提供环境与 SDK 设置、模板建项、虚拟设备管理、APK 安装和界面检查等能力；同时可以连接 Android Studio，使用语义分析与 Compose 预览能力Overview of Android CLI \| Android Studio \| Android Developers。
对团队来说，值得关注的不是"终于可以不用 IDE"，而是工程的基础操作开始拥有统一接口。Agent 不必从零拼凑每个细节，人也不必反复解释项目应该长什么样。
CLI 和 IDE 因而不是替代关系。前者适合自动化、组合执行和外部 Agent 接入；后者仍然适合调试、代码导航以及需要人判断的深度开发。两者共享能力，才能避免自动化流程与人工开发各走一套。
落到实践中，第一步应当是固定工具版本、模板、构建入口和设备准备方式。先让同一项任务有一个稳定的起点，再讨论模型能跑多快。
02
子 Agent 的价值，不只是同时开工
谈到多 Agent，很容易把注意力放在数量上：能不能一次启动十个、二十个任务？但数量不是最重要的指标，上下文边界才是。
一个主 Agent 如果既读配置、查接口、分析架构，又审查测试、逐个解释所有文件，很快就会携带大量只在某个步骤有用的细节。后续每一次推理，都不得不在这些历史信息中辨认当前目标。
子 Agent 提供了另一种组织方式：把独立问题交给独立上下文，只把结论、证据和未解决事项交回来。主任务保留决策所需的信息，而不是保留所有过程。
需要区分三种常被混在一起的能力：后台会话让用户不用等一个任务结束再开始另一个；并行工具调用让互不依赖的操作同时执行；子 Agent 则为子任务提供独立的工作上下文。它们可以配合，但不是同一件事。
这也不意味着多 Agent 一定更省钱。主上下文变短，可能减少重复携带的历史；更多任务同时运行，又可能在短时间内消耗更多额度。真正应该观察的是完成质量、总消耗和失败后的返工成本，而不是只看等待时间。
最适合先并行化的，通常是只读工作：让一个 Agent 梳理调用链，另一个检查测试缺口，再让第三个独立审查当前变更。这些任务相互干扰较少，也容易定义清楚的交付物。
涉及写入时，边界必须更严格。多个会话仍然可能面对同一份工作区；上下文隔离，并不等于文件系统隔离。并行修改同一文件、切换分支或回退提交，都可能影响其他任务。需要并行实现时，应明确文件归属，并按实际需要使用独立 worktree 或独立环境。
一个写入者，多个只读分析者，是更容易落地的起点。
03
先给廉价反馈，再跑昂贵验证
让 Agent 修改代码后立刻运行完整构建，看起来稳妥，却不一定高效。
不存在的方法、错误的参数、未解析的引用，往往不需要等完整 Gradle 构建结束才发现。如果每一个局部问题都走一遍"修改---全量构建---读取长日志"，大量时间就花在重复等待上。
更合理的策略，是按问题范围逐层获得反馈：先检查文件和符号，再运行相关模块的构建或测试，最后验证设备上的真实行为。这里没有哪一层能够替代其他层，只有反馈成本和覆盖范围的区别。
尤其在 Kotlin 工程中，文本搜索并不等于语义理解。两个同名调用可能来自不同类型，扩展函数、重载以及不同依赖上下文也会改变实际解析结果。找到一串文字，不代表找到了真正的引用关系。
因此，向 Agent 开放 IDE 的语义工具，比让它不断扩大文本搜索范围更有价值。Android CLI 提供的 Studio 连接能力，正是把这类 IDE 能力开放给命令行工作流的桥梁Overview of Android CLI \| Android Studio \| Android Developers。
可以把反馈设计成四层：
1.静态层：符号是否解析，类型是否匹配，检查器是否提示明显问题。
2.构建层：受影响模块能否编译，资源与依赖是否正确。
3.测试层：核心逻辑与稳定用户路径是否满足断言。
4.运行层：真实界面是否可操作，状态转换和设备差异是否符合预期。
越靠前的反馈，越适合频繁执行；越靠后的反馈，越接近最终体验。高效流程不是跳过验证，而是尽量让问题在成本最低的那一层暴露。
04
代码写完，不等于功能做完
Android 应用的正确性不仅存在于源码里，还存在于屏幕、状态与交互之间。
按钮能否被点击？输入法弹出后会不会遮住关键操作？切到平板之后布局是否仍然可用？经历加载、失败和重试后，页面会不会落入无法恢复的状态？这些问题，很难只靠一次代码阅读确认。
当 Agent 能够启动应用、读取界面层级、截取屏幕并执行操作，它才有机会从"我认为这段代码正确"走向"我观察到了这个行为"。
因此，任务描述不应只写实现要求，还应该写验收路径。例如：
在现有收藏功能中增加撤销入口。完成后，启动应用，删除一条收藏，执行撤销，再次进入列表确认数据恢复。分别检查手机与平板布局，并记录实际结果。
这段描述的重点不是句式，而是把完成标准放到了用户行为上。它要求 Agent 验证修改，而不是只总结修改。
不过，截图也不是万能证据。界面看起来正确，不代表后台数据、持久化、异常恢复和并发场景都正确。可观察的 UI 行为需要与日志、测试和必要的数据检查结合，才能形成完整判断。
05
探索式验证，不要冒充确定性测试
自然语言非常适合描述目标："搜索一家酒店，选择符合条件的房型，尝试完成预订。"Agent 可以根据当时的界面状态决定如何操作，而不必要求人把每一次点击都写成固定脚本。
这种灵活性很有用，但它同时意味着：同一个目标，两次执行的路径可能不同。失败可能来自应用，也可能来自 Agent 的判断或操作。把这种结果直接当成稳定的提交门禁，容易制造难以复现的失败。
更清晰的分工是：确定性测试负责稳定基线，Agent 负责探索、补充检查和发现未知问题。
例如，用单元测试和 Espresso 等测试覆盖关键规则与回归路径，再让 Agent 尝试不同界面尺寸、异常状态或较长的用户流程。Agent 找到有价值的问题后，将其沉淀为可复现步骤；适合长期守护的行为，再转化为带明确断言的测试代码。
无论采用哪一种方式，都要说明初始状态。账号是否已登录、首次启动引导是否完成、数据库里有哪些数据、是否允许访问真实服务，这些条件如果没有固定，测试描述再清晰也可能走偏。
建议给探索式验证保留四类记录：起始条件、实际执行的动作、观察到的现象，以及能够支持结论的证据。结论不能只是一句"测试通过"。
本地模型也是类似的权衡。减少远程模型调用，不代表总成本归零；硬件、运行时间、决策稳定性和维护投入都要计算。模型选型应服从验证目标，而不是反过来迁就模型。
06
让审查先理解意图，再评价代码
AI 生成代码越快，开发者越容易从"写不完"变成"看不完"。如果审查依旧只是机械地逐文件翻阅，大量新增代码会迅速压垮人的注意力。
更有效的审查入口，是先回答三个问题：这次变更解决什么问题，采用了什么方案，又有哪些行为不应改变。理解意图之后，再把代码按职责或主题展开，而不是让文件顺序决定思考顺序。
另一个实用做法，是把实现与审查分开。实现 Agent 已经在某条路径上投入了大量上下文，容易沿着既有决策继续解释；独立审查者则更有机会发现遗漏的边界条件、缺少的测试和不合理的假设。
但独立审查不等于把决定权交出去。比如，迁移期间有意保留的重复代码，可能被建议抽成公共工具；为了保持兼容而留下的分支，可能被判断为可以删除。没有业务背景的"清理"，有时会破坏迁移节奏。
人的职责，是明确约束并判断建议是否成立：哪些接口不能改变，哪些重复是临时策略，哪些兼容成本必须承担，哪些风险需要在本次解决。
随着生成能力提高，审查重心也应向设计层移动。除了看代码是否能运行，还要看权限、数据边界、生命周期、错误处理、维护成本，以及未来的开发者能否理解这套实现。
07
把经验变成可加载的工作规范
当一个团队开始反复使用 Agent，同样的规则不应该每次重新解释。
架构约束、构建方式、测试入口、性能分析步骤和审查重点，都可以整理成简洁的项目说明。更专业、只在特定任务中使用的指导，则适合组织为按需加载的技能或参考资料。
这里的关键不是把提示写得越来越长，而是让知识在合适的时机出现。处理界面问题时，Agent 需要设备与 UI 工具；分析性能时，需要采样条件、追踪方法和结果解释；修改构建配置时，需要版本约束与验证步骤。
一份好的任务交接，也遵循相同原则：说明目标、约束、已经确认的事实、失败过的尝试，以及下一步需要验证的假设。它应保留有价值的决策信息，而不是复制整段对话。
例如，性能优化任务的交付物不应只是"建议减少主线程工作"，而应该包括如何复现、在哪里采集证据、观察到了什么，以及建议如何验证。工具输出可以提供线索，但线索与已经证明的根因必须区分。
08
从一条可控流程开始
不必一开始就搭建复杂的多 Agent 系统。可以先选一个边界明确的功能，用下面的流程建立团队的最小闭环：
1.定义任务：写清目标、不可变约束、验收条件和允许修改的范围。
2.确认环境：明确分支、工作区、构建入口、设备和初始数据。
3.只读分析：先梳理相关代码与测试，必要时让独立 Agent 并行研究。
4.实施修改：控制写入者数量，避免不同任务同时争用同一批文件。
5.分层验证：从静态检查开始，逐步进入构建、测试和设备行为验证。
6.独立审查：检查设计与边界条件，而不只是重复运行工具。
7.沉淀结果：记录证据，将关键回归转成确定性测试，更新项目规范。
衡量这条流程时，可以关注从修改到可信反馈的耗时、一次通过验收的比例、返工次数，以及人工审查负担。生成代码行数，只能描述产量，无法说明工程质量。
AI 可以扩大执行能力，但工程闭环决定这些能力能否被信任。
当环境有标准入口，任务有明确边界，修改有可验证证据，审查保留人的判断，Agent 才不只是一个写代码很快的工具，而会成为开发流程中可管理的一部分。
