clarify

Clarify

仅在授权的目标和范围内进行文案编辑。

改写不清晰的界面文本，让用户了解发生了什么、哪些信息重要，以及接下来该做什么。保留事实含义、产品术语和品牌语气。

审查语言

阅读完整的交互路径，不要孤立地查看字符串。找出以下问题：

• 含义模糊的名词、动词和操作；
• 内部行话或用户可能不了解的知识；
• 含糊的标签、结果和系统状态；
• 缺少后果、恢复方式或时间信息；
• 术语和大小写不一致；
• 多余的标题、引言、辅助文本和确认信息；
• 在常见屏幕宽度或翻译后显示不佳的文本；
• 忽视用户压力、风险、成功或紧迫性的语气。

根据产品背景和周围的界面推断受众和任务。若要更改事实声明、法律含义或可能属于特定领域的术语，请先询问。

确定信息层级

针对每种状态，决定：

1. 用户此刻需要了解的一个事实；
2. 用户接下来可以采取的操作；
3. 会影响决策的辅助信息；
4. 此时适当的语气。

每个意思只表达一次。如果标题已经说明状态，引言就应补充新信息，否则应删去。

按功能改写

操作和导航

如果结果并非一目了然，请使用明确的动词和对象。标签应说明将会发生什么，而不是触发操作的方式。同一概念在整个产品中应使用相同的名词和动词。

对于有破坏性的操作，应明确指出对象和后果。如果安全且可恢复，优先提供撤销，而不是确认。必须确认时，应在提示和按钮上明确写出操作，不要使用 Yes、No、OK 或 Submit。

表单

使用持久显示的标签；占位符用于举例，不能代替标签。提交前说明格式和资格要求。仅当索取信息的原因并非显而易见时，才解释原因。必填项和选填项的标示方式应保持一致。

验证提示应指出需要注意的问题以及如何修正，不要责怪用户。将相关说明放在字段附近，并以无障碍方式播报错误。

错误和权限

可采取操作的错误提示应说明：

1. 发生了什么故障；
2. 已知且有用时，说明原因；
3. 如何恢复，或有哪些替代方案。

不要将内部代码作为主要提示内容。不要承诺系统无法确定的原因或解决结果。应认真处理隐私、付款、删除、访问权限丢失和工作受阻等问题；可以亲切，但不要开玩笑。

加载、空状态和成功状态

加载文本应说明实际正在执行的操作；等待时间较长时，应如实说明预期等待时间。有可确定的进度时应显示进度；切勿编造进度。

空状态应区分首次使用、无搜索结果、筛选条件、权限问题和故障。说明当前状态，并提供有用的下一步操作。

成功提示应确认已完成的结果；只有当后续影响会改变用户的操作时，才提及该影响。常规成功提示应简短。

帮助和说明文本

辅助文本应回答用户可能提出的问题，而不是重复控件内容。少见的详细信息应逐步展示。链接文本脱离上下文后也应能表达明确含义；仅图标控件需要无障碍名称。

语气、无障碍性和本地化

保持语气一致，并根据具体情境调整风格。使用浅显的语言，但不要抹去受众确实熟悉的术语。

• 编写完整、可翻译的消息，不要拼接片段。
• 以结构化方式组织变量和数字，方便译者调整顺序。
• 为文本扩展留出空间，不要过早缩写。
• 替代文本应传达图像信息；装饰性图像使用空替代文本。
• 屏幕阅读器名称应与可见标签和操作结果保持一致。
• 不要仅依赖标点、颜色或图标传达信息。

如果产品内的术语不一致，应维护一份简短的术语表。不要为了文风变化而在界面中使用不同词语表达同一概念。

验证

结合上下文阅读流程并测试：

• 无需了解隐藏的产品知识也能理解；
• 在出错、空状态和决策点提供可执行的操作指引；
• 信息准确，术语一致；
• 在目标宽度和 200% 缩放下易于浏览；
• 长名称、本地化后的文本扩展、复数形式和动态值；
• 无障碍名称和播报的状态变化；
• 语气与后果和情绪背景相符。

在不删减含义或补救方式的前提下，最终文案应尽可能简短。

建议在最后一轮润色时使用可用的 polish skill。