一開始的運動紀錄頁，是我直接跟 AI 說：「幫我寫一個運動紀錄頁，打 API 顯示資料就好。」
AI 立刻幫我生了一份能跑的程式碼。看似沒問題，但很快就暴露出一堆 bug：

• 切換頁面 → state 消失，要重抓一次
• 新增一筆紀錄 → 回到日曆 → 再進來 → 剛剛新增的居然不見了
• 同時多個請求 → 回傳順序錯亂，畫面「倒退」

這些問題不是 API 寫壞，而是 狀態管理出了大問題。

我開始懷疑：是不是要換架構？

當時的我心想：「要不要乾脆自己改，把狀態抽出來？」
但一想到要自己從零開始重構 Redux，就覺得累。

於是我決定再賭一把 —— 請 AI 幫我重構。

和 AI 的重構過程

我跟 AI 說：
「這樣直接在元件打 API 不行，幫我改成用 Redux Toolkit 管理狀態。」

AI 給了第一版的 slice，我試著套上去。
結果一跑，畫面還是怪怪的，dispatch 後資料沒進來。
我又回去跟 AI 說：「你的 reducer 少處理 fulfilled 的 case，幫我補上。」

它馬上修正。

接著又遇到問題：
「新增紀錄後，日曆沒更新。」
我就再補一句：「selector 也要更新，記得用 createEntityAdapter 正規化資料。」

AI 聽話地加了 adapter，還幫我整理出 selectAllWorkoutsByDate 這種 selector。
我只要在元件裡呼叫 selector，畫面就會自動同步了。

成果：比我自己改還快

整個過程，幾乎是我提需求、AI 負責產 code、我再根據錯誤回報修正。
本來以為重構會是件大工程，但因為有 AI 幫忙，速度反而比我自己土法煉鋼還快。

更重要的是：

• 運動紀錄的狀態現在集中在 store，不會再「換頁就消失」。
• 日曆、列表、統計卡片都吃同一份資料，更新一次全場同步。
• loading/error 的流程也統一了，UI 顯示更一致。

小結

這次重構的故事，讓我有一個新的體會：

AI 不只可以幫忙做 MVP，還可以幫忙重構。

以前我覺得 AI 只適合「快速生出能跑的版本」，但現在發現，只要你會丟對需求、把問題拆開，AI 也能幫忙「從混亂變成秩序」。

就像這次的運動紀錄頁：從一個 bug 滿天飛的版本，到現在狀態乾淨、切頁穩定，全靠 AI 一步步把 Redux Toolkit 的結構搭好。

👉 今天的收穫：

• 直接打 API 很快，但維護性差。
• Redux Toolkit 是穩定長大的必經之路。
• 重構不用自己扛，AI 也能幫你做架構升級。