用AI写了个uni-app插件，结果自己改了三版才跑通——聊聊AI编程的“靠谱度”边界

背景：一个看似简单，实则处处是坑的需求

上个月接到一个任务：在 uni-app 项目中实现一个图片裁剪插件，支持缩放、旋转和拖拽。我第一反应是“这不简单吗？网上模板一大堆，让 AI 写一个不就完了？”于是，我打开常用的 AI 代码助手，把需求描述得清清楚楚：用 uni-app 写一个图片裁剪组件，支持手势缩放、旋转、拖拽，兼容 H5 和微信小程序。

AI 秒回一个完整的 vue 组件，代码结构清晰，注释到位。我心里一阵窃喜：这效率，以后谁还自己写？结果一跑，直接翻车。H5 端页面卡死，小程序端裁剪框歪了，旋转后图片飞出边界。更离谱的是，AI 生成的代码里，touch 事件直接用了 @touchmove.prevent，在微信小程序里压根不生效。

于是，我开始了“AI 写一版，我改一版”的循环。前后改了三个大版本，踩了无数坑，才算勉强跑通。这篇文章就来聊聊——AI 写 uni-app 插件到底靠不靠谱，以及我们该怎么用好它。

问题分析：AI 编程的“三大盲区”

在改代码的过程中，我逐渐摸清了 AI 的弱点。它擅长的是“拼凑”，而不是“适配”。

1. 平台差异被忽略
   uni-app 最大的特点就是跨平台。AI 生成的代码往往默认“一套逻辑走天下”。比如，在 H5 端，touch 事件处理非常自由，可以用 e.touches[0] 直接取坐标；但在微信小程序里，touches 对象的 clientX 和 pageX 在不同组件层级下表现不同。AI 生成的裁剪组件，在小程序里拖拽时，坐标计算完全错位，因为没考虑到 uni.createSelectorQuery() 的异步特性。

2. 边界情况全靠猜
   AI 会写“理想状态”的代码，但不会考虑用户的实际操作。比如，它生成的旋转逻辑是：每次旋转 90°，然后更新 transform。但用户如果连续快速旋转，或者先旋转再缩放，图片的 transform-origin 就会乱。AI 没有处理这种“状态叠加”的场景，导致图片在多次操作后直接飞出去。

3. 性能优化完全缺失
   uni-app 的 H5 端和原生小程序端，性能模型完全不同。AI 生成的代码在 H5 端用 v-bind:style 动态绑定 transform，每次手指滑动都触发一次重渲染。这在 H5 上勉强能跑，但在小程序里，由于 setData 的异步机制和渲染层与逻辑层的通信开销，直接导致页面卡死。AI 不会主动考虑用 requestAnimationFrame 节流，也不会用 computed 缓存计算结果。

第一版：推倒重来，从“事件模型”开始改

第一版 AI 代码的核心逻辑是：在 touchstart 时记录初始位置，touchmove 时更新 transform: translate(X, Y) scale(S) rotate(R)。看起来没问题，但小程序里一跑，拖拽时有延迟，而且缩放后图片边界不对。

问题定位：AI 用了 @touchmove="onTouchMove"，但在 onTouchMove 里直接计算并赋值给 this.style。在小程序里，touchmove 事件触发频率极高（每秒几十次），每次都要执行 setData 更新样式，性能瓶颈就在这里。

解决方案：改用 uni.createSelectorQuery() 获取组件边界，然后用 requestAnimationFrame 节流。具体来说：

javascript
// 节流函数，控制更新频率
let ticking = false;
function onTouchMove(e) {
if (!ticking) {
requestAnimationFrame(() => {
updateTransform(e.touches[0]);
ticking = false;
});
ticking = true;
}
}

同时，把 transform 的计算结果缓存到 computed 属性里，只在手势结束时才一次性写入 data。这样，setData 的调用次数从每秒几十次降到每秒一次。

踩坑记录：requestAnimationFrame 在微信小程序里是支持的，但要注意，它返回的是一个 number 类型的 ID，不能用 cancelAnimationFrame 直接取消（因为小程序的实现有差异）。我的做法是：用一个 flag 变量控制，而不是依赖 cancelAnimationFrame。

第二版：旋转与缩放的“叠加噩梦”

第二版改完，拖拽和缩放基本 ok，但旋转加入后，问题又来了。用户先旋转 90°，再缩放 2x，图片位置会跳变。原因是 AI 的旋转逻辑是：每次旋转后，重新计算 transform: translate(x, y) scale(s) rotate(r)，但 x 和 y 是基于初始坐标的，旋转后图片的视觉中心变了，translate 的偏移量却没更新。

问题定位：旋转改变了图片的坐标系，但 translate 的偏移量还是基于原始坐标系计算的。比如，图片中心在 (100, 100)，旋转 90° 后，中心点还在 (100, 100)，但图片的视觉边界变了。AI 没有考虑“旋转后中心点偏移”这个细节。

