实际业务场景中，设计师到底如何与 AI 人机协作
“设计师掌控主体判断并保持独立思想，与AI协作不以丢失作者性为代价”
*本文中案例均来自多个实际合作客户项目，部分内容由于NDA限制所以打码处理。文章内容手搓，无AI辅助创作或优化，仅配图内容部分采用AI辅助。
张天任 (Chris)
AI 确实极大地降低了设计的门槛。一个小小的灵感，通过几十上百次的对话，任何人似乎都能“生成”一个像模像样的产品。但这引出了一个必须正视的问题：如果创作在极早期就进入了“可观察状态”，这个产品究竟是基于你的思想，还是仅仅基于你的语言？AI 工具是否正在悄悄剥离我们的独立思考，让我们仅仅成为它的“提示词翻译官”？你在和AI驾驶一辆“汽车”时，你到底是主驾驶还是副驾驶？
在 2026 年的今天，这些看似哲学的问题在真实的业务流中正引发切实的阵痛。在实际项目中，我观察到一种普遍的“作者性丢失”陷阱：大家惊叹于 AI 的高效，过早地把一切抛给工具。当 AI 瞬间吐出完整度极高、甚至可以直接运行的 Demo 时，设计师很容易产生“方向已定”的错觉，从而削弱了对当前设计阶段和核心目标的底层判断。这种过早的高细节demo，导致当业务方提出合理修改时，设计师反而会比过去面对中低保真草图时，产生更强烈的沉没成本焦虑与情绪抵触。
真正的 AI 协作，不应以丢失设计的“作者性”为代价。作为设计师，我们需要掌控主体判断，让 AI 成为执行副驾，而不是外包我们的思考。以下是我在多个复杂 B 端与 C 端项目中，已经经过反复验证并沉淀的 AI 协作工作流。涵盖 A体验走查与优化，B业务需求理解与设计构建，C设计交付三个核心设计师实用工作场景。
坐在电脑前悠闲的等AI干活确实是十分理想的工作方式，但是“你”作为企业雇佣者而不是AI。该如何利用AI工具的便利，同时又行使被雇佣者-设计师角色的责任和价值呢？
Scenario A. 体验走查与优化策略
🌞理想
你：学院派设计理论给AI应用，找出问题后直接给业务方就结束
通过设计理论一步步去找页面设计的茬；或者在今天，部分设计师同事以为把几十个页面截图扔给大模型，让它“指出体验问题”，就能直接拿来当结论，把找出的问题全部抛给业务同事，并指望他们会欣然排期。
🫣挑战
🌚现实
你的其他角色同事：除了“客观”数据，其他都是“主观”推断
事实上，业务方几乎一定会将纯粹的“体验可用性瑕疵”放在第二优先级，因为他们紧盯的是转化、留存和成本。尤其在缺乏业务视角的支撑下，纯设计视角的走查在别人眼里容易变成“主观审美挑刺”；AI做体验走查会丢失交互链路的理解，依赖设计师自己截图并整理核心用户链路。
经典理论（如体验五要素、启发式评估）在此时的作用，不是用来教我们“怎么做设计”的，而是用来建立跨部门沟通的共识。设计师需要在海量且破碎的用户反馈 (VoC)、错综复杂的现有页面链路，以及高度凝练的业务诉求之间反复横跳。如何用有限的精力，将“业务重点”、“用户原声”和“界面触点”严密地绑定在这个共识框架上？如果靠人肉去整理这种映射，不仅耗时，且极易在细节中丢失全局视野。
💻协作策略：AI 作为数据降维与交叉映射工具
不让 AI 帮助“下结论”，而是掌控评估框架的选择权，让 AI 去承担枯燥的高并发信息清洗与交叉比对工作，为我的最终判断提供算力支撑。下面经验分享仅针对通用型操作思路，长期使用时必须依据思路考虑制作skill。
操作一：锚定业务基准 (Contextualization)
协作思路： 不急着看设计图，先将前期的业务规划文档或会议纪要等原始材料投喂给 AI，确立整个走查的北极星。同时，铆钉走查范围及核心用户链路定义。
目的：建立走查整体背景与现状意识，为大块走查拆分成AI可轻松执行的小任务。
Prompt 关键词与引导逻辑： 提炼 Top 3 核心业务诉求、结构化映射至体验五要素中、总结核心用户路径任务。
*案例来自与港交所、联想海外、中国某头部无人机与云台相机公司的设计项目
操作二：多模态原声与界面的交叉印证 (Triangulation Mapping)
协作思路： 按照定义好的核心用户链路，再拆分为几个具体的交互行为，并将数百条脱敏的客诉文本，连同对应模块的 UI 长图（甚至是交互链路图）一同输入，进行多模态的交叉诊断。同时记得走查内容输出的框架内容模板。
目的：了解用户在哪个特定触点，因为违背了哪条原则，产生了什么抱怨，并了解针对这一问题下行业中的best practice是什么。
Prompt 关键词与引导逻辑： 用户原声聚类 (VoC Clustering)、精准绑定 UI 视觉触点、引用尼尔森可用性原则进行理论解释、业内外是如何通过设计处理类似问题的。
*案例来自与中国某头部无人机与云台相机公司的设计项目
操作三：收拢主体判断，输出策略定调 (Synthesis & Pitching)
协作思路： 当 AI 整理好一张逻辑严密的“映射表”后，是设计师行使“作者性”的时刻。需要基于这些客观证据链，推演出直击业务痛点的全局设计策略。定义判断维度后，带着这份报告去沟通，会上同产品、开发一同根据判断维度为体验问题进行优先级排序。这样兜售的就不再是主观的“我觉得不好看”，而是基于数据的客观逻辑推导，以及可实施落地的体验优化指导指南。
✨Bonus Point：整体性的体验走查结束并定义好高优先级优化项后，可以vibe coding一个TO-BE demo，给其他同事直观感受未来优化基础方向，也更方便内外部同步
*案例来自与中国某头部无人机与云台相机公司的设计项目
Scenario B. 业务需求理解与想法构建
🌞理想
你：用PM/BA给的完美PRD做设计，美滋滋
需求下发时，伴随着一份逻辑严密、详尽无比的 PRD 文档。你只需安静戴上耳机，慢慢将文字“翻译”成界面。并且因为需求很明确了，所以设计师在确定初步设计方向时画几张低保真，业务方就能瞬间理解设计意图并做出方向抉择。
操作一：访谈提纲的定向生成与破冰 (Targeted Questioning Prep)
协作思路： 绝不要空着脑袋去参加业务访谈。拿着模糊的一句话需求，可利用 AI 快速拓展提问维度，准备结构化的访谈提纲。（也适用于对产品实际用户的访谈）
目的：确保在有限的沟通时间里掌握主动权，切中商业与体验要害，能深入了解需求或优化项背后。
Prompt 关键词与引导逻辑： 拆解极简业务诉求、探究商业价值底线 (Business Value)、定义成功指标 (Success Metrics)、生成 5高优先级的业务访谈追问 (Follow-up Questions) 。
*案例来自联劝公益产品设计咨询项目
操作三：多方向 Ideation 与可交互 Demo 生成 (Interactive Prototyping)
协作思路：拿着梳理好的用户故事，和即将进行设计优化的现有页面，让 AI (如 Claude Code/Gemini等) 直接生成几个不同设计方向的 HTML/JS 单文件。只追求“核心链路可点击、可跳转”，页面可保持灰度。
目的：快速生成初期想法，让业务同事了解设计是否match优化目标，让开发同事提前了解技术实现性且能并行技术设计。
Prompt 关键词与引导逻辑： 基于核心链路探索 3 种不同的交互、使用 HTML生成单页面可点击 Demo、仅保留中低保真灰度样式，拒绝视觉干扰。
*案例来自与中国某头部无人机与云台相机公司的设计项目
✨Bonus Point：代码级可行性验证，粉碎“实现不了”的借口 (Code-level Validation)
捍卫作者性的绝佳手段。当开发以“技术实现成本太高”为由想要砍掉核心交互时，不轻易妥协。必要时可以直接在 Cursor 中利用 AI 辅助，跑出基础的 SwiftUI 或前端组件代码进行本地验证。拿着能在本地模拟器跑通的代码片段去交涉，身份从“提需求的设计师”变成了“探讨解法的设计工程师”。用工程实力确立话语权，绝不让核心思想在执行层被廉价折损。
🌚现实
你：接收到的都是需求碎片，靠自己拼凑却还经常返工
业务方抛出的往往是模糊的“一句话需求”，或者直接告诉你怎么改。这样真正的诉求就会被隐藏，你必须通过访谈去挖掘。致命的是，当访谈结束、设计师拿着几张静态的线框图去提案时，非设计背景的业务方很难脑补出真实的交互链路。这种缺乏体感的沟通，极易导致前期方向误判，最终在交付高保真 UI 时面临推翻重来的风险。
协作策略：用AI “深水探雷”实际需求，动态提案设计方向
不让 AI 在 Figma 里画“死”的图，而是将其作为“提问智囊”和“原型引擎”，改变早期的需求剖析与提案媒介。
Scenario C. 交付设计准备
🌞理想
你：画个Happy Path，剩下就靠交互描述及PM/BA的PRD细节
交付（Handoff）就是把一个完成的高保真 Figma 链接发给研发，研发就能像照镜子一样，一比一完美还原出你的设计。设计里面交互逻辑情况没覆盖到也没关系，有PM/BA的PRD兜底
操作二：访谈原声的意图萃取与降噪 (Intent Distillation)
协作思路： 访谈结束后，与产品协作，将录音转写文本喂给 AI，剔除闲聊和技术实现细节的杂音，提炼出清晰的业务意图，还原出 1-2 条核心体验链路或用户故事。
目的：全量访谈内容的提纯降噪，用直接的用户故事来定义交互行为。
Prompt 关键词与引导逻辑： 剥离杂音话术、结构化归纳：What / Why / Expected Outcomes、输出纯粹的用户故事 (User Story)
✨Bonus Point：可以基于动态 Demo 的边界测试与方向提案 (Stress Testing & Pitching)
有了可点击的 Demo，可以先让 AI 扮演“找茬者”对着代码逻辑进行压力测试。同时客观了解各设计方向优缺点及设计师视角的方向性推荐。再带着修复了漏洞的 .html文件去提案。业务方在浏览器里实际点击、体验不同的方向，理解效率也更高。如果有微调想法，也可以直接现场快速修改调整。对齐理解是协作沟通最重要的一环。
🌚现实
你的同事：“另一种情况的设计图呢？”“辛苦补个图吧”
设计流中最后、也最隐蔽的“过早高保真陷阱”——往往用视觉的高保真，掩盖了逻辑的低保真。静态的精美界面在复杂的真实代码环境中极其脆弱，如果没有穷举各种状态，开发在遇到接口超时、极限断点、异常溢出时，只能靠时不时来“骚扰”你或使用系统默认样式兜底。当开发被迫替你决定这些微观交互时，你最初的设计思想完整性已经被截断，产品设计的“作者性”在代码落地的那一刻发生了流失。
🫣挑战
面对模模糊糊的需求或者直白的修改点，仿佛业务同事已经把你该做的前期设计思考都完成了。果真如此吗？你需要深挖模糊需求背后的真实需求，产出有设计思考的优化点。如何在去访谈前做好充足的弹药准备？如何在极短的时间内探明业务真实意图？在不投入大量精力打磨视觉的前提下，如何用最高效的媒介构建出几个不同的设计方向，并让业务方拥有最真实的体感，从而做出准确的判断？
🫣挑战
撰写长篇大论的散文式交互说明反人性，且研发根本不爱看。如何协同PM/BA，在设计视角补齐前端开发真正需要的全套“状态机 (State Machine)”？如何将主观的设计意图，翻译为研发无法拒绝的约束语言，从而把握体验控制权？
协作策略：用AI 做工程翻译官与交互逻辑补全大师
操作二：设计图完善与标注，消除理解损耗 (Developer-Friendly Specs)
协作思路： 不沦为给PM配prd图片的小透明，主动图文并茂的标注分支逻辑或交互动效，必要时用AI做出原型demo，并让 AI 标注翻译为开发熟悉的结构化语言，用契约代替猜测。
目的：保持设计师角色主体性，让开发更喜欢看你的直观设计、听你的解释，而不是听PM/BA倾向于业务细节的“方案”。
Prompt 关键词与引导逻辑： 将设计意图转化为 Gherkin 语法 (Given/When/Then)、精细定义微交互参数 (如：贝塞尔曲线缓动值、Spring 弹簧动效的质量与阻尼)
放弃对视觉细节的过度迷恋，利用 AI 对抗人工梳理逻辑的疲惫感。不让 AI 替我做决策，而是让它将脑子里的动态思想，翻译为严密的开发约束。
操作一：逻辑高保真，补全全状态矩阵 (State Machine Generation)
协作思路： 拿着 Figma 里的 Happy Path 界面，让 AI 帮助“破坏”。利用 AI 擅长的发散穷举能力，强制拉出该组件或交互在实际运行中必须面对的前端异常状态，逼迫自己补齐逻辑。
目的：确保各状态没有考虑疏忽或遗漏，尤其注意新页面或业务组件展示的各种状态 (空状态、表单填满状态、分页、编辑态等)。
Prompt 关键词与引导逻辑： 前端架构师视角、穷举该组件的状态机、推演异常流、列出状态操作反馈/极值溢出/加载等边界约束条件。
结语：在 AI 时代，重新定义“设计”的边界
回望这套涵盖了策略走查、需求推演到工程交付的 AI 工作流，我想回答在文章开头提出的那个问题：在这个人人都能用 AI 生成界面的时代，设计师的价值到底还剩什么？
当枯燥的执行、繁琐的文档和机械的推演都可以被 AI 代劳时，设计的核心终于可以剥离掉“绘图员”的属性，回归到它的本质——一种定义问题、构建系统、并在混沌中做出主观判断的能力。
我们警惕“过早高保真”，因为我们知道视觉的完美掩盖不了逻辑的漏洞；我们用代码作为草图和沟通媒介，因为我们明白真实世界的体感胜过一切静态的幻象；我们利用 AI 翻译前端状态机，是因为我们要用工程的严谨去捍卫体验落地的尊严。
在这个工作流中，AI 是我的“外脑”和“执行副驾”，但那个提出正确问题、确立核心逻辑、并在“主驾驶”席位的角色，始终是我自己。
掌控主体判断，不以丢失作者性为代价。这不仅仅是应对 AI 冲击的策略，更是体验设计师在未来复杂商业语境下，最核心的不可替代性。