AI 编程 Agent 进入生产代码后开发者的角色转变

我的第一次在 IDE 中使用 AI 的体验是简单的自动补全。

你输入一个函数名，等待灰色的幽灵文本出现，按下 Tab，然后继续。

它对工具函数、正则表达式、样板代码和重复性代码很有用。

然后 AI 编码 Agent 出现了。

现代 Agent 不再局限于单个文件内部、预测接下来的几行代码，而是可以横跨整个代码仓库工作。它们可以检查多个文件、追踪依赖关系、规划变更、编辑代码、运行终端命令、读取构建错误，并迭代改进自己的实现。

当我不再把 AI 当作自动补全工具，而是开始让它在生产代码上承担真正的仓库级任务时，我的工作流程发生了显著变化。

有趣的地方不在于 AI 能更快地写代码。

而是当实现变得便宜得多时，开发者角色发生了什么变化。

1. 我的工作流程发生了什么变化

思维转变很简单：

你不再主要是打字员，而是开始更像是一个技术负责人，在指挥一个非常快速的新人工程师。

传统的工作流程大致如下：

Read Task
   ↓
Find Relevant Files
   ↓
Design Solution
   ↓
Write Code
   ↓
Test
   ↓
Debug

使用 AI 编码 Agent 后：

Define Context & Constraints
           ↓
      Direct Agent
           ↓
      Multi-File Work
           ↓
    Verify & Iterate
           ↓
      Review Diff
           ↓
   Validate in Runtime

我仍然对解决方案负责。

但我花更少的时间打重复性代码，更多的时间思考：

这大概是我注意到的最大变化。

在三个领域，我发现它们特别有用。

跨文件重构

看似很小的改动可能很容易波及多个层级：

API Service
    ↓
Transformation
    ↓
Custom Hook
    ↓
Component
    ↓
Tests

Agent 可以追踪这些关系，并以比手动搜索每个文件快得多的速度进行协调变更。

例如，与其花时间查找重命名属性的每个引用，我可以这样问：

"追踪这个属性的所有消费者，一致地更新实现，但不要改变公共 API。"

重要的部分是约束条件。

没有约束条件，Agent 可能会正确地解决问题，但同时也更改了你没有要求它更改的东西。

调试和流程追踪

一些最难的 bug 不是由复杂的代码引起的。

而是由几个简单的部分以意想不到的方式交互引起的。

Auth Event
    ↓
Token Refresh
    ↓
Background Operation
    ↓
State Update
    ↓
UI Update

在立即让 Agent 修复 bug 之前，我通常先让它调查：

"追踪如果在 fetchNextPage() 仍在运行时 refreshAuth() 解决了会发生什么。先不要修改代码。识别可能的竞态条件和生命周期问题。"

这使得 Agent 作为代码库探索工具而非代码生成器变得有用。

AI 也非常擅长生成重复性测试的第一个版本。

但生成的测试仍然需要审查。

测试通过不一定意味着正在测试正确的行为。

我自己的工作流程中有一个例子，是关于一个 React Native Android TV 应用的性能问题。

Home 屏幕包含多个水平内容轨道。在后台刷新期间，新数据必须合并到现有 UI 中，同时不必要地重建所有内容。

"修复这个性能问题。"

我让 Agent 首先追踪数据流，找出在哪里创建了新的对象和数组引用。

Agent 发现合并路径正在不必要地重建数据结构中更多的部分。

最终的方法很简单：

只更新其数据发生变化的轨道，保留未更改数据的引用。

这部分效果很好。

但是在重构期间，Agent 还更改了一些列表项使用的 key。

但在 Android TV 上，这个更改影响了焦点行为，因为一些项目被当作新组件处理。

这就是说明当前 AI 编码 Agent 边界的一类问题。

Agent 很擅长理解数据转换问题。

它并不能自动意识到组件标识对平台的焦点行为也很重要。

必须由熟悉应用和运行时的开发者来发现这个问题。

这是一个重要的教训：

AI 可以理解代码，但不能完全理解系统。

一旦你在生产代码上使用 Agent，它们的盲点就变得相当明显。

让 Agent 创建一个小型的缓存辅助函数，你可能会得到：

CacheManager
    ↓
CacheRepository
    ↓
CacheFactory
    ↓
CacheStrategy
    ↓
CacheProvider

而你需要的只是：

getCache(key);
setCache(key, value);

AI 倾向于泛化。

生产代码通常受益于保持简洁。

如果问题简单，解决方案可能也应该简单。

框架特定行为

AI 非常擅长常见的 React 和 JavaScript 模式。

但生产应用通常依赖于平台特定的行为。

例如，在 Android TV 应用中，你可能需要推理：

• 空间焦点导航
• JavaScript 运行时行为
• 设备特定内存约束

