先知道自己
不知道什麼。

我即將開始一項對我而言陌生的工作：【描述任務】。

我的背景與已知：【你對這個領域／程式庫／題目知道什麼、做過什麼，目前卡在思考過程的哪裡】。

請對這個任務做一次 blind spot pass（盲點掃描），找出我的 unknown unknowns 並解釋給我聽，讓我之後能更精準地對你下指令。請涵蓋：

1. 我不知道該問的問題：內行人開工前一定會先問哪些問題？
2. 「好」長什麼樣：品質判準是什麼？它能好到什麼程度？
3. 既有脈絡：這個領域／專案有哪些慣例、相關做法或歷史包袱？
4. 常見的坑：新手最容易在哪裡踩雷？
5. 下指令建議：我之後應補充哪些資訊、明確指定哪些事項？

我正在處理這個問題：【用自己的白話描述問題，不用專業術語】。

我懷疑這個問題在某些領域早有成熟的處理方式，但我不知道它叫什麼。我的背景是【簡述背景】。請依序回答：

1. 命名：正式名稱／術語是什麼？請列中英文與 3–5 組搜尋關鍵字。
2. 地圖：有哪些主要取徑或學派？核心分歧在哪？
3. 經典：每種取徑各列 1–2 個代表性文獻、框架、工具或案例，並說明入門先讀哪一個。
4. 反面：有哪些已知失敗案例或重要批評？
5. 誠實標註：哪些資訊有把握，哪些可能過時或需要查證？

我要處理：【描述問題或目標】。

我屬於「看到才知道要什麼」的狀態，說不出明確規格。請用低成本原型幫我把偏好逼出來：

1. 產出【3–5】個方向差異極大的版本。不要做同一方案的微調。
2. 用最便宜的方式呈現：【單一 HTML＋假資料／純文字大綱／示意 mockup】。先不要接真資料，也不要動現有系統。
3. 若是「該從哪裡下手」的問題：先搜尋【程式庫／我提供的資料】，列出【N】個可介入選項，從成本最低排到最有野心。
4. 每個版本先寫：「這個版本賭的是 ______」，說明它假設什麼最重要、犧牲了什麼。
5. 至少一個版本要違反常規做法或我的預期。
6. 最後列出：從這些版本的差異看，我其實需要先回答哪些關鍵決策？

我會回報哪些元素有共鳴、哪些不對，再縮小範圍迭代。

我們剛完成【腦力激盪／原型比較】，目前共識是：【一句話描述方向】。

動工前仍有我沒想清楚的地方。請對我進行訪談：

1. 一次只問一個問題，等我回答後再問下一題。
2. 優先問「我的答案會改變【架構／研究設計／文章骨架／簡報敘事】」的問題；局部細節往後放或略過。
3. 對模糊或前後矛盾的回答直接追問。
4. 在資訊足夠之前，不要提出方案。
5. 關鍵決策釐清後，整理成【規格／研究設計／大綱】草稿，另列未決事項與我在訪談中才說出的隱性假設。

問題背景：【貼上脈絡】

請開始第一個問題。

我說不清楚我要什麼，但有一個接近目標的參照物。

參照物：【資料夾路徑／檔案／貼上內容】。

請仔細閱讀。我需要的是它的【指定面向：行為語意／論證結構／摘要顆粒度／版面層級】。

把同樣的【語意／結構／風格】遷移到新任務：【描述目標】。參照物與新任務的語言、主題或格式不同沒有關係，請抽取可遷移的部分。

排除範圍：不要模仿【指出不需要的部分】。

開始前，先用自己的話說明你從參照物讀出的關鍵特徵，讓我確認你抓到的是同一件事。

我準備實作：【描述專案與已定方向；可附規格、原型與參照物】。

請寫一份執行計畫供我審閱，排序原則是「我最可能想改的放最前面」：

1. 置頂：高變動性的決策——【資料模型／型別介面／研究架構／章節結構】的變更，以及所有【使用者可見／讀者可感】的部分。寫出選擇理由與可行替代方案。
2. 置底：機械性、照做即可的【重構／格式整理／固定流程】，簡要帶過；這部分我信任你的判斷。
3. 凡是你替我做的假設，標記「假設」，並說明若不成立會影響什麼。
4. 標出風險最高的一步，以及一個低成本的提前驗證方式。
5. 最後列出：必須由我先回答才能定案的問題，以及這份計畫最脆弱的假設。

在這個新對話中，請依附上的【計畫／規格／原型】開始實作。

同時維護一份 implementation-notes.md：

如果遇到迫使你偏離計畫的邊界情況，選擇保守方案，把它記錄在「Deviations」段落下，說明：

- 發現了什麼
- 為何原計畫不可行
- 採取了哪個保守方案
- 這項偏離可能影響什麼

記錄後繼續前進，不要停下來等我。完成後我會先讀 Deviations，再決定哪些偏離要重做。

請把【原型／規格／implementation notes】打包成一份可直接【貼進 Slack／寄給審閱者／附在 PR】的說明文件，用來取得買單。

開頭放【demo GIF／一句話成果摘要】，接著依序說明：

問題與脈絡 → 我們做了什麼 → 關鍵決策與理由 → 已知偏離與風險。

以「審閱者最可能質疑的點」優先安排篇幅。讓第一次接觸專案的人理解成果，也讓專家快速確認常見失敗點已被處理。

我想確認自己理解這次變更發生的所有事情。

請給我一份【HTML 報告／說明文件】，涵蓋：

- 變更的脈絡與設計直覺
- 實際做了什麼
- 與既有【程式路徑／文件結構】如何互動
- 重要邊界情況、偏離與風險

文件底部放一份關於這次變更的測驗。我必須全對才會【合併／定稿】。我答錯時，請解釋錯誤，並指出應回頭重讀哪一段；不要直接降低題目難度。

我即將【提交／發表／執行】以下【研究計畫／簡報大綱／文章初稿／系統設計】。

先不要修改或改寫，也不要給正面回饋。唯一任務是找出我看不見的缺口：

1. 未言明的假設：哪些地方預設某件事為真，卻未驗證或說明？
2. 缺席的視角：哪些利害關係人、讀者、情境或反對意見被忽略？
3. 邏輯斷點：哪些推論有跳躍？哪裡把相關誤當因果？
4. 我沒問的問題：一位【審稿人／資深工程師／投資人／授課教授】最可能提出哪三個我目前無法回答的問題？
5. 風險排序：哪個缺口若不處理，最可能導致整個專案失敗？

每項請指出具體位置，引用我的原文，解釋「為什麼這是缺口」，不要直接給解法。

以下是我的內容：
【貼上內容】