Best minds · 命名系统
观点一：topic 不是内部细节
如果系统自动推断了 topic，但最终回执里不展示，用户就无法确认“你到底把这条需求记成了什么”。验收必须把 topic 可见性视作功能本身。
自动推断可以隐藏过程，但不能隐藏结果。
Deploy Group · Topic Inference
自动 Topic Slug 推断验收
这页用于验收 deploy 群在用户没有显式给出 topic 时，是否能从请求语义里推断出一个稳定、可发布、可回执的 topic slug，并且在最终回执中把 推断出的 topic 与 可访问链接 一起返回。
Inferred Topic: deploy-group-auto-topic-slug-inference-acceptance-20260317
Focus: infer → deploy → reply
Need: visible topic + live links
1核心目标：让 topic 推断可被用户看见
3关键链路：推断、部署、回执
4验收原则
10多样图表模块
Best minds · 可运维性
观点二：slug 要稳定可追溯
同类请求如果每次推断出风格完全不同的 slug，后续状态查询、历史追踪、回归测试都会断裂。一个好的推断规则，应该同时服务部署和运维。
slug 是部署标识，也是后续排障索引。
Best minds · 用户体验
观点三：回执必须把“名字”和“地址”一起给
只给链接，不给 topic，用户不容易复用；只给 topic，不给链接，用户无法验证。验收的目标是同时返回两者，让用户可以立即点击，也可以随后 `/status` 复查。
最好的回执，是这次能打开，下次还能查到。
综合判断
deploy 群的自动 slug 推断，不该只是“能生成一个 kebab-case 名字”。真正的验收标准是：用户未显式给 topic 时，系统能推断出一个稳定 slug，并在最终回执中明确写出该 topic 与对应的 snapshot / latest / history 链接。这样后续 `/links`、`/status`、404 追问才有共同锚点。
推荐把“回执中显式包含 inferred topic”设为上线门槛，因为这是自动命名机制与群内协作真正接轨的位置。
四条验收要点
P1
要点 1 · topic 可见
自动推断出的 slug 必须出现在最终回执文本中，而不是只存在于内部脚本变量里。
P2
要点 2 · slug 可复用
推断结果需短、稳、kebab-case，便于后续 `/status
P3
要点 3 · 链接可访问
回执中的 snapshot / latest / history 至少要经过线上验证，不可只报“已发”。
P4
要点 4 · 失败也可解释
若推断错 topic 或部署未完成，答复必须能指出推断值与失败位置，而不是只说失败。
图 1 · 推断主流程
验收核心是：没给 topic 也能稳定进入 deploy 主链路。
图 2 · 角色泳道
用户无需懂 topic 命名规则，但必须收到推断结果。
图 3 · 结果可见性矩阵
“推断成功但用户看不见 topic”位于黄区，不算完整交付。
图 4 · 执行时间线
用户最终看到的不是“你做了推断”，而是“推断 + 部署 + 链接已返回”。
图 5 · 验收评分维度
如果 topic 没写回回执，topic 显式性维度直接不及格。
图 6 · 可复用反馈回路
用户看到 topic 后，才能在下次查询时复用同一 slug。
图 7 · slug 质量雷达
一个可验收的 inferred topic 需要同时满足部署与查询场景。
图 8 · 输入流向图
无论推断是否有歧义，最终都需要回到一个可解释的回执出口。
图 9 · 推断判定树
验收要覆盖清晰请求与模糊请求两类分支。
图 10 · 场景热力图
“无 topic 明示 + 需立即回执”的场景应被标红高优先级覆盖。
验收矩阵
| 场景 | 输入 | 预期 topic | 预期回执 | 失败时动作 |
|---|---|---|---|---|
| 自动推断 /topic | `/topic 做一页 ... 自动 topic slug 推断验收 ...` | `deploy-group-auto-topic-slug-inference-acceptance-20260317` | 明确写出 inferred topic + snapshot/latest/history | 解释推断规则并给出实际 topic |
| 后续 /status | `/status deploy-group-auto-topic-slug-inference-acceptance-20260317` | 沿用同一 slug | 返回链接，不重生成 | 检查 topic 是否被误改 |
| 后续裸 topic | `deploy-group-auto-topic-slug-inference-acceptance-20260317 token=...` | 提取首个 token | 可见状态回执 | 检查 slash-strip 路由 |
| 404 追问 | “为什么打不开” | 回溯同一 topic | 先读 log / reply-meta 再解释 | 区分推断错、部署断、latest 丢 |
回归测试步骤
Step 01
发起无 topic 的 /topic 请求
确认系统自行推断 slug，而不是报缺参或生成过长、不可读的 topic。
Step 02
检查回执文本
确认回复里不仅有链接，还明确展示推断出来的 topic 名称。
Step 03
点击 latest/history
确认回执中的链接真实可访问，而不是仅由脚本打印。
Step 04
复用 topic 查询
用回执里展示的 topic 再跑一次 `/status` 或裸 topic/token，验证 topic 可复用。