目前使用了Cursor和GLM-4.7，刚开始Cursor接入的是sonet-4.5，开始起点很高，直接帮我做的几个程序都成功了，感觉非常好。
但是问题是访问国外的模型很麻烦，速度太慢，体验不好。GLM模型的评分也很高，所以想着简单的任务应该用GLM就可以满足要求了，就订阅了Lite的套餐，结合Claude Code来使用。
说说体验。
1.在Cursor中接入Claude Code插件调用的GLM-4.7模型，使用过程中比较好的地方是规划模式，我提出一个需求，能够给我进行详细功能拆解，绘制数据流图，这个让我觉得非常好。
2.我问了一个点云数据和图像处理方面的问题，对于我的需求一开始给我写的代码还是挺复杂的，设计了多个Python类包括UI类、相机类、图像渲染类等等。当然这个没啥不好，设计的没有问题，如果直接都完成那真是非常棒了，但是隐隐开始担心后面出问题怎么调试了。
3.果然，后面使用过程中体验就不太好了，对于相机模型的计算问题，本来计算公式比较多，挺复杂了。开始库调用的问题比如open3的版本问题，它基本都能改出来。但是到后面当计算结果不对时，你把问题抛给他，他吭哧吭哧的写了一大堆；然后不对，你再丢给他，他又吭哧吭哧的写一堆；让人很崩溃。如果你不能很好的描述问题的所在，给它正确的方向，感觉会在哪里原地打转，怎么都改不对。
4.你给他提示，你说啥都是对的，它很谦虚。但是如果你说的不对，它也没有办法判断出来，上来就改。所以版本管理还是挺重要的，当出现阶段结果时，一定得备份，不然后面直接改动大了，就很难回退。
5.代码中的注释和函数命名会影响它对实际程序功能的判断，给了一个参考代码，让他参考写相应功能。当参考代码的逻辑不能满足要求，需要修改时，他不能很好的理解现在的逻辑需要对原先的代码进行修改，原有的变量命名、函数命名和注释会影响它修改为正确的执行逻辑。
6.会不断地进行测试，Bash，判断运行环境，然后让你确定。实际感觉没啥用，因为这个根本没有样例数据，测个寂寞。
同时还有一个毛病，你说检查一个功能，他就写一个函数，或者在程序正常逻辑中增加测试代码，相对主要业务流程写了一堆子冗余代码，print信息，让代码很难读。
7.这里总结一个心得就是，对于计算准确性要求高的函数，一定要写单独的测试用例，不然后面错了，真的很难调试。计算的正确性必须由自己判断。
另外一个心得是，对于错误调试的方向自己要有判断，不然真的就是越用越废，越用越生气，写了一堆子屎山代码。细节的知识点不能指望AI完全掌握，我就遇到了就是旋转矩阵转欧拉角的问题，结果怎么都不对。自己查了好的资料，连蒙加猜才搞定！
折腾了3天，终于把bug解决了。