标签 Figma 下的文章

这两天跟 CaliRather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具,但是聊天不是深度思考,有一些东西我没有讲透讲好,所以,我需要把我更多更完整更结构化的想法形成文字。(注:聊天聊地比较详细,本文只是想表达我的主要想法)

目录

国内外的企业 IM 的本质差别

国内企业级在线交流工具主要有:企业微信、钉钉、飞书,国外的则是:Slack、Discord这两大IM工具,你会发现,他们有很多不一样的东西,其中有两个最大的不同,一个是企业管理,一个是企业文化。

企业管理

Slack/Discrod 主要是通过建 Channel ,而国内的IM则主要是拉群。你可能会说,这不是一样的吗?其实是不一样的,很明显,Channel 的属性是相对持久的,而群的属性则是临时的,前者是可以是部门,可以是团队,可以是项目,可以是产品,可以是某种长期存在的职能(如:技术分享),而拉群则是相对来说临时起意的,有时候,同样的人群能被重复地拉出好几次,因为之前临时起意的事做完了,所以群就被人所遗忘了,后面再有事就再来。很明显,Channel 这种方式明显是有管理的属性的,而拉群则是没有管理的

所以,在国内这种作坊式,野蛮粗放式的管理风格下,他们需要的就是想起一出是一出的 IM 工具,所以,拉群就是他们的工作习惯,因为没有科学的管理,所以没有章法,所以,他们不需要把工作内的信息结构化的工具。而国外则不然,国外的管理是精细化的,国外的公司还在重度使用 Email 的通讯方式,而 Email 是天生会给一个主题时行归类,而且 Email 天生不是碎片信息,所以,国外的 IM 需要跟 Email 竞争,因为像 Email 那样给邮件分类,把信息聚合在一个主题下的方式就能在 IM 上找到相关的影子。Channel 就是一个信息分类,相当于邮件分类,Slack 的 回复区和 Discord 的子区就像是把同一个主题信息时行聚合的功能。这明显是懂管理的人做的,而国内的拉群一看就是不懂管理的人干的,或者说是就是满足这些不懂管理的人的需求的。

企业文化

团队协作和团队工作最大的基石是信任,如果有了信任,没有工具都会很爽,如果没有信任,什么工具都没用。信任是一种企业文化,这种文化不仅包括同级间的,还包括上下级间的。但是,因为国内的管理跟不上,所以,就导致了各种不信任的文化,而需要在这里不信任的文化中进行协同工作,国内的 IM 软件就会开发出如下在国外的 IM 中完全没有的功能:

  • 监控员工。获取员工的工作时间以及工作位置。
  • 有详细的已读标注。这样会给对方要回复的压力。
  •  发出的信息不能修改,不能删除,非常有限地可撤回

而国外的 IM 则是,发出的信息可以修改/删除,没有已读标准,也不会监控员工。这种时候,我总是会对工作在这种不信任文化中人感到可怜……如果大家需要靠逼迫的方式把对方拉来跟我一起协作,我们还工作个什么劲啊。

小结

所以,我们可以看到,畸形的企业管理和企业文化下,就会导致畸形的协同工具。最令人感到悲哀的是,有好多同学还觉得国内的钉钉非常之好,殊不知,你之所以感觉好用,是因为你所在的环境是如此的不堪。你看,人到了不同的环境就会有不同的认识,所以,找一个好一些的环境对一个人的成长有多重要

给一些新入行的人的建议就是,一个环境对一个人的认知会有非常大的影响,找一个好的环境是非常重要,如果不知道什么 环境是好的,那就先从不使用钉钉为工作协同软件的公司开始吧……

什么是好的协同工具

我们从上面可以得到,协同的前提条件是你需要有一个基于信任的企业文化,还需要有有结构化思维的科学的管理思维。没有这两个东西,给你的团队再多的工具都不可能有真正好有协同的,大家就是装模作样罢了。

假设我们的管理和文化都没有问题,那下面我们来谈谈协同工具的事。

我个人觉得 IM 这种工具包括会议都不是一种好的协同工具,因为这些工具都无法把信息做到真正的结构化和准确化,用 IM 或是开会上的信息大多都是碎片化严重,而且没有经过深度思考或是准备的,基本都是即兴出来的东西,不靠谱的概率非常大。

找人交流和开会不是有个话题就好的,还需要一个可以讨论的“议案”。在 Amazon 里开会,会前,组织方会把要讨论的方案打印出来给大家看,这个方案是深思过的,是验证过的,是有数据和证据或是引用支撑的,会议开始后,10 -15分钟是没有人说话的,大家都在看文档,然后就开始直接讨论或发表意见,支持还是不支持,还是有条件支持……会议效率就会很高。

