項目	內容
這個作業屬于哪個課程	2025年春季軟件工程（羅杰、任健）
這個作業的要求在哪里	[T.12] 團隊項目：Alpha 階段項目展示
我在這個課程的目標是	學習軟件工程的基礎知識，和團隊成員們實踐各種軟件工程的方法與流程，開發一個讓我們值得驕傲的項目
這個作業在哪個具體方面幫助我實現目標	Alpha 階段項目展示

團隊成員與分工簡介

1. 范興堃

• 參與任務：
  • 選題（調研與可行性分析）
  • 整體架構設計（協同完成）
  • 工具調研：（協助執行）
  • 流程構想（主責）
  • 數據庫設計（主責）

2. 吳佳峻

• 參與任務：
  • 選題及需求分析（獨立）
  • 整體架構（協同完成）
  • 前端移動端適配（多端實現）
  • MCP協議支持探索（獨立）
  • 工具調研：（主責執行）
  • 流程構想（協同執行）

3. 葉佩霖

• 參與任務：
  • 選題（調研）
  • 前端適配（響應式設計）
  • 學習 React 和 Ragflow 前端架構（主要負責人）
  • 搭建RAGnarok前端（主要負責人）

4. 林宇浩

• 參與任務：
  • 選題（調研）
  • 前端適配（響應式開發）
  • 文件切分（新增，獨立負責）
  • 后端組件對接（協作執行）

5. 熊曉焜

• 參與任務：
  • 選題（調研）
  • 前端適配（移動端開發協同）
  • embedding（優化和聯調）
  • 后端組件對接（協作執行）

6. 鐘芳梽

• 參與任務：
  • 選題（調研）
  • 向量庫+Retrieve 模塊（獨立負責）
  • Qdrant（框架搭建與功能完善）
  • 后端組件對接（協作執行）

7. 陳敘傳

• 參與任務：
  • 選題（調研）
  • 用戶提問 + LLM 模塊（獨立完成）
  • 后端組件對接（協作執行）
  • 優化 LLM 異步調用性能

項目管理

1. 任務管理工具

• 飛書多維表格：記錄和跟蹤所有任務的信息，包括任務標題、描述、執行人、開始與截止日期、預估工時、實際進展、依賴關系等。

2. 任務分解方法

• WBS（工作分解結構）方法：項目目標首先被拆解為高層次的任務，再根據任務的重要性和復雜性進一步細化為具體的、獨立的、短時的子任務。
• 任務粒度控制：通過拆解任務為短時、可執行的小任務，可以確保每個子任務能夠在短時間內完成，降低任務的復雜度與不確定性。

3. 進度記錄與跟蹤

• 飛書多維表格進度更新：所有任務及子任務的進度信息都記錄在飛書多維表格中，包括任務描述、負責人、實際完成情況、任務進展等。
• 定期進度更新：團隊定期進行進度更新（如每日或每周），通過飛書進行共享，形成動態的任務進度圖表。這有助于團隊及時了解各自任務的完成情況，保持整體協調。

4. 動態調整機制

• 實時反饋與調整：項目經理（PM）根據團隊成員的反饋、開發過程中的實際情況對任務的預估工時、依賴關系以及任務分配進行動態調整。

典型用戶場景與軟件滿足方式

本項目RAGnarok面向B端企業用戶和C端個人用戶兩大核心用戶群體，針對其實際使用需求和目標，系統在功能、架構和使用體驗等方面做了明確設計，以滿足典型應用場景下的業務與個人智能問答需求。

一、B端企業用戶典型場景

1. 應用背景

企業IT部門或業務團隊希望構建專屬的智能問答系統，用于客服支持、知識管理、內部知識庫問答、員工培訓等場景，需保障數據安全、知識隔離、系統集成能力。

2. 典型用戶畫像

• 企業IT經理、架構師、系統管理員
• 對接平臺的第三方服務集成商
• 企業知識庫維護人員

3. 典型用戶場景

