以每日為入口：讓 AI 協助找回多專案進度

專案少的時候，我會記得每個資料夾代表什麼，也知道下一步該開哪一個。當工作跨越設計、程式、文件與創作，真正的困難逐漸變成：有些專案已經不在我的注意力裡，連要搜尋它的名字都想不起來。

2026 年 9 月，我開始試行以「每日工作」為入口的管理方式。每天可以先問 Agent：「有哪些事情還沒完成？有沒有延宕，或可能被我忘記的專案？」再從有依據的候選中，決定今天要接續什麼。

這篇記錄改變流程的原因、目前做法與驗證方式。截至寫作時，已建立第一組每日任務入口；跨專案自動追蹤與提醒尚未完成，也還沒有足夠使用紀錄證明效率提升。

從整理名稱，走到協助回想

我原本考慮替新專案加上日期，讓它們能依時間排列。例如 2026-09-06_教學工具 同時提供開始時間與主題，比純日期更容易辨認。

但日期命名只能改善一部分問題。如果我根本不記得還有某個專案，仍然不會主動去找它。資料分類很完整，也可能有工作一直躺在分類底下。

因此，我更需要的是一個每天可以重新進入工作的地方。以每日為單位，不是要求一天完成所有事情，而是讓「今天有哪些事值得接回來」成為固定的判斷入口。相較於要求自己先背熟專案清單，我希望 Agent 能根據留下的紀錄，協助恢復脈絡。

每日入口與專案來源，各自保存什麼

每天的工作會跨越不同主題，同一個專案也可能持續數週。我將兩者分開：

層次	保存內容	何時更新
每日入口	今天選擇處理的任務、當日結果與來源連結	安排或收尾當天工作時
專案來源	正文、程式、素材、README 與實際成果	工作內容改變時
專案交接	目前狀態、已確認限制、驗證方式與下一步	出現影響後續工作的變化時

例如，今天做影片測試，明天繼續修字幕，應該回到同一份影片資料。明天的入口可以連到原任務；若成果已轉成另一個獨立工作，也可以建立新任務並附短交接。不需要每天再複製整份專案。

新建立的每日分組可以命名為 2026-09-07｜今日工作，子任務則保留「影片字幕校正」這類具體名稱。日期幫助回想時間，名稱幫助辨識目的。已存在的資料夾與歷史對話，先保持原樣。

一天如何開始、推進與結束

開始時，我不必提供完整清單，可以直接用語音說：「幫我看看有哪些工作還沒收尾，今天適合先做什麼。」Agent 先查可取得的任務摘要、既有交接與相關來源，再提出少量候選。

一個有用的候選至少要讓我知道：這是什麼工作、上次停在哪裡、為什麼現在被提出，以及下一個能執行的動作。下面是假設情境，不是實際專案狀態：

影片測試上次停在配音方式未定，尚未產出成片。若今天要完成測試，下一步是選定配音方案與一段短腳本。來源是該任務的交接紀錄。

我再決定今天要接續、延後，或維持暫停。工作進行時，仍用原本自然的語音或文字補充：「先處理這段」「今天只做到可以測試」「昨天那個方向先保留」。Agent 負責辨識這是補充、修正，還是改變目標。

收尾時，記錄當天實際完成什麼、驗證到哪裡、還缺什麼。影響後續接手的內容回到專案交接，每日入口只留下摘要與指向。這些紀錄由工作過程整理，不需要我每天另外填一份很長的表格。

「延宕」不能只靠多久沒更新判斷

找回專案時，最容易犯的錯是把「沒有新動作」當成「忘記做」。但一個專案可能正在等待回覆、被我刻意暫停，甚至早已完成，只是沒有整理好最後的紀錄。

情況	合理的說法
已超過約定期限，且有未完成證據	已延宕，列出期限與缺少的成果
沒有期限，一段時間沒更新	待確認是否繼續
已記錄等待他人或素材	等待中，說明依賴條件
已明確決定暫停	暫停中，不自動催辦
只有舊摘要，無法確認現況	資料不足，先核對來源

檔案修改時間、Git 提交或任務活躍時間都只是線索。它們可能反映備份、格式調整或同步，不能單獨證明真正的工作進度。

Agent 也應交代本次看過哪些來源。例如只檢查近期任務與幾個已知專案，就不能回答「所有專案都沒有遺漏」。這套方法的可靠程度，取決於來源是否可取得、紀錄是否夠新，以及是否願意明確承認未知。

AI 協助提出候選，決定仍在我手上

我希望少花時間找資料，但仍能控制自己今天投入什麼。Agent 可以指出等待決策的項目、可能遺漏的工作與下一步，不能因為找到舊計畫，就自行重新啟動開發、增加功能或改寫期限。

同樣地，保留舊對話不代表它的內容已自動帶入新任務。真正值得延續的是最近確認的目標、決策、限制與來源；必要時再回頭查特定歷史，而不是每次重讀全部聊天。

我把「每日」理解為工作組織方式。是否每天自動執行、何時通知、要查哪些資料，是另外的自動化設定，需要有明確的範圍與停止條件。這次試行沒有新增每日排程，也沒有建立全量監控。

這次不需要升級 CLI

現有 agents CLI 負責共用規則的安裝、更新與檔案保護；專案交接則負責保存現況。每日分組、查詢既有任務與整理短紀錄，可以先運用現有能力完成，因此這次沒有修改 CLI 或新增版本。

如果試行後發現，常常找不到主要工作位置，或無法判斷交接入口是否缺失，再考慮加入可驗證的檢查能力。先讓需求在真實工作中出現，才能知道該自動化哪個步驟。

關於這些資料的分工，可參考 Systems/wikinb and codexrules；規則工具的角色見 Systems/codexrules agent system。公開文章說明方法，私人工作明細與操作紀錄仍留在適當的本機來源。

如何判斷試行是否有幫助

我會觀察：不記得專案名稱時，能不能找回想做的事；新任務是否減少重講背景；Agent 是否把刻意暫停誤判成延宕；以及每日收尾是否反而增加額外負擔。

如果常常漏掉工作，先檢查來源涵蓋範圍與交接缺口。如果每天出現一大串沒有行動價值的提醒，就縮小候選範圍。如果每日紀錄開始變成另一份完整專案文件，就改回短摘要與連結。

這套方法能否持續，取決於它是否讓我更容易決定並開始下一個動作，而不是產生更多分類、文件或通知。

參考方法與取捨

PARA 依當前用途區分專案、長期責任、資源與封存，提醒我保留歷史不等於每天都要看到它。GitHub Projects 的管理建議則把狀態與日期分開管理，並強調單一事實來源。

我的每日入口試行借用這些原則，再配合語音輸入與 Agent 回想。它是針對目前工作困難的調整，並不表示每個人都適合按日組織專案，也不表示日期命名本身就能解決多專案管理。