aloxaf

现在这些大模型给我的感觉就是：富有经验，但沉溺在自己经验里的工程师，一旦跳出它的舒适圈，就很难绷。

前几天有段 Rust 代码想重构一下，是用 async + rayon + opencv 对一批图像进行处理。

由于把 async 和 rayon 混在一起比较麻烦，我一开始选择是每个 task 把“所有”图片处理完再进行下一个 task ，大概像这样 async task1 （过滤） -> rayon task2 （多线程计算） -> async task3 （收集），但这样显然效率不高，应该流式处理更合适。

然后我就试了让 gemini 2.5 pro 和 claude 3.7 sonnet thinking 帮我重构一下，我解释了这段代码在干啥，我为什么这么写，我现在希望重构成哪种效果……

结果惨不忍睹，它们做的事情包括但不限于：
1. 先计算，再过滤收集——即使我强调过计算非常慢
2. 把计算任务也全部放到异步 task 里——你觉得我为啥要特地拆成三个 task
3. 遇到所有权和生命周期问题就是一通乱改，改了几次过不了就全部重写（？？）
……

最后为了预防高血压，还是自己写了，其实就是把 rayon 换成一个线程池，然后三个 task 之间用 channel 通信。就这么个简单的任务，这些刷起题来比我强到不知到哪里去的 AI 硬是没做出来。

> 真正优秀的交互，应当是符合认知直觉的，而不是让人产生模糊感和不确定性。

交互是否合理不应该看用户的选择吗？

我看了一下我手机（小米）里的全面屏手势教程，发现侧滑返回用的示意图是左侧滑动，教的时候也是先教左侧
滑动——但事实上我大部分时候用的都是右侧滑动。在看到这个帖子之前，我都没有意识到原来还可以左侧滑动。

在提供两种滑动的情况下，我自然而然地就选择了右侧滑动，这是不是可以说明，至少对于像我一样的用户来说，右侧滑动是一个更好的设计呢？

你这「教用户做事」的味儿也太浓了……

这里面只用过 copilot ，首先 agent 模式慢很多，不管是请求还是编辑都慢。
这个其实我还能接受，但 tab 实在是差远了！

copilot 的 tab 别说补全代码，TM 连基本的重构都做不好，给的建议莫名其妙，

> 20 刀一个月是赚不了钱吗

我也觉得现在的 Cursor 没以前好用，但是你说 20 刀赚不赚钱，那肯定是不赚钱，完全是在烧钱抢市场。

@PrinceofInj 我也非常震惊，点进来之前估计以为是讨论什么历史遗留问题之类的，结果很多人竟然连 checksum 是什么都不理解，还在嘲讽可行性……