從羅盤排盤到可審計空間決策：玄空地圖工作台的多源地理資料融合、排龍計算與人機協同設計

文章類型：研究論文／系統設計與技術驗證報告
系統版本：xk-autodragon 0.1.0；app 20260421e；algorithm pailong_v4_five_auspicious_palace_coverage
評審狀態：內部技術稿；尚未經獨立同行評審或實地效度驗證

研究聲明：本文評估的是系統在既定規則下的結構一致性與可審計性，不以程式測試證明傳統術數的現代科學因果效力，也不以線上圖資替代現場測量與專業判斷。

摘要

傳統玄空風水的數位工具多由羅盤讀數或人工輸入坐向開始，再輸出二十四山與飛星盤。這種模式能加快排盤，卻仍把地址定位、周邊道路判讀、建築輪廓辨識、水口選擇、立向測量及流派規則核對留給使用者在多個工具之間完成。本文以「玄空地圖工作台」原型為研究對象，採用設計科學研究取向，說明一套把多源地理資料、幾何計算、排龍矩陣、玄空飛星與可解釋候選排序連成同一工作流的方法。

系統從地址或地圖點位出發，整合 OpenStreetMap／Overpass 道路與建築資料、Overture Maps 建築輪廓，以及 Google Geocoding API v4 SearchDestinations 可提供的建築外框、入口與導航點。道路交會與轉折被視為「水口候選代理」，依距離、道路級別、結構、連通尺度、方向可見度及道路數量排序；建築向首與入口則由建築邊界、鄰近道路和平行／朝向關係推定。其後，系統把真北方位、磁偏角修正、二十四山十五度分區、十二宮排龍、下卦／替卦與九宮飛星分開記錄，再以可展開的分項權重產生候選立向排序。使用者可覆寫水口與坐向，並在介面中核對原始度數、資料來源、算法版本及中間結果。

本文對當前版本進行的是結構與一致性驗證，而非風水效能驗證。驗證涵蓋 36,000 個百分之一度方位樣本、24 個水口山中心、180 年三元九運週期、432 組宅盤組合，以及合成道路／建築情境。所有已定義的結構性不變量均通過：方位完整落入二十四山、每一排龍矩陣含十二宮與五個吉星宮、九個運期各含二十年、每個宅盤的三組九星排列均為 1 至 9 的全排列，合成南向臨路建築亦回傳 180° 向首。然而，這些結果只能證明程式在既定規則下可重複且內部一致，不能證明傳統術數的現代科學因果效力，也不能替代現場羅盤、地形、水文、入口使用狀況與專業判斷。

本文認為，該原型的主要創新不在於宣稱創造新的風水理論，而在於四項系統工程轉變：由單點排盤轉為空間情境分析；由黑箱結論轉為證據鏈審計；由單一資料源轉為帶來源標記的多源融合；由自動裁決轉為可覆寫、可追溯的人機協同。此設計可作為數字堪輿、文化知識計算化與專業服務治理的研究基礎，但下一階段仍需建立去識別化實地樣本、專家間一致性基準、角度誤差與 Top-k 命中率指標，並對啟發式權重做敏感度與校準研究。

關鍵詞：玄空風水；地理資訊系統；排龍；玄空飛星；二十四山；多源地理資料；可解釋決策支援；人機協同；數字人文

Abstract

Most digital Xuan Kong tools begin with a compass reading or a manually entered orientation and then generate a Twenty-four Mountains or Flying Stars chart. The Xuan Kong Map Workbench prototype extends this workflow by joining geospatial context acquisition, road-network-based water-mouth candidate generation, building-footprint and entrance inference, Pai Long computation, Flying Stars charting, and explainable orientation ranking in one auditable pipeline. Following a design-science approach, this paper documents the artefact, its rule boundaries, and a reproducible structural verification.

