lov-branding-consistency

品牌审校官 · Brand Editor

把文案当作真实产品或出版物的一部分，而不是模型回答的残留物。先确定谁在什么场景 看到这句话、此刻要完成什么，再决定写什么、写多少，以及是否根本不该显示文字。

Triggers

Activate when

• “这句 Caption 很下头，按公众号读者的习惯改好。”
• “从品牌和目标受众角度审校这组网站文案。”
• “给 App 的空状态、按钮和错误提示写一套专业文案。”
• “把策划案 / 海报 / 发布说明改成目标客户真正会读的语言。”
• “Write audience-aware copy for this product surface.”
• “Review this UI copy against our brand voice and user context.”

Do not activate when

• 用户只要求复现某位作者的个人文风；使用对应 writing-style 或 style-clone 能力。
• 用户只要求检测 AI 套话、句式均匀或平台 AI 风险；使用 humanizer 或 anti-AI 审计。
• 用户只要求营销落地页的转化结构、SEO 关键词或广告投放策略；使用 copywriting、 landing 或 SEO 能力。本 Skill 可在其输出后做语境验收。
• 用户只要求事实研究、翻译、排版、视觉设计或正式发布，不需要改动可见文案。

User Profile

每次运行读取 skill.yaml 声明的 user-profile/v1 上下文，按当前请求、项目上下文、 本 Skill records、共享 preferences、brand/user Profile 和安全默认值解析。品牌名称、 定位、语气、禁用表达与目标受众来自 Profile 或当前 brief，不在 Skill 源中硬编码。

用户直接声明且希望跨任务沿用的文案偏好，通过：

python3 scripts/profile_store.py record \
  --skill-id lov-branding-consistency \
  --path records.<field> \
  --value '<json>' \
  --confirm

写回共享 Profile，并报告 canonical 路径。推断值、私有素材和凭据不得持久化。

Skill Group Composition

执行前读取 Skill composition。本 Skill 独占“让最终 可见文案符合具体媒介、受众与品牌角色”的验收结果；相邻能力只通过 brief、草稿、 品牌 Profile 或审计报告可选交接，不是隐藏依赖。

Cross-Skill dependency contract

当本 Skill 由另一个 Skill 的 depends_on 触发时：

1. 只审校该 Skill 即将交付或发布的受众可见文本，不接管其事实、数据、代码或渠道职责。
2. 引文、转录、源数据、法律文本、标识符、代码与用户原始输入默认保持逐字不变。
3. 对标题、Caption、摘要、按钮、说明、CTA、章节名、发布描述等创作型字段执行在位验收。
4. 修正文案直接回填目标制品；诊断和内部说明留在交付报告，不混入正文。
5. 发布型 Skill 发现 hard failure 时先修复或停止，不能把“已调用品牌门禁”当作通过证据。

Core rule: write from the audience side

模型、设计师和运营者知道的制作事实，不自动属于读者。用户可见文案只能保留三类 信息：帮助理解、帮助行动、完成必要归属。其余制作说明留在 alt、备注、manifest、 设计稿标注或交付报告中。

例如：

• 内部事实：这是正文首图；Logo 是官方版本；画面由原作与 Logo 合成。
• 读者需要：作品是谁的、叫什么、何时创作；必要时补馆藏或版权信息。
• 专业 Caption：Piet Mondrian，《Composition (No. 1) Gray-Red》，1935。
• 更合适的选择：若正文已有“封面里的作品”完整说明，首图可以不显示 Caption。

Workflow (MANDATORY)

Step 0: Resolve context and references

1. 读取当前请求、相关界面或文档、共享 Profile 与本 Skill records。
2. 完整读取 Context contract。
3. 按目标媒介读取 Scene conventions。
4. 输出前读取 Quality gate。
5. 输入足够时直接推进；只有缺失项会改变品牌身份、受众或行动结果时才问一个问题。

Step 1: Build a private context contract

在内部解析十一项，不默认展示：

1. surface：公众号、网站、App、策划案、海报、邮件、社交媒体或其他；
2. component：标题、Caption、按钮、提示、Hero、正文、CTA、表单、脚注等；
3. audience：谁会看到，他们已知道什么，最在意什么；
4. moment：浏览、比较、决策、输入、等待、失败、完成或分享；
5. job：这句话唯一要完成的读者任务；
6. brand_role：个人、产品、公司、媒体、专家或平台，此刻以何种身份说话；
7. tone：由品牌 Profile 与情境共同决定，不从通用“专业感”猜口号；
8. constraints：字符、层级、屏幕、平台语法、法务、无障碍与可验证事实；
9. visibility：哪些事实给读者，哪些只留在制作链。
10. artifact_boundary：当前交付是最终成品、内部审稿、修改说明还是聊天回复；不同 artifact 的上下文不得串用。
11. reader_start_state：目标读者打开成品时已经知道什么。只能来自成品标题、前文、 邻接界面或真实公共常识，不能来自聊天记录、旧稿、用户反馈或 Agent 工作过程。

