brand-voice

brand-voice — 定义并保持语言身份

属于 super-ux 的一部分——完整流程参见 system-map.md。 修改后，运行 python3 docs/brand/lint.py。

docs/ux/ 决定产品做什么。此技能决定产品如何表达，并负责目标项目中的 docs/brand/。

格式规范：brand-contract.md （brand-contract v1）。在编写或编辑 docs/brand/ 下的任何内容前，先阅读此规范。绝不能偏离其中的文件名、字段名或状态——代码检查器和审计都会据此进行检查。

语气包库：voice-packs.md——六种原型，各自声明了一种失效模式。语域模型： surface-registers.md。地区设置： localization.md。

触发条件

会将请求路由到此技能的英文和俄文短语。为了让技能列表符合预算（2026-10-20），描述中只保留了最强的几种；系列路由钩子会匹配此列表。

"tone of voice" / "тон оф войс"、"brand voice" / "голос бренда"、"brandbook" / "брендбук"、"our terminology" / "наша терминология"、"how should this sound" / "как это должно звучать"、"the copy is inconsistent" / "текстовка разная везде"、开始制作任何营销内容，或将产品引入 docs/brand/。

未指定任务时调用 → 报告状态，然后提出一项后续行动

1. 报告状态：是否记录了语气包，voice.md 中的 Status 是什么，有多少事实标记为 ⚠ TBD 或没有来源，地区设置是否一致，以及代码检查器报出的错误和警告数量。
2. 列出所有尚未解决的事实。绝不能编造事实来填补空缺——未知信息应如实报告，而不是补上。
3. 只提出一项后续行动，通常是最优先的未解决事实，或用户实际前来处理的内容。

语气来源

语气包源自 docs/ux/foundation.md——用户画像、工作任务，以及决定性输入：产品失效时，用户会失去什么。 当赌注只是一份播放列表时，讨喜的语气或许无妨；当赌注是工资发放时，这种语气就无法容忍。

依赖关系是单向的。绝不能因为某种语气讨喜，就改变用户画像。如果没有基础文档，则以降级模式开展工作：标记 Derived-from: inferred，明确说明应构建 WHY 层，然后继续，而不是因此停滞。

**这一路由还提供了口头退出选项：**操作者说 "no brand" / «без бренда» 即表示拒绝——应在不使用语气包的情况下继续，并明确说明，而不是悄然省略。

选择工作流

情况	工作流
没有 docs/brand/	初始化
已选择语气包，但缺少产品具体信息	校准
定位、用户画像或事实已更改	更新
对一致性有疑问，或发布前	验证

说明你将运行哪种工作流。

初始化

1. 阅读基础资料。 用户画像、待完成任务（JTBD）、用户旅程、利害关系。若缺少这些资料，请进行访谈：这是为谁设计的，他们需要对什么负责，失败会给他们造成什么代价。
2. 阅读现有内容。 界面文案、落地页文案、README、商店页面、近期帖子。即使没人刻意选择，当前的语气也是一种数据。
3. 提出一套方案并说明理由，再提供一个备选方案。 说明为什么第二选择不够理想。让用户选择。
4. 从此技能自带的 templates/brand/ 初始化 docs/brand/，并首先填写 Sources: 区块。在 Linter 知道项目将文本存放在哪里之前，其他内容都无法检查。
5. 全面盘点 strings.md：路由、屏幕、按钮、状态、错误、空状态。每条文案都要有一行记录，注明其 file:line 和所服务的场景。对于大型代码库，可并行使用可用的只读子 Agent，每个 Agent 负责一个区域；若不委派，则依次检查相同区域，并遵守相同的证据要求。
6. 询问项目希望采用哪种人性化处理方式，并将答案写入 voice.md 的 Humanization pass: 字段。own 是默认选项，也是唯一会读取此方案的语气规范和事实的选项；运行 npx sshlg-skills humanizers 可查看已安装的其他选项及其安装方法。只询问一次：设置此字段就是为了不再重复询问；它用于选择处理方式，而非给出评判。
7. 所有内容的初始状态均为 Status: draft。

校准

这套方案只是起点；在这一步，它才会成为产品自己的方案。

• 术语。 产品会用什么词替换哪些通用词？根据弱动词、模糊措辞链以及 ai-tells.md 初始化禁用词表，然后添加此处特有的内容。
• 事实。 产品引用的每个数字都要附上来源、核查日期和复审日期。内部数据标记为 Public: no。
• 渠道。 产品实际拥有的每个界面都要有一条记录。将规范登记为差异项；Forbidden: 始终同时包含物理限制和品牌规范两部分。
• 现成文案。 编写六到十条适用于本产品的文案，不要照搬方案中的内容。
• 失败模式。 将方案中的内容复制到 voice.md，以便审计能按名称查找。
• 破折号不变量。 在 voice.md 的不变量中加入“任何语言的新文本都不得使用 em dash（U+2014）”（负责人决定，2026-10-18）。这不是方案可以放宽的语气选择：所有方案都必须遵守，只有在俄语中无法自然改写时，语法上必须使用的俄语破折号可以保留（ai-tells.md AT-06、B062、B067）。

逐节提交审批。获批后，状态由 draft 变为 validated。

更新

1. 确认发生了哪些变化：定位、用户画像、价格、层级名称或新增界面。
2. 应用修改。实体名称变更时，需在同一次修改中同步更新 terminology.md、strings.md 及每种语言环境的文件。
3. 修改过的文件状态降为 Status: draft，直至重新获批。
4. 重新标注 Last calibrated。

验证

1. 完整性：契约要求的每个字段都已填写；状态值合法；Derived-from 可在基础资料中找到对应项。
2. 覆盖范围：产品发布的每个界面都有记录；声明的每种语言环境都有对应文件；每个引用的数字都有对应事实记录。
3. 一致性：运行 python3 docs/brand/lint.py，并整合其发现的问题。它只能验证机械层面的问题；报告它无法识别的内容，并将其作为问题提交给 /ux-audit copy。
4. 时效性：基础资料是否比最近一次校准更新、事实是否已过复审日期、物理限制规则是否已过核查日期。

完成定义

• 遵守契约；每个文件上都带有标记。
• 用户已查看并批准新增或更改的部分。
• python3 docs/brand/lint.py 的退出码为 0，或已说明所有剩余问题及其原因。
• 未知信息明确标为未知。不得为填满表格而编造内容。

references/ 中还有什么。 本技能直接提及 6 份契约；references/ 中有 13 份，因为本技能提及的契约还链接到其他契约，且整个依赖闭包都随本技能一起分发——技能 CLI 只会安装一个目录，而同级目录中的文件若未随之安装，就会成为悬空文件。打开这里提及的契约；其余契约会在某份契约指引你时，按名称从中找到。