離職後還要修 Bug？從 13 套內部系統談開發、維護與專業界線

前一份工作離職前，我替公司開發了 13 套內部系統，改善原本大量依靠人工處理的工作流程，也協助老闆租賃虛擬主機、購買網域，以及建立相關的資訊環境。這些系統後來逐漸進入公司的日常營運，確實提高了工作效率，也減輕後續員工的工作負擔。

但效率提升的另一面，是公司逐漸形成了嚴重的 Key-person Dependency（關鍵人依賴）：系統是我開發的，架構是我最熟悉的，出了問題也只有我知道應該從哪裡處理。換句話說，公司得到了一套高度客製化的資訊系統，卻沒有建立相對應的技術交接與維護能力。

後來我要離開原本的公司，到築心開始下一階段的工作。我希望整個離職過程可以比較圓滿，老闆最後也同意依法以資遣方式處理，讓我離職後具有申請失業給付的資格。同時，因為公司已經高度依賴這些系統，我也答應老闆，即使離職之後，原有系統如果發生 Bug，我仍然願意協助處理。

因此，整件事情真正的因果關係比較接近：

• 我在職期間開發大量內部系統。
• 公司逐漸依賴這些系統運作。
• 系統只有我最熟悉，形成 Key-person Dependency。
• 老闆擔心我離職之後沒有人能維護。
• 我承諾離職後仍協助處理既有系統的 Bug。
• 老闆同意以資遣方式處理離職。
• 我因此取得資遣費。

資遣費，差點變成沒有期限的「終生保固」

真正的問題，是資遣與系統維護後來被綁在了一起。資遣費原本是勞動關係終止時的給付，但後續卻逐漸形成一種理解：既然公司已經付了資遣費，那麼以前我開發的系統，未來只要發生問題，我就應該繼續協助處理。

偶爾協助修復 Bug 並不是最大的問題，真正危險的是沒有明確的責任終點。今年修、明年修，那三年後呢？PHP、資料庫或主機環境升級造成的相容性問題算不算 Bug？員工希望新增欄位、修改流程，又到底屬於維護還是功能擴充？如果這些界線沒有定義，一句「有問題再幫忙處理」，就可能變成一張沒有到期日的技術支票。

所以我和老闆重新協議，把原本模糊、近似無限期的責任正式改成一年期保固及基礎維運。在職期間開發的 13 套既有系統，保固期間明確訂為 2026/10/01～2027/09/30。

而且責任也必須拆清楚：

• 既有系統 Bug：依協議，在保固期間內協助修復。
• 小型功能修改：依雙方約定的維護範圍處理，而不是無限增加。
• 重大功能變更：不屬於既有系統 Bug。
• 新增模組：屬於新的開發需求。
• 第三方 API、系統重構：不包含在原本保固範圍內。
• 2027/09/30 之後：原有保固責任正式終止。

這件事情對我非常重要，因為我終於把一個模糊的「以後有問題都找你」，轉變成有範圍、有期限、可以真正結束的契約責任。

離職之後，2,000 元的新系統讓問題徹底浮上檯面

如果事情只停留在原本 13 套系統的 Bug 維護，其實透過契約還有辦法把責任切清楚。但離職之後，老闆又找我開發一套新的「批價訂單及模具製造追蹤系統」，並告訴我：「我預算只有 2,000 元，不急，你慢慢做。」

一開始聽起來，好像只是一套簡單的內部管理工具。但當我真正把需求拆成 Scope，才發現這根本不是一個 2,000 元等級的小程式，而是一套具備 B2B 廠商協作平台特徵，甚至已經接近垂直領域 SaaS 雛形的系統。

實際需求包含：