The current verification covers 36,000 bearing samples at 0.01-degree intervals, 24 water-mouth mountain centres, a 180-year period cycle, 432 house-chart combinations, and synthetic road/building scenarios. All defined software invariants passed. These checks establish deterministic consistency under the encoded rules; they do not validate the real-world efficacy of feng shui, field accuracy of third-party data, or causal effects on occupants. The system's principal contribution is therefore an integrative and governance-oriented one: it moves from isolated chart calculation to contextual spatial analysis, preserves data and rule provenance, exposes intermediate scores and degree boundaries, and keeps manual expert correction inside the workflow. Field validation, inter-rater studies, error calibration, and sensitivity analysis remain necessary.

Keywords: Xuan Kong feng shui; GIS; Pai Long; Flying Stars; Twenty-four Mountains; geospatial data fusion; explainable decision support; human-in-the-loop systems

1. 研究定位與問題意識

風水既可被研究為歷史形成的空間知識、建築文化與實務傳統，也常被市場包裝為具有確定因果效果的預測工具。兩者必須區分。既有研究已使用 GIS、空間回歸、遙感或景觀特徵模型來整理與比較風水相關的空間概念，例如墓葬選址、山水景觀和文化遺產特徵；這些工作說明傳統空間語彙可以被形式化、測量與比較，但不等於所有流派判斷已獲現代科學驗證。[1][2][3]

本文聚焦的是一個資訊系統問題：當專業使用者要從「某一地址」走到「可核對的水口、建築與立向判斷」時，如何減少資料在地圖、羅盤、排盤表與人工筆記之間反覆搬運，同時避免自動化把假設偽裝成確定事實？

據此提出四個研究問題：

1. 如何把道路、建築輪廓、入口資訊與傳統方位規則放入同一可重複的計算流程？
2. 如何保留真北／磁北、原始度數、二十四山邊界、資料來源與算法版本，使結果可回查？
3. 如何讓自動候選縮小人工核對範圍，而不取代實地測量與流派判斷？
4. 在尚未建立實地效度資料集之前，哪些結論可以由程式結構驗證支持，哪些只能標為假設或未驗證主張？

2. 相關工作與產業缺口

設計科學研究把可運作的資訊系統視為研究產物，強調問題界定、目標、設計開發、展示、評估與傳播。[4] 本文依此將玄空地圖工作台視為「可檢驗的設計產物」，評估重點首先是規則是否一致、計算是否可重複、輸入輸出是否可追溯，而不是以系統存在本身證明其文化判斷正確。

公開產品頁面顯示，現有專業或消費級工具常見能力包括二十四山、下卦／替卦、飛星盤、羅盤感測、平面圖疊加、報告輸出及客戶檔案。[5][6][7] 這些頁面不是完整市場普查，不能用來宣稱某項功能「全球首創」；但它們可作為產品重心的公開樣本。相較之下，本原型的研究重點是把排盤之前的空間資料取得、候選生成和排盤之後的證據審計納入同一流程。

在學術端，GIS 與風水／山水文化的結合已有先例。[1][2][3] 本系統的增量貢獻並非首次把 GIS 與風水並置，而是把「多源線上地理資料—道路與建築幾何—傳統規則引擎—候選排序—人工覆寫—審計介面」實作為面向個別建築的連續工作流。

3. 研究方法與證據分級

3.1 方法

1. 程式構件盤點：檢視 13 個 Python 模組、11 個 API 端點與地圖工作台前端，整理輸入、計算、回傳欄位與版本標記。
2. 規則鏈重建：由程式常數與函式建立從方位、二十四山、十二宮、排龍矩陣到飛星宅盤的轉換鏈。
3. 結構驗證：以可重跑腳本檢查角度分區、對宮關係、週期、九星排列、候選數量、排序界限及合成幾何情境。
4. 限制審查：把程式內部一致性、第三方資料精度、傳統規則正確性與現實效果分開，不以較低層級證據替代較高層級結論。

3.2 本文採用的證據層級

