note-md

人在AI开发中的角色演进

随着大语言模型能力的飞速进化，我对 AI 开发的认知也经历了深刻的变化。 从最初把 AI 当作一个”智能补全器”，到如今可以将完整需求交给 AI Agent 自主完成，每一次跃迁都伴随着开发模式的重构和工程师角色的重新定义。

本文以 人的角色演进 为主轴，梳理这一变化历程。 每一次阶段跃迁的本质，是人”放下”了某项具体工作，将其交给 AI，同时承担起更高层次的职责。

编码者  -->  审查者  -->  指挥者  -->  验收者  -->  Tech Lead
     放下键盘     放下红笔     放下操控杆     放下单任务

1. 编码者：人写代码，AI 加速打字

2021 – 2023，以 GitHub Copilot 为代表

1.1 AI 能力

1.2 开发模式

工程师在 IDE 中编写代码，AI 在光标处实时提供补全建议，工程师按 Tab 接受或忽略。本质上是 “人写代码，AI 加速敲键盘”。

工程师编写代码  -->  AI 实时补全建议  -->  工程师接受/忽略  -->  继续编写

1.3 工程师核心关注点

1.4 典型范例

# 工程师输入注释
# 计算两个日期之间的工作日天数

# AI 自动补全函数体
def count_workdays(start_date, end_date):
    count = 0
    current = start_date
    while current <= end_date:
        if current.weekday() < 5:  # Monday = 0, Friday = 4
            count += 1
        current += timedelta(days=1)
    return count

工程师写注释或函数签名，AI 补全实现。工程师需要逐行审查补全内容是否正确。

1.5 典型挑战

1.6 认知

跃迁驱动力：随着 LLM 能力增强，工程师发现 AI 不仅能补全一行，还能生成整个函数甚至文件。手动逐行编写开始显得低效——为什么不让 AI 直接写，我来审查？

2. 审查者：AI 写代码，人逐行审查

2023 – 2024，以 ChatGPT/Claude 对话式编程、Cursor Chat 为代表

2.1 AI 能力

2.2 开发模式

工程师用自然语言描述需求，AI 生成或修改代码，工程师逐行 Review 并手动应用修改。核心是 “人描述需求，AI 写代码，人审查每一行”。

工程师描述需求  -->  AI 生成/修改代码  -->  工程师逐行 Review  -->  手动应用修改  -->  反馈调整  -->  循环

关于 Vibe Coding：Andrej Karpathy 于 2025 年提出 Vibe Coding 概念——”完全放弃理解代码，拥抱直觉”。这实际上是审查者阶段的 反模式：放弃了 Review 职责的审查者。Simon Willison 进一步区分了 Vibe Coding（不审查、凭感觉）和 Vibe Engineering（利用 AI 但结合测试、Review 等工程实践）。本阶段的正确做法是后者。

2.3 工程师核心关注点

2.4 典型范例

工程师：帮我写一个用户注册的 API，使用 Go + Gin 框架，需要验证邮箱格式和密码强度。

AI：[生成 200 行代码]

工程师：（Review 后发现）密码校验逻辑不对，应该要求至少包含大小写字母和数字，
       而且错误返回格式不符合我们项目的统一响应格式，请参考 xxx.go 的写法。

AI：[修改后重新生成]

工程师：（继续 Review）这次密码校验对了，但你把邮箱验证的正则改错了...

每一轮生成都需要工程师仔细审查，往往需要 3-5 轮对话才能得到满意的结果。

2.5 典型挑战

2.6 认知

跃迁驱动力：逐行 Review 的疲劳感和低效率成为核心痛点。工程师开始思考：能不能让 AI 先出方案，我审方案而不是审代码？能不能让 AI 像一个可指挥的 Agent，而不是一个需要逐字检查的打字员？

3. 指挥者：人审核方案，实时操控 Agent

2024 – 2025，以 Cursor Agent、Claude Code、Windsurf 等 IDE Agent 为代表

