問卷（Open Questions → Questionnaire）

有問題必須由別人回答時用這個：文件有洞、兩份來源打架、或根本還沒有任何來源文件。

輸出是一份使用者拿去問對方的 Markdown 問卷，不是 AI 自己去訪談。

核心手法：Grill the send, not the subject

只訪談使用者關於「這份要寄給誰、你要拿回什麼」——那是他永遠答得出來的。

不要反過來訪談他問題本身：他之所以需要這份問卷，正是因為那些他答不出來。逼他猜的結果是把假設寫成事實，違反 golden-rules 第 1 條。

兩輪對話，各問一次：

1. 要寄給誰？ 收件人的角色、專業、與使用者的關係。這決定問卷的語氣，以及要攜帶多少背景。 完成條件：你知道收件人是誰，以及他知道而使用者不知道的是什麼。
2. 你要拿回什麼？ 使用者無法獨力解決、必須由這個人給的具體決策或事實。 完成條件：你有一份清單，列出使用者拿到回覆後必須能夠決定或執行的事。

問卷的每一道題，瞄準的是第 1 步與第 2 步之間的落差。

語域

問卷是 L1 業務語言（見 language-register）。收件人是業主、PM 或領域專家，不是工程師。

不出現：schema、欄位名、API、環境變數、框架名、內部識別字。 可以出現：需求編號，但要用一句話說明它指的是哪條需求，不能只給編號。

出題規則

• 一題一個概念，絕不複合。「系統要支援哪些付款方式，以及退款規則是什麼？」是兩題。
• 重要的排前面。 非同步意味著你可能只有一次機會，對方讀到一半就放棄是常態。
• 超過幾題就用 ## 依主題分組。
• 每題底下留作答區。
• 只在問題可能被誤讀、或容易招來敷衍答案時，加一行「為什麼這題重要」。每題都加會變成噪音。
• 收尾留一個 catch-all：「有沒有我們沒問到、但你覺得我們該知道的？」

題庫：需求類問卷（FR／NFR 還沒問清楚）不要從零想題目——取 00 需求護身符 §3.2／§4.2 的 8＋8 題起手，再依「你要拿回什麼」裁剪。那份已經是 L1 語域，可直接照念；§3.1／§4.1 的完整清單只在往 production 走時才展開。

模板

寫到 docs/questionnaire-<slug>.md（或專案既有放需求文件的地方），並從相關的 spec／plan 連過去。

# <問卷標題>

**目的：** 這份問卷為什麼存在，以及卡在上面的是什麼決策。

**From：** <使用者> — **To：** <收件人> — **您的答覆會用在：** <去向>

## 背景

一段話，讓沒在使用者腦袋裡的人也能答得好。足夠回答即可，不是一頁簡報。

## 怎麼填

期限與大概要花多久。**部分作答與「我不知道」都有用**——不確定的請標記出來，不要跳過。

## <主題標題>

### <一個問題，一個概念>

_為什麼這題重要：<只在可能被誤讀時才寫>_

>

## 還有其他嗎？

有沒有我們沒問到、但你覺得我們該知道的？

答覆回來之後

1. 每一則答覆落進 spec 或 plan 時，標明它來自問卷的哪一題，不要抹除它來自哪裡。
2. 分清楚確認與推論——收件人親口回答的算確認；由回答推導出來的仍然是假設，要標記。
3. 「我不知道」是有效資料：它代表這件事目前沒有人有答案，記成未決項而不是省略。
4. 對方的回答不等於拍板。涉及優先序與範圍的，仍需要有決定權的人明確同意——回答是輸入，不是核准。

Attribution

方法改編自 mattpocock/skills to-questionnaire（MIT, © 2026 Matt Pocock）。L1 語域約束、答覆的來源標註與「回答不等於核准」的邊界為本專案新增。