>- 评论区运营与舆情危机应对:为一批评论生成分层回复模板(赞美/提问/求购/杠精/黑粉) 与分级处理规则,从评论中挖掘选题反哺内容,负面事件时做危机分级 + 声明草稿 + 统一口径。 当用户说"回复评论"、"评论区运营"、"评论怎么回"、"钓评论"、"引导互动"、 "评论区选题"、"舆情"、"危机公关"、"差评"、"黑粉"、"被骂了"、"道歉声明"、 "统一口径"、"负面缠上来了"、"翻车了怎么办"时触发。 和 skill-quality-gate 的区别:quality-gate 是发布前合规质检, community-ops 是发布后的评论互动与危机响应。
npx skills add https://github.com/ZJU-REAL/Easel --skill skill-community-ops
> 发布后的运营层能力:回复评论、从评论挖选题、负面事件时分级响应。三种模式,命中哪个做哪个。
| 模式 | 触发场景 | 核心产出 |
|------|----------|----------|
| A 评论回复策略 | 有一批评论要回 / 问"评论怎么回" | 分层回复模板 + 分级处理规则 |
| B 评论区选题反哺 | 问"评论区能挖什么选题" / 给了一堆评论 | 3-5 条下一步选题建议 |
| C 舆情危机应对 | 出现负面事件、差评风波、被黑 | 危机分级 + 声明草稿 + 统一口径 + 红线 + 时效 |
一次请求可能命中多个模式(如"评论区吵起来了,帮我回一下顺便看要不要出声明")。先判定模式,再按对应流程执行。若输入模糊,先问清"是要回评论、挖选题、还是处理负面"。
| 字段 | 必填 | 说明 |
|------|------|------|
| 评论内容 | 模式 A/B 必填 | 一批真实评论,或"我这类内容常收到 XX 类评论"的场景描述 |
| 负面事件描述 | 模式 C 必填 | 发生了什么、在哪个平台、扩散到什么程度、有无实锤 |
| 目标平台 | 推荐 | 小红书 / 抖音 / B站 / 微博 / 公众号 / 知乎,决定调性 |
| 品牌人设/红线 | 可选 | 无 Profile 时可手动提供,用于定语气和口径 |
references/reply-playbook.md「一、五类评论分层话术库」,按五类归类用户给的评论:普通赞美 / 专业提问 / 求购买求链接 / 杠精抬杠 / 黑粉恶意差评。[占位符] 表示品牌名、产品、链接等,不写死具体 case)。references/reply-playbook.md「二、分级处理规则」给出处置分级:必回 / 引导私信 / 置顶 / 冷处理 / 删除拉黑,并说明每条评论归入哪级、为什么。references/platform-comment-ecology.md 对应平台段(小红书亲和、B站梗感、知乎专业、抖音短平快、微博快节奏、公众号克制)。references/topic-mining.md「一、评论聚类维度」聚类出高频诉求、重复疑问、争议点、许愿、吐槽。references/topic-mining.md「二、评论转选题公式」把高价值聚类转成 3-5 条具体选题建议。references/crisis-grading.md「一、危机三级分级标准」,按事件性质、扩散度、是否有实锤、是否触及安全/法律/伦理底线,判定:🟢 可忽略 / 🟡 需回应 / 🔴 需正式声明。给出判定依据(命中了哪几条标准)。references/crisis-grading.md「三、回应话术框架」出评论区/私信回应话术草稿。references/crisis-grading.md「五、统一口径」)。references/crisis-grading.md「六、危机红线」,如删评控评、甩锅、情绪化对线、大规模拉黑)。references/crisis-grading.md「七、响应时效」)。有 Profile 时:
preferences.md(要做的/不做的/合规底线)→ 回复语气与危机口径贴合品牌人设,不越红线。style.md / identity.md → 回复模板的用词、称呼、梗的尺度对齐账号风格。platforms.md → 自动确定主攻平台的评论调性,无需再问。preferences.md「合规底线」,声明不承诺做不到的事。无 Profile 时:
[占位符],不写死具体品牌/产品/人名的 case。Take zju-real/skill-community-ops from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.