品質是唯一的變數

專案經理的工作是平衡四個變數：範圍、時間、成本與品質。經典的限制三角形告訴我們，你最多只能同時優化其中兩個。想要又快又便宜？品質就會打折。想要又好又快？成本就會攀升。在資源受限的環境中，這個三角形確實是實用的思維模型。

但我並不在資源受限的環境中運作。我使用的 AI 代理能以推論速度產出程式碼，上下文視窗容納得下整個程式庫，而一次工作階段的成本以美元計，而非薪資。限制三角形就此崩解。

當代理能在數分鐘內實作一項功能，問題不再是「我們負擔得起把事情做對嗎？」而是「我們為什麼要把事情做錯？」

逐一排除

把時間從決策中移除。不問「這要花多久？」而問「完成時它應該是什麼樣子？」前者為交付速度而優化，後者為成品本身而優化。

把成本從決策中移除。一次產出正確、乾淨、經過完整測試的程式碼的工作階段，與一次產出權宜、混亂、未經測試的程式碼的工作階段，花費相同。API按 token 計費，不因品質而異。把事情做對的邊際成本是零。

把心力從決策中移除。代理不會疲倦。第一百個函式與第一個函式以同等能力寫就。不存在人類的疲勞曲線來合理化工作階段後期的偷工減料。產出品質取決於指令品質與上下文品質，而非已經過了多少小時。

排除時間、成本與心力之後，剩下什麼？品質。品質是唯一剩下的變數。

實務上的意義

當品質是唯一的變數，許多常見的工程決策變得不言自明：

寫測試。 「要不要為這個函式寫測試」的辯論消失了。代理幾秒鐘就能寫完。邊際成本為零，邊際效益是永久的驗證。不寫測試，等於在毫無節省的情況下選擇接受較低的品質。

修復鄰近的程式碼。 修一個 bug 時，周圍的程式碼往往有相關問題：命名不一致、缺少錯誤處理、過時的模式。在時間受限的環境中，你修了 bug 就把鄰近的程式碼留給「以後」。當品質是唯一的變數，你應該修好所有碰到的東西。以後永遠不會來，而現在是免費的。

使用正確的抽象。 快速的權宜之計解決眼前的問題，正確的抽象解決的是一整類問題。在時間受限的環境中，權宜之計今天就能上線，而抽象永遠上不了線。當代理在同一個工作階段內就能實作任何一種方案，權宜之計便不再有優勢。選擇抽象。

先讀再寫。 在時間受限的環境中，工程師有時會在尚未完整閱讀程式碼的情況下進行修改，僅依賴局部理解。當代理能讀完整個檔案、理解其中的模式、在完整上下文下進行修改，就沒有理由在只有片面理解的情況下動手。讀完整個檔案，理解模式，然後再寫。

不要延後。 TODO、FIXME、HACK 是品質延後的標記。在時間受限的環境中，延後是合理的：等有空再修。當品質是唯一的變數，延後就失去了道理。代理就在這裡，上下文已經載入，現在修和以後修成本一樣。現在就做。

次郎原則

小野二郎做壽司超過七十年。他的餐廳有米其林三星，只有十個座位。菜單和手法從未改變，但他每天都在精煉這套手法，持續了七十年。

當有人問二郎一貫壽司是否夠好，答案從不取決於餐廳有多忙、有多少客人在等候、魚有多貴。答案只取決於這貫壽司是否達到他的標準。標準是絕對的，外在情境無關緊要。

這就是應用於工程的原則：標準是程式碼本身，不是衝刺週期。一個函式要麼正確、乾淨、經過完整測試，要麼就不是。截止日期不會改變這個判斷。預算不會改變這個判斷。唯一的問題是：成品是否達到標準。

AI 代理讓這個原則首次在軟體工程中變得可行。在代理出現之前，次郎原則只是一種理想。人力追求完美的成本太高，每一次偷工減料都有合理的理由：我們週四要上線、預算用完了、工程師已經精疲力竭。有了代理，做對的成本與做錯的成本相同。那些偷工減料失去了存在的理由。

