大廠干貨分享：AI幫我們值了一個月的夜班

本文作者為張敬峰，現為FunPlus某項目測試負責人，原文標題為《LLM驅動的QA-NightlyCheck系統-從架構設計到落地實踐》。

01

背景與痛點

AI的發展速度超乎了我們大部分人的想象，程序寫代碼、美術和UI出圖、策劃配表的速度提升了幾倍甚至幾十倍，這種效率的提升，我想最終會由量變引起質變，我們的工作習慣、工作流程甚至組織結構都會被解構和重塑。

我們或興奮、或焦慮、或茫然、或堅定，但無論如何，我們終須去面對，恰如狄更斯名著《雙城記》開篇所寫的：這是最好的時代，也是最壞的時代。

QA作為整個游戲研發流程中的最下游，隨著上游產能的瘋狂提升，版本的高速迭代，壓力和瓶頸也越來越大。但如何結合AI把產能和質量提升上去，我們大部分QA都面臨著以下幾個痛點：

1. 測試速度跟不上產能：同等人力下，上游產能爆發，QA繼續用舊有流程和工作方式無法及時處理版本內容，瓶頸逐漸顯現。

2. 無從下手：很多同學思想上知道必須用AI，也在使用一些AI工具輔助測試，但是總有一種無從下手的感覺，不知道怎么更好地提效，無法發揮AI的優勢。

3. AI幻覺和性價比：瘋狂燒了不少token，實際產出不穩定、不準確，還得不斷糾正AI，工作效率反而下降了。

為了解決這些問題，我們必須把AI用起來，而且還要用好，能夠擊敗魔法的只有魔法。

我們團隊的做法是先把日常工作流都做了一遍梳理和抽象，逐步把日常工作流都改為用AI驅動，結合一個具有綜合處理能力的QA Agent和一堆處理特定事務的skill，把AI從一個會產生幻覺、輸出結果不穩定的助手型工具變成了一個靠譜的QA專家。

本文我想跟大家分享的是我們QA Agent的一個子模塊落地實踐：QA Nightly Check系統，這個子模塊是一個基于大模型驅動的夜間無人值守的代碼和配置檢查系統，不僅能應對每日提交內容，也能應對版本合并時的海量合并情況，實現了在項目工業化落地，運行一個月來，產出結果穩定靠譜，誤報率低。

02

設計思路

1. 讓AI在人休息的時候也能干活，且整個工作流應該是自動化的，不需要人工干預；

2. 整個系統要實用、穩定，能在項目工業化落地；

3. 檢查范圍要有足夠的覆蓋度，檢查結果要穩定、準確、誤報率低，不能是一堆摻雜著AI幻覺產物的垃圾信息；

4. 對檢查出來且經過人工確認的bug要具有跟蹤能力，直到問題解決；

5. 保證準確率的基礎上盡量降低token消耗，提升性價比。

為了平衡問題解決速度和Token消耗，整個系統被劃分為三個驗證維度：

• 維度 1：硬規則與確定性過濾（純 Python 腳本）負責測試環境清理、待檢查內容切片與基礎數據采集。通過零 Token 消耗的硬性規則，直接剔除無業務影響的噪音代碼和資源文件。

• 維度 2：語義判定與跨端關聯（AI Agent）雙層復檢：縱向結合上下文調用鏈進行邏輯反證推理，橫向跨git倉庫進行多端關聯校驗。

• 維度 3：BUG知識庫跟蹤（AI Agent + Python腳本）對檢出問題打標簽并人工確認入庫，每輪檢查對知識庫特定標簽內容進行跟蹤復檢。

整體工作流如下：

最終報告的呈現：

03

流水線五階段詳細解析

階段一: 測試環境治理

在無人值守的 Cronjob 環境下，前一天的異常中斷或異常操作可能留下臟鎖，導致本次任務執行拉取代碼失敗。底層腳本通過強制清理.git/index.lock和.git/rebase-apply僵尸鎖，清空緩存數據等干擾項，提供一個干凈的待測環境給下一步的拉取腳本。

階段二: Diff采集與智能切片

這個階段主要是拉取Git倉庫數據和對待檢數據進行合理切分，主要采取了3個策略：

策略一：git 游標記錄，為了讓待檢數據準確，既不漏檢，也不多檢，我們會在機器本地保存一個記錄git 游標的json文件，那么我們就可以拿前一天最后一次提交的提交號與記錄的上次檢查的提交號來取git diff，檢查完畢后把本次檢查的提交號記錄到json文件中。不用日期來作為條件是因為我們白天可能臨時檢查了當天的內容，如果第二天凌晨檢查時又以固定日期來取 git diff，那么就會出現重復內容檢查的情況。或者是某次檢查失敗了我們沒注意，隔了幾天再檢查，如果以日期為條件那么就會出現漏檢的情況。

