XIAOJUSURVEY：滴滴開源的問卷系統，值得企業導入嗎？

從滴滴內部到開源：XIAOJUSURVEY 要解決什麼

XIAOJUSURVEY 是滴滴出行內部沉澱的問卷系統，對外宣稱輕量且安全，提供一站式產品級方案。它鎖定的不是單一表單需求，而是涵蓋市場調查、客戶滿意度、線上考試、投票、報導與測評等多種場景。對企業而言，問題往往不是「怎麼做一個表單」，而是「怎麼管理從設計到分析的整個流程」。這個專案試圖把滴滴內部累積的經驗，包含 40 多種題型與 100 多個模板，直接變成可部署的產品。它明顯是寫給需要快速建立內部或對外問卷系統的團隊，而不是只想在網頁上插入一個聯絡表單的個人開發者。後者用 Google Forms 或 Typeform 就夠了，不需要自己架設伺服器。

前後端分離的實際架構：Vue3、NestJS 與 MongoDB

從 README 的技術段落可以清楚看到，XIAOJUSURVEY 採用前後端分離。Web 端使用 Vue3 搭配 ElementPlus，跨端 SDK 則標註為 React Native，這點值得注意，因為它暗示著未來可能支援行動裝置的原生整合，但目前文件並未提供具體的 SDK 使用範例。Server 端是 NestJS 搭配 MongoDB，這表示資料模型是文件導向，適合問卷這種結構多變的內容。架構上，它將問卷編輯劃分為五大子領域，試圖降低編輯器的複雜度。前端與後端透過 API 溝通，而題型被設計成「物料」，每一種題型都有通用基礎能力與原子化特性能力。這種設計讓新增題型不必改動核心程式碼，只要遵循物料協議就能擴充。但相對的，開發者必須先理解「問卷 Meta 協議」與「題型物料協議」，這不是打開程式碼就能立刻上手的專案。

啟動與部署：從 npm run local 到 Docker 的兩條路

本地開發流程在 README 寫得很直接。先進入 server 目錄執行 npm install 與 npm run local，再進入 web 目錄執行 npm install 與 npm run serve。啟動後，B 端管理介面在 http://localhost:8080/management，C 端渲染頁面則在 http://localhost:8080/render/:surveyPath。這裡的 surveyPath 是動態參數，代表每份問卷有專屬路徑。部署方面，官方提供 Docker 化方案，並有兩個映像標籤可選。slim 版本基於 node:18-slim，體積小，適合生產環境；完整版本基於 node:18，包含 curl、vim、git 等除錯工具，適合開發環境。切換方式是在 docker-compose.yaml 中修改映像標籤。這種雙軌設計很務實，但要注意的是，README 沒有提供 docker-compose.yaml 的完整內容，實際使用時仍需參考部署指導文件。另外，Node.js 版本要求大於等於 18，如果你的伺服器環境還是 Node 16，就必須先升級。

題型物料化與 Meta 協議：擴充性的真正關鍵

XIAOJUSURVEY 最核心的設計理念是「題型物料化」。官方文件指出，題型是問卷最核心的組成部分，而題型可配置化能力決定了上層業務的擴展場景。每一類題型擁有通用基礎能力，每一種題型擁有原子化特性能力。這意味著，如果你要新增一種「矩陣滑桿」題型，你不需要重寫整個表單引擎，而是定義新的物料，描述它的設定器與渲染邏輯。這個機制依賴於「問卷 Meta 協議」，官方稱之為領域標準，分為業務描述與物料描述兩大類。協議的存在讓搭建端與渲染端可以保持高度一致，也就是官方強調的「所見即所得」。然而，這套協議是 XIAOJUSURVEY 自己定義的，不是業界標準。開發者在擴充題型時，必須先熟悉這套規範，學習曲線比直接修改一個傳統表單產生器來得陡峭。換句話說，擴充性強，但前提是你願意投入時間理解它的抽象層。

AI 生成問卷與邏輯編排：亮點背後的模糊地帶

