一套科技執法系統幾乎不會單獨存在。實務上至少要介接六類既有系統：監理資料交換（M3）、機關的公文與檔案管理、路口主檔與 GIS 圖資、影像來源與監控平台、車籍與身分查詢，以及對外通知與機關單一登入。招標前沒有把這六類逐一盤點，規格書就只能寫出「應與既有系統完成介接」這種沒有驗收效力的句子，等到履約才發現有一半的介面根本不在承商可以決定的範圍內。
介接之所以值得單獨寫一篇，是因為它有兩個和其他工項都不同的性質。第一，它同時牽涉兩個以上的主責單位——對方系統的維護廠商、對方機關的資訊窗口，都不是本案的承商可以指揮的對象。第二，介接故障通常是無聲的：網站看起來正常、後台登得進去、案件也建得起來，只有送往下游的那一批資料悄悄停住，往往要等到承辦人發現這幾天紅單數量不對，才回頭查。
這篇把「一個機關同時要接幾套系統、各自的規格與風險」攤開講。整條紅單的作業流程（八個關卡與 M3 在其中的位置）在科技執法一條龍全流程解析那篇，本文不重述；規格書的整體寫法與綁標紅線見科技執法標案規格書怎麼寫，本文只補「介接這一類條文」該怎麼落筆。
科技執法系統要介接哪些系統？六類對象一次盤點
下表是盤點時建議照著填的四個欄位。資料方向決定誰是主動的一方，也決定失敗時誰先發現；「沒接好的後果」那一欄請寫成承辦人看得懂的具體症狀，而不是技術名詞——因為它最後要變成規格書裡的驗收項目。
| 介接對象 | 資料方向 | 常見型態 | 沒接好的具體後果 |
|---|---|---|---|
| 監理資料交換（M3） | 本案系統送出 | 標準格式批次交換 | 案件卡在警政與監理的交界處，紅單開不出來，逾期就報廢 |
| 公文與檔案管理 | 雙向 | 取號介面或檔案交換 | 申訴與陳情回覆進不了正式公文流程，承辦要把同一份內容重打一次 |
| 路口主檔與 GIS 圖資 | 本案系統取用 | 主檔同步或圖資服務 | 違規地點變成自由輸入的文字，同一個路口三種寫法，統計與成效報表做不出來 |
| 影像來源與監控平台 | 本案系統取用 | 串流協定或事件推播 | 調不到原始母檔，只有判讀後的截圖，申訴時證據鏈接不起來 |
| 車籍與身分查詢 | 送出查詢、取回結果 | 授權查詢介面 | 車號、車種與顏色無法自動比對，需要人工逐件查，退件率升高 |
| 對外通知與機關單一登入 | 通知送出、身分取用 | 通知介面與目錄服務 | 民眾查不到案件進度而重複檢舉；操作紀錄對不到真人帳號，稽核軌跡失去意義 |
逐項說明盤點時要問到什麼程度：
- 監理資料交換（M3）：這是整條鏈路上不可替代的對外出口，也是格式最不能自己決定的一段。盤點時要確認的是現行採用的格式版本、退件（受理失敗）的回饋方式，以及對方有沒有測試環境。部分機關的規格書把它寫成「界接」，指的是同一件事，投標前先確認招標文件用的是哪一種寫法，以免評選時被認為答非所問。
- 公文與檔案管理：重點不在技術，而在「哪些動作必須留下公文文號」。通常是對民眾的正式回覆、跨機關函送、以及涉及裁決的文件。要問清楚取號是由公文系統主動配發還是本案系統呼叫，附件容量上限多少，以及對方系統是否限制來源網段。
- 路口主檔與 GIS 圖資：先確定路口代碼的權威來源是哪一個單位維護、更新頻率多久一次。沒有主檔就沒有可比較的地點欄位，後續的點位檢討會全部退回人工整理；這也是科技執法點位怎麼挑那篇把「建立路口主檔」列為資料清洗第一步的原因。
- 影像來源與監控平台：機關手上常常已有既設的監控系統，本案要接的可能只是其中幾支鏡頭。要問到影像調閱的介面形式、原始母檔由誰保管、保存天數，以及本案系統取用時會不會佔用對方的頻寬與授權數。母檔與判讀輸出為什麼必須分開保存，見交通違規證據鏈要保存什麼。
- 車籍與身分查詢：這一類介接的風險不在技術而在個資。要寫清楚授權查詢的範圍、每日查詢量上限、回傳欄位只取比對所需的最小集合，以及查詢紀錄保存多久。凡是能用代碼比對的欄位就不要落地儲存明文。
- 對外通知與機關單一登入：通知是降低重複檢舉最便宜的手段——民眾收到案件編號就不會再送一次。單一登入則決定稽核軌跡能不能對到真人：如果系統自建一組共用帳號，操作紀錄再完整也證明不了是誰做的。帳號的開立與停用要跟著機關的人事異動走，不要另開一套。
四種介接型態怎麼選？API、檔案批次、資料庫直連與訊息推播
選型的判準不是哪一種比較新，而是四個問題：需不需要即時回應、單筆還是大量、對方能提供什麼、失敗之後能不能重送。四個問題答完，型態通常就只剩一個選項。
| 型態 | 適合 | 不適合 | 必須配套 |
|---|---|---|---|
| 即時查詢介面（API） | 單筆、要立刻拿到結果：車籍比對、公文取號 | 一次幾萬筆的批次匯出 | 逾時設定、重試次數上限、對方限流時的降級處理 |
| 檔案批次交換 | 大量、可容忍數十分鐘延遲、對方系統較舊：監理交換、統計報表 | 需要立即回應的查詢 | 檔名規則、產檔完成的旗標檔、取檔後搬移或改名避免重複處理 |
| 資料庫直連 | 同一機關、同一維運團隊、且只讀 | 跨機關、跨廠商、需要寫入 | 唯讀帳號與檢視表、欄位變更的事前通知義務 |
| 事件推播（訊息佇列或回呼） | 狀態變更、影像事件這類「發生了才送」的資料 | 需要保證順序且不容許重複的帳務型資料 | 去重鍵、重送機制、接收端的冪等處理 |
資料庫直連是最常被選、也最常後悔的一種
它在開發階段確實最省事：不必定規格、不必等對方開介面，連上去就有資料。代價要到第二年才顯現——對方系統改一個欄位長度、換一次版本，本案就跟著壞，而且沒有人會事先通知，因為在對方眼裡那只是一次內部調整。更麻煩的是權限：直連帳號通常拿得到整個資料庫，遠超本案需要的範圍，資安查核時很難說明。若真的必須直連，至少要求對方建一個只含必要欄位的唯讀檢視表，並把「結構變更須於幾個工作日前書面通知」寫進契約。
還有一個實務細節值得先講：介接的網路路徑要在建置初期就確認。政府機關的內外網分流、固定來源 IP、防火牆開放申請，往返一趟常常比寫程式久。把「防火牆開放與網段確認」列成專案里程碑，而不是等到整合測試才發現連不到；需要對外服務的檢舉平台，頻寬與尖峰連線數的估法見民眾檢舉平台連假爆量怎麼撐。
介接規格要寫死哪七個欄位？
一條介接寫成一張表，七個欄位缺一項就會在履約期間變成爭議。這七項不是理論清單，而是驗收人員可以拿著逐條打勾的內容：
- 介接對象與主責單位：系統名稱、管理機關、資訊窗口、現行維護廠商。沒有寫主責單位的介接條文，等於沒有人可以被要求配合測試。
- 傳輸方式與端點：協定、位址與埠、允許的來源網段、憑證的簽發者與到期日。憑證到期日要進維運行事曆，它是無聲故障裡最常見的成因。
- 資料結構與必填欄位：欄位名稱、型態、長度、字元編碼、日期時間格式與時區。時區與編碼沒寫清楚，資料搬一次就整批平移或變亂碼。
- 觸發時機與頻率：即時、每幾分鐘一次，或每日固定時間；單次最大筆數；重跑同一批會發生什麼。
- 驗證規則與錯誤回覆：哪些情況必須擋下來、錯誤代碼表、每個代碼對應的處理方式，以及哪幾種錯誤要主動通知人而不只是寫紀錄檔。
- 重送、去重與對帳：重送幾次、間隔多久、以哪個欄位判斷重複、每天用什麼報表核對雙方筆數。
- 測試與變更程序：有沒有測試環境、測試資料由誰提供、任一方改版要提前幾個工作日通知、由誰執行回歸測試。
判斷寫得夠不夠細的標準：驗收人員能不能照著這一條，當場送一筆錯的資料進去，並預期系統回覆哪一個錯誤代碼。
這個標準不是本文發明的，它就是驗收現場實際在做的動作——科技執法系統驗收怎麼驗那篇把「故意送一筆錯的進去」列為初驗七個動作之一，並要求觀察系統有沒有擋下來、有沒有寫進錯誤紀錄、有沒有通知人。規格書寫得出錯誤代碼表，驗收才驗得到這一項；寫不出來，現場就只能驗「正常資料送得進去」，而那是最低標準。
另外提醒一件容易被忽略的事：介接規格屬於交付文件，不是廠商的內部文件。它要跟系統架構圖、資料庫綱要一起列進驗收清單，並隨著每次變更更新版本。沒有交付介接規格的專案，換廠商時就得靠讀原始碼反推，成本高到經常變成「乾脆重做」。
介接失敗時誰負責？責任邊界、對帳與告警
釐清責任的方法是把鏈路切成三段，各問一個問題：資料在離開本案系統之前就已經錯了嗎？是在傳輸或中介平台這一段丟掉的嗎？還是對方系統收下了卻沒有處理？要回答得出來，前提是兩邊都留下足夠的紀錄。
讓三段都有證據的四件事
- 送出端留完整紀錄：送出時間、批次序號、筆數、對方回應代碼與回應時間。這幾個欄位要進稽核軌跡，而不是只寫在應用程式的紀錄檔裡——紀錄檔通常幾天就輪替掉了。
- 每日筆數對帳：本案系統今天送出幾筆、對方受理幾筆、退件幾筆，差異要列出案件編號。對帳表是爭議時真正派得上用場的依據；沒有它，雙方只能各說各話。
- 告警要有門檻與收件人：連續失敗達到幾次、或當日成功率低於多少就發出告警，並指定通知到人而不是通知到一個沒人看的信箱。介接故障是無聲的，沒有告警就等於沒有監控。
- 憑證與帳號密碼的到期日：列進維運行事曆並設定提前提醒。實務上有相當比例的「系統突然不通」，原因就是某張憑證或某組密碼到期了。
有了紀錄與對帳，責任邊界才能寫進契約。建議至少把兩件事納入服務水準條款：每日對帳差異須為零（有差異須於約定時限內查明並回報），以及介接連續失敗達門檻須告警並通知窗口。回應時效怎麼分級、扣款級距怎麼訂、稼動率以誰的監測為準，在警政系統維運委外怎麼談 SLA那篇有完整訂法，介接項目直接套用同一套分級即可，不必另創一套。
介接最常踩到的五件事
- 把「應與既有系統完成介接」當成規格：沒有指名對象、格式與驗收方式，這句話在履約期間沒有任何拘束力。
- 沉默地吞掉錯誤資料：程式攔到例外卻不回報、也不寫紀錄。比直接報錯嚴重得多，因為錯誤會累積到無法回溯。
- 測試環境用正式資料：測試方便，但等於把個資複製到防護較弱的環境。測試資料要另外產製，並寫進規格書。
- 只測正常流程：驗收只送格式正確的資料，錯誤格式、重複案號、欄位超長三種情況完全沒測，上線後第一次遇到就出事。
- 沒有人負責整條鏈路：分段發包最常見的結局是每一段都說自己正常。這也是為什麼機關越來越傾向把辨識、入案、對外平台與後端主機放在同一個技術體系內——從資料格式到網站代管的責任集中在單一窗口，是一條龍服務對機關最實際的價值。
瑪尼國際成立於 2004 年，深耕資訊服務逾 20 年、服務逾 500 家企業，並以協力廠商身分參與全台多個縣市警察局交通隊的入案系統建置與維運。機關若在招標前需要協助盤點現有系統、確認哪幾條介接是本案可以控制的範圍，或想把介接條文改寫成驗得出來的寫法，我們可以依實際環境提供技術說明。機關對外的宣導專區與成效公開頁面若一併納入本案，網頁設計與後端維運的實績要求建議分列，別用同一條實績條款涵蓋兩種專業。系統的完整技術規格與資安設計見智慧警政科技執法系統方案頁。
常見問題
Q：科技執法系統要跟哪些既有系統介接？
實務上至少六類：一、監理資料交換，也就是把舉發資料以標準化格式送往監理體系的 M3 介接；二、機關的公文與檔案管理系統，讓申訴、陳情與回覆進得了正式流程；三、路口主檔與 GIS 圖資，讓地點是代碼而不是自由文字；四、影像來源與監控平台，決定原始母檔放在誰手上、能保存多久；五、車籍與身分查詢，用於車號與車種顏色的自動比對；六、對外通知與機關單一登入，前者通知民眾案件進度，後者讓每個操作都對得到一個真人帳號。招標前把這六類逐一確認主責單位與現況，規格書才寫得出可驗收的條文。
Q：科技執法系統的介接規格書要寫到多細才驗得出來？
一條介接至少要寫死七個欄位：介接對象與其主責單位、傳輸方式與端點（含協定、網段、憑證與到期日）、資料結構與必填欄位（含欄位長度、編碼與時區）、觸發時機與頻率（含單次最大筆數）、驗證規則與錯誤回覆代碼表、重送與去重與對帳方式、測試環境與變更通知程序。判斷寫得夠不夠細的標準只有一個：驗收人員能不能照著這一條，當場送一筆錯的資料進去，並預期系統回覆哪一個錯誤代碼。做不到這件事的條文，履約期間就沒有拘束力。
Q：科技執法系統介接出問題時，要怎麼判斷是哪一邊的責任？
用三個問句把鏈路切開：資料在離開我方系統之前就已經錯了嗎？是在傳輸或中介平台這一段丟掉的嗎？還是對方系統收下了卻沒有處理？要回答得出來，前提是雙方都留下送出時間、批次序號、回應代碼與筆數，並且每天做一次筆數對帳。沒有對帳表的介接，爭議時只能各說各話。建議把「每日對帳差異為零」與「介接連續失敗達門檻須告警並通知窗口」兩件事寫進維運的服務水準條款，責任邊界才會落在文件上而不是會議上。