計畫裡有四條我原本沒想到要決定的事

IMS 的實作計畫裡，有一段「資料層關鍵決策」：

1. 用 JavaScriptCore 執行網站的 JavaScript，沿用修正邏輯。
2. 直接讀取網站的遠端檔案，讓 App 能取得更新的排班資料。
3. 日期對應為 D0 = 7/24、D1 = 7/25、D2 = 7/26，時區固定為 Asia/Taipei。
4. 同一天、同角色相連的任務時段，要合併成一個任務區段（block）。

一開始，我腦中只有「把網站做成 App」。這四件事都是往下問，才發現必須先決定的。

例如，網站除了主資料，還有一份 22 KB 的修正檔，會修正人名、補上任務，而且持續更新。知道這件事後，才有下一個問題：要在 Swift 維護另一份邏輯，還是沿用 JavaScript？

任務合併也是如此。必須先知道一個人有多少時段、通知排程受到什麼限制，才能決定應該每個時段都通知，還是合併後再通知。

Grill 的作用，就是把一句需求裡還沒想清楚的決定，一層一層問出來。

先看問題之間的依賴，再決定怎麼問

Day 6 介紹了 grill 的基本紀律：釐清要收斂、事實先查、決策要保存。這篇用 IMS 說明，提問可以怎麼安排。

你可以把問題想成一棵樹。先決定「要不要做 Widget」，才有必要討論 Widget 要顯示什麼資料；確定使用資料快照後，再決定快照放哪裡、由誰更新。

每一輪先問目前已有足夠前提的問題。彼此獨立的問題可以一起問；需要等上一題決定的，就放到下一輪。每題附上推薦答案與理由，方便你比較取捨。

這種方式適合用在方向大致確定、需要補齊細節的時候。若連使用者或問題都還不清楚，先回到 Day 7 的四個問題，不急著決定資料格式和檔案位置。

事實先查，取捨再問

提問時，我會把「能查證的事實」和「需要選擇的方案」分開：

AI 可以先整理事實，再帶著依據提出選項。例如：「修正檔會持續更新，重寫需要同步維護，因此建議沿用原邏輯。」這樣你能判斷推薦背後的理由。

但不是所有事實都一定查得到。帳號權限、尚未公開的活動資訊，或工具無法存取的文件，仍可能需要你補充。查不到時應標示未知，不能直接當成已確認。

你也可以請 AI 推薦方案；重要的取捨則要讀懂後再確認。AI 提供分析，不能代替你知道專案真正承受得起什麼。

提問的產物，是能被重新使用的決策紀錄

三輪對話結束後，最有價值的是裡面定下來的決策。每條至少記下：選了什麼、為什麼、放棄了哪些方案，以及什麼情況下需要重新評估。

今年五月，我在一個翻譯 App 功能上分七個步驟實作。每一步開始前，AI 都先讀規格與決策紀錄，再回報要做的範圍。那次過程中，它沒有自行增加入口或發明新的 timeout 數值。

這次經驗讓我更重視把邊界寫在文件裡。光靠對話記憶，換一個執行者或隔一段時間回來，很難知道哪些事已經決定過。

中途，我曾把三個入口縮成一個。記錄時保留原本「三個入口」的理由，再新增一條決策，說明為什麼改成一個，並在舊條目標示已被取代。

這樣三個月後回來看，能讀到決策的變化，不會只剩一個結果。

今天要做的一件事：把釐清結果存成決策紀錄

拿 Day 7 的設計文件，檢查還有哪些會影響實作的決定沒有答案。

如果 Day 6 已經完成過 grill，就整理那次的結論，只追問新發現的缺口。若尚未做過，再使用下面這段指令：

請根據這份設計文件，釐清仍未決定、會影響實作的事項。

- 先讀既有決策，避免重問已經確認的內容。
- 事實類：先查專案、文件或資料來源，附上依據；查不到就標示未知。
- 決策類：列出選項、推薦方案、理由，以及會影響什麼。
- 每輪只問前提已足夠的關鍵問題，三輪內整理結果。
- 尚未解決的問題，分成「阻擋開工」和「可以延後」。

接著，請 AI 依文末格式輸出決策紀錄。你要逐條讀理由：它引用的事實可靠嗎？這個取捨符合你的時間、資源和使用者需求嗎？

接受全部推薦也可以。這個系列的企劃，我就接受了十八題的推薦方案；前提是我讀過理由並同意。若不同意，也把原因寫進去，讓下一個讀文件的人知道你的考量。

確認後，將決策紀錄存到 docs/decisions-log.md，納入版本控制。阻擋核心設計的問題要先解決；可以延後的問題，則留下暫定做法與重新檢查的時機。

新人最常在這一步犯的錯

把查資料和做決策混在一起。 能查到的事實先查，再討論取捨；工具無法取得的資訊要明確列出。

提問完，只留下聊天紀錄。 後續執行者還要從長對話裡重新找答案。整理成決策條目，才能直接引用。

改了決策，卻蓋掉原本的理由。 新增替代決策，標示舊條目已失效，保留當時的脈絡。

只看推薦答案，沒看理由。 是否採用，應取決於依據與代價，而不是 AI 的語氣有多肯定。

到了三輪就把所有未知都當成可延後。 停止提問是為了整理，不代表未知已經消失。會阻擋開工的事項仍要處理。

本篇可帶走的檔案

decisions-log.md 的骨架如下。原則是保留歷史，不覆寫舊理由；可以更新狀態，並連到取代它的新決策。

# 決策紀錄

## D-001：<決策標題>

- **狀態**：有效／已被 D-00X 取代
- **決策**：
- **依據**：<專案檔案、文件、已確認的需求>
- **理由**：
- **未採用的方案**：<方案，以及不選它的原因>
- **重新評估的條件**：
- **日期**：

## D-002：<新決策標題>

- **狀態**：有效
- **取代的決策**：<若無則省略>
- **決策**：
- **依據與理由**：
- **未採用的方案**：
- **重新評估的條件**：
- **日期**：

以 IMS 為例，一條決策可以這樣寫：

• 決策：由 App 使用 JavaScriptCore 執行修正檔。
• 理由：修正檔持續更新，沿用原邏輯可避免維護兩份實作。
• 未採用的方案：在 Swift 重寫；修正邏輯變更時，需要額外同步修改。
• 重新評估的條件：修正檔開始依賴 JavaScriptCore 無法直接提供的瀏覽器功能。

最後一項讓決策有了適用邊界。未來條件改變時，團隊可以有依據地重開討論，不必每次從零開始。