PIXELSYNC / 游戏界面，始终同步
美术专注设计，技术专注逻辑。PixelSync 基于 OpenRaster，将两端的修改接入同一条自动化链路，让界面从画布一路同步到游戏。
像使用 Photoshop 一样工作。图层、快捷键、参考线，
都在熟悉的位置；打开浏览器，就能开始。
美术改 ORA，技术改 FGUI XML。哪一端有更新，另一端就自动跟上。
布局、文本、样式都存为文本文件。
每次修改可逐行审阅，Git 按行自动合并。
n7_btn_ok:
− text: "开始游戏"
+ text: "开始旅程"
− fontSize: 16
+ fontSize: 18自动转换、校验、打包和发布。
团队直接在游戏里验收。
外观和切图归美术，控制器、关联和命名归技术。各自负责的字段，由转换器保护。
一套界面，两方各司其职编辑器只提供 FGUI 能表达的效果。不支持的内容及时提示，减少交付时的意外。
问题在编辑时被发现在 CI 中导入旧 PSD，或按需导出 PSD。仓库始终保留可审阅的 ORA 与 FGUI 源文件。
PSD 是交付产物，源文件更轻盈工作流程
从任何一端开始，沿着同一条链路完成同步与交付。
在网页编辑器中保存，将 ORA 目录提交到 Git。
技术也可以在 FairyGUI 中提交 XML，启动同一流程。
识别变更来源，基于上次同步点进行三方合并。
生成对侧文件（ORA 或 FGUI XML），完成规范校验与前后对比图。
合并成功后，bot 提交生成物，并更新同步基准。
打包 FGUI，发布到客户端构建或测试环境。
自动化，也保留人工决策。 发生冲突时，流水线输出报告或 MR，交由团队确认后继续。
开放设计
开放格式、明确约定，让每一次同步都有据可循。
固定键顺序、固定数值精度、每个属性一行。
文件名携带稳定 ID，改名也不会丢失对应关系。
ORA 图层与 FGUI 节点一一对应。改名或调整层级，不改变映射关系。
网页编辑器只读写 ORA。格式转换由流水线统一处理，技术字段在编辑器内锁定。
跳过 bot 自身的提交；内容哈希没有变化就不提交，避免同步循环。
外观、布局和切图以美术为准；控制器、关联和命名以技术为准。转换时只覆盖对方负责的字段。
PSD 不作为源文件入库。旧 PSD 中的智能对象、调整图层等不支持的内容，在导入时栅格化并给出警告。
三方合并以最近同步点为基准。冲突输出报告或 MR；校验通过后，发布到游戏客户端构建和测试环境。
减少交接，专注创作。
从第一个像素，到游戏里的每一帧。