UHD_Media_Tool/.claude/skills/human-copy/SKILL.md

---
name: human-copy
description: 生成、检查和改写产品中的用户可见文案（界面、按钮、提示、Toast、错误信息、表单、空状态、确认弹窗、设置项、日志）。写或改任何用户会看到的文字之前先读它；目标是准确、清楚、简洁、自然，没有 AI 味、客服腔、营销腔和翻译腔。
---

# Human Copy

用于生成、检查和改写产品中的用户可见文案。

目标不是“文案写得漂亮”，而是：

**准确、清楚、简洁、自然。**

用户扫一眼就能看懂，不需要理解文案本身。

最终效果应该像成熟产品团队人工写出的文案，而不是 AI、客服模板、营销稿或翻译稿。

---

## When to use

当任务涉及以下内容时使用本 Skill：

* 生成产品界面文案
* 检查已有产品文案
* 改写不自然的产品文案
* 去除 AI 味
* 精简 UI 文案
* 统一产品术语
* 优化按钮、标题、提示、Toast、错误信息
* 优化表单 Label、Placeholder、Help Text
* 优化空状态
* 优化确认弹窗
* 优化设置项说明
* 优化 Onboarding
* 优化系统通知
* 检查产品中的中英文翻译腔
* 检查 AI 自动生成的用户可见文本

除非用户明确要求营销文案，否则默认按**产品文案**处理。

---

# Core Principle

所有判断按以下优先级执行：

**准确 > 清楚 > 简洁 > 自然 > 风格**

不能为了简短损失信息。

不能为了“说人话”变得随意、卖萌或低幼。

不能为了显得专业，把简单的事情说复杂。

不能为了文案完整，补充产品实际上不存在的信息。

---

# Default Tone

默认语气：

* 自然
* 克制
* 直接
* 专业
* 不冷漠
* 不热情过度

像一个表达能力正常、熟悉产品的设计师或工程师写的。

不是：

* AI 助手
* 客服
* 广告文案
* 公关稿
* 政府公文
* 产品经理汇报
* 网络段子

---

# Two Modes

本 Skill 有两个主要工作模式。

## Mode A — Generate

当需要从零生成文案时：

1. 理解当前界面的实际功能。
2. 判断用户此刻最需要知道什么。
3. 先写最短可用版本。
4. 只在必要时补充说明。
5. 检查是否存在风险、状态或下一步动作需要表达。
6. 使用项目已有术语。
7. 执行最终文案检查。

不要为了让界面显得丰富而主动增加文字。

---

## Mode B — Review

当用户提供现有文案时：

依次检查：

1. 是否准确
2. 是否清楚
3. 是否有废话
4. 是否有 AI 味
5. 是否有客服腔
6. 是否有营销腔
7. 是否有翻译腔
8. 是否重复界面已有信息
9. 是否过度解释
10. 是否存在术语不一致
11. 是否把简单动作写复杂
12. 是否存在不必要的情绪表达
13. 是否擅自承诺产品能力
14. 是否可以继续压缩

发现问题后直接修改。

不要只指出“这句话有 AI 味”。

必须说明具体问题属于哪一种，并给出更自然的版本。

---

# Writing Rules

## 1. 先说结果

用户最关心的内容放最前面。

错误：

> 由于当前网络环境可能存在一定波动，因此此次请求暂时未能成功完成。

正确：

> 连接超时。

需要动作时：

> 连接超时。检查网络后重试。

---

## 2. 每句话都必须提供信息

一句话应该至少完成一件事：

* 说明发生了什么
* 说明当前状态
* 提供决策需要的信息
* 告诉用户下一步能做什么
* 提醒真实存在的风险

如果删除后不影响用户理解、决策或操作：

**删除。**

---

## 3. 默认使用短句

优先：

> 删除后无法恢复。

而不是：

> 执行删除操作之后，相关数据将无法进行恢复，请谨慎进行操作。

但不要为了字少而写得含糊。

错误：

> 失败

正确：

> 保存失败

---

## 4. 使用正常中文

避免公文结构、机器翻译结构和 AI 常见结构。

错误：

> 你的请求已被成功处理。

正确：

> 处理完成。

