一、起因一个“偷懒”的决定事情发生在上个月。公司临时启动了一个新的移动端项目排期紧、需求杂我负责搭网络请求层——说白了就是封装 axios 拦截器、统一处理 token 过期和接口错误码。这种活儿我干了不下五遍了从 jQuery 时代的 $.ajax 封装到后来 fetch 拦截器再到现在的 axios 实例工厂模板代码翻来覆去就那几套。那天下午我盯着屏幕发呆心想与其手动敲这些重复的拦截器逻辑不如让 AI 帮我写个初版我改改就完事。毕竟这种基础架构代码大家写出来都差不多AI 应该能胜任。于是我把需求描述给了 AI包括基础请求封装、请求/响应拦截器、自动携带 token、401 自动跳登录页、统一错误提示、接口缓存支持等。AI 返回的代码结构出乎意料地完整——该有的拦截器、错误处理、方法暴露都有。但真正让我震惊的是当我把它放到项目里跑通之后同事来 review 代码看了一眼说了句“这代码风格一看就是你写的。” 我愣了一下因为那代码确实不是我自己逐行敲的。这件事让我开始琢磨AI 生成的代码到底能不能直接用在生产项目它写出来的东西为什么看起来像我个人风格以及在这个过程中我踩了哪些坑二、AI 生成的代码到底长什么样先说结论AI 生成的代码在结构上是合格的甚至比很多初级工程师写的更规范。但它并不是直接就能用的需要做大量的定制和修正。我让 AI 写了一个最基础的请求模块它返回了这样的内容一个 Request 类构造函数接收 baseURL 和默认配置请求拦截器里自动注入 token响应拦截器里统一处理 200、401、500 状态暴露 get、post、put、delete 四个方法一个简单的缓存工具类支持 localStorage 存储看起来挺全的。但问题出现在细节上它把 token 的获取写死了从 localStorage 取而我们项目是从 indexDB 读取的错误提示用了 alert这在移动端 H5 里没问题但在小程序环境里根本用不了缓存逻辑里没有考虑过期时间只是简单的 set/get没有处理并发请求时的 token 刷新问题如果 token 过期多个请求同时进来会重复刷新这些都不是 AI 的错是我的提示词写得太笼统了。AI 只能根据它训练数据里的“常见做法”来生成而每个公司、每个项目的实际场景都有差异。三、踩坑实录我改掉了哪些地方改代码的过程其实比我自己从头写还费劲因为要理解 AI 的意图再覆盖它的逻辑。但好处是它帮我搭好了骨架我只需要填充血肉。第一个坑错误处理太粗暴AI 写的响应拦截器里只要 status 不是 200就直接调用一个统一的 errorHandler。但在实际项目中不同的错误码需要不同的处理方式。比如 403 需要弹窗提示权限不足500 需要提示服务器繁忙而 422 需要把后端返回的字段级错误展示在表单旁边。我改成了根据 errorCode 分发到不同的处理函数并且支持外部传入自定义 handler。第二个坑缓存设计太简陋AI 的缓存实现是 key-value 对每次请求前先去缓存里查有就直接返回。但没考虑缓存失效、缓存清除、缓存 key 的生成规则。我加了一个时间戳字段每次缓存时记录当前时间 过期时长读取时判断是否过期。同时支持手动清除单个或全部缓存。另外缓存 key 不能只用 url还要带上参数否则不同参数的相同接口会互相污染。第三个坑没有请求取消机制移动端场景里页面切换频繁如果前一个页面的请求还没完成可能会导致数据覆盖或者内存泄漏。AI 完全没有处理这个。我加了一个 cancelToken 的队列每个请求生成一个唯一的 cancelToken在组件销毁时调用 cancel 方法取消未完成的请求。这个改动虽然不大但很关键。第四个坑类型推导不够严谨项目用的是 TypeScriptAI 虽然生成了类型声明但很多地方用了 any。比如请求参数的泛型、响应数据的泛型都是 any。我把它们改成了泛型约束让每个接口方法都能推导出返回数据的类型。这样在调用的时候IDE 就能自动补全字段减少运行时错误。四、为什么同事觉得“像我自己写的”这个问题我后来仔细想了想发现原因其实很简单AI 生成的代码在结构上是中性的没有个人风格。但当我修改它的时候我下意识地按照自己的习惯去调整变量命名用驼峰还是下划线、注释写在哪里、换行风格、错误处理是抛异常还是返回 null、工具函数是放在类里还是独立导出……这些微小的选择最终让代码带上了我的印记。同事之所以觉得像是因为他看到的是我修改后的版本而不是 AI 的原版。而我在修改时并没有刻意去改变风格只是按照自己一贯的方式去“完善”它。这其实说明了一个道理AI 能帮你完成 70% 的模板代码但剩下 30% 的定制和决策才是真正体现个人经验和工程能力的地方。另外我还发现一个有趣的点AI 生成的代码里函数命名往往比较长且啰嗦比如handleTokenExpiredAndRedirectToLogin。我习惯用更短的命名比如handleTokenExpire因为移动端代码行宽有限长命名在代码 review 时很难一眼看清。这个差异也被同事注意到了。五、落地实践建议怎么用好 AI 写基础代码经过这次实践我总结了几条可落地的建议给想用 AI 辅助写代码的同行参考提示词要写具体场景不要只说“写一个请求封装”要说“写一个移动端 H5 的请求封装使用 axiostoken 从 indexDB 读取错误提示用 toast 组件支持请求取消”。越具体AI 输出的代码越接近可用状态。先搭骨架再填肉让 AI 生成核心结构和主要方法然后自己逐行 review替换掉那些不适合你项目的默认实现。不要偷懒直接复制粘贴。关注边界情况AI 容易忽略边界比如网络超时、并发请求、缓存穿透、内存泄漏。这些需要你在 review 时主动补全。保持代码一致性如果团队有代码规范ESLint、Prettier在 AI 输出后立即格式化一遍把命名风格、缩进、引号都统一成团队标准。不要期望一步到位AI 给你的是一个初稿而不是最终产品。把它当成一个高级实习生写的代码需要你来把关和优化。总结这次用 AI 写 API 层的经历让我意识到AI 不是替代品是加速器。它帮我节省了敲模板代码的时间但并没有减少我对代码的理解和决策。同事那句“像你自己写的”其实是对我修改工作的认可而不是对 AI 的认可。如果你也想尝试用 AI 辅助写基础架构代码我的建议是大胆用但别全信。把它当成一个高效的工具而不是一个完美的解决方案。最终的代码质量还是取决于你对业务的理解和对细节的把控。对了那个 AI 生成的缓存模块我后来彻底重写了因为它没有考虑 LRU 淘汰策略在列表页频繁切换的场景下缓存会越堆越多。这又是一个新的坑但那是另一个故事了。
一、起因一个“偷懒”的决定事情发生在上个月。公司临时启动了一个新的移动端项目排期紧、需求杂我负责搭网络请求层——说白了就是封装 axios 拦截器、统一处理 token 过期和接口错误码。这种活儿我干了不下五遍了从 jQuery 时代的 $.ajax 封装到后来 fetch 拦截器再到现在的 axios 实例工厂模板代码翻来覆去就那几套。那天下午我盯着屏幕发呆心想与其手动敲这些重复的拦截器逻辑不如让 AI 帮我写个初版我改改就完事。毕竟这种基础架构代码大家写出来都差不多AI 应该能胜任。于是我把需求描述给了 AI包括基础请求封装、请求/响应拦截器、自动携带 token、401 自动跳登录页、统一错误提示、接口缓存支持等。AI 返回的代码结构出乎意料地完整——该有的拦截器、错误处理、方法暴露都有。但真正让我震惊的是当我把它放到项目里跑通之后同事来 review 代码看了一眼说了句“这代码风格一看就是你写的。” 我愣了一下因为那代码确实不是我自己逐行敲的。这件事让我开始琢磨AI 生成的代码到底能不能直接用在生产项目它写出来的东西为什么看起来像我个人风格以及在这个过程中我踩了哪些坑二、AI 生成的代码到底长什么样先说结论AI 生成的代码在结构上是合格的甚至比很多初级工程师写的更规范。但它并不是直接就能用的需要做大量的定制和修正。我让 AI 写了一个最基础的请求模块它返回了这样的内容一个 Request 类构造函数接收 baseURL 和默认配置请求拦截器里自动注入 token响应拦截器里统一处理 200、401、500 状态暴露 get、post、put、delete 四个方法一个简单的缓存工具类支持 localStorage 存储看起来挺全的。但问题出现在细节上它把 token 的获取写死了从 localStorage 取而我们项目是从 indexDB 读取的错误提示用了 alert这在移动端 H5 里没问题但在小程序环境里根本用不了缓存逻辑里没有考虑过期时间只是简单的 set/get没有处理并发请求时的 token 刷新问题如果 token 过期多个请求同时进来会重复刷新这些都不是 AI 的错是我的提示词写得太笼统了。AI 只能根据它训练数据里的“常见做法”来生成而每个公司、每个项目的实际场景都有差异。三、踩坑实录我改掉了哪些地方改代码的过程其实比我自己从头写还费劲因为要理解 AI 的意图再覆盖它的逻辑。但好处是它帮我搭好了骨架我只需要填充血肉。第一个坑错误处理太粗暴AI 写的响应拦截器里只要 status 不是 200就直接调用一个统一的 errorHandler。但在实际项目中不同的错误码需要不同的处理方式。比如 403 需要弹窗提示权限不足500 需要提示服务器繁忙而 422 需要把后端返回的字段级错误展示在表单旁边。我改成了根据 errorCode 分发到不同的处理函数并且支持外部传入自定义 handler。第二个坑缓存设计太简陋AI 的缓存实现是 key-value 对每次请求前先去缓存里查有就直接返回。但没考虑缓存失效、缓存清除、缓存 key 的生成规则。我加了一个时间戳字段每次缓存时记录当前时间 过期时长读取时判断是否过期。同时支持手动清除单个或全部缓存。另外缓存 key 不能只用 url还要带上参数否则不同参数的相同接口会互相污染。第三个坑没有请求取消机制移动端场景里页面切换频繁如果前一个页面的请求还没完成可能会导致数据覆盖或者内存泄漏。AI 完全没有处理这个。我加了一个 cancelToken 的队列每个请求生成一个唯一的 cancelToken在组件销毁时调用 cancel 方法取消未完成的请求。这个改动虽然不大但很关键。第四个坑类型推导不够严谨项目用的是 TypeScriptAI 虽然生成了类型声明但很多地方用了 any。比如请求参数的泛型、响应数据的泛型都是 any。我把它们改成了泛型约束让每个接口方法都能推导出返回数据的类型。这样在调用的时候IDE 就能自动补全字段减少运行时错误。四、为什么同事觉得“像我自己写的”这个问题我后来仔细想了想发现原因其实很简单AI 生成的代码在结构上是中性的没有个人风格。但当我修改它的时候我下意识地按照自己的习惯去调整变量命名用驼峰还是下划线、注释写在哪里、换行风格、错误处理是抛异常还是返回 null、工具函数是放在类里还是独立导出……这些微小的选择最终让代码带上了我的印记。同事之所以觉得像是因为他看到的是我修改后的版本而不是 AI 的原版。而我在修改时并没有刻意去改变风格只是按照自己一贯的方式去“完善”它。这其实说明了一个道理AI 能帮你完成 70% 的模板代码但剩下 30% 的定制和决策才是真正体现个人经验和工程能力的地方。另外我还发现一个有趣的点AI 生成的代码里函数命名往往比较长且啰嗦比如handleTokenExpiredAndRedirectToLogin。我习惯用更短的命名比如handleTokenExpire因为移动端代码行宽有限长命名在代码 review 时很难一眼看清。这个差异也被同事注意到了。五、落地实践建议怎么用好 AI 写基础代码经过这次实践我总结了几条可落地的建议给想用 AI 辅助写代码的同行参考提示词要写具体场景不要只说“写一个请求封装”要说“写一个移动端 H5 的请求封装使用 axiostoken 从 indexDB 读取错误提示用 toast 组件支持请求取消”。越具体AI 输出的代码越接近可用状态。先搭骨架再填肉让 AI 生成核心结构和主要方法然后自己逐行 review替换掉那些不适合你项目的默认实现。不要偷懒直接复制粘贴。关注边界情况AI 容易忽略边界比如网络超时、并发请求、缓存穿透、内存泄漏。这些需要你在 review 时主动补全。保持代码一致性如果团队有代码规范ESLint、Prettier在 AI 输出后立即格式化一遍把命名风格、缩进、引号都统一成团队标准。不要期望一步到位AI 给你的是一个初稿而不是最终产品。把它当成一个高级实习生写的代码需要你来把关和优化。总结这次用 AI 写 API 层的经历让我意识到AI 不是替代品是加速器。它帮我节省了敲模板代码的时间但并没有减少我对代码的理解和决策。同事那句“像你自己写的”其实是对我修改工作的认可而不是对 AI 的认可。如果你也想尝试用 AI 辅助写基础架构代码我的建议是大胆用但别全信。把它当成一个高效的工具而不是一个完美的解决方案。最终的代码质量还是取决于你对业务的理解和对细节的把控。对了那个 AI 生成的缓存模块我后来彻底重写了因为它没有考虑 LRU 淘汰策略在列表页频繁切换的场景下缓存会越堆越多。这又是一个新的坑但那是另一个故事了。
