其實找不太到用 git submodule 的場合，直到 AI 登場後，這個需求對我而言就比較容易浮出檯面

你是否曾讀過一篇文章覺得很重要，但兩週後卻想不起來在哪看過？或者辛苦存了書籤、截圖，一個月後打開卻不知從何看起？更常見的問題是，文章 A 和文章 B 提到了同一個概念，但因為存在不同地方，你根本沒發現它們的關聯。

最近 OpenAI 共同創辦人、前 Tesla AI 總監 Andrej Karpathy 在 X 上分享了解決這個問題的方法，在網路上引起廣大回響。他的作法很簡單：把文章丟給 AI，AI 讀完後自動整理成一個 Wiki 知識庫，包含總結、目錄以及相關概念的連結，全部以 Markdown 檔案的形式存在你的電腦裡。

這篇文章我想要演練「用 Claude Code 建立這套個人知識管理系統」，從環境建置到實際 ingest 文章，一步一步帶大家走過去。

在軟體工程的開發與日常知識管理中，工具的選擇與工作流的順暢度往往決定了生產力的高低。傳統雲端筆記在切換頁面時常有卡頓感，容易打斷工作心流，且資料受限於第三方伺服器。

Obsidian 憑藉著本地端獨立 Markdown (MD) 檔案的特性，不依賴雲端伺服器，不僅確保了資料安全，其純文字的架構更是與 AI 程式開發工具（如 Claude Code 或 Gemini CLI）完美結合的絕佳載體。本篇文章將紀錄如何建置 Obsidian 基礎環境，透過 GitHub 進行全自動雲端同步，並導入 AI 工具實踐「自動整理」的筆記工作流。

在使用 AI 輔助開發（如 Claude Code、Copilot、Codex）接手或分析大型專案時，若讓 AI 直接讀取大量檔案，不僅會耗費大量 Token，AI 也容易迷失在細節中。Graphify 橫空出世，落實了 Karpathy 的工作流程，它是一款強大的擴充工具，能將專案內的程式碼、文件、圖片甚至影音，轉換為「可查詢的知識圖譜（Knowledge Graph）」。它能引導 AI 優先閱讀摘要報告，快速掌握系統架構與設計理念，這是我一直想要的阿。

因為 Windows 10 IoT Enterprise 的 2016 LTSB 推出至今將滿 10 年了，除了在今年 7/31 會 EOL 之外，也將會在今年的 10/13 正式 EOS。

手上的機台還是運作 Windows 10 IoT Enterprise 的 2016 LTSB 的怎辦呢？可以的話請把目光放向 Windows 11 IoT Enterprise LTSC 會是最長治久安的打算：

ASP.NET Framework 的 Session 預設使用排他鎖（Mutex），同一個使用者的 Request 會排隊等待，嚴重影響效能。而 ASP.NET Core 的 Session 雖然不會排隊，但底層是 IDistributedCache，不支援 HybridCache，每次存取都直接打 Redis，沒有 L1 記憶體快取，高流量時有快取擊穿的風險。

這篇想要演練的是用 HybridCache + Cookie 實作一個 SessionCacheProvider，讓開發者用起來跟原本的 Session["key"] 幾乎一樣，同時支援 ASP.NET Framework 4.8 和 ASP.NET Core (.NET 10)。

如果真要推薦近期偏 AI-driven 而生的 IDE 開發工具，目前比較有 "獨立" 精神的是 OpenCode "Desktop"。

雖然個人覺得 OpenCode 是 CLI 主打，但 OpenCode 後來也推出了 OpenCode Desktop 可以直接在 macOS / Windows 安裝使用：

如果你今天是 .NET 開發人員，那使用 Visual Studio 應該不陌生；如果你今天是開發人員，那使用 Visual Studio Code 應該不陌生。

自 Visual Studio 2026 起，Visual Studio 幾乎可以算是直接內建 "GitHub Copilot Chat"：

當然 Visual Studio 2022 也能裝 GitHub Copilot Chat 的，但不知道是不是個人的心理作用，感覺用起來沒有 Visual Studio 2026 的順。

Visual Studio Code 也不用太多說什麼，在 Visual Studio Code 的延伸模組的市集當中搜尋一下 "GitHub Copilot Chat" 就可以安裝。