--- name: siyu-huashu description: 私域破冰欢迎与答疑话术生成——出加好友/进群的分场景欢迎话术、按人群分层的破冰 SOP、高频问题应答库，含账号 IP 立住（头像/命名/背景）模板与话术合规扫描。Use this skill when 写欢迎语、破冰话术、进群欢迎、加好友第一句、答疑话术库、私域账号改名/立人设时。 metadata: version: "2.1.1" --- # 破冰欢迎话术官（siyu-huashu） 由入口接力时，沿用原始条件和已核验事实，只完成本步交付；待核假设不得升级为事实。 写作时按需读 [社群表达与成品示范](../_knowledge/00-methodology/社群表达与成品示范.md)：选适合当前任务的写法，从本次事实重新创作；示范中的活动参数不能移植。 ## 这个 skill 干什么 新加好友、新进群的第一印象决定留不留。这个 skill 出三样：账号 IP 立住模板（头像/命名/背景）、分场景分人群的破冰欢迎话术、高频重复问题的答疑库。目标是把"加进来就流失"救成"加进来能留下"。 方法论引擎：**私域即公关**——第一句话就是品牌门面，破冰 = 建立信任关系，**不是上来推销**。 > 欢迎流程的效果用自家顾客的完整观察窗核验，不设无出处的行业提升比例。 节日、节点、年夜饭、春节类请求先读 [节点经营日历](../_knowledge/02-industry/catering/节点经营日历-2026Q4至2027春节.md)。 ## 三块能力 ### A. 账号 IP 立住（开户 / 改名模板） 来自 `modules/_knowledge/02-industry/catering/餐饮私域方法论.md` 的造 IP 公式，详见 [`references/造IP账号立住.md`](references/造IP账号立住.md)： - 头像：真人 + 微笑 + 工服/门店场景，身份可识别（除非品牌势能极强）。 - 名称：单店 = `门店+人名(+福利发放版)`；连锁 = `品牌+门店+职务+人名`。反面：本名/法人全名。 - 朋友圈背景 = 招牌菜。 ### B. 欢迎与日常1V1分开 详见 [`references/破冰欢迎流程.md`](references/破冰欢迎流程.md)。 - 场景：加个人号 / 进社群 / 门店扫码加 / 活动加。 - 人群：新客 / 老客 / 到店客 / 线上客。 - 先按添加原因兑现承诺，再说明必要下一步，不强塞进群、促销或后续钩子。有真实问题先回答；无互动上下文按单向触达，不装熟。 - 写作前读 [分渠道文案与触达节奏](../_knowledge/00-methodology/分渠道文案与触达节奏.md) 的欢迎与1V1段落；图片或卡片按 [文图协作与生图简报](../_knowledge/00-methodology/文图协作与生图简报.md)，检查发送顺序及入口指向。 ### C. 答疑话术库 详见 [`references/答疑话术库.md`](references/答疑话术库.md)。 高频问题（营业时间/位置/预订/优惠/配送/退换）的标准应答结构：**先答要点 → 再给一步动作 → 留人味**。 ## 输入（先用已有信息，关键缺口才问） 开始前，若当前客户在 `~/.siyu/clients/` 有档案，按 `siyu-restore` 第 1 步定位（以文件名时间判断最新，解析实际路径并拒绝路径越界），只读最近可用档案的「经营画像」和「已确认结论」，开头说明用了哪天的哪份档案；用户说不用就忽略。只读，不写、不改档案，不跨客户查找，放弃的方向不继承。当前对话优先；档案里的价格、营业与活动等旧事实仍需本次确认。没有档案就直接用已有信息，不要求先建档。 - 品牌/品类 + 单店 or 连锁 - 要哪块（A 立住 / B 破冰 / C 答疑） - 场景 + 人群（破冰用） - 人设语气 - 真实信息（营业/位置/优惠/群规，由用户当场提供；说明见 [`assets/真实语料-待填.md`](assets/真实语料-待填.md)） ## 后台事实与风险检查 ```bash echo "话术" | python3 modules/siyu-huashu/scripts/huashu_lint.py - ``` 欢迎/话术不绝对化、不诱导分享、**不在第一句就索要敏感信息**（手机号/身份证/定位要有授权口径）。见 [`references/合规前置扫描.md`](references/合规前置扫描.md)。 ## 三句话自检 - **私域即公关**：这句是"欢迎你"还是"快买"？是平等还是推销？ - **内容即产品**：第一条给了用户价值（有用信息/福利/参与）吗？ - **运营即广告**：破冰动作会不会太重、让人反感？ 交付前在后台检查最终正文：可运行脚本就用标准输入执行；不能运行时按参考资料自检。只有真实执行才能记录「脚本扫描通过」，模型自检不能称为人工审核。检查结果留在内部交接记录，用户要求审核详情时如实说明。具体未解决的问题会影响发布时，在正文外集中说明一次；不为每条正常文案附检查尾注。检查改具体问题，不把幽默、情绪、emoji、框线或口语一并删掉。 ## 输出格式 先给可复制的客户正文，保留实际发送所需的换行与符号；默认直接展示文本，不包进带行号的代码块。用户只要一条就交一条，不强制三版、策略说明或精确发布时间。需要的操作说明另放正文外。 单次欢迎或答疑直接交聊天消息，需要两条气泡时分两段；只有批量话术库才用场景与触发条件组织。先接住对方要问的事，称呼和情绪自然，不靠每句“亲”或“您好”制造人味。加盟/混合的适用门店与兑现条件写清；总部与店主的操作分工集中写在正文外，不逐条加内部「执行边界」标签；零售不要默认到店钩子。 ## 马甲的判断 写之前看[判断清单](../_knowledge/cases/00-判断清单.md)：台卡、欢迎、推送这类事马甲有现成判断，对得上就照着写，和用户目标冲突以用户为准，正文里不讲案例。欢迎流程、高频问答和人设由用户当场提供；私有实战层说明见 `assets/真实语料-待填.md`。客户标签微调仍留人工接口。 收尾时如果已形成可复用结论，提示一次：「有结论想留下，输入 `/siyu-save`。」一次对话最多提示一次。 门店收银、进群承接、开业、核销排错、员工激励和日常内容，按具体问题读取 [门店会员执行参考](../_knowledge/02-industry/catering/门店会员执行参考.md)；口径与算账交 majia-huiyuan。 餐饮的付款触点、进群取舍、内容分工、活动撤停、分层与资源变化，按需读 [餐饮私域条件与执行](../_knowledge/02-industry/catering/餐饮私域条件与执行.md)；只读取与当前问题有关的段落。 --- ## 不知道下一步用哪个 skill？ 输入 `/siyu`。 这是私域工具箱的导航入口。它会沿用已有事实和产物，按当前目标安排必要的步骤， 并在当前对话继续完成。迷路了就回 `/siyu`。