AI 影响下的工程开发流程

AI影响下的工程开发流程

引言

AI（特别是大语言模型与代码助手）正在重塑工程开发的底层流程。这种重塑不是简单的"工具升级"，而是对协作单位、职责边界、交付物形态的重新定义。本报告围绕五个核心问题展开：AI 能做什么、人机之间交换什么、各方的责任、流程如何演变、AI 当前的局限。最后给出一个完整的软件工程协作案例。

报告的基本立场：AI 当前最准确的定位不是"替代工程师"，而是头脑风暴伙伴 + 高级程序员 + 知识秘书的复合体。它承担的是认知劳动中可被外包的那一层，把人解放出来去做真正只有人能做的事——定义意图、做高层判断、承担最终责任。

一、AI 能承担的工作

按"AI 主导 / 协作 / 人主导"三档划分，更接近实际工作分配方式：

AI 可以主导的工作

这类工作的共同特征是：有明确输入、有可验证输出、模式重复度高。

协作完成的工作

这类工作 AI 出方案、人做判断，或者反过来人定方向、AI 出实现。

不适合 AI 主导的工作

二、双方交换的中间产品

这是 AI 协作流程中最容易被忽视、也最值得设计的部分。中间产品的形态决定了协作的效率与质量。

人 → AI 的输入

类型 说明 质量决定因素
意图描述 任务目标、成功标准、约束 越具体越好，给负面例子比正面例子更有效
上下文信息 相关代码、文档、历史决策 选择性而非全量；相关性 > 完整性
规则与偏好 编码规范、命名习惯、技术栈约束 通常以 CLAUDE.md / AGENTS.md / cursor rules 等形式持久化
示例与反例 已有实现、想模仿的风格 比抽象描述更高效
反馈 对前一轮输出的修正、追问 是收敛速度的关键

AI → 人的输出

类型 说明 验证方式
代码 函数、模块、完整应用 测试、运行、评审
方案与备选项 多个可行方向的对比 人的判断与组织决策
解释与教学 概念、为什么、注意事项 与权威来源交叉验证
文档 接口说明、设计文档、操作手册 与实际行为对照
风险提示 潜在 bug、安全问题、不确定的地方 人来决定是否接受
元产物 任务计划、TODO 列表、进度报告 用作协作上下文

一类被低估的"新工件"

这些产物在传统流程中不存在或不重要，但在 AI 协作流程中变成了一类核心资产：

这些新工件本身需要被维护、评审、版本化。它们和代码一样，是工程资产。

三、各方的职责与义务

人的职责

不可外包的核心职责：

对 AI 的义务：

AI 的职责

组织/团队的职责

这是经常被忽略的一层：

四、流程演变：当前与未来

阶段 0：传统流程（AI 无关）

需求 → 设计 → 编码 → 测试 → 评审 → 上线，人在每一步都是主体。

阶段 1：AI 作为补全工具（当下大多数团队）

IDE 内的代码补全、对话式查询、零散使用聊天助手。AI 只在编码环节出现，且粒度很小（几行到几个函数）。流程本身没有改变，只是某些环节人的输入速度提升了 20-40%。

阶段 2：AI 作为协作伙伴（领先团队的当前状态）

AI 进入需求澄清、设计讨论、代码评审、文档生成等多个环节。人和 AI 之间形成"对话循环"。出现了新的工件（CLAUDE.md、prompt 模板）。流程开始重组：某些步骤被压缩，某些步骤被新增（如"上下文准备"）。

特征：

阶段 3：Agent 模式（正在发生）

AI 不再是一问一答，而是接受一个任务后自主多步执行：读代码、跑测试、改代码、再跑测试、提 PR。人变成"任务发起者 + 关键节点审批者 + 最终验收者"。

新的流程角色出现：

阶段 4：意图驱动开发（远期推测）

人主要工作变成精确描述意图和判断结果是否符合意图。中间过程（设计、编码、测试、文档）大部分由 AI 完成。这要求：

不同团队的演进速度差别会很大。判断自己处在哪个阶段，比预测未来更重要。

