自動化的舊夢:Codex 的 Record & Replay,這次真的不一樣嗎

前言:連名字都不是新的

每隔一段時間,自動化就會被重新興奮地講一次。這一次的句子是這樣的:你把一件重複的工作做一遍給它看,它就學會了,以後自己重播。

聽起來很新。但只要把這句話翻成英文 — record and playback — 就會發現它一點都不新。

「錄一次、之後重播」這個詞,在自動化的世界裡已經被講了幾十年。早在 GUI 軟體開始普及、手動測試變得又慢又累的年代,第一批測試自動化工具走的就是這條路:讓人把操作做一遍,工具像錄音機那樣把滑鼠點擊與鍵盤輸入記下來,之後反覆重播來驗證軟體有沒有壞。後來不少 RPA(機器人流程自動化)工具,也把 recorder、record and playback 當成重要入口;再往前推,個人電腦上的巨集錄製更早就在做同一件事。

所以,當我們看到 OpenAI 為 Codex 加上 Record & Replay,把一個流程做一次給它看、它整理成可重用的技能 — 機制細節篇①已經拆過了,這裡不重講 — 比較誠實的反應,或許不是「哇,這太神奇了」,而是先把那段歷史回音聽進去:連名字都是借來的。

這不是要潑冷水。一個夢做了幾十年還在做,通常代表它真的有價值、只是一直沒做好。所以該問的,從來不是「它做不做得到」 — 這題前人早就用各種方式做到過了 — 而是更難、也更值得的那一題:這一次,它解掉了哪些幾十年沒解的老問題,又留下了哪些?

這次確實不一樣的地方

先把該給的分給足。比起傳統的巨集與 RPA 錄製,Codex 這一代的做法,至少有三個方向是真的往前挪了。

第一,它記的是意圖,不是座標。 傳統錄製的脆,脆在它記的是「在螢幕 (840, 220) 的位置點一下」這種死板的動作。介面一改版、按鈕一挪位,整段就對不上、當場壞掉。意圖式的記法換了一個層次:它試著看懂你這一步「想完成什麼」,而不是「手怎麼動」。目標對了,執行的路徑就有彈性 — 按鈕換了位置、版面小改了,它有機會自己繞過去。這對長年被「一改版就全壞」折磨的人來說,是體感上的差別。

第二,它用 agent 的工具去達成目的,而不是複製一串死動作。 重播的時候,它不是把當初那段操作原封不動倒帶,而是依當下情況,該操作電腦的操作電腦、該開瀏覽器的開瀏覽器、該呼叫外掛的呼叫外掛。換句話說,它重播的是「做這件事」,不是「當時那幾下」。這讓它在面對小變化時,比逐格倒帶的舊做法更有迴旋餘地。

第三,它產出的是一份可讀、可改的說明書,不是一段黑箱錄影。 這點容易被忽略,卻可能是最耐想的。傳統錄製吐回來的東西,要嘛是一段你看不懂的腳本,要嘛是一團封在工具裡的設定,出了錯很難從外面修。Codex 把示範整理成一份「技能」:什麼時候該用、需要哪些輸入、分哪幾步、怎麼確認做對了 — 寫得不對,你可以直接讀、直接改。這種「把自動化變成一份人看得懂的文件」的方向,正是篇②談到的那股收斂:多家 agent 產品採用同一套開放格式,把可重用的流程寫成一份可讀可改的說明書。從「黑箱」走向「說明書」,確實是進步,該承認就承認。

這三點疊起來,讓人理解為什麼這次的版本看起來比舊夢更接近「成真」。它把幾十年來最惹人厭的那個老問題 — 介面一動就脆 — 至少削掉了一角。

沒解掉的老問題,大多還在

但削掉一角,不等於整面牆都拆了。RPA 幾十年累積的老病,agent 版本多半還在,有些甚至換了個更難察覺的形狀。

脆,並沒有消失,只是門檻變高了。 意圖式理解能扛住小改版,但介面要是大改、流程要是被重新設計,它一樣會跟不上。早期自動化測試工具那句老話「一個按鈕標籤改了,整個測試就毀了」,今天不會因為一次小調整就應驗,卻會在更大的變動面前重新成立。韌性買到的是「容忍小變動」,不是「對任何變動免疫」。

可靠度,仍然帶著機率性。 這是 RPA 時代就有、AI 也沒解掉的老問題:同一套流程跑十次,你很難打包票十次都一模一樣 — 用比較口語的說法,仍然有點像在抽卡。意圖式的理解讓它在「看懂」上更聰明,卻也因此引入了一種傳統巨集沒有的變數 — 它對意圖的解讀,本身就帶著機率。多數時候對,但「多數時候」這四個字,在某些流程裡是可以接受的,在另一些流程裡是災難。

