# AI 团队成员时代：管理复杂与不确定性软件项目的方法论演进

AI 编码助手和自主代理正在改变软件开发。这些工具能以前所未有的速度生成代码、实现功能，处理过去需要开发者数天甚至数周才能完成的任务。但这种加速也带来了新的挑战：人类团队成员往往成为瓶颈——理解更大的架构全貌、审查代码质量、权衡设计取舍，这些都是 AI 无法独立完成的。简而言之，AI 可以大幅提升编码速度，但确保软件正确、可维护、符合用户需求，仍然严重依赖人类洞察力。要有效利用 AI，开发方法论必须演进。

## 人类瓶颈：AI 辅助开发中的新挑战

AI 编码助手能快速产出代码，但并未消除软件开发中较慢的环节——事实上，它们常常将瓶颈转移到人类监督上。团队遇到的第一个痛点是代码审查。随着 AI 生成"越来越多的代码"，开发者难以跟上审查节奏，检查这些变更的 bug、一致性和质量。这种困境因 AI 对大型复杂代码库的理解有限而加剧——当前模型往往缺乏对项目数百万行代码完整上下文的深入洞察，容易建议与系统其他部分冲突的修改。结果是人类专家必须花费大量时间指导 AI 并检查其输出，捕捉狭窄上下文的 AI 可能遗漏的问题。

虽然 AI 加速了代码编写，但无法以同样方式加速验证流程。行业观察者指出，仅仅让 Agile 开发步骤（借助 AI）跑得更快可能导致混乱而非进步。实践中，反馈和审查循环仍受人类认知速度制约。正如一位产品教练所说："AI 不会加速人类审查流程。如果你的路线图中遗漏了'中间的人'，就会制造问题。"换句话说，团队仍需时间理解需求、审查 AI 生成的输出、提供反馈——这些步骤不能安全跳过或完全自动化。将代码推向生产的速度快于人类有效审查的速度，是脆弱软件的配方。

为什么人类监督如此耗时？传统代码审查是劳动密集型的手动过程。审查者花费数小时仔细检查 pull request，发现 bug、执行编码标准、确保安全和性能最佳实践。在快节奏环境中，这可能成为瓶颈——PR 审批缓慢而截止日期迫近。即使最优秀的人类审查者也有局限：疲劳和人为错误意味着细微问题或架构不一致可能漏网。当 AI 快速生成大量变更时，风险在于未审查代码队列增长，或审查变得肤浅。最终效果可能是技术债务悄然累积或缺陷被忽视。因此，AI 开发的速度往往受限于人类审查和完善其输出的能力。

## 复杂性与架构挑战

现代软件系统极其复杂,常常超出单个人能完全理解的范围。人脑管理复杂性的能力有限——工作记忆一次只能容纳有限信息。在大型代码库中,细节很容易被遗忘或忽视；开发者经常报告,如果文档不完善,仅几周后就会忘记系统架构。在理解系统如何组合方面的一个小疏忽可能导致灾难性后果,从引入难以发现的 bug 到使软件无法维护。这种固有的认知限制意味着随着代码库增长,维护整个系统的连贯心智模型对任何个人都是严峻挑战。这不是技能或智力问题——是生物学问题。我们通过团队协作、文档和工具来缓解,但风险依然存在:复杂性可能压垮人类理解。

将 AI 引入这个混合体可能帮助也可能伤害局面。一方面,AI 可以快速编写代码实现新功能。另一方面,如果缺乏指导,AI 可能做出以隐蔽方式增加复杂性的设计决策。AI 代理对代码库健康没有长期责任——它们不会感受到维护混乱代码的痛苦。因此,它们可能产出技术上能用于即时任务但创造纠缠架构或到处重复逻辑的代码。有观察指出,当前 AI 模型"在独立做出正确设计和架构决策方面相当糟糕",即使它们产生语法正确的代码。如果让 AI 代码生成器在没有架构指导下运作,它会快速累积技术债务——编写大量通过测试但结构糟糕的代码。数万行之后,这样的代码库基本上无法维护。实际中,这可能表现为高度耦合的组件、不一致的数据模型、或重复且脆弱的逻辑,使整个系统变得脆弱。在这种失控系统中,小小的配置更改或库更新可能触发级联故障,因为底层设计不稳固。这就是为什么开发者常常害怕重构或更改 AI 编写的代码——他们感觉系统是纸牌屋,可能在没有大量细致重新工程的情况下崩溃。

关键挑战是确保凝聚的架构,即使 AI 在贡献代码。软件架构是支撑复杂系统的骨架;它定义模块如何交互、数据如何流动、基本设计原则是什么。人类通常通过经验和有意识的设计工作来发展这种架构。相比之下,AI 本质上不理解"可维护性"或"优雅设计"等概念,除非我们明确编程或提示它遵循某些模式。因此,没有人类架构师参与,AI 可能以看似最简单的方式解决每个局部问题,潜在违反架构约定或引入人类团队通常会避免的不一致。随着时间推移,这些失误成为瓶颈——代码能用,但没人真正完全理解它,任何新变更都变得危险。总之,如果我们不对 AI 的输出施加结构和设计纪律,AI 会放大复杂性。