3.1 AI 能力

3.2 开发模式

工程师像指挥者（Conductor）一样与 Agent 紧密协作：定义需求或 Spec，审核 Agent 的执行计划，在关键节点给予指令调整。“人审方案、指挥行动，AI 执行落地”。

工程师定义需求/Spec  -->  AI 生成 Plan  -->  工程师审核 Plan  -->  AI 执行（读写文件、运行命令） -->  工程师在关键节点调整方向  -->  微调交付

信任度在这个阶段呈渐进式增长：

3.3 工程师核心关注点

3.4 典型范例

工程师：请根据 user-api.yml OpenAPI 定义，开发用户管理页面 static/views/system/user，
       包括搜索、列表展示、详情、新增、编辑、删除功能。
       详情、新增、编辑、删除分别点击按钮弹框进行操作。

AI Agent：[进入 Plan 模式，输出执行计划]
    1. 分析 user-api.yml 中的接口定义...
    2. 创建 User.html 模板，包含搜索栏和表格...
    3. 创建 User.js，实现数据加载、分页、CRUD 操作...
    4. 创建 User.css，样式与项目风格保持一致...

工程师：（审核 Plan）Plan 没问题，执行吧。
       另外搜索要支持按角色筛选，Plan 里漏了。

AI Agent：[更新 Plan 并执行，自主完成文件创建和代码编写]

工程师的重心从”逐行 Review 代码”转移到”审核计划是否符合需求”，效率大幅提升。

3.5 典型挑战

3.6 认知

跃迁驱动力：实时操控 Agent 仍然是”一人一 Agent”的串行模式，人是瓶颈。工程师开始思考：能否前置定义好约束和验收标准，让 Agent 自驱完成并自我验证，从而解放人的实时关注？

4. 验收者：人定义约束，只看结果

2025 – 2026，以 TDD 驱动、自动化测试约束、CI 质量门禁为代表

4.1 AI 能力

4.2 开发模式

工程师的工作被 前置 和 后置 两段化：前置定义需求、验收标准和约束规则，后置检查测试是否通过、功能是否符合预期。中间过程由 Agent 自驱完成。“人定义约束，AI 在约束内自主交付，人只验收结果”。

工程师定义需求 + 验收标准 + 约束规则  -->  [人退出过程]  -->  AI 生成测试  -->  AI 编写实现  -->  自动运行测试  -->  失败则自动修复  -->  全部通过  -->  人验收结果

对应 Addy Osmani 的 Orchestrator 角色：前端装载（写 Spec、设约束）、后端验收（看测试结果）、中间不介入。一个 Orchestrator 可以并行管理的总工作量远超实时操控单个 Agent 的模式。

4.3 工程师核心关注点

4.4 典型范例

工程师：实现订单超时自动取消功能。

       验收标准：
       1. 订单创建 30 分钟后未支付，自动标记为"已取消"
       2. 取消时释放库存
       3. 发送取消通知给用户
       4. 并发场景下不会重复取消

       约束：
       - 使用延迟队列实现
       - 编写单元测试覆盖所有边界情况
       - 编写集成测试验证完整流程
       - 所有测试通过后提交

AI Agent：
  [步骤1: 分析需求，生成测试用例 - 15个单元测试 + 3个集成测试]
  [步骤2: 运行测试  -->  全部失败（红）]
  [步骤3: 编写实现代码]
  [步骤4: 运行测试  -->  2个失败  -->  分析原因  -->  修复  -->  全部通过（绿）]
  [步骤5: 运行 lint + 静态分析  -->  通过]
  [完成: 所有验收标准已通过验证]

工程师无需查看代码，测试和质量门禁就是”自动化审查员”。

4.5 典型挑战

4.6 认知

跃迁驱动力：单 Agent 的”自己写自己审”仍然有局限——谁来验证约束本身是否完备？系统级的复杂变更超出单 Agent 能力范围。工程师开始需要多个 Agent 分工协作、互相制衡。

