
沒想到一轉眼就來到第 30 天,居然沒有斷賽!!!每天固定產出、整理內容、錄影片、補圖片,說不累是騙人的,尤其到了後半段,腦袋大概只剩下「今天到底還有沒有發文啊」 😵💫
不過,這次完賽對筆者來說,並不是結束,反而比較像是一個起點。因為筆者這 30 天真正想摸清楚的,不只是 GitHub Copilot 的特異功能,而是 AI Coding 到底會把軟體開發帶到哪裡?
這篇就來做一次 recap,對 AI Coding 演進的理解,以及接下來明年鐵人賽想挑戰的 Agentic Development Workflow 與 Copilot Cloud Agent。
🪜 目前站在 AI Coding 的第幾關?
AI Coding 可以拆成八個階段。這個概念來自前 AWS 工程師 Steve Yegge 對開發者 AI 演進的整理,從完全不用 AI,到最後自己打造一套可以協調多個 Agent 的開發流程。

①~②:從零到補全
第一階段完全不用 AI,第二階段開始使用基本的 code completion,讓工具幫忙補幾行程式碼。這時候 AI 比較像一支很會猜的自動鉛筆,偶爾猜對,偶爾也會把筆者帶去奇怪的地方。
③:IDE 裡的聊天助理
把 Chat 模式開在 IDE 裡,遇到錯誤可以問、看不懂的程式可以請它解釋。這個階段筆者其實已經用了不少,算是日常開發的基本配備。
④:Coding Agent 接管工作區
Agent 不只回答問題,而是可以讀取專案、修改檔案、操作目錄,甚至在 VS Code 中直接執行一連串工作。這時候權限變大了,風險也跟著變大,不能再把它當聊天機器人看待。
⑤~⑧:多 Agent 與自動化流程
從 CLI 執行單一 Agent,到多個 Agent 平行工作,最後甚至建立自己的開發工作流與 Orchestrator。這已經不是「我叫 AI 幫我寫一段程式」,而是「我設計一個系統,讓 AI 自己跑流程」。
老實說,筆者目前大概落在第四階段附近,偶爾摸到第五階段的門口,但後面的多 Agent、完整自動化流程,還沒有開始練。所以筆者已經先把 2027 年可能挑戰的內容列出來,包含 GH-200、GitHub Agents,以及更完整的 Agentic Workflow等魔王關先標記起來,明年再戰!![]()
☁️ GitHub Copilot Cloud Agent:AI 不只在本機工作
Cloud Agent 把開發工作延伸到 GitHub 雲端環境。
這次回顧時,筆者也特別補充了 GitHub Copilot Cloud Agent。原本以為 Coding Agent 只是在本機 IDE 裡幫忙,結果 Cloud Agent 居然可以搭配 GitHub,在雲端環境裡處理工作。

舉例來說,筆者可以把需求放進 GitHub Issue,請 Cloud Agent 去探索 Repository、建立分支、修改程式、執行測試,最後產生 Pull Request,甚至請它協助做 Code Review。
🤖 筆者看到的重點:GitHub Cloud Agent 讓人與 Agent 形成一個 Hybrid Team。
這個模式讓團隊不再只有人與人合作,也可以把 Cloud Agent 放進開發團隊中,讓它負責明確、可驗證的工作,例如:
修正小型 Bug
補上 Unit Test
更新文件與註解
協助分析 Issue
提出 Pull Request
針對變更內容進行 Code Review

🔁 Agentic Workflow:從「使用工具」進化成「設計流程」
GitHub Agentic Workflow:由 Markdown 定義流程,再交由 GitHub Actions 執行。
筆者覺得真正有趣的地方,是 Agentic Workflow。當我們把流程寫進 Markdown,再透過像 .lock.yml 這類檔案固定權限、觸發條件與安全輸出,接著 Commit、Push,最後由 GitHub Actions 呼叫 Agent 執行任務,這時候就不只是「用 Copilot」而已了。

