# UX Microcopy Writer

> 当需要为界面元素（按钮/CTA、报错、空状态、确认弹窗、提示气泡、加载态、引导文案）撰写或评审 UX 微文案，并产出推荐文案+备选方案+理由+本地化提示时使用；不适用于长篇营销文案、品牌口号、纯视觉设计或后端文案逻辑实现；触发词：UX 文案、微文案、按钮该写什么、报错文案、空状态、确认弹窗措辞、CTA 命名、引导文案

- Skill: `findscripter/ux-microcopy-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add findscripter/ux-microcopy-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/findscripter/ux-microcopy-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: findscripter (https://skillmd.com/u/findscripter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/findscripter/ux-microcopy-writer

---

## 何时使用

- 要为具体界面元素写或评审简短文案：CTA/按钮、报错信息、空状态、确认弹窗、提示气泡（tooltip）、加载态、引导/onboarding 文案。
- 目标产物是：推荐文案 + 2-3 个带语气标签的备选 + 选用理由 + 本地化提示。
- 已能描述上下文（哪个界面/流程、用户在做什么、想要什么语气、有无字数/平台约束），或愿意被追问补齐。

不该用的边界：
- 长篇营销文案、落地页正文、品牌 slogan、SEO 文章 → 那是内容创作，不是界面微文案。
- 纯视觉/排版设计、组件实现、把文案接进代码的逻辑 → 本技能只给文案，不画稿不写码。
- 没有任何界面上下文、只让"随便写点文案" → 先索要上下文（界面+用户状态+语气+约束）再开工。
- 整体界面/可用性体检、反模式审计 → 用 `ux-ui-principles-audit`。

## 步骤 / 指令

```
1. 先固定上下文（缺则向用户索要，不要凭空写）
   - 界面/流程：哪个屏幕、哪一步、什么功能？
   - 用户状态：用户在做什么？此刻的情绪（着急/困惑/期待）？
   - 语气：正式 / 友好 / 俏皮 / 安抚？
   - 约束：字数上限、平台规范、术语表/品牌声音？

2. 按元素类型套用文案结构（见下「指令」）。

3. 逐元素产出：1 条推荐 + 2-3 条备选（各标语气与适用场景）+ 选用理由。

4. 补本地化提示：避免的双关/俚语、字符膨胀（中→英可能变长）、文化差异。
```

指令（核心约束，逐条照用）：

五条原则：① 清晰——说人话，零行话零歧义；② 精简——用最少的词说全；③ 一致——同一事物全程用同一术语；④ 有用——每个词都帮用户达成目标；⑤ 像人——像乐于助人的人，不像机器人。

各元素文案模式：
- CTA/按钮：动词开头、具体。"开始免费试用""保存更改""下载报告"，而非"提交""确定"；标签要与实际结果一致。
- 报错信息：结构=发生了什么 + 为什么 + 怎么解决。例："支付未成功。银行拒绝了这张卡。请换一张卡或联系发卡行。"
- 空状态：结构=这是什么 + 为什么空 + 如何开始。例："还没有项目。创建第一个项目，开始和团队协作。"
- 确认弹窗：把动作写清楚（"删除 3 个文件？"而非"确定吗？"）；说明后果（"此操作无法撤销"）；按钮用动作命名（"删除文件"/"保留文件"，而非"确定"/"取消"）。
- 提示气泡：精简、有用，不说显而易见的废话。
- 加载态：设定预期、降低焦虑。
- 引导文案：渐进披露，一次只讲一个概念。

语气随场景调整：成功→克制庆祝；报错→共情且给出办法；警告→清晰可执行；中性→信息准确简洁。

## 示例

输出模板：

```markdown
## UX 文案：[上下文]

### 推荐文案
**[元素]**：[文案]

### 备选
| 选项 | 文案 | 语气 | 适用场景 |
|------|------|------|----------|
| A | [文案] | [语气] | [何时用] |
| B | [文案] | [语气] | [何时用] |
| C | [文案] | [语气] | [何时用] |

### 理由
[为何这条更好——用户处境、清晰度、动作导向]

### 本地化提示
[译者需知：避免的习语、字符膨胀、文化背景]
```

报错文案最小示例（结构=发生什么+为什么+怎么办）：

```
支付未成功。银行拒绝了这张卡。请换一张卡，或联系发卡行后重试。
```

## 注意事项

- 上下文不全就别硬写：界面、用户状态、语气、约束四项缺哪问哪，模糊文案不如不写。
- 上下文要具体——"支付失败时的报错"远胜"一条报错"。
- 顾及情绪：报错要共情，成功可适度庆祝，别一律冷冰冰或一律卖萌。
- 有品牌声音/术语表就先对齐它，保证全局术语一致；接入设计稿时核对字数与布局约束（本技能不抓取页面，需用户提供截图或文字稿）。
- 备选要真有差异（不同语气/场景），不要换几个同义词凑数；理由要落到用户后果，不要写"更优雅"这种空话。

## 互见

- requires：无。
- related：`ux-ui-principles-audit`（界面原则与反模式审计，会涉及文案类反模式如 confirmshaming，本技能专注产出文案）；`ux-research-design-toolkit`（用户研究转设计决策，为文案语气提供依据）。
- combines_with：`brand-guidelines`（拉取品牌声音与内容风格指南，约束文案语气与术语）；`ui-design-system-builder`（文案与组件/设计令牌一并落到设计体系）。

---
采编自 anthropics/knowledge-work-plugins（Apache-2.0）。