鐵人賽第17天，今天的重點是規劃任務管理功能，並與 AI 同事進行實作。
由於之前在開發專案管理功能時的流程體驗不錯，這次我同樣採用相同的流程來推進。

一開始，我先下指令讓 AI 同事了解當前進度與整個框架；接著，為了避免他在討論階段就開始實作，我特別叮嚀：在討論結束前不能動手。
當 AI 同事準備好後，我依照以下步驟展開討論：

• 請他先規劃一版建構計畫。
• 再從後端角度檢視，看看是否有需要優化或補強的地方。
• 接著以使用者角度（如專案經理）出發，思考應用情境，並在後端設計上增加必要功能。
• 再換成前端角度，設計 UI/UX 時會需要哪些後端支援。
• 最後整合以上意見，調整出一版新的任務管理建構計畫，並將完整計畫與建議寫入 任務管理計畫.md。

這套流程涵蓋多角度思考，可以減少後期因需求變更而導致的大量修改。
不過這次在輸出計畫時出現小狀況──我原本希望他參考 專案管理計畫.md 的格式來寫 任務管理計畫.md，結果可能受到干擾，他在紀錄任務管理建議時把內容寫成昨天的「專案管理建議」。
我本來想直接下指令更正，提醒他要寫「任務管理」而不是「專案管理」，但結果卻導致一些本來與專案管理相關的「任務管理功能」也被刪掉了。

為了避免計畫變得混亂，我最後只保留了 任務管理計畫.md 的標題，然後重新開一個 gemini cli，再請 AI 同事完整跑一次設計流程。
下次我會改進方法：先請他根據範例文件生成「只有格式、沒有內容」的模板，再依照模板去填寫內容。這樣可以避免因直接丟 A 文件，導致他誤把內容當成指令來生成 B 文件，進而造成混淆。

跟AI同事溝通的時候，步驟最好不要省略。
例如我有一份A文件，我想要用A文件的結構去生成B文件，如果我直接丟A文件，AI會把A文件的內容也當成指令，結果生成時就容易造成混淆。
但如果先給文件，請AI同事參考文件生成沒有內容的範例，再透過範例文件生成另一個內容的B文件，文件品質會比原本提高不少。

進入任務管理的實際建構階段後，AI 同事表現得還不錯。雖然在多檔案建構時，常出現 未 import函數 或 命名不一致 的小問題，但我先讓AI同事自行測試修復，基本上都能解決。
等到遇到同一個錯誤嘗試了好幾次都沒解決時，我就會中斷測試，改由我手動排查。

在開始測試前，我先請 AI 同事幫我規劃測試順序，他依照依賴關係給了以下建議：

1. test_task_statuses.py：測試任務狀態的建立和管理。
2. test_tags.py：測試標籤的建立和管理。
3. test_tasks.py：測試核心任務管理功能，這些功能依賴於狀態和標籤。

我照著這個順序測試，果然問題都相對容易處理。大部分錯誤 AI 同事就能自行修復，只有少部分問題，我請外援 Claude 幫忙，很快也解決了。

這次測試比前幾天順利許多，測試心得包括：

• AI同事replace定位錯誤找不到位置，手動介入處理修改。
• AI同事相同錯誤換了兩三個方法後，錯誤訊息不變時，立刻中斷，將錯誤訊息或者AI同事給的修改內容貼給其他AI模型，通常會給初不一樣的視角。
• 只貼關鍵錯誤訊息給AI同事，不讓他自己直行測試程式去讀錯誤訊息，以免受到太多不相干資訊的影響導致錯誤判斷

後端功能也快要接近尾聲了，再一兩天收尾後，就準備要朝我比較不熟的前端建置，不知道沒什麼碰過前端的我，與AI同事合作是否能像後端一樣順利。

以下為今天的研究流程

首先開始前的老樣子，請AI同事了解應用現況。
我給AI的指令:

@ai_context.md @README.md @軟體核心架構規劃.md @功能需求總覽.md   了解目前現況

由於之前請他規劃專案管理的流程實做下來體驗不錯，因此我決定任務管理也使用這一套流程。
流程如下：

• 請依照目前現況進度幫我計畫，計畫時請用小顆粒度的方式去計劃，並且先告訴我完整計畫不要直接實作
• 用@agents/engineering/backend-architect.md 視角，去看計畫有沒有需要優化或缺少的地方
• @agents/project-management/project-shipper.md @agents/project-management/studio-producer.md 之前是軟體面，現在我希望你分別以這兩個角色，給出應用面的建議，並假設如果需要用到這些功能，這邊要怎麼設計
• @agents/engineering/frontend-developer.md 請提供以你的角度，除了原本建議的UIUX功能，專案管理這一塊前端在設計UIUX功能時，還會需要後端提供哪些功能給前端使用，請提供你的意見

