后端前端認(rèn)證鑒權(quán)低代碼企業(yè)應(yīng)用【免費(fèi)下載鏈接】gin-vue-adminViteVue3Gin的開發(fā)基礎(chǔ)平臺(tái)支持TS和JS混用。它集成了JWT鑒權(quán)、權(quán)限管理、動(dòng)態(tài)路由、顯隱可控組件、分頁(yè)封裝、多點(diǎn)登錄攔截、資源權(quán)限、上傳下載、代碼生成器【可AI輔助】、表單生成器和可配置的導(dǎo)入導(dǎo)出等開發(fā)必備功能。項(xiàng)目地址https://gitcode.com/flipped-aurora/gin-vue-admin點(diǎn)擊查看免費(fèi)下載本文以.cursor/rules/project_rules.md為切入點(diǎn)講清楚 gin-vue-admin 是如何用薄適配層 單一真源AGENT.MD 結(jié)構(gòu)化文檔層aiDoc/三層結(jié)構(gòu)來(lái)組織面向 AI 的項(xiàng)目規(guī)則的讀完你不僅能看懂這個(gè)適配文件為什么只有 20 多行還能掌握它背后的讀取順序、維護(hù)約束以及如何在規(guī)則變更時(shí)正確地更新各層文件。一、適配文件本身一個(gè)刻意做薄的兼容入口.cursor/rules/project_rules.md全文極短開頭是一段 YAML frontmatter隨后只有真實(shí)規(guī)則入口和適配層約束兩節(jié)。frontmatter 的四個(gè)字段是整個(gè)設(shè)計(jì)的錨點(diǎn)--- tool: cursor role: compatibility-adapter canonical_source: /AGENT.MD structured_context: /aiDoc ---tool: cursor標(biāo)識(shí)該文件服務(wù)的工具Cursor 的 rules 自動(dòng)加載路徑role: compatibility-adapter聲明自己只是兼容適配層不承載獨(dú)立規(guī)則canonical_source: /AGENT.MD指向規(guī)則的唯一真源structured_context: /aiDoc指向結(jié)構(gòu)化上下文的根目錄。正文給出的真實(shí)規(guī)則入口要求按以下順序讀取/AGENT.MD/aiDoc/README.md/aiDoc/relations/、/aiDoc/modules/、/aiDoc/frontend-backend/、/aiDoc/examples/、/aiDoc/memory/中與當(dāng)前任務(wù)相關(guān)的文件而適配層約束則立下三條硬邊界不要在適配層擴(kuò)寫項(xiàng)目級(jí)規(guī)則規(guī)則變更時(shí)先更新/AGENT.MD與/aiDoc/工具目錄只保留薄適配層職責(zé)不再保存獨(dú)立的 project rule 副本。這個(gè)文件的本質(zhì)是一根指針——把 Cursor 的自動(dòng)加載能力橋接到真正被維護(hù)的那份規(guī)則上。二、單一真源AGENT.MD 到底寫了什么適配文件指向的 AGENT.MD 是整份規(guī)則的核心。它開篇即聲明本文件是本倉(cāng)庫(kù)內(nèi) AI 協(xié)作規(guī)則的唯一真源并明確.codex/、.claude/、.cursor/、.trae/下的規(guī)則文件僅作為兼容適配層不能再次演變成各自獨(dú)立維護(hù)的 project rule 副本。這正是 Cursor 適配文件里canonical_source三個(gè)字段的落地。AGENT.MD 的正文可以拆成幾塊逐一對(duì)應(yīng)到倉(cāng)庫(kù)里真實(shí)存在的目錄2.1 讀取順序與沖突裁決給出與適配文件一致的加載順序AGENT.MD → aiDoc/README.md → 按任務(wù)打開 aiDoc 各子目錄 → 僅在工具確實(shí)依賴時(shí)再讀工具目錄適配文件并規(guī)定若內(nèi)容沖突以AGENT.MD為準(zhǔn)。這一條是三層結(jié)構(gòu)能穩(wěn)定工作的前提真源擁有最高優(yōu)先級(jí)。2.2 倉(cāng)庫(kù)概覽AGENT.MD 用五行勾勒出倉(cāng)庫(kù)骨架與真實(shí)目錄一一對(duì)應(yīng)server/Go Gin 后端web/Vue 3 Vite 前端deploy/部署資產(chǎn)docs/項(xiàng)目文檔與設(shè)計(jì)記錄aiDoc/AI 協(xié)作文檔層這份概覽同時(shí)也是 aiDoc/relations/repo-profile.md 和 aiDoc/relations/system-map.md 所描述的對(duì)象前后兩處互相印證。2.3 工程規(guī)則跨任務(wù)、長(zhǎng)期穩(wěn)定的約束這是 AGENT.MD 的主體也是 AI 落碼時(shí)最常引用的部分按主題分為若干小節(jié)架構(gòu)保持Router - API - Service - Model分層enter.go作為分組注冊(cè)與組合入口API 層處理 HTTP 相關(guān)邏輯、Service 層不依賴gin.ContextSwagger 注釋必須與真實(shí)行為一致優(yōu)先沿用現(xiàn)有模式不做無(wú)關(guān)大改。這條分層約束在 aiDoc/modules/backend-layer-rules.md 中被進(jìn)一步展開并在 server/service/enter.go 里得到印證——ServiceGroupApp正是通過(guò)組合各子ServiceGroup暴露給 API 層引用的全局入口。前后端協(xié)作明確請(qǐng)求/響應(yīng)契約統(tǒng)一響應(yīng)結(jié)構(gòu){ code, data, msg }、統(tǒng)一分頁(yè)結(jié)構(gòu){ page, pageSize, total, list }前后端字段名與類型保持一致優(yōu)先復(fù)用web/src/utils/。分頁(yè)結(jié)構(gòu)可在 server/model/common/response/common.go 的PageResult中得到源碼級(jí)印證。插件與模塊后端插件放server/plugin/name/前端插件放web/src/plugin/name/穩(wěn)定職責(zé)沉淀到aiDoc/modules/。以 server/plugin/announcement/plugin.go 為例它通過(guò)interfaces.Register(Plugin)自注冊(cè)并實(shí)現(xiàn)Register(group)掛載初始化流程正符合插件自包含、入口統(tǒng)一的約定。示例文檔aiDoc/examples/是講解型示例層告訴 AI 該如何按項(xiàng)目標(biāo)準(zhǔn)組織代碼而非要求逐字復(fù)制AI 新增某一層文件前應(yīng)先讀對(duì)應(yīng)示例。記憶規(guī)則aiDoc/memory/long-term/存長(zhǎng)期穩(wěn)定偏好aiDoc/memory/business/存每次業(yè)務(wù)需求用戶提出業(yè)務(wù)需求時(shí)必須新增/更新一條business記憶并同步索引長(zhǎng)期穩(wěn)定后再提煉到long-term索引文件README.md、project-memory.md、demand-index.md只承擔(dān)索引職責(zé)不承載多條記憶正文。文檔維護(hù)AGENT.MD只留高層穩(wěn)定規(guī)則細(xì)節(jié)進(jìn)aiDoc/規(guī)則變化時(shí)先改AGENT.MD再按需更新適配層。版權(quán)與授權(quán)保護(hù)涉及版權(quán)/署名/許可證/品牌標(biāo)識(shí)的任務(wù)統(tǒng)一參考 aiDoc/relations/licensing-and-branding.md公開規(guī)則與口頭說(shuō)明沖突時(shí)以倉(cāng)庫(kù)內(nèi)可審計(jì)的事實(shí)為準(zhǔn)。代碼讀取約束任何情況下都不直接讀node_modules/里的代碼需了解第三方庫(kù)行為時(shí)優(yōu)先看調(diào)用方式、鎖文件、配置與包的公開類型/說(shuō)明文件。2.4 AI 文檔索引AGENT.MD 末尾給出了一組aiDoc/下的標(biāo)準(zhǔn)入口清單relations、modules、frontend-backend、examples、memory 各子目錄相當(dāng)于真源 → 結(jié)構(gòu)化上下文的路由表AI 按任務(wù)取用即可。三、結(jié)構(gòu)化上下文層aiDoc 如何把細(xì)節(jié)拆開維護(hù)適配文件里的structured_context: /aiDoc對(duì)應(yīng) aiDoc/README.md 描述的結(jié)構(gòu)化文檔層。它把長(zhǎng)期有效的項(xiàng)目上下文從工具私有目錄中抽離出來(lái)按主題拆成五類relations/倉(cāng)庫(kù)結(jié)構(gòu)、技術(shù)棧、依賴關(guān)系、開發(fā)流程modules/后端分層規(guī)則、插件結(jié)構(gòu)、模塊職責(zé)frontend-backend/前后端契約、前端規(guī)范、工具函數(shù)復(fù)用規(guī)則examples/講解型示例告訴 AI 每一層該按什么標(biāo)準(zhǔn)組織memory/AI 記憶層拆分為長(zhǎng)期記憶與業(yè)務(wù)記憶。aiDoc/README.md 的使用方式與 AGENT.MD 的讀取順序完全對(duì)齊先讀 AGENT.MD再看本索引按任務(wù)只打開相關(guān)子目錄且不再把項(xiàng)目級(jí)規(guī)則塞回各工具目錄。它的維護(hù)原則也復(fù)述了適配層約束的精神——穩(wěn)定規(guī)則放aiDoc/臨時(shí)會(huì)話草稿不入庫(kù)適用于所有 AI 的規(guī)則先寫進(jìn)AGENT.MD。3.1 契約與邊界frontend-backendaiDoc/frontend-backend/boundary.md 把前后端邊界落成可檢查的條款統(tǒng)一響應(yīng){ code, data, msg }、統(tǒng)一分頁(yè){ page, pageSize, total, list }、字段名不漂移、字段類型一致、Swagger 必須與實(shí)現(xiàn)一致涉及破壞性接口調(diào)整要先寫清變更范圍前端接口封裝繼續(xù)放在web/src/api/或web/src/plugin/name/api/可復(fù)用邏輯優(yōu)先復(fù)用web/src/utils/。它還給出完成前檢查清單讓跨棧改動(dòng)結(jié)束前能自校驗(yàn)響應(yīng)結(jié)構(gòu)、字段名與類型。3.2 記憶層long-term 與 business 的分工aiDoc/memory/README.md 明確了記憶不是普通筆記堆放區(qū)而是分兩類長(zhǎng)期記憶aiDoc/memory/long-term/記錄長(zhǎng)期穩(wěn)定的用戶偏好、協(xié)作方式、跨任務(wù)約束一條記憶一個(gè)獨(dú)立文件優(yōu)先更新對(duì)應(yīng)主題文件README.md只說(shuō)明規(guī)則、不承擔(dān)記憶正文。業(yè)務(wù)記憶aiDoc/memory/business/記錄每次用戶提出的業(yè)務(wù)需求新增模塊/接口/頁(yè)面/流程/規(guī)則活躍需求在business/active/已完成的在business/done/demand-index.md只存索引。配套的 aiDoc/memory/business/TEMPLATE.md 給出標(biāo)準(zhǔn)需求條目模板基本信息狀態(tài)、類型、優(yōu)先級(jí)、用戶原始意圖摘要、影響范圍后端/前端/文檔/插件模塊、涉及對(duì)象模塊/接口/頁(yè)面/配置、已確認(rèn)約束、當(dāng)前進(jìn)展、后續(xù)待辦與更新規(guī)則。而 aiDoc/memory/business/demand-index.md 則是一個(gè)真實(shí)的索引文件按Active/Done分組列出需求鏈接——這正是索引不承載正文原則的實(shí)例。3.3 示例層examples 的定位aiDoc/examples/README.md 強(qiáng)調(diào)示例文檔不是要求逐字復(fù)制代碼而是告訴 AI 某一層文件應(yīng)承擔(dān)什么職責(zé)、推薦什么組織方式、常見錯(cuò)誤是什么、真正可參考哪些現(xiàn)成文件并按新增后端能力 / 新增前端能力 / 新增插件給出不同的讀取順序。它與 AGENT.MD示例文檔小節(jié)互為呼應(yīng)。四、四種工具適配層的橫向?qū)Ρ冗m配層設(shè)計(jì)的核心是讓每個(gè) AI 工具用自己的加載路徑讀同一份規(guī)則。倉(cāng)庫(kù)里對(duì)應(yīng)著幾個(gè)project_rules.md工具目錄形態(tài)作用.cursor/rules/project_rules.md薄適配層~25 行指向 AGENT.MD 與 aiDoc.claude/rules/project_rules.md薄適配層同上并額外強(qiáng)調(diào)代碼讀取約束以 AGENT.MD 為準(zhǔn).codex/rules/project_rules.md薄適配層同上.trae/rules/project_rules.md薄適配層同上這四個(gè)文件 frontmatter 結(jié)構(gòu)一致role: compatibility-adapter、canonical_source: /AGENT.MD、structured_context: /aiDoc正文也幾乎相同只是把標(biāo)題與本文件只用于兼容 XX 現(xiàn)有的自動(dòng)加載路徑換成各自工具名。它們刻意保持同構(gòu)意味著任何一處規(guī)則演進(jìn)都不需要分別維護(hù)四份副本——只改AGENT.MD與aiDoc/適配層自動(dòng)透?jìng)髯钚抡嬖?。值得注意的?aone_copilot/rules/project_rules.md走的是另一條路線它不是薄適配層而是一份內(nèi)容完整的獨(dú)立規(guī)則文件直接內(nèi)嵌了項(xiàng)目技術(shù)棧清單、角色與目標(biāo)、GVA Helper / MCP 工作流、后端/前端各層開發(fā)規(guī)范與插件結(jié)構(gòu)。從源碼結(jié)構(gòu)看這形成了一個(gè)鮮明對(duì)照——薄適配 單一真源與自包含厚規(guī)則兩種組織方式并存而 Cursor/Claude/Codex/Trae 選擇了前者以換取單一來(lái)源、多工具復(fù)用、不復(fù)制副本的一致性優(yōu)勢(shì)。五、這套三層結(jié)構(gòu)如何落地到真實(shí)代碼規(guī)則不是懸浮的口號(hào)而是映射到倉(cāng)庫(kù)的真實(shí)分層。以 aiDoc/relations/system-map.md 描述的流向?yàn)槔蠖吮３謗outer/ → api/ → service/ → model/enter.go繼續(xù)承擔(dān)組合與暴露入口前端遵循src/api/ 或 src/plugin/name/api/ → src/pinia/ → src/router/ → src/view/ → src/utils/的依賴方向插件盡量保持前后端結(jié)構(gòu)對(duì)稱后端server/plugin/name/、前端web/src/plugin/name/。AGENT.MD 的工程規(guī)則、aiDoc/modules/的分層約束、aiDoc/frontend-backend/的契約條款最終都收斂到這些可被打開、可被驗(yàn)證的具體文件上形成真源定調(diào) → 結(jié)構(gòu)化層細(xì)化 → 適配層透?jìng)?→ 源碼印證的閉環(huán)。六、規(guī)則變更時(shí)的正確維護(hù)姿勢(shì)綜合三份文件的約束維護(hù)規(guī)則應(yīng)遵循這條固定路徑改真源凡是適用于所有 AI 的項(xiàng)目級(jí)規(guī)則變化先改 AGENT.MD保持它高層、穩(wěn)定、跨任務(wù)。下沉細(xì)節(jié)把細(xì)節(jié)上下文寫進(jìn) aiDoc/ 對(duì)應(yīng)子目錄結(jié)構(gòu)進(jìn)relations/、示例進(jìn)examples/、長(zhǎng)期/業(yè)務(wù)記憶進(jìn)memory/、分層與插件進(jìn)modules/、契約進(jìn)frontend-backend/。透?jìng)鬟m配層.cursor/、.claude/、.codex/、.trae/下的薄適配文件不單獨(dú)改寫只在確需時(shí)同步指向嚴(yán)禁在適配層里擴(kuò)寫項(xiàng)目級(jí)規(guī)則或保存獨(dú)立副本。同步業(yè)務(wù)記憶一旦用戶提出業(yè)務(wù)需求就更新aiDoc/memory/business/下對(duì)應(yīng)條目并維護(hù)demand-index.md索引只有模式跨任務(wù)穩(wěn)定后才提煉到long-term/。沖突裁決任何層之間內(nèi)容沖突時(shí)一律以AGENT.MD為準(zhǔn)。這套機(jī)制的實(shí)際收益是多工具共用同一份規(guī)則、避免副本漂移、細(xì)節(jié)按主題可檢索、記憶與索引職責(zé)清晰且每一處約束都能在倉(cāng)庫(kù)內(nèi)找到對(duì)應(yīng)的真實(shí)文件佐證。對(duì)于要在該倉(cāng)庫(kù)里引入 AI 協(xié)作或新增 AI 工具的團(tuán)隊(duì)來(lái)說(shuō)新增一個(gè)薄適配文件 復(fù)用 AGENT.MD 與 aiDoc就是成本最低、最不易出錯(cuò)的接入方式。贊分享后端前端認(rèn)證鑒權(quán)低代碼企業(yè)應(yīng)用【免費(fèi)下載鏈接】gin-vue-adminViteVue3Gin的開發(fā)基礎(chǔ)平臺(tái)支持TS和JS混用。它集成了JWT鑒權(quán)、權(quán)限管理、動(dòng)態(tài)路由、顯隱可控組件、分頁(yè)封裝、多點(diǎn)登錄攔截、資源權(quán)限、上傳下載、代碼生成器【可AI輔助】、表單生成器和可配置的導(dǎo)入導(dǎo)出等開發(fā)必備功能。項(xiàng)目地址https://gitcode.com/flipped-aurora/gin-vue-admin點(diǎn)擊查看免費(fèi)下載相關(guān)推薦為 AI 構(gòu)建長(zhǎng)期記憶gin-vue-admin 倉(cāng)庫(kù)中 aiDoc 記憶層的目錄設(shè)計(jì)與寫入規(guī)則為 AI 構(gòu)建長(zhǎng)期記憶gin vue admin 倉(cāng)庫(kù)中 aiDoc 記憶層的目錄設(shè)計(jì)與寫入規(guī)則 長(zhǎng)期記憶long term memory是 AI 協(xié)后端前端認(rèn)證鑒權(quán)低代碼企業(yè)應(yīng)用HyperFrames v0.7.72內(nèi)容尋址 Plan v2 繞開 2 GiB 分布式渲染上限音頻時(shí)長(zhǎng)對(duì)齊采樣時(shí)間線HyperFrames v0.7.72內(nèi)容尋址 Plan v2 繞開 2 GiB 分布式渲染上限音頻時(shí)長(zhǎng)對(duì)齊采樣時(shí)間線 HyperFrames v0.7.7音視頻視頻AI 技能gin-vue-admin 用戶長(zhǎng)期偏好文檔解析AI 記憶層的單條一文件管理與中文協(xié)作約定gin vue admin 用戶長(zhǎng)期偏好文檔解析AI 記憶層的單條一文件管理與中文協(xié)作約定 導(dǎo)讀 本文圍繞 aiDoc/memory/long term/后端前端認(rèn)證鑒權(quán)低代碼任務(wù)調(diào)度創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考