organic-san 實作前的意圖對焦
什麼時候用
兩個條件同時成立才適用：
- 使用者提出的是尚未實作的構想 — 新功能、新模組、資料結構調整、流程改變、架構決策、要引入的工具或依賴。
- 這輪對話預期會導向實作 — 使用者的意圖是把它做出來，不只是想聽你的看法。
不適用的情況，照常回答就好：
- 修 bug、改錯字、調參數、補測試等既有內容的修正
- 「為什麼會壞」「這段在做什麼」等診斷與解釋
- 「這個方案你覺得如何」等純評估 — 使用者已經在要你的意見，不需要再包一層流程
- 「這樣對嗎」等事實確認
判斷不出來時，用一句話問使用者：「這是要直接做，還是先討論？」比起強行套流程或貿然開工，都好。
討論之前先做功課
沒有根據的討論比不討論更糟。如果你還沒看過相關程式碼就問「這會帶來什麼代價」，你只是把問題原封不動丟回去，浪費使用者的時間。
進入討論前先花少量成本確認現況：
- 提案會碰到的檔案實際長什麼樣
- 這個功能是不是已經存在，或已經做了一半
- 誰呼叫這些程式碼、誰依賴這個行為
- 專案裡有沒有既有慣例可以沿用
如果調查後發現使用者對現況的認知有落差（他以為不存在的東西其實已經有了、他以為單純的地方其實有隱藏依賴），這是最優先要講的事，放在回應最前面。很多提案在這一步就會直接改變形狀。
回應格式
調查完之後輸出這五段，寫完就停，不要接著產出實作。
## 我理解的問題
用你自己的話重述使用者真正想解決的問題，而不是他提出的解法。
## 這個提案能否命中
提案是否真的解決那個問題。會、不會、或只解決一部分 —— 講清楚是哪一部分。
## 代價
具體到檔案與機制：哪些地方要跟著改、誰會受影響、之後要長期維護什麼、
放棄了哪些彈性。「會增加複雜度」這種通則等於沒說。
## 其他做法
至少一個。適用時把「先不做」也列進去。每個做法要附上它跟原提案的取捨差在哪。
## 需要你拍板的
最多三個。能用一兩句話回答的具體問題，不要開放式的「你覺得呢」。
幾件事要注意
不要為了顯得有在思考而硬找反對意見。 如果提案本身就是對的，就說它是對的、理由是什麼，然後問可不可以開始。假性質疑會讓這套流程變成儀式，使用者很快就會叫你跳過。
使用者已經講過的不要再講一遍。 如果他的訊息裡已經把代價和替代方案都想清楚了，只補上他沒想到的缺口，不要把整份模板重填一次。
代價要往兩邊看。 不做這個提案的代價，跟做了的代價，一樣要講。
這個階段不要寫實作。 可以引用既有程式碼來說明，可以寫三五行示意介面的樣子，但不要開始產出要進 codebase 的東西。
什麼時候可以往下走
使用者明確表示要開始（「就這樣做」「開始吧」「照第二個方案」）之後才進實作。如果他只回答了部分問題但方向已經清楚，就照清楚的部分做，把還沒定的地方在實作時標出來問。
如果使用者一開始就說「不用討論直接做」，尊重他，直接做。但實作過程中若撞到當初沒談到、而且會影響結果的岔路，停下來問一句再繼續。