## 分工与分层架构

管理任何大型软件项目(AI 辅助与否)的基本策略之一是分而治之。这意味着将系统分解为更小、更易管理的组件,并以清晰的层次结构分层。分层架构将复杂系统划分为具有明确定义职责的不同层次。例如,一个常见分层是:展示层 → 业务逻辑 → 数据存储。每层以有组织的方式与紧邻的上层或下层通信,各自承担特定角色。这种模块化方法在成功的软件项目中极其常见,正是因为它驯服了复杂性。通过分割功能,团队可以处理 UI 而无需担心数据库内部,或替换数据存储层而无需重写业务规则。层次创造了自然的"知识桶"——只要各部分之间有清晰的契约,没有单个人需要知道一切。

对于包含 AI 开发者的团队,分层和模块化变得至关重要。为什么？因为处理代码的 AI 代理需要约束才能有效运作。如果我们能告诉 AI,"这部分代码只处理网络,所有 HTTP 调用都使用模块 X",我们就给了它一个框架来保持在范围内。如果项目架构是没有边界的自由放任,AI 很容易调用错误的部分或重复本该在别处的功能。清晰的关注点分离引导人类和 AI 贡献者将代码放在正确的位置。

此外,分工延伸到人类方面的所有权。在人类团队中,你可能有前端负责人、后端/数据库负责人、DevOps 专家等。类似地,与 AI 协作时,人类可能监督某些领域或层,同时在指南内将范围明确的任务委托给 AI。例如,人类可以概述高层方法(API 设计、数据模型、服务间交互),然后要求 AI 在指南内实现特定函数或类。通过划分任务,如果 AI 犯错,错误是局部的,不会破坏整个代码库。

至关重要的是,团队必须建立规则和边界,使 AI 贡献不违反预期架构。一些前瞻性团队甚至为 AI 结对编程会话定义工作协议。例如,一个协议可能是:"尊重现有架构——遵循已建立的模式,除非明确要求,否则不引入根本不同的方法。"这意味着如果 AI 开始以不符合当前设计的方式编码(也许它试图添加新微服务而团队同意单体,或使用不兼容的库),人类会介入并重定向它。另一个协议可以强制 AI 一次专注于一个小变更——确保它不试图一次性彻底改造系统的多个部分,这可能破坏东西。通过编纂这些约束,我们本质上将"责任"构建到 AI 的流程中。AI 本身可能不会感到负责,但它被负责任的人类设定的指南框住了。

总之,应用可靠的架构分层和明确的责任分工是控制复杂性的基础方法。它允许 AI 代理在明确定义的护栏内工作,并允许人类更有效地监督(因为每个人可以一次专注于系统的一部分)。分层系统的有组织结构使其随时间更容易理解和维护——每个部分都有清晰的目的,就像组织中的部门。这样,即使软件范围增长,我们也能防止它变成无法管理的混乱。AI 与否,这个原则都成立,但当 AI 可能在没有全局理解的情况下生成代码时,这尤其至关重要。

## 知识管理与文档

单个人一周后无法记住系统架构的一个原因往往是文档不足。在快节奏开发中,团队有时忽视记录——当 AI 高速生成代码时,未记录知识的风险更高。然而,如果我们想让人类和 AI 朝着相同目标对齐,记录软件架构不是可选的。良好的文档实践对于扩展知识、对齐团队成员、赋能每个人(包括 AI 助手)做出正确决策至关重要。

有几种经过验证的技术来保存和共享架构知识:

### Architecture Decision Records (ADR)

ADR 是记录单个关键决策及其上下文和后果的简短文档。当团队决定"我们将为此服务使用数据库 X"或"出于这些原因我们将采用微服务架构而非单体"时,他们写一个 ADR。这创建了一个按时间顺序记录事物为何如此的日志。未来,如果新开发者(或 AI)想知道"为什么这样做?",ADR 提供答案。它防止团队失去决策背后的理由,这在复杂性增长时至关重要。ADR 还帮助避免原地打转——未来贡献者可以看到考虑和拒绝了哪些替代方案,因此不会重复辩论。简而言之,ADR 维护决策制定的连续性和透明度。

### Requests for Comments (RFC)

从互联网工程实践借鉴,RFC 流程意味着为重大变更或功能写下提案,然后向团队(甚至社区)征求反馈。这是在承诺方向之前收集多样化视角的强大工具。在复杂系统中,没有一个人看到问题的所有角度;RFC 确保想法经过多位专家审查。RFC 文档可能概述问题、提出解决方案、列出问题或顾虑。团队成员审查它、添加评论、建议修改或提出异议。这种协作讨论导致更稳健的设计,也记录了为什么选择某种方法(以及为什么没选择其他)。它本质上是以书面形式进行设计讨论,创建集体智慧的纸质轨迹。对于 AI 相关工作,RFC 甚至可用于决定如何以及在哪里使用 AI 代理(例如,"我们应该使用 AI 重构模块 Y 吗？这是计划…"),邀请审查以确保安全和合理。

