鐵人檔案
這個平台最初只是 DBA 為降低資料庫申請與權限作業風險而開發的自用工具，如今正與中心內四個科的作業流程對接，成為後續自動化的共同基礎。本系列將以 30 天記錄平台從 Jupyter Notebook、Vibe Coding 到 AI Engineering 的三代演進，分享如何運用 Spec、Plan、Task、Agent、驗證與人工審查，建立超過 100 項需求的血淚史。
Day 10 我先處理 AI 改程式時的範圍：哪些檔案可以動、哪些 API 與 payload 不動，完成後再看 Git diff 和頁面。 為了讓這次驗收完後...
Day 11 我把功能驗收寫成 Scenario，讓 LLM 透過 Playwright MCP 依照前置條件操作頁面。Scenario 確認的是：使用者依既定...
Day 12 的 Security Agent 完成檢查後，我會先確認修法與剩餘風險，再進入文件更新。 剛開始做這套流程時，我把文件當成每次功能完成後要補齊的工...
六月底的一天，我開始陸續調整畫面，那次在一份需求文件上一次列了11個要調整的地方項目。多數是文字調整或小 bug：欄位文字要改、某個預設值該拿掉、確認頁該顯示姓...
六月底那一天，我把需求文件裡的 11 項分完類、安排執行順序後，回頭想，指揮中心能把工作分批、判斷誰跟誰能平行做，是使用我定義好的 Agent —— Front...
Day 15 定義了五個角色——誰來做。這一篇講怎麼做：那些反覆執行的流程，被寫成一份一份的 Skill 檔案。 第三代我保留了 Spec Kit 的骨架，...
Day 14 那天的 11 個任務，是我手動分類的：哪些是 bug、新功能、文字調整。後來這件任務寫進了指揮中心 /orchestrate，變成它收到任務檔之後...
為了不讓兩個 agent 同時改同一個檔案，導致後做的會把先做的蓋掉。 所以六月底那天走完整流程的 3 個任務，指揮中心沒有一次全部丟出去。那時距 7/31 上...
