.NET Walker

前言 你可能有聽過 GitHub Copilot Coding Agent ，它是一個可以搭配 GitHub Action，在背景自動執行 AI 任務的工具。甫一推出，就讓開發者們眼睛一亮，因為它讓 AI 能夠在 PR 或 CI/CD Pipeline 流程中，自動化地幫助我們完成許多重複性任務。 可惜的是，它目前只能在 GitHub Repo 上使用。 因此，我試著開發了 ADO Coding Agent 套件。 簡單來說，ADO Coding Agent 就像是 GitHub Copilot Coding Agent 的 Azure DevOps 版本 - 它可以在 Azure DevOps Pipeline 中自動執行你給 AI 的提示詞 (背後是 GitHub Copilot CLI)，將 AI 的強大能力與 CI/CD 工作流程無縫整合。 我之前也 Demo 過，如何在 Azure Pipeline 中運行 GitHub Copilot CLI，我對這議題一直很有興趣，因為這讓 AI 驅動的自動化開發變成可能。這意味著，我們未來可能不再需要手動執行重複性的程式碼修改工作，而是可以在每次程式碼提交、或 PR 被觸發時，透過 Pipeline 讓 AI 來執行這些自動化工作。 無論是自動化 Code Review、自動生成單元測試、自動撰寫文件、自動修復 Bugs、或是進行程式碼重構，ADO Coding Agent 都能夠在背景完成，並且把結果直接寫回 Repo 中，這已經不只是效率的提升，而是我一直期待的 24h 自動化 AI 開發團隊的逐漸成形。 具體使用方法: 在 Pipeline 中添加 ADO Coding Agent Task (套件安裝位置： https://marketplace.visualstudio.com/items?itemName=tw-developer.ado-coding-agent )。 在 GitHub 站台上申請一個具有 Copilot Requests 權限的 PAT (申請位置： https://github.com/settings/personal-access-tokens/new )，這是因為該 task 主要是在 Pipeline 中調用 GitHub Copilot CLI ...

你有沒有過這種經驗？把資料庫密碼寫在設定檔裡，commit 之後才驚覺「慘了！」然後開始瘋狂 Google「如何從 Git 歷史紀錄中永久刪除檔案」。 或者更糟的是，一時偷懶把 API Key 硬寫在程式碼裡，結果被同事在 Code Review 時抓包，尷尬地說「我只是暫時測試用的啦」（但其實已經在 Production 跑了三個月）。 歡迎來到~密碼管理地獄。😈 然而你可能不知道，Azure 提供了一個叫做 Managed Identity（受控識別） 的機制，可以跟本性的解決這類問題。 Managed Identity 是 Azure AD 中的一種應用身分（Service Principal），它就像是幫你的應用程式辦了一張「雲端身分證」。有了這張身分證，你的 WebApp 可以直接向 Azure 的各種服務（像是 Key Vault、Storage、Database）亮出證件說：「嘿，我是合法的！讓我進去！」 同時完全不需要在程式碼裡寫任何帳號密碼。 😲 這就像是住在有門禁管理的大樓，你不需要每次都掏出鑰匙，因為管理員認識你的臉。系統會自動幫你驗證身份，既方便又安全。 為什麼這麼做會讓老闆和資安長都笑開懷？那你得先知道，究竟使用 Managed Identity 的好處有多少? 1. 零密碼外洩風險 💪 當你的程式碼裡 完全沒有 密碼時，就算有人偷看你的 GitHub Repository、翻遍你的設定檔、甚至把整個專案下載回去，也拿不到任何可以用來入侵的憑證。因為根本就不存在！這就像是你家的保險箱沒有鑰匙孔，只能透過虹膜辨識開啟，小偷就算把保險箱搬走也沒用。 2. 不用再煩惱密碼輪替(Rotate) 🔄 傳統做法中，如果要定期更換密碼（資安政策通常要求 90 天換一次），你常常得改設定檔檔、重新部署、還要確保所有環境都同步更新。一個不小心，Production 就掛了。但使用 Managed Identity，Azure 會在背後自動處理所有的憑證更新，就像是有個超敬業的助理幫你處理所有煩人的行政工作。 3. 精準的權限管理 🎯 透過 Azure 的 IAM（Identity and Access Management），你可以精確控制「 誰 」可以「 對什麼資源 」做「 哪些操作 」。想讓 WebApp ...

我有兩次非常不好的用餐經驗。嗯…或許，該說是一次半。🤔 某天假日，一時興起想吃個早午餐，到了知名的連鎖店之後，點了看起來頗可口的漢堡。過程一切順利，餐點非常迅速的上桌，我迫不及待地品嘗一口，溫度適中，口感極好。一切都非常的完美… 直到…桌上放醬料的籃子旁，突然出現一隻蟑螂，會動的。靠~ 我不動聲色，伸手攔截了剛好從我座位旁經過的服務人員，他一臉驚訝地望著我(我猜他是在想，我為何突然伸手襲擊他!?)。 我什麼都沒說，隨即給了他一個眼色。 他朝我的目光望去，臉上的驚訝轉為慌張。 但，他也不動聲色(厲害!)，朝著目標前進，居然用手一巴掌把目標物給抓了起來，隨即往廚房走去，就好像什麼事情都沒發生過一樣。 另一次，一天早晨，我到了一個過去不曾來過的地點，因為剛好有一段不長不短的時間(等人)，所以我就沿著大街閒逛，突然看到一家老麵包子店，正愁沒吃早餐，因此我就隨便點肉包菜包各一份，想說試試看。 沒想到，非常之好吃 ! 我對包子是很挑的，我覺得全台灣好吃的包子只有三家，而我今天吃到的這家，居然可以媲美我心中第二名，這讓我內心的包子排行榜大大的洗牌了。 回到家之後，立刻把這包子跟家人分享。 然後我也很疑惑，這麼好吃的店怎麼從來沒有聽到過呢? 上網查。 一查不得了，Google 評價非常兩極。 翻了幾頁都還無所謂，直到我看到一個評價，除了文字還附上了一張照片。 文字是這麼寫的：『吃到腳了，有人吃到頭嗎?』 然後照片是包子裡面一節蟑螂的腳。 靠~ 又來。 你猜，我後來還有去這兩家店嗎? 再也沒有，一次都沒有。 這兩家店不好吃嗎? 不會，其實都很好吃。 但我不會去了，因為我對這兩家店完全失去信心。 (那怕其中一家根本不是親身經驗) 上面是第一段故事。 接著，我要講另一段我前幾天在課堂上說的故事。 我有一個朋友(不是我)，他從小喜歡外文，也常常看外文書籍，雖然都是自學，但也因此遍覽群書，自從有了 AI 之後，他樂翻了。 透過 AI 的翻譯，他開始閱讀過去不曾讀過的語言，剎那間全世界的浩瀚，都在他的眼前。由於他常常在網路上分享他讀過的書，因此出版社就開始找他作書籍翻譯，他也很開心能夠把不同語言的書籍介紹給更多有興趣的人。 但因為他畢竟都是靠自學和 AI 翻譯，所以對於比較艱澀少見的文字較難掌握，不過整個大方向他是 OK 的，他用極...

上週四晚十一點，有位工作上的夥伴 Eric 在 Teams 上貼出了一段訊息：「剛剛用 Claude 一口氣寫了三個功能，感覺效率爆表！」文末還配上了一個肌肉的 emoji 💪。 隔天，早上九點，我看著他頂著熊貓眼進會議室，手裡拿著第三杯咖啡。「怎麼了？」我問。 「昨晚那幾個功能…有兩個邏輯不對，一個測試全掛…我從半夜改到剛剛。」他苦笑著說「AI 寫得太快了，我根本來不及想清楚就繼續下一個，結果…」 這種場景，你是不是也開始很熟悉？ AI 讓我們變成了「高速公路上的疲勞駕駛」 還記得沒有 AI 的年代嗎？（對，我知道那好像已經是上個世紀的事了，雖然才過了兩年） 以前寫程式是這樣的： 思考需求（泡杯咖啡，先想個 15 分鐘） 設計架構（畫畫白板，跟同事討論一下） 開始寫 code（一行一行慢慢敲） 測試除錯（找問題，修 bugs） 提交上版（長舒一口氣） 現在呢？ 有了 Claude、GitHub Copilot、Cursor 這些開發神器後，開始有所不同： 在 Prompt 輸入方格裡描述需求（30 秒） AI 給你三種架構方案（10 秒） 選一個，AI 自動生成程式碼（20 秒） 複製貼上，改改參數（1 分鐘） 跑不過？問 AI 為什麼（30 秒） AI 給你修正版本（20 秒） 能動，結束。那…繼續下一個功能… 看起來超讚的對吧？效率提升十倍！老闆眉開眼笑，專案進度超前！ 但問題來了：我們的大腦跟上了嗎？ 「認知債」：比技術債更可怕的東西 技術債大家都知道，就是為了趕進度寫出來的爛 code，將來要花更多時間來償還。 但現在我們面對的是一種新型態的債務： 認知債 。 什麼是認知債？就是 當 AI 生成程式碼的速度，遠超過你理解這些程式碼的速度時，累積下來的「理解負債」 。 舉個例子。 某天 AI 幫你生成了一個看起來「完美」的 .NET 8 Web API 專案：用 Minimal APIs 搭配 依賴注入 (DI) 、全域 Exception Handling Middleware 、 EF Core （含 UnitOfWork 與 Repository 模式）、 MediatR 指令/查詢分離、 FluentValidation 、 AutoMapper 、背景作業用 IHos...

我跟你說，我夢想著實現這個功能很久了✌ 我一直希望能夠在 CI/CD Pipeline 中加入 LLM 的力量。 我一直想透過 CLI 讓 LLM 在 Pipeline 中自動處理重複性任務。例如，在晚上讓 AI 自動幫我找 bugs、自動做 Code Review、甚至自動撰寫說明文件或一部分程式碼… 然後，我夢寐以求的 “兩班制全天候24h開發團隊” 就可以實現了!!! 白天，由 Developer 搭配 AI 進行開發。 晚上，由 AI 自己去做比較不需要人監督或無傷大雅的工作，像是寫文件，找 bugs 之類的。 然後隔天早上工程師上班之後，就可以繼續接手 AI 昨晚產出的成果，接著進行開發。 嘿嘿，這樣是不是太完美了? 想想都覺得興奮。 緣起 在現代軟體開發中，效率與自動化是不可或缺的要素。 GitHub Copilot CLI 的出現，為我們提供了一個強大的工具，能夠在開發過程中自動生成程式碼、撰寫技術文件，甚至協助除錯。 假設我能將這項工具整合到 Azure DevOps 的 Pipeline 中，自動在晚上運行，就可以實現我之前說的 全天候的開發流程 。(以前是把程式碼發包給印度的工程師，現在 AI 就是我的夜班工程師!!!) 嘗試在 Azure DevOps Pipeline 中使用 GitHub Copilot CLI 想要將 GitHub Copilot CLI 整合到 Azure DevOps Pipeline 中，有幾個關鍵步驟。 首先，你要能夠在 Build Agent 上安裝 GitHub Copilot CLI。要這麼做不難，只需透過底下這個 bash script 指令就可以完成安裝 。 npm install -g @github/copilot 只是，你得先確定 Node.js 已經安裝在你的 Agent 上，且是最新版本。 因此，我們會在 pipeline 中，先用一個 step 來安裝 Node.js。 steps : - task : NodeTool@0 displayName : 'Use Node 22.x' inputs : versionSpec : 22.x 接著，我們就可以安裝 GitHub Copilot CLI 了...

這支影片展示了如何透過 Azure DevOps (ADO) 的 Model Context Protocol (MCP) 整合 Chrome DevTools MCP ，實現端到端（E2E）的自動化 UI 測試流程。 影片中展示了如何讓測試腳本的運行不再倚賴人工，開發者只需要在 GitHub Copilot 中下達提示指令，MCP 代理便能自動呼叫瀏覽器、執行互動測試、檢查運行結果並回報測試通過或失敗，還能順手撰寫完整的測試報告。 整個流程結合了 AI Agent + Chrome DevTools + Azure DevOps Test Case 的強大能力，實現真正的「零人工自動化測試」： 由 PM/SA/PO 負責描述測試路徑 （例如登入流程、輸入數據、按鈕執行…etc.） 由 Chrome DevTools MCP 負責具體執行並檢查測試結果 由 GitHub Copilot 負責記錄與撰寫測試結果 這樣的整合大幅提升測試效率與速度。 未來，或許每位工程師都能「像喝咖啡一樣輕鬆地跑完自動化測試」。 看完之後，來 FB 留言分享一下你的感想～ https://www.facebook.com/DotNetWalker/posts/pfbid02qnBruy8mJLnoCswoXnNRQvAqoyAhnXMEA9dqcun3M3rSMx1rv3NovvAZWmJBFqwBl 我很好奇大家的看法。

日前參加 DevDays 2025 大會，和幾位 MVP 講師在台上 live 接受學員們的提問。問題五花八門，既有技術細節，也有宏觀趨勢。會後又和社群朋友閒聊，回到家，還收到幾則來自學員與老友的 LINE 訊息。 和大夥閒聊和互動的過程中讓我更感受到，似乎還是有不少開發人員對 Vibe Coding 以及最近這陣子以來，AI所帶來的改變感到焦慮~ 技術變化如此快速，我們究竟該緊跟不放，還是先按兵不動？ 到底該持續follow，還是讓子彈飛一會兒? 不只是個人，企業也急於導入 AI，卻總是找不到真正有意義的場景與能發揮價值施力點。 大家隱約知道 AI 開始改變了許多事情，但心中又有一絲不安：自己該怎麼辦？該如何面對？ 在一個半小時的時間裡，我還真無法給一個面面俱到的答案。 最後主持人請我做個總結，但其實我心裡想講的是，在資訊產業當中，面對變革早已不是一天兩天的事情了。2022 年底 ChatGPT 初現時，我滿懷興奮與期待；到了 2023 年中，焦慮與疑惑席捲而來；2024 年底，我逐漸找回自己的節奏，直到今天。 回想自己整個歷程， DevDays 2025 大會的最後，我分享給大家我自己面對 AI 時的三個心態與轉折… 接觸：直球對決 直到今天，仍有不少人對 AI 避之唯恐不及，甚至認為它只是一場即將破滅的泡沫。這樣的想法很可以理解，當市場上各種 AI 課程、話題氾濫，它走向泡沫並不令人意外。但請注意，那是對投資人而言。而我們來說，則大大不同。還記得2001年 .com 泡沫化之後發生的事情嗎？真正的改變，那時才剛剛開始。 AI帶來的影響已無庸置疑，這個階段，你的各種的接觸都是好事(是的，包含可能帶來風險的 Vibe Coding )，各種嘗試都是加分，不要躲避，去面對這個改變，直球對決，這是第一件事情，也是最重要的一件。 體驗：唯有親身嘗試，才會生出洞見 接著是體驗，我是指你自己親身的體驗。不只是去聽聽課，或只是上網玩玩圖片生成、與ChatGPT聊聊天而已。 昨天提到，光是 Vibe Coding 這個詞，十個人就能說出十一種不同的解釋。我自己在 2022 到 2025 年間，就歷經至少四種不同型態的 AI 輔助開發，而 Vibe Coding 這個詞到了2025年初才開始出現。其實每種方式在碰到不同的情境時（專案大小、團隊...