發表文章

關於 Azure DevOps 中的 YAML Pipeline

作者： -
圖片
關於 Azure DevOps 中的 YAML Pipeline 最近在上課上到 Azure DevOps Pipeline 的時候，發現有些技術人員對 ADO 的 YAML Pipeline 有個小小的誤會。 很多人以為，只要是 Azure DevOps 的 YAML Pipeline，就一定要放在 repo root 底下，然後檔名一定要叫： azure-pipelines.yml 其實，不是的。 這個檔名只是 Azure DevOps 預設最容易被偵測到的慣例，並不是限制。 換句話說，你的 repo 裡可以有： /azure-pipelines.yml 也可以有： /pipelines/ci.yml /pipelines/deploy-dev.yml /pipelines/deploy-prod.yml /pipelines/security-scan.yml /.azuredevops/agentic-dev.yml 真正的重點不是檔名，而是： Azure DevOps 裡的 Pipeline Definition 必須指向 repo 中的某一個 YAML 檔案 也就是說，Pipeline 不是靠檔名自動決定要跑哪一份 YAML，而是 Azure DevOps 裡面那條 Pipeline 本身記住了它要使用哪一個 YAML file path。 建立新的 YAML Pipeline，並指定特定的 yml 檔案 假設你的 repo 裡已經有一份 YAML： /pipelines/ci.yml 那麼你可以這樣建立一條新的 Pipeline，連結到既有的 yaml 檔案，作法是在新增 yml pipeline 的時候，選擇 Select an existing YAML file： 接著選擇你的程式碼中的 yml 來源即可，這樣一來，你就在 Azure DevOps 裡建立了一條新的 Pipeline，而這條 Pipeline 使用的 YAML 內容，就是： /pipelines/ci.yml 一個 repo 可以有多個 YAML Pipeline 這也是另一個常見誤會。 很多人以為一個 repo 只能有一個 YAML Pipeline。 當然不是。 當你知道可以在建立 Yaml Pipeline 的時候，指...
張貼留言
Read more »

在 ADO Pipeline 中使用 SonarCloud 進行自動化源碼掃描

作者： -
圖片
程式碼品質，絕對是每個專業開發團隊都會遇到的課題。 你知道的，當系統上線後，突然收到資安通報說發現了安全性漏洞，需要緊急修補。更糟的是，這個漏洞在開發階段就可以避免，只是當時沒人發現。然後你開始翻 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...
張貼留言
Read more »

從 Function Calling 到 MAF 中的 tool use

作者： -
圖片
我覺得今年真的是 AI Agent 崛起的一年。 AI 輔助開發在今年幾乎可以說是全面 Agent 化，而一般的消費者應用領域，也開始有許多 AI Agent 出現。最近身邊的幾個專案，都不約而同地從傳統的 Web應用程式升級成採用單一對談式介面為主要入口的 AI Agnet。 上課時，和學員聊到這些改變。 其中有位學員問到，這是因為MCP出現的關係嗎? 我說不是，真要說的話，其實應該從 Function Calling 開始說起。 一切從 Function Calling 開始 還記得 Function Calling 嗎? 最初的 LLM 只能聊天。你問，它答。但它就是個黑箱，不會上網，不能查資料庫，不知道今天幾月幾號，現在是幾點，當然也不可能去執行你的 API。 後來模型的推理能力變強了(約莫是在 gpt 4o 前後的那個階段)，OpenAI 才提供了一個新的能力： 讓模型可以「要求系統替它做事」 。 這因為當時的LLM開始能夠理解、進行結構化輸出、並且能做到多步驟推理的這個基礎上。 那時候你跟模型聊天，模型可以依照你的對話，來判斷是否需要呼叫外部函式(API)，如果需要，模型就回你一段結構化的JSON，像是底下這樣(例如你在聊天的過程中提到要進行請假)： "function_call" : { "name" : "leave_request" , "arguments" : "{ start_date:2026-5-12,end_date:2026-5-13,leave_type:病假,substitute:張大寶 }" } 這就是 Function Calling。 很多人看到 Function Calling 這個字眼，誤以為「LLM 模型能夠直接呼叫API」?? 不，其實並沒有，也不能。 真正執行 API 的，是你的 Runtime、你的 Framework、或是你的AI Agent程式。 LLM 模型做的只有三件事： 依照對談或語意，判斷需不需要呼叫 API 以及，呼叫哪個 API (像是上面的 name) 還有，組出呼叫API時所需要的參數 (像是上面的 arguments) 然後...
張貼留言
Read more »

在MAF中使用 Agent Skills

