Pack 与基础动效：从哪里开始
基础动效解决一个行为，Pack 把多个行为组织成真实产品瞬间。两者都可独立使用，也能互相拆解和组合。
Product Moment 和 Motion Primitive 是两种平级的设计入口。前者交付一段真实产品交互，后者交付一个可复用行为和它的边界。选择起点取决于问题的完整度、现有界面的约束和你需要保留多少设计控制力。
当界面已经有清楚的状态流程时，从 Pack 开始；当你只需要解决一个局部行为时，从基础动效开始。
实施路径
- 01
先看场景是否完整
保存、发布、删除这类含有多段状态的流程，可以直接借用 Pack 的结构。
- 02
再看需要改到多深
只改进入方式或曲线时，直接打开对应基础动效会更轻。
- 03
回到基础规则校验
采用 Pack 后，仍检查时长、空间连续性和减弱动效，确保它适配你的界面。
理解两种入口各自解决什么
Motion Primitive 解决一个清楚的行为问题，例如淡入、滑入、交错、缓动、按压反馈或减弱动效。它适合团队已经知道对象、状态和界面结构，只需要为某个局部变化选择合适规则的时刻。Primitive 的价值在于边界清楚：它告诉你什么时候适合用、参数如何调整、会和哪些相近动作混淆、如何在低动态模式下保持意义。它让局部决定可被复用，也让设计系统拥有共同语言。
Product Moment 解决一个完整场景，例如保存确认、删除确认、筛选结果、权限变更或审批请求。它把触发器、等待、结果、关联对象和恢复路径组织成一段可运行的交互。Moment 的价值在于让人先看到整体：保存不只是一条 press feedback，还是按钮、状态标记、内容状态和可能的失败提示共同构成的结果。它适合需求已经带有多个状态和多个参与对象，团队希望快速拥有一个经过推敲的骨架。
按问题完整度选择起点
先问问题能否用一句状态转换说清。若答案是“按钮变为已保存”“一张卡片从当前位置进入”“数字在原位更新”，从 Primitive 开始通常更有效，因为你需要的主要是一个局部规则。若答案包含“用户提交后等待服务端、页面顶部状态改变、列表新增记录、失败后能重试”，它已经是一个 Moment。此时从完整场景开始能帮助团队发现遗漏的状态，再回到其中的基础动效做细调。
再问是否已有可靠的产品结构。一个成熟的设置页可能已经有清楚的字段、保存栏和状态区，团队只需为错误或确认加上局部反馈；一个新工作流则往往缺少状态区、恢复路径和信息层级，直接选择 Pack 会更快得到可讨论的整体。选择 Pack 并不意味着照搬视觉。把它当作交互的状态模板，保留业务对象、品牌语言和现有导航结构；选择 Primitive 也不意味着只做一个孤立效果，它仍要回到页面里验证焦点、空间关系和可访问性。
从 Pack 拆出基础规则，再把规则装回界面
采用 Pack 的高效方式是先保留它的状态序列，再逐项检查其中的基础动作。以保存确认举例：输入反馈告诉用户点击已收到，状态文本切换告诉用户正在保存或已保存，短暂的加载循环只在等待期间出现，顶部状态标记和文档内容在完成时同步更新。团队可以保留这条因果链，同时把 press 的力度、文本切换的速度、状态标记的位置换成自己的设计系统。Pack 提供的是结构，Primitive 提供的是每个结构节点的精确控制。
反向使用也很重要。当团队从一个 Primitive 开始，例如只想给筛选后的卡片增加淡入，应该顺手问：结果数量是否也要更新？旧卡片如何离开？用户是否需要知道筛选条件仍然生效？如果回答引入了多个对象和连续状态，就值得打开 Filter results 这样的 Moment 作为检查表。这个来回过程让组件库和产品瞬间互相供给：基础规则避免 Pack 变成黑盒，真实场景避免 Primitive 漂在脱离业务的演示里。
用控制范围决定定制深度
定制可以分成三层。第一层是换内容：名称、颜色、文案、数据与品牌语气改变，交互状态保持；第二层是换规则：时长、曲线、出现顺序、撤销窗口与低动态策略改变；第三层是换结构：触发器、参与对象、状态图和恢复路径改变。第一层通常直接采用 Pack 最省力，第二层需要回到关联 Primitives 做精调，第三层更适合从场景规格重新开始。提前说清处在哪一层，能避免“只改一点”最后变成重写整套交互。
控制范围还包括技术边界。若产品只能使用原生 HTML、CSS 和少量 JavaScript，应选择能在这些约束内稳定运行的 Pack，并确认代码的状态源和事件绑定容易迁移；若组件本身是现有设计系统的一部分，Primitive 的 CSS 变量、参数范围和无障碍规则可能更适合直接嵌入。无论从哪里开始，最终都要保留可复制的实现说明、浏览器兼容性判断和 `prefers-reduced-motion` 路径。可移植性本身就是设计质量的一部分。
建立两条目录之间的工作流
实际工作中可以采用一个简单循环：先用一句话描述产品场景；判断它是局部行为还是完整流程；从对应目录打开一个参考；把参考中的状态、参数和限制写入当前项目；在真实界面里预览；把经过验证的改动回馈为新的 Pack 候选或 Primitive 说明。这个循环让内容库持续贴近真实问题，也避免团队把目录当成一次性灵感板。每次复用都留下新的判断证据。
评审时同时看两件事：这段交互是否帮助用户理解当前任务，这条基础规则是否还能在别处复用。前一个问题保护产品语义，后一个问题保护系统质量。若一个 Pack 被多次拆出同样的基础动作，那个动作应当获得更完整的 Primitive 文档；若多个 Primitive 总是被同一种业务场景组合，那个场景应当晋升为 Pack。这样网站的信息架构会随真实使用演化，用户也会逐渐看到一套既有审美又能落地的动效语言。
选择入口清单
- 用一句话判断问题范围单一状态变化优先看 Primitive；多状态流程优先看 Pack。
- 检查现有页面是否已有可靠结构已有状态区和导航时更容易嵌入基础规则。
- 明确内容、规则或结构哪一层需要改不同层级对应不同的复用起点与改造成本。
- 从 Pack 追溯关联基础动效保留整体状态链，同时获得局部参数控制。
- 把重复出现的真实模式回馈目录反复组合的 Primitive 可形成 Pack，反复拆出的动作可扩展 Primitive。
案例：筛选结果该从 Pack 还是 Primitive 开始
团队最初只想让筛选后的卡片淡入，随后发现用户还要追踪筛选条件、命中数量、旧内容离开和新内容到达。
Scenario: status filter changes in a resource library
Start: Filter results Pack
Keep: active filter, result count, stable list container, empty state
Tune primitives: crossfade for replacement; stagger for first three new rows; duration 160–220ms
Reduced motion: update count and rows in place, retain live-region result announcement需求包含多个对象和连续状态，因此从 Filter results Pack 开始更完整。团队随后只调整其中的 crossfade、stagger 和 duration，而无需重新发明筛选语义。