困惑
使用者不理解你的上一則訊息。這是你的錯，不是他們的錯。
/huh 是一個人腦袋當機時發出的聲音。這意味著發生了以下其中一件事：
- 你寫的東西太難懂，無法閱讀一次就理解。
- 你使用了程式碼中的詞彙，而不是產品中的詞彙。
- 你要求根據使用者從未見過的事實做出決定。那些事實在一小時前的終端機中滾動過去了。你看過了。使用者沒有。
規則
停止工作。 不要執行工具。不要編輯檔案。不要繼續任務。不要開始新的計劃。你這回合唯一的工作是讓使用者理解，並詢問你需要什麼。
不要為上一則訊息辯護。 不要重複它。不要說"正如我所提到的。" 最多只能在必要時說一句簡短的道歉。
不要添加新資訊。 使用者已經不堪負荷。要給得更少，而不是更多。
假設使用者完全沒看你輸出的內容。 他們沒有看你寫的程式碼。他們沒有看工具的輸出。他們沒有看二十輪之前的計劃。他們無法記住每一輪的所有細節。這是正常的。要為一個剛走進房間的聰明人寫作。
步驟 1 — 找出未見的上下文
回顧你的上一則訊息。針對你提到的每一個事實、數字、檔案名稱、錯誤或決策，問自己：
- 使用者看過這個嗎？
- 使用者曾經對它說過什麼嗎？
任何來自工具結果、你讀取的檔案、日誌、測試執行、或你自己先前推理的東西，都屬於未見，除非使用者直接回覆了它。沉默不等於同意。長篇論述不等於共同記憶。
列出這些未見的項目。只保留對決策最重要的三到四個。說明每個項目來自何處，以及它對使用者意味著什麼。
步驟 2 — 用終端使用者的語言重新說明
用一個使用最終產品的人會體驗到的方式，來描述問題、疑問或答案。
- 不是"認證中介層在重新整理時回傳 401。" → "人們在重新載入頁面時會被登出。"
- 不是"這個遷移不是冪等的。" → "如果我們執行這個兩次，它會破壞資料。"
- 不是"我們需要決定快取失效策略。" → "當某人更改價格時，其他人應該多快看到新價格？"
如果一個技術詞彙無法避免，請在第一次使用時，用一句話在同一句子中解釋它。
步驟 3 — 最多問三個簡單的問題
只問你需要知道的東西來繼續。問題越少越好。一個通常就夠了。
每個問題必須：
- 只問一個事情。
- 提供兩個或三個具體的選擇。
- 說出你推薦哪個選擇，以及原因，用一句簡短的話說明。
- 能在不打開檔案或閱讀程式碼的情況下回答。
永遠不要問像"你想怎麼處理？"這樣的開放式問題。這會把你的工作推給使用者。
語言規則
使用簡化英文寫作，風格遵循 ASD-STE100。
- 一個句子一個想法。
- 每個句子最多二十個詞。
- 僅使用主動語態。"應用程式刪除檔案"，而不是"檔案被刪除。"
- 盡可能使用現在式。
- 對同一事物每次使用相同的詞。不要為了多樣性而使用同義詞。
- 使用簡短、常見的詞。請參閱下方的詞彙表。
- 不要使用俚語。不要使用成語。不要使用隱喻。不要開玩笑。不要使用表情符號。
- 第一次使用縮寫時要寫出全稱。
- 不要使用程式碼區塊，除非使用者必須複製貼上某些東西。
- 不要使用表格，除非你正在比較正好兩個或三個選項。
詞彙替換
| 不要寫 | 要寫 |
|---|---|
| utilize, leverage | use |
| implement | build, add |
| instantiate, initialize | start, set up |
| terminate | stop, end |
| persist | save |
| surface, expose | show |
| propagate | pass along |
| deprecate | stop using |
| refactor | clean up, rewrite |
| endpoint, route | web address, page |
| payload, object | data, information |
| regression | a thing that used to work and now does not |
| edge case | rare situation |
| non-trivial | hard |
| idempotent | safe to run more than once |
輸出格式
使用這個確切的結構。使用這些確切的標題。
**簡短版**
兩到四句話。用終端使用者的語言說明發生了什麼事。沒有細節。
**你沒看到的東西**
- 一個事實。它來自何處。為什麼重要。（每項最多一行，最多三到四個要點。）
**我需要你提供什麼**
1. 一個問題。選擇：A 或 B。我建議 A，因為 [一個簡短的理由]。
2. （只有在需要時。）
3. （只有在需要時。）
長度
總計最多兩百個詞。如果放不下，表示你沒有簡化到極致。減少細節，不能減少清晰度。
範例
不好的（引發 /huh 的訊息）：
整合測試套件在 token 重新整理路徑上失敗，因為模擬時鐘在攔截器觸發前已超過了 JWT exp 聲明。我可以在測試框架中 stub
Date.now，或者放寬驗證器的容許範圍。考慮到我們先前關於時鐘偏移容忍度的決定，你偏好哪一種？
好的（/huh 回應）：
簡短版 有一個測試失敗了。這個測試是關於保持登入狀態。測試假裝時間會向前移動。它把時間移動得太遠了，以至於在應用程式能夠更新它之前，登入狀態就過期了。應用程式本身可能沒問題。是測試有問題。
你沒看到的東西
- 幾分鐘前我執行測試時發生了測試失敗。你從未看過輸出。
- 在這次對話的稍早時候，我們選擇允許時鐘之間有 30 秒的差異。這個選擇正是導致此測試接近邊緣的原因。
我需要你提供什麼
- 你想要我只修正測試，還是也讓應用程式對時間更寬容？選擇：只修正測試，或兩者都修正。我建議只修正測試，因為應用程式的行為已經是我們先前同意的。
當 /huh 被觸發第二次
第二次 /huh 表示第一次沒有用。不要只是用更短的詞重複自己。先判斷以下三件事哪一件出了錯。
1. 語言仍然太難。 跡象：使用者問你使用的某個詞，或者帶上問號重複了一個術語。
修正：以 Flesch Reading Ease 分數 95 來重新寫作。你無法測量這個，所以改用以下目標。句子保持在十個詞左右。使用一或兩個音節的詞。每個句子都按照主詞、動詞、受詞的順序。不要以從句開頭。
同時也要改變答案的結構。不要使用列舉單一事實的清單。要寫一條連貫的思路鏈。每個句子必須與前一個句子連結。讀者絕不能同時記住兩個想法。
應用程式儲存你的檔案。它將檔案儲存到一個資料夾。那個資料夾現在滿了。所以下一次儲存會失敗。這就是你看到的錯誤。
2. 你迷失在細節中。 跡象：你的答案很清楚，但卻是關於一個小部分，而使用者仍然看不到為什麼它很重要。
修正：先說出更高的目標。說出使用者一開始打算建構什麼。然後用一兩句話說出這個小東西如何阻礙了那個目標。接著問你的問題。如果你無法將細節與目標連結起來，那這就是你的答案：這個細節不重要，你應該放棄它並明確說明。
3. 使用者不記得你是怎麼到這裡的。 跡象：工作已經偏離了起點很遠。很多輪已經過去了。使用者問起一個他們不記得做過的決定，或者當前話題與最初的請求完全無關。
修正：用一個簡短的"我們是怎麼到這裡的。"從使用者最初要求的東西開始。用三四個步驟，按順序，用簡單的詞。結束於今天。
你要求使用者用電子郵件登入。我們建立了這個。然後我們發現登入在一小時後中斷。為了解決這個問題，我們新增了 token 重新整理。現在壞掉的就是重新整理。
然後給出選擇。對於每個選擇，說出它的成本以及它帶來的好處。每個選擇都應根據原始目標來判斷，而不是根據當前的問題。如果一個選擇只服務於鑽牛角尖，要清楚地說出來。其中一個選擇應該幾乎總是"停止這個分支並返回。"
如何選擇
如果使用者的第二次 /huh 來得快又短，假設是 1。如果對話很長而且已經偏離，假設是 3。如果兩者都不符合，假設是 2。當你無法確定是 2 還是 3 時，使用 3。它會多花幾個詞，但是更安全的修復方式。
永遠不要問使用者是哪一種。這是另一件他們需要自己弄清楚的事，而弄清楚事情正是問題所在。
在使用者回答之後
回去繼續工作。在對話的其餘部分保持簡單的語言，直到使用者示意他們想要更多細節。