使用 Windows Sandbox 建立可重複的 VS Code 開發驗證環境

簡介

平常在測試新的開發工具、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 專案。

啟用 Windows Sandbox

Windows Sandbox 是 Windows 內建的隔離桌面環境，但不是所有版本都能使用。開始前需要先確認主機使用的是 Windows 10 / 11 Pro、Enterprise 或 Education 版本，並且已啟用 CPU 虛擬化功能。如果是 Windows Home，預設不提供 Windows Sandbox 功能。

確認版本與虛擬化支援後，可以透過「Windows 功能」啟用：

1. 開啟開始選單，搜尋並進入「開啟或關閉 Windows 功能」。
2. 勾選「Windows Sandbox」。
3. 按下「確定」後等待功能安裝完成。
4. 依照提示重新啟動電腦。

如果習慣使用命令列，也可以用系統管理員身分開啟 PowerShell，執行以下指令啟用：

1

Enable-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM -All

功能啟用並重新開機後，可以在開始選單搜尋 Windows Sandbox 直接啟動預設環境。若能成功開啟一個乾淨的 Windows 桌面，就代表 Sandbox 功能已安裝完成。

不過，直接從開始選單啟動的 Sandbox 只會得到預設環境。若要套用這篇文章後續的自動化設定，接下來會改用 C:\Sandbox\boot.wsb 作為啟動入口，讓 Sandbox 開機後自動掛載資料夾並執行初始化腳本。

目錄結構

這次的 Sandbox 初始化資料都放在主機的 C:\Sandbox 底下，主要分成四個部分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

C:\Sandbox
├─ boot.bat
├─ boot.wsb
├─ Init_Scripts
│  ├─ Install-All.ps1
│  └─ RegistrySettings.cmd
├─ Install
│  ├─ 7z2601-x64.exe
│  ├─ Microsoft.WindowsTerminal_1.24.11321.0_x64.zip
│  ├─ PowerShell-7.6.3-win-x64.msi
│  ├─ VSCodeUserSetup-x64-1.126.0.exe
│  └─ zulu25.32.21-ca-fx-jdk25.0.2-win_x64.zip
└─ Logs
   ├─ install.log
   └─ install-transcript.log

其中 boot.wsb 是 Windows Sandbox 的啟動設定檔，負責定義資源、映射資料夾與登入後要執行的命令。boot.bat 則是進入 Sandbox 後的第一個入口，會依序執行登錄檔設定與工具安裝腳本。

Install 資料夾放的是離線安裝檔。這樣做的好處是 Sandbox 不需要每次啟動都重新下載工具，也比較容易控制測試時使用的版本。Logs 則用來保存安裝紀錄，方便確認初始化是否成功，或在安裝失敗時回頭追查原因。

Windows Sandbox 啟動設定

boot.wsb 的第一個重點是資源與裝置設定。這份設定將 Sandbox 記憶體設為 8192 MB，並停用麥克風、攝影機與印表機重新導向；剪貼簿、vGPU 與網路則維持啟用。

1
2
3
4
5
6
7
8

<MemoryInMB>8192</MemoryInMB>
<AudioInput>Disable</AudioInput>
<VideoInput>Disable</VideoInput>
<PrinterRedirection>Disable</PrinterRedirection>
<ClipboardRedirection>Enable</ClipboardRedirection>
<ProtectedClient>Disable</ProtectedClient>
<vGPU>Enable</vGPU>
<Networking>Enable</Networking>

這樣的配置很適合開發驗證情境：保留剪貼簿與網路，方便複製指令、下載資料或登入服務；同時關閉不需要的輸入裝置與印表機重新導向，降低 Sandbox 接觸主機周邊資源的範圍。

接著是資料夾映射設定。這份設定將主機的 C:\Sandbox 映射到 Sandbox 內相同路徑，讓啟動腳本、安裝檔與 log 都能被 Sandbox 存取。

1
2
3
4

<MappedFolder>
	<HostFolder>C:\Sandbox</HostFolder>
	<SandboxFolder>C:\Sandbox</SandboxFolder>
</MappedFolder>

另外也將主機的 C:\CodeBase 以唯讀方式映射進 Sandbox，方便在隔離環境中開啟與檢查程式碼，但避免 Sandbox 直接修改主機上的原始碼。

