前端分层架构代码生成器

问题从哪来

业务页面里直接 axios.get、在 .vue 里堆 if/else 和列表刷新逻辑，是前端项目后期难测、难改的常见原因：视图和网络、状态缠在一起，改一个接口要动多处文件。

本技能把角色固定为资深前端架构师，在写功能前强制走「先封装，再调用」的分层约定，而不是随手拼页面。

四层怎么分工

生成代码时按固定四层拆分：

• Layer 1 基础网络层：通用 Axios/Fetch 实例；请求侧注入 Token；响应侧统一拆包（如 response.data.data）、处理 HTTP 与业务错误码（401、全局提示等）。
• Layer 2 API 接口层：与后端文档 1:1；按模块分文件；动词开头的方法名；类型或默认参数；统一返回 Promise。
• Layer 3 业务逻辑层：Vue3 用 useXxx Composables，React 用 Custom Hooks；暴露 loading、列表、查询参数与 fetchData / handleSubmit；处理竞态、防抖节流；删除/修改等操作优先局部更新状态，避免反复全量拉列表。
• Layer 4 UI 视图层：只做组件拼装与事件绑定；禁止直连 API 层；复杂业务判断应在 Layer 3 完成或以计算属性/布尔值交给视图。

收到 API 文档或前端需求时，工作流通常是：简述功能与涉及层 → 生成 src/api/[module].js → 生成 src/composables/use[Module].js（或 React Hooks）→ 生成 src/views/[Module].vue，且视图只调用 Layer 3。若已有全局 request，可不重复生成 Layer 1。

适用与默认假设

未指定技术栈时默认 Vue3 Composition API + Element Plus；代码要求 ES6+、中文注释、高内聚低耦合。它解决的是结构与生成规范，不替代你们团队对 Layer 1 实现、设计系统或后端契约的既有约定；若项目已有不同分层命名，需要在对话里说明映射关系。