流程对比表

环节 传统流程 AI 协作流程
需求 人写 PRD 人定方向，AI 协助提问、整理、生成用户故事
设计 人画图、写 ADR 人定关键决策，AI 给方案对比与初稿
编码 人逐行写 AI 写大部分，人定算法核心与边界
测试 人写主要用例 AI 大量铺开，人定关键场景
评审 人对人 AI 预审 + 人做架构判断
文档 事后补写（常缺） AI 同步生成，人审定
调试 人主导 AI 提假设，人收敛
上线 人决策 人主导，AI 辅助监控查询、文档、公告
新增：上下文工程 不存在 持续维护规则文件、知识库、模板
新增：eval 与回归 不存在 评估 AI 输出质量的标准化机制

五、AI 当前的局限及应对

局限一：欠缺领域专业知识背景

表现：

根本原因：

应对策略：

局限二：欠缺高层次的设计与抽象能力

表现：

根本原因：

应对策略：

局限三：欠缺品位

表现：

根本原因：

应对策略：

局限四：不能进行高层级、大范围的知识处理

表现：

根本原因：

应对策略：

局限的本质判断

需要诚实区分两类局限：

  1. 模型本质局限：当前架构难以在短期内突破，必须靠流程设计绕开
  2. 上下文工程不到位：表面看是 AI 不行，实际是没把信息组织好

很多被归为"AI 能力不足"的问题，其实是后者。在抱怨 AI 之前，先问：我给的上下文够吗？任务描述清晰吗？验证机制建立了吗？

六、案例：为电商 SaaS 平台添加"促销引擎"

案例背景

一个运行 3 年的电商 SaaS 平台，服务约 2000 家中小商家。当前促销功能只有"全场折扣"和"满减券"两种，商家反馈强烈要求更灵活的促销规则：

团队配置：1 PM、3 后端、2 前端、1 测试，预计 8 周完成 MVP。

下面按阶段展示 AI 与人的协作模式、中间产品、时间分配。

阶段 1：需求探索（第 1 周）

目标：搞清楚商家真正需要什么、优先级如何、有哪些隐藏约束。

角色 工作内容
人（PM） 访谈 8 家代表性商家、调研 3 个竞品、与销售/客服对齐
AI 整理访谈录音转文字、提取高频诉求、生成竞品功能矩阵、起草需求清单
人（PM + 工程负责人） 判断优先级、决定 MVP 范围、识别关键风险

中间产品：

关键观察：

时间分配：人 60%，AI 40%；过去同样工作量约 2 周，现在 1 周。

阶段 2：领域建模与架构设计（第 2 周）

目标：建立促销引擎的核心抽象，决定关键架构方向。

核心问题：

协作模式：

人（架构师）先列出关键问题。AI 针对每个问题给出 2-3 种方案与利弊：

例：促销规则建模

  • 方案 A：每种类型独立类，硬编码逻辑（简单、不灵活）

  • 方案 B：统一的"条件 + 动作"规则模型（灵活、复杂、需要配置 DSL）

  • 方案 C：策略模式 + 责任链（中庸方案）

AI 给出每种方案的代码示意、扩展场景、维护成本估算。

人的判断：选择方案 C，理由是 MVP 阶段不需要 B 的灵活度，但要为未来留扩展点。这个判断 AI 做不了，因为它涉及对团队能力、客户增长曲线、产品路线图的综合判断。

中间产品：

关键观察：

时间分配：人 70%，AI 30%；过去约 1.5 周，现在 1 周。

阶段 3：API 与数据库设计（第 3 周前半）

协作模式：

人定义关键接口形态（如"促销规则的 CRUD API 必须支持批量更新"）。AI 基于领域模型生成：

人审核重点：

中间产品：

关键观察：

时间分配：人 40%，AI 60%。

阶段 4：核心实现（第 3 周后半 - 第 5 周）

协作模式（这是 AI 贡献最大的阶段）：

人定义关键算法的伪代码与边界条件，AI 实现。例如：

