构建一个AI辅助应用让我对判断力、架构以及软件工程的未来有了哪些认识。

我第一次尝试氛围编程（vibe coding）时彻底失败了。

我摇了摇头，盯着屏幕。好吧，这显然不适合我。我开始确信问题出在AI身上。

我已经上传了那个可用的Excel电子表格，其中已经包含了我希望AI复制的业务逻辑、工作流程和计算。对于“人工智能”来说，把它转化为一个应用程序能有多难？结果一团糟。我关掉了浏览器，将近一个月都没有再碰它。

后来有一天晚上，几乎是勉强地，我决定再试一次。二十分钟后，我不再感到沮丧。我感到不安。

在第二次尝试中，我只改变了一件事：我不再要求AI推断我的意图，而是解释我想要的结果。我描述了用户旅程、评估流程、注册过程、评分逻辑和预期行为。大约在第五或第六个提示词时，我意识到我已经不再像程序员那样思考，而是开始像一个具备足够技术深度来指挥机器的产品负责人那样思考。

一个小时后，我已经有了一个可投入生产的应用程序的基础：一个精致的React界面、一个SQL后端、用户注册以及可用的评估工作流。最引人注目的部分不是速度。而是我逐渐意识到，软件开发本身已经悄然改变，而直到我身处其中时才发现。

教训1：探索会通向意想不到的地方

敏捷教练，团队敏捷性评估——通常基于电子表格——只是工作的一部分。你管理评估、审查发现，并引导团队走向改进。很简单，对吧？

不。在实践中，我开始不信任这些庞大的成熟度评估。它们承诺精确，却常常带来疲惫。我最新使用的评估工具有超过120个问题。一百二十个问题。一定有更好的方法。

我发现自己想到了一个医学类比。大多数团队不需要高级MRI诊断。大多数时候，他们只需要一张X光片来找出问题所在。全面的MRI可能有其用武之地，但它很少是最好的起点。

因此，我决定解构基于电子表格的评估流程，将重量级评估转变为一个轻量级应用程序——一个团队敏捷性快速扫描（Team Agility Quick Scan），团队只需10分钟、回答12个问题即可完成。这个概念奏效了，我也有了一个不错的电子表格工具。

很快我意识到，我不想把时间花在分发电子表格或要求各组织再管理一个 Excel 文件上。我希望团队能体验评估过程，而不是继承又一份需要维护的文档。于是我想，氛围编程？

第 2 课：AI 先改变了我的角色，然后才改变了我的软件

我有一个用例。经过一番研究，我选定了 Replit 平台。

当我的第一次尝试失败时，我责怪 AI。走开了。我的失败是因为我期望 AI 像程序员一样行事。一个月后我回来时，我改变了对 AI 的态度，不再把它当作承包商，而更像是协作者。

我没有向它展示我想要什么，而是描述我试图达成的结果。我不再指定实现方式，而是开始指定意图。我解释了用户旅程、评估流程、注册过程，以及分数应如何汇总和显示。我不再以代码的方式思考，而是开始以行为的方式思考。

在对第一个提示词进行了几轮编辑和润色后，我提交了它。

三分钟后，AI 的回应不是几段代码片段，而相当于一份设计方案。它概述了应用程序，描述了打算如何构建它，然后悄然宣布第一个版本已准备好测试。

“继续吧，”AI 建议道。“创建你的第一个评估。”

我点击了 Register Account 按钮。注册流程正常。界面看起来很精致。

我点击了 Create Assessment 按钮。它正常工作了。我可以创建一个快速扫描评估，在应用程序中导航，并开始体验就在片刻之前还只存在于我想象中的功能。

问题迅速出现在眼前。易于阅读，易于回答。然后我点击了 View Results 按钮。我惊呆了。

它并不完美。但远比我预期的要好。重要的是基础已经存在。

从那一刻起，我们的互动不再像编程。它变成了协作。过了一段时间，感觉不再像编程，而更像导演。

我提出修改建议；AI 来实现它们。我优化用户体验；它生成另一个迭代版本。我指出缺失的功能；它填补空白。我提出颜色和设计图形建议；它同意其中一些，改进另一些。每一次对话交流都让产品更接近我设想的样子。

看着应用程序实时演进令人兴奋。每个提示都成为另一次设计评审。每个迭代都成为另一次产品对话。AI 加速了实现，但它依赖人类提供上下文、优先级和判断。

