昨天寫，那些規則不在文件裡，它們長在系統上。沒有人寫下來過，因為每個填單的人都是看著畫面反應，順手就處理掉了。

今天來聊聊我怎麼決定要用哪一種方式，去複製那些動作。

我考慮過三種方法：

第一種，直接寫進資料庫

這在 Day 18 講過，讀得到但寫不進去，沒有可以用的寫入管道，而我也不打算為了這件事去跟廠商開規格，最重要的是風險太高。

所以跳過這個方法。

第二種，讓 AI 看著畫面操作

寫成skill，讓cowork幫我完成，這是現在最直覺的做法。截一張畫面給ai看，告訴它欄位在哪，它就去點、去打字、去按 Tab。

這條路兩天就會動。

Day 18 寫的那些坑，負號打不進去、稅額會自己冒出來、最後一欄按 Tab 會多生一列，全部都是用這個方法踩出來的。踩完之後我把每一條都寫成規則，它就能把一整張單填完。

它真的會填。

但我沒有把這個方式給員工們使用，有以下三個理由。

理由一，我沒辦法確認它做對了

它填完之後，我要怎麼知道對不對。

能做的事情是再截一張圖，然後看。

問題就在這裡。看畫面正是它可能出錯的地方。如果它把某一格看錯了，那麼它回頭驗證的時候很可能用同一種方式再看錯一次。模型沒有變，畫面沒有變，解析的方法也沒有變。

執行跟驗證用的是同一雙眼睛。

Day 14 我寫過一件很像的事。那時候新系統做好了，我沒有把舊的那套關掉，因為舊的是從明細表自己算的，新的是從介面拉的，兩邊走完全不同的路。對得起來，才證明兩邊都沒錯。

今天這件事是同一個道理，只是換成了動作。驗證如果跟執行走同一條路，那它證明不了任何事。

理由二，它什麼都能按

畫面上除了欄位，還有儲存、刪除、取消。

一個能點 A 的東西，就能點 B。我可以在指令裡寫「不要按儲存」，但那是一句請求，不是一道牆。

而這張單是會產生會計分錄的正式單據。它一旦存進去，就是公司帳上的一筆資料。

這裡還有一個細節讓我更不安。那個系統裡有一組快速鍵，在某個畫面是用來開啟作業的，但在另一個畫面是儲存。同一組鍵，兩個意思，差別只在當下停在哪個視窗。

一個靠看畫面判斷自己在哪裡的東西，我沒辦法保證它每一次都判斷對。

理由三，每跑一次都要重新付一次錢

這一點我一開始完全沒放在心上，後來發現它比我想的嚴重。

看畫面操作的每一個動作都要先截圖，而每一張截圖都是 token。

這張單表頭十幾欄，下面三列每列又有八九欄。填完一格要再看一次確認填對了，中文打進去要放大檢查有沒有變成別的字，下拉打不開要重試。一張單跑完是上百次的「看」，而這還只是順利的時候。

重點在於兩條路的成本形狀完全不一樣。

寫一支程式，成本是一次性的，寫完就固定在那裡，跑一次跟跑一千次差別幾乎是零。看畫面操作，成本是每一次都要重付，而且跟表單的長度成正比，單子越長、欄位越多、重試越多次，就越貴。

而我要做的這件事，是每個月都要跑一次，內容幾乎一樣。對這種任務來說，這條路的成本結構根本是反的。它適合的是另一種事情，一次性的、沒有規律的、不值得為它寫程式的那種。

而且這不只是錢的問題。

消耗大代表一次能做的事情有上限。表單越長，越容易在中途撞到長度限制，撞到就得切段、重開、把前面的狀況重新講一遍。而每一次重新建立上下文，都是一道接縫，接縫就是會出錯的地方。

所以理由三繞了一圈，最後又回到理由一。

第三種，自己寫一支工具

我讓ai參考我原先skill的步驟，把它整個重寫了一次，寫成RPA的程式。

不用看畫面。 Windows 的桌面程式可以用程式直接取得欄位本身，不用去辨識螢幕上的一塊像素。

先校準。 每台電腦量一次，把表單每一格的位置存成定位表。之後填單的時候，視窗大小只要跟校準時不一樣，它就直接拒絕執行，不會憑感覺去猜。

邊填邊讀回來。 每填完一格立刻把值讀出來比對，不一樣就停在那一格，不往下走。

OCR 當第二道。 這一道的作用就是理由一講的那件事，讓驗證走一條跟執行不同的路。

只有三個功能。 試算、填寫、看狀態。沒有儲存，沒有刪除，沒有取消。

最後這一點我想特別講，不是我規定自己不按儲存，是這支工具裡面根本沒有「按儲存」這個能力。 它不存在，所以它不可能被誤用，也不可能被說服。

填完之後表單就停在那裡，最後一下由人自己按。

所以我真正的挑選標準是什麼？

我在比的從來不是哪一條路做得到，因為第二種方法和第三種方法都做得到。

我在比的是另外三件事。

第一，出錯的時候，我能不能知道它錯了。

第二，它最多能做到什麼程度。

第三，跑一百次的時候，這個方法會花多少錢。

其中第二件最容易被忽略，能力的上限本身就是一道護欄，而且是唯一一道不需要靠紀律維持的護欄。 規則會被忘記，提示詞會被改掉，但一個不存在的功能就能確保它永遠不會被呼叫，是最保險的方法。