此分級沿用環球風水協會《學術與研究治理規範》的原則：來源、證據層級、方法限制和責任必須清楚標示。[8]

4. 系統架構

4.1 從地址到審計結果的工作流

系統以地址搜尋或地圖選點為入口，依次完成：

目標定位 → 周邊道路／建築資料取得 → 水口候選生成或人工指定 → 選定水口後批量分析建築 → 建築輪廓與向首／入口推定 → 排龍矩陣 → 坐向兩點量測或人工覆寫 → 下卦／替卦飛星盤 → 候選立向排序 → 度數與來源審計。

這個順序刻意把兩條測線分開：排龍使用「建築中心至水口」方位；飛星使用「建築坐向」方位。介面分別顯示兩者，避免把水口方向誤當作宅向。

4.2 多源地理資料層

系統可讀取 GeoJSON 點、線與多邊形。GeoJSON 的標準座標參考系為 WGS 84，座標以十進制度表示；RFC 7946 同時提醒，座標小數位數不能直接解讀為精度或不確定度。[9] 這一提醒對本系統尤為重要：地圖顯示很多小數位不代表現場方位已達同等精度。

• OpenStreetMap／Overpass：提供道路網與建築要素；OpenStreetMap 資料採 ODbL，公開呈現與衍生資料使用須保留適當署名與授權說明。[10]
• Overture Maps Buildings：補充建築外框、類別、名稱與來源記錄；其建築規格包含 geometry、class、subtype、sources 等欄位，且單一建築可能融合多個上游來源。[11]
• Google Geocoding API v4 SearchDestinations：可回傳建築 displayPolygon、entrances 與 navigationPoints；系統用其作為選定建築或範圍掃描的補充資料，而非默認真值。[12]

資料合併時保留主要來源、來源提供者及補充來源標記。這使使用者能區分「OSM 建築」「Overture 補充建築」與「Google 探測所得建築」，也為未來按來源計算缺失率與誤差提供條件。

4.3 局部平面投影與方位

道路與建築在小範圍內被轉換為以米為近似單位的局部平面座標；跨點方位則可使用球面初始方位公式。系統定義北為 0°、東為 90°，並將任意角度正規化至 [0°, 360°)。真北轉磁北採用：

磁北方位 =（真北方位 − 磁偏角）mod 360°

其中磁偏角 δ 由使用者輸入。當前版本不自動取得時地相依的磁偏角，因此輸入值、日期和來源應由使用者保存；若 δ = 0，輸出只代表未做磁偏修正。

4.4 水口候選：把道路結構當作可審查代理

當前演算法不是水文模型。它從道路線網中找出兩類幾何節點：道路交會點與轉折角達門檻的彎折點，合併相近節點後排序。候選總分為：

S_w = 0.20D + 0.22R + 0.18T + 0.15L + 0.08V + 0.10N + 0.07C

其中 D 為距離分數、R 為道路級別、T 為交會／彎折結構、L 為連通線段尺度、V 為方向可見度、N 為相連道路數、C 為候選類型。系統預設轉折門檻為 35°，距離分數隨候選遠離目標而降低。

因此，更嚴謹的名稱是「基於道路形態的水口候選代理」。道路交會可能與傳統水口判讀相關，也可能完全無關；河流、地勢、排水、橋涵、視線、封閉社區道路與現場出入口均可能改變判斷。設計上保留候選清單與人工指定，就是為了防止第一名分數被誤解為客觀水口。

4.5 建築向首與入口推定

對每一建築多邊形，系統計算質心、各邊長度、邊線方向和質心指向邊中點的外向方位，並把每條邊與鄰近道路比較。道路匹配分數為：

S_r = 0.40P + 0.30D_r + 0.20F + 0.10R_c

其中 P 為建築邊與道路的平行程度，D_r 為距路分數，F 為立面朝路程度，R_c 為道路級別。立面總分為：

S_f = 0.35L_e + 0.65S_r

