懂流程的我，在離職前，把公司流程寫進系統

去年，我曾經寫過幾篇關於前一份工作的文章。

那時候，我還在一間規模很小的電商公司裡工作。公司人不多，我卻橫跨了商品修圖、影片剪輯、商品上架、電商後台、行政，甚至揀貨、理貨、裝箱與寄件等工作。因為長期處在第一線，我幾乎實際走過公司的整套工作流程。

當時的我一直在思考一件事：

為什麼很多明明可以更簡單的工作，最後都變成人在不斷複製、貼上、切換視窗、核對資料，再靠短期記憶避免自己出錯？

今年農曆年前，我甚至曾經把老闆原本需要大約 15 分鐘完成的一項工作，透過重新設計流程，縮短到大約 6 分鐘。我當時已經逐漸理解：真正的效率，不是要求一個人把錯誤的流程做得更快，而是重新設計流程，讓那些沒有必要的工作直接消失。

只是當時的我還不知道，幾個月後，這種「流程優化」的思考方式，會進一步變成真正的內部資訊系統。

我不是先會寫系統，才開始理解公司的流程

如果只看到最後的結果，很容易把事情理解成：「我開始使用 AI，所以突然做出了 13 套系統。」

但真正的順序完全相反。

我不是先會寫系統，才開始研究公司的工作流程；而是因為我已經在那些流程裡工作很久，才知道系統究竟應該怎麼寫。

我自己做過訂單處理、商品資料整理、圖片處理、影片剪輯、商品上架、後台維護，也參與過揀貨、理貨、包裝與出貨。

因為我真的做過，所以我知道：

• 哪些工作每天都在重複。
• 哪些資料一直被人工複製與輸入。
• 哪些流程最容易發生錯誤。
• 哪些操作高度依賴員工的短期記憶。
• 哪些事情其實根本不應該繼續由人處理。

我以前曾經把這種工作稱為「數位勞役」。例如一個原本應該由資料結構與程式處理的同步問題，最後卻被轉嫁成人工操作；價格改一次、規格動一次，就必須重新進行大量重複修改。

那時候我寫過一句話：只要有一個人能撐住，就沒有誘因去優化系統。

後來，開始真正優化系統的人，就是我自己。

懂流程的我，開始把流程寫進系統。

真正的轉折點，是我終於離開了舊硬體的限制

但這中間還缺了一個很重要的條件：工具。

我原本使用的是一台 2017 年的 Intel MacBook Air。到了 2026 年，它已經陪我工作將近八年。這台電腦不是完全不能工作，但面對現代化的開發環境、設計軟體、大量瀏覽器分頁與 AI 工具時，硬體已經逐漸從工具變成瓶頸。

尤其當 AI Coding 開始改變程式開發方式之後，我其實已經看到新的可能性，卻受限於舊電腦的效能，很難真正把這套工作方式跑起來。

2026 年 4 月，我最後決定不再等待，換了一台 M5 MacBook Air。

當時我以為這次升級主要只是為了讓 WordPress、Adobe、影片剪輯與日常工作重新流暢起來。後來才發現，這台電腦真正解除的，還有另一個我當時沒有完全預料到的瓶頸：AI Coding 終於可以成為我的實際生產工具。

我並不是換了電腦之後，才突然理解公司的流程。那些 Domain Knowledge 早就在我的腦袋裡；HTML、CSS、WordPress 與網站開發能力，我也已經累積很多年。

真正發生的事情是：

• 我本來就懂公司的工作流程。
• 我本來就知道流程的痛點在哪裡。
• 我已經具備前端與網站開發基礎。
• AI Coding 大幅降低了完整系統實作的門檻。
• 新的硬體則讓這套開發方式真正能夠順暢運作。

當這些條件全部接在一起之後，原本只存在我腦中的流程改善方案，開始可以快速轉換成真正能夠運作的程式。

新筆電沒有讓我突然變成工程師，它只是解除了最後一道生產力瓶頸。

懂流程的我，留下了 13 套公司內部系統

接下來幾個月，我開始大量把公司的工作流程系統化。

以前需要人工處理的資料，開始進入資料庫；需要人記住的工作狀態，開始由系統保存；需要反覆查找的資訊，開始可以直接查詢；原本散落在紙本、Excel、訊息與人的腦袋裡的流程，也開始被整理成真正可以執行的系統。

到我離職以前，我陸續替公司留下了 13 套內部系統，同時也協助老闆租賃虛擬主機、購買網域，以及建立相關的資訊環境。