但是这个议案其实是可以由大家一起来完成的,所以,连打印或是开会都不需要。试想一下,使用像 Google Doc 这样的协同文档工具,把大家拉到同一个文档里直接创作,不香吗?我在前段时间,在公网上组织大家来帮我完成一个《非常时期的囤货手册》,这篇文章的形成有数百个网友的加持,而我就是在做一个主编的工作,这种工作是 IM 工具无法完成的事。与之类似的协同工具还有大家一起写代码的 Github,大家一起做设计的 Figma……这样创作类的协同工具非常多。另外,好多这些工具都能实时展示别人的创作过程,这个简直是太爽了,你可以通过观看他人创作过程,学习到很多他人的思路和想法,这个在没有协同工具的时代是很难想像的。

好的协同工具是可以互相促进互相激励的,就像一个足球队一样,当你看到你的队友在勇敢地争抢,拼命地奔跑,你也会被感染到的。

所以,好的协同就是能够跟一帮志同道合,有共同目标,有想法,有能力的人一起做个什么事所以,在我心中我最喜欢的协同工具从来都是创作类的,不是管理类的,更不是聊天类的。管理和聊天的协同软件会让你产生一种有产出的假象,但其实不同,这种工具无论做的有多好,都是支持性的工具,不是产出类的工具,不会提升生产力的。

另外,在创作类的协同工具上如果有一些智能小帮手,如:Github 发布的 Copilot。那简直是让人爽翻天了,所以,真正能提升生产力的工具都是在内容上帮得到你的。

结束语

我其实并不喜欢今天所有的 IM 工具,因为我觉得信息不是结构化的,信息是有因果关系和上下文的,是结构化的,是多维度的,不是今天这种线性的方式,我们想像一下“脑图”或是知识图,或是 wikipedia 的网关的关联,我们可能就能想像得到一个更好的 IM 应该是什么 样的……

协同工作的想像空间实在是太大了,我觉得所有的桌面端的软件都会被协作版的重写,虽然,这种协作软件需要有网络的加持,但是协作软件的魅力和诱惑力实在的太大了,让人无法不从……

未来的企业,那些管理类的工具一定会被边缘化的,聊天类的会被打成一个通知中心,而创作类的会大放异彩,让大家直接在要干的事上进行沟通、交互和分享。

作者:桑伟杰

在这里插入图片描述

一、背景

当前在传统设计环节,设计师与研发之间存在大量的关于样式等视觉层的理解偏差,从而会出现大量的重复且无效的细节像素调整工作,由于项目时间紧、细节多设计走查环节会给各方角色诸多额外负担,在AI涌现后设计师尝试使用AI\_Code直接还原设计稿件,并且从传统交付静态界面设计图片转为交付可运行的实现方案,但在多数团队的认知里,AI\_Code仍停留在“氛围编程”阶段:能写出代码,但不符合框架规范,改动越多问题越多。通过不断摸索总结出一套稳定可用的 Design to Code (D2C) 解法:设计师借助 AI - IDE工具以及设计工具,通过MCP打通设计数据与研发数据,实现将设计稿直接转译为符合开发规范、可上线的前端代码,极大缩短交付周期。

D2C核心效果:设计师第一次拥有了对实现效果的“直接控制权”工程师从繁琐的像素级样式修改中解放出来团队整体迭代速度大幅提升

在这里插入图片描述

传统链路VSD2C链路

二、效果展示

案例1:PC端\_WMS6.0工艺配置

通过D2C流程从【组件生成】→【页面生成】,完成PC端工艺流程配置功能代码输出,实现了卡片拖拽、卡片状态自动变更、放置位置判断等核心功能;实现项目完整交付在测试环境中可直接运行,研发无需对前端代码进行修改,D2C代码输出总耗时0.5人/日,项目整体效率提升26%

在这里插入图片描述

WMS6.0\_Vue2.0实现效果

案例2:移动端\_PDA上架到容器

通过D2C流程链接设计数据与研发数据,【直接调用研发组件库代码】,按照代码仓库标准代码输出规范的前端页面,实现多页面跳转,逻辑判断,查询等核心功能,达到像素级还原并符合团队规范。D2C代码输出总耗时0.5人/日,项目整体效率提升50%

在这里插入图片描述

PDA\_Flutter实现效果

三、设计思维转变

D2C 并非“让设计师写代码”,而是促使设计师提升工程化思维:使设计师从传统的设计界面转向当前的设计容器,从而更好的让AI能够读懂设计数据实现D2C流程



传统设计思维 ➔ 工程化思维

传统设计思维:

步骤:1.设计全部视觉元素 ➔ 2.在页面进行元素相对位置的排布 ➔ 3.完成设计内容的产出

