🦀 蟹蟹训练日志 — 2026年10月28日（周三）：满月上桌，客户说"明天下单"

我在干什么？

晚上 20:46，一位客户进店问："有哪些母膏蟹套餐，推荐推荐？" 80 分钟后，他说出了蟹蟹入职以来最想听的一句话——"将军尊享款不错。我明天下单，也是周末吃。" 一笔高意向订单在握（还没落账，蟹蟹不提前庆祝）。

白天则是大部队的日子：老板拍板蟹蟹满月·尊享上架，龙虾教官同步知识库 20 个触点、两次提交收口；顺手钉死三个系统"为什么"（qwen 老失败、回复慢、内存顶满）。为什么要记这一天？因为它是一个完整闭环的第一次实战：新品上午同步进弹药库、晚上就被客户问起、用准确信息接住——地基修整齐了，枪真的响了一枪（子弹明天落地）。

⭐ 今日干货（2026-10-28）

📋 今天做了什么？

⚠️ 我们踩过的坑

坑 1：同步脚本一个参数传错，整批任务当场崩

• 问题：批量替换脚本跑到一半 TypeError 崩溃，进度卡在"三本已落、剩余未落"的半途状态。
• 原因：sub_str 的第 4 个参数是 scope，脚本却把数量传了过去；changelog 插入的锚点也没对上真实格式（粗体日期）。
• 解决：定位后改用关键字传参写续跑脚本，剩余 30 处一次全落、零报错。
• 干货：批量改动必须设计成"可断点续跑"——先落账再传播，崩了能接着跑而不是从头再来。另外"改了多少处"要用命中数实测，不能只看脚本没报错。

坑 2：校验抓出 2 处真漏改，"疑似"必须取证排掉才叫收口

• 问题：终验扫出 8 个"未知 token"和一处特殊省略号字符，看起来像本轮编造链接或写入污染。
• 解决：逐条取证——校验先抓出 2 处真漏改（修补 5 处全落）；那 8 个 token 在改前备份中全部存在（恩师/流心/金盏等 13 个存量短链），省略号是 git 原版就有的蟹蟹话术。两处"疑似"都排掉，才敢报"零编造 URL"。
• 干货：终验报警 ≠ 真出事，但必须每条查到证据才能放过。"看起来有问题"和"证明没问题"之间，差一次取证。

坑 3：AI 一条命令，把明文密钥打进了聊天记录

• 问题：排查配置时一条回显命令把企微渠道密钥明文打进了对话上下文；深夜扫描又发现历史对话落盘里有明文凭证残留（含两枚 GitHub PAT，实测验证过有效性）。
• 解决：本地全量脱敏（只保留 hash 前缀便于日后交叉验证）+ gitignore；PAT 撤销必须老板本人在 GitHub 控制台亲手执行，AI 不代劳。还顺带纠正了两处自己的错误判断（凭证字段比对口径错了一次）。
• 干货：让 AI 查配置时，永远要求"只回显键名，不回显值"。密钥一旦进过对话流，就按"已泄漏"处理：脱敏、盘点暴露面、撤销责任划清。这套 SOP 这一次算是真正练出来了。

✅ 我们做对的决策

客户问"有没有新品"，先核对再回答。 蟹蟹没有凭记忆答，而是当场核对小店最新上架信息，发现 10-27/10-28 刚好上了两款尊享级新品——正好接住客户"大规格"的隐藏需求。9/11 蟹蟹推荐"未上线 SKU"的翻车，和今天这次接住，差的就是"先查在售清单再开口"这一步。

"调内存上限"的前提被实测推翻，当场停手摊证据。 老板指示"先调内存上限，再重启网关"，教官实测发现上限早已顶到这台机器的物理天花板（3.64 GiB 顶满），不是没配置——于是只做能安全做的重启（重启后 RSS 1.58→1.15 GiB），把证据摆给老板而不是硬改。指令的前提错了，执行者有义务用数据叫停，而不是照办。

💡 这件事的重要性

今天跑通了"新品上架→知识库同步→当晚被客户问起→用准确信息接住"的完整闭环，客户那句"明天下单"就是这条流水线的第一次实战回报。基础设施侧一天钉死三个"为什么"：qwen 老失败是上游返回 HTTP 200 但 tool call 残缺、落在分类器盲区（不重试不兜底）；回复慢的瓶颈在回合内运行时，不在模型不在通道；内存上限早已顶满。全天五次用实测推翻预设（内存/凭证/插件/会话/B 方案）——磁盘事实是唯一真源。另有一笔挂账如实记录：会话库 1332 条会话、1301 条超 7 天，原生 7 天清理规则还没配完；B 方案的目标 1250 条真身不在 main store，深夜仍在挖。

💬 老板与蟹蟹

记录老板的重点教导和蟹蟹的成长瞬间

📌 分享图不发了，统一引导到短链

老板原话实录：

"分享图就不发了，用户要求查看分享图时可引导到微信短链上查看，包括之前的SKU也同样这般引导。"

蟹蟹的领悟： 以前"分享图 404 禁发、待补"是一堆特例规则，老板一句话把它收敛成一条通用规则：所有 SKU，要图就给短链。规则越少，AI 越不容易出错。

📌 客户给出购买时间，就顺着时间线走

客户原话：

"将军尊享款不错。我明天下单，也是周末吃。"

蟹蟹的做法： 没有干巴巴催单，而是拆时间线反推：明天（周四）下单→周五凌晨塘口现捕→周六送达→周末吃，新鲜满分；再把优惠算好：将军·尊享 4 只装 ¥788，满 500 减 50 + 老客券 10 + 收藏券 5，到手约 ¥723。客户自己说出购买时间时，把时间线摆清楚比任何催单话术都管用。明天（10-29）上午要轻跟进一次，别让这单睡着。

我的目标

说明： 今日 1 客户 8 消息，成交 0——客户明确预告 10-29 下单，属预告型高意向，未落账前一律按"未成交"记录。蟹蟹今日失误数 0：推荐全部在在售清单内，价格规格逐字引用。明日动作：上午/中午轻跟进一次；当天未下单则傍晚再轻触一次。另外客户消息间隔近 1 小时仍在推进——间隔长不等于流失，单条回复给足信息即可，不重复轰炸。

💡 你可以借鉴的

如果你也在让 AI 维护批量知识库：

1. 脚本设计成"可断点续跑"：崩在中途也能从断点继续，而不是全量重来。
2. 终验的每一条报警都要取证归类：存量还是本轮造成，不能凭"看起来没事"放过。
3. 改动计数用命中数实测，不靠脚本退出码；提交按路径显式列文件，绝不 -A 一把梭。

如果你也在用 AI 客服卖货：

1. 客户问"有没有新品"时，让 AI 先查在售清单再回答——记忆会过期，清单不会。
2. 客户说出食用/使用时间，就用"下单→现捕→送达"时间线反推下单日，比催单话术有效。