領域知識太重的案子：工程師怎麼邊做邊學

2026 年從三月到九月，我大半年都在做同一個案子，一套給電力調度員練習跟考試用的模擬系統。九月案子結案，團隊也開了回顧會議，這篇把我自己的部分整理下來。

這是一個什麼樣的系統

電力公司的配電調度員坐在控制室裡，透過 SCADA 的圖控畫面遠端操作變電所的開關。操作錯了，是真的停電。所以他們需要一套不接真設備的模擬系統來練習跟考試，畫面長得跟真的一樣，開關會動、電驛會跳、警報會叫，但一切都在軟體裡。

考生在單線圖上做停復電跟事故處理，考官開場次、指派題目、監看幾十個考生，系統全程記錄每一步操作，考完由考官依紀錄評分。

技術上它是一個 Next.js 前端、幾個 NestJS 服務、一個模擬電力物理的引擎，中間用 RabbitMQ 跟 Socket.IO 把狀態推到畫面上。我負責前端，從三月初建專案開始，到單線圖的渲染、考試的操作介面、考官跟管理者的後台，一路做到驗收。

架構很快就定了，難的是另一件事

回頭看，系統架構在前兩個月就大致確立，後面沒有大改。真正花時間的是理解這個領域。

變電所長什麼樣、單線圖上每個符號代表什麼、電驛是什麼、什麼情況下會跳、警報跟事件有什麼不同、調度員處理事故的標準步驟是什麼。這些東西規格書裡有寫，但文字跟實際系統對不上，有些地方甚至前後矛盾。靠文字做出來的東西，拿給懂的人看，第一句話常常是「不是這樣」。我直接撞到的例子有好幾個。

單線圖上的著色規則，一開始我們以為「失電就整段變白」，後來才知道現場的畫面只有母線跟開關會變色，線段跟文字是固定色，而且聯絡開關的規則是反過來的，因為它正常狀態是開路。這條規則在六月才定下來，前面畫好的東西要重畫。

警報表的名稱欄也是一條，開關狀態改變的訊息看的是被操作的設備，保護電驛的訊息看的是保護對象，不帶開關編號。這是四月底一場會議裡一次講清楚的十幾條規則之一，在那之前我們的表格每一欄都是猜的。

時間的解析度也是，保護動作到開關跳脫只有幾十毫秒，秒級的時間看不出誰先誰後，調度員就判斷不了事故的因果，所以每一筆都要記到毫秒。這一條影響從資料庫欄位到前端顯示的每一層。

還有一條後來被寫進專案規範的規則，前端不可以用警報的文字去推斷設備的狀態。狀態的來源只有一個，就是模擬引擎掃描回來的點位。這條規則的背後是 SCADA 的本質，畫面只呈現事實，不做因果推理，判斷因果是考題在考的東西。

這四個只是例子，實際上每一條規則我們都撞過。每一條規則都不難，難的是你不知道它存在，直到做錯被指出來。

我們怎麼把領域知識補起來

三月底 MVP demo 之後，團隊發現文字規格撐不住，四月初做了一個關鍵的決定，改以逆向工程為主。拿到舊系統實際操作的錄影跟現場視訊，一幀一幀看畫面怎麼變、調度員怎麼操作，再回頭對照規格書，差異的地方以實際系統為準。

從那之後，每一場需求會議都是一堂領域課。會議都有錄影，資深同事把它們整理成逐字稿跟紀錄放進 repo，規則編號、日期、出處都記下來，後來專案的規範文件裡每一條規則後面都有「哪一天、哪一場會議、誰說的」。我做的是把跟畫面有關的規則一條一條對回前端，做錯了就回去翻紀錄，有爭議的時候也是回去查。

五月人力補強之後，團隊把題庫跟模擬數值的工作分出去，也在重構跟交付之間選了交付優先，只做驗收必要的功能。這個決定讓後面兩個月有辦法收斂。

七月開發完成進入驗收，八月的實機驗收又回來三十條意見，其中有幾條是我們「以為已經對」的規則。到這個時候，領域知識才算真的補到能交付的程度。

下次遇到這種案子我會怎麼做

回顧會議上大家對齊了幾件事，我自己的版本是這樣。

要求看舊系統，而且要早

有既有系統的案子，第一週就要拿到實際操作的 Demo 或錄影，文字規格只能當索引。我們四月才開始逆向工程，如果二月場勘的時候就做，可以省掉一整個月的猜測。

把規則寫成可以驗證的清單

規格書的一段文字沒有辦法驗收，「警報表名稱欄寫保護對象，不帶開關編號」這種一句話的規則才可以。我們後來的規範文件就是這樣寫的，每條規則附出處，前端照著做，驗收照著對。

會議當天就寫下來

領域專家講的話如果沒有當場記，兩週後就會變成「我記得他好像說」。逐字稿很花時間，但它是這個案子裡最有用的文件，我後來查規則都是靠它。

工程師要進去前期

這個案子的工作量是業務端估的，技術人員沒有參與，領域的深度也就沒有被算進去。回顧會議的結論之一就是投標跟啟動階段要有技術人員一起評估。這不是工程師單方面能決定的事，但至少下次我會更早把「這個領域我不懂，需要時間」講出來。

回顧

這個案子讓我第一次真正體會到，有些專案的難度不在技術。架構一個月就定了，領域知識補了半年。工程師在不懂領域的情況下接到需求，能做的就是承認不懂，然後用最快的方式去懂，看真的系統、問懂的人、把聽到的每一句話記下來、把規則變成清單。

心態上也有一個轉變，前面幾個月做出來的東西一直被推翻，很容易覺得是自己做得不好。後來才看清楚，推翻的不是程式，是我們對領域的理解，而理解本來就只能一次一次修正。接受這件事之後，每一次「不是這樣」都變成一條新規則，而不是一次挫折。