我開始發現，和 AI 一起開發，真正重要的是讓它找得到「現在」

做 Money Snap 的時候，我已經慢慢建立了 PRD、開發規格、工作計畫、測試與版本文件。 一開始只是覺得這樣比較有條理。

但當產品開始迭代，版本越來越多，我才發現這些文件真正的價值： 它們讓 AI 可以重新理解現在的專案。

這和記住上一段對話不太一樣。

今天可能在電腦前面開發，明天換一台電腦。 這一次對話已經很長，下一次可能重新開一個 Copilot Session。 版本也會一直往前走。

如果每一次都要重新跟 AI 解釋「我們現在做到哪裡」，那 AI 協作其實很難真正持續下去。

只要產品目前的狀態有被留下來，AI 就有機會從現在繼續往下走。 AI 不一定要記得我們昨天聊了什麼，但它必須看得懂我們今天留下了什麼。 這可能才是跨裝置、跨對話還能繼續工作的關鍵。 而且不只是接著寫程式，而是接著往「正確的方向」開發。

從「聊天」變成「交接」

以前像是在「聊天」，現在比較像是在「交接」， 我現在在意的是「上下文能不能被接續」。

我會讓專案裡留下：

這些東西看起來很像文件管理，其實也是 AI 協作的「上下文」。 讓 AI 回到專案本身，而不是只依賴上一段對話。

AI 會不會走偏，還是取決於我們有沒有留下方向

當然，這不代表 AI 每次重新讀專案，就一定會做對。 所以我現在比較在意的是，不要讓它急著動手。

先理解，再開始動手。

哪些東西已經有了？ 哪些地方需要修改？ 哪些功能彼此有關？ 哪些地方可能會影響原本的行為？ 然後再開始整理工作。

這樣做的好處是： 我不需要自己把整個專案重新講一次。 AI 也不需要猜，它可以直接從現在的程式和文件裡找答案。

但真正讓產品繼續往前的，通常不是規格

實際開發最有趣的地方，往往不是完全照著規格完成。 而是：我打開畫面之後，突然發現這裡怪怪的。

例如 CSV 匯入。 一開始看規格，好像就是把 CSV 匯進來。 但真的拿檔案測試之後，才會發現，有些實際使用情境，和原本想像的不太一樣。

這些事情很難在第一次寫規格的時候全部想到。

所以後來我的工作方式變成： 發現問題。 把問題描述給 AI。 讓 AI 回頭去找是哪一段程式造成的。 修改。 再測。 然後我再用一次。

UI 是我最明顯感受到這件事情的地方

規格已經寫好 UI 了，那照著做應該就差不多。 但真的開始使用之後，UI 很難一次定案。

一個按鈕的位置。 一段提示文字。 一個設定要不要預設展開。 手機上是不是太擠。 桌機上是不是又太空。

這些事情，很少能在第一次規格裡就全部想清楚。 而且有些問題不是「不好看」。 而是「用起來不順」。 這兩件事情差很多。

例如後來做自訂面額時，原本的操作方式比較像一個設定面板。 實際使用之後，我希望它改成主開關，讓使用者一眼就知道現在到底有沒有啟用自訂面額。 所以我把需求告訴 AI。

它不是只把 UI 換一個樣式而已。 而是重新把 UI 的操作方式、設定狀態，以及背後的計算邏輯一起調整。 主開關關閉，就使用預設面額。 主開關開啟，才使用自訂設定。 使用者的偏好也要能被記住。

所以 UI 的改動，最後還是回到了產品邏輯。

這也是我越來越在意的地方：好的 UI 調整，不只是把畫面改漂亮，而是畫面、互動、程式邏輯和驗收標準一起改。

測試讓我們知道，改完之後還是不是同一個產品

持續修改有一個很大的風險。 就是：「這次修好了，但上次好的東西被弄壞了。」 測試就像是一條安全線。 讓我們可以一直往前修改，而不是每改一次，就害怕整個產品不知道壞在哪裡。

如果要讓 AI 跨對話、跨裝置持續工作，測試其實也是很重要的一條線。

因為對話可以不見。 Session 可以換。 甚至 AI 模型都可以換。 但：

規格 → 程式 → 測試 → 驗收

這條線可以留下來。

我現在和 AI 的工作方式，開始變成這樣

產品需求
   ↓
版本規格
   ↓
AI 讀取目前專案
   ↓
確認「現在在哪裡」與「要往哪裡走」
   ↓
建立工作計畫 / 待辦項目
   ↓
依照依賴關係實作
   ↓
測試
   ↓
我實際操作
   ↓
發現問題
   ↓
把「現象」告訴 AI
   ↓
AI 回頭檢查程式
   ↓
修改
   ↓
再測試
   ↓
更新文件
   ↓
下一個版本

這個循環可以一直繼續。

當我隔了一天、換了一台電腦、開了一個新的對話，我還能不能持續和 AI 一起工作？

這件事情最後不是靠 AI 的記憶解決的，而是靠我們一起留下來的東西。 不管下一次從哪裡開始，我們都還能繼續往正確的方向走。 這可能才是我目前最想建立的 AI Workflow。