.NET Walker

開源 一個軟體或產品，要讓人信任它最簡單的方法，就是『開源(open source)』。 有時，用戶心裡會想：『我在你們這個技術上投資，萬一哪天你們整個開發團隊解散了怎麼辦? 我的投資不就打水漂了嗎? 』的確，這顧慮不無道理，產品的開發團隊也知道。 怎麼辦呢? 答案很簡單，就是『👉開源』。 怎麼讓用戶相信產品開發團隊在雲端上host的平台很正直，不會拿客戶上傳的資訊幹些什麼壞事? 答案也很簡單，又是『👉開源』。 總之呢，開源是快速獲取用戶信任的好方法。除了原始程式碼開源，最好連運行的環境也一併容器化，也開源。放上docker hub上讓大家可以免費下載。很佛心，沒錯，但它要換來的就是，你的信任和使用。 Dify 好唷，Dify 這個 2023年才開始的專案就是這麼幹的，這讓你可以比較放心這個其實只有20多人的新創團隊(而且還不是歐美血統)所開發的大語言模型 AI Agent 運行平台/框架。 Dify.AI 有一個雲端版本的 portal (如下圖)，功能面我先不在這篇文章說，這篇只講容器化，但讀者可以自行上網申請一個帳號體驗一下： 總的來說，Dify 對自己的定位是 LLMOps 平台，負責幫你代勞一堆有的沒的LLM相關整合大小事。(前面說了，這個你自己上網查或申請個帳號去體驗一下) 我們來看它如何在地端環境執行，首先，它整個專案在 GitHub上，可以透過底下指令下載： git clone https://github.com/langgenius/dify.git clone 下來之後，進到 \dify\docker 資料夾： 接著透過 docker-compose指令： docker-compose up -d 來運行，接著稀哩哩嘩啦啦的執行一陣： 接著你可以開啟 http://localhost/install ，進入整個系統的設定畫面： 設置好帳密之後，以後就可以透過 http://localhost/apps 網址登入站台囉： 整個畫面跟前面說到的 Dify.ai 網站完全相同，等於是你可以把人家整個網站 host 一份在自己的地端伺服器上，確保你的投資(例如設計的 AI Agent) 不會變成孤兒。 而我們在雲端設計好的 AI Agent，也可以透過匯出 DSL，直接在地端匯入： 匯...

以前，要做一個 AI Agent，光是想怎麼讓它跟外部系統溝通，就足以讓人頭痛。 但現在不同了。 Dify 與 MCP：天作之合的組合技 先說說 Dify 。如果你還沒用過它，那真的該好好認識一下。Dify 是一個開源的 LLM 應用開發平台，整合了視覺化的工作流程編輯器、RAG（檢索增強生成）管道、AI Agent 開發能力、模型管理等功能。簡單說，就是把原本複雜的 AI 應用開發，變成拖拖拉拉就能搞定的事情。 然後，另外是 MCP （Model Context Protocol）。這是 Anthropic 推出的協議標準，目的是讓 AI 模型能夠標準地串接各種外部工具、與不同的資料來源溝通。 試想一下，以前當我們想讓 AI 接資料庫、串 API、整合各種企業內五花八門的資訊系統時，每套都要自己刻一個介面。有了 MCP，這些都變成像是標準化的「插頭」，插上去就能用。 當這兩個東西碰在一起，會發生什麼事？ 讓流程無所不能的魔法 有了 MCP 之後，Dify (開發的AI Agent) 能做的事情突然變多了。 更讚的是，我之前做了一個小工具，可以把 Dify 直接串到 LINE OA(官方帳號) 上。現在要設計一個 AI Agent？ 輕鬆到太過美好。 以前要花兩週處理的工作，現在可能半小時就搞定了。 實戰：用 MCP 串接請假系統 直接看個案例。 底下這張圖片就是 Dify 串接 MCP 請假系統進行請假的畫面。看到了什麼？對話介面相當乾淨(下圖右方)，使用者只需要自然地說「我要請假」，AI Agent 就會自動處理剩下的流程，蒐集請假所需要的資料，然後透過MCP呼叫串接好的HR請假系統的 API，完成請假功能。 當然，查詢剩餘請假時數，也是如此。 這背後發生了什麼？AI 透過我們做好的 MCP Tools，呼叫了請假系統的 API，確認你的假別、假期餘額、代理人…等資訊。所有這些複雜的商業邏輯，都被優雅地包裝在 MCP Server 裡面。使用者完全感覺不到複雜性，就像在跟一個很聰明的 AI 聊天助理對談而已。 這就是 MCP 的魅力。 它不只是一個協議，更是一個思維模式的轉變——把複雜的系統整合，變成簡單的行動，讓AI Agent可以在與用戶對話互動中隨時調用。 用 .NET Core 打造你的 MCP Server ...