错误：

> 你没有权限去执行这个操作。

正确：

> 你没有这个操作权限。

错误：

> 该功能当前无法被使用。

正确：

> 当前无法使用该功能。

---

## 5. 少用抽象名词，多用动词

错误：

> 进行项目创建

正确：

> 创建项目

错误：

> 执行连接测试

正确：

> 测试连接

错误：

> 完成数据同步

正确：

> 同步完成

---

# Remove AI Tone

默认避免以下表达方式。

## 无意义开场

* 当然
* 当然可以
* 没问题
* 好的
* 接下来
* 下面
* 首先
* 那么
* 让我们

产品界面直接进入信息。

---

## 无意义总结

* 总的来说
* 总而言之
* 综上所述
* 简而言之
* 通过以上方式
* 最终实现
* 从而进一步
* 这意味着

如果信息已经说完，不需要总结。

---

## AI 高频连接词

默认谨慎使用：

* 此外
* 同时
* 与此同时
* 值得注意的是
* 需要注意的是
* 值得一提的是
* 更进一步

如果后面的内容重要，直接说内容。

---

## AI 高频结构

避免：

> 不仅 A，而且 B

改成：

> 支持 A 和 B。

避免：

> 无论你是 A、B，还是 C……

直接说明功能。

避免：

> 通过 XX，你可以轻松完成……

改成：

> 使用 XX 完成……

或者直接写动作。

避免：

> 旨在帮助用户……

直接说明产品做什么。

---

# No Marketing by Default

除非明确要求营销，否则禁止自动营销化。

避免：

* 解锁
* 探索
* 开启
* 赋能
* 助力
* 打造
* 释放潜能
* 无限可能
* 全新体验
* 重新定义
* 革新
* 下一代
* 一站式
* 尽在掌握
* 从未如此简单

错误：

> 释放 Agent 的无限潜能。

正确：

> 创建、运行和管理 Agent。

---

# No Customer-Service Tone

产品不是客服。

默认少用：

* 您
* 请您
* 感谢
* 非常抱歉
* 给您带来的不便
* 敬请谅解
* 温馨提示

错误：

> 请您输入您的 API Key。

正确：

> 输入 API Key

错误：

> 非常抱歉，保存操作未能成功。

正确：

> 保存失败。

---

# Do Not Manufacture Emotion

不要主动写：

* 别担心
* 放心
* 不要着急
* 无需担心
* 好消息是
* 遗憾的是
* 很遗憾
* 太棒了
* 恭喜

描述事实。

错误：

> 别担心，本地文件没有受到影响。

正确：

> 本地文件不受影响。

---

# Do Not Pretend to Be Human

“没有 AI 味”不代表故意说网络口语。

避免：

* 哎呀
* 搞定啦
* 不太行哦
* 寄了
* 炸了
* 走起
* 冲
* ～
* 无必要 Emoji

错误：

> 哎呀，连接好像出了点小问题～

正确：

> 连接失败。

---

# Never Invent Product Facts

生成文案时，只能描述已经确认存在的能力。

禁止自动增加：

* 安全加密
* 端到端加密
* 实时同步
* 自动备份
* 高可用
* 企业级安全
* 智能优化
* 隐私保护
* 秒级响应
* 永久保存
* 完全兼容

如果输入信息不足，不得为了让文案显得完整而自行补充。

---

# Do Not Guess Failure Reasons

如果系统不知道失败原因：

不要猜。

错误：

> 上传失败，可能是网络波动导致。

正确：

> 上传失败。

可以给安全动作：

> 上传失败。重新上传或查看日志。

只有已经确定原因时才写：

> 文件超过 100 MB 上限。

---

# Terminology

同一个概念始终使用同一个名称。

如果产品中已经叫：

> 任务

就不要轮流写：

* 作业
* 执行项
* 流程
* Operation
* Job

产品文案不需要为了避免重复而使用同义词。

**一致比文采重要。**

优先沿用：

1. 产品已有名称
2. 行业通用名称
3. 用户已经使用的名称

不要擅自创造新术语。

---

# Technical Copy

“说人话”不意味着删除专业术语。

面对技术产品，应优先准确。

例如：