其中 L_e 是相對邊長。入口候選再組合立面證據、向路對齊、邊上居中程度與距路分數：

S_e = 0.45S_f + 0.30A + 0.15C_e + 0.10D_e

這套方法能為規整、沿街建築提供合理初判，但長邊不一定是主立面、主入口也不一定居中；商場、轉角樓、裙樓塔樓、園區多入口與歷史建築尤其容易偏離。Google 入口或導航點可作補充核對，仍須以現場實際使用狀況確認。

4.6 排龍與玄空飛星的規則分離

二十四山每山寬 15°，以半開區間處理邊界，避免同一方位同時落入兩山。建築中心至水口的觀測方位加 180° 得到來龍方向；水口山依陰陽設定順逆，再把十二步星序放入十二宮。當前規則把右弼、武曲、貪狼、左輔與巨門五類標為吉星，因而每一排龍矩陣形成五個候選宮、十個候選坐山。

飛星模組與排龍模組分離。宅盤接受運期、坐山與盤式，輸出運盤、山盤、向盤及九宮格；盤式可為挨星下卦或挨星替卦。三元九運以 1864 年為 180 年週期起點，每運二十年。系統也能依建造、入住或翻修年份選擇運期，但這些年份的術數含義屬流派與實務判斷，不應由軟體自行替使用者決定。

4.7 候選立向排序與缺失資料處理

候選立向總分由五項構成：排龍星優先 35%、立面證據 25%、入口證據 15%、水口證據 15%、盤式信心 10%。若某項證據缺失，系統會在剩餘項目間重新正規化權重，而不是把缺失值當成零分。每個候選均保留原始分數、套用後權重、分項貢獻、度數區間與對應證據。

這些權重是工程啟發式，不是由已標註樣本訓練或校準得出。因此排序只能解讀為「依當前規則值得優先核對」，不能解讀為成功機率、吉凶概率、投資價值或健康風險。

5. 結構驗證與結果

5.1 驗證範圍

1. 二十四山覆蓋與邊界；
2. 平面與球面基準方位；
3. 180 年九運週期；
4. 二十四個水口山中心的排龍矩陣；
5. 九運 × 二十四坐山 × 兩種盤式的宅盤；
6. 合成建築與道路的向首、入口和水口候選；
7. 候選排序範圍、順序與權重正規化。

5.2 結果

5.3 結果應如何解讀

這些檢查證明「輸入相同時，程式依已編碼規則產生一致且結構完整的結果」。它們沒有回答三個更高層次問題：道路代理是否等同現場水口、演算法推定向首與專家現場量向相差多少、依此產生的傳統判斷是否對居住或經營結果有因果效力。後三者需要獨立樣本、盲評、現場基準與適當研究設計，不能由單元或結構測試推論。

6. 創新性分析

6.1 由「排盤器」轉為「情境式空間工作台」

傳統數位工具常把坐向視為已知輸入。本系統把坐向形成之前的地址、道路、建築、水口與入口納入分析，因此服務對象從單一排盤動作擴展為完整的前期勘察流程。這是工作流層面的整合創新，不是對傳統理論本身的重新發明。

6.2 由「給答案」轉為「展示證據鏈」

系統同時保留原始真北方位、磁偏修正、落山區間、宮位、星序、資料來源、分項權重與算法版本。使用者可查看「為何被排在前面」，也能定位分歧來自資料、度數邊界、盤式還是流派規則。對專業服務而言，可回查比單純自動化更具治理價值。

6.3 多源資料的互補而非混同

OSM 適合取得可查詢道路與社群建築資料，Overture 可補充大規模建築輪廓與來源鏈，Google SearchDestinations 可補充建築外框、入口及導航點。系統保留來源分類，使不同覆蓋率與授權條件不被抹平。這為日後做來源別準確率比較提供了基礎。

6.4 自動候選與人工裁決並存

