Problem
原文(使用者回饋,2026-06-19):
「需要 clarify 的部分,與其要我說,不如給我幾個選擇我比較確定」
Context:一次 /idd-diagnose batch(12 個客戶 issue)結束後,AI 在 aggregate report 用散文列出 4 個需要 stakeholder 拍板的決策,並問使用者「要不要我用 AskUserQuestion 把這 4 個決策做成選項讓你逐一拍板?」。使用者的回饋是:對於需要澄清/決策的點,與其要使用者用自由文字 articulate,不如 render 幾個具體選項讓他挑,使用者會更確定。
定位:這不是 net-new principle — IDD 已有此哲學(見下方「Actual」)。本 issue 是建議把 choice-rendering 升為更一致的 default,並延伸到 diagnose 結尾 surface 的一般 stakeholder 決策(目前只在 Layer V vagueness trigger 才自動走 choice-rendering)。
Type
enhancement(clarify / decision-surfacing UX)
Expected
- 當 AI 在 diagnose / clarify / 任何決策點需要使用者輸入時,只要決策空間可列舉,預設用
AskUserQuestion render 具體候選選項(含推薦項 + 一句 trade-off),讓使用者「挑」而非「寫」。
- 只有當決策本質開放、AI 真的舉不出候選時,才 fallback 到 free-text 詢問(fallback 是具名例外,不是預設)。
- 適用範圍不限 Layer V vagueness pre-check — 也涵蓋 diagnose aggregate report 結尾 surface 的 stakeholder 決策(例如「移除 X 與既有 #N 方向衝突,要 A保留/B移除/C只移placement 哪種」這類)。
Actual
IDD 已有「render 候選讓 user 挑」的原則,但觸發面偏窄:
- idd-clarify Step D.1:「可列舉 → 用 AskUserQuestion render 該點的候選詮釋讓 user 挑,而非從白紙寫(NSQL P1 — Read-Only for Humans);無法列舉才 fallback free-text」— 但這綁在 Layer V vagueness trigger(V1/V4 ≥ 4) 才會自動跑。
- idd-diagnose Step 3.4 Layer V:同樣只在 vagueness 分數觸發時走 Hybrid 3-option。
- 缺口:diagnose 結尾 surface 給 user 的「一般 stakeholder 決策」(非 vagueness、非單一 issue 的 clarify)目前靠 AI 自覺才會提議做成選項 — 本 case 就是 AI 先用散文列「你需要決定 X/Y/Z」,使用者才回饋「不如直接給我選項」。
Impact
- 降低使用者 articulate 的認知負擔、提高決策確定性(user 自述「給我幾個選擇我比較確定」)。
- 與 NSQL「AI 寫,人讀」哲學一致(candidate enumeration 把「AI 理解的選項空間」攤開,misframe 一眼可抓)。
- 影響面:idd-diagnose(aggregate / stakeholder decision surfacing)、idd-clarify(放寬 trigger 面)、可能 idd-plan。
相關
- idd-clarify Step D.1(既有 choice-rendering 原則 — 本 issue 建議放寬其 trigger 面)
- idd-diagnose Step 3.4 Layer V Hybrid 3-option
- NSQL Confirmation Protocol(AI 寫、人讀;Read-Only for Humans)
Current Status
Update (2026-06-19): implemented via spectra propose+apply → verify-gated PASS (1 adversarial review, P1 fixed) → PR #191 open. Next: review + merge + /idd-close #190.
Problem
Context:一次
/idd-diagnosebatch(12 個客戶 issue)結束後,AI 在 aggregate report 用散文列出 4 個需要 stakeholder 拍板的決策,並問使用者「要不要我用 AskUserQuestion 把這 4 個決策做成選項讓你逐一拍板?」。使用者的回饋是:對於需要澄清/決策的點,與其要使用者用自由文字 articulate,不如 render 幾個具體選項讓他挑,使用者會更確定。定位:這不是 net-new principle — IDD 已有此哲學(見下方「Actual」)。本 issue 是建議把 choice-rendering 升為更一致的 default,並延伸到 diagnose 結尾 surface 的一般 stakeholder 決策(目前只在 Layer V vagueness trigger 才自動走 choice-rendering)。
Type
enhancement(clarify / decision-surfacing UX)
Expected
AskUserQuestionrender 具體候選選項(含推薦項 + 一句 trade-off),讓使用者「挑」而非「寫」。Actual
IDD 已有「render 候選讓 user 挑」的原則,但觸發面偏窄:
Impact
相關
Current Status