作者： -
圖片
你一定已經發現，最近一年在 AI 領域裡，「Skill」這個詞忽然之間就火了起來。本來 Skill 就是個一般般的英文單字，沒什麼了不起的，但現在一講到 AI Agent，不能沒有 Skill；講到 Agent 開發框架，當然也一定得談談 Skill。 最近看了一堆關於 AI Agent 的討論，幾乎每個新框架、新平台上線時，都會強調他們的 Skill 整合有多強、支援有多完整。就像當年「微服務」爆紅的時候，所有架構都要講微服務、所有工程師都在討論如何切分服務。 時代不同，但焦點轉移的方式卻是一樣的。 Skill 到底在夯什麼？簡單說就是： 你的 Agent 大腦(Model)再聰明，如果沒有 Skill，那它就只能聊天對談回答問題，頂多就是幫你做些決策或判斷，但卻沒辦法真正去「做」事情。 Skill 讓 Agent 有了「手」和「腳」 差不多就是一個人聰明絕頂，但四肢癱瘓，只能用嘴巴說話這樣。 AI Agent 沒有 Skill，就是這種情況。它知道怎麼回答你的問題，但沒辦法去呼叫你的系統、修改你的資料、執行你的商業邏輯。 Skill 就是那雙「手」和「腳」。透過 Skill，Agent 可以呼叫你的函式、連接你的資料庫、整合你的第三方服務、執行實際的業務操作。換句話說，Skill 是讓 AI Agent 從「一個聰明的客服」轉變成「一個能幹的員工」的關鍵。 MAF(Microsoft Agent Framework) 老實說，身為 .NET 開發者算是幸運的，相較之下微軟在 AI Agent 開發技術這塊，毫無疑問算是跑得非常快。 Microsoft 推出的 Agent Framework（MAF） 對整合 Skill 的支援，說實話，就是一個 優雅 。不只是功能全，在設計上也考慮到開發者的痛點。 舉個例子，如果你要給 Agent 加一個「查詢訂單」的 Skill，你不用寫複雜的 JSON Schema、不用手寫一堆的 serialization 邏輯。在 MAF 裡，你可以寫像這樣的程式碼： // 建立一個技能提供者，指向技能目錄 var skillsDir = Path . Combine ( Directory . GetCurrentDirectory ( ) , "skills" ) ; var...
張貼留言
Read more »

SPA 的 SSO 和身分驗證與授權

作者： -
圖片
上課時談 OAuth，學員問到 SPA 怎麼做安全的身分驗證? 這其實是很多前端工程師都會碰到的問題，頁面是沒有後端的單頁應用程式，想要實現使用者體驗，安全性又不能妥協，那到底該怎麼做？ 先說結論：以前常見的 The OAuth 2.0 implicit grant，現在已經不是建議解法。它會把 access token 直接帶回前端（甚至出現在 URL），流程看起來簡單，但實際上會有 token 暴露、回傳路徑難以控管等問題，而且整個授權流程本身的保護也比較不足(例如授權碼被攔截後遭濫用的問題)；因此現在比較正確的做法，是用 Authorization Code Flow + PKCE (Proof Key for Code Exchange) 來完成 SPA 的登入。 如果你把這件事想成一個「前端能不能不靠傳統後端也安全登入」的題目，答案是『可以』，但前提是你要知道 PKCE 解決的是哪一段問題，也要知道它沒有解決哪些問題。 後端不是必須 一個前端App其實真的可以在沒有傳統後端的情況下，實現一個符合現代 OAuth 建議做法的登入流程。 邏輯其實很簡單，但實作的時候需要留意。 關鍵在： SPA 本來就不適合在前端保管祕密(secret) 。 傳統的 server-side web app，通常會由後端保管 client secret ，後端負責跟授權伺服器(OAuth Provider)拿 code 交換 token，前端只需要拿著後端自己發的 session 或 cookie，就可以維持身分。這種模式很合理，因為secret是放在伺服器上，不會直接暴露給使用者。 但 SPA（Single Page Application）不一樣。 因為 JavaScript 是跑在前端瀏覽器裡，使用者也拿得到前端程式碼，所以你不可能真的把 client secret 放在前端。這也是為什麼 SPA 無法走傳統的 Authorization Code Flow 的原因。 而 Authorization Code Flow + PKCE 的核心思想，就是讓這種 前端在不保管 client secret 的情況下，仍然可以比較安全地完成OAuth授權流程。 PKCE(Proof Key for Code Exchange) 的妙處 先說個比喻。 ...
張貼留言
Read more »

AI 輔助開發的三個時代：從 Copilot 到 AI Engineering System

