ＣＪ軟體工程日誌

AI Vibecoding 的地基（上）：大型專案導入前的準備筆記 這篇文章記錄我在一個真實的大型 monorepo（後端數千支服務、前端數百個元件的 .NET + Vue 3 專案） 導入 AI 輔助開發的完整過程——蓋了什麼、為什麼蓋、踩過哪些坑、以及先後順序該怎麼排。 為了不洩漏真實業務內容，範例一律改寫成大家熟悉的 NorthWind（北風貿易） 資料庫情境，路徑也改成通用寫法，但架構、順序、數字都是真實測過的。 📖 系列文章・共 2 篇，這是上篇 下篇：五層架構的實作 Prompt——照抄就能用的版本 → 太長不看版 在大型專案放手讓 AI 改程式碼之前，需要先蓋五層基礎建設： ①靜態地圖 （讓 AI 找得到東西）→ ②閱讀紀律 （教 AI 怎麼查地圖，而不是整包讀）→ ③風格範本 （讓 AI 寫出來的東西像自己人）→ ④事實庫 （記錄程式碼本身回答不了的單一業務真相）→ ⑤深度研究筆記 （累積子系統級的來龍去脈，但要有防發散設計）。 前兩層先蓋、成本最低效益最高；後三層要等真實需求出現才動手，不要預先猜測。 起 沒有地圖的 AI，只會用最笨的方法找路 先講一個真實測過的失敗案例。任務是：「幫我追一支 API，看看改動它會影響前後端哪些地方」。 天真的作法是讓 AI 直接對整個 repo 下關鍵字搜尋、讀完相關檔案——聽起來合理，實際跑起來完全不是那回事。 真實測過的數字 同一個搜尋，因為沒有排除建置產物目錄，回傳結果裡混進了壓縮過的前端 bundle （單行超過五萬字元），總輸出超過 30 萬字元 ，跑了 兩分鐘還沒結束 。 而真正相關的命中，其實只有 5 個檔案、不到一千字 。 問題不是 AI 不夠聰明，是它跟人一樣——沒有地圖，只能把整座城市走一遍。專案規模一旦到了 數千支後端檔案、數百個前端元件，「...

