意图原型设计：企业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助手确认了这一点：
不，这不是预期的行为——这是一个错误！问题是测试被存储在两个独立的地方（索引页面的本地状态和应用程序状态），所以在主页面创建的测试没有与产品想法页面同步。
当然，它最终修复了那个错误，但请注意，我们只是在第三步，当我们要求稍微扩展一个非常简单的应用程序的功能时就遇到了这个问题。我们添加的复杂性层次越多，我们注定会遇到更多这类障碍。
还要注意，这个两个实体（产品想法和测试）之间关系没有完全想清楚的具体问题并不局限于技术层面，因此，一旦技术错误被修复，它并没有消失。底层的概念模型仍然是坏的，并且它也在UI中表现出来。
例如，你仍然可以创建"孤儿"测试，这些测试没有连接到"产品想法"页面中的任何项目。结果，你可能会在应用程序的不同页面上看到不同数量的想法和测试：
让我们诊断这里真正发生了什么。AI回应说这是一个"错误"只说对了一半。真正根本原因是概念模型失败。我的提示从未明确定义产品想法和测试之间的关系。AI被迫猜测，这导致了糟糕的体验。对于一个简单的演示，这可能是一个可修复的烦恼。但对于数据密集型企业应用程序，这种结构性的模糊性是致命的。它展示了在没有蓝图的情况下构建的根本弱点，而这正是氛围编码所鼓励的。
不要把这看作是对氛围编码工具的批评。它们正在创造真正的魔力。然而，“垃圾进，垃圾出"的基本真理仍然有效。如果你没有足够清晰地表达你的意图，结果很可能无法满足你的期望。
另一个值得提及的问题是，即使你设法让它进入一个可工作的状态，这个工件也是一个黑盒，几乎不能作为最终产品的可靠规范。初始意义在对话中丢失，剩下的只有最终结果。这使得开发团队成为"代码考古学家”，他们必须通过逆向工程AI的代码来弄清楚设计师当时在想什么，而这些代码通常非常复杂。一开始获得的任何速度都会因为这种摩擦和不确定性而立即丧失。
从快速魔法到坚实基础
纯粹的氛围编码，尽管有其诱惑力，却鼓励在没有蓝图的情况下构建。正如我们所看到的，这导致了结构性的模糊性，这在设计复杂应用程序时是不可接受的。我们留下了一个看似快速但脆弱的过程，它创造了一个黑盒，难以迭代，更难以交接。
这让我们回到我们的主要问题：我们如何弥合设计意图和实时原型之间的差距，以便从第一天起就能迭代真实功能，同时又不会陷入模糊性陷阱？答案在于一个更有条理、更规范、因此更值得信赖的过程。
在本系列的第2部分"清晰构建实用指南"中，我将概述意图原型设计的整个工作流程。这种方法将设计师的明确意图置于流程的最前沿，同时拥抱AI辅助编码的潜力。
感谢您的阅读，期待在第2部分中与您相见。