【Day 18】從SOP到實戰：AI 同事陪我解時間追蹤與文件管理難題

2025 iThome 鐵人賽

DAY 18

生成式 AI

30 天與 AI 同事打造系統的求生實錄系列第 18 篇

17th鐵人賽

elliot_coding

2025-08-18 07:30:22

139 瀏覽

分享至

鐵人賽第18天，今天繼續剩餘後端功能建置。

有了之前經驗，今天的建置前流程特別順利，流程如下：

了解現況
告訴我進度
進度功能計畫
後端角度優化
使用者角度優化
前端角度優化
讀取範例檔，將前面計畫與各角度建議生成計畫檔
開新視窗，讀取計畫檔案開始建置
AI同事自動測試，修復基礎錯誤
AI開始無法修復進入循環，中斷自動測試，改手動測試

這段時間的摸石頭探路後，感覺已經可以整理一套後端AI建置SOP了。

AI同事了解現況後，告訴我現在的進度是時間追蹤功能。
我根據上面那段SOP，程式很快就建置完成，不過測試當然還是會有一些問題。

在測試環節，除了跟之前一樣常出現的命名錯誤跟非同步與同步程式沒統一外。
最大的坑是在測試時間重疊時，一直沒有測通過。
我請AI同事檢查一直提出不太可能的解決地方，去問其他AI也是類似的結果。
一直說我的程式邏輯沒問題，然後想改奇怪的地方。

後來沒辦法，我只好用print去一個一個排查，包含時間格式是否正確、資料是否有插入，結果最後找到的地方是他事前插入資料的user_id與測試時的user_id不同，所以根本不會去比對不同user_id的資料，導致這個測試邏輯上比對完全沒問題，導致很難找出這個BUG。

另一個是時間比對問題，AI同事在檢查開始跟結束時間一致要跳錯，但因為他分開生成，所以會差很微小的時間導致判斷失敗，稍微調整一下也正常通過。

完成並版本控制之後，想說還有時間，就請AI同事討論下一階段的功能輔助功能與數據準備。
一樣使用前面的SOP規劃建置內容，不過這時有個地方發現之前缺乏思考。
文件上傳功能，我原本想直接使用google雲端硬碟分享，但規劃時沒考慮多團隊該怎麼半。
AI同事原本的設計是我申請一個專案管理程式專門用的帳號去做文件管理，但是這有個問題。
一個團隊還好，但是多團隊或者我要分享給別人使用時，如果對方上傳文件，文件存放位置會放在專門帳號的雲端上，一是免費帳號沒那麼多空間分享，二是就算付費升級，別人團隊的資料我可以存取的話也是問題。
目前我思考的是兩個方式：

SaaS（Software as a Service:雲端代管服務），就是架在我的帳號上，提供帳號密碼登入使用
On-Premise Software(交付型軟體)，將程式交給對方部屬，

雲端代管的好處是使用者不用自己去研究架站，省時省力。不過如果用這種方式，文件存放會變成放在我的雲端上，這種方式可能就調整成不能上傳檔案，只能分享檔案連結。
交付行則是一開始會麻煩需要架站管理，但可以自訂檔案要放的雲端空間，這樣使用者就不用另外找地方放再分享連結，直接就可以分享檔案。

兩種各有優缺，針對的客群可能也有差異，當然在軟體設計上也有會一點不同。
問了一下AI同事，他是建議我使用GCS去做文件管理，由於我之前沒有碰過這一塊，不過看起來有免費額度，就決定嘗試看看了。
先去GCS建立了bucket跟服務帳號備用，準備在建置文件管理功能時使用。

申請完之後一樣使用SOP流程去請AI同事計畫輔助功能與數據準備。
並將方案改成GCS，請他計劃建構功能與流程。

這個階段的複雜度跟前幾個階段完全不同等級，明後天會針對後端做個收尾，之後要開始做前端的部分了

以下為今天的研究流程

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

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

AI同事告訴我接下來的計畫是建置時間追蹤功能，這個功能跟前幾天的專案管理與任務管理相比，規模相對比較好。
AI同事合作建構功能SOP，一樣先請他出一版初版，再請他根據後端、專案管理使用者、前端的角度分別給出建議，這裡就不贅述了過程，只提供指令。

