前言：進度清單本身，就是一份記憶

「這項長期遷移計畫的進度，我們有記在清單裡，要用的時候查一下就好了吧？」

Day 20 講過記憶會過期,今天要把這個原則套用到一個具體、每天都會用到的場景：一項橫跨數十個項目、需要好幾週甚至好幾個月才能完成的重構計畫，該怎麼追蹤進度。這種計畫的進度清單，本質上就是一份 project 類型的記憶，也繼承了 Day 20 講過的所有風險——只是因為它每天都被拿出來用，過期的代價會更頻繁地發作。

今日目標

• 理解長期重構計畫的進度清單，為什麼特別容易過期
• 認識「排優先序」這件事裡藏著一個容易被忽略的隱藏維度
• 學會用「實際查詢現況」取代「直接引用清單」的具體做法
• 建立追蹤長期計畫進度的一套可持續習慣

為什麼進度清單特別容易過期

一項橫跨數十個項目的長期遷移計畫，通常不是一個人從頭做到尾，也不是連續不中斷地做——可能今天處理三個項目，明天被別的緊急任務打斷，下週才回來繼續。每次回來繼續之前，很自然地會想先看一眼進度清單：「上次做到哪裡了？」

問題在於，這份清單記錄的是「上次更新時的狀態」，而不是「現在的狀態」。如果這段期間有其他人（或其他 AI agent 的其他任務）也動過同一個計畫的一部分，清單就已經過期了,但清單本身不會主動告訴你這件事——它靜靜地躺在那裡，看起來完整、可信，直到你依賴它做出一個錯誤判斷。

排優先序：一個容易被忽略的隱藏維度

長期遷移計畫通常需要決定「先做哪些、後做哪些」，直覺的排序依據是「哪個影響範圍最大」（例如流量最高的那幾個項目優先）。但實際操作後會發現，還有一個容易被忽略的維度：這個項目「有沒有可用的真實樣本」，直接決定了實際能不能動手，跟它的重要性排序是兩件獨立的事。

具體來說：某些項目雖然影響範圍看起來很大，但如果現在沒有任何管道能拿到真實的成功案例當驗證素材（例如某個外部串接的正常回應範例），這個項目就算排在優先序最前面，實際上也動不了手——因為沒有真實樣本，就沒辦法驗證「這樣改是不是真的沒問題」，勉強動手反而是在賭運氣。這種情況下，正確的做法是把它的優先序往後調，先處理那些「重要性稍低,但確實有真實樣本可以驗證」的項目，而不是死守著「影響範圍」這一個維度不放。

用一組對照來看這個差異：

❌ 只看重要性排序：
「這個項目流量最高，優先處理它。」
→ 沒有考慮到這個項目目前有沒有真實樣本可以驗證，
  可能排在第一位，卻因為缺乏驗證素材遲遲動不了手

✅ 同時考慮重要性跟可驗證性：
「這個項目流量最高，但目前沒有真實成功樣本可以驗證；
 那個項目流量中等，但有現成的真實樣本可以驗證。
 先處理後者，前者標注『等有樣本再排進來』，
 而不是讓它卡在優先序第一位動彈不得。」
→ 排序依據不只是重要性，也包含「現在能不能真的動手」

怎麼讓進度清單保持可信：用實際查詢取代直接引用

把 Day 20 的原則套進來，具體做法是：每次要決定下一步做什麼之前，先用實際指令查一次真正的現況（例如列出目前已經完成的項目目錄、查一次相關的 PR 列表），而不是直接相信清單上寫的狀態。 清單的角色是「提示你該往哪裡查」，不是「幫你把查證這個動作省略掉」——這跟 Day 20 講的完全是同一件事，只是這裡的場景換成了「長期重構計畫」這個每天都會用到的具體情境。

這聽起來像是多做一步、犧牲了效率，但實際上省下的成本更大：一旦依賴一份過期的清單做出錯誤判斷（例如以為某個項目已經完成，結果其實只完成了一半），事後回頭排查花的時間，遠比每次多花幾秒鐘查證一次現況要高。

今日思考題

如果你手上也有一項需要跨越好幾週的長期計畫，你追蹤進度的方式是「定期看一眼清單」，還是「每次要動手前先用實際指令確認現況」？如果是前者，上一次清單跟現況出現落差的時候,你是怎麼發現的？

今日重點回顧

• 長期重構計畫的進度清單，本質上是一份會隨時間推進而過期的 project 類型記憶
• 排優先序不能只看重要性，「現在有沒有真實樣本可以驗證」是一個容易被忽略但決定能不能動手的隱藏維度
• 動手前用實際查詢取代直接引用清單，是 Day 20 那條原則在長期計畫場景下的具體實踐
• 多花幾秒鐘查證現況,遠比依賴過期清單做錯判斷後回頭排查要划算

明日預告

明天要做一件更誠實的事：不再談這套方法論能做到什麼，而是談它的邊界——有哪些事情，這一整套流程、機制、記憶系統,都解決不了,AI 重構 legacy 系統時不該碰的地方在哪裡。