定義 Workflow:先用 Markdown 描述任務、觸發條件、工具與預期輸出。
固定執行規則:把 Workflow 編譯或轉換成 GitHub Actions 可以執行的設定。
Commit 與 Push:把流程檔案放進 Repository,讓它成為團隊可追蹤的一部分。
Agent 執行任務:由 GitHub Actions 在雲端環境啟動 Agent,進行分析、修改或產生結果。
人工 Review:檢查 Commit、Log、測試結果與 Pull Request,再決定是否合併。
🧭 從 Vibe Coding、結構化開發,到 Agentic Engineering。
Google 今年針對 Vibe Coding 與新 SDLC 提出的白皮書,也讓筆者重新思考:AI 產生的程式碼,能跑起來,真的就代表寫得好嗎?

原本以為只要 Prompt 下得夠好,AI 就能一路把 Prototype 生出來,結果確實很快,甚至快到讓人有點害怕。但「可以 Run」和「這是最佳解」中間,隔著一整條工程品質的高速公路。
⚡ Vibe Coding
適合探索、Prototype、PoC 和個人實驗,速度非常快,使用門檻也低。但程式檢查、測試與架構約束通常比較少,風險相對高。
🧩 Structured AI-Assisted Development
開始加入規格、限制條件、範例、測試與人工 Review,讓 AI 不只是自由發揮,而是在較明確的框架中逐步完成工作。
🛡️ Agentic Engineering
將正式規格、架構文件、Context、Automated Tests 和 Guardrails 納入流程,讓 Agent 可以實作、驗證、修正,形成可持續迭代的工程循環。
🏠 GitHub 全家桶,筆者還有幾關沒打
GitHub 把開發、Actions、Copilot 與 Agentic AI 串成一套學習路徑。
筆者目前工作上比較常接觸 Azure DevOps Pipeline,還沒有完整使用 GitHub Actions 與 GitHub Agent 的所有功能,所以 GH-200、Cloud Agent 這些內容,筆者還在摸索中。

不過從 GitHub Foundations、GH-200、GH-300,到後面的 Agentic AI 路線,可以看得出來 GitHub 正努力把原始碼管理、CI/CD、Copilot、Security 和 Agent 串成一條路。微軟與 GitHub 這次確實很用心在推 Agentic Workflow,路線也拆得蠻細,對想要循序練習的人算是友善。
🎓 30 天的兩個學習目標:Applied Skills 與 GH-300
這次挑戰一開始,筆者設定了兩個小目標。第一個是完成 Microsoft Applied Skills,第二個則是準備 GitHub Copilot 的 GH-300 認證。

Applied Skills 是實作型認證,筆者覺得它相對容易入手,因為不是只考選擇題,而是要在實際環境裡完成任務。更佛心的是,這類挑戰可以重複嘗試,失敗也不會直接人生重開,算是很適合拿來練手。
GH-300 的範圍,基本上涵蓋這 30 天練習過的內容。
GH-300 的準備內容,則包含 GitHub Copilot 的使用方式、Prompt、Chat、程式碼分析、測試、重構與負責任地使用 AI。筆者在這 30 天裡幾乎都有碰到,所以如果有跟著完整跑過一輪,準備起來應該不會太痛苦。
更多內容說明的部分,請參考完整版影片囉
👀 本日結論:「不去讀 AI 寫的程式碼,不是一種決定,而是一種能力。」
這句話其實戳到筆者。現在 AI 寫出來的程式碼,筆者還是會仔細看,甚至會反覆確認,因為心裡就是不放心。這不是不相信 AI,而是目前還沒有足夠的規格、測試與驗證機制,讓筆者可以完全不看。
筆者希望未來可以慢慢靠近 Uncle Bob 提到的那種狀態:不是完全不看程式,而是因為規格足夠清楚、測試足夠完整、驗證方式足夠可靠,所以不需要逐行檢查每一段產出的程式碼。
程式碼可以交給 AI 產生,但品質、規格與責任,還是要有人扛。![]()