最近工作中也开始尝试完全使用ai coding来完成工作内容了，但说实话，这不仅要求我们对业务逻辑的理解到位，更要求我们对业务逻辑的描述准确。否则ai coding经常会莫名奇妙的生成一些无关的内容。在使用的过程中会遇到一些经常出现的坑，因此准备记录下来，帮助更多有ai coding需求的人，避免因为盲目相信ai coding而将严重bug携带到生产环境中。希望能对使用ai coding工作的人有所帮助。
需求描述：不止需要描述功能性（http链接泄露事件）
在调用外部api的时候，我会尝试让cusor给我写一个调用外部api的方法。需求很简单，写的也很快，然后很快也就调通了。但是当它一直运行一直运行直到某一次我修改逻辑重启服务的时候，我看到了no buffer space avaliable, maxinum connections reached的报错。一脸懵逼。。。。。然后查了一下，发现它的实现方式是每次请求来了之后创建一个http client，然后去调用，然后没有正确的去关闭连接。最后就出现了这样的内存泄漏。最后让它自己修复了一下。从这个问题其实可以看出，虽然我们清晰的描述了它的功能需求，但是对于一些非功能性的实现ai coding工具还是可能会出错。从解决方案上来看，我们和工具交互时不仅要清晰的描述功能，还可能需要在某些时候加上一些非功能性的约束（比如一些时候让它实现单例而非每次都创建新的实例）。
过度的生成降低效率（测试用例和说明文档）
这是最近使用cursor遇到的问题，可能你也会经常遇到：当你提出某个需求让它进行修改时，它不仅会按要求处理你的业务逻辑，在完成逻辑的修改之后，他还会给你输出一些测试用例和说明文档。从完备性的角度看无可厚非，但很多时候我们只是想简单的改个逻辑。多余的测试用例和说明文档会降低单词会话完成的效率，同时增加很多不需要的"垃圾文件"（我遇到过的一个比较恶心的情况是，修改相同函数的逻辑，测试用例不会在之前的测试文件中修改，而是会重新写一个测试用例文件，最后的结果就是测试用例文件非常多，类似下图）。解决方案也比较简单，无论是在cursor rule中去设置还是在提示词中添加默认不写这些文件，都是可行的（目前我是在提示词中写，当每开一个新的agent之后我都会告诉它当次以及之后的处理中不要生成任何测试用例和说明文档）。通过这样的约束方式来让它只专注于逻辑的处理，可以提高单次会话的效率。
好的模型能让你的效率提高
反之，坏的模型会让你的效率急速下降。最开始的时候Agent的模型我使用默认的Auto，然后输入需求之后不仅胡说八道，修改错误的时候还会把正确的内容给修改掉，搞的我花了很长的时间都在原地踏步。后面直接指定了好一点的模型，情况好转了许多。
总结
AI Coding提效并不是说有了AI Coding的工具之后效率就一定能上升，不正确的使用可能会导致你的开发效率不增反降，因此，识别出AI Coding的坑，避免AI Coding的坑才是提效真正的关键。所以后续遇到比较典型的坑，我也会记录下来。
（PS: 最近工作有点忙，更新不规律，后续尽可能规律更新）