> 请求返回 HTTP 429。降低并发或稍后重试。

比：

> 请求有点太频繁了，服务器现在比较忙。

更准确。

行业通用词可以直接保留：

* API
* Token
* Agent
* Prompt
* GPU
* URL
* Webhook
* JSON
* Git
* Docker

不要为了中文化硬翻译。

也不要为了显得专业滥用英文。

---

# UI-Specific Rules

## Page Title

直接说明页面对象或当前任务。

推荐：

> 模型

> 运行记录

> 创建项目

> API 设置

不要：

> 欢迎来到模型管理中心

---

## Button

按钮描述动作。

推荐：

> 保存

> 删除

> 重试

> 创建项目

> 查看日志

> 重新连接

避免：

> 确定

> 好的

> 点击这里

> 立即体验

> 开始探索

危险操作尽量使用明确动作。

例如：

> 删除项目

而不是：

> 确定

---

## Toast

只表达结果。

推荐：

> 已保存

> 已复制

> 上传完成

> 删除失败

> 连接超时

不要：

> 太棒了！保存成功！

如果 UI 本身已经明确反馈状态，可以不显示 Toast。

---

## Form Label

Label 写字段名称。

推荐：

> API Key

> 模型

> Base URL

> 超时时间

不要：

> 请输入你的 API Key

---

## Placeholder

Placeholder 不重复 Label。

Label：

> 项目名称

不要：

> 请输入项目名称

可以使用有效示例：

> 例如：客服 Agent

---

## Help Text

只提供用户无法直接知道的信息。

错误：

Label：

> API Key

说明：

> 在这里填写 API Key。

正确：

> 密钥只保存在本机。

---

## Empty State

根据场景决定是否需要动作。

推荐：

> 还没有项目。

或者：

> 还没有项目。创建一个项目开始使用。

搜索为空：

> 没有找到匹配结果。

不要所有空状态都写成长篇 Onboarding。

---

## Error

优先结构：

**结果 + 已知原因 + 可执行动作**

不要求机械出现全部三项。

例如：

> 登录失败。验证码已过期，重新获取验证码。

> 连接失败。API Key 无效。

> 文件无法上传。最大支持 100 MB。

> 任务启动失败。没有可用的 GPU。

---

## Confirmation Dialog

必须明确说明：

* 用户将执行什么
* 会产生什么后果

错误：

标题：

> 确认操作

正文：

> 确定要执行此操作吗？

按钮：

> 确定

正确：

标题：

> 删除项目？

正文：

> 项目和运行记录都会被删除，无法恢复。

按钮：

> 删除项目

> 取消

---

## Success Message

成功操作默认只确认结果。

推荐：

> 项目已创建

> 配置已保存

> 已复制

不要：

> 恭喜！你的项目创建成功 🎉

---

## Settings

说明具体行为。

错误：

> 开启后可以获得更加智能的使用体验。

正确：

> 开启后，系统会记录最近使用的模型。

---

## Onboarding

目标是帮助用户完成第一次操作。

不要解释企业使命。

错误：

> 欢迎来到 XX，我们致力于帮助你打造下一代 AI 工作体验。

正确：

> 连接一个模型开始使用。

---

# Information Density

文案长度取决于决策风险。

## Low Risk

尽可能短。

例如：

> 已复制

## Medium Risk

说明影响。

例如：

> 修改后，新任务会使用这个模型。

## High Risk

明确：

* 影响对象
* 影响范围
* 是否可恢复

例如：

> 删除后，项目、配置和运行记录都会永久删除，无法恢复。

不要机械追求所有文案都极短。

---

# UI Before Copy

如果一个界面必须依赖大段文字才能让用户理解，先检查交互本身。

可能需要调整：

* 信息层级
* 控件名称
* 默认值
* 分组
* 按钮位置
* 状态反馈

不要默认用“说明文字”修补设计问题。

---

# Review Workflow

检查现有文案时，按下面顺序执行。

## Step 1 — Understand Context

明确：

* 用户现在在哪个界面
* 用户刚刚做了什么
* 系统发生了什么
* 用户接下来能做什么
* 有没有风险
* 有没有不可逆操作

只根据已知信息判断。

