从0写一个抖音自动评论工作流Skill

很多人第一次看到 Claude Code 的 Skill，都会有一种感觉：这东西很强，但不知道该从哪里开始写。

如果一上来就做“自动剪辑 + 一键多平台发布”这种大型工作流，门槛会很高：工具多、链路长、发布风险也更高，不适合拿来做第一篇入门实战。

所以这篇文章，我换一个更容易讲清楚、也更接近真实需求的案例：

从 0 写一个抖音评论工作流 Skill。

这个案例为什么适合入门？因为它同时具备 4 个特点：

  1. 有明确输入：评论内容、视频链接、回复目标
  2. 有明确输出：回复草稿、待发布内容、执行结果
  3. 有明确边界：先生成，再确认，再发布
  4. 能完整体现 Skill 的核心价值：把一段提示词变成可复用的工作流能力

这篇文章不会只讲概念，我会直接带你拆清楚：

  • Skill 到底适合解决什么问题
  • 一个可用的 Skill 目录应该怎么组织
  • 抖音评论工作流该怎么拆步骤
  • SKILL.md 应该怎么写
  • 怎样给“发布动作”加人工确认，避免误操作
  • 写完之后怎么调试，怎么迭代

如果你想做自己的自动化工作流，这篇应该会比单纯看官方文档更容易上手。

一、先想清楚：为什么这个场景适合做 Skill？

很多人写自动化时，第一反应是先写脚本。但 Skill 和普通脚本最大的区别，不在于“能不能执行动作”，而在于它把下面几件事统一起来了：

  • 使用场景描述
  • 输入输出约束
  • 执行流程约束
  • 风险控制规则
  • 和 Claude Code 工具链的配合方式

也就是说，Skill 不是“多了一段 prompt”，而是给 Claude Code 增加了一种可重复调用的工作方式。

以抖音评论处理为例，如果你每次都手动这样说：

1
去打开抖音后台，看看最新评论，把值得回复的挑出来，帮我写 3 条风格自然的回复，最后等我确认再发布。

当然也能做，但问题是：

  • 每次都要重新描述
  • 容易遗漏约束
  • 风格不稳定
  • 忘记加“人工确认”就有风险
  • 后续也不方便复用

这时候，把它封装成一个 Skill 就很有价值。

你以后只需要一句：

1
/comment-reply-workflow

或者你自己的自定义 Skill 名称，就能把整条流程拉起来。

二、先别急着写，先把工作流拆对

一个 Skill 写得好不好，核心不是文笔，而是流程拆解是否合理。

我建议你先把抖音评论工作流拆成下面这 5 步：

1. 读取评论

先拿到当前视频下的新评论，或者由用户直接提供评论内容。

2. 筛选是否值得回复

不是所有评论都值得处理。比如：

  • 明显是广告
  • 纯表情
  • 引战内容
  • 重复评论
  • 没有交流价值的内容

这一步的目标，是减少无效回复。

3. 生成回复草稿

根据评论内容，生成 1 到 3 条候选回复。

这里要控制几个点：

  • 语气自然
  • 不像机器人
  • 不要太官方
  • 不要过度营销
  • 保持账号人设一致

4. 人工确认

这是非常关键的一步。

我自己的建议是：所有对外发布动作，都必须加人工确认。

也就是说，Skill 可以自动：

  • 读取评论
  • 分析评论
  • 生成回复
  • 准备发布动作

但真正点击“发送”之前，一定要等你确认。

5. 执行发布

确认之后，再让 Claude Code 通过浏览器工具完成最终回复。

这就是一个非常标准、非常适合教学的 Skill 流程。

你会发现，它其实已经具备了工作流的完整结构：

1
2
3
4
5
6
7
8
9
读取输入
  ↓
分析筛选
  ↓
生成草稿
  ↓
人工确认
  ↓
执行外部动作

只要你能把这条链路想清楚，后面写别的 Skill，本质上也都是类似套路。

三、一个最小可用的 Skill 目录应该长什么样？

如果你只是先做入门版，我建议目录尽量简单，不要一上来拆太多文件。

一个最小可用版本，通常像这样：

1
2
3
4
5
6
.claude/
└── skills/
    └── douyin-comment-workflow/
        ├── SKILL.md
        └── scripts/
            └── extract_comments.py

这里面最重要的是 SKILL.md。

因为 Claude Code 识别 Skill，本质上先看的就是这个文件。你可以把它理解为：

  • 这个 Skill 是干什么的
  • 什么时候触发
  • 要遵守什么流程
  • 允许用哪些工具
  • 哪一步必须等用户确认

