设计流程

设计是一个迭代过程：设计活动并非沿单一线性路径一次完成，而是通过多轮循环反复组织、记录并改进创造性思考与行动，逐步把最初的简报或需求推进为有价值的有形成果。^{33The Design Process | NSEADnsead.org前往参考资料 ↓在新标签页中打开}

迭代性在设计流程中的功能定位是“改进”：每一轮循环都以前一轮的记录与产出为输入，对创意方向和具体行动作出修正，使设计逐步逼近可实现、可交付的方案，而不是简单重复。^{33The Design Process | NSEADnsead.org前往参考资料 ↓在新标签页中打开}

迭代与记录不可分割：设计过程要求把思考过程以及推进设计走向实现所必需的信息记录下来，这些记录构成下一轮迭代的判断依据，因此迭代性同时是一种过程性文档实践。^{33The Design Process | NSEADnsead.org前往参考资料 ↓在新标签页中打开}

在设计教育与设计通识语境中，迭代被视为设计的本质属性之一，而非某种特定方法论的附加特征；英国全国艺术与设计教育协会（NSEAD）在阐述设计流程时即把“设计是迭代过程”作为出发点。^{33The Design Process | NSEADnsead.org前往参考资料 ↓在新标签页中打开}

迭代性的表现形式是开放的：它可以采取多种形态来组织、记录和传达改进，并不绑定于某一种固定的阶段图或模板，这使不同学科领域（如艺术设计、设计与技术）可以在同一迭代原则下采用各自的流程表达。^{33The Design Process | NSEADnsead.org前往参考资料 ↓在新标签页中打开}

用户中心设计（User-centred design）是一种把最终用户置于设计流程中心的方法论取向：在流程的每个阶段——从项目启动、决策到设计验证——都持续把用户的需求、行为与反馈作为判断依据，而不是在开发末期才引入用户测试。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

英国水文局（UK Hydrographic Office）在其 ADMIRALTY 设计体系中明确声明，用户中心设计原则是其开发产品与服务的核心，目标是让用户处于流程、决策与设计验证的中心位置。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

在 ADMIRALTY 的实践中，用户中心设计流程覆盖从项目启动（kick-off）到迭代测试与再设计的完整周期，即用户参与不是一次性环节，而是贯穿交付全程的循环结构。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

ADMIRALTY 的设计流程大体遵循英国政府数字服务（GDS）的设计原则，但由于其用户群体与需求具有特殊性，部分原则需要做适应性调整——这说明用户中心的具体做法是情境化的，而非一套固定不变的通用清单。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

用户中心设计的一个可操作特征是：把用户研究结论转化为对设计方案的验证标准，即在流程中设置以用户为参照的决策与验收节点，而不仅是产出用户画像或调研报告。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

跨学科协作在设计流程中指的是将来自不同学科背景（如工程、人因、工业设计、心理学、计算机科学等）的成员组织到同一流程中共同推进设计决策，其核心特征不是简单的人员拼凑，而是不同知识体系在问题定义、方案生成与评估环节的持续交互。^{55Design Thinkinghbr.org前往参考资料 ↓在新标签页中打开}

跨学科协作在设计流程中的必要性常被归因于设计问题的「 wicked problem（棘手问题）」属性：问题本身没有唯一正解、约束相互冲突，单一学科视角难以覆盖全部约束，因此需要多学科知识同时在场。^{66Dilemmas in a General Theory of Planninglink.springer.com前往参考资料 ↓在新标签页中打开}

在设计流程的早期阶段（需求发现与问题定义），跨学科协作的价值主要体现在把用户研究、技术可行性与商业约束同时纳入问题框架，避免流程后期因单学科假设而返工。^{55Design Thinkinghbr.org前往参考资料 ↓在新标签页中打开|77The Design of Design: Essays from a Computer Scientistdl.acm.org前往参考资料 ↓在新标签页中打开}

跨学科协作的有效性依赖共享的表征与沟通媒介，例如草图、原型、场景脚本与共同的设计语言；缺少共享表征时，不同学科成员容易各自沿用本学科术语，导致协作退化为并行工作而非真正整合。^{77The Design of Design: Essays from a Computer Scientistdl.acm.org前往参考资料 ↓在新标签页中打开}

跨学科协作并不等于消除学科分工：多数设计流程模型仍保留各学科的专业职责与交付物，协作发生在接口与决策节点上，而非让所有成员在所有环节做同样的事。^{55Design Thinkinghbr.org前往参考资料 ↓在新标签页中打开}

跨学科协作在实践中面临的主要障碍包括学科间权力与话语不对等、目标与评价标准不一致、以及协作成本（会议、协调、翻译）随参与学科数量上升而增加。^{77The Design of Design: Essays from a Computer Scientistdl.acm.org前往参考资料 ↓在新标签页中打开}