5. Tech Lead：人管理 AI 工程团队

2026+，以多 Agent 协作、角色分工、项目级自主交付为代表

5.1 AI 能力

5.2 开发模式

工程师像 Tech Lead 一样给出项目级需求，Agent Team 自主完成从架构设计到代码交付的全过程。 各角色 Agent 分工协作、互相验证，形成内部的 Review 和制衡机制。“人是 Tech Lead，AI 是工程团队”。

工程师给出项目需求  -->  Orchestrator Agent 分解任务
   -->  Architect Agent 设计架构
   -->  Dev Agent(s) 并行编码
   -->  Test Agent 独立编写测试并验证
   -->  Review Agent 审查代码质量
   -->  发现问题则反馈给 Dev Agent 修复
   -->  全部通过  -->  交付

5.3 工程师核心关注点

5.4 典型范例

工程师：我们需要为系统增加多租户支持。要求：
       1. 数据层面完全隔离，每个租户独立 schema
       2. API 层通过 header 识别租户
       3. 现有功能全部兼容，不影响已有租户
       4. 需要租户管理后台（CRUD + 配额管理）

Agent Team：
  [Orchestrator: 分解为 4 个子任务，分配给不同 Agent]
  [Architect Agent: 设计多租户架构方案，输出架构文档]
  [Dev Agent 1: 改造数据层，实现 schema 隔离和动态路由]
  [Dev Agent 2: 改造 API 中间件，实现租户识别和注入]
  [Dev Agent 3: 开发租户管理后台页面和 API]
  [Test Agent: 为每个模块独立编写测试，编写跨模块集成测试]
  [Review Agent: 审查各模块代码，检查接口一致性和安全性]
  [Dev Agent 1: 根据 Review 反馈修复数据层隔离漏洞]
  [集成验证: 全部模块联调测试通过]
  [完成: 输出变更摘要和部署指南]

工程师只需在关键节点（架构方案确认、最终验收）介入，中间过程由 Agent Team 自主运转。

5.5 典型挑战

5.6 认知

6. 阶段对比总结

维度 编码者 审查者 指挥者 验收者 Tech Lead
时间 2021-2023 2023-2024 2024-2025 2025-2026 2026+
代表工具 Copilot ChatGPT, Cursor Chat Cursor Agent, Claude Code Claude Code + TDD + CI Multi-Agent 编排框架
AI 角色 打字助手 结对程序员 可指挥的 Agent 自驱开发者 工程团队
人做什么 写代码 Review 每行代码 审核 Plan、实时指挥 定义约束、验收结果 定义目标、架构决策
人不再做什么 — 不再亲手写 不再逐行 Review 不再实时操控 不再管单个任务
交互粒度 行/块 文件 模块/功能 需求/验收标准 项目/系统
信任度 不信任 低信任（逐行验证） 中信任（Plan 级验证） 高信任（结果级验证） 委托信任
质量保障 人工编写 人工逐行 Review 审核 Plan + 抽查代码 自动化测试驱动 Agent 互审 + 自动化
典型挑战 补全质量不稳定 Review 疲劳 上下文管理、信任校准 约束设计能力要求高 协调成本、一致性
角色跃迁 — 放下键盘 放下红笔 放下操控杆 放下单任务

7. 对未来的展望

7.1 下一阶段：意图编程（Intent Programming）

随着 AI 能力继续增强，下一个阶段可能进入 意图编程 时代：

工程师："我们的用户流失率在注册后第3天达到峰值，需要改善新用户引导体验。"

AI：[自主分析用户行为数据  -->  设计引导方案  -->  实现功能  -->  A/B测试  -->  输出结果报告]

7.2 当前的现实约束

通往意图编程的路上仍有显著障碍：

7.3 终局：AI 原生软件工程

终局不是 AI 替代程序员，而是 软件工程的范式彻底改变：

7.4 带来的影响

对个人：

对团队：

对行业：

参考