而這些系統到底有沒有實際價值，其實不需要由我自己判斷。老闆後來親口告訴我，這些系統確實減少了他和新進員工的工作量。這也是我後來才真正理解的事情：

系統的價值從來不在於寫了多少程式碼，而在於它替人拿掉了多少原本不需要存在的工作。

以前的我，是那個被迫用大量人工操作填補系統缺陷的人；後來，我開始寫系統，把人從那些低效率流程裡解放出來。

但事情也在這裡出現了一個我當時沒有預料到的反轉。系統降低了公司對人工操作的依賴，卻沒有降低公司對系統開發者的依賴。

我成功讓工作不必由我來做，卻產生了新的 Key-person Dependency，這 13 套系統讓公司的工作變得比較輕鬆，也讓後來接手的人不需要完全按照我以前的方式工作。從營運角度來看，這其實是一件好事。

我把原本存在自己腦袋裡的部分流程知識，轉換成系統規則。換句話說，即使我不坐在那個位置上，一部分工作仍然可以透過我留下來的系統繼續運作。

但問題是，公司只完成了系統化的第一半。流程被寫進系統了，卻沒有同步建立完整的技術文件、程式交接、第二維護者與長期維運機制。

於是產生了一個很典型的 Key-person Dependency（關鍵人依賴）：

• 公司越來越依賴這些內部系統。
• 系統確實降低了老闆與員工的工作量。
• 但整間公司只有我最熟悉系統架構與程式邏輯。
• 一旦系統發生問題，最後仍然只能回頭找我。

這形成了一個很有意思的悖論：

我成功讓公司不必再依賴我親手完成那些工作，卻讓公司開始依賴那些由我開發、也只有我最熟悉的系統。

換句話說，營運上的人力依賴下降了，技術上的依賴反而上升了。

六月底，我真的離職了

2026 年 6 月底，我離開了這間公司，準備到新的工作環境開始下一個階段。

我希望整個離職過程可以比較圓滿。老闆最後同意依法以資遣方式處理，讓我離職後具有申請失業給付的資格。

但老闆真正擔心的一件事情，就是我離開之後，那 13 套公司內部系統怎麼辦？因為這些系統已經實際進入公司的工作流程，而且只有我最熟悉，所以我也答應老闆：即使離職之後，如果原有系統發生 Bug，我仍然會協助處理。

因此，如果把整件事情的因果關係拆開，其實比較接近：

• 我長期參與公司的實際工作，因此非常熟悉流程。
• 我開始重新設計低效率的工作方式。
• 換新電腦與 AI Coding 解除實作瓶頸。
• 我把大量工作流程寫進 13 套內部系統。
• 系統降低老闆與新員工的工作量。
• 公司開始高度依賴這些系統。
• 但只有我最熟悉系統，形成 Key-person Dependency。
• 我要離職時，老闆擔心系統未來沒有人處理。
• 我答應離職後仍協助修復既有系統的 Bug。
• 老闆最後同意以資遣方式處理離職。
• 我因此取得資遣費。

這就是為什麼，我的離職從來不是單純的「交接完就走」。因為我留下來的不只是工作成果，而是一整套已經被公司日常營運依賴的資訊系統。

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

問題也從這裡開始。

在後續雙方的互動裡，資遣費逐漸和我留下來的 13 套系統綁在一起。

邏輯慢慢變成：公司已經付了資遣費，而我也答應過協助處理系統，所以這些系統以後只要有問題，我就應該繼續處理。

真正危險的不是偶爾幫忙修一次 Bug，而是這個責任沒有明確的終點。

今年修，那明年呢？三年後呢？

PHP、資料庫、主機環境升級造成程式不能正常執行，算不算我的 Bug？員工希望增加欄位、修改流程，究竟是維護還是新功能？原本系統因為公司的營運方式改變而需要重構，又應該算誰的責任？

如果這些事情沒有定義，一句「以後有問題再幫忙處理」，就可能變成一張沒有到期日的技術支票。

人已經離職了，責任卻沒有離職。

新系統，讓界線問題徹底浮上檯面

如果事情只停留在原本 13 套系統的 Bug，其實還有機會透過協議慢慢把責任切清楚。

但離職之後，老闆又找我開發一套新的「批價訂單及模具製造追蹤系統」，預算是 NT$2,000。

