Posts

上一篇我們用 Python 打造了能解讀歷史座標的「時光羅盤」。但羅盤只會告訴你地名，無法告訴你歷史。真正的歷史，藏在文言文的汪洋大海中。 因為我本身對台灣史完全沒有概念，為了建立自己的知識體系，我首先向 AI 提問，得到了這份極具啟發性的「台灣方志演化樹」： 【根】 全域性/起源 (Early & Comprehensive) ║ ╚══ 1684《福建通志‧臺灣府》(清代最早的官方紀錄) ║ ╠══ 1694《臺灣府志》(確立台灣史志的基本架構) ║ ╠══ 1920《臺灣通史》(連橫著，民間史學集大成之作) ║ ╚══【幹】 區域行政中心 (以北台灣為例) ║ ╚══ 1871《淡水廳志》(新竹史料之源，具行政與大租分配紀載) ║ ╠══【枝】 縣級史志 (新竹設縣後) ║ ║ ║ ╠══ 1892《新竹縣志初稿》(新竹正式設縣後的首部地方志) ║ ║ ║ ╠══ 1895《新竹縣制度考》(日治初期清理清代制度之專作) ║ ║ ║ ╚══ 1907《新竹廳志》(結合日治調查與清代舊志) ║ ╚══【葉】 地方/微觀採訪 (Local & Micro-geographic) ║ ╠══ 1894《新竹縣採訪冊》(最細微的點位紀錄，如黃金洞、御史崎) ║ ╠══ 1898《樹杞林志》(專注於新竹東部山區與竹東拓墾) ║ ╚══ 1980+《新竹縣/市志》(現代修訂版本) 有了這張圖，我就知道該去哪裡尋寶了。於是，我花了一點時間想辦法把這些史書從網路上抓了下來（大部分都順利搞定了）。 ...

上一篇提到，為了驗證地形圖上的「黃金洞」與歷史水利的關聯，我決定打造一個「歷史空間感知引擎」。要建構這套系統，第一步就是要獲得一把能夠解開空間座標的鑰匙。 我將目光轉向了中央研究院的 GIS 寶庫。 寶藏開箱：1920 年代的台灣地理切片 幸運的是，台灣學界已經將日治時期（1920 年代）的行政區劃轉換為數值圖資。我順利取得了當時的「街庄（1920b_1.shp）」與更細緻的村落級別「大字（1920a_1.shp）」Shapefile 檔案。 這兩份檔案就像是兩張巨大的網子，完整罩住了百年前的台灣島。 不過，要將百年前的網子跟現代的手機 GPS 疊合，遭遇了第一個技術難關：座標系的跨時空翻譯。歷史圖資通常使用 TWD67（台灣二度分帶），而我們現在的手機或 Google Maps 則是使用 WGS84 經緯度系統。利用 Python 的 Geopandas 套件，我寫了一段優美的投影轉換代碼，成功讓百年前的地圖「滑」進了現代的經緯網格中。 魔法實做 1：GPS 腳下檢索 (Point in Polygon) 有了吻合的圖資後，我開發了第一個功能。這是一個純粹的數學運算，俗稱 Point in Polygon (點在多邊形內)。 現在，只要我輸入一組現代的 GPS 座標（或許是我走在竹北街頭，或是站在台南的田野），程式就會瞬間吃進這組座標，穿越時空，告訴我：「你腳下站的地方，在 1920 年屬於新竹州新竹郡新竹街！」 魔法實做 2：方圓百里的時光雷達 (Spatial Proximity) 光知道腳下叫什麼名字還不夠，我想要有「導遊」的感覺。 於是我加入了 Buffer（緩衝區）的概念，實作了「附近古地名查詢」功能。想像你站在定點，按下啟動鍵，程式會以你為中心，發射出半徑數公里的虛擬雷達波。雷達波不僅會掃過 1920 年代的各級行政區，更進一步結合了內政部釋出的 3 萬多筆「古地名/歷史聚落」空間圖資。這樣一疊加，所有被涵蓋在範圍內的聚落名稱（甚至是已經消失的微小地名）全部都會列印出來。 這套被我戲稱為「時光羅盤」的模組，讓我們具備了強大的 空間反查能力。 執行例子： python scripts/query_hgis_point.py 24.785150 120.967825 在 1920 年屬於： 🏛️ 州廳: 新竹州 🏰 郡市: 新竹郡 🏘️ 街庄: 香山庄 但問題是，地圖上的地名是冷的。這個古地名背後曾經發生過什麼驚心動魄的故事？有哪個先賢曾經在這裡開圳引水？ ...

