ux-writing-content-design

UX 写作与内容设计

目的

帮助 AI Agent 撰写和评估产品文案，助人们理解界面、采取行动、解决问题并信任产品。将文字视为设计系统和交互模型的一部分，而非界面完成后才添加的装饰。

本技能涵盖产品 UX 文案：微文案、按钮标签、链接、标签、提示、说明、空状态、引导、校验、错误、成功消息、加载／进度状态、通知、术语、品牌声音、语气和内容策略。除非长篇营销文案会直接影响产品体验中的理解、行动、信任、引导或转化，否则本技能不涵盖此类文案。

何时使用本技能

在用户要求你进行以下工作时，使用本技能：

• 撰写、改写或评审 UI 文本、产品文案、UX 文案、微文案、表单文案、导航标签、行动号召、引导、空状态、错误、确认信息、加载状态、通知、帮助文本或设计系统内容指南。
• 从清晰度、语气、易用性、信任、问题恢复或无障碍的角度，评审 UI、模型、截图、前端组件、流程、原型或设计系统。
• 设计或实现会通过文案影响用户理解或行为的前端状态。
• 创建内容规则、品牌声音与语气指南、术语、内容模式或 UX 写作检查清单。

何时不使用本技能

以下情况不要将本技能作为主要技能：

• 长篇营销页面、广告、品牌宣传活动、公关、SEO 文章或销售文案，除非它们会影响产品内的 UX 流程。
• 纯视觉样式、布局、插画或动画任务，且不涉及界面文本、状态或理解问题。
• 需要持证专业人士处理的法律、医疗、金融或合规文案。你可以改善其清晰度，但应指出需要专家评审。
• 翻译／本地化本身。使用本技能让源文案便于本地化并确保语境安全，然后另行运用翻译／本地化专业知识。

核心原则

1. 文字是设计素材。 不要只挑选“好听的词”。用文字解决用户问题并塑造交互行为。
2. 从用户任务和产品目的出发。 只有在文案支持用户想要完成的事情和产品合理需要时，文案才有效。
3. 实用胜过巧妙。 个性和趣味性应让位于理解、行动、信任和问题恢复。
4. 设计完整对话，而非孤立字符串。 检查入口、操作、系统响应、后续步骤、撤销操作和失败路径。
5. 根据状态选择合适模式。 标签、提示、工具提示、行内错误、横幅、空状态、通知和确认信息各有不同用途。
6. 结合语境撰写。 在文案实际出现的位置撰写和评估，并考虑周边 UI、组件限制、状态、平台和设备。
7. 让操作清楚揭示后果。 按钮和链接应说明会发生什么，而不是描述输入方式。
8. 错误是高压场景。 尽可能避免错误；错误发生时清楚说明，并帮助用户解决问题。
9. 尊重处境不利的人群。 敏感问题、强制选择、默认建议和看似“无害”的快捷回复都可能排斥或伤害他人。
10. 简洁，但不要晦涩。 只有用户仍能立即理解时，简短文案才有价值。
11. 在影响重大时进行衡量。 当文案变更影响激活、转化、留存、问题恢复或信任时，使用可用性测试、行为指标、支持数据和 A/B 测试。
12. 确保文案可实现。 内容应适配语义化 HTML、无障碍 API、本地化、设计令牌、组件状态和设计系统模式。

参见 references/principle-cards.md，了解每条原则对应的可复用卡片。

默认建议

除非用户提供了更具体的产品背景，否则请使用这些默认设置。