### 可视化架构模型 (C4 model 等)

复杂架构受益于可视化。例如,C4 model 提供系统的多个视图——上下文、容器、组件和代码——每个都处于不同抽象层次。上下文图可能显示系统整体如何与用户和外部系统交互。容器图显示高层构建块(如服务、数据库、消息队列)。组件图放大到其中一个容器以显示内部结构。这些分层视图帮助人类和 AI 掌握系统。例如,如果你向 AI 提供基于 C4 的文档或描述,它可以理解"模块 A"不应该"直接调用数据库 B",而只能"通过服务 C"等。好处是双重的:它使新团队成员入职更快(人们可以快速获得系统的心智地图),并作为做变更时的参考,检查变更是否符合架构。

### 问题跟踪器与知识库

像 Jira(用于跟踪任务/问题)或 Confluence/Wiki(用于文档)这样的工具在复杂项目中扮演关键角色。它们通过将需求链接到设计工件到实现任务来施加结构。例如,一个 Jira ticket 可能有子任务、到 ADR 或设计文档的链接、以及测试用例引用。这种可追溯性帮助管理不确定性,因为它创建了上下文网络:如果某些东西改变(比如需求),你可以找到所有可能受影响的相关任务、设计笔记和代码部分。当 AI 是工作流的一部分时,将它与这些工具集成是明智的。例如,AI 代理可以被给予用户故事或 Jira ticket 的文本作为提示的一部分,这样它就有编写代码的上下文。类似地,当 AI 建议代码变更时,将该建议链接回问题或文档页面帮助人类验证它是正确的。底线是强大的知识管理——无论通过 ADR、RFC、图表还是跟踪工具——是人类解决复杂性问题的方式。它外化知识,所以我们不纯粹依赖记忆,并创建人类和 AI 协作者都可以参考的共享理解。

通过投资这些实践,团队降低了"只有 Bob 知道那个子系统如何工作"的风险——或者因为它由 AI 生成且从未解释而没人知道。相反,架构知识成为项目资产的一部分。这在与 AI 代理合作时尤其关键:如果 AI 基于提示构建了某些东西,我们理想情况下应该在 ADR 或设计文档等工件中捕获推理(提示和它遵循的设计)。这样,如果我们稍后重新访问该组件,我们不会对 AI 的神秘逻辑感到困惑;我们有它被要求做什么以及给了什么约束的上下文。

本质上,工具和文档充当人类记忆的扩展和团队成员与 AI 之间的通信桥梁。它们确保随着项目期间结构的出现(特别是敏捷的、自下而上的项目,其中并非所有东西都是预先已知的),沿途形成的决策和架构被记录和同意。这大大降低了复杂性失控或知识孤岛导致瓶颈的可能性。

## 维持质量:人在回路监督

无论 AI 开发者变得多么先进,人类监督对于确保软件项目的质量和正确性仍然至关重要。AI 代理不具备真正的理解或问责——如果它们引入使生产崩溃的 bug,它们不会感到难过,它们也无法直觉未明说的需求或伦理考虑。因此,团队必须保持人类"在回路中"作为最终检查和指导。实践中,这意味着调整角色和流程,使人类专注于 AI 无法(或不应该)独立完成的事情。

一个新兴范式是人类角色从编码者转变为架构师和监督者。开发者不再自己编写每一行,而是监督 AI 生成的代码,确保它符合预期设计并满足验收标准。人类设定方向("我们需要在这些约束下做 X 的功能"),然后监控 AI 的输出,在 AI 偏离轨道时介入。重要的是,在任何 AI 编写的代码合并或发布之前,人会在上下文中评估它。这类似于高级工程师审查初级开发者的工作——除了这种情况下的"初级开发者"是除非给定否则上下文为零的 AI。人类审查者不仅看代码差异,还考虑此变更是否会在其他地方产生连锁反应,是否遵循项目的风格和架构,是否真正解决问题而不引入新问题。

AI 代码审查工具可以通过提供自动化的第一遍来协助:例如,专门的代理可以分析代码变更并突出显示整个代码库中的潜在问题或不一致。这样的 AI 审查代理可能捕获简单的基于差异的检查会错过的东西,比如"这个新函数绕过了其他类似函数使用的重要安全检查"——因为它能够扫描整个仓库寻找类似模式。这对增强人类审查者的能力极其有用。