一開始聽起來，好像只是一套簡單的小工具。但當我真的把需求 Scope 拆開之後，我才發現事情完全不是這樣。

實際需求逐漸包含：

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

當系統開始出現廠商帳號、權限、訂單、Multi-tenant、資料隔離、站內通訊與資安問題時，它就已經不是 2,000 元的小程式，而是一套 B2B 廠商協作平台的雛形。

真正的問題也不是「我做不做得出來」。

我知道自己做得出來。

問題是：我為什麼要用 2,000 元的預算，承接一套規模遠超過 2,000 元的系統開發與後續責任？

AI Coding 讓我變快，不代表我的專業因此變便宜

這也是整件事情裡，我花了一段時間才真正想清楚的地方。

因為 AI Coding ，我現在確實可以比以前更快完成系統。以前可能需要花大量時間查文件、建立架構與除錯的功能，現在可以透過 AI 大幅壓縮實作時間。但這不代表系統的價值應該按照「我花了幾個小時」來計算。

真正讓這些系統能夠運作的，不只是 AI，而是一整條能力鏈：

• Domain Knowledge：我知道公司實際怎麼運作。
• Process Analysis：我知道問題卡在哪裡。
• Process Design：我知道哪些步驟應該被拿掉或重新設計。
• Data Modeling：我知道資料應該如何被結構化。
• UI／UX：我知道使用者實際操作時需要什麼。
• Development：我能把需求真正轉換成可以執行的系統。
• AI Coding：把上述能力的實作速度進一步放大。

AI 是槓桿，不是價值本身。

如果一個人因為使用更好的工具，可以把原本需要十天完成的事情縮短成兩天，那代表的是他的生產力提高了，不代表他的專業價值只剩五分之一。

更重要的是，2,000 元真正買不起的並不是程式碼，而是責任。

系統正式投入使用之後，需求變更誰處理？Bug 誰修？主機升級誰處理？資料異常誰排查？權限漏洞誰修？半年後還要不要維護？如果開發費只有 2,000 元，責任卻可以不斷往後延伸，那最後就會形成一個非常不合理的結構：報酬有上限，責任卻沒有上限。

所以，我最後決定把所有事情重新切開

到了 2026 年 9 月，也就是我離職不到三個月之後，我終於和前老闆把這些事情重新整理清楚。

最重要的第一件事，就是不能再把「以前的系統」、「修 Bug」、「功能修改」和「新的開發需求」全部混成同一件事情。

• 在職期間開發的 13 套既有系統：屬於過去工作期間留下來的成果，依照雙方後續簽訂的協議提供一年期保固與基礎維護。
• 既有系統 Bug：在約定期間與範圍內，我仍然協助修復。
• 小型功能修改：依雙方約定的次數與範圍處理，不無限累積。
• 重大功能變更、新模組、第三方 API 與重構：不屬於既有系統的免費保固範圍。
• 新增系統：視為新的開發委託，重新確認需求、報價，以及我是否願意承接。

這些分類看起來只是合約文字，但對我而言，它們真正處理的是一個更根本的問題：以前的人情，不能無限延伸成未來的義務。而最重要的一件事，就是替這段維護關係設定一個明確的終點。

2026 年 10 月 1 日至 2027 年 9 月 30 日。

真正的離職，是讓責任也有離開的一天

現在回頭看，我其實經歷了一個很奇妙的轉變。

最早，我只是公司流程裡的一個執行者。我被大量重複、低效率、沒有累積價值的數位工作消耗，所以開始思考怎麼讓工作變簡單。

後來，我開始重新設計流程。再後來，新的硬體與 AI IDE 補上了最後的實作能力，我開始把流程直接寫成系統。我從被流程支配的人，變成改善流程的人，最後變成把流程寫進系統的人。

那些系統確實發揮了作用。它們降低了老闆與新進員工的工作量，也讓公司不再需要完全依賴某一個人，用大量人工操作完成所有工作。

只是這個故事最後教我的，反而不是怎麼再多寫一套系統。

而是如何讓自己的責任有邊界。我會寫，不代表我有義務寫。我修得好，不代表我要終生修。我以前願意幫忙，不代表所有未來的新需求，都可以自動算進過去的人情。AI 讓我變得更有能力，也因此更需要知道什麼事情不應該接。

做得到，跟值不值得做，是兩件完全不同的事情。

2026 年 6 月底，我的人離開了前公司。2027 年 9 月 30 日，則是我替那些留下來的系統責任設定的保固終點。