如果你正在搜尋「網站沒人顧怎麼辦」或「工程師離職怎麼用 AI 接手」，重點不是先找一個工具把所有事自動接走，而是先讓下一個維護者看得懂、測得到、改得動。AI 可以協助閱讀程式碼、整理文件、產生檢查清單、找出風險與補上測試路徑；但它不能替代網域、主機、部署、資料庫與權限的控制權。
軟體交接感覺像是程式碼的問題，但真正危險的部分，通常是「營運記憶」。一套系統從外面看可能很簡單，實際上卻依賴著某一台筆電、某個被遺忘的排程工作、某張正式環境的資料表，或某個從來只有一個人跑過的手動發布步驟。
如果你的團隊正處在這種狀況，請避開兩種昂貴的直覺反應：把舊系統當成不能碰的禁區，或是在還不清楚有什麼正在運行之前就宣布要整套重寫。用下面這份交接檢查清單，找出最小而安全的下一步。
開發者離開後，會改變什麼？
系統失去了它的「人的地圖」。程式碼也許還能跑，但團隊已經不知道哪些部分可以安全地改、需要哪些帳號、rollback 要怎麼做、或當初某些決定為什麼要這樣做。這會帶來四種實際的風險：
- 變更風險：一個小修改就可能弄壞一條隱藏的流程，因為沒有人知道彼此的相依關係。
- 存取風險：部署、網域、資料庫、電子郵件、金流或雲端的存取權，可能握在錯的人手上。
- 資料風險：備份、資料庫遷移與保留規則，可能沒有文件記錄、也從沒被實測過。
- 業務風險：使用者持續仰賴這套系統，公司卻沒有明確的維護負責人。
交接的目標是「控制權」，不是「文書作業」。一份好的交接，會讓下一位維護者有足夠的脈絡去檢視、測試、部署與還原系統，而不必用猜的。
軟體交接檢查清單
確認正式的程式庫（repository）、正式環境的分支、最新部署的 commit、相依套件版本、建置指令，以及發布筆記或變更歷史放在哪裡。
寫下正式環境是怎麼部署的、誰有權部署、失敗時會發生什麼事，以及在不靠記憶的情況下要怎麼 rollback。
列出需要用到的雲端專案、網域、DNS 紀錄、電子郵件服務、App 商店、分析工具與管理後台。不要把原始密鑰四處傳遞；請輪替後存放到正確的地方。
找出正式環境的資料庫、儲存空間（bucket）、資料庫遷移、手動改過的地方、備份頻率、還原程序，以及最重要的資料表或紀錄。
找出每一個金流、CRM、通訊、試算表、webhook、cron、背景工作與第三方 API 的相依關係，並檢查哪些會「悄悄失敗」而沒人發現。
指名那些一定要持續運作的流程：註冊、付款、報價申請、報表產生、管理者審核、庫存同步，或任何業務不能暫停的環節。
指派一個人在未來 30 天負責承接進來的需求、事故與發布決策，並定義在盤查完成之前，哪些變更是可以被允許的。
風險等級：接下來該做什麼？
| 訊號 | 代表什麼 | 最好的下一步 |
|---|---|---|
| 綠燈 | 程式庫、部署路徑、資料庫、備份與關鍵流程都有文件、也能重複執行。 | 繼續維護，在高風險流程周圍補上小型測試，並隨著變更持續改善文件。 |
| 黃燈 | 系統能運作，但部署、資料、串接或負責歸屬，都仰賴某一個人的記憶。 | 在做新功能之前，先跑一次交接盤查；把發布路徑穩定下來，並寫下第一版 rollback 計畫。 |
| 紅燈 | 沒有人能安全地部署、還原、測試或說明某條關鍵流程。 | 凍結非緊急的變更、找回存取權、盤點正式環境，並診斷「救援」還是「重寫」比較安全。 |
72 小時穩定化計畫
如果開發者已經離開、而業務又仰賴這套軟體，請把最初的 72 小時用來「減少未知」，而不是「增加功能」。
凍結高風險變更
暫停美化或臆測性的工作，範圍只保留緊急修復、存取權還原、備份驗證與證據蒐集。
盤點什麼正在運行
找出網域、主機、資料庫、排程工作、串接、分析與活躍使用者。凡是不在程式碼裡的，用截圖或筆記記下來。
測試一條關鍵流程
挑一條最影響營收或營運的流程，確認它怎麼開始、資料落在哪裡、由誰接收，以及失敗時會怎麼呈現。
選出最小而安全的路徑
決定當下的路徑是維護、救援、可直接開發的藍圖，還是更完整的資料與部署盤查。
原開發者不在了，該重寫嗎？
不要預設就重寫。當平台已經走到盡頭、當初的假設已經錯了、或系統無法被安全地修改時，重寫可能是對的。但重寫也等於把所有隱藏的規則搬進一個新專案，而在這期間，業務仍然需要舊系統繼續運作。
在選擇重寫之前，先回答三個問題：
- 現有系統是否仍然符合目前的業務流程？
- 危險的部分能不能被隔離在一個穩定的介面後面？
- 團隊能不能把資料與串接規則講得夠清楚，足以重新打造出來？
如果答案不清楚，就先診斷。正確的第一個專案，可能是一次交接盤查、一次發布路徑救援、一張資料地圖，或替換掉風險最高的那個元件。
下一步
找出你的軟體交接風險等級
用「軟體健檢」把「開發者離開了」變成一個具體的下一步：診斷、找回發布路徑、準備藍圖、救援原型，或盤查資料與部署的邊界。
常見問題
開發者離職時，軟體交接應該包含哪些內容？
一份實用的交接應該把以下內容搶救回來：正在運行的原始碼、部署路徑、環境對照表、資料庫與備份說明、串接清單、管理者存取權限邊界、維運手冊，以及未來 30 天有一位指名的負責人。
工程師離職了，可以用 AI 接手維護這套系統嗎？
可以用 AI 協助接手，但不要把 AI 當成跳過交接的捷徑。比較安全的做法是先找回原始碼、部署路徑、資料、權限與關鍵流程，再用 AI 協助閱讀程式、整理文件、盤點風險與設計小範圍測試。
網站沒人顧、沒人維護時，第一步該做什麼？
第一步不是立刻重做網站，而是確認誰掌握網域、主機、程式碼、後台、資料庫、備份、部署方式與表單通知。先把控制權拿回來，再判斷該維護、救援、重構，還是重新設計。
原開發者離開時，最大的風險是什麼？
最大的風險通常是隱藏的部署步驟、不知道的密鑰、沒有文件記錄的資料庫變更、脆弱的第三方串接、沒有測試路徑，以及沒有一個人清楚哪些地方可以安全地改。
原開發者不在了，我們應該重寫軟體嗎？
不要預設就重寫。先判斷這套軟體是否仍符合現在的業務、是否能被安全地修改，以及危險的部分能不能被隔離起來。
沒有現任維護者時，要怎麼盤點一套軟體？
先盤點：什麼正在運行、部署在哪裡、碰到哪些資料庫與串接、哪些使用者流程最重要，以及今天如果上線一個變更會有什麼會壞掉。
Omni Care 能協助穩定或接手一套沒人維護的系統嗎？
Omni Care 可以協助診斷風險、還原營運對照表、定義出最小而安全的下一步，並判斷正確的路徑是救援、受控開發、藍圖規劃，還是更完整的資料與部署盤查。