然而,最终判断仍由人类做出。软件开发生命周期的外环——代码审查、测试、事件分类、决定优先级等任务——需要人类洞察。AI 可以帮助其中每一项(我们已经看到 AI 建议测试用例或诊断构建失败),但人类应该验证结论。例如,如果 AI 建议修复失败的单元测试,人类需要确保该修复不会破坏需求或引入细微 bug。如果 AI 将一段代码标记为安全风险,人类安全专家需要确认并决定如何处理。让人类在回路中提供了针对 AI 错误或幻觉的安全网。这类似于航空中的自动驾驶:自动驾驶可以在常规条件下飞行飞机,但当情况棘手或发生意外时,人类飞行员必须准备好接管控制。

此外,人类必须在设计决策上指导 AI。如前所述,AI 通常缺乏预见实现选择长期影响的能力。例如,AI 可能选择对 100 个用户有效的快速算法,但人类架构师应该预见到对于 100,000 个用户,该方法无法扩展。除非被指示,AI 本质上不做那种前瞻性分析。一位 AI 辅助开发专家观察到,如果你让代理在没有指导的情况下编码,"它们会编写正确的代码但会非常快速地累积大量技术债务",在某个点之后你最终得到无法维护的系统。人类监督者的工作是引导 AI 朝向良好的长期决策。这可能涉及告诉 AI 不仅构建什么,还如何构造它——例如,"通过在这里添加新类来实现此功能,不要只是往现有的 1000 行函数中塞更多逻辑。"它也可能涉及偶尔说"不,停——这种方法在架构上走错了方向,让我们重新思考",类似于团队负责人如何重定向开始编写过度复杂解决方案的初级开发者。

为了管理 AI 输出的数量,团队也在监督本身中利用自动化。AI 辅助代码审查工具使用在大型代码语料库上训练的机器学习模型来自动发现常见问题并执行标准。它们可以在几秒钟内捕获样式违规、明显 bug、甚至某些安全漏洞。通过将常规检查卸载给 AI,人类审查者可以专注于更高阶的关注点,如架构、边缘情况逻辑或变更的面向用户影响。研究和行业数据显示这里有令人印象深刻的收益:使用 AI 增强代码审查的团队看到了显著更快的合并时间和代码质量改进,因为 AI 提供一致、快速的反馈。然而,强调的是 AI 是补充,不是人类判断的替代品。这些工具是第一道防线——它们确保琐碎或机械问题不浪费人类时间——但它们不是万无一失的。它们可能错过上下文或误判某些复杂逻辑。因此,关键决策和最终签署仍然是人类的责任。口号是将 AI 用于它擅长的(速度、模式识别、暴力检查),同时维护对需要理解的事物(设计意图、用户价值、风险评估)的人类监督。

实际上,保持人类在回路中意味着调整团队工作流。例如,如果 AI 开了一个带有一些代码的 pull request,团队可能要求至少一位经验丰富的开发者审查和批准它,可能借助留下初始评论的 AI 代码审查者的帮助。团队也可能做人类和 AI 实时协作的结对编程(就像 IDE 中的 GitHub Copilot 等工具,人类在驾驶而 AI 在建议代码)。在所有情况下,人类是设定目标和验证输出的人。这是我们确保问责保持在人身上的方式。毕竟,如果生产中出了问题,是人类团队必须为此负责并修复它——AI 不会承担责任(你也不能因为搞砸而解雇 AI!)。因此,从风险管理角度,人类必须在每个关键关口保持参与:计划、代码批准、测试和部署。

## 迭代开发与 Agile 适应

传统敏捷方法论被创建来应对软件项目中的不确定性和快速变化。它们青睐短周期(sprint)、来自利益相关者的持续反馈、以及适应新信息的灵活性。在 AI 可以在几秒或几分钟内生成代码的世界中,一个自然问题出现:Agile 如何变化？当 AI 理论上可能一次性构建整个功能时,我们还需要迭代吗？有趣的是,许多专家认为 Agile 没有死亡,但确实需要在 AI 时代演进。敏捷的原则——迭代改进、客户协作、对变化的响应性——仍然极其相关,但当 AI 是团队一部分时,机制可能看起来不同。

一个明显的转变是迭代速度。Agile 被设计用来对抗瀑布的长周期,通过在几周而非几月内交付可用的东西。现在 AI 可以在几天或几小时内交付,这进一步压缩了周期。这对于快速实验可能很棒:你可以让 AI 在下午生成原型,第二天早上获得用户反馈,然后迭代。但有一个问题:人类(用户、产品经理、设计师等)仍需要时间提供反馈并决定变更。如前所述,在没有适当反馈的情况下加速开发只是更快地创造垃圾。因此,一个适应是维护健康的反馈循环节奏。人类反馈周期成为限制因素——也许团队可以做 1 周或 3 天 sprint 而不是 2 周 sprint,因为代码编写更快,但你不太可能做比那更快的有意义的反馈周期,因为用户/客户需要实际使用软件并响应。本质上,sprint 长度可能缩短,但不能缩短到零。你仍需要计划、审查和回顾阶段,即使编码现在是时间线中较小的部分。

