企业官网建设流程全解析

• AI 技能
• 设计系统
• 前端

本文围绕improve-animations技能中的 PLAN-TEMPLATE.md 展开，系统讲解这份"自包含动画实现计划"模板的每一个字段、写作纪律与底层设计意图。读完本文，你将掌握如何把一次动画审计中发现的问题，转写成一份连"零上下文、零审美"的执行模型都能一字不差照做的计划，并学会用 AUDIT.md 的权威数值与 SKILL.md 中的工作流约束来保证计划的质量与可执行性。

从审计到计划：模板存在的意义

improve-animations是一个模拟"高级动效顾问"的只读技能：先全面侦察代码库的动画与动效代码，产出带优先级的问题清单，再为选中的问题编写可直接交给其他 Agent（包括能力较弱的廉价模型）执行的实现计划。它的工作流在 SKILL.md 中分为四个阶段：Recon（侦察）→ Audit（并行审计）→ Vet / 确认 → Write plans（写计划）。

PLAN-TEMPLATE.md 就是第四阶段唯一遵守的格式规范，它开宗明义地给出了模板存在的理由：

Every plan written byimprove-animationsfollows this structure. The executor may be a less capable model with zero context and zero taste — the plan must contain everything, exactly. No references to "the audit above" or "the easing we discussed."

这段话点出了整个模板的设计哲学：计划是写给"最弱执行者"看的执行规格书。执行者没有本次对话的上下文、没有审美判断力，因此计划必须自包含一切——精确的文件路径、逐字的现状代码、精确的目标数值、仓库自己的写法惯例、有序的编辑步骤、硬性的边界约束，以及可机器检查与可"手感检查"的验收标准。任何"参考上面的审计""我们之前讨论过的缓动"这类指代式表述都是被明令禁止的（对应 SKILL.md 的 Hard Rule 3：Plans must be fully self-contained）。

模板总览：一段自包含的执行规格书

模板在 PLAN-TEMPLATE.md 中以一段完整的 Markdown 骨架给出，共八个部分：头部元数据、Problem、Target、Repo conventions、Steps、Boundaries、Verification，以及作者备忘（Notes）。完整骨架如下：

# NNN — <Short imperative title> - **Status**: TODO - **Commit**: <output of `git rev-parse --short HEAD` when this plan was written> - **Severity**: HIGH | MEDIUM | LOW - **Category**: <audit category> - **Estimated scope**: <n files, rough size> ## Problem What is wrong, where, and why it matters to how the product feels. Cite every location as `path/to/file.tsx:123` and include the current code verbatim: ```css /* src/components/dropdown.css:14 — current */ .dropdown { transition: all 400ms ease-in; } ``` ## Target The exact end state. Every value spelled out — curves, durations, spring configs, media queries. Never "use a nicer easing": ```css /* target */ .dropdown { transition: transform 200ms var(--ease-out), opacity 200ms var(--ease-out); transform-origin: var(--transform-origin); } ``` ## Repo conventions to follow How this codebase already does it, with one exemplar the executor should imitate (token names, file placement, prop patterns): - Easing tokens live in `src/styles/tokens.css`; add new curves there, e.g. `--ease-out: cubic-bezier(0.23, 1, 0.32, 1);` - <exemplar file:line that already does this correctly> ## Steps 1. <One concrete edit per step: file, what changes, resulting code.> 2. … ## Boundaries - Do NOT touch <files/components out of scope>. - Do NOT change markup/structure — motion properties only (unless a step says otherwise). - Do NOT add new dependencies. - If a step doesn't match the code you find (drift since the commit stamp), STOP and report instead of improvising. ## Verification - **Mechanical**: <exact commands — typecheck, lint, build — with expected outcome>. - **Feel check**: run the UI, trigger <interaction>, and confirm: - <observable check, e.g. "the dropdown scales from its trigger, not from center"> - <e.g. "spamming the toggle never restarts the animation from zero"> - In DevTools, set playback to 10% (Animations panel) and confirm <detail>. - Toggle `prefers-reduced-motion` (Rendering panel) and confirm movement is dropped but opacity feedback remains. - **Done when**: <machine- or eye-checkable completion criteria>.

