我們用 SMART——Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（具關聯）、Time-bound（有時限）——把每個故事拆成五天，作為每次動手造輪子前的五個檢查問題。

本篇是回顧總結的「方法」篇：從現成到自研之間，決策順序應該長什麼樣？

本篇定位：建立一套由低成本、低風險到高責任的決策順序。

會議室裡只有兩個選項

認出五種起手式之後，我一度以為問題解決了：以後只要察覺熟悉感在作祟，擋下來就好。真的回到會議室才發現，擋下來之後大家會轉頭看我，等我回答下一個問題：「不然要怎麼做？」而會議室的語言裡，這個問題通常只有兩個答案——「用現成的」，或者「自己做」。

二選一的框架有個致命的性質：只要現成方案被找到任何一個缺點——文件是英文的、參數要學、介面不合手——「用現成的」就出局了，剩下的唯一選項自動當選。回頭看，每個故事裡都有這樣一個瞬間：從「現成方案有摩擦」到「自己重做」，一步跨過去，中間什麼都沒有。

被跳過的中間樓層

真正的毛病出在別的地方：我們把選項排成了平面。「用現成的」和「自己做」其實是同一座階梯的最上層與最下層，中間還有好幾級；每往下一級，技術自由度多一點，團隊要背的責任也厚一層。採用，只需要承擔選型責任；自研，要承擔設計、測試、部署、資安、相容性與維護的完整生命週期。

順帶把方向詞統一：前面幾次講的「升級處理層級」，指的就是在這座梯子上往下走。後面一律用「往下」，因為往下加的是責任。

用這個視角重看，五個故事裡至少有三個嚴格說來不是「選了自研」的錯，而是跳級的錯——需要的其實是中間某一級，落點卻直接掉到最底下。另外兩個的錯位發生得更早：梯子的第一級是「採用既有的東西」，其中一個把它誤讀成非重寫不可，另一個則把手邊的零件當成這一級已經定案的採用結果，於是連比較都省了。跳級之所以是常態，是因為中間那幾級沒有名字；沒有名字的選項，不會出現在會議室的白板上。

可以怎麼做

所以先給它們名字。六級輪子決策梯，由上往下：

1. 採用：直接使用既有標準、元件、平台或工具。故事四的答案本來就停在這一級——ONVIF 的 Snapshot URI，原本就是為了「要一張圖」這個需求而存在的。
2. 設定：透過既有的設定、參數、組態範本或部署方式滿足需求。很多「它做不到」翻譯過來其實是「預設值不是我要的」。
3. 文件與範例：補上說明、可執行範例、測試集合與操作流程。使用者的困難常常停在這一級，一份匯入之後就能直接按下 Send 的請求集合，比一套自己寫的介面便宜得多。
4. 薄型轉接：在明確邊界加一層轉接層，隔離差異，但不改寫原有方案的核心語意。把硬體或平台差異包進幾個具名函式，介面換了、語意沒換，就是這一級。
5. 官方擴充：使用原廠正式提供的 Plugin、Driver、Extension、Integration 或 SDK 這類擴充點，讓客製留在原廠支援範圍內。故事四的技術路徑走到後段，有一步是「評估廠商提供的正式 API 或 SDK」，落點就在這一級——同一個故事，第一級與第五級都到得了，差別只在侵入多深。
6. 自研：現有方案有具體且無法接受的缺口，而且團隊願意承擔完整生命週期。

會有人問：官方擴充聽起來比自己寫的轉接層安全，為什麼排在薄型轉接下面？因為這座梯子排的不是安全性，而是「你寫下並且必須長期維護的程式量與綁定深度」。官方擴充雖然留在原廠支援範圍內，卻要寫出真正的擴充邏輯，還得綁定原廠擴充點的版本；轉接層只在自己這一側薄薄一層，核心語意仍然是別人的。所以它的位置在薄型轉接之下。

配套規則只有一條：想往下走一級，就要多交一份證據。證據有固定格式，至少五樣：

• 現有方案無法滿足的具體需求：精確到哪一個輸入、哪一條規格、哪一種場景做不到。能寫成「在什麼條件下、預期得到什麼、實際得到什麼」，才算數。
• 已嘗試的方法與失敗結果：試過才算，想像中的失敗不算。留下指令、請求、錯誤訊息或量測紀錄；這一項同時是路標，防止半年後有人滿懷希望地重走同一條死路。
• 這一級新增的責任、成本與風險：不只是第一版的工時，還包括上游升級時誰會被弄壞、出事的半夜誰先被叫醒。
• 測試、部署、資安與維護的負責人：要有名字。沒有署名的維護承諾，在人事異動時第一個蒸發。
• 完成、停止、回退與淘汰條件：往下走之前先寫好往上退的路。有退路的往下是決策，沒有退路的往下是賭注。

這份清單就是熟悉感的過濾器。「我比較有把握」在第一項就會卡住，因為它說不出具體是哪裡做不到；真正的缺口則通過這五關毫不費力——它本來就帶著實測紀錄、錯誤訊息與規格對照。決策梯不歧視任何一級，它只歧視空手往下走的人。

今天學到的事

自研不是第零步，而是前面較小的選項都被證據淘汰之後，才有資格進入的高責任選項。這句話反過來讀也成立：證據齊了，自研就完全正當——梯子的用途是把責任照順序排好，讓每一次往下，都是睜著眼睛走的。

但我也很清楚，沒有人會在時程燃燒的會議裡翻出一座六級梯子逐級對照。方法要能活下來，就得壓縮成一個夠短的儀式，短到再趕的專案都擠得出時間、再急的人都願意停一下。那個儀式該短到什麼程度，又得問完哪些欄位才不算敷衍？