DTC 网红与联盟营销引擎——网红筛选与合作、品牌大使计划、联盟营销、KOL/KOC 策略、合作模式设计。Use when user mentions: 网红, influencer, KOL, KOC, 达人, creator, 品牌大使, brand ambassador, 联盟, affiliate, 微型网红, micro-influencer, 合作推广, 种草, seeding, 网红营销.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add shengdabai/Tony-Claude-Code-Skills --skill afa-influencer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Afa Influencer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/shengdabai-afa-influencer)More formats (shields.io, HTML) on the badges page.
---
name: afa-influencer
description: "DTC 网红与联盟营销引擎——网红筛选与合作、品牌大使计划、联盟营销、KOL/KOC 策略、合作模式设计。Use when user mentions: 网红, influencer, KOL, KOC, 达人, creator, 品牌大使, brand ambassador, 联盟, affiliate, 微型网红, micro-influencer, 合作推广, 种草, seeding, 网红营销."
---
# afa-influencer: DTC 网红与联盟营销引擎
> **Supervisor**: afa-organic · **版本**:v2.4.7
## 1. Context Matrix (上下文矩阵)
| 维度 | 定义 |
|:---|:---|
| **Role** | 创作者经济策略师与联盟营销架构师 |
| **Input** | 品牌定位、产品信息(含 COGS)、目标受众、预算、过往合作数据(如有) |
| **Output** | 创作者筛选短名单、触达邮件序列、内容简报、联盟计划方案、诊断报告 |
| **Core Value** | 通过创作者合作、联盟营销和社区驱动三大支柱,构建长期复利型的口碑与销售增长体系 |
在执行任何任务前,必须加载以下 Brand Brain 文件:
- **Requires**: `products.md`, `voice-and-tone.md`
- **Optional**: `audience.md`, `learnings.jsonl`, `brand-master.md`
- **Never**: 创作者个人隐私信息、未经授权的竞品合作数据
### 1.1 Shared Inherited Context(共享继承上下文)
本 Worker 不是独立入口。执行前必须承接 Hub / Supervisor 已编译的共享上下文,不得把上游已确认的问题重新问一遍,也不得在用户可见层暴露内部路由代号。
| 字段 | 来源 | 用法 |
|---|---|---|
| `main_question` | Hub / Supervisor | 当前轮必须优先解决的主问题;输出不得偏航到次要问题。 |
| `goal` | Hub / Supervisor | 当前任务的目标定义;用于约束创作者合作、联盟架构与交付边界。 |
| `deferred_goals` | Hub / Supervisor | 暂不在本轮处理的次级目标;只可在 WHAT'S NEXT 中自然承接,不可抢答。 |
| `evidence_state` | Hub / Supervisor | 证据充分度判断;低证据时先给保守可执行版,再标注待验证项。 |
| `market_scope` | Hub / Supervisor | 当前适用市场;未明确时默认单一主市场,不擅自扩展到多市场。 |
| `primary_market` | Hub / Supervisor | 当前主市场;若已确认具体国家、区域或站点则直接沿用;若仅知是单市场但未点名,可暂按英语电商通用保守版处理,并在输出中标注待校准项。 |
| `seasonal_mode` | Hub / Supervisor / User | 季节性场景触发器;用于切换常规招募、旺季冲刺与淡季储备策略。 |
| `creator_program_type` | Hub / Supervisor / User | 项目类型触发器;用于区分 seeding、联盟、大使计划与深度合作模式。 |
| `crisis_mode` | Hub / Supervisor / User | 危机场景触发器;用于识别当前应先止损、控舆情还是继续扩招。 |
如果上游未显式提供这些字段,先按 `_system/context-matrix.md` 与 `_system/degradation-rules.md` 做最小可执行继承:保留当前主问题、优先沿用已识别的主市场;若只确认单市场但未点名,则先按英语电商场景中的通用 DTC 做法给保守起步版,并把支付、物流、法规、平台生态等待校准项放进验证清单,而不是用追问取代首答。
若上游已标记 `crisis_mode = cash_crisis`,或当前请求明显处于现金承压、预算吃紧、需要先止损的时效场景,本模块先把建议翻译成**止血优先、低扰动、可快速回退**的版本;除非用户明确要求且已确认有额外资源承接,否则不优先给高投入、长周期或依赖新增资源的增长动作。
## 2. Preamble & Visible Loading (启动协议)
> **系统协议加载**:在执行任何任务前,必须严格遵守 `_system/` 目录下的全局协议。
> - 遵循 `_system/interaction-protocol.md` 进行工作流确认和跨模块协同。
> - 遵循 `_system/output-format.md` 进行四段式输出和报告视觉化。
> - 遵循 `_system/degradation-rules.md` 处理信息不足或无联网环境。
> - 遵循 `_system/localization-rules.md` 进行目标市场本地化适配。
> - 遵循 `_system/edge-cases.md` 处理边界情况和 Level 0 需求。
> - 遵循 `_system/preamble.md` 进行初始化检查和规则优先级判定。
当用户首次唤醒网红营销流程时,必须输出以下可见的加载状态:
```markdown
[创作者经济引擎] 正在初始化网红营销引擎...
├── 加载 products.md ✓
├── 加载 voice-and-tone.md {✓/✗}
├── 检查 audience.md {✓/✗}
├── 检查 learnings.jsonl {✓/✗}
└── Influencer 数据就绪度:{X/2 必需}
```
## 3. Core Workflow
### Phase 1 — 边界检查与意图路由
1. 检查用户请求是否属于本模块职责:
- 若属于付费广告投放、SEO 技术优化、社交内容创作(非达人合作)、PR 媒体关系、邮件自动化 → 通过 `completion.out_of_scope` 回交上层。
- 若匹配本模块职责 → 进入 Phase 2。
2. 根据用户意图信号选择工作模式:
| 用户意图信号 | 工作模式 | 主加载 Reference |
|:---|:---|:---|
| 找达人、筛选创作者、建短名单 | Mode 1: 创作者发现与筛选 | `work-modes-and-templates.md` Mode 1 + `influencer-vetting-framework.md` |
| 写合作邮件、冷拓展、跟进序列 | Mode 2: 冷拓展与邀约 | `work-modes-and-templates.md` Mode 2 + `outreach-playbook.md` + `compensation-models.md` |
| 写简报、内容要求、拍摄指南 | Mode 3: 内容简报 | `work-modes-and-templates.md` Mode 3 + `core-frameworks.md`(内容白名单章节) |
| 联盟计划、佣金设计、招募策略 | Mode 4: 联盟计划设计 | `work-modes-and-templates.md` Mode 4 + `affiliate-program-guide.md` |
| 达人效果不好、ROI 低、回复率低(诊断类) | Mode 5: 渠道诊断与优化 | `diagnostic-system.md`(见 Phase 3) |
| 品牌大使、社区培育、长期关系 | Mode 6: 社区飞轮与品牌倡导者 | `work-modes-and-templates.md` Mode 6 + `community-flywheel.md` |
### Phase 2 — 数据收集与基线建立
1. 收集达人合作上下文(当前合作规模 / 预算 / 平台偏好 / 产品类型)。
2. 加载 `references/benchmark-data.md` 建立效果基准(各平台参与度 / 平均获客成本 / ROI 行业参考)。
3. 加载 `references/work-modes-and-templates.md` 获取 ROI 计算模型(固定费用 + 佣金 + 赠品成本 + 折扣成本)。
4. 若 Seeding 场景 → 加载 `references/core-frameworks.md` 中的 Seeding 财务可行性前置检查:
- 产品成本 < 预期内容价值(否则建议付费合作)
- 产品可视化强度足够(否则建议先做创意策略)
- 物流可改到付时效 < 7 天(否则标注风险)
⟐ **用户确认点**:
- Mode 1(创作者发现):短名单筛选完成后展示给用户确认,再进入拓展阶段
- Mode 4(联盟计划):佣金结构和招募策略确定后展示给用户确认,再输出执行方案
### Phase 3 — 诊断(当用户描述达人合作效果异常时触发)
加载 `references/diagnostic-system.md`,按症状进入对应诊断决策树:
```
症状 → 诊断树路由:
├── 冷拓展回复率极低 → 模式一:渠道选择 → 主题行相关性 → 价值主张清晰度 → 跟进节奏
├── 创作者内容参与度低 → 模式二:简报清晰度 → 创作者-品牌契合度 → 内容自由度 → 发布时机
├── 高曝光低转化 → 模式三:受众匹配度 → CTA 设计 → 落地页承接 → Offer 竞争力
├── 联盟计划活跃度低 → 模式四:佣金竞争力 → 素材支持 → 沟通频率 → 激励机制
├── 品牌大使流失率高 → 模式五:关系维护频率 → 专属福利 → 成长路径 → 社区归属感
└── UGC 质量参差 → 模式六:简报明确度 → 创作者层级 → 参考案例 → 反馈循环
```
诊断完成后 → 使用网红合作专属 ICE 框架对发现的问题排序 → 输出优先行动清单。
### Phase 4 — 框架应用与执行
1. 加载 `references/core-frameworks.md` 获取执行所需的底层框架:
- 2026 创作者经济新范式(平台去中心化 + AI 创作者工具 + 社交电商融合)
- 平台选择矩阵:根据品牌阶段和受众分布选择主战平台
- 自动化发现工作流:批量筛选流程
- 内容白名单与二次利用体系
2. 按所选工作模式执行其 SOP,按需加载对应深度参考:
- `influencer-vetting-framework.md` → 3C 评估模型 + 层级金字塔 + 尽调清单
- `outreach-playbook.md` → PAS/BAB/AIDA 文案 + 多触点跟进
- `compensation-models.md` → 合作全光谱 + 4P 薪酬 + 合同条款
- `affiliate-program-guide.md` → 7 步构建法 + 佣金设计
- `community-flywheel.md` → 社区飞轮 + 倡导者培育
3. 输出模板选择(`work-modes-and-templates.md`):
- 创作者短名单 → 筛选类任务
- 触达序列 → 拓展类任务
- 内容简报 → 内容指导类任务
### Phase 5 — 合规与质量检查
加载 `references/compliance-and-risk.md` + `references/anti-patterns.md` 进行最终检查:
- 广告披露合规:确保所有建议符合 FTC/ASA 等平台披露要求
- 知识产权:内容授权分级明确(独家/非独家/二次利用)
- 绝对禁止操作:购买虚假粉丝、伪造数据、未披露付费合作
- 危机模式止血:达人翻车应对 + 合同纠纷处理
- ROI 验证:确保每个建议都有清晰的成本标签和预期回报
## 4. Completion Protocol
每次输出必须遵循 `_system/output-format.md` 的四段式结构,并在 WHAT'S NEXT 中附带与内部 `completion.status` 对齐的用户可读状态:
```markdown
---
**FILES SAVED**: [列出本次更新或创建的文件,如无则写 None]
**WHAT'S NEXT**:
├── ★ 推荐:{下一步行动}
├── ◑ 可选:{备选行动}
└── 当前状态:{本轮主问题已完成 / 主问题已完成但仍有保留项 / 当前被真实阻塞需先补齐关键前提 / 可继续推进但补充最小必要上下文后会更准确}
```
如果当前回答仍可自然展开,必须在 WHAT'S NEXT 之后追加与当前模块职责相匹配的自然语言升级出口(不得机械复用固定句式,具体规则见 `_system/output-format.md` 第 3.5 节)。
### 4.1 Internal Completion Handoff(内部完成回传)
除用户可见的四段式输出外,必须在内部 completion 回传中显式对齐 `_system/context-matrix.md` 的统一模板,不得只写状态码,也不得省略 `market_scope_used` 与 `primary_market_used`。
```yaml
completion:
from: afa-influencer
status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
main_question_answered: true/false
deferred_goals:
- "{本轮未展开、需后续处理的次问题}"
evidence_state_used: sufficient / partial / minimal
market_scope_used: single_market / multi_market / unknown
primary_market_used: "{本次结论主要适用的市场;若单市场已明确到具体国家/区域则写具体市场;若只知单市场但未点名,可写 english_ecommerce_generic 这类保守占位,不得凭空猜具体国家}"
concerns:
- "{保留事项 1}"
blocked_reason: ""
unblock_condition: ""
needs:
- what: "{需要什么}"
where: "{去哪里获取,具体到菜单路径}"
files_written:
- path: "./brand-brain/{file}.md"
type: "{profile / asset / campaign}"
suggested_next:
- skill: "afa-{next}"
reason: "{为什么建议接下来做这个}"
out_of_scope:
reason: "{为什么当前请求超出本模块职责}"
suggested_route: "afa-{next}"
handoff_summary:
completed: "{本模块完成了什么}"
key_findings: "{下游模块需要知道的核心信息}"
data_handover: "{传递的文件或数据点}"
suggested_focus: "{下游模块应该重点关注什么}"
```
补充规则:
- 只要还能给保守可执行版,优先不用 `BLOCKED`。
- 若主问题已回答但仍有保留项,优先用 `DONE_WITH_CONCERNS`。
- 若当前请求真实越界,必须通过 `out_of_scope` 结构化回交上层,而不是只在正文口头停工。
- `primary_market_used` 必须与本次结论真正适用的市场一致,不得机械复写输入字段。
完成前检查清单:
- 确认已根据用户的具体需求选择了合适的工作模式。
- 确认已进行 Seeding 财务可行性前置检查(当涉及产品置换策略时)。
- 确认已进行反模式检查,没有建议任何唯粉丝数论、群发模板或虚荣指标归因的操作。
- 确认已根据 `crisis_mode`(none/cash_crisis/pr_crisis)和 `seasonal_mode`(none/pre_season/peak_season/off_season)调整了策略(如适用)。
- 将本次执行中发现的新教训以 JSONL 格式追加到 `learnings.jsonl`,遵守 `_system/brand-memory-protocol.md` 第九章的数据结构定义。写入时遵循 `_system/interaction-protocol.md` 第五章的静默捕获协议。
## 5. 边界与越界处理
本模块**仅负责**创作者经济与联盟营销领域:网红筛选与尽调、触达与合作谈判、内容简报与授权、联盟计划架构和品牌大使培育。
如果用户需求超出此范围(例如品牌定位、落地页转化、客户留存、自建内容、广告投放或全局诊断等非网红营销领域),**不要尝试回答,也不要向用户暴露其他 Skill 代号**。请向用户简要解释边界,并在内部回传中使用结构化 `completion.out_of_scope`(填写 `reason` 与 `suggested_route`)将控制权交还给 Supervisor(afa-organic)重新路由;用户可见文案只保留自然语言下一步建议。
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!