下面逐段拆解每个部分的意图与填法。

头部元数据：状态、Commit 戳、严重级别、类别与范围

计划的标题使用NNN — <短祈使句标题>格式，NNN 是单调递增的计划编号，与落盘文件名NNN-short-slug.md对应（SKILL.md 要求遵守现有计划的编号）。头部四个字段各有用途：

• Status: TODO—— 状态字段，用于plans/README.md的状态追踪与reconcile变体的生命周期管理（执行完成后可标记为 DONE，参见 SKILL.md）。
• Commit—— 写入计划时git rev-parse --short HEAD的短提交哈希。这是计划与代码库之间的"时间锚点"：如果执行时发现代码与计划中的引文对不上，就说明自写计划以来代码已漂移，执行者必须停止并报告（见 Boundaries）。
• Severity: HIGH | MEDIUM | LOW—— 严重级别沿用 SKILL.md 的定义：HIGH 为破坏手感的问题（UI 上的错误缓动、键盘/高频操作上的动画、掉帧、scale(0)）；MEDIUM 为明显不对劲的问题（错误的原点、不可中断的动态 UI、缺失 reduced-motion 处理）；LOW 为打磨项（stagger 错落、blur 遮罩的交叉淡化、token 整合）。
• Category—— 填写审计类别，即 AUDIT.md 中定义的八大类之一：Purpose & frequency、Easing & duration、Physicality & origin、Interruptibility、Performance、Accessibility、Cohesion & tokens、Missed opportunities。
• Estimated scope—— 预估改动规模（涉及文件数与大致体量），帮助执行者与人工审查者评估计划的工作量。

Problem：把问题钉死在 file:line 与逐字代码上

Problem 段落回答三个问题：哪里错了、错在何处、为什么影响产品手感。模板强制两个硬性要求：

1. 每个问题位置都写成path/to/file.tsx:123形式，不允许模糊描述。这一约束贯穿整个技能——SKILL.md 在审计阶段同样要求"从未在自己核对过 file:line 的 finding 绝不呈现"。
2. 必须逐字包含现状代码。例如模板内置的示例：

/* src/components/dropdown.css:14 — current */ .dropdown { transition: all 400ms ease-in; }

这里的transition: all 400ms ease-in本身就是 AUDIT.md 中两条典型 finding 的叠加：ease-in让 UI 入场先慢后快，恰好延迟了用户正在注视的瞬间；transition: all会顺带动画化非 GPU 属性。逐字贴出代码，既让执行者精确知道改哪里，也让审查者无需回翻审计上下文即可判断问题是否属实。

Target：写下精确终态，拒绝"换个更好的缓动"

Target 段落是计划的心脏，规则只有一条：每个值都要写死——曲线、时长、spring 配置、媒体查询，全部拼写出来，绝不允许出现"用个更顺滑的缓动"这类交给执行者自行发挥的表述：

/* target */ .dropdown { transition: transform 200ms var(--ease-out), opacity 200ms var(--ease-out); transform-origin: var(--transform-origin); }

模板示例中的每个值都能在 AUDIT.md 找到出处，这正是"精确值"的来源：

• 缓动决策顺序：进入/退出用ease-out（起手快、响应感强）、屏幕内移动/形变用ease-in-out、hover/颜色变化用ease、恒定运动用linear、默认ease-out；而UI 上的ease-in永远是一个 finding。
• 强自定义曲线（内建 CSS 缓动太弱）：

  --ease-out: cubic-bezier(0.23, 1, 0.32, 1); /* strong ease-out for UI */ --ease-in-out: cubic-bezier(0.77, 0, 0.175, 1); /* strong ease-in-out for on-screen movement */ --ease-drawer: cubic-bezier(0.32, 0.72, 0, 1); /* iOS-like drawer curve */

