产品设计师开始交付代码以后：设计角色正在如何重写
一位产品设计师在调研里这样描述自己现在的工作：
我对自己能直接提交 PR 这件事感到震惊……很多时候我可以自己合并自己的 PR。用户的问题，我在讨论的时候就修了，会议还没结束就上线了。
过去，产品设计师通常交付设计稿，再由工程师把它变成产品。现在，AI 编码工具让越来越多产品设计师越过这道交接线：自己做可运行原型、修改前端，甚至直接提交生产代码。
本文所说的“产品设计师”，主要指数字产品研发团队中的 UI、UX 和 UE 设计师，不包括品牌、平面或工业设计师。为方便阅读，下文简称“设计师”。
问题不再是“产品设计师该不该写代码”，而是： 当产品设计师开始交付代码，这个角色会变成什么？
一、产品设计师正在进入代码
本文主要依据两份大样本调研。
第一份是 Foundation Capital 与 Designer Fund 联合发布的《State of AI in Design 2026》，调研了 60 多个国家的 900 名设计师，并访谈了 Stripe、Linear、Shopify、Anthropic 等公司的设计负责人。需要说明的是，这份样本同时包含产品设计师和品牌设计师；本文只采用其中与数字产品、原型和代码交付直接相关的发现。
第二份是 Figma 的《2026 AI 报告》，基于三年累计 8,403 份问卷和 639 次深度访谈，覆盖设计师、开发者和产品经理。
两份报告都指向同一个变化：设计师的工作正在从“提出方案”延伸到“亲手实现”。
| 指标 | 数据 | 来源 |
|---|---|---|
| 把 AI 生成的代码推上生产的受访设计师 | 50%（早期创业公司 68%，上市公司 33%） | Foundation Capital |
| 参与开发工作的设计师 | 41%，一年内翻倍 | Figma |
| 自认为在做更多产品和研发工作的设计师 | 65% | Foundation Capital |
| 公司期望设计师交付可运行原型 | 43%，另有 36% 说项目直接从原型开始 | Foundation Capital |
| 感到工作期望正在上升的设计师 | 73% | Foundation Capital |
| 已正式调整制度的管理者 | 28%（调整绩效或招聘的只有 13%） | Foundation Capital |
最值得注意的是，在 Foundation Capital 同时包含产品和品牌设计师的样本中，已经交付代码的人达到 50%，自认为“设计工程师”的却只有 20%。这说明写代码不再只是少数技术型设计师的专长，也正在进入普通产品设计师的工具箱。
二、变化从交付物开始
设计师角色的变化，首先体现在“最后交付什么”。
过去，设计师交付静态稿。页面能否在真实数据、异常状态和不同屏幕下工作，通常要等开发完成后才知道。设计师在验收时发现问题，再开工单请工程师修改。
现在，设计师可以直接做可运行原型，在真实代码和数据中验证用户流程。Samsara 的团队甚至把原型建在实际产品环境里，让设计师直接观察设计如何适应不同账户和数据边界。文案、间距、组件替换这类问题，也可以由设计师自己提交修改。
Anthropic 的设计负责人 Joel Lewenstein 说：
代码一直是软件的黏土。把一个可运行的原型交给工程师，就等于说：“看，这不是一个抽象想法，我没有含糊任何细节。”原型里没法糊弄。
设计师的交付物正在经历三次升级：从描述界面，到演示体验，再到参与交付真正的产品。
三、从方案提供者走向产品构建者
交付物变了，设计师的工作也随之改变。
第一，设计师离最终体验更近了。过去，设计意图经过设计稿、标注和开发实现，落地时难免损失。现在，设计师可以直接修正动效、间距和交互细节，不必把每个问题重新翻译成工单。
第二，设计师更早面对真实约束。静态稿可以绕开加载、权限、空状态和脏数据，可运行原型不行。开始写代码以后，设计师会更早发现一个方案是否真的成立。
第三，设计师的责任从“稿子画完”延伸到“体验是否落地”。Foundation Capital 的报告提到，一些设计师开始端到端负责工单，而不是完成设计环节后就退出。设计验收也不再只是指出问题，而是直接修复问题。
这并不意味着设计师要变成工程师。Watershed 的设计负责人强调，设计师可以生成和修改代码，但并不负责长期维护，也不用承担线上值班。设计师扩张的是对最终体验的控制范围，而不是接管全部工程责任。
四、会写代码以后，设计师仍要守住什么
代码扩大了设计师的执行能力，却没有改变设计工作的核心。
调研中约 80% 的设计师仍然更依赖自己的判断来把握质量、视觉细节和创意方向；60% 到 70% 的设计师认为，在理解用户、定义问题、讲故事和系统思考上，人类判断仍然更重要。
Linear 的 CEO Karri Saarinen 提醒说：“设计难的部分很少是生成形式，而是把问题理解到足以知道某个东西应不应该存在、应该怎样存在。”
因此，设计师真正需要守住的不是画图这项动作，而是四件事。
问题判断：先确定用户真正遇到了什么，再决定是否值得做。AI 可以迅速给出方案，却无法替团队决定哪个问题最重要。
体验取舍：可用、易用、品牌一致和商业目标经常互相冲突。工具能生成选项，设计师要解释为什么选择其中一个。
系统一致性：当产出速度越来越快，设计系统、组件和规则更重要。设计师不仅要做好一个页面，还要防止每次生成都发明新的模式。
最终质量：“代码能运行”不代表体验已经完成。异常状态、可访问性、文案、动效和边缘场景，仍然需要设计师逐项检查。
代码是新的设计媒介，不是设计判断的替代品。
五、设计师会分化成哪些方向
产品设计师不会全部变成同一种“全栈设计师”。调研里已经出现了三种方向。
一类是 设计构建者。他们深入代码和生产环境，做原型、提交前端 PR，对功能从想法到上线承担更完整的责任。设计工程师是这个方向最明确的岗位名称。
一类是 设计系统架构者。他们搭建设计系统、组件库和 AI 工作流，让更多人能在统一标准下完成设计。AirOps 把这类设计师称为“Agent 船长”：AI 负责重复生产，设计师负责规则、方向和审查。
还有一类是 设计工匠。他们继续在视觉、交互、品牌或动效上保持深度。生成变便宜以后，普通执行会贬值，但顶尖工艺并不会。调研中只有 5% 的管理者降低了对执行品质的要求。
这三种方向并不互斥。一个设计师可以以其中一个为主，同时具备另外两种能力。真正过时的不是某个设计岗位，而是“交完设计稿，工作就结束了”的角色想象。
六、组织需要为设计师补上什么
设计师的工作已经改变，组织制度却明显落后。73% 的设计师感到期望在上升，只有 28% 的管理者做了正式调整，更新绩效或招聘标准的更只有 13%。
最差的做法，是一边要求设计师交付更多，一边不给学习时间、开发环境和协作支持，最后再用“用了多少 AI”评价绩效。
调研中的实践给出了更合理的路径。DoorDash 先用两周帮助设计师搭建开发环境，再用两天黑客松让团队提交了 200 个 PR；所有设计师提交的代码仍然遵守与工程师相同的生产质量标准。Watershed 则鼓励每位设计师找一位“工程伙伴”，在环境故障或 PR 审查时提供帮助。
设计师进入代码，不是买一个工具就能完成的。组织至少需要提供学习时间、可用的开发环境、明确的代码审查规则，以及可以求助的工程伙伴。
写在最后
Figma 的调研中，90% 的受访者认为设计至少和 AI 出现前一样重要，近六成认为设计更重要了。Foundation Capital 的调研中，60% 的设计管理者计划维持或扩大设计团队。
产品设计师不会因为 AI 会生成界面、会写代码而消失，但“只交付设计稿”的产品设计师会受到越来越大挑战。
未来产品设计师的价值，不只体现在画出了什么，还体现在能否理解正确的问题、做出清晰的取舍、把体验真正交付出去，并把判断沉淀成可以复用的系统。
真正值得继续观察的，不是设计师会不会写代码，而是当代码成为新的设计媒介以后，企业会如何重新界定产品设计师的交付物、责任边界和评价标准。
本文部分内容由 AI 辅助生成，经人工审校和补充后发布。
参考资料
- Foundation Capital & Designer Fund. State of AI in Design 2026: Craft. 2026. https://stateofaidesign.com/chapters/craft
- Foundation Capital & Designer Fund. State of AI in Design 2026: Teams. 2026. https://stateofaidesign.com/chapters/teams
- Foundation Capital. “How AI is reshaping design in tech.” 2026. https://foundationcapital.com/ideas/how-ai-is-reshaping-design-in-tech
- Madeline Stafford, Shane Johnston. “Figma's 2026 AI report: Can AI help us collaborate better?” Figma Blog, 2026-06-24. https://www.figma.com/blog/2026-ai-report/