Day 1 的問題很生活化：讓訂便當方便一點。手機能用、資料能看、同事不用每次都靠人工詢問，第一版就有存在的理由。

三十篇寫到這裡，回頭看最有代表性的變化，不是多了幾個頁面。是原本一句「幫我加這個功能」，開始需要接上更明確的問題：資料屬於誰、會改到什麼、過去的紀錄還在不在，以及下一次出問題時能否查清楚。

這套系統累積的是一組責任：讓真實需求能被表達，讓修改有邊界，讓結果仍有依據可查。

訂單、店家與餘額，逐漸不再只是欄位

一個店家名稱，後來會連到菜單來源、開團日期與管理操作；一個取餐樓層，會影響如何分餐；一個餘額，會引出扣款、退款與追查歷史的責任。

這些不是為了把小工具做成大型平台。它們先是使用者要完成的事情，直到原本的欄位與畫面裝不下，才需要更明確的模型。

因此前半段留下的判斷是：看到新增欄位時，多問它代表哪個真實行為。若會影響訂單、金額或時間，就不能只靠介面上的顯示文字維持意思。

一個功能能寫入，也要能走完

代點餐把這個差別呈現得很清楚。功能不能停在「替別人建立了訂單」；成功後，要更新被代點者的餘額，回讀他的訂單，結束時清除目標，回到操作人自己的情境。

店家專區也有類似提醒：菜單圖片、外部來源與可訂購狀態放在同一頁，仍由不同責任提供答案。畫面集中，不代表資料規則可以合併成一個模糊的「店家設定」。

這些都是前面文章已拆過的案例。放在結尾一起看，它們讓「完成」變成可描述的使用結果，而不是修改檔案數或成功回應而已。

版本時間線保留了系統曾經不同的樣子

v0.14.x 到 v0.15.x 的 Changelog，保存了代點資格、日期與截止政策、身份路由，以及管理介面的變化。

只看最後程式碼，很容易把它們誤讀成一開始就想好的設計。版本紀錄讓那些調整仍能被定位，也提醒下一個接手的人：有些舊說明對舊版成立，不能直接拿來驗收新狀態。

這條時間線證明的是來源版本的演進。它沒有代替正式部署紀錄，也不代表每個版本都經過本系列重新操作驗證。保留這個限制，才不會在總結時把證據放大。

AI 協作仍在，提問方式變了

這個專案仍然透過自然語言與 AI 一起實作。差別是，要求逐漸從「把功能加上去」，變成同時說清楚：

• 要讓誰完成哪個工作？
• 哪些資料與既有行為不能被改掉？
• 要用什麼結果判斷完成，哪些環境還沒驗證？

這些問題不需要每次排成固定的大流程。小改動有小改動的檢查；碰到帳務、歷史或正式環境，再補上相應證據與限制。中段幾次真實問題留下的，正是這種分辨能力。

AI 能把實作推得很快，人仍要說清楚「正確」是什麼。否則產出的程式越完整，錯誤假設也可能被接得越完整。

簡單開始，並不妨礙之後認真對待

Day 3 的 GAS 與 Sheets 讓第一版容易開始，這個價值不需要被後來的遷移否定。後面長出 Worker、D1、測試與版本紀錄，也不表示所有新專案都該從同樣的終點起跑。

比較值得帶走的是：先解今天存在的問題；當同一種摩擦反覆出現，或資料已承擔無法隨意回復的責任，就把它說清楚、留下證據，再決定要補哪一層。

有些資料當年沒記錄，就保留未知；有些行為只在原始碼看見，就不要說成正式環境已驗證；有些新需求還沒出現，也不必預先建立整套解法。

從一份便當回到工程

這三十篇沒有把便當系統宣告成「全部完成」。仍有要核對的營運證據、會演進的需求，以及只能在下一次使用中看見的問題。

留下來的方向比較踏實：每次修改之後，下一個維護者更容易理解資料從哪裡來、誰能改、怎麼核對結果，以及哪些部分還不知道。

最初想改善的是訂便當。一路做下來，我也更清楚怎麼和 AI 一起照顧一個會被持續使用的系統。這件事不會在 Day 30 結束，文章先在這裡停下來。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app