最棘手的,是那種「安靜的失敗」。 篇①已經點到這個概念,這裡想往下深化一層。傳統巨集的失敗很吵:介面對不上,它當場停、當場報錯,你一眼就知道出事了。意圖式的重播剛好相反 — 它的失敗很安靜。因為它在「理解並達成目的」,所以即使理解歪了,它往往不會停下來,而是照著它「以為」的目的把流程跑完,結果看起來一切正常,只是做的不是你要的那件事。這種錯不會跳紅字,要等到下游、甚至月底對帳才浮出來。韌性與這種安靜的失敗,其實是同一枚硬幣的兩面:它越能自動消化小變動,就越可能把那些其實該停下來問你的情況,也一起無聲地消化過去。

還有一道最被低估的老問題:RPA 幾十年真正卡住的地方,根本不在「能不能錄」。 能錄、能播,從來不是難點;難的是錄完之後那條長尾 — 流程一變,誰負責回去把技能重新校準?碰到沒示範過的例外,它該停下來問、還是自作主張往下做?哪些技能能動到哪些系統、用誰的權限去跑,由誰來管?這些「維護、例外處理、權限治理」的事,才是 RPA 專案真正燒錢、也真正出事的地方。Codex 這一代把「維護的介面」做友善了不少 — 技能變成一份人看得懂、改得動的說明書,校準起來確實沒那麼痛。但它改善的是「改起來順不順」,並沒有消除「誰來盯、誰來管、出了例外算誰的」這層治理問題。錄製從來不是這個舊夢真正的牆;治理才是。

而官方自己,也把這條線畫得很清楚。 OpenAI 的 Record & Replay 文件直接建議:挑那些你「已經知道怎麼完成」的流程來錄,而且它最穩的場景,是「步驟固定、成功標準清楚」的那種。這句話值得正著讀,也值得反著讀:正著讀,是它在主場很好用;反著讀,是凡是步驟會變、或成功與否難以一刀切的流程,它就進入了不保證的地帶。一家公司願意主動把適用邊界講出來,是誠實;但也正提醒我們,意圖式自動化在帶來韌性的同時,確實同步帶進了新的不確定 — 它越懂得隨機應變,你就越難事先框死它到底會怎麼變。

一個冷靜的判準:誰該試,誰先別碰

把優點與老問題都擺上桌之後,問題就從「這東西好不好」變成一個更務實的問句:哪些流程適合現在就試,哪些該再等等?

可以先試的流程,往往有幾個共同特徵:

• 容錯度高。 偶爾跑歪一次,損失有限、補救得回來,不會一錯就釀成大麻煩。
• 有人會覆核。 結果有個人或一道檢查會看過去,而不是跑完直接送出、沒人再回頭看。
• 介面相對穩定。 操作的系統不三天兩頭大改版,意圖式理解的韌性才用得上。
• 對錯分明。 做對做錯一眼看得出來,「安靜的失敗」就藏不住,出了問題抓得到。

拉每週固定報表、把試算表資料逐筆建成設定好的工單、整理格式統一的檔案 — 這類「長得一樣、做錯看得出來、出錯也補得回來」的事,正是它的主場,值得拿低風險的流程先試水溫。

反過來,目前傾向先別整段託付的,通常是另一組相反的特徵:一步錯就難挽回(動到錢、動到對外發送、動到難以回復的資料)、需要臨機判斷(每一步都要看情況拿捏,沒有固定的對錯)、又沒人盯著(跑完直接生效,沒有任何人會在事後覆核)。這三者只要疊上兩個,風險就開始失衡。

說到底,這個判準的核心不是「它做不做得到」 — 多數流程它跑一兩次都做得出來 — 而是換成那個更該問的問題:這件事萬一它某次做歪了,我承不承擔得起、又看不看得出來? 承擔得起、又看得出來,就可以放手試;反過來,就先把它留在自己手上,或至少在它和「按下確認」之間,留一個人。

結尾:刻度被推了一點,拉扯沒有消失

自動化從來不是一道「能不能」的技術題,而是一場「省力」與「失控」之間的拉扯。每一次工具變強,我們省下的力氣就更多;但省力的同時,我們也把更多原本握在手裡的判斷,一點一點交了出去 — 交出去得越多,真正出事時,我們離現場也就越遠。

Record & Replay 把這把尺往「省力」那一端,確實推了一點點。它讓「錄一次、之後重播」這個幾十年的舊夢,在介面韌性與可讀性上,比前幾代更像樣了一些。這是真進步,不必假裝沒看見。

但它沒有、也不可能取消掉那場拉扯本身。它消化小變動的能力,同時就是它可能安靜地替你做錯決定的能力;它越聰明地理解你的意圖,你就越難在事前框死它會怎麼理解。舊夢往前走了一步,代價是它的失敗變得更安靜、更難被你當場抓到。

所以也許,面對這一代自動化,最務實的姿態既不是興奮地全盤交出,也不是懷疑地完全不碰,而是停在中間問自己一句:這件事,我是想「省力」,還是只是想「不想再碰它」?如果是前者,我願不願意為了省下的力氣,在它和結果之間,繼續留一隻自己的眼睛?

這把尺該停在哪,沒有標準答案。但至少,別讓「它好像真的會了」這份驚喜,替你把眼睛也一起省掉。