請依照目前現況進度幫我計畫，計畫時請用小顆粒度的方式去計劃，並且先告訴我完整計畫不要直接實作

用@agents/engineering/backend-architect.md 視角，去看計畫有沒有需要優化或缺少的地方

@agents/project-management/project-shipper.md @agents/project-management/studio-producer.md 之前是軟體面，現在我希望你分別以這兩個角色，給出應用面的建議，並假設如果需要用到這些功能，這邊要怎麼設計

@agents/engineering/frontend-developer.md 請提供以你的角度，除了原本建議的UIUX功能，這一塊前端在設計UIUX功能時，還會需要後端提供哪些功能給前端使用，請提供你的意見

請參考所有意見，整合一版新的時間追蹤建構計畫，並將計畫與建議寫入時間追蹤計畫.md，格式請參考@document_templates/功能開發計畫_範例.md

這裡我利用了昨天說的新生成的範例文件，去控制他生成的框架，讓AI同事的計畫更符合我想要的結構。
我利用之前任務管理計畫.md文件，請AI同事生成類似的範例。
不過也不是給檔案參考AI同事就直接生出來，中間經過不少疊代調整，依序如下：

整個軟體的計畫
活動計畫
只有計畫沒有紀錄各角度建議
功能計畫+各方向建議

最後調整出一款我喜歡的範例，部分內容如下：

[功能名稱] 開發計畫

概述與目標

功能名稱：[請填寫此功能的名稱，例如：使用者認證、任務建立]

目標：[簡要說明此功能的目的、解決的問題以及預期成果。]

前置條件：

[前置條件一]

[前置條件二]

階段一：資料庫模型與結構定義

定義 [模型名稱] 模型 (backend/models/[模型檔案名].py)

核心屬性：

id: UUID (主鍵)

[屬性名]: [類型] ([描述])

...

關係：

與 [其他模型] 建立 [關係類型] 關係。

...

定義 [其他模型名稱] 模型 (backend/models/[其他模型檔案名].py)

...

定義關聯表 (backend/models/links.py 或獨立檔案)

[關聯表名稱]：[描述]

更新 ActivityLog 模型 (若有)

[說明如何更新 ActivityLog 以記錄此功能相關操作]

階段二：Pydantic Schema 定義

建立 backend/schemas/[功能相關檔案].py

[Schema名稱]Base: [描述]

[Schema名稱]Create: [描述]

[Schema名稱]Update: [描述]

[Schema名稱]Response: [描述]

...

建立 backend/schemas/[其他功能相關檔案].py (若有)

...

使用後果然比之前順利，不用再補充資訊AI同事就知道我想要什麼。
計畫文件完成後，請AI同事讀取計畫內容。
我給AI的指令：

@時間追蹤計畫.md 這是時間追蹤的建置計畫內容

等AI同事讀完文件之後，請他根據文件內容開始建置功能。
這次時間追蹤建置的功能不多，很快就建置好了，不過一開始一樣會有同步與非同步的問題。

除了原本就常發生的問題，這次被AI同事挖了一個坑。
在測試時間重疊需要觸發報錯時，一直都沒觸發，相關程式也來來回回修了幾次，也問了其他AI但也沒有解決。
最後為了發現問題所在，我使用print把相關地方的資訊都顯示出來，包含輸入的資料對不對，資料庫內的資料，各個user_id的筆數，最後終於發現問題，AI同事他預設的user跟插入資料的user不是同一個id，結果是他插入資料時，臨時新增的id，因為id不同，根本找不到該比對是否重疊的資料。
這個錯誤不是真的去一個一個排修，真的會找不出來。

另一個則是常見的時間比對時，相同時間應該要報錯，但由於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 ，去提供設計前端功能時，需要後端提供哪些功能給前端使用

這次建構由於功能相對複雜，跳出來的錯誤也複雜許多，這部分可能要花點時間去做處理。
等這個階段告一段落，雖然後端還有一些功能可以做，但前端再不開始就會太趕了。
因此在收尾一兩天，就會開始準備前端的工程了。
如果前端的部分做完還有時間，會再來補設計但還沒做的功能~