為何有這種需求 最近在上 Azure DevOps 課程，下課後，一群學員突然跑來問了個問題。 「老師，我們公司有三十幾個 Azure DevOps 專案，每個專案都有自己的 repo，每個 repo 都有自己的 pipeline yaml 檔…」他頓了一下，臉上帶著某種「歷盡滄桑」的表情，「有沒有辦法讓這些 pipeline 共用同一份 template？改一次就全部生效的那種？」 我其實急著下課，並沒有聽得很仔細，腦袋裡還在糾結：「為何要讓所有的 repo 都共用同一份 yaml template，每個開發專案不是應該有自己的 pipeline design 嗎？為何要為了統一控管搞得這麼複雜？」 於是我追問：「為什麼會有這種需求呢？」 他苦笑著說「每當公司想要在 pipeline 裡加入一些共用的步驟，比如說安全掃描、程式碼品質檢查、部署前的驗證等等，我們就得一個一個 repo 去改 pipeline yaml 檔。三十幾個專案，每個專案又可能會有好幾個 repo，改起來超級累人。」 教室裡其他學員也紛紛露出「我懂我懂」的表情。這種痛，做 DevOps 的人應該都瞭。 更慘的是，當你好不容易改完三十幾份檔案，過兩個月主管又說：「欸，我們現在還要加入程式碼品質檢查。」然後你又要再改一輪。如果哪天發現其中一個步驟寫錯了，想改？好啊，三十幾個 repo 再巡一次。 這就像是複製貼上了三十幾份同樣的食譜，結果發現鹽放太多了，然後你得把三十幾本筆記本都翻出來，一本一本改。真的累。 「所以…」學員問，「有沒有辦法讓這些 pipeline 共用同一份 template？改一次就全部生效？」 我當下趕著回家，沒多想，也來不及具體回答。 但回家後仔細思量：「這個問題其實挺實際的，應該是有解決方案的吧?」稍微翻了一下，果然發現 Azure DevOps pipeline 原本就支援引用外部的 yaml template。 如何實現？ Azure DevOps 其實早就想到這個問題了。它提供了一個機制，讓你可以把 pipeline 的某些步驟抽出來，放到另一個 repo 裡當作「模板」，然後其他專案的 pipeline 就可以「引用」這個模板。 聽起來很簡單對吧？但實際上第一次設定的時候，總會有那種「欸這樣寫對嗎?」的不確定感。 我也是這樣，看著官方...

11/29 ，我在 .net conf Taiwan 2025 的分享，題目是 『變革👉面對變革』，主要想談的是 LLM 在軟體開發領域(SDLC)中，這三年所帶來的改變。以及，如何面對。 關於『如何面對』這個部分，因人而異，我也就不想在這邊多說些什麼了。 但從 2022/11/30，一直到今天(2025/11/30)，AI對軟體開發帶來哪些改變，我倒是整理出了一些影片，也是我在這次會場中分享的部分內容，做為這一季也是 .net conf 2025 我自己場次的小總結，也分享給大家。 有些影片沒有聲音，原因是那是用來配合我在在講台上的講解所錄製，大多不長，讀者可以自己腦補體會一下。 我想表達的是， LLM在SDLC的每一個階段，都已經留下了深刻而無法抹滅的痕跡。不管你願不願意，未來AI都會與你一起開發系統，沒有例外。 開發階段AI帶來的改變(AI輔助開發): 這一段我想說的是，從2023年到2025年，AI在程式碼撰寫這個領域，介入的愈來愈深，愈來愈廣。從『只是這樣?』，到『原來可以這樣』… 2023年盛行的 Code Suggestion(程式碼片段生成或建議) https://youtu.be/gPGE-Tze_sk 2024年盛行的 Agent Mode(IDE內的大範圍生成) https://youtu.be/v6PI9Fbt7Oo 2025年開始的 CLI(命令列模式大範圍修改或生成) https://www.youtube.com/watch?v=MnbEhg3JWq4 當天做的一個現場小調查，你會發現，在今天，軟體開發就等同於AI輔助軟體開發，幾乎沒有例外： 需求設計階段AI帶來的改變： 如果你願意，AI也可以產生需求規格。甚至，從產生需求規格一路自動到完成開發… User Story/AC 自動生成 https://www.youtube.com/watch?v=AxtYwBUMIyM 搭配MCP，從規格自動完成功能開發 https://www.youtube.com/watch?v=Yp9UImcfWfs CI階段AI帶來的改變： AI的大幅度介入，將會讓人類成為開發的瓶頸，而有趣的是解決這個瓶頸的鑰匙，也是AI。現在透過AI，可以協助人類做 code review，在測試左移(shift ...

