老板看完几个AI演示Demo，转头就期待设计师变成全栈，一个人扛下整个项目。做不成，责任归到一句「没把AI用好」。这个场景，正在不少团队里反复上演。 问题出在哪？演示里看见的结果，和工作里需要负责的结果，中间还隔着非常多要做的事情。 演示那一步，和交付那一步 老板看到的是AI快速出图的那一步。但真实项目里，还有需求对齐、规则统一、检查返工和交接。这些环节一个都不能少。 作者以OS设计为例：这类项目强调整体性与一致性，AI只能处理单独页面。链路一长，就容易出问题。AI目前更适合配图、发散和推导，一旦任务链条拉长，它的短板就暴露出来。 把演示结果等同于交付结果，等于把中间那一大段工作直接抹掉了。 责任全归员工，反馈就断了 如果每个AI做不好的地方，最后都被归为「你不会用」，下次再遇到问题，就没人愿意认真反馈。 作者强调，指出AI哪里做不好，本身就是有价值的反馈。做成了，说明AI厉害；做不成，说明你不行——这种归因方式，摧毁的是团队里说真话的意愿。 AI对设计工作的影响，被作者比作水位不断上涨的过程：先漫过相对独立、难度不高的设计任务，再逐渐影响更深、更复杂的工作。设计师的压力真实存在，不该被一句轻飘飘的「拥抱AI」打发。 提效这笔账，要算到做完 作者给出的建议很具体：挑一个熟悉的真实需求，先对齐完成标准，再分别记录两段耗时。 AI生成初稿的耗时 修改、检查和交接的耗时 模型调用成本 人工返工时间 不能只挑最漂亮的那一步算提效。把这几项都摆上桌面，具体问题才有讨论的基础。 补齐流程的人，不该被当成没用 如果一个项目最终能交付，靠的是设计师把流程补齐、把错误改掉、把前后规则对上，那么这些投入就应该被承认。 作者的原话是：请别一边靠他们把事情做完，一边觉得他们已经没用了，很可能最后花的token不比工资低。 提效这笔账，得算到把事情真正做完。先对齐完成标准，再记录返工与检查耗时，让问题回到可讨论的层面，而不是停在「你不会用AI」这句结论上。 特别