回國已經三週了。
公司裡的氣氛異常安靜。
德華忙著追蹤巴西客戶退回的樣品,阿哲則被一堆報銷單據淹沒。
唯獨老張,整整一週幾乎沒說過一句話。
直到週五下午,他忽然放下手邊的檢驗報告,開口:
「上次客訴的事,以後不會再發生第二次。」
全辦公室瞬間安靜下來。
德華愣住了,這麼多年來,他第一次聽老張用這麼堅決的語氣。
這不是抱怨,也不是推責,而是一種: 下定決心。
雖然公司已經導入了 Odoo,檢驗流程也能在 Quality Check 裡登錄,
但實務上仍然存在漏洞:
老張盯著系統裡一排「Pass」紀錄,悶聲說:
「如果只是多了一個按鈕,我們跟 Excel 時代沒什麼不同。」
阿哲忍不住湊過來:
「老張,你什麼時候會用 YOLO,還會搞 Telegram Bot 啦?」
老張咳了一下,笑得有點不好意思:
「哪會啊,我只是去 g0v 社群發了一個問題。沒想到真的有人回我,還丟了範例程式。」
阿哲驚訝:
「蛤?你隨便問,就有人幫?」
老張點頭:
「是啊,我本來也只是想求個方向。結果那些工程師不只給了範例,還跟我說可以先用手機拍照測試,不一定要一開始就買工業相機。」
阿哲翻了個白眼:
「所以最後程式還不是我幫你串進 Odoo 的?」
老張拍拍他肩膀,笑著說:
「沒錯啦,但我至少熬了幾個晚上,把手機拍照、上傳、辨識的流程試到能跑通。至於串接 Odoo,還是你比較在行。」
阿哲點頭:
「原來是兩步走,先省錢再擴張,這倒像你會想的方案。」
阿哲又忍不住吐槽:
「那為什麼不用 CNN?你在室內檢驗用 YOLO,不會有點殺雞用牛刀嗎?」
老張推了推眼鏡:
「CNN 當然可以做分類,判斷好或壞,但它告訴不了你瑕疵在哪。
YOLO 不只會說『有問題』,還能框出異常位置,而且速度快,適合生產線。」
阿哲半開玩笑地說:
「所以 CNN 是『知道有問題』,YOLO 是『指出問題在哪』?」
老張笑了:
「正解!」
老張參考社群範例,自己先把 YOLO 模型訓練跑通,還做了拍照測試。後來再由阿哲幫忙,把流程正式串接進 Odoo:
# 以 YOLO 模型偵測結果為依據,透過 Odoo API 自動建立檢驗紀錄
quality = env['quality.check'].create({
'lot_id': lot.id, # 對應批號
'product_id': product.id, # 對應產品
'result': 'fail', # YOLO 檢測結果:Fail
'picture': img_binary, # 上傳瑕疵照片
'note': yolo_result.get('defect_type', ''), # 瑕疵類型,如「刮傷」「污漬」
})
💡 其實,Odoo Quality 模組 本身就具備 量測點、照片上傳、報表分析 等功能;
老張導入 YOLO,並非取代,而是補強人為檢驗的盲區,
讓制度更即時、更客觀,真正落地。
(以下示意了從檢驗到報廢、索賠的自動化閉環)
[手機/USB 攝影機:檢驗工站]
↓
[YOLO 模型:瑕疵辨識]
↓
[Telegram Bot:推播檢驗結果]
↓
[Odoo Quality:建立檢驗紀錄]
↓
├─ 若為原料瑕疵 → [Inventory:更新庫存狀態為 Scrap]
└─ 同步通知 → [Purchase:啟動供應商索賠流程]
功能 | 模組 | 重點欄位 |
---|---|---|
檢驗紀錄 | quality.check | result, lot_id, picture, note |
不良報廢 | stock.quant | location_id, scrap |
供應商索賠 | purchase.order | state, claim_note |
即時提醒 | mail.activity | activity_type_id, deadline |
客訴事件中,德華救回的是客戶的心。
但老張這一次的「倔強」,救下的卻是整個制度。
品質不能只靠眼睛與經驗,必須被制度化。
而制度,必須被科技支撐,才能真正落實。
老張抬頭望著牆上的白板,補了一句:
「而且啊,這些品質數據,未來一定會派上用場。
到時候,不只是追蹤問題,更能展現我們的責任與改進。」
阿哲一愣,心想:
這傢伙,看得比誰都遠。