驕傲檢查

每次非瑣碎的變更之後，我會問五個問題：

一位資深工程師會尊重這段程式碼嗎？
程式碼是否不言自明？
邊界情況是否已處理？
這是否達到了恰當的簡潔程度？
我是否讓程式庫比我接手時更好了？

這些問題不是在問正確性——證據關卡負責正確性。驕傲檢查負責的是工藝。正確但沒人願意維護的程式碼，過不了第 1 題。聰明但需要註解才能理解的程式碼，過不了第 2 題。只處理了正常路徑卻忽略錯誤路徑的程式碼，過不了第 3 題。

第 4 題最難。「恰當的簡潔程度」不等於「盡可能簡單」。一行的權宜之計比正式的抽象更簡單，但如果問題會反覆出現，那這種簡單就是錯誤的層次。恰當的簡潔，是用最少的複雜度解決實際問題，同時不去解決假想的未來問題。

第 5 題關乎軌跡。每一次工作階段都應該讓程式庫處於比開始時更好的狀態。不只是被修改的特定檔案，還包括周圍的上下文：更新測試、清理匯入、修正註解、移除無用程式碼。標準不是「我完成任務了嗎？」而是「這個專案因為我的存在而變得更好了嗎？」

反論

顯而易見的反論是：速度很重要，交付很重要。一個完美但永遠無法上線的程式庫，不如一個混亂但解決了真實問題的程式庫。

在品質與速度負相關的世界裡，這個反論是正確的。但在 AI 代理以相同速度產出高品質與低品質成果的世界裡，這種相關性被打破了。品質與速度成為獨立變數，魚與熊掌可以兼得。

剩下的取捨是注意力，而非時間。讀完整個檔案需要注意力，執行證據關卡需要注意力，套用驕傲檢查需要注意力。代理的時間是免費的，但你的注意力是有限的。

品質是唯一的變數，而注意力是品質的限制條件。解決之道不是降低標準，而是建構基礎設施來降低維持標準所需的注意力成本：自動捕捉常見錯誤的 hook、將品質工作流程編碼的 skill，以及跨工作階段攜帶上下文的記憶系統，讓你不必重複推導已做過的決策。

這就是複合上下文為品質服務的方式。每一層基礎設施都降低了下一次工作階段的注意力成本。經過足夠多的工作階段，標準就能自我維持。

常見問題

這適用於所有軟體專案嗎？

這個原則最直接適用於由 AI 代理負責實作的專案。在完全由人力實作的專案中，時間與成本仍然是真實的限制條件。隨著代理能力提升、人力實作時間減少，這個原則的適用範圍也會隨之擴大。

原型開發呢？

原型本質上就是可拋棄的。原型的品質標準是「它是否回答了我們正在探究的問題？」如果答案為是，無論程式碼品質如何，原型都已完成使命。這個原則適用於將會留存的程式碼，而非即將被丟棄的程式碼。

這不就是完美主義嗎？

完美主義是一個無限的標準，沒有任何東西能達到。品質是一個有限的標準，由證據關卡定義：正確、乾淨、經過測試、無回歸、解決了實際問題。達到標準是可實現的，超越標準則不必要。標準很高，但並非無限。

如何處理技術債？

不要製造它。技術債就是延後的品質。當品質是唯一的變數，延後就失去了正當性。代理現在就可以使用，現在修和以後修成本一樣。代理產出的技術債不存在利率問題，因為根本沒有理由去承擔它。

參考資料

此處描述的哲學源自日本職人（Shokunin）工藝傳統，以及 AI 工程系列中記錄的生產實務經驗。具體引用的實作包括：

證據關卡：完成驗證的六項準則
驕傲檢查：工藝評估的五個問題
Hook 系統：84 個 hook 作為品質基礎設施（Every Hook Is a Scar）
複合上下文：降低品質注意力成本的基礎設施（Compound Context）