場景：某大型企業搭建內部智能問答助手，支持員工在內部系統中提問業務流程、制度政策、技術文檔。

用戶操作流程：

• 企業通過RAGnarok部署私有化實例，上傳結構化/非結構化文檔至私有知識庫。
• 使用模塊化Pipeline配置：文檔檢索 → 智能排序 → LLM問答生成。
• 系統通過MCP協議對接企業已有系統（如OA或CRM）以獲取動態信息。
• IT管理員設定訪問權限，多租戶模式保障不同部門數據隔離。

4. 軟件滿足方式

功能模塊	滿足點說明
私有化部署 & 多租戶架構	確保企業數據安全，支持不同部門獨立使用與管理知識庫
MCP接口協議	統一數據上下文結構，簡化與企業現有系統的集成工作
流水線（Pipeline）編排	企業可自定義問答流程，靈活適應業務場景變化
權限與審計管理	提供用戶權限分級與操作日志，滿足企業合規要求
運維監控 & 調試工具	保障系統穩定運行，支持快速故障定位與性能調優

5. 效果

• 快速構建面向員工或客戶的問答系統，縮短部署周期
• 強化內部知識共享與工作效率
• 降低技術集成與維護成本，提高系統安全性和穩定性

二、C端普通用戶典型場景

1. 應用背景

個人用戶希望借助RAG技術便捷獲取知識答案，例如進行日常知識查詢、學習輔助、工作參考等，追求高效、準確、無需技術門檻的使用體驗。

2. 典型用戶畫像

• 學生、自由職業者、知識工作者、AI興趣愛好者
• 對LLM技術感興趣但無開發能力的用戶

3. 典型用戶場景

場景：用戶希望快速查詢某個專業術語、撰寫資料或整理文獻摘要，通過RAGnarok平臺完成這一過程。

用戶操作流程：

• 用戶注冊并創建個人知識庫，上傳PDF、網頁、筆記等內容。
• 在界面中輸入問題，系統使用內置Pipeline完成檢索增強問答。
• 系統提供回答結果，并列出參考文檔與出處。
• 用戶收藏、反饋或分享回答結果，形成個性化歷史記錄。

4. 軟件滿足方式

功能模塊	滿足點說明
開箱即用的可視化界面	無需編碼，即可上傳文檔、提問并獲取回答
智能問答 + 引用文檔呈現	保證答案可追溯，提高信任度與實用性
個性化知識庫	用戶可構建屬于自己的語義庫，提升問答的相關性
查詢歷史與推薦機制	根據用戶行為進行答案推薦與內容優化
簡潔交互體驗	面向C端設計的界面與流程，適配移動端與Web端

5. 效果

• 快速獲得準確、上下文相關的答案，無需自行查閱文檔
• 可持續構建個人知識體系，助力學習與工作
• 用戶體驗友好，無需任何技術背景即可使用

RAGnarok?的殺手級功能與差異化亮點

（對比 Dify / Haystack / RAGFlow 等主流競品）

