iT邦幫忙

2026 iThome 鐵人賽

DAY 30
0
Vibe Coding

重新認識Github Copilot (續)系列 第 30 篇

Day30 - 完賽回顧:從 Vibe Coding 走向 Agentic Workflow!!!

  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20261014/201033333W8P2UcPzW.png

沒想到一轉眼就來到第 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 的開發流程。

https://ithelp.ithome.com.tw/upload/images/20261014/20103333274I5Li8ce.jpg

①~②:從零到補全
第一階段完全不用 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等魔王關先標記起來,明年再戰!/images/emoticon/emoticon12.gif

☁️ GitHub Copilot Cloud Agent:AI 不只在本機工作
Cloud Agent 把開發工作延伸到 GitHub 雲端環境。
這次回顧時,筆者也特別補充了 GitHub Copilot Cloud Agent。原本以為 Coding Agent 只是在本機 IDE 裡幫忙,結果 Cloud Agent 居然可以搭配 GitHub,在雲端環境裡處理工作。

https://ithelp.ithome.com.tw/upload/images/20261015/20103333yPhXCAeBjn.jpg

舉例來說,筆者可以把需求放進 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

https://ithelp.ithome.com.tw/upload/images/20261015/20103333YkQu3mWlmM.jpg

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

https://ithelp.ithome.com.tw/upload/images/20261015/20103333D4hIwsVvW9.jpg

定義 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 產生的程式碼,能跑起來,真的就代表寫得好嗎?

https://ithelp.ithome.com.tw/upload/images/20261015/20103333f1KMU98LSh.jpg

原本以為只要 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 這些內容,筆者還在摸索中。

https://ithelp.ithome.com.tw/upload/images/20261015/20103333hN5YkLiPSY.jpg

不過從 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 認證。

https://ithelp.ithome.com.tw/upload/images/20261015/20103333iCFUk003Hh.jpg

Applied Skills 是實作型認證,筆者覺得它相對容易入手,因為不是只考選擇題,而是要在實際環境裡完成任務。更佛心的是,這類挑戰可以重複嘗試,失敗也不會直接人生重開,算是很適合拿來練手。

GH-300 的範圍,基本上涵蓋這 30 天練習過的內容。
GH-300 的準備內容,則包含 GitHub Copilot 的使用方式、Prompt、Chat、程式碼分析、測試、重構與負責任地使用 AI。筆者在這 30 天裡幾乎都有碰到,所以如果有跟著完整跑過一輪,準備起來應該不會太痛苦。

更多內容說明的部分,請參考完整版影片囉

👀 本日結論:「不去讀 AI 寫的程式碼,不是一種決定,而是一種能力。」
這句話其實戳到筆者。現在 AI 寫出來的程式碼,筆者還是會仔細看,甚至會反覆確認,因為心裡就是不放心。這不是不相信 AI,而是目前還沒有足夠的規格、測試與驗證機制,讓筆者可以完全不看。

筆者希望未來可以慢慢靠近 Uncle Bob 提到的那種狀態:不是完全不看程式,而是因為規格足夠清楚、測試足夠完整、驗證方式足夠可靠,所以不需要逐行檢查每一段產出的程式碼。

程式碼可以交給 AI 產生,但品質、規格與責任,還是要有人扛。
/images/emoticon/emoticon10.gif


上一篇
Day29 - 什麼!!! Github Copilot 居然可以在 PowerPoint 跟 M365 Copilot 打對台😮
系列文
重新認識Github Copilot (續) 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言