AI程式碼提速後，驗證基礎設施究竟該證明什麼

Blacksmith於2026年10月21日宣布C輪融資，使持續整合（CI）基礎設施再次受到關注。CI負責在程式碼變更合併之前完成建置和檢查。藉這個機會，更值得追問的是：團隊購買更快的驗證能力時，究竟買到了什麼？公司公告

對於使用程式設計代理的團隊，一個可能出現的限制是，寫出修補程式所需的時間減少了，判斷它是否值得成為產品一部分的時間卻沒有同步下降。這是本文的分析命題，並不意味所有團隊都已遇到同一種瓶頸。測試快速且可靠的小型應用，可能仍受產品決策限制；大型程式碼庫即使機器充足，也可能缺少真正理解故障模式的人。

這裡需要區分兩項成本：等待證據的成本，以及判斷證據究竟能證明多少的成本。增加算力可以降低前者，卻未必改善後者。在某些情況下，它甚至只是讓一個容易誤導人的結果更快出現。

更快回答了一個不完整的問題

設想一家零售商正在修改折扣計算方式。這是一個假設案例：代理改寫了定價函式，並新增測試，證明符合條件的購物籃能獲得優惠。建置通過了。但退款、匯率轉換，以及兩種促銷同時生效時，結果是否仍符合業務要求？如果測試規格沒有表達這些行為，更頻繁地執行原有測試，並不會自動補上缺少的規則。

這不是否定生成式測試的價值。代理可以協助列舉邊界情形，也能把一次已知故障變成迴歸測試。真正需要注意的是獨立性：如果實作程式碼與預期輸出都來自同一個錯誤理解，兩者彼此一致，只能提供有限證據。更有效的挑戰需要來自其他依據，例如必須保持的業務約束、現有客戶合約，或者由業務負責人審閱過的反例。

Chenglin Li等人的論文於2026年8月6日修訂，報告稱更強的測試揭示了被錯誤接受的基準修補。實驗針對程式碼庫修復基準，而非正式環境事故率。研究論文

實驗場景與實際業務的差異，限制了可以推導出的結論。這項研究不能說明某家公司的發布會以多高頻率失敗。對營運團隊而言，更穩妥的推論是：測試通過，只能為它能夠區分的行為提供證據，無法認證從未被表達出來的需求。即使執行測試越來越便宜，設計測試依然是一項持續的工程責任。

執行器結束後，佇列還在繼續

再看另一個假設團隊。它的測試已經比較充分地涵蓋變更，但每份執行結果仍需有人解釋。某些失敗來自修補程式本身，某些來自暫時不可用的依賴，還有一些來自過期的測試資料。候選變更數量翻倍，可以增加診斷工作，卻不一定增加有能力處理這些問題的人。

這時，畫面上可見的CI排隊時間可能縮短，等待解釋的結果卻越積越多。只測量工作開始到完成的時間，會錯過瓶頸的轉移。更有意義的觀察範圍，應持續到有人能夠據此作出有依據的合併決定，並把重跑和排查納入其中。否則，供應商可能完全履行了執行速度承諾，團隊的實際交付卻沒有明顯改善。

Martin Fowler在2011年4月14日的文章中討論了間歇性失敗的測試如何削弱團隊對測試套件的信任。這是長期工程經驗，而非對當下AI工具的新測量。原文

從經濟角度看，不可靠的訊號會消耗稀缺的注意力。審閱者反覆遇到無法解釋的失敗，可能逐漸形成先重跑、後調查的習慣。代價不只是浪費機器分鐘數，也包括失去區分「變更有問題」與「測試有問題」的可靠依據。增加測試量要真正有用，組織需要維持這種區分，並明確由誰修復已經退化的檢查。

吞吐量能告訴採購者什麼

Google於2025年9月23日發布的DORA研究介紹，將AI採用與更高的軟體交付吞吐量聯繫起來，同時指出驗證仍有挑戰。這是歷史調查證據，不能當作某家供應商效果的受控估計。研究介紹

因此，也不應反過來否定更快基礎設施的價值。縮短回饋週期，可以讓開發者在尚未離開變更思路時獲得結果；充足的測試容量，也能讓原本過於昂貴的檢查變得可行。關鍵在於識別它緩解了哪個限制。如果可靠的檢查正在等待資源，更快執行有直接價值；如果問題仍是「正確行為應該是什麼」，速度的即時作用就比較有限。

採購比較需要相對穩定的工作單位。每分鐘CI費用容易觀察，卻可能鼓勵不完整的比較。更快的機器每分鐘更貴，跑完同一套檢查的總成本卻可能更低；更便宜的測試套件，也可能只是省略了昂貴檢查；每次成功執行的低價格，則可能掩蓋此前反覆失敗的成本。內部評估可以嘗試追蹤一項可比變更，直到它獲得經過審閱的發布決定，同時保留檢查範圍。

這個單位也不完美。變更的風險各不相同，有些事故會在發布很久後才出現。介面裝飾修改，不適合直接與重寫客戶餘額的資料遷移比較。區分變更類別、記錄例外情況，雖然不如一個統一的生產力數字簡潔，卻能讓所謂改善更容易解釋。

不必把測試預算無限擴大

一種可能的營運設計，是讓低成本檢查快速回答較窄的問題，把涵蓋更廣的檢查與人工注意力留給影響可能更大的變更。這是本文提出的營運假設，不是普遍適用的固定流程。涉及安全關鍵元件或陌生依賴時，合理的平衡可能不同。重要的是，更快的路徑不能悄悄移除原本支持批准決定的證據。

過度謹慎同樣有成本。如果每次無害修改都要經歷相同的昂貴審查，團隊會失去自動化收益，也可能為了減少手續而把不相關的變更打包提交。目標並非把測試數量推到最大，而是把剩餘不確定性說清楚，使組織能夠判斷這項變更、它的影響範圍及恢復路徑是否可以接受。

因此，圍繞CI的商業機會比出售處理器更廣，但也不能無限延伸為隨時供應「可信度」的承諾。供應商可以降低取得證據的成本，團隊仍須定義值得保護的行為、維護檢查並解釋結果。程式碼生成加速之後，這種責任分工會更清楚地體現在交付一項使用者真正能夠依賴的變更所需的成本中。