.NET Walker

農曆初二，我開著車子在高速公路上疾行(意外地，車並不多)。 Google 導航的女聲冷靜而準確地提醒我：「前方三百公尺，請靠右行駛…」 我突然想起那個還沒有 GPS 的時代。 那時候出門前，我會把地圖攤在椅墊上研究半天，記幾個路名後才敢上路。 若是真的迷路了，也只得停在路邊搖下車窗問路人：「不好意思，請問這條路怎麼走？」 有些人會熱心比劃，有些人則會乾脆帶你走一段。 當時，大家看路標會看得特別仔細，方向盤握得好像也特別專心。 可能因此花的時間多一點，繞的路遠一些， 但偶爾也會多看到一些原本不在計畫裡的東西。 我記得有一年，跟老闆和同事一起去客戶端救一個快搞砸的專案。一整天像打仗一樣，大家累到話都不太想說。 回程途中，下錯交流道，想繞回去又迷路，在烏漆摸黑的鄉間小路上轉來轉去，四個人餓到飢腸轆轆。 正當有點煩躁的時候，路邊出現一家老兵開的牛肉麵店，我們只好進去問路，也順便坐下來吃。 四個人各自點了一大碗牛肉麵，又切了一大盤滷味。(真的是有生以來最大盤) 專案是什麼，其實我忘了。 店在哪裡，更是想不起來。 但那天晚上的燈光、熱湯，還有大家終於鬆一口氣的感覺，我到今天都還記得。 現在不太會發生這樣的事情了。 導航隨時幫我算好最快的路，提醒塞車，提前改道。 如今我幾乎不再迷路，也很少因為繞路而遲到。 老實說，這樣比較輕鬆。 只是我有時候也會想， 那些因為走錯路才遇到的片刻，是不是也慢慢地變少了。 在人生裡，我是不是也很習慣打開導航， 選一條看起來最安全、最有效率的路？ 其實我也說不上哪一種比較好。 只是偶爾，我會想起那碗因為走錯路而吃到的牛肉麵。

