昨天講的是發現：那些問題單的數量，跟真實的問題數量沒有關係。

今天講另一半：那些已經被發現、也已經被修好的問題，後來留下了什麼。

答案是：幾乎什麼都沒有。

兩類問題，跨了十輪

先把數字攤開。那個案子裡有兩類問題反覆出現：

日期元件／民國年       橫跨 4 輪，20 張單
表單驗證／必填         橫跨 6 輪，27 張單
                      合計 47 張，全部是同一批原因的分身

而每一張都被好好地處理了——立單、指派、修復、驗證、關單。流程上一步都沒有少。

那為什麼還會有第二輪、第三輪、第四輪？

因為那 47 次修復，一次都沒有變成「下一次不會再發生」的東西。

一個 bug 的生命週期，結束在關單

每個問題單的生命是這樣的：

立單  →  指派  →  修好  →  驗證  →  關單  →  結束

注意最後那一格。結束。

那個 bug 教會團隊的東西——「原來原生日期元件在民國年格式下會被遮住」——隨著關單一起消失了。它沒有變成一條規則、沒有變成一個檢查、沒有變成範例裡的一行註解。

所以下一個頁面開發的時候，那個知識不在任何地方。它只在修過那一次的那個人腦子裡，而他不會出現在下一次的每一個決定裡。

於是同類問題在下一輪以變形再出現，然後被當成一個新問題重新走一遍流程。

修了 47 次，等於重新學了 47 次。

而 AI 讓這件事更嚴重，因為它連那個腦子都沒有

一個修過三次同樣問題的工程師，第四次會有感覺——「這個我好像看過」。那個感覺不可靠、不完整，但它至少存在。所以，要想辦法讓 AI 可以自我進化。

AI 沒有那個感覺。

它每一次收到的都是一張全新的單，而它處理得又快又乾淨。它不會累、不會煩、也不會在第四次的時候停下來說「等等，這個是不是跟上次那個一樣」。

舉一反三，還是一個口令一個動作？

這裡有一個更根本的問題，值得停下來想：AI 修第三張單的時候，難道看不出來它跟第一張、第二張是同一件事嗎？ 看得出來。你把三張單一起貼給它、問它「這幾個有沒有關係」，它會答得很好。

但它沒有被問。 它收到的指令是「一次處理五個」，範圍就是那五張單。

所以人跟 AI 的協作，其實一直在兩種模式之間，而我們當時從頭到尾只用了左邊那種：

看到這裡很容易得出一個結論：應該讓 AI 更主動一點、學會舉一反三。

而這個結論有陷阱。

一個會自己擴大範圍的 AI，跟一個會自己補檢核邏輯、自己挑架構的 AI，是同一個 AI。你在這裡稱讚它主動，就會在 Day 02 那裡罵它多做。那正是第二種失敗（規格沒說，AI 自己補了）的來源。「主動」不是一種可以局部開啟的性格。

所以我認為真正的答案不是把它調得更聰明，而是：

舉一反三要變成一個「被指定的動作」，不是一種「被期待的性格」。

而指定的方式有一個關鍵設計：它的產出是一份清單，不是一批改動。

發散  →  交給 AI：把同類全部找出來（它很擅長，而且不會累）
收斂  →  留給人：決定哪些要一起改、哪些是誤判

這樣你既拿到了舉一反三的好處，又沒有把範圍決定權交出去。

但其實人也在一個口令一個動作

而這件事其實跟 AI 無關。

先前提到：測試按頁面測、單按頁面立、修按單修。整條 Workflow 沒有任何一個環節的職責是「把這次學到的留下來」。

AI 沒有去做那件事，不是因為它不會。是因為那條產線上本來就沒有這道工序。

AI 不會改變你的流程，它會放大你的流程。
原本是一個口令一個動作，現在變成一秒鐘一個動作。

