在软件开发与产品迭代的航程中，项目团队时常会遭遇一头名为“范围蔓延”（Scope Creep）的隐形巨兽。它悄无声息地出现，不断为项目增加新的触手，最终可能导致航船偏离预定目标，甚至搁浅在复杂度的暗礁上。随着人工智能（AI）辅助开发的普及，这头巨兽似乎获得了前所未有的力量，演化为一只更具迷惑性的范围蔓蔓延海妖（Scope Creep Kraken）。

正如 O’Reilly 上一篇热门文章 《遇见范围蔓延海妖》^[1] 所描绘的，AI 并没有发明范围蔓延，但它极大地削弱了过去用于抑制其滋长的天然摩擦力。过去，一项新功能的诞生需要经历严格的资源评估与人力博弈；而今，一个看似合理的想法，在 AI 工具的加持下，几十秒内就能生成一个可供演示的分支。这种即刻实现的快感，让拒绝的门槛变得空前之高，也让范围蔓延海妖得以更隐蔽、更迅速地将项目拖入深渊。

本文将深入探讨范围蔓延在当下的新表现，系统性地分析其成因与风险，并最终聚焦于如何在技术与产品架构层面，构建一套行之有效的识别、治理与落地路径，帮助团队在享受 AI 带来的巨大便利的同时，也能稳稳地掌好自己项目的舵。

什么是“范围蔓延海妖”？

范围蔓延（Scope Creep）并非一个新概念。它指的是在项目启动后，其需求和目标发生不受控制、非预期性增长的现象。这些新增的需求往往超出了最初约定的范围，导致项目延期、预算超支，甚至最终交付物的价值被稀释。传统的范围蔓延通常源于模糊的需求定义、沟通不畅或是对顺手做了的默许。

然而，AI 时代的“范围蔓延海妖”则呈现出全新的特点。原文作者 Tim O’Brien 巧妙地用海妖来比喻这种现象，因为它极具诱惑性且不易察觉。

从“能力约束”到“能力驱动”的转变

过去，范围蔓延的最大制约因素是“能力约束”。任何新想法都必须直面现实的拷问：“我们有足够的人手和时间来实现它吗？”这个过程自然形成了一道防火墙，迫使团队聚焦于最高优先级的核心功能。

AI 辅助编程工具（如 Copilot、ChatGPT 等）的出现，彻底改变了游戏规则。现在，许多需求从“需要一周开发”变成了“模型一分钟就生成了”。这种变化导致了一种危险的思维模式转换：从“能力约束下的聚焦”转向了“能力驱动下的扩张”。

团队的讨论不再是“我们应该做什么”，而是“我们还能做什么”。当一个新功能带着现成的代码演示一同出现时，拒绝它似乎变得不合情理。

“善意”的触手与隐性的代价

根据原文的观点^[1]，范围蔓延的起点并非源于无能或恶意，恰恰相反，它往往始于一次由工具驱动的、看似高效的“胜利”。比如，原本计划开发一个内部报表工具，有人突然发现 AI 能在几分钟内生成一个配套的 iOS 应用。这个最初的想法或许真的很有价值，它所带来的效率提升是实实在在的。

但这正是“海妖”的第一根触手。紧接着，“我们为什么不把全年的积压需求都扔给模型试试？”、“增加多语言支持怎么样？”、“让命令行支持自然语言输入吧？”……每一个提议单独来看似乎都唾手可及，且极具吸引力。这便是“海妖”的捕食方式：它不会一次性猛扑过来，而是一根根触手悄悄缠上项目，每一次都以“这很容易实现”为伪装。

当团队沉浸在飞速产出的成就感中时，往往忽略了那些被隐藏的“集成成本”和“维护义务”。每一个由 AI 生成的“便利”，都将成为未来需要测试、调试、记录文档并长期维护的“债务”。

二、识别“海妖”的早期信号

“范围蔓延海妖”虽然狡猾，但当它开始“登船”时，总会留下一些蛛丝马迹。技术管理者和产品负责人需要具备高度的警惕性，及时识别这些早期预警信号。以下几个迹象值得高度关注。

1. 混淆“演示”与“决策”

这是最典型也是最危险的信号。当会议中的设计讨论被一个即时生成的代码演示所取代时，团队实际上已经将“技术上的可能性”等同于“产品上的必要性”。AI 让“证明某个想法可行”的成本变得极低，但这并不意味着这个想法就应该被纳入项目范围。

