代码生成角度
小结
针对新的领域制定技术栈，实现三天半350 行demo代码，能在写功能的过程中学习技术
简单功能完成度高，稍复杂的功能完成度低（完成不了，例：帮我将现有的删除元素的功能换成点击元素时fabric控件上出现一个删除的小图标点击删除，不要用按钮去实现删除），需要自己去排错。
优化代码角度
优化思路：
1. 异常捕获：可能发生错误的但未进行错误捕获的函数/方法
例：二维码生成失效、图片加载失败的异常处理等
解决方案：捕获错误，给出用户提示或记录日志
2. 边界条件：未给出超出正常范围时的处理方案
例：图片/二维码的缩放超出画布大小
解决方案：设置可缩放的最大最小值
3. 性能优化：避免冗余计算和多余内存消耗
例：每次更新选中元素时调用 this.canvas.renderAll()，导致频繁重绘，影响性能。
解决方案：使用浏览器自带方法延迟重绘，减少不必要的渲染
实操
针对全量代码的优化，文件改动较大。
针对特定功能点：二维码渲染逻辑导致的二维码选中后不能连续多次修改缩放值和位置 优化成功，但引入bug，二维码内容修改失败，二次优化成功
小结
负向优化
- 变量命名的改动后端需要同步更改
- 边界值条件限制失败，最大最小值设置未生效，需要人工排错
- 存在无用函数：删除元素前重置元素属性、确保图片不会超出画布边界
- 理解成本大幅提升：重新梳理代码的调用关系和执行流程
- 引入新的漏洞
正向优化
- 代码模块化与复用性提升，业务逻辑分离
- 数据初始化
- 减少不必要的画布渲染操作，防止重复渲染，利用浏览器原生方法确保动画更流畅
- 减少不必要的中间变量
用于特定功能点的体验优于全量代码优化，可把控。
生成注释及代码补全角度
小结：
代码补全会按照上下文，保留开发者代码风格。变量及方法命名可读性高。代码注释准确的高
组件页面样式优化
自由修改：
条件修改
小结： 对于界面样式的优化，条件限制较小的情况下优化效果更好, 提供一些条件优化的情况下只能完成所给条件，自身优化能力变差
对于复杂、内存消耗过多的组件的优化能力
模拟大量数据处理（定时器）、频繁的重渲染以及复杂的嵌套计算（函数嵌套），从而导致性能下降和内存消耗增加
提供的优化思路
1.减少不必要的计算
- 问题 ：
complexCalculation和processedData中都有复杂的循环计算，每次渲染都会重新计算，导致性能瓶颈。 - 优化 ：使用缓存（如
computed或memoization）来避免重复计算。
2. 减少频繁的渲染
- 问题 ：
currentTime每秒更新一次，会触发整个组件的重新渲染，即使数据没有变化。 - 优化 ：将
currentTime提取到一个独立的组件中，避免影响父组件的渲染。
3. 避免不必要的状态复制
- 问题 ：
NestedComponent中复制了largeDataList到localData，增加了内存开销。 - 优化 ：直接使用
props数据，避免不必要的复制。
4. 使用虚拟列表优化大量数据渲染
- 问题 ：
largeDataList包含 10000 条数据，直接渲染会导致性能问题。 - 优化 ：使用虚拟列表（如
vue-virtual-scroller）只渲染可见区域的数据。
实操：
报错原因：引入了一个vuejs的三方库，导致报错，因为该依赖没有安装。没用提示需要先安装才能使用，没有给出对应依赖版本，版本不符合会导致报错，难以排查
优化效果：
单元测试的角度
测试用例执行情况：
文字更新不符合预期 图片缩放不符合预期
ai尝试分析错误原因，调整用例后依然报错
总结：
1、需要给ai提供一个完整的单元测试框架（模板），比如组件的挂载，组件的前置条件，组件数据初始化，接口的mock数据，ai只负责给出核心功能或者针对某个函数的测试用例，成功率会增大，生成完整的单元测试能力弱
2、Ai提供的测试用例方向较为单一，除去检查元素的更新还应测试一下功能
- deleteSelectedElement 方法：测试删除选中元素的功能。
- handleObjectChange 事件：检查元素移动、缩放时，组件的数据是否正确更新。
- 导出功能的测试。