重點先講：我在 Facebook 發了一支短 Reel，講一個很多人每天都在經歷、卻很少說破的事：你以為是你在命令 AI，其實是 AI 在給你內容，你負責複製、貼上、遇到 bug、回報，再修正。一輪又一輪，到底誰才是操作員？這篇用工程和自動化的角度把它拆開，最後講怎麼把角色翻回來。
Reel 在講什麼
- 第 1 步：你下指令，AI 一口氣吐出一大段程式碼或設定。
- 第 2 步：你複製、貼到編輯器或 PLC 專案，存檔、編譯、執行。
- 第 3 步：出現錯誤訊息，你再把錯誤貼回去給 AI。
- 第 4 步：AI 道歉、給新版本，你再複製、貼上……回到第 2 步。
用控制迴路來看：設定值是你想要的功能，控制器是 AI，受控體是你的程式和設備，而「量測、回授」這一段全靠你手動抄錯誤訊息。在工廠裡，沒有人會讓操作員每個掃描週期都看一次錶、再把數字打回 PLC；但寫程式時，我們常常就這樣做。
工程重點 1：AI 看不到執行結果，所以一定要驗
聊天視窗裡的 AI 沒有你的執行環境：它不知道你裝了哪個版本的函式庫、PLC 韌體是哪一版、I/O 實際怎麼配。它只能「猜一個看起來合理的答案」。最典型的是幻覺套件：USENIX Security 2025 的論文用 16 個模型產生 57.6 萬段程式碼，推薦的套件裡約 19.7% 根本不存在；商用模型平均約 5.2%，開源模型約 21.7%。這些名字還可能被有心人搶註，變成供應鏈攻擊。再加上對話一長，前面講過的限制條件容易被忽略，你就會看到同一個 bug 修好又回來。
工程重點 2：「感覺變快」不等於真的變快
METR 在 2025 年做過一個隨機對照實驗：16 位資深開源開發者在自己熟悉的專案裡做 246 個任務，允許用 AI 的那組反而多花了 19% 時間，但他們事後仍自認快了 20%。螢幕錄影顯示，省下的打字時間被「看 AI 輸出、寫提示、等它生成」吃掉了。這正是 Reel 裡那個迴圈的成本。公平地說，METR 在 2026 年 2 月已經表示這份結果過時了，新工具可能真的變快，只是新數據證據力還很弱。重點不是 AI 好或壞，而是人在迴圈裡手動搬運的時間，沒有被算進去。
工程重點 3：把角色翻回來，先給規格和驗收條件
做過 PLC 專案的人都知道，開工前要先有 I/O 表、動作時序、連鎖條件，交機前要跑 FAT／SAT。對 AI 也一樣：不要只說「幫我寫一段程式」，而是先給規格、限制、輸入輸出範例和測試案例，例如「這個函式輸入 X 要回傳 Y、遇到斷線要在 3 秒內報警」。有了驗收條件，你就從「幫 AI 抄錯誤的人」變成「定義什麼叫完成的人」，AI 每次給的東西也能直接對著測試判斷對錯。
工程重點 4：把回授自動化，人只管設定值和最後放行
下一步是把「複製、貼上、執行、回報」這段交給機器：讓 AI 代理能直接在專案裡執行測試、讀錯誤訊息、自己修，再用 CI、靜態檢查、型別檢查擋住明顯錯誤。就像把手動抄表改成感測器直接接進 PLC，回授迴路閉合在自動化裡，人退到監督層：訂規格、審關鍵變更、決定上線。要注意，碰到實體設備的程式，還是要有模擬或安全連鎖，不能讓 AI 直接改現場。
還缺什麼／待核
- Reel 內容依作者描述撰寫；實際畫面與細節請以 Facebook 原片為準。
- 19.7% 幻覺套件率是論文測試當時的模型（含 GPT-4、CodeLlama 等），新模型的比例可能不同。
- METR 的 19% 變慢是 2025 年初的工具與特定情境；METR 自己已說明結果過時。
- 文中控制迴路與 PLC 的比喻是作者觀點，不是研究結論。
看完整 Reel
這個「人變成 AI 的複製貼上機」的畫面，Reel 裡演得更直接：
你用 AI 寫程式或寫 PLC 時，最常卡在哪一步？是複製貼上、找 bug，還是 AI 一直修不好同一個錯？留言聊聊，順便到 Reel 那邊分享你的經驗。
Reel：Facebook Reel
發佈於 vkinngworld｜影片頻道：@vkinng