特点:元素之间仅包含相对关系没有结构层的动态属性,与页面实现的框架不一致

工程化思维:

步骤:1.设计组织分层关系 ➔ 2.设计分层容器布局规则 ➔ 3.设计容器所需设计元素 ➔ 4.完成设计内容的产出

特点:先有组织容器再有容器内容,组织容器具备布局规则等动态属性,更符合页面实现的框架。

四、实现路径

D2C的核心方法:D2C的核心法则是在保证幻觉与Token限制的条件下,通过稳定与可靠的方法,尽量多的将设计数据与研发数据进行链接,让AI充分理解两端数据并完成翻译

在这里插入图片描述

优劣势对比

稳定的D2C链接方法:

通过Figma MCP获取全部设计数据,包括颜色、圆角、间距、图层名称、文本信息、图片资源、代码数据、页面截图;将设计数据传递给AI-IDE工具,通过rules和Prompt控制设计数据解析标准,规定AI按照解析结果与代码数据对应,实现代码输出优势:即有设计元属性,又包含截图以及基础代码信息,AI可以更好的关联研发数据实现完美还原

并且针对不同页面构成,总结并执行不同的D2C步骤,用于还原设计内容,由于D2C的核心是链接,所以重点在于如何制造稳定链接,我们可以通过Code Connect或者让AI通过图层命名检索的方式实现稳定链接

在这里插入图片描述

D2C设计流程图

针对已有组件:

逻辑:通过调整设计组件名称与变体与研发组件名称和属性建立映射链接

步骤:提供界面截图 ➔ 工程师维护组件映射表 ➔ 设计师调整设计组件与研发组件结构一致 ➔ 还原页面内容

重点:工程师维护的组件映射表需包含组件名称及组件属性,设计师需保持设计组件与研发组件的结构相同

案例:PDADesign组件映射表

针对无组件场景:

逻辑:按照设计组件的名称与结构按照研发代码编写规则输出组件建立映射链接

步骤:设计师需采用工程化思维绘制组件 ➔ AI阅读代码仓库组件书写规范 ➔ 按照规范将设计组件输出为研发组件 ➔ 通过MCP获取设计组件并关联已经转为代码的研发组件

重点:与工程师对齐结构规范,若仓库中有Token数据再设计组件绘制时也需要保持一致



五、结语

D2C 是一次 团队角色和流程的升级,更是一场认知的跃迁:设计师不再只是交付界面,而是交付“可运行的实现方案”AI 成为设计师和工程师之间的“实时翻译器”最终实现:更快迭代、更少摩擦、更强共创。

在这条由 AI 驱动的设计到代码之路上,设计师不再是单纯的界面构建者,而是系统规则的定义者、智能逻辑的编织者。他们与 AI 一起,共同塑造一个能“理解意图、自动生成、持续学习”的设计生态。

当设计稿不再停留于视觉表达,而成为可以被机器直接理解的语言,设计师便跨越了传统的边界——从视觉思考者,走向了系统架构的参与者;从界面呈现者,走向了智能生产力的创造者。

AI 不会取代设计师,但会放大他们的思考维度,让人类的创造力从重复劳动中解放出来,去关注更本质的价值:如何让设计更智能、更高效、更具生命力。 在未来,D2C 不仅是“设计到代码”的捷径,更是“人机共创”的起点—— 让每一位设计师,都能成为 AI 时代的工程合作者,让设计真正成为推动产品智能演化的核心力量。

作者:桑伟杰

在这里插入图片描述

一、背景

当前在传统设计环节,设计师与研发之间存在大量的关于样式等视觉层的理解偏差,从而会出现大量的重复且无效的细节像素调整工作,由于项目时间紧、细节多设计走查环节会给各方角色诸多额外负担,在AI涌现后设计师尝试使用AI\_Code直接还原设计稿件,并且从传统交付静态界面设计图片转为交付可运行的实现方案,但在多数团队的认知里,AI\_Code仍停留在“氛围编程”阶段:能写出代码,但不符合框架规范,改动越多问题越多。通过不断摸索总结出一套稳定可用的 Design to Code (D2C) 解法:设计师借助 AI - IDE工具以及设计工具,通过MCP打通设计数据与研发数据,实现将设计稿直接转译为符合开发规范、可上线的前端代码,极大缩短交付周期。

D2C核心效果:设计师第一次拥有了对实现效果的“直接控制权”工程师从繁琐的像素级样式修改中解放出来团队整体迭代速度大幅提升

在这里插入图片描述

传统链路VSD2C链路

二、效果展示

案例1:PC端\_WMS6.0工艺配置