策略二：針對超大 git diff 導致的上下文溢出，采用拆批策略。當 git diff 超過 40KB 閾值時，開始對 diff 進行切分，不會完全按字符量死板截斷，而是按完整的修改代碼塊切分為多個 json chunk。

策略三：這條策略僅僅針對配置表的diff采集，配置表相對比較特殊，有時候diff會超級大，比如涉及一次大的數值重構，可能有數萬行數據的變化，如果恰好這些配置表的字段又很多，那么這次diff就會大的超乎想象，為了應對這種情況，我們采取了3層漏斗降噪策略去處理。

• 第一層漏斗：忽略那些純前端顯示的配置字段，比如美術資源類，對這些類型數據喂給AI，AI也無從判斷是否正確。

• 第二層漏斗：數值微調過濾，如果我們發現一個字段是純數值變動，那么對于數值變化率小于20%的可以忽略，我們認為是一次正常的數值調整，對于那些發生驟變的數據需要保留進行AI檢查。

• 第三層漏斗：對于某個表里批量新增的數據進行聚合，不會直接把所有數據直接發給AI，而是告訴AI某個表新增了N條配置，ID號是多少，讓AI后續逐條去檢查完整配置行和關聯表數據。

這一階段主要是起多個子Agent并行處理上一步提取的git diff 數據，不同的子Agent加載不同的檢查skill，從而實現快速準確的獲得初步檢查結果。這里的子Agent數量也是可以控制的，可以分輪次去處理上一個階段產出的多個拆批數據。

還會起一個額外的子Agent去檢索BUG知識庫中標簽為open的歷史數據，進行初檢，實現對歷史未修復BUG的跟蹤，檢查發現BUG已修復的會給知識庫中的BUG打上resolved標簽。

我們也需要對初檢覆蓋率進行檢查，不能直接相信AI告訴我們的結果，這里采取了對每個檢查文件進行日志記錄的策略，最后統計檢查的實際文件數，如果實檢文件數與總待檢文件數比值達到或超過90%，那么我們認為本次檢查是有效的，小于90%則需要體現在最終的報告中，提醒人工去檢查原因。

階段四: 主Agent匯總初檢數據并進行復檢

對于階段三產出的初檢結果，我們并不能完全信任結果是正確的，這里也采取了3個策略去進行復檢：

策略一：縱向加大上下文檢查，但是這里需要注意的是，需要讓AI自己通過證偽的方式去追蹤BUG的邏輯鏈條，因為AI更傾向于本能地去找更多支持這個BUG成立的證據，從而導致對邏輯鏈條的追蹤的深度可能不足。

舉個真實的例子，有次 AI 發現一段代碼把if-else的兩個分支合并成了一個，它判斷"刪除了一個分支，邏輯丟失了"。驗證的時候它繼續讀代碼，確認"對，那個分支確實被刪了"。但實際情況是——兩個分支做的事情完全一樣（只是寫法不同），合并是正確的重構，AI 從來沒想過要去證明"這兩個分支本來就一樣"。

所以需要讓AI先證偽再確認，即先假設初檢的問題不存在，試著找到一個能推翻它的證據，如果找到證據，才能確認這是一個真實的BUG，這樣AI就會順著邏輯鏈條不斷往上追溯，直到找到證明問題存在的證據。

策略二：橫向跨端追蹤。當涉及協議變化或配置讀取時，僅僅查看一端的邏輯是不能判斷這個BUG一定成立的，需要跨端驗證，去另一個倉庫讀取對應的數據來進行佐證。

策略三：誤報知識庫學習。每次復檢時，對知識庫中誤報標簽的BUG進行學習和參考，對類似的誤報原因進行參考和規避。

對于階段三和階段四，必須給AI設置一條紅線，只給AI讀取權限，剝奪修改權限。AI非常喜歡自己主動去修改它認為是BUG的代碼。

階段五: 生成報告與BUG歸檔

這個階段為了報告格式穩定，通過Python腳本進行信息匯總和郵件發送，唯一需要注意的是需要告訴AI哪怕檢查結果沒有任何BUG，也要調用腳本發送郵件，避免AI認為沒問題就不再調起腳本，我們沒收到郵件無從判斷是檢查失敗了還是郵件發送失敗了。