现在我明白为什么这么多人被 vibe coding 迷住了。它以几乎神奇的方式压缩了想法和可运行原型之间的距离。像这样的原型，一个小团队或独立开发者需要数周才能完成，之后还要做更多工作才能达到最小可行产品（MVP）。

我知道这一点，因为几年前我资助过一个软件创意，花了几个月与一个优秀的外包开发团队合作，最终看着成品消失在历史的尘埃中。我向自己承诺永远不会重复那段经历。这一次，我在几小时内、花很少的钱就得到了接近可运行的 MVP。

我不知道容易的部分已经过去了。事实证明，课程现在开始了。

第 3 课：架构变得更重要，而不是更不重要

应用程序的第一个版本很快出现，几乎毫不费力。让它准备好面向真实用户则是另一回事。

实际的编码会话非常短。一阵集中的提示、一次评审、一些改进，应用程序就会向前迈出又一个有意义的增量。这种速度是我从未经历过的。我估计我在三个日历月里花了大约 40 小时让应用程序准备好呈现给早期用户。与之前花费的时间和金钱相比，这不算什么。

但这种速度隐藏了一个重要事实。

AI 可以以惊人的效率生成功能，但它无法消除围绕生产应用程序的无数设计决策。

随着应用程序成熟，我发现 AI 可以以惊人的速度生成代码，但它无法替我做出架构决策。

作为产品经理，我希望通过简单的电子邮件通知实时了解用户活动。我让 AI 添加这个功能。哇，爱丽丝掉进了兔子洞。

很快我发现电子邮件通知需要选择并集成一个专用的投递平台。我必须订阅一项服务，然后将其与应用程序集成。我了解到了软件工程中这一我之前不知道的方面。很快，当新用户注册、完成评估或删除账户时，我就能收到电子邮件。

接下来，我不喜欢 AI 自带的原生用户身份验证流程。所以，我说，我们做点不一样的。再次，我发现独立身份验证需要引入一个单独的身份提供商。再次，又有一个第三方需要集成到应用程序中。再次，幸运的是，免费层拥有我需要的所有性能规格，并且没有引入新的成本。

关于 AI 在产品中应处于什么位置的决策，既需要雄心，也需要克制。

这些问题没有一个是通过代码生成解决的。它们是影响安全性、运营、可维护性和用户信任的架构选择。

第 4 课：瓶颈转移了

我在这个应用程序上花的时间越多，就越意识到 AI 协作并不会消除软件工程。它只是将其转移了位置。它加速了软件构建，同时将产品设计、集成策略、运营决策和长期维护暴露为真正的工作。代码来得出奇地容易。代码周围的一切却并非如此。

这成了核心教训。AI 能以惊人的效率生成代码。它无法决定系统边界应该在哪里、哪些妥协是可以接受的、用户真正需要什么，或者什么时候一个技术上正确的答案在战略上是错误的。这些仍然是人类的责任。

技术令人惊叹。它可以把一个想法到可运行产品之间的距离从几个月压缩到几天甚至几个小时。曾经需要一支专家团队才能完成的事情，现在可以从一次对话和一个精心设计的提示开始。这应该让每一位知识工作者感到兴奋。

但快速构建软件和构建正确的软件之间有一个重要区别。

开始进行 AI 协作非常容易。要产出安全、直观、可维护且真正有用的东西，仍然需要判断力。它需要做出架构权衡、理解用户、质疑假设，并识别 AI 何时自信地走错了方向。

最终，我最大的教训与软件无关。困难的部分并没有消失。它转移了。AI 让编码变得更容易，但也让判断力变得更有价值。工作的未来不是人类与 AI 竞争，而是培养能够提出更好问题、识别更好答案并领导越来越强大的机器的人。

企业领导者应当关注这一点，因为这种模式的影响范围远不止于软件。每当 AI 压缩执行环节，判断力就会成为稀缺资源。那些将更快的实现误认为更好决策的组织，只会更快地产出糟糕的结果。而那些在产品思维、架构、治理和人类洞察力上投入的组织，将放大 AI 的优势，而不是放大其弱点。

New Tech Forum 为技术领导者——包括供应商和其他外部贡献者——提供了一个场所，以前所未有的深度和广度探索和讨论新兴企业技术。内容选择是主观的，基于我们认为重要且 InfoWorld 读者最感兴趣的技术。InfoWorld 不接受营销材料用于发布，并保留编辑所有投稿内容的权利。如有任何疑问，请发送邮件至 doug_dineley@foundryco.com 。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：InfoWorld

原创地址：https://www.infoworld.com/article/4229802/ai-changed-my-role-before-it-changed-my-software.html