生成的代码可能是有效的 React Native 代码，但对于该平台来说仍然是错误的解决方案。

AI 通常优化的是看起来干净和地道的代码。

但性能是上下文相关的。

例如，多个数组操作并不自动就是坏的。问题在于在性能关键路径中重复进行时不必要的分配。

看起来更简洁的实现不一定更快。

性能应该被测量，而不是被假设。

本地代码和构建系统

当 Agent 修改本地代码或构建配置时，我特别谨慎。

Gradle、Kotlin、C++、本地模块、SDK 版本和生成代码都可能以从单个文件看不出来的方式交互。

Agent 可能产生一个看起来完全合理的配置，但仍然会因为环境级依赖或版本不匹配而失败。

终端输出往往比生成的代码更有用。

隐藏的架构规则

每个成熟的代码库都有不一定被写下来的规则。

"这种状态在启动期间绝不能被同步读取。"

"这个组件必须保持其标识，因为焦点状态依赖于它。"

"不要在这里引入另一个缓存层。"

这些规则通常存在于团队知识中，而非文档中。

AI Agent 无法可靠地遵循它不知道存在的约束。

我的工作流程相当简单：

Context
   ↓
Constraints
   ↓
Small Task
   ↓
Verification
   ↓
Diff Review
   ↓
Runtime Validation

不要立即让它实现功能。

首先让它理解现有的实现并识别相关文件。

我明确声明诸如：

• 不要添加依赖。
• 不要改变公共 API。
• 遵循现有架构。
• 不要修改请求范围之外的文件。

约束通常比更长的期望实现描述更有价值。

"实现整个缓存架构。"

1. 分析当前数据流。
2. 实现存储工具。
3. 添加测试。
4. 将其集成到现有 hook 中。
5. 验证行为。

小任务使错误的假设更容易被捕捉。

4. 让 Agent 验证其工作

如果项目有自动化检查，让 Agent 运行它们：

npm run lint
npm test

Implement
   ↓
Run
   ↓
Fail
   ↓
Inspect
   ↓
Fix
   ↓
Run Again

这是我不会跳过的部分。

我审查 AI 生成的变更，几乎像对待另一位工程师的代码一样。

• 为什么这个文件改变了？
• 为什么引入这个抽象？
• 行为是否在需求之外发生了改变？
• 是否添加了依赖？
• 是否引入了新的分配？
• 计时器和监听器是否被正确清理了？
• 组件标识是否改变了？
• 现有状态是否被意外修改了？

问题不仅仅是：

"为什么 Agent 做了这些决定？"

6. 在真实硬件上验证

对于运行时行为重要的应用，测试是不够的。

React Native Android TV 应用可以通过测试，但仍然可能：

• 消耗过多内存
• 在低端硬件上表现不同

所以最终验证循环需要包括真实环境。

随着 AI 处理更多的机械实现工作，我认为几项工程技能变得更加重要。

• 知道代码应该放在哪里以及系统应该如何交互。
• 能够精确地定义需求、边界和不变量。
• 理解为什么某事发生，而不仅仅是更改代码直到症状消失。
• 知道如何测量内存、CPU、渲染和运行时行为。
• 理解框架之下发生了什么。
• 能够识别不是你亲自编写的代码中的微妙问题。

最后一项可能变得特别重要。

如果 AI Agent 可以几秒钟生成数百行代码，正确评估这些行的能力变得更有价值——而不是更没价值。

我不认为未来是：

Human → AI → Code

我认为更接近于：

Human defines the problem
          ↓
AI investigates
          ↓
Human validates the approach
          ↓
AI implements
          ↓
AI verifies
          ↓
Human reviews
          ↓
Real-world validation
          ↓
Ship

人类对结果负责。

AI 加速执行。

这是一个比"AI 取代开发者"有用得多的思维模型。

在生产代码上使用 AI 编码 Agent 后，我最大的收获不是 AI 写代码更快。

这已经很明显了。

更有趣的变化是瓶颈转移了。

以前，大量的工程时间花在将已知解决方案转化为代码上。

AI 现在可以处理更多的这种翻译工作。

困难的问题变成：

• 我们应该构建什么？
• 它应该放在哪里？
• 什么约束是重要的？
• 性能影响是什么？
• 我们如何知道解决方案实际上是正确的？

当你把 AI 编码 Agent 当作实现和调查伙伴时，它们非常有用。

当你把它们当作不需要审查其决策的自主工程师时，它们是危险的。

最适合我的工作流程很简单：

给 AI 足够的上下文来理解问题，足够的约束来避免不必要的决策，足够的工具来验证其工作，足够的人工监督来捕捉它看不到的东西。

AI 越擅长写代码，好的工程判断力就越有价值。

这可能是 AI 编码 Agent 给我的工作流程带来的最大变化。