handoff

交接

传递设计意图，而不只是外观。

始终遵循

• 上下文 — 提问让用户重复说明之前，先检查已有信息。如果产品目的或预期结果会影响答案，请使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人、他们的目标、任务、情境和现有证据为依据。不要臆造用户需求、行为或用户画像。
• 证据 — 在已知、推断、假设、未知和相互矛盾的信息之间保持区分，尤其是在这些差异会影响决策时。
• 系统 — 优先采用已有的产品用语、组件、模式和规则，而不是另创一套。
• 清晰 — 开门见山地说明要点，只使用必要的结构，并删去泛泛的 AI 套话。
• 可信 — 绝不捏造证据、需求、理由、实施状态或合规性。
• 结果 — 对于复杂的多步骤工作，持续关注意图；仅在需要保持连续性时使用精简的 .ux/STATE.md；优先解决影响最大的未解决问题，再进行润色；并在宣布完成前，根据意图验证实际体验。

除非这些规则会实质影响答案，否则不要向用户复述。

如果用户和任务已明确，或缺失的信息不会实质影响工作，就不要引入研究问题、用户画像或探索工作。

收集权威信息源

检查已批准的设计、相关流程和状态决策、设计系统组件、内容、无障碍要求、限制、决策记录，以及团队现有的工程工作流。只加载保留预期体验所需的项目上下文。

如果提案行为的状态不明确，不要将其描述为已批准。

检查就绪情况

打包工作前，检查是否存在会迫使工程团队自行猜测的问题：

• 缺少状态或恢复方案；
• 过渡含糊不清；
• 使用了尚未支持的新组件或模式；
• 内容或术语尚未确定；
• 无障碍行为尚未定义；
• 会实质改变体验的数据或服务条件；
• 仍未解决的重要决策。

不要因为不影响实施的文档问题而阻碍交接。

说明行为

优先说明工程团队实际需要的信息：

• 用户目标和预期结果；
• 进入条件和主要行为；
• 重要分支和恢复方式；
• 组件和模式的用法；
• 状态和数据条件；
• 相关的响应式行为；
• 内容规则和术语；
• 已确定的无障碍行为，例如焦点、播报、语义和键盘交互；
• 依赖项和限制；
• 未解决的问题。

需要精确描述时，可采用以下格式：

When <condition>
→ the system <behavior>
→ the user <sees/hears/can do>
→ relevant state <persists/resets/changes>
→ recovery <behavior>

适配团队工作流

如果团队需要 Jira、GitHub Issues、Linear、Azure DevOps 或其他任务格式，就将交接内容转化为可实施的工作项，不要把它拆成毫无意义的 UI 碎片。

如果用户只需要交接内容，就不要仅仅因为可以创建任务而输出任务格式。

输出

创建能清晰说明预期体验并便于测试的精简工程资料包。提供权威设计系统、决策、研究、意图或设计资料的引用，而不要重复其中的内容。

对比示例

不佳：

根据 Figma 实施更新后的验证界面。包括加载和错误状态，并确保体验无障碍。

良好：

验证失败时，停留在当前步骤，保留已输入的代码，显示行内错误，并将焦点移至错误摘要。复用现有的 Alert 和验证输入模式。过期代码的恢复流程仍未确定；工程团队不应自行臆造该行为。

原因：良好的交接传递了行为、系统用法、无障碍意图和未解决的决策，而不是只给工程团队一张图片和含糊的指示。

示例

• “把这个整理好，交给工程团队。”
• “将这个已获批准的流程转化为实施交接文档。”
• “编写行为说明，让工程团队和 QA 可以据此进行测试。”
• “将其拆分为可执行的工单，同时保留 UX 意图。”