领域	默认建议	通常最优的原因	何时覆盖默认建议	覆盖前请先询问
产品目标	帮助用户以尽可能少的不确定性完成当前任务。	大多数产品文案都用于帮助用户完成操作，用户并不是来阅读的。	流程旨在进行教学、发出警告，或改变高风险决策。	询问最重要的结果是什么：理解、转化、完成、留存、安全，还是减少支持需求。
受众	面向广泛、忙碌且能力各异的受众，使用通俗易懂的语言。	这能减轻认知负担，并提升无障碍性和本地化效果。	产品面向需要使用领域术语的专业专家受众。	询问受众是否期待使用领域专属术语。
语态	专业、亲切、直接、自然。	适用于大多数 SaaS、效率、商务和公共服务产品。	存在明确记录的品牌语态或受监管的语气要求。	询问品牌个性或语态指南。
语气	沉稳、乐于助人，并与情境的情绪强度相匹配。	用户常在感到不确定或被打断时接触产品文案。	成功或愉悦的情境可以更热情；严重或敏感的情境则需要克制。	询问当下情境会让用户感到多大的压力，或有多敏感。
CTA 标签	尽可能使用 1–3 个词的动词短语；必要时说明操作对象或后果。	用户会在按钮和链接处做出决定。	法律相关、具有破坏性、付费或不可撤销的操作需要更明确的说明。	询问执行操作后具体会发生什么。
表单标签	在字段上方或旁边持续显示标签；仅在需要额外说明时使用提示。	用户输入后标签仍会显示，也能支持无障碍使用。	UI 空间非常有限，且已有经过测试的无障碍模式。	询问平台或组件方面的限制。
占位文本	仅用于示例或格式说明，绝不能作为唯一标签。	占位文本会消失，可能对比度偏低，也无法充分支持无障碍使用。	设计系统提供了无障碍的浮动标签。	询问组件是否有无障碍标签和错误关联。
帮助/说明文案	仅当标签本身不足以说明时，才在操作附近提供指导。	额外文案可能有帮助，但不必要的说明会增加阅读负担。	任务不熟悉、风险较高，或受政策/格式限制。	询问用户通常会误解什么。
敏感数据请求	说明为何需要这些数据，以及数据将如何使用。	提供背景信息可以增进信任，并减少对不符合简单分类的用户造成的伤害。	原因显而易见，且数据并不敏感。	询问产品为何需要这些信息，以及用户能否跳过。
错误处理	先避免错误，再加以说明，最后提供解决办法。	预防错误能减少阻碍；预防失败时，恢复提示仍必须提供帮助。	后端或法律限制导致无法预防。	询问技术上有哪些可用的恢复操作。
禁用控件	不要只依靠禁用 UI 来提供说明。	禁用控件可能不利于无障碍使用，也可能让用户不知所措。	逐步启用控件的同时，还提供无障碍状态说明或帮助。	询问禁用控件是否有无障碍说明。
空状态	说明什么内容为空、为何重要，以及接下来可采取的有用操作。	空状态是引导新用户和帮助用户恢复的机会。	空状态一目了然，且没有可采取的操作。	询问用户接下来可以做什么。
成功消息	确认已完成的操作；适当时说明下一步或后果。	用户需要明确的结束反馈，有时还需要了解内容的可见范围、送达情况或是否可撤销。	UI 状态本身已清楚表明操作完成。	询问成功后是否会影响可见范围、账单、权限或数据。
加载/进度	说明正在进行的操作，并在延迟明显时告知预期等待时间。	等待期间提供反馈可以减轻焦虑。	延迟短到用户无法察觉。	询问等待时长是否已知或会有变化。
通知	仅发送及时、相关且可采取行动的消息。	通知会打断用户；其价值必须高于打断带来的成本。	合规或运营需要发送无法采取行动的通知。	询问通知支持用户采取什么操作或做出什么决定。
愉悦体验	先确保文案功能明确、有用且符合情境，再加入个性表达。	幽默能为成功或低压力时刻增色，却可能伤害处于错误或压力情境中的用户。	品牌语态有意采用轻松风格，且情境安全。	询问当下情境是否有压力、敏感或不可撤销。
指标	优先使用任务成功率和理解度；仅在转化与用户利益一致时将其作为指标。	文案不应诱导用户偏离自己的目标。	业务目标是明确的优化目标。	询问关注哪些指标，以及相应的护栏指标。
无障碍级别	满足与 WCAG 一致的产品基本要求：标签、程序化错误提示、焦点、键盘操作、屏幕阅读器状态，以及易读文本。	无障碍就是易用性；排斥用户是一种设计选择。	政策要求达到更高的一致性级别。	如果涉及合规，询问要求遵循的无障碍标准。
本地化	避免习语、特定文化的笑话、无法扩展的紧凑字符串，以及含义模糊的变量。	产品文案通常会变成 UI 字符串；本地化可能破坏布局和含义。	产品只面向单一地区，且会一直如此。	询问产品是否会被翻译。