今天是農曆年前的最後一個上班日。 昨天，轉戰到台中客戶端，一個非常氣派且具有質感的大樓，分享 Github Copilot。 這次，一路從 2023 年談到 2026 年，一口氣回顧了過去三年這段驚奇的旅程。 從 GitHub Copilot Chat, GitHub Copilot Agent, 到 GitHub Copilot CLI, GitHub Copilot SDK, 還有 GitHub Copilot Coding Agent…恍如隔世。 趁著還有點清醒的腦袋，來聊聊過去這半年，我在 AI輔助開發這個領域哩，看到的變化。 Coding Agent 的演進 似乎不少團隊很喜歡在農曆年前推出足以撥動一池春水的新玩意兒，之前的 DeepSeek是如此，前幾天的 SeeDance 2.0 也是這般。 然而這半年來，對我這個老開發人來說，最大的衝擊應該就是親眼看著 GitHub Copilot 從程式碼補全的 “副駕”，逐漸變成可以自己獨當一面的 AI 隊友。 最初，它只是 IDE 裡的小幫手，幫你改改程式，給點小建議。 後來，它開始可以跟你對話，幫助你大範圍的一次寫完包含好幾隻程式碼的完整模組。 再然後，又出了 GitHub Copilot CLI ，讓你不再受 IDE 的限制，在終端機下用自然語言就可以直接下達指令，完成一個專案的開發、bug的修復、文件的撰寫。 最近，又推出了 GitHub Copilot SDK ，讓你把 Copilot 的能力整合進任何應用。 龍蝦很有趣? 但你知道嗎? 其實有了 GitHub Copilot SDK，你也能自己親手寫一隻，一點都不難。 然而，對開發人員來說，或許未來真正會影響工作流程的， 是在雲端運行的 Coding Agent。 現在，你可以直接把 GitHub Issue(或 ADO Board 中的 backlog) 等工項直接 assign 給 “雲端的” Copilot Coding Agent，它會自己開 VM、clone code、分析需求、自主寫程式、跑測試、最後建 PR 等你 Review。 全程跑在雲端上， 你若在 PR 裡留 Comment 請它改， 它還可以繼續迭代，修改程式碼，直到你滿意為止。 全自動的 AI開發(注意，不是AI"輔助...

上個月協助客戶做技術評估時，他們的 CTO 會後跟我聊了個問題。 「你知道我們團隊最近在研究把 AI 整合進現有的系統與開發流程…」他闔上記事本(實體，有紙張的那種)，帶著思索的表情說到「你知道的，其實就自動化一些日常任務，像是程式碼掃描、Code Review、各種文件生成、自動化測試、應用程式部署、以及運行狀況檢查…這些。我們一開始看了 OpenAI API、後來也研究過 GitHub Copilot CLI、但最近又出了 GitHub Copilot SDK，老實說，不太確定該選哪個?」 他頓了一下，「還有，開發人員是不是常用一個 GitHub Copilot Agent? 它和 GitHub Copilot CLI 是什麼關係? 我們的開發主管說他每天都在用 GitHub Copilot, 但我不確定這幾個東西到底是不是在做同一件事…」 我打開投影片準備跟他慢慢解釋，心裡想「呵呵，你不是第一個問的…最近有太多人對這些新工具"們"感到困惑。很正常，你沒搞混我才覺得奇怪…」 GitHub Copilot SDK 是啥？ 最近我發現，只要聊到 Copilot，幾乎一定會卡在這個地方。 先講結論：GitHub Copilot SDK 是 GitHub 提供的一套 “開發套件” ，讓開發人員可以在自己的程式裡面整合 GitHub Copilot 的能力。 注意，是 整合 GitHub Copilot 的能力 ，而非在程式碼裡面整合 LLM(大語言模型) 的能力，兩者完全不同。 要在程式碼裡面整合 LLM(大語言模型) 的能力，三年前的 OpenAI API 就可以做到了。 GitHub Copilot SDK 是讓開發人員可以直接利用 GitHub Copilot 的 AI 能力來執行特定任務、調用工具，甚至讓 AI 自己進入一個工作循環，持續執行任務，並且持續改進，直到該任務真正完成。 你應該曾經在 VS Code 裡面用 GitHub Copilot Agent Mode 來產程式碼。那個嚴格來說叫做 Copilot Extension，是安裝在 VS Code、Visual Studio 裡面，自動幫你補全(或生成)程式碼的幫手，也就是現在大部分開發人員已經在用的那個 AI輔助開發工具。(也就是坊間所謂的 AI ...

上禮拜在改 Azure DevOps 的 Pipeline，因為客戶遇到一個很實際的問題。 用戶抱怨，每次 Pipeline 跑完，他們團隊的 PM 和相關人等都跑來問：「這次測試過了幾個？Coverage 多少？部署有沒有成功？Sonar 掃描的報表結果如何?」 苦主耐心地一一回答：「這些資訊都在 Pipeline 的 tasks 裡面啊，你們自己點進去看就好。」 但是，這些大爺們從來不想自己去一個一個 tasks 去點，他們希望有個「一目了然」的整合頁面，能直接看到他們想要的重點數字就好。 『就算我說服了他們，他們也真的自己去看，但沒多久又在 LINE 上問我：那個 Log 到底是什麼意思？這個掃描報告要在哪裡找?』 就這樣『來來回回，他們累了，我也累了。』 苦主無奈地說。 需求很簡單：給我一個摘要頁面就好 大爺們最後跟苦主說：「你能不能幫我們在 pipeline 裡面弄一個 Summary 頁面？我們只要打開就能看到重點數字，不用再去翻那些 log?」 恩恩，我被問到的就是這個… Pipeline 跑完之後，能不能有個漂亮的摘要頁面，一進來就看到重點： 測試通過幾個、失敗幾個、Coverage 趨勢 部署到哪個環境、- 有沒有什麼重要的警告 源碼掃描報告的摘要是如何? 自動化測試結果? 能不能上正式機? … 就這樣。 說的很簡單，要蒐集到需要的資訊似乎也還算容易。 但問題是，要怎麼把這些資訊「塞」進 Azure DevOps 的 Pipeline Summary 頁面？ 然後我發現了個神奇的東西 在翻 Azure DevOps 的文件時，我發現一個很有趣的機制。 你知道那些客製化的 Extensions 是怎麼樣讓你在 Pipeline 的 Summary 頁面看到額外的資訊(例如掃描報告、測試報告)的嗎? 類似底下這樣： 答案可能會讓你傻眼，不是呼叫什麼 REST API、不用設定什麼 Token、也不用安裝套件。 ADO 用的方法超級簡單： 監聽你在 Build Agent 裡面的 console 輸出 。 對，就是 stdout。 你只要在 Pipeline 運行的 script 裡面 echo 一行特定格式的字串： echo "##vso[task.uploadsummary]...

程式碼品質，絕對是每個專業開發團隊都會遇到的課題。 你知道的，當系統上線後，突然收到資安通報說發現了安全性漏洞，需要緊急修補。更糟的是，這個漏洞在開發階段就可以避免，只是當時沒人發現。然後你開始翻 Commit 紀錄，發現那段有問題的程式碼正是自己幾個月前寫的…這種情境難免會讓你冷汗直流。 這是為什麼我們需要在 SAST(Static Application Security Testing，靜態應用程式安全測試)與源碼掃描的原因。它就像是你的程式碼守門員，在你還沒意識到問題之前，先幫你把那些潛在的地雷給挖出來。 SAST 與 SonarCloud 的關係 靜態程式碼分析，也就是我們常說的原碼掃描，它不是去執行你的程式，而是透過搜尋常見的程式碼撰寫樣式，嗅出程式碼中可能的安全漏洞、程式碼壞味道(code smell)、技術債、還有那些可能會在半夜讓你接到客戶電話的潛在bug。 SonarCloud 則是 SonarSource 提供的原碼掃描雲端服務版，它基於知名的 SonarQube，但你不用自己架設伺服器、不用煩惱維護更新，申請完直接使用就行了。 對於使用 Azure DevOps 的團隊來說，兩者更是天作之合，因為官方有提供極其簡單好用的 Tasks 支援，整合起來超級輕鬆，幾個步驟就搞定。 而且，SonarCloud 支援超過 25 種程式語言，從 C#、Java、JavaScript 到 Python，基本上你想得到的它都有。它不只找出你的程式碼潛在問題，還會告訴你為什麼這段程式碼會是個問題、以及該怎麼修復，甚至連預估要花多少時間修復都幫你算好了。 我在 2020 年寫過一篇關於在 Azure DevOps Build Pipeline 中整合 SonarCube 的文章。但你也知道，科技業的時間流速跟外面不太一樣，四年過去了，很多東西都變了。 所以，是時候來個 2026 年的更新版了。 開始動手 : SonarCloud 帳號申請與設定 好，廢話不多說，我們直接開始。 首先，你需要一個 SonarCloud 雲端帳號。如果你有 Azure DevOps 帳號，就可以直接用它以 SSO 方式登入 SonarCloud，不用再另外註冊帳號。 你可以前往 https://SonarCloud.io/ ，選擇用 Azure DevOp...

下課後，有個學員帶著問題走了過來， 戴著一幅黑框眼鏡，看起來就是那種勤奮型的人。 「老師，想請教你個問題」他說，「不知道你怎麼安排時間學習新的技術的? 現在 AI 發展這麼快，每天都有新東西出來。今天這個模型紅了，明天那個工具又說是必學。我根本不知道該從什麼地方開始，感覺永遠追不完…」 我點了點頭，收拾著背包。 這問題，我打從 AI 還沒出現的年代，就被問到現在。 說實在的，這年頭當開發者，挺累。 你打開社群網站，滿滿都是「不學這個你就落伍了」的暗示、 「202x 必學的 10 個技術」讓大家一窩蜂地膜拜新功能，那怕根本不知道那是幹嘛用的。 焦慮感一波一波襲來，搞得你晚上睡覺都不安穩。 但我想告訴大家一個事實： 其實，你永遠學不完的。 真的，別再想了。接受這個事實，你會輕鬆很多。 問題不在「學什麼」，而在「為什麼學」 我反問他：「你為什麼想學？」 他愣了一下，「因為…大家都在學啊。」 (我心想：又來了，面對熊來了，大家都只是想跑得比身邊的人快一些，是吧? 🤔) 大部分人學東西，是因為害怕。怕跟不上，怕被市場淘汰，怕面試被問倒。 所以瘋狂囤課、狂買書、把教學平台的購物車塞得滿滿的。結果呢？買了一堆課，上了5分鐘就放著長灰塵。 其實這不是學習，這是焦慮的發洩出口而已。 教育訓練從販賣知識變成販賣焦慮，我想作者本人應該也不願意吧。 其實，真正有效的學習，永遠從 解決問題 開始。 你現在手上有什麼專案？遇到什麼問題讓你卡關？你想做出怎樣的東西？從這裡出發，你才知道該學什麼。 不是「我要學完 Vue才能開始做專案」，而是「我要做這個功能，所以我得搞懂 Vue 的這個部分」。 差別在哪？前者你可能永遠學不完，後者你今天就能做出東西。 AI時代更要會「選擇」 如今，AI都會能自己程式了，直接 Vibe Coding 就好，還要學什麼？ 不，不是的! AI 越厲害，你越需要知道「該問什麼問題」。你得知道要做什麼、怎麼拆解問題、如何判斷 AI 給的答案對不對。 這些能力，從來都不是靠狂學一堆技術就能培養的。而是靠你真正去 做 、去 踩坑 、去 修bug 累積出來的。 (注意到關鍵字 修bug 了沒，這句是寫給想 Vibe Coding 的同學看的) 我常跟學員說，與其花三個月把一門課從頭到尾看完，不如花十天先做出一個爛爛...

這天 Azure DevOps 課程下課後，又有位學員留下來找我。 事情是這樣的… 他們公司政策規定要導入敏捷和ADO，但上完我的課程後，覺得有點困惑… (我內心OS: 呃? 怎麼會呢? 🤔 你不是應該上完我的課程後豁然開朗的嗎?) 他說，因為公司很多專案還是瀑布式在跑。需求從客戶那邊來的時候，動不動就是三個月、五個月這麼大包的東西。PM 離開技術圈一段時間了，也不知道該怎麼 end-to-end 切出一個迭代(兩周)內可以完成、又有價值的 PBI。 (我一邊聽，一邊想，覺得這是個難題沒錯，但其實最大的挑戰是心理障礙和習慣，因此…) 我跟他說：「其實把需求顆粒度切小，對每個人都有好處。對 PM、對客戶、對開發人員，全是利多。」 他笑的很無奈。 「這道理我可以理解，但我們的開發人員同時身兼好幾個專案，很難專注在某一個案子上。這時候，大家心態上就不想把顆粒度切小，因為怕時時刻刻被盯著要看進度。」 他停頓了一下，接著說：「所以開發人員寧願維持以前那樣一個功能做一個月、兩個月的顆粒度。這樣開發人員可以先去忙別的事情，最後幾天再來趕工。」 聽完，換我沉默想了幾秒。 因為這根本不是技術問題，也不是工具問題。這是整個組織的心態問題。 更深層的，是大家對「敏捷」的誤解。 很多人以為敏捷就是迭代、就是 Scrum、就是看板或站立會議。 但其實，真正的敏捷有一個很明顯的照妖鏡： 需求的顆粒度 。 沒有小的需求顆粒度，就沒有頻繁交付；沒有頻繁交付，就沒有敏捷。 我幾乎可以說，如果團隊無法把需求顆粒度變小，那敏捷導入十之八九是假的。 粗顆粒度的惡性循環 你在 Board(看板) 上看過那種預估要做三、五週的需求卡片嗎？ 「完成訂單管理功能」（預估五週） 「優化報表系統」（預估三週） 「整合第三方金流」（預估兩週） 每次看到這種，我就知道這個團隊有問題。 為什麼？因為一個需求如果要做兩週，在這兩週裡，這張卡片的狀態是什麼？「In Progress」? 但 In Progress 告訴了我們什麼？什麼都沒有。你不知道他做到哪裡了，可能才剛開始，也可能快做完了，也可能卡住了但不好意思說。 更慘的是，開發者在自己的 branch 上悶著頭寫了兩、三週的程式碼。等到要 merge 的時候，衝突、錯誤、邏輯不一致，問題才一個一個冒出來。然後就是...

開源 一個軟體或產品，要讓人信任它最簡單的方法，就是『開源(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 ...