維度	RAGnarok 核心能力	競品現狀	差異化價值
標準化對接（80%）	原生支持 MCP 協議- “萬能插頭”式標準- 既可作為 MCP Client 調用外部工具，也能作為 MCP Server 把知識庫能力共享給其它 Agent	? Dify / RAGFlow：僅自有 REST? Haystack：自行封裝連接器	徹底消除“每接一個數據源就改一次代碼”的痛點，形成可組合、可互聯的 AI 生態
RAG 邏輯細分（100%）	Pipeline 顆粒級可編排- 檢索 → 過濾 → Rerank → LLM → 后處理… 塊級拖拽- 串并行、條件分支、循環、斷點調試	? Dify：可視化流程但節點種類有限、不可并行? Haystack：需寫 Python 腳本? RAGFlow：主流程固定	像“搭積木”一樣自定義任意深度的 RAG & Agent；復雜業務鏈路不再受限
高級檢索（0%）	- 混合搜（向量 + BM25）- 可插拔 Cross?Encoder Rerank- 跨庫調度與去重	? Dify：主打跨庫，單庫精準度一般? Haystack：需自行配置 Rerank? RAGFlow：高精度但慢	在保留跨庫廣度的同時給出專業級精準度，滿足金融 / 法律等高要求場景
知識庫多租戶 & 安全（50%）	- 公私庫 + 租戶隔離- 條目級權限 & 字段加密	多數競品僅簡單分庫或需企業版	企業可放心私有化部署；同一實例服務多業務線 SaaS 化無障礙
實時可觀測性（50%）	全鏈路調試儀表盤- 中間結果逐步展示- WebSocket 秒級推送- 斷點運行 / 參數熱調	大多僅日志或簡單 Console	開發者 DX 大幅提升，定位“幻覺”、檢索不準等問題只需幾分鐘
開發者友好（80%）	- Python SDK + 細粒度子模塊- MIT / Apache?2.0 友好開源- Docker 一鍵起	? Dify：License 對商業有約束? Haystack：代碼型，上手門檻高	既“開箱即用”，又能拆成庫嵌入現有系統，商業化不背包袱
擴展方式（50%）	MCP + 自定義組件雙軌- 插件即服務- 支持把本地腳本包裝成 MCP 工具	競品多依賴內建接口	未來新模型 / 新數據庫不改核心，只加一個組件即可熱插拔

一句話總結

RAGnarok 把 RAG 做成了“可編排的樂高套裝”，再加上 MCP 這把“USB?C 通用插頭”，讓開發者和企業第一次可以 無鎖定、零膠水 地自由拼裝高精度、可觀測、可擴展的檢索增強智能體——這是現有任何單一 RAG 框架都無法同時做到的。

項目發布時的團隊努力

項目已完成alpha階段任務

• 邀請b端用戶進行試用，收集反饋

軟件工程質量

一、團隊代碼的軟件工程質量分析

1. 架構設計清晰，模塊劃分合理

項目采用模塊化流水線（Pipeline）架構，具備高度可組合性和擴展性，支持企業用戶和個人用戶的多樣化需求。這種設計模式體現了良好的高內聚、低耦合理念，是現代軟件工程的典范結構。

2. 高度關注安全性與可維護性

引入私有化部署、多租戶隔離、權限管理、審計機制等功能，體現了系統在安全合規性和運維可控性方面的嚴謹設計，符合企業級工程的質量標準。

3. 支持自動化與標準化對接

通過 MCP 協議標準化數據上下文和系統接口，大大降低與外部系統的耦合度，提高了系統的可移植性和長期維護能力。

4. 面向企業用戶的專業化體驗設計

系統界面與交互流程針對 B 端用戶進行專業化設計，支持多租戶管理、權限配置、模塊化知識庫配置與流程編排，滿足企業在數據安全、系統集成和操作效率上的需求，體現出企業級人機工程與可用性設計水準。

二、可用的數據或指標證明工程質量

為了更客觀地評估和證明團隊的軟件工程質量，可以從以下幾個維度引入數據支撐：

1. 模塊測試
   • 除了每一個組件都有自己的單元測試外還有流水線整體測試，保證單個組件正常運行的同時測試組件間的連通性；

• 目標覆蓋率應不低于 80%，關鍵模塊（如知識庫上傳、MCP接口）應達到 90%+；

2. 架構一致性與接口規范性

? 使用Apifox 保障軟件工程質量

• 接口規范一致 接口即文檔，統一前后端理解，減少對接錯誤，變更自動同步。
• 自動化測試 支持接口測試用例與斷言校驗，發現邊界問題，保障接口穩定性。
• 前后端高效協作 提供 Mock 數據，前后端可并行開發，減少等待時間。
• 質量可視化 自動生成測試報告，覆蓋率可追蹤，便于問題定位與風險評估。
• 集成 CI/CD 流程 支持自動化測試接入流水線，實現每次構建前接口校驗，保障上線質量。

