人在基于AI交付的流程中是不可代替的
探讨人在基于 AI 的软件工程中的阻碍程度及建议
现状
2022 年 11 月 30 日,ChatGPT 以研究预览版的形式向公众开放。此后,AI 在代码补全、重构、测试和交付自动化方面快速发展。Prompt、Agent、Harness、Loop 和 Graph 等方法,也在不断扩大 AI 可以处理的任务范围。
软件开发的速度因此得到明显提升。Vibe Coding 等方式可以让人用很少的代码完成一个小功能,甚至完成一个简单应用。但是,在面向大量用户的软件交付中,人的作用仍然重要。
AI 可以替代大量执行工作,但暂时不能替代人来定义目标、接受风险、授予权限和承担结果。人在 AI 时代可能成为软件交付的瓶颈,但这不表示人必须亲自执行每一步操作。
软件交付流程中的 AI 参与度
软件交付流程大致包括需求挖掘与设计、编码实现、测试、部署、监控与维护。不同业务对 AI 的依赖程度不同。
需求挖掘与设计
在需求阶段,AI 可以帮助团队收集信息、分析竞品、整理会议内容和生成用户故事。
- 在
B2C或B2B业务中,AI 可以访问公开的竞争产品,分析功能和用户流程,并生成改进建议。团队仍然需要检查数据来源、版权、隐私和服务条款。 - 对于没有现成产品参考的业务,AI 只能根据已有数据和团队提供的上下文进行推断。它可以提出假设,但不能把假设当成经过验证的需求。
- 对于临时的小需求,用户可以直接使用
Prompt让 AI 生成实现方案。此时人的工作可以很少,但仍然需要定义验收标准。
例如,AI 分析一个竞品后,建议增加“自动续费”功能。这个建议从产品角度看很合理,但它可能忽略不同地区的自动续费规则。产品负责人必须确认用户价值、合规要求和业务成本,然后决定是否立项。
因此,AI 可以生成需求产物,但领域人员必须确认需求真实、可行并且符合约束。
编码实现
结合 Harness Engineering[1] 和相关 Skill,AI 已经可以处理很多编码任务。一个需求经过规划后,可以进入标准化的 Loop Engineering[2] 流程,并由 AI 辅助完成端到端交付。
流程
-
准备代码仓库
- 切换到主分支并拉取最新代码。
- 检查工作区状态,确认没有未处理的改动。
- 以最新主分支作为本次任务的基线。
-
创建特性分支
- 用不超过 30 个英文字符的短语概括本次变更。
- 使用连字符连接单词,并将短语用于特性分支名。
- 基于最新主分支创建特性分支,例如
fix-validation或add-user-search。
-
实现功能并提交
- 在特性分支上完成编码实现。
- 遵循项目规范,并优先复用仓库中的模式、工具和测试方式。
- 补充单元测试、集成测试和必要的验证逻辑。
- 完成功能后提交变更,并保持每次提交聚焦。
-
重构
- 使用重构工具改善代码结构。
- 只进行不改变行为的改进,例如减少重复逻辑、改善命名和拆分过长函数。
- 重构后重新运行测试,并修复由重构引入的问题。
-
审查
- 使用独立审查流程检查当前分支相对主分支的变更。
- 重点检查功能正确性、测试覆盖、可维护性和回归风险。
- 汇总审查结果,并返回实现流程处理问题。
-
修复审查问题
- 修复审查发现的问题。
- 重新运行测试、重构和审查流程,直到没有明确的高优先级问题。
-
完成交付
- 确认工作区干净。
- 推送特性分支并创建 Pull Request。
- 在 Pull Request 中说明变更内容、影响范围和验证结果。
这个流程中的编码、测试和审查工作可以高度自动化。但是,AI 仍然需要人提供目标、约束和验收标准。
例如,AI 可以根据 Jira 任务生成支付接口、测试和 Pull Request。它仍然可能遗漏退款规则、幂等要求、权限边界或旧客户端兼容性。代码通过测试,不代表业务行为正确。人需要确认这些规则,并决定是否接受这次变更。
测试
测试不仅检查代码是否运行,也检查系统是否满足真实业务的预期。单元测试和集成测试可以由 AI 辅助生成,但上线前仍需要在接近真实的环境中验证。
测试经常依赖 VPN、SSO、上游服务、下游服务、流水线和日志平台。这些依赖会限制 AI 的自动化范围。
例如,一个微服务系统需要通过 VPN 访问。测试人员先登录 SSO,再在流水线上部署上游服务、被测服务和下游服务。服务启动后,AI 可以发送请求、检查响应,并通过日志平台分析调用链路。如果这些平台提供 MCP 或 CLI,大部分检查都可以自动化。
但是,AI 仍然需要知道什么结果才符合业务要求。它可能看到接口返回 200,就认为测试成功,却没有发现订单没有进入清算系统。
对于前端变更,可以使用 Playwright MCP[3] 或 chrome-devtools-mcp[4] 自动执行浏览器操作。
例如,AI 可以确认点击“提交”后页面显示成功,但它可能没有发现用户连续点击两次后创建了两笔订单。人工需要确认关键业务流程、异常流程和数据结果。
AI 可以加速测试,但不能单独承担测试结论。测试结论必须由有业务责任的人接受。
部署
AI 可以生成和审查 IaC[5],也可以查看流水线状态。低风险变更可以自动部署,高风险变更必须具备明确的授权和责任记录。
例如,AI 发现数据库性能下降,并修改 Terraform[6] 来增大数据库实例。这个修改可能改善性能,也可能超出成本预算,或者破坏现有的多可用区配置。人需要审查变更影响,并决定是否授权。
AI 也可能通过修改白名单解决访问问题,但同时开放不应公开的管理端口。生产环境的部署必须限制 AI 的权限,并保留审计记录。
安全的部署流程通常包括:
- 最小权限和明确的操作范围;
- 自动化检查和策略审查;
- 灰度发布和健康检查;
- 失败后的自动回滚;
- 高风险变更的人类审批;
- 随时可用的人工接管方式。
因此,人不必亲自点击每一个部署按钮,但高风险变更必须有可追责的人类授权。部署策略、权限边界和组织责任,才是这一阶段的主要约束。
监控与维护
监控可以分为静态监控和动态监控。
静态监控根据预先定义的条件检查系统。例如,CloudWatch[7] 可以在最近 5 分钟内新增错误日志超过阈值时触发告警。
动态监控使用规则引擎或 AI 分析告警和系统行为。常见场景包括:
事件和告警分诊:AI 分析告警和日志,判断优先级并合并重复事件。根因分析辅助:AI 关联日志、指标、Trace 和变更记录,提供排查建议。告警降噪:AI 识别低价值告警,减少重复通知。运行手册建议:AI 根据 Runbook 提供修复步骤,并执行低风险动作。行为漂移监控:团队使用 online monitoring、agent tracing 和 golden datasets 观察 AI 系统的生产行为。变更影响分析:AI 根据代码和配置变更推断可能受影响的服务。
例如,AI 认为某个错误告警长期没有造成明显影响,于是建议提高告警阈值。但这些错误实际代表消息持续进入死信队列。阈值调整后,系统可能数天都不会告警。
因此,AI 不能自由修改关键告警。阈值必须有上下限,变更必须可审计,并且必须支持回滚和人工接管。
评估模型
基于简化的软件交付生命周期与 AI 在各个阶段的使用程度,可以建立一个 AI 参与程度的示意模型。这个模型只描述 AI 在各阶段的参与和自治程度,不代表生产环境必须采用相同的自治策略。
| 阶段 | Level 1(人工执行) | Level 2(AI 辅助) | Level 3(AI 协作) | Level 4(AI 主导,人类审批) | Level 5(受控自治) | Level 6(完全自治) |
|---|---|---|---|---|---|---|
| 需求与设计 | 人工访谈、分析并编写需求。 | AI 整理会议、搜索资料并格式化需求。 | AI 起草用户故事、流程图和验收标准,人进行确认。 | AI 根据批准的业务上下文生成依赖、任务和策略,人进行签发。 | AI 根据遥测和用户反馈发现需求并提出方案,人决定是否立项。 | AI 自主发现问题、确定需求、制定方案并推动需求进入交付流程。 |
| 编码实现 | 人工编写、测试并审查代码。 | AI 提供代码补全、样板代码和局部测试。 | AI 完成多文件修改、重构和 Pull Request 草稿,人进行审查。 | AI 根据任务完成代码、测试、文档和策略检查,人批准合并。 | AI 主动发现低风险技术债并发起修复,人保留合并和例外处理权。 | AI 自主识别问题、修改代码、完成测试、合并变更并发布。 |
| 测试 | 人工设计和执行单元、集成及 E2E 测试。 | AI 根据提示生成局部测试和测试数据。 | AI 根据设计和验收标准生成并执行完整测试套件。 | AI 连接测试环境、浏览器、接口和日志系统,自动验证技术结果,人确认关键业务结果。 | AI 持续生成异常场景、执行混沌测试并处理低风险问题,人接管高影响问题。 | AI 自主生成测试、构造异常场景、判断结果并修复问题。 |
| 部署 | 人工维护配置并执行部署。 | AI 生成脚本、配置和故障排查建议。 | AI 分析变更影响并建议部署策略,人执行或批准部署。 | AI 在策略约束下自动完成测试环境和灰度部署,生产部署需要人工审批。 | AI 在明确边界内执行渐进式发布、健康检查和自动回滚,人保留紧急接管权。 | AI 自主选择部署策略、调整基础设施、扩缩容并执行回滚。 |
| 监控与维护 | 人工维护静态阈值和监控面板。 | AI 将自然语言转换为查询,并生成告警摘要。 | AI 关联告警、日志、指标和变更记录,起草 RCA。 | AI 定位可能的故障提交,并执行经过授权的低风险修复,人批准高风险操作。 | AI 在阈值、权限和回滚边界内进行预测性扩容和自动修复,人负责异常接管。 | AI 自主发现异常、定位根因、修复系统并验证修复结果。 |
使用这个模型时,需要注意三点:
- 各阶段分别评估:同一个团队可以在编码阶段达到较高等级,但在生产部署和支付故障处理阶段仍然保持较低等级。
- 能力不等于权限:更高等级表示 AI 具备更强的分析、生成或执行能力,不表示 AI 自动获得生产操作权限。
- 自治不等于推荐策略:实际授权需要根据业务影响、数据敏感性、变更范围、回滚能力和审计要求决定。
例如,一个支付系统可以在编码阶段达到 Level 4。AI 可以根据 Jira 任务生成代码、测试和 Pull Request。但是,生产部署仍然需要人工审批,数据迁移和故障回滚仍然需要人工接管。因此,AI 能力等级较高,不代表整个交付流程已经完全自治。
这个例子说明,AI 的能力、AI 的权限和人的责任是三个不同概念。人的介入点应当由风险决定,而不是由流程步骤机械决定。
Level 6 表示 AI 在技术上具备端到端自治能力。它是评估模型的理论上限,不表示组织应当取消人类治理。对于支付、医疗、金融和安全等高风险系统,完全自治仍然需要受到法律、组织政策和系统边界的约束。
问题
在简化的软件交付生命周期中,AI 可以参与需求、编码、测试、部署和监控。但是,如果没有适当的人类介入,系统会产生以下风险:
- 需求错误:AI 生成的需求可能违背业务规则、合规要求或现实条件。
- 测试误判:AI 通过技术检查,但没有确认真实业务结果。
- 部署风险:AI 修改基础设施、访问策略或白名单时,可能造成服务中断或信息泄漏。
- 监控失效:AI 调整告警条件后,可能掩盖真实故障。
- 责任不清:发生线上事故后,组织仍然需要明确谁批准了变更,谁接受了风险。
这些问题不表示 AI 没有价值。它们说明 AI 的执行权限必须与风险等级匹配。
方案
问题不能完全消除,但可以通过流程和工具降低风险。核心原则是:人负责目标、边界、授权和责任,AI 负责分析、生成、执行和反馈。
- 需求挖掘与设计:AI 生成需求、流程和依赖关系。产品负责人和领域专家确认用户价值、业务规则、合规要求和资源成本。只有经过授权的需求,才能进入实现阶段。
- 编码实现:AI 可以完成代码生成、测试生成、重构和 Pull Request 准备。人需要提供验收标准,并审查安全、数据、权限和兼容性风险。
- 测试:将环境准备、接口调用、浏览器操作、日志查询和链路分析尽量代码化。对于关键业务结果,保留人工验收和风险确认。
- 部署:对低风险变更使用自动化发布。对生产基础设施、权限策略、数据迁移和高影响变更,保留人工授权、审计、灰度和回滚机制。
- 监控与维护:让 AI 分析告警、提供 RCA 和执行低风险修复。对告警阈值、扩容策略、数据修复和大范围回滚设置边界,并保留人工接管。
- 事故响应:AI 可以快速整理时间线、关联日志和提出修复建议。事故负责人必须判断业务影响,决定是否回滚、降级或暂停自动化操作。
这样做的目标不是让人阻塞所有操作,而是让人在真正需要判断的地方介入。自动化流程应当减少人工等待,而不是绕过必要的授权。
总结
AI 正在改变软件交付的分工。它可以生成需求草稿、编写代码、执行测试、分析告警,甚至完成部分部署和修复。
但是,软件交付不只有技术执行。它还涉及业务目标、合规要求、风险接受、权限授权和事故责任。AI 可以提供建议和执行动作,却不能独立决定组织愿意承担什么后果。
因此,人不会消失。人的角色会从直接执行者转变为目标定义者、边界设计者、风险审批者和责任主体。优秀的软件交付流程,不是让人参与每一步,而是让 AI 在明确边界内自动工作,并让人在高风险决策点可靠地介入。
参考
- Harness Engineering: https://openai.com/index/harness-engineering/
- Loop Engineering: https://addyosmani.com/blog/loop-engineering/
- Playwright MCP: https://playwright.dev/docs/getting-started-mcp
- chrome-devtools-mcp: https://github.com/ChromeDevTools/chrome-devtools-mcp
- IaC: https://en.wikipedia.org/wiki/Infrastructure_as_code
- Terraform: https://developer.hashicorp.com/terraform
- CloudWatch: https://aws.amazon.com/cloudwatch/