冰山下的庞然大物

老练的水手在看到一座冰山的时候，哪怕它再小，也会立刻意识到冰山底下有着一个庞然大物。
但不是所有人都能够看得到冰山底下的庞然大物，对于绝大部分人来说，人们的直觉往往只是看到冰山浮在水面上的一角。

从产品的角度来看，产品的质量、非功能需求 [^understandfr]、性能、安全隐患等方面的考虑是冰山下真正的庞然大物。
但是这一部分往往属于良心部分，因为它在表面上看不见。

然而仅仅是良心部分并不足以说明情况的严重性，当危险发生的时候，大家才能够知道哪些东西是真正可靠的。只是此时对于用户和产品服务方来说都已经为时太晚。

软件行业的冰山

对于软件行业来说，技术债是冰山下的庞然大物。人们总只是看见产品表面的界面、功能以及特性，这些都是冰山上的一角。真正隐藏在产品背后的技术层面的代码结构、架构漏洞、安全性 [^aivsprogrammer]能以及设计上的耦合、接口、数据模型混乱等等，这些都是影响到产品真正能够存活多长时间的技术债。

技术债不是一天出现的问题，在很多年前人们就开始讨论技术债。IBM研究院的最新研究报告《技术债的清算时刻》显示，在需求阶段产生的技术债，最终在生产阶段要花上百到上千倍的成本来进行修复。

债务的层次

技术债并不仅仅只体现在技术这一层面上，事实上在设计层面以及需求层面的债务有时候会更加严重，因为它的影响程度要更深一些，比如说有一些虚假的假设、临时性的权衡、理解的偏差以及随意的变更等等。

但是技术债在过往的软件开发过程中普遍被认为是一个可以权衡的因素，并且是作为一个重点考虑的权衡点。

原因是作为新产品上市来说，上市的速度和前期的推广可能是至关重要的，这个时候产品的稳定性、性能和功能约束等等重要性不是那么高，并且有足够的时间来修正和改进，一旦得到了用户的认可的话。

精心挑选的负债

因此对于传统的产品开发来说，适当范围的技术负债是一个优选的考虑。在保证最小可用产品的上市速度上，有选择性的进行负债有时候是一个最佳的选择。

当然这是经过精心挑选的负债，而不是因为毫无意识而导致的负债。毫无意识的负债会形成沉重的包袱，并在表面光鲜一切顺利的假象下突然爆发，瞬间摧毁信任，导致所有努力都付诸东流。

正因为如此，技术债在以往过程中只是在一些比较高层的、思想比较领先的软件工程中被定量性的讨论，而不是一个普遍的大家关心的因素。

AI编码的双刃剑

但是AI编码产生以后，这一切都变了。AI的强大的编码能力和同样快的腐烂速度，对于技术债来说，形成了一个急剧的放大效应。

IBM Systems Sciences Institute等研究机构的经典研究揭示了缺陷修复成本的指数级增长曲线：

模糊的需求可在数分钟内被放大为数千行问题代码。对于完全理解正确的需求，AI编码放大了开发能力；但对于定义不清的需求，AI编码则迅速放大了技术债务。在我们借助AI编码能力的同时，必须清醒地认识到：AI既放大了能力，也放大了错误。

这就使得AI编码时代技术债务变得前所未有的严峻。

规范驱动的救赎

在诸多尝试解决AI编码的开发模式的过程中，规范驱动的开发是目前看来唯一走向正确路径的方式，因为它使得AI编码可以进行重复的迭代。重复的迭代就意味着产品可以进行持续的改进，这是一个基本的分水岭。简单的氛围开发，正因为无法进行持续的迭代，迅速的腐烂，所以导致它无法成为一个做产品的有效的持续的开发。

当我们总结这些开发模式的成因的时候，实际上我们是在解决一个最基本的事实，就是不论AI的能力如何强大，它无法解决一个定义不清的问题。这就是我强调的需求分析的重要之处。

需求分析的复兴

在传统的软件开发过程中，需求分析作为前期的一个很小的阶段，很容易被产品设计给覆盖掉，因此它引起的重视是很少的。但是在AI编码时代，由于开发以及产品的设计，很大一部分都可以借助AI来实现，因此需求分析的重要性变得越来越清晰和明确，在需求上的一点点疏忽都可能在后续的产品设计阶段以及开发阶段，放大成无数倍的后果。

因此需求分析这一在之前被忽视或很少人注意到的阶段、方法、理论现在在AI编码时代变得至关重要起来，每一个细微的差异都会在后续的产品设计和开发阶段无限的放大，从而影响最终的产品质量。

人机协作的新模式

借助需求分析的思想、理论、方法和工具，我们可以在规格驱动的开发过程中更好的与AI去交互，不仅用我们人类能够理解的和通用的语言和表达方式，同时也能够让AI能够理解的规范性的结构化的表达，从而形成人和机器之间的一个非常高效的沟通的方法和工具。

最重要的是我们会形成一个持续的校验和优化的过程，这个过程中不仅仅是在迭代代码，同时也是在迭代产品的定义、需求的规格约束。在我们完成一个产品开发的同时，我们不只是得到了一个可执行的产品，我们还得到了一个可编译的源码，最重要的是我们得到了一份完善的产品定义。

角色的根本转变

在AI编码时代，需求分析师、产品经理和技术管理者的角色 [^jueseyuquanxianjuzhen]正在发生根本性的转变。我们不再是文档的编写者，而是AI的协作者和训练师；不再是需求的传递者，而是业务与技术之间的智慧桥梁。

这种转变意味着需求分析从一个被忽视的前期阶段，升级为整个开发过程的战略 [^strategy]核心。它不再是成本中心，而是决定AI投资成败的关键步骤；不是产品的负担，而是质量与效率的重要保障。

定海神针

技术在不断进步，工具也在不断演进，但软件工程的本质从未改变：我们的使命始终是用技术解决真实问题，创造真正价值。

工具可以帮助我们更快地到达目的地，但只有需求分析能告诉我们正确的方向。否则的话，如果你不知道要去哪里，那么任何道路都不会带你到达目的地。

在AI编码这场狂欢中，需求分析就是那个能够告诉我们"要去哪里"的指南针。

AI时代已经到来，技术债务的挑战就摆在我们面前。但只要掌握了需求分析这根定海神针，一切问题都不在是问题。

::: {#author name=reddish}
本文同步发表在 软件需求探索的https://srs.pub/thinking/ai-coding-who-defines-problems.html

作者: reddish@srs.pub
:::

[^understandfr]: 理解功能需求. https://srs.pub/theory/understand-fr.html
[^aivsprogrammer]: 程序员如何避免被AI替代. https://srs.pub/thinking/ai-vs-programmer.html
[^jueseyuquanxianjuzhen]: 商业分析中的五十种分析方法和技巧之39-角色与权限矩阵. https://srs.pub/babok/juese-yu-quanxian-juzhen.html
[^strategy]: 战略分析. https://srs.pub/babok/strategy.html