接手一个 3 年老项目打开api/axios.ts看到 800 行代码——拦截器里塞了鉴权、品牌切换、错误提示、日志、重试……每次改一个逻辑都怕影响别的。我把这个文件丢给 AI让它帮我重新设计架构。最终方案洋葱模型每个关注点一个中间件互不干扰。原始状态axios.ts (800行) ├── 请求拦截器 (200行) │ ├── 鉴权 token 注入 │ ├── brandId 注入 │ ├── 环境判断 │ ├── 请求日志 │ └── 特殊 URL 处理 ├── 响应拦截器 (400行) │ ├── 登录过期处理 │ ├── 权限不足处理 │ ├── 网络错误处理 │ ├── 业务错误码映射 │ ├── 错误弹窗逻辑 │ └── 重试逻辑 └── 工具函数 (200行)改一行都心惊肉跳。AI 给出的分层设计请求生命周期洋葱模型 请求方向 → ┌─────────────────────────────────────────────┐ │ Layer 1: Auth鉴权 │ │ ┌───────────────────────────────────────┐ │ │ │ Layer 2: BrandId品牌注入 │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │ │ Layer 3: ErrorHandler错误 │ │ │ │ │ │ ┌───────────────────────────┐ │ │ │ │ │ │ │ 实际网络请求 │ │ │ │ │ │ │ └───────────────────────────┘ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ └───────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ ← 响应方向每一层只管一件事新增需求加一层删除需求去掉一层不影响其他层。关键代码拦截器拆分改造前混在一起axios.interceptors.request.use((config){// 50行鉴权逻辑consttokengetToken()if(token)config.headers.Authorizationtoken// 30行品牌逻辑constbrandIdgetBrandId()if(brandId)config.headers[X-Brand-Id]brandId// 20行环境逻辑if(process.env.API_ENVtest){...}// ...更多returnconfig})改造后各管各的// interceptors/auth.tsexportconstauthInterceptor{request:(config:AxiosRequestConfig){consttokengetToken()if(token){config.headers.Authorizationtoken}returnconfig},responseError:(error:AxiosError){if(error.response?.status401){handleLogout()}returnPromise.reject(error)},}// interceptors/brandId.tsexportconstbrandIdInterceptor{request:(config:AxiosRequestConfig){constbrandIdgetBrandId()if(brandId){config.headers[X-Brand-Id]brandId}returnconfig},}// interceptors/errorHandler.tsexportconsterrorHandlerInterceptor{responseError:(error:AxiosError){const{status,data}error.response||{}constmsgERROR_CODE_MAP[data?.code]||网络异常message.error(msg)returnPromise.reject(error)},}注册// api/axios.ts现在只有 30 行constinstanceaxios.create({baseURL:PROXY_URL,timeout:15000})constinterceptors[authInterceptor,brandIdInterceptor,errorHandlerInterceptor,]interceptors.forEach(({request,response,responseError}){if(request)instance.interceptors.request.use(request)if(response)instance.interceptors.response.use(response)if(responseError)instance.interceptors.response.use(undefined,responseError)})exportdefaultinstanceAI 在这个过程中做了什么我的输入 ├── 这是我的 axios.ts帮我重构 ├── 要求每个关注点分离可独立测试 └── 保持对外 API 不变调用方零改动 AI 的输出 ├── 架构建议洋葱模型 vs 管道模式 vs 装饰器模式 ├── 每个拦截器的独立文件 ├── 注册逻辑 └── 一个我没想到的点拦截器执行顺序说明拦截器顺序的坑AI 特别提醒了一个 axios 的行为请求拦截器后注册的先执行栈结构 响应拦截器先注册的先执行队列结构 所以注册顺序要反着想 interceptors [auth, brandId, errorHandler] 实际请求执行顺序errorHandler → brandId → auth → [网络] → auth → brandId → errorHandler这个如果不注意鉴权失败时的错误处理顺序会出问题。AI 在设计阶段就帮我规避了。对外接口不变改造前怎么用的改造后还是怎么用// 业务层调用——零改动importrequestfrom/api/axiosexportconstgetStoreList(params:StoreListParams)request.get(/store/list,{params})这就是重构的核心原则内部随便改外部无感知。收益改造前 ├── 800 行单文件改一行可能影响全部 ├── 无法单独测试某个拦截逻辑 ├── 新人看完需要 2h 才能理解 └── 加新功能如请求加密需要在 3 个地方改 改造后 ├── 主文件 30 行每个拦截器 30-50 行 ├── 每个拦截器可独立 mock 测试 ├── 新人 10min 理解整体架构 └── 加新功能 加一个文件 注册一行什么时候该重构请求层值得重构 ├── 拦截器超过 100 行 ├── 多个不相关逻辑写在同一个拦截器 ├── 改一个功能总担心影响其他 └── 新人入职搞不懂请求层做了什么 不需要的 ├── 项目小拦截器 50 行 ├── 逻辑简单只有 token 注入 错误提示 └── 没人维护的遗留项目 你们项目的请求层是什么状态有没有类似的上帝文件想重构但不敢动完整 Skills 源码已开源github.com/sleepyccat/ai-native-workflow欢迎 Star ⭐ 和 PR。