Prose 界面文案

问题在哪

界面上的按钮、错误提示、空状态和首次引导，往往各自为政：术语不一致、错误只报「出了点问题」、按钮写成「提交」或「点击此处」，屏幕阅读器读到的是 aria-label 里拼出来的半句话。产品要出海时，文案里嵌了逻辑或拼接字符串，翻译成本陡增。Prose 面向的是面向用户的文本——从微文案到错误消息、从语气框架到 EU AI Act 所需的披露标签，要求每个词都服务于用户，且清晰胜过聪明。

技能如何工作

Prose 按 AUDIT → DRAFT → REVIEW → DELIVER 推进，并强调在 AUDIT 阶段读取既有语气框架、术语与周围 UI 上下文（文案含义取决于放置位置）。核心契约包括：

• 错误消息：统一采用「什么 / 为什么 / 下一步」结构，优先内联验证，避免仅靠提交后错误列表或 toast 承载关键错误。
• 微文案：按钮标签用动词 + 宾语（如「下载报告」），不用泛泛的「点击此处」；空状态、工具提示、占位符有对应配方（microcopy、empty-state 等）。
• 语气与可访问性：遵循或新建语气/语调框架；交互元素考虑屏幕阅读器，优先 aria-labelledby，需翻译的文本不用 aria-label；无障碍名称需包含可见文本（WCAG 2.2 SC 2.5.3）。
• 可读性与 i18n：消费者产品目标 Flesch-Kincaid 约 6–8 级，专业工具 10–12；文案为翻译就绪编写（不拼接、不嵌入逻辑）。

配方表覆盖 errors、onboarding、a11y、tone、notification、status 等子场景，并引用 reference/ 下的模式文档与 Opus 4.8 创作原则中的 P3、P5。

边界与注意点

始终执行：已有语气框架必须遵守；术语全应用一致；文案要在真实 UI 上下文中验证，而非孤立润色。

绝对禁止：牺牲清晰度的「聪明」文案、无理由的性别化用语、会上线的占位符、仅用颜色表示错误、用禁用提交按钮代替校验、把 AI 披露标签藏进二级页或冗长条款。Prose 不负责替代你们的产品策略决策，但会把「错误是对话、正确时隐形、错误时痛苦」落到可执行的写法上。