AI 品保筆記|三十年品保人看 AI

一、一個看起來是好消息的數字 某天的品質日報上，一條產線的判退率從六成五掉到不到三成。 這是所有人都想看到的數字。當天的會議上，大家的討論很自然地往「哪個改善見效了」去走：是前段的參數調整？還是新的清潔程序？要不要複製到其他產線？ 我沒有跟著討論。我問了一個不太受歡迎的問題： 「那天，判的人有沒有換？判的標準有沒有換？」 二、為什麼我不信 品質數字有一個特性，和製程數字不同： 它是「判」出來的，不是「量」出來的。 線寬是量出來的，尺不變，數字就有可比性。但外觀判退不是——它經過一個人、一份限度樣本、一套判定標準。這條鏈上任何一環變了，數字就會跳，而製程可能一點都沒動。 更麻煩的是， 兩種原因造成的跳躍，在圖上長得一模一樣 ：都是某一天之後，均值換到另一個水準，而且穩定地停在那裡。統計上做變點偵測，兩者都會被抓出同一個日期，分不出誰是誰。 所以我的習慣是： 當判退率出現階梯式的大幅改善，先假設是量測系統變了，直到證明它不是。 這不是悲觀，是因為兩件事的後果差很多： 若是真的製程改善，你該去複製它。 若是判準改了，你複製的是一個不存在的東西，而且 你從此失去了跨越那一天比較的能力 。 第二種情況最傷的不是那一天，是 往後一整年的趨勢圖全部不能用 。 三、怎麼查 查證的順序是固定的，從最便宜的查起： 第一步：問人，不要先算。 那段期間判定人員有沒有異動？有沒有新人接手？有沒有因為人力調度換班？這個問題花五分鐘，卻能省下三天的分析。 第二步：查限度樣本與判定標準的版本。 限度樣本有沒有換一套？判定基準有沒有改版？文件有沒有留下生效日？ 這裡最常見的失敗是：標準確實改了，但沒有人把生效日記在品質數據旁邊 ，所以三個月後沒人記得。 第三步：對日期。 把變點日期、人員異動日期、標準改版日期三條時間軸疊在一起看。如果變點正好落在改版日或換人日的那一兩天，它幾乎不會是巧合。 第四步：看缺陷結構，不要只看總率。 這一步最有力。如果是真的製程改善，通常是 某幾類特定缺陷 減少，其他類別維持不動。如果是判準變鬆或換人，則往往是 某一類邊界模糊的缺陷整批消失 ——就是那種「判 A 也可以、判 B 也說得過去」的類別。 總率一樣降，結構卻完全不同。 第五步：找還在的實物。 如果那段期間的樣片還留著，拿改版前後的實物讓同一位判定人員重判一次。...

一、一個看起來是好消息的回報 我讓 AI 幫我建一套品質報表系統。其中一頁是中文網頁，給現場主管每天看。 AI 回報：「已完成，已驗證。」 它不是隨口說說。它跑了程式，程式沒有報錯；它檢查了每個連結，連結都指得到檔案；它還派出好幾個「子代理」互相複查，每一層都回報通過。 前後十一天，它派了兩百多次子代理，留下兩百多 MB 的紀錄。每一份紀錄都寫著綠燈。 可是那一頁，主管打開來，中文全是亂碼。 二、為什麼那麼多綠燈都沒用 做了三十年品保，這個場景我很熟。只是以前出現在產線上，這次出現在 AI 身上。 問題不在 AI 不夠努力，而在它 驗的東西，跟使用者看到的東西，不是同一個 ： 「程式跑完沒報錯」——驗的是程式有沒有執行，不是畫面對不對。 「連結都指得到檔案」——驗的是檔案存在，不是檔案打開後看得懂。 「子代理互相複查都通過」——它們用的是同一套推論，錯在同一個地方，就一起通過。 品保的老話叫 共模失效 ：兩道檢驗站用同一把尺，一起量錯的時候，不會有任何一站報警。AI 派十個分身去檢查，如果十個都只是「再推論一遍」，就等於同一把尺量十次。 三、怎麼查出來的 最後抓到問題的，是另一個 AI。它做的事情非常簡單： 開一個真的瀏覽器，把那一頁點開，看一眼。 一眼就看到亂碼。再往下查，原因是網頁少了一行宣告文字編碼的設定。十一天沒抓到的問題，點一下就現形。 差別不在聰明，在 順序 ： 做法 它回答的問題 程式跑完、連結可解析、型別檢查通過 「看起來應該對」——這是推論 另一個 AI 再推論一遍 還是推論，只是多了一層 打開真的畫面、跑一次真的流程、看原始檔案 「實際上對不對」——這才是驗證 四、真相：順序倒過來，錯誤會被放大 我後來把這件事整理成一條規則，叫 驗證階梯 ，順序不准倒： 先接觸真實 ：打開畫面、實際跑一次、直接看原檔、親眼看圖。 再獨立審核 ：換一個沒參與製作的人(或 AI)去做第 1 步，不是去再推論一遍。 最後才機器化 ：量大了才派一堆代理、寫自動流程。它解決的是「量大」，不解決「真假」。 如果跳過第 1 步，直接做第 3 步，你得到的不是更可靠的檢查，而是 把錯誤工業化 ：同一個幻覺被分裝到好幾層，每一層都發綠燈，最後所有人都很有信心。 這跟工廠一模一樣：首件...