如何確保AI軟體工程品質？

“Agent管理學社區是AI Coding先鋒們密集交流的論壇，在日常交流之外，定期舉辦專項研討會，過去十幾期研討會覆蓋了自動測試保障AI程式碼品質， 硅基碳基混合團隊構建，AI 根因分析，設計文檔驅動開發，端到端商業化等各種前沿話題。”

承蒙馬工發起，十九人線上圓桌研討。與會者來自券商、醫療器械、K12教培、支付寶、開源基礎設施，背景迥異，皆AI編程先行者，只為一探AI程式碼品質之法。

測試：AI Coding的終極質量控制手段

一）概率性是本質，不是缺陷

AI寫程式碼品質不穩定，不是模型還不夠好，也不是Prompt沒調對，是概率採樣的數學必然。大語言模型的每一次輸出都是從概率分佈中採樣，同一段Prompt跑兩次，結果可能不同。

我們遇到了完全相同的症狀：文檔漏字段，程式碼漏功能，該改業務程式碼的改了測試，該改測試的改了Mock，讓它別Mock業務程式碼，它表面答應，轉頭就Mock。

胥克謙是個不懂技術的創始人，現在一個人幹著原來兩百人技術團隊的開發工作量。他給AI寫的規則和配置加起來2.5萬多行，文檔平均3萬字。AI生成後他得開新會話做交叉驗證，不能在原來的上下文裡驗，因為AI會帶著”我已經檢查過了”的偏見跳過問題。十幾輪下來，每一輪都能揪出新的遺漏。

概率性是大語言模型的數學本質，不是工程缺陷。不能消除，只能約束。問題是——什麼樣的約束才有效？

二）確定性約束

1924年5月16日，紐約，西電公司工程部（後來的貝爾實驗室）。物理學家沃爾特·休哈特給上司遞了一份備忘錄，只有三分之一頁紙。上面畫著一張簡單的圖：三條線依次為：上控制限，實際表現，下控制限

西電的工廠當時在生產電話設備，零件要埋入地下，壞了沒法修，必須在出廠前把次品攔住。工廠的做法是：一旦發現某批次不合格率偏高，立刻調整生產流程。

休哈特發現了一件反直覺的事——每次出了次品就去調整流程，品質反而更差了。次品是隨機出現的，跟流程無關。你對著它調流程，把本來沒問題的流程調偏了，下一批又出次品，又調，越調越亂。

他用三分之一頁紙終結了這個死循環。波動分兩種：隨機波動是過程的統計本質，不要管；異常波動有具體原因——機器鬆了，原料換了——必須停機排查。兩條控制線就是區分兩者的邊界：落在限內，隨機波動，不動；超出限外，異常信號，停機找原因。

這就是統計過程控制（SPC）的內核：第一，任何過程都有固有波動，消滅不了；第二，對固有波動做反應叫過度調整（tampering），不是在解決問題，是在製造問題；第三，控制限的作用不是消除波動，是把需要干預的和不需要干預的分開。

一念天地寬，到底什麼算出錯？

百年之後，AI編程遇到了同構的問題。大語言模型的輸出天然有波動——概率採樣的數學本質，你不能讓它每次都寫對，就像你不能讓生產線每個零件都完美。

每次AI寫錯了就去調Prompt、改規則、逐行Review，就是過度調整——在固有波動上疊加人為干擾。

休哈特的答案：不要消除波動，要建確定性的邊界。測試是否通過，API契約是否符合。這些就是控制限——過了就過了，沒過就打回重來。沒有”差不多”。

而一個典型的反例，就是Code Review。一個人看另一個人寫的程式碼，說”我覺得沒問題”。這不是控制，是概率性判斷——邊界模糊，因人而異，因時而異。休哈特之前的工廠幹的就是這個事。

在歐洲做金融系統的馬工說得最直接：AI時代的Code Review已沒什麼意義，人工Review最後什麼也看不出來，只剩”情緒價值”。在他的體系裡，OpenAPI契約是”靈魂”，分層測試從單元測試到端到端測試層層把關，人的主觀判斷已經被確定性約束替代了。

為什麼契約是”靈魂”？因為控制的品質取決於它編碼的規約——測試驗證的是需求，契約定義的是接口，規約不準，測試通過了也不代表正確。

胥克謙七八成精力花在文檔驗證上，而券商行業的L先生，14萬條用例建立在完備的需求文檔之上，李雪涛從土木工程的視角說了同一句話：先有圖紙才能開工。

規約先行，約束才立得住。

確定性約束的效果有多大？做K12教培的老魏，他的團隊1到2千條用例20到30秒跑完，每改一行程式碼都跑全量回歸。Mason在一個團隊項目中20天寫了3.6萬行程式碼，分層測試下整個開發過程幾乎沒有bug。

約束越完備，人越可以放手。

三）約束的獨立性

光有確定性約束就夠了嗎？

全場最大的痛點不是AI寫不好程式碼，是AI寫的測試”太好了”——好到永遠能通過。

負責一個棕地項目的金金對此感受最深。AI被要求寫測試，程式碼依賴資料庫、外部API、其他模塊，正常做法是搭建測試環境跑真實依賴。但AI找到了一條捷徑——把所有依賴都Mock掉。資料庫Mock，外部API Mock。測試通過，覆蓋率100%，但它驗證的是一個幻象。

金金在規則裡明確寫了”禁止對業務程式碼做Mock”，AI照樣會出錯。

這不是AI在作弊。這是概率性系統在被要求”讓測試通過”時找到了阻力最小的路徑。

問題不在約束本身。寫程式碼的AI同時寫測試，它就會把約束悄悄放到最容易通過的位置。約束力完好，獨立性為零。

馬工的做法最有代表性。測試Agent和Coding agent徹底分開，Prompt風格對立，一個追求效率一個追求嚴謹，用文件系統權限做隔離，coding agent物理上無法修改測試程式碼。

L先生更幹脆：開發、測試、運維三個獨立部門，KPI對立，測試打回，開發自己去整改。

部門隔離是組織架構級的獨立性，Agent對抗是技術架構級的獨立性。

至此我們得到：有效約束 = 約束力 × 獨立性。

約束力：用確定性約束取代概率性判斷；獨立性：設定約束的人不能是被約束的人。兩者缺一不可。

四）因地制宜

支付寶agent工程師曉灰讓AI自主運行6到24小時，通過啟發式方法找到解決方案，他不關心AI用什麼方法，只關心最後測試通不通過。

而胥克謙反對現階段全自動，因為文檔一定有遺漏，AI自動確認的東西”不靠譜概率比較大”。

兩種截然不同的做法，一個公式就能解釋：

AI自主度 = f(約束的完備性, 失敗的代價)

約束越完備、失敗後果越可承受，AI越可以放手；約束有漏洞、失敗代價大，人就必須親自去補。不同的輸入，不同的輸出。

集成測試有沒有價值？重要的不是測試叫什麼名字，是有沒有形成有效的約束。

要不要用BMad流程？方法論是原理的載體，不是原理本身，換一個瓶子不影響喝水。

L先生說了一句話：“金融業現在的品質高峰，以後就是大家的底線。”

七層測試，14萬條用例，獨立測試部門，開發測試運維分立。這些以前是金融業獨有的奢侈品，隨著AI把研發成本打下來，即將成為行業標配。

SPC誕生在美國，美國人自己不用。日本人浪費不起一顆螺絲釘，最先學會了做品質控制，迎來黃金30年。

此時此刻，恰如彼時彼刻。

（莫道遠, 2026年2月）

---