一个健康的决策流程应该是：我们决定了这个功能属于当前项目，所以我们去实现它。而被“海妖”迷惑的流程则变成了：我们能够快速地生成这个功能，所以它似乎就应该属于这个项目。这两句话之间有着本质的区别。

2. “无源之水”的功能与代码

警惕那些没有对应需求单（Feature）、无人认领、甚至没人要求过的功能分支（Branch）突然出现。这通常意味着有团队成员在 AI 的协助下进行了“即兴创作”。这种行为在短期内可能看起来是“积极主动”，但长期来看，它破坏了需求的统一管理和优先级排序，为项目引入了未经评审的复杂性。

3. 口头禅：“模型只花了几十秒”

当这句话成为团队成员挂在嘴边的常用语时，需要引起警惕。它暗示着一种危险的倾向：过度关注实现的“瞬时成本”，而完全忽略了“长期持有成本”。一个功能从诞生到消亡的整个生命周期，包括了集成、测试、部署、文档、用户支持、迭代和最终的下线。AI 生成代码或许只占整个生命周期成本的极小一部分。

4. 从“锤子”到“瑞士军刀”的失控演变

项目初期，客户或业务方可能只是需要一把“锤子”来解决一个明确的问题。但随着范围的蔓延，交付物在未经充分沟通的情况下，逐渐演变成一把功能繁多但或许并不实用的“瑞士军”刀。更糟糕的是，其中一些“刀片”（功能）可能没人需要，甚至还有一两个无法正常折叠，带来了新的问题。当产品经理或项目发起人开始发出“我没要过这个，但……好像也行？”的疑问时，说明“海妖”已经牢牢控制了项目的方向。

三、范围蔓延对架构的侵蚀与长期风险

如果不能有效控制范围蔓延，其危害将从项目管理层面，逐步渗透到软件架构的肌理之中，带来一系列深远的技术风险。

1. 架构一致性与优雅性的破坏

优秀的软件架构强调高内聚、低耦合以及清晰的边界。而范围蔓延所引入的“游离功能”往往缺乏深思熟虑的设计，它们如同随意搭建的“违章建筑”，破坏了系统原有的架构一致性。例如，一个原本清晰的微服务边界，可能因为一个“顺手实现”的跨服务数据查询功能而变得模糊不清，导致服务间的依赖关系错综复杂。

2. 技术债的指数级累积

每一个由 AI 草率生成的功能，都可能是一笔未来的技术债。这些代码或许能够通过短期测试，但在可读性、可维护性、错误处理和边界条件考虑上往往存在缺陷。当这些“快餐式”代码大量涌入代码库，它们会迅速降低整体代码质量，使得后续的重构和维护工作变得异常艰难。正如另一篇相关文章 《理解力债务：AI 生成代码的隐藏成本》^[2] 所指出的，团队需要为理解这些并非由自己深思熟虑写下的代码，付出额外的“理解力成本”。

3. 可测试性与系统稳定性的下降

新增的功能需要相应的测试用例来保证其质量。范围蔓延带来的大量非核心功能，会急剧增加测试矩阵的复杂度。在紧张的交付周期下，这些“额外”功能的测试往往被忽视或简化，为系统稳定性埋下巨大隐患。一个未经充分测试的边缘功能，完全有可能在生产环境中引发核心业务流程的崩溃。

4. 团队认知负荷的急剧增加

一个设计精良的系统，其心智模型应该是简单且易于理解的。范围蔓延使得系统变得越来越臃肿，功能越来越多，逻辑越来越复杂。这不仅让新成员难以快速上手，也让现有团队成员对系统的整体把握能力下降。当没有人能完整说清“我们系统到底包含了什么”时，任何变更都将变得举步维艰，创新也无从谈起。

四、架构的“定海神针”：系统化的治理与实践路径

对抗“范围蔓延海妖”，绝非要我们因噎废食，放弃 AI 带来的强大生产力。恰恰相反，我们应该做的，是重新建立起被 AI 便利性所“冲垮”的纪律与流程。这套纪律的核心，就是构建一个稳固的架构治理框架，作为抵御范围蔓延的“定海神针”。

1. 强化“范围”的契约精神：架构决策记录（ADR）

