把測試做成產品：AI 時代的業務測試可視化實踐指南
整理版優先睇
用低成本前端將測試變成業務用戶的協作工具，核心是按能力分層、每個頁面只回答一個明確問題。
呢篇文章係作者分享點樣用AI寫前端代碼嘅低成本優勢，將測試從開發專屬嘅腳本變成業務同事都用得嘅可視化產品。作者做緊智能審核系統，成日遇到業務同事睇唔明測試結果，要等開發解釋，溝通成本好高。佢發現傳統測試門檻高、結果難理解、協作困難，尤其係智能系統鏈路太長，出錯時根本唔知邊層有問題。
作者嘅結論係：測試可視化唔係取代單元測試，而係幫大家「睇得明」系統點解咁判斷。佢提出按能力分層設計測試頁面：業務審核能力、底層公共能力、抽取實驗室，每層只答一個問題。每個頁面要講清測試對象、輸入提示、配置同源（唔好前端寫死）、運行過程反饋，仲要產品化管理測試數據，保存歷史記錄支持復跑。
最後佢建議落地順序：先畫系統鏈路，找出最難解釋嘅環節，整最小頁面，逐步升級。唔好一開始就做大而全嘅控制枱，而係先做一個高頻痛點頁面，例如上傳文件、選節點規則、睇結果存歷史，已經可以解決好多問題。
- 測試可視化嘅核心目標係讓業務用戶睇得明、能夠協作，而唔係取代單元測試。
- 按能力分三層：業務審核（最貼近業務）、底層公共能力（文件分類、OCR等）、抽取實驗室（新文檔試抽、調優）。
- 頁面設計必須包含測試對象（用業務語言）、輸入提示（自動顯示要上傳嘅文件角色）、配置同源（連真實配置）、運行反饋（顯示進度，避免用戶以為卡死）。
- 推薦問題定位鏈路：完整結果異常 → 業務節點測試 → 規則級測試 → 文件分類測試 → OCR測試 → 抽取實驗室，逐層聚焦。
- 測試數據要產品化管理，保存原始文件、manifest.json，支持復跑和審計；落地時先做一個高頻痛點頁面，逐步迭代，唔好追求大而全。
點解要將測試做成產品
傳統代碼式測試門檻高，業務用戶唔會跑腳本，結果失敗後只見到異常棧同JSON，佢哋真正關心嘅係「邊條規則冇過？要補咩文件？」。而且智能審核鏈路太長，例如文件上傳、OCR、抽取、規則判斷等，任何一層出事都會令最終結果異常，但好難即刻知邊層錯。
測試可視化就係要幫業務用戶睇得明結果、快速復現問題，唔使等開發解釋。
作者認為，AI寫前端代碼成本夠低，以前「唔值得整頁面」嘅內部工具而家可以做好。測試唔一定要留喺腳本入面，可以設計成產品畀成個團隊用。
按能力分層，唔好堆入口
作者冇將所有測試塞入一個頁面，而係按能力層級拆開，每個入口只回答一個明確問題。
- 1 業務審核能力測試：使用者揀節點同規則，上傳所需文件，結果顯示通過、失敗、跳過，仲有風險依據同證據。
- 2 底層公共能力測試：例如文件分類測試頁面，答文件有冇被正確歸類；OCR清洗測試確認文字提取結果。
- 3 抽取實驗室：唔綁定審核規則，例如泛化抽取實驗室，用嚟試抽同調優，適合開發同能力驗證。
每個頁面只答一個問題，避免做成「大雜燴」令人唔知點入手。
一個好嘅測試可視化頁面要有啲咩
測試頁面唔可以淨係「上傳文件 + 睇 JSON」，咁樣業務同事一樣用唔起。作者提出至少要有四樣嘢。
測試對象要用業務語言，唔好淨係畀 `check_subject_seal` 呢類技術字段。
- 測試對象：清楚顯示而家測緊咩場景、節點、規則，用業務語言描述。
- 輸入提示：自動提示要上傳嘅文件角色，例如「主體與蓋章校驗」要上傳報銷面單同合同，避免用戶卡喺第一步。
- 配置同源：節點、規則、文件角色要從配置中心動態拎，唔好前端寫死，否則配置改咗測試頁面唔同步，會造成混亂。
- 運行過程反饋：顯示已耗時、當前步驟（OCR、解析、節點執行等），避免用戶以為系統卡死。
輸入提示係作者感受最深嘅一點：用戶好多時唔係唔識測，而係唔知要上傳邊啲文件。
問題定位鏈路同數據管理
測試頁面要服務於問題定位。作者推薦一條清晰鏈路：完整審核結果異常 → 業務節點測試（邊個節點失敗） → 規則級測試 → 文件分類測試 → OCR測試 → 抽取實驗室。每一步只答一個問題。
另外，測試數據要產品化管理。作者做法係每次測試保存原始文件同 manifest.json，紀錄文件名、sha256、場景、節點規則等。咁樣可以復跑、審計、沉澱標準樣例。注意刪除功能要謹慎，第一版最好只允許刪除單一文件，避免誤刪測試資產。
測試歷史記錄係必須嘅，冇歷史就冇復現能力，協作效率會好低。
常見誤區同落地建議
作者列出幾個常見誤區：只做頁面但唔接真實配置、只展示 Raw JSON、只有完整流程測試、冇歷史記錄、運行中冇反饋。呢啲都會令測試工具淪為擺設。
落地順序建議：先畫系統鏈路，找出最常出問題嘅環節，整最小測試頁面，每個頁面只答一個核心問題。
- 1 畫出系統能力鏈路。
- 2 揾出最難解釋嘅環節。
- 3 為呢啲環節整最小測試頁面。
- 4 輸入區盡量貼近真實業務。
- 5 輸出區先畀業務結論，再畀技術細節。
- 6 節點、規則必須同配置中心同源。
- 7 每次測試保存歷史，支持復跑。
- 8 逐步從節點級升級到規則級，再沉澱成迴歸測試集。
作者最後總結：測試頁面本身都係產品。AI令前端開發成本下降，好多內部工具值得重新設計。當業務用戶都可以理解、復現、討論時，測試就變成團隊協作嘅一部分，而唔係淨係開發嘅工程工具。
過去好長一段時間入面，大家預設「測試」主要係開發嘅事。
⠀
單元測試、接口測試、腳本測試、命令行調試，呢啲嘢對開發好順手。
但係去到業務同事、測試同事、規則配置同事嗰度，就冇咁友好喇。
尤其係智能審核、文檔抽取、OCR、規則判斷呢類系統，一個結果失敗咗，大家第一反應通常唔係「我知邊度錯咗」，而係「呢個到底係邊一層嘅問題」。
⠀
如果答案都藏喺代碼、日誌同 JSON 入面，業務用戶只能等開發解釋。
測試呢件事，就好難變成大家一齊用嘅工具。
⠀
而家呢個前提變咗。
⠀
AI 寫前端代碼已經夠平、夠快。
以前好多「唔值得專門做頁面」嘅測試工具，而家可以用好低成本整成可視化頁面。
測試唔一定只可以留喺腳本入面，佢都可以被設計成一個產品。
⠀
呢篇文章唔講通用測試理論，主要紀錄我在呢個項目入面行過嘅一條路：
點樣將測試變成業務用戶睇得明、操作到、可以重現嘅可視化工具。
⠀
⠀
⠀
【重點】一、點解要將測試做成產品
⠀
代碼式測試梗係有價值，但佢有幾個天然限制。
⠀
第一，門檻高。業務用戶唔會行腳本，亦唔應該被要求睇得明測試代碼。
⠀
第二，結果難理解。測試失敗之後，開發見到嘅係異常棧、日誌、字段差異；業務用戶真正關心嘅係：邊條規則唔過？依據係咩？我要唔要補文件？補邊個文件？
⠀
第三，協作成本高。如果測試結果唔可以被業務、測試、開發共同理解，大家唯有不停截圖、轉述、解釋。好多時間花喺「你講緊係咪呢個問題」上面。
⠀
第四，智能系統嘅問題鏈太長。以智能審核為例，一次審核結果可能經過：
⠀
文件上傳
↓
文件分類
↓
OCR / T1 預解析
↓
文檔結構化抽取
↓
審核節點執行
↓
規則判斷
↓
風險彙總
↓
審核報告生成⠀
任何一層出問題，最終結果都會異常。
⠀
所以我後來更傾向於做一組測試入口，而唔係一個「大而全」嘅測試腳本。
每個入口只幫用戶回答一個問題：呢一層到底係唔係正常。
⠀
⠀
【重點】二、測試可視化唔係取代單元測試
⠀
先講清楚：測試可視化唔係用嚟取代代碼測試嘅。
⠀
單元測試、接口測試、回歸測試、CI 仍然要做。佢哋負責守住工程底線。
⠀
可視化測試解決嘅係另一類問題：
⠀
- 等業務用戶睇得明測試結果
- 等測試人員可以快速重現問題
- 等規則配置人員可以驗證規則變化
- 讓開發更快定位問題發生喺邊一層
- 等同一組測試文件、同一段測試記錄可以反覆討論
⠀
可以咁樣理解：
⠀
代碼測試：保證系統不會壞
可視化測試：幫助大家看懂系統為什麼這樣判斷⠀
前者偏工程保障，後者偏協作同解釋。兩者最好都要有，唔好溝埋一齊互相取代。
⠀
⠀
【重點】三、測試頁面要按能力分層，而唔係堆入口
⠀
係呢個項目入面，我冇將所有測試都塞入一個頁面。咁樣做睇落慳事，最後一定會變成一個邊個都唔想打開嘅「大雜燴」。
⠀
我更願意按能力層級拆開。
⠀
→ 1. 業務審核能力測試
⠀
呢一類測試最接近業務用戶嘅理解方式，亦係最容易令業務同事參與嘅入口。
⠀
佢關心嘅係：
⠀
- 邊個審核節點喺度運作
- 邊條規則被測試
- 需要上傳邊啲業務文件
- 節點結果係通過、失敗、跳過定係異常
- 風險依據係咩
- 通過證據係咩
⠀
例如「業務節點測試」頁面入面，用戶可以選擇：
⠀
頁面會提示呢條規則需要嘅文件，例如報銷面單、合同。用戶上傳文件之後，只行呢個節點，然後睇對應風險、證據、日誌同原始 JSON。
⠀
呢類頁面嘅重點好樸素：等業務規則可以被單獨拎出嚟驗證。
⠀
→ 2. 底層公共能力測試
⠀
業務節點失敗，唔一定係規則錯咗。有時只係底層能力冇做好。
⠀
所以需要單獨測試底層公共能力，例如：
- 文件分類測試
- 頁面分型診斷
- T1 OCR 清洗測試
- 合同抽取子圖測試
佢哋回答嘅係更底層嘅問題：
- 文件有冇被辨識成正確角色
- 邊個文件被當成合同，邊個文件被當成結算書
- PDF 每一頁係咪分型正確
- OCR 係咪提取到關鍵文字
- 合同字段係咪可以單獨抽取成功
⠀
呢類頁面主要畀開發同測試用，但做得清楚嘅話，業務同事都睇得明一部分。
⠀
佢嘅價值好直接：業務節點結果唔啱嘅時候，唔使即刻估規則錯咗，可以先落去查多一層。
⠀
→ 3. 抽取實驗室
⠀
抽取實驗室更偏開發同能力調優，我將佢當成「試驗田」。
佢適合用嚟做：
⠀
- 新文檔類型試抽
- 抽取模板調試
- prompt 迭代
- 字段結構驗證
- 標準答案對比
⠀
例如「泛化抽取實驗室」同「單頁提取測試」唔綁定某一條審核規則，佢哋服務抽取能力本身。
⠀
呢一層適合探索。行通之後，再沉到正式審核流程入面。
⠀
⠀
【重點】四、一個好嘅測試可視化頁面應該包含啲咩
⠀
測試頁面唔可以只係「上傳文件 + 睇 JSON」。咁做只係將命令行搬咗去網頁，業務同事都係用唔到。
⠀
如果希望業務用戶都用得，我覺得至少要把下面幾件事講清楚。
⠀
→ 1. 測試對象
⠀
用戶一定要知道自己而家係測緊啲咩。
⠀
例如：
⠀
場景：營銷費用審核
審核節點：主體與蓋章校驗
測試規則：確認報銷供應商與合同供應商一致⠀
唔好淨係畀用戶睇 `check_subject_seal` 呢啲技術字段。技術字段可以留低，但頁面主信息應該係業務語言。
⠀
→ 2. 輸入提示
⠀
呢度係我自己感受最強嘅一點：用戶成日唔係唔識測，而係唔知要上傳邊啲文件。
⠀
所以頁面需要根據配置中心自動提示：
⠀
- 呢條規則涉及邊啲文件角色
- 每個文件角色係咩意思
- 文件缺失可能會導致咩結果
⠀
例如揀「主體與蓋章校驗」下面嘅某條規則之後，頁面提示：報銷面單、合同
⠀
揀另一條規則時，提示可能變成：結算書/交付報告
⠀
⠀
呢步如果唔做，頁面再靚都冇用。用戶會卡喺第一步：我到底要傳咩？
⠀
→ 3. 配置同源
⠀
測試頁面上嘅節點、規則、文件角色、參數，唔應該係前端寫死嘅。
⠀
否則配置中心改咗規則，測試頁面仲顯示舊內容，就會造成新嘅混亂。
⠀
我更認同嘅做法係：
⠀
配置中心 audit_config.xlsx
↓
後端配置接口 /config/audit-rules
↓
測試頁面動態展示節點、規則、文件角色、參數⠀
咁樣測試頁面就會成為正式規則配置嘅一個可視化入口，而唔係另一套要人手維護嘅說明文案。
⠀
→ 4. 運行過程反饋
⠀
智能審核成日行得比較耐。涉及 OCR、PDF 解析、大模型抽取時，用戶唔可以淨係見到一個「正在測試」。
⠀
頁面應該展示：
⠀
- 已經用咗幾耐
- 而家大約喺邊一步
- 係咪正在保存文件
- 係咪正在 OCR
- 係咪正在執行節點
- 係咪正在等後端返回
⠀
就算第一版仲未做到真正實時日誌，都應該先畀用戶一個運行中進展面板。
⠀
否則用戶會以為系統卡咗。⠀
⠀
【重點】五、推薦嘅問題定位鏈路
⠀
測試頁面點樣組織，最後要服務於問題定位。
⠀
⠀
我而家覺得比較順嘅一條鏈路係：
⠀
完整審核結果異常
↓
業務節點測試：哪個節點失敗
↓
規則級測試：是哪條規則失敗
↓
文件分類測試：文件角色是否識別正確
↓
T1 OCR / 頁面分型：底層解析是否正確
↓
抽取實驗室：字段抽取是否需要調優⠀
咁樣用戶唔會迷失喺一堆工具入面，亦唔會一嚟就被逼睇最底層嘅技術細節。
⠀
每個頁面回答一個明確問題就夠：
⠀
- 業務節點測試：呢個節點係唔係正常？
- 規則級測試：呢條規則點解過或唔過？
- 文件分類測試：文件有冇辨識啱？
- OCR 測試：文字有冇提取出嚟？
- 抽取實驗室：字段有冇抽啱？
⠀
⠀
【重點】六、測試數據都要產品化管理
⠀
可視化測試唔係淨係做頁面，仲要管理測試數據。
⠀
尤其係業務文件類測試，上傳嘅文件本身就係測試樣例。呢一點好容易被低估。
⠀
呢個項目入面嘅做法係：
⠀
audit-agent/uploads/capability_cases/{record_id}/
files/
原始上傳文件
manifest.json⠀
每次測試都會保存：
⠀
- 原始文件名
- 儲存路徑
- 文件大小
- sha256
- 測試場景
- 節點
- 規則
- 係咪用咗 T1 緩存
⠀
咁樣做有幾個實際好處：
⠀
- 可以重跑
- 可以審計
- 可以排查文件係咪有變
- 可以沉澱標準測試樣例
- 可以將來擴展成回歸測試集
⠀
需要注意嘅係，長期保存文件之後，刪除能力都要謹慎設計。唔好一嚟就提供批量刪除目錄。第一版最好淨係允許刪除明確嘅單個文件，避免誤刪測試資產。
⠀
⠀
⠀
【重點】七、測試可視化嘅常見誤區
⠀
→ 誤區一：淨係做頁面，唔接真實配置
⠀
頁面睇落好靚，但規則、節點、文件說明都係前端寫死嘅。
⠀
呢類頁面好快會同真實系統脱節。到最後，大家又要問：到底以配置中心為準，定係以測試頁面為準？
⠀
→ 誤區二：淨係展示 Raw JSON
⠀
Raw JSON 對開發有用，但對業務用戶唔友好。
⠀
應該先展示業務結論，再將 JSON 留畀開發排查。
⠀
→ 誤區三：淨係得完整流程測試
⠀
完整流程測試梗係重要，但定位問題太慢。
⠀
需要支援：
⠀
- 單節點測試
- 單規則聚焦測試
- 底層能力測試
- 抽取實驗測試
⠀
→ 誤區四：冇歷史紀錄
⠀
冇歷史紀錄，就冇重現能力。
⠀
測試結果只能靠截圖傳播，協作效率會好低。
⠀
→ 誤區五：運行中冇反饋
⠀
智能審核好容易行幾十秒甚至幾分鐘。
⠀
如果頁面得一個 loading，用戶好易懷疑係統卡咗。呢個體驗好差，仲會製造好多無謂嘅溝通。
⠀
⠀
【重點】九、點樣喺其他項目落地
⠀
如果其他項目都想做，可以唔使一開始就做得好完整。我建議按呢個順序嚟：
⠀
undefined. 先畫出系統能力鏈路 undefined. 揾出最常出問題、最難解釋嘅環節 undefined. 為呢啲環節做最小測試頁面 undefined. 每個頁面只回答一個核心問題 undefined. 輸入區盡量貼近真實業務使用方式 undefined. 輸出區先畀業務結論，再畀技術細節 undefined. 節點、規則、參數、文件角色一定要同配置中心同源 undefined. 每次測試一定要保存歷史 undefined. 支援基於歷史重跑 undefined. 逐步由節點級測試升級到規則級測試 undefined. 再進一步沉澱成回歸測試集
⠀
唔好一開始就追求大而全。測試可視化最怕做成「萬能控制枱」，睇落咩都有，其實邊個都唔知由邊度開始。
⠀
先做一個高頻痛點頁面，例如：
⠀
上傳一組文件
選擇一個節點
選擇一條規則
運行測試
查看結果和證據
保存歷史⠀
咁就已經可以解決唔少問題。
⠀
⠀
【重點】十、結語：測試頁面都係產品
⠀、
AI 令前端開發成本下降之後，好多內部工具都值得重新設計。
⠀
以前我哋可能會覺得，為測試做頁面唔划算。
而家唔同咗。好多測試頁面唔需要做到正式產品咁複雜，但可以做得夠清楚、夠好用。
⠀
當測試頁面夠平，測試就唔使淨係停留喺代碼入面。佢可以變成業務、測試、開發共同使用嘅協作界面。
⠀
尤其係喺智能審核呢類系統入面，可視化測試好實用。
冇咗佢，好多問題會一直停留喺「我覺得唔啱」同「你再 send 多次文件畀我」嘅來回溝通入面。
⠀
如果淨係留一句話，我會咁講：
⠀
當測試結果得開發睇得明嘅時候，測試只係工程工具；
當業務用戶都可以理解、重現、討論嘅時候，測試先開始變成團隊協作嘅一部分。
過去很長一段時間裏，大家默認“測試”主要是開發的事情。
⠀
單元測試、接口測試、腳本測試、命令行調試，這些東西對開發很順手。
但換到業務同事、測試同事、規則配置同事那裏，就沒那麼友好了。
尤其是智能審核、文檔抽取、OCR、規則判斷這類系統，一個結果失敗了，大家第一反應往往不是“我知道哪裏錯了”，而是“這到底是哪一層的問題”。
⠀
如果答案都藏在代碼、日誌和 JSON 裏，業務用戶只能等開發解釋。
測試這件事，也就很難變成大家一起用的工具。
⠀
現在這個前提變了。
⠀
AI 寫前端代碼已經足夠便宜、足夠快。
以前很多“不值得專門做頁面”的測試工具，現在可以用很低的成本做成可視化頁面。
測試不一定只能留在腳本里，它也可以被設計成一個產品。
⠀
這篇文章不講通用測試理論，主要記錄我在這個項目裏走過的一條路：
怎麼把測試做成業務用戶能看懂、能操作、能復現的可視化工具。
⠀
⠀
⠀
【重點】一、為什麼要把測試做成產品
⠀
代碼式測試當然有價值，但它有幾個天然限制。
⠀
第一，門檻高。業務用戶不會跑腳本，也不應該被要求看懂測試代碼。
⠀
第二，結果難理解。測試失敗以後，開發看到的是異常棧、日誌、字段差異；業務用戶真正關心的是：哪條規則沒過？依據是什麼？我要不要補文件？補哪個文件？
⠀
第三，協作成本高。如果測試結果不能被業務、測試、開發共同理解，大家只能反覆截圖、轉述、解釋。很多時間花在“你說的是不是這個問題”上。
⠀
第四，智能系統的問題鏈路太長。以智能審核為例，一次審核結果可能經過：
⠀
文件上傳
↓
文件分類
↓
OCR / T1 預解析
↓
文檔結構化抽取
↓
審核節點執行
↓
規則判斷
↓
風險彙總
↓
審核報告生成⠀
任何一層出問題，最終結果都會異常。
⠀
所以我後來更傾向於做一組測試入口，而不是一個“大而全”的測試腳本。
每個入口只幫用戶回答一個問題：這一層到底是不是正常。
⠀
⠀
【重點】二、測試可視化不是替代單元測試
⠀
先說清楚：測試可視化不是用來替代代碼測試的。
⠀
單元測試、接口測試、迴歸測試、CI 仍然要做。它們負責守住工程底線。
⠀
可視化測試解決的是另一類問題：
⠀
- 讓業務用戶看得懂測試結果
- 讓測試人員能快速復現問題
- 讓規則配置人員能驗證規則變化
- 讓開發更快定位問題發生在哪一層
- 讓同一組測試文件、同一次測試記錄可以反覆討論
⠀
可以這樣理解：
⠀
代碼測試：保證系統不會壞
可視化測試：幫助大家看懂系統為什麼這樣判斷⠀
前者偏工程保障，後者偏協作和解釋。兩者最好都要有，不要混在一起互相替代。
⠀
⠀
【重點】三、測試頁面要按能力分層，而不是堆入口
⠀
在這個項目裏，我沒有把所有測試都塞進一個頁面。這樣做看起來省事，最後一定會變成一個誰都不想打開的“大雜燴”。
⠀
我更願意按能力層級拆開。
⠀
→ 1. 業務審核能力測試
⠀
這一類測試最接近業務用戶的理解方式，也是最容易讓業務同事參與進來的入口。
⠀
它關心的是：
⠀
- 哪個審核節點在工作
- 哪條規則被測試
- 需要上傳哪些業務文件
- 節點結果是通過、失敗、跳過還是異常
- 風險依據是什麼
- 通過證據是什麼
⠀
例如“業務節點測試”頁面裏，用戶可以選擇：
⠀
頁面會提示這條規則需要的文件，例如報銷面單、合同。用戶上傳文件後，只跑這個節點，然後看對應風險、證據、日誌和原始 JSON。
⠀
這類頁面的重點很樸素：讓業務規則可以被單獨拿出來驗證。
⠀
→ 2. 底層公共能力測試
⠀
業務節點失敗，不一定是規則錯了。有時只是底層能力沒做好。
⠀
所以需要單獨測試底層公共能力，例如：
- 文件分類測試
- 頁面分型診斷
- T1 OCR 清洗測試
- 合同抽取子圖測試
它們回答的是更底層的問題：
- 文件有沒有被識別成正確角色
- 哪個文件被當成合同，哪個文件被當成結算書
- PDF 每一頁是否分型正確
- OCR 是否提取到了關鍵文字
- 合同字段是否能單獨抽取成功
⠀
這類頁面主要給開發和測試用，但做得清楚一點，業務同事也能看懂一部分。
⠀
它的價值很直接：業務節點結果不對時，不用馬上猜規則錯了，可以先往下查一層。
⠀
→ 3. 抽取實驗室
⠀
抽取實驗室更偏開發和能力調優，我把它看成“試驗田”。
它適合用來做：
⠀
- 新文檔類型試抽
- 抽取模板調試
- prompt 迭代
- 字段結構驗證
- 標準答案對比
⠀
比如“泛化抽取實驗室”和“單頁提取測試”不綁定某一條審核規則，它們服務抽取能力本身。
⠀
這一層適合探索。跑通以後，再沉到正式審核流程裏。
⠀
⠀
【重點】四、一個好的測試可視化頁面應該包含什麼
⠀
測試頁面不能只是“上傳文件 + 看 JSON”。那只是把命令行搬到了網頁上，業務同事還是用不起來。
⠀
如果希望業務用戶也能用，我覺得至少要把下面幾件事講清楚。
⠀
→ 1. 測試對象
⠀
用戶必須知道自己現在在測什麼。
⠀
例如：
⠀
場景：營銷費用審核
審核節點：主體與蓋章校驗
測試規則：確認報銷供應商與合同供應商一致⠀
不要只給用戶看 `check_subject_seal` 這種技術字段。技術字段可以留着，但頁面主信息應該是業務語言。
⠀
→ 2. 輸入提示
⠀
這裏是我自己感受最強的一點：用戶經常不是不會測，而是不知道該上傳哪些文件。
⠀
所以頁面需要根據配置中心自動提示：
⠀
- 這條規則涉及哪些文件角色
- 每個文件角色是什麼意思
- 文件缺失可能導致什麼結果
⠀
例如選擇“主體與蓋章校驗”下的某條規則後，頁面提示：報銷面單、合同
⠀
選擇另一條規則時，提示可能變成：結算書/交付報告
⠀
⠀
這一步如果不做，頁面再漂亮也沒用。用戶會卡在第一步：我到底要傳什麼？
⠀
→ 3. 配置同源
⠀
測試頁面上的節點、規則、文件角色、參數，不應該在前端硬編碼一份。
⠀
否則配置中心改了規則，測試頁面還顯示舊內容，就會造成新的混亂。
⠀
我更認可的做法是：
⠀
配置中心 audit_config.xlsx
↓
後端配置接口 /config/audit-rules
↓
測試頁面動態展示節點、規則、文件角色、參數⠀
這樣測試頁面會成為正式規則配置的一個可視化入口，而不是另一套需要人工維護的說明文案。
⠀
→ 4. 運行過程反饋
⠀
智能審核經常跑得比較久。涉及 OCR、PDF 解析、大模型抽取時，用戶不能只看到一個“正在測試”。
⠀
頁面應該展示：
⠀
- 已耗時多久
- 當前大概在哪一步
- 是否正在保存文件
- 是否正在 OCR
- 是否正在執行節點
- 是否正在等待後端返回
⠀
哪怕第一版還做不到真正實時日誌，也應該先給用戶一個運行中進展面板。
⠀
否則用戶會以為系統卡死。⠀
⠀
【重點】五、推薦的問題定位鏈路
⠀
測試頁面怎麼組織，最後要服務於問題定位。
⠀
⠀
我現在覺得比較順的一條鏈路是：
⠀
完整審核結果異常
↓
業務節點測試：哪個節點失敗
↓
規則級測試：是哪條規則失敗
↓
文件分類測試：文件角色是否識別正確
↓
T1 OCR / 頁面分型：底層解析是否正確
↓
抽取實驗室：字段抽取是否需要調優⠀
這樣用戶不會迷失在一堆工具裏，也不會一上來就被迫看最底層的技術細節。
⠀
每個頁面回答一個明確問題就夠了：
⠀
- 業務節點測試：這個節點是否正常？
- 規則級測試：這條規則為什麼過或不過？
- 文件分類測試：文件有沒有識別對？
- OCR 測試：文字有沒有提出來？
- 抽取實驗室：字段有沒有抽對？
⠀
⠀
【重點】六、測試數據也要產品化管理
⠀
可視化測試不是隻做頁面，還要管理測試數據。
⠀
尤其是業務文件類測試，上傳的文件本身就是測試樣例。這個點很容易被低估。
⠀
這個項目裏的做法是：
⠀
audit-agent/uploads/capability_cases/{record_id}/
files/
原始上傳文件
manifest.json⠀
每次測試都會保存：
⠀
- 原始文件名
- 存儲路徑
- 文件大小
- sha256
- 測試場景
- 節點
- 規則
- 是否使用 T1 緩存
⠀
這樣做有幾個實際好處：
⠀
- 可以復跑
- 可以審計
- 可以排查文件是否變化
- 可以沉澱標準測試樣例
- 可以未來擴展成迴歸測試集
⠀
需要注意的是，長期保存文件以後，刪除能力也要謹慎設計。不要一上來就提供批量刪除目錄。第一版最好只允許刪除明確的單個文件，避免誤刪測試資產。
⠀
⠀
⠀
【重點】七、測試可視化的常見誤區
⠀
→ 誤區一：只做頁面，不接真實配置
⠀
頁面看起來很漂亮，但規則、節點、文件說明都是前端寫死的。
⠀
這類頁面很快會和真實系統脱節。到最後，大家又要問：到底以配置中心為準，還是以測試頁面為準？
⠀
→ 誤區二：只展示 Raw JSON
⠀
Raw JSON 對開發有用，但對業務用戶不友好。
⠀
應該先展示業務結論，再把 JSON 留給開發排查。
⠀
→ 誤區三：只有完整流程測試
⠀
完整流程測試當然重要，但定位問題太慢。
⠀
需要支持：
⠀
- 單節點測試
- 單規則聚焦測試
- 底層能力測試
- 抽取實驗測試
⠀
→ 誤區四：沒有歷史記錄
⠀
沒有歷史記錄，就沒有復現能力。
⠀
測試結果只能靠截圖傳播，協作效率會很低。
⠀
→ 誤區五：運行中沒有反饋
⠀
智能審核很容易跑幾十秒甚至幾分鐘。
⠀
如果頁面只有一個 loading，用戶很容易懷疑係統卡住。這個體驗很糟，而且會製造很多不必要的溝通。
⠀
⠀
【重點】九、如何在其他項目落地
⠀
如果其他項目也想做，可以不用一開始就做得很完整。我建議按這個順序來：
⠀
undefined. 先畫出系統能力鏈路 undefined. 找出最常出問題、最難解釋的環節 undefined. 為這些環節做最小測試頁面 undefined. 每個頁面只回答一個核心問題 undefined. 輸入區儘量貼近真實業務使用方式 undefined. 輸出區先給業務結論，再給技術細節 undefined. 節點、規則、參數、文件角色必須和配置中心同源 undefined. 每次測試必須保存歷史 undefined. 支持基於歷史復跑 undefined. 逐步從節點級測試升級到規則級測試 undefined. 再進一步沉澱成迴歸測試集
⠀
不要一開始就追求大而全。測試可視化最怕做成“萬能控制枱”，看起來什麼都有，其實誰都不知道從哪裏開始。
⠀
先做一個高頻痛點頁面，比如：
⠀
上傳一組文件
選擇一個節點
選擇一條規則
運行測試
查看結果和證據
保存歷史⠀
這就已經能解決不少問題了。
⠀
⠀
【重點】十、結語：測試頁面也是產品
⠀、
AI 讓前端開發成本下降以後，很多內部工具都值得重新設計。
⠀
過去我們可能會覺得，為測試做頁面不划算。
現在不一樣了。很多測試頁面不需要做成正式產品那樣複雜，但可以做得足夠清楚、足夠好用。
⠀
當測試頁面足夠便宜，測試就不必只停留在代碼裏。它可以變成業務、測試、開發共同使用的協作界面。
⠀
尤其是在智能審核這類系統裏，可視化測試很實用。
沒有它，很多問題會一直停留在“我覺得不對”和“你再發我一份文件”的來回溝通裏。
⠀
如果只留一句話，我會這麼說：
⠀
當測試結果只有開發能看懂時，測試只是工程工具；
當業務用戶也能理解、復現、討論時，測試才開始變成團隊協作的一部分。