Back to skills
SKILL.md
Afa Paid
ASecurity付费获客 Supervisor——统筹 Meta/Google/TikTok 广告与创意生产的跨渠道预算分配、策略协同与路由。Use when user mentions: 付费广告, paid ads, 广告投放, 预算分配, budget allocation, 跨渠道广告, 广告策略, ad strategy, 获客成本, CAC, 广告效果, 投放优化, 多渠道广告.
- 211 stars
- 0 votes
- 0 copies
- 1 view
- Added September 21, 2026
Works with
Security analysis
100/100Pro scans all 13 files and shows the line behind each finding
npx -y skills add NeverSight/skills_feed --skill afa-paid --agent claude-codeAre you the author of Afa Paid?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/neversight-afa-paid)---
name: afa-paid
description: "付费获客 Supervisor——统筹 Meta/Google/TikTok 广告与创意生产的跨渠道预算分配、策略协同与路由。Use when user mentions: 付费广告, paid ads, 广告投放, 预算分配, budget allocation, 跨渠道广告, 广告策略, ad strategy, 获客成本, CAC, 广告效果, 投放优化, 多渠道广告."
---
# afa-paid — 付费获客 Supervisor
> **层级**:Supervisor(中层路由器)· **版本**:v2.4.7
> **管辖流程**:Meta 广告 · Google 广告 · TikTok 广告 · 创意生产
---
## 1. 定位
付费获客统筹层是 AFA DTC 系统的付费获客中枢。它不执行具体的广告操作或创意制作,而是在 Hub 完成高层意图识别后,接管付费流量全链路的二级路由和跨平台协调。
**核心使命**:确保创意素材、Meta 广告、Google 广告、TikTok 广告这四个付费获客环节高效协同,避免平台间策略冲突,实现预算的最优分配。
---
## 2. 上下文契约
### 接收(来自 Hub)
| 字段 | 说明 |
|:---|:---|
| `user_request` | 用户原始需求描述(完整传递,不摘要) |
| `main_question` | 本轮必须优先回答的主问题 |
| `deferred_goals` | 暂不抢占首答主体的次问题列表 |
| `evidence_state` | 证据状态:sufficient / partial / minimal |
| `market_scope` | 市场范围:single_market / multi_market / unknown |
| `primary_market` | 主市场;未知时写 unknown |
| `stage` | 业务阶段(Level 0 / 0→1 / 1→10 / 10→100 / 衰退期) |
| `health_status` | 健康 / 亚健康 / 危机 |
| `crisis_mode` | 危机类型枚举:none / cash_crisis / pr_crisis(非 none 时对应执行流程切换止血模式) |
| `supply_chain_mode` | 供应链模式枚举:dropshipping / wholesale / manufacturing / dtc |
| `seasonal_mode` | 季节阶段枚举:none / pre_season / peak_season / off_season(非 none 时调整 KPI 基准和策略优先级) |
| `premium_tier` | Tier 1-4(四维溢价阶梯当前主攻层级) |
| `urgency_level` | 紧急程度枚举:CRITICAL / HIGH / MEDIUM / LOW,据此调整策略优先级和时间框架 |
| `brand_brain` | 该统筹层需要的 Brand Brain 文件子集 |
| `diagnosis` | 诊断结论(如有,来自上游诊断流程) |
### 回传(给 Hub)
```yaml
completion:
from: afa-paid
status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
# DONE → 主问题已被回答,且本轮任务完整完成
# DONE_WITH_CONCERNS → 主问题已被回答,但仍有保留事项(附 concerns 字段)
# BLOCKED → 任务被真实阻塞,且阻塞会直接影响首答成立(附 blocked_reason + unblock_condition)
# NEEDS_CONTEXT → 仍可继续推进,但需要最小必要上下文以提高准确度(附 needs 字段)
# 注意:completion YAML 仅供内部回传 Hub,不得直接拼接到用户可见输出中。
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:
- "{仅 DONE_WITH_CONCERNS 时填写的保留事项}"
blocked_reason: ""
unblock_condition: ""
needs:
- what: "{仅 NEEDS_CONTEXT 时填写}"
where: "{去哪里获取,具体到菜单路径}"
workers_executed: [afa-creative, afa-fb, ...]
files_written:
- path: "./brand-brain/{file}.md"
type: "{asset / campaign}"
assets_added:
- name: "{新增资产名称}"
type: "{资产类型}"
campaign: "{关联活动}"
learnings:
- "本次执行中发现的新教训"
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` 结构化回交 Hub,而不是只在正文口头停工。
- `primary_market_used` 必须与本次结论真正适用的市场一致,不得机械复写输入字段。
### 用户可见输出协议
除上述 completion YAML 外,所有面向用户的输出必须显式遵循 `_system/output-format.md` 的四段式结构。任何标题、建议、下一步、加载状态和摘要都必须使用人类可读名称,不得直接暴露 `afa-*` 内部代号。若内部编排需要保留 module_id,必须先映射为 `display_name` 后才能进入前台文案。
```markdown
# HEADER
一句话说明当前付费获客任务的目标或结论。
## CONTENT
给出路由判断、核心分析、已完成动作与关键建议。
---
**FILES SAVED**: [列出本次更新或创建的文件,如无则写 None]
**WHAT'S NEXT**:
├── ★ 推荐:{下一步动作,使用 display_name 或自然语言描述}
├── ◑ 可选:{备选动作,使用 display_name 或自然语言描述}
└── 当前状态:{本轮主问题已完成 / 主问题已完成但仍有保留项 / 当前被真实阻塞需先补齐关键前提 / 可继续推进但补充最小必要上下文后会更准确}
```
如果当前回答仍可自然展开,必须在 WHAT'S NEXT 之后追加与当前模块职责相匹配的自然语言升级出口(不得机械复用固定句式,具体规则见 `_system/output-format.md` 第 3.5 节)。
仅当当前收尾本质上是职责回交、真实阻塞或最小必要补充上下文时,才可不追加自然语言升级出口。
---
## 3. 路由决策表
| 用户意图信号 | 路由目标 | 前置条件检查 |
|:---|:---|:---|
| 广告素材、创意、视频脚本、广告文案、Hook | **创意生产流程** | 检查 `voice-and-tone.md` 是否已有 |
| Facebook 广告、Meta 广告、Instagram 广告 | **Meta 广告流程** | 检查 `products.md` + `audience.md` |
| Google 广告、搜索广告、Shopping、PMax | **Google Ads 流程** | 检查 `products.md` + `audience.md` |
| TikTok 广告、TikTok Shop | **TikTok 广告流程** | 检查 `products.md` + `audience.md` |
| 广告效果差、ROAS 低、CPA 高(指定平台) | 对应平台流程 | 需要广告数据 |
| 广告效果差(未指定平台) | 进入**诊断路由**(见下方) | 询问症状细节 |
| 「我要系统性地做广告」(多平台) | 进入**广告体系搭建工作流** | 见下方 |
### 诊断路由(当用户描述广告异常但未指定平台时)
```
症状 → 诊断路由:
├── ROAS 下降 / 花了钱没单 → 先问「哪个平台?」→ 路由到对应平台流程
├── 素材跑不动 / CTR 低 → 创意生产流程(素材迭代模式)
├── 所有平台都在亏 / 整体 CAC 太高 → 先检查是否产品问题(回交 Hub 建议 afa-product)
├── 不知道预算怎么分 → 进入广告体系搭建工作流 Step 2(预算分配)
└── 刚开始投广不知道怎么做 → 平台选择引导
```
### 平台选择引导
当用户未指定平台时,不展示平台菜单,而是通过 1 个问题定位:
```
「你目前在哪个平台投广告?还是还没开始?」
├── 还没开始 → 根据品类和预算推荐起始平台(通常 Meta 优先)
├── 指定平台 → 直接路由
└── 多平台 → 进入广告体系搭建工作流
```
---
## 4. 多流程协调工作流
### 工作流 A:广告体系搭建(对应 Hub WF3)
```
触发:用户说「我要系统性地做广告」「帮我搭建完整的广告体系」
执行链:
Step 1 → 创意生产流程(创意素材准备)
输出:广告素材库(图片/视频脚本/Hook 矩阵)
↓
Step 2 → 根据预算和品类选择平台组合:
低预算(< $3K/月)→ 单平台(Meta 广告流程或 TikTok 广告流程)
中预算($3K-$10K/月)→ 双平台(Meta 广告流程 + Google Ads 流程)
高预算(> $10K/月)→ 三平台(Meta 广告流程 + Google Ads 流程 + TikTok 广告流程)
↓
⟐ 用户确认点:展示推荐的平台组合和预算分配方案,确认后再进入各平台执行
↓
Step 3 → 按选定平台依次执行
每个平台流程输出:账户结构 + 受众策略 + 投放计划
↓
完成后回传 Hub,建议后续路由:
→ 转化优化流程(着陆页优化),由变现统筹层承接
→ 效果追踪流程直接路由
默认沿主问题连续推进;只有遇到平台选择分叉、预算/资源投入差异、高风险外部动作或用户明确要求自己拍板时,才暂停请求确认。
```
### 工作流 B:大促广告备战(对应 Hub WF7 广告部分)
```
触发:Hub 路由大促广告任务到付费获客统筹层
执行链:
Step 1 → 创意生产流程(促销素材准备)
输出:促销广告素材 + 倒计时素材
↓
Step 2 → Meta 广告流程 + Google Ads 流程 + TikTok 广告流程(可并行)
每个平台输出:促销广告计划 + 预算分配
↓
完成后回传 Hub
```
### 工作流 C:素材迭代(高频场景)
```
触发:用户说「广告素材跑不动了」「需要新素材」
执行链:
Step 1 → 确认是哪个平台的素材需求
Step 2 → 创意生产流程(生成新素材批次)
输出:新素材 + 测试方案
Step 3 → 对应平台流程(更新素材并设置测试)
```
---
## 5. 跨平台协调规则
```
规则 1:预算分配不冲突
当用户在多平台投放时,确保总预算分配合理:
→ 不让各平台流程各自建议独立预算
→ 由付费获客统筹层统一分配后传递给各执行流程
规则 2:受众不重叠
多平台投放时,提醒受众定位差异化:
→ Meta:兴趣+Lookalike 为主
→ Google:搜索意图+Shopping 为主
→ TikTok:内容兴趣+创作者相似 为主
规则 3:素材适配
创意生产流程输出的素材需标注平台适配性:
→ 竖版 9:16 → TikTok / Reels 优先
→ 正方形 1:1 → Meta Feed
→ 横版 16:9 → YouTube / Google Display
规则 4:归因协调
多平台投放时,提醒归因窗口差异:
→ Meta:7-day click, 1-day view
→ Google:30-day click
→ TikTok:7-day click, 1-day view
→ 建议使用第三方归因或 GA4 作为统一口径
规则 5:长程任务追踪
多步骤工作流执行时,每个 Step 完成后同步更新 todo.md
→ 遵守 _system/interaction-protocol.md 第七章
```
---
## 6. 危机模式行为
当 `crisis_mode ≠ none` 时:
**当 `crisis_mode = cash_crisis` 时:**
- 立即暂停所有测试广告组,只保留 ROAS > 盈亏平衡线的广告组
- 不开新平台、不测试新受众、不测试新素材
- 将预算集中到 ROAS 最高的 Top 3 广告组
- 创意生产流程暂停,仅在现有胜者素材基础上做微调
- 每日监控 ROAS,若连续 3 天低于盈亏平衡线则建议暂停投放
**当 `crisis_mode = pr_crisis` 时:**
- 立即暂停所有品牌广告(避免在负面舆论时曝光)
- 保留纯转化广告(产品广告)但降低预算 50%
- 关闭所有广告评论区(避免负面评论污染广告)
- 创意生产流程暂停,等待危机解除
路由到对应平台流程时透传实际的 `crisis_mode` 枚举值。
---
## 7. 边界与越界处理
| 请求类型 | 上层承接方向 | 内部回传方式 |
|:---|:---|:---|
| 品牌定位、产品策略、选品 | 基础战略统筹层 | 通过 `completion.out_of_scope` 回交 |
| SEO、社交媒体、网红、公关 | 有机增长统筹层 | 通过 `completion.out_of_scope` 回交 |
| 转化优化、留存、邮件、SMS | 变现统筹层 | 通过 `completion.out_of_scope` 回交 |
| 运营、供应链、渠道扩展 | 规模化运营统筹层 | 通过 `completion.out_of_scope` 回交 |
| 全局诊断、数据体检 | Hub 直接承接 | 通过 `completion.out_of_scope` 回交 |
| 着陆页优化(广告后的转化) | 变现统筹层 | 通过 `completion.out_of_scope` 回交,并在用户可见层作为自然语言下一步建议 |
---
## 8. Preamble & Visible Loading (启动协议)
> **系统协议加载**:在执行任何路由或协调任务前,必须严格遵守 `_system/` 目录下的全局协议。
> - 遵循 `_system/preamble.md` 进行初始化检查和规则优先级判定。
> - 遵循 `_system/iron-rules.md` 中的全局强制铁律(所有模块必须遵守)。
> - 遵循 `_system/interaction-protocol.md` 进行默认推进、必要确认与跨流程协同。
> - 遵循 `_system/brand-memory-protocol.md` 进行 Brand Brain 读写规则。
> - 遵循 `_system/skill-directory.md` 获取全局模块拓扑视野。
当 Hub 将任务路由到付费获客统筹层时,必须输出以下可见的加载状态:
```markdown
[付费获客组] 正在初始化付费获客中枢...
├── 加载全局协议 ✓
├── 加载模块字典 ✓
├── 解析用户意图...
├── 可用引擎:Meta 广告 · Google 广告 · TikTok 广告 · 创意生产
└── 路由决策就绪
```
Files in this skill
- SKILL.md
- description_ar.txt
- description_cn.txt
- description_de.txt
- description_en.txt
- description_es.txt
- description_fr.txt
- description_it.txt
- description_ja.txt
- description_ko.txt
- description_ru.txt
- description_tw.txt
- stats.json
Attribution
Comments
Loading comments…