魔兽世界周维护后做什么

哈喽，大家好，我是小邵，如果你们项目还有人在手动维护 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 工程后真正有价值的地方。最后点赞关注不迷路，拜拜，我是小赵。