ECC brand-voice 技能深度解析：从真实素材构建可复用的写作风格画像（VOICE PROFILE）

本文以 ECC 仓库中的 brand-voice 技能定义 为核心，完整拆解这一"来源派生写作风格系统"的激活条件、素材优先级、采集流程、风格特征提取维度、VOICE PROFILE 输出契约与默认语音规则，并结合仓库中 x-api、content-engine 等下游技能的实际调用方式，说明该画像如何在内容生产、外联与社交工作流中被消费。读完本文，你可以按同一套方法论为任意作者/品牌从真实帖子、文章与产品文档中提取风格画像，并将其作为会话级可复用资产接入 Agent 内容管线，替代千篇一律的通用 AI 文案。

一、brand-voice 在 ECC 中的定位

ECC（agent harness performance optimization system）将写作能力组织为一条"内容泳道（content lane）"，而 brand-voice 是这条泳道的声音层（voice layer）。技能自身的 frontmatter 描述给出了它的核心契约：

---
name: brand-voice
description: Build a source-derived writing style profile from real posts, essays,
  launch notes, docs, or site copy, then reuse that profile across content,
  outreach, and social workflows. Use when the user wants voice consistency
  without generic AI writing tropes.
---

技能正文的开场一句话概括了它的哲学：从真实素材（real source material）构建一份持久（durable）的语音画像，然后在所有地方复用这份画像，而不是每次都从零推导风格，或退化成通用 AI 文案（generic AI copy）。

从仓库文档可以确认它的"权威"地位：

• CHANGELOG.md 将其标注为 "brand-voice — canonical source-derived writing-style system"（规范性的来源派生写作风格系统）；
• WORKING-CONTEXT.md 记录了两次关键整合：2026-04-01 将 brand-voice 添加为规范的来源派生写作风格系统，并把内容泳道接线为"把它当作共享的声音真源（shared voice source of truth），而不是在各技能中重复部分式风格启发式"；2026-04-02 对写作泳道做了同样处理——content-engine、crosspost、article-writing、investor-outreach 从此只保留各自工作流特有的指引，不再各自维护第二套语音模型或重复完整的禁用清单；
• README.md 将 brand-voice 归入"Operator and outbound workflow expansion"（运营与外联工作流扩展），与 social-graph-ranker、connections-optimizer 等共同构成运营泳道；
• 仓库在 .agents/skills/brand-voice/ 与 skills/brand-voice/ 两处存放该技能，内容一致，后者 frontmatter 额外带有 metadata: origin: ECC 标记；docs/ja-JP/skills/brand-voice/SKILL.md 则提供日文版本。

在 Agent 注册侧，.agents/skills/brand-voice/agents/openai.yaml 声明了它的接口与调用策略：

interface:
  display_name: "Brand Voice"
  short_description: "Source-derived writing style profiles"
  brand_color: "#0EA5E9"
  default_prompt: "Use $brand-voice to derive and reuse a source-grounded writing style."
policy:
  allow_implicit_invocation: true

其中 allow_implicit_invocation: true 意味着该技能可以在没有用户显式点名的情况下被隐式调用——这与它"作为共享声音层被下游技能自动前置运行"的角色设计是吻合的。

二、激活时机：When to Activate

原文档给出了四条明确的激活场景，即当出现以下任一情况时应启用该技能：

• 用户希望以特定声音产出内容或外联信息（content or outreach）；
• 为 X、LinkedIn、邮件、发布帖（launch posts）、线程（threads）或产品更新写作；
• 将某位已知作者的语气跨渠道适配（adapting a known author's tone across channels）；
• 既有内容泳道需要一套可复用的风格系统，而不是对每次模仿做一次性处理（one-off mimicry）。

值得注意的是原文刻意强调"可复用"而非"单次模仿"：如果只需要模仿一篇范文的语气，直接让模型照着写即可；而 brand-voice 的目标是沉淀出能被多个下游输出反复消费的资产。

三、素材优先级：Source Priority

风格画像的可靠度完全取决于素材质量。原文档规定了**按优先级取用"最强真实素材集（strongest real source set）"**的顺序：