另一个有趣的发展是结合 Agile 和 Waterfall 元素的混合方法想法。一些行业声音建议 AI 对清晰指令的需求在某种程度上带回了前期计划的风味。回想一下,敏捷出现是因为需求经常变化,在新项目开始时详细计划一切是低效的。但 AI,就其目前状态而言,不擅长模糊指令。如果你只是告诉 AI,"给我做个漂亮的仪表板",它可能产生通用或不对齐的东西。然而,如果你给它非常详细的规范,它通常可以快速构建一个令人惊讶稳健的系统。这种动态导致团队考虑花更多时间前期定义他们想要什么——有效地编写更详细的设计文档或用户故事——因为 AI 然后可以以惊人的速度执行该计划。换句话说,类似 Waterfall 风格的计划(在编码前指定很多事情)可能变得值得,因为 Waterfall 的通常风险"花太长时间,等你构建时世界已经变了"被 AI 的快速执行缓解了。一位评论者将此称为"Waterfall 2.0",你投资于清晰规范,然后让 AI 构建它,它完成得如此之快以至于你可以负担得起详细计划而不失去敏捷性。

这是否意味着我们放弃 Agile？完全不是。混合模型通过将这些前期计划作为仍需验证的假设来保持 Agile 的优势。Agile 对于处理未知仍然至关重要——例如,验证功能是否实际解决客户问题,或在市场转变时转向。AI 可能减少使功能技术上正确所需的迭代次数,但不保证功能是构建正确的东西。Agile 对持续检查用户需求并调整方向的强调仍然重要。可能淡化的是编码的内部试错。在经典敏捷中,团队可能实现基本的东西,然后基于他们从技术和用户反馈中学到的在下一个 sprint 中完善它。有了 AI,技术完善部分可能更短(AI 可以根据需要快速重构或重建组件),但用户反馈部分保持。有时,尽管详细计划,你发现构建了错误的产品——Agile 方法论是你的安全网,允许你改变方向。

因此实际上,我们可能看到这样的方法论:为功能开始详细计划(比如果人类在编码会费心的更详细,因为他们可以边走边澄清)。使用 AI 主要在一次突发中实现它。然后立即将其放在利益相关者或至少产品团队面前审查。如果好,很好——你节省了几个迭代周期。如果稍微偏离,你调整规范或需求并让 AI 更新,这可能是另一个非常短的周期。本质上,你可能在感觉像 Waterfall(计划 -> 完全实现)和感觉像 Agile(小调整周期)之间振荡,取决于问题的不确定程度。对于真正新颖的、研究性的功能,你可能仍做非常小的实验(AI 在每个中协助)并频繁迭代,因为你在学习问题甚至是什么。对于充分理解的功能(如向电商网站添加已知支付方法),你可能充实需求并让 AI 一次性完成——有点更计划驱动。

值得注意的是,敏捷项目管理工具和仪式也可以纳入 AI。例如,站会可能涉及讨论 AI 前一天做了什么以及今天将被分配什么任务。Sprint 计划可能包括梳理专门"AI 可做"的任务与需要人类触摸的任务。Jira tickets 可能以兼作 AI 学习的方式编写(可以给 AI 的验收标准)。持续集成管道可能作为"测试"阶段的一部分运行 AI 代码分析工具以尽早捕获问题。所有这一切都是说,Agile 不会消失;它在适应。一个敏捷原则是"响应变化胜过遵循计划"——引入 AI 是我们如何开发的巨大变化。敏捷思维会建议我们持续适应流程以最好利用 AI,同时仍交付价值。

总之,团队应该保持迭代和以用户为中心,即使 AI 使技术实现更快。迭代周期可能在每个中涉及更多 AI 驱动的工作,并可能用更少的周期达到给定的技术结果,但审查和适应的周期继续。一个新兴最佳实践是结合两个世界的优势:做足够的前期思考来指导 AI(所以它不会漫无目的地颠簸或产生垃圾),但保留简短的反馈周期以适应现实。这种混合方法避免了 AI 闪电般快速构建实际上不是用户需要的东西的场景。相反,你利用速度并通过迭代检查点保持开发与实际需求对齐。

## 将质量控制嵌入每个周期

当开发加速时,风险是错误也发生得更快并可能在任何人注意到之前累积。为了对抗这一点,团队将质量控制步骤嵌入到每个 AI 驱动的开发周期中,通常受精益制造和持续改进技术的启发。一种获得关注的方法是在编码会话的微观层面应用 Plan-Do-Check-Act (PDCA) 循环。

以下是 PDCA 循环在 AI 编码会话(可能短至一两个小时)背景下的样子:

### Plan (计划)

在 AI 开始编码之前,人类开发者和 AI 花一些时间(比如 10 分钟)详细计划任务。这涉及分析问题、审查代码库的相关部分、制定精确方法。AI 扫描大型代码库的优势可以在这里被利用——例如,你可以提示 AI 从仓库中组装关于功能的上下文,以避免重复代码或偏离现有模式。计划应包括明确的检查点:将工作分解为步骤,决定将编写什么测试,澄清完成的定义。本质上,这一步是在任何代码变更发生之前通过获得清晰策略来减少歧义并防止"架构漂移"。人类将确保此计划与整体架构和范围对齐(尽早捕获任何误解)。

