在產品開發的世界裡,上線並不是結束,而是新的起點。
一個系統能否長久被使用,不僅取決於功能是否完整,還取決於它的 維護性、彈性,以及回應使用者需求的速度。這些因素,往往比初期的功能設計更能決定專案能否真正發展壯大,並持續創造價值。
接下來,我將分享目前為止所收到的一些回饋問題,以及我如何在 AI 幫助下一步步進行修改與調整,讓系統能夠更貼近使用者的需求。
某天收到一位使用者的訊息:
「任務管理只能一天一天改,能不能有批量修改和查看的功能?」
其實這個問題我自己近期也有體會,只是因為優先順序的關係,暫時放在待辦清單裡。
但既然有使用者提出,那就代表這確實是個 真實痛點,因此決定立刻動手處理。
我心裡已經大概有方向,接著就交給 AI 來確認可行性,然後逐步展開實作。
這次的調整主要分成三個部分:
我選擇先從「匯入任務」開始,因為這部分概念清楚、操作單純。
我使用大概如下的提示詞,並附上一張截圖說明:
1.在「新增任務」按鈕左邊,新增一個「匯入任務」按鈕。
2.點下去後,會跳出視窗,讓使用者選擇要匯入的日期。
3.系統會列出該日期的任務清單,確認後即可匯入到今天。
AI 自行查詢了現有的 API 與資料結構,並完成 UI 介面與資料庫串接。
我只需要在最後做一些微調與測試,就能順利完成。
主要需要特別處理的,是 Firebase 的讀取限制。
為避免讀取速度過慢與消耗過多資料庫讀取次數,我設定只能匯入「一個月內」的任務,並請 AI 設計處理中動畫效果。這樣既符合效能,也能確保使用體驗。
目前使用 Vibe Coding 的一個明顯缺點是,AI 會在資訊有限的情況下,設想合適的設計方案。
雖然整個專案都是 AI 做出來的,但是在這個例子,AI 在設計過程中並沒有意識到firebase 資料讀取速度以及讀寫成本的資訊,因此作出來的往往不會是最佳方案。
而當下為了避免這些問題,可能就要利用一些其他輔助 AI 記憶的工具或是設定好的 Rules,協助 AI 記憶住當前專案的一些重要事項。
當然,如果自身對專案掌控度高,依靠開發者自身的判斷,在給予提示詞時再將需要讓 AI 獲取的資訊放進提示詞中也是最有彈性,避免過多資訊汙染提示詞的一個方式,畢竟,AI 上下文長度有限,精準的提示詞才能獲取較好的效果。
接下來是 週期處理。
很多時候,孩子的任務其實具有規律性,例如「每天刷牙」、「每週一交作業」。
如果每次都要手動新增或複製,未免太麻煩。
我設計的方式是:
這裡的實作還算順利,但卻再次提醒我一個教訓:命名的重要性。
由於我之前在設計任務卡片(如task_card
)時,命名不夠精確,導致程式碼裡出現了許多類似的名稱。
AI 在修改時常常改錯地方,浪費不少時間,這次修改再次遇到類似狀況。
後來我才體會到,一開始就注意元件命名避免重覆或高度類似,可以減少後續維護的難度。
這對我後續的 Vibe Coding 都是值得謹記的經驗。
最後是 月曆顯示,這部分其實最花時間。
為什麼?因為「要顯示月曆」這件事不難,
但「怎樣的月曆好用」卻沒有標準答案。操作方式、視覺呈現、互動細節,都需要一點點試出來。
我一開始給 AI 的指令很簡單:
幫我在行程管理頁面上方,日期欄位旁邊,新增一個切換月曆顯示的開關。
切換後,可以用月曆檢視當月的任務清單。
這種模糊描述有點像「碰運氣」。
AI 會自己發揮,但結果可能不一定符合心中預期。
不過有時候反而會帶來驚喜。
在多次嘗試後,我得到一個意外的功能 ——
AI 在日曆介面上,透過顏色標記每天的任務狀態,
用來識別每天任務完成的比例。
這原本不是我要求的,但看起來還不錯,讓整體視覺更直觀。
這邊也呼應先前提到的,有時候也可以不用太精細的描述提示詞內容,引導大方向,適當地讓 AI 發揮創意碰碰運氣,或許可以得到意想不到的收穫。
這次的任務管理功能升級,讓平台從「單純的任務清單」進化成「更靈活的日程規劃工具」。
後面會繼續分享近期收到的一些回饋,以及我如何在 AI 的幫助下一步步改善平台使用體驗。
敬請期待下一篇《回饋驅動的進化:小細節、大體驗 — AI 協助下的 UI 優化之路》