Hi, I’m Hsien-Te Hsieh 🧑🏻‍💻

看到一篇文章寫的不錯，紀錄留存一下，並且簡單的重點整理。 本文僅做紀錄與整理，觀點本身皆來自原文作者。 原文：https://www.facebook.com/100063744608911/posts/1526846902783449/?mibextid=wwXIfr&rdid=ABv4HxePsdb0LmOe Agent 開發的三個階段演變 第一階段：工具連接期 (Function Calling / MCP) 作法：利用 LLM 的 API 與 Function Calling 能力，將 AI 與後端系統串接。後來演變成標準化的 MCP (Model Context Protocol)。 痛點：技術門檻過高，能獨立完成的人很少。 第二階段：多代理協作期 (A2A / Multi-Agent) 作法：類似 Google 提出的 Agent to Agent，讓多個 AI 各司其職。 痛點：類似「微服務」亂象，過度設計 (Over-engineering)。管理多個 Agent 的 Context 很困難，且往往「一個 Agent + 多個 Tools」就能解決問題。 第三階段：Coding Agent 與 SDK 成熟期 (現在) 作法：使用 Claude Code 或 GitHub Copilot 這類高度可自訂的 Coding Agent。 突破：透過自訂 Instructions 和 SKILLs (流程知識)，不僅能寫程式，還能處理非開發任務。這是最直覺有效的路徑。 AI 時代的 MVP (最小可行性產品) 開發新路徑 過去的軟體開發往往是「從輪子造車」(從底層一行行寫)，風險在於最後一刻才知道客戶喜不喜歡。AI 讓「理想的 MVP 路徑」(滑板車 -> 腳踏車 -> 汽車) 變得成本極低且可行： ...

