rootandClaude Opus 5.5
542f107566
Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Cxwgnn2pbzQ7rXv3rq7fei
15 KiB
name, description
| name | description |
|---|---|
| human-copy | 生成、检查和改写产品中的用户可见文案（界面、按钮、提示、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
当需要从零生成文案时：
- 理解当前界面的实际功能。
- 判断用户此刻最需要知道什么。
- 先写最短可用版本。
- 只在必要时补充说明。
- 检查是否存在风险、状态或下一步动作需要表达。
- 使用项目已有术语。
- 执行最终文案检查。
不要为了让界面显得丰富而主动增加文字。
Mode B — Review
当用户提供现有文案时：
依次检查：
- 是否准确
- 是否清楚
- 是否有废话
- 是否有 AI 味
- 是否有客服腔
- 是否有营销腔
- 是否有翻译腔
- 是否重复界面已有信息
- 是否过度解释
- 是否存在术语不一致
- 是否把简单动作写复杂
- 是否存在不必要的情绪表达
- 是否擅自承诺产品能力
- 是否可以继续压缩
发现问题后直接修改。
不要只指出“这句话有 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
产品文案不需要为了避免重复而使用同义词。
一致比文采重要。
优先沿用：
- 产品已有名称
- 行业通用名称
- 用户已经使用的名称
不要擅自创造新术语。
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
从零生成产品文案时：
- 找出当前用户任务。
- 找出必须表达的信息。
- 写出最短准确版本。
- 判断是否需要补充原因。
- 判断是否需要下一步动作。
- 判断是否存在风险。
- 检查项目术语。
- 删除 AI 套话。
- 删除营销词。
- 删除不必要礼貌。
- 压缩。
- 输出。
Review Output
用户要求“检查文案”时，默认输出：
原文
用户提供的文字。
问题
只指出真正有问题的地方。
问题标签可以包括：
- 废话
- AI 味
- 客服腔
- 营销腔
- 翻译腔
- 信息重复
- 含义模糊
- 太啰嗦
- 术语不一致
- 原因猜测
- 无依据承诺
- 风险表达不足
建议
给出可以直接使用的最终版本。
如果原文没有问题，不要为了体现工作量强行改写。
直接说明：
这句可以保留。
Batch Review
检查一组界面文案时，优先用：
| 场景 | 原文 | 问题 | 建议 |
|---|
只列出需要修改的项目。
如果用户要求完整校对，则保留全部项目。
Alternative Copy
默认只给一个最佳版本。
不要自动生成：
- 正式版
- 活泼版
- 年轻版
- 高级版
- 极简版
除非用户明确要求多个方向。
产品文案需要决策，不需要制造选择困难。
Things Not to Do
禁止：
- 为了显得有帮助而增加额外文案
- 为了避免重复而换术语
- 为了自然加入网络语言
- 为了专业加入复杂名词
- 为了完整猜产品逻辑
- 为了友好加大量礼貌词
- 为了高级写抽象价值
- 为了短而删除必要信息
- 为了体现修改而修改原本已经正确的文字
Final Checklist
输出前检查：
- 信息是否准确？
- 用户能否一眼看懂？
- 是否直接说结果？
- 是否存在废话？
- 是否存在 AI 套话？
- 是否存在客服腔？
- 是否存在营销腔？
- 是否存在翻译腔？
- 是否过度口语？
- 是否重复已有信息？
- 是否使用明确动词？
- 是否统一术语？
- 是否猜测未知原因？
- 是否创造不存在的产品能力？
- 是否做出未经确认的承诺？
- 风险是否说明清楚？
- 用户是否知道下一步？
- 是否还能继续删除文字？
最后执行一次：
删除测试。
如果某句话或某个词删掉以后：
- 不影响理解
- 不影响判断
- 不影响操作
- 不影响风险认知
就删掉。
Quality Bar
最终文案应该满足：
不是“写得像人”。
而是：
根本不会让用户想到这段文字是谁写的。
文案只是界面的一部分。
看懂，操作，然后继续。