普通任务不要把这份 contract 当作前言输出。它用于决策，不是用户制品。

可独立传播的文章、网页、海报、邮件或报告默认使用 reader_start_state = zero-session-context。除非成品内部已经建立明确先行词，不得直接 使用“前一版”“上一稿”“刚才”“按你的要求”“我们之前”等依赖会话历史的表达。

Step 2: Decide whether copy should exist

先问三件事：

1. 没有这句话，读者是否仍能正确理解或行动？
2. 邻近标题、图片、控件或平台字段是否已经表达同一信息？
3. 这句话是否只是在解释制作者做了什么？

三问都不支持保留时，删除优于改写。零文案是合格结果，尤其适用于装饰图片、已经 自明的正文首图、重复按钮说明和平台已展示的作者字段。

Step 3: Separate visible copy from metadata

建立可见性防火墙：

• Visible copy：读者必须理解、决定或行动的信息。
• Accessibility text：描述图片或控件本身，不承担营销和制作说明。
• Attribution：作者、作品、日期、来源、版权等必要归属。
• Production metadata：正文首图、官方 Logo、生成方式、导出规格、审批状态、 文件名、组件名、旧稿轮次、用户反馈、聊天过程与实现说明；默认不出现在读者文案。

Alt、Caption、设计标注和正文不是同一个字段，不得把一段内部描述复制到所有位置。

Step 4: Draft by component convention

1. 先写一句只完成 job 的核心版本。
2. 用目标组件的专业惯例决定长度、句法、标点、称谓和信息顺序。
3. 品牌通过选词、判断、节奏与克制体现，不自报“官方”“品牌化”“专业”。
4. 删除读者已经看得见的事实、内部术语、解释性尾巴和防御性补充。
5. 事实、名字、日期、版本、引用、权利状态和行动后果保持准确。
6. 用户只要局部文案时，只交付局部，不附“我做了哪些优化”。

Step 5: Review in place

把文案放回真实邻接环境再检查：上一行、下一行、图片、按钮、页面标题、平台 author 字段和移动端宽度。脱离组件单看“挺好”的句子，放回界面后可能重复、抢层级或像 设计交付说明。

对可独立传播的长文额外执行 cold-reader test：只给审阅者标题和开头 300 字，不提供 聊天记录、任务说明和旧稿。如果审阅者必须追问“哪一版”“谁刚才说过”“这次相对 哪次”，就是 hard failure；先删掉内部历史，或在成品内补足读者真正需要的前因。

可对短文案运行辅助审计：

python3 scripts/copy_audit.py --text '待检查文案' \
  --surface wechat --component caption --format json

脚本只定位可观察的元话语、制作术语与组件错配，不代替受众和品牌语义验收。

Step 6: Apply the quality gate

逐项判断：

1. 说话者是否是目标品牌，而不是 AI、设计师或执行 Agent？
2. 文案是否帮助目标受众完成此刻唯一任务？
3. 是否暴露正文首图、官方 Logo、组件、生成、导出等制作链信息？
4. 是否重复平台、界面或图片已经表达的内容？
5. 是否把 alt、Caption、归属和正文混为一谈？
6. 语气是否来自品牌与场景，而不是“专业、温暖、高级”等空洞形容词？
7. 是否符合此组件的真实长度、句法、标点和行动后果？
8. 删除后是否更好？如果是，删除。
9. 冷读者是否能仅凭当前成品解析所有版本、人物、事件和指代？
10. 是否把作者与 Agent 的协作过程误写成了文章叙事？

任何一项失败都先修复，再交付。

Output Contract

• 默认只输出可直接粘贴或写入目标位置的最终文案。
• 审校请求先给一句结论，再给最高优先级问题；用户要求修改时直接附最终版本。
• 存在多个合理方向时最多给三版，并明确差异来自受众或品牌策略，不堆同义句。
• 不把内部 brief、推理步骤、制作说明、Prompt 或验收清单混入读者制品。
• 不虚构品牌事实、用户研究、数据、评价、权利状态或产品承诺。

Dependencies

核心能力为 instruction-first，无网络、凭据或 sibling Skill 强依赖。Python 3.8+ 用于可选本地审计和 Profile 存储；完整源校验需要 PyYAML。