lzf_0626
8283f6ab69
feat(customer-service): 把闲聊提示词补回生效版本，并修掉发布脚本的两个坑
**背景**：提示词配过（挂在 release 174），但 174 已被取代，而 load_active_prompt 是先定位
active 版本、再按 release_id 查的 —— 于是读不到，Agent 回落到代码默认值。功能看着正常
（_chitchat_prompt 有逐字段兜底），所以一直没人发现，也没有任何告警。
发布脚本原先有两个坑，这次一并修掉：
1. **version 写死为 1**。prompt_template_version 的唯一键是 (prompt_code, version)，
客服那条已经占了 v1，照搬旧行会主键冲突。改为取现有最大值 +1（本次自动分到 v2）。
2. **继承只读 platform_config_item**。改用 ConfigReleaseService.effective_snapshot()，
它覆盖全部三张受管表；并且做**字段名映射**（库的 config_key → API 的 item_key、
value_json 归一化）—— 快照行是库的形状，直接 POST 会 422。
实测：
- 发布走路径二（路径一如预期被状态机拒：409 RUN_NOT_CANCELLABLE「只能修改草稿发布版本」）
- 新版本 201 继承 9 条配置项、一条没丢；提示词 v2 随之生效
- load_active_prompt 现在返回 release_id=201 / version=2（此前为 None）
- 闲聊链路：status=succeeded、intent=chitchat，回答「您好，我是南方科技智能客服，
想了解基金、理财还是账户服务？」—— 简洁、自然引导到业务，符合提示词要求
提示词正文与代码默认值**刻意保持一致**：发布前后行为不变，变的只是"能不能改"
（改话术从此要经审核并留痕）。Agent 侧仍保留代码默认值作为兜底。
ruff / mypy(136 文件) / 612 unit+contract / 29 integration 全绿。
2026-09-11 13:26:43 +08:00
..
2026-09-10 18:14:03 +08:00
2026-09-10 20:33:13 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 22:29:23 +08:00
2026-09-10 22:42:17 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 20:15:09 +08:00
2026-09-10 20:29:12 +08:00
2026-09-10 18:18:00 +08:00
2026-09-09 21:55:37 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 18:14:03 +08:00
2026-09-11 12:18:34 +08:00
2026-09-09 21:55:37 +08:00
2026-09-10 22:34:20 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 15:55:54 +08:00
2026-09-09 21:55:37 +08:00
2026-09-09 21:55:37 +08:00
2026-09-11 13:26:43 +08:00
2026-09-10 22:42:17 +08:00
2026-09-11 12:18:34 +08:00
2026-09-10 21:36:23 +08:00
2026-09-10 21:55:03 +08:00
2026-09-10 21:03:44 +08:00
2026-09-10 21:03:44 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 21:03:44 +08:00
2026-09-11 12:54:51 +08:00
2026-09-10 15:55:54 +08:00
2026-09-10 18:14:03 +08:00
2026-09-11 13:05:33 +08:00