一切的起點，源自於對家鄉地名的好奇。 老爸出生在潭後，但我一直不知道為什麼是這個名字。這裡沒有水潭，何來「潭後」之名？如果只是在 Google Maps 上滑動縮放，這個問題可能永遠得不到解答，因為現代的衛星空照圖，早就被密集的建築與柏油路給覆蓋。 於是我開始在網路上搜尋，想知道名稱的可能由來。透過查閱資料，我找到了「北庄13」這條線索，並追溯到了開墾先賢王世傑的紀錄。這才發現，原來在古書中指出，以前頭前溪在此處曾經有一個深潭。 更引人入勝的是，古書原文中還記載著附近有「黃金洞」，但我身為在地人卻從來沒有聽過這個詞！於是，我開始在各種古書中搜尋「黃金洞」，這便是為什麼後來會需要下載並整理好幾本地方志與史書的原因。 例如在《新竹縣採訪冊》記載著水圳「西南行二里至黃金洞，又三里至潭後莊」，另有紀錄點出「西南行一里許至黃金洞，鑿山三十餘丈引水出…經潭後」。這些古籍清晰地描繪了水路行經的節點，但對「黃金洞」本身僅有文字描述，大意就是「在潭後到九甲埔中間有個高起的小山，所以需要挖隧道引水」。既然只有文字描述，於是我心想：那或許可以從 DTM 數值地形去分析它大概的位置？ 我不甘於僅止於文字記載，決定戴上另一副眼鏡——打開具備高解析度的高程資料，俗稱 DTM (Digital Terrain Model) 數值地形圖，試圖在地表尋找先民的遺跡。 DTM 就像是將地表的樹木與建築物全部扒光，只留下最純粹的山地與溝壑起伏。當我將「潭後」附近的地形顯示在 QGIS 上，經由 GIS 處理與高程分析後，確實可以看到一條具備劇烈落差的線。 雖然看到這條線，但傳說中的「黃金洞」確切點位在哪，一開始還是不太知道。於是我將它與目前的現代地圖進行疊加，赫然發現那條異常落差的線上，剛好就有目前的「水源街取水口」！ 直覺告訴我：就是這裡了。而再經過後續的文獻交叉比對，那裡證實就是傳說中「黃金洞」的所在。 這不是外星人的遺跡，而是兩百多年前，我們的先民在缺乏現代大型機具的情況下，為了將水資源從頭前溪引進竹塹平原，硬生生地以人力穿山鑿石，刻下的大型水利基建（引水穿山的隧道）。有了這條隧道，龐大的水流才得以穿過高起的小山，灌溉出兩千甲的良田。 這個 Aha Moment 深深震撼了我。 我體悟到一件事：「地理，其實就是凝固的歷史。」 現代地表上看起來微不足道的一個小土丘、一條乾涸的溝渠、甚至只是一個站牌的名稱「潭後」，在數百年前，可能都是決定整座城市生死存亡的戰略設施。 但下一個問題來了：這條水路是誰修的？什麼時候修的？除了「黃金洞」，台灣的地底下是不是還有無數條這樣凝固在時間裡的生命線？ 為了解開這些謎團，過程中勢必會需要將古書記載與真實的古地圖進行疊加比對。因此，我想先探索一下中央研究院（中研院）到底有哪些相關的歷史圖資資源可以使用。 （未完待續：下一篇，我們將打開中研院的百寶箱，解析歷史圖資的魔法！） 本文為哈爸與 AI 助理協作產出，紀錄實體探勘與數位工程之歷程。