### Do (执行)

现在 AI 根据计划生成代码。这可能持续几分钟到几个小时,取决于复杂性。至关重要的是,人类在此编码阶段保持积极参与——这不是发射后不管。开发者监控 AI 的工作(许多 AI 工具允许你看到正在编写的内容或它正在思考的步骤)并提供主动监督。如果 AI 开始偏离轨道——也许它尝试过度复杂的解决方案,或偏离计划——人类立即介入纠正或引导它回来。这与我们讨论的"工作协议"一致:例如,如果 AI 突然试图一次修改两个不相关的模块,人类会阻止它(因为协议是一次一个集中的变更)。通过早期且经常地介入,人类防止浪费努力并阻止 AI 生成需要返工的大块错误或低质量代码。实际上,编码是合作之舞:AI 写,人类实时监督和纠正方向。

### Check (检查)

一旦 AI 认为它完成了(或编码会话时间到了),就是验证输出的时候了。这是一个简短步骤,也许几分钟,代码针对计划中建立的明确完成定义运行。完成定义可能包括:所有新代码都有相应的通过测试,功能行为满足验收标准,没有主要 lint 或静态分析问题等。团队可能运行自动化测试、检查代码风格、并在这里使用 AI 代码分析。重点是在继续之前快速验证完整性和质量。如果某些东西不对——测试失败或未满足需求——它被反馈到重做部分代码(另一个 Do 循环)或调整计划中。本质上,"检查"确保 AI 编码会话的输出实际解决了问题并遵守质量标准,而不是在很久以后才发现某些东西偏了。这是一个紧密的反馈循环。

### Act (行动)

最后,发生简短的回顾或调整阶段。即使在 1-2 小时周期中,也值得花 5 分钟反思:这次使用 AI 什么进展顺利？任何特定提示或策略产生了好结果吗？是否有误沟通或错误下次可以避免？人类(如果 AI 保留一些记忆或日志,可能还有 AI)记下未来协作的改进。例如,也许团队注意到 AI 反复在代码库的某个部分挣扎——这可能表明他们下次需要给它更好的上下文,或者也许那部分代码需要重构以提高清晰度。Act 阶段是关于持续改进人类-AI 交互的流程。它也可以基于学到的更新"工作协议"或提示。

这种 PDCA 方法基本上将 Agile 的迭代和反馈思想带入小时级工作流。不是只在 2 周 sprint 结束时做回顾,你在编码会话结束时做迷你回顾。通过用计划和检查结构化每个 AI 编码会话,你大大减少了 AI 失控并向团队倾倒一堆有问题代码的可能性。它也在整个过程中保持人类参与,正如我们强调的,这至关重要。值得注意的是,Agile Alliance 报告中描述了这种有纪律的循环,强调它如何通过使用近乎即时的反馈循环来管理 AI 的贡献,从而保持人类"参与、赋能和负责"。

PDCA 循环的另一个好处是解决关于人类理解与编码速度的早期观点。研究表明开发者花在理解代码上的时间多于编写代码(一项 IEEE 研究发现约 58% 的时间花在理解上)。如果 AI 泵出大量代码,团队仍必须理解它。Plan 步骤在前期强制一些理解(通过分析上下文),Check 步骤强制对输出的理解(通过运行测试和审查)。所以 PDCA 确保理解与编码保持同步。它防止 AI 写得如此之多如此之快以至于没人真正知道代码库中有什么的场景。

最后,团队应该用稳健的自动化测试和 CI/CD 来补充这些微迭代。持续集成系统可以在 AI(或任何人)提交代码时运行测试套件和静态分析器,立即捕获问题。一些团队甚至实验用 AI 生成的测试来覆盖 AI 生成的代码——本质上让一个 AI 验证另一个。但仍然,人类监督设置标准:团队决定关键测试用例是什么,性能预算是什么等,然后确保这些在每个周期中被检查。

本质上,通过将质量控制循环和明确监督嵌入每个迭代——无论多快多小——团队可以在 AI 做大量实现时维持高质量。这是恢复可能在"AI 可以一次性完成"的兴奋中丢失的纪律。不是狂野冲刺,你有一个可以重复和改进的受控、可测量流程。

## AI 时代的协作与团队结构

软件工程一直是团队运动。引入 AI 参与者不会降低这一事实——如果有什么的话,它加剧了对有效协作和清晰角色的需求。AI 代理,尽管强大,不具备软技能:它们不能举行设计辩论,不能在利益相关者之间协商冲突需求,当然也不能直觉办公室政治或客户情绪。人类仍然是必须参与创造性头脑风暴、解决冲突观点、确保技术工作与业务战略对齐的人。因此,团队的结构和文化仍然至关重要。

