最小可驗證增量，為什麼比一次改完整站更可靠

「把整站整理好」很難交付。這句話可能同時包括配色、內容、元件、路由與互動；只要其中一個改動不符合預期，連回頭找原因都得先問，這次究竟一起改了什麼。

我會把這類工作切成能獨立檢查的增量。但小不等於只改一個檔案，也不等於先交一個沒有接到頁面的空殼。這一輪需要有完整用途、能辨認的邊界，以及真的能檢查的結果。

本站的 Button 基礎導入和英日文章補譯，是兩種不同的增量：前者先確認新元件能否適應既有網站，後者則讓選定文章從原文一路走到可讀的多語路由。它們都沒有把「全部做完」當成唯一的完成單位。

最小的單位應該是一個結果，而不是一個檔案

假設要讓讀者能在文章頁切換英文，完成條件至少包括譯文、同篇身份、有效路由，以及能連到該版本的入口。只建立一個英文檔案，若文章還是草稿、連結不存在，對公開頁面的讀者來說，這個用途還沒有成立。

這是說明用的需求例子，不是某次翻譯事故。它提醒我，拆任務不能只用檔案數量衡量。

相反地，一個結果也可能碰到好幾個地方。導入 Button 會涉及元件、class 合併、tokens 與依賴；完成一批翻譯可能要新增語言檔案、更新追蹤文件，並重新建置相關列表。檔案多，不一定表示範圍失控；每個改動都能回答同一個用途，才是需要保留的條件。

我通常先寫兩句話：這輪要讓誰完成什麼，以及哪些東西不跟著改。若這兩句還寫不清楚，就不急著把任務拆成程式步驟。

Button 試接先回答一個相容性問題

本站加入 bejamas/ui 時，先限制在一個 Button，沒有因為元件庫也提供其他控制，就把網站全部換成它的示範風格。

那一輪的問題是：元件怎麼進入專案，需要哪些依賴，能不能接到既有色彩，以及連結用途是否真的輸出 anchor。這些都能從實際變更和生成的 HTML 追查。

當時既有頁面還沒有使用新 Button，所以整站建置成功，並不能證明它已經被渲染。我們另外用隔離樣板引用同一份元件與 CSS，檢查不同尺寸、變體、type、停用狀態、連結和 class 合併。

這個增量雖然沒有把正式頁面全部替換，仍有完整結果：它完成的是基礎導入相容性，而不是整站換用元件。後續要進正式使用點，或加入需要焦點管理的互動控制，仍是另一輪工作。

Button 導入紀錄保留了當時的條件，包括依賴恢復的限制。不能拿那次樣板通過，替後來所有元件更新背書。

補譯的增量，要從原文走到網站輸出

本站後續補英日版本時，先選定有限的文章範圍，不把所有待補譯題目都視為當輪工作。

每篇各自保留同篇 stableId，但標題、摘要和正文要依語言自然表達；版本日期記錄該譯文的完成與來源公開時間，不複製繁中歷史日期。若原稿曾寫「英文列表尚無文章」，譯文需要交代那是原稿的歷史情境，不能把已經有文章的狀態說成仍然空白。

這裡的邊界同時保護兩件事：新版本要完整，站主已確認的繁中原文則不能為了翻譯順手重寫。既有補譯紀錄使用逐檔雜湊核對原文未變；這能檢查檔案內容是否保持一致，不能代替譯文語意校對。

內容完成後還要走到網站：公開集合是否納入該版本，文章頁是否生成，語言連結是否真能互相抵達，列表與 sitemap 是否一致。只寫了正文，還不能把這些接入結果一起稱為完成。

與 Button 不同，這個增量的交付目標就是正式來源裡的完整語言版本，因此不能停在一個未通過檢查的檔案。至於正式主機是否更新，仍是部署的另一條邊界。

先記下不應該改的東西

做一項修改時，我會把保護範圍寫得和新增範圍一樣具體。下面是工作格式示例，不是所有任務都必須照抄的規格。

問題	Button 試接的邊界	選定文章補譯的邊界
這輪增加什麼	一個能受測的基礎元件	指定原文的完整語言版本
哪些保持不變	既有資訊架構與整站設計	已確認繁中正文與發布欄位
從哪裡判斷結果	元件樣板的實際 HTML 與相關檢查	譯文回讀、正式頁面、語言入口與內容輸出
不能順便宣稱什麼	整套互動元件已驗收	外部母語編輯認證或正式主機已部署

保護條件如果只寫「不要亂改」，很難檢查。對原文，可以核對位元組是否不變；對元件導入，可以審查全域 CSS、依賴與既有使用點。保護的方法依對象不同，不必硬套同一種工具。

出現旁支問題時，先判斷它是否阻止這輪用途

範圍有限，不代表看到任何問題都不處理。

如果新增的合法內容讓既有輸出檢查誤判，就要先區分：文章是否真的違反契約，還是驗證器沒有涵蓋這種有效資料。不能為了讓工具變綠而刪掉合法內容；若需要修驗證器，也應保留原有保護、補上可重現的案例，再重新檢查。

這是處理旁支問題的判斷方式，不表示每輪寫文章都要改程式。若發現的是不影響本輪用途的版面偏好，或另一個元件的重構機會，就另外記錄，不擴成整站整理。

把工作切小，最有用的地方是讓這個決定有依據：問題是否使目前承諾的結果不成立？如果是，就處理到能成立；如果不是，另列範圍。不能用「最小修改」掩蓋必要修正，也不能用「順便改善」擴大授權。

同一輪的內容與檢查要一起收尾

一次驗證通過後又改了正文、metadata 或查詢規則，前一次結果就不能直接當成最後版本的證據。交付時需要知道檢查對應哪一份內容，不能把不同階段的成功訊息拼在一起。

我會把交付說明分成實際增加的結果、完成的檢查，以及仍未完成或需要站主判斷的部分。範圍外的事情不是偷偷省略，而是明確留下界線。

例如一批英日譯文可寫成：「指定版本已校對並進入本機正式輸出，原文未改；沒有部署，手機閱讀外觀仍由站主確認。」這是交付格式示例，不是本文替任何一批新譯文宣告測試通過。

這也意味著，任務清單全部打勾不一定等於交付成立。若清單漏了實際路由、主要使用點或必要授權，就應修正完成條件，而不是用清單替結果背書。

哪些工作不能靠拆小來迴避

資料遷移、權限規則或跨層契約，有時必須一起成立，不能為了少改幾個檔案，留下新舊規則同時作用的過渡狀態。本文沒有用本站的靜態內容經驗，證明這些系統也能照同一方式拆分。

較合適的做法是先找出不可分開的契約，再將其餘工作切小。即使修改範圍較大，仍要有對應的驗證與退回條件；若無法安全交付局部版本，就不要把半套結果當成已完成增量。

紀錄範圍

本文以本站既有 Button 基礎導入與多批文章補譯紀錄，整理修改範圍和完成條件的判斷。表格、假設需求及交付引文是方法示例；沒有新增工時、錯誤率、效能或協作效率的量測，也不宣稱小批次一定比整批修改更省時間。

我的取捨是讓每輪工作都能回到一個具體結果，知道哪些內容改了、哪些保持不變，以及下一步是否需要新的授權。拆小的用途是方便理解與核對，不是讓交付停在半路。