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