粉丝837获赞8918

哈喽,大家好,我是小邵,如果你们项目还有人在手动维护 figma 主建库,那这条视频你一定要看完。我们最近把一件特别重复、特别耗时的事情开始逐渐交给 ai 了,就是让 agent 围绕 ferrari gi 的 阿麦尔工程自动同步到 figma 主建库。 过去每次封版后光维护主建库就要花一两周,而最离谱的是这些信息。其实封版后光维护主建库就要花一两周,而最离谱的是这些信息其实工程里已经有了命名、结构、尺寸、主建关系, 但是以前只能靠人工手动搬运到飞格玛组建库,所以后来我就在想,能不能把这件事情拆成 agent 能稳定执行的流程。最后我们总结下来,核心其实就三步,验证最小循环、补充对应关系、确定执行范围。 先说第一件事情,验证最小循环,也就是先验证单个叉 ml 文件能不能转成 figma 里面的一个实体组建结构,只要这个叉 ml 到 figma, 这个单个文件的循环能跑通。后面的问题就不再是 ai 能不能做,而而是工程怎么猜的问题。 所以第一步不是做大,而是先做闭环。最小的循环成立以后,第二步是补充对应关系。因为真实的项目不是一个文件,我们项目里可能会有多个业务包,多个 ui 文件, ferrari gui 叉 ml 和 figma, 它们之间都有关系, 所以这里要先把关系补起来。比如 perry 包对应哪个菲克玛包,叉 ml 文件对应哪个实体主键,哪些内容已经存在,哪些内容还在缺失。这一轮做完以后,就能得到两个东西, 一个是完整的对照表,一个是缺失的任务列表。有了这两个东西, agent 才不是在一堆混乱的信息里乱跑,而是按照任务清单一个一个的执行。第三步也是我觉得最关键的一步,确定执行范围。 因为帮我创建 ui 这个任务太模糊,一旦任务模糊, agent 就 容易自由发挥,最后的结果就会跑偏。所以我后来把他的执行范围压的很小, 他既不负责延伸设计,也不负责判断准不准确。他只做两件事情,根据叉 m l 的 命名尺寸创建飞格码主键,先让他稳定的执行,再逐渐补全表现。 也就是说,叉 m l 是 工程源头,飞格码是生产侧使用主键的结果, agent 是 中间的执行者, 飞格码最终还是服务设计师、交互设计师和程序的设计师用它来生产 ui, 交互用它表达页面结构状态和方案,程序用它查看工程命名和组建的对应关系。还有对其交互方案, agent 要做的不是理解飞格码,也不是重新设计,它只是围绕着叉麦尔工程,把已经存在的结构、命名、尺寸、组建关系同步到飞格码组建库里。 这个流程跑通一次以后,后面就可以将流程反向补充到 skill, 每执行一批任务,就可以把规则沉淀下来,每遇到一种异常,就可以把处理方式补进去, 最后形成的是一套可持续迭代的 ml 到 figma 的 能力链。我的感受是, ai 时代做 ui 工程,更重要的是,你要把工作拆成 ai 能稳定执行的结构,先验证最小循环,再补齐对应关系,最后限制执行的范围。 只有这样, agent 才不会失控, skill 才能真正地被沉淀下来,而人真的要做的,也会从重复维护变成了定义规则,拆解任务、控制边界。这才是我觉得 ai 接入 ui 工程后真正有价值的地方。最后点赞关注不迷路,拜拜,我是小赵。