促销叠加计算的核心算法（人写规约）： 输入：购物车 + 用户可用促销列表 输出：最优促销组合 + 优惠后价格 约束：

  • 同一互斥组内最多选一个

  • 必须满足所有触发条件

  • 在合法组合中选总优惠最大者

  • 计算时间不超过 50ms（购物车最多 100 商品） 边界情况：

  • 商品在多个促销中：按 X 规则归属

  • 优惠后价格 < 0：归零

  • 促销在计算过程中过期：按计算开始时刻为准

AI 实现这个算法的代码与单元测试。人审核的重点：

典型的"AI 主导"工作：

典型的"人主导"工作：

中间产品：

关键观察：

时间分配：人 30%，AI 70%；过去约 4 周，现在 2.5 周。

阶段 5：测试与质量保障（第 6 周）

协作模式：

测试工程师定义关键测试场景与验收标准。AI 大量铺开测试用例：

人主导：

中间产品：

关键观察：

时间分配：人 50%，AI 50%。

阶段 6：代码评审（持续，集中在第 5-6 周）

协作模式：

每个 PR 先经过 AI 预审：

人评审聚焦在 AI 难以判断的层面：

中间产品：

关键观察：

阶段 7：上线与监控（第 7-8 周）

人主导：

AI 辅助：

中间产品：

案例总结

整体时间对比：

阶段 传统流程 AI 协作流程 节省
需求探索 2 周 1 周 50%
设计 1.5 周 1 周 33%
API/DB 设计 1 周 0.5 周 50%
实现 4 周 2.5 周 38%
测试 1.5 周 1 周 33%
上线 1 周 1 周 0%
合计 11 周 7 周 ~36%

关键洞察：

  1. AI 节省的不是"思考"，而是"动手"。设计、决策、判断的时间几乎没缩短，但实现、文档、测试的时间大幅缩短。

  2. 节省的时间一部分回流到"质量"。例如测试覆盖率从 60% 提升到 85%，文档完整度大幅提升。

  3. 新增的工作不可忽视：维护 CLAUDE.md、设计 prompt、审核 AI 输出、维护上下文包，大约占总工时的 8-10%。

  4. 风险集中在"AI 看起来对，实际微妙错误"。金钱计算、并发、时区、安全四个领域必须人深度参与。

  5. 团队结构没变，但每个角色的工作内容变了：

    • PM 更多时间花在判断和取舍，少花在文档撰写

    • 工程师更多时间花在设计和评审，少花在编码

    • 测试更多时间花在场景设计和异常工程，少花在用例编写

七、给个人和组织的建议

给工程师

给团队负责人

给组织

八、开放问题

这些问题没有标准答案，但每个团队都应该自己思考：

  1. 品位与判断力如何在 AI 时代培养？ 当初级工程师不再写大量小代码，他们的"代码直觉"从哪里来？
  2. AI 写的代码出 bug，谁负责？ 法律、组织、个人三个层面都需要明确。
  3. 代码所有权与知识产权如何界定？ AI 生成的代码受版权保护吗？商业秘密如何界定？
  4. 团队规模会不会变小？ 如果 1 个人 + AI 能完成过去 3 个人的工作，组织如何重构？
  5. 当所有人都用同样的 AI 时，差异化竞争力来自哪里？ 答案可能是：领域知识、上下文工程能力、组织独特的判断与品位。
  6. 现在投入大量时间维护的 AI 工作流，半年后还适用吗？ 模型能力变化快，要建立"流程的弹性"。

结语

AI 不是工程师的替代者，而是工程师的放大器。它放大优秀工程师的产出，也放大平庸工程师的平庸——后者更危险，因为 AI 让"看起来在干活"变得太容易了。

真正的竞争力不在于"会不会用 AI"，而在于：

这些能力的本质，依然是工程的本质：理解问题、做出取舍、承担责任。AI 改变的是工具与流程，不是工程的内核。

Revision #3
Created 2026-04-26 06:50:34 UTC by Colin
Updated 2026-05-04 03:53:30 UTC by Colin