AI寫文章、AI翻譯、AI檢查連結、AI統計流量、AI改文案，再讓AI繼續找問題。
做到某個程度後，會出現一個很奇妙的問題：
系統裡的所有人都太了解這個網站了。
製作者知道按鈕的用途。AI讀過規格後能推測意圖。營運者看過畫面太多次，小小的不自然也會被大腦自動補完。
第一次進來的人不會。
「這是什麼？」 「我要按哪裡？」 「為什麼突然換語言？」 「怎麼回去？」 「句子看得懂，但就是有點怪。」
真正有價值的就是這個「有點怪」。
所以最後出現了一個很直接的做法：
請第一次來的訪客實際用一用，指出哪裡看不懂、哪裡用起來彆扭。
每個有效問題1日圓，每人最高1,000日圓。
人類重新被放回自動化流水線，負責的模組叫「怪怪的」。
1. 要外包的不是程式碼審查，而是第一次使用時的卡點
目的不是請專家做大型稽核。
需要的是：
- 不知道按鈕做什麼
- 不知道下一步要去哪
- 標題或小標怪怪的
- 手機上不好按
- 相關文章跳到錯誤語言
- 按了一下頁面變空白
- 文法沒錯，但真人讀起來不自然
- 直覺覺得「這裡如果有某功能會比較方便」
Digital.gov把可用性測試描述為觀察使用者實際嘗試使用產品或服務的過程。[1] GOV.UK也指出，觀察真實使用者能發現語言、版面與任務完成上的具體問題。[2]
所以這不是AI時代突然發明的新儀式。
只是傳統可用性測試，重新回到一個能以機器速度生產與修改內容的網站。
2. 營運者本人有時反而是最差的測試者
「自己仔細看不就好了」只在規模小的時候容易。
文章變多、語言變多、操作路徑變多之後，每次全部檢查幾乎不可能。
而且營運者知道得太多。
知道搜尋在哪裡。 知道相關文章模組想做什麼。 知道語言切換規則。 稍微奇怪也會自動解釋成「本來就是這樣」。
另外還有一個現實問題：
手動一直看真的很麻煩。
這不是意志力問題，而是流程設計訊號。
與其要求自己每天巡幾百頁，不如把這一步拆出去。
營運者不一定要成為「看完所有頁面的人」，可以成為「決定什麼證據重要，並把發現變成修復流程的人」。
3. 1日圓買的不是點子，而是第一次來的人的眼光
如果把1日圓理解成顧問費，當然低得荒謬。
但真正買的東西不同。
買的是：
一個第一次看到網站的人，真的在這裡卡了一下。
一個人可以交很多項，但每人最高1,000日圓。同一問題只換說法，不會變成多筆計費。
上限很重要。
因為「請盡量多找」很容易突然變成：
「那我叫AI生一萬條改善建議不就好了？」
所以按件計酬必須搭配界線：
- 必須真的看網站
- 必須指出真實頁面、元素或行為
- 同義改寫不重複計算
- 明確設定總報酬上限
1日圓只是這個案例的實驗設計，不是普遍適用的合理報酬標準。如果工作耗時、專業或負擔高，報酬模式就應該改變。
4. 最糟的回報是「我用AI產生了一萬條改善建議」
不需要全面禁止AI。
問題是完全沒看產品，就產生一堆通用建議。
「改善導覽。」 「提升無障礙。」 「最佳化響應式設計。」
全部正確。
但都不是這次要的。
真正有價值的是：
「這個頁面的這個按鈕，我不知道按了會發生什麼。」 「這個小標之後主題突然跳掉。」 「只有這個語言版本的相關文章會跳回預設語言。」
AI可以在後面整理文字、合併重複、統一格式。
順序應該是：
人類發現，AI整理。
不要反過來。
5. 如果每一項都分開丟聊天，先累死的是委託人
想讓人指出很多問題，就得讓他們把發現的內容一起送來。
最痛苦的是無限聊天：
「第1項。」 「第2項。」 「對了還有第3項。」 「再補一個……」
測試外包了，卻生出新的手工作業：把回報重新收集。
所以應該批次交付：
- Excel
- 試算表
- txt
- 編號清單
- 任何可直接複製的純文字
截圖原則上不必強制。圖片有時適合解釋視覺錯誤，但文字更容易搜尋、去重、排序、交給AI做下一步處理。
GOV.UK的使用者研究指南也指出，打字筆記更容易保存與分析，每則筆記只保留一個清楚觀察點，也比較容易分類。[3]
格式可以很簡單：
位置 / 現況 / 建議
Bug則是：
位置 / 做了什麼 / 發生了什麼
6. 多語網站裡，「生成成功」不等於「真人讀起來正常」
12種語言的頁面都能產生，也不代表沒有問題。
- 某段仍留著原語言
- 按鈕翻譯奇怪
- 意思對，但母語者不會這樣說
- 文字變長把版面撐壞
- 切換語言後，相關文章又跳回預設語言
- 某個語言版本少了一段
每個人只需要看自己真的看得懂的語言。
機器確認：
有沒有生成。
人類確認：
正常人會不會這樣講。
兩者不是同一種測試。
7. 重複在計酬上是一筆，但在分析上可能是黃金
同一個人用三種說法抱怨同一個按鈕，只算一件。
但三個互不相關的人都在同一個按鈕卡住，就完全不同。
這不只是重複。
這表示不同的人也會在同一個地方看不懂。
所以分析時要區分：
- 同一人的同義改寫 → 合併
- 不同人的獨立相同回報 → 保留頻率
「三個人都在這裡迷路」比營運者個人不喜歡某個設計更有證據力。
GOV.UK服務標準也建議持續用實際或潛在使用者做可用性測試，並在符合真實使用行為的裝置範圍上測試。[4]
8. 完整流程是 AI → 人類 → AI
流程可以變成：
- AI產生文章
- AI翻譯
- AI檢查已知技術與結構條件
- AI修已知問題
- 人類閱讀、點擊、猶豫、迷路
- 人類把「怪怪的」用文字交出來
- AI去重
- AI按問題有多大、會不會再次出現、修起來費多少工夫分組
- AI產生或執行修正
- 再跑機器檢查與人工檢查
人也回到了檢查網站的工作裡。
但留下來的角色不是機械重複。
機器能找到404。 人類能說：「連結有開，但我完全不知道為什麼被帶來這裡。」
機器能確認翻譯字串存在。 人類能說：「真人根本不會這樣講。」
這種分工更自然。
9. 測試會自然增加PV，但PV不是商品
如果測試者真的看了幾十頁，瀏覽量當然會增加。
有廣告的網站，也可能在正常瀏覽時產生一般廣告曝光。
但那只是副作用。
不要把廣告點擊或曝光量變成工作條件或報酬條件。
買的不是流量。
買的是：
因為真人真的看過頁面而留下的觀察。
10. 自動化的終點不是「零人類」
自動化很容易讓人把目標想成「把每個步驟的人都拿掉」。
但做深之後，可能得到相反答案：
不是刪除人類，而是把人類移到只有人類才有價值的位置。
草稿、翻譯、去重、連結檢查、分類、統計、修正建議，可以交給機器。
最後只向人類買：
「第一次看不懂。」 「這裡很煩。」 「這裡怪怪的。」 「這功能有的話很好。」
1日圓買的不是一句文字。
買的是一個不共享營運者假設、不共享AI上下文的人，在某一瞬間感到的違和感。
自動化走到最後，人類回來了。
職稱：怪怪的偵測器。
可能反而是整套系統裡最像人的工作。
參考資料（4筆）
- 觀察人們實際使用服務 digital.gov
- 讓使用者實際操作 gov.uk
- 記錄觀察結果 gov.uk
- 讓服務更容易使用 gov.uk