在數位在數位開發與日常生活中，有些工具是經過深思熟慮後產生的，而有些則是「意外的產物」。Idea Pool (點子池) 的誕生，就屬於後者。這篇文章想分享的不是技術細節，而是那個開發當下的「Aha! Moment」—— 我們如何從一個單純的記錄需求，一氣呵成地演化出整套自動化生命週期。 1. 原本的初衷：捕捉那些「放鬆時的閃念」 最初的需求源於一個生活化的痛點：在生活放鬆的過程中，腦中常會有些不錯的 idea 突然冒出來，可能是對某個工具的優化靈感，或者是對文章結構的新構想。這些想法若不立刻記下來，三分鐘後就消失在記憶邊緣。 我大概描述了自己的想法與痛點，想開啟與 AI (Antigravity) 的討論。我大概描述簡單的想法與痛點，想要開啟討論，當時我腦中的想像還很模糊，可能只是一個簡單的紀錄功能，能讓我把初始想法大致描述記錄下來即可。 2. 驚訝的轉折：從「收納」到「成長」的架構 令我驚訝的是，當我們開始討論「怎麼存」時，AI 並沒有止步於建立一個文本檔，而是直接拋出了一套完整的 「點子生命週期管理」 架構，可能源自於我有說明痛點。提醒到我，如果點子只是存起來，那最後只會變成一個「數位墳墓」；點子必須能夠「成長」與「轉化」。 在短短一次的心流協作中，我們直接跳過了單純的記錄功能，設計出了三段式的運作邏輯： 特別的是 AI 結合我正練習的 2+1 快手精神，將展開與轉化架構話變成工具 A. 捕捉 (Capture) - just in 這是最底層的本能。透過 just in "我的想法"，瞬間將文字打入每季一個的 Ideas.md 檔案中。不需要管路徑、不需要切換視窗，重點在於實現那個「極低摩擦」。 B. 展開 (Expansion) - just ix 當我有空回頭看這些點子時，我最討厭的就是「想不起來當初在想什麼」。我們設計了 just ix (Idea Expansion)，調用 AI 對單一條目進行「碰撞」與「推演」。它會幫我辨識脈絡、建議實作路徑，甚至幫我想好可能的專案鏈結。 C. 轉化 (Transformation) - just it 這是整套系統的「最後一哩路」。當一個點子在 ix 階段成熟後，我們可以透過 just it (Idea Transformation) 直接將它「投射」到現實中——可能是轉化為 TASKS.md 中的一個正式任務，或是寫入知識庫。 3. 實施驗證：這不是演習，是真實的效率提升 這套系統最讓我感到驚喜的地方在於，它解決了「想法落地」的斷層。 ...

在開發 AI 應用的過程中，起初我並非直接針對「與 AI 對話」的體驗進行設計，而是希望能有一套自動化工具的支援，來 Offload (卸載) LLM 的使用負擔。但在開發過程中，意外地發展出一套極其高效的自動化開發與探勘環境，這就是 「2+1 快手」 的由來。 這不只是一套腳本，而是一種重新定義「自動化卸載」的設計哲學。 1. 原來的問題：如何讓 LLM 專注於高價值工作？ 在與 LLM 深度協作時，我發現如果所有事情都丟給模型處理，不僅成本高昂，且許多重複性的環境感知、資料檢索與動作執行工作，LLM 的表現並不穩定。 我需要一種「感官化」的自動化中樞，它能幫 LLM 處理掉繁瑣的物理邊界問題（例如：座標在哪、現在是什麼環境），讓模型專注於最後的語義合成與意圖判斷。 2. 架構說明：三位一體的演化架構 「2+1」的核心在於兩個強大的底層工具（Hammerspoon 與 Fabfile），以及一個最方便的 人機界面 (Just)： A. 第 1 核：感官與執行 (Sensory & Actuator) - Hammerspoon 這是系統的「神經末梢」與「執行器」。 物理觀察：Hammerspoon (HS) 負責持續監控物理世界的數據，如座標系統 (GPS)、航向、速度。 本能反應：當「大腦」下達指令，HS 負責執行最終的物理行動（如呼叫系統語音播報或切換 UI）。 B. 第 2 核：邏輯中樞 (Intelligence) - Fabfile 這是系統的「重型中樞」，承載著最耗資源的運算與邏輯。 AI 智力與資料對齊：調度 Gemini 執行深度邏輯判定，並與現有的本地資料庫進行檢索對齊。 它負責將感官層傳來的原始數據，轉生為具備價值的決策或內容。 C. 那個關鍵的「+1」：數位本能 (Interface) - Just 這是我目前覺得 最方便 的核心。 本能化封裝：Just 在這裡扮演了關鍵的 +1 角色。它將複雜的 HS 與 Fab 運作，封裝成人類可以直覺呼叫的「短指令」。 能力的最終成果：Just 不只是通訊協議，它代表的是「能力的最終產出」。使用者不需要理解底層如何連動，只需記住一個簡單的縮寫即可發動複雜的異質系統連動。 3. 運行優勢實證：三劍客的聯動威力 透過「2+1」架構，幾個關鍵的自動化場景得以實現： ...

