uzqw

我的 AI 编程工作流，是如何从「写代码」演化到「工程治理」的

过去一年多 AI 编程工作流的演变：从写代码、设计系统让 AI 执行，到工程设施验证，再到重新设计人与机器的职责边界。

2026/08/15更新于 2026/08/15约 7 分钟

过去一年多，我使用 AI 编程工具的方式发生了一个明显变化。

一开始，我最关注的是：

AI 能不能帮我把代码写得更快？

后来我逐渐发现，这其实不是最重要的问题。

当代码生成速度越来越快以后，新的瓶颈开始出现：

  • AI 是否理解了我的真实需求？
  • 架构方向有没有偏？
  • 多个 Agent 同时工作时，谁负责协调？
  • AI 修改完代码以后，谁证明它是正确的？
  • 一个改动能够通过测试，并不意味着它在线上一定安全。
  • 当代码生成成本接近于零以后，真正昂贵的东西开始变成“决策”和“验证”。

我的工作方式因此逐渐从：

亲自写代码

转向：

设计系统，让 AI 执行，再通过工程设施验证结果。

这篇文章记录一下这个过程。

第一阶段：AI 首先解决的是代码生成速度

2025 年，我开始高频使用 AI 编程工具。

这个阶段对我最直接的帮助就是：

写代码明显变快了。

以前开发一个功能，需要自己：

  1. 查框架文档。
  2. 找类似实现。
  3. 写 CRUD。
  4. 写参数校验。
  5. 调接口。
  6. 修一些机械性错误。

AI 能够把其中大量工作压缩掉。

特别是在技术方案比较确定的时候，例如：

  • Go 后端接口开发；
  • React 前端页面；
  • 数据库 CRUD；
  • 框架样板代码；
  • 常规重构。

只要我能把要求描述清楚，AI 的实现速度通常远远高于自己手写。

这个阶段很容易产生一个错觉：

AI Coding 的核心问题，就是寻找更强的模型。

但随着使用越来越多，我发现并不是这样。

模型再强，也无法替代一个事实：

如果我自己不知道系统应该长什么样，AI 很容易把错误方向实现得非常完整。

于是第一个瓶颈出现了。

第二阶段：瓶颈从编码能力转移到了架构能力

当实现速度大幅提高以后，我越来越少卡在：

这段代码应该怎么写？

更多时候卡在：

这个系统到底应该怎么设计？

例如设计一个业务模块时，需要决定：

  • 数据应该存在哪里；
  • 哪个服务拥有数据所有权；
  • 状态如何流转；
  • 接口之间如何划分职责；
  • 哪些操作必须保证幂等；
  • 哪些失败需要补偿；
  • 哪些数据必须可追溯；
  • 历史系统如何兼容。

这些问题如果没有提前想清楚，AI 会非常高效地制造技术债。

这也是我逐渐形成的一种工作方式：

我负责建立 Problem Model，AI 负责 Implementation。

也就是说，我至少需要明确：

  • 当前问题是什么；
  • 核心数据是什么；
  • 系统边界在哪里；
  • 哪些约束不能违反；
  • 什么结果才算完成。

在这些东西清楚以后，AI 的代码实现反而变成了成本比较低的一部分。

这时我开始意识到：

AI 并没有让架构能力变得不重要，反而放大了架构能力的杠杆。

以前一个错误设计，可能因为开发速度慢，只造成几百行错误代码。

现在一个错误设计，可以让 Agent 在半小时内生成几千行错误代码。

方向错误的代价反而更大。

第三阶段：从「让 AI 写代码」变成「让 AI 完成任务」

后来，我开始进一步减少自己亲自执行的工作。

一个任务不再只是：

帮我实现这个函数。

而开始变成：

阅读这个模块，理解当前实现，按照约束修改代码，补测试，运行测试，并汇报风险。

任务粒度越来越大。

我开始使用：

  • Skills；
  • MCP；
  • 子 Agent；
  • Relay；
  • Workflow；
  • Kanban；
  • Agent 任务队列。

这个变化本质上不是“工具更多了”。

而是我开始把 AI 当成一个：

可以接受任务、执行任务、返回结果的计算单元。

于是问题再次发生变化。

以前的问题是：

AI 能不能写代码？

现在的问题是：

我如何同时管理三个甚至四个正在工作的 Agent？