如果只是第一版，你甚至可以先不写脚本，把评论内容直接由用户粘贴进来。等工作流跑顺了，再去补浏览器抓取和解析逻辑。

这个思路非常重要：

先跑通最小闭环，再补自动化。

很多人一开始就想把所有动作都自动化，最后不是卡在网页结构变化，就是卡在权限问题，结果 Skill 反而写不出来。

四、抖音评论工作流 Skill 的核心提示词怎么写？

下面给你一个适合入门讲解的 SKILL.md 简化版结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# douyin-comment-workflow

用于处理抖音视频评论：读取评论、筛选优先回复对象、生成回复草稿，并在用户确认后执行发布。

## 目标
- 帮用户提高评论区互动效率
- 保持回复风格自然、真实
- 所有发布动作必须经过人工确认

## 执行流程
1. 获取评论内容
2. 判断哪些评论值得回复
3. 为每条评论生成 1-3 条候选回复
4. 汇总给用户确认
5. 用户确认后，才执行发布动作

## 规则
- 不要回复广告、辱骂、引战内容
- 不要生成夸张营销话术
- 回复语气要口语化，像真人
- 如果用户没有明确确认，绝对不能自动发布

你会发现，这里面没有任何复杂代码，但它已经把一个 Skill 最重要的东西说清楚了。

对于教学来说，我认为这里要反复强调一件事：

Skill 最重要的不是“写得多复杂”

而是下面这三点有没有定义清楚：

  1. 目标是什么
  2. 流程是什么
  3. 边界是什么

一旦这三点不清楚，Skill 就会变得很飘。

比如有的人会写成这样：

1
帮我自动处理抖音评论并完成发布。

这句话太短了，看起来简单，但实际上信息严重不够，Claude Code 很难稳定执行。

因为它不知道：

  • 处理到哪一步算完成
  • 需不需要筛选评论
  • 回复要几条候选
  • 是否需要人工确认
  • 什么评论不该回

所以真正好用的 Skill，通常都不是一句话，而是一套明确的工作流规则。

五、评论回复这类 Skill，最重要的是“人工确认关卡”

为什么我选抖音评论工作流当教学案例？

一个很重要的原因就是：它天然适合讲确认机制。

因为只要涉及这些动作：

  • 回复评论
  • 发布内容
  • 发送消息
  • 修改外部平台状态

你都应该默认它是一个高风险动作。

所以在 Skill 里，我建议明确写出类似这样的规则：

1
2
3
4
## 发布前确认（必须遵守）
- 展示待回复的评论和候选文案
- 等待用户明确确认
- 未收到确认前，绝不执行发送操作

这个规则非常值钱。

因为很多新手写自动化，最容易犯的错误不是“不会写”，而是写得太敢了。

看起来像是自动化程度高了，实际上是把风险也一起自动化了。

对于内容运营、社媒运营、账号管理类场景，我认为更稳的模式应该是：

  • AI 负责准备
  • 人类负责拍板

这样既能省掉重复劳动，又不会把账号安全和内容风险交出去。

六、一个更适合实战的执行流程示例

如果你要把这个案例继续往真实使用方向推进，我建议工作流可以设计成下面这样：

Step 1：用户提供目标

比如：

  • 指定某条视频
  • 或者直接让 Skill 处理“最新评论”

Step 2：读取评论列表

如果已经接了浏览器自动化工具，就让 Claude Code 打开页面读取。

如果还没接浏览器，就先让用户贴评论文本。

Step 3：提取重点评论

筛选原则可以这样设：

  • 优先回复提问型评论
  • 优先回复高互动评论
  • 优先回复能带来二次讨论的评论
  • 跳过无意义、重复、攻击性评论

Step 4：生成候选回复

每条评论给 2-3 个版本，比如：

  • 自然版
  • 专业版
  • 轻松版

这样用户选择会更方便。

Step 5：等待用户确认

把结果整理成这样的结构展示：

1
2
3
4
5
6
7
评论 1：这个功能怎么做的？
- 回复A：这个是我用 Claude Code 写了一个小工作流跑出来的，后面我会单独出教程。
- 回复B：核心是用 Skill 把几个重复步骤串起来了，后面我会专门讲。

评论 2：能不能出教程？
- 回复A：可以，我准备先写一篇博客，再录一期完整视频讲解。
- 回复B：已经在安排了，我会先从一个简单案例开始讲。

Step 6：执行发布

只有你明确点头之后，Claude Code 才继续执行评论回复。

这个流程一旦跑通，你后面其实很容易把它扩展成：

  • YouTube 评论回复工作流
  • 小红书评论处理工作流
  • 视频平台统一评论运营工作流