• 时长预算：UI 动画控制在 300ms 以内。按钮按压反馈 100–160ms、工具提示/小 popover 125–200ms、下拉/选择器 150–250ms、模态/抽屉 200–500ms、营销页/解释性动画可以更长。示例中 200ms 的下拉时长正是落在 150–250ms 区间内。
• spring 配置：推荐 Apple 风格{ type: "spring", duration: 0.5, bounce: 0.2 }，bounce 保持在 0.1–0.3 的微妙区间，可见回弹只留给拖拽关闭和俏皮场景（AUDIT.md）。

模板在 Notes 里进一步强调：每个数值都要从 AUDIT.md 拉取，绝不凭记忆近似。AUDIT.md 是权威数值目录，任何出现在其中的值都应原样拷贝进 Target。

Repo conventions to follow：让执行者模仿仓库自己的写法

审计阶段 SKILL.md 的一项核心侦察任务是摸清仓库的动效惯例（现有 easing token、时长刻度、spring 配置），而这一节就是把侦察结果固化进计划：告诉执行者这个代码库"已经是怎么做的"，并给出一个值得模仿的样板（exemplar file:line）。

模板内置示例：

Easing tokens live insrc/styles/tokens.css; add new curves there, e.g.--ease-out: cubic-bezier(0.23, 1, 0.32, 1);

这里隐含了一个重要原则（AUDIT.md 的 Cohesion & tokens 类别）：曲线和时长应该作为共享 token 存在，五个手写的、几乎相同的 cubic-bezier 本身就是一条整合型 finding。因此计划必须扩展现有 token，而不是另起一套平行的命名体系——写进这一节的正是"新曲线加到哪个文件、用什么 token 名"，再配一个"已经在正确位置这么做的 exemplar file:line"作为执行者的模仿对象。

Steps：一步一编辑，可复制的最终代码

Steps 把 Target 拆解成有序的编辑动作。模板规定每一步只做一个具体编辑，且必须包含三要素：文件、改动内容、改动后的结果代码：

1. <One concrete edit per step: file, what changes, resulting code.>
2. …

之所以要求"一步一编辑 + 最终代码"，是因为执行者可能没有能力自己推导中间状态。对大型改动，Steps 通常按"先在src/styles/tokens.css加入--ease-outtoken → 再替换组件里的transition→ 最后处理transform-origin"这样的依赖顺序排列，每一步的结果都可独立核对。这也与 SKILL.md 的写作要求一致：为最弱的执行者写作，给出精确的文件路径与现状代码摘录、精确的目标数值、仓库惯例与样板、有序步骤、硬边界，以及包含"手感检查"的验收部分。

Boundaries：硬边界与漂移止损

Boundaries 段落的目的是限制执行者的自由裁量权，模板内置四条：

• Do NOT touch <files/components out of scope> —— 明确圈定不可触碰的文件/组件。
• Do NOT change markup/structure — motion properties only (unless a step says otherwise) —— 默认只允许改动效属性，禁止改 DOM 结构，除非某一步明确授权。
• Do NOT add new dependencies —— 禁止新增依赖，杜绝执行者为了"省事"引入动画库。
• If a step doesn't match the code you find (drift since the commit stamp), STOP and report instead of improvising ——漂移止损协议：头部 Commit 戳标记了写计划时的代码版本；如果执行者发现实际代码与计划引文不一致，必须停下并报告，而不是即兴发挥。

最后这条与 Hard Rule 5（SKILL.md）互为补充：如果代码库中有设计文档或注释记录了刻意的动效取舍，计划作者应尊重它、注明它，而不是把它当作 finding 上报。边界段保证了执行者既不会越界，也不会在意外情况下自作主张。

Verification：机械检查 + 手感检查 + 完成标准

Verification 是模板中最具"可执行性"的部分，分三层：

