意图原型设计：企业UX中纯氛围编码的魅力与陷阱（第一部分）
Yegor Gilyov研究了过度依赖静态高保真模型的问题，这些模型常常让概念模型和用户流程危险地缺乏开发。然后他探讨了AI驱动的原型设计是否是答案，质疑前进之路是流行的“氛围编码”方法，还是更结构化、意图驱动的方法。
关于代理AI浪潮将如何改变所有创意职业，存在着一系列观点，从非常怀疑到极度乐观甚至世界末日般悲观。我认为，即使你处于“怀疑”的一端，探索这项新技术如何帮助你的日常工作也是有意义的。就我的日常工作而言，我从事UX和产品设计已经大约25年了，我一直热衷于学习新技巧并与同事分享。现在，我对AI辅助原型设计很感兴趣，并在此分享我对它如何改变数字产品设计过程的思考。
首先设定你的期望：这次探索专注于产品设计生命周期的特定部分。许多人都知道双钻模型，它展示了从问题到解决方案的路径。然而，我认为三钻模型为我们的需求提出了一个重要观点。它明确将解决方案空间分为两个阶段：解决方案发现（构思和验证正确的概念）和解决方案交付（将验证过的概念工程化为最终产品）。本文完全聚焦于中间的那个钻石：解决方案发现。
AI如何帮助前一个（问题发现）和后一个（解决方案交付）阶段超出了本文的范围。问题发现较少涉及原型设计，更多是关于研究，虽然我相信AI也能彻底改变研究过程，但我会把这个问题留给该领域更专业的人。至于解决方案交付，更多是关于工程优化。毫无疑问，AI时代的软件工程正在经历巨大变化，但我不是工程师——我是设计师，所以让我专注于我的“甜蜜点”。
我的“甜蜜点”有一个特定的风味：设计企业应用程序。在这个世界里，主要的挑战是驯服复杂性：处理复杂的数据模型并引导用户通过非线性工作流程。这个背景对我的设计方法产生了很大影响，非常强调底层逻辑和结构。本文通过这个视角探讨了AI的潜力。
我将首先概述设计师在解决方案发现期间创建的典型工件。然后，我将研究这部分过程在实践中通常如何展开的问题。最后，我们将探讨AI驱动的原型设计是否能提供更好的方法，如果能，它是否与人们所说的“氛围编码”一致，或者需要一种更刻意和纪律严明的工作方式。
我们在解决方案发现期间创造什么
解决方案发现阶段始于先前研究的关键输出：一个明确的问题和一个解决方案的核心假设。这是我们的起点。我们从此处创建的所有工件都旨在将那个初始假设转化为有形的、可测试的概念。
传统上，在这个阶段，设计师可以制作不同类型的工件，逐步提高保真度：从餐巾纸草图、框线图和概念图到高保真模型，再到交互式原型，在某些情况下甚至是实时原型。低保真度的工件允许快速迭代并能够探索许多替代方案，而高保真度的工件有助于理解、解释和验证概念的所有细节。
重要的是要整体思考，考虑解决方案的不同方面。我会强调三个维度：
- 概念模型：对象、关系、属性、动作；
- 可视化：屏幕，从粗略草图到高保真模型；
- 流程：从非常高级的用户旅程到更详细的旅程。
有人可能会争辩说这些是层而不是维度，并且每一个都建立在前一个之上（例如，根据Daniel Rosenberg的语义交互设计），但我更倾向于将它们视为同一事物的不同方面，因此通过它们的设计过程不一定是线性的：你可能需要多次从一个视角切换到另一个视角。
不同类型的设计工件如何映射到这些维度：
随着解决方案发现的进行，设计师从这张图的左侧部分移动到右侧，从低保真度到高保真度，从构思到验证，从发散到收敛。
请注意，在过程开始时，不同的维度由不同类型的工件支持（框线图、草图、类图等），只有接近尾声时，你才能构建一个包含所有三个维度的实时原型：概念模型、可视化和流程。
这种进展显示了一个经典的权衡，就像铅笔素描和油画之间的区别。素描让你以最灵活的方式探索想法，而油画则有很多细节，整体看起来更逼真，但很难调整。类似地，当我们朝着以更高保真度整合所有三个维度的工件前进时，我们快速迭代和探索发散想法的能力会下降。这种反比关系长期以来一直是设计过程中一个被接受、几乎不受挑战的限制。
以模型为中心的方法的问题
面对这种困难的权衡，团队常常选择最简单的出路。一方面，他们需要展示他们正在取得进展，并创造看起来详细的东西。另一方面，他们很少能负担得起构建交互式或实时原型的成本。这导致他们过度投资于一种似乎能提供两全其美的工件类型。结果，我们之前看到的整齐组织的设计工件“便当盒”缩小到只有一个隔间：创建静态高保真模型。
这种选择是可以理解的，因为有几种力量将设计师推向这个方向。利益相关者总是渴望看到漂亮的图片，而代表用户流程和概念模型的工件受到的关注和优先级要少得多。它们过于高层，难以用于验证，而且通常不是每个人都能理解它们。
在保真度范围的另一端，交互式原型需要太多的精力来创建和维护，而用代码创建实时原型过去需要特殊技能（同样，也需要精力）。即使团队进行了这项投资，他们也是在解决方案发现的最后阶段，在收敛阶段这样做，那时尝试根本不同的想法往往为时已晚。由于已经投入了如此多的精力，很少有人愿意回到绘图板前。
因此，许多团队默认选择静态模型看似安全的选择，将它们视为草图的粗糙度和原型可能具有的压倒性复杂性和脆弱性之间的中间地带。
结果，用户验证并不能提供足够的信心证明解决方案实际上能解决问题，团队被迫凭信念开始构建。更糟糕的是，他们在没有清晰理解概念模型、用户流程和交互的情况下这样做，因为从一开始，设计师的注意力就严重偏向于可视化。
结果往往是一个设计工件，类似于著名的“画马”梗图：在每个人首先看到的部分（模型）渲染得很漂亮，但在其底层结构（概念模型和流程）中危险地缺乏开发。
虽然这是整个行业熟悉的问题，但其严重性取决于项目的性质。如果你的核心挑战是优化一个被充分理解的线性流程（如许多B2C产品），以模型为中心的方法可能完全足够。风险是可控的，“不平衡的马”问题不太可能是致命的。
然而，对于我所专攻的系统来说，情况就不同了：由复杂数据模型和非线性、相互连接的用户流程定义的复杂应用程序。在这里，最大的风险不在表面，而在底层结构，对后者缺乏关注将是灾难的根源。
转变设计过程
这种情况让我思考：
我们如何弥合设计意图和实时原型之间的差距，以便我们从第一天起就能迭代真实功能？
如果我们能够回答这个问题，我们将：
- 学得更快。通过直接从意图转到可测试的工件，我们将反馈循环从几周缩短到几天。
- 获得更多信心。用户与真实逻辑互动，这为我们提供了更多证据证明想法可行。
- 强制概念清晰。实时原型无法隐藏有缺陷或模糊的概念模型。
- 建立清晰持久的真相来源。实时原型结合明确记录的设计意图，为工程团队提供了明确的规范。
当然，对这种过程的渴望并不新鲜。这种真正由原型驱动的工作流程的愿景对于企业应用程序尤其引人注目，在那里，更快学习和强制概念清晰的好处是对抗代价高昂的结构缺陷的最佳防御。但这个理想仍然遥不可及，因为用代码进行原型设计需要太多的工作和专业技能。现在，强大的AI编码助手的兴起极大地改变了这个等式。
“氛围编码”的诱人承诺
答案似乎很明显：氛围编码！
“氛围编码是一种人工智能辅助的软件开发风格，由Andrej Karpathy在2025年初推广。它描述了一种快速、即兴、协作的创建软件方法，开发者和一个为编码调整的大型语言模型（LLM）的互动更像是一对结对程序员在对话循环中。”——维基百科
推广该术语的Andrej Karpathy原始推文：
这种方法的吸引力是不可否认的。如果你不是开发人员，当你用简单的语言描述一个解决方案，片刻之后就能与之互动时，你一定会感到敬畏。这似乎是我们目标的最终实现：从想法到实时原型的直接、无摩擦的路径。但这种方法是否足够可靠，可以围绕它构建我们的新设计过程？
陷阱：没有蓝图的过程
氛围编码将UI的描述与系统本身的描述混为一谈，导致原型基于不断变化的假设，而不是清晰、坚实的模型。
氛围编码的陷阱在于它鼓励我们以最模糊的方式表达我们的意图：通过对话。
“这就像雇一个建筑工人，一次一句话地告诉他们该做什么，却从不给他们看蓝图。他们可能做出一堵看起来很好的墙，但你不能确定它能承重。”
我将给你一个例子，说明如果你试图依靠纯氛围编码，以Andrej Karpathy推文的精神，跨越你的想法和实时原型之间的鸿沟，你可能会面临的问题。想象我想原型化一个解决方案来跟踪验证产品想法的测试。我打开我选择的氛围编码工具（我故意不透露它的名字，因为我相信它们都很棒但容易陷入类似的陷阱），并从以下提示开始：
|
|
大约一分钟后，我得到了一个可工作的原型：
受成功鼓舞，我更进一步：
|
|
结果仍然相当不错：
但后来我想扩展与产品想法相关的功能：
|
|
从这一点开始，结果变得越来越令人困惑。
创建测试的流程没有太大变化。我仍然可以创建一堆测试，它们似乎按产品想法组织。但当我点击顶部导航中的“产品想法”时，我什么也没看到：
我需要从头开始创建我的想法，它们与我之前创建的测试没有连接：
此外，当我回到“测试”时，我看到它们都不见了。显然出了什么问题，我的AI助手确认了这一点：
不，这不是预期的行为——这是一个bug！问题是测试被存储在两个独立的地方（索引页面的本地状态和应用程序状态），所以在主页面创建的测试没有与产品想法页面同步。
当然，它最终修复了那个bug，但请注意，我们只是在第三步，当我们要求稍微扩展一个非常简单的应用程序的功能时，就遇到了这个问题。我们添加的复杂性层越多，我们注定会遇到更多这类障碍。
还要注意，这两个实体（产品想法和测试）之间没有完全考虑清楚的关系的具体问题并不孤立于技术层面，因此，一旦技术bug被修复，它并没有消失。底层的概念模型仍然是坏的，并且它在UI中也表现出来。
例如，你仍然可以创建“孤儿”测试，这些测试没有连接到“产品想法”页面中的任何项目。结果，你可能在应用程序的不同页面上得到不同数量的想法和测试：
让我们诊断这里真正发生了什么。AI回应说这是一个“bug”只是故事的一半。真正的根本原因是概念模型失败。我的提示从未明确定义产品想法和测试之间的关系。AI被迫猜测，这导致了破碎的体验。对于一个简单的演示，这可能是一个可修复的烦恼。但对于数据密集型企业应用程序，这种结构性模糊是致命的。它展示了在没有蓝图的情况下构建的根本弱点，而这正是氛围编码所鼓励的。
不要把这看作是对氛围编码工具的批评。它们正在创造真正的魔法。然而，“垃圾进，垃圾出”的基本真理仍然有效。如果你没有足够清晰地表达你的意图，结果很可能不会满足你的期望。
另一个值得一提的问题是，即使你设法让它进入一个可工作的状态，这个工件也是一个黑盒，很难作为最终产品的可靠规范。初始的意义在对话中丢失了，剩下的只有最终结果。这使得开发团队成为“代码考古学家”，他们必须通过逆向工程AI的代码来弄清楚设计师在想什么，这些代码通常非常复杂。一开始获得的任何速度都因为这种摩擦和不确定性而立即丧失。
从快速魔法到坚实基础
纯氛围编码，尽管有其吸引力，但鼓励在没有蓝图的情况下构建。正如我们所看到的，这导致了结构性模糊，这在设计复杂应用程序时是不可接受的。我们留下了一个看似快速但脆弱的过程，它创造了一个黑盒，难以迭代，更难以交接。
这让我们回到我们的主要问题：我们如何弥合设计意图和实时原型之间的差距，以便我们从第一天起就能迭代真实功能，而不会陷入模糊陷阱？答案在于一个更有条理、纪律严明且因此更值得信赖的过程。
在本系列的第2部分“构建清晰度的实用指南”中，我将概述意图原型设计的整个工作流程。这种方法将设计师的明确意图置于过程的前沿，同时拥抱AI辅助编码的潜力。
感谢您的阅读，我期待在第2部分中与您相见。