用 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 參與實作，以及如何避免它在錯誤的方向上越走越遠。

客製化 Google Map 樣式完整教學

Google Maps 是目前最廣泛使用的地圖服務之一,但預設樣式對於追求設計感或特殊主題的網站(例如遊戲、品牌官網、資料視覺化儀表板)來說,往往略顯單調。所幸 Google 提供了完整的樣式自訂機制,讓開發者可以透過 JSON 設定檔調整地圖上每一項元素的色彩、可見度與標籤呈現方式。

本文將介紹兩個最常被使用的工具:官方推出的 Google Maps Styling Wizard,以及社群維護的 Snazzy Maps,並說明如何將樣式套用到實際的網頁中。

為什麼要客製化地圖樣式

預設的 Google Maps 配色雖然中性,但在某些情境下會帶來干擾:

• 遊戲或互動體驗:需要突出地圖上的角色、任務點或路線,過多的 POI(興趣點)反而會分散注意力
• 品牌一致性:希望地圖配色與網站主視覺(Logo、主色調)融合
• 深色模式:夜間瀏覽情境下,亮色地圖會造成眩光
• 資料視覺化:在地圖上疊加大量標記或熱力圖時,需要降低底圖的視覺權重

透過樣式設定,你可以隱藏不需要的元素、調整配色,甚至打造復古、科幻、極簡等各種風格主題。

從零開始導入 Google Maps API

簡介

什麼是 Google Maps API？

Google Maps API 是 Google 提供的網頁地圖服務，讓開發者能在自己的網站或 Web App 中嵌入互動式地圖。除了基本的地圖顯示外，還支援標記（Marker）、路線規劃、街景、自訂樣式等豐富功能,是製作 LBS（Location-Based Service）應用、店家定位、地圖小遊戲等常見專案時的首選方案。

本文以最精簡的範例,示範如何取得 API Key、建立第一張可運作的地圖,並透過 importLibrary() 動態載入新版地圖函式庫。

適合使用情境

• 需要在網站中嵌入互動式地圖的應用
• 開發以地理位置為基礎的小型專案或 Game Jam 作品
• 想體驗 Google Maps 新版動態載入 API（importLibrary）的開發者
• 需要使用 Cloud-based Map Styling（雲端地圖樣式）的專案