设计与工程解决不同的问题；AI正在忘记这一点

当组织通过工程工作流采用AI时，设计工作往往被拉进管道，变成代码的提示生成器，或者只是加快产出速度的另一种方式。设计师不得不适应这些流程，因为通常只有这些流程可用，但这种适应将焦点从设计本应进行的决策上转移开。

设计与工程的交叉确实重要，它可以改善双方的决策。当设计师理解工程师如何构建、编码和测试时，他们能做出更好的设计决策。当工程师理解设计思维时，他们能更周到地构建产品。但交叉不等于做同样的工作，或使用同样的流程。

AI最初在工程领域显现的收益，主要体现在更快的代码生成、自动化管道和系统效率提升上。这并不奇怪。工程工作已经以速度和产出为导向，AI则同时加速了这两者。当工程引领组织的AI探索时，其工作流和优化目标将塑造整个过程：组织会选择适合工程管道的工具，团队以速度和产出衡量成功，开发者围绕交付代码设计工作流。当设计师采用这些工具时，焦点就转向了速度和可交付性，偏离了设计本应做的决策：我们是否应该构建这个功能？这会将谁排除在外？当顺利路径失败时，什么会出问题？这些正是这些工作流所没有留出空间的工作。

设计工作并非从工程工作流的起点开始。它开始得更早，在模糊性、相互冲突的约束和尚未有明确答案的问题中。它在承诺解决方案之前理清问题空间。这需要一个不同的过程，而不是工程过程的加速版本。当设计师被赋予工程工作流时，工作开始发生变化：更多时间花在学习工具上，而不是从事实际工作；团队开始优化产出而非决策质量；设计创造的价值（风险降低、问题框架、共享理解）变得更难看见，也更容易被削减。这并不是因为组织明确决定设计应该像工程一样工作，而是当只有一个学科塑造工具和工作流时，系统会自动产生这种结果。

设计工作的实际作用是，在构建任何东西之前做出更好的决策。它识别什么不该构建，在风险变得昂贵之前将其暴露，并创造共享理解，使团队能够自信地朝正确方向构建。无论设计师是在为不熟悉的用户选择导航模式、为屏幕阅读器构建内容层次，还是确定在开始设计新功能之前需要研究哪些问题，这一点都成立。放慢这些早期决策通常能通过防止返工和后期失败来加速整体交付。这在无障碍工作中最为明显。团队可以快速生成UI，生成能通过自动化检查的东西。但通过测试并不等于对使用屏幕阅读器、开关设备或语音控制的人来说是可行的。这些失败不会以代码错误的形式出现，而是后来以真实人的糟糕体验出现。发现这些失败需要判断力、模式识别和领域知识，需要理解交互和用户。更快的产出并不能解决这个问题。加速错误的部分没有帮助，只会让你更快地到达错误的地方。

这并不是反对在设计中使用AI的论点。而是主张以符合设计实际工作的方式来使用AI。使用AI更快地生成代码并不能使结果更易访问。使用AI来压力测试交互则确实有帮助。这种质疑——键盘用户会遇上什么？焦点顺序在哪里崩溃？屏幕阅读器会宣告什么？——扩展了已有的思考。这就是AI作为思考伙伴，而非生产工具。当使用得当时，AI可以通过更早地发现风险、挑战假设、探索边缘情况和综合研究来支持设计所需的思考。在无障碍工作中，早期关于交互模式、组件结构和内容层次的决策可以防止下游任何工具都无法捕获的失败。这样使用AI，它支持判断而非取代判断。

任何AI倡议更重要的问题不仅仅是“我们如何更快？”而是“工作的哪些部分可以借助AI改进——哪些部分需要保持缓慢？”设计和无障碍从业者最有资格回答这个问题，但前提是他们在问题被提出时在场。许多组织缺少的是认识到设计师带来了不同的方法，这种方法暴露了可用性、理解性和无障碍方面的风险，并以决策质量而非产出速度来衡量成功。这不是软技能。这是基础设施。它是防止代价高昂的失败并确保构建的东西真正适用于人的基础性思考。

目标不是将AI从工程主导转向设计主导。那将造成另一种不平衡。纯工程方法过度优化速度；纯设计方法可能过度强调开放探索。产品开发是一个共享的决策系统，而不仅仅是执行。AI的采纳需要工程、设计和产品共同领导。在实践中，这意味着：将AI工具置于工程、设计和产品工作流中评估；以包含决策质量的方式定义成功；明确哪些思考需要保护；让两个学科参与工具和工作流的定义。AI不应该只是让团队更快，它应该帮助他们做出更好的决策。只有设计、工程和产品共同塑造AI的使用方式，而不是让一方适应另一方的工作方式时，这一点才能实现。