找出你的未知數 是做什麼的？
概述
使用者對任務的描述（他們的提示、上下文、參考資料）與實際工作（程式碼庫、其限制條件、現實）之間的差距，正是未知存在的地方。當代理遇到未知時，它會猜測使用者的意圖。這項技能的任務是終止猜測：幫助使用者在實作之前、期間和之後，以迭代的方式——而不是一次性的事前計劃——發現並命名他們的未知數。
這是一個工具箱，而不是固定的管線。先進行診斷，然後只應用適合的技術。不要在瑣碎的任務上執行所有技術。
四種未知數
在選擇技術之前，先分類缺少的是什麼：
- 已知已知 — 已在提示中說明。
- 已知未知 — 使用者知道自己尚未決定這個部分。
- 未知已知 — 太明顯以至於沒有寫下來，但使用者一眼就能認出（通常是視覺/使用者體驗品味）。
- 未知未知 — 從未考慮過；使用者不知道他們自己不知道什麼。
步驟 0 — 診斷
在執行任何操作之前，決定哪種未知佔主導地位，並相應地選擇技術：
- 不熟悉的領域或程式碼庫中不熟悉的角落 → 盲點掃描（未知未知）。
- 難以描述，「看到就知道」→ 原型設計（未知已知）。
- 方向明確，細節模糊 → 面試使用者 + 起草計劃（已知未知）。
始終提供關於使用者是誰以及他們已經知道什麼的上下文——這會讓下面的每一項技術都更有效。
交接給其他技能
使用此技能作為發現層，而不是整個工作流程。在命名未知數之後，選擇能夠解決下一個不確定性的最小後續技能。
| 未知或下一個需求 | 交接給 | 使用時機 |
|---|---|---|
| 使用者尚未完全表達意圖 | interview-me | 一次問一個問題，直到潛在需求明確。 |
| 計劃需要壓力測試 | grill-me 或 grill-with-docs | 壓力測試假設；當需要記錄 ADR 或詞彙表更新時，使用文檔變體。 |
| 缺少外部事實 | research 或 source-driven-development | 在決定之前收集原始來源證據。 |
| 使用者「看到就知道」 | prototype | 在提交實作之前，使用假資料顯示具體選項。 |
| 工作需要正式規格 | spec-driven-development | 將發現的限制和決定轉換為 PRD/規格。 |
| 工作太大，無法直接執行 | planning-and-task-breakdown 或 writing-plans | 將對齊的規格分解為有序、可驗證的部分。 |
| 介面邊界不明確 | api-and-interface-design 或 design-an-interface | 決定 API、模組或型別合約。 |
| 程式碼庫形狀是不確定因素 | codebase-design 或 improve-codebase-architecture | 找到正確的模組邊界、抽象或重構方向。 |
| UI 行為或視覺品質不確定 | frontend-ui-engineering | 將選定的原型或偏好轉換為生產級 UI 工作。 |
| 存在錯誤但原因不明確 | systematic-debugging 或 diagnosing-bugs | 重現、隔離、假設、檢測並修復。 |
| 實作跨越多個獨立任務 | subagent-driven-development 或 dispatching-parallel-agents | 僅在任務不共享狀態或順序依賴時拆分工作。 |
| 工作看似完成 | verification-before-completion、requesting-code-review 或 code-review | 在聲明完成或合併之前，驗證證據，然後進行審查。 |
在交接之前，總結：
- 現在已知什麼。
- 仍然未知什麼。
- 哪個決定會改變實作。
- 哪個工件應該向前傳遞：原型、規格、計劃、實作筆記或驗收報告。
各階段的技術
每項技術都有一個觸發器和一個準備好的提示範本。請調整括號中的部分。
探索（找出未知數）
1. 盲點掃描 — 在不熟悉的區域中的第一步。
我正在添加 [X]，但我幾乎不熟悉此程式碼庫中的 [Y] 模組。做一次盲點掃描——找出我的「未知未知」並解釋它們，這樣我才能為你寫一個更好的提示。
2. 原型設計 — 當無法描述時，就展示它。使用假資料，無需後端。
在觸碰真實應用程式之前，製作一個 HTML 檔案，用假資料模擬 [該介面]。給我 4 種完全不同的設計方向，這樣我就能看出哪個感覺是對的。
3. 面試使用者 — 擠出剩餘的模糊點。
一次問我一個問題。針對模糊的領域，並優先考慮那些答案會改變架構的問題。
計劃（對齊意圖）
4. 展示參考 — 最好的參考是原始碼，而不是螢幕截圖。
[路徑 / 函式庫] 實作了我想要的 [行為]。閱讀它，然後在 [我們的技術棧] 中重新實作相同的語義。
5. 起草計劃 — 首先浮現最可能改變的決定。
撰寫一個 HTML 實作計劃，但將我最可能調整的決定放在最上面：資料模型變更、新的型別介面、任何使用者可見的內容。將機械性的重構放在最後——這些我相信你。
實作（捕捉在工作中出現的未知數）
6. 邊做邊記 — 開始一個新的會話，輸入規格/原型，然後：
維護一個 implementation-notes.md。如果邊緣情況迫使你偏離計劃，選擇保守選項，將其記錄在「偏離」章節下，然後繼續。
交付（與他人對齊，驗證你的理解）
7. 交接說明
將原型、規格和實作筆記打包成一個文件，我可以將其放入聊天中以獲得買入。在頂部放置一個示範 GIF。
8. 驗收測驗 — 作者的嚴格規則：通過後才能合併。
我想確定我完全理解了這項變更。製作一個 HTML 報告，包含變更的上下文、直覺以及已完成的工作——然後在底部加上一個我必須通過的測驗。
操作規則
- 每當你正要猜測使用者的意圖時，停下來並應用匹配的技術。
- 串聯工件：原型 → 規格 → 實作筆記 → 驗收報告；每個都是下一個的輸入，因此新的會話不會失去上下文。
- 對於小型任務，
盲點掃描 + 起草計劃 + 驗收測驗已經捕捉了大部分價值。不要過度執行。