1
2
3
4
5

<MappedFolder>
	<HostFolder>C:\CodeBase</HostFolder>
	<SandboxFolder>C:\CodeBase</SandboxFolder>
	<ReadOnly>true</ReadOnly>
</MappedFolder>

下載資料夾同樣以唯讀方式映射到 Sandbox 使用者的 Downloads 目錄，適合取用主機已下載的檔案，又不讓 Sandbox 寫回主機下載目錄。

1
2
3
4
5

<MappedFolder>
	<HostFolder>C:\Users\User\Downloads</HostFolder>
	<SandboxFolder>C:\Users\WDAGUtilityAccount\Downloads</SandboxFolder>
	<ReadOnly>true</ReadOnly>
</MappedFolder>

最後，LogonCommand 指定 Sandbox 登入後自動執行 boot.bat。

1
2
3

<LogonCommand>
	<Command>cmd /c "C:\Sandbox\boot.bat"</Command>
</LogonCommand>

也就是說，只要開啟 boot.wsb，後續的系統設定與工具安裝都會自動開始，不需要手動進入 Sandbox 後再一個一個執行命令。

啟動入口：boot.bat

boot.bat 的內容很單純，主要負責組合腳本路徑，然後依序執行 RegistrySettings.cmd 與 Install-All.ps1。

1
2
3
4
5
6
7
8
9
10
11

@echo off
setlocal

set "SCRIPT_DIR=%~dp0"
set "REGISTRY_SCRIPT=%SCRIPT_DIR%Init_Scripts\RegistrySettings.cmd"
set "INSTALL_SCRIPT=%SCRIPT_DIR%Init_Scripts\Install-All.ps1"

call "%REGISTRY_SCRIPT%"
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%INSTALL_SCRIPT%"

endlocal

這裡使用 %~dp0 取得 boot.bat 所在目錄，因此即使未來 C:\Sandbox 內容調整，只要相對目錄結構不變，腳本仍能正確找到初始化檔案。

PowerShell 腳本執行時加上 -NoProfile 與 -ExecutionPolicy Bypass，目的是避免受到使用者 profile 或執行原則影響，讓 Sandbox 初始化流程更接近可重複執行的狀態。

套用 Sandbox 內的基本操作設定

RegistrySettings.cmd 負責先把 Sandbox 調整成比較適合開發與驗證的桌面環境。它做了幾件常見但實用的設定：

• 在開始選單中顯示「以其他使用者執行」選項
• 設定主控台與終端機委派
• 關閉開始選單建議項目
• 顯示檔案副檔名
• 顯示隱藏檔案與資料夾
• 將檔案總管 Win + E 預設開啟位置設為「本機」
• 將工作列搜尋調整為僅顯示搜尋圖示
• 啟用傳統右鍵選單

例如顯示副檔名與隱藏檔案的設定如下：

1
2

reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v "HideFileExt" /t REG_DWORD /d 0 /f
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v "Hidden" /t REG_DWORD /d 1 /f

這些設定不一定和 VS Code 安裝直接相關，但會影響開發驗證時的操作效率。例如在測試 extension、檢查設定檔或確認壓縮檔內容時，能直接看到副檔名與隱藏檔會方便很多。

腳本最後會重新啟動檔案總管，讓相關設定立即生效。

1
2

taskkill /f /im explorer.exe >nul 2>&1
start explorer.exe

離線安裝開發工具

真正建立開發環境的工作集中在 Init_Scripts\Install-All.ps1。這支腳本一開始會設定幾個重要路徑：

1
2
3
4
5
6

$Root = Split-Path -Parent $PSScriptRoot
$InstallDir = Join-Path $Root 'Install'
$ToolsDir = 'C:\Tools'
$LogsDir = Join-Path $Root 'Logs'
$LogFile = Join-Path $LogsDir 'install.log'
$TranscriptFile = Join-Path $LogsDir 'install-transcript.log'

$Root 會指向 C:\Sandbox，$InstallDir 則指向離線安裝檔所在的 C:\Sandbox\Install。可攜式工具會解壓到 C:\Tools，安裝過程則記錄到 C:\Sandbox\Logs。

腳本也會啟用 transcript，完整保存 PowerShell 執行過程。