作者： -
圖片
前幾天有好友轉 PO 了某貼文，內容提到他們公司想要讓 PM 能直接在 Jira 上撰寫需求，然後直接觸發 AI 自動開發，完成後自動開 PR，最後工程師只需要 code review 即可。 原 PO 問，這樣可行嗎? (真是個有趣的孩子…) 剛好，適逢 Codex App 在 Windows 上正式釋出，來談談這個議題。 這三年，我幾乎是死盯著 AI 輔助開發的發展。 走到今天的感覺是： 上面那個流程 不只可行， 而且很可能在兩年內會成為軟體開發的主流。 回頭看三年 AI 輔助開發的演進 讓我帶你回頭看一下這三年 AI 輔助開發的發展。 你如果從 2023 年開始觀察到今天，大概分成這三個階段： Copilot (副駕) 時代 ( 2023-2024 ) → AI Assistant（你寫，AI幫你完善） Claude Code / Copilot CLI 時代 ( 2025 ) → AI Agent（你說，AI幫你寫程式） Codex App / Copilot Workspace 時代 ( 2026+ ) → AI Engineering System（從需求啟動，AI 自己進行多 Agent 協作，幫你直接完成交付） 換句話說，開發流程正從： Developer 寫 code -> PR -> 交付 走向 Stakeholders/Developer 定義問題 -> AI Agents 實作 -> Developer Review -> AI 完成交付 AI 輔助開發的三個階段 我把上述提到的 AI 輔助開發三個階段，整理成一張生態圖，大概是下面這樣： 第一階段：AI in IDE（讓你寫得更快） 代表工具： GitHub Copilot Cursor Windsurf 核心功能： Autocomplete / inline suggestion 小範圍程式碼生成 即時問答 與 片段的程式碼重構 這階段本質上是「效率增幅器」，主角仍是工程師本人。 第二階段：AI Developer / Terminal AI Agent（幫你做得更多） 代表工具： Claude Code Copilot CLI 核心功能： AI...
張貼留言
Read more »

期待

作者： -
對我這一代的人來說，國中那時候的過年，其實有點漫長。 那時候，過年的台北都像座空城。店家鐵門拉下來，朋友們各自回老家，街道安靜得有點誇張。沒有手機、沒有社群，更沒有隨時可看的影音平台。時間多得讓人不知所措。 但其實我並不討厭這樣的空白。 我記得，當年自己最期待的，是跑去光華商場看倪匡的科幻小說(我記得初三初四好像就開張了)。那時候的書都還沒封膜，可以站在書架前，一頁一頁翻下去。過年有比較多的零用錢，也有比較完整的時間，可以把錯過的幾本一口氣補完。如果願意，你花上一百多塊，把書帶回家，在房間裡慢慢讀，是一種非常奢侈的享受。但我卻常常一口氣讀到最後幾頁停下來，因為捨不得看完。 閱讀倪匡的時候，腦袋是自由的。 故事在想像裡展開，不需要特效，也沒有刻意的鏡頭切換來幫忙製造張力。 倪匡說過，好看的小說必須要「情理之中，意料之外」。 這句話我一直記得。 所以這兩天閒來無事，我試著讓 GPT 5.2 依照這個原則，寫幾篇短篇小說。 老實說，完成度很高，幾乎篇篇都能符合我要的「情理之中，意料之外」。 (也可能是我提示詞下的好😛) 不過這讓我有些感慨，不是因為它寫得好，而是因為它寫得太容易。 這幾天，很多人討論新的 Seedance 2.0 模型的影片生成、或是春晚的武術機器人。老實說，技術真的往前推進了一大步。但我在YT上看到一個蠻有趣的觀點，它在談「稀缺性」這個問題，這角度讓我停下來想了一下。 閱讀的樂趣，有一部分是因為「有限」而珍貴。過去，我等一本書出版，等電視台重播，等某張唱片進貨開賣。等待本身，是一種參與。 如今，當文章、作曲、寫程式、拍短片都變得不再困難，每個人似乎都能為自己生成專屬的小說、電影、和主題音樂，當創作不再稀少，等待，好像也變得不重要了。 如今，我們幾乎可以擁有無限的創作內容。 只是，當一切變得唾手可得，我還會像當年那樣，站在書架前，為一本新上架的小說而感到心跳加快嗎？ 不過，改變從來都不是好或壞。 只是每個時代，都在重新定義「珍貴」是什麼。
張貼留言
Read more »

繞路

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

2026 農曆年前的最後一篇 - 關於這半年的一些觀察

作者： -
圖片
今天是農曆年前的最後一個上班日。 昨天，轉戰到台中客戶端，一個非常氣派且具有質感的大樓，分享 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"輔助...
張貼留言
Read more »

GitHub Copilot SDK：當你的程式碼有了自己的靈魂

作者： -
圖片
上個月協助客戶做技術評估時，他們的 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 ...
張貼留言
Read more »