1. 近期的原创 X 帖子与线程（recent original X posts and threads）；
2. 文章、随笔、备忘录、发布说明或通讯（articles, essays, memos, launch notes, or newsletters）；
3. 真实有效的外发邮件或私信（real outbound emails or DMs that worked）；
4. 产品文档、变更日志、README 表述框架与站点文案（product docs, changelogs, README framing, and site copy）。

并有一条硬约束：不得把"通用平台范例"（generic platform exemplars）当作素材来源——也就是说，不能拿"X 上大家怎么写发布帖"之类的平台套路来推断某位作者的声音，只能从该作者本人的真实产物中提取。

这一优先级逻辑与 x-api 技能中的取数接口相互咬合。skills/x-api/SKILL.md 专门提供了一个"Pull Recent Original Posts for Voice Modeling"小节，用只读 Bearer Token 拉取目标作者的近期原创帖子（排除转发与回复），正好对应素材优先级第 1 项：

resp = requests.get(
    "https://api.x.com/2/tweets/search/recent",
    headers=headers,
    params={
        "query": "from:affaanmustafa -is:retweet -is:reply",
        "max_results": 25,
        "tweet.fields": "created_at,public_metrics",
    }
)
voice_samples = resp.json()

-is:retweet -is:reply 的查询条件确保只采集原创内容，避免把回复语气、转评互动噪声混入风格样本；max_results 取 25 也略高于 brand-voice 建议的样本上限（20 条），为筛选留出余量。需要提醒的是，x-api 技能在文首自标"Drift-prone skill"：X API 的端点、权限档位与配额变化频繁，引用速率限制或实现拉帖流程前应先核对 X 开发者当前文档。

四、采集工作流：Collection Workflow

原文档定义了五步采集流程，可直接照做：

1. 收集 5 到 20 条代表性样本（if available）——样本量下限保证统计意义，上限避免风格漂移被平均掉；
2. 优先使用近期素材，除非用户明确说旧文更"正统（canonical）"；
3. 若素材集明显分裂，区分"公开发布声音（public launch voice）"与"私人工作声音（private working voice）"——这一点直接呼应了 schema 末尾"素材冲突时明确指出分裂、而不是平均成一团糊"的准则（见第六节）；
4. 如果可访问 X 实时数据，先用 x-api 拉取近期原创帖子再动笔——与第三节所述接口呼应；
5. 如果站点文案重要，纳入当前 ECC 落地页与仓库/插件表述框架——即把产品官网 copy 与仓库 README 的自我表述当作第 4 级素材。

五、提取什么：What to Extract

采集到样本后，原文档列出了九个必须提取的风格维度。这九项不是文学评论，而是可操作化、可写入 profile 字段的观察点：

维度	含义
Rhythm and sentence length	节奏与句长：长短句分布、是否碎片化
Compression vs explanation	压缩与解释的取向：密度高、少解释，还是充分展开
Capitalization norms	大小写规范：是否常规大写、是否故意破格
Parenthetical use	括号的使用方式与目的
Question frequency and purpose	提问的频率与用途：设问、引导、还是几乎不用
How sharply claims are made	断言的锋利程度：直给结论还是层层铺垫
Numbers, mechanisms, receipts	数字、机制、实据（receipts）出现的频率
How transitions work	段落/论点之间如何过渡
What the author never does	该作者从不做的事——负面清单同样关键

最后一条"该作者从不做的事"是整个提取清单中最容易被忽略、也最有判别力的一项：风格画像的边界（Banned Moves）与它的正面特征同等重要。

六、输出契约：VOICE PROFILE 与 Schema

技能的产物是一个可复用的 VOICE PROFILE 块，供下游技能直接消费。原文档要求使用 references/voice-profile-schema.md（公开副本为 skills/brand-voice/references/voice-profile-schema.md）中规定的精确结构，全文如下：

VOICE PROFILE
=============
Author:
Goal:
Confidence:

Source Set
- source 1
- source 2
- source 3

Rhythm
- short note on sentence length, pacing, and fragmentation

Compression
- how dense or explanatory the writing is

