1. 项目概述当老项目遇见新AI五年前我为了给一个线下活动暖场用当时最时髦的技术栈——React Three.js吭哧吭哧写了一个线上娃娃机小游戏。它运行得不错也收获了一些好评但代码库就像那个被遗忘在角落的毛绒玩具积满了灰尘。五年时间前端技术栈已经天翻地覆TypeScript 成了标配构建工具从 Webpack 换到了 ViteThree.js 的 API 也迭代了好几轮。更重要的是AI 编程助手已经从科幻走进了现实。最近我突发奇想把这个老项目丢给了 AI想看看在它的“帮助”下这个项目能进化成什么样子。我的目标很明确不追求功能上的巨大革新而是聚焦于代码质量、开发体验和性能的现代化重构。整个过程我主要扮演“产品经理”和“代码审查者”的角色将具体的编码、重构、文档甚至部分调试工作交给了 AI 助手。结果出乎意料。原本预计需要一周的梳理和重构工作在 AI 的辅助下仅用了半天时间就完成了核心代码的重写与升级。这半天不仅仅是代码的翻新更是一次对现代前端工程化、类型安全以及 AI 辅助开发流程的深度实践。如果你也有一个“历史包袱”项目或者对如何将 AI 融入实际开发流程感到好奇那么我这次的经验或许能给你一些直接的参考。2. 核心重构思路与技术选型2.1 老项目的“历史债”诊断在让 AI 动手之前我得先自己看看这个“病人”的现状。打开五年前的代码扑面而来的是一股“古典”气息无类型化的 JavaScript满屏的any实际上是连any都没有纯 JS函数参数和返回值的意图全靠猜一个抓取动作的函数传入的参数可能是对象、数组甚至是undefined运行时错误是家常便饭。陈旧的 Three.js 用法使用的是r89左右的版本很多 API 如Geometry已经废弃被BufferGeometry取代。场景、相机、渲染器的初始化代码冗长且与业务逻辑耦合。笨重的 React 类组件整个游戏状态管理分散在各个组件的this.state里生命周期函数componentDidMount和componentWillUnmount里塞满了 Three.js 的初始化和清理逻辑可读性和可维护性都很差。缺失的工程化没有 lint 工具代码格式混乱构建配置基于老版本的 Webpack速度慢热更新不灵敏缺乏任何形式的单元测试。物理交互的生硬实现当时的“物理”效果实际上是用简单的线性插值Lerp和欧拉角旋转模拟的爪子运动轨迹僵硬抓取反馈不真实。基于这个诊断我确定了本次 AI 重构的四大核心目标TypeScript 化、Three.js 版本与代码结构升级、React 函数组件与状态管理重构、引入基础工程化与物理引擎。2.2 为什么选择 TypeScript React Three.js 这个组合即使有 AI技术选型依然需要人的判断。这个组合在今天看来依然是构建此类 3D 交互应用的黄金搭档。TypeScript 是安全网与说明书对于涉及大量数学计算向量、矩阵、欧拉角和复杂对象层级3D 场景图的 Three.js 项目类型系统至关重要。它能在我编写代码时就提示Vector3不能和Euler直接相加能自动补全Object3D的所有方法和属性将大量运行时错误消灭在编译时。AI 在理解并应用类型约束后生成的代码健壮性显著提高。React 负责 UI 与状态娃娃机的控制面板按钮、币数显示、结果提示、游戏状态空闲、下爪、抓取、返回非常适合用 React 的声明式 UI 来管理。将 Three.js 的渲染视图作为一个独立的“画布”组件嵌入可以使 UI 逻辑和 3D 渲染逻辑清晰分离。Three.js 是 3D 基石它封装了 WebGL 的复杂性提供了直观的 3D 对象、材质、光照、相机概念。对于不需要用到极致性能如数百万级多边形的轻量级 3D 应用Three.js 的生态和易用性无可替代。AI 对 Three.js 的文档和常见模式有很好的理解能快速生成正确的场景搭建代码。2.3 物理引擎的考量Cannon.js 与 Rapier老版本的“伪物理”是体验的短板。我决定引入一个真正的物理引擎来模拟爪子的摆动、抓取碰撞以及玩偶的掉落。这里有两个主流选择Cannon.js老牌、轻量、纯 JavaScript 实现文档和社区示例丰富。但它的 TypeScript 支持是社区维护的可能有些滞后且性能在极端复杂场景下可能成为瓶颈。dimforge/rapier后起之秀使用 Rust 编写通过 WebAssembly 在浏览器中运行性能强劲API 设计现代对 TypeScript 支持一流。但生态相对较新中文资料较少。考虑到我的娃娃机场景刚体数量少一个爪子、几个玩偶、四壁和底部复杂度低但对开发体验和类型安全要求高我最终选择了Rapier。它的高性能在未来增加更多互动元素时留有余地优秀的 TS 支持能让 AI 和我更高效地工作。虽然初期学习曲线稍陡但 AI 助手能快速根据官方文档生成正确的物理世界设置和刚体创建代码极大地平滑了这一过程。注意如果你的项目物理模拟非常复杂如上百个持续交互的物体且对包体积极其敏感Cannon.js 仍是值得考虑的选项。但对于大多数项目Rapier 的现代化和性能优势更明显。3. AI 辅助下的具体重构流程3.1 第一步项目地基现代化——配置与工具链在写第一行业务代码前必须先搭建好现代化的开发环境。我向 AI 助手描述了需求“将一个旧的 Create-React-App (CRA) JavaScript 项目迁移到基于 Vite TypeScript React 的新项目并集成 ESLint 和 Prettier。”AI 并没有直接给我一个魔法命令而是给出了一个清晰、可操作的步骤列表和代码片段初始化 Vite 项目npm create vitelatest claw-machine -- --template react-ts迁移核心源码将老项目src/下的组件、样式、静态资源模型、纹理拷贝到新项目。此时 TypeScript 会报大量错误先忽略。安装 Three.js 和 Rapiernpm install three types/three dimforge/rapier配置tsconfig.jsonAI 建议调整compilerOptions例如将“target”设为“ES2020”以获得更好的现代特性支持确保“moduleResolution”为“node”。特别重要的是它提醒我注意一个即将到来的破坏性变更“baseUrl”选项在 TypeScript 5.0 的某些用法已被标记为弃用将在 7.0 中移除。AI 建议我检查老配置并改用“paths”进行路径映射或者直接使用相对路径。集成代码质量工具AI 生成了.eslintrc.cjs和.prettierrc的配置文件并指导我在package.json中添加相应的lint和format脚本。这个过程大约花了 1 小时大部分时间在文件拷贝和依赖安装上。AI 的价值在于提供了准确的命令、合理的配置和重要的版本变更预警避免了我在查阅零散文档中踩坑。3.2 第二步核心组件 TypeScript 化与重构这是重头戏。我打开了最核心的ClawMachine.tsx文件原.jsx文件将内容粘贴到 AI 聊天窗口并给出指令“将这个 React 类组件重构为函数组件使用 TypeScript并分离 Three.js 渲染逻辑到自定义 Hook 中。”AI 的操作令人印象深刻类型定义先行它首先为我定义了游戏的核心状态类型。interface GameState { status: idle | descending | grabbing | ascending | failed | success; coins: number; targetToyIndex: number | null; } interface ToyModel { id: number; name: string; position: [number, number, number]; // ... 其他属性 }拆解类组件将componentDidMount中长达上百行的 Three.js 初始化代码创建场景、相机、渲染器、加载模型、设置光照抽离到一个名为useThreeScene的自定义 Hook 中。这个 Hook 返回scene、camera、renderer等核心对象的引用并在useEffect中处理创建和清理。这使得主组件变得非常清爽。状态管理现代化将分散的this.state用useState和useReducer替代。对于复杂的、涉及多个子状态同步变更的游戏逻辑如下爪、抓取、判定AI 建议使用useReducer因为它更利于表达复杂的状态迁移例如function gameReducer(state: GameState, action: GameAction): GameState { switch (action.type) { case INSERT_COIN: return { ...state, coins: state.coins 1 }; case START_DESCEND: // 物理引擎开始模拟爪子下落 return { ...state, status: descending }; // ... 其他 cases } }物理引擎集成AI 根据 Rapier 文档在useThreeSceneHook 中初始化了物理世界world并指导我创建地面、墙壁、爪子和玩偶的刚体RigidBody和碰撞形状Collider。关键的一步是同步物理世界与渲染世界需要在每一帧的动画循环中从 Rapier 的刚体中获取最新的position和rotation然后更新 Three.js 场景中对应模型的位置和旋转。在这个过程中我并非完全被动。AI 生成的代码有时会忽略一些边缘情况或者对 React Hooks 的依赖项处理不够完善。我的角色是审查和修正检查useEffect的依赖数组是否正确确保事件监听器在组件卸载时被移除验证物理模拟的步长timeStep设置是否合理以避免“抖动”或“穿透”。3.3 第三步三维模型与交互的优化老项目使用.obj模型加载慢且材质处理麻烦。AI 建议转换为.glb二进制格式的 glTF格式它体积更小、包含场景信息、且 Three.js 支持度最好。这里遇到了一个典型问题当我将转换好的.glb模型用GLTFLoader加载到 Three.js 中时场景一片漆黑。我把这个现象描述给 AI“模型在建模软件里正常但在 Three.js 里打开是黑的。”AI 给出了系统性的排查思路检查光照场景中是否添加了光源AmbientLight,DirectionalLight光源强度是否足够位置是否合适检查相机相机是否对准了模型near和far平面是否将模型包含在内检查模型材质.glb模型可能包含 PBR基于物理的渲染材质需要WebGLRenderer的outputEncoding和toneMapping进行正确配置。AI 生成了启用sRGBEncoding和ACESFilmicToneMapping的代码。检查模型本身使用glTF Viewer等在线工具验证.glb文件是否完好。有时建模软件的导出设置有问题。最终问题在于光照和色调映射。按照 AI 的建议调整后模型正确显示。此外AI 还建议为模型添加简单的点击交互通过Raycaster从相机发射射线检测与哪个玩偶模型相交从而高亮显示或将其设置为抓取目标这比老版本用 2D UI 选择的方式沉浸感强得多。3.4 第四步构建、部署与性能调优代码重构完成后运行npm run build进行构建。Vite 的速度比老 Webpack 快了一个数量级。但首次构建的包体积有点大超过 3MB。我向 AI 提问“如何优化基于 Vite Three.js 的 React 项目的产物体积”AI 提供了组合拳代码分割使用React.lazy和Suspense将非核心组件如游戏说明、历史记录动态导入。依赖分析运行npm run build -- --report生成构建报告查看哪个依赖包体积最大。Three.js 按需导入避免import * as THREE from ‘three’改为只导入需要的模块例如import { Scene, PerspectiveCamera, WebGLRenderer } from ‘three’。AI 特别指出对于 Tree-shaking 友好的库这种方式能显著减少打包体积。压缩静态资源对.glb模型进行进一步的压缩如使用glTFpack工具对纹理图片使用 WebP 格式。经过优化最终产物体积减少了约 40%。AI 还生成了一个简单的Dockerfile和nginx.conf配置文件让我能快速将应用部署到任何支持容器的云服务上。4. 踩坑实录与 AI 协作心得4.1 那些 AI 暂时搞不定的“坑”尽管 AI 能力强大但一些深层次的、需要综合理解和创造性思维的问题仍然需要开发者亲自解决。物理参数调校的“手感”问题Rapier 引擎需要设置质量mass、摩擦力friction、恢复系数restitution等参数。AI 可以给我这些参数的物理意义和典型取值范围但**“爪子抓取玩偶时的那种恰到好处的粘滞感”**需要我手动反复调整、测试。这就像炒菜放盐AI 告诉你“适量”但最终的火候得自己掌握。我建立了一个简单的调试面板实时调整这些参数才找到最佳手感。复杂状态流的竞态条件游戏状态从“下爪”到“抓取”到“升起”涉及物理模拟、定时器、用户输入。AI 生成的useReducer逻辑有时在快速连续操作下会出现状态不一致。例如爪子还没升回用户又按了下爪按钮。这需要我仔细设计action的类型在某些状态下禁用 UI 按钮并添加额外的状态校验逻辑。三维空间中的 UX 设计如何让用户通过 2D 鼠标/触摸屏直观地控制 3D 空间中的爪子移动老项目用的是四个方向按钮。AI 建议了更现代的方案拖拽画布来旋转视角点击玩偶进行目标选择。但这个交互方案的细节比如拖拽灵敏度、视角边界、选中高亮效果需要结合具体场景进行大量微调和用户测试AI 无法代劳。4.2 如何高效地向 AI 提问这次重构成功的关键之一是我学会了如何与 AI 协作。以下是我的心得提供充足上下文不要只说“我的代码报错了”。把错误信息、相关代码片段、你正在尝试做的事情、以及你已经排查过的步骤都告诉它。就像你向同事求助一样。分步骤、模块化地推进不要一次性要求“重写我的整个项目”。拆解成“帮我把这个 Three.js 初始化函数转换成 Hook”、“为这个游戏状态设计 TypeScript 接口”、“如何用 Rapier 创建一个可以掉落的盒子刚体”。每个小任务的成功都会积累上下文让 AI 在后续任务中表现更好。要求解释而不仅仅是代码当 AI 给出解决方案时多问一句“为什么”。例如它建议使用useRef来保存 Three.js 的渲染器实例我会问“为什么不用useState” 它会解释因为渲染器实例在组件生命周期内是稳定的不需要触发重新渲染。这能帮助你真正理解并在未来举一反三。保持批判性思维亲自验证AI 生成的代码尤其是涉及第三方库 API 的一定要对照官方文档进行核实。AI 可能基于过时的文档或错误的上下文生成代码。永远不要盲目信任将其视为一个强大的、但需要监督的初级程序员。4.3 对现有工作流的颠覆性影响经过这“半天”的重构我的工作流发生了显著变化从“搜索引擎驱动”到“对话驱动”以前遇到问题我需要把错误信息提炼成关键词去 Stack Overflow 或博客搜索在多个结果中筛选、拼凑答案。现在我直接向 AI 描述问题它能给出针对性更强的解决方案并且能进行多轮对话深入探讨。从“从零开始”到“从草图开始”对于搭建项目框架、编写样板代码如配置、Hook、工具函数这类重复性高、创造性低的工作AI 极大地提升了效率。我可以把精力集中在核心业务逻辑、算法设计和用户体验这些更需要人类创造力和判断力的地方。代码审查的“第二双眼睛”在提交代码前我会把 diff 片段丢给 AI让它从代码风格、潜在 bug如内存泄漏、无限循环、性能隐患等角度进行“预审”。它常常能发现一些我疏忽的细节。5. 展望AI 辅助开发的未来与边界这次“娃娃机重生记”是一个绝佳的缩影展示了 AI 辅助开发在当前阶段的能力与局限。它极大地提升了效率和代码质量的下限尤其是在处理技术升级、编写样板代码、快速学习新库如 Rapier方面。然而它也清晰地标定了自己的边界架构设计AI 擅长在给定架构下填充代码但项目的顶层架构设计、模块划分、技术选型的权衡仍然需要资深工程师的经验和洞察。产品与业务逻辑娃娃机的游戏规则、付费点设计、如何让抓取过程更有趣更上瘾这些属于产品和游戏设计范畴AI 无法替代人类对用户心理和市场需求的理解。调试与问题解决当遇到复杂的、涉及多个系统交互的 bug 时AI 可以给出排查方向但最终的根因分析、逻辑推理和解决方案的创造性构思依然依赖于开发者的系统性思维。对我而言AI 不是一个即将取代我的对手而是一个能力超强的“实习生”或“结对编程伙伴”。它负责处理那些繁琐、规范、有大量现成模式可循的工作而我则专注于设计、决策、创造和解决那些真正棘手的问题。未来随着 AI 对代码上下文理解能力的加深这种协作模式只会更加紧密和高效。这次经历让我确信拥抱 AI学会如何有效地指挥和协同它是当下开发者必须掌握的核心技能之一。它不是让你变懒而是让你能飞得更高把时间用在刀刃上。你的旧项目或许也值得用这样的方式获得一次新生。