从编写Kotlin代码到管理智能体：移动工程师的新角色

编码助手不再仅仅停留在完成单行代码的任务上。它们会浏览代码库、规划修改方案、编辑多个文件、运行构建过程、分析错误并再次尝试。这对移动端工程师来说提出了一个棘手的问题：如果大部分 Kotlin 代码都是助手生成的，这还算是 Android 开发工作吗？还是说它已经悄然变成了在 IDE 中编写提示词的工作？本文认为这两种定义都不适用，并阐述了这一角色应有的新定位：撰写精确的规范、设计助手工作的环境、将架构要求转化为约束条件，以及验证那些并非自己输入的结果。

这些例子针对的是 Android，但其逻辑同样适用于使用同类工具的 React Native、网页开发及后端团队。

编码助手的发展历程

经典的 Android 开发流程我们都很熟悉：打开 Android Studio，创建类，编写 Kotlin 代码，处理 Gradle 相关问题，通过 Logcat 排查崩溃故障，在设备上进行测试，最后提交 pull request。

AI 辅助功能是逐步融入这一流程的。最初它只能完成单行代码，后来能处理整个函数，再后来则可处理整个类。目前的工具则表现为智能代理的角色。在撰写本文时，已有几款产品明确宣传了这一功能：

• Android Studio 中的 Gemini Agent Mode 可以接收高层次的开发目标，制定计划，调用相关工具，编辑多个文件，构建项目，并在某一步骤失败时进行迭代调整。
• Cursor 的 Agent 能够遍历代码库，修改多个文件，执行终端命令，在完成特定任务的同时修复错误，而不仅仅是提示下一行该写什么代码。

OpenAI Codex 作为编程代理在终端中运行，能够读取、修改并执行代码。

该领域的产品功能变化迅速，因此请查阅团队所使用工具的最新文档。不过发展方向是明确的。

工作正在向更上层推进

一个有用的思维模型是将工程活动视为一架梯子，最底层是机械性最强的任务，而最顶层则是需要更多判断力的任务：

Write code
   ↓
Understand code
   ↓
Design architecture
   ↓
Define requirements
   ↓
Make engineering decisions
   ↓
Validate behavior
   ↓
Own the product

智能体在基础层面已经表现得非常出色。这并不意味着编写和阅读代码变得毫无价值，只是改变了这些技能的价值所在。原本需要半小时手工完成的标准代码库实现，现在几秒钟就能生成。十个几乎相同的Compose界面手动编写十分繁琐；而智能体只需操作相关文件即可处理重复性内容。一个简单的编译错误就会耗费数分钟时间，而智能体只需读取错误信息、定位问题代码、修复它，然后重新编译并继续工作。

总体而言，工程师用于编写代码的时间减少了，而用于决定最初应该有哪些代码的时间则增加了。

一个好的提示语其实就相当于一份规范

以一个典型的产品需求为例：在应用中添加下载队列。经验丰富的 Android 工程师会将该需求在脑海中转化为分层设计：

Database
    ↓
Repository
    ↓
Use Cases
    ↓
ViewModel
    ↓
UI State
    ↓
UI
    ↓
Background execution
    ↓
Notifications

现在开发者可以实现这一架构中的大部分功能，但最终成果的质量在很大程度上取决于最初的请求内容。对比一下只有三个字的指令（“添加下载队列”）与如下这样的需求：

构建一个能够同时处理多个下载任务，并在应用重启后仍能保持状态的队列，由 Room 提供数据存储支持，WorkManager 负责执行实际下载操作。应在内存中跟踪进度，而非将每次更新都保存到数据库中。当进程被终止时，需恢复那些尚未完成或正在进行的下载任务。ViewModel 应该发布一个只读的 StateFlow。领域层中不得使用任何 Android 框架相关的类型。需通过单元测试来覆盖队列状态的变化以及故障恢复场景。不要修改与下载功能无关的 Room 实体类。

将第二个版本称为“更好的提示”其实低估了它的价值。它实际上是一份工程规范：其中明确了持久化技术、后台执行机制、性能决策（无需将每次进度更新都写入磁盘）、容错要求（能在进程崩溃后继续运行）、API契约（不可变的StateFlow）、分层规则、测试范围以及明确的影响范围。这些条款每一项都体现了Android相关知识，而智能体仅凭“添加下载队列”这样的描述是无法推断出这些内容的。

