ECC content-engine 技能解析：面向 Agent 的多平台原生内容生产系统

在 Claude Code、Codex、Cursor 等 AI 编程代理生态中，「Skill（技能）」是以 Markdown 文档定义的、可被 Agent 按需激活的工作流单元。ECC（The agent harness performance optimization system）仓库中的 content-engine 技能就是典型代表：它把「从一手素材到 X / LinkedIn / 短视频 / YouTube / Newsletter 多平台原生内容」这一内容生产流程，编码为一套可复用的规则体系，核心原则是「不抹平作者真实声音、不把内容写成平台腔的口水文」。本文基于仓库中该技能的完整定义文档，拆解其激活条件、五条不可妥协准则、Source-First 工作流、语音（Voice）分层机制、平台适配规则、七步 Repurposing 流程与质量门禁，并结合仓库中的配套技能（brand-voice、crosspost、x-api）和命令（/marketing-campaign）说明其在 ECC 内容生产链路中的实际调用关系，读完你可以理解如何在自己的 Agent 配置中构建一套不产出"平台垃圾内容"的内容系统。

技能定位与在仓库中的存在形态

content-engine 在仓库中存在两个副本位置，分别服务于不同的加载面：

• .agents/skills/content-engine/SKILL.md：面向 .agents 规范目录的技能定义（本文分析的主体）；
• skills/content-engine/SKILL.md：技能库中的同源版本，随 ECC 的技能分发体系（manifests/ 安装清单）一起安装到用户工作区。

技能的 Frontmatter 声明了激活语义（见 .agents/skills/content-engine/SKILL.md）：

name: content-engine
description: Create platform-native content systems for X, LinkedIn, TikTok,
  YouTube, newsletters, and repurposed multi-platform campaigns. Use when the
  user wants social posts, threads, scripts, content calendars, or one source
  asset adapted cleanly across platforms.

description 字段不仅是描述，更是 Agent 判断「何时激活该技能」的触发条件：用户要写社交帖、帖子串（threads）、脚本、内容日历，或者要把一份源素材干净地适配到多个平台时，该技能即应介入。

同目录下还有一个 agents/openai.yaml，用于在 OpenAI 系 Agent 界面上注册该技能：

interface:
  display_name: "Content Engine"
  short_description: "Platform-native content systems and campaigns"
  brand_color: "#DC2626"
  default_prompt: "Use $content-engine to turn source material into platform-native content."
policy:
  allow_implicit_invocation: true

其中 allow_implicit_invocation: true 表示该技能允许被隐式调用（由 Agent 根据任务语义自动激活，而不需要用户显式指名），这与 description 中"Use when the user wants..."的触发语义相呼应——从源码结构看，ECC 的技能激活机制依赖 description 语义匹配 + 策略开关两条路径。

激活场景：什么时候该用它

原文档的 "When to Activate" 一节给出了五类触发场景（SKILL.md）：

1. 写 X 帖子或帖子串（posts / threads）；
2. 起草 LinkedIn 帖子或产品发布更新（launch updates）；
3. 为短视频或 YouTube 讲解视频写脚本；
4. 把文章、播客、产品演示、文档、内部笔记等 repurpose（再加工）成公开内容；
5. 围绕某个产品、洞察或叙事，构建发布序列（launch sequence）或持续性内容系统。

这五类场景覆盖了从「单条帖子」到「跨平台内容系统」的完整粒度：场景 1–3 是单平台单条产出，场景 4 是素材转化，场景 5 是体系化运营。这一点与 ECC 中的 /marketing-campaign 命令形成互补——后者处理完整营销战役（定位、落地页、邮件序列、广告变体、内容日历），而 content-engine 专注于其中「平台原生社交内容生产」这一环。/marketing-campaign 命令文档在 "Agent Delegation" 一节明确声明了这种委派关系（commands/marketing-campaign.md）：该命令会调用 marketing-agent 做战役规划，在需要锁定语气时调用 brand-voice，调用 content-engine 做平台原生社交内容生产，再调用 crosspost 做多平台分发。

五条不可妥协准则（Non-Negotiables）

技能把五条准则定义为 Non-Negotiables（不可谈判项），这是整个内容系统的价值锚点（SKILL.md）：

