AI 影响下的工程开发流程 AI影响下的工程开发流程 引言 AI（特别是大语言模型与代码助手）正在重塑工程开发的底层流程。这种重塑不是简单的"工具升级"，而是对 协作单位、职责边界、交付物形态 的重新定义。本报告围绕五个核心问题展开：AI 能做什么、人机之间交换什么、各方的责任、流程如何演变、AI 当前的局限。最后给出一个完整的软件工程协作案例。 报告的基本立场：AI 当前最准确的定位不是"替代工程师"，而是 头脑风暴伙伴 + 高级程序员 + 知识秘书 的复合体。它承担的是认知劳动中可被外包的那一层，把人解放出来去做真正只有人能做的事——定义意图、做高层判断、承担最终责任。 一、AI 能承担的工作 按"AI 主导 / 协作 / 人主导"三档划分，更接近实际工作分配方式： AI 可以主导的工作 这类工作的共同特征是： 有明确输入、有可验证输出、模式重复度高 。 样板代码与脚手架 ：CRUD 接口、配置文件、数据迁移脚本、测试桩、Mock 数据 代码翻译与重构 ：语言转换、框架升级（如 Vue 2 → 3）、API 风格迁移 文档生成 ：API 文档、代码注释、变更日志、README、内部 wiki 测试编写 ：单元测试、集成测试桩、property-based 测试、边界用例枚举 数据处理一次性脚本 ：数据清洗、格式转换、临时分析 错误诊断的初步分析 ：日志解读、堆栈追踪、常见错误模式识别 代码搜索与定位 ：在大型代码库中找到"做某件事的代码在哪" 协作完成的工作 这类工作 AI 出方案、人做判断，或者反过来人定方向、AI 出实现。 需求澄清 ：AI 帮助提问、识别歧义、生成用户故事；人判断哪些需求真正重要 领域建模 ：AI 罗列常见建模方式、给出对比；人决定抽象粒度与边界 API/接口设计 ：AI 生成草案与备选方案；人评估一致性、向后兼容、未来扩展 架构方案探讨 ：AI 提供模式对比（如 REST vs GraphQL、单体 vs 微服务）；人结合组织实际做选择 代码评审 ：AI 标注风险与不一致；人做架构层判断与"够好了"的拍板 调试复杂问题 ：AI 提出假设、生成验证代码；人结合系统直觉收敛 性能优化 ：AI 识别可疑模式、给出优化建议；人验证是否真的是瓶颈 不适合 AI 主导的工作 战略性产品决策 ：做什么、不做什么、为谁做 跨团队协调与组织设计 ：涉及人际、政治、长期信任 高风险的不可逆决策 ：架构选型、技术栈切换、数据模型重大变更 承担责任 ：法律责任、伦理责任、对用户的承诺 品位判断 ：什么是"好"的代码、设计、产品体验 二、双方交换的中间产品 这是 AI 协作流程中最容易被忽视、也最值得设计的部分。中间产品的形态决定了协作的效率与质量。 人 → AI 的输入 类型 说明 质量决定因素 意图描述 任务目标、成功标准、约束 越具体越好，给负面例子比正面例子更有效 上下文信息 相关代码、文档、历史决策 选择性而非全量；相关性 > 完整性 规则与偏好 编码规范、命名习惯、技术栈约束 通常以 CLAUDE.md / AGENTS.md / cursor rules 等形式持久化 示例与反例 已有实现、想模仿的风格 比抽象描述更高效 反馈 对前一轮输出的修正、追问 是收敛速度的关键 AI → 人的输出 类型 说明 验证方式 代码 函数、模块、完整应用 测试、运行、评审 方案与备选项 多个可行方向的对比 人的判断与组织决策 解释与教学 概念、为什么、注意事项 与权威来源交叉验证 文档 接口说明、设计文档、操作手册 与实际行为对照 风险提示 潜在 bug、安全问题、不确定的地方 人来决定是否接受 元产物 任务计划、TODO 列表、进度报告 用作协作上下文 一类被低估的"新工件" 这些产物在传统流程中不存在或不重要，但在 AI 协作流程中变成了 一类核心资产 ： Prompt / Spec 模板 ：可复用、可版本化的任务描述 上下文包 ：为某类任务预先准备的代码片段、文档、规则集合 AI 操作手册 ：规定 AI 在仓库中可以做什么、不能做什么、必须问谁 Eval 数据集 ：用来评估 AI 输出质量的测试集 这些新工件本身需要被维护、评审、版本化。它们和代码一样，是工程资产。 三、各方的职责与义务 人的职责 不可外包的核心职责： 定义意图与成功标准 ：清晰、可验证、有取舍 承担最终责任 ：代码出 bug、产品出问题，人负责 做高层判断 ：架构、抽象、品位、组织影响 维护语境 ：让 AI 拿到正确的上下文（这本身是一项需要训练的技能） 验证关键产出 ：尤其是涉及安全、金钱、不可逆的部分 保持判断力 ：不被 AI 看似自信的输出误导 对 AI 的义务： 给清晰的任务描述，而不是含糊的指令 给必要的上下文，而不是甩一句话 给反馈，让协作收敛 不要把 AI 当作甩锅对象——AI 出错，责任仍在人 AI 的职责 诚实 ：不知道就说不知道，不确定就标注不确定 可验证 ：输出要让人能验证，包括给出测试、解释推理过程 遵守约束 ：用户给的规则、组织的安全策略 主动提问 ：在歧义处停下来澄清，而不是猜 暴露假设 ：把隐含的判断说出来 组织/团队的职责 这是经常被忽略的一层： 建立验证机制 ：CI/CD、code review 流程、灰度发布 维护共享上下文 ：仓库级的 AI 规则文件、技术决策记录（ADR） 设计权限边界 ：哪些环境 AI 可以直接操作（dev），哪些必须人审批（prod） 培养能力 ：让团队学会上下文工程、prompt 工程、评估 AI 输出 关注成长路径 ：避免初级工程师的成长被 AI 短路（写小函数、修小 bug 是建立直觉的过程） 四、流程演变：当前与未来 阶段 0：传统流程（AI 无关） 需求 → 设计 → 编码 → 测试 → 评审 → 上线，人在每一步都是主体。 阶段 1：AI 作为补全工具（当下大多数团队） IDE 内的代码补全、对话式查询、零散使用聊天助手。AI 只在编码环节出现，且粒度很小（几行到几个函数）。 流程本身没有改变 ，只是某些环节人的输入速度提升了 20-40%。 阶段 2：AI 作为协作伙伴（领先团队的当前状态） AI 进入需求澄清、设计讨论、代码评审、文档生成等多个环节。人和 AI 之间形成"对话循环"。出现了新的工件（CLAUDE.md、prompt 模板）。 流程开始重组 ：某些步骤被压缩，某些步骤被新增（如"上下文准备"）。 特征： AI 是"高级程序员 + 头脑风暴伙伴 + 知识秘书"的复合体 一次交互的粒度从"一行代码"扩展到"一个功能模块" 人的精力开始向"定义意图"和"验证产出"两端集中 阶段 3：Agent 模式（正在发生） AI 不再是一问一答，而是接受一个任务后 自主多步执行 ：读代码、跑测试、改代码、再跑测试、提 PR。人变成"任务发起者 + 关键节点审批者 + 最终验收者"。 新的流程角色出现： 任务编排者 ：拆任务、分给不同 agent、收集结果 eval 工程师 ：设计 AI 输出的评估机制 上下文管理员 ：维护让 agent 高效工作的知识库 阶段 4：意图驱动开发（远期推测） 人主要工作变成 精确描述意图 和 判断结果是否符合意图 。中间过程（设计、编码、测试、文档）大部分由 AI 完成。这要求： 意图描述工具远比今天的 PRD/spec 强大 验证机制（形式化验证、property testing、可观测性）成为标准配套 工程师的核心能力变成"问对问题"和"识别什么是对的" 不同团队的演进速度差别会很大。判断自己处在哪个阶段，比预测未来更重要。 流程对比表 环节 传统流程 AI 协作流程 需求 人写 PRD 人定方向，AI 协助提问、整理、生成用户故事 设计 人画图、写 ADR 人定关键决策，AI 给方案对比与初稿 编码 人逐行写 AI 写大部分，人定算法核心与边界 测试 人写主要用例 AI 大量铺开，人定关键场景 评审 人对人 AI 预审 + 人做架构判断 文档 事后补写（常缺） AI 同步生成，人审定 调试 人主导 AI 提假设，人收敛 上线 人决策 人主导，AI 辅助监控查询、文档、公告 新增：上下文工程 不存在 持续维护规则文件、知识库、模板 新增：eval 与回归 不存在 评估 AI 输出质量的标准化机制 五、AI 当前的局限及应对 局限一：欠缺领域专业知识背景 表现： 对特定行业的合规、术语、潜规则不了解（医疗、金融、法律、半导体） 对组织内部的业务概念、历史包袱、客户偏好一无所知 容易给出"教科书正确但场景错误"的方案 根本原因： 训练数据以公开互联网为主，专业领域和企业内部信息覆盖少 即使有相关知识，也无法判断在当前组织语境下哪部分适用 应对策略： 把领域知识沉淀为可被 AI 读取的形式：术语表、业务规则、决策记录 在关键决策环节引入领域专家做最终判断 不让 AI 在缺乏领域上下文的情况下做"看似合理的推断" 局限二：欠缺高层次的设计与抽象能力 表现： 能写出可工作的代码，但难以判断"这个抽象是否合理" 倾向于产生"局部最优、全局割裂"的方案 难以跨越多个模块、多个文件做系统性重构 在多种合理方案之间，倾向于选择最常见的，而非最适合的 根本原因： 训练目标偏向"产生看起来合理的代码"，而非"产生最优结构" 上下文窗口有限，难以同时考虑大型系统的全部约束 没有"长期演化"的视角——不知道一年后会怎么样 应对策略： 关键的架构决策由人做，AI 只做方案对比与利弊分析 用 ADR（架构决策记录）把"为什么这样设计"沉淀下来 大型重构分阶段进行，每阶段限定在 AI 可处理的范围内 把抽象判断作为评审重点，不放过 AI 的快速产出 局限三：欠缺品位 表现： 代码"能跑"但不"优雅" 命名平庸、注释冗余、抽象层次混乱 API 设计"功能完整但不易用" 写出的文档信息密度低，重要细节被淹没 根本原因： 品位是大量经验+审美训练的产物，难以用文字规则完全表达 AI 默认追求"安全、完整、看起来负责任"，而品位要求"克制、精准、敢于省略" 应对策略： 把团队的代码风格、API 设计原则写成可被 AI 读取的指南 给具体的好/坏例子（few-shot），比抽象规则更有效 关键接口由人设计，AI 实现 把"删减"作为 AI 输出后的固定动作 局限四：不能进行高层级、大范围的知识处理 表现： 难以同时理解整个大型代码库 难以做跨多个文档、多个数据源的系统性综合 一次任务涉及的信息超过上下文窗口时，质量急剧下降 长对话中容易"遗忘"早期约束 根本原因： 上下文窗口的物理限制 注意力机制在长上下文中精度下降 没有真正的长期记忆 应对策略： 把大任务拆成 AI 能处理的粒度 维护良好的代码索引、文档结构，让"按需检索"代替"全量喂入" 关键约束放在 prompt 开头和结尾，避免被淹没 大范围综合工作（如全库审计、跨系统设计）仍需人主导 局限的本质判断 需要诚实区分两类局限： 模型本质局限 ：当前架构难以在短期内突破，必须靠流程设计绕开 上下文工程不到位 ：表面看是 AI 不行，实际是没把信息组织好 很多被归为"AI 能力不足"的问题，其实是后者。在抱怨 AI 之前，先问：我给的上下文够吗？任务描述清晰吗？验证机制建立了吗？ 六、案例：为电商 SaaS 平台添加"促销引擎" 案例背景 一个运行 3 年的电商 SaaS 平台，服务约 2000 家中小商家。当前促销功能只有"全场折扣"和"满减券"两种，商家反馈强烈要求更灵活的促销规则： 阶梯满减（满 100 减 10、满 200 减 30） 买赠（买 A 送 B） 组合优惠（A+B 套餐价） 会员等级折扣 限时秒杀 多种促销的叠加与互斥规则 团队配置：1 PM、3 后端、2 前端、1 测试，预计 8 周完成 MVP。 下面按阶段展示 AI 与人的协作模式、中间产品、时间分配。 阶段 1：需求探索（第 1 周） 目标 ：搞清楚商家真正需要什么、优先级如何、有哪些隐藏约束。 角色 工作内容 人（PM） 访谈 8 家代表性商家、调研 3 个竞品、与销售/客服对齐 AI 整理访谈录音转文字、提取高频诉求、生成竞品功能矩阵、起草需求清单 人（PM + 工程负责人） 判断优先级、决定 MVP 范围、识别关键风险 中间产品： 访谈摘要（AI 起草，人审定） 竞品功能对比表（AI 起草，人补充） 需求清单 v0.1（AI 起草，人裁剪定稿） 关键决策记录 ：MVP 包含阶梯满减、买赠、组合优惠；不包含秒杀和会员等级（人决定） 关键观察： AI 的访谈摘要容易"平均化"，丢失商家的强烈情绪和具体场景。人需要回到原录音校正。 AI 罗列的竞品功能很全，但分不清"竞品有 vs 用户真要"。这个判断必须由 PM 做。 时间分配 ：人 60%，AI 40%；过去同样工作量约 2 周，现在 1 周。 阶段 2：领域建模与架构设计（第 2 周） 目标 ：建立促销引擎的核心抽象，决定关键架构方向。 核心问题 ： 促销规则如何建模？（每种类型一个类？统一抽象？规则引擎？） 多种促销叠加与互斥如何处理？ 与现有订单、商品、用户系统如何集成？ 商家配置界面如何抽象？ 协作模式： 人（架构师）先列出关键问题。AI 针对每个问题给出 2-3 种方案与利弊： 例：促销规则建模 方案 A：每种类型独立类，硬编码逻辑（简单、不灵活） 方案 B：统一的"条件 + 动作"规则模型（灵活、复杂、需要配置 DSL） 方案 C：策略模式 + 责任链（中庸方案） AI 给出每种方案的代码示意、扩展场景、维护成本估算。 人的判断 ：选择方案 C，理由是 MVP 阶段不需要 B 的灵活度，但要为未来留扩展点。这个判断 AI 做不了，因为它涉及对团队能力、客户增长曲线、产品路线图的综合判断。 中间产品： 领域模型图（人画核心，AI 补细节） 概念词典（AI 起草，人审定关键术语） ADR-001 ：促销规则建模选用方案 C，原因与权衡（人写决策，AI 协助文档化） ADR-002 ：促销叠加规则采用"显式互斥组 + 优先级"，而非自动推导 模块划分草图（协作产出） 关键观察： AI 在提供方案对比上非常高效，但"选哪个"必须是人。 ADR 是这个阶段最重要的产出。它把判断的理由固化下来，未来 AI 在相关领域工作时可以读取，避免重复决策。 时间分配 ：人 70%，AI 30%；过去约 1.5 周，现在 1 周。 阶段 3：API 与数据库设计（第 3 周前半） 协作模式： 人定义关键接口形态（如"促销规则的 CRUD API 必须支持批量更新"）。AI 基于领域模型生成： OpenAPI spec 草稿 ER 图与建表语句 数据迁移脚本（含回滚） 与现有订单系统的集成接口 人审核重点： 命名一致性（与现有系统对齐） 向后兼容性（不能破坏老商家的数据） 索引设计是否合理 权限边界是否清晰 中间产品： promotion-api.yaml （OpenAPI 规约） migrations/2026_04_add_promotion_engine.sql docs/integration-with-order-service.md 关键观察： AI 生成的 API 草稿在 80% 情况下可用，但 命名风格容易跑偏 。需要在 CLAUDE.md 里固化命名规范。 数据库迁移脚本必须人逐行审。AI 容易漏掉"迁移过程中如何处理在途数据"。 时间分配 ：人 40%，AI 60%。 阶段 4：核心实现（第 3 周后半 - 第 5 周） 协作模式（这是 AI 贡献最大的阶段）： 人定义关键算法的伪代码与边界条件，AI 实现。例如： 促销叠加计算的核心算法 （人写规约）： 输入：购物车 + 用户可用促销列表 输出：最优促销组合 + 优惠后价格 约束： 同一互斥组内最多选一个 必须满足所有触发条件 在合法组合中选总优惠最大者 计算时间不超过 50ms（购物车最多 100 商品） 边界情况： 商品在多个促销中：按 X 规则归属 优惠后价格 < 0：归零 促销在计算过程中过期：按计算开始时刻为准 AI 实现这个算法的代码与单元测试。人审核的重点： 边界条件是否真的被覆盖 性能是否达标（用 AI 生成的 benchmark 验证） 与领域模型是否一致 典型的"AI 主导"工作： 控制器层（HTTP handler） DTO 与序列化 数据库查询 错误处理与日志 大部分单元测试 典型的"人主导"工作： 核心计算算法的设计 与外部系统的集成（订单、库存、支付） 并发与一致性处理 涉及金钱计算的精度问题 中间产品： 代码（按模块组织） 单元测试（覆盖率目标 85%+） 算法的设计文档（人写规约，AI 补例子） 性能 benchmark 报告 关键观察： AI 生成的代码"乍看正确"，但金钱计算、并发、时区这三类问题是高发区。 AI 容易产生"看起来覆盖很全"的测试，但其实都是 happy path。需要人主动补反向用例。 在长时间 AI 协作后，代码风格会逐渐偏移。需要定期回到 CLAUDE.md 校准。 时间分配 ：人 30%，AI 70%；过去约 4 周，现在 2.5 周。 阶段 5：测试与质量保障（第 6 周） 协作模式： 测试工程师定义关键测试场景与验收标准。AI 大量铺开测试用例： 单元测试（已在阶段 4 同步完成） 集成测试（覆盖促销引擎与订单、库存、支付的交互） Property-based 测试（核心算法的不变量） 场景化端到端测试（基于商家访谈中的真实场景） 人主导： 关键业务场景的测试设计（如"商家在促销活动中突然下架商品"） 异常场景设计（数据库故障、第三方支付超时、并发抢购） 性能与压力测试方案 中间产品： 测试套件（数千个用例，AI 生成 80%） 测试场景文档 缺陷清单（发现 23 个 bug，其中 8 个是 AI 实现中的边界问题） 关键观察： Property-based 测试在金钱计算这类场景中极其有效。AI 善于枚举边界，property test 帮助发现"AI 写出来但 AI 自己也没意识到的"bug。 大量测试本身需要被维护。要警惕"测试代码膨胀"导致以后改一个功能要改 50 个测试。 时间分配 ：人 50%，AI 50%。 阶段 6：代码评审（持续，集中在第 5-6 周） 协作模式： 每个 PR 先经过 AI 预审： 与编码规范的偏离 与领域模型/ADR 的不一致 潜在的安全问题（SQL 注入、未授权访问） 性能可疑模式 测试覆盖率与质量 人评审聚焦在 AI 难以判断的层面： 抽象是否合理 与系统其他部分的一致性 长期可维护性 "够好了"的判断 中间产品： PR 与评审意见 评审清单（人和 AI 分工的指南） 关键观察： AI 预审可以挡掉 60-70% 的低层次问题，让人评审者集中在真正需要判断的地方。 但 AI 评审有"宽容偏差"——倾向于不指出过于激进的问题，避免冲突。需要在 prompt 中明确鼓励它直言。 阶段 7：上线与监控（第 7-8 周） 人主导： 灰度发布策略（先 5% 商家，观察 3 天，再 20%，最后全量） 关键监控指标定义（促销计算成功率、平均耗时、异常订单数） 回滚预案 商家公告与培训材料 AI 辅助： 生成 Grafana 查询语句 生成商家面向的功能介绍文档 生成内部支持团队的 FAQ 灰度过程中的日志快速分析 中间产品： 上线 checklist 监控仪表盘 商家公告（中英文） 内部支持文档 案例总结 整体时间对比： 阶段 传统流程 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% 关键洞察： AI 节省的不是"思考"，而是"动手" 。设计、决策、判断的时间几乎没缩短，但实现、文档、测试的时间大幅缩短。 节省的时间一部分回流到"质量" 。例如测试覆盖率从 60% 提升到 85%，文档完整度大幅提升。 新增的工作不可忽视 ：维护 CLAUDE.md 、设计 prompt、审核 AI 输出、维护上下文包，大约占总工时的 8-10%。 风险集中在"AI 看起来对，实际微妙错误" 。金钱计算、并发、时区、安全四个领域必须人深度参与。 团队结构没变，但每个角色的工作内容变了 ： PM 更多时间花在判断和取舍，少花在文档撰写 工程师更多时间花在设计和评审，少花在编码 测试更多时间花在场景设计和异常工程，少花在用例编写 七、给个人和组织的建议 给工程师 加强不可被 AI 替代的能力 ：系统设计、问题拆解、调试直觉、品位、跨域沟通 学习"上下文工程" ：如何高效地把任务、约束、上下文传递给 AI 保持对代码的"读"和"判断"能力 ：未来你写的少了，但读的会多 不要把成长外包给 AI ：刻意保留一些任务自己从头做，建立第一手经验 把 AI 当协作者而非答案机 ：质疑、追问、要求解释 给团队负责人 建立团队级的 AI 协作规范 ：仓库内的 CLAUDE.md 、prompt 模板库、ADR 制度 重新设计 code review ：分工 AI 预审与人评审 投资验证基础设施 ：CI、自动化测试、可观测性、灰度发布 关注初级工程师的成长路径 ：避免他们的成长机会被 AI 完全占据 度量真正重要的指标 ：质量、稳定性、用户价值，而不是代码行数或 PR 数 给组织 明确权限边界 ：哪些环境 AI 可以自主操作，哪些必须人审批 管理风险敞口 ：法律责任、数据泄露、知识产权污染 建立 eval 文化 ：用数据评估 AI 的输出质量，而不是凭感觉 保留组织记忆 ：决策记录、设计文档、事故复盘——这些是 AI 协作的关键养料 八、开放问题 这些问题没有标准答案，但每个团队都应该自己思考： 品位与判断力如何在 AI 时代培养？ 当初级工程师不再写大量小代码，他们的"代码直觉"从哪里来？ AI 写的代码出 bug，谁负责？ 法律、组织、个人三个层面都需要明确。 代码所有权与知识产权如何界定？ AI 生成的代码受版权保护吗？商业秘密如何界定？ 团队规模会不会变小？ 如果 1 个人 + AI 能完成过去 3 个人的工作，组织如何重构？ 当所有人都用同样的 AI 时，差异化竞争力来自哪里？ 答案可能是：领域知识、上下文工程能力、组织独特的判断与品位。 现在投入大量时间维护的 AI 工作流，半年后还适用吗？ 模型能力变化快，要建立"流程的弹性"。 结语 AI 不是工程师的替代者，而是工程师的放大器。它放大优秀工程师的产出，也放大平庸工程师的平庸——后者更危险，因为 AI 让"看起来在干活"变得太容易了。 真正的竞争力不在于"会不会用 AI"，而在于： 能否清晰定义意图 能否给出高质量的上下文 能否判断输出是否真的正确 能否在 AI 高速产出的洪流中保持品位与判断 这些能力的本质，依然是工程的本质：理解问题、做出取舍、承担责任。AI 改变的是工具与流程，不是工程的内核。