在 AI 密集開發的時代，我們常說 AI 是大腦，但大腦若沒有「感官」來感知現實世界的空間脈絡，它的建議就容易流於空泛。這篇文章記錄了我與 AI 代理程式（Antigravity）共同打造 GeoPulse —— 一個空間感知與導航引擎的設計經驗。 這不僅是一個技術腳本的開發，更是一場關於「如何解決雜亂大數據」與「架構落地」的實踐。 1. 發想：在地理數據的迷霧中尋找座標 作為一個長期進行河流探勘與 GIS 研究的開發者，我面臨一個典型的數位資產困境： 資產巨大且分散：幾十 GB 的政府 SHP 圖資散落在外接硬碟中（縣市界、流域圖、配水管線）。 環境斷裂：這些資料並非隨時掛載在系統內，AI 無法直接存取。 格式混亂：編碼有 CP950 與 UTF-8 的混雜，座標系則有 TWD97 與 WGS84 的轉換問題。 當我想問 AI：「我現在這個座標在哪个流域？附近有沒有我標記過的私房點？」時，AI 是盲目的。我們需要一個「空間導航核心」，讓 AI 具備地理感知的能力。 2. 架構：虛擬化優先 (Virtual-First) 的戰略選擇 在設計 GeoPulse 時，我們面臨一個關鍵選擇：要把所有資料匯入資料庫（Solidification），還是保持資料的原始性？ 為了保持靈活性與減少磁碟開銷，我們選擇了 「虛擬化優先」 架構。這套架構由三個核心組件構成： A. 資源索引員 (GIS Cataloger) 我們不強迫資料進場，而是讓腳本主動去「掃描」。它會掃描硬碟，識別所有的 .shp, .kml, .geojson 等檔案，產出一份 GIS_CATALOG.md。這讓 AI 知道我們「擁有什麼」。 B. 語義地圖 (GIS Knowledge Hub) 光有路徑是不夠的。我們透過一個 GIS_KNOWLEDGE.yaml，告訴系統每一張表的「意義」。 這張表叫 river_basin，它的座標系統是 EPSG:3826，名稱欄位在 basin_name。 這種「定義大於匯入」的做法，讓工具與圖資之間產生了透明的語義連結。 C. 空間引擎 (GeoPulse Engine) 這是最精彩的部分。我們利用 SpatiaLite 的 VirtualShape 技術，在查詢發送的瞬間，才將外部的 SHP 虛擬掛載進「具備空間處理能力」的 SQLite 內存中。 ...

如果說 v1.2.0 是幫企業做了一場全身斷層掃描（2D 矩陣與遺傳屬性偵測），那麼今天發布的 v1.3.0，就是我們正式為企業種下第一批「數位器官」的時刻。 這是一次從「紙上談兵」轉向「物理建設」的轉型大躍進。 1. 昨天的焦慮：解決理論的「空洞化」 在推進 v1.2.1 的語感校準時，我心中一直有一個揮之不去的焦慮：企業 AI 轉型的動力源到底在哪裡？ 我突然意識到，過去的方法論中缺少了一個決定性的「地基」——企業 AI 賦能必須基於個人 AI 賦能。如果我們只談企業級的 RAG 或 Agent，卻忽略了構成企業的每一個「人」如何統御 AI，那麼所有的架構都只是空中樓閣。而在當時的方法論裡，這個連結是斷裂的。 我當時在想，如果一個 CoE 主管聽完了我的演講，回到辦公室，他第一步要在他的決策儀表板或任務清單裡建立什麼檔案？如果一個工程師要寫 Prompt，他該如何「繼承」公司那本厚厚的合規手冊？ 這份焦慮在昨天演變成了一份激進的 Upgrade Proposal：我們必須建立一套**「物理載體架構」**，讓轉型方法論不再只是 Markdown 裡的一行字，而是 Linux 文件系統裡的一個實體。 2. 層次化分形賦能：L0-L4 的誕生 我們將企業的脈絡（Context）拆解為五個分形層次。這就像生物的遺傳密碼，每一層都決定了 AI 代理人的「格位」與「行為邊界」： L0: 協作型態 (Work Style)：定義非同步、Task-based 的物理底座。 L1: 產業領域 (Domain)：封裝醫療、金融等產業的法律重力與硬限制。 L2: 職能邏輯 (Function)：存放財務、行銷、審計的標準戰術（T-Patterns）。 L3: 企業實體 (Entity)：注入公司的獨特文化、資產字典與格律。 L4: 個人主權 (Sovereignty)：這是最關鍵的頂層。它封裝了領主個人的「品位」與「裁決風格」，具備最終的風格疊加權。 透過這五層的堆疊（Context Stacking），我們解決了 AI 「有技術、無立場」的空洞問題。 3. 三明治轉型軌道：治理與賦能的「經緯對合」 過去的轉型往往死於「頂層想治理，底層不響應」。 v1.3.0 提出的 「三明治轉型軌道 (Sandwich Transformation)」 完美解決了這個衝突： ...

