三十天前，CareCall AI 只是一個模糊想法：能不能用 AI 協助高齡關懷，讓需要協助的個案更容易被看見？當時我很容易把注意力放在語音、AI 或漂亮畫面上，卻不知道專案應該放在哪裡、每天做出的東西是否能接續，也不知道「看起來能操作」和「真的能被驗收」其實是不同的事。

這三十天最後形成的，不只是一個首頁。CareCall AI 現在有五個核心畫面、四位虛構個案、四題固定關懷、可解釋的有限規則、未回應後的再次聯絡、人工處理中心、多日事件紀錄，以及三條可以重設並重現的展示情境。即使語音不支援、AI 沒有設定、資料損壞或外部服務失敗，使用者仍能回到文字、規則與人工確認。對我而言，這種「失敗時仍知道下一步」比單次成功的畫面更接近產品。

但完成 Day 30 的功能後，我沒有立刻停下來。我重新用第一次使用者的角度檢查公開作品，才發現功能雖然都在，真正的工作台卻被成果介紹、操作教學、安全說明和展示情境推到很下面。桌面版要捲到約 1,430px，手機版甚至要到約 3,686px 才看得到今日狀態。安全與模式說明也重複出現，導覽開關同時存在於側欄和頁首。這些內容單獨看都有理由，但放在一起就讓作品更像說明文件，而不像可以開始工作的工具。

因此我做了第一輪資訊架構優化：首頁先顯示今日狀態與四位個案，再放三條展示情境；操作導覽改為預設收合；Day 30 成果、GitHub、證據、安全界線和公開／本機版差異，集中到「關於作品與使用限制」。我也刪除重複的側欄導覽與模式說明。調整後，桌面版在約 242px 就能看到今日狀態，手機版也從約 3,686px 提前到 765px。這讓我理解，介面優化不一定是增加動畫或重新設計顏色，有時只是把使用者現在需要的資訊放到正確位置。

第二輪則處理真正的操作效率。手機導覽改成頂端固定、可橫向滑動，導覽高度從約 267px 降到 43px；狀態摘要也改成更緊湊的排列。首頁個案不再依固定編號，而是按照「優先處理、待人工確認、待提醒、已完成」排序，按鈕也從四個相同的「查看共用個案資料」，改成「立即處理」、「進入人工確認」、「查看並再次聯絡」或「查看完成紀錄」。四題關懷流程加入已保存題數；完成一題後會自動開啟下一個尚未回答的問題。實際驗收時，第 1 題保存後成功切換到第 2 題，進度從 0／4 更新為 1／4。公開版不能呼叫外部 AI，因此 AI／規則雙路徑改為預設收合；本機完整版仍保留完整功能與證據。這些改動沒有重寫規則或資料結構，而是讓既有能力更容易被使用。

最後幾天也讓我重新理解誠實的完成定義。Day 23 我實際建立 API key 並嘗試呼叫模型，但 API 額度是零；系統成功保留原文並進入規則備援，卻沒有取得真實模型結果。Day 24 完成了失敗備援錄影，但沒有真實 AI 正常路徑。Day 26 的兩位真人測試也仍等待外部證據。因此最終版本命名為 v1.2-public-demo，而不是暗示所有功能和使用者驗證都完成的名稱。功能矩陣清楚區分已實作、模擬或裝置依賴、等待外部驗收與下一版。

AI 在這段過程中協助我產生程式草稿、整理文件、補測試與檢查證據，但作品範圍、安全界線、是否能宣稱完成，以及哪些結果必須交給人判斷，仍然需要由我負責。Vibe Coding 並不是把一句願望交給 AI 後等待成品，而是持續把模糊需求變成可檢查的決定。

今天的發布本身也是一次真實的除錯。優化完成後，TypeScript 正式建置與 Day 17～30 全套測試都通過，但推送時發現本機分支和遠端 main 的提交歷史不同，而且 Codex 執行環境無法使用 Windows Git 憑證庫。我沒有強制覆蓋遠端，而是先從遠端 main 建立乾淨分支，只套用這次的單一優化提交，再由 VS Code 終端機完成推送。最終 commit 83cd2e6 成功進入 main，GitHub Pages 也載入新版檔案；公開網站實際顯示優先個案李春美、「立即處理」按鈕、預設收合導覽與新的作品資訊區塊。

今天公開的版本沒有正式後端、真實電話、醫療診斷或跨裝置同步，但它已經能被打開、操作、重設、測試、失敗、說明限制，也能從 README、程式提交、測試結果與證據索引追溯。下一步不是繼續堆功能，而是先完成兩位真人測試，觀察他們能否在沒有口頭提示的情況下找到個案、完成四題、理解狀態並處理人工待辦，再依實際卡點修正。三十天後，我真正得到的，是一套比較不容易散掉的開發方法：先定義問題，保留唯一專案，用證據驗收，承認缺口，再讓下一版建立在今天可靠而且可使用的基礎上。