你会发现，真正能复用的不是平台本身，而是这套工作流骨架。

七、写 Skill 时，最容易踩的 4 个坑

1. 一开始就追求“大而全”

很多人第一版就想加上：

  • 自动读取评论
  • 自动分类
  • 自动生成回复
  • 自动发送
  • 自动记录日志
  • 自动生成日报

结果最后哪一步都不稳定。

更好的方式是：

第一版只做“读取评论 + 生成回复 + 人工确认”

先把这个闭环跑通，再继续扩展。

2. 不写边界规则

比如没有写清楚：

  • 什么评论不能回
  • 什么情况下要停下来
  • 什么动作必须确认

一旦这些没写，Skill 的行为就容易飘。

3. 回复文案太像机器人

如果你只是让 AI“礼貌回复用户评论”，很容易生成这种内容：

1
感谢您的评论与支持，我们会持续为您带来优质内容。

这种回复最大的问题不是语法，而是太不像真人。

你应该给 Skill 更明确的要求，比如：

  • 用口语化表达
  • 避免官方腔
  • 每条不超过 40 字
  • 像创作者本人在回复

4. 忘记把“确认”写成硬规则

很多人会在脑子里默认“最后我会看一下”，但没有写进 Skill。

这非常危险。

因为对 Claude 来说，没写出来的约束，往往就不算稳定约束。

所以只要涉及外部发布动作，最好把这句话直接写进 Skill：

1
未收到用户明确确认前，绝不能执行发布动作。

八、别急着自己写，先复用现成 Skill

很多人一学 Skill，就默认所有东西都得从零开始写。其实完全没必要。

更成熟的顺序应该是：

  1. 先找现成 Skill
  2. 能直接用就直接用
  3. 不完全匹配就在现有 Skill 基础上改
  4. 只有确实没有合适方案，再从零创建

也就是说，真正高效的路径不是“从零手搓一切”，而是：

先复用，再生成，最后定制。

获取现成 Skill 的两种方式

1. 直接去 skills.sh 找

1
https://skills.sh/

这个方式适合：

  • 你想自己浏览现成 Skill
  • 你想看看别人是怎么组织 Skill 结构的
  • 你想直接挑一个能安装、能复用的方案

2. 安装 find-skills 让 Claude Code 帮你找

1
npx skills add https://github.com/vercel-labs/skills --skill find-skills

装好之后，就可以直接让 Claude Code 按你的需求去找合适的 Skill。

比如你想找“把 Markdown 文章直接发布到微信公众号”这类能力，可以这样搜：

1
npx skills find "md写微信公众号文章"

这个方式适合：

  • 你不想打开网站慢慢看
  • 你想直接用自然语言描述需求
  • 你想让 Claude Code 帮你匹配更接近的 Skill

这和抖音评论工作流有什么关系？

关系很大。

你完全可以二选一：

  • 去 skills.sh 看有没有接近“评论处理 / 评论回复 / 社媒运营”的 Skill
  • 或者直接让 find-skills 帮你找

如果已经有接近的，优先复用。
如果没有完全贴合的，再生成自己的 Skill。

这样你真正自己写的，就只剩下最有价值、最个性化的那一部分。

九、用现成的 skill-creator 生成规范骨架

如果找不到完全合适的现成 Skill，也没必要从空白文件开始硬写。更好的方法是直接复用官方的 skill-creator：

1
https://skills.sh/anthropics/skills/skill-creator

安装命令：

1
npx skills add https://github.com/anthropics/skills --skill skill-creator

它解决了什么问题？

它最有价值的地方，不只是生成模板，而是把“从想法到可用 Skill”的流程标准化了。它会帮助你：

  • 定义 Skill 要做什么
  • 补齐输入、输出、触发方式、执行步骤
  • 生成更完整的 SKILL.md
  • 设计测试提示词
  • 对比“有 Skill”和“没 Skill”的效果差异
  • 根据结果继续迭代

所以它不是简单的模板复制器，更像一个 Skill 创建工作台。

为什么比手写更靠谱？

因为你真正想要的不是“看起来像 Skill”，而是：

  • 格式是对的
  • 结构是完整的
  • 触发描述更稳定
  • 在真实任务里能用

很多人自己手写时，最后常见的问题不是不会写，而是：规则漏了、确认关卡没写、结构漂了，结果 Skill 虽然存在，但并不稳定。

那这篇里的抖音评论案例，应该怎么结合它？