AI 的一个直接影响是团队成员可能需要调整他们的角色,但不是消除它们。以软件架构师或技术负责人的角色为例:以前,他们可能花大量时间自己编写关键系统代码。现在,他们可能花更多时间定义架构、为 AI 编写详细设计文档或提示、审查 AI 正在做的更大设计决策。他们变得更像教练和协调员,确保 AI 和人类贡献者都和谐工作并遵循架构愿景。类似地,考虑 QA 工程师或测试人员。他们可能从编写大量手动测试用例转向策划测试场景和基于属性的测试,确保 AI 的输出被彻底审查。他们也可能训练或配置基于 AI 的测试工具。他们的目标保持不变——保证质量——但他们使用的工具和运作的速度会改变。

另一个关键角色是类似 AI Wrangler 或 Prompt Engineer 的东西——团队中专门理解 AI 如何行为、如何从中获得最佳结果、以及当 AI 输出胡言乱语时如何排错的人。这可能是开发者或负责人角色的新方面。它涉及提示措辞的实验、维护团队做的任何自定义模型或微调、并跟上 AI 的能力和限制。从某种意义上说,这就像 AI 的系统管理:保持 AI "开发者"最优运行。

团队流程如每日站会、sprint 计划和回顾将包括 AI 考虑。例如,在站会中,除了听每个人做了什么,团队可能讨论什么任务被交给了 AI、返回了什么结果、遇到了什么问题。如果 AI 在某些东西上挣扎(比如它产生了五个版本的函数但没有一个令人满意),那是值得分享和学习的重要信息。计划会议将不仅决定做什么,还决定谁或什么应该做——这个任务最好由人类完成,还是 AI,还是两者配对？也许 AI 擅长编写样板代码,而人类应该做与怪异遗留系统的集成,因为对 AI 来说太特定于上下文。这些决策成为项目管理的一部分。

协作也意味着人类一起工作来监督 AI。例如,结对编程可能变成三人编程:一个人类驾驶,另一个人类审查,AI 建议。这可以更快地捕获问题——一个人类可以盯着 AI 建议,而另一个人提前思考设计。或者,AI 可以与初级开发者配对,通过建议代码有效地指导他们,而开发者学习指导或纠正 AI。在所有情况下,沟通是关键。如果有人发现特定提示导致 AI 误入歧途,他们应该告诉团队("注意,一次性要求它做 X 搞砸了,最好将提示分成两部分")。这种开放沟通确保整个团队——不仅是个人——学习如何与 AI 合作。这类似于团队如何分享关于新框架或调试技术的技巧。

从组织角度,AI 可能减少对某些角色的需求同时增加对其他角色的需求。如果 AI 可以处理常规编码,你可能不需要那么多纯码农程序员。但你可能需要更多产品思考者、设计师或系统工程师。这也可能意味着团队可以用相同数量的人承担更雄心勃勃的项目。想象一个小团队,有了 AI 助手,可以维护过去需要大得多团队的东西。这是可能的,但只有当他们非常有组织并有效使用 AI 时。否则,很容易淹没在没有协调地工作的多个 AI 的输出中。这就是为什么拥有强大的组织结构和清晰的责任分配仍然至关重要。项目的每个部分都应该有所有者,即使工作由 AI 完成。例如,如果 AI 产生认证模块,应该有一个负责该模块完整性的人审查它并定期检查它仍满足需求(特别是当其他 AI 或人类变更在其周围发生时)。

我们还应该考虑利益相关者协作:与用户、客户和其他部门(营销、支持等)交谈。AI 无法替代用户说"我不喜欢这个功能,它在实践中不能解决问题"或合规官说"软件需要以这种特定方式记录数据以符合法规"的对话。人类必须仍与这些利益相关者接口,然后将这些需求转化为任务(也许 AI 可以帮助实现)。在复杂、不确定的项目中,大量时间花在首先澄清需要做什么——人类沟通是唯一选择的领域。所以团队不应该放弃 Agile 倡导的对交互和协作的强调。事实上,他们可能需要最初过度沟通以确保 AI 不在过时或误解的需求上运作。

总之,即使有 AI 团队成员,人类团队也需要像运转良好的机器一样运作。他们需要设定目标、分享知识、执行标准、相互支持。AI 的存在有点像拥有一个非常强大但有些不可预测的工具——就像一个超级聪明的实习生,24/7 工作但除非你给明确指令否则没有常识。有效管理这一点是团队努力。这可能涉及新角色或新技能(提示工程、AI 监督),但它肯定涉及古老的清晰沟通、领导力和团队合作技能。能掌握这些的团队可能将 AI 变成巨大资产,而功能失调的团队实际上可能随 AI 变得更糟(想象一个沟通不良的团队——AI 可能放大误沟通,一遍又一遍做错误的事,因为人类从未同步他们想要什么)。

## 结论