系統容許手動指定水口、覆寫坐向及在地圖上做兩點量向。人機協同不是過渡缺陷，而是對問題性質的正面回應：建築主立面、實際入口與傳統水口均可能依現場使用和流派而異，自動化最適合縮小候選空間、呈現一致計算，不適合假裝消除所有歧義。

6.5 傳統規則的版本化

把流派規則寫成程式會暴露以往容易被口傳掩蓋的細節：邊界是否含端點、真北或磁北如何轉換、何時用下卦或替卦、缺資料時如何處理。版本號和規則標識使更正、比較與回溯成為可能，也便於不同傳承建立平行規則集，而非把單一實作誤稱為唯一標準。

7. 產業價值與適用場景

• 前期篩查：在大量候選建築中先找出值得實地核對的少數對象，降低重複排盤和資料搬運。
• 專業勘察輔助：把地址、地圖、兩點量向、水口選擇、排龍與飛星放在同一案件脈絡，方便現場前後比對。
• 教學與傳承：讓學員看到同一度數如何落山、入宮、飛布與進入排序，並比較人工覆寫前後差異。
• 研究資料基礎：在取得同意並去識別化後，累積「機器候選—專家修正—現場基準—最終判斷」資料，為未來可靠性研究提供結構化記錄。

可能的商業價值是提高資料整理與初判效率、增強報告一致性和客戶溝通透明度；但本文未做工時對照、用戶研究或付費轉化實驗，故不報告節省比例、準確率或收入提升。

8. 限制、風險與治理要求

1. 沒有實地金標資料。目前沒有足夠樣本比較系統候選與多名專家現場判斷，不能報告準確率、召回率或專家一致性。
2. 道路不是水文。目前水口候選主要來自道路交會與彎折；未整合高程、河網、排水方向、地形遮擋與現場視線。
3. 建築外框不是使用事實。圖資可能過時、缺失或合併錯誤；幾何主立面不一定是實際納氣面，標記入口也不一定是常用主入口。
4. 角度誤差可能跨界放大。二十四山邊界附近，小幅圖資、投影、磁偏角或現場量測誤差可能改變落山與盤式。介面應對臨界方位顯示警示和不確定區間。
5. 權重尚未校準。水口、立面、入口與候選立向權重均為啟發式；數值透明不等於數值已被實證支持。
6. 流派適用範圍有限。本版本實作特定排龍矩陣與中州派飛星流程，不代表三合、八宅、其他玄空傳承或所有實務共識。
7. 第三方資料與服務限制。不同地區覆蓋率、API 階段、配額、服務條款和授權均可能變動；發布地圖、截圖或衍生資料時須逐項履行署名與使用條款。
8. 隱私與專業邊界。精確住宅位置、出入口、客戶姓名與勘察記錄可能構成敏感資料；公開研究應去識別化，不得把風水工具用作醫療、心理、法律、財務或安全判斷的替代品。

9. 後續研究計畫

9.1 建立分層實地資料集

至少記錄建築類型、圖資來源、城市密度、現場主入口、專家量得坐向、水口判斷及理由；位置公開前做空間模糊化，研究原始資料則採權限與保留期限管理。商場、獨立住宅、塔樓、園區和鄉郊建築應分層抽樣。

9.2 定義可被否證的指標

• 向首角度平均絕對誤差與 95% 誤差分位數；
• 水口候選 Top-1、Top-3、Top-5 命中率；
• 建築入口點到現場主入口的距離誤差；
• 系統與專家、專家與專家之間的一致性；
• 來源別覆蓋率、缺失率和錯配率；
• 邊界 ±1°、±2°、±3° 擾動下的落山與排序穩定性；
• 權重變動對 Top-k 排序的敏感度。

9.3 採用盲評與預註冊

專家評審應在看不到系統排名時先獨立標註，再比較候選；資料排除、缺失處理、成功指標與分析方法應預先登記。這能減少事後選擇有利案例的風險。

9.4 建立規則與結果版本治理

