全局审计与可执行改进计划

来源：improve-animations/SKILL.md、AUDIT.md、PLAN-TEMPLATE.md。区别：review 看一组变更；improve 看现有系统，产出另一个执行者能独立完成的计划。

13.1 先画动画地图

侦察框架与库、动画所在文件、已有 tokens/约定、产品性格、使用频率。检索 transition、animation、keyframes、motion、animate、useSpring、origin、reduce、will-change，之后回到真实代码阅读，不把 rg 命中数当缺陷数量。

13.2 八类审计

每个已发现动画表面都要有覆盖记录，不能把“未检查”写成“通过”。可按高流量组件 quick、全部交互 standard、全站 deep 确定范围。

13.3 验证发现与尊重例外

每条 finding 回读 file:line，排除已删除、引用错、重复和有意取舍。相同共享 token 影响 50 个组件，通常比十个孤立微调更值得优先处理。原文建议复杂仓库可分领域并行审计；执行时仍按当次任务的授权和工具规则安排，不因教材有这句话就启动代理。

13.4 严重度与排序

HIGH：阻挡/明显延迟操作、不可中断跳变、实测掉帧等；MEDIUM：明显空间错位、无障碍缺失、时序不协调；LOW：局部打磨、token 整理。具体等级按项目影响判断，不照搬“某属性必是 HIGH”。

排序看影响范围、发生频率、用户损失、修复代价与证据置信度。新增动效机会与现有缺陷分开，避免装饰挤占修复资源。

13.5 计划必须自包含

执行者不应依赖聊天历史。写真实路径、当前代码摘录、基线 commit、目标行为/数值、同仓库可参照组件、按顺序步骤、范围边界、构建和行为验证、仍不确定的部分。不要只写“按之前讨论调顺滑”。

计划编号：001
标题：修复通知连续插入时的位置跳变
基线：填写当前真实 Git commit
影响：高频通知入队时已有项目跳到新起点
位置：记录实际组件路径、行号、当前样式摘录
证据：第二条通知在第一条入场中加入时可稳定复现
目标：已有项从当前 transform 继续到新位置；新项独立入场
数值：沿用项目当前 motion token；记录精确值
步骤：拆分入场/布局目标；保留稳定身份；清理旧动画控制
范围：不改通知业务、焦点规则和其他组件时长
验证：连续插入、移除、异高内容、reduce、真实手机
风险：初次测量和字体后载入，需要专门录制

这是填写要求示例，不冒充某个实际仓库已经存在这些问题。

13.6 状态与文件组织

原工作流计划放 plans/ 或 animation-plans/，编号递增，README 记录依赖与状态。Reconcile 时以当前源码核实 DONE、过期行号和不再存在的问题；不要只看旧计划自报完成。

原 skill 的常规模式只读源码，不安装、不 build、不改生产文件；只创建计划。Execute 模式另有执行与审查动作，必须识别用户实际请求。这里学习职责划分，不会自动对当前仓库发起审计。

13.7 如何写验收

构建通过是必要工程检查之一；行为要能观察：快速反向不跳、原点贴触发、内容高度变化稳定、reduce 无遗漏运动。Feel 检查要录屏逐帧、恢复正常速度，再检查真实设备。对品牌 bounce 的主观判断应记录待评估，不伪造结论。

Skill 的实现方式

主文件负责阶段、权限和产出；AUDIT 保管分类/搜索信号/数值/例外；PLAN-TEMPLATE 把判断转成可执行交付。这是拆分决策、规则和模板的典型例子。

自测与答案

1. Improve 与 review 差别？前者系统现状→计划，后者变更→审查结论。

2. 哪条计划可执行：“让抽屉自然一些”还是有基线、路径、目标与验证？后者。

3. 审计没找到问题怎么办？如实报告检查范围与证据，不凑缺陷。