必须向用户提出的问题

不要询问“文本是否应该清晰、简洁或易于理解”这类常规最佳实践问题。直接采用默认做法。

只有当答案会实质性影响文案、模式、语气或实现时才提问。除非用户明确要求进行完整的需求调研，否则每次只问一个有针对性的问题。

以下信息缺失且不可或缺时，才提出问题：

• 用户的主要任务或功能目标不明确。
• 受众具有特殊性、易受伤害、使用多种语言、年龄很小或很大、受到监管，或其他方面依赖具体情境。
• 流程要求提供敏感个人数据、法律同意、付款、健康、身份、安全相关信息，或涉及不可撤销的操作。
• 用户承受压力、包容性、无障碍或信任方面的要求与所需语气相冲突。
• 文案取决于技术限制、后端验证、恢复路径、设计系统模式或本地化要求。
• 用户要求针对某项指标进行优化，但该指标或防护措施尚不明确。
• 决策需要法律或合规部门批准。

默认提问模式：

question({
  question: "What is the primary user task this copy needs to support?",
  recommended_default: "Assume the user wants to complete the immediate visible action with as little uncertainty as possible.",
  options: [
    "Complete a task",
    "Learn how something works",
    "Recover from a problem",
    "Make a high-stakes decision",
    "Other / custom"
  ]
})

完整的决策问题集请参阅 references/decision-prompts.md 中可直接用于提问工具的提示词。

工作流

A. 评估现有 UI 文案

按以下顺序检查：

1. 任务契合度： 用户想要完成什么？文案是在帮助用户完成任务，还是在分散注意力？
2. 用户与业务目标的一致性： 文案是否在不强迫、隐瞒或操纵用户的前提下，实现合理的产品目标？
3. 交互流程： 入口 → 说明 → 操作 → 反馈 → 下一步 → 撤销操作 → 失败处理路径。
4. 模式选择： 每条文案是否使用了合适的组件或状态：标签、提示、CTA、工具提示、行内验证、横幅、模态框、空状态、确认信息或通知？
5. 操作清晰度： 按钮和链接是否清楚说明操作结果？
6. 易于理解： 文案是否通俗、具体、易于浏览，且没有不必要的术语？
7. 压力与恢复： 错误提示是否避免归咎于用户、解释问题并提供切实可行的下一步？
8. 信任与包容性： 是否解释了敏感信息的索取原因？选项是否具有包容性？默认选项和建议是否安全？
9. 语气与一致性： 用词是否遵循产品原则、术语、语法、大小写规范和语气要求？
10. 无障碍与前端可行性： 标签、说明、错误提示、状态更新、焦点行为和本地化是否都能实现？
11. 效果衡量： 如果风险较高，请指出如何测试或衡量文案是否有效。

汇报评估结果时，按严重程度归类：

• 阻断性问题： 妨碍理解、操作、无障碍体验、信任或恢复。
• 重要问题： 增加认知负担、不确定性或不一致性。
• 润色建议： 在解决核心可用性问题后，进一步改善语气、流程或愉悦感。

针对每个问题，请说明：当前问题、更好的文案或模式、原因，以及任何实现说明。

B. 创建或改进新的 UX 文案

按以下顺序进行：

