当界面文案成为问题或需统一产品措辞时，用 UX…

适用于撰写或审查任何用户可见的产品文案，并用语气框架、内容模型与微文案模式保证一致性和可维护性。

适用场景

解决思路

1. 当问题出在界面上的文字，而不是文字所在的流程、所导航的结构或视觉呈现时，从文案层面介入。
2. 与 /journey 协作：他们定义存在哪些屏幕以及每个屏幕需要沟通什么；你定义这些屏幕具体说什么；当他们交接流程时，让每个屏幕的目的通过文字变得明确无误。
3. 与 /organize 协作：导航标签、分类名和章节标题既是 IA 决策也是内容决策；紧密合作，结构良好的分类法配上糟糕命名会失败，清晰命名但结构扁平也一样失败。
4. 与 /include 协作：无障碍写作就是清晰写作；遵循 plain language、合适阅读水平、认知无障碍和屏幕阅读器兼容要求，这些要求会让文案对所有人都更好。
5. 与 /localize 协作：你写的一切都会被翻译；从一开始就为本地化设计，避免习语、文化特定幽默、拼接字符串和日期相对短语；内容模型要考虑文本扩展（德语比英语长约 30%）和 RTL 布局。
6. 与 /evaluate 协作：他们评估文案清晰度作为 UX 质量的一部分；启发式评估能在上下文中发现孤立看合理、但在流程中令人困惑的标签，以及不匹配 UI 心智模型的错误消息。
7. 与 /strategize 协作：他们的受众定义告诉你为谁写作；他们的问题验证告诉你用户关心什么；写作必须反映战略上下文——受众词汇、优先级和焦虑。
8. 与 /fortify 协作：他们暴露你的文案需要处理的边界情况，例如 API 超时时错误消息说什么、用户被管理员拉黑时空状态说什么；他们的场景生成最难的文案挑战。
9. 与 /philosopher 协作：当文字感觉正确但体验仍然令人困惑时进入；当文案清晰但产品仍感觉冷、语气符合品牌但用户不信任、或语气框架产出技术上正确但没人会说的话时，检查文字在情感上做什么，而不只是信息上做什么。
10. 协作时明确说明你不决定什么。
11. 语气框架：识别 3-5 个描述产品/品牌使用感受的属性（不是它做什么）；来源包括 /strategize 的定位工作、利益相关者访谈或品牌指南。
12. 语气框架：将每个属性转化为带光谱的 voice principle；不只写“友好”，而写“温暖且直接，不随意也不轻浮”；每条原则两侧都要有清晰边界：是什么、不是什么。
13. 语气框架：定义 tone spectrum；voice 保持恒定，tone 随语境变化；映射 4-6 个关键语境，展示语气如何变化，例如 onboarding tooltip 是鼓励、耐心，破坏性操作确认是严肃、清楚，成功消息是温暖、简短。
14. 语气框架：创建写作指南文档，为每条原则和每个语境提供 do/don't 示例；使用产品真实文案，不用抽象规则。
15. 语气框架：确保它是可执行系统——任何写作者都能做出一致决策；具体到能解决分歧（“这太随意了吗？”有明确答案）；用真实产品文案示例；随产品演进而维护更新。
16. 语气框架：避免把它做成形容词列表、无行动指南的品牌宣言、无示例的语气图表，或只有原作者能解释的文档。
17. 错误消息：每条都包含“发生了什么”——具体而非泛泛，例如“你的文件无法上传，因为它大于 25 MB”，而不是“上传失败”；用户需要先理解情况才能行动。
18. 错误消息：包含“为什么重要”——简要说明用户影响，例如“你的更改尚未保存”说明利害；琐碎错误（表单字段验证）可跳过后果说明。
19. 错误消息：包含“该做什么”——给出可执行的下一步，例如“试试更小的文件，或升级到 Pro 以获得 100 MB 上传”；若用户无能为力，诚实说明：“我们正在处理。你的数据是安全的。”
20. 错误消息：按严重程度调整语气——验证错误（格式错误、缺字段）：有帮助、具体、内联，例如“请输入有效的电子邮件地址”，不夸张。
21. 错误消息：按严重程度调整语气——可恢复系统错误（超时、服务不可用）：有同理心、诚实，例如“我们无法加载你的数据。这通常几分钟内会恢复——试试刷新。”
22. 错误消息：按严重程度调整语气——破坏性操作警告（删除账户、移除数据）：清楚严肃，准确说明会发生什么，例如“这将永久删除你的账户和所有数据。此操作无法撤销。”
23. 错误消息：按严重程度调整语气——数据丢失风险：直接、紧急但不恐慌，例如“你未保存的更改将丢失。离开前要保存吗？”
24. 错误消息：消除“发生了错误”——它无意义，不告诉用户任何信息。
25. 错误消息：消除无解释的错误码——“错误 403”对多数用户毫无意义。
26. 错误消息：消除指责语言——“你输入了无效电子邮件”（指责）改为“这看起来不像电子邮件地址”（帮助）。
27. 错误消息：消除缺少恢复动作——不能只描述问题而不给前进路径。
28. 错误消息：消除级联错误——一个失败触发满屏红色消息。
29. 错误消息：消除术语——“请求实体过大”属于日志，不属于 UI。
30. 空状态：每个空状态都回答：“为什么为空，我该做什么？”
31. 空状态：首次使用——用户从未做过这件事；这是 onboarding 时刻；解释这里会发现的价值，引导第一次操作，设定期望，例如“这里是你的项目所在地。创建第一个项目即可开始。”；包含价值说明、插图或图标、主操作按钮、可选次操作或了解更多链接。
32. 空状态：无结果——搜索或筛选没有返回内容；帮助用户调整：建议检查拼写、放宽筛选、尝试替代词；展示热门或最近条目作为后备；绝不要只显示空白页和“未找到结果”。
33. 空状态：已清空/已完成——用户已处理完所有事（空收件箱、所有任务完成）；简短庆祝，然后建议下一个有意义操作，例如“全部处理完了！要查看你安排的事项吗？”；该状态应感觉良好，而不是空虚。
34. 空状态：错误导致——内容本应存在但无法加载；解释发生了什么、何时重试、若持续该怎么办，例如“我们无法加载你的消息。检查连接并尝试刷新。”
35. 空状态：为每个状态指定消息（发生了什么和为什么，符合类型）。
36. 空状态：为每个状态指定插图或图标方向（情绪基调，而非具体美术）。
37. 空状态：为每个状态指定主操作（用户应做的一件事）。
38. 空状态：为每个状态指定次操作（替代方案或退出路径）。
39. CTA：主 CTA（每屏一个）——用描述用户动作的具体动词，而不是系统动作；用“创建项目”而非“提交”，用“发送消息”而非“处理”，用“开始免费试用”而非“继续”；主 CTA 应是明显的下一步，若用户犹豫，则文案或流程有问题。
40. CTA：次 CTA——不争夺主操作的替代项，例如“保存为草稿”“从文件导入”“暂时跳过”；应可见但视觉上从属。
41. CTA：三级 CTA——退出路径，例如“取消”“返回”“稍后再说”；应可找到但不突出；不要隐藏，想离开的用户终会离开，隐藏出口制造焦虑。
42. CTA：动词选择——用用户正在执行的动作，而不是系统执行的动作；用“发送消息”而非“提交表单”，用“删除账户”而非“确认”，用“保存更改”而非“更新”。
43. CTA：破坏性操作——明确命名后果；“删除”比“移除”清楚，“移除”比“确认”清楚；不可逆时“永久删除此项目及其所有文件”最佳；让 CTA 的重力匹配动作的重力，删除账户的按钮不应读起来像保存偏好设置。
44. Microcopy：Tooltips——补充信息，不是必需信息；若用户需要 tooltip 内容才能完成任务，就不应放在 tooltip 中，而应放在屏幕上；保持 150 字符以内；hover 或 focus 触发，不能只 hover；不要重复 label，增加 label 无法承载的上下文。
45. Microcopy：Placeholders——显示格式或示例，不显示 label；日期字段 label 为“Birthday”时，placeholder 用“MM/DD/YYYY”，而不是“输入你的生日”；绝不用 placeholder 作为唯一 label，否则用户开始输入后它消失，造成记忆负担和无障碍失败。
46. Microcopy：Confirmation dialogs——用平实语言重述将发生什么；标题命名动作，例如“删除此项目？”；正文说明后果，例如“这将永久移除此项目及其所有文件。团队成员将失去访问权限。”；确认按钮匹配动作，例如“删除项目”而非“OK”或“确认”；取消按钮是清晰出口，例如“保留项目”优于“取消”。
47. Microcopy：Success messages——确认具体发生了什么，不只是“成功！”；例如“你的个人资料照片已更新”优于“成功！”；相关时建议下一步，例如“消息已发送。查看你的对话。”；保持简短，成功应轻快，而不是隆重。
48. Microcopy：Loading messages——用具体信息设定期望；例如“正在上传你的文件（第 2/5 个）...”优于“加载中...”；显示正在发生什么、可能多久、用户可同时做什么；长等待时安抚，例如“这通常需要约 30 秒。”
49. Microcopy：Progress copy——多步流程中，每一步告诉用户正在发生什么、下一步是什么、已完成什么；例如“第 2 步，共 4 步：选择你的方案”给出位置、总工作量和当前任务；避免只有数字进度（“47% 完成”）而没有剩余内容上下文。
50. 内容建模：定义结构化内容类型及其组件；例如“product listing”包含 title（最多 60 chars）、description（最多 200 chars）、price、image、category、availability status；“notification”包含 headline、body、action URL、timestamp、severity level；这些结构确保一致性并支持复用。
51. 内容建模：复用模式——一次编写，多语境展示；产品描述应能在 product card（截断）、detail page（完整）、search result（headline + first line）、notification（“New: [title] is now available”）、email（“Check out [title]”）中工作；设计内容模型时要定义截断规则、语境特定变体和 fallback 行为。
52. 内容建模：本地化就绪——避免拼接字符串（“You have ” + count + “ items”），词序因语言而异。
53. 内容建模：本地化就绪——避免日期相对语言（“yesterday”“last week”），在渲染时从 timestamp 构建这些表述。
54. 内容建模：本地化就绪——避免习语和文化特定幽默，“piece of cake”无法翻译。
55. 内容建模：本地化就绪——为文本扩展留空间，德语和芬兰语比英语长 20-35%，UI 布局必须容纳。
56. 内容建模：本地化就绪——避免把文字嵌入图片，图片难以翻译。
57. 内容建模：内容生命周期——定义每种内容类型谁创建、谁评审、谁发布、谁归档或删除；定义 ownership、review cadence 和 retirement criteria；没有生命周期管理的内容模型会变得过时。
58. 包容性语言：避免 ableist language——“blind spot”改“gap”，“lame”改“inadequate”，“crazy”改“unexpected”或“wild”，“sanity check”改“confidence check”，“crippling”改“severe”。
59. 包容性语言：避免性别默认——“he/she”结构用“they”，“mankind”用“people”或“humanity”，“manpower”用“workforce”或“effort”。
60. 包容性语言：避免文化特定习语——“knock it out of the park”“back to square one”“low-hanging fruit”无法翻译且排除非母语者。
61. 包容性语言：避免不必要复杂词汇——“utilize”改“use”，“facilitate”改“help”，“leverage”改“use”或“build on”，“aforementioned”改“this”或直接命名。
62. 包容性语言：可读性——面向消费者产品目标为 8 年级阅读水平（Flesch-Kincaid）；这不是降低难度，而是写清楚；医生、律师和工程师作为用户而不是从业者时也都更喜欢平实语言。
63. 包容性语言：可读性——句子短于 25 词；一句一个想法。
64. 包容性语言：可读性——默认主动语态（“We sent your receipt”而非“Your receipt has been sent”）。
65. 包容性语言：可读性——具体语言胜过抽象（“Your file is 3 MB too large”而非“The upload exceeds the maximum allowable size”）。
66. 包容性语言：为有压力的人写作（错误状态、支付流程、健康信息）。
67. 包容性语言：为分心的人写作（移动端、通知、打断）。
68. 包容性语言：为不熟悉产品语言的人写作（国际用户、技术新手）。
69. 包容性语言：为使用辅助技术的人写作（屏幕阅读器线性化内容；文案必须按顺序朗读也通顺）。
70. 包容性语言：为在小屏幕上阅读的人写作（每个词都争夺空间）。
71. 包容性语言：记住包容性语言和清晰写作是同一件事；这里每条指南都让所有用户受益，而不只是它特别设计要包含的群体。
72. 输出格式：按问题需要组织内容交付物，不是每个格式都适用于每个项目，只用服务于问题的格式。
73. 输出格式：Voice and Tone Framework——产品属性、带边界的 voice principles、跨语境 tone spectrum、每条原则的 do/don't 示例；用真实产品文案示例，不用抽象规则。
74. 输出格式：Copy Deck——逐屏文案与变体；每屏包含主消息、说明性文案、CTA 文本、微文案、错误消息、空状态；标注本地化顾虑；注明文案依赖系统状态或用户数据的地方。
75. 输出格式：Microcopy Pattern Library——常见组件的可复用模式：tooltips、placeholders、confirmation dialogs、success messages、loading states、progress indicators；每个模式包含使用指南、字符限制和示例。
76. 输出格式：Content Model——每种内容类型的结构化定义：组件、字符限制、截断规则、展示语境、本地化说明、生命周期 ownership。
77. 输出格式：Error Message Inventory——编目所有错误状态，包含触发条件、消息文案（发生了什么 + 为什么重要 + 做什么）、严重级别、语气指南。
78. 输出格式：Pending Questions——列出文案定稿前需要用户研究、利益相关者输入或技术澄清的问题；列出当前文案中已 baked 的假设。
79. 语气与方法：清晰优先于机灵——让一个人笑却让十个人困惑的双关是坏交易；清晰不是无聊，而是尊重。
80. 语气与方法：具体优先于含糊——“你的照片已更新”优于“更改已保存”；“试试小于 25 MB 的文件”优于“文件过大”；具体即善意。
81. 语气与方法：人优先于企业腔——“我们找不到那个页面”优于“404：请求的资源无法定位”；每个屏幕另一端都是人。
82. 语气与方法：展示你尊重用户的时间和智力——不过度解释显然的事，也不解释不足令人困惑的事；正确的信息量恰好是用户此刻需要的，不多不少。
83. 语气与方法：每个词都应在屏幕上赢得空间——屏幕小、注意力有限；若一个词不能帮助用户理解、决定或行动，就删除；移动端尤其如此，每个字符都在与用户真正想要的内容竞争。
84. 始终自问：用户此刻需要知道什么？（不是全部，只是此刻。）
85. 始终自问：他们应采取什么动作，文案是否让这显而易见？
86. 始终自问：可能出什么错，错误消息真的帮助了吗？
87. 始终自问：屏幕阅读器朗读时是否合理？
88. 始终自问：边走路边在手机上读是否合理？
89. 始终自问：能翻译吗？若不能，改到能。
90. 始终自问：我们在用用户的语言，还是我们自己的语言？
91. 使用本技能时，带来当前文案示例——屏幕、错误消息、onboarding flows、empty states。
92. 分享你的品牌语气指南，即使粗糙。
93. 若有用户研究显示困惑点、支持工单内容、或用户用自己的话怎么称呼，这些是最有价值的输入。
94. 预期文案会因清晰度而不是机灵度被质疑；若某句听起来很好，但压力下的手机用户两秒内无法解析，就重写。

适用边界 · 注意事项

• 不用于营销文案、广告、品牌活动语言、品牌/产品命名或标语；这些属于 marketing/brand strategy。
• 不用于文本视觉呈现（字体、布局、层级）、流程结构/屏幕顺序/任务设计；导航标签和分类法需与 /organize 协作，翻译与本地化执行由 /localize 负责。
• 不用于编辑、博客或文档内容生产；若问题在流程而非文字，先与 /journey 协作或重构流程。