后端前端认证鉴权低代码企业应用【免费下载链接】gin-vue-adminViteVue3Gin的开发基础平台支持TS和JS混用。它集成了JWT鉴权、权限管理、动态路由、显隐可控组件、分页封装、多点登录拦截、资源权限、上传下载、代码生成器【可AI辅助】、表单生成器和可配置的导入导出等开发必备功能。项目地址https://gitcode.com/flipped-aurora/gin-vue-admin点击查看免费下载本文以.cursor/rules/project_rules.md为切入点讲清楚 gin-vue-admin 是如何用薄适配层 单一真源AGENT.MD 结构化文档层aiDoc/三层结构来组织面向 AI 的项目规则的读完你不仅能看懂这个适配文件为什么只有 20 多行还能掌握它背后的读取顺序、维护约束以及如何在规则变更时正确地更新各层文件。一、适配文件本身一个刻意做薄的兼容入口.cursor/rules/project_rules.md全文极短开头是一段 YAML frontmatter随后只有真实规则入口和适配层约束两节。frontmatter 的四个字段是整个设计的锚点--- tool: cursor role: compatibility-adapter canonical_source: /AGENT.MD structured_context: /aiDoc ---tool: cursor标识该文件服务的工具Cursor 的 rules 自动加载路径role: compatibility-adapter声明自己只是兼容适配层不承载独立规则canonical_source: /AGENT.MD指向规则的唯一真源structured_context: /aiDoc指向结构化上下文的根目录。正文给出的真实规则入口要求按以下顺序读取/AGENT.MD/aiDoc/README.md/aiDoc/relations/、/aiDoc/modules/、/aiDoc/frontend-backend/、/aiDoc/examples/、/aiDoc/memory/中与当前任务相关的文件而适配层约束则立下三条硬边界不要在适配层扩写项目级规则规则变更时先更新/AGENT.MD与/aiDoc/工具目录只保留薄适配层职责不再保存独立的 project rule 副本。这个文件的本质是一根指针——把 Cursor 的自动加载能力桥接到真正被维护的那份规则上。二、单一真源AGENT.MD 到底写了什么适配文件指向的 AGENT.MD 是整份规则的核心。它开篇即声明本文件是本仓库内 AI 协作规则的唯一真源并明确.codex/、.claude/、.cursor/、.trae/下的规则文件仅作为兼容适配层不能再次演变成各自独立维护的 project rule 副本。这正是 Cursor 适配文件里canonical_source三个字段的落地。AGENT.MD 的正文可以拆成几块逐一对应到仓库里真实存在的目录2.1 读取顺序与冲突裁决给出与适配文件一致的加载顺序AGENT.MD → aiDoc/README.md → 按任务打开 aiDoc 各子目录 → 仅在工具确实依赖时再读工具目录适配文件并规定若内容冲突以AGENT.MD为准。这一条是三层结构能稳定工作的前提真源拥有最高优先级。2.2 仓库概览AGENT.MD 用五行勾勒出仓库骨架与真实目录一一对应server/Go Gin 后端web/Vue 3 Vite 前端deploy/部署资产docs/项目文档与设计记录aiDoc/AI 协作文档层这份概览同时也是 aiDoc/relations/repo-profile.md 和 aiDoc/relations/system-map.md 所描述的对象前后两处互相印证。2.3 工程规则跨任务、长期稳定的约束这是 AGENT.MD 的主体也是 AI 落码时最常引用的部分按主题分为若干小节架构保持Router - API - Service - Model分层enter.go作为分组注册与组合入口API 层处理 HTTP 相关逻辑、Service 层不依赖gin.ContextSwagger 注释必须与真实行为一致优先沿用现有模式不做无关大改。这条分层约束在 aiDoc/modules/backend-layer-rules.md 中被进一步展开并在 server/service/enter.go 里得到印证——ServiceGroupApp正是通过组合各子ServiceGroup暴露给 API 层引用的全局入口。前后端协作明确请求/响应契约统一响应结构{ code, data, msg }、统一分页结构{ page, pageSize, total, list }前后端字段名与类型保持一致优先复用web/src/utils/。分页结构可在 server/model/common/response/common.go 的PageResult中得到源码级印证。插件与模块后端插件放server/plugin/name/前端插件放web/src/plugin/name/稳定职责沉淀到aiDoc/modules/。以 server/plugin/announcement/plugin.go 为例它通过interfaces.Register(Plugin)自注册并实现Register(group)挂载初始化流程正符合插件自包含、入口统一的约定。示例文档aiDoc/examples/是讲解型示例层告诉 AI 该如何按项目标准组织代码而非要求逐字复制AI 新增某一层文件前应先读对应示例。记忆规则aiDoc/memory/long-term/存长期稳定偏好aiDoc/memory/business/存每次业务需求用户提出业务需求时必须新增/更新一条business记忆并同步索引长期稳定后再提炼到long-term索引文件README.md、project-memory.md、demand-index.md只承担索引职责不承载多条记忆正文。文档维护AGENT.MD只留高层稳定规则细节进aiDoc/规则变化时先改AGENT.MD再按需更新适配层。版权与授权保护涉及版权/署名/许可证/品牌标识的任务统一参考 aiDoc/relations/licensing-and-branding.md公开规则与口头说明冲突时以仓库内可审计的事实为准。代码读取约束任何情况下都不直接读node_modules/里的代码需了解第三方库行为时优先看调用方式、锁文件、配置与包的公开类型/说明文件。2.4 AI 文档索引AGENT.MD 末尾给出了一组aiDoc/下的标准入口清单relations、modules、frontend-backend、examples、memory 各子目录相当于真源 → 结构化上下文的路由表AI 按任务取用即可。三、结构化上下文层aiDoc 如何把细节拆开维护适配文件里的structured_context: /aiDoc对应 aiDoc/README.md 描述的结构化文档层。它把长期有效的项目上下文从工具私有目录中抽离出来按主题拆成五类relations/仓库结构、技术栈、依赖关系、开发流程modules/后端分层规则、插件结构、模块职责frontend-backend/前后端契约、前端规范、工具函数复用规则examples/讲解型示例告诉 AI 每一层该按什么标准组织memory/AI 记忆层拆分为长期记忆与业务记忆。aiDoc/README.md 的使用方式与 AGENT.MD 的读取顺序完全对齐先读 AGENT.MD再看本索引按任务只打开相关子目录且不再把项目级规则塞回各工具目录。它的维护原则也复述了适配层约束的精神——稳定规则放aiDoc/临时会话草稿不入库适用于所有 AI 的规则先写进AGENT.MD。3.1 契约与边界frontend-backendaiDoc/frontend-backend/boundary.md 把前后端边界落成可检查的条款统一响应{ code, data, msg }、统一分页{ page, pageSize, total, list }、字段名不漂移、字段类型一致、Swagger 必须与实现一致涉及破坏性接口调整要先写清变更范围前端接口封装继续放在web/src/api/或web/src/plugin/name/api/可复用逻辑优先复用web/src/utils/。它还给出完成前检查清单让跨栈改动结束前能自校验响应结构、字段名与类型。3.2 记忆层long-term 与 business 的分工aiDoc/memory/README.md 明确了记忆不是普通笔记堆放区而是分两类长期记忆aiDoc/memory/long-term/记录长期稳定的用户偏好、协作方式、跨任务约束一条记忆一个独立文件优先更新对应主题文件README.md只说明规则、不承担记忆正文。业务记忆aiDoc/memory/business/记录每次用户提出的业务需求新增模块/接口/页面/流程/规则活跃需求在business/active/已完成的在business/done/demand-index.md只存索引。配套的 aiDoc/memory/business/TEMPLATE.md 给出标准需求条目模板基本信息状态、类型、优先级、用户原始意图摘要、影响范围后端/前端/文档/插件模块、涉及对象模块/接口/页面/配置、已确认约束、当前进展、后续待办与更新规则。而 aiDoc/memory/business/demand-index.md 则是一个真实的索引文件按Active/Done分组列出需求链接——这正是索引不承载正文原则的实例。3.3 示例层examples 的定位aiDoc/examples/README.md 强调示例文档不是要求逐字复制代码而是告诉 AI 某一层文件应承担什么职责、推荐什么组织方式、常见错误是什么、真正可参考哪些现成文件并按新增后端能力 / 新增前端能力 / 新增插件给出不同的读取顺序。它与 AGENT.MD示例文档小节互为呼应。四、四种工具适配层的横向对比适配层设计的核心是让每个 AI 工具用自己的加载路径读同一份规则。仓库里对应着几个project_rules.md工具目录形态作用.cursor/rules/project_rules.md薄适配层~25 行指向 AGENT.MD 与 aiDoc.claude/rules/project_rules.md薄适配层同上并额外强调代码读取约束以 AGENT.MD 为准.codex/rules/project_rules.md薄适配层同上.trae/rules/project_rules.md薄适配层同上这四个文件 frontmatter 结构一致role: compatibility-adapter、canonical_source: /AGENT.MD、structured_context: /aiDoc正文也几乎相同只是把标题与本文件只用于兼容 XX 现有的自动加载路径换成各自工具名。它们刻意保持同构意味着任何一处规则演进都不需要分别维护四份副本——只改AGENT.MD与aiDoc/适配层自动透传最新真源。值得注意的是.aone_copilot/rules/project_rules.md走的是另一条路线它不是薄适配层而是一份内容完整的独立规则文件直接内嵌了项目技术栈清单、角色与目标、GVA Helper / MCP 工作流、后端/前端各层开发规范与插件结构。从源码结构看这形成了一个鲜明对照——薄适配 单一真源与自包含厚规则两种组织方式并存而 Cursor/Claude/Codex/Trae 选择了前者以换取单一来源、多工具复用、不复制副本的一致性优势。五、这套三层结构如何落地到真实代码规则不是悬浮的口号而是映射到仓库的真实分层。以 aiDoc/relations/system-map.md 描述的流向为例后端保持router/ → api/ → service/ → model/enter.go继续承担组合与暴露入口前端遵循src/api/ 或 src/plugin/name/api/ → src/pinia/ → src/router/ → src/view/ → src/utils/的依赖方向插件尽量保持前后端结构对称后端server/plugin/name/、前端web/src/plugin/name/。AGENT.MD 的工程规则、aiDoc/modules/的分层约束、aiDoc/frontend-backend/的契约条款最终都收敛到这些可被打开、可被验证的具体文件上形成真源定调 → 结构化层细化 → 适配层透传 → 源码印证的闭环。六、规则变更时的正确维护姿势综合三份文件的约束维护规则应遵循这条固定路径改真源凡是适用于所有 AI 的项目级规则变化先改 AGENT.MD保持它高层、稳定、跨任务。下沉细节把细节上下文写进 aiDoc/ 对应子目录结构进relations/、示例进examples/、长期/业务记忆进memory/、分层与插件进modules/、契约进frontend-backend/。透传适配层.cursor/、.claude/、.codex/、.trae/下的薄适配文件不单独改写只在确需时同步指向严禁在适配层里扩写项目级规则或保存独立副本。同步业务记忆一旦用户提出业务需求就更新aiDoc/memory/business/下对应条目并维护demand-index.md索引只有模式跨任务稳定后才提炼到long-term/。冲突裁决任何层之间内容冲突时一律以AGENT.MD为准。这套机制的实际收益是多工具共用同一份规则、避免副本漂移、细节按主题可检索、记忆与索引职责清晰且每一处约束都能在仓库内找到对应的真实文件佐证。对于要在该仓库里引入 AI 协作或新增 AI 工具的团队来说新增一个薄适配文件 复用 AGENT.MD 与 aiDoc就是成本最低、最不易出错的接入方式。赞分享后端前端认证鉴权低代码企业应用【免费下载链接】gin-vue-adminViteVue3Gin的开发基础平台支持TS和JS混用。它集成了JWT鉴权、权限管理、动态路由、显隐可控组件、分页封装、多点登录拦截、资源权限、上传下载、代码生成器【可AI辅助】、表单生成器和可配置的导入导出等开发必备功能。项目地址https://gitcode.com/flipped-aurora/gin-vue-admin点击查看免费下载相关推荐为 AI 构建长期记忆gin-vue-admin 仓库中 aiDoc 记忆层的目录设计与写入规则为 AI 构建长期记忆gin vue admin 仓库中 aiDoc 记忆层的目录设计与写入规则 长期记忆long term memory是 AI 协后端前端认证鉴权低代码企业应用HyperFrames v0.7.72内容寻址 Plan v2 绕开 2 GiB 分布式渲染上限音频时长对齐采样时间线HyperFrames v0.7.72内容寻址 Plan v2 绕开 2 GiB 分布式渲染上限音频时长对齐采样时间线 HyperFrames v0.7.7音视频视频AI 技能gin-vue-admin 用户长期偏好文档解析AI 记忆层的单条一文件管理与中文协作约定gin vue admin 用户长期偏好文档解析AI 记忆层的单条一文件管理与中文协作约定 导读 本文围绕 aiDoc/memory/long term/后端前端认证鉴权低代码任务调度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考