3. 版本控制與協作度指標

• 使用 Git 倉庫進行版本管理；
• 所有代碼通過 Pull Request 審核機制，確保每次合并前經過同行評審，提升代碼質量與一致性。
• 提交記錄顯示多人頻繁貢獻代碼，PR（合并請求）流程規范，說明團隊協作良好、分工明確。

4. 使用 uv 使依賴完全一致

? 使用 uv 提高了依賴管理與協作開發的工程質量，主要體現在以下方面：

• 構建環境統一：通過 uv.lock，每個開發者、CI/CD 服務器都使用完全一致的依賴版本，避免版本不一致的問題。
• 依賴安裝提速：大幅減少依賴安裝時間，提高開發效率和構建速度。
• 自動創建虛擬環境：簡化項目初始化步驟，降低新人上手門檻。
• 依賴安全與審計支持：便于后續接入安全掃描工具，確保依賴清潔可靠。

項目管理

團隊成員的簡介和個人博客地址

成員	介紹	個人博客地址
吳佳峻	"你是項目的PM兼測試人員，負責捍衛cxc,fxk,lyh,xxk,ypl,zfz的頭發"	http://www.rzrgm.cn/wuyu666888
熊曉焜	"你是一個后端開發工程師，喜歡古典樂和足球，希望寫出有序且優雅的項目"	http://www.rzrgm.cn/CrisXxk
葉佩霖	"你是一個前端開發工程師，想要捍衛銀河中的美"	http://www.rzrgm.cn/Idrila
林宇浩	"你是一個前端開發工程師，喜歡北冰洋，還是一名羽毛球愛好者"	http://www.rzrgm.cn/7111-lyh
范興堃	"你是項目的PM兼測試人員，熱愛滑雪"	http://www.rzrgm.cn/Poseidon-fan
鐘芳梽	"你是一個后端開發工程師，永遠對新的技術保持熱忱，希望能在這次合作中學習到更多的新技能"	http://www.rzrgm.cn/Wednesday-zfz
陳敘傳	"你是一個后端開發工程師，熱衷于一切釋放生產力的新技術，喜歡構建自動化工作流，你期待在團隊中與前端工程師、PM等其他團隊成員合作，共同創造出有價值的項目"	http://www.rzrgm.cn/cxccxc

團隊項目管理

項目在開發過程中結合多種工具，實現了任務規劃清晰、進度追蹤高效、接口規范一致、環境統一部署，全面保障工程質量。

1. 任務規劃與執行跟蹤：飛書文檔管理全流程

• 任務管理工具：使用 飛書多維表格 全程記錄任務標題、執行人、起止時間、預估工時與依賴關系，確保信息完整透明；
• 任務拆解方法：應用 WBS 將項目目標層層分解為短周期、可執行的子任務；
• 進度跟蹤機制：
  • 所有進度實時更新至飛書表格；
  • 定期共享（每兩天一次），形成 任務動態進度圖表；
  • 項目經理根據實際情況進行工時與依賴動態調整。

1. 版本控制與開發協作：GitHub 高效管理、同步團隊代碼倉庫
2. 接口一致性與測試保障：Apifox 提升前后端協同效率
3. 依賴管理與構建統一：uv 實現環境一致性

分工協作

分工協作方式：

團隊成員聽從PM進行任務分配，同時也按專業技能和學習意愿分工。

經驗與教訓：

• 經驗：

  • 各自負責模塊，協同接口聯調，明確責任邊界；
  • 鼓勵探索新技術并在組內分享（如 MCP 協議、Qdrant 向量庫）。

• 教訓：

  • 前期接口定義不夠明確，導致后端聯調階段耗時較長
  • 對部分功能定義模糊，讓人難以下手，進度推進緩慢
  • 前端適配對多端兼容細節預估不足，影響初期演示進度
  • 組件化不足時，成員之間代碼協作摩擦較大

