Chrome Extension 最迷人的地方，是它可以在不改動網站原始碼的情況下，替既有網頁補上一層新的操作體驗。這篇文章會以 coolpc-plus 這個專案為範例，拆解一個 Chrome Extension 如何在原價屋估價頁注入側邊欄、讀取頁面零件清單、呼叫 AI Provider，最後把推薦零件反映回原本的頁面。
這個專案不需要打包流程，也沒有複雜的前端框架。整體使用 Chrome Extension Manifest V3、原生 JavaScript、HTML 與 CSS 完成，因此很適合拿來理解 Chrome 插件的基本架構。
Docker 是容器化技術的核心工具，掌握其常用指令對於日常開發和運維工作至關重要。本指南將介紹最實用的 Docker 指令，並提供詳細的使用說明和範例。
平常在測試新的開發工具、VS Code 版本、JDK 或終端機設定時，最麻煩的地方通常不是安裝本身，而是安裝後會不會改到主機環境。像是 PATH、右鍵選單、登錄檔、使用者設定與工具版本，只要多試幾次，就可能讓原本穩定的開發機變得難以追蹤。
而這篇文章的起因，則是近期各種套件竊取資訊、惡意更新與供應鏈攻擊事件越來越頻繁。當我們只是想快速驗證某個工具、套件或 extension 是否可用時，其實不一定適合直接在主要開發機上執行。即使來源看起來可信，也可能因為相依套件、安裝腳本或更新流程帶來額外風險。
Windows Sandbox 很適合用來處理這類需求。它可以建立一個一次性的 Windows 環境，關閉後所有變更都會被丟棄；只要把啟動設定與安裝腳本整理好，每次都能快速還原出乾淨且一致的 VS Code 開發驗證環境。
這篇文章會以 C:\Sandbox 底下的設定為例，說明如何透過 Windows Sandbox 自動掛載資料夾、套用基本系統設定，並離線安裝 VS Code、PowerShell 7、Windows Terminal、7-Zip 與 Zulu JDK，讓 Sandbox 啟動後就能直接進行開發驗證。完整範例可參考 java-sandbox 專案。
最近把一個放在腦中一陣子的小想法做出來了：幫自己的 blog 做一個可以聊天的 agent。
這個念頭其實是從很日常的困擾開始的。文章寫久了之後，自己有時候也會忘記以前到底寫過哪些東西。要找內容時，通常就是翻分類、看標籤、搜關鍵字；這些方式當然都能用，但總覺得少了一點「直接問它」的感覺。既然現在 AI 工具都已經這麼容易接了，那乾脆試試看，能不能讓自己的 blog 也變成一個可以對話的入口。
所以這次就用 LangChain4j 快速做了一個 Blog Agent。沒有一開始就想把它做成什麼很完整的產品，比較像是先把腦中的畫面做出來：後端有一個 server side 可以處理 agent 的互動，服務直接丟到 Cloud Run 上跑，然後再寫一個給 Hexo 用的聊天室窗插件，把它接回原本的 blog 頁面。
做的時候其實滿有那種「先讓它跑起來再說」的感覺。LangChain4j 這邊先把後端流程接起來，Cloud Run 負責讓服務可以被呼叫，Hexo 插件則處理畫面上的聊天入口。每一塊都不算特別巨大，但全部接在一起之後，看到自己的部落格右下角真的出現一個可以互動的聊天室，感覺還是滿微妙的。原本只是靜靜放文章的地方，突然多了一個可以被詢問的介面。
這一輪 Pixel Battle 的開發，主要集中在任務引導與前期體驗的整理。相較於前幾次紀錄裡還在搭建系統骨架，現在遊戲已經做出兩個章節的任務流程，也加入了對話系統。整體來看，玩家進入遊戲後應該會比以前更容易理解自己正在做什麼，也比較能感受到遊戲希望帶出的體驗方向。
最近 Pixel Battle 的基礎系統已經完成到一個可以繼續往內容層推進的程度。地圖探索、角色成長、戰鬥切換、怪物素材、技能與 build 的骨架都逐步搭起來之後，開發上遇到的問題也開始改變：以前比較常卡在「系統要怎麼做」，現在則更常卡在「玩家進來之後，到底要經歷什麼」。
所以這一輪我把重點放在世界觀設定，以及遊戲前 30 分鐘的體驗內容。也就是先讓遊戲從一個功能逐漸堆起來的原型，慢慢變成一個有背景、有起點、有任務節奏，也能讓玩家理解自己正在扮演什麼角色的作品。
最近和朋友聊了一下，也趁這個機會重新檢視了原本的設計方向。最早我想做的是結合世界地理位置的遊戲概念，讓玩家可以依照不同地區、座標或現實地圖上的位置展開探索與戰鬥；這個想法聽起來很有想像空間，但真的開始往下拆解之後，才發現範圍比一開始預期的還要龐大許多。光是要建立世界規模的地理資料集、整理不同區域的內容規則，甚至後續還要考慮資料維護、遊戲平衡與實際遊玩節奏，就已經不是目前這個原型階段能夠輕易承擔的規模。因此，接下來我打算先把內容收斂到限定區域，先從比較小、比較明確的範圍開始設計，讓核心玩法、戰鬥流程與角色成長可以更聚焦。這樣雖然暫時放棄了一些宏大的想像，但也讓整個專案更有機會真正做出可玩的版本，而不是停留在一個很大的概念上。
在 VS Code 的 GitHub Copilot Chat 中，Custom Agent 可以讓我們把不同類型的工作拆成明確角色。例如有的 agent 負責規劃，有的 agent 負責提出反對意見，有的 agent 則專門整理文件。當任務變得複雜時，比起只讓單一 agent 從頭做到尾，更適合透過多個 agent 協作，讓每個角色各自處理自己擅長的部分，再由統籌者整合成最終成果。
這次影片示範的是一個「多 agent 協作任務」：使用者要求 Copilot 幫忙設計一款符合現代玩法的貪食蛇遊戲，並將企劃輸出到 plans 資料夾底下。整個過程不是直接請單一 agent 產生一份企劃，而是透過 commander agent 統籌，先理解工作區、確認限制，再把任務交給不同角色審視，最後整合成一份可審閱的遊戲企劃文件。
Custom Agent 是 VS Code 中 GitHub Copilot Chat 的自訂代理設定。它可以讓你針對不同開發任務，預先定義 AI 應該扮演的角色、可使用的工具、模型偏好與工作流程，讓 Copilot 在切換到該 agent 後，以更貼近任務需求的方式回應。
內建 agent 通常適合一般用途，但實際開發時，不同任務會需要不同的行為模式。例如規劃階段可能只需要讀取與搜尋工具，避免 AI 直接修改檔案；實作階段則需要編輯工具；Code Review 階段又會更重視安全性、可維護性與測試覆蓋。Custom Agent 的價值就在於把這些設定整理成可重複使用的工作角色。
Custom Agent 會定義在 .agent.md Markdown 檔案中，可以放在工作區內與團隊共享，也可以放在使用者層級，讓你在不同專案中重複使用。