关键在于，工程师并没有消失，他们变成了能够将产品方模糊的需求转化为对技术系统精确描述的人。

提示工程与实际工程开发

这两种角色会提出不同的问题。专注于提示设计的人会思考如何让模型生成特定的输出；而工程师则想知道应该构建什么、为何要构建、在何种约束条件下构建，以及如何确认其功能正常。

假设有个开发者把这样的ViewModel交给你：

class DownloadViewModel(
    private val repository: DownloadRepository
) : ViewModel() {
    val downloads = repository.downloads
}

它能够正常编译且代码结构清晰。但即便是有经验的Android开发者，在接受之前仍会有诸多疑问：

• downloads是普通的Flow还是StateFlow？各自的收集器又会触发什么操作？
• 下载状态的唯一数据来源在何处？
• 进程终止后哪些信息会保留下来？
• 每次进度更新都会触发Room数据库的写入操作吗？
• 如果有两个下载同时完成会怎样？
• 如何实现取消操作的处理？

WorkManager能否重新启动这项任务，状态是否能够反映这一点？

网络断开时会发生什么？

如果用户强制终止应用程序，系统会如何反应？

从生命周期的角度来看，数据存储是否安全？

一次性触发的UI事件是否与状态分开处理？

在低端设备上，系统的表现如何？

生成相关类很简单，但围绕它来查询系统信息才是难点，而且自动化处理更是困难重重。

智能体开发循环

传统开发模式要求开发者参与每一步的关键流程：

Requirement
    ↓
Developer writes code
    ↓
Build
    ↓
Error
    ↓
Developer investigates
    ↓
Fix
    ↓
Test
    ↓
PR

引入智能体后，开发流程发生了变化。开发者仅在开始时设定目标，并在最后负责审核与验证，而智能体则负责中间的探索、编辑以及问题修复工作：

Developer defines goal
        ↓
AI Agent explores codebase
        ↓
AI creates plan
        ↓
AI modifies files
        ↓
AI runs build/tests
        ↓
AI observes result
        ↓
AI fixes problems
        ↓
Developer reviews
        ↓
Developer validates behavior
        ↓
Ship

供应商的文档也描述了相同的模式。Android Studio的Agent Mode被描述为规划、调用工具、修改文件以及迭代处理结果的过程。Cursor则将其代理视为一个能够进行推理的模型，拥有用于搜索、编辑文件或运行终端命令的工具，同时还包含一个循环结构，让代理能够观察结果并选择下一步操作。这已不再是简单的自动补全功能，而更像是将某项工程任务委托出去。

IDE作为协调层

这种转变改变了IDE的用途。它曾经只是单个开发者的工作台。在撰写本文时，Android Studio的AI工具已提供了以下功能：

• Agent Mode
• 多个并行运行的代理对话
• MCP服务器连接
• 项目级的AGENTS.md配置指令
• 对Android相关知识的访问权限

网络搜索

专业技能

权限管理

模拟器上的验证

Google将Agent Mode定位为能够处理多阶段开发任务，并提供MCP服务器及AGENTS.md作为扩展和操控它的手段。IDE不再仅仅是编写Kotlin代码的地方，而变成了运行和监控人工智能辅助工程环境的地方。

基础知识的重要性愈发凸显

人们很容易认为如果由智能体来编写代码，工程师掌握的知识就可以减少。事实恰恰相反：智能体会让错误的实现方式快速产生，因此需要更扎实的基础知识才能及时发现这些问题。

Kotlin

你仍然需要牢牢掌握那些最容易隐藏细微错误的语言特性：

Flow
StateFlow
SharedFlow
coroutines
structured concurrency
inline functions
sealed classes
value classes
delegation
generics
null safety

重点不在于自己手动编写每一行代码，而在于能够发现生成的 Kotlin 代码中存在的细微错误，比如本应使用冷流却使用了热流，或者协程在非结构化并发环境中被启动。

Android 平台

