dashi-motion

交付能继续修改的原生工程，并在目标软件里检查实际结果。保留用户选定的软件、现有文件、制作方式和相似度要求。

按软件路由

先确定本次实际要操作的软件，只读取对应文件。比较三款软件或明确要求跨软件时，才读取多个分支。

“状态机”或“字阵”本身不构成切换软件的理由。用户已指定 AE 时，即使要做字阵，也只走 AE 分支。

没有指定软件时，先看当前文件和前文。仍无法判断且选择会改变交付形式时，再问软件选择。不要自行把原生工程改成网页或视频脚本。

按当前工作加载

• 有参考视频，或反馈动画不够像： 再读 参考拆解与对比。没有参考素材的自由创作不必读。
• 只换字体、配色、文字或比例： 读取对应软件的相关小节，保留已确认的运动结构。
• 继续下一段： 找到当前已确认的工程，在同一文件继续。旧构建脚本可能会覆盖后续分段，先检查其输入基线和输出范围。
• 只导出、询问目录或统计节点： 检查当前工程和现有输出，使用软件分支的导出或统计说明；不重做动画。

附带脚本按任务使用：AE 分支提供属性与队列检查，Cavalry 分支提供工程统计，参考视频分支提供顺序抽帧与并排图。入口、依赖和调用方法在各分支中；不需要运行全部脚本。

共同制作原则

选定软件后，先读该分支的“跑通的路线”，按步骤中的成功标志推进；碰到相同现象时，再用“碰壁与处理”定位。只导出或修改一个属性时，从对应步骤进入，不重跑整个流程。

分支中的证据分三种：实跑记录是制作中执行并观察过的结果；文档核对是官方支持但本案例未完整走过的路线；未确认表示只有现象，尚未证实根因或修复。优先复用适合当前任务的实跑路线，不能把后两类写成已解决。

1. 先建立真实操作路径。 确认应用、文件、合成或画板，再完成一个可见动作。用户指定 Dia 等浏览器时沿用该浏览器；画布不适合 DOM 操作时使用可用的 Computer Use。工具的入口和参数以当前工具文档为准。
2. 将可编辑性落实到对象。 字体、路径、颜色、动作和状态要有对应的原生编辑入口。“可以改一大段代码”不等于用户能在编辑器里调整。
3. 遵守制作方式。 用户要求绘制图形和可视状态机时，直接使用编辑器对象。用户允许自动化时，可用脚本批量建立原生对象；不要把全部画面和交互封装成运行时绘图脚本。用户明确禁止脚本时，不用“结果仍可编辑”作为例外。
4. 先改用户指出的差异。 运动问题先核对方向、节奏、位移、层距、展开和收束；字体问题再检查字形、字面大小和混排。用户已接受的部分不因其他优化而重做。
5. 复杂度服务于编辑。 重复运动使用共享控制、复制器或组件；独立动作保留独立控制。少量关键帧和大量数学节点都不能单独证明方案易调。
6. 尊重完成标准。 “约八成即可”是该次任务的取舍；不把它写成所有项目的默认标准，也不在用户接受后继续追求像素一致。
7. 用实际结果收尾。 原生工程能打开、目标动作能播放、导出文件能解码是不同证据。按当前改动完成必要检查，不另建无关测试框架。

交付方式

给出工程和本次预览的准确路径，简述改动与主要控制入口。对比视频和独立成片分开命名；用户要单独成片时，交付没有对照画面和说明条的视频。

明确区分“文件已生成”“应用已打开并保存”“已原生渲染”“已与参考对比”。遇到捕捉失败或渲染未完成时，说明缺少的证据，不用节点数量或脚本执行成功替代。

下列分支来自具体制作记录与文档核对，已写入执行顺序和成功标志；使用者不需要访问作者原工程才能开始。案例名称用于说明经验来源。软件版本、菜单、导出模板和文件路径均可能变化；复用前验证当前环境，不固定历史坐标、账号、文件 ID、帧数或节点数量。