LGTM 諷刺 MV 在笑什麼？AI 寫程式、AI 審程式之後，人要簽的是哪一關
LGTM 諷刺 MV 在笑什麼？AI 寫程式、AI 審程式之後，人要簽的是哪一關。程式寫完、AI 也審過，最後只留一句 LGTM，就算驗收了嗎？這支同名諷刺 MV 把熟悉的開發口頭禪放進荒謬情境，笑點也落在責任被層層轉交的地方。
程式寫完、AI 也審過，最後只留一句 LGTM，就算驗收了嗎？這支同名諷刺 MV 把熟悉的開發口頭禪放進荒謬情境，笑點也落在責任被層層轉交的地方。
LGTM 是 Looks Good to Me，常用來表示審閱後覺得沒問題。當寫作、檢查與簽核都由代理接手，這句話究竟指向哪些證據，會變得更重要。
我會把作品當成討論開發流程的起點，再回自己的專案檢查。諷刺故事可以提醒問題，不能拿來證明真實公司的做法。
LGTM 這支 MV 是什麼作品？
創作者 Degenerative Pixels 的原始影片 以「LGTM (Looks Good to Me)」為題，結合歌曲和程式動畫。作者說明使用 Suno 製作歌曲，並以 Claude Opus 5.5、TypeScript 與 Three.js 製作動畫。
TypeScript 是程式語言，Three.js 則常用來做瀏覽器 3D 畫面。這條製作路線讓歌曲和程式畫面配合，與把文字直接交給影片生成模型的方式不同。
作品中的機器審稿與誇張數字屬諷刺敘事。引用時應保留作者與作品名稱，避免把歌詞情節寫成已查證的產業統計。
它提醒了哪一種審查問題？
當 AI 寫完程式，再用差不多的背景和假設檢查一次，可能只是把同一個理解重述成通過意見。檢查次數增加，未必等於獨立證據增加。
比較有用的做法，是讓審查者拿到需求、變更和測試條件，自己找能重現的問題。作者的「看起來可以」，也應轉成哪個情境已經測過。
例如匯出報表的功能，不能只查程式碼沒有明顯錯誤，還要拿空資料、不同日期與大量資料實際匯出，核對欄位和筆數。
最後簽核的人可以先看什麼？
先確認這次要解決的問題，再看修改是否對上需求。接著把自動測試、人工操作及尚未涵蓋的部分分開記錄，讓最後的決定有依據。
可以要求代理交這張短表：
| 欄位 | 要交的內容 |
|---|---|
| 改了什麼 | 使用者會看到的行為差異 |
| 怎麼驗證 | 可重現的步驟與結果 |
| 還沒測什麼 | 會影響完成判斷的缺口 |
這張表讓人能回到成品，而不只閱讀一段自信的總結。小改動用最小相關檢查，大變動再擴大範圍，驗收也比較有效率。
常見問題
MV 是 Anthropic 官方作品嗎？
來源是創作者自己的頻道。使用 Claude 製作和由 Anthropic 發布，是不同身分。
多個 AI 互審沒有價值嗎？
能增加找問題的角度，但仍要有獨立的檢查方法。重複同一句通過，資訊不會因此變多。
可以直接轉載整支 MV 嗎？
影片、歌曲與使用工具的授權分開處理。本文採原影片嵌入與連結，保留作者入口。
讓 LGTM 後面接得上一份結果
下一次簽核前，請代理交出重現步驟和實際輸出，再決定是否通過。這能讓一句簡短的審查用語，重新連回應有的證據。