1

Start-Transcript -Path $TranscriptFile -Append | Out-Null

在安裝前，Require-File 會先確認預期的安裝檔是否存在。如果缺少任一檔案，流程會直接中止，避免後面出現不明確的安裝錯誤。

1
2
3
4
5
6
7
8
9
10

function Require-File {
	param([string]$FileName)

	$path = Join-Path $InstallDir $FileName
	if (-not (Test-Path -LiteralPath $path)) {
		throw "Missing installer: $path"
	}

	return $path
}

這次安裝流程包含以下工具：

7-Zip 與 PowerShell 7

7-Zip 透過靜默參數 /S 安裝，安裝後會將 C:\Program Files\7-Zip 加入系統 PATH。

1
2
3

$sevenZipInstaller = Require-File '7z2601-x64.exe'
Invoke-Installer -FilePath $sevenZipInstaller -Arguments @('/S') -Name '7-Zip'
Add-MachinePath 'C:\Program Files\7-Zip'

PowerShell 7 則透過 msiexec.exe 以靜默模式安裝，並加入檔案總管右鍵選單，但不啟用 PowerShell Remoting 與 Microsoft Update。

1
2
3

$powershellInstaller = Require-File 'PowerShell-7.6.3-win-x64.msi'
Invoke-Installer -FilePath 'msiexec.exe' -Arguments @('/i', $powershellInstaller, '/qn', '/norestart', 'ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL=1', 'ENABLE_PSREMOTING=0', 'REGISTER_MANIFEST=1', 'USE_MU=0', 'ENABLE_MU=0') -Name 'PowerShell 7'
Add-MachinePath 'C:\Program Files\PowerShell\7'

Windows Terminal

Windows Terminal 使用 ZIP 套件，不走安裝程式。腳本會先清掉目標資料夾，再解壓到 C:\Tools\WindowsTerminal。

1
2
3

$terminalArchive = Require-File 'Microsoft.WindowsTerminal_1.24.11321.0_x64.zip'
$terminalDir = Join-Path $ToolsDir 'WindowsTerminal'
Expand-ArchiveClean -ArchivePath $terminalArchive -DestinationPath $terminalDir -Name 'Windows Terminal'

解壓後，腳本會找到實際的應用程式目錄，加入 PATH，並在桌面建立 Windows Terminal 捷徑。

1
2

Add-MachinePath $terminalRoot.FullName
Create-WindowsTerminalDesktopShortcut -TerminalRootPath $terminalRoot.FullName

這讓 Sandbox 啟動完成後，可以直接從桌面開啟 Windows Terminal，不需要手動尋找 WindowsTerminal.exe。

Zulu JDK

Zulu JDK 同樣以 ZIP 方式解壓到 C:\Tools\JDK，接著設定系統層級的 JAVA_HOME，並將 JDK 的 bin 目錄加入 PATH。

1
2
3
4
5
6

$jdkArchive = Require-File 'zulu25.32.21-ca-fx-jdk25.0.2-win_x64.zip'
$jdkDir = Join-Path $ToolsDir 'JDK'
Expand-ArchiveClean -ArchivePath $jdkArchive -DestinationPath $jdkDir -Name 'Zulu JDK'
[Environment]::SetEnvironmentVariable('JAVA_HOME', $jdkRoot.FullName, 'Machine')
$env:JAVA_HOME = $jdkRoot.FullName
Add-MachinePath (Join-Path $jdkRoot.FullName 'bin')

這對 VS Code Java 開發驗證很重要。啟動 VS Code 後，可以直接檢查 Java extension 是否能找到 JDK，或透過終端機執行 java -version 確認環境變數是否生效。

Visual Studio Code

VS Code 使用 User Setup 安裝包，透過靜默參數安裝，並加入 PATH、檔案右鍵選單與資料夾右鍵選單。

1
2
3

$vscodeInstaller = Require-File 'VSCodeUserSetup-x64-1.126.0.exe'
Invoke-Installer -FilePath $vscodeInstaller -Arguments @('/VERYSILENT', '/SUPPRESSMSGBOXES', '/NORESTART', '/MERGETASKS=!runcode,desktopicon,addcontextmenufiles,addcontextmenufolders,addtopath') -Name 'Visual Studio Code'
Register-VSCodeContextMenus