#	准则	工程含义
1	从源素材出发，而不是套通用帖子公式	内容必须可溯源（source-backed），禁止从"爆款模板"反推
2	适配的是平台格式，不是人设	换平台时改结构/长度/媒介，不改作者声音
3	一条帖子只承载一个真实论点（one post, one actual claim）	控制信息密度，防止一条内容讲三件事
4	具体性胜过多形容词（Specificity beats adjectives）	用数字、机制、证据替代"强大/革命性"这类修饰
5	除非用户明确要求，否则不用互动诱饵（no engagement bait）	禁止"你同意吗？"式刷回复

这五条准则贯穿了后文的所有流程：Source-First 工作流服务准则 1 和 2，平台适配规则服务准则 2，Hard Bans 服务准则 3、4、5，Quality Gate 则是对五条准则的逐条验收。

Source-First 工作流：先定素材，再动笔

技能要求在起草之前先完成「源素材集合（source set）」的识别（SKILL.md）。合法的源素材类型包括：

• 已发布的文章（published articles）
• 笔记或内部备忘录（notes / internal memos）
• 产品演示（product demos）
• 文档或变更日志（docs / changelogs）
• 转录稿（transcripts，如播客、会议记录）
• 截图（screenshots）
• 同一作者过去的帖子（prior posts from the same author）

这一步的深层逻辑是：Agent 生成的内容质量上限取决于输入素材的真实信息量。跳过素材识别直接进入写作，是"平台腔内容"的主要来源——模型会回落到训练语料中常见的帖子套路。

此外，原文档规定：如果用户要求特定声音（voice），必须先基于真实示例建立 voice profile 再写作；当声音一致性跨越多个产出物时，必须使用 brand-voice 技能作为正规工作流（canonical workflow）。

语音层（Voice Handling）：与 brand-voice 的分工

content-engine 自身不定义声音建模算法，而是明确声明「brand-voice 是正规的语音层（canonical voice layer）」（SKILL.md）。两者的分工如下：

• brand-voice 负责建：从真实素材中提炼出可复用的 VOICE PROFILE 块。其技能定义见 skills/brand-voice/SKILL.md，它规定了素材优先级（近期 X 原创帖 > 文章/备忘录/发布笔记 > 有效的真实外发邮件 > 产品文档/README 文案）、采集流程（5 到 20 个代表性样本、优先近期素材、区分「公开发布声音」与「内部工作声音」）、以及要提取的维度（节奏与句长、压缩 vs 解释、大小写规范、括号使用、提问频率、论点锋利度、数字/机制/证据出现频率、过渡方式、作者从不做的事）。
• content-engine 负责用：在声音层已建好的前提下，把 VOICE PROFILE 直接喂给后续的多平台适配流程，而不是重建第二个声音模型。

content-engine 给出应「先运行 brand-voice」的三种条件：

1. 存在多个下游产出物（multiple downstream outputs）；
2. 用户明确在意写作风格；
3. 内容属于发布、外联（outreach）或声誉敏感场景。

关于 VOICE PROFILE 的具体结构，仓库提供了固定的 schema（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:

schema 的配套指南强调：条目必须具体且有素材支撑；用短 bullet 而非散文段落；每条 Banned Move 必须是素材中可观察到的或用户明确要求的；如果素材集合内部有冲突，要指出这个分裂，而不是平均成糊状。这套 schema 的设计意图（原话）是「operational reuse（可操作复用）」而非文学批评——profile 要短到可以直接放进会话上下文被下游技能消费。

值得注意的是，brand-voice 还内置了 "Affaan / ECC Defaults"：当用户要求 Affaan / ECC 的声音、且线上素材稀薄时，可以直接以「直接、压缩、具体；具体信息、机制、证据、数字优先于形容词；括号只用于限定、收窄或过度澄清；大小写保持常规；提问稀少且不作诱饵；语气可以尖锐、直白、怀疑或冷峻；过渡要挣得而非抹平」作为默认起点，除非更新的一手素材推翻它。content-engine 文档中也特别注明：即使用户要的就是 Affaan / ECC 声音，brand-voice 仍是唯一事实来源（source of truth），要喂给它最好的线上或素材来源材料——这意味着「项目内置默认声音」也不能绕过声音建模流程。

Hard Bans：必须删除重写的表达清单

content-engine 维护了一份「出现即删改（Delete and rewrite）」的禁语清单（SKILL.md）：