平台行为往往是生成代码在测试时看似正常，但在实际运行中出问题的地方：

Lifecycle
Process death
Configuration changes
Services
WorkManager
Room
Navigation
Permissions
Storage
Background execution
Notifications
Compose
Views
Performance

一个代理可以在几秒钟内生成一个 Worker 类。但这并不能说明该 Worker 是否遵循了应用程序的生命周期、重试机制以及各种约束要求。

将架构视为代理的约束条件

架构知识有了新的用途。MVI和MVVM、Clean Architecture、模块边界、数据存储层、依赖注入、状态处理以及领域分离等模式不仅仅是组织代码的方式，它们还变成了你赋予智能体的约束条件。与其说“开发一个功能”，你可以这样指令：

按照我们现有的MVI架构来开发这个功能，参照功能A和功能B中的模式实现，不得引入新的依赖项。业务规则应放在领域层中。

参考现有的功能尤其有效，因为这能让智能体直接看到代码库中经过验证的具体示例，而非仅依赖其对“MVI”这一概念的模糊理解。架构 thus 成为了你用来指导智能体的语言的一部分。

使用AGENTS.md给出数据存储层级别的指令

许多团队在每次会议中都会反复强调同样的要求：项目需使用 Kotlin 和 Hilt，业务逻辑不应出现在 Composables 中，状态应通过 StateFlow 暴露，必须遵循命名规范，需要编写测试，同时禁止修改自动生成的文件。

这些要求可以直接存储在代码仓库中。目前，Android Studio 的 Gemini 工具会读取记录有此类规范的 AGENTS.md 文件，从而使相关工具将它们视为项目上下文。其他工具也会读取类似的文件；关于这一点的详细内容可见 编写有效 CLAUDE.md 文件的实用指南。

这虽是个小小的改动，却能带来重大影响。传统上，代码仓库仅用于存储：

source code
configuration
tests
documentation

现在它还可以存储：

AI engineering instructions

代码库开始同时描述软件本身以及智能体应如何在其上工作。将这些说明视为代码来处理：审查其中的变更，保持其简短且具体，并删除不再适用的规则。

MCP将智能体与工具链的其余部分连接起来

模型上下文协议使人工智能系统能够连接到外部工具和服务，这意味着智能体不再局限于聊天界面。通过MCP服务器，它有可能访问：

GitHub
Databases
Design tools
Documentation
Issue trackers
CI systems
Cloud services
Internal APIs

Android Studio的AI工具目前支持连接MCP服务器，包括远程服务器。设想有一个请求，要求该智能体根据Figma文件创建一个新的Profile界面，复用现有的设计元素，将该界面与profile接口相连，处理加载和失败状态，添加测试并准备好拉取请求。完成这一任务需要同时涉及多个系统：

Developer
    ↓
AI Agent
    ├── Figma
    ├── Codebase
    ├── Documentation
    ├── API
    ├── Tests
    ├── Git
    └── CI

当一个工具能够协调设计文件、代码、文档、API、测试、Git以及CI流程时，用“代码生成器”来描述它是不准确的。它实际上是一个工程智能体，而其功能范围也正是权限和审核至关重要的原因：每一个被连接的系统都是该智能体可以读取或修改的对象。

陷阱：依赖性强但能力不足

这种新架构存在一种典型的故障模式：开发者可能会依赖人工智能，却并未真正掌握其使用方法。完全有可能写出使用了所有这些功能的代码：

Flow
StateFlow
SharedFlow
CoroutineScope
SupervisorJob
Channel

却根本不明白它们各自的作用。所有代码都能成功编译，工作进度看似很快，但几个月后系统就会出现与生命周期取消相关的竞态条件，而团队中没人能解释其原因。

人工智能虽然加快了打字速度，但并未提升开发者的能力。正因如此，审查人工智能生成的代码或许比具备生成代码的能力更为重要。给团队的一个实用准则是：绝不要合并那些在审查时无法逐行解释的生成代码。

上下文才是真正的关键

编码智能体在很大程度上依赖于其接收到的上下文。例如，Cursor的文档将智能体系统描述为由上下文、工具、指令和模型构成的整体。这表明二者之间存在大致的乘法关系：