安裝完成後，Register-VSCodeContextMenus 會再針對檔案、資料夾與資料夾空白處建立 Open with VS Code 右鍵選單。

1
2
3
4
5

$menuItems = @(
	@{ Path = 'Registry::HKEY_CURRENT_USER\Software\Classes\*\shell\VSCode'; Command = '"{0}" "%1"' -f $codeExe },
	@{ Path = 'Registry::HKEY_CURRENT_USER\Software\Classes\Directory\shell\VSCode'; Command = '"{0}" "%1"' -f $codeExe },
	@{ Path = 'Registry::HKEY_CURRENT_USER\Software\Classes\Directory\Background\shell\VSCode'; Command = '"{0}" "%V"' -f $codeExe }
)

搭配前面啟用的傳統右鍵選單，這樣在 Sandbox 中測試 Open with VS Code 行為會更直覺，也更接近許多開發者熟悉的 Windows 操作方式。

啟動與驗證流程

使用時只需要在主機上開啟 C:\Sandbox\boot.wsb。Windows Sandbox 登入後會自動執行 C:\Sandbox\boot.bat，接著套用登錄檔設定並開始安裝工具。

從目前的 install-transcript.log 可以看到，整段流程在 Sandbox 內以 WDAGUtilityAccount 身分執行，PowerShell 版本為 5.1，並成功完成所有工具安裝。

1
2
3
4
5
6
7
8
9

[2026-06-26 01:20:42] Starting sandbox application installation
[2026-06-26 01:20:42] Installing 7-Zip
[2026-06-26 01:20:44] Installing PowerShell 7
[2026-06-26 01:22:51] Extracting Windows Terminal
[2026-06-26 01:22:52] Created Windows Terminal desktop shortcut: C:\Users\WDAGUtilityAccount\Desktop\Windows Terminal.lnk
[2026-06-26 01:22:52] Extracting Zulu JDK
[2026-06-26 01:22:55] Installing Visual Studio Code
[2026-06-26 01:23:25] Registered VS Code file and folder context menus
[2026-06-26 01:23:25] Installation completed successfully

依照這份紀錄，初始化大約從 01:20:42 到 01:23:25 完成，整體約三分鐘左右。完成後腳本會顯示「初始化成功」提示視窗，代表 Sandbox 已經可以開始進行 VS Code 開發驗證。

建議啟動後可以依序檢查幾個項目：

• 桌面是否出現 Windows Terminal 捷徑
• C:\Tools 是否包含 Windows Terminal 與 JDK
• 檔案總管是否顯示副檔名與隱藏檔
• 右鍵選單是否出現 Open with VS Code
• 終端機中是否能執行 pwsh、code、7z 與 java -version
• VS Code 是否能開啟唯讀映射的 C:\CodeBase

如果安裝過程失敗，可以先檢查 C:\Sandbox\Logs\install.log。若需要更完整的 PowerShell 執行細節，再查看 C:\Sandbox\Logs\install-transcript.log。

為什麼適合用來驗證 VS Code 開發環境

這套做法最大的優點是可重複與可丟棄。每次開啟 Sandbox 都會從乾淨環境開始，然後透過同一份腳本安裝指定版本的工具。當你要測試新的 VS Code 版本、Java extension 行為、PATH 設定、右鍵選單或終端機整合時，不需要擔心把主機環境弄亂。

C:\CodeBase 以唯讀方式映射也很適合做驗證。你可以在 Sandbox 中開啟專案、觀察 VS Code 是否正確載入、測試 extension 或執行只讀分析；即使誤操作，也不會直接修改主機上的原始碼。

離線安裝檔則讓環境更穩定。工具版本都固定在 Install 資料夾中，不會因為每次從網路下載到不同版本而造成測試結果不一致。對於需要反覆確認 VS Code 開發體驗、JDK 偵測、命令列工具整合的情境，這會比手動安裝更容易追蹤。

小結

透過 boot.wsb、boot.bat、RegistrySettings.cmd 與 Install-All.ps1，可以把 Windows Sandbox 變成一個自動化的 VS Code 開發驗證環境。主機只需要準備好 C:\Sandbox 目錄與離線安裝檔，啟動 Sandbox 後就會自動完成桌面設定、工具安裝、PATH 設定、JDK 設定與 VS Code 右鍵選單註冊。