1. 明确产品情境。 确认用户、任务、状态、平台、约束和成功标准。只有当缺失的上下文会改变建议时才提问。
2. 梳理对话流程。 用户现在了解什么？还需要了解什么？可以采取什么行动？系统接下来会做什么？
3. 选择文案模式。 判断文案适用于标题、标签、提示、正文、CTA、行内验证、横幅、模态框、空状态、Toast、通知、加载消息还是帮助入口。
4. 先撰写有用的文案。 优先确保文案准确、聚焦任务且明确说明结果，然后再精简或调整品牌风格。
5. 分四轮编辑。
   • 有目的：它是否服务于用户和产品目标？
   • 简洁：在不丢失含义的前提下，能否删去内容？
   • 自然：听起来像人与人之间的交流，而不是系统日志吗？
   • 清晰：目标用户能否立即理解？
6. 处理边缘和高压状态。 根据需要涵盖空状态、加载、成功、验证、失败、权限、离线、破坏性操作和撤销／重试状态。
7. 确保可实现。 提供组件／状态映射、语义标签、错误关联、必要时的 ARIA 实时区域指南、有用时的字符串 token，以及本地化说明。
8. 测试或验证。 根据风险程度，建议可用性测试问题、理解度检查、支持数据审查或 A/B 测试。
9. 说明决策依据。 将建议与任务完成、理解、信任、问题恢复、无障碍性和产品目标联系起来。

决策框架

使用此框架选择内容模式：

用户需求	优先采用的模式	默认内容结构
知道自己身处何处	页面标题／分区标题	对象或任务名称；需要明确说明时，避免使用笼统的“详情”。
知道字段的含义	可见标签	名词短语：“工作邮箱”“存款金额”。
知道格式或限制	提示／辅助文本	限制或示例：“使用 8–64 个字符。”
决定接下来会发生什么	按钮／链接	动词 + 对象／结果：“创建帖子”“支付 $24”“下载报告”。
理解敏感信息请求	情境说明	为什么需要 + 如何使用 + 是否可选。
知道操作正在进行	加载／进度	当前操作 + 已知时的耗时／预期。
知道操作已成功	确认信息／Toast	发生了什么 + 重要结果 + 有用时的下一步。
知道当前还没有内容	空状态	哪项内容为空 + 原因／时间 + 下一步操作。
从问题中恢复	行内错误或错误页面	发生了什么 + 有用时说明原因 + 如何修复／重试／退出。
不受打扰地了解信息	行内帮助／文档链接	简短的上下文说明 + 深入帮助链接。
对及时变化做出响应	通知	及时说明原因 + 对用户的益处 + 明确的操作或关闭方式。
防止造成损害	确认对话框／插页	后果 + 不可逆的范围 + 安全取消方式 + 具体的确认操作。

实用规则

按钮和链接

• 使用操作结果，而非交互方式。优先使用“下载报告”“创建帖子”或“查看价格”，而不是“点击此处”“提交”，或在对象／操作很重要时使用含糊的“保存”。
• 对于付款、删除、发送、发布、分享、权限和不可逆操作，在标签中突出显示最重要的后果。
• 让主要操作和次要操作具有明确区别。当用户需要了解后果时，避免使用“确定／取消”这类组合。
• 谨慎使用“返回”“取消”“撤销”“移除”和“删除”；它们暗示了不同的可逆性。

表单

• 为每个输入项使用固定标签。不要用占位符代替标签。
• 对于特殊限制、示例、隐私问题或询问信息的原因，使用辅助说明。
• 在字段附近显示错误；只有表单较长或提交失败时，才在顶部汇总错误。
• 使用符合所需格式的示例，但避免使用看起来像真实已保存数据的示例。
• 优先采用渐进式披露，避免冗长说明，但不要隐藏完成任务所需的信息。

敏感问题和个人数据

• 在询问身份、人口统计信息、健康、财务、位置、联系人或法律信息之前，用通俗易懂的语言说明原因。
• 除非法律要求，否则不要强制用户选择二元、过于狭窄或具有特定文化背景的类别。
• 适当且可行时，提供“倾向于不透露”“自行描述”“未列出”或跳过选项。
• 绝不要用轻松俏皮的语气淡化监视、胁迫或索取数据的行为。

