AI Coding 項(xiàng)目案例企業(yè)組織架構(gòu)與 RBAC 權(quán)限管理系統(tǒng)這是 AI 通識課第三次作業(yè)的項(xiàng)目記錄。項(xiàng)目依據(jù)第六天課件 7.8 節(jié)的實(shí)戰(zhàn)主題基于 RBAC 模式的企業(yè)級組織架構(gòu)和權(quán)限管理的實(shí)現(xiàn)完成目標(biāo)是做出一個可以本地運(yùn)行、可以演示、可以測試的前后端分離 MVP。一、項(xiàng)目要解決的問題企業(yè)內(nèi)部管理系統(tǒng)通常同時處理組織、用戶、角色和權(quán)限四類數(shù)據(jù)。如果只在前端隱藏菜單用戶仍然可能直接調(diào)用接口因此權(quán)限控制必須由后端完成。這個項(xiàng)目把權(quán)限抽象為用戶通過角色獲得權(quán)限并用權(quán)限碼控制菜單和 API。本次作業(yè)保留三個演示角色超級管理員管理組織、用戶、角色和權(quán)限部門管理員可以查看組織和用戶但不能修改角色及權(quán)限普通員工只能訪問工作臺和自己的基礎(chǔ)信息。項(xiàng)目范圍經(jīng)過主動收斂沒有加入 Redis、MySQL 生產(chǎn)部署、多租戶、真實(shí)審計(jì)日志、短信找回密碼和云端部署。這些內(nèi)容不屬于本次 MVP 的驗(yàn)收重點(diǎn)。二、為什么先寫 Spec課件將 SDDSpec-Driven Development規(guī)范驅(qū)動開發(fā)作為 AI Coding 的重要方法先把做什么寫清楚再在設(shè)計(jì)文檔中確定怎么做最后編碼和驗(yàn)證。因此項(xiàng)目沒有直接從頁面或數(shù)據(jù)庫開始而是先建立了三個文檔spec.md定義角色、功能范圍、權(quán)限邊界、異常場景和驗(yàn)收標(biāo)準(zhǔn)design.md確定技術(shù)棧、目錄結(jié)構(gòu)、數(shù)據(jù)表、API 約定和測試策略tasks.md把實(shí)現(xiàn)拆成數(shù)據(jù)庫、認(rèn)證、業(yè)務(wù) API、前端和測試任務(wù)。這樣的拆分解決了兩個實(shí)際問題。第一AI 生成代碼時有明確邊界不容易把項(xiàng)目擴(kuò)展成沒有驗(yàn)收標(biāo)準(zhǔn)的大系統(tǒng)。第二測試可以直接對應(yīng)規(guī)格中的驗(yàn)收標(biāo)準(zhǔn)而不是只驗(yàn)證頁面能打開。三、技術(shù)方案后端采用 Python、FastAPI 和 Uvicorn數(shù)據(jù)庫使用 SQLite密碼使用 bcrypt 哈希登錄認(rèn)證使用 JWT。前端使用 HTML5、CSS3 和原生 JavaScript通過fetch調(diào)用后端 API避免引入構(gòu)建工具和大型依賴使課程項(xiàng)目可以快速啟動。主要數(shù)據(jù)表如下departments 組織部門 users 用戶 roles 角色 permissions 權(quán)限 user_roles 用戶與角色關(guān)聯(lián) role_permissions 角色與權(quán)限關(guān)聯(lián)數(shù)據(jù)庫首次啟動時會自動建表并插入演示數(shù)據(jù)。系統(tǒng)內(nèi)置 4 個部門、3 個用戶、3 個角色和 9 個權(quán)限方便直接演示不同角色之間的差異。認(rèn)證和授權(quán)流程是用戶提交用戶名和密碼后端校驗(yàn)密碼哈希和賬號狀態(tài)登錄成功后簽發(fā) JWT受保護(hù)接口從 Bearer Token 獲取當(dāng)前用戶后端查詢用戶的角色權(quán)限并執(zhí)行權(quán)限依賴前端根據(jù)當(dāng)前用戶權(quán)限渲染菜單但菜單隱藏不作為安全邊界。四、AI Coding 的開發(fā)流程1. 讀取課程資料并確認(rèn)范圍先瀏覽 AI 通識課文件夾定位第六天課件并確認(rèn)本次項(xiàng)目主題、可選技術(shù)棧以及 SDD/TDD 相關(guān)要求。根據(jù)課程給出的 Python、SQLite、H5/CSS/TS 等選擇空間項(xiàng)目最終采用 Python SQLite 原生 HTML/CSS/JavaScript。2. 把需求整理為可驗(yàn)收條目規(guī)格文檔中沒有只寫做一個權(quán)限系統(tǒng)而是把需求拆成登錄、組織架構(gòu)、用戶管理、角色權(quán)限、權(quán)限控制和數(shù)據(jù)約束。例如普通員工請求用戶接口必須返回 403部門有子部門或成員時不能刪除用戶響應(yīng)中不能出現(xiàn)密碼字段登錄后普通員工不顯示用戶管理和角色權(quán)限菜單。這些條目都能通過 API 測試或?yàn)g覽器測試驗(yàn)證。3. 依據(jù)設(shè)計(jì)文檔實(shí)現(xiàn)后端后端先完成 SQLite 初始化和種子數(shù)據(jù)再實(shí)現(xiàn)認(rèn)證依賴、權(quán)限依賴和業(yè)務(wù)服務(wù)最后接入 FastAPI 路由。組織、用戶、角色和權(quán)限的處理集中在服務(wù)層路由層負(fù)責(zé)參數(shù)校驗(yàn)、權(quán)限依賴和錯誤狀態(tài)碼轉(zhuǎn)換。實(shí)現(xiàn)時特別保留了兩層權(quán)限控制前端根據(jù)權(quán)限隱藏沒有訪問資格的菜單后端每個受保護(hù)接口再次校驗(yàn)權(quán)限。這樣即使用戶繞過頁面直接請求接口也不能獲得越權(quán)數(shù)據(jù)。4. 實(shí)現(xiàn)前端工作臺頁面采用控制臺布局包含登錄頁、工作臺、組織架構(gòu)、用戶管理和角色權(quán)限五個視圖。新增和編輯操作使用統(tǒng)一彈窗表單減少重復(fù)頁面代碼。頁面還處理了加載狀態(tài)、錯誤提示、退出登錄和移動端基本寬度適配。前端沒有把權(quán)限判斷寫成唯一安全邏輯而是把/api/auth/me返回的權(quán)限用于界面展示真正的權(quán)限判斷仍然由 FastAPI 后端負(fù)責(zé)。5. 測試驅(qū)動的校驗(yàn)與調(diào)試API 測試覆蓋了以下場景管理員登錄和當(dāng)前用戶信息錯誤密碼被拒絕普通員工訪問用戶 API 被拒絕部門管理員可以讀取組織但不能創(chuàng)建角色刪除仍有子部門的部門被拒絕管理員可以創(chuàng)建用戶和角色且密碼不會返回。瀏覽器測試使用本機(jī) Microsoft Edge驗(yàn)證了管理員登錄、管理員菜單、組織架構(gòu)頁面、普通員工菜單權(quán)限和 390 像素移動端頁面。開發(fā)過程中遇到兩個實(shí)際問題。第一個是組織頁面點(diǎn)擊后立即斷言文本異步請求尚未完成測試偶發(fā)找不到技術(shù)研發(fā)部處理方式是等待該節(jié)點(diǎn)真正出現(xiàn)在頁面后再斷言。第二個是組織樹沒有子節(jié)點(diǎn)時渲染了暫無組織數(shù)據(jù)這與樹組件的遞歸結(jié)構(gòu)不一致后來讓空節(jié)點(diǎn)直接返回空字符串。五、驗(yàn)證結(jié)果在項(xiàng)目根目錄執(zhí)行python -m pytest -q結(jié)果為6 passed隨后啟動 Uvicorn并執(zhí)行瀏覽器檢查腳本結(jié)果為browser_check: PASS瀏覽器驗(yàn)證還檢查了移動端頁面沒有橫向溢出。測試過程中出現(xiàn) FastAPIon_event的棄用警告這是當(dāng)前依賴版本的 API 遷移提示不影響本次功能驗(yàn)收后續(xù)可改為 lifespan 寫法。六、項(xiàng)目邊界與后續(xù)改進(jìn)當(dāng)前版本是課程作業(yè)級 MVP不應(yīng)直接當(dāng)作生產(chǎn)系統(tǒng)使用。后續(xù)如果繼續(xù)開發(fā)可以優(yōu)先完成將 SQLite 遷移到 MySQL使用環(huán)境變量管理 JWT 密鑰增加操作審計(jì)日志增加更細(xì)粒度的數(shù)據(jù)范圍權(quán)限使用 Vue3 或 TypeScript 重構(gòu)前端增加 CI 自動測試和部署配置將 FastAPI 的棄用事件處理遷移到 lifespan。這次開發(fā)最重要的收獲不是讓 AI 一次生成全部代碼而是把需求、設(shè)計(jì)、實(shí)現(xiàn)和驗(yàn)證串成了一個可檢查的流程。AI 可以加快代碼和頁面的生成但開發(fā)者仍然需要確認(rèn)課程要求、控制項(xiàng)目范圍、檢查權(quán)限邊界并用測試證明功能確實(shí)完成。另外附上個人Git倉庫連接433525/-供大家參考