docs: demo handbook - compare subcommand (2b) + deepseek model guidance

Case 2b documents `advisor compare` with the live-observed echo-vs-LLM
table (echo 0ms unverified "unknown" vs deepseek ~1.5s severe
cross-field root cause). Case 2 notes deepseek-v4-flash as the
preferred model after glm timed out twice back-to-back on
2026-10-20; pitfalls table updated to match.

Co-Authored-By: Claude Code <noreply@anthropic.com>

src/docs/advisor-demo-cases.md

@@ -93,16 +93,51 @@ xce jobs kill <JOBID1> [JOBID2]
 
 ## 用例 2：真 LLM 抓跨字段不一致（最出彩，需 LLM 路由）
 
-与用例 1 同一操作，但重点展示 LLM 的增值：glm-5-3-flash 在同一份快照上
+与用例 1 同一操作，但重点展示 LLM 的增值。实测两个独立增量（都复现过）：
-输出了 echo 规则给不出的**第二条** finding——"cluster 报 2 个 pending，
+
-但队列 normal 报 0 pending 0 running，记账不一致"。这是真实观测（两次
+- glm-5-3-flash：输出 echo 规则给不出的**第二条** finding——"cluster 报
-独立运行都出现），evidence 全部逐字可验、unverified=false。
+  2 个 pending，但队列 normal 报 0 pending 0 running，记账不一致"。
+- deepseek-v4-flash：输出 echo 给不出的**跨字段矛盾定性**——"作业 PEND
+  876s 而三节点全 idle 且无派发"（severe，直接点名 job id，suggestion
+  指向 scheduler 日志）；echo 只能说 reason "unknown"（degraded）。
+  延迟 ~1.5s，1400 input + ~130 output token。
 
 **讲法**：echo 是基线（兜底、零成本），LLM 是增量（跨字段关联）；防火墙
 保证 LLM 说的话每个标识符都能在快照里找到原文，编造就降级标记。
 
 **风险预案**：glm 路由偶发超时（30s 超时后自动降级 echo，决策标记
 degraded=true）——现场反而是卖点："外部模型挂了，advisor 没挂"。
+**首选 deepseek-v4-flash**（2026-10-20 实测：glm 连续两次 30s 超时，
+deepseek 同场景 1.5s 稳定返回）；换模型只需 `--stop` 后
+`ADVISOR_LLM_MODEL=deepseek-v4-flash ~/bin/advisor-restart.sh`。
+
+---
+
+## 用例 2b：echo vs LLM 同题对照（pitch 数据页，一键）
+
+`advisor compare`（d4bd504f）把同一份快照同时喂给 echo 和 LLM，输出
+JSON 对照行（scenario / trigger / 每侧 model、延迟、token、findings、
+unverified 计数）。LLM 侧错误原样进 `llm_error` 字段而非静默降级——
+路由抖动会作为数据呈现，不会被吞掉。
+
+```bash
+# 先按用例 1 提交一个 PEND 作业（-R "select[r1m > 9999]"），等过 5min 阈值后：
+env XCE_API_URL=http://172.31.1.30:8080 XCE_API_KEY=$(cat /tmp/advisor_apikey_v2) \
+  ADVISOR_LLM_BASE_URL=http://127.0.0.1:6789/v1 ADVISOR_LLM_API_KEY=sk-litellm-router \
+  ADVISOR_LLM_MODEL=deepseek-v4-flash \
+  ~/bin/xce-advisor compare | python3 -m json.tool
+```
+
+实测对照（pend_stall，同一快照，两次运行一致）：
+
+| 侧 | 模型 | 延迟 | token | findings | unverified |
+|---|---|---|---|---|---|
+| echo | echo-rules | 0ms | 0 | 1（reason "unknown"，degraded） | 1/1 |
+| LLM | deepseek-v4-flash | ~1.5s | 1408+~130 | 1（severe：PEND 876-902s 而 3 节点全 idle） | 0/1 |
+
+干净的对照一行话：**echo 0ms 给出一个无法归因的 degraded；LLM 1.5s 给出
+可执行根因方向，且证据全部逐字可验**。这是 pitch 里"LLM 增量价值"的
+量化页。compare 是纯测量路径：不写决策日志、不推送。
 
 ---
 
@@ -162,7 +197,7 @@ EOF
 | 坑 | 影响 | 预案 |
 |---|---|---|
 | **apiserver 重启使所有 API key 失效**（key 是纯内存 map，无持久化） | 所有 curl/xce 401 | 重新发：logon 拿 admin token → `POST /xce/v1/apikeys`（role_name=advisor_agent，username=advisor-svc）→ 存回 `/tmp/advisor_apikey_v2` → **重启 advisor** |
-| glm 路由超时（偶发） | 用例 2 降级为 echo（degraded=true） | 顺势讲兜底设计；或演示前 `curl /v1/models` 预检 |
+| glm 路由超时（偶发） | 用例 2 降级为 echo（degraded=true） | 顺势讲兜底设计；或演示前 `curl /v1/models` 预检；**直接换 deepseek-v4-flash**（快且稳，见用例 2） |
 | SSE 监听用 `curl -m 180` 会在 5min 阈值前断 | 以为推送没到 | 监听窗口用 `-m 600` 以上，或用 MCP 工具事后查 |
 | stall 阈值 5 分钟 | 用例 1 有 5-6 分钟干等 | 先讲架构图/MCP 工具填这段时间；或把演示作业提前 5 分钟提交 |
 | advisor 进程死了 | 一切不输出 | `~/bin/advisor-restart.sh --check` 确认；`~/bin/advisor-restart.sh` 一键拉起（自检活性） |