关于 copywriting
copywriting 是 super-ux 中按产品品牌规范撰写和修改文案的技能,适用于产品文本与营销内容。它要求先读取品牌资料,并通过文案登记与默认的人性化检查,保持各渠道表达一致。
主要功能
- 01按品牌声音与渠道规范写作
- 02编辑和跨渠道改写文案
- 03维护界面文案登记表
- 04默认执行人性化检查
- 05依据来源核验产品声明
适用场景
- 01撰写界面按钮、提示和错误文案
- 02编辑营销页面或应用商店介绍
- 03将一段文案改写用于多个渠道
- 04审查既有文案的自然度
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ ssheleg/ super-ux --skill copywriting安装后在 Claude Code 中输入/copywriting确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/ai-tells.mdbrand-contract.mdchannel-playbooks.mdhooks.mdlanding-pages.mdlocalization.mdmarketing-copy.mdresearch-outliers.mdseo-aeo-safety.mdstore-copy.mdsurface-registers.mdsystem-map.mdui-copy.mdvideo-script.mdvoice-packs.mdtemplates/brand/copy-brief.md详细介绍
copywriting — 以产品自己的语气撰写
属于 super-ux — 参见 system-map.md。 修改后,按下文说明解析并运行品牌检查器。
每次都要先做的一件事:阅读品牌资料包。 阅读 docs/brand/voice.md、
terminology.md,以及所写内容对应界面的 channels.md 记录。
没有资料包?停止并移交给 brand-voice。 不要自行揣摩语气。
猜错的代价大于暂停;而逐个界面臆造文案的产品,正是本层要消除的偏差。
退出必须明确说出,不能默认: "no brand" / «без бренда» — 或 "draft it" / «черновиком» — 表示操作者选择不走这条流程: 直接撰写,并说明资料包是按要求跳过的,绝不要默默跳过。
所有权按文件划分,而非按目录划分。 brand-voice 负责资料包中的
权威来源——voice.md、术语词典、facts.md、各渠道指南和本地化政策——
本技能绝不编写这些内容:词典中缺少的术语,或 facts.md 中没有对应条目的数字,
都要报告,绝不为了写完句子而编造——是否添加由 brand-voice 决定。本技能确实负责
strings.md(界面字符串登记表,写入时标记为 Status: proposed)和产品文案。
两者都放在 docs/brand/ 下,但目录不代表所有权——所有权归文件本身。
填写 strings.md 条目是本技能的工作,无需为其存放位置另行审批;协同运行时须先认领文件再编辑,
同一轮中不得改动语气和事实资料。
触发条件
以下英文和俄文短语会触发本技能。为使技能列表不超出预算,描述中仅保留最强的触发短语(2026-10-20);家族路由钩子与此列表一致。
"write copy" / "напиши текст", "App Store description" / "описание для App Store", "store listing" / "описание в сторе", "rewrite this" / "перепиши", "headline" / "заголовок", "CTA" / "кнопка", "microcopy" / "микрокопия", "error text" / "текст ошибки", "this sounds like AI" / "звучит как нейросеть", "post for X" / "пост в твиттер", "reel script" / "сценарий рилса", "video hook" / "хук ролика", "build a landing page" / "сделай лендинг"(指页面文案;视觉层由 sheleg-design 负责)。
参考资料
| 阅读 | 使用场景 |
|---|---|
| ui-copy.md | 产品内的任何字符串 |
| marketing-copy.md | 页面、长文、七轮检查、事实依据 |
| landing-pages.md | 组装落地页:报价、认知、证明、行动 |
| channel-playbooks.md | 社交媒体、博客、更新日志、广告或邮件界面,或创作者、品牌大使计划 |
| video-script.md | 短视频、短片、TikTok 或视频广告:切入角度、结构、时长、镜头清单、关卡 |
| hooks.md | 开头三秒:三段式、26 种公式、40 个模板、B044 筛选器 |
| research-outliers.md | 视频制作前:哪些视频的表现超过了其账号自身水平 |
| store-copy.md | App Store 或 Google Play |
| seo-aeo-safety.md | 爬虫或答案引擎会读取的任何内容 |
| ai-tells.md | 所有会生成文本的模式:默认执行此检查 |
| localization.md | 任何非主要语言地区 |
| surface-registers.md | 界面的语体 |
模式
凡是会生成文本的模式,默认都会执行人性化处理。 这不是一种需要进入的模式,而是撰写、编辑和改编的最后一步,且必须遵循 ai-tells.md 中不可省略的约束。之所以将其设为默认而非可选项,是因为未经处理的草稿会带有该文件所评估的特征,而读者往往在说清原因之前,就已经察觉到了这些特征。
voice.md 通过两个字段记录状态,分别回答不同的问题。Humanization: on | off 表示是否执行这一步;如果未设置该字段,默认值为 on。Humanization pass: 指定运行哪种实现;如果未设置,默认值为 own,这是唯一会读取此套件的语域和规范事实的实现。关闭此功能是一个正当的决定,即使做出决定的人离开后也仍然有效,因此 off 时必须附带一行 Humanization declined:,写明原因和日期。B064 会检查这三种状态。
每次交付文案时,都要用一行说明执行情况,放在文案之前或紧接其后:
Humanization: on (own pass): 7 markers at 2 densities, 4 addressed, 11% changed
Humanization: off (declined 2026-08-30): wording fixed by counsel
这行文字不是装饰。不可见地执行处理,与完全没有执行无法区分;而文案的读者通常也不是设置选项的人。
撰写
- 明确使用场景。该场景必须存在于
channels.md中;如果不存在,应由brand-voice决定,而不是在这里临时发挥。 仅限营销工作,阅读marketing-copy.md→ 撰写前,并根据templates/brand/copy-brief.md创建或更新当前简报。尚未解决的输入保留为unknown;仅涉及界面的工作无需额外加载简报。 - 应用语域:采用
voice.md中的各个维度,以及该使用场景对应的差异。差异可以调整各个维度,但绝不能越过不变原则。 - 撰写。每项主张都必须能追溯到
facts.md。每个产品术语都必须来自terminology.md。 - 先交付文案,再说明理由。对于标题和 CTA,提供两到三个选项,并说明各自舍弃了什么。
- 对于界面文案,添加或更新
strings.md中的行,包含键、file:line、场景和Status: proposed。 - 按照下方「人性化处理」中的约束执行人性化处理,然后输出状态行。对于新文本,变更率以刚刚写出的草稿为基准衡量,因此 50% 的上限不像编辑时那样适用;无论如何都要报告变更率。
编辑
按照 marketing-copy.md 中的顺序进行七轮检查,每轮后回到开头:清晰度、语气与风格、价值说明、证据支持、具体性、情感、零风险。按影响优先级逐轮交付,而非按阅读顺序。
人性化处理最后执行,七轮检查完成后,再输出状态行。之所以放在最后,是因为各轮检查会改写整句;若提前执行人性化处理,其衡量基准就会变成已经不存在的文本。此外,语义保留清单最适合用于检查不会再被改写的版本。
改编
将一篇内容适配到多个使用场景。针对每个场景重写,绝不要把一个语域直接粘贴到另一个场景中。改编后保留的是主张和证据;改变的是篇幅、结构、CTA 策略和语域。
明确说明每个版本删去了什么。帖子串不是只带有换行符的页面。
人性化处理按使用场景分别执行,而不是只针对源文本执行一次。 每个版本都是采用不同语域的不同文本;在博客文章中可以接受的特征密度,放到落地页首屏就不合适。每个使用场景都要有一行状态说明。
人性化
独立模式,用于审核已有文本,不写入任何内容: 继承而来的页面、竞争对手的文案、别人写的草稿。无论在哪运行, 审核都遵循同样的规则,且这些规则不可忽略:
- 每 500 个词的标记超过约 10 个时,应说明情况,并从论点出发重写—— 修补只会用更好的措辞制造同样的模式。
- 更改率超过 50% 时,不要交付。 报告更改率并征求意见。 这已经不再是编辑。
- 输出前运行语义保留检查清单:数字、日期和专有名词保持不变;因果 方向不变;否定不反转;引文保持原样;核心主张不变。
- 已经读起来自然的文本应保持原样。为了证明运行过审核而修改原本没问题 的内容,就是此模式的失败。
- 标记数量不是判定依据,也绝不会成为任何操作的门槛。 说明存在哪些
标记及其密度;绝不要说文本是 AI 写的。标记数量无法证明作者身份——
误报对使用第二语言写作的人影响最大,而写作者不是需要被编辑到流畅、
却从未提出这种要求的缺陷。人性化审核始终仅供参考:
B060只会警告,不会报错。ai-tells.md记录了衡量方式及其约束。 唯一例外是 em dash(AT-06):它是对你所写文本的硬性禁用项,不是 计数项,并列在“不可妥协项”下。 - 引文、注册术语和明确设置为
off都绝不会强制重写。 引文中的标记 是源文本用词;terminology.md中的术语本来就应该重复出现;而Humanization: off(附带原因)会原样保留文本。品牌禁用词是独立的 用户政策——禁用词是品牌在terminology.md中自行选择的内容,不是 机器生成文案的标记,应由相应检查处理,而不是本次审核。 - 先读取
voice.md中的两个字段。Humanization:决定是否运行审核, 默认值为on;Humanization pass:指定使用哪种实现,未设置时为own。即使两项都未设置,也不要停止工作:运行默认设置,打印状态行, 说明使用了默认值,并询问是否记录一次。若指定的工具未安装,则回退到own并说明原因——缺少可选工具不得阻止文案撰写。 - 还有其他实现,值得了解其中两种——
npx sshlg-skills humanizers可列出这台机器上已有的工具。对于不重写 文本的审核、长篇文案,或写作者提供了自己的写作样本以供匹配时,可以 使用其中一种。产品文案则留在这里处理:品牌资料包中的语体和规范事实 才是约束,而通用的人性化工具不会读取这些内容。
不可妥协的要求
-
你撰写的任何语言文本中都不得出现 em dash(U+2014)(负责人决定, 2026-10-18)。这不是频率目标:出现一个就是错误,交付前必须修正, 也不能用其他符号代替(
--、en dash 或起到破折号作用的空格加连字符 都不行)。请使用句号、逗号、冒号或括号,或者改写句子。唯一罕见的例外是 俄语语法需要破折号,且没有自然的改写方式。引文、代码、命令、路径和历史记录 保留其中原有的破折号。B062和B067检查机器能够验证的内容;其余部分参见 ai-tells.md AT-06。 -
标题或标签中不得添加装饰性句号,包括嵌套 HTML、格式化 Markdown 以及“Your agents. Your tools.”这类断句。请根据渲染后的实际效果判断, 而不是只看纯文本导出。保留真正的问句、省略号、缩写、版本号、URL 和常规段落标点。 项目可以将此规则扩展到主视觉摘要和说明文字;请在品牌政策中记录适用范围, 并测试生成的页面。 恢复历史文案时,请重新套用当前项目的标点政策;旧版精确文本快照不构成有意例外。
-
不得捏造事实、统计数据、引文或专家。 不要为了赶截止日期、充实基准测试, 或让占位内容显得更好而这样做。应拒绝,说明原因,并提出寻找真实内容。
-
任何内容包中的
error、destructive confirm、billing and receipts或paywall and upgrade场景都不得使用幽默。用户在这些场景中会失去某些东西。 -
一个操作,一个名称。 为操作命名之前,先在
strings.md中搜索。 为已有操作另起名称是缺陷,不是同义词。 -
绝不引用
facts.md中没有的数字。
完成定义
- 每个字符串或章节都能追溯到一个表层记录和一种语气。
- 无论报告哪种状态,都要打印人性化状态行。
- 新的界面字符串必须放在
strings.md中,并注明位置和场景。 - 运行检查器前先解决其依赖:如果存在
docs/brand/lint.py,就使用它;否则,在其脚本目录中找到已安装的 super-ux 检查器brand_lint.py,并传入项目的docs/brand路径。不要臆造项目本地脚本,也不要假定 shell 导出了插件根目录变量。如果两者都不存在,要明确指出缺少的工具和手动检查范围;绝不能称其为检查通过。 - 确认
Sources:能解析到已修改的表层。HTML 标题角色必须在复制投影后保留;扁平段落不能证明标题覆盖完整。标题标点是必要门槛时,运行解析出的脚本并加上--fail-on B063(或用--strict检查所有警告)。如果旧版脚本不接受该标志,就应更新脚本,而不是重试并悄悄去掉这一门槛。 - 除了检查器,还必须进行语气检查;绝不能用它替代检查器。 根据会话中是否有该工具来决定是否执行,不要看配置:如果存在语气检查 MCP 工具(提供
*.check和*.voices.list的工具),就用文本的locale、项目已保存的语气(若语气列表中有,则作为voiceRef),以及其 schema 提供的register和format,检查你编写的每一段公开文本。目标是页面使用register: web和format: web-page;在 schema 列出这些选项之前,使用register: marketing(在广告或商店表层分别使用ad或store),省略format,并说明尚无 web-page pack。报告报告 ID,并逐条处理或驳回每项发现:这些只是建议,与B060类似。如果没有该工具,则打印voice checker: not connected, brand_lint only并继续。 - 报告已扫描的表层、剩余警告以及准确的命令和退出代码。存在建议性警告时,即使退出代码为零,也不代表审查干净。检查渲染后的文案和生成器;只检查源文件无法发现外部 CSS 或运行时文本。
- 对于任何报告为缺失的内容——术语、事实或表层——都要明确指出,不能绕过。
references/ 中还有什么。 本技能直接提及 13 个契约;references/ 中有 15 个,因为本技能提及的契约还会链接到其他契约,而整个依赖闭包都随技能一起发布——skills CLI 会安装一个目录,否则兄弟目录中的文件就会成为悬空文件。打开此处提及的契约;其余契约会由它们按名称引出。