禁语 / 禁式	说明
"In today's rapidly evolving landscape"	典型 AI 开头套话
"game-changer"、"revolutionary"、"cutting-edge"	空转的 hype 形容词
"here's why this matters"	除非其后紧跟具体内容，否则删除
以 LinkedIn 式提问结尾来刷回复	互动诱饵
在 LinkedIn 上强行装 casual	平台腔错配
源素材中不存在的假互动填充（fake engagement padding）	无中生有的互动感

这份清单与 brand-voice 的 Hard Bans（skills/brand-voice/SKILL.md，含 fake curiosity hooks、"not X, just Y"、"no fluff"、forced lowercase、LinkedIn thought-leader 节奏、bait questions、"Excited to share"、创始人旅程填充、油腻括号等）形成两层防线：brand-voice 的禁令从「作者从不做的事」出发，是素材驱动的；content-engine 的禁令从「平台垃圾腔」出发，是产出侧的硬性过滤器。

平台适配规则：X / LinkedIn / 短视频 / YouTube / Newsletter

这是技能的核心操作层——同一份源素材、同一个作者声音，如何在五个平台上分别落地（SKILL.md）。逐平台拆解如下：

X

• 用最强的论点、工件（artifact）或张力开场（open with the strongest claim, artifact, or tension）；
• 如果源声音本身就是压缩型的，保持压缩——不要因为换了平台就展开解释；
• 写帖子串（thread）时，每一条都必须推进论证，不允许有一条只是"凑数"；
• 不要用受众不需要的上下文去填充。

LinkedIn

• 展开的程度只到「圈子外的人能跟上」为止，不多不少；
• 除非源素材本身就是反思性的，否则不要硬改成"假经验分享帖"（fake lesson post）；
• 禁止企业励志节奏（corporate inspiration cadence）；
• 禁止堆砌赞美（praise-stacking）和 "journey" 式填充词。

短视频（Short Video）

• 脚本围绕视觉序列和证据点来写（script around the visual sequence and proof points）；
• 开头几秒先展示结果、问题或冲击点；
• 不要写"纸面读着比画面上好看"的旁白——短视频脚本的可验收标准是念出来/演出来好不好，而不是文本好不好。

YouTube

• 尽早展示结果或张力；
• 按论证或递进关系组织结构，而不是填充式分节；
• 只有在确实帮助理解时才使用章节（chaptering）。

Newsletter

• 开场即观点、冲突或工件，第一段不许用来"暖场"；
• 每个小节必须提供新的信息增量，不允许复述前文。

五个平台的规则共享同一条元规则——改格式，不改人设。X 要压缩就压缩，LinkedIn 需要展开就展开到"圈外人能懂"为止，但作者的声音 profile（来自 VOICE PROFILE 的 Rhythm / Compression / Claim Style 等字段）保持不变。

Repurposing Flow：七步再加工流程

把一份锚定素材（anchor asset）转化为多平台产出物时，技能规定了一个固定的七步流水线（SKILL.md）：

1. Pick the anchor asset —— 选定锚定素材（文章、演示、文档、转录稿中信息密度最高的那份）；
2. Extract 3 to 7 atomic claims or scenes —— 从锚定素材中抽取 3 到 7 个原子论点或场景。"原子"意味着每条可独立成立、可单独验证；
3. Rank them by sharpness, novelty, and proof —— 按锋利度（sharpness）、新鲜度（novelty）、证据强度（proof）三个维度排序；
4. Assign one strong idea per output —— 每个产出物只分配一个强观点（对应 Non-Negotiable 第 3 条）；
5. Adapt structure for each platform —— 按上文平台适配规则调整结构；
6. Strip platform-shaped filler —— 剥掉平台形态的填充物（如 LinkedIn 式金句分隔、X 式尾钩）；
7. Run the quality gate —— 跑质量门禁（见下一节）。

第 2 步的「3 到 7」是一个刻意收窄的数量窗口：少于 3 条说明锚定素材信息量不足，应换素材；多于 7 条通常是把"事实"和"论点"混在一起抽取了，需要进一步原子化。第 4 步与第 2 步的组合保证了：一个锚定素材最多产出 3–7 个互不重复的观点，每个平台拿到的都是"独占观点 + 平台结构"，而不是同一段文案的格式转换——这直接服务于质量门禁中「跨平台不允许复制文案」的检查项。

Deliverables：一次战役请求的标准交付物

当用户以「campaign（战役）」粒度发起请求时，技能的交付契约是返回以下五类产物（SKILL.md）：