通过D2C流程从【组件生成】→【页面生成】,完成PC端工艺流程配置功能代码输出,实现了卡片拖拽、卡片状态自动变更、放置位置判断等核心功能;实现项目完整交付在测试环境中可直接运行,研发无需对前端代码进行修改,D2C代码输出总耗时0.5人/日,项目整体效率提升26%

在这里插入图片描述

WMS6.0\_Vue2.0实现效果

案例2:移动端\_PDA上架到容器

通过D2C流程链接设计数据与研发数据,【直接调用研发组件库代码】,按照代码仓库标准代码输出规范的前端页面,实现多页面跳转,逻辑判断,查询等核心功能,达到像素级还原并符合团队规范。D2C代码输出总耗时0.5人/日,项目整体效率提升50%

在这里插入图片描述

PDA\_Flutter实现效果

三、设计思维转变

D2C 并非“让设计师写代码”,而是促使设计师提升工程化思维:使设计师从传统的设计界面转向当前的设计容器,从而更好的让AI能够读懂设计数据实现D2C流程



传统设计思维 ➔ 工程化思维

传统设计思维:

步骤:1.设计全部视觉元素 ➔ 2.在页面进行元素相对位置的排布 ➔ 3.完成设计内容的产出

特点:元素之间仅包含相对关系没有结构层的动态属性,与页面实现的框架不一致

工程化思维:

步骤:1.设计组织分层关系 ➔ 2.设计分层容器布局规则 ➔ 3.设计容器所需设计元素 ➔ 4.完成设计内容的产出

特点:先有组织容器再有容器内容,组织容器具备布局规则等动态属性,更符合页面实现的框架。

四、实现路径

D2C的核心方法:D2C的核心法则是在保证幻觉与Token限制的条件下,通过稳定与可靠的方法,尽量多的将设计数据与研发数据进行链接,让AI充分理解两端数据并完成翻译

在这里插入图片描述

优劣势对比

稳定的D2C链接方法:

通过Figma MCP获取全部设计数据,包括颜色、圆角、间距、图层名称、文本信息、图片资源、代码数据、页面截图;将设计数据传递给AI-IDE工具,通过rules和Prompt控制设计数据解析标准,规定AI按照解析结果与代码数据对应,实现代码输出优势:即有设计元属性,又包含截图以及基础代码信息,AI可以更好的关联研发数据实现完美还原

并且针对不同页面构成,总结并执行不同的D2C步骤,用于还原设计内容,由于D2C的核心是链接,所以重点在于如何制造稳定链接,我们可以通过Code Connect或者让AI通过图层命名检索的方式实现稳定链接

在这里插入图片描述

D2C设计流程图

针对已有组件:

逻辑:通过调整设计组件名称与变体与研发组件名称和属性建立映射链接

步骤:提供界面截图 ➔ 工程师维护组件映射表 ➔ 设计师调整设计组件与研发组件结构一致 ➔ 还原页面内容

重点:工程师维护的组件映射表需包含组件名称及组件属性,设计师需保持设计组件与研发组件的结构相同

案例:PDADesign组件映射表

针对无组件场景:

逻辑:按照设计组件的名称与结构按照研发代码编写规则输出组件建立映射链接

步骤:设计师需采用工程化思维绘制组件 ➔ AI阅读代码仓库组件书写规范 ➔ 按照规范将设计组件输出为研发组件 ➔ 通过MCP获取设计组件并关联已经转为代码的研发组件

重点:与工程师对齐结构规范,若仓库中有Token数据再设计组件绘制时也需要保持一致



五、结语

D2C 是一次 团队角色和流程的升级,更是一场认知的跃迁:设计师不再只是交付界面,而是交付“可运行的实现方案”AI 成为设计师和工程师之间的“实时翻译器”最终实现:更快迭代、更少摩擦、更强共创。

在这条由 AI 驱动的设计到代码之路上,设计师不再是单纯的界面构建者,而是系统规则的定义者、智能逻辑的编织者。他们与 AI 一起,共同塑造一个能“理解意图、自动生成、持续学习”的设计生态。

当设计稿不再停留于视觉表达,而成为可以被机器直接理解的语言,设计师便跨越了传统的边界——从视觉思考者,走向了系统架构的参与者;从界面呈现者,走向了智能生产力的创造者。

AI 不会取代设计师,但会放大他们的思考维度,让人类的创造力从重复劳动中解放出来,去关注更本质的价值:如何让设计更智能、更高效、更具生命力。 在未来,D2C 不仅是“设计到代码”的捷径,更是“人机共创”的起点—— 让每一位设计师,都能成为 AI 时代的工程合作者,让设计真正成为推动产品智能演化的核心力量。