• 多角色帳號與權限管理。
• Multi-tenant 多租戶資料隔離。
• 不同廠商只能存取自己的訂單與模具資料。
• 公司端可以統一管理所有廠商。
• 一對一站內通訊功能。
• 繁體中文／簡體中文雙語支援。
• 人民幣金額與訂單資料管理。
• 模具製造進度追蹤。
• RWD 響應式操作介面。
• 後端身分驗證、授權與資料存取控制。
• 防止 IDOR／Broken Access Control 等越權存取問題。

當需求出現帳號、權限、廠商、訂單、Multi-tenant、站內通訊及資料隔離之後，問題就已經不是「做幾個 PHP 頁面」而已。只要讓外部廠商登入，A 廠商能不能看到 B 廠商的資料、修改網址或 ID 能不能越權讀取其他訂單、公司端和廠商端的權限如何切割、訊息如何保存、資料如何隔離，全部都成為真正的系統工程與資安問題。

如果按照正常的系統開發方式，把需求分析、資料庫、前後端、權限、測試、部署、資安與後續維護全部算進去，這已經是數萬元以上等級的開發案，而不是 2,000 元的小工具。

真正的問題不是「做不做得出來」，而是專業與報酬完全失衡

我後來才意識到，我一直被一個問題困住：「這套系統我到底做不做得出來？」

但其實這根本不是核心問題。我知道自己做得出來。現在有 AI 輔助，再加上我原本具備的 HTML、CSS、前端、伺服器與系統架構能力，我確實可以用比傳統開發方式更短的時間完成很多功能。

真正應該問的是：「我為什麼要用 2,000 元，承接一套數萬元等級系統的開發與後續責任？」

AI 讓我變快，不代表我的專業因此變便宜。真正有價值的並不是我敲了多少行程式碼，而是我能不能把模糊需求轉換成資料結構、設計操作流程、建立權限模型、判斷資安風險、完成部署，並且在系統發生問題時知道應該從哪裡排查。

更重要的是，2,000 元真正買不起的，其實不是程式碼，而是責任。一套正式投入公司營運的 B2B 系統，後面還會產生需求變更、Bug、環境升級、使用者操作問題、資料異常、權限漏洞與後續維護。如果開發費只有 2,000 元，卻默認開發者未來還要繼續承擔這些責任，那就會形成非常明顯的不對等：

報酬有上限，責任卻沒有上限。

這才是我真正拒絕的東西。

我要切斷的，不是人情，而是沒有邊界的責任

經過這次事情，我終於把過去混在一起的責任拆成三個完全不同的層次：

• 在職期間開發的 13 套既有系統：屬於過去勞動關係留下來的成果，目前依照協議提供一年期保固與基礎維運。
• 既有系統的 Bug：依照契約約定，在保固期限及範圍內協助修復。
• 離職後提出的新功能、新模組、新系統：全部屬於新的開發委託，必須重新確認需求、報價、工期，以及我是否願意承接。

以前我很容易陷入一種工程師思維：「這個我會」、「這個應該做得到」、「AI 可以幫我加快」、「反正慢慢做就好了」。但現在我開始理解，做得到，跟值不值得做，是兩件完全不同的事情。

我能開發一套 B2B 系統，不代表我應該用 2,000 元做；我願意修以前留下來的 Bug，不代表我要終生維護；我曾經答應協助前老闆，也不代表所有未來的新需求，都可以自動包含在過去的人情與資遣關係裡。

所以這次，我替整件事情設定了一個非常清楚的終點：2027 年 9 月 30 日。

在這之前，我依照雙方簽訂的協議，處理約定範圍內的既有系統保固與維運；新的系統、新的模組與重大功能變更，則重新報價、重新評估，我也保留不承接的權利。

到了 2027/09/30，這段因為 13 套系統、資遣與離職承諾形成的特殊責任關係，就正式畫下句點。

我花了很長一段時間才理解：真正的離職，不只是人離開公司。有時候，你還必須把留在前公司的責任、模糊的人情，以及沒有期限的承諾，一項一項收回來。

否則，人走了，責任卻永遠沒有離職。