验证的不对称性

双轴分析框架

想象一个常见场景：你正在参加设计评审，有人提出一句——“要不我们再改一版试试？”   设计师只能礼貌地笑一笑，然后继续改。每个人都有主观判断，但谁也拿不出足够有说服力的客观依据。这样的场景每天都在无数设计团队里重复上演，也暴露了设计工作里一个非常根本的问题。

为什么有些设计决策总是显得特别主观，而另一些却几乎没有争议？为什么设计师常常在与业务方的会议里反复拉扯，而工程师却更容易通过异步协作推进工作？关键在于两个维度：创作难度（craft）和验证难度（verify）。

以登录页为例——它的创作难度不高（已有大量成熟模式可参考），验证也相对容易（用户要么能登录，要么不能）。   再看品牌视觉识别系统（Brand Identity）——它的创作难度很高（需要深度创意与系统化表达），验证难度更高（涉及大量利益相关者，最终效果还要在长期市场表现中间接体现，而市场表现本身又受到许多复杂因素影响）。

这种差异并不只是一个“理论上的分类方式”——它实际上深刻影响了设计师的工作方式、协作关系，以及团队对设计价值的判断。

设计的核心挑战，不在创作，而在验证。

也正因为如此，解决这种“验证不对称”问题，才是当下设计实践中更关键的范式转移；相比之下，AI 反而不是最核心的变量。真正的变化，是设计工程师的崛起。

设计与工程的验证不对称性

验证难，几乎总会带来摩擦，而且往往是高成本摩擦。

以软件工程为例，它从来不只是“把代码写出来”这么简单，更重要的是“证明这段代码是可靠的”。持续集成（CI）把“在我电脑上能跑”变成“在任何环境都能跑”；单元测试把“我觉得应该没问题”变成“我可以证明它没问题”。

但在设计领域，我们长期缺少一套能系统性降低验证成本的基础设施。

当工程师说某个功能已经完成，他们通常可以拿出测试结果、性能基准、部署记录作为证据。   而当设计师说某个方案已经完成，很多时候只能依赖利益相关者“点头通过”。这是一种非常脆弱的验证方式，因为它往往并不建立在真实、可交互、被实际体验过的产品形态之上。

这道可验证性的代沟会让设计团队的沟通成本急剧飙升，最终拖累产品质量和迭代效率。

• 决策滞后：没有清晰的验证标准，讨论就会反复拉扯、难以收敛
• 观点博弈：谁声音更大、资历更深，谁就更容易主导结果
• 迭代焦虑：当你无法验证“改完是不是更好”时，任何改动都会显得风险很高
• 人才错配：设计师把大量精力耗在会议里“解释和辩护”，而不是创造与打磨
• 行业门槛失衡：资深设计师可以靠品味（训练有素的直觉）做出好设计，但学生和初级设计师往往很难证明自己的判断，也因此更难建立成长闭环

勾勒设计领域的版图

把常见的设计工作放到这两个维度里，我们会看到一张更清晰的地图：

传统上，设计师的价值体现和成长路径，往往来自于解决那些在一个或两个维度上持续升级的问题。

这里有一个关键观察：绝大多数设计工作都“难验证”，而且长期受制于这种本可降低却尚未被系统解决的难度。   这也是为什么设计常常被视为“主观”，也是为什么设计师在提升交付速度、产品质量和组织影响力时，往往步履维艰。

设计工程师如何破局验证难题

设计工程师不只是“会写代码的设计师”，也不只是“对像素敏感的工程师”。他们真正的价值在于：利用软件工程能力，帮助设计建立更强的验证机制。 一旦验证改善了，设计工作自然会变得更快、更稳，也更容易达成共识。

下面是几个典型例子：

• 真实原型（High-fidelity in code）

  设计师不再只能抽象地问业务方：“这个新导航你觉得怎么样？”     设计工程师会和设计师一起把方案直接做成可交互原型，让团队真实点击、真实体验，甚至让内部员工先行试用（Dogfooding）。这样得到的反馈，质量会高很多。

