AI编程助手在动态导入报错中的实战教训

1. 当AI编程助手遇上动态导入报错：我的GLM4.7翻车实录

上周五下午，我正对着控制台里那个顽固的动态导入报错发愁。错误信息很直白："Failed to fetch dynamically imported module.../router/index.ts"，但解决方案却像捉迷藏。作为长期使用GLM的老用户，我决定给新上线的Claude Code功能一个机会——结果成了我今年最昂贵的debug尝试之一。

这次经历让我深刻认识到：AI编程助手在前端工程化问题面前，就像带着高级渔具的新手钓鱼佬，装备精良却可能连鱼饵都挂不好。1小时内烧光5小时套餐额度（约3000万token），问题却依然如故。下面我会完整复盘这次经历，分享哪些场景适合用AI辅助，哪些坑必须提前避开。

2. 问题背景与工具选择

2.1 那个看似简单的动态导入报错

报错发生在Vue3 + Vite + TypeScript的项目中，当路由切换到某个懒加载的页面组件时，控制台抛出模块加载失败。表面看是典型的动态导入问题，但特殊之处在于：

• 仅特定环境出现（本地开发环境）
• 报错模块路径显示为编译后的chunk路径
• 清除缓存、重装依赖等常规操作无效

这种"时灵时不灵"的特性，正是前端工程中最让人头疼的问题类型——它可能涉及：

bash复制1. Vite配置中的base路径或publicPath
2. 路由器的history模式与服务器配置不匹配  
3. TypeScript的路径别名(alias)转换问题
4. 依赖树中的版本冲突
5. HMR热更新机制的异常

2.2 为什么选择Claude Code + GLM4.7组合

作为GLM的老用户，我选择这个组合出于三个考虑：

1. 代码理解深度：GLM4.7在TypeScript和Vue生态的支持度较好
2. 终端交互能力：Claude Code可以直接读取控制台输出并执行命令
3. 成本可控：GLM的5小时套餐通常足够日常使用（或至少我是这么认为的）

工具链配置如下：

javascript复制// vite.config.ts
export default defineConfig({
  plugins: [vue(), vueJsx()],
  reso