01. 为什么做这个动态效果
最近，我准备上线我的个人网站，我想为我的个人网站制作一个加载动画，让整个网站更完整，也减少加载时等待的焦灼感。
最终效果并不复杂：两个相同 Logo 相隔半圈，沿倾斜椭圆轨道运动。
但这个看似不复杂的动画，我用 Codex 实际上做了两遍，花了一天半的时间。
第一遍，我试图让 AI 一次性生成轨道、速度、方向、景深和循环，给了一个大而全的要求。它很快给出了一个可以运行的版本，接下来却在不断修改中越来越偏，最后不得不重新建立工程，从静态结构开始重做。
这次经历让我重新理解了一件事：
AI 能一次生成很多东西，不等于我们应该一次让它把所有东西都做完。
02. 最初的做法
第一次尝试，本质上是一次性生成，我把轨道、朝向、速度、循环、景深等多个目标一起交给 AI，希望先直接得到完整效果，再逐步微调。
一开始，我对动效的描述大致是：两个相同的 Logo，围绕倾斜的椭圆轨道运动、具有空间透视感、速度经历慢—极快—慢、整体约三秒、最终作为个人网站的加载动画，并且让 AI 帮我优化了整体的提示词。
这套做法的优点非常明显：速度快，几乎立刻就能看到一个可运行的版本，也能快速验证概念是否成立。
但它的问题同样明显，设计者可以尽可能把边界和限制写完整，但仍然会有未说明的边界。当多个尚未确认的变量同时进入实现以后，后续每一次局部修改都会影响其他部分。
当描述存在空白时，AI 会自行补全。它补全的实现可能技术上合理，却未必符合设计者脑中的画面，这是因为设计者在尝试使用 AI 时把仍需要视觉试验的内容当成已经确认的开发需求，一次性交给 AI 实现。
03. 问题出现
AI 根据这些描述，一次性生成了完整代码。轨道有了，Logo 会动，速度发生了变化，甚至已经出现了一些远近效果。
从“能不能实现”的角度，它很快证明了方案可行，但问题出现在后续修改中。
我发现 Logo 朝向不对，于是修改旋转逻辑；调整以后，轨道方向又显得不自然。接着修改轨道，又发现两个 Logo 的相位关系发生变化；加入景深后，原本的位移、旋转和缩放开始互相覆盖。
每次看起来只是在修一个局部问题，但因为所有效果从一开始就耦合在一起，局部修改不断影响其他部分。
项目逐渐进入一种危险状态：代码仍能运行，AI 也仍然可以继续提出修复方案，但我们已经很难判断问题究竟属于路径、朝向、速度、景深还是结构。
此时，继续修改并不代表继续接近目标。
04. 过程中遇到的问题
04.1 为什么会越改越偏
后来复盘发现，第一次失败并不是因为 AI 不会写动效，而是因为我们一开始同时处理了太多尚未确认的问题：
- “旋转”究竟是 Logo 自转，还是围绕中心公转；
- Logo 应该保持固定朝向，还是沿轨道切线改变方向；
- 两个 Logo 是一正一倒，还是使用相同朝向；
- Logo 哪一端是头，哪一端是尾；
- 椭圆倾斜应该旋转父容器，还是通过数学坐标计算；
- 景深使用真实 3D，还是仅通过缩放、透明度与层级表达；
- 2700ms 是一圈，还是两圈；
- 慢—快—慢是每圈重复，还是两圈共享一条完整曲线；
- 循环边界是否允许完全停下。
这些内容虽然都写进了自然语言需求，但“被写进需求”不等于“已经被验证”。
例如，我们最初冻结了“Logo 始终保持正立、禁止切线跟随”的规则；实际预览后，我却发现切线跟随更有动势。后来切线公式正确了，又发现长尖角朝向了运动方向。
数学没有错，但视觉语义错了——长尖角应该是尾巴，不是头部。
真正的问题不是 AI 写错了，而是我们太早把尚未确认的视觉判断固化成了工程规则。
04.2 什么时候应该停止修补，重新开始
重新开始并不是因为旧代码完全不能修，而是因为继续修补已经失去性价比。
一个动效可以拆成：静态资源、页面结构、轨道路径、元素朝向、时间与速度、循环衔接、景深、响应式。
如果页面同时存在路径、朝向、尺寸与速度问题，而这些逻辑又集中在同一段实现中，我们已经无法判断一次修改会破坏什么。
当你已经无法指出“问题属于哪一层”时，就应该考虑重建结构。
因此，我们保留第一版作为可行性原型，但不再继续叠加补丁，而是新建 Git（版本管理）仓库，从一个不可覆盖的基线开始。
05. 如何调整
第二次尝试的核心规则变成了：每次只解决一个问题。
阶段被拆成：v0.0：基线 - v0.1：静态 - v0.2：轨道 - v0.3：速度 - v0.4：景深
05.1 v0.0：先保存原始资产与规则
我们先保存 Logo SVG、轨道草图、动效规范和协作规则，不创建 Astro 工程，也不写动画。
这个节点的意义是：无论后续发生什么，原始意图和素材始终有一个可以回到的稳定起点。
05.2 v0.1：只搭静态骨架
这一阶段只验证：Astro + TypeScript（类型脚本）能否正常运行、SVG 能否加载、两个 Logo 是否正确显示。
同时明确禁止：轨道、JavaScript 动画、绝对定位。
这一阶段曾出现过破损图片和意外动画，但因为目标足够单一，我们可以明确判断：问题属于资源路径和阶段越界，而不是轨道算法。
05.3 v0.2：只做匀速轨道与朝向
静态结构确认后，才加入：椭圆轨道、半圈相位差、单个 requestAnimationFrame（浏览器逐帧回调）时钟、切线方向，暂时不处理速度曲线与景深。
这样我们可以单独判断：轨道是否正确、两个 Logo 是否始终相隔半圈、朝向是否连续、头尾关系是否符合视觉语义。
05.4 v0.3：只处理时间、速度与循环
轨道稳定后，再加入：2700ms、两圈、慢—极快—慢、连续循环。
这一阶段发现：单次运动很好看，但周期结束时仍有明显停顿。
原因并不是动画没有循环，而是缓动曲线在进度 0 和 1 处的速度都降到了零。
最终通过混入少量线性进度，让首尾保持低速但非完全静止，解决了循环边界的停顿。
05.5 v0.4：最后加入景深和真实页面尺寸
只有路径、朝向和速度都稳定以后，才加入：scale（缩放）、opacity（透明度）、z-index（层级）。
我们没有使用真实 3D，而是根据 Logo 在屏幕中的纵向位置判断前后，随后又发现，独立 Demo 中合适的尺寸，放进真实首屏后明显过大，于是继续缩小轨道、Logo 和舞台容器，直到它更像网页中的品牌辅助视觉，而不是一张占据页面中心的动效海报。
05.6 用更窄的任务边界约束 AI
第二次开发中，AI 本身并没有发生变化。真正变化的是，每次交给它的任务更窄、更明确，而且包含清晰的禁止项。
第一次的指令类似：“做一个双 Logo 椭圆轨道动画，需要空间感、速度变化和循环。”
第二次则变成：“当前阶段只验证两个 SVG 是否能静态显示。禁止加入动画、轨道、绝对定位和 JavaScript。”
AI 协作中的控制力，很大一部分来自任务粒度。任务越大，AI 自主补全的范围越大；任务越小，结果越容易观察、验收和回退。详细的阶段约束并不是多余的啰嗦，而是在减少未知决策。
05.7 把 Git 当成试验过程中的安全网
第二次重做时，我们从一开始就规定：
- 每一阶段先实现与预览，视觉确认后才能提交；
- Codex（代码智能体）不能自动 Commit（提交）；
- 稳定版本使用 Tag（标签）；
- 实验性动效使用独立 Branch（分支）；
- 禁止
git reset --hard； - 禁止覆盖已确认版本。
这套规则很快发挥了作用。
有一次，v0.2-orbit 标签已经创建，但轨道代码仍留在 Working Tree（工作区）中，并没有真正提交。也就是说，标签名称是轨道版本，实际指向的却仍是静态版本。
还有一次，仓库中意外出现了一个文件名为 rbit 的文件，末尾甚至带有空格。我们没有直接删除或执行 git clean，而是先查看文件类型与内容，确认只是粘贴错误后再移出仓库。
在 AI 辅助开发里，Git 的价值不是保存最终代码，而是让每一次试验都有边界、有证据、有撤退路线。
06. 最终结果
回头看，第一版并非完全失败，它快速证明了几个关键判断：这个视觉概念可以实现、SVG 可以沿椭圆路径运动、不需要真实 3D、浏览器性能足以承载这个效果，因此，一次性生成更适合作为可行性原型，而不是直接被当作最终工程。
整个过程可以概括为：一次性生成 → 验证概念 → 暴露未知 → 提取结论 → 分阶段重建
真正浪费时间的，不是原型失败本身，而是在已经明显偏离的原型上持续修补，却因为舍不得已有代码而迟迟不愿重新开始。
最终，双 Logo 动效通过分阶段开发完成了路径、朝向、速度、循环、景深和真实页面尺寸的逐层验证，并形成了可以稳定回退和继续迭代的版本结构。
07. 经验总结
07.1 以后如何判断一个 AI 动效方案是否可行
-
视觉是否在真实场景中成立
不能只看独立 Demo 是否好看，还要看它缩小到实际 Hero 后是否仍可识别、快速阶段是否糊成一团、是否抢夺标题和项目内容，以及 Logo 的方向是否符合图形语义。
-
技术结构是否可以拆分
位移、旋转与缩放最好分属不同 DOM 层：
orbit-node负责位移和层级，depth-node负责缩放和透明度，logo-image负责旋转。一个元素只承担一种主要变换职责，后续修改才不会互相覆盖。
-
性能是否足够轻
当前方案只需要两个 SVG、一个 requestAnimationFrame、少量数学运算，以及 transform、opacity 和 z-index。
不依赖 Canvas、WebGL、Three.js 或大型动画框架，因此适合作为个人网站中的持续品牌动效。
-
参数是否集中、可调整
时间、圈数、轨道半径、倾斜角、起始角、景深范围等参数应集中管理。
以后在不同页面调整尺寸时，只改参数，不重写运动逻辑。
-
是否能独立验收并安全回退
每个阶段都要提前写清楚“看什么、不看什么、怎样算通过”。
无法独立验证、也无法安全回退的实现，即使当前能运行，后续维护成本也会很高。
07.2 如果重新开始，我会先做这些准备
- 先明确使用场景：全屏 Loader（加载动画）、Hero 品牌视觉、按钮微交互，还是页面转场；
- 画出起点、四分之一圈、半圈、四分之三圈和终点，标注位置、朝向、大小、透明度与层级；
- 区分真正冻结的工程规则与仍需试验的视觉参数；
- 提前建立阶段验收标准：资源、路径、朝向、速度、循环、景深、真实页面；
- 检查 SVG 的 viewBox、图形中心、透明边距与默认方向；
- 提前确认 Node、npm、Astro、Git、Netlify 与构建产物位置；
- 先建立 Baseline Commit（基线提交）和 Tag，再开始实验。
08. 结语
这次项目让我更明确了人在 AI Collaboration（AI 协作）中的角色。
AI 擅长快速生成结构、编写数学与动画逻辑、检查代码、执行构建，以及按照明确规则完成修改。
而我需要负责判断视觉是否成立，识别文字描述与真实需求之间的差异，决定哪些规则应该冻结，控制每次任务的边界，判断继续修补还是重新开始，并在真实页面中完成最终收口。
整个过程可以概括为：模糊想法 → 可运行原型 → 暴露问题 → 拆分变量 → 逐层验证 → 固化版本 → 真实场景收口
真正高效的 AI 协作，不是一次说清所有要求，也不是一次生成全部结果，而是知道下一步最需要验证的究竟是哪一个问题。
AI 提高的是实现与试验的速度。但如果没有阶段边界、视觉判断和版本控制，更快的生成也可能只是让项目更快偏离目标。
这次双 Logo 动效最终形成的方法可以概括为：先用 AI 快速验证可行性，再把复杂目标拆成可独立验收的阶段；每一阶段只解决一个问题，确认后用 Git 固化，最后放进真实场景完成判断。
先验证可行性，再重建正式结构；先缩小问题，再扩大成果。