谷中仁谷中仁的博客

Engineering

人在基于AI交付的流程中是不可代替的

探讨人在基于 AI 的软件工程中的阻碍程度及建议

现状

2022 年 11 月 30 日,ChatGPT 以研究预览版的形式向公众开放。此后,AI 在代码补全、重构、测试和交付自动化方面快速发展。PromptAgentHarnessLoopGraph 等方法,也在不断扩大 AI 可以处理的任务范围。

软件开发的速度因此得到明显提升。Vibe Coding 等方式可以让人用很少的代码完成一个小功能,甚至完成一个简单应用。但是,在面向大量用户的软件交付中,人的作用仍然重要。

AI 可以替代大量执行工作,但暂时不能替代人来定义目标、接受风险、授予权限和承担结果。人在 AI 时代可能成为软件交付的瓶颈,但这不表示人必须亲自执行每一步操作。

软件交付流程中的 AI 参与度

软件交付流程大致包括需求挖掘与设计编码实现测试部署监控与维护。不同业务对 AI 的依赖程度不同。

需求挖掘与设计

在需求阶段,AI 可以帮助团队收集信息分析竞品整理会议内容生成用户故事

  • B2CB2B 业务中,AI 可以访问公开的竞争产品,分析功能和用户流程,并生成改进建议。团队仍然需要检查数据来源、版权、隐私和服务条款。
  • 对于没有现成产品参考的业务,AI 只能根据已有数据和团队提供的上下文进行推断。它可以提出假设,但不能把假设当成经过验证的需求。
  • 对于临时的小需求,用户可以直接使用 Prompt 让 AI 生成实现方案。此时人的工作可以很少,但仍然需要定义验收标准。

例如,AI 分析一个竞品后,建议增加“自动续费”功能。这个建议从产品角度看很合理,但它可能忽略不同地区的自动续费规则。产品负责人必须确认用户价值、合规要求和业务成本,然后决定是否立项。

因此,AI 可以生成需求产物,但领域人员必须确认需求真实、可行并且符合约束。

编码实现

结合 Harness Engineering[1] 和相关 Skill,AI 已经可以处理很多编码任务。一个需求经过规划后,可以进入标准化的 Loop Engineering[2] 流程,并由 AI 辅助完成端到端交付。

流程

  1. 准备代码仓库

    • 切换到主分支并拉取最新代码。
    • 检查工作区状态,确认没有未处理的改动。
    • 以最新主分支作为本次任务的基线。
  2. 创建特性分支

    • 用不超过 30 个英文字符的短语概括本次变更。
    • 使用连字符连接单词,并将短语用于特性分支名。
    • 基于最新主分支创建特性分支,例如 fix-validationadd-user-search
  3. 实现功能并提交

    • 在特性分支上完成编码实现。
    • 遵循项目规范,并优先复用仓库中的模式、工具和测试方式。
    • 补充单元测试、集成测试和必要的验证逻辑。
    • 完成功能后提交变更,并保持每次提交聚焦。
  4. 重构

    • 使用重构工具改善代码结构。
    • 只进行不改变行为的改进,例如减少重复逻辑、改善命名和拆分过长函数。
    • 重构后重新运行测试,并修复由重构引入的问题。
  5. 审查

    • 使用独立审查流程检查当前分支相对主分支的变更。
    • 重点检查功能正确性、测试覆盖、可维护性和回归风险。
    • 汇总审查结果,并返回实现流程处理问题。
  6. 修复审查问题

    • 修复审查发现的问题。
    • 重新运行测试、重构和审查流程,直到没有明确的高优先级问题。
  7. 完成交付

    • 确认工作区干净。
    • 推送特性分支并创建 Pull Request。
    • 在 Pull Request 中说明变更内容、影响范围和验证结果。

这个流程中的编码、测试和审查工作可以高度自动化。但是,AI 仍然需要人提供目标、约束和验收标准。

例如,AI 可以根据 Jira 任务生成支付接口、测试和 Pull Request。它仍然可能遗漏退款规则、幂等要求、权限边界或旧客户端兼容性。代码通过测试,不代表业务行为正确。人需要确认这些规则,并决定是否接受这次变更。

测试

测试不仅检查代码是否运行,也检查系统是否满足真实业务的预期。单元测试和集成测试可以由 AI 辅助生成,但上线前仍需要在接近真实的环境中验证。

测试经常依赖 VPNSSO上游服务下游服务流水线日志平台。这些依赖会限制 AI 的自动化范围。

例如,一个微服务系统需要通过 VPN 访问。测试人员先登录 SSO,再在流水线上部署上游服务、被测服务和下游服务。服务启动后,AI 可以发送请求、检查响应,并通过日志平台分析调用链路。如果这些平台提供 MCPCLI,大部分检查都可以自动化。

但是,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 在明确边界内自动工作,并让人在高风险决策点可靠地介入。

参考

full-text search

Type at least 2 characters to search.

    drag to pan · scroll to zoom