前言 在進行 Entity Framework 查詢時，當你執行的是「唯讀」操作，卻沒有使用 AsNoTracking() 時，效能會有差距。本篇記錄實際踩雷的經驗——當資料量小時還看不出來，但隨著資料成長，超過預設的 60 秒 Timeout 限制，導致排程工作失敗。 問題情景 某個 .NET Framework 排程工作，定期執行一份複雜的資料查詢： using (var db = new MyDbContext()) { var result = db.Orders .Where(o => o.Status == "Completed") .GroupBy(o => o.CustomerId) .Select(g => new { CustomerId = g.Key, TotalAmount = g.Sum(o => o.Amount), OrderCount = g.Count() }) .ToList(); // 處理 result... } 起初，資料量只有幾千筆，執行速度很快。但隨著程式修改，時間推移，累積到數十萬筆以上，這個查詢開始變得異常緩慢，最終超過預設的 60 秒 Timeout，排程執行失敗。 根本原因：Change Tracking Entity Framework 預設會追蹤查詢結果中的每一個實體： ...

最近因為有需求，需要了解一下 Azure APIM 的用法，初步整理一下，從 Kong 的角度來理解新東西。 設定 API 從 Kong 的觀念來理解 Azure APIM 對應之概念 Kong Azure 差異 Service API (或 Backend) 在 Kong 中我們使用 Service 來定義上游 URL；Azure 中則在 API 層定義，或使用 Backend 實體來管理共用的上游設定。 Route Operation Kong 的 Route 負責路徑匹配；Azure 則在 API 層的 Operation 定義具體 HTTP method 與路徑。 Plugin Policy Kong 使用內建 Plugin，直接套用，或使用 lua 寫自訂 plugin；Azure 則使用 XML 定義 Policy。 Consumer Subscription Kong 透過 Consumer 身分來控制 API 存取權；Azure 透過 Subscription (訂閱帳戶) 來控制。每一個「訂用帳戶」都會產生一組 Subscription Key (Primary & Secondary Key)，呼叫 API 時，於 Header 設置 Ocp-Apim-Subscription-Key 來呼叫。 Product 在 Azure APIM 中，API 必須被包在一個 Product 中才能被「訂閱」與呼叫(除非該 API 是 open 的，所有人皆可呼叫)。 ...

前言 三十天的鐵人賽，像一場技術馬拉松，終於來到了終點線前。最初的目標很明確：結合我對 iOS 開發的熱情與工作上學習到的 DevOps 實踐，從零到一打造一款名為「台灣公路 K 點通」的 SwiftUI App，並為它建立一套完整的自動化開發流程。 每天產出一篇文章是個挑戰，也是將腦中零散知識點串連成完整實踐地圖的過程。從動機、UI/UX 的草圖規劃，到 Swift 語法的基礎、SwiftUI 的畫面雕刻，再整合 Core Location 與 MapKit, Google map 的地圖服務，期間並導入 Azure Boards 進行專案管理，最後用 Azure Pipelines 實現 CI/CD。 旅程回顧：從痛點到 App Store 的完整路徑 這三十天的內容，可以劃分為四個階段，描繪了一個 iOS App 從概念誕生到最終上架的完整生命週期。 第一階段：從痛點到藍圖 萬事起頭難，在一開始專注於「想清楚要做什麼」與如何做。 我們從一個生活中的真實痛點出發：在公路上難以快速找到特定里程的確切位置，這個具體的目標，成為了整個專案的起點。在技術選型上，我們比較了 UIKit 與 SwiftUI，並基於開發效率、宣告式語法的優勢，以及想要嘗試新技術的心情，最終選擇了 SwiftUI 作為主力框架。 接著，我們在 Azure DevOps 上初始化了專案，設定了 Git Repo，並選擇了適合個人專案的 Basic 流程，為後續的專案管理與 CI/CD 建立基礎架構。 在開始動手寫 App 前，我們先透過使用者流程圖釐清了 App 的操作路徑，再用手繪 Wireframe 與 AI 工具輔助，描繪出 App 的畫面草圖，確保了後續開發的方向明確。 第二階段：掌握 SwiftUI 在這個階段建立 Swift 的語言基礎，快速複習了變數、常數、Optional 型別與流程控制等核心語法，並釐清了 Class 與 Struct 的關鍵差異。接著，我們深入 SwiftUI 的核心，從 Text、Image 與 Button 等基本元件著手，並學習運用 VStack、HStack 與 ZStack 這些佈局容器將畫面元素組合起來。在此過程中，我們掌握了 @State 與 @Binding 如何驅動畫面即時更新，理解了 SwiftUI 的宣告式思想。 ...

前言 經過了前面 28 天的努力，我們的 App 終於來到提交審查的這一步。Apple 的 App Store 審查機制其實算是蠻嚴格的，確保每一款上架的 App 都經過確實審核，所以有不少人會卡在上架的門檻前。 蘋果 App Store 上架審查機制 權限存取 (Access) vs. 資料收集 (Collect)。 資料收集 (Collect) 蘋果的審查規則其實大致上繞不開幾個重點，比方說禁止任何形式的歧視、誹謗、暴力描述，以及色情或鼓勵非法行為的內容。 另一個重點是「隱私權」。Apple 是著名地十分注重隱私，並將這一理念貫徹到 App Store 的每一個角落。其核心要求是：透明與掌控。開發者必須清楚告知用戶他們收集了什麼資料、為何收集，並給予用戶控制其個人資料的權利。 開發者在 App Store Connect 提交 App 時，必須誠實地自我報告 App 會收集的各種資料。這些資訊會直接顯示在 App Store 的產品頁面上，供使用者下載前參考。 舉例來說，假設你的 App 是一款健身應用，會記錄用戶的身高、體重等健康資訊，並使用電子郵件註冊。在隱私權標籤中，你就必須勾選「健康與健身」和「聯絡資訊」這兩項，並說明這些資料會「與您連結」，因為它們與用戶的個人帳號綁定。如果你的 App 只是個單機遊戲，完全不收集任何資訊，你也需要在標籤中明確標示「未收集資料」。 回到我們的 App，有取得使用者位置，這樣算不算「收集」資料？我們來看蘋果官方在 Data collection 這一節當中的這段說明： “Collect” refers to transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time. “Third-party partners” refers to analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you’ve added to your app. ...