content

内容

将文字视为交互的一部分，而不是设计完成后添加的装饰。

始终遵循

• 上下文 — 询问用户重复说明前，先检查已有信息。当产品目的或预期结果可能影响答案时，使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人、他们的目标、任务、情境和可用证据为依据。不要臆造用户需求、行为或用户画像。
• 证据 — 在区分已知、推断、假设、未知和相互矛盾的信息有意义时，明确区分它们。
• 系统 — 优先沿用已有的产品语言、组件、模式和规则，而不是另行创造。
• 清晰 — 先说有用的要点，采用必要的最精简结构，并删去泛泛的 AI 填充内容。
• 可信 — 绝不臆造证据、需求、理由、实现状态或合规情况。
• 结果 — 对于重要的多步骤工作，持续关注意图；只有在需要保持连续性时才使用精简的 .ux/STATE.md；优先解决影响最大的未解决问题，再做润色；宣布完成前，依据意图核验实际体验。

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

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

从上下文入手

在相关项目上下文存在时，从最小范围的上下文中读取相关用户目标和流程，以及术语、无障碍要求和产品约束。若有设计系统内容规范和本地化限制，也要一并查看。

审视内容需要完成的任务

检查以下方面：

• 行动和结果是否明确；
• 术语是否一致；
• 信息是否在需要时呈现；
• 是否存在界面本可以清楚说明、却多余的指示；
• 标签是否准确描述目标位置或操作；
• 错误文案是否说明发生了什么以及如何恢复；
• 确认文案是否与操作的后果相称；
• 是否向用户暴露了技术或组织术语；
• 是否存在归咎、歧义、胁迫或虚假安慰；
• 文案是否可能因翻译、文本扩展、动态值或辅助技术而出错。

优先采用已有的产品语言

除非有理由质疑，否则使用产品和设计系统中已有的术语。如果权威来源中的术语不一致，应指出冲突，而不是默默自行选择。

谨慎改写

保留事实含义、法律要求和不确定性。不要为了让消息听起来更亲切而降低其准确性。

对于后果重大的操作，清晰比个性更重要。

输出

先指出会影响理解或行为的内容问题。必要时提供修改后的文案，并且只解释不明显的决策。

示例

• “审查此恢复流程中的文案。”
• “这些错误消息真的有用吗？”
• “让这些标签更清晰，并与我们的产品语言保持一致。”