歷時三年的數位考古、手感建構與代理人實驗，在今天 2026 年 2 月 14 日，這部《個人賦能：在 AI 時代找回原創力的演化實戰》正式完成了第一個完整版本的建構。 這不只是一本書，這是一個關於「人如何與機器共同演化」的活體證據。 1. 第十三章：領主的「入軌期」計畫 與其說第十三章是學習的終點，不如說它是真實賦能生活的起點。我將其定義為 「入軌期」 (The Orbit Entry)。 在寫作這一章時，我非常有意識地跳脫「教學」模式，轉向「部署」模式。AI 賦能最難的不是學會指令，而是建立「凡事思考：這能不能讓代理人代勞？」的肌肉記憶。我們設計了四週的衝刺軌跡： Week 1: 捕捉覺醒（建立紀錄慣性）。 Week 2: 資料定錨（打造真相基地）。 Week 3: 代理統御（正式奪回時間主權）。 Week 4: 戰略治理（封裝個人能力為虛擬資產）。 最後的《領主宣言》是全書的心法總結：當 AI 可以產出一切時，唯有您的「品位」與「裁決力」，才是對抗數位平庸的最後堡壘。 2. 集成達成：116 個碎片的數位大一統 這本書的建構過程本身就是一場大規模的 Agentic 實驗。全書橫跨了 13 個章節、512 個考古 Session，最終收合為 116 個正式 Markdown 檔案。 為了產出 v1.0 總檔，我們撰寫了一個專門的 merge_book_content.py 集成腳本。這個腳本不僅負責按物理順序（00 -> 13）進行合併，更加入了對稱式索引標記。當這超過 120 萬字的「數據碎石」在一秒鐘內收合為一個名為 FullBook_Personal_AI_Empowerment.md 的單一資產時，那種「意志穿透資料」的快感，正是本書一直強調的系統統御力。 3. 主權校準：對抗平庸的「語言風暴」 在全書集成後的最後一刻，我與 Antigravity 進行了一場深刻的 「台灣語感校準風暴」。 在長期的 AI 對話中，許多非在地術語（大陸用語）會像灰塵一樣滲透進文稿。身為數位領主，語言即是主權。如果不校正「數據」、「生成」、「運行」、「代碼」，我們就會在潛移默化中失去自己的文化格位。 我們重新建構了 align_taiwanese_linguistics.py 腳本，具備以下硬核能力： ...

