iT邦幫忙

2025 iThome 鐵人賽

DAY 8
0
生成式 AI

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

【Day 8】每到穩定就記錄:與 AI 長期合作的自保策略

  • 分享至 

  • xImage
  •  

今天是鐵人賽第八天。
延續前天與 AI 協作解決 pytest 問題後,我決定先將專案納入 Git 版本控制。
版本控制的好處很明顯——只要在「能正常運行」的時刻做一次版本記錄,之後即使 AI 同事突然暴走,我也能快速回到暴走前的狀態,防止災難擴大。

順利建立好 GitHub 環境後,我發現 AI 同事連微小的文字更新也會立刻 Push 上去。為避免過度頻繁的 Push 操作,我請他改成等我完成重要更新並同意後,再進行 Push。

接著,我先用 /clear 清除舊的對話背景,讓 AI 同事重新理解目前的應用狀態,並開始規劃下一個功能。第一階段是「資料庫模型與結構定義」。我採用一問一答並附選項的方式,與 AI 一起釐清所需的 Permission、Role 與 User 模型,並著手建構。

我發現 AI 同事在初次建構時通常只會先做一個大致的雛形,因此常帶有一些錯誤,需要我溝通指正,他才會再修正。這次雖然也出現錯誤,但比之前容易得多,只用了幾個指令就順利解決。

由於模型內容有調整,pytest 測試也需要同步修改。不過因為之前基礎打得紮實,AI 同事這次只需微調就能完成。到這個穩定的節點後,我立即用 Git 將檔案推送到 GitHub——我認為「每個功能穩定運行時就做版本記錄」是非常值得養成的好習慣。

今天完成了權限相關模型架構。經過上週的 debug 大魔王與昨天的架構盤點,今天與 AI 的協作明顯順暢許多。希望未來能越來越默契。那麼DEBUG大魔王跟昨天的盤點整理後,今天在跟AI同事共事上有比上禮拜更順利一點,願之後能越來越順利。

以下為今天的研究流程


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

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

等他瞭解目前進度後,請他先幫我規劃git版本控制的功能。
我給AI的指令:

我現在想先做git做版本控制,並將專案更新到github,請幫我規劃

AI同事告訴我,我需要先在我的github上創立一個空的儲存庫,再給他儲存庫的URL。
我把他需要的URL給他之後,他就開始操作包含創建.gitignore排除敏感的檔案。
由於我之前電腦就已經有git的環境,所以除了中間跳出要我登入哪個帳號的選項外,其他都很順利就完成了。
我檢查了github上的內容,的確資料都順利上傳,.env等敏感資料也正確沒有上傳上去。
不過我發現我改個文檔他每次都做push上github太過繁瑣,因此我告訴AI同事,除非完成大更新且我同意再push上github。
我給AI的指令:

記住,只有完成大更新且我同意再push上github

版本控制完成後,接下來就繼續我們的應用建置了,首先為了避免像之前一樣被舊的文本影響,首先我用/clear指令清除舊文本,再請AI同事重新了解應用現況。
我給AI的指令:

請幫我計畫實作下一個功能 

他規劃了一個版本,但我想說讓AI同事以backend-architect的角度去優化一下計畫。
我給AI的指令:

@agents/engineering/backend-architect.md 以你的角度,有什麼需要優化或者有問題需要改善的地方

帶入角色後,AI同事給出了很多原本沒提到的細節建議:

  • JWT 令牌管理與撤銷機制
  • 認證端點的速率限制 (Rate Limiting)
  • 權限粒度與管理
  • 初始資料填充 (Seeding)
  • 錯誤處理的標準化
  • 安全標頭 (Security Headers)
  • 審計日誌 (Audit Logging)

很多其實都蠻重要的,我就讓他幫我根據建議重新計畫。
我給AI的指令:

好的,請按照你的建議,重新幫我計畫 

他給出了一版新的計畫內容,內容比原本那版更加完善,但架構有點大,我請AI同事把他的計畫更新到ai_context.md與README.md,方便今天沒做完明天繼續做時,不會偏離今天規劃的內容。
我給AI的指令:

我同意這個計畫,請將計畫內容詳細更新到@ai_context.md @README.md,以便如果這次沒做完,下次可以接著計畫繼續做

紀錄完之後,AI同事問我是不是開始第一階段的 「資料庫模型與結構定義」,不過在結構定義部分,我擔心AI同事會暴走,所以我請他用一問一答的方式,先詢問我,在建構。
我給AI的指令:

好的,在結構定義部分,請用一問一答方式詢問我,並在問題中都提出建議選項跟優缺

在一問一答的過程中,除了AI同事提供的選項,我會針對選項,並提出能否增加某某功能,可以增加建構的彈性等。
討論完之後他就開始實作討論的功能了,他第一階段先規劃了三個模型定義:

  • Permission 模型:定義權限
  • Role 模型:定義角色
  • User 模型:定義使用者

在AI同事完成建構後,我請AI同事檢查建構的功能是否正常運作。
我給AI的指令:

檢查這三個功能是否正常運作

果不其然,AI同事在做這種稍微比較複雜的工作很容易各做各的功能導致許多錯誤跳出,例如無法找到backend 模組、循環導入錯誤等常見錯誤,不過AI同事試圖修復他並完成修復。
再來我檢查之前pytest,因為AI同事這次修改了一些程式邏輯,所以pytest如我所預料無法正常執行,這時我請AI同事去根據內容修正。
我給AI的指令:

這次更新@backend/tests/ 的內容就失敗了,請幫我調整內容符合這次更新

由於先前已打好基礎,AI 同事只需稍作調整便順利通過測試。
在這個階段完成後,我請他將檔案透過 Git 推送上去。在每個功能可正常運行的階段進行版本控制,是一個值得養成的好習慣。

今天進度就先告一段落,明天會繼續下一個階段:「認證與授權工具」,所以我告訴AI同事,紀錄今天進度,以便明天繼續。
我給AI的指令:

請將這次內容更新到@ai_context.md @README.md ,以便如果這次沒做完,下次可以接著計畫繼續做

上一篇
【Day 7】技術可以靠 AI,判斷得靠自己:一週實戰後的合作策略盤點
下一篇
【Day 9】認證授權全上線:修完 Bug 還得防 AI 改壞程式
系列文
30 天與 AI 同事打造系統的求生實錄30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言