重新将“书面范围”置于核心地位。任何对项目范围的实质性改动，都必须被视为一次正式的“架构决策”，并遵循相应的流程。引入或强化架构决策记录（Architecture Decision Record, ADR） 制度是一个极佳的实践。

• • 明确化：每一个新增功能或重要变更，都必须创建一个 ADR，清晰地阐述其要解决的问题（上下文）、经过权衡的多种方案以及最终的决策。
• • 可追溯：“它只花了模型 30 秒”不再是理由。真正的理由应该记录在 ADR 中 —— 这个功能为哪个用户故事服务？它如何支持我们的核心业务目标？
• • 共识驱动：ADR 的评审过程，就是一次建立共识的过程。它迫使团队成员（包括产品、开发、测试）从“技术可行性”回归到“业务必要性”的讨论。

2. 设立“架构守护者”与设计评审关卡

在团队中明确“架构守护者”的角色（可以由架构师或资深工程师担任）。他们的职责之一，就是捍卫架构的一致性和长期健康度，对可能引入范围蔓延的变更提出质询。

同时，建立轻量级但不可或缺的设计评审（Design Review）关卡。所有非平凡的、由 AI 辅助生成的功能模块，在合入主干之前，必须经过设计评审。评审的重点不应是代码的细枝末节，而应聚焦于：

• • 集成成本：这个新功能将如何与现有系统集成？它会引入哪些新的依赖？
• • 维护边界：谁将为这个功能的长期维护负责？相关文档是否清晰？
• • 测试策略：如何保证这个功能的质量？它对现有的测试覆盖率有何影响？

3. 拥抱“实验区”与“主干”的隔离

AI 在激发创意和快速验证想法方面拥有无与伦比的优势。我们应该鼓励这种探索，但必须将其控制在安全的“实验区”（Sandbox）内。

• • 建立功能开关（Feature Toggles）：对于那些有潜力但尚未被正式纳入范围的功能，可以使用功能开关进行隔离。这样，它们可以被部署到生产环境进行小范围验证（如 A/B 测试或灰度发布），但默认对大多数用户关闭，从而不影响主干业务的稳定性。
• • 明确“原型分支”策略：鼓励团队在独立的原型分支（Prototype Branch）上利用 AI 进行天马行空的探索。但是，从原型分支到主开发分支的合并，必须遵循严格的审查流程，等同于一个全新的、正式的需求。

4. 建立基于“总体拥有成本”的评估模型

推动团队思维模式的转变，从关注“开发效率”转向关注“总体拥有成本”（Total Cost of Ownership, TCO）。一个功能的 TCO 不仅包括初期的开发投入，更涵盖了其整个生命周期的所有成本。

在评估一个新想法时，可以引入一个简化的 TCO 评估模型，引导团队思考：

• • 支持成本：该功能上线后，预计会带来多少额外的客户支持工单？
• • 基础设施成本：它需要额外的服务器、数据库或第三方服务吗？
• • 机会成本：投入在这个功能上的时间和精力，是否会挤占更重要功能开发的资源？

通过量化这些“隐性成本”，可以更客观地判断一个“唾手可得”的功能是否真的“划算”。

结语：驾驭海妖，而非畏惧深海

“范围蔓延海妖”是 AI 时代软件开发的新常态。它源于技术带来的巨大机遇，也考验着我们驾驭复杂性的智慧。有效的回应不是对每一次创新尝试都抱持怀疑，而是将旧的纪律重新放回被 AI 冲刷掉的地方。

通过建立书面化的范围契约，设立清晰的评审关卡，隔离实验与交付，并以更宏观的成本视角评估决策，我们就能为项目装上坚固的“护栏”。这让我们既能享受 AI 在广阔“深海”中探索新航路的自由与激情，又能确保我们的“主舰”始终朝着既定的、最有价值的目标稳定航行。

那么，在你的团队中，是否也曾瞥见过“范围蔓延海妖”的触手？你们又是如何应对的呢？欢迎在评论区分享你的经验与见解。

引用链接

[1] 《遇见范围蔓延海妖》: https://www.oreilly.com/radar/meet-the-scope-creep-kraken/[2] 《理解力债务：AI 生成代码的隐藏成本》: https://www.oreilly.com/radar/comprehension-debt-the-hidden-cost-of-ai-generated-code/