過去十天在搏鬥什麼 — The Hard-to-Verify Detour

一句話收 Day 11-20: 文字沒有客觀判准. 一段話對不對, 要人讀、要查證、要主觀判斷; 是不是 AI 寫的, 頂多給你機率、給不了鐵證. 累的根源在這 - 人就是唯一的 bottleneck.

原話 (jason3e7):

過去十天花了很多時間, 探討了比較難驗證的文字產出; 接下來要回到比較容易驗證的主場, 程式的產出。

回到主場: 程式為什麼好驗 — Back on Home Turf

程式跟文字最大的差別, 一句話: 程式有判准, 文字沒有. 判准指「一個能自動告訴你答案對不對的東西」 - 編譯器、執行、測試、diff 都是; 文字幾乎沒有, 沒有「編譯器」會告訴你這段話寫錯了。

關鍵在這句: 錯的程式大多會自己冒出來, 錯的文字只會靜靜躺著。 一個 exception、一條紅色的 CI, 是程式在對你喊「這裡不對」; 一段邏輯怪怪的文字不會喊, 它看起來一樣通順。

驗證難不難不是是非題, 是一條光譜。把文字跟程式擺一起看最清楚:

表裡那幾個特性 (客觀、快、可自動化、可重現), 文字一個都給不了。對「驗 AI 產出」這是天大的好消息: 前十天人是唯一的 bottleneck, 回到程式, 機器能幫你擋掉一大半。

註： 不是說程式「一定好驗」、文字「一定沒救」。有些程式超難驗 (並行、分散式、浮點數、UI), 有些文字有明確事實可查 (數字、日期、引用來源)。重點是平均而言程式靠光譜「好驗」那端近得多 - 而且它好驗的理由 (有判准、錯誤會自曝) 剛好是文字最缺的。

一個現成的判准: online judge — A Ready-Made Verifier

最乾淨的例子是 online judge (線上解題系統, 像 ZeroJudge)。你把程式丟上去, 它拿一堆藏起來的測資跑你的 code, 回一個判決: AC (通過)、WA (答案錯)、CE (編譯錯)、TLE (超時)⋯ 這不是「我覺得不錯」, 是一個客觀、秒級、可重複的結果 - 判准長這樣最清楚。

我實際接了一條全自動的小迴圈來玩這件事 (用 Playwright 操作瀏覽器送題):

寫 .cpp  →  本機 g++ 編譯、跑範例  →  Playwright 自動上傳  →  判題回 AC/WA/CE/TLE  →  不過就讀訊息改, 再送

結果: a001、a002、a003 三題都第一次送就 AC。這不是運氣, 是因為上傳前先在本機用同一版 g++ (-std=c++17) 把範例跑過 - 等於先對著判准自測一輪, 再交出去。這就是「有判准」的威力: 你不用猜對不對, 跑一下就知道; 連送出、讀結果都能讓機器代勞。

換成文字呢? 一篇文章沒有「判題系統」會回你 AC 還是 WA。這就是主場跟客場的差別。

綠燈不等於對 — Green Doesn't Mean Correct

回到主場不代表從此輕鬆。程式的判准很強, 但有邊界, 不認清這點會踩更大的坑 - 因為它給你一種「有在驗」的安全感。

Program testing can be used to show the presence of bugs, but never to show their absence.
— Edsger W. Dijkstra

這句話是整段的核心。幾個具體的陷阱:

• 測試只驗你想到的 case。你沒想到的那個 edge case, 照樣安靜地爆。綠燈的意思是「我寫的那些檢查過了」, 不是「全對」。
• 能編譯、能跑 ≠ 做對的東西。這是驗證 (verification, 把東西做對) 跟確認 (validation, 做對的東西) 的差別。AI 很會把一個錯的需求實作得又乾淨又能跑。
• 有些錯不會讓燈變紅。安全漏洞、效能退化、資料外洩, 常常測試全綠照樣存在 - 因為沒人寫測試去抓它。
• AI 會「幫你」讓燈變綠。叫它修到測試過, 它可能改測試、而不是改程式。判准被它繞過去了。

註： 上面那個 online judge 其實是個比自測更強的判准 - 它有出題者寫的隱藏測資, 會抓到你自己沒想到的 case (WA 就是這樣冒出來的)。但那是解題題目的奢侈: 真實世界的程式很少附一套完整判題, 多數時候判准得你自己建 (寫測試) - 一旦自己建, 又回到「只驗你想到的」這條限制。judge 幫你驗的是「答案對不對」, 驗不了「這題該不該這樣解」。

所以主場不是「不用驗了」, 是「驗得動了, 但要補上機器驗不到的那幾關」: 你想要的終點是什麼、哪裡是不能踩的紅線、誰來看 AI 到底動了什麼。

Sources

• Day 11: AI 給的答案, 你怎麼知道是對的 — 前十天那條驗證線的方法論底本
• Day 12: 為了方便人類驗證而生的兩個 skill — 把難驗的長輸出變得驗得動的手法
• Day 13: AI 用久了會鈍化 — 為什麼「人當 bottleneck」會累、會鈍 (驗證疲勞)
• ZeroJudge — 文中用的線上解題系統 (現成的判准)
• Playwright MCP — 讓 AI 用 MCP 操作瀏覽器 (自動送題那段用的工具)
• E. W. Dijkstra, "The Humble Programmer" (1972) — "testing shows the presence, not the absence of bugs"
• Verification vs Validation (Wikipedia) — 把東西做對 vs 做對的東西