• 若声音匹配重要，附一份简短 voice profile；
• 核心角度（the core angle）；
• 各平台原生草稿（platform-native drafts）；
• 仅当发布顺序有助于执行时才给 posting order——顺序是执行细节，不是必须品；
• 发布前必须补齐的缺口（gaps that must be filled before publishing）——这是交付物中容易被忽略但最有价值的一项：Agent 应当显式列出哪些论断缺证据、哪些场景缺截图、哪些数据需要用户确认，而不是把缺口藏进草稿里。

Quality Gate：交付前的六项验收

质量门禁是发布前的强制检查清单（SKILL.md），六项全部通过才能交付：

1. 每篇草稿听起来像目标作者，而不是像该平台的刻板印象；
2. 每篇草稿都包含一个真实论点、证据点或具体观察；
3. 不残留任何通用 hype 语言（对应 Hard Bans）;
4. 不残留任何假互动诱饵；
5. 跨平台不出现复制文案（除非用户明确要求）；
6. 任何 CTA 都必须是"挣得的"（earned）且经用户批准的。

对照 Non-Negotiables 可以发现，这六项门禁本质上是对五条准则的验收化：准则 1/2 对应检查项 1，准则 3 对应检查项 2，准则 4/5 对应检查项 3/4，检查项 5 对应 Repurposing Flow 第 4 步的独占观点约束，检查项 6 则把 CTA 的最终决定权留给人——从源码结构看，这种"规则前置（Non-Negotiables）+ 清单后置（Quality Gate）"的双层设计，是该技能保证 Agent 产出可被验收、可被追责的关键。

在 ECC 内容链路中的协作网络

content-engine 不是孤立技能。原文档 "Related Skills" 一节声明了它的三个协作伙伴（SKILL.md）：

协作技能	职责	与 content-engine 的关系
brand-voice	从素材推导声音 profile	上游：提供 VOICE PROFILE，是声音的唯一事实来源
crosspost	平台特定分发	下游：草稿通过质量门禁后进入分发
x-api	拉取近期帖子、发布已批准的 X 内容	双向：既给 brand-voice 供活体素材，也承接经批准的 X 发布

再往外一层，/marketing-campaign 命令把这条链路串成完整的营销战役流程：研究 → 定位 → 按序生产（落地页 → 邮件 → 社交 → 广告 → 视频脚本 → 日历）→ 转化与品牌一致性审查；其 "Agent Delegation" 段（commands/marketing-campaign.md）明确了 marketing-agent、brand-voice、content-engine、crosspost、market-research 五个组件的委派关系，战役产物默认落盘到 .claude/campaigns/{campaign-name}/ 目录（positioning.md、social-posts.md、content-calendar.md 等）。因此，一次典型的 ECC 多平台内容生产链路是：

源素材（文章/演示/文档/转录稿）
  → x-api 拉取作者近期帖（声音素材）
  → brand-voice 建立 VOICE PROFILE（schema 见 voice-profile-schema.md）
  → content-engine 抽取原子论点 + 平台适配 + 质量门禁
  → crosspost 多平台分发 / x-api 发布已批准的 X 内容
  → （战役级场景由 /marketing-campaign 统一编排与落盘）

小结：这套技能可迁移的设计模式

从 .agents/skills/content-engine/SKILL.md 的实现中，可以提炼出四个可迁移到自建 Agent 技能的设计模式：

1. description 即触发器：技能描述直接写明"Use when..."的激活场景，配合 agents/openai.yaml 中 allow_implicit_invocation: true，实现语义级自动激活；
2. 单一事实来源分层：声音建模只归 brand-voice，content-engine 只消费 VOICE PROFILE，避免两个技能各自维护一份互相漂移的声音模型；
3. 规则前置 + 门禁后置：Non-Negotiables 在起草前约束行为，Quality Gate 在交付前逐项验收，两层都是可逐条核对的清单而非笼统原则；
4. 交付缺口显式化：把"发布前必须补齐的 gaps"作为交付物的一等公民，让 Agent 的不确定性以显式清单形式交还给用户，而不是悄悄降级。

如果你想在自己的仓库中复用这套体系，可以直接阅读 .agents/skills/content-engine/SKILL.md 获取完整规则文本，配合 skills/brand-voice/SKILL.md 与 skills/brand-voice/references/voice-profile-schema.md 构建声音层，再参照 commands/marketing-campaign.md 的委派结构将其编排进战役级命令。