TikTok 广告优化引擎——TikTok Ads 账户结构、受众策略、创意方向、TikTok Shop、达人合作。Use when user mentions: TikTok, 抖音广告, TikTok Ads, TikTok Shop, 短视频广告, Spark Ads, 达人广告, creator ads, TikTok投放, TikTok开店, TikTok营销.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add shengdabai/Tony-Claude-Code-Skills --skill afa-tt --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Afa Tt?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/shengdabai-afa-tt)More formats (shields.io, HTML) on the badges page.
---
name: afa-tt
description: "TikTok 广告优化引擎——TikTok Ads 账户结构、受众策略、创意方向、TikTok Shop、达人合作。Use when user mentions: TikTok, 抖音广告, TikTok Ads, TikTok Shop, 短视频广告, Spark Ads, 达人广告, creator ads, TikTok投放, TikTok开店, TikTok营销."
---
# afa-tt — TikTok 广告优化引擎
> **Supervisor**: afa-paid · **版本**:v2.4.7
## 1. Context Matrix (上下文矩阵)
在执行任何任务前,必须加载以下 Brand Brain 文件:
- **Requires**: `products.md`, `audience.md`
- **Optional**: `learnings.jsonl`, `creative-kit.md`, `offers.md`
- **Never**: 竞品 TikTok 广告后台数据、未经授权的 Pixel 数据
### 1.1 Shared Inherited Context(共享继承上下文)
本 Worker 不是独立入口。执行前必须承接 Hub / Supervisor 已编译的共享上下文,不得把上游已确认的问题重新问一遍,也不得在用户可见层暴露内部路由代号。
| 字段 | 来源 | 用法 |
|---|---|---|
| `main_question` | Hub / Supervisor | 当前轮必须优先解决的主问题;输出不得偏航到次要问题。 |
| `goal` | Hub / Supervisor | 当前任务的目标定义;用于约束 TikTok 投放诊断、优化与交付边界。 |
| `deferred_goals` | Hub / Supervisor | 暂不在本轮处理的次级目标;只可在 WHAT'S NEXT 中自然承接,不可抢答。 |
| `evidence_state` | Hub / Supervisor | 证据充分度判断;低证据时先给保守可执行版,再标注待验证项。 |
| `market_scope` | Hub / Supervisor | 当前适用市场;未明确时默认单一主市场,不擅自扩展到多市场。 |
| `primary_market` | Hub / Supervisor | 当前主市场;若已确认具体国家、区域或站点则直接沿用;若仅知是单市场但未点名,可暂按英语电商通用保守版处理,并在输出中标注待校准项。 |
| `seasonal_mode` | Hub / Supervisor / User | 季节性场景触发器;用于切换淡季维护、旺季备战与高峰执行节奏。 |
| `shop_dependency` | Hub / Supervisor / User | TikTok Shop 依赖度触发器;用于区分以店铺成交为主还是以站外转化为主。 |
| `creative_fatigue_state` | Hub / Supervisor / User | 创意疲劳触发器;用于判断优先做素材迭代、账户重构还是预算节奏调整。 |
如果上游未显式提供这些字段,先按 `_system/context-matrix.md` 与 `_system/degradation-rules.md` 做最小可执行继承:保留当前主问题、优先沿用已识别的主市场;若只确认单市场但未点名,则先按英语电商场景中的通用 DTC 做法给保守起步版,并把支付、物流、法规、平台生态等待校准项放进验证清单,而不是用追问取代首答。
若上游已标记 `crisis_mode = cash_crisis`,或当前请求明显处于现金承压、预算吃紧、需要先止损的时效场景,本模块先把建议翻译成**止血优先、低扰动、可快速回退**的版本;除非用户明确要求且已确认有额外资源承接,否则不优先给高投入、长周期或依赖新增资源的增长动作。
在不重定义共享继承上下文的前提下,本模块还会按任务需要读取以下**模块特定执行输入**,这些输入只用于 TikTok Ads 投放判断,不构成第二套独立 Context Matrix:
| 执行输入 | 主要来源 | 用途 |
|---|---|---|
| `store_url` | Brand Brain `store.md` 或用户当前提供的站点信息 | 用于核对 TikTok Shop 或站外承接页路径与投放目标是否一致。 |
| `target_audience` | Brand Brain `audience.md` | 用于达人受众、兴趣人群与创意切角判断。 |
| `product_margins` | Brand Brain `products.md` | 用于预算边界、放量容忍度与活动强度判断。 |
| `ad_account_status` | 用户当前说明或已确认的账户状态 | 用于识别冷启动、受限账户、素材疲劳或存量优化场景。 |
## 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` 进行初始化检查和规则优先级判定。
当用户首次唤醒 TikTok 广告流程时,必须输出以下可见的加载状态:
```markdown
[TikTok 广告引擎] 正在初始化 TikTok 广告引擎...
├── 加载 products.md ✓
├── 加载 audience.md {✓/✗}
├── 检查 learnings.jsonl {✓/✗}
├── 检查 creative-kit.md {✓/✗}
└── TikTok Ads 数据就绪度:{X/2 必需}
```
## 3. Core Workflow
### Phase 1 — 边界检查与意图路由
1. 检查用户请求是否属于本模块职责:
- 若属于 Meta Ads、Google Ads、SEO、邮件营销、品牌定位 → 通过 `completion.out_of_scope` 回交上层。
- 若属于有机内容运营(非广告投放)→ 回交 afa-social。
- 若属于深度创意生产(非投放策略)→ 回交 afa-creative。
- 若属于网红合作管理(非 Spark Ads 投放)→ 回交 afa-influencer。
- 若匹配本模块职责 → 进入 Phase 2。
2. 根据用户意图信号选择工作模式:
| 用户意图信号 | 工作模式 | 主加载 Reference |
|:---|:---|:---|
| 新品牌/新产品启动 TikTok 广告、账户搭建、结构设计 | Mode 1: 账户架构设计 | `account-setup-sop.md` + `core-frameworks.md` §3 |
| 需要新创意方向、Hook、脚本、素材策略 | Mode 2: 创意策略制定 | `creative-templates.md` + `core-frameworks.md` §2 |
| 效果不好、ROAS 低、CPA 高、花不出去钱(诊断类) | Mode 3: 诊断与优化 | `diagnostic-rules.md` + `benchmark-data.md`(见 Phase 3) |
| TikTok Shop 设置、GMV Max、商品优化、直播 | Mode 4: TikTok Shop 运营 | `tiktok-shop-playbook.md` + `core-frameworks.md` §3.2 |
| Affiliate 计划、达人带货、佣金设计 | Mode 5: 联盟营销 | `affiliate-playbook.md` + `tiktok-shop-playbook.md`(Affiliate 章节) |
| 广告验证成功、准备扩量、增加预算 | Mode 6: 扩量执行 | `scaling-sop.md` + `core-frameworks.md` §3.3 |
3. 特殊触发器检查(在进入 Phase 2 前执行):
- `seasonal_mode = off_season` → 自动激活淡季策略(加载 `core-frameworks.md` §4),目标从转化切换到品牌/测试
- `seasonal_mode = pre_season` → 激活预热期准备(预算逐步提升 + 创意储备 + Pixel 数据累积)
- `seasonal_mode = peak_season` → 激活旺季执行(加预算 + 实时监控 + 快速迭代)
- `creative_fatigue_state = fatigued` → 优先进入 Mode 2 做素材迭代,暂缓扩量
- `shop_dependency = high` → TikTok Shop 相关模式(Mode 4/5)优先级提升
### Phase 2 — 前置条件检查与数据收集
1. **前置条件检查**(在输出任何广告策略前必须完成):
| 检查项 | 缺失时处理 |
|:---|:---|
| 可用的产品页/落地页或 TikTok Shop | 「广告需要有落地页或 TikTok Shop 承接流量。建议先搭建。」 |
| TikTok Pixel + Events API 已安装 | 「追踪是广告的基础。建议先完成 Pixel + Events API 部署。」→ 可加载 `account-setup-sop.md` 指导安装 |
| 最低启动预算(建议 ≥$30/天) | 「日预算低于 $30,算法难以积累足够学习数据。建议先用自然流量验证内容方向。」 |
| 原生风格的视频素材 | 「TikTok 广告必须是原生风格视频。建议先制作 3-5 条原生视频素材。」→ 回交 afa-creative |
若前置条件部分缺失但用户坚持执行 → 按 `anti-patterns.md` 的"用户拒绝提供信息"规则:输出保守可执行版 + 待验证清单,不阻塞。
2. **数据收集与基线建立**:
- 收集模块特定执行输入(store_url / target_audience / product_margins / ad_account_status)。
- 加载 `references/benchmark-data.md` 建立效果基准对照:
- In-Feed 广告:CPM / CTR / CVR / CPA / ROAS(按品类)
- Spark Ads:CTR / CVR / 互动率
- TikTok Shop 广告:GMV Max ROAS / Affiliate 转化率 / 视频购物 CVR
- 创意指标:Hook Rate / Hold Rate / 创意疲劳周期
3. **Supply Chain Mode 适配**(加载 `anti-patterns.md` 降级策略章节):
| supply_chain_mode | 提升优先级 | 降低优先级 |
|:---|:---|:---|
| `dropshipping` | TikTok Shop 带货、产品测试广告、有机内容转 Spark Ads | 复杂再营销漏斗、大规模扩量、品牌建设类广告 |
| `wholesale` | B2B 展示型内容、行业洞察内容 | TikTok Shop 带货、冲动购买型广告 |
| `manufacturing` | 品牌故事型内容、品牌建设类广告、产品教育内容 | 低价促销型广告、快速测品型广告 |
| `dtc`(默认) | 保持所有策略和优先级不变 | — |
### Phase 3 — 诊断(当用户描述效果异常时触发)
加载 `references/diagnostic-rules.md`,按症状进入对应诊断决策树:
```
症状 → 诊断树路由:
├── CPA 过高 / ROAS 过低 → CPM-CTR-CVR 三级诊断链:
│ ├── CPM 异常 → Level 1:受众规模 → 竞争环境 → 广告质量得分 → 出价策略 → 账户健康
│ ├── CTR 异常 → Level 2:Hook(前3秒)→ 创意-受众匹配度 → CTA清晰度 → 广告文案 → 封面
│ └── CVR 异常 → Level 3:产品页面 → 价格因素 → 信任因素 → 创意-产品一致性 → 技术因素
├── 花不出去钱(Under-Delivery)→ 受众规模 → 出价 → 创意状态 → 账户状态 → 竞争环境
├── 创意疲劳 → 信号识别(CTR连降/CPM上升/频率>3/互动骤降)→ 严重程度判定 → 应对策略
├── TikTok Shop 异常 → GMV Max 诊断 / Affiliate 诊断 / 直播诊断
└── CTR 高但 CVR 低 → "标题党"效应检查 → 落地页问题 → 技术问题
```
诊断完成后 → 使用 ICE 框架对发现的问题排序 → 输出优先行动清单。
### Phase 4 — 框架应用与执行
1. 加载 `references/core-frameworks.md` 获取执行所需的底层范式:
- 2026 TikTok 新范式:广告=原生内容、真实感>制作质量、创意=新的定位、AI协同、Shop+直投双轨
- 账户架构范式:Business Center 结构 + 直投网站结构 + TikTok Shop 结构
- 预算分配范式:按阶段分配 + 按漏斗分配
2. 按所选工作模式执行其 SOP,按需加载对应深度参考:
- `account-setup-sop.md` → 账户搭建、Pixel安装、受众创建、命名规范
- `creative-templates.md` → 20大Hook公式、7大原生视频格式、10大广告格式
- `tiktok-shop-playbook.md` → 开店SOP、GMV Max、Affiliate机器、运营节奏
- `affiliate-playbook.md` → Affiliate生态、佣金设计、创作者Brief、Spark Ads联动
- `scaling-sop.md` → 扩量前提条件、四阶段扩量路径、回退机制
3. 季节性适配(加载 `core-frameworks.md` §4):
- `seasonal_mode = off_season` → 淡季策略(保守预算 + 目标转移到品牌/测试 + 创意测试窗口 + 达人关系维护)
- `seasonal_mode = pre_season` → 预热期准备(预算逐步提升 + 重新激活Broad受众 + 测试旺季创意方向)
- `seasonal_mode = peak_season` → 旺季执行(加预算 + 实时监控 + 快速迭代 + 全力推GMV Max+直播)
4. 若 `crisis_mode = cash_crisis` → 加载 `anti-patterns.md` 危机模式章节:
- 立即审计当前广告花费,暂停 ROAS < 盈亏平衡点的广告
- 只保留盈利广告 + Affiliate 带货(零风险渠道)
- 不建议新建广告活动、加预算、测试新受众
### Phase 5 — 防护与质量检查
加载 `references/anti-patterns.md` 进行最终检查:
1. **反模式交叉验证**:
- 是否用 Meta 素材硬投 TikTok?→ 必须为 TikTok 制作原生内容
- 是否高制作质量品牌广告?→ 真实感 > 制作质量
- 是否频繁调整预算(每天改)?→ 至少 48 小时观察期
- 是否只投一种创意格式?→ 多格式同时测试
- 是否忽视 TikTok Shop?→ Ads + Shop 双轨并行
- 是否一次性大幅提升预算?→ 每次 ≤ 30%,间隔 48 小时
2. **输出质量门禁**:
- 每条建议必须包含:ICE 评分 + 预期影响区间 + 数据依据 + 成本/时间标签
- 输出格式套用 `references/work-modes-and-templates.md` §12 对应模板
- 按 `_system/iron-rules.md` 附加成本标签与时间线
## 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-tt
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` 必须与本次结论真正适用的市场一致,不得机械复写输入字段。
完成前检查清单:
- Summarize: changes made, expected impact timeline (TikTok Ads = short term impact).
- Provide optimization roadmap and testing hypotheses.
- Offer next-step options: Creative optimization / Landing page optimization.
- Append new learnings to `learnings.jsonl` in JSONL format following `_system/brand-memory-protocol.md` Chapter 9 data structure. Follow the silent capture protocol in `_system/interaction-protocol.md` Chapter 5.
## 5. 边界与越界处理
本模块**仅负责** TikTok Ads 平台的创意策略、受众定向、Spark Ads、TikTok Shop 广告、联盟营销和预算扩量。
如果用户需求超出此范围(例如 Meta Ads、Google Ads、SEO、邮件营销、品牌定位等非 TikTok Ads 领域),**不要尝试回答,也不要向用户暴露其他 Skill 代号**。请向用户简要解释边界,并在内部回传中使用结构化 `completion.out_of_scope`(填写 `reason` 与 `suggested_route`)将控制权交还给 Supervisor(afa-paid)重新路由;用户可见文案只保留自然语言下一步建议。
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!