溝通和對接

溝通方式：

• 線上同步：
  • 日常通過飛書會議 + 群聊 + 多維表格協同；
  • 每兩天舉行例會（線上或線下），進行階段回顧與下階段規劃。
• 異步溝通：
  • 所有需求、任務進展、代碼接口文檔都統一記錄在飛書文檔與表格中；
  • 代碼通過 Git 分支管理進行協同開發。

留存記錄：

• 飛書表格保留了完整的任務與進展信息；
• 代碼開發階段的接口文檔、提交記錄、版本更新均保留在 Git 倉庫與飛書知識庫中；
• 會議紀要與決策結論同步記錄在飛書文檔。

時間/質量/資源的平衡

• 前期任務粒度控制與優先級排序：使用 WBS 拆解任務，并按照關鍵路徑優先調配資源，提升整體效率；
• 動態調整與容錯機制：項目經理根據任務實際進展靈活調整優先級與人力配置，有效緩解關鍵路徑上的卡點問題；
• 階段性完成目標、邊做邊調：每完成一部分功能就盡快使用和測試，根據結果及時改進后續開發方向，避免方向偏離；
• 集中投入解決關鍵問題：在項目后期將精力集中到系統穩定性、功能完整性和團隊協作效率上，確保最終項目整體表現良好。

這種方式有助于在人員精力有限的情況下，保證演示功能的基本可用與系統結構的合理性。

實際進展情況

我們采用飛書文檔進行項目進度管理

項目管理工具（燃盡圖）如何反應真實狀態

通過與“理想燃盡線”的對比，燃盡圖能夠清晰反映項目是否按計劃推進：如果實際燃盡線大致貼合或低于理想線，說明項目進展順利；如果持續高于理想線，說明進度落后，存在任務積壓；而如果實際線長期沒有變化，說明團隊在某個階段可能遇到阻塞，進展停滯。

燃盡圖之所以能夠真實反映項目狀態，是因為它以每日任務完成數據為基礎，不依賴主觀判斷，具有高度透明性和可追蹤性。它不僅幫助團隊及時發現偏差、調整節奏，還能在沖刺回顧時提供依據，用于復盤哪些階段執行順利、哪些地方存在瓶頸，從而不斷優化開發流程。

項目進度管理工具（燃盡圖）反映真實性分析：

• 真實性方面：

  • 燃盡圖反映了各成員提交的任務完成度，配合定期更新，能較真實地展示整體進度；

• 存在一定“美化”情況：

  • 部分任務標為“完成”但仍有 bug 或未測試完全；
  • 個別任務以“部分完成”狀態上報，但在圖表中仍計入“完成量”，可能掩蓋問題。

團隊角色與貢獻

名字	角色	團隊貢獻分	具體的、可衡量的、可驗證的貢獻
范興堃	架構與數據庫設計	54	負責數據庫結構設計，主導核心流程構想，參與架構方案制定與優化
吳佳峻	PM & 技術骨干 & 工具集成	53.5	主導工具選型與集成，完成移動端適配，實現核心協議接入功能
葉佩霖	前端核心開發	53	搭建前端架構，完成主要頁面設計與組件開發，實現響應式布局
林宇浩	文件處理與前端協作	47.1	開發文件切分模塊，參與后端聯調
熊曉焜	embedding、前端支持與博客管理	47.4	開發embedding模塊，參與前端開發、博客整理與發布
鐘芳梽	檢索模塊開發	48	開發 Retrieve 模塊、搭建 Qdrant 環境、參與后端聯調
陳敘傳	問答與模型調用	47	獨立完成問答模塊開發，優化大模型調用性能

用戶場景

1. 項目開發前的目標，預期的典型用戶場景，預期的功能描述

目標：
構建一個支持多租戶、私有化部署、模塊化Pipeline配置的RAG問答系統，服務B端企業用戶與C端個人用戶，滿足其智能問答和知識管理需求。