将 AI "员工"引入软件开发是一把双刃剑。一方面,我们有生产力的惊人提升——AI 代理可以以人类无法匹敌的速度生成代码甚至设计建议,潜在地处理大量繁重工作并解放人类进行更多创造性任务。另一方面,这种速度和输出量本身可能使我们确保项目质量和连贯性的传统方式紧张。瓶颈转移到人类层面:我们监督、理解和指导这些 AI 贡献者的能力成为项目成功的决定因素。在处理需求可能流动且系统架构事先并非完全已知的复杂和不确定软件项目时,这一挑战更加明显。

要在这个新时代成功,我们需要在方法本身上迭代。从过去实践中借鉴最好的并适应新现实是前进的道路。以下是用 AI 在团队中管理复杂性和不确定性的关键要点和演进实践:

**架构纪律不可协商**:我们必须主动施加结构(层、模块、接口)并在这些约束内引导 AI。人类应该负责架构完整性——就像高级工程师一直做的那样——现在着眼于引导 AI 贡献。如果我们不这样做,AI 会愉快地产生逻辑正确的混乱。分层设计和分工使系统可理解,让人类逐块监督而不是被整体压倒。

**增强人类,不要替代他们**:拥抱 AI 擅长的——速度和规模——但保持人类在回路中进行监督、批判性思维和创造性问题解决。使用 AI 处理常规编码、生成样板、运行分析、甚至做初步代码审查,但总是让人类验证重要输出。在可预见的未来,AI 是强大助手,不是自主项目经理。人类演进为架构师和审查者的角色,专注于战略和长期质量。

**更强的知识管理**:虔诚地记录决策和设计。在快速移动的、AI 推动的项目中,很容易失去对为什么以某种方式构建某些东西的追踪。ADR、RFC、设计文档和图表变得更加关键以创建共享理解。它们也作为与 AI 的沟通(我们可以将相关文档输入提示以获取上下文)。本质上,将知识视为一等资产。这缓解了人类记忆限制问题并快速入职新人或 AI 系统。

**混合开发方法论**:对混合计划驱动和敏捷方法持开放态度。对于充分理解的项目部分,投资时间于清晰规范——你可能发现如果给了优秀蓝图,AI 可以一次性交付大块。对于模糊部分,按 Agile 继续短迭代和探索性尖峰。未来可能不是纯 Agile 或纯 Waterfall,而是使用更多前期清晰度(因为 AI 受益于此)同时在需要时保留改变灵活性的混合体。在所有情况下,保持与真实用户和利益相关者的反馈循环——这对于构建正确产品是不可协商的。

**嵌入式 QA 和持续改进**:不要在最后才附加测试和 QA;将其编织到每一步。随着 AI 生成代码,持续集成和测试是你的安全网。使用像 PDCA 微循环这样的技术确保每个 AI 编码会话都被计划、监控、检查和调整。这防止小错误复合并维持高质量标准。它也保持人类参与并每次学习如何更好地与 AI 合作。

**团队协作与角色演进**:训练并鼓励你的团队更多沟通。当 AI 严格遵循指令时,人类之间的不对齐可能加剧。目标、需求和审查的清晰沟通是至关重要的。预期角色转变——开发者可能自己写更少行但审查更多,设计师可能需要更正式地指定行为,测试人员可能需要处理 AI 驱动的测试生成等。投资于提升团队成员在 AI 工具和提示设计上的技能。并确保有共享责任的文化:即使 AI 写代码,团队拥有结果。不要指责机器——将 AI 输出视为好像由需要指导的团队成员产生。

最终,人类因素仍是复杂项目中的决定性要素。AI 可以承担大量工作负载,但人类提供方向、智慧和问责。通过更新我们的方法论——分层架构、记录一切、平衡前期计划与敏捷迭代、构建质量反馈循环——我们可以利用 AI 的优势同时缓解其弱点。回报是巨大的:在不牺牲(理想情况下改进)质量的情况下更快交付的软件项目。人类监督的瓶颈可以通过更好的工具和流程拓宽,但不会消失;相反,我们的目标是使该监督更有效和可持续。最终,成功的团队将是那些将 AI 视为强大协作者并仔细设计协作本身的团队。他们将不仅在软件上迭代,还在软件如何构建上迭代,确保人类创造力和判断与 AI 的能力结合,解决两者都无法独自管理的复杂性。

通过这些适应,关于"有了 AI 员工,我们如何解决复杂、不确定的软件项目?"的问题可以自信地回答:通过将人类战略指导与 AI 的战术速度配对,持续完善我们的方法。瓶颈——我们——可以变成放大 AI 能做什么的支点,产生比以往更快构建的可靠、创新软件,但没有混乱。这是一个令人兴奋的前沿,通过学习和调整,我们将成功导航它。这里概述的方法是那个旅程中的第一步,确保即使在 AI 开发时代,项目团队仍保持控制并能在复杂性和不确定性中交付高质量结果。