預檢工具的原型開發
第六週｜Agent 時代的知識工作
從一個存在已久的問題開始
第五週的討論中，學員各自提出了想要解決的問題。本週接著以一個實際的開發案例，示範拿到題目之後如何進行。以下稱主導這次開發的人為開發者，這位開發者同時也熟悉這項業務。
題目是地震資料的品質檢查。這是組內存在已久的問題：承辦把完成的資料交出去，被主管退回，修正之後再交，有時又被退回一次。每一次退回，雙方都要重新打開同一筆資料，說明同一個問題。開發者想找一個方法改善，也想看看 AI 能不能在其中幫上忙。
做法是先用 AI 做出一個原型，也就是以 vibe coding 做一個有實際用途的網頁：用自然語言描述想要的東西，由 Agent 寫出程式，人負責引導、試用與回饋。這也是本週的 vibe coding 示範。學員不必學會寫程式，重點在於看清每一個設計決定從哪裡來，其他科別的同仁也可以把它當成「如何為自己的業務做一個原型」的例子。
本週呈現的整個過程，在軟體開發的階段中都還屬於最前面的需求階段。這個階段的做法是先快速把使用者會看到的畫面與操作設計出來，讓大家能夠想像完成的樣子，判斷它是否合理。網頁原型的用途在於確認目標，並不是交出一個可以正式上線的系統；目標確定之後，才回頭設計程式的架構。
案例依時間分為三個階段，每個階段整理出幾項設計重點。
| 階段 | 主要的工作 | 設計重點 |
|---|---|---|
| 分析現況 | 確定優化的目標；以文字描述想像的畫面；從投影片與紙本清單抽出檢查規則 | 減少來回的次數、好的設計要滿足的條件、分層攔截、工具的定位 |
| 釐清需求 | 把現況圖畫到能討論；向同仁確認分工與派工的方式 | 現況圖要畫到能討論、檢查放在必經的節點 |
| 製作原型 | 以真實資料與程式初步確認；做出畫面的雛形；對齊現有的介面；加強檢查結果的可讀性 | 先在實際的條件下測試、讓承辦不必重新學習、讓檢查的依據清楚一致、讓承辦能自己確認檢查結果 |
畫面是在最後一個階段才做的，但對畫面的想像從第一天就在。先有想像，才知道要整理哪些規則、要確認哪些資料；規則與資料確認過，畫面才不會做成一個空殼。
一、分析現況
案例的業務是地震資料的品質檢查。主管以派工網頁派發地震事件，承辦以定位軟體完成定位、產出定位結果檔之後自行檢查，再交給主管。主管檢視時發現問題就退回，承辦修正後再交。檢查的依據是一份訓練投影片與一張紙本清單。
整個流程除了大量仰賴人工，還會一再退回，需要重新處理的定位結果檔偏多，地震因此無法快速消化。
優化的目標：減少來回的次數
工作量目前以完成的件數計算。以件數計算時，先送出再說是合理的選擇，錯誤就留到主管檢視時才被發現，提交的錯誤率也就一直降不下來。這是衡量方式造成的結果，與個人是否認真無關。
| 衡量方式 | 承辦合理的選擇 | 結果 |
|---|---|---|
| 完成的件數 | 優先送出，錯誤留待主管檢視時發現 | 提交的錯誤率始終無法降低 |
| 來回的次數 | 送出前先排除可檢查出的錯誤 | 一筆資料從送出到通過，中間被退回的次數減少 |
因此這個案例把優化的目標放在來回的次數：一筆資料從送出到通過，中間被退回幾次。這也是第五週所說的以返工作為驗收標準，並在後面成為評估導入效果的指標。
要減少來回，方向是讓錯誤在提交之前就盡量被流程攔截。同仁之間的每一次傳遞都需要等待，錯誤越晚被發現，來回的成本越高；承辦在送出前自己發現並修正，則幾乎沒有等待。以下的分析都朝著這個方向進行。
好的設計要滿足的條件
設想自己要完整執行這件事，會先遇到幾個阻礙。拿到訓練投影片之後，要花上許多功夫才能大致理解內容。每次送出資料之前，又要把各個資料來源逐一打開，照著清單一項一項檢查，費力的程度足以讓人想要略過。即使願意完整執行，規則散在各處，檢查也只能依靠自己記得去做。
從這些阻礙回頭看，一個好的檢查工具應該滿足以下條件。這些條件也是之後檢視每一版成品的標準。
- 很快知道哪裡不對。 所有問題一次列出，並指出在資料的哪個位置。
- 知道如何修改。 每一項問題附上明確的處理指示，不必回頭查閱投影片。
- 不偏離原本的習慣。 操作方式與原本的作業相近，不必重新學習。
- 容易上手。 不必另外安裝程式，打開就能使用。
- 不讓人感覺受到監視。 結果先給承辦本人，不自動回報，也不統計個人錯誤。
條件都達到了，使用者用起來能比原本輕鬆，這就是好的設計。這一節對應第五週的需求工程：先確認要解決的問題與成功的條件，再決定做什麼。
分層攔截：先假設每一步都出錯
要決定哪些錯誤交給程式、哪些交給人，可以先假設流程中每一個步驟都出錯，再逐一檢視原本的流程能攔下多少，有多少會流到下一位承辦手上。依錯誤的性質，可以分成三層。
- 流程錯誤，以規則攔截。 時間格式、欄位範圍等有明確對錯的項目，由程式直接攔截。
- 執行品質，以物理限制篩選。 殘差、深度、定位誤差等沒有標準答案，但必須落在合理範圍內的結果，由程式篩選。
- 其餘項目，由人檢視。 前兩層都攔不下、需要看波形才能判斷的項目，才交給承辦。
這樣分層，人的時間就能留給真正需要判斷的地方。
案例中，開發者看過 Agent 依投影片畫出的第一版故事圖之後，認為重點應該放在錯誤被漏掉的地方，要求改畫「每一步都出錯」的情況；讀完 Agent 依此所做的說明，再歸納出這三層。這個分層之後成為整個工具的骨架。
工具的定位：減少承辦的工作
工具能不能被使用，取決於使用者覺得它是幫手還是負擔。從使用者的利益來看：承辦要願意使用，這個工具就必須真正幫忙減少工作，而不是監控程式，才有機會被普遍使用。
同一次討論中，也確定了另外兩項做法。第一，檢查依原本訓練投影片的步驟編排，不大幅改動大家熟悉的流程，每一項都有原本的文件可以比對。第二，現有的程式大多是老舊的 Windows 程式，第一版只以指令執行，必須在圖形介面完成的步驟改為提示承辦操作。
這三項決定來自對業務、同仁處境與現有環境的理解，Agent 無法自行提出。
同一天，開發者也先以文字寫下對工具畫面的想像：一份任務清單，分開列出程式已經完成的工作，以及需要承辦協助的地方。這時還沒有任何程式，但之後整理規則、確認資料與製作畫面，都朝著這個想像前進。
把難讀的投影片整理成文字與步驟清單，依開發者的方向重畫故事圖，並分析舊程式的類型與可以介入的方式。
二、釐清需求
現況圖要畫到能討論
第四週介紹的 Story 圖，目的是看出每個人或每個系統之間的交互關係。圖本身不能複雜到一比一反映現實，而要有某種程度的抽象，才能聚焦在要解決的問題上。
案例中，Agent 一開始照著投影片的規則，把每一項檢查、每一支程式都逐一列成圖上的活動。內容沒有錯，但整張圖看起來相當雜亂，也看不出重點在哪裡。
後來的修改是把圖整理成不同人與系統之間交互的階段，不再把具體的檢查規則一一列出，而是抽象成一份要檢查的項目清單，配上後續的處理流程：檢查、處理、再檢查，一直迭代到沒有問題，或轉為特殊案例處理，才能上交。細節收起來之後，才看得到資料實際在人與系統之間如何往返：承辦交出、主管退回、承辦修正後再交出。這個往返正是返工發生的地方，也是工具要介入的位置。
修改過程中，開發者一再要求「圖好像可以再更簡單」，並逐一調整活動的寫法，例如讓掃描由承辦發起而程式只作為工具、在人與程式之間補上動詞，使每個活動都能讀成完整的句子。
前後修改約二十次，最後收斂為三張遞進的圖：現況、假設承辦以現有工具完整自行檢查、導入工具之後。第二張圖畫出照規定完整做完時要走過的一大堆繁瑣步驟：分別執行數支檢查程式、對照紙本清單補查程式沒有涵蓋的項目、逐筆依經驗判斷如何處理、改完再重跑直到清單清空。畫出來就看得出步驟為什麼常被省略，問題出在流程與工具，而不在個人；即使全部照做，也還有舊程式本來就檢查不到的項目。學員畫自己的現況圖時，也可以多畫一張「照規定完整做完」的版本，分辨問題出在人還是出在工具。這是第四週「把圖修順」在真實業務上的樣子。每一版圖畫出來，才看得出哪裡太複雜，前一版本身就是下一版的依據。
檢查放在必經的節點
把現況圖整理清楚之後，分析現在的流程，會發現定位完成之後就可以直接上交，許多沒有檢查的錯誤因此流到下游的步驟，由主管檢視時才發現。這是目前最大的缺口。為了減少下游的工作量，流程上需要一個攔截這些錯誤的位置。
只要檢查需要承辦自己想到才做，就一定會有遺漏。比起提醒大家記得，更可靠的做法是把檢查放在流程上一定會經過的位置。
案例中，Agent 分析後發現定位軟體缺少一些防呆的措施，因此可以產出帶有簡單錯誤的定位結果檔；原本已有兩支檢查程式，卻不是流程上必經的節點。向同仁了解實際的作業方式之後，又得到兩項資訊：主管派發地震事件使用的是一個網頁介面，而且原本以為分屬兩個單位的資料處理與目錄維護，實際上是同一組。原本並列的兩種方案（工具放在送出端或接收端）因此取消，派工網頁則成為最合適的位置。承辦本來就要在這個網頁上提交成果，上傳之後先自動執行一輪檢查，列出問題並附上明確的指示，承辦不必再依靠記憶；規則明確的簡單問題，日後也可以由程式自動修正。
這也印證第五週的觀察：提出需求的人往往只看得到自己那一段，需求需要透過詢問逐步釐清。
重畫故事圖的每一個版本、分析定位軟體與舊程式的防呆缺口、整理要向同仁確認的問題、依新資訊改寫全部文件。哪一版的圖可以拿來討論、分工到底如何，則由開發者判斷與詢問確認。
三、製作原型
先在實際的條件下測試
開始做畫面之前，先建立開發環境，用真實的資料把檢查跑一次。建立開發環境時，目標是盡量還原生產環境。生產環境是軟體工程的用語，指系統實際上線、使用者每天作業的環境。原型要在接近生產環境的條件下測試，才看得出問題。用自己編的範例，只會驗證自己想得到的情況；換成真實的資料、真實的程式與真實的系統環境，投影片沒有寫到的問題才會浮現。
案例中，開發者向單位取得一個月內約一千筆尚未經過檢查的定位結果檔，以及舊檢查程式的原始碼，也確認了舊程式實際執行的系統環境。三者各自補上一塊只看投影片看不到的資訊。
- 真實的資料。 以這批資料執行掃描，才知道每一項問題實際有多常發生。例如「方位角空缺過大」一項就標出約四成的事件，這不表示四成事件都有問題，而是這項門檻還沒有定案。工具列出的是需要注意的地方，不是結論，門檻如何訂定仍需熟悉業務的人決定。
- 真實的程式。 讀原始碼才知道舊程式實際檢查了什麼，說明文件寫的不一定是程式的實際行為。這也是下一週規則溯源的起點。
- 真實的系統環境。 舊程式只能在 Windows 上執行，日後若要與舊程式的結果逐筆比對，需要在相同的環境中進行，這是下一週的工作。
因為前兩個階段已經把規則與流程整理清楚，掃描程式很快就寫出來了，這一步的重點在於讓原型面對真實的條件。
原型只用 Python 寫成，在日常使用的電腦上就能執行。若要做成自己用的小工具，記下用的是哪個 Python 版本、怎麼啟動即可，幾個月後自己再打開時才不會忘。要交給別人使用，或與舊程式逐筆比對時，才需要更嚴格地記錄環境，並準備與實際作業相同的 Windows 測試機，這些留到下一週。
有了規則與確認過的資料，才開始做畫面：先做出雛形，再對齊現有的介面，最後加強檢查結果的可讀性。以下三節依設計的目的整理，各自對應前面「好的設計要滿足的條件」。
讓承辦不必重新學習
這一節的目的是前面「不偏離原本的習慣」與「容易上手」：工具要能被使用，操作方式必須符合實際的作業，承辦不必另外學一套新的操作。
案例中，Agent 一開始沿用前一步的掃描程式，把網頁做成一次掃描整個月的檔案、產出一份總報表。技術上沒有錯，卻是過度設計：實際作業中沒有人需要一次看整個月的結果。開發者想像的實際作業，是每個人提交一個檔案，就針對那個檔案列出全部結果與建議，因此把工具導正回單筆提交，同日其他檔案只用來比對重複事件。
| Agent 的第一版 | 導正之後 | |
|---|---|---|
| 輸入 | 整個月的檔案 | 承辦提交的一個檔案 |
| 輸出 | 一份總報表 | 這個檔案的全部結果與建議 |
| 其他檔案 | 一起掃描 | 只用來比對重複事件 |
另一個重點是讓整個介面的設計語言與現有系統一致。承辦每天使用派工網頁，新的畫面若沿用同樣的欄位、排列、操作方式與配色，看起來就像原本系統多了一個功能，不必重新學習。案例中，Agent 原本做的是通用的上傳頁面；提供派工網頁的截圖之後，改為沿用既有的欄位與排列，只新增一欄「預檢」。之後的修改也都朝同一個方向：承辦自己上傳之後再按預檢、細節以派工網頁慣用的彈出視窗顯示、配色維持淺色。這些都是現場的資訊，Agent 事先無從得知，只能先依一般做法做出合理的版本，等人提供畫面與說明之後再修正。
要讓 Agent 理解現有的設計語言，截圖是最快的溝通方式：直接給一張圖，比用文字描述欄位、排列與配色快得多，也準確得多。手邊有現成的畫面、紙本表單或別人做好的範例，都可以拍下來交給 Agent 參考。
讓檢查的依據清楚一致
每一項檢查結果都附上修正指示，指示要可信，背後的規則就必須清楚、一致，而且說得出依據。做法是讓規則只有單一來源。一條規則原本散在規格表、門檻表、設定檔、說明文件與程式五處，各處的版本不一定相同，修改一個門檻也容易漏改。設計上改為單一來源：一條規則一個檔案，記錄門檻與說明，程式依規則檔執行，網頁上的說明頁也由規則檔產生。來源之間互相矛盾時，工具不自行決定，而是全部列出、標明出處，交由會議定案。做成自己用的小工具，做到這裡就夠了；規則的版本、修改紀錄與發布流程，是要交給同仁使用時才需要的機制，留到下一週。
案例中有兩次修正。第一次，開發者原本希望有一個友善的地方可以修改規則，Agent 依此做出網頁上的規則編輯、草稿與發布流程。看到成品之後，才發現介面過於複雜：規則是開會討論後才定案的東西，網頁不需要讓人修改，只要有說明的介面即可，編輯功能因此移除。需求在口頭描述時看似合理，做成畫面之後才發現過大，這正是以原型探索需求的用處。
第二次，開發者追問規則的編號是不是署內訂的。查證後發現，編號是 Agent 早期整理資料時自訂的，寫進多份文件之後，看起來就像正式代碼。工具尚未上線，修改成本最低，於是重新編號，並保留舊編號對照。這件事點出規則必須能夠溯源：每一條規則都要能追溯到投影片、紙本清單或舊程式中的出處，才分得出哪些是既有的規範、哪些只是 Agent 的整理。Agent 整理出來的內容，即使看起來很正式，也需要追問來源；下一週會把這件事做完整。
讓承辦能自己確認檢查結果
這一節的目的是前面「很快知道哪裡不對」與「知道如何修改」：承辦不只要看到哪裡有問題，也要能自己確認工具檢查得對不對。定位結果檔是固定欄位的文字格式，數值彼此的關係很難直接看出來，因此畫面分成兩層。
- 列表的快速摘要。 在事件列表上按下預檢，結果依承辦要做的事分組，例如需要協助、確認去向、重新定位、格式修正，每一項附上發現的內容與建議，並在原文中標出問題的位置。多數情況下，承辦看摘要就能知道哪裡不對、要怎麼修改。列表上的「詳細檢視」按鈕也加強為醒目的樣式，讓人一開始就知道可以點進去。
- 詳細檢視的逐一對照。 需要確認時，點進詳細檢視：左邊列出每一項檢查，右邊對照原始資料，能作圖的就作圖。看過第一版之後，又加上要求：標出每項檢查讀取的欄位，這樣才知道它在檢查什麼。最後的畫面中，點選任何一項檢查，包括通過的，原始資料中它讀取的欄位都以底色標出，有問題的值另以醒目的顏色標出；地圖、走時圖與規模圖呈現原始格式中看不出的數值關係；滑鼠移到數值上，則提示欄位名稱與解讀後的值。
一層讓人快速處理，一層讓人在需要時逐一確認。使用者不必讀程式，也能判斷工具是否檢查了正確的位置。
依舊程式的讀取格式寫出解析與掃描程式，以真實資料執行並統計各項問題的筆數；撰寫規則檔、三個網頁、四種圖表與自動測試，每次修正在數分鐘內做出新版並附上截圖；比對兩支舊檢查程式的原始碼，找出說明文件與實際程式不一致之處；規則搬進規則檔之後，以約一千筆真實資料重新檢查，逐筆確認結果與搬移之前相同。擔心全部預先檢查會太久時，Agent 先量測，一整天約一百三十個檔案不到 0.1 秒，才依結果決定整日一次檢查。
四、與 Agent 合作的方式
資訊越多，設計越貼近現實
回顧整個過程，設計每一次改變方向，幾乎都是因為取得了新的資訊：訓練投影片、舊程式的類型、派工網頁、實際的分工、原始碼與真實資料、現場的畫面與習慣，以及前一版的成品本身。每多一項資訊，設計就更貼近現實一些。與 Agent 溝通也是如此，提供的資訊越多，得到的設計越接近實際的需要。
| 取得的資訊 | 設計的改變 |
|---|---|
| 訓練投影片與紙本清單 | 整理出檢查規則，檢查依原本的步驟編排 |
| 舊程式是老舊的 Windows 程式 | 第一版只以指令執行，圖形介面的步驟改為提示 |
| 派工本來就是一個網頁 | 檢查放進上傳的節點，取消兩種方案 |
| 原始碼與一個月的真實資料 | 發現文件與程式不一致、門檻尚未定案 |
| 派工網頁的截圖與使用習慣 | 沿用既有欄位、彈出視窗與淺色配色 |
| 前一版的成品 | 刪去規則編輯，導正回單筆提交 |
人類工程師也是如此，資訊不足時只能先依合理的猜測完成手上的階段工作，取得新的資訊之後再重新對齊、修正設計；方向調整幾次，是開發的常態。
力氣花在哪裡
一般人對軟體工程師常有一個誤解，以為時間都花在寫程式上。實際上，軟體開發大部分的時間花在理解需求與設計架構，寫程式只佔其中一部分。Agent 能大幅縮短的，主要是寫程式這一段的實作。
這個案例的數字也是如此。開發對話中，開發者輸入的訊息共約一百二十則，其中約八十則發生在寫程式之前，用於讀懂投影片、畫出現況與釐清分工；寫程式的兩個階段合計約三十則。程式本身可以很快完成，前提是需求已經弄清楚、設計已經想好。Agent 讓實作變快之後，理解需求與設計的比重反而更明顯，而這兩件事仍需要熟悉業務的人投入。
Agent 縮短的是製作與查證的時間，人負責的是判斷。三個階段的分工如下：
| 階段 | Agent 做的事 | 人做的決定 |
|---|---|---|
| 分析現況 | 整理難讀的投影片、畫出故事圖 | 寫下好的設計要滿足的條件、提出攔截的三層、確立工具不能是監控程式 |
| 釐清需求 | 重畫故事圖的每一個版本、分析防呆缺口 | 決定哪一版可以拿來討論、向同仁詢問實際的分工 |
| 製作原型 | 寫出檢查程式與網頁、逐行比對原始碼、以真實資料估算影響，數分鐘內完成新版 | 提供現場的畫面與習慣、看到成品之後刪去過大的需求、追問 Agent 的整理是否有依據 |
回到自己的工作，人負責的這些判斷可以化為幾個與 Agent 合作的做法：主動提供現場的資料，例如畫面截圖、作業說明、既有的程式與真實的資料；以截圖溝通想要的設計語言；先做出一版，再依看到的成品提出修正；對 Agent 整理出來的內容追問依據；擔心效能時先量測，再決定。
這也回應第五週的三個條件。驗收標準是事先寫下的設計條件與規則檔，外部檢查是原始碼的比對、量測、真實資料的重新檢查與開發者的試用，判斷與責任由熟悉業務的人承擔，規則由開會定案。
五、之後的路
目前的狀態
本週完成的是需求階段的原型，而且只做到後面「分階段導入」的第一階段。
- 已經完成。 可以掃描、列出問題與修正指示的網頁原型。
- 尚未完成。 規則全部還在待確認的狀態；網頁是仿照派工網頁製作的示範，尚未接上實際的系統；承辦也還沒有實際使用。
- 對接之前要弄清楚。 派工網頁由誰維護、資料存放在哪裡、能否在伺服器端執行檢查。
返工是否真的減少，要等規則定案、正式對接、承辦用過之後才能確認。工具能夠完成，與是否解決了原本的問題，是兩件需要分開確認的事。
原型、自己用的小工具與正式工具
原型是用來確認需求的，某種程度上做完就要被丟棄，因此許多太細的工不必馬上做。但原型最後若要變成自己用的小工具，有些事就要顧及；若要交給同仁使用、接上實際的系統，要顧及的事又更多。三者的差別如下：
| 層次 | 用途 | 要顧及的事 |
|---|---|---|
| 原型 | 確認需求，做完可以丟 | 只要能看出合不合用 |
| 自己用的小工具 | 自己反覆使用 | 結果要對、下次打得開、改得動 |
| 正式工具 | 給同仁使用、接上系統 | 可以追溯、可以重現、可以維護，並有人負責 |
本週的範圍到「自己用的小工具」為止。做成自己用的小工具，需要以真實資料確認結果、有幾個基本測試、規則放在一個檔案、記下用的版本與怎麼執行、以版本控制保存，並大致記下每條規則的出處。不需要的，則是規則的版本與發布流程、與舊程式逐條對應的完整溯源、嚴格的環境驗證、與舊程式比對用的測試機，以及下一節的工程化與分階段導入、前測後測。這些都是要交給別人或取代原本流程時才需要的工作。
Agent 讓這些工作變得很快，所以很容易一路做下去；但原型的方向一改，提早做的工就會白費。先確認做到哪一層，再決定要做哪些事。
從自己用的小工具到正式工具
要接上實際的系統，讓同仁每天使用，就會出現許多自己用時不必處理的工程問題。
- 可以追溯。 每一筆檢查結果都要能回溯到當時的輸入檔、規則版本與程式版本，日後被問到「這筆資料當時為什麼通過」，能夠拿出依據。
- 版本化。 程式、規則與部署的環境都要有版本，知道目前線上執行的是哪一版，出問題時能夠退回上一版。
- 日誌與錯誤回報。 程式在伺服器上自動執行時，沒有人在旁邊看著。執行紀錄要保存下來，發生錯誤時要能通知負責的人，不能默默失敗。
- 自動測試與部署（CI/CD）。 每次修改程式或規則，都先自動執行測試，通過之後才部署到正式環境，避免一次修改讓原本正常的檢查失效。
原型與自己用的小工具階段，頂多有一些雛形，例如修改後執行幾個測試、以真實資料確認結果不變，但這些都只是開發者自己的習慣，還不是正式系統的機制。此外，要取代原本的流程，還需要逐支閱讀舊程式、確認每一條規則都有出處，並在與實際作業相同的環境記錄與驗證。真正對接時，必須先弄清楚派工網頁的實際架構，包括由誰維護、資料存放在哪裡、能否在伺服器端執行檢查，並與維護者一起設計，決定由誰負責日後的維運。這個案例的順序是先把業務流程大致收斂，再去研究如何對接。
vibe coding 能夠很快做出原型，用於探索需求相當合適，走到正式工具則需要上述的工程化。提出 vibe coding 一詞的 Karpathy，後來也把有工程紀律的專業用法另稱為 agentic engineering。兩者都使用 Agent，差別在於是否具備可以追溯、版本化、錯誤回報與自動測試這些機制。
分階段導入
工具的權限依可靠程度逐步放大，每一階段確認可靠之後，才進入下一階段。
| 階段 | 工具做的事 | 進入下一階段之前 |
|---|---|---|
| 1. 只檢查、不修改 | 掃描並列出問題與修正指示，所有修正由承辦自己做；程式不改動任何資料，風險最低，也最容易取得同仁的同意 | 確認檢查結果可靠 |
| 2. 自動修正 | 時間進位等規則明確的欄位由程式直接修正，並保留修改前後的內容 | 確認修正不會改錯 |
| 3. 自動重新定位 | 需要重跑定位程式的項目由程式代做 | 先以過去已定位的事件逐筆比對，結果一致才使用 |
| 4. 是否強制 | 要求每筆都通過檢查才能提交 | 等承辦實際用過、認為有幫助之後再討論，不以強制作為推廣方式 |
自動修正與自動重新定位都還沒有實作；需要人工辨識的項目，例如看波形判斷有無地震、依理論到時補挑近站、比對疑似重複的事件，目前只列為提示，交給承辦處理。這些功能一旦由程式代做，錯誤會直接寫進資料，因此每一項都要先更詳細地評估：規則是否明確、能否以過去的資料驗證、出錯時如何發現與復原。需要人判斷的項目，程式可以先把判斷所需的資訊整理好，判斷本身仍由承辦做；是否能進一步自動化，要另外以實際案例評估。
評估導入的效果
要確認工具是否解決了原本的問題，導入前就得先準備前測與後測，否則事後無法說明工具帶來了什麼改變。依第五週的原則，評估看的是返工，而不是使用率或速度。
- 前測（導入前）。 蒐集現行的退回紀錄：每筆事件從送出到通過來回幾次、退回的原因、送出時仍有哪些問題。這個案例以一個月尚未經過檢查的真實資料執行掃描，得到的問題分布可以作為前測的一部分。
- 後測（導入後）。 承辦實際使用一段時間之後，以同樣的方式再量一次：來回次數與退回原因、送出時仍有的問題，並以訪談或少量問卷了解承辦花在檢查上的時間是否減少。
前後兩次用同一套規則與同樣的計算方式，差異才有意義。這也是規則要有版本的另一個理由：比較時要能說明兩次各依據哪一版規則。每進入下一個階段，都以前一階段的結果作為新的前測。
長期的方向：在上游補上防呆
問題之所以會留到送出前的檢查才被發現，根本原因在於上游的定位軟體沒有防呆。預檢是在下游攔截錯誤，可以減少退回，卻無法讓錯誤不再產生。長期的解法是等挑波定位程式進行大規模更新時，把這些檢查條件寫進程式，在產出定位結果檔的當下就阻止錯誤。到了那個時候，規則檔可以直接作為更新的規格，短期的預檢工具因此也在為長期的修正累積規格。
下一週：規格階段
下一週接續這個案例，進入規格階段。做法是一步一步重現原本的流程：逐支閱讀舊程式的原始碼、逐頁比對投影片與清單，列出每一個來源實際做了哪些檢查，再確認每一項都被規則接住，或註明不納入的理由。所有規則都能追溯到來源之後，再以本週原型確定的畫面與操作為目標，回頭設計架構，重新寫出實現這些業務邏輯的程式。照著投影片直接重寫，容易漏掉舊程式實際在做、投影片卻沒有寫到的檢查。實際逐支讀過之後也發現，說明文件與程式的實際行為有好幾處並不一致，只看文件會寫出另一套規則。因此下一週也會在測試機上，以同一批真實資料執行舊的檢查程式，把它的結果與規則的結果逐筆比對。
開放討論與自主練習
講述之後的時間留給學員討論自己想談的題目，形式與第五週的工作坊相同：學員提出題目，在課堂上逐一討論。可以延續第五週收集到的問題，例如這件工作適不適合以 vibe coding 先做出原型、好的設計要滿足哪些條件、要提供 Agent 哪些現場資料，或單位若要導入，應如何分階段、如何以前測與後測評估效果。也可以提出與本週無關、但想討論的題目。
自主練習（選做）
想動手試試的學員，可以在課後或討論的空檔自行練習，遇到問題再於課堂上提出，課堂上不另外帶領。
- 題目：以 vibe coding 做一個單頁網頁，可以上傳一個定位結果檔，並畫出震央與測站的位置，以及各測站的到時與震央距的關係。
- 做法：分三次提供資訊，比較每一次的結果。第一次只給一句話描述想要的網頁；第二次加上欄位格式說明與範例檔；第三次再加上一張想要的畫面截圖，請 Agent 照著做。每一次記下補了什麼資訊、結果有什麼不同。
- 要求：做成單一 HTML 檔、不使用外部套件，以瀏覽器直接開啟即可；只使用課堂提供的虛構範例檔，不放真實資料。
- 提供的材料：課堂提供的虛構範例檔與一頁欄位格式說明。