解决方案：改用“矩阵变换”的思路，而不是直接操作 translate、scale、rotate。因为 transform: matrix() 可以统一处理所有变换，而且能保持坐标系的连续性。

javascript
// 使用矩阵变换，把所有操作叠加到一个 matrix 上
let currentMatrix = [1, 0, 0, 1, 0, 0]; // [a, b, c, d, tx, ty]

function applyRotation(angle) {
const rad = angle Math.PI / 180;
const cos = Math.cos(rad);
const sin = Math.sin(rad);
// 矩阵乘法：旋转矩阵 当前矩阵
currentMatrix = [
cos currentMatrix[0] + sin currentMatrix[2],
cos currentMatrix[1] + sin currentMatrix[3],
-sin currentMatrix[0] + cos currentMatrix[2],
-sin currentMatrix[1] + cos currentMatrix[3],
currentMatrix[4],
currentMatrix[5]
];
updateStyle();
}

踩坑记录：矩阵变换虽然精准，但在 uni-app 里，transform: matrix() 的兼容性要特别注意。微信小程序支持 matrix，但 H5 端的某些旧版浏览器可能不支持。我的做法是：在 onReady 里用 uni.getSystemInfoSync() 判断平台，如果是 H5 且版本低，就回退到 translate + scale + rotate 的分步写法。

第三版：裁剪框的“边界锁定”与“用户体验”

前两版跑通后，第三版主要解决裁剪框的边界锁定问题。AI 生成的代码里，用户可以把图片拖到裁剪框外面，然后裁剪出空白区域。这显然不行。

问题定位：AI 只计算了图片的 transform 值，但没有计算图片在裁剪框内的有效显示区域。它不会自动判断“图片边缘是否超出裁剪框边界”，更不会做“边界回弹”。

解决方案：在每次手势结束时，计算图片的四个角在裁剪框坐标系中的坐标，然后做边界约束。

javascript
function clampBounds() {
// 获取裁剪框的尺寸（假设已知 width, height）
const cropRect = { x: 0, y: 0, w: cropWidth, h: cropHeight };
// 获取图片当前变换后的四个角坐标（通过矩阵计算）
const corners = getImageCorners(currentMatrix, imageWidth, imageHeight);
// 计算需要偏移的量，保证所有角都在裁剪框内
let dx = 0, dy = 0;
for (const corner of corners) {
if (corner.x cropRect.x + cropRect.w) dx = Math.min(dx, cropRect.x + cropRect.w - corner.x);
if (corner.y cropRect.y + cropRect.h) dy = Math.min(dy, cropRect.y + cropRect.h - corner.y);
}
// 更新矩阵的平移部分
currentMatrix[4] += dx;
currentMatrix[5] += dy;
updateStyle();
}

用户体验优化：边界锁定后，用户如果拖动到边缘，会感觉“卡死了”。我加了弹性效果：当图片边缘超出边界时，用 transition: all 0.2s ease-out 让图片“弹回”边界内。这样用户操作时，手感更自然。

踩坑记录：弹性效果在 H5 端用 CSS transition 就行，但在小程序里，transition 对 transform 的支持有限（特别是微信小程序的旧版基础库）。我的做法是：用 uni.createAnimation() 创建动画实例，手动控制回弹的缓动效果。

注意事项：AI 编程的“靠谱度”边界总结

通过这次三版迭代，我总结了几条 AI 编程的“靠谱度”边界，供大家参考：

1. AI 擅长的：快速生成“骨架代码”，比如组件的基本结构、事件绑定、样式模板。这些工作重复性高，AI 效率极高。
2. AI 不擅长的：处理平台差异、边界情况、性能优化、用户体验细节。这些需要开发者对 uni-app 的底层机制有深入理解。
3. 建议做法：让 AI 写 70% 的代码（基础功能 + 模板），自己写 30% 的“硬核”部分（事件处理、状态管理、性能优化）。不要期望 AI 能输出一个生产级的插件。
4. 测试策略：AI 生成的代码，一定要在“最小环境”里测试，比如单独创建一个空白 uni-app 项目，只引入这个组件，测试 H5 和微信小程序两个端。等基础功能 ok，再集成到实际项目中。

总结：AI 是“实习生”，不是“主力”

这次经历让我从一个“AI 万能论者”变成了“AI 实用主义者”。AI 能帮我们省下写模板的时间，但真正决定代码质量的，还是我们自己对 uni-app 的理解深度。比如，你是否知道 uni-app 的 touch 事件在 H5 和小程序里的坐标系差异？你是否了解 requestAnimationFrame 在跨平台下的兼容性？这些知识，AI 不会主动告诉你，只能靠你自己去踩坑、去总结。

如果你也想用 AI 写 uni-app 插件，我的建议是：先让 AI 写一个“玩具版”，然后基于这个“玩具版”去迭代。不要指望一次成型。每次迭代，你都会发现自己对问题的理解更深一层。这，可能才是 AI 编程真正有价值的地方——它逼着我们思考那些原本会被忽略的细节。