错误和验证

采用 预防 → 说明 → 解决。

1. 预防： 通过清晰的标签、限制条件、输入掩码、示例、渐进式验证和更好的交互设计来避免错误。
2. 说明： 用通俗易懂的语言说明出了什么问题。避免原始错误代码、堆栈跟踪或归咎于用户。
3. 解决： 告诉用户接下来该怎么做：修正、重试、撤销、联系支持、使用其他途径或稍后再试。

错误消息结构：

[Problem in user terms]. [Specific fix or next step].

以下是结构示例，并非固定文案：

• “请输入有效的电子邮件地址。”
• “文件过大。请上传小于 10 MB 的文件。”
• “我们无法保存你的更改。请检查网络连接后重试。”

对于高压、法律、财务、医疗、身份、安全或破坏性操作相关的状态，请使用冷静、明确且不带幽默的文案。

空状态

使用空状态帮助用户了解当前情况并继续操作。

默认结构：

Title: No [objects] yet
Description: [What will appear here or why it matters]
Action: [Next useful action]

不要把每种空状态都变成营销宣传。如果没有有用的下一步操作，请说明当前状态并提供返回途径。

加载和进度状态

• 如果等待时间明显，请告知用户当前正在进行什么操作。
• 如果时长可预测，请提前说明预期时间。
• 如果流程可能失败，请提供恢复途径。
• 谨慎使用品牌个性；绝不要让俏皮的加载文案掩盖风险、成本或不确定性。

成功和确认

• 具体确认已完成的操作。
• 说明重要后果：发布、可见性、付款、交付、权限、数据变更或已发送的电子邮件。
• 仅在有助于当前任务时添加后续步骤。
• 对敏感操作成功的提示，避免使用庆祝语气。

通知

• 少发通知，确保每条都有价值。
• 及时发送，内容相关且可执行。
• 避免含糊的互动诱饵。
• 使用符合用户语言和当前情境的表达。
• 适当时提供频率控制和退订选项。

语言风格和语气

根据产品原则构建语言风格，而不只是依靠形容词。

定义：

• 概念： 产品应始终强调的内容。
• 词汇： 建议使用和避免使用的词语。
• 详略程度： 不同状态下适合提供多少说明。
• 语法： 句子结构、人称、缩略形式和时态。
• 标点和大小写： 保持规范一致。
• 语气变化： 在成功、错误、法律、隐私、引导和高压场景中，语言风格应如何调整。

未提供特定语言风格时，使用专业、亲切、直接的语气。

编辑

分四轮编辑：

1. 目的明确
2. 简洁
3. 自然对话
4. 清晰易懂

不要一开始就缩短。先确认文案解决了正确的问题，再在不删减必要含义的前提下精简。

无障碍与包容性要求

• 为输入项使用可见标签和程序化标签。
• 使用无障碍描述，将辅助文本和错误信息与字段关联起来。
• 不要仅依靠颜色、图标、位置或动画来传达状态。
• 确保错误、成功和加载状态的更新能以适当方式通知辅助技术。
• 在对话框、错误和状态变化过程中，保持焦点和键盘访问能力。
• 不要让禁用控件成为唯一的说明。如果控件已禁用，请用无障碍文本说明原因以及如何启用。
• 使用易读的日常语言、简短的句子和常见术语。
• 在功能性文案中避免使用习语、笑话、隐喻和特定文化背景的表达，除非已针对目标受众进行测试。
• 针对与身份相关的问题提供包容性选项，并说明为何需要这些信息。
• 考虑用户的情绪处境：他们可能正承受压力、经历丧亲、生病、无法登录、担心财务问题或时间紧迫。
• 通过预留字符串扩展空间、支持变量移动和复数形式，并为译者提供上下文说明，来支持本地化。

前端实现指南

提供前端建议时，应将文案作为组件行为的一部分。

语义化 HTML 和 ARIA