在智能座舱等软硬件深度耦合的产品领域，跨学科协作被进一步扩展为设计、人机交互、嵌入式软件、功能安全与法规合规等多职能的协同，协作边界从设计团队内部延伸到工程与合规组织。^{88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

需求分析与研究是设计流程的起始阶段，其核心任务是通过系统化方法收集、整理和解读用户需求、业务目标与约束条件，形成可指导后续设计决策的需求定义。^{99Designing for the Digital Age: How to Create Human-Centered Products and Serviceswiley.com前往参考资料 ↓在新标签页中打开}

英国设计委员会（Design Council）提出的「双钻模型」（Double Diamond）将设计流程分为「发现」「定义」「开发」「交付」四个阶段，其中前两个阶段——发现与定义——共同构成需求分析与研究环节。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

在需求分析与研究阶段，常用的方法包括用户访谈、情境访谈、焦点小组、问卷调查、日记研究、竞品分析以及利益相关者地图等，这些方法旨在从不同维度获取定性或定量洞察。^{1010Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开}

人机交互领域的人本设计（Human-Centred Design）标准 ISO 9241-210 将「理解并明确使用情境」列为设计活动的首要环节，强调需识别用户、任务、设备及环境等要素。^{88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

需求分析与研究阶段的输出通常包括用户画像（Persona）、用户旅程地图（User Journey Map）、需求清单、设计简报（Design Brief）等交付物，用于在团队内对齐对问题的理解。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

敏捷开发语境下的设计流程往往将需求分析与研究压缩为短周期的「探索」活动，强调持续发现（Continuous Discovery）而非一次性前置调研，以应对需求的不确定性。^{1212Continuous Discovery Habits: Discover Products that Create Customer Value and Business Valueproducttalk.org前往参考资料 ↓在新标签页中打开}

在工业设计的设计程序划分中，概念设计（概念生成）通常被列为继课题确定、调研与可行性研究之后的第三个阶段，位于核心设计与推广设计之前。^{1313工业设计概论netedu.xauat.edu.cn前往参考资料 ↓在新标签页中打开}

概念生成阶段的基本任务是在前期调研与可行性研究的基础上，把用户需求、技术条件与市场信息转化为初步的设计构想，形成可供后续深化与筛选的概念方案。^{1313工业设计概论netedu.xauat.edu.cn前往参考资料 ↓在新标签页中打开}

概念生成并非凭空创意，其输入来自调研阶段收集的参数、文献、图片、广告、国家规范与政策资料，以及用户访谈、市场调查、生活方式调查和设计调查所获得的第一手信息。^{1313工业设计概论netedu.xauat.edu.cn前往参考资料 ↓在新标签页中打开}

调研阶段通过信度与效度分析提取有价值、可信的信息，建立用户模型或数学模型，并对照创意与构思确定研究方向、核心要素与课题的主题结构，这些成果构成概念生成的直接依据。^{1313工业设计概论netedu.xauat.edu.cn前往参考资料 ↓在新标签页中打开}

概念生成阶段的产出需要以可行性论证报告的形式提交上级审定，作为从概念构想进入核心设计阶段的决策依据。^{1313工业设计概论netedu.xauat.edu.cn前往参考资料 ↓在新标签页中打开}

在工业设计程序的语境下，概念设计被定位为承上启下的环节：它既是对调研与可行性研究结论的收敛，也是对后续核心设计与推广设计的展开起点。^{1313工业设计概论netedu.xauat.edu.cn前往参考资料 ↓在新标签页中打开}

原型制作在设计流程中并非从打开工具画页面开始，而是从明确「这次要验证什么」开始，到团队确认方案、交付研发并记录决策结束；一个可复用的原型流程通常包括明确目标、梳理用户任务、搭建信息架构、制作低保真原型、补齐交互与状态、组织评审测试、整理交付与复盘七个环节。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

原型制作阶段的核心原则是「先验证流程，再提高保真度」：先确认用户能否完成核心任务，再处理视觉、动效和细节，避免过早陷入高保真细节而掩盖流程问题。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

原型制作应逐步推进并让每一步解决一个具体问题：为什么做、用户怎么走、页面放什么、操作后发生什么、团队准备实现哪一版；发现问题时返回对应步骤修改，而不必把整套流程从头重做。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

原型制作不应以页面数量衡量进度：画了十个页面但用户不知道提交后是否成功，仍缺少关键设计；只做四个页面却把正常、取消和失败路径讲清楚，已能支持一轮有价值的评审。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

原型制作各步骤应留下可继续使用的产物：明确目标留下核心任务、范围与待验证问题；梳理任务留下主流程、关键分支与返回路径；列出页面留下页面清单、字段与页面关系；搭建低保真留下真实文案下的布局与可点击路径；补齐交互留下交互说明、状态与恢复方式；评审测试留下问题、修改决定与负责人；整理交付留下原型版本、规则、验收条件与未决项。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

在原型制作中，低保真阶段关注的是「不靠装饰，用户能否看懂顺序」，即以真实文案检验布局与可点击路径，而非追求视觉完成度。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

原型制作中的交互补齐环节需覆盖提交、等待、失败、退出等状态及其恢复方式，使原型能说明操作后发生什么，而不只是静态页面集合。^{1414原型设计流程与原则：从需求梳理到评审交付的7个步骤modao.cc前往参考资料 ↓在新标签页中打开}

用户测试是设计流程中位于原型之后的评估阶段：在开发前用真实或代表性用户操作原型或可用版本，观察其行为、收集反馈，以判断设计是否满足使用需求并发现可用性问题。^{1515Usability Testingnngroup.com前往参考资料 ↓在新标签页中打开|88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

在以人为本设计（HCD）的迭代循环中，用户测试属于「评估设计」环节，其输出（可用性问题清单、改进建议）回流到「理解并明确使用情境」与「产出设计方案」，构成设计—测试—再设计的闭环。^{88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

ISO 9241-210 将「以用户为中心的设计」定义为包含四个相互关联活动的迭代过程：理解并明确使用情境、明确用户需求、产出设计方案、依据需求评估设计；用户测试是「评估设计」活动的主要手段之一。^{88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

可用性测试的经典方法论奠基工作来自 Nielsen 与 Molich 对启发式评估的提出，以及 Nielsen 关于「少量用户即可发现大部分可用性问题」的实证研究，后者常被概括为「5 名用户可发现约 85% 的可用性问题」。^{1616Heuristic evaluation of user interfacesdl.acm.org前往参考资料 ↓在新标签页中打开|1717Why You Only Need to Test with 5 Usersnngroup.com前往参考资料 ↓在新标签页中打开}

Nielsen 的「5 名用户」结论建立在特定测试条件（单一用户群体、同一类界面、启发式评估或简单可用性测试）之上，作者本人也强调该数字随用户群体划分与问题类型而变化，不应被当作普适常数。^{1717Why You Only Need to Test with 5 Usersnngroup.com前往参考资料 ↓在新标签页中打开}

用户测试按执行环境可分为实验室测试、现场测试与远程测试；按主持方式可分为有主持（moderated）与无主持（unmoderated）；按测试目标可分为形成性测试（formative，用于发现并改进问题）与总结性测试（summative，用于验证是否达到可用性指标）。^{1515Usability Testingnngroup.com前往参考资料 ↓在新标签页中打开|1818Usability Testing: Formative vs. Summativeinteraction-design.org前往参考资料 ↓在新标签页中打开}

形成性测试通常在设计中前期进行，样本量小、以定性发现为主；总结性测试在设计定型前后进行，需要更大的样本量与预先定义的量化指标（如任务完成率、任务用时、错误率、主观满意度量表得分）。^{1818Usability Testing: Formative vs. Summativeinteraction-design.org前往参考资料 ↓在新标签页中打开}

用户测试的常用数据采集手段包括出声思维（think-aloud）、任务后问卷（如 SUS 系统可用性量表）、观察记录与日志/眼动等行为数据；出声思维分为同步与回溯两种，同步出声思维更贴近真实操作但可能干扰任务表现。^{1515Usability Testingnngroup.com前往参考资料 ↓在新标签页中打开|1919SUS: A quick and dirty usability scaletandfonline.com前往参考资料 ↓在新标签页中打开}

SUS（System Usability Scale）由 Brooke 于 1986 年提出，包含 10 个题目、采用 5 点李克特量表，最终换算为 0–100 的分数；它被广泛用于测试后的主观可用性度量。^{1919SUS: A quick and dirty usability scaletandfonline.com前往参考资料 ↓在新标签页中打开}

在敏捷与精益设计流程中，用户测试被压缩为短周期、小样本的「快速测试」或「游击测试」，与持续交付节奏对齐，强调在每次迭代结束前获得可行动的反馈而非统计显著性。^{2020Lean UX: Designing Great Products with Agile Teamsoreilly.com前往参考资料 ↓在新标签页中打开}

用户测试的常见局限包括：测试情境与真实使用情境存在差异、样本代表性不足、主持人偏差（如引导性提问）、以及测试只能发现「已设计出来的问题」而难以发现需求层面的缺失。^{1515Usability Testingnngroup.com前往参考资料 ↓在新标签页中打开|1818Usability Testing: Formative vs. Summativeinteraction-design.org前往参考资料 ↓在新标签页中打开}

在智能座舱等安全相关场景中，用户测试还需覆盖驾驶分心与情境感知维度，常结合驾驶模拟器、实车道路测试与分心评估方法（如 NHTSA 的分心驾驶指南）进行，而不仅是桌面可用性测试。^{2222Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesnhtsa.gov前往参考资料 ↓在新标签页中打开}

迭代优化指设计流程在原型、测试、反思、改进之间反复循环，而非一次性线性走完；台大智活 iNSIGHT 将企业设计创新流程描述为「螺旋状持续不断循环与迭代」，随着产品迭代，螺旋逐渐内缩，探索的议题层面逐渐缩小、构想概念逐渐具体化。^{2323一次看懂企業設計創新流程（下）：敏捷開發、迭代測試｜台大智活iNSIGHTinsight.ntu.edu.tw前往参考资料 ↓在新标签页中打开}

在台大智活 iNSIGHT 归纳的十阶段企业设计创新流程中，迭代优化对应第 5 至第 9 阶段：原型制作、构想测试、学习/反思、方案改进、再次发展概念，并持续迭代直到产品或服务生命周期结束。^{2323一次看懂企業設計創新流程（下）：敏捷開發、迭代測試｜台大智活iNSIGHTinsight.ntu.edu.tw前往参考资料 ↓在新标签页中打开}

该流程的后半段（阶段 5~9）体现精实创业与敏捷开发的精神，强调通过持续测试与反思来优化或验证先前发展的概念，以便快速迭代产品或服务。^{2323一次看懂企業設計創新流程（下）：敏捷開發、迭代測試｜台大智活iNSIGHTinsight.ntu.edu.tw前往参考资料 ↓在新标签页中打开}

英国水文局（UKHO）的 ADMIRALTY 设计体系明确采用以用户为中心的设计流程，从项目启动一直贯穿到迭代测试与再设计（iterative test and re-design），迭代测试被列为交付流程中的固定环节。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

ADMIRALTY 设计体系大体遵循英国政府数字服务（GDS）的设计原则，但因用户群体与需求特殊而对部分原则做了调整；这说明迭代优化的具体做法会随组织与用户情境而本地化，而非照搬通用模板。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

迭代优化并不否定前期阶段的价值：台大智活 iNSIGHT 指出流程前半段（阶段 0~4）强调深刻理解课题、找到机会点后才进入概念发展，后半段的快速迭代是建立在前期收敛之上的。^{2323一次看懂企業設計創新流程（下）：敏捷開發、迭代測試｜台大智活iNSIGHTinsight.ntu.edu.tw前往参考资料 ↓在新标签页中打开}

设计交付（design handoff）指设计阶段向开发、制造或供应链移交成果物的环节，通常包括设计规范、组件与样式定义、标注与切图、原型与交互说明、设计源文件以及验收标准等交付物。^{2424Design handoffinteraction-design.org前往参考资料 ↓在新标签页中打开}

在数字产品设计流程中，设计交付被普遍视为从设计走向实现的过渡节点，其质量直接影响实现还原度与返工率；设计系统与组件库的引入使交付物从一次性文档转向可持续维护的共享资产。^{2424Design handoffinteraction-design.org前往参考资料 ↓在新标签页中打开|2525Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计规范类交付物的典型内容包含颜色、字体排印、间距与栅格、图标、组件状态与交互反馈规则，其目的是让实现方在不反复询问设计师的情况下完成开发。^{2525Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

在硬件与工业设计领域，设计交付更多表现为面向制造的设计数据移交，包括三维模型、二维图纸、公差与材料规格、表面处理要求等，并需与工程变更流程衔接。^{2626Design for manufacturabilityen.wikipedia.org前往参考资料 ↓在新标签页中打开}

设计交付并非流程终点：交付后通常伴随设计走查（design QA）与验收，用以核对实现结果与设计意图的一致性，并将偏差回流为规范或组件的修订。^{2424Design handoffinteraction-design.org前往参考资料 ↓在新标签页中打开|2525Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

随着设计工具与研发工具链的集成加深，交付方式正从静态标注文档转向设计令牌（design tokens）与代码化规范，使设计决策能以结构化数据形式在设计与代码之间同步。^{2525Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

设计交付的常见失败模式包括交付物不完整或过期、设计与实现之间缺少共同语言、变更未同步到所有下游，导致实现偏差与重复沟通成本上升。^{2424Design handoffinteraction-design.org前往参考资料 ↓在新标签页中打开}

共情阶段要求设计者通过访谈、观察、沉浸式体验等方式理解用户的真实需求与情感动机，强调暂时搁置自身假设，从用户视角收集一手材料。^{2727Design Thinking Bootlegdschool.stanford.edu前往参考资料 ↓在新标签页中打开}

定义阶段将共情阶段收集的零散信息收敛为一个清晰的问题陈述（problem statement），通常以「用户 + 需求 + 洞察」的句式表达，目的是把模糊的用户痛点转化为可操作的设计目标。^{2727Design Thinking Bootlegdschool.stanford.edu前往参考资料 ↓在新标签页中打开}

构思阶段以发散为核心，通过头脑风暴、SCAMPER、最坏想法法等技巧生成大量候选方案，强调先求数量、延迟评判，再在后续阶段收敛筛选。^{2828Design Thinking: A Guide to Creative Problem Solving for Everyoneinteraction-design.org前往参考资料 ↓在新标签页中打开}

原型阶段主张以低成本、低精度的物理或数字形式（纸面草图、纸板模型、可点击原型等）快速外化想法，目的是用最小代价暴露问题而非展示最终方案。^{2727Design Thinking Bootlegdschool.stanford.edu前往参考资料 ↓在新标签页中打开}

测试阶段将原型交给真实用户使用并观察其反馈，测试结果往往不是终点，而是回到前面某一阶段重新迭代的起点，因此五阶段在实践中呈非线性循环而非单向流水线。^{2727Design Thinking Bootlegdschool.stanford.edu前往参考资料 ↓在新标签页中打开}

设计思维五阶段与 IDEO 提出的「灵感—构思—实施」（Inspiration–Ideation–Implementation）三空间模型同源，后者由 IDEO 在 2001 年前后提出，五阶段可视为对其中「构思」空间的进一步细分。^{2929Design Thinkingdesignthinking.ideo.com前往参考资料 ↓在新标签页中打开}

英国设计委员会（Design Council）于 2004 年提出的「双钻模型」（Discover–Define–Develop–Deliver）与设计思维五阶段在结构上高度相似，两者都把「发散—收敛」的交替作为流程骨架，常被并列讨论。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

在智能座舱等复杂产品开发中，五阶段常被裁剪使用：共情与定义阶段对应座舱用户场景研究，构思与原型阶段对应 HMI 概念设计与可交互原型，测试阶段对应驾驶模拟器或实车用户测试。^{3131Design Thinking for Automotive HMIsae.org前往参考资料 ↓在新标签页中打开}

双钻模型（Double Diamond）由英国设计委员会（Design Council）于 2004 年提出，最初用于描述设计在商业与社会创新中的价值，后成为公共部门与产业界广泛采用的设计流程框架。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

双钻模型将设计过程划分为四个阶段：发现（Discover）、定义（Define）、开发（Develop）与交付（Deliver），前两个阶段构成第一个钻石（从发散到收敛的问题空间），后两个阶段构成第二个钻石（从发散到收敛的解决方案空间）。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开|11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

在双钻模型中，发现阶段强调通过用户研究、民族志、利益相关者访谈等方式广泛收集信息，以理解问题背景与用户需求；定义阶段则对收集到的信息进行综合、聚类与优先级排序，形成清晰的问题陈述（problem statement）。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开|2828Design Thinking: A Guide to Creative Problem Solving for Everyoneinteraction-design.org前往参考资料 ↓在新标签页中打开}

开发阶段通过头脑风暴、原型制作、快速迭代等方法生成并测试多种解决方案；交付阶段则对选定的方案进行细化、测试与实施，并最终推向市场或交付使用。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开|11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

双钻模型强调设计过程的发散与收敛交替进行，而非线性推进；每个钻石内部都包含先扩展可能性再聚焦决策的循环，且阶段之间允许回溯与迭代。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开|2828Design Thinking: A Guide to Creative Problem Solving for Everyoneinteraction-design.org前往参考资料 ↓在新标签页中打开}

英国设计委员会在 2019 年对双钻模型进行了更新，发布了《双钻模型：设计过程框架》修订版，进一步强调框架的灵活性与非规定性，并增加了对协作、包容性设计与系统思维的关注。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

双钻模型已被英国政府、多家公共机构及企业采用为设计流程的参考框架，并衍生出多个变体，如英国设计委员会与公共服务部门合作推出的“政策双钻”等。^{11The Double Diamond: A universally accepted depiction of the design processdesigncouncil.org.uk前往参考资料 ↓在新标签页中打开}

瀑布模型由温斯顿·罗伊斯于1970年提出，其核心思想是将软件开发划分为需求分析、设计、实现、测试、维护等顺序阶段，每个阶段完成后才进入下一阶段，并强调文档驱动与阶段性评审。^{3333Managing the Development of Large Software Systemscs.umd.edu前往参考资料 ↓在新标签页中打开}

瀑布模型在20世纪70至90年代成为软件工程与系统设计的主流流程范式，被广泛纳入政府与大型企业的采购标准（如美国国防部的DOD-STD-2167A），因其可预测性和合同可管理性而受到青睐。^{3434DOD-STD-2167A: Defense Systems Software Developmentquicksearch.dla.mil前往参考资料 ↓在新标签页中打开}

敏捷宣言于2001年由17位软件开发者在美国犹他州雪鸟滑雪场发布，提出个体与互动、可工作的软件、客户合作、响应变化四项价值观，以及十二条原则，标志着敏捷设计流程的正式成型。^{3535Manifesto for Agile Software Developmentagilemanifesto.org前往参考资料 ↓在新标签页中打开}

敏捷开发强调迭代增量交付，典型迭代周期为1至4周，每个迭代结束时交付可工作的软件，并通过持续反馈调整设计方向；Scrum和极限编程（XP）是其中最具代表性的两种实践框架。^{3636Agile Software Development: Principles, Patterns, and Practicespearson.com前往参考资料 ↓在新标签页中打开}

瀑布式与敏捷式在需求变更处理上存在根本差异：瀑布式假设需求在早期即可冻结，变更需走正式变更控制流程；敏捷式则将变更视为常态，通过短迭代和待办事项列表（backlog）动态管理优先级。^{3737A Comparison of Waterfall and Agile Software Development Methodologiesresearchgate.net前往参考资料 ↓在新标签页中打开}

在受监管行业（如医疗设备、航空航天）中，瀑布式流程因其完整的文档追溯链仍被广泛采用，而敏捷式则需通过额外裁剪（如将迭代与阶段关口结合）来满足合规要求，形成所谓的“混合式”或“敏捷瀑布”流程。^{3838Agile in Regulated Environments: A Systematic Reviewsciencedirect.com前往参考资料 ↓在新标签页中打开}

瀑布式与敏捷式并非互斥，实践中常出现“瀑布-敏捷混合”模式：在项目前期采用瀑布式进行可行性研究与总体架构设计，在开发阶段转入敏捷迭代，最终以瀑布式验收与交付收尾。^{4040Hybrid Software Development Approaches: A Systematic Mapping Studysciencedirect.com前往参考资料 ↓在新标签页中打开}

在汽车电子与软件工程中，V模型把开发过程划分为左侧的分解与设计阶段（整车需求、系统需求、子系统/组件设计）和右侧的集成与验证阶段（组件测试、子系统测试、系统测试、整车测试），左右两侧通过需求追溯关系一一对应。^{4141Systems Engineering Fundamentalsdau.edu前往参考资料 ↓在新标签页中打开|4242Systems Engineering for Automotive Embedded Systemslink.springer.com前往参考资料 ↓在新标签页中打开}

汽车行业软件过程改进能力评定（Automotive SPICE，ASPICE）以V模型为参照组织其过程域，把系统工程（SYS）、软件工程（SWE）和硬件工程（HWE）的过程按V形左右两侧排列，并要求双向追溯与一致性证据。^{4343Automotive SPICE in Practicelink.springer.com前往参考资料 ↓在新标签页中打开}

ISO 26262 在功能安全开发中采用与V模型同构的阶段划分：概念阶段（相关项定义、危害分析与风险评估、功能安全概念）、产品开发阶段（系统级、硬件级、软件级）以及生产运行阶段，每个开发阶段都对应明确的验证与确认活动。^{22ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

智能座舱的设计流程通常把用户体验设计（场景定义、交互原型、视觉与HMI设计）放在V模型左侧的需求与概念阶段，把可用性测试、HMI一致性检查、实车体验验收放在右侧的验证与确认阶段，使设计交付物与工程验证节点对齐。^{4444Designing for the Automotive User Experience: Challenges and Opportunitiesdl.acm.org前往参考资料 ↓在新标签页中打开|4545Human-Machine Interface Design for Automated Vehiclessae.org前往参考资料 ↓在新标签页中打开}

在智能座舱项目中，设计阶段输出的用户需求与场景描述需要被转化为可追溯的系统需求，并向下分解到座舱域控制器、显示、语音交互等子系统，从而在V模型左侧建立从用户需求到系统需求的追溯链。^{4646Requirements Engineering for Automotive Systemslink.springer.com前往参考资料 ↓在新标签页中打开}

V模型右侧的验证活动与设计流程的对应关系体现为：组件级测试验证交互组件的功能与性能，系统级测试验证多模态交互的整体行为，整车级测试与用户体验验收验证真实场景下的可用性与一致性。^{4242Systems Engineering for Automotive Embedded Systemslink.springer.com前往参考资料 ↓在新标签页中打开|4545Human-Machine Interface Design for Automated Vehiclessae.org前往参考资料 ↓在新标签页中打开}

由于智能座舱的交互设计迭代速度快于传统整车开发节奏，实践中常采用设计冲刺、原型快速验证等敏捷方法，与V模型的阶段门评审形成“双轨”并行，设计侧快速迭代、工程侧按V模型节点收敛。^{4444Designing for the Automotive User Experience: Challenges and Opportunitiesdl.acm.org前往参考资料 ↓在新标签页中打开|4747Agile Development in Automotive Software: A Systematic Mapping Studyieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在V模型框架下，设计变更需要经过变更影响分析并更新相应的需求与测试用例，以维持追溯链的完整性；智能座舱HMI频繁变更对变更管理流程提出了更高要求。^{4646Requirements Engineering for Automotive Systemslink.springer.com前往参考资料 ↓在新标签页中打开}

ISO 26262《道路车辆 功能安全》是智能座舱功能安全设计流程的基础标准，其流程要求从概念阶段（危害分析与风险评估、安全目标制定）到系统、硬件、软件开发，再到生产、运行、报废，形成完整的汽车安全生命周期（safety lifecycle）。^{22ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 将汽车安全完整性等级（ASIL）划分为 A、B、C、D 四级，D 级要求最严；智能座舱中涉及驾驶员信息显示、告警提示等安全相关功能时，需按 ASIL 等级确定开发流程的严格程度与验证深度。^{22ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 第二版（2018 年发布）将适用范围从乘用车扩展到公共汽车、卡车、摩托车等所有量产道路车辆，并新增了对半导体、软件工具和网络安全相关接口的指导，使座舱域控制器等复杂电子系统的功能安全流程有了更明确的依据。^{22ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 21448《预期功能安全》（SOTIF）针对的是没有系统故障、但功能或性能不足或可预见误用所导致的风险，与 ISO 26262 形成互补；智能座舱中的语音交互、手势识别、驾驶员监控等感知与交互功能，其性能局限与误用风险通常需要按 SOTIF 流程评估。^{4848ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开}

ISO/TR 21959 系列技术报告讨论了车辆驾驶自动化中与人类行为相关的问题，为智能座舱人机交互设计中的驾驶员状态、接管与注意力分配等提供参考框架。^{4949ISO/TR 21959-1:2020 Road vehicles — Human performance and state in the context of automated driving — Part 1: Common underlying conceptsiso.org前往参考资料 ↓在新标签页中打开}

ISO 9241-210 确立了以人为中心的设计（Human-Centred Design）流程，包括理解使用情境、明确用户需求、产出设计解决方案、基于用户评估迭代四个活动；该流程常被引入智能座舱人机交互设计，用于在功能安全约束下平衡可用性与驾驶安全。^{88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

美国国家公路交通安全管理局（NHTSA）发布的《Human Factors Design Guidance for Driver-Vehicle Interfaces》为车载信息娱乐与驾驶员交互界面提供了人因设计指导，涵盖视觉负荷、分心时长、任务复杂度等可检验要求，常被座舱 HMI 设计流程用作验收参考。^{5050Human Factors Design Guidance for Driver-Vehicle Interfacesnhtsa.gov前往参考资料 ↓在新标签页中打开}

联合国欧洲经济委员会（UNECE）法规 R79（转向装置）与 R10（电磁兼容）等对车辆驾驶控制与电子系统提出型式认证要求，智能座舱中与驾驶控制相关的交互功能在进入市场前需满足相应法规流程。^{5151UN Regulation No. 79 — Steering equipmentunece.org前往参考资料 ↓在新标签页中打开}

在智能座舱开发中，功能安全流程与人机交互流程需要在需求阶段就进行联合评审：安全目标（safety goal）会转化为对 HMI 的具体约束（如告警优先级、不可屏蔽的提示、操作确认机制），而 HMI 的可用性评估结果又可能反过来触发危害分析更新。^{22ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开|88ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 要求对安全相关电子系统进行验证与确认（verification and validation），包括硬件在环（HIL）测试、故障注入测试等；智能座舱域控制器的多屏、多模态交互特性使这些测试需要覆盖显示失效、触控误触发、语音误识别等场景。^{22ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 与 ISO 21448 的边界划分在业界存在讨论：对于依赖机器学习感知的座舱功能（如驾驶员疲劳监测），其性能不足究竟应归入功能安全流程还是 SOTIF 流程，不同企业与研究者的处理方式并不一致。^{4848ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开}

英国政府数字服务（GDS）发布的《政府设计原则》是公共部门数字服务设计流程中被广泛参照的纲领性文件，其十条原则强调「从用户需求出发」「为所有人设计」「用数据做设计」等，并明确要求在设计早期就开展用户研究、以真实用户需求而非假设驱动设计决策。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

英国水文局（UKHO）在其 ADMIRALTY 设计系统中说明，团队大体遵循 GDS 设计原则，但因自身用户群体（航海人员、航运机构等）特殊，对部分原则做了适配；其设计流程从项目启动贯穿到迭代测试与再设计，用户被置于流程、决策与设计验证的中心。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

在用户研究工具的分类上，业界通常按「定性—定量」与「行为—态度」两个维度划分：定性行为类包括可用性测试、田野研究，定性态度类包括用户访谈、焦点小组，定量行为类包括 A/B 测试、日志分析，定量态度类包括问卷调研、净推荐值（NPS）测量。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

可用性测试是设计流程中验证设计方案的核心工具：让代表性用户完成典型任务，研究者观察并记录任务完成率、出错次数与主观满意度，据此定位界面问题并驱动下一轮迭代。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

用户访谈与焦点小组属于定性态度类工具，适合在流程早期探索用户心智模型与未满足需求；其结论不宜直接外推为总体比例，通常需与问卷等定量工具配合使用。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

问卷调研与日志分析等定量工具用于度量用户行为的分布与规模，A/B 测试则用于在真实流量下比较两个设计变体的效果差异，二者共同构成设计决策的量化证据来源。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

人物角色（persona）、用户旅程地图（user journey map）与情境访谈等工具，常被用于把分散的用户研究结论整合为可被设计与开发团队共享的用户模型，从而在流程各阶段持续对齐用户需求。^{44Admiralty Design Systemdesignsystem.admiralty.co.uk前往参考资料 ↓在新标签页中打开}

原型工具是设计流程中用于将概念假设转化为可感知、可交互形态的软件或硬件手段，其核心价值在于以较低成本在早期暴露需求误解与交互缺陷，从而减少后期返工。^{5252Prototypinginteraction-design.org前往参考资料 ↓在新标签页中打开}

按保真度划分，原型工具通常覆盖低保真（纸质草图、线框图）、中保真（可点击线框、交互式原型）和高保真（接近最终视觉与动效的可运行原型）三个层次；低保真工具强调快速迭代与低成本修改，高保真工具强调真实感与可用性测试的生态效度。^{5252Prototypinginteraction-design.org前往参考资料 ↓在新标签页中打开}

Figma 是当前主流的界面设计与协作原型工具，支持多人实时协同编辑、组件库与自动布局，并通过 Figma Mirror 在移动设备上预览原型；其协作模型将设计文件从单人本地文件转变为团队共享的云端工作空间。^{5353Figma — Design and prototypefigma.com前往参考资料 ↓在新标签页中打开}

Sketch 是 macOS 平台上的矢量界面设计工具，以符号（Symbols）机制支持可复用组件，长期是 iOS 应用界面设计的主流工具之一；其插件生态和 .sketch 文件格式在第三方工具间具有较广的兼容性。^{5454Sketch — Design, prototype, collaboratesketch.com前往参考资料 ↓在新标签页中打开}

Adobe XD 是 Adobe 推出的界面设计与原型工具，支持画板、重复网格、自动动画与语音原型等特性，并与 Photoshop、Illustrator 等 Adobe 生态工具集成；Adobe 已于 2023 年宣布停止对 XD 的功能开发并逐步引导用户迁移。^{5555Adobe XDadobe.com前往参考资料 ↓在新标签页中打开}

Axure RP 是面向复杂交互与逻辑原型的桌面工具，支持条件逻辑、动态面板、变量与中继器（Repeater）等机制，常用于需要模拟真实业务规则的企业级系统与后台管理界面的原型设计。^{5656Axure RPaxure.com前往参考资料 ↓在新标签页中打开}

Framer 将原型工具与前端代码能力结合，允许设计者在可视化画布上构建交互原型并导出为可运行的 React 代码，代表了“设计—开发一体化”原型工具的方向。^{5757Framer — Design and publish sitesframer.com前往参考资料 ↓在新标签页中打开}

在智能座舱领域，原型工具需要覆盖多屏联动、语音交互、手势与触控混合输入等场景，因此除通用界面原型工具外，还常借助 Unity、Unreal Engine 等实时 3D 引擎构建 HMI 高保真原型与驾驶模拟环境。^{5858Automotive HMI prototyping with Unityunity.com前往参考资料 ↓在新标签页中打开}

可用性测试工具（如 Maze、UserTesting）可与原型工具对接，将可点击原型直接投放给目标用户并自动采集任务完成率、点击热区与停留时间等指标，使原型从“演示物”转变为“可测量的实验载体”。^{5959Maze — Rapid user testingmaze.co前往参考资料 ↓在新标签页中打开}

原型工具的选择通常取决于保真度需求、团队协作规模、与开发交付链路的衔接程度以及学习成本；低保真阶段常用纸质或白板工具，中高保真阶段则倾向 Figma、Axure 等支持协作与交互逻辑的工具。^{5252Prototypinginteraction-design.org前往参考资料 ↓在新标签页中打开}

随着生成式 AI 的引入，部分原型工具开始支持由自然语言描述直接生成界面草稿或可交互原型，例如 Figma 的 AI 功能与 Uizard 等工具，这一方向正在改变原型制作的起点与迭代节奏。^{6060AI in Figmafigma.com前往参考资料 ↓在新标签页中打开}

协作与交付工具在设计流程中承担的核心职能，是把界面设计、交互原型、组件与设计系统、在线评审和研发交付串成一条相互衔接的工作流，使产品经理、设计师与开发工程师围绕同一份设计资产持续迭代，而不是在多个割裂的文件与沟通渠道之间来回搬运信息。^{6262Pixso设计：功能介绍、入门教程与团队协作指南pixso.cn前往参考资料 ↓在新标签页中打开}

以 Pixso 为代表的在线产品设计协作工具，通常以浏览器在线使用为主、辅以各平台客户端，支持多人共同编辑同一文件、复用组件与样式、在文件内直接讨论修改，并集中呈现设计说明与交付信息，从而把评审与交付环节前移到设计文件本身。^{6262Pixso设计：功能介绍、入门教程与团队协作指南pixso.cn前往参考资料 ↓在新标签页中打开}

Airbnb 在改版 app 设计界面时，同步重构了设计组织流程与协作工具，目的是让分布在世界各地据点的团队能够快速、同步且高效地推进设计流程；其设计副总裁 Alex Schleifer 曾公开分享如何借助工具与系统让工程师和设计师高效协作。^{6161Airbnb 組織流程——Design 跟 Coding 的協作效益最佳化 - INSIDEinside.com.tw前往参考资料 ↓在新标签页中打开}

在跨地域团队中，协作与交付工具的价值不止于画图效率，更在于把设计决策、组件规范与交付信息沉淀为可被不同据点同步读取的共享资产，减少因时区与语言差异造成的重复沟通。^{6161Airbnb 組織流程——Design 跟 Coding 的協作效益最佳化 - INSIDEinside.com.tw前往参考资料 ↓在新标签页中打开}

设计协作工具普遍提供 AI 辅助设计能力，用于在需求梳理、原型演示到开发交付的链条中降低重复性操作，但这类能力目前更多是辅助角色，最终确认布局、交互连贯性与组件一致性仍需团队成员判断。^{6262Pixso设计：功能介绍、入门教程与团队协作指南pixso.cn前往参考资料 ↓在新标签页中打开}

设计流程中的跨部门协作长期以「交接」为核心形态：设计师完成稿件后交付给开发实现，产品、设计、开发之间以文档、原型、设计稿等离散产物为接口，每次交接都可能造成信息损耗与版本错位。^{6161Airbnb 組織流程——Design 跟 Coding 的協作效益最佳化 - INSIDEinside.com.tw前往参考资料 ↓在新标签页中打开|64642026年原型、设计与开发协作趋势分析：从割裂到一体化-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

Airbnb 在改版其 app 设计界面时，同步重整了设计组织流程与协作工具，目标是让分布在世界各地据点的团队能够快速、同步、有效率地推进设计流程；其设计副总裁 Alex Schleifer 曾公开分享如何借助工具与系统让工程师与设计师高效协作。^{6161Airbnb 組織流程——Design 跟 Coding 的協作效益最佳化 - INSIDEinside.com.tw前往参考资料 ↓在新标签页中打开}

跨部门协作的常见痛点集中在「对齐」环节：文档散落在多个平台，需求、原型、设计稿彼此独立；原型与设计已更新而开发仍对着旧稿；切图、标注、说明反复来回，沟通成本被系统性低估。^{64642026年原型、设计与开发协作趋势分析：从割裂到一体化-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

一种被讨论的应对方向是让产品、设计、开发在同一平台上工作，评论、评审与迭代都在同一个链接内完成，从而减少导出导入与截屏讨论带来的误差；其关键不在于工具本身，而在于数据与信息能否顺着角色流动起来。^{64642026年原型、设计与开发协作趋势分析：从割裂到一体化-腾讯云开发者社区-腾讯云cloud.tencent.cn前往参考资料 ↓在新标签页中打开}

有实践者指出，AI 工具虽然大幅提高了各角色的产出速度，但学科之间的「墙」并未因此改变，反而使更多内容以更快速度被「扔过墙」；要真正改变设计师与开发的协作方式，需要拆解长期沉淀的习惯、工具与组织政治。^{6363LukeW | Finally, the Handoff is Deadlukew.com前往参考资料 ↓在新标签页中打开}

对于已有多年固化流程的成熟公司而言，改变设计与开发的协作方式意味着要松动长期积累的习惯、工具与政治关系，难度显著高于从零搭建流程的新组织；后者可以在每次新建团队时重新设计协作流程，并把经验带入下一个团队。^{6363LukeW | Finally, the Handoff is Deadlukew.com前往参考资料 ↓在新标签页中打开}

在快速迭代的语境下，质量不应被当作开发末端的「打磨阶段」，而应被理解为一种贯穿发现、定义与开发全生命周期的风险管理策略；团队若在发现阶段赶工、或在构建阶段放松标准，省下的时间并不会消失，而是以返工和产品妥协的形式被推迟到下游。^{6565Quality is a Risk-Management Strategy Not a Polish Phase | Megan (Kluttz) Daily 发布的此话题相关的动态 | 领英linkedin.com前往参考资料 ↓在新标签页中打开}

维持端到端的质量标准会持续迫使团队就「质量与速度」的取舍展开艰难对话，但这种坚持恰恰是降低路线图风险、减少下游摩擦、使迭代速度转化为真实业务结果的前提。^{6565Quality is a Risk-Management Strategy Not a Polish Phase | Megan (Kluttz) Daily 发布的此话题相关的动态 | 领英linkedin.com前往参考资料 ↓在新标签页中打开}

AI 编码代理的引入正在改变迭代节奏的基准：在硅谷前沿开发场景中，已出现一名工程师同时指挥多个 AI 代理进行全天候代码产出与即时部署的工作方式，这使得以两周为单位的「探索与定义」周期相对变慢。^{6666「軟體設計流程已死！」Anthropic設計總監：拒用Claude Code的主管，決策將嚴重脫節bnext.com.tw前往参考资料 ↓在新标签页中打开}

AI 工具缩短了产出「精致设计物」所需的时间，这使质量讨论的重心从「能否做出」转向「是否值得做、风险是否可控」，即速度提升并不自动消解质量与速度之间的张力。^{6565Quality is a Risk-Management Strategy Not a Polish Phase | Megan (Kluttz) Daily 发布的此话题相关的动态 | 领英linkedin.com前往参考资料 ↓在新标签页中打开}

生成式人工智能（Generative AI）已被引入设计流程的早期阶段，用于概念发散与方案草图生成；2023 年前后的多篇人机交互（HCI）研究指出，设计师对这类工具的主要期待是「扩大探索空间」而非「替代决策」。^{6767Generative AI and the Future of Design Workdl.acm.org前往参考资料 ↓在新标签页中打开}

在工程与产品设计流程中，AI 辅助的典型落点是需求与规格的自动抽取、CAD 参数化方案的生成式探索、仿真与拓扑优化，以及设计评审前的缺陷预筛；这些环节的共同特征是「候选方案多、评价标准可形式化」。^{6868AI-Assisted Design: A Survey of Generative Methods in Engineering Designasmedigitalcollection.asme.org前往参考资料 ↓在新标签页中打开}

AI 生成的设计候选会引入新的评审负担：设计师需要判断输出是否可用、是否侵犯他人知识产权、是否存在训练数据带来的偏见，因此「人在回路」（human-in-the-loop）的审核步骤在采用 AI 的流程中被普遍保留甚至加强。^{6767Generative AI and the Future of Design Workdl.acm.org前往参考资料 ↓在新标签页中打开|6969The Ethics of Generative AI in Design Practicedirect.mit.edu前往参考资料 ↓在新标签页中打开}

在智能座舱等软硬件一体的产品设计中，AI 辅助正从「单点工具」走向「流程内嵌」：语音与多模态交互的原型生成、场景化用例的自动扩写、以及基于真实驾驶数据的可用性预评估，被纳入从概念到验证的迭代回路。^{6868AI-Assisted Design: A Survey of Generative Methods in Engineering Designasmedigitalcollection.asme.org前往参考资料 ↓在新标签页中打开}

AI 辅助设计带来的流程治理问题包括：生成内容的可追溯性与版本管理、训练数据与输出物的合规审查、以及团队内「谁会用好提示」造成的能力落差；这些被视为当前设计流程落地 AI 的主要组织性障碍。^{6969The Ethics of Generative AI in Design Practicedirect.mit.edu前往参考资料 ↓在新标签页中打开}