有一天我在筆記裡記下這句話：「當你有很多想法時，又知道這些 AI 都做得到時，才發現你才是那個卡住 pipeline 的瓶頸，你是小丑。」這篇是後來把這句話拿出來追問的結果：如果真人的我真是瓶頸，究竟是卡在哪一段？
我原本以為
慢慢的從下面的想法轉變
- 我是卡住 pipeline 的瓶頸，我是小丑。（發現許多是卡在來來回回）
- 希望自己能表達得更明確。（我需要看到才能說明，我腦中有時候沒有畫面）
- 「看到才知道」是不適合的。
- 一次用 issue 把功能和畫面完善，再請 Claude 一次做完。
審閱段
不是慢，是卡在需要我放行的那一段
卡住的是需要我放行的那一段。
審閱有兩種：
- 「功能對不對」，可以交給證據
- 「功能是不是我要的」，只能由我判斷。
而第二點是我最容易遇到的瓶頸，不論是 UI/功能，我時常都要看到開發完成後的實體，才有辦法審閱，提出我的想法。
所以這裡講的範圍，是 llm-wiki vault 和 side project 裡需要我放行的設計與功能變更；「有沒有壞掉」可以交給自動驗證，不在這個範圍內。這和 從執行者到選擇者 是同一個母題：選擇的人變成瓶頸。這次是把瓶頸具體定位到審閱段。
意圖經過實體才變成語言
事後說得出具體，事前只有抽象
我原本希望自己能表達得更明確，但第一時間描述需求時，可能只會說幫我加個分類，但沒有特別的想法，導致我看到實體之後，我知道哪裡怪、可以改什麼。
所以 mock 不只是拿來審閱的東西，它是把意圖翻成語言的中介，這件事整理成一個概念：意圖經過實體才變成語言。整個過程大概是這樣：
- 腦中有一個意圖，先講出第一個描述
- 照描述做出實體：一張 mock，或一個功能描述的 flowchart
- 看到之後有反應：如果是發現漏講了條件，就補上條件、回到第 1 步重來；如果是要接受一個妥協，接受了就定案
第一版的實體會錨定後面的方向，所以起點的描述影響最大。事後說得出原因、事先說不出，那要練的就是第一個描述的轉譯。
補條件輪與說服輪
條件可以事先講，解法和妥協要看到才接受
看到 mock 或做好的功能之後，每一次「再改一下」，都可以歸進兩種之一：補條件輪與說服輪。
| 補條件輪 | 說服輪 | |
|---|---|---|
| 發生原因 | 第一個描述漏講了條件 | 要接受一個妥協，但還沒親眼看到不妥協的代價 |
| 能不能事先省 | 可以，第一個描述講出來就少一輪 | 不行，寫規格時不會發生 |
拿來拆的例子是 llm-wiki 系列頁的分組（#89）。這張 issue 有寫規格、沒有 mock，做完之後我才在 #102 提「選取大一點、不要跳轉改成切換顯示」，接著又改了好幾版，前後五版，過程寫在 llm-wiki 系列按功能分組。
- 補條件輪：五版裡，「一致」這一個條件就否決了三版。第一個描述就講出來的話，可以少兩輪。
- 說服輪：分組選單最後用英文短名（Architecture、Routine 這種）。沒有親眼看到中文名折行之前，我不會接受英文短名。
拆完之後，「看到才知道不適合」修正成：條件可以事先講，解法和妥協要看到才接受。
mock 先行
issue 裡先看 mock、選定再做
我原本想的是用 issue 一次把功能和畫面完善，再請 Claude 一次做完。但說服輪在寫規格時不會發生，規格寫得再完整，也逼不出「看到才接受」的那一輪。
對照兩張 issue：
- #89 沒有 mock：反悔全部發生在實作之後，就是上面的五版。
- #116 發文熱度圖有 mockup：第二輪、第三輪的反悔（第二輪改了深淺的分級，第三輪拿掉圖例和說明文字），都在 issue 裡用改圖完成。
mock 先行，把反悔搬到實作之前。所以修正後的做法是：在 issue 裡先看 mock，選定之後再做，放行點只留兩個。這也是這個 repo 現在 issue 流程的樣子：作者審兩次，一次審 issue（這是不是要做的東西，含 mock），一次審 PR（是不是照核准的做了、有沒有證據）。
寫這頁的時候，有 11 張已經核准（approved）的 issue 還沒做。我的判斷是卡在派工：還沒排時間叫 Claude 做，而派工的機制已經在做。後來在 10/19～10/20，一個 Claude session 把這 11 張拆成 worktree session、一次三個派出去，到 10/20 這 11 張都發了 PR，也都合併了，這段另外寫在 AI 補完 issue，我只審兩次。
結論
瓶頸的確是我，但將來來回回的修改，拉到開工前，應該可有效降低。
- 文件化與圖像化需求
- 第一關在 issues 確認 spec，最後驗證則是 PR，要求 claude 提供佐證