Capitalization
- conventional, mixed, or situational

Parentheticals
- how they are used and how they are not used

Question Use
- rare, frequent, rhetorical, direct, or mostly absent

Claim Style
- how claims are framed, supported, and sharpened

Preferred Moves
- concrete moves the author does use

Banned Moves
- specific patterns the author does not use

CTA Rules
- how, when, or whether to close with asks

Channel Notes
- X:
- LinkedIn:
- Email:

字段设计与第五节的九个提取维度一一对应：Rhythm/Compression/Capitalization/Parentheticals/Question Use/Claim Style 覆盖正面特征；Preferred Moves 与 Banned Moves 对应"作者做什么/从不做"；CTA Rules 与 Channel Notes 补充收尾策略与分渠道差异；头部的 Author/Goal/Confidence 与 Source Set 保证画像可溯源——置信度声明与素材清单正是"素材不足时用默认值、素材充足时以真实素材为准"这一机制的落点。

schema 文件末尾还附有四条编写准则：

• 保持画像具体且有素材支撑（concrete and source-backed）；
• 使用短条目，而非论述性段落；
• 每一条 Banned Move 必须能在素材集中被观察到，或是用户明确要求的；
• 若素材集相互冲突，明确指出分裂（call out the split），而不是平均成一团糊（averaging it into mush）。

原文档在 Output Contract 一节还强调了两点定位性表述：画像要"结构化且足够短，短到能在会话上下文里复用"；"重点不是文学评论，重点是操作性复用（operational reuse）"。换句话说，VOICE PROFILE 是一份运行时资产，它的价值体现在被 content-engine 之类的下游技能加载并约束其输出，而不是供人赏析。

七、Affaan / ECC 默认声音

当用户要求 "Affaan / ECC voice" 但实时素材匮乏时，原文档内置了一套出厂默认值（除非更新的素材将其覆盖）：

• 直接、压缩、具体（direct, compressed, concrete）；
• 细节、机制、实据与数字胜过形容词；
• 括号用于限定、收窄或过度澄清，而非点缀；
• 大小写保持常规，除非有真实理由破格；
• 提问稀少，且不得作为钓引（bait）；
• 语气可以是锋利、直白、怀疑或冷干的（sharp, blunt, skeptical, or dry）；
• 过渡应当是"挣来的（earned）"，而不是被磨平的顺滑。

这套默认值与 content-engine 的 Non-Negotiables（"从素材而非公式出发""具体胜过形容词""不主动制造互动钓引"）相互印证，说明 ECC 的默认声音并非随意设定，而是贯穿内容泳道的一致性约束。

八、硬禁用清单：Hard Bans

原文档规定以下十类表达一旦出现即删除并重写：

1. 伪好奇钩子（fake curiosity hooks）；
2. "not X, just Y" 句式；
3. "no fluff"（"没有废话"——用宣称不废话来装风格）；
4. 强行全小写（forced lowercase）；
5. LinkedIn 思想领袖式节奏（thought-leader cadence）；
6. 钓引式提问（bait questions）；
7. "Excited to share"（"很激动地分享"）；
8. 泛泛的创始人旅程填充（generic founder-journey filler）;
9. 尬括号（corny parentheticals）——注意与第七节"括号用于限定/收窄"的正面规则形成对照；
10. （以上 9 条为原文完整清单，逐条照录。）

这份清单的设计意图是反"AI 套路感"：所列每一条都是 LLM 生成社交文案时的高频默认行为。它与 content-engine 的 Hard Bans 清单（如 "In today's rapidly evolving landscape"、"game-changer/revolutionary/cutting-edge" 等）分工明确——brand-voice 管声音层面的禁用，content-engine 管内容层面的禁用，且按 WORKING-CONTEXT 记录的 2026-04-02 整合规则，各技能不再各自重复完整的禁用清单，避免规则漂移。

九、持久化规则：Persistence Rules

画像产出后如何管理生命周期，原文档给出三条规则：