• 使用与输入项关联的真实 <label> 元素。
• 使用 <button> 执行操作，使用 <a> 进行导航。
• 使用能体现信息层级的标题。
• 使用 aria-describedby 将辅助文本和错误文本与字段关联起来。
• 验证失败时使用 aria-invalid="true"。
• 对紧急验证或状态更新使用 role="alert" 或适当的实时区域，但应避免过度播报。
• 在模态框打开、表单提交失败、路由变化和破坏性操作确认后管理焦点。
• 不要移除焦点轮廓。

组件／状态结构

为每种相关状态记录文案：

• 默认
• 悬停／聚焦时文案变化（如有）
• 加载中
• 空
• 部分
• 成功
• 警告
• 错误
• 离线
• 权限被拒
• 已禁用
• 破坏性操作确认
• 撤销／重试

设计系统集成

• 为可复用的内容模式命名，而不只是为单条字符串命名。
• 记录推荐用语和禁用用语。
• 为标签、CTA 标签、辅助文本、错误、空状态、加载状态、确认提示和通知提供示例。
• 如果实现需要复用，请使用内容令牌或字符串 ID，但避免使用隐藏上下文的抽象 ID。
• 保持源字符串可本地化。避免在代码中拼接句子片段。

响应式与本地化注意事项

• 为翻译后的文案扩展预留空间。
• 避免采用只适用于极短英文字符串的布局。
• 不要仅通过换行来表达含义。
• 测试 CTA、标签页、导航、提示消息和表格标题的截断行为。
• 为译者提供关于变量、语气和上下文的注释。

质量检查清单

完成 UX 文案前，请确认：

• 用户的主要任务清晰明确。
• 每条字符串都有明确作用：引导、指示、激励、确认、警告、帮助恢复或解释。
• 文案不会被用来弥补本应重新设计的交互缺陷。
• 按钮和链接能说明操作结果。
• 表单有可见标签和有用的限制说明。
• 对敏感信息的询问会说明为何需要这些数据。
• 错误信息会说明问题和下一步操作，且不归咎于用户。
• 有可行后续操作时，空状态会提供有用的下一步操作。
• 成功状态会确认重要后果。
• 语气符合情绪影响程度。
• 语气和术语保持一致。
• 文案简洁明了，但不会晦涩难懂。
• 无障碍状态能够实现。
• 本地化不会破坏 UI。
• 影响重大的文案有验证或衡量计划。
• 实现方式会影响建议时，应附上前端说明。

请使用 references/checklists.md 中的完整检查清单。

应避免的常见错误

• 把 UX 文案写作当成 UI 完成后的文字润色。
• 不默认采用清晰表达，而是问用户“要我把它写清楚吗？”
• 当操作结果很重要时，仍使用“提交”“继续”“确定”或“保存”。
• 用占位文本替代可见标签。
• 解释有问题的 UI，而不是修复 UI。
• 用友好的措辞掩盖操纵用户的业务目标。
• 在错误、拒绝、付款失败、身份验证、法律、安全、医疗或金融场景中使用幽默。
• 不解释原因就询问敏感的人口统计信息或个人信息。
• 在面向用户的文案中使用技术错误代码或后端术语。
• 在导航、表单、说明和错误信息中滥用品牌元素。
• 创建让用户无路可走的空状态。
• 发送无法帮助用户采取行动的通知。
• 编写无法本地化或无法由辅助技术朗读的文本。
• 未提供状态、限制条件或实现背景就交付文案。

完整的反模式列表请参阅 references/anti-patterns.md。

如何向用户解释建议

从对用户的影响出发解释建议，而非个人喜好。

使用以下结构：

I recommend [copy/pattern] because [user goal or risk]. It improves [comprehension/action/trust/recovery/accessibility]. Use [alternative] only if [context/constraint].

提供多个选项时，请按用途标注：

• 清晰／默认
• 更亲切
• 更正式
• 更值得信赖
• 适用于受限 UI 的精简版本
• 无障碍／错误安全
• 待审核的法律／合规安全版本

避免只说“这个听起来更好”，却不解释相关任务、状态或用户需求。