四。這大致是一個構建首次通過自身驗證、產出真正可運作成果的時刻——一個能用的頁面、一個能用的端點、一個能讓人成功登入的登入流程。十一，是使用者宣告完成並部署時，構建累積的提示數中位數。百分之六十八，是在那第一個可運作版本之後發出的所有提示中，完全沒有改變使用者能察覺的底層邏輯的比例。三十，則是多數人默默停手的地方，不是因為產品已經完成，而是因為他們已經想不出還有什麼好改的。
這四個數字一次又一次描繪出同一種樣貌：構建很快就具備功能，然後把剩下的大部分生命，花在被討論上，而不是被重建上。
這道牆出現的位置，並不在你預期的地方
如果在我開始留意這件事之前你問我，建構者通常卡在哪裡，我會猜是整合——金流服務商、驗證回呼、需要驗證發送者 ID 的簡訊 API。這些確實是真實的摩擦點，但提示數暴增的地方並不在這裡。它們通常只多花一兩輪提示就能解決。
那道牆出現得更晚，在東西已經能用之後。一個構建第一次乾淨通過驗證——頁面正常渲染、核心流程從頭到尾都能跑、沒有任何錯誤——照理說應該可以停手了，但提示還是繼續送進來。「把標題放大一點。」「換個不同的強調色試試。」「按鈕可以再圓一點嗎。」「其實還是改回第一個版本吧。」這些沒有一個碰到資料模型、路由或權限檢查。全都只是表面功夫。
為什麼「完成」不覺得是個停下來的節點
部分原因純粹是迭代這件事從內部感受起來就是如此。當構建壞掉時，你很清楚該要求什麼——修正錯誤、補上缺少的欄位、把沒連上的東西接起來。而當它能運作時，目標就消失了。沒有錯誤訊息會告訴你這個藍色調錯了。你現在做的是沒有客觀依據的品味判斷，而品味判斷不像錯誤那樣有終點，可以無止盡地反覆修改。
另一部分原因是，下提示既便宜又即時，所以「再試一次看看」的成本在當下感覺趨近於零，即使累積起來並非如此。十幾次外觀微調，每次只花幾分鐘，加起來就是真實的一整個下午，但這十幾次裡沒有任何一次感覺貴到需要被省略。
後期的提示實際上改變了什麼
| 提示範圍 | 典型目標 | 有功能差異嗎？ |
|---|---|---|
| 1–4 | 核心頁面、資料模型、主要流程 | 有——這是產品被真正建構出來的階段 |
| 5–7 | 邊緣情況、錯誤狀態、缺漏欄位 | 通常有——這些是在實際使用中發現的真實缺口 |
| 8–15 | 版面、文案、顏色、間距、語氣 | 很少 |
| 16+ | 反覆推翻或重新嘗試先前的視覺選擇 | 幾乎從不 |
第三排才是真正值得深思的。並不是說外觀的打磨是浪費——一個看起來平凡的成品，表現一定不如經過精心設計的成品，設計這一步確實重要。問題在於，把外觀調對，很少需要八到十五次獨立的提示，而之所以要花這麼多次，通常是因為猶豫不決，而不是真正的迭代。你在第十一次提示後並沒有收斂到更好的答案；你只是在第九次提示前就已經產生的兩個答案之間來回擺盪。
我看過有人花四十分鐘，把一個行動呼籲按鈕在登陸頁面上的三個位置之間搬來搬去，到了第十四次提示才決定第一個位置最好，然後要求建構代理把它放回去。建構代理在這些回合中沒有做錯任何事。這個按鈕本來就不需要十四種意見。
二十次和三十次提示之間的落差究竟說明了什麼
最讓我意外的是這一點：大約在第十一次提示就停下的成品，和跑超過三十次提示的成品，最後品質上並沒有明顯差異。我原本以為多迭代必定帶來更精緻的成果——結果大多沒有找到這種回報。我反而發現，較早停下的建構者，往往一開始就在提示本身中一次做好了品味上的決定（例如「乾淨、極簡、單一強調色、不用素材庫照片」），而不是事後透過二十輪的試誤來摸索出自己的品味。
跑得最久的建構案並不是野心更大，而是原始提示留下最多未決定事項的那些——沒有定調、沒有參考範例、沒有說明目標受眾——於是每個空缺都得靠一次次小提示慢慢補上，而不是在第一次執行前就用文字一次講清楚。
實務上的啟示
如果你在第四、五次提示就跑通了，那不是一個檢查點——那代表真正的工作大多已經完成了。剩下的事情雖然真實存在，但都很小：檢查沒人想到要描述的邊緣情況、確認文案是否合理，並在視覺調性上刻意做一次修改，而不是十幾次摸索式的嘗試。如果你發現自己在第二十次提示還在微調邊角圓弧半徑，那通常不是這個成品還沒完成的訊號，而是說明早該在最初的提示裡把想要的東西講清楚——而修正應該放進下一個建構案的開場訊息裡，而不是塞進這個案子的第四十次提示。