1. 同一会话内跨任务复用最新已确认的 VOICE PROFILE——不重复推导；
2. 若用户要求持久化产物，将画像保存到用户指定的工作区位置或记忆面（memory surface）；
3. 除非用户明确要求，不得创建纳入版本控制（repo-tracked）的文件来存放个人声音指纹——这是一条隐私边界：个人写作风格画像属于敏感资产，不应默认可被提交进仓库。

第 1 条解释了为什么 schema 要求画像"短到能在会话上下文里复用"：它的运行形态是会话级缓存，而不是文件级数据库。

十、下游消费链路：VOICE PROFILE 如何被使用

原文档的 Downstream Use 一节规定，brand-voice 应在以下场景之前或之内运行：

• content-engine
• crosspost
• lead-intelligence
• 文章或发布写作（article or launch writing）
• 面向 X、LinkedIn、邮件的冷启动或温启动外联（cold or warm outbound）

并声明：若其他技能已有部分语音捕捉（partial voice capture）章节，本技能是真源（canonical source of truth）。仓库中的实际接线印证了这一声明：

• skills/content-engine/SKILL.md 的 Voice Handling 小节写明 "brand-voice is the canonical voice layer"，并要求在"存在多个下游输出、用户明确在意写作风格、内容属于发布/外联/声誉敏感"三类情形下先运行它，然后"在这里复用产出的 VOICE PROFILE，而不是重建第二个语音模型"；其 Quality Gate 也把"每份草稿听起来像目标作者、而不是平台刻板印象"列为交付前检查项；
• skills/x-api/SKILL.md 的 Integration with Content Engine 小节给出了完整的七步管线：需要声音匹配时先拉取近期原创帖 → 构建或复用 VOICE PROFILE → 用 content-engine 生成 X 原生格式内容 → 校验长度与线程结构 → 除非用户明确说"现在发"，否则交草稿待批 → 批准后经 X API 发布 → 通过 public_metrics 追踪互动；
• agents/marketing-agent.md 中，营销 Agent 被要求"写作前锁定语气画像（Lock the tone profile before writing）"，并在需要跨多个输出保持声音一致时委托给 brand-voice；
• commands/marketing-campaign.md 也把 brand-voice 列为该命令的配套技能："tone needs locking across multiple outputs 时的语音捕捉"。

从源码结构看，整条链路是单向的：brand-voice（生产画像）→ content-engine / crosspost / 外联技能（消费画像）→ x-api（取数与发布），画像本身在会话内流动，不落库，除非用户显式要求持久化。

十一、在自己的项目中落地：查看、复制与适配

ECC 仓库本身是只读的，你可以按以下方式在自己的工程中复用这套体系：

1. 阅读规范定义：主文件 .agents/skills/brand-voice/SKILL.md 与其 schema references/voice-profile-schema.md，公开目录下的 skills/brand-voice/ 副本内容相同且带 origin: ECC 元数据，可作为分发基线；
2. 在自己的 Agent 技能目录下复制该目录结构（SKILL.md + references/ + 可选 agents/openai.yaml），保留 frontmatter 的 name 与 description 字段——description 同时承担了"何时激活"的触发说明，是技能被隐式调用的依据；
3. 按第三节优先级准备你自己的素材集：若目标作者有 X 账号且你有 API 访问，可参照 skills/x-api/SKILL.md 的只读取数方式先拉 5–20 条近期原创帖；否则退化为文章、备忘录与产品文档；
4. 按第五节九维度提取、第六节 schema 产出画像，并把第七节的 Affaan/ECC 默认值替换为你自己的"出厂默认"；
5. 接入下游：在你自己的内容/外联技能中声明"voice 层以本画像为真源"，避免每个下游技能各自维护一套风格启发式——这正是 ECC 在 2026-04-02 整合写作泳道时解决的问题。

适用前提与限制：该技能是"技能定义文档"（Markdown 工作流规范），本身不含可执行代码，依赖宿主 Agent 运行时加载执行；实时拉帖环节依赖 X API 的可用性与账户权限档位（x-api 技能已提示其端点与配额易变，应以 X 开发者文档为准）；画像质量上限由素材集决定——素材冲突时应显式声明分裂而非强行平均，素材不足时应显式回退到声明过的默认值而非虚构风格特征。