设计交付工程时：用结构化规格、交接包…

当设计需要进入工程、跨职能对齐或把决策文档化以避免返工时，产出可实现的规格、资源清单和测试计划。

适用场景

解决思路

1. 把设计工作转化为可执行、可直接实现的文档；产出结构化规格、资源包、测试计划和干系人演示，确保设计意图存活到生产环境。
2. 每个规格都追溯回战略意图：解释功能为何存在、验证什么假设、服务什么用户需求（来自 /strategize）。
3. 用研究发现作为用例证据：引用真实用户原话、观察到的行为和已验证痛点，使规格准确且有说服力（来自 /investigate）。
4. 把系统架构作为约束：纳入服务依赖、数据流和技术限制，明确哪些可实现、哪些需要工程讨论（来自 /blueprint）。
5. 记录要实现的体验流：屏幕序列、交互过渡、状态变化；/journey 设计体验，specify 将其文档化。
6. 把信息架构作为导航规格的骨架：来自 /organize 的分类、层级和标签决策。
7. 把文案工作直接转化为文案矩阵：来自 /articulate 的 voice、tone 和内容策略决策变成具体字符串。
8. 把边界情况分析纳入规格：逐屏记录错误状态、失败模式、边界条件和恢复模式（来自 /fortify）。
9. 把无障碍要求织入每个屏幕规格：ARIA 标签、键盘导航、颜色对比度、屏幕阅读器行为（来自 /include）。
10. 用评估结果识别规格缺口：启发式违规、可用性问题和反模式标记成为交接前要解决的问题（来自 /evaluate）。
11. 用成功指标定义测试计划标准：每个功能规格包含成功标准、测量方式和埋点需求（来自 /measure）。
12. 当规格暴露更深层问题（边界情况不断增多、设计在真实条件下脆弱、pending questions 持续增长，或用户说 “sit with this”、“brainstorm”、“what could go wrong that nobody has imagined?”）时，调用 /philosopher 思考未预见的失败场景以及规格是否在文档化正确的东西。
13. 编写全面的逐屏或逐状态规格，记录视觉设计的具体尺寸、颜色、字体、间距。
14. 在规格中记录交互逻辑：什么触发什么、顺序、条件。
15. 在规格中记录文案：精确文本，以及不同上下文、市场、边界情况下的变体。
16. 在规格中记录状态：default、hover、active、error、loading、empty、success，均从视觉和逻辑上文档化。
17. 在规格中记录约束：设备尺寸、性能要求、无障碍需求。
18. 输出活文档（HTML 或 markdown），让工程师实现时无需猜测。
19. 结构化交接交付物，让工程清楚要构建什么以及为什么。
20. 明确所有权：谁在何时决定了什么。
21. 提供问题背景：解决什么用户需求或业务问题。
22. 说明设计方法：考虑过的约束、被拒绝的替代方案及原因。
23. 使用具体而非泛化的用例：能暴露边界情况的真实用户场景。
24. 整理资源：所有文件已组织、命名、版本化，并附使用说明。
25. 提供测试标准：成功指标和面向不同受众的测试计划。
26. 在一个地方记录所有文案变体。
27. 区分主要文案、次要文案和微文案（标签、提示、错误、空状态）。
28. 记录市场变体：语气变化、文化考虑、监管语言。
29. 记录边界情况：字符限制、长字符串、极短字符串、数字边界情况。
30. 记录 A/B 测试变体：明确测试的文案改动及成功标准。
31. 在合适时产出交互式 HTML 规格。
32. 在交互式 HTML 规格中内联展示设计并配解释文本。
33. 在交互式 HTML 规格中链接相关屏幕和决策。
34. 在交互式 HTML 规格中包含可折叠参考区（组件规格、文案矩阵、测试计划）。
35. 让交互式 HTML 规格自包含，可在任何浏览器查看，无外部依赖。
36. 写具体而非泛化的用例。
37. 示例：'首次用户创建账户' vs '用户登录'；'支付时网络超时' vs '错误状态'；'用户购物车有 200+ 件商品' vs '用户购物车有商品'。
38. 记录每种情况下设计如何表现、出现什么文案、接下来发生什么。
39. 组织能对齐跨职能团队的演示。
40. 在演示中包含问题陈述（来自 /strategize）。
41. 在演示中包含设计方法和考虑过的约束。
42. 在演示中包含关键决策以及有意不做的事。
43. 在演示中包含测试计划：测量什么以及为什么（来自 /measure）。
44. 在演示中包含开放问题：仍需解决什么。
45. 在演示中包含时间线和依赖。
46. 编写把观察结果与决策者配对的测试计划。
47. 明确谁需要看这项工作（PM、工程负责人、CEO？）。
48. 定义成功是什么样：具体、可衡量的结果（连接到 /measure 的 GSM 链）。
49. 说明我们在学习什么以及为什么学习。
50. 说明结果如何反馈到设计迭代。
51. 按综合交接模板写文档：Ownership & Context 包含 Owner、Created、Status、Design document version。
52. Problem & User Need：用 1-2 段说明解决什么问题、为谁、为什么现在。
53. Design Approach：包含 Constraints considered、Design strategy、What we did NOT do (and why)。
54. UX Questions Answered：列出该规格解决的具体设计问题，例如用户如何知道操作成功？API 无结果时发生什么？如何处理超长标题？
55. Ethical Review：对照 Intent 反模式目录检查；包含 Patterns reviewed、Potential concerns、Design intent documentation、Dark pattern clearance。
56. Measurement：包含 Primary success metric（来自 GSM 映射）、Counter-metrics、Instrumentation needs、Learning plan（day 1、week 1、month 1 何时检查指标）。
57. Design Specification：对每个 Screen 写 Intent（为什么存在、服务什么用户需求、移除会怎样）。
58. Design Specification：对每个 Screen 写 Behavior（用户看到什么、能做什么）。
59. Design Specification：对每个 Screen 写 Layout & Styling（具体尺寸、间距、颜色、字体、视觉层级和网格位置）。
60. Design Specification：对每个 Screen 写 Copy（Headline、Description、Button label、Error state、Empty state 的精确文案）。
61. Design Specification：对每个 Screen 写 Interaction Logic（On load、On user action X、On error Y 的预期结果和兜底行为与提示）。
62. Design Specification：对每个 Screen 写 Accessibility（ARIA labels、Keyboard navigation、Color contrast）。
63. Design Specification：对每个 Screen 写 States（default、hover、active、error、loading、empty 的视觉和文案文档）。
64. Use Cases & Variants：按具体场景写用户旅程、每步所见、出现的文案、成功/失败后发生什么。
65. Copy Matrix：用表格列出 Element、Primary、Edge Case 1、Edge Case 2、Market Variant (DE)、A/B Test Variant。
66. Test Plan：按受众（PM / Engineering / End User）写 What we're testing、Success looks like、How we measure it。
67. Pending Questions：分别列出 Design Questions 和 Engineering Questions。
68. Assets & Deliverables：Design files 写 Figma 文件名和链接、要参考的 artboards/pages。
69. Assets & Deliverables：Handoff package contents 包含 Design spec、Design files（Figma 链接）、Copy matrix、Test plan 及其他资源。
70. Assets & Deliverables：File naming & organization 说明文件如何命名和组织在 assets/ 中，以及版本控制方式。
71. Appendix：附参考材料，如 component specs、design system tokens、brand guidelines 摘录、采用的无障碍标准等。
72. 并非每次交接都需要所有章节；根据项目与受众取用所需部分。
73. 交接完成前检查：每个屏幕都有文档化 intent——为何存在、服务什么用户需求（不要做 real estate tour）。
74. 检查所有屏幕和状态都已视觉化文档化。
75. 检查所有文案都已写出（不要留 TBD 之类占位符）。
76. 检查所有变体（市场、边界情况、A/B 测试）都已文档化。
77. 检查边界情况已处理（空状态、错误、长内容、网络延迟）。
78. 检查 pending questions 已明确标记（设计 + 工程）。
79. 检查 ownership 已说明（谁、何时、状态）。
80. 检查测试计划已包含具体成功标准。
81. 检查资源已组织和命名，并文档化其位置。
82. 检查开放问题不阻塞工程；它们被标记为并行解决。
83. 检查文案矩阵包含实现所需的所有变体。
84. 检查相关处已指定交互时序（例如 toast 持续时间、动画速度、debounce 间隔）。
85. 检查 A/B 测试：两个变体并排文档化，并明确标出差异。
86. 检查伦理审查已完成：设计已对照反模式目录检查。
87. 检查 Measurement 部分已完成：成功指标、反指标和埋点需求已文档化。
88. Intent over inventory：不要做 real estate tour——只描述屏幕有什么而不解释为什么。
89. 规格中每个元素都应回答：为什么在这里？为用户解决什么问题？移除会怎样？
90. 反例：'On load, display “Create your first project” in Headline 2 (24px, Inter Medium).' 正例：'On load, display “Create your first project”——可用性测试中的新用户无法识别起始操作。此标题作为主要 onboarding cue，使用 Headline 2 建立为页面核心指令。'
91. 如果无法说清某个设计决策背后的 intent，就把它标记为 open question，而不是当作已确定事项文档化。
92. Structured and thorough, never bloated：只说重要内容，省略不连接用户需求或设计 intent 的泛化描述。
93. Clear cross-functional ownership：明确说明谁做了什么决策以及为什么。
94. 把约束作为设计输入，而不是限制来标注。
95. Raise open questions explicitly：不要隐藏不确定性，要标记出来。
96. 区分“设计需要决定” vs “工程需要决定” vs “需要数据/研究”。
97. Visual + logical rules：先展示设计，再解释其后的推理。
98. 让文案可测试、可实现。
99. Treat constraints as design inputs：性能要求、无障碍需求、品牌指南都会塑造规格，因此要让它们可见。
100. 本技能只文档化设计决策，不替设计师做决策。
101. 组织和结构化已有设计工作以供实现。
102. 编写综合规格、测试计划和资源包。
103. 产出跨职能演示和对齐文档。
104. 透明地标记开放问题和依赖。
105. 映射边界情况并编写文案变体。
106. 对照 Intent 的反模式目录进行伦理审查。
107. 把规格连接到 /measure 的测量框架。

适用边界 · 注意事项

• 没有 Intent 技能系统时，本技能中引用的 /strategize、/investigate、/blueprint、/journey、/organize、/articulate、/fortify、/include、/evaluate、/measure、/philosopher 等命令不可用；需先用等价流程产出这些输入。
• 不要用它做设计决策、设计新功能或进行用户研究；这些分别属于设计师、/strategize 或 /journey、/investigate。
• 不要用它写代码、给出实现估时、从头定义成功指标或评估 UX 质量；这些分别属于工程、/measure 或 /evaluate。