一開始，我真的只是想讓大家訂便當方便一點。
事情要從 2024 年說起。
當時公司固定向一家便當店「蔡老師」訂餐。
如果每天都靠人工詢問、訊息統計，再自己整理最後要訂幾份，很容易漏掉，也很難提前安排。
我做了一個公司內部的便當訂購網頁。
最初的需求很單純：
如果故事停在這裡，它大概就只是一個普通的內部小工具。
但真實世界通常不會停在第一版。
最初的畫面很簡單。
看到日期、餐點，選擇自己要吃的便當就完成了。
2024 年最初的訂餐介面。目的很單純：讓大家自己登記便當，不需要每天再人工詢問一次。
對使用者來說，只是多了一個可以點餐的網頁。
但對負責訂餐的人來說，最大的差別是：
終於不用每天重新問一次「今天誰要吃？」
當大家開始真的使用之後，很快又出現下一個問題：
最後到底要跟店家訂幾份？
而且不是只有總數。
還要知道：
於是系統又慢慢長出了「當日統計」。
系統會整理不同取餐樓層與不同餐點的數量，最後直接拿來向店家下單。
這是整套系統第一次從「方便填資料」，變成真的參與日常訂餐流程。
因為最後向店家回報的便當數量，就是從這裡來的。
如果這個數字錯了，就不是畫面不好看而已，而是真的可能少訂或多訂便當。
訂單統計解決之後，下一個麻煩很快就出現了：
每天收錢真的很累。
有人忘了付，有人想一次先付幾天，最後還要再回頭確認每個人到底還剩多少。
後來系統又加入了預付餘額。
例如一次先收 10 餐的費用，或直接儲值 1,000 元，每次訂餐再從餘額扣除。
一開始看起來只是多一個欄位。
但只要開始碰到「錢」，事情就變得不太一樣。
例如：
取消訂單後，錢要不要加回去？
或者更麻煩的：
如果畫面上的餘額和交易紀錄對不起來，到底哪一個才是真的？
原本只是訂便當，這時候已經開始碰到資料一致性的問題。
到了 2026 年 8 月，需求又出現了一次明顯的變化。
原本長期只有一家店。
很多東西都很固定：
後來開始找其他便當店，原本的規則就開始不夠用了。
不同店家有不同菜單。
有些會調整價格。
有些餐點會停售。
有些店家甚至需要前一天就先訂。
於是原本單純的訂餐頁，開始需要處理多店家、不同菜單、價格、圖片、開團日期與訂購截止時間。
從單一店家走向多家店之後，原本固定的訂餐模式，也開始需要處理更多變動。
這時候已經可以感覺到：
它不再只是一張「比較聰明的表單」。
後來還有一個很實際的問題。
有時候我在開會。
有時候請假。
有時候根本不在座位上。
但便當店還是在固定時間等著確認：
明天總共要幾個便當？
如果系統只能在公司電腦上方便操作，那最後還是得想辦法回到電腦前查看。
於是我開始有一個很單純的想法：
為什麼不能直接用手機？
而這個看起來很小的需求，反而成了整個系統最大的轉折點。
因為手機版帶來的，不只是把畫面縮小。
當系統開始走到公司環境之外，就必須開始重新思考：
這個人是誰？他能做什麼？資料放在哪裡？原本的歷史資料又要怎麼繼續用？
也因為這樣，系統後來才逐漸從原本的架構，走向：
React + Cloudflare Workers + D1
但這些都不是我在 2024 年一開始就規劃好的。
而是需求一路把系統推到了這裡。
學 Web 開發時，很常看到 Todo List。
新增、修改、刪除、完成。
它很適合學 CRUD。
但真實系統麻煩的地方，通常不只是 CRUD。
這套便當系統後來困難的問題，反而比較像：
已經存在的歷史資料到底能不能改？
金額和訂單對不起來時，哪一份才該相信？
本機明明正常，為什麼部署之後卻不能用？
還有一個後來越來越重要的問題：
當 AI Agent 開始幫我修改正式系統時，怎麼確定它真的改對了，而且沒有順手改壞其他地方？
這些事情，才慢慢把一個小工具推成了一套需要被認真維護的系統。
如果把這兩年的變化濃縮起來，大概是這樣：
2024
單一店家便當預訂
↓
未來 21 天預訂 / 過去 7 天查詢
↓
依取餐樓層統計
↓
預付餘額
↓
2026/08
開始增加其他店家
↓
多店家 / 多菜單
↓
想要直接用手機點餐
↓
身份 / 權限 / 歷史資料開始變複雜
↓
原本架構開始不夠用
↓
GAS + Google Sheets
→ React + Cloudflare Workers + D1
↓
正式系統治理
回頭看最明顯的是：
這裡面幾乎沒有哪一個功能，是我一開始就完整規劃好的。
全部都是因為真的有人使用之後，又冒出了下一個問題。
這個專案最值得我記錄的，並不是：
我用了哪些技術。
而是：
一個看起來很小的需求，是怎麼在真實環境裡一步一步長成正式系統的。
這個系列不會寫成：
Day 1 做登入
Day 2 做 CRUD
Day 3 串 API
Day 30 Deploy
因為這套系統根本不是這樣長出來的。
接下來的 30 天，我想記錄三件事：
從最早的訂餐網頁，到多店家、手機版、身份與權限。
包括資料遷移、歷史資料、Production Bug、CORS、餘額一致性，以及 Migration 風險。
從「叫 AI 寫 Code」，一路走到 Worktree、Preflight、Verification、Handoff，最後甚至需要 Agent Governance。
我不打算把這段故事整理成一個「從零開始、一次就設計正確」的完美案例。
因為真實系統從來不是這樣。
它會變。
會壞。
會有歷史包袱。
也會因為新的需求，再被迫做下一次選擇。
下一篇先回到這套系統更早的起點。
在還沒有 GAS、React、Cloudflare Workers、D1、LINE 登入以前，
公司原本就已經有一套真的能用的內部便當系統。
舊系統沒有壞。
改變的是使用情境：我想把訂餐流程搬到手機上，但又不能把原本已經跑過一段時間的行為弄丟。
在選 React、GAS，甚至決定資料要放哪裡以前，我遇到的第一個問題反而是：
舊系統裡，到底有哪些東西不能在重做時消失？
下一篇先不談技術選型，而是把舊系統拆開來看：
畫面背後到底藏了哪些 Business Rules，以及怎麼把它們整理成可驗收的需求？
iThome鐵人賽
看影片追技術