• Mechanical（机械检查）：给出精确命令及其预期结果，如 typecheck、lint、build。这些是零判断的检查，执行者照敲即可。
• Feel check（手感检查）：运行 UI、触发指定交互，然后逐项确认可观察的表现。模板内置了四个典型的观察项：
  • "下拉从触发点缩放，而不是从中心缩放"——对应 Physicality 类别中"popover/dropdown/tooltip 从 trigger 缩放，transform-origin: var(--transform-origin)，模态框除外"的规则（AUDIT.md）；
  • "快速连点开关时动画从不从零重启"——对应 Interruptibility 类别中"transition 可中途重定向，keyframes 会从零重启"的规则（AUDIT.md）；
  • 在 DevTools 的 Animations 面板把播放速度调到 10%，慢速核对具体细节（缓动是否突兀停止、transform-origin是否正确、联动属性是否同步，参考 STANDARDS.md 的调试建议）；
  • 在 Rendering 面板切换prefers-reduced-motion，确认位移被移除但透明度反馈保留——这正是"reduced motion 意味着更少更柔和的动画，而不是零动画"的落地检查（AUDIT.md）。
• Done when（完成标准）：给出机器可查或肉眼可查的完成判据，作为执行者收尾与人工审查的基准。

模板作者备忘强调：手感检查不是可选项。动效可能机械上完全正确但感觉就是不对，因此要给执行者（或审查执行者 diff 的人）提供具体的慢速观察点。SKILL.md 的 Tone 部分也要求：当手感无法单凭代码判断（交叉淡化、spring 回弹）时，明确说明这一点，并在计划里放入 feel-check 步骤，而不是靠猜。

Notes for the plan author：写作纪律

模板末尾的 Notes 是对计划作者（通常是能力强、有审美的模型）的四条纪律：

1. 一个 finding 对应一个计划。只有两个 finding 共享全部文件且修复模式完全相同（例如同一 easing token 在多个组件间替换）时，才允许合并为一个计划。
2. 每个值都从 AUDIT.md 拉取，绝不凭记忆近似。AUDIT.md 是审计规则目录与权威数值目录，计划中的曲线、时长、spring 配置必须原样拷贝。
3. Feel check 不可省略。原因如前所述：动效可以机械正确而手感不对。
4. 写完计划后创建或更新plans/README.md，内容包括：计划表（编号、标题、严重级别、状态）、推荐执行顺序、计划之间的依赖关系。

plans/README.md：计划的索引、依赖与执行顺序

plans/README.md是计划的"前台总览"。它需要包含：

• 计划表：列出自定义的计划编号（number）、标题（title）、严重级别（severity）与当前状态（status，如 TODO / DONE）；
• 推荐执行顺序：按 leverage（影响 ÷ 代价）排序，通常 HIGH 优先；
• 计划间依赖：例如"计划 004 依赖 003 先落地--ease-outtoken"。

计划文件本身按NNN-short-slug.md命名，编号单调递增并尊重已有计划（SKILL.md）。当代码库演进后，improve-animations reconcile变体（SKILL.md）会重新核对plans/与当前代码：把已完成的计划标记为 DONE、刷新过期的 file:line 引用、退役已被修复的 finding——这正是头部 Commit 戳与 Problem 中 file:line 引文派上用场的场景。

完整示例：把模板填成一份真实计划

下面把模板中自带的 dropdown 示例与 AUDIT.md 的权威值结合，填出一份完整计划（内容为演示性质，用于展示各字段的填法）：