問題描述 在 Windows 上使用 nvm for Windows（nvm4w） 管理多個 Node.js 版本時，執行切換版本的指令： nvm use 20.20.2 指令執行後 沒有任何反應、也不會報錯 ，但用 node -v 確認時，版本號卻完全沒有改變，實際上還是停留在切換前的版本。反覆重試、重開終端機都沒用。 原因分析 nvm4w 管理多版本 Node.js 的方式，是在一個固定路徑（預設為 C:\nvm4w\nodejs ） 建立一個 目錄連結（junction） ，指向實際安裝的某個版本資料夾，例如 ...\nvm\v20.20.2 。 這條連結才是系統 PATH 實際指向的位置，所以只要連結指到哪個版本， node -v 就會回報哪個版本。 問題就出在這裡： nvm use 內部理應要先移除舊的 junction、再建立新的 junction 指向目標版本，但實際測試下來這個「移除舊連結 → 重建新連結」的動作偶爾會失效，導致連結沒有被更新——指令本身不報錯，版本卻沒有真正切換。 解決辦法：手動控制切換 既然問題出在 nvm use 內部重建連結的邏輯不可靠，那就繞過它，改成自己寫一支批次檔，直接用 rmdir 刪掉舊 junction，再用 mklink /J 重新建立一次，確保連結一定會指向正確版本。 把下面這支腳本存成 %USERPROFILE%\.local\bin\nvmuse.cmd （ %USERPROFILE% 是 Windows 的環境變數，會自動代入目前登入的使用者資料夾路徑，不需要自己改成固定的使用者名稱）： @echo off setlocal enabledelayedexpansion set "NVM_ROOT=%USERPROFILE%\AppData\Local\nvm" set "NVM_LINK=C:\nvm4w\nodejs" if "%~1"=="" ( echo Usag...

C# / LINQ 用「資料形狀」思考 LINQ:SelectMany 與 10 個進階 API Select 、 Where 、 GroupBy 之後的下一步。每個範例都標出資料怎麼進、結果怎麼出—— 綠色註解就是答案 。 SelectMany 三用法 10 個進階 API 組合技 實戰:RulesEngine 形狀對照表 進階 LINQ 有個比背定義更好用的讀法: 看它讓資料的「形狀」怎麼變 。巢狀變扁平、兩條變一條、一條變一個值——記住形狀,API 自然就記住了。這篇每個 API 都附上一行形狀簽名,以及完整的輸入資料與輸出結果。 // SelectMany:進階 LINQ 的入口 它做的事只有一件:把「集合中的集合」攤平成一層。但三種用法各有妙處。 1 / 3 帶 result selector [[a, b], [c]] → [a, b, c] (每個元素還記得自己的爸爸) 最實用的 overload:攤平的同時 保留父層資訊 。第二個參數同時拿得到父元素和子元素。 // 資料 var orders = new[] { new { OrderId = 1, Customer = "小明" , Items = new[] { new { Product = "滑鼠" , Price = 500 }, new { Product = "鍵盤" , Price = 1200 } } }, new { OrderId = 2, Customer = "小華" , Items = new[] { new { Product = "螢幕" , Price = 4500 } } } }; var flat = orders. SelectMany (o => o.Items, (o, item) => new { o.OrderId, o.Customer, item.Product, item.Price }); // 結果:2 筆訂單 × 各自明細 → 攤成 3 列,每列都帶著父層的 Cu...

從零開始的大數據 SQL 優化： 用北風資料庫打造「零壓力分批轉檔」神級架構 在日常開發中，我們常常面臨需要從舊表撈取資料、經過一連串運算與 JOIN 後，再將結果生成一張實體報表提供給前端或長官檢視的需求。然而，當資料量突破百萬、甚至千萬等級，且資料庫充滿了歷史包袱與非正規化結構時，傳統的作法往往會引發嚴重的 「磁碟 I/O 暴走」 或 「共用 tempdb 撐爆」 的慘劇，進而收到資料庫管理員（DBA）的奪命連環叩。 今天這篇文章，我們將結合 SELECT TOP 0 INTO 的複製神技，搭配 WHILE 迴圈與「事後補建索引」的進階心法，利用經典的 北風資料庫 (Northwind) 當作戰場，手把手帶你建構出一套兼具 高吞吐量、零 tempdb 負擔、且具備斷線容錯能力 的終極大數據處理方案！ 一、 傳統作法與大數據瓶頸 面對大數據轉檔，初學者最常使用 SELECT INTO 或大型 CTE (Common Table Expression) 一口氣把資料全部灌進去。這種「一條 SQL 戰到底」的作法在小表運作良好，但遇到百萬級資料時，就會產生巨大的效能分水嶺： 暫存表 (#TempTable) 法 ：直接整批塞進暫存表，會將幾百萬筆資料塞滿全系統共用的 tempdb 空間，導致其他線上即時交易跟著集體卡死報錯。 純 CTE / 子查詢法 ：雖然避開了實體硬碟空間的消耗，但大量的資料串流在記憶體中反覆被多個 JOIN 呼叫時，會導致資料庫反覆重算，CPU 瞬間飆高至 100%。 【圖解：大量資料一次性寫入 vs 分批寫入的資料庫壓力對比】 [Image of Database table ingestion comparison showing monolithic query vs batching loops with tempdb lifecycle] 為了克服這些代價，高手工程師在實務上會採用 「分而治之 (Divide and Conquer)」 的策略：把一個會讓資料庫休克的大手術，拆解成數十個毫無負擔的微整形。這就是「分批處理...

Vue 3 + .NET 8 Web API + Azure SQL Database 從零開始，將現代化全端應用程式部署到 Microsoft Azure 雲端平台 📋 專案架構總覽 🎨 前端層 Vue 3 + Vite Azure Static Web Apps ⚙️ 後端層 .NET 8 Web API Azure App Service 🗄️ 資料層 SQL Server Azure SQL Database 💡 為什麼選擇這個技術組合？ 現代化開發： Vue 3 Composition API + .NET 8 提供最新的開發體驗 完整整合： Azure 全家桶服務無縫配合，部署簡單 自動化 CI/CD： GitHub Actions 自動建置部署，提高效率 成本優化： 提供免費層級和彈性計費，適合各種規模專案 企業級安全： 內建 SSL、防火牆、備份機制 🗺️ 部署流程總覽 1 ...