最自然的方式就是：

  1. 先安装 skill-creator
  2. 用它生成“抖音评论工作流 Skill”的第一版骨架
  3. 再补上这个场景特有的规则
    • 哪些评论不要回复
    • 回复语气要像真人
    • 发布前必须人工确认
  4. 最后再接浏览器读取评论和执行发布动作

这样讲给观众时，逻辑会非常顺：

  • 不是从空白硬写
  • 而是先借助成熟工具生成结构
  • 再把业务规则一点点补进去

十、调试自己的第一个 Skill，我建议这样做

如果这是你第一次写 Skill，我建议你按这个顺序调试：

第一步：先只测试文案生成

别急着接平台，先验证下面这件事：

  • 同一条评论
  • 能不能稳定生成你满意的回复风格

如果这一步都不稳定，后面接平台也没意义。

第二步：再测试流程顺序

看看 Claude Code 会不会老老实实按你定义的流程走：

  1. 先看评论
  2. 再生成回复
  3. 先展示给你
  4. 没确认前不继续

如果顺序总跑偏，说明 SKILL.md 里的流程定义还不够明确。

第三步：最后再接外部动作

等前面两步都稳定了，再去接浏览器自动化或者发布动作。

这样调试效率会高很多。

因为你能明确知道：问题到底出在提示词、流程设计，还是外部平台操作。

十一、为什么我建议你先用这个案例入门，而不是一上来做复杂自动化？

因为这个案例刚好处在一个非常好的难度区间。

它不像“Hello World”那么简单，也不像完整内容工厂那么复杂。

它能完整覆盖这些 Skill 核心能力：

  • 定义任务目标
  • 组织执行流程
  • 约束输出格式
  • 控制风险动作
  • 等待用户确认
  • 再执行外部操作

说白了，你真正学会的不是“抖音评论”本身，而是“怎么把一个真实需求包装成可复用 Skill”。

只要这个能力掌握了，后面你可以继续做：

  • 自动整理评论区高频问题
  • 自动给视频生成 FAQ 素材
  • 自动把评论转成选题池
  • 自动把热门问题整理成下一条视频脚本

这时候，Skill 就不再只是一个“命令别名”，而是你工作流里的一个稳定能力模块。

十二、最后总结一下

如果你之前一直觉得 Claude Code 的 Skill 很神秘，那我希望你看完这篇，至少先抓住一个核心认知：

Skill 不是复杂系统的专属能力，而是把一个重复工作流，整理成 Claude Code 可稳定调用的执行模板。

而“抖音评论工作流”这个案例，正好是非常适合入门的一种：

  • 需求真实
  • 结构清晰
  • 风险可控
  • 很容易扩展

如果你准备开始写自己的第一个 Skill，我建议直接照下面这个顺序动手：

  1. 先写出工作流步骤
  2. 再写 SKILL.md
  3. 先跑“生成草稿”版本
  4. 再补“人工确认”规则
  5. 最后才接“执行发布”动作

这样你会更容易成功。

十三、一个最小行动清单

如果你今天就想开始，我建议按这个顺序动手：

  1. 先去 skills.sh 看有没有现成 Skill
  2. 或者直接装 find-skills，让 Claude Code 帮你找
  3. 如果没有完全合适的，再安装 skill-creator
  4. 用它生成“抖音评论工作流 Skill”的第一版骨架
  5. 最后只补你自己的业务规则

如果你只是想先验证目录结构，也可以先建一个最小目录：

1
2
3
4
cd /你的项目目录
mkdir -p .claude/skills/douyin-comment-workflow
cd .claude/skills/douyin-comment-workflow
touch SKILL.md

然后把下面 3 件事写清楚：

  • 这个 Skill 的目标是什么
  • 它的执行步骤是什么
  • 哪一步必须等待你确认

只要这三件事写清楚，你的第一个 Skill 就已经不是空架子了。

后面我也会继续把这个案例往下拆，下一篇会更具体讲：

  • SKILL.md 应该怎么逐段写
  • 怎么让 Claude Code 真正识别并调用它
  • 怎么把浏览器操作接进这个工作流里
  • 怎么把这个案例扩展成可复用的评论运营工具

如果你想学会写自己的 Skill，我建议先别追求复杂，先把这个小工作流跑通。你一旦跑通第一个，后面很多自动化思路都会一下子打开。

赏 支付宝打赏 微信打赏

如果文章对你有帮助，欢迎点击上方按钮打赏作者，更多功能请访问博客站

AI工具 > 教程
#AI自动化 #Claude Code #Skill #抖音
从0写一个抖音自动评论工作流Skill
https://blog.fxcxy.com/2026/03/19/从0写一个抖音评论工作流Skill/
作者
独立开发
发布于
2026年3月19日
许可协议