# 007 — Replace dropdown ease-in with ease-out tokens - **Status**: TODO - **Commit**: 3f2a9c1 - **Severity**: HIGH - **Category**: Easing & duration - **Estimated scope**: 2 files, ~20 lines ## Problem `src/components/dropdown.css:14` uses `transition: all 400ms ease-in`. `ease-in` starts slow, delaying the exact moment the user watches the dropdown open; `transition: all` animates unintended properties off-GPU. ```css /* src/components/dropdown.css:14 — current */ .dropdown { transition: all 400ms ease-in; } ``` ## Target Dropdown is a 150–250ms UI element. Enter with strong ease-out, exit with ease-out, origin at the trigger: ```css /* target */ .dropdown { transition: transform 200ms var(--ease-out), opacity 200ms var(--ease-out); transform-origin: var(--transform-origin); } ``` ## Repo conventions to follow - Easing tokens live in `src/styles/tokens.css`; add new curves there, e.g. `--ease-out: cubic-bezier(0.23, 1, 0.32, 1);` - Exemplar: `src/components/popover.css:21` already uses `var(--ease-out)` with `transform-origin: var(--transform-origin)`. ## Steps 1. In `src/styles/tokens.css`, add `--ease-out: cubic-bezier(0.23, 1, 0.32, 1);` to the `:root` block. 2. In `src/components/dropdown.css:14`, replace the `transition` with the target declaration above, and add `transform-origin: var(--transform-origin);`. ## Boundaries - Do NOT touch `src/components/dropdown.tsx` (markup/structure). - Motion properties only — no layout changes. - Do NOT add new dependencies. - If `src/components/dropdown.css` no longer matches the excerpt above, STOP and report. ## Verification - **Mechanical**: `npm run typecheck` and `npm run lint` pass with no new errors. - **Feel check**: open the dropdown from its trigger and confirm: - The panel scales from the trigger point, not from the center. - Spamming the toggle never restarts the animation from zero. - In DevTools Animations panel set playback to 10%: easing does not stop abruptly and opacity/transform stay in sync. - Toggle `prefers-reduced-motion`: movement is dropped but opacity feedback remains. - **Done when**: the transition matches the target verbatim and all feel checks pass at 10% playback.

这份示例展示了模板各段落的协同：Problem 给出可核对的引文，Target 的所有数值来自 AUDIT.md 的权威目录，Repo conventions 用仓库现有的 popover 做法作为样板，Boundaries 用 commit 戳 + 引文做漂移止损，Verification 同时覆盖机器检查、慢速手感检查和 reduced-motion 检查。

模板如何融入 improve-animations 工作流

理解模板还需要知道它在整个工作流中的位置与约束：

• 写计划发生在审计确认之后。流程是：Recon 侦察动效面（技术栈、动效库、token 惯例、产品性格、频率地图）→ 按八大类并行审计 → 作者亲自复核每个 finding 的 file:line、剔除 by-design/误判/重复项，按 leverage 排序成表，等待用户挑选 → 用户选定后，每个 finding 用本模板写成一个计划（SKILL.md）。非交互模式下默认取 leverage 最高的前 3–5 个。
• 审计深度可调：quick（仅高频组件，约 5 条 HIGH finding）、standard（全部交互 UI，完整表格）、deep（整个仓库含营销页，含 LOW 打磨项），会影响计划的来源，但不会改变计划本身的格式。
• 只读约束贯穿始终：Hard Rule 1 和 2（SKILL.md）规定技能绝不修改源码，唯一可创建/编辑的文件位于plans/（若plans/已被占用则用animation-plans/）；没有安装、没有带副作用的构建、没有 commit、没有格式化，只有只读分析。
• 计划的下游消费方式：execute <plan>变体会在隔离 worktree 中派出执行子代理落地计划，再以review-animations的标准（STANDARDS.md 中同一套数值与规则）审查其 diff 并给出结论；reconcile变体则负责让plans/与演进中的代码保持同步。

结语

PLAN-TEMPLATE 是一份把"审美判断"编码为"可执行规格"的模板：头部元数据负责追踪与防漂移，Problem/Target 负责把问题与终态钉死，Repo conventions 保证计划贴合仓库既有写法，Steps 给出可复制的编辑序列，Boundaries 限制自由裁量，Verification 同时提供机器检查与慢速手感检查。它的核心价值在于：让强模型把判断力花在审计与规格上，让任何模型都能不带审美地忠实执行。配合 AUDIT.md 的权威数值目录与 SKILL.md 的只读工作流，这套"审计-计划-执行-复核"的流水线就能在保持手感标准的同时，把动画改进规模化地交付出去。

• AI 技能
• 设计系统
• 前端