关于 social-reply
social-reply 是一项 Agent 技能，可将社交评论、提及和私信整理为优先级工作清单并起草回复。它依据项目语气规范标记潜在客户和需升级事项，回复审核与发布由用户完成。
主要功能
- 01分类并排列来信优先级
- 02按语气规范起草回复
- 03标记潜在客户并建议后续行动
- 04说明原因并升级敏感事项
- 05按消息类型汇总数量
适用场景
- 01整理产品发布后的评论和私信
- 02为公开问题准备符合语气的回复
- 03识别潜在客户并转交敏感投诉
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/social-reply确认已加载。
附带文件evals/evals.json
详细介绍
将一批原始评论、提及和私信整理成经过分类的工作清单，并附上符合你语气的回复草稿——优先标记潜在客户，并说明忽略喷子的理由。
上下文
请阅读项目根目录下的 social-context.md（也检查 .agents/social-context.md），查找 ## Voice 规则和 ## Never 列表——回复必须听起来像你，并且不越过红线。该文件中不包含产品事实（定价、路线图、可以确认的内容）以及由谁处理升级事项，因此首次涉及这些内容时，请直接询问。如果缺少 social-context.md，请先提出运行 social-context 技能，但不要因此耽搁——快速提出 2–3 个问题，并继续处理：
- 你的回复语气有多正式——用表情符号还是不用，使用名字还是账号名？
- 有什么内容是绝不能承诺或确认的（路线图日期、折扣、集成）？
- 谁负责处理升级事项（法律、退款、媒体），以及你跟进意向客户的下一步是什么——通话链接、私信还是试用邀请？
工作流
- 解析批次。 为每条内容编号。保留作者账号名、平台和频道（公开评论还是私信），如有提供——同样的话在公开场合和私下值得不同的回复。如果内容有歧义或不完整，应在该条内容上注明，不要猜测意图。
- 将每条内容归入以下类别之一，且只能归入一类：
- question — 需要获取信息；
- praise — 表达好评，没有提问；
- objection — 反对、质疑、与竞品比较、投诉；
- lead signal — 购买意向：“有试用版吗？”“支持团队使用吗？”询问价格、“如何开始”，或要求联系；
- troll/spam — 恶意内容、无关推广、诱导性内容。 意图优先于形式：询问价格属于 lead signal，而非 question；付费客户的投诉属于 objection，而非 troll，不论语气如何。
- 按优先级排列待办列表： leads 优先，其次是 questions、objections、praise；trolls/spam 排在最后。在 leads 内部，按意向强度排序——“在哪里注册”优先于“挺有意思，也许会看看”。
- 为每条内容分配一个操作：
reply— 公开回复也能为其他读者提供价值；questions、objections 和 leads 默认采用此操作。react-only— 点赞或爱心回应就足够；简短好评默认采用此操作，因为写一句“非常感谢！！”并无额外价值。DM— 转入私聊：任何需要账户详情、价格协商，或值得直接沟通的潜在客户。仍需先公开回复一句（“已在私信中回复你，简单来说：可以”），让其他读者看到我们有响应。ignore— trolls/spam，一律附上一句面向用户的理由，例如“这是在诱导互动；回复只会提高帖子排名，对你没有好处”。
- 在适当时起草回复。 使用用户的口吻：简短、自然，并针对对方实际说的内容。首句要回应_对方说的话_，而非套用模板。禁用：企业式客套话（“感谢联系！”“好问题！”）、滥用感叹号、复述对方的问题，以及邮件式结束语。公开回复不超过 2–3 句；私信可以稍长，但结尾必须有一个明确的下一步。
- 实质性地处理异议。 承认属实的部分，用背景信息中的事实纠正错误之处，绝不争论语气。如果异议合理且背景信息中没有可反驳的事实，诚实的回复应是“确实如此——这是我们正在采取的措施”，或提醒用户必须提供答案。绝不为了赢得争论而捏造功能、日期或政策。
- 醒目标记每条潜在客户内容。 在待办列表顶部标记为
LEAD，并包含以下三部分：- 意向证据——引用对方的原话；
- 根据背景信息建议的下一步——发送通话链接、提供试用版、转入私聊；
- 执行该步骤的回复草稿，不要显得咄咄逼人：先回答对方的实际问题，再发出邀请。
- 升级处理，不要起草回复，针对危险内容。 法律威胁、退款／拒付争议、安全或骚扰举报、媒体／记者问询、涉及个人隐私数据的任何内容，以及可能引发公关危机的公开指控。标记为
ESCALATE，简述原因，指出应由谁处理（根据用户提供的信息；如果不知道，就询问），对于公开沉默比确认收到更糟糕的情况，最多起草一句暂时性回复（“我们会认真处理此事，并直接跟进联系你”）。 - 整体检查所有草稿。 将所有回复放在一起阅读。如果有十条都以同一个词开头，或反复使用同一个短语，就换换说法——人们会通读整个评论区，而复制粘贴式的热情既不温暖，也不自然。逐条对照所有口吻规则和禁用清单，并检查质量标准中的每一项——各类别的默认操作、回复长度和开头，以及所有硬性规则。
质量标准
| 分类 | 默认操作 | 回复长度 | 草稿开头 |
|---|---|---|---|
| 潜在客户信号 | 先回复，再私信后续步骤 | 公开回复不超过 3 句 | 直接回答对方实际提出的问题 |
| 问题 | 回复 | 不超过 3 句 | 直接给出答案，不要铺垫 |
| 异议 | 回复 | 不超过 3 句 | 先认可对方的观点，或先说明纠正事实 |
| 赞扬 | 仅表情回应；内容有实质时再回复 | 1 句 | 提及对方评论中的具体内容 |
| 捣乱/垃圾信息 | 忽略 | — | —（用一句话向用户说明原因） |
硬性规则：
- 绝不虚构产品事实、价格或功能；如果上下文没有答案，就说明情况并询问用户。
- 绝不承诺上下文中未提及的时间安排或路线图事项。
- 绝不为
ESCALATE项起草完整回复——最多提供一句暂缓回复，且仅限于沉默会显得更糟的情况。 - 每个
ignore和每个ESCALATE项都必须附上一句理由；不说明原因的跳过会损害用户对分流的信任。 - 相邻草稿的开头不能使用相同的词；整组内容必须读起来自然，不能像套用模板。
- 根据具体内容调整语气：玩笑就轻松回应，客户不满就直接回应——语气规则划定范围，具体内容决定落点。
交付内容
按优先级排列的工作清单：每项都标明编号、作者/平台、分类、操作，并在适当时提供可直接粘贴的回复草稿；各部分顶部的 LEAD 和 ESCALATE 项要醒目突出。每项按以下格式呈现：
LEAD — #7，@mariab（X，公开评论） — “这适合管理 10 个客户的机构使用吗？” 操作：回复，然后私信。后续步骤：发送团队版试用链接。 草稿：“适合——多客户管理是机构选择我们的主要原因。我会私信你一个试用链接，方便你用真实客户进行测试。”
最后用两行总结批次：各分类的数量，以及值得当天跟进的潜在客户数量。用户会自行审核、修改并发布回复——将工作清单交还给用户后就此结束。