对于agent模式的思考

使用了大半年cursor的会员，可以说我对于这款软件确实是爱不释手，在一定程度上彻底改变了我进行编程的流程，并且提高了很多代码效率，完成了很多以前我觉得需要花很多时间，甚至是不可能完成的事情。尤其是在Claude 3.7 以及后续的大模型发布之后，模型的编程能力大大提升，以前的大模型可能只是对小范围的函数修改或者是代码生成，但现在的大模型往往可以自主思考，根据列出的需求划分好todo事项，并且将其逐个完成，还可以自己进行测试和检查，出现上下文过多的情况时，也会将其存储在特定的markdown文件中，以方便减少模型的开销。

尽管如此，在我个人的实操体验中，这种agent模式的开发效果往往仍与个人的水平相关。以我自己为例，agent模式在我进行一个前端网页项目的功能开发（包括信息更新，功能美化等功能）时特别方便。因为这些任务对于目前的大模型来说并不是一件难事，对我来说，我自己可能需要很长一段时间去查询相关的CSS样式，或是调试好看的配色。但是对于大模型来说，我只需要把命令输给它，它就可以快速对代码进行迭代和更新，如果有不满意的地方，我再让它微调就可以。在这个过程中，我作为一个审核者的角色，虽然不完全懂相关的知识，但是由于我对于底层的HTML，CSS等代码的样式有相关的了解，所以可以很快评审相关网页的变改，并且能够针对性提出需求。在我可以控制的范围里使用agent模式是一件很舒服，很高效的行为，是绝对值得提倡的。

然而反之，当我自己想要开发一个IDE的插件时，使用agent模式反而会碰到困难。首先是我本身对于IDE的插件开发并不了解，看的文档并不是很多，没有相关的上下文。其次现在的agent功能都太强大了，往往我给它指令以后，他可以去联动地更改几个甚至十几个文件，每次都会带来大量的更改，但代码却不一定能运行，而我就需要花大量的精力去审核它生成的代码。这个过程其实是非常耗费心力的，因为在某种程度上，这其实是超出了我能力范围以外的事情，而我却妄想通过大模型来帮助我实现，这是一种冒险的行为。可以说我学习这个文档，然后自己借助大模型的简单辅助来完成这个项目所消耗的时间，可能跟我把所有的代码生成全部交给大模型，再一次次审阅它的代码，和它一起去修复一些我自己都不知道来源的bug，这两者消耗的时间其实是差不多，甚至可能后者是更多的。所以在使用AI进行编程时需要去抓住它的长处，但也要避免它的短处，可能对我来说最大的启发就是，在自己的能力范围内使用AI提效；而在能力范围以外的事情，多用AI辅助理解，而不是让它取代我本身的对项目的理解。