• 性能预算（Performance Budgets）

  那些看起来很惊艳的动效，可能会提升体验；也可能因为在低端设备上卡顿，反而损害体验。     设计工程师可以和工程团队一起设定性能预算，让“是否值得做”从审美争论，变成可衡量、可权衡的决策。

• 技术可行性前置

  “这个能不能做？要怎么做？”这类问题在很多团队里总是出现得太晚。     设计工程师能更早识别技术边界，把限制提前暴露出来，并把它转化为设计机会，而不是等到上线前夕才被动妥协。

AI 以一种意想不到的方式重塑设计

产品设计师最常用的 AI 功能——图层重命名、智能抠图、文案改写、图像生成——几乎都集中在“创作”这个维度。它们确实降低了部分创作门槛，但并没有触及设计中最难的部分：验证。

这其实也符合 AI 的能力边界。AI 一向更擅长处理那些“验证标准清晰”的问题。它最擅长生成的，往往是那种可以明确判断“通过/不通过”的代码。过去几十年里，代码检查（Lint）、自动化测试、容器化、监控指标等工程基础设施的成熟，大幅降低了软件工作的验证成本——这也是 AI 能在软件工程领域快速渗透的重要原因。

这也解释了一个看似矛盾的现象：设计类 AI 工具的讨论热度很高，但至今没有哪一款真正像人们想象中那样“颠覆设计”，更谈不上“取代设计师”。

于是我们看到一种很有意思的变化：   很多产品设计师开始把 AI 用进日常工作，但很快发现自己的实际产出能力并没有出现质变——AI 并不会直接生成高质量的 UI/UX 决策。   与此同时，AI 大幅降低了写代码的门槛，反而让设计工程师的能力边界进一步扩大。他们可以更快地搭建验证环境、推进方案落地，从而实实在在地缩短设计到验证的链路。

AI 对设计行业最长期、最有价值的影响，不是替代设计师，而是加速了设计工程师的崛起。

有些人会问：“那 v0、Lovable、Bolt 这些工具呢？”   当然，它们很有价值，而且是很好的起点——它们能让你快速体验到设计工程的魅力。

如果你发现自己很喜欢这类工具，那很可能说明你对设计工程这条路有兴趣。   但真正的价值，不在于“会用这些工具”，而在于你是否具备一种能力：即使离开这些工具，也能在真实业务环境里解决更复杂的创作与验证问题。

所以，不要沉迷于那些来得太容易的生成式代码。

试着想象一个更真实的场景：在一个已有的前端代码库里，你和设计师一起为一个复杂的多步骤股票下单流程设计两种布局动画方案，把它们接入内部环境，让团队成员实际试用（Dogfooding），再根据反馈继续迭代。

设计工程师能做的，是无缝接入既有代码库、业务上下文和团队流程，去处理 v0 这类工具目前还无法触达的高难度验证问题。   而在创作层面，仅仅是把动画的节奏、缓动曲线、状态切换打磨到位，本身就是一项难度很高的工作——这同样远远超出 v0 的能力边界。

设计工程也重新定义了那个被反复讨论的问题：“设计师到底该不该写代码？”   这个问题本身其实有些表面化。更核心的问题其实是：

我们怎样才能让设计决策变得更可验证？

过去，这个问题的答案有时是代码，有时是更好的研究方法，有时是更合理的数据指标。   而到了 2025 年，越来越多团队正在形成一个共识：代码正在成为最关键的答案之一。

未来展望

短期内，AI 不会取代设计师；但它确实正在加速设计工程师这一角色的涌现。对经验丰富的设计师来说，未来的进阶方向大致会分成两条（当然，也可以叠加管理路径）：

• 探险家（Adventurer）：专注攻克那些真正高难度的创作与验证问题——这些问题仍然需要极强的人类创造力、同理心与判断力
• 架构师（Architect）：专注搭建方法、流程与基础设施，把更多设计问题从“验证困难”的泥潭里拉出来，让团队整体能力被放大