Agent Quality
=
Model
× Context
× Tools
× Instructions
× Verification

其中的乘法运算才是关键。即便模型性能很强，但如果上下文质量较差，最终生成的软件质量也会很差，因为接近零的系数会拉低整个结果。相反，一个性能不错的模型在结构清晰、测试完善、文档详尽且指令明确的代码库中运行时，表现会好得多。真正需要掌握的技能是上下文工程，而提示词编写只是其中的一部分而已。

为何“提示词工程”概念过于狭隘

将两者放在一起对比就能很容易看出差异。单纯的提示词看起来像这样：

"Create a login screen."

经过上下文工程处理的请求则看起来像这样：

Here is our architecture.
Here are our design rules.
Here is the API contract.
Here are existing authentication patterns.
Here are the tests.
Here are the project constraints.
Here is the expected behavior.
Now implement the feature and verify it.

第二种方式是将架构、设计规则、API契约、现有的认证模式、测试用例、约束条件以及预期行为一并交给智能体，再要求其同时实现并验证这些内容。这更接近于向新同事介绍工作的方式，而提示语只是其中的一个组成部分。当智能体表现异常时，有必要查明是哪些环节缺失了；我们的按层次调试AI智能体指南详细介绍了这种诊断方法。

工程师负责设计整个流程

最大的变化可能在于责任划分。以往的关系是直接的：

Developer → Code

现在的模式则要经过多个阶段，而工程师需要负责所有这些阶段：

Developer
    ↓
Specification
    ↓
Agent
    ↓
Tools
    ↓
Code
    ↓
Tests
    ↓
Verification

掌控循环意味着要清楚某种情况需要执行哪条指令：

• 当任务定义明确且风险较低时，选择“直接执行”。
• 当变更涉及多个模块时，选择“先制定计划”。
• 在修改代码之前需要先理解整体架构时，选择“暂时不动代码，先研究架构”。
• 在接受任何修复方案之前，选择“重现故障”。
• 当执行路径明显错误时，选择“停止；你的假设有误”。

最后这种干预措施或许是最宝贵的技能之一，而这完全取决于是否足够熟悉平台，从而能发现错误的假设。

既不是安卓开发者也不是提示词工程师

单独来看，这两种标签都无法完整体现该角色的职责。仅会手动编写 Kotlin 的 Android 开发者在效率上会落后；那些能向人工智能请求 Kotlin 代码却不懂 Android 架构的人迟早会陷入困境。理想的组合应该是这样的：

Android Engineering
        +
AI Agent Skills
        +
System Design
        +
Context Engineering
        +
Verification
        =
AI-Augmented Android Engineer

实际上，这意味着要不断巩固 Android 相关知识，深化对架构的理解，学会向机器准确表达需求，并熟悉各种智能体、它们的工具、MCP、仓库指令以及自动化检查机制。最重要的是，要学会判断人工智能何时出错——智能体可以轻松生成两千行代码，但是否应该保留这些代码则需工程师来判断。

更现实的未来并非人工智能取代开发者，而是那些能与智能体高效协作的开发者取代那些无法与之协同的工作流程。具备扎实基础且拥有完善配置的智能体环境，能够让一名工程师完成过去需要大量人工投入的工作。工程工作并不会消失，而是提升到更高层次——在这一点上，推理、定义约束条件以及验证结果比单纯的键盘操作更为重要，而架构则如同地图，防止智能体偏离方向。

核心要点

• 将给智能体的指令视为规范：明确说明所使用的技术、性能要求、可靠性标准、契约条款、测试范围以及不可更改的内容。
• 审查生成的代码时，应通过分析相关系统的运行机制（状态管理、生命周期、进程终止、并发处理、取消操作）来进行，而非仅检查其是否能编译通过。

重视基础要素，正是它们能帮助你及时发现那些看似合理实则错误的实现方式。

将团队规范编码到仓库级别的说明文件中，如AGENTS.md，并像对待代码一样维护它们。

通过优化上下文（架构、测试、文档、示例）来提升结果，因为某个薄弱环节会限制整体表现。

始终掌控流程的主导权：决定智能体何时应该行动、规划、调查、复现或停止。