04

AI基礎設施的工程泥潭：

幾個坑及解決辦法

坑點一：AI更傾向于證明自己是對的。

推薦：讓AI證偽比證實更靠譜：

這個夜間巡檢系統一開始運行時，我們發現誤報率有點高，AI對提交的代碼片段檢查發現邏輯問題就直接認為是一個BUG，實際上下文可能已經存在某些約束，導致我們花了很多時間去驗證這些誤報的BUG，為了解決這個問題，我們大概優化了3輪：

第一輪優化：我們又在流程中加入了一旦命中BUG即增加上下文檢查的策略，讓AI不僅僅讀diff代碼，也要讀更多的上下文。實際使用了幾天，誤報率有所下降，但是下降的不多。

第二輪優化：我們在流程中增加了跨端檢查的策略，既然增大上下文還是不能讓誤報率降低到可接受的點，那么我們繼續加碼，讓AI對命中的BUG繼續檢查可能使用到的配表數據和后端數據，通過多端驗證，增加BUG的置信度。

第三輪優化：第二輪優化后，我們發現還是不行，誤報率還是有點高，幾近崩潰。又研究了一下，發現AI更傾向于尋找一些證據證明自己是對的，當它往上查找一個鏈條發現BUG還成立，它就會終止檢查，所以存在對邏輯鏈條檢查的深度和廣度不夠的情況。

于是我們把AI對BUG的審查策略從證實改為證偽，讓AI拿出足夠的證據證明這個BUG是誤報，當找不到任何證據的時候才確定這是一個真實的BUG，這個策略會逼迫AI加大對邏輯鏈條的審查深度。這次優化之后，誤報率終于降低到了可接受的程度。

坑點二：AI會產生幻覺。

推薦：給AI設置嚴格禁區：

有一次我拿著測試報告中的BUG去核對時，無論如何也找不到對應的問題代碼，百思不得其解，后來查看運行時的日志文件，才發現當天的檢查由于某個環節卡住了導致實際上是失敗的。

但是AI為了按照流程給我一份報告，就自己偽造了幾個足以以假亂真的BUG發給了我，原因就是我們在對應的skill文件里面沒有嚴格約束AI的行為。讓AI做事時，應該明確告訴它可以做什么，禁止做什么，描述一定要準確。

坑點三：同樣的輸入，AI每次推理結果不一定相同。

推薦：確定性的流程盡量用Python腳本：

最初我設計的是讓AI負責發送測試報告的，結果我收到了各式各樣的測試報告，哪怕給了AI一個模板參考也不行，AI有時候發散的太嚴重。為了解決這個問題，讓測試報告穩定的包含各個關鍵信息，改為AI驅動Python腳本來實現測試結果數據的聚合和報告發送。

坑點四：token可能隨時會燒完額度。

推薦：盡量在流程中設置一個備用LLM：

任務執行過程中，需要考慮token燒完額度的情況，遇到幾次token燒光或其他原因導致流程中斷的情況。這里推薦如果任務流程很長，盡量分階段產出數據，并在每個節點都打印日志，并配置一個備用LLM，當一個LLM因某種原因不可用時，備用LLM可以根據日志和中間階段產出的數據繼續把后續流程跑完。

05

工業化落地的幾個權衡點

1. Human-in-the-loop vs. 全自動化

對某些無風險流程可以完全交給AI，但是對于高風險或不確定性較高的內容則需要人工確認。需要在自動化效率與安全風控之間實現一個較合理的平衡。

1. 性價比

在獲得AI便利的同時，我們也需要考慮token消耗。將海量正則、統計、Git 調用的粗活交給純 Python 腳本，把Python腳本的產出數據交給 LLM 去分析，盡量降低token的消耗量。

1. 穩定性

由于整個流程環節較多，每個環節都可能出現問題，從而導致整個任務失敗。在設計的時候需要考慮到這些，是增加更多的容錯機制去維持系統的穩定還是保持一個有日志記錄、有報錯提醒的簡潔系統，需要根據實際需求去權衡。

06

結語

如果不能一下把所有內容都做成AI Native的工作流，不妨先把一條工作流做到可在項目真實落地，每一條能在項目真實落地的工作流都是整個項目 AI Native 研發基礎的一塊堅實底座。

希望通過 Nightly Check 的分享能給大家提供一些參考，拋磚引玉，也希望大家有好的建議可以多多交流。

游戲葡萄招聘內容編輯，

（星標可第一時間收到推送和完整封面）