這種方式特別適合用來驗證不想直接動到主機的開發環境變更。測完之後關閉 Sandbox，所有 Sandbox 內的變更都會消失；下一次再開啟時，又能從同一份腳本重新產生一致的測試環境。對需要反覆測試 VS Code、Java 工具鏈與 Windows 開發體驗的人來說，是一個乾淨、可控又容易重現的做法。

參考專案

• java-sandbox

VS Code 開發 Java 常用快捷鍵介紹

簡介

VS Code 搭配 Extension Pack for Java 後，已經可以完成 Java 專案開發中常見的編輯、導覽、重構、測試與除錯工作。不過，如果每個動作都依賴滑鼠點選，開發節奏很容易被打斷。熟悉幾組常用快捷鍵，可以讓你在閱讀程式碼、追蹤呼叫關係、修正錯誤與啟動 Debug 時更加順手。

這篇文章整理在 VS Code 上開發 Java 時最常用的快捷鍵，會以實際開發情境分類，方便你依照自己的使用頻率逐步記起來。

用 LangChain4j 做了一個自己的 Blog Agent

最近把一個放在腦中一陣子的小想法做出來了：幫自己的 blog 做一個可以聊天的 agent。

這個念頭其實是從很日常的困擾開始的。文章寫久了之後，自己有時候也會忘記以前到底寫過哪些東西。要找內容時，通常就是翻分類、看標籤、搜關鍵字；這些方式當然都能用，但總覺得少了一點「直接問它」的感覺。既然現在 AI 工具都已經這麼容易接了，那乾脆試試看，能不能讓自己的 blog 也變成一個可以對話的入口。

所以這次就用 LangChain4j 快速做了一個 Blog Agent。沒有一開始就想把它做成什麼很完整的產品，比較像是先把腦中的畫面做出來：後端有一個 server side 可以處理 agent 的互動，服務直接丟到 Cloud Run 上跑，然後再寫一個給 Hexo 用的聊天室窗插件，把它接回原本的 blog 頁面。

做的時候其實滿有那種「先讓它跑起來再說」的感覺。LangChain4j 這邊先把後端流程接起來，Cloud Run 負責讓服務可以被呼叫，Hexo 插件則處理畫面上的聊天入口。每一塊都不算特別巨大，但全部接在一起之後，看到自己的部落格右下角真的出現一個可以互動的聊天室，感覺還是滿微妙的。原本只是靜靜放文章的地方，突然多了一個可以被詢問的介面。

Pixel Battle 開發紀錄 04：任務引導、對話系統與方向取捨

這一輪 Pixel Battle 的開發，主要集中在任務引導與前期體驗的整理。相較於前幾次紀錄裡還在搭建系統骨架，現在遊戲已經做出兩個章節的任務流程，也加入了對話系統。整體來看，玩家進入遊戲後應該會比以前更容易理解自己正在做什麼，也比較能感受到遊戲希望帶出的體驗方向。

Pixel Battle 開發紀錄 03：世界觀與前 30 分鐘體驗

最近 Pixel Battle 的基礎系統已經完成到一個可以繼續往內容層推進的程度。地圖探索、角色成長、戰鬥切換、怪物素材、技能與 build 的骨架都逐步搭起來之後，開發上遇到的問題也開始改變：以前比較常卡在「系統要怎麼做」，現在則更常卡在「玩家進來之後，到底要經歷什麼」。

所以這一輪我把重點放在世界觀設定，以及遊戲前 30 分鐘的體驗內容。也就是先讓遊戲從一個功能逐漸堆起來的原型，慢慢變成一個有背景、有起點、有任務節奏，也能讓玩家理解自己正在扮演什麼角色的作品。

Pixel Battle 開發紀錄 02：重新收斂遊戲方向