如果每个 Agent 都需要我不断盯着：

  • 有没有跑完；
  • 有没有报错；
  • 下一步是什么；
  • 哪个任务优先；
  • 哪些结果需要我决策；

那么虽然 AI 在执行，我的大脑实际上仍然被大量上下文切换占用。

这时候新的瓶颈变成了：

调度。

我开始倾向于建立一个简单的任务中心：

Backlog
  ↓
Ready
  ↓
Agent Working
  ↓
Need Human Decision
  ↓
Verification
  ↓
Done

Agent 自己领取任务，执行后更新状态。

只有遇到真正需要人工判断的决策点，才通知我。

这让我意识到，多 Agent 的价值并不是：

同时打开很多终端。

而是：

降低人类参与每个任务生命周期的频率。

否则 Agent 数量越多，人反而越忙。

第四阶段：代码生成越强，验证能力越重要

真正让我改变最大的，是生产级项目。

在个人 Demo 里，AI 写出来的代码：

能跑。

很多时候已经够了。

但生产系统不一样。

例如一个会员系统，看起来只是：

  • 创建会员；
  • 更新会员；
  • 扣减额度；
  • 处理续费。

实际上会涉及：

  • 重复请求；
  • 异步事件；
  • 数据迁移；
  • 历史兼容；
  • 重试；
  • 网络失败；
  • 状态不一致；
  • 定时同步；
  • 第三方 Webhook；
  • 多服务同时读写。

AI 可以非常快地实现 Happy Path。

但生产事故通常发生在：

Happy Path 之外。

于是我的注意力开始从“生成代码”转向“证明代码”。

我开始越来越重视：

  • Hurl；
  • Testcontainers；
  • 集成测试；
  • E2E；
  • 日志；
  • Metrics；
  • Trace；
  • Error Tracking；
  • 数据库只读排查；
  • 发布前检查；
  • 数据一致性验证。

我逐渐形成了一个判断：

AI Coding 的核心竞争力，最终不会只是 Generation，而是 Verification。

如果 AI 一小时可以生成过去一天才能写完的代码，那么人类不应该再花一天继续生成代码。

真正应该投资的是：

如何在十分钟内知道这批代码到底能不能上线。

第五阶段：程序员正在从 Builder 变成 Controller

现在回头看，我过去一年使用 AI 的变化大概是：

Phase 1
我写代码，AI 辅助

↓

Phase 2
我设计，AI 实现

↓

Phase 3
我拆任务，Agent 执行

↓

Phase 4
系统自动调度 Agent

↓

Phase 5
我只处理关键决策和异常

这和传统软件工程里的自动化演进其实很相似。

程序员逐渐从：

操作机器的人

变成：

设计自动化系统的人。

未来我的目标不是让自己：

一天写更多代码。

而是让自己：

一天做更少但更重要的决策，同时让更多正确的工作自动完成。

这两者完全不同。

我现在采用的基本分工

目前我比较认可的人机边界是：

人负责

  • Problem Definition；
  • Architecture；
  • Constraints；
  • Priority；
  • Trade-off；
  • Acceptance Criteria；
  • Production Risk。

AI 负责

  • 搜索代码；
  • 阅读上下文；
  • 常规实现；
  • 重构；
  • 测试生成；
  • 文档整理；
  • 重复性排查；
  • 机械操作。

工程系统负责

  • CI；
  • Tests；
  • Observability；
  • Static Analysis；
  • Deployment Guard；
  • Runtime Feedback。

这三层组合以后，AI 才真正成为工程生产力。

否则只是：

一个写代码特别快的助手。

最后的判断

过去我比较关注：

哪个 AI 模型代码能力更强？

现在我越来越不关心这个问题。

因为模型能力会不断变化。

真正能长期复利的是另外几个问题：

  • 我能不能快速理解一个系统？
  • 我能不能给 AI 建立清晰约束？
  • 我能不能把任务拆成可以独立执行的单元？
  • 我能不能建立自动验证系统？
  • 我能不能只把真正重要的决策留给自己？

模型会变。

工具会变。

Agent 框架也会变。

但这些工程约束不会快速消失。

所以现在我更愿意把 AI Coding 理解成：

不是“用 AI 写代码”，而是重新设计软件工程里人与机器的职责边界。

评论