shumingyang-opencode 將一個使用者無法獨自回答的事情轉化為一份問卷 — 一份 Markdown 文件，他們把它交給一個人非同步填寫，或在會議中一起填寫。收件人握有使用者缺乏的知識；問卷把它從他們身上引出來。
質詢的是寄送，不是主題。 只訪問使用者關於_寄送_的事，這他們總是能回答：寄給誰，以及他們需要回覆什麼。文件中的問題然後針對收件人所知與使用者所需之間的缺口。
要寄給誰？ 在一個來回中詢問收件人的角色、專業以及與使用者的關係。這決定了問卷的語氣以及它必須承載多少脈絡。當您知道收件人是誰以及他們知道什麼使用者不知道的事時，就完成了。
您需要回覆什麼？ 在一個來回中詢問使用者無法獨自解決、且需要從此人身上取得的具體決策或事實。當您有了一個具體清單，列出使用者必須能帶著去做或決策的事時，就完成了。
撰寫問卷。 起草針對第 1–2 步缺口的問題，遵循下方的文件結構。將它寫到目前目錄的
to-questionnaire-<slug>.md（slug 取自主題），並回報路徑。當檔案存在且使用者在第 2 步提出的每一項都被一個問題涵蓋時，就完成了。
文件結構
將文件框定為一份發現問卷：使用者缺乏脈絡，收件人握有它。以最重要的優先排序問題 — 非同步意味著您可能只有一次機會 — 當問題超過幾則時，按主題分組在 ## 標題下。使用下面的範本撰寫。
<問卷標題>
Purpose（目的）： 這份問卷為什麼存在，以及它所承載的決策。
From（寄件者）： <使用者> — To（收件人）： <收件人> — How your answers will be used（您的回答將如何使用）： <它們去向何處>
Context
一段用來導向一個不在使用者腦中的收件人的段落。足以好好回答即可，不是一整頁。
How to answer
截止時間與粗略的努力程度。部分回答與「我不知道」都很有用 — 標記任何您不確定的東西，而不是跳過它。
<主題標題>
每個主題一個 ## 段落。在其下，是它的問題，最重要的優先。每個問題都是一個想法 — 絕不複合 — 正下方有一個作答欄位，並且只有當問題可能被誤讀或引來敷衍回答時，才加一行_為什麼這很重要_。
Why this matters: it decides whether we provision for burst traffic now or defer it.
Anything else?
一個收尾的包羅萬象：任何我們沒問但您認為我們應該知道的事？