我這次做網站的起點，是一件很小的家務：我和太太每天輪流給孩子五元零用錢。一天她給，隔天我給，就這樣輪流。
我希望有個地方，可以一眼看見今天輪到誰、孩子有沒有收到，以及累積了多少錢。於是，我把這個需求交給 Codex，請它幫我做一個網站。
後來真正值得記錄的，除了網站本身，還有我們一路把需求說清楚、修正錯誤、確認資料放在哪裡的過程。
如果你也想用 AI 做一個自己會用的小工具，這個案例可以當作參考。它提醒我：畫面出現，只是第一個里程碑；能在日常生活裡安心使用，還有好幾步要走。
第一版：先讓生活中的動作有地方落下來
第一版網站做出了幾個很直覺的功能：顯示今天由爸爸或媽媽給款、按一下記錄收到五元、查看累積金額，以及用月曆補記或撤銷錯誤紀錄。
這個階段的好處，是我不用先想出一份完整的系統規格，就能看到一個可以操作的版本。畫面讓抽象需求變得具體，我也更容易指出還缺什麼。
例如，「每天輪流」聽起來很簡單，實際上卻至少包含兩條規則：誰從第一天開始給？漏記一天，隔天還要不要照原本日期輪流？
我們採用的方式，是依日期計算輪流順序。沒有記錄收到，不代表輪值就停在那一天。這讓「今天該誰給」和「這天是否收到」成為兩件分開的事情。
第一版也有清楚的限制：它在本機運作，紀錄存在當下使用的瀏覽器。我能操作，不等於太太換一支手機，也能看到同一份帳本。
第二步：先釐清數字的意思，再要求 AI 計算
接著，我補充孩子原本已經有一些零錢，而且我提供的總額，已經包含今天收到的五元。
這句話很容易被誤解。如果直接把總額當作起始金額，又加上今天的五元，就會多算一次。
所以帳本需要區分「開始記帳前的零錢」和「開始記帳後，每天收到的紀錄」。計算方式是：原有零錢，加上已確認收到的零用錢，才是目前總額。
這個細節也讓我想到企業裡常見的問題。很多計算錯誤，不是加減乘除做錯，而是欄位的意思沒有先講清楚。這個金額是否含稅？這筆收入是否已收款？這個總數是否已包含今天新增的資料？
使用 AI 時，我們仍然要負責定義數字代表什麼。工具可以替我們算，但不能靠猜測替我們決定資料的意義。
第三步：有一個網址，還不等於只有家人看得到
當本機版可以使用，我提出下一個需求：希望網站有公開可連線的網址，但帳本內容只讓我和太太查看。
這時，任務就從做畫面，進入存取權限與資料儲存的設計。
一開始討論了信箱登入，後來我決定採用不需要信箱的家庭 PIN。首頁只放簡單提示，輸入家庭 PIN 後，才載入零用錢紀錄。
這裡最重要的是，保護不能只做在畫面上。把金額藏起來，卻仍然讓任何人直接呼叫資料介面，並不符合需求。真正需要驗證的，是沒有登入時，伺服器是否拒絕提供帳本資料。
我們也必須說清楚這個設計的界線：共用家庭 PIN，是讓知道 PIN 的人取得存取權限，並不是辨認登入者一定是我或太太。它符合這次簡單家庭帳本的操作選擇，卻不能直接當作企業客戶資料、薪資或其他敏感系統的登入範本。
公開文章分享的是製作方法，因此不附上實際帳本網址、家庭 PIN 或孩子的真實存款數字。
第四步：我決定資料只放在 Vercel
製作過程中，曾經先建立 Supabase 的獨立受保護資料表。後來我進一步確認需求：這個小工具，我希望網站與帳本都集中在 Vercel，不再使用 Supabase。
最後的做法，是由 Vercel 提供網站與伺服器功能，帳本存放在 Vercel 的私人 Blob 儲存空間。前端登入後，透過伺服器讀取資料，不把私人帳本直接公開成任何人都能下載的檔案。
這個選擇是本次小型帳本的取捨，並不代表所有專案都應該用檔案儲存。資料量增加、查詢變複雜，或開始需要多個家庭、不同角色與操作稽核時，就要重新評估資料庫和權限架構。
搬移也不是把新資料寫進去就結束。我要求確認新位置的金額、給款人和登入保護都正確，再移除原先的 Supabase 家庭資料表，停用原有資料服務，避免留下兩份不知該相信哪一份的帳本。
第五步：一句「今天是我給的」，修正了 AI 的預設
最早的版本，先預設由媽媽開始。我後來補上一句：「今天是我給的零用錢。」
這個修正看似很小，卻不能只改首頁上的稱呼。今天的收款紀錄要改成爸爸，輪流起始設定也要一起調整，明天才會正確輪到媽媽；累積金額則不應該因此改變。
這是我很重視的一種協作能力：AI 接到修正後，要找到這項事實影響哪些地方，讓整套規則保持一致。
對使用者來說，只是補充一句生活事實；對系統來說，卻包含歷史紀錄、未來安排與金額不變這三個條件。好的驗收，應該把這三件事分開確認。
第六步：部署成功的訊息，不能取代實際打開網站
這次上線並不是一次就完全順利。
過程中遇到部署參數與授權檢查，也曾經發生發布工具回報成功，實際打開首頁卻找不到頁面的情況。原因是排除檔案的規則，連同應該發布的首頁檔案一起排除了。
這件事再次提醒我：不能只看工具說「完成」。網址要真的打開，登入要真的操作，資料要真的讀回來。
修正之後，我們確認首頁能正常顯示；未登入的帳本請求會被拒絕；登入後可以看到正確金額與給款人；再開另一個登入工作階段，也能讀到同一份資料。
另外，兩人若在接近的時間修改帳本，也不能讓後存的人直接蓋掉前一個人的更新。因此系統會檢查資料版本，遇到舊版本修改時拒絕覆蓋，請使用者重新載入後再操作。
這些檢查不會讓首頁看起來更漂亮，卻決定了它能不能被放心使用。當然，一次通過測試，也不代表未來不必維護；這次完成的是可用的小型家庭工具，並非已經具備完整備份、帳號管理與長期維運制度的服務。
從這個小網站，我整理出一套可重複的方法
如果你準備和 AI 一起做工具，可以先照下面的順序走：
- 說清楚一個真實場景。 誰會用？每天會做什麼？目前最容易忘記或弄錯的是哪個動作？
- 把規則拆成可以核對的句子。 例如依日期輪流、收到才記錄、同一天不能重複計入。
- 先看可操作版本。 用實際操作找缺口，再補起始金額、補記、撤銷等細節。
- 補上共用與隱私條件。 換裝置是否能看到同一份資料？誰能讀、誰能改？資料放在哪裡？
- 讓修正反映在整套系統。 不能只改顯示文字，還要檢查紀錄、計算與未來安排是否一致。
- 到真正的目標端驗收。 實際打開正式網址，分別測試未登入、已登入、重新登入與同時修改的結果。
這套順序，可以用在家庭記帳，也能用來思考課程簽到、工作交接、設備借用或簡單的內部申請。只是涉及的人越多、資料越重要，權限與驗證就必須跟著提高，不能直接照搬家庭工具的設定。
我的實戰心得：小需求，也能練習把 AI 變成可用系統
我不想把這次經驗寫成「一句話，就能完成一切」。真正的過程，是我不斷補充需求、決定取捨，AI 協助實作、測試，再根據實際結果修正。
每天五元的零用錢，最後成了一次很具體的人機協作練習。它讓我看見，使用 AI 的能力，除了怎麼問，還包含怎麼定義規則、辨認假設，以及判斷什麼才算完成。
工具只是起點，流程才是核心，系統才是成果。
給想開始的你：一個小小的行動呼籲
先挑一件每週都會發生、規則不太複雜、你能親自驗收的小事，把「誰、何時、做什麼、怎樣算正確」寫下來，再請 AI 做出第一個可操作版本。
如果你想把這樣的做法帶進企業，從一個具體工作流程開始盤點，可以到漫遊數位官網了解人機協同的服務方向，也可以在技術知識庫閱讀其他實作紀錄。
延伸閱讀
本文依蔡正信與 Codex 於 2026 年 9 月 8 日的製作對話及當次上線驗收整理，於 9 月 9 日撰寫。家庭私密資料已省略。
📖 技術知識庫版本：本文亦同步收錄於 蔡正信 ‧ 技術知識庫 (wiki.rd.coach)，提供免受側欄干擾的乾淨技術筆記閱讀體驗。
