很多人開始用 AI 協助工作後，會遇到一個很現實的問題：AI 很會幫你寫、幫你查、幫你整理，但它常常不知道「現在到底做到哪裡」。
你可能在聊天紀錄裡交代過一次，在文件裡寫過一次，在腦袋裡又記了一半。等下一次叫 AI 接著做，它就像剛進公司的新人，只能很有禮貌地問：「請問目前進度是？」如果每天都要重新交接一次，AI 再聰明也會被你訓練成會議記錄機。
ProjectWorkTracker 就是為了解決這個問題做出來的。它是 TEND「AI許願池」裡的一項產品實驗，目標不是做一個更花俏的待辦清單，而是建立一個人和 AI Agent 都能讀懂、都能維護的工作追蹤中樞。
先講結論：ProjectWorkTracker 解決的不是「我忘記今天要做什麼」這麼簡單，而是解決 AI 協作時最麻煩的三件事：工作狀態散落、任務無法安全交給 AI 更新、每天都要人工重新排序。
痛點一：工作狀態散在太多地方，AI 很難接續
一般個人工作流常常長這樣：
- 想法在聊天紀錄。
- 規格在文件。
- 任務在筆記。
- 進度在腦袋。
- 昨天做到哪裡，可能在一段你自己也找不到的對話裡。
這對人已經不輕鬆，對 AI 更麻煩。因為 AI Agent 要接手工作時，需要知道至少幾件事：
- 目前有哪些專案正在進行？
- 每個專案有哪些工作項目？
- 哪些已完成、哪些取消、哪些暫停？
- 哪些項目逾期？
- 哪些項目優先度比較高？
- 哪個項目底下還有子任務？
如果這些資訊沒有被結構化，AI 每次都只能靠上下文猜。猜對的時候你覺得它很神，猜錯的時候你會開始懷疑自己是不是在跟一台很有禮貌的骰子聊天。
ProjectWorkTracker 的第一個價值，就是把工作狀態從聊天、文件和記憶裡拉出來，變成可以查詢、可以更新、可以回頭看的資料。
痛點二：待辦清單太扁，撐不起真正的專案工作
一般待辦工具很適合記「買牛奶」、「回信」、「補發票」。但實際做產品或內容專案時，任務通常不是一行文字就能結束。
例如一個 AI 內容系統，可能會拆成：
- 需求整理
- 資料來源確認
- Draft 產出
- SEO metadata
- HTML 發佈
- Hub 同步
- sitemap 更新
- 發佈後檢查
這些項目有層級、有狀態、有順序，也可能有工時與到期日。只用一串待辦清單，很快就會變成「看起來很多事，但不知道哪件事卡住」。
ProjectWorkTracker 支援專案底下最多三層工作項目。這個限制看起來保守，但其實很實用。三層足夠拆出主任務、子任務、細項，又不會深到像在挖地道，挖到最後連出口都忘了在哪。
它也保留幾個重要狀態：
- 專案可以是未開始、進行中、暫停、完成、封存。
- 工作項目可以是未開始、進行中、暫停、完成、取消。
- 取消項目不算進進度。
- 封存專案預設不干擾 active overview。
這讓工作不是只有「做完 / 沒做完」兩種結果，而是能反映比較真實的工作狀態。
痛點三：AI 可以幫忙，但不能讓它亂改資料
如果只是人自己用，Web 表單就夠了。但 ProjectWorkTracker 的重點在於：它從一開始就把 AI Agent 納入設計。
它提供本機或內網使用的 Agent API，讓 AI 可以做幾類受控操作：
- 查詢專案清單。
- 查詢未完成工作項目。
- 新增或更新專案。
- 新增或更新工作項目。
- 調整狀態。
- 取消工作項目。
但它不提供硬刪除能力，也不把 API 設計成公開網路服務。這點很重要。
AI 很適合幫你維護資料，但前提是邊界要清楚。你可以讓它新增一個工作項目、把某個項目標成完成、查詢今天哪些事情逾期；但不應該讓它在不受控的情況下刪掉歷史紀錄，或把整個系統暴露到公開網路。
ProjectWorkTracker 的設計比較像是：給 AI 一支筆和一張表格，但不要把資料庫的拆牆工具也交給它。這樣 AI 能幫忙，資料也比較不會被熱心過頭地整理到消失。
痛點四：每天早上最花時間的不是做事，是重新決定要做哪件事
很多工作的麻煩不在於不知道有哪些任務，而是不知道今天應該先處理哪一個。
你可能有十幾個未完成項目，其中有些逾期、有些高優先、有些其實還在等別人、有些只是看起來很急。每天早上重新整理一次，會消耗一點腦力。一天一點，累積起來就是一包很扎實的精神零錢。
ProjectWorkTracker 後續加了一個工作日 Telegram 報告流程：透過 AI 查詢未完成項目，整理成早上的決策簡報。
這個報告的重點不是把清單丟給你，而是幫你整理：
- 未完成項目總覽。
- 今日建議處理順序。
- 逾期或高優先項目。
- 需要決策或等待釐清的項目。
- 依專案分組的工作狀態。
換句話說，它想解決的是「每天早上重新開機」的問題。人還是負責判斷，但 AI 可以先把桌面整理好，不要一早打開工作就像看到十個視窗同時跳更新通知。
ProjectWorkTracker 不是要取代人，而是讓 AI 有地方接手
這個產品最有意思的地方，是它不把 AI 想成一個神奇按鈕，而是把 AI 放進工作流裡。
人負責
- 決定專案目標。
- 判斷工作優先順序。
- 確認任務是否真的完成。
- 做最後取捨。
- 決定哪些事情要暫停、封存或取消。
AI Agent 負責
- 查詢目前未完成項目。
- 協助整理今日焦點。
- 根據指令新增或更新任務。
- 把口語需求轉成結構化工作項目。
- 在受控範圍內維護狀態。
這樣的分工，比「叫 AI 幫我記一下」穩很多。因為任務不是只存在某次對話裡，而是進到一個可查、可改、可追蹤的系統。
它目前不想解決所有問題
ProjectWorkTracker 不是大型團隊管理平台，也不是要挑戰 Jira、Notion、Trello。它現在刻意保持個人使用定位：
- 登入很簡單，只適合本機或內網。
- 不做多人權限。
- 不做公開服務。
- 不做即時計時。
- 不做複雜通知中心。
- 工作項目最多三層。
這些限制不是缺乏野心，而是產品邊界。第一版要先解決最核心的事：讓個人工作可以被結構化，讓 AI Agent 可以安全參與維護。
如果一開始就做成大型平台，很可能最後會得到一個功能很多、但自己也不想每天打開的系統。這種產品很熟悉，通常叫做「我下週會整理」，然後下週從來沒有真正來過。
為什麼它適合放在 AI許願池
AI許願池收的不是單純工具清單，而是 TEND 正在驗證的 AI 實例、Agent 工作流與自動化實驗。ProjectWorkTracker 很符合這個定位，因為它不是只展示 AI 能做什麼，而是在回答一個更實際的問題：
「如果我要長期使用 AI 做事，工作狀態要放在哪裡？」
沒有這種狀態中心，AI 工作流很容易停留在單次對話。今天很順，明天重來；這次有上下文，下次又要重新餵資料。久了之後，你不是在用 AI 加速工作，而是在替 AI 補習你的近況。
ProjectWorkTracker 想補上的，就是這個中間層：讓人、AI、專案、工作項目、狀態與每日決策能接在一起。
結論：真正解決的是 AI 協作的「狀態問題」
ProjectWorkTracker 表面上是一個專案與工作項目追蹤系統，但它真正解決的是 AI 協作裡的狀態問題。
它讓工作不只停在聊天紀錄裡，而是變成可查詢、可更新、可彙整的資料。它讓 AI 不只是幫你回答問題，而是能在受控邊界內參與維護工作流。它也讓每天早上的工作排序，不必每次都從零開始。
所以它不是一個更漂亮的待辦清單。
它比較像是一個給人和 AI 共用的工作中樞：人決定方向，AI 協助整理與維護，系統負責把狀態留下來。
這才是 AI 產品真正值得做的地方。不是把每件事都自動化，而是先讓工作流有地方站穩。
延伸閱讀
- AI許願池：回到 TEND 的 AI / Agent 產品與工作流入口。
- AI Agent 工作流入門與工具整理：補充 AI 工具、工作流與 Agent 分工的基本概念。
- 用 AI 做產品，不要一開始就鑽進細節：延伸理解為什麼工作流比局部實作更重要。
- 編輯與內容原則：了解 TEND 如何使用 AI 協助內容與產品整理。