一次上傳 6 份資料查出 27 個問題：這位開發者用 AI 搭審查工具的背後，你的眼睛和肩膀也值得被檢查一遍

2026 年 9 月 1 日，掘金上出現一篇技術長文：一位署名「一隻牛博」的開發者，用 Qwen3.8-Max 搭了一個電商商品資料包的「體檢助手」。他把產品說明書、檢測報告、品牌授權書、平臺發布規則、商品資訊表和待發布文案，一共六份資料，加上一張商品圖，一次餵進系統，結果查出 27 個問題，其中高風險 25 個、中風險 2 個，結論是「不建議發布」。

這篇文章的讀者多半是工程師和電商從業者，但我們想從另一個角度看這件事：當一個人決定用 AI 把一件繁瑣的重複工作自動化，中間那些「先在網頁端把需求問清楚」「讓模型先讀資料再動手」「從 Mock 版本一路接到真實 API」的過程，往往意味著好幾個晚上的連續趕工。工具上線之前，先被過度使用的，常常是開發者自己的身體。

這個工具到底做了什麼，值得我們借鏡的思維

先回顧事件本身。原作者的痛點很具體：商品上架前，最花時間的不是寫標題，而是確認標題有沒有被說明書、檢測報告和平臺規則支持。六份材料分散在不同檔案裡，人工檢查要在視窗之間來回切換，逐項核對型號、規格、企業名稱、授權渠道和有效期，很容易漏細節。

他的做法有幾個值得注意的地方。第一，他沒有直接把「做一個審查工具」丟給程式編輯器，而是先在 Qwen3.8-Max 網頁端把業務流程、頁面、介面、驗收條件全部問清楚，模型給出的設計一路寫到第 25 部分，列出 16 項交付物。第二，他要求「每一條問題都要能定位到文件名和頁碼」，這個要求在後續迭代中沒有因為上下文變長而消失。第三，商品圖是直接以多模態訊息傳給模型處理，模型從圖片中提取出品牌、商品名稱、型號和淨含量四個欄位，再和六份資料一起做一致性檢查。

最後的運行紀錄也記得很清楚：模型呼叫 2 次，總共消耗 7739 個 Token，耗時 125.3 秒。他把圖片理解和文字審查兩次呼叫拆開記錄，方便分別判斷成本。

這裡頭其實藏著一個健康識讀的道理：他把「可回溯」當成整個工具的核心要求，每一個問題都要能指回原始文件。這跟我們在醫師說下週再來測一次背後的邏輯很像，任何結論如果不能回到證據本身，就值得多問一句「這是從哪裡看出來的」。無論是 AI 給你的審查報告，還是健檢報告上的異常標記，能回溯到來源的結論，才是你能採取行動的結論。

從 Mock 到真實 API：那段最容易賠上作息的路

文章裡有一段描述特別真實。開發者先建立 Vue 3 前端、FastAPI 後端和本地 Mock 規則引擎，先讓「上傳、解析、檢查、展示」這條路徑完整跑起來，之後才接上真實模型。

熟悉軟體開發的人都知道，這種「先跑通再最佳化」的路線理論上最穩，實際執行時卻最容易變成熬夜的藉口。因為每一個階段看起來都「只差一點點」：Mock 通了，就想趕快接真 API；API 通了，就想趕快看真實資料的結果；結果一出來 27 個問題，又忍不住想逐一驗證每一條是不是誤報。凌晨一點、兩點、三點，就是這樣一格格被填掉的。

如果你最近也在做類似的專案，有幾個實際可用的做法：

給每一次 session 設一個「可停下的驗收點」。原作者的設計裡有 16 項交付物和明確的驗收條件，這其實是很好的休息錨點。完成一個可驗收的環節就停，比「再改一個 bug」更容易真的停下來，因為「一個 bug」永遠會生出下一個。

把除錯和長時間盯螢幕分開。連續看 log 和比對文件是最傷眼睛的工作型態之一。每隔一段時間抬頭看遠處，讓眼睛的睫狀肌（眼睛裡負責調整對焦的肌肉）換個姿勢，比任何保健食品都實際。關於長時間用眼的具體調整，我們在桌面健康檢查裡有更完整的清單可以參考。

注意「心流」和「過勞」的界線。投入是好事，但如果出現躺上牀還在想程式碼、半夜醒來檢查部署、白天靠咖啡續命這些訊號，代表身體已經在跟你收利息了。這些不是道德問題，是生理訊號，值得像處理 bug 一樣認真對待。

27 個問題裡，藏著「證據強度」的活教材

回到工具本身，它查出的問題分成幾類：資料之間的型號、淨含量、品牌和商品名稱衝突；宣傳語超出證據範圍；授權渠道和有效期風險。

用健康的語言翻譯一下，這些其實就是「宣稱與證據的落差」。這正是我們在健康資訊識讀上最常提醒的事：一段文案說商品有某種功效，但它有沒有檢測報告支持？報告上的型號和實際商品一致嗎？授權還在有效期內嗎？

AI 工具能幫忙把這些比對做得又快又全，這是它的價值。但也要說清楚證據的層次：模型的一致性檢查是基於你餵進去的文件，文件本身如果造假或不完整，工具查不出「來源可信度」這一層。這跟醫學證據的概念相通，一個大型臨牀研究、一篇文獻回顧、一個個案經驗，可信度完全不同。AI 給出的 27 條問題清單，最後仍然需要人回到原始文件逐條複核，原作者自己也把「可回溯」設計成了硬性要求。工具再快，判斷責任還在人身上。

建立工具的人，也需要被建立休息機制

這篇文章讀下來，你能感受到那種「流程終於跑通」的興奮。但這類個人專案有一個隱藏成本：沒有deadline，也就沒有下班。全職工作之外擠出來的時間，往往直接從睡眠裡扣。

幾個溫和的提醒，給正在或打算做類似專案的你：

睡眠是欠不得的債。研究睡眠的領域有相當一致的共識：長期睡眠不足會影響注意力、情緒穩定和判斷力。而寫程式恰恰是最需要判斷力的工作，熬夜趕出來的程式碼，隔天常常要花雙倍時間修。這不是效率問題，是身體的運作方式。

肩頸和手腕的訊號別拖。打字到肩頸僵硬、手腕痠麻，是很多開發者的日常。短暫痠麻通常休息就好，但如果麻的感覺持續出現、或往手指延伸，特別是半夜痛醒，建議找復健科或家醫科評估，可能是腕隧道症候候羣（正中神經在手腕處被壓迫，造成拇指、食指、中指麻木）這類需要處理的問題。紅旗出現時，下一步很單純：掛號，讓專業判斷。

給專案設定「上線即放假」。工具跑通的那天，給自己一個真正的休息日。這不是獎勵，是讓身體從連續專注的模式裡退出來的必要程序。

結語：工具體檢資料，誰來體檢你

原作者替商品資料做了一次徹底的體檢，27 個問題、每條可回溯、高風險明確標示。這套方法其實可以直接搬到你自己身上：最近兩週的睡眠時數、螢幕時間、肩頸狀態、運動次數，也可以列成一張清單，逐項核對，找出衝突的地方，例如「計畫十一點睡」和「實際一點半睡」就是一條高風險的不一致。

不用查出 27 個問題才開始行動。挑一條最明顯的，今晚就修復它。你的身體，值得比商品資料更認真的一次審查。