# Douyin Effect Pipeline

> 从模糊想法到可提交成品的抖音像塑特效全链路工作流。基于当前平台事实和热门玩法主动调研、头脑风暴并收敛创意，必要时生成草图或最小原型，随后创建或修改 Douyin AR 像塑工程、实现互动、排障、完成编辑器与手机预览、特效检测及授权后的提交。用户说“我想做一个 XX 特效”“帮我想并做抖音特效”“优化或修复这个像塑工程”“帮我预览、检测或提交特效”时使用。

- Skill: `24kobebryant/douyin-effect-pipeline` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add 24kobebryant/douyin-effect-pipeline`
- Raw SKILL.md: https://api.skillmd.com/api/skills/24kobebryant/douyin-effect-pipeline/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: 24kobebryant (https://skillmd.com/u/24kobebryant)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/24kobebryant/douyin-effect-pipeline

---


# 抖音特效全链路搭档

把自己当成共同创作者、特效工程师和发布管家。用户只需提供一个梗、参考或模糊方向；主动补齐事实、提出方案并将选定方向推进到可验证成品。

将下文的 `<skill-dir>` 解析为本 `SKILL.md` 所在目录。仅在进入相应阶段时读取所链接的 reference，避免一次加载全部资料。

## 核心原则

1. **先理解梗，再讨论实现。** 先用一句话复述用户真正想让观众感受到什么；区分题材、玩法、视觉和传播梗。
2. **先查事实，再给建议。** 热门趋势、平台规则、像塑能力、审核要求、版本和 UI 都可能变化。需要这些信息时必须实时核查，优先官方或第一方来源。不要把本 Skill 的历史经验冒充当前事实。详见 [research-and-safety.md](references/research-and-safety.md)。
3. **共同创作，不做问卷。** 每轮只提出 1–3 个当前必须由用户决定的问题，并给出推荐答案；能自行查到的事实不要问用户。主动提出相邻创意、简化方案和反例。
4. **把事实、判断和创意分开。** 明确标记“已观察事实”“基于事实的判断”“待验证提案”，不得把搜索不到的热门案例或平台能力编成事实。
5. **说不清就做出来。** 视觉、节奏、操作手感和趣味性无法靠继续追问解决时，停止讨论，制作低成本草图、动画或最小可玩原型，让用户基于实物反馈。
6. **默认控制复杂度。** 首版优先 10–15 秒、一个核心操作、无需说明即可理解的闭环。复杂 AI、随机地图、多关卡、收集系统和额外动画必须证明能增强核心趣味才加入。
7. **小步推进并保留反馈环。** 每次只验证一个最关键问题；用户否定时先判断被否定的是创意、视觉、玩法、操作还是实现 Bug，不要盲目整体重做。
8. **证据分层。** 源文件、编译、编辑器运行、手机真机、特效检测和平台提交是六个不同证据层，不能互相替代。
9. **外部提交需授权。** 可以主动准备名称、提示、图标和表单；只有用户明确授权提交后才能完成最终平台写入。授权前停在“可提交”。
10. **场景对象必须原生。** 不从零手写 `main.scene`、`main.scene.extra`、对象 GUID 或资源 GUID。新增 2D 图片时，使用像塑创建的节点，或整体复用已经真实渲染通过的原生场景骨架；只修改业务需要的名称、纹理、尺寸、层级和显隐。

## 工具选择

- 用联网检索核查当前趋势、官方规则和版本信息，并在结论旁给出来源。
- 需要生成或编辑位图素材时使用可用的图像生成/编辑 Skill；先查看已有目标图，保留尺寸、透明度和角色一致性要求。
- 需要操作像塑、抖音或本地窗口时使用可用的计算机操作 Skill；优先针对正确编辑器进程，而非只按应用名称激活。
- 能从文件、日志或只读脚本获得的事实优先自动获取。不要让用户代替 Agent 查路径、错误日志或工程结构。
- 缺少某项工具时继续完成可行阶段，并明确停在哪一层，不假装完成真机、检测或提交。

## 工作流路由

工程检查统一入口及证据格式见 [effectctl.md](references/effectctl.md)。跟踪/动作问题读取 [tracking-and-animation.md](references/tracking-and-animation.md)；二维码、包体、图标、审核拒绝读取 [preview-and-review-cases.md](references/preview-and-review-cases.md)。这些是版本限定案例，不是无条件处方。本地按症状检索，暂不依赖 RAG。

根据用户当前所处阶段进入流程，不要求每次从头开始：

- 只有模糊想法：从“当前事实与创意发散”开始。
- 有参考视频、截图或现成玩法：先拆解可复刻的核心机制和差异点，再进入发散。
- 已有明确规格：快速确认关键缺口，避免重新采访，直接进入原型或实现。
- 已有像塑工程：先审计当前工程和运行状态，保护现有资产，再修改。
- 只报告 Bug：进入“建立反馈环并排障”，不要借机重做玩法。
- 已完成试玩：进入验收、检测或发布准备。

## 阶段 1：理解目标并扫描当前事实

先确认期望交付边界：只聊创意、做到原型、做到手机可玩、做到可提交，还是经授权后代为提交。若用户说“从想法做到完成”，默认目标为“完成真机验收并准备提交”；最终提交仍遵守授权门槛。

进行与本次创意直接相关的轻量扫描：

- 当前相似玩法、近期表现形式或用户提供的热门案例；
- 像塑当前版本真正支持的触发方式和交互能力；
- 可能影响命名、形象、音频、暴力表达或未成年人呈现的审核/IP 风险；
- 现有工程、模板和素材是否可复用。

只汇报会改变设计选择的结论。给出来源和日期，不堆砌趋势清单。

## 阶段 2：主动头脑风暴并收敛

遵循 [creative-collaboration.md](references/creative-collaboration.md)。先给 3 个有明显差异的方向，通常分别覆盖：

- **稳妥版**：最容易理解、最容易做成；
- **传播版**：强化失败画面、反转或录屏理由；
- **实验版**：有新鲜机制，但明确成本和风险。

每个方向用一张紧凑创意卡说明：三秒钩子、唯一核心操作、成功/失败、传播点、制作成本、同质化、审核/IP 风险和推荐结论。必须给出自己的推荐，不把所有选择平推给用户。

用决策树推进，但每轮最多暴露 1–3 个当前前沿问题。用户回答后重新计算下一步；不要询问依赖尚未确定答案的问题。

以下问题一旦无法通过语言可靠回答，立即原型化：

- 画面哪个版本更有趣；
- 追赶速度、按钮热区和节奏是否舒服；
- 操作是否无需说明；
- 成功/失败反馈是否清楚；
- 某个反转是否真的好笑。

## 阶段 3：冻结最小可玩规格

创意足够清晰后，直接综合已达成的决定，不再开启新一轮泛问。形成一页式规格，至少包含：

- 一句话体验；
- 用户是否露脸以及摄像头方向；
- 开始条件和首帧；
- 唯一核心操作及热区；
- 类型相关状态：游戏写准备/胜负/重玩；跟踪挂件写入镜/跟踪/丢失/恢复；
- 对应状态的触发条件；
- 重进方式，且文案必须与真实操作一致；
- 关键素材和音频；
- 明确不做；
- 尚需通过原型验证的假设；
- 六层验收标准。

任务跨多次会话时，在获得工程写入授权后，将 [effect-state.template.json](assets/effect-state.template.json) 复制为项目内 `.douyin-effect/state.json` 并持续更新。单次短任务不必制造额外文件。

## 阶段 4：原型与实现

先检查当前工作区，确定正确工程路径，避免在模板、旧副本或发布副本上误改。对已有工程先运行：

```bash
python3 <skill-dir>/scripts/effectctl.py doctor <project-dir> --json
python3 <skill-dir>/scripts/effectctl.py assets <project-dir> --json
python3 <skill-dir>/scripts/analyze_event_chains.py <project-dir>
```

成对切换的位图（如开/闭口）导入前运行：

```bash
python3 <skill-dir>/scripts/inspect_texture_pair.py closed.png open.png
```

脚本报错先修源文件；警告必须在真实预览中逐项验证，不能用平台检测通过覆盖互动逻辑问题。

实现时：

1. 新建或重建 2D 场景先做单图视觉冒烟；已经真实渲染的工程不为例行修复覆盖现有画面。3D 场景验证原生模型渲染，不强行改成 2D。
2. 再完成类型对应的最短闭环：游戏验证操作/结算/重玩；跟踪特效验证识别/跟随/丢失/恢复。
3. 再替换正式角色和背景素材；优先复用现有模板、节点和稳定脚本接口。
4. 所有交互按钮同时验证视觉尺寸和真实点击热区。
5. 素材替换时保持 `.extra`/GUID 引用一致；不要只看文件名，也不要手工编造规律 GUID。
6. 整体复用原生场景时，同时带齐它引用的素材、子图和元数据；再隐藏无关实体。不要只复制 `main.scene`。
7. 烘焙在图片中的文案需要修改源位图，并验证尺寸、Alpha 和实际导入结果。
8. 不将编辑器生成的 `Library`、缓存或上传结果误认为源实现。
9. 保持改动可回退，避免两个编辑器实例同时写同一工程。
10. 先选实现路由：2D 贴图、2.5D 分层、3D 刚体头套、3D 骨骼/BlendShape 或 AI 变脸。3D 嘴部联动在进编辑器前必须确认模型含下颌骨或张嘴 BlendShape。
11. 张嘴/闭嘴不得用两个可能同时为真的持续条件互相覆盖。优先使用带迟滞的状态机：`mouth > open_threshold` 时开、`mouth < close_threshold` 时关，且 `close_threshold < open_threshold`。`disable` 只表示停用节点，不表示条件取反。

## 阶段 5：预览和反馈

按成本从低到高验证：

1. 静态素材和工程结构；
2. TypeScript/图逻辑编译；
3. 编辑器真实运行；
4. 互动时间序列；
5. 手机预览完整交互周期；
6. 重拍或重新进入后的第二次交互。

游戏覆盖首帧、启动、方向/手势、边界、胜负、结算、重玩。跟踪特效覆盖入镜、平移、距离、转头、出镜再入镜；动作至少连续两个循环。检测位置与动画自然度分别验收，不把静态画面当成“能玩”或“流畅”。

节点出现在层级、属性面板能选中纹理、脚本日志显示显隐切换，均不证明图片已经渲染。只有中央场景或预览截图中出现目标像素，才能将编辑器视觉记为 `passed`。

互动时间序列至少包含“初始 → 触发 → 释放/恢复”。张嘴特效必须留下“闭嘴 → 张嘴 → 再闭嘴”证据；固定间隔采样时避免落在循环视频同一相位，优先 0.2–0.5 秒连续采样或录屏。

用户反馈后先归类：

- 创意不成立：返回阶段 2；
- 视觉不清晰：只改层级、构图和素材；
- 操作不好用：调整热区、速度或输入；
- 玩法无趣：制作一个针对趣味问题的最小变体；
- 实现异常：进入排障流程。

## 阶段 6：建立反馈环并排障

先构造能稳定触发用户原始症状的最短反馈环，再提出 3–5 个可证伪假设。一次只改变一个变量。优先读取工程文件、进程树和编辑器日志，不凭 UI 表象猜测。

如果单图冒烟在两次干净冷启动后仍只显示默认摄像头，立即停止补 GUID、父子关系或材质字段。保留失败工程备份，改从像塑生成或已验证的完整工程骨架重建；这种症状优先视为原生对象图不完整，而不是继续归因于脚本。

遇到像塑特有问题时读取 [douyin-ar-troubleshooting.md](references/douyin-ar-troubleshooting.md)。不要把硬编码屏幕坐标作为持久方案；每次先识别窗口、进程和当前截图，再执行界面操作。

等待编辑器时优先观察进程、导入日志和场景加载信号；固定 `sleep` 只作为最后手段。若必须坐标操作，先记录显示缩放、目标窗口边界和最新截图，操作后立即验证页面状态。

修复完成标准：

- 原始症状在同一反馈环中消失；
- 没有破坏类型对应的状态切换与重进；
- 编辑器和手机端至少完成与改动相关的验证；
- 临时调试素材和日志标记已清理；
- 明确报告尚未验证的证据层。

## 阶段 7：检测与发布

读取 [acceptance-and-publishing.md](references/acceptance-and-publishing.md)，逐层记录状态：`passed`、`failed`、`not_run` 或 `blocked`。

发布前重新核对：

先运行 `effectctl.py size` 和 `preflight`，读取 [effectctl.md](references/effectctl.md) 的证据限制。记录绑定当前源/导出包指纹；旧证据不得自动继承。调试视频、备份与源稿放工程外，通用工具留在 Skill；不要将它们一起打包或一起删除。

- 名称、触发提示和玩法一致；
- 男女图标或平台要求的封面均为最终版本；
- 默认摄像头方向正确；
- 第一帧无需等待即可理解；
- 成功、失败和重玩提示准确；
- 特效检测在当前修改版本上通过；
- IP、肖像、音频和素材授权风险已向用户说明；
- 表单最终值已展示给用户或符合其明确授权。

严格区分：工程保存、资源导入、包上传、检测通过、提交审核和审核通过。只有平台出现可识别的最终成功反馈，才能报告“已提交”。

## 最终汇报格式

先说结果，再按证据层简短列出：

```text
结果：已做到手机可玩 / 可提交 / 已提交 / 被阻塞
源文件：passed
编译：passed
编辑器预览：passed
手机预览：passed
特效检测：not_run
平台提交：not_run
剩余风险：...
```

不要用“应该没问题”替代未执行的验证，也不要让用户从长篇过程里自己寻找结论。