---

## Step 2 — Remove Noise

删除：

* 开场白
* 套话
* 重复
* 空泛价值
* 不必要解释
* 无意义礼貌
* 无意义情绪
* 无意义总结

---

## Step 3 — Make It Concrete

把抽象描述换成：

* 状态
* 数字
* 条件
* 行为
* 后果
* 下一步

错误：

> 当前配置存在问题。

更好：

> API Key 为空。

---

## Step 4 — Simplify Language

检查是否存在：

* 进行
* 实现
* 相关
* 相应
* 有关
* 基于
* 通过
* 当前情况下
* 进一步

能删则删。

---

## Step 5 — Check Terminology

确认：

* 同一个对象是否使用同一个名字
* 中英文是否统一
* 是否擅自创造别名
* 是否与产品已有术语冲突

---

## Step 6 — Check Facts

确认：

* 有没有猜测失败原因
* 有没有增加不存在的能力
* 有没有未经确认的承诺
* 有没有扩大操作影响范围

---

## Step 7 — Compress Again

对最终版本再检查一次：

> 有没有任何一个词删掉以后意思不变？

有就继续删。

---

# Generation Workflow

从零生成产品文案时：

1. 找出当前用户任务。
2. 找出必须表达的信息。
3. 写出最短准确版本。
4. 判断是否需要补充原因。
5. 判断是否需要下一步动作。
6. 判断是否存在风险。
7. 检查项目术语。
8. 删除 AI 套话。
9. 删除营销词。
10. 删除不必要礼貌。
11. 压缩。
12. 输出。

---

# Review Output

用户要求“检查文案”时，默认输出：

### 原文

用户提供的文字。

### 问题

只指出真正有问题的地方。

问题标签可以包括：

* 废话
* AI 味
* 客服腔
* 营销腔
* 翻译腔
* 信息重复
* 含义模糊
* 太啰嗦
* 术语不一致
* 原因猜测
* 无依据承诺
* 风险表达不足

### 建议

给出可以直接使用的最终版本。

如果原文没有问题，不要为了体现工作量强行改写。

直接说明：

> 这句可以保留。

---

# Batch Review

检查一组界面文案时，优先用：

| 场景 | 原文 | 问题 | 建议 |
| -- | -- | -- | -- |

只列出需要修改的项目。

如果用户要求完整校对，则保留全部项目。

---

# Alternative Copy

默认只给一个最佳版本。

不要自动生成：

* 正式版
* 活泼版
* 年轻版
* 高级版
* 极简版

除非用户明确要求多个方向。

产品文案需要决策，不需要制造选择困难。

---

# Things Not to Do

禁止：

* 为了显得有帮助而增加额外文案
* 为了避免重复而换术语
* 为了自然加入网络语言
* 为了专业加入复杂名词
* 为了完整猜产品逻辑
* 为了友好加大量礼貌词
* 为了高级写抽象价值
* 为了短而删除必要信息
* 为了体现修改而修改原本已经正确的文字

---

# Final Checklist

输出前检查：

* [ ] 信息是否准确？
* [ ] 用户能否一眼看懂？
* [ ] 是否直接说结果？
* [ ] 是否存在废话？
* [ ] 是否存在 AI 套话？
* [ ] 是否存在客服腔？
* [ ] 是否存在营销腔？
* [ ] 是否存在翻译腔？
* [ ] 是否过度口语？
* [ ] 是否重复已有信息？
* [ ] 是否使用明确动词？
* [ ] 是否统一术语？
* [ ] 是否猜测未知原因？
* [ ] 是否创造不存在的产品能力？
* [ ] 是否做出未经确认的承诺？
* [ ] 风险是否说明清楚？
* [ ] 用户是否知道下一步？
* [ ] 是否还能继续删除文字？

最后执行一次：

**删除测试。**

如果某句话或某个词删掉以后：

* 不影响理解
* 不影响判断
* 不影响操作
* 不影响风险认知

就删掉。

---

# Quality Bar

最终文案应该满足：

**不是“写得像人”。**

而是：

**根本不会让用户想到这段文字是谁写的。**

文案只是界面的一部分。

看懂，操作，然后继续。