企业官网建设流程全解析

一、起因：一个“偷懒”的决定

事情发生在上个月。公司临时启动了一个新的移动端项目，排期紧、需求杂，我负责搭网络请求层——说白了就是封装 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 方法取消未完成的请求。这个改动虽然不大，但很关键。

第四个坑：类型推导不够严谨
项目用的是 TypeScript，AI 虽然生成了类型声明，但很多地方用了 any。比如请求参数的泛型、响应数据的泛型，都是 any。我把它们改成了泛型约束，让每个接口方法都能推导出返回数据的类型。这样在调用的时候，IDE 就能自动补全字段，减少运行时错误。

四、为什么同事觉得“像我自己写的”？

这个问题我后来仔细想了想，发现原因其实很简单：AI 生成的代码在结构上是中性的，没有个人风格。但当我修改它的时候，我下意识地按照自己的习惯去调整：变量命名用驼峰还是下划线、注释写在哪里、换行风格、错误处理是抛异常还是返回 null、工具函数是放在类里还是独立导出……这些微小的选择，最终让代码带上了我的印记。

同事之所以觉得像，是因为他看到的是我修改后的版本，而不是 AI 的原版。而我在修改时，并没有刻意去改变风格，只是按照自己一贯的方式去“完善”它。这其实说明了一个道理：AI 能帮你完成 70% 的模板代码，但剩下 30% 的定制和决策，才是真正体现个人经验和工程能力的地方。

另外，我还发现一个有趣的点：AI 生成的代码里，函数命名往往比较长且啰嗦，比如handleTokenExpiredAndRedirectToLogin。我习惯用更短的命名，比如handleTokenExpire，因为移动端代码行宽有限，长命名在代码 review 时很难一眼看清。这个差异也被同事注意到了。

五、落地实践建议：怎么用好 AI 写基础代码？

经过这次实践，我总结了几条可落地的建议，给想用 AI 辅助写代码的同行参考：

• 提示词要写具体场景：不要只说“写一个请求封装”，要说“写一个移动端 H5 的请求封装，使用 axios，token 从 indexDB 读取，错误提示用 toast 组件，支持请求取消”。越具体，AI 输出的代码越接近可用状态。
• 先搭骨架再填肉：让 AI 生成核心结构和主要方法，然后自己逐行 review，替换掉那些不适合你项目的默认实现。不要偷懒直接复制粘贴。
• 关注边界情况：AI 容易忽略边界，比如网络超时、并发请求、缓存穿透、内存泄漏。这些需要你在 review 时主动补全。
• 保持代码一致性：如果团队有代码规范（ESLint、Prettier），在 AI 输出后立即格式化一遍，把命名风格、缩进、引号都统一成团队标准。
• 不要期望一步到位：AI 给你的是一个初稿，而不是最终产品。把它当成一个高级实习生写的代码，需要你来把关和优化。

总结

这次用 AI 写 API 层的经历，让我意识到：AI 不是替代品，是加速器。它帮我节省了敲模板代码的时间，但并没有减少我对代码的理解和决策。同事那句“像你自己写的”，其实是对我修改工作的认可，而不是对 AI 的认可。

如果你也想尝试用 AI 辅助写基础架构代码，我的建议是：大胆用，但别全信。把它当成一个高效的工具，而不是一个完美的解决方案。最终的代码质量，还是取决于你对业务的理解和对细节的把控。

对了，那个 AI 生成的缓存模块我后来彻底重写了，因为它没有考虑 LRU 淘汰策略，在列表页频繁切换的场景下，缓存会越堆越多。这又是一个新的坑，但那是另一个故事了。