README 在功能特性中提到「AI 生成問卷，支援一鍵接入 LLM」，並在技術段落補充「智慧化問卷：AI 一句話生成問卷」。這聽起來很吸引人，但文件完全沒有說明是串接哪個 LLM、API 金鑰如何設定、或是 prompt 如何設計。以開源專案而言，這種功能通常需要外部服務，而滴滴內部可能使用自家的大模型，外部使用者未必能直接複製同樣的體驗。另外，邏輯編排方面，它支援顯示邏輯、跳轉邏輯、選項引用與題目引用，這些是動態表單的標準需求。文件沒有提供實際的規則語法範例，例如「當題目 A 回答為 B 時，顯示題目 C」要怎麼在 Meta 協議中表達。對於想評估邏輯引擎是否符合自己需求的工程師，這是一個資訊缺口。你必須實際安裝後測試，或者自行翻閱原始碼，才能判斷它的邏輯表達能力是否足夠。

安全與合規：內建能力的實際邊界

安全是 XIAOJUSURVEY 強調的重點，README 列舉了資料加密傳輸、敏感詞庫、發布審查與投票防刷等能力。但要注意，這些描述大多來自官方文件的摘要，實際的實作細節，例如敏感詞庫是內建清單還是可自訂、發布審查的流程是自動還是人為介入，文件都沒有交代。它提到的「安全能力可擴展」，指的是提供經驗指導，而非保證任何部署都安全。對於需要處理個資的企業，例如客戶滿意度調查，你仍然需要自己評估 GDPR 或台灣個資法的合規要求。MongoDB 的資料儲存方式也需要考量，如果沒有正確設定索引或備份策略，資料遺失的風險依然存在。此外，README 提到「多角色權限管理」與「空間管理」，這暗示它支援多租戶架構，但沒有說明角色權限的細粒度，例如是否能限制特定管理員只能看到特定問卷的資料。這些都需要查閱官方文件或直接測試才能確認。

維運成本與授權：Apache-2.0 的雙面刃

XIAOJUSURVEY 採用 Apache-2.0 授權，這對企業是友善的，允許商業使用、修改與再發布，只要保留版權聲明。但維運成本不能只看授權。它依賴 MongoDB 與 NestJS，這表示你需要具備 Node.js 後端維運能力的團隊。MongoDB 的版本升級、資料備份、索引最佳化，都是長期責任。Docker 部署降低了初始安裝門檻，但後續的版本更新，例如從一個映像標籤升級到另一個，是否會破壞既有資料結構，README 沒有提供遷移指南。CHANGELOG 是放在 GitHub issues 中，而不是標準的 CHANGELOG 檔案，這對習慣查閱 release notes 的團隊來說不太方便。另外，README 提到「上億量級打磨」，這是滴滴內部的規模，不代表你的部署也會有同樣的效能。如果你的問卷流量只有每月幾千次，這套系統可能過度設計，但如果你預期有百萬級並發，你仍然需要自行進行壓力測試，因為文件沒有提供任何效能基準。

替代方案的實際差異：formly、surveyjs 與 Typeform

在開源世界，XIAOJUSURVEY 的競爭對手包括 Angular formly 或 Vue Formly 這類表單產生器，以及 SurveyJS 這種專門的問卷函式庫。SurveyJS 的核心是前端元件，它提供類似的題型庫與邏輯跳轉，但它不包含後端資料收集與分析儀表板。你必須自己建立 API 來儲存回覆，或串接第三方服務。XIAOJUSURVEY 的優勢在於它是一個完整產品，包含使用者管理、問卷權限與數據分析。另一個差異是 SurveyJS 的 JSON schema 是公開且廣泛使用的，許多開發者已經熟悉，而 XIAOJUSURVEY 的 Meta 協議是專屬的，社群文件也相對少。若你只需要前端表單，SurveyJS 的整合成本較低；若你需要完整的回收與分析流程，XIAOJUSURVEY 的 all-in-one 架構較有吸引力。但要注意，SurveyJS 的進階功能有時需要付費，而 XIAOJUSURVEY 完全是 Apache-2.0，這在成本上是明確的優勢。

編輯結論

XIAOJUSURVEY 適合需要快速建立完整問卷生命週期（創建、編輯、投放、回收、分析）的企業或個人開發者，尤其是那些希望透過 Docker 一鍵部署、並願意投入時間理解其 Meta 協議與物料化設計的團隊。它不適合只需要簡單嵌入表單、不想管理 MongoDB 與 NestJS 後端的小型專案，也不適合對即時協作編輯有高度需求的場景。導入前應先確認你的 Node.js 環境版本（需大於等於 18），並詳細閱讀官方提供的問卷 Meta 協議與 Docker 部署文件，因為這些是客製化與維運的基礎。若你重視的是社群生態與外掛豐富度，則需要考慮其他更成熟的開源表單工具。

官方來源

1. didi/xiaoju-survey on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README