每份報告應保存程式版本、算法版本、資料取得日期、來源、半徑、磁偏角、人工覆寫和更正記錄。若規則更改，舊報告不得無記錄重算。不同流派可使用獨立規則識別碼並列比較。

10. 結論

玄空地圖工作台展示了一條比「把羅盤搬上螢幕」更深入的數位化路徑：把地址、道路、建築、水口代理、坐向、排龍、飛星與候選排序連成可審計的空間工作流。其現階段最可靠的成果，是把隱含規則變成可重複計算，把中間假設攤開，把自動化限制在候選生成與一致運算之內，並保留專業人員覆寫與負責的空間。

結構驗證表明，當前版本在二十四山分區、排龍矩陣、九運週期、飛星盤排列與排序正規化上保持內部一致；但這不是實地效度或現代科學效能證明。若後續能以去識別化樣本、盲評、誤差指標、敏感度分析和版本治理補足證據，該系統有潛力成為數字堪輿研究、專業教育與負責任服務流程的共同基礎設施。

參考資料

1. Um, J.-S. (2009). Exploring spatially prioritized parameters of Feng-Shui from tomb footprint. International Journal of Geographical Information Science, 23(4), 513–529. DOI.
2. Zhao, Y., Harvey, D. C., & Gao, C. (2020). Identifying Shan-Shui characteristics for national landscape heritage. The Geographical Journal, 186, 300–313. DOI.
3. Cui, J., Liu, Y., Sun, J., Hu, D., & He, H. (2021). Study on Feng Shui (Geomantic) Suitability Evaluation of Mausoleums in Nanjing City Based on GIS. ISPRS International Journal of Geo-Information, 10(11), 752. DOI.
4. Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 24(3), 45–77. DOI.
5. QiPlus. Qi+ Feng Shui Software — Features. 產品頁面.
6. Feng Shui Magazine Ltd. FSML Professional Feng Shui Software Tool. 產品頁面.
7. Google Play. Flying Stars Feng Shui — App listing. 應用程式頁面.
8. 環球風水協會（2026）。《學術與研究治理規範》2.0。規範頁面.
9. Butler, H. et al. (2016). RFC 7946: The GeoJSON Format. IETF. RFC 7946.
10. OpenStreetMap Foundation. Copyright and License. 授權頁面.
11. Overture Maps Foundation. Building Schema Reference. 規格文件.
12. Google Maps Platform. Search for destinations — Geocoding API v4. 官方文件.

附錄 A：可重複驗證

• 研究對象：xk-autodragon 0.1.0
• 程式基線：Git commit 161a305
• 後端版本：20260421e
• 算法版本：pailong_v4_five_auspicious_palace_coverage
• 驗證日期：2026-09-04
• 驗證腳本：research/validate_xk_workbench.py
• 執行方式：uv run --no-project --with overturemaps --with httpx --with fastapi --with pydantic python research/validate_xk_workbench.py

本腳本只使用合成幾何與確定性不變量，不連線取得真實住宅資料，也不含客戶資料。

附錄 B：披露與責任聲明

評審狀態：本文為系統設計與內部技術驗證稿，未經獨立同行評審，亦未完成實地效度研究。

利益關係：本文以發布方參與開發或運營的原型為研究對象，系統展示與研究傳播存在直接關聯；讀者應據此理解創新性評價的立場。

人工智能使用披露：本稿於 2026-09-04 使用 OpenAI Codex（GPT-5 系列）協助整理程式結構、生成初稿與格式化。方位公式、權重、版本號及驗證結果取自本地程式與可重跑腳本。正式發表前，署名作者與編輯須逐項核對原始碼、參考資料、傳統術數表述、授權與利益衝突資訊，並對最終文本負責。

使用邊界：本文討論文化研究與專業工作流，不構成建築、規劃、測量、醫療、心理、法律、財務或其他受監管專業意見，也不證明風水判斷對健康、財富、關係或其他結果具有因果效力。