今天在 Build School 上課時發生了一件事，讓我想了想之後，還是決定寫篇文。 事情是這樣的。 上課時，我問學員：「如果有一個敏捷團隊，裡面大概 5-7 位成員，在一個迭代中同時開發 3-5 張需求卡片，你們覺得應該切幾個 feature branch?」 本來以為會聽到各種答案。 有人會按功能切、會按人頭切、或是按模組切…，因為我曾經聽過各式各樣的回答。 結果，他們所有人異口同聲：「只切一個分支。」 我愣了一下。「只切一個？」 「對，一個。」 這群學員才剛學 Git 沒多久，怎麼得出這個『違反常理』的結論的？上了這麼多年課，每次談到這個議題，學員都還可以跟我糾結半天，討論到底要不要用 Git Flow。 後來，助教跟我解釋，原來他們之前讓學員自己做了實驗。 什麼實驗? 實驗很簡單，因為反正要做專題，所以把學員幾個人分一組，讓他們用不同的分支策略跑幾個迭代。有些組按人切分支，有些按功能切，有些混著切。然後看看哪種方式最順。 結果呢？ 用多分支的組，第一個迭代還算順利，大家各寫各的，感覺井然有序。但整合的時候就開始出事了。功能 A 做完了，但要等 B 跟 C 才能 merge。有人幾天沒事做，只能坐著等。 到第二個迭代，問題更大。大家在自己的分支上寫了一段時間，最後 merge 時才發現衝突一堆。有些衝突好解，但有些是邏輯上的衝突，或是使用了同樣功能的不同套件，兩個人改了同一個模組的不同地方，單獨看都沒問題，合起來就爆了。 第三個迭代，有人開始崩潰。明明功能做完、測試也過了，但因為流程卡在 release branch，要等到迭代結束才能部署。一個小 bug 改了五分鐘，卻要三天才能上線。更慘的是，有人說：「程式碼寫完過了很久才整合，開始忘記當初為什麼要這樣寫了。」 最後，讓他們自己試試看：如果大家都在同一個分支上開發會怎樣？ 結果出乎所有人的意料之外。 衝突變少了(其實是變多了，但因為每天都在整合，有問題馬上發現，立刻解決，所以花在解決衝突的時間反而變少了)。部署變快了，一個小功能做完，就能立刻上線。整個團隊的節奏順暢很多，不用再有人乾等。 助教說：「他們自己體驗過就懂了，不用我們特別去教。」 聽完之後，我想了很久。 DORA 指標 其實他們體驗到的，就是 Google 研究出來的 DORA 指標在講的事情。 ...

開場 去年在 DevOps Days Taipei 研討會中，我有分享過類似的概念，當時我還無法實現。而且我覺得當時我提出這個想法的時候，很多現場聽眾目光裡閃爍著的，其實是略帶懷疑的眼神。 什麼概念呢? 我一直希望，能不能在 PR 過程中，Reviewer 只要寫下 Comment，就能有個 AI 工程師在背景直接幫我們改 code？ 或是能有一個夜班的 AI 工程師，可以隨時待命，接手白天人類的工作，在晚上完成一些例行性的任務。 現在，這個夢想終於實現了。而且比我想像的還要好用。 讓我們先聊聊 Git 版控時的 PR 流程。如果你有再用 Git 做團隊開發，我相信你一定知道 Pull Request 是整個開發協作的核心。開發者提交程式碼、reviewer 進行逐行檢查、留下 comment、來回討論、最後 approve 或是 request changes。這個流程很務實，也很必要。 但一直有一個問題。 不知道你有沒有算過，從 reviewer 在 PR 上留下 comment，到開發者真正動手修改，中間會經過多久時間？ 有時候是幾小時（如果大家都很閒），有時候是一整天（因為有會議、或其他工作），有時候甚至會拖到一兩天（可能是 Developer 沒收信、甚至根本是單純忘了上去看）。這段時間，PR 就這樣卡在那裡，什麼都不能做。CI/CD pipeline 也只能乾等。 更煩的是，有時候那些 comment 其實都是些「小修改」：改個函示名稱、加個錯誤處理、調整一下格式、補個註解。這種事情，說難不難，但要開發者停下手邊的工作、重新進入 context、再去改這些小東西，說實話，挺浪費時間的。 所以我一直覺得： 如果可以讓 AI 先做初步修改呢？ 那會如何? 主要不是為了取代開發人員，而是在 reviewer 提出建議後，讓 AI 先試著去處理那些「機械性」的修改。再由人類負責審核、判斷、給建議；AI 負責執行、修改、產出結果。這不是挺完美的分工嗎？ 實際操作 好，概念介紹完畢，來看看實際上如何運作。 假設今天有個 PR，reviewer 檢查後發現了一些需要改進的地方。就像平常一樣，在程式碼旁邊留個 comment。可能是「AI: 這一段應該要加上錯誤處理或Log」、「AI: 這個OOO變數名稱不夠明確」、「AI: 請加上OOO的...

前言 你可能有聽過 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 的，他用極...