最近和朋友聊了一下，也趁這個機會重新檢視了原本的設計方向。最早我想做的是結合世界地理位置的遊戲概念，讓玩家可以依照不同地區、座標或現實地圖上的位置展開探索與戰鬥；這個想法聽起來很有想像空間，但真的開始往下拆解之後，才發現範圍比一開始預期的還要龐大許多。光是要建立世界規模的地理資料集、整理不同區域的內容規則，甚至後續還要考慮資料維護、遊戲平衡與實際遊玩節奏，就已經不是目前這個原型階段能夠輕易承擔的規模。因此，接下來我打算先把內容收斂到限定區域，先從比較小、比較明確的範圍開始設計，讓核心玩法、戰鬥流程與角色成長可以更聚焦。這樣雖然暫時放棄了一些宏大的想像，但也讓整個專案更有機會真正做出可玩的版本，而不是停留在一個很大的概念上。

VS Code 多個 Agent 協作任務實戰

簡介

在 VS Code 的 GitHub Copilot Chat 中，Custom Agent 可以讓我們把不同類型的工作拆成明確角色。例如有的 agent 負責規劃，有的 agent 負責提出反對意見，有的 agent 則專門整理文件。當任務變得複雜時，比起只讓單一 agent 從頭做到尾，更適合透過多個 agent 協作，讓每個角色各自處理自己擅長的部分，再由統籌者整合成最終成果。

這次影片示範的是一個「多 agent 協作任務」：使用者要求 Copilot 幫忙設計一款符合現代玩法的貪食蛇遊戲，並將企劃輸出到 plans 資料夾底下。整個過程不是直接請單一 agent 產生一份企劃，而是透過 commander agent 統籌，先理解工作區、確認限制，再把任務交給不同角色審視，最後整合成一份可審閱的遊戲企劃文件。

VS Code Custom Agent 使用指南

簡介

什麼是 Custom Agent？

Custom Agent 是 VS Code 中 GitHub Copilot Chat 的自訂代理設定。它可以讓你針對不同開發任務，預先定義 AI 應該扮演的角色、可使用的工具、模型偏好與工作流程，讓 Copilot 在切換到該 agent 後，以更貼近任務需求的方式回應。

內建 agent 通常適合一般用途，但實際開發時，不同任務會需要不同的行為模式。例如規劃階段可能只需要讀取與搜尋工具，避免 AI 直接修改檔案；實作階段則需要編輯工具；Code Review 階段又會更重視安全性、可維護性與測試覆蓋。Custom Agent 的價值就在於把這些設定整理成可重複使用的工作角色。

Custom Agent 會定義在 .agent.md Markdown 檔案中，可以放在工作區內與團隊共享，也可以放在使用者層級，讓你在不同專案中重複使用。

適合使用情境

• 規劃任務：建立只具備讀取與搜尋能力的 planning agent，用來整理需求、分析程式碼與產出實作計畫。
• 功能開發：建立 implementation agent，讓 AI 依照專案規範進行程式碼修改與測試。
• 程式碼審查：建立 review agent，專注檢查安全性、可讀性、錯誤處理與測試缺口。
• 專案特定流程：針對團隊內固定流程，例如產生測試、撰寫文件、維護 API 規格，建立可重複使用的 agent。
• 多階段工作流：透過 handoffs 在不同 agent 之間交接，例如從規劃 agent 交給實作 agent，再交給審查 agent。

使用 geojson.io 在 Google Maps 上建立地理柵欄

在開發需要「位置範圍判斷」的功能時，地理柵欄（Geofencing）是很常見的需求。例如：判斷玩家是否進入指定活動區域、確認使用者是否位於服務範圍內，或是根據所在位置觸發不同的互動內容。

如果直接在程式碼裡手動輸入經緯度，不但不直覺，也很容易因為座標順序或邊界不精準而出錯。這時候可以使用 geojson.io 先在地圖上畫出範圍，再把結果匯出成 GeoJSON，最後放到 Google Maps 裡顯示與判斷。

這篇文章會介紹如何使用 geojson.io 建立地理柵欄，並示範如何將 GeoJSON 套用到 Google Maps JavaScript API 中。

使用 VS Code 與 AI 協作開發遊戲的一個月心得

想更新一下最近使用 VS Code 開發遊戲的想法。

從零開始開發這個專案到現在，已經經過了一個月。這段時間我一直在摸索一套能和 AI 穩定協作的開發循環：如何把想法交給 AI、如何讓 AI 參與實作，以及如何避免它在錯誤的方向上越走越遠。