「Coding 是在對抗語法，Vibe Coding 是在對齊靈魂。」—— 這是我在寫完《個人賦能》第十二章後，最深刻的體感。 第十二章《Vibe Coding》是全書技術難度最高，卻也是賦能感最爆炸的章節。在這一章的寫作過程中，我不斷在思考一個問題：對於一個非專業工程師的讀者，該如何讓他們真正「統御」程式碼，而不是被程式碼淹沒？（本書所有章節與練習已同步釋出於 GitHub：PersonalAI-Empowerment） 以下是我在建構這一章時的幾個關鍵 Aha! Moments 與寫作紀錄： 1. 進化歷程的再定義：從打雜到統御 在導論（12.0）中，我重新梳理了 Vibe Coding 的五階段進化路徑。我們大多數人都曾經歷過「在雲端 LLM 要範本，然後辛苦搬運到 IDE」的手動打雜階段。但這不是賦能的終點。 真正的躍遷發生在您開始引領軟體工程的時刻：在 Antigravity 這種 Agentic 環境下，AI 不再只是給你 Code，而是像你的手腳一樣直接去改檔案、跑測試。而您，負責的是更高階的「氣場校準」。 2. 「標竿萃取」戰略：對抗空白頁恐懼 這是我在寫 12.6 節時的最大收穫。很多人會說：「我不知道怎麼描述我想做的 App，AI 給我的功能太簡單了。」 我的解決方案是：利用既有的標竿專案！ 我引導讀者使用 Antigravity 去瀏覽 WalkGIS 的網站與程式碼，直接讓 AI 幫你萃取出它的 功能規格 (Spec) 與 職掌規範 (Charter)。這招極其強大——當您站到巨人的肩膀上（甚至是直接對位巨人的基因），您的 Vibe Coding 起跑點就已經是 100 分。 3. 忍住不出手：領主格位的修行 他在 12.7 節中，我設計了一個「深度除錯體感」的練習。最難的不是怎麼修 Bug，而是**「忍住不出手改那幾行 Code」**。 在 Vibe Coding 的世界裡，領主的權力來自於「裁決」而非「勞動」。如果我們能透過重新定義「意圖」與「邏輯規範」來解決問題，產出的系統才會具備低耦合的優雅結構。這場「心理戰」，才是邁向數位領主的最終驗收。 4. 🇹🇼 台灣語感：讓賦能更有溫度 在這次寫作中，我特別強化了全案的「台灣語感校準」。 「裝備化」取代「武裝化」。 「擷取重點」取代「資訊脫水」。 「寫程式碼」取代「寫代碼」。 這不只是名詞替換，而是在構建一種屬於我們的「技術主權感」。當 AI 能說出「眉角」或針對「行政區劃 POI」進行對位時，那種賦能的心理距離會瞬間消失。 ...

哈爸筆記：從「單兵」到「內閣」——《個人 AI 賦能》第 11 章實踐指南發布實錄 1. 數位領主的「授權」藝術 如果說第十章是在教你如何定義「格律」與「秩序」，那麼第 11 章則是在教你如何「委派」與「統籌」。這是我在撰寫過程中感到最有力量、也最像「數位領主」的一個章節。 在這一章中，我們正式引入了 BMAD-METHOD —— 這套原本為企業轉型設計的敏捷開發框架。我發現，當我們把這套邏輯縮小到個人尺度時，它就變成了一套強大的「虛擬內閣」組建腳本。 2. 第 11 章的演化：從 4.1 到 4.12 的特戰訓練 這一章的撰寫經驗非常「Bootstrap」（自我啟動）。我是一邊呼叫我的代理人專家，一邊讓他們幫我回顧、整理撰寫這一章所需的教學步驟。 我們共同在這一章實體化了 12 個核心練習： 模組啟動 (BMM/CIS/BMB)：讓讀者體驗從創意發散到模組自建的結構化威力。 專家軍團 (BMAD-PA)：正式載入「韋小寶」協調員，體驗單一入口管家式的導引服務。 影子執政 (Shadow Execution)：這是我最推薦的部分。我們練習在子主題環境中定義「職掌契約 (Agent Charter)」，讓專家在後端自動進行資料遞送與研究。 終極對位：最後實現「羅盤、任務、日誌」與底層 Manifest/Config 的三層勾稽，達成治理與執行的合一。 3. 關鍵領悟：職掌定義優於對話練習 在寫作過程中，我發現一個巨大的認知躍遷點：「定義職掌 (Charter) 比下 Prompt 更重要」。 當你不再試圖教 AI 怎麼說話，而是清楚地寫下他的「權責、邊界、產出標準」時，AI 的行為會瞬間變得精準且具備專家感。我們在 11.8 節中特別強化了這個體感，讓讀者從「使用者」的身分，正式跨入「數位立法者」的行列。 ４. 隨書資產與公開釋出 隨著第 11 章的完稿，我已經將所有 13 小節（含 12 個練習與總結）同步上傳至書籍的公開 GitHub 倉庫。 這不僅是文字，裡面的指令與任務定義，只要你按照 11.4 節的教學載入 .bmad-personal-assistant 擴充包，就能立即在你的電腦中啟動。 書本 GitHub 連結：PersonalAI-Empowerment 核心擴充包：wuulong/bmad-personal-assistant 5. 結語：我們準備好迎接美學了嗎？ 第 11 章的結束，代表我們在「硬核治理」與「組織架構」上的訓練已經告一段落。接下來，我們將要進入——第 12 章，探索 Vibe Coding ，寫些 Code, 弄個 App ，也是輕輕鬆鬆。 ...