"于是我熬了两晚，把界面搭出来了，自己觉得还挺 OK ，昨天兴冲冲拿去给产品看" 这中间没沟通么? 沟通很重要的啊, 尤其是那种不明确的需求.

你们 UI 设计呢？

这种就属于沙雕产品，让他给具体的设计稿就完了。

现在都 AI 时代了，为啥沟通，流程，跟文档还是那么传统？

UI 出 UI 图和产品达成一致后，UE 出交互图，再和产品达成一致，前端负责将 UI 图实现。后端负责实现产品的功能。只要 UI 和 UE 确定了基本上没啥争吵的。

要五彩斑斓的黑，找 UI 去。

所以提前设计好很重要，设计先多做几版，确定好了用哪个再开始写代码。改设计图还是比改代码方便写。不过一般程序员不负责 UX 的活，每人能力和审美都有差异，得取长补短。他不满意你听着就行了，让他给下一版改进意见，如果这个按钮没那么重要就下次再改呗。当然这个 UX 具体要谁负责最好确定一下，别每次都为了这个反复。

写程序本身就需要严谨固定的描述，对前端来说自然是 UI 设计图。 如果产品不是你的上级，那这就是一个话语权的问题，谁的话语权大听谁的。 你这种一般情况下就三个解决方案，一是找出 UI 设计图，让产品和 UI 去研究到底什么样子，你还原设计图即可；要不就是界面长什么你说了算；要不就是直接说做不了；当然还有一个方案就是认可产品话语权，他怎么说你就怎么改，就拉着他在你的工位上，他现场描述你现场改

不出高保？ 干啥呢

1.产品对产品负责 2.技术对技术负责 2.你做不不是你的职责，所以不用 pua 自己，也不用生气，你可以换公司，或者从现在开始只做好自己的技术就行了，其他和你无关的，兄弟