不過有時候AI同事很急，還沒討論完就想開始做，這時候按esc中斷他的流程，並告訴他等我們討論完再開始。
我給AI的指令：

在完全討論完之前，我說可以開始實做之前，都不要有任何實作，並把剛剛實作的地方還原 

中間遇到一些問題，gemini cli轉了很久沒有跑出東西，可能AI同事下班了，我過了一段時間關掉重開後，AI同事才又回神繼續工作。
後來重新用下面流程重跑一次，才正常輸出：

• 在完全討論完之前，我說可以開始實做之前，都不要有任何實作，並把剛剛實作的地方還原
• 先請他規劃一版建構計畫
• 請他依照後端腳色看有沒有需要優化跟缺少的地方
• 請他依照使用者腳色，例如專案經理的角度去給出應用面的建議，以使用者需要的功能增加後端設計
• 請他以前端腳色設計UIUX時，會需要哪些後端支援
• 請參考所有意見，整合一版新的任務管理建構計畫，並將計畫與建議寫入任務管理計畫.md

不過在輸出任務管理計畫時，因為我想讓AI同事參考之前專案管理計畫的格式去輸出，結果因為我用@讓他讀資料，他把內容有參考進去了，而且建議寫成給專案管理而不是任務管理的建議。
我本來跟AI同事說寫錯了，寫成專案管理內容，結果AI同事又誤會把任務管理中有關專案管理的部分改掉。
變成一份有點亂的計畫，為了避免這個問題，我直接將輸出文本全部清除，只剩下標題格式，在重新跑一次剛剛的計畫流程，讓他生出一份乾淨的計畫。

計畫大致看過沒什麼問題，使用/clear清除舊的文本，讓AI同事用乾淨的狀態實作。
實作前一樣先請AI同事了解現況。
我給AI的指令：

@ai_context.md @README.md @軟體核心架構規劃.md @功能需求總覽.md   了解目前現況

AI同事了解之後，在請他了解任務管理的計畫內容。
我給AI的指令：

@任務管理計畫.md 這是任務管理的建置計畫內容

AI同事了解之後，我請他按照這份計畫進行任務管理實作。
我給AI的指令：

請依照這份計畫進行實作

AI同事開始建構程式，建構時他依照需求依序將程式建構上去並建構pytest去測試功能。
前期測試時蠻多import跟命名錯誤，這種類型AI同事擅長排查，所以我先讓AI同事自己去排錯。
直到排錯進入下一個階段，AI同事開始鬼打牆，一直在嘗試解決同一個錯誤時，我停止了AI同事的自動排錯，告訴他我現在要手動排錯。
我給AI的指令：

好的，看來目前的錯誤已經超過你的能力範圍，現在開始手動排錯 

我看了一下AI同事新產生了測試檔，我請AI同事推薦我測試順序，回應如下：

✦ 使用者正在詢問新添加的測試檔案 test_tags.py、test_tasks.py 和 test_task_statuses.py 的推薦執行順序。
我應該推薦一個尊重依賴關係的順序。

• Task 模型依賴於 TaskStatus 和 Tag 模型。
• Task 操作（建立、更新）可能涉及 TaskStatus 和 Tag ID。
• 因此，先測試 TaskStatus 和 Tag 的建立/管理是有意義的，因為它們的成功操作是 Task 測試的先決條件。
  所以，推薦的順序是：

1. test_task_statuses.py：測試任務狀態的建立和管理。
2. test_tags.py：測試標籤的建立和管理。
3. test_tasks.py：測試核心任務管理功能，這些功能依賴於狀態和標籤。

我依序檢查錯誤訊息在test_task_statuses與test_tags錯誤相對單存，錯誤約分幾種：

1. session錯用成db
2. 功能需要非同步但部分程式碼未改成非同步

這兩個修改完就順利解決，但test_tasks功能相對複雜，因此除了這兩個錯誤外，有許多錯誤需要解決。
但大部分在貼給AI同事都能順利解決，目前遇到一兩個重複修改未解決的，
將錯誤訊息或者AI同事修改內容貼給claude，請他提出建議，再將建議貼給AI同事，也很順利的解決問題。
直到現在，任務管理相關功能也全部測試完成。