想要讓 GitHub Copilot 串其他 AI 平台的 model 到 GitHub Copilot 在 Organtization 來使用，行不行？
行，當然行！
看 GitHub 設定 API key 的選項：
基本上主流的幾家 AI 平台都支援了！
記錄把本地 Terraform State 文件轉移到 AWS S3 的過程與注意事項
Harmony 是一個 .NET 的開源 Runtime Patching 函式庫，由 Andreas Pardeike 開發，這個函式庫能夠在不具有原始碼的狀況下動態修改任何 .NET 方法的行為。這系列文章記錄一些關於這個函式庫的使用方式。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（2/10）
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（1/10）
2025 年 8 月到 9 月，我參加了 iThome 鐵人賽，花了 30 天寫完「重啟挑戰：老派軟體工程師的測試修練」這個系列。一直沒有在部落格這邊正式介紹過，趁這個機會寫一篇導讀，讓大家在還沒有把 30 篇全部看完也能瞭解裡面在講什麼。
30 天的內容從最基本的「為什麼要寫測試」一路寫到 Testcontainers、.NET Aspire 整合測試、TUnit，每一篇都有技術介紹說明、程式碼範例，以及我自己在專案裡踩過的坑。如果你對 .NET 測試有興趣但不確定要從哪裡開始看，這篇可以幫你省點時間。
另外，完賽之後我把這 30 天的測試知識重新整理成了 29 個 Agent Skills，讓 AI 可以直接拿來用。後續會有一系列文章介紹 `dotnet-testing-agent-skills` 這個專案 — 從 Agent Skills 到 Agent Orchestration 的完整方案。所以這篇鐵人賽導讀也算是後續系列的起點，先從源頭說起。
Vibe Coding 課程的繁榮與隱憂：當非技術出身的人開始販售「人人都能寫軟體」的夢想，轉職者與初階工程師該如何判斷？
GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。
更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。
"對 GitHub 的 Organization 中的成員設定 GitHub Copilot : 解釋篇" 所提到的 Organization 請理解為：
群體
這個 "群體" 可能會是：
…等這樣的詞彙解釋。
在 AI 盛行起來後，在數位世界中的任何一個 "單位" 中有可能存在多個 "人類" 或 "Agent" 的個體，那就適用這個 "Organization" 的觀點。
Reference：https://github.com/bubbliiiing/yolov4-pytorch
Key Word：WSL2、Bubbliiiing、Pytorch YOLOv4、Object Detection、RTX4060、Github License Issue、Roboflow、CrowdHuman
C# 14 新功能還有一些比較無法長篇描述的就集中在這裡一次說完。
在 GitHub Copilot (以 2026Q1 這時間點瞭解到) 所設計的各種 Plans 來看，在使用上分成兩大區塊：
如果你就是只有一個人，基本上都是 Individuals (個人/獨立個體商)。
這樣的使用情境大概就是，想要自己放飛自我寫程式或是整間公司就只有你一個人，不用跟其他任何 "人類" 或 "Agent" 有交流與互動就能完成工作，那可以選的 Plan 有：
在微服務架構中，一個使用者請求可能跨越多個服務，當問題發生時，如何追蹤這個請求到底經過了哪些服務？每個服務做了什麼事？花了多少時間？這就是「可觀測性（Observability）」要解決的問題。
本篇文章將介紹如何在 ASP.NET Core 10 微服務中整合 OpenTelemetry、Serilog、Jaeger 與 Aspire Dashboard，建立完整的分散式追蹤與結構化日誌方案。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
前篇已經聊過關於 Extension members 的一些基本操作，這裡補充一些前篇沒提到的部分。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
如果要在 C# 14 的眾多新功能中挑選一個最令我心動的，一定是 Extension members。這項功能不僅是對既有 this extension methods 的延展，而且是進一步的語言層級提升、更為貼近原生成員的使用體驗。
在 GitLab.com 申請好的帳號與建立第一個專案的 Repo 之後，就可以進行 Pipeline 的使用。
根據 ChatGPT 對 GitLab 中的 Pipeline 其定義是：
在程式碼變動時，自動執行 CI/CD（Continuous Integration / Continuous Delivery）流程。
技術一點的說：
當程式碼有異動的時候時，GitLab 會依照 .gitlab-ci.yml 的設定，根據 Pipeline 中所設計的 Stages (階段)，如: 建置、測試、部署…等，來自動化的執行一連串 Jobs (工作)。
不知道大家是否有這樣的困擾，使用Google Antigravity要開啟瀏覽器來進行除錯或測試的時候，有時候瀏覽器的開啟就是卡卡的，不順利，這個問題一個設定，也許就能處理。
在使用 GitLab 進行專案管理時，透過範本建立專案可以大幅減少初始化設定的時間。
這篇來介紹一下如何在 GitLab 中使用 .NET 專案範本 (dotnet template) 建立第一個專案，從建立 GitLab Project、套用範本，到完成基本的專案結構與設定。
這樣可以快速建立標準化的 .NET 專案環境，為後續的版本控制與 CI/CD 自動化流程奠定一定程度的基礎。