技術 Day 28｜把服務藍圖變成工具：查規則、補資料、產生草稿、確認送出

Day 27 的目標很清楚：使用者說一次需求，Agent 先交出完成八成的申請草稿，使用者集中調整一次，再完成送出。 接下來要處理真正的技術問題。Agent 要...

技術 Day 26｜第四代 DAP 的目標：讓 Agent 協助完成一張申請單

第四代 DAP 的使用方式，會從一句話開始： 幫我申請一張資料抄寫單。來源是某張業務資料表，每天更新，需要同步到雲端。 Agent 讀完後，先找到「資料抄寫...

技術 Day 22｜第一次 UAT：用跨角色走查找出流程斷點

第一輪 UAT 開始，什麼請況都會出現，使用者如何操作真的是很難預期。 第一批人開始操作後，有一張單據從申請、審核一路走到最後，按下結案時卻出現伺服器錯誤。 原...

技術 Day 21｜UAT 我的規劃架構與修復原則

距離第一次 UAT 前，剩下四天 6 月 27 日，指揮中心第一次完成一整批需求，還剩下一些小功能調整後，7 月 1 日，系統就要交給第一批 UAT 人員使用，...

技術 Day 19｜我以為 Agent 越多越快

Day 14 到 Day 18 鋪的東西——角色、Skill、分流、排批次——這一篇第一次合體。六月底一個早上，我的清單上有 30 多項任務。距離 7 月 3...

技術 Day 18｜多個 agent 同時動工前，先排好誰先誰後

為了不讓兩個 agent 同時改同一個檔案，導致後做的會把先做的蓋掉。 所以六月底那天走完整流程的 3 個任務，指揮中心沒有一次全部丟出去。那時距 7/31 上...

技術 Day 17｜一批需求進來，先分流：小改直接做，新功能才走完整流程

Day 14 那天的 11 個任務，是我手動分類的：哪些是 bug、新功能、文字調整。後來這件任務寫進了指揮中心 /orchestrate，變成它收到任務檔之後...

技術 Day 13｜Step 8：把系統現況寫進文件，讓下一次開發接得上

Day 12 的 Security Agent 完成檢查後，我會先確認修法與剩餘風險，再進入文件更新。 剛開始做這套流程時，我把文件當成每次功能完成後要補齊的工...