預期典型用戶場景：

• B端企業用戶：如企業IT部門希望構建內部智能問答助手，應用于客服、知識庫、員工培訓等，注重數據安全、系統集成和多部門隔離。
• C端個人用戶：如學生或自由職業者，用于查詢術語、文獻摘要、輔助寫作等，追求使用便捷和高質量問答體驗。

預期功能描述：

• 私有化部署、多租戶支持
• 模塊化問答流程配置（Pipeline）
• 知識上傳、引用溯源
• MCP協議系統集成
• 用戶權限管理、操作日志審計
• 可視化問答界面、個性化知識庫

2. 項目發布的功能（拷貝發布文檔），在哪里發布了軟件

發布功能包含：

• 私有化部署 & 多租戶架構
• MCP協議支持（系統對接）
• 模塊化Pipeline問答配置
• 可視化問答界面（C端界面）
• 支持結構化/非結構化文檔上傳與引用
• 用戶權限管理、日志審計
• 查詢歷史與個性化推薦機制

發布平臺：
在 GitHub上作為開源項目。

3. 項目發布后是否滿足了全部典型場景？剩下的為何沒有滿足？

是否滿足全部典型場景：

• 大部分典型場景已滿足：包括企業內部問答系統搭建、私有化部署、個性化知識查詢等。
• 尚未滿足的部分：
  • 更復雜場景下的深度集成需求
  • 移動端適配
  • 高并發能力

原因推測：

• 開發周期和資源限制
• 用戶場景過于復雜或需二次定制開發
• 某些功能優先級較低或仍在測試階段

4. 項目發布后真正符合用戶需求了嗎？列出目標用戶使用產品的過程和評價

是否符合用戶需求：

• 大體上滿足了用戶需求，尤其是針對B端企業的系統集成、權限管理、私有化需求，以及C端用戶的低門檻、高效率問答體驗。

用戶使用過程與評價：

• B端用戶使用流程：

  • 企業部署系統 → 上傳資料 → 配置Pipeline → 對接內部系統 → 設置權限

• C端用戶使用流程：

  • 注冊賬號 → 上傳筆記/PDF → 提問 → 獲取答案和引用文獻 → 收藏/反饋

用戶日活

我們已經邀請了b端用戶進行試用，現階段用戶的活躍量不是很多，收集到的反饋也比較有限。

特色功能

1. 殺手級功能

RAGnarok 的殺手級功能是：

• MCP協議支持 + 可編排 RAG Pipeline 的雙組合：
  • MCP協議支持讓 RAGnarok 成為可以雙向對接的“AI 萬能插頭”，既能調用外部智能體工具，也能將自身能力暴露給其它系統，突破了單一框架的封閉限制。
  • 可編排的 RAG 流程設計支持顆粒級邏輯自由組合（檢索→過濾→重排→LLM調用→后處理等），以圖形化方式“搭積木”構建任意復雜任務流程。

與競品相比，Dify 的流程節點種類有限、不能并行；Haystack 需代碼腳本實現流程，RAGFlow 流程固定難拓展。RAGnarok 首次實現了零代碼、塊級組合的靈活性，同時還支持斷點調試、參數熱調等高級可觀測性。

2. 競品為何不具有這些功能

競品缺失原因：

• 生態封閉或設計初衷不同：如 Dify 更聚焦 C 端輕量體驗，不追求多智能體協作；Haystack 偏底層 NLP 工具包，缺乏“通用插件”理念；RAGFlow 固化流程，利于教學但缺乏生產級靈活性。
• 缺乏協議層標準（如 MCP）支持：競品大多是“孤島型”設計，無法與外部智能體生態打通。

我們的實現優勢：

• 架構前瞻性：在系統設計初期就將“模塊化、組合性、可擴展性”作為首要目標。
• 協議抽象層 MCP 的原生支持：團隊在系統集成與智能體通信方面積累較多經驗，能夠實現 RAG 與智能體的無縫協同。
• 前后端協同能力強：支持 WebSocket 實時鏈路追蹤、圖形化拖拽界面、后端可熱插拔調度器等技術難度較高的功能。