而這正是為什麼「AI 讓我們變快」在這個案子上沒有兌現成「做得更好」：快的是每一次動作，而不是整件事。 同一個原因修 20 次，修得再快也還是 20 次。

後來開始有了名詞 harness engineering 大概就是那種感覺吧

那要怎麼讓一次發現，變成永久的東西

我後來把它整理成三條，而它們要一起用才有意義：

• 立案時就強制選一個原因分類，從預定清單裡選，不是自由填寫。同一個原因第二次被立案，立刻關聯到第一張單。
• 修復 SOP 的最後一步是強制的整庫掃描：把這個 bug 的 pattern 寫成 grep 或 lint 規則，掃過整個 codebase。只在一處出現就加一條 lint 防再犯，在 N 處出現就一次全部修完。
• 這條 SOP 要用機器強制，不是寫在文件裡。 例如在提交前跑一次 pattern 掃描，發現同 pattern 多處存在就擋下來。

三條的順序有意義：第一條讓你看見重複，第二條把一次修復擴大成一批，而第三條讓它留下來。

前兩條沒有第三條，效果會隨著人的記憶衰減；第三條才是把「這次學到的」變成產線的一部分。

而它值多少？如果第一輪當下就做整庫掃描加 lint，那 20 張單裡至少 17 張不會出現。成本差距大概是 1 倍對 1.5 倍，收益差距是 1 個對 17 個。

但要說清楚它解的是哪一半。 它解的是「已經被碰到的那一類，怎麼一次清乾淨、而且不再回來」。

至於「還有哪些沒被碰到」——昨天那個問題——它一個字都沒解。 那需要的不是更好的修復流程，是一份「這一頁應該檢查什麼」的清單。

順帶把那個「後端沒事」的對照再打一次折

前面說「這 18 個幾乎全在前端」。寫到這裡，你覺得後端會沒事嗎?

原本我們說，因為我們加了很多單元測試，差別在「有沒有那層測試」。這句話沒錯，但它不是全部——基本上後端的業務邏輯沒有換。

所以「後端沒事」有三個原因疊在一起：有測試網、沒有人深入測過、以及它本來就沒被大改。我原本只講了第一個；第三個是最大的那個，而我一開始沒有意識到它的份量。

這個對照我仍然相信方向，但強度只剩下：在同一個案子裡，被大改的那一半出了事，沒被大改的那一半沒出事。 那不能證明「測試網有用」，它只能證明——動得越多，越需要一個能判斷對錯的東西。

而這個案子動得最多的那一半，剛好就是「沒有人說得出對長什麼樣」的那一半。

如果 AI 可以那麼快了，不要嘗試一次要他處理掉所有的事情

所以真正的問題不是「修得不夠快」

回到那份回顧。

那份文件做得不錯，它把八十幾個問題歸納成 10 大類原因。但它是一份文件。

它擋不住下一輪，因為：

同一個知識，放在不同的地方，效力差了一個數量級。

而這正是整個系列後面會反覆出現的主題：

寫在文件裡的規則，和機器會擋的規則，是兩種東西。

那 47 次修復留下的東西，如果當初是一條 grep、一條 lint、一個 hook，它就會一直在那裡——不需要有人記得，不需要有人交接，也不需要 AI 有記憶。

小結

• 47 張單全部被好好處理了，流程上一步都沒有少——問題不在執行，在沒有沉澱
• 一個 bug 的生命週期結束在「關單」，那個 bug 教會團隊的東西也跟著結束
• AI 讓這件事更嚴重：一個修過三次的人第四次會有感覺，而 AI 每次都是全新的一張單
• 舉一反三要變成被指定的動作，不是被期待的性格——發散交給 AI，收斂留給人
• 同一個知識，放在文件裡和放在產線上，效力差一個數量級

明天

明天往上游走一段——問題單會這麼多，有一部分在第一個月就決定了：那八十幾個頁面的需求，藏了一些不為人知的秘密。

本系列所有案例均經去識別處理，不指涉任何特定客戶、系統或產業。