3. 團隊成員對這些功能的自我評價

自我評價：

• 核心目標已實現。
  • MCP 協議集成效果優于預期，插件注冊和調用穩定性高，復用效率高。
  • 拖拽式 RAG 設計在測試場景中實現了多流程并發與調試。

是否達標：

達到了預期目標

4. 用戶對這些功能的評價如何？是否認為這些功能富有特色，為什么？

用戶評價：

B端用戶普遍認為 MCP 插件機制與圖形化流程功能非常有用。特別是在多部門共享數據、分層權限配置與私有部署需求場景中更加靈活且安全。

用戶為何覺得功能富有特色：

• 之前嘗試過的工具無法兼容多個數據源或自定義工作流，而 RAGnarok 正好解決了這個痛點。
• MCP 協議的“即插即用”能力，幫助 IT 團隊快速打通原有系統與新 AI 能力，無需改動業務系統。
• 圖形化流程中每個步驟都能實時預覽中間結果，對調試和教學極具幫助。

軟件工程質量

1. 項目有完善的文檔嗎，是否有約定代碼規范？

項目具備完善的文檔體系和統一的代碼規范

• 使用 Apifox 進行接口文檔與測試管理，接口即文檔，前后端協作高效。
• 每個模塊和接口都有說明文檔，遵循統一的設計規范和接口約定。
• 所有代碼通過 Pull Request 審核機制，確保風格一致性與代碼質量。

2. 項目是否有出現代碼混亂、沒有注釋、沒有詳細文檔的問題？明年繼續開發會不會出現以上抱怨？

• 項目代碼組織良好，模塊劃分清晰。
• 代碼和接口的規范性能夠在聯調過程中確保。
• 每個模塊有文檔說明，新同學閱讀文檔和 PR 記錄能快速理解項目結構和開發規范。

3. 如果一個新學生在一臺新機器上想編譯并運行你的項目，能順利完成嗎？有什么樣的文檔能指導他？

可以順利完成，項目使用 uv 管理依賴，具備良好的可移植性：

• 項目配套提供 README 和環境初始化腳本。
• 通過 uv 自動創建虛擬環境，確保依賴版本一致、安裝過程簡潔。
• 有明確的啟動說明文檔，包括數據庫初始化、接口服務運行、前端調試等流程。

4. 項目是否有單元測試？測試用例數目、代碼覆蓋率等？

有明確的單元測試與流水線測試機制：

• 每個組件都具備單元測試。
• 流水線中集成了整體測試。
• 關鍵模塊和整體項目都能夠充分覆蓋。

**5. 項目是否采用了 CI/CD

• 集成自動化測試、接口校驗與構建流程。
• 每次提交觸發流水線進行接口測試與依賴校驗。
• 通過測試報告和覆蓋率工具確保上線版本質量。

6. 學到的經驗和教訓：Alpha 階段學到了什么？對軟件工程的經驗教訓？Beta 階段有什么計劃？

Alpha 階段經驗教訓：

• 模塊解耦性很關鍵：早期模塊間耦合度高，后期通過流水線架構大幅降低依賴，提高可測試性。
• 接口標準化帶來巨大收益：MCP 協議與 Apifox 使前后端協作更流暢。
• 可擴展性：如果沒有事先進行規劃未來擴展時會面臨許多困難。過早的決定或不充分的規劃可能導致需要重構系統。

Beta 階段計劃：

• 優化多租戶資源隔離與權限控制模塊。
• 前端的功能要繼續完善。
• 增加使用文檔與開發者指南，降低用戶與開發者上手門檻。
• 實現完整的持續部署流程，支持線上預覽與多環境切換。
• 需要改變項目的推廣方式，找到更多的用戶并且得到更多的反饋，尤其是C端。

項目一覽