一些Qoder的阶段使用体验总结

我的开发环境一直以VsCode为主，没有足够的动力去尝试其他IDE，直到Qoder降价，订阅费改成了10刀起步。对比其Credits的消耗，10刀订阅每月给的2000Credits确实依然谈不上够用，但相比之前20刀的定价，我觉得多少有了些继续尝试的理由。以下是第一个月Credits接近消耗完毕后带给我的一些使用体验（吐槽）：

一、复杂任务理解到位 但会犯低级错误

我用Qoder尝试的第一个完全由agent自主生成的项目就是本博客程序。初始prompt谈不上精细，但规范了实现技术栈，数据库结构，UI风格等方向性问题，其余细节由Qoder自主发散完成的。初版效果符合预期，但存在如下我认为比较降智的问题，比如：

系统配置没有默认持久化保存：

初版程序中，这个博客的系统配置保存在一个Config类中，配置的修改与保存是通过setattr()实现的，这样的设计我多少有点意外，一般的做法不是持久化成json或者yaml之类的吗？以至于关于页面中描述性的文字中都不能有回车，因为一旦保存就会引发异常。而且不源码部署的话，配置根本就无法保存。

分页配置没有生效

系统配置中提供了分页配置选项，但实际代码并没有引用配置，而是自己写死了一个分页参数。配置是Qoder自己写的，后面的实现也是自己实现的，但是竟然忘记了引用。

数据统计错误

文章，随思，话题，网站的页面访问量，这些统计模块通通存在Bug，要么是该更新的没有一起更新，要么就是更新逻辑存在无法理解的低级错误（比如更新数据也会计数+1）。

个人设置保存错误

个人设置进行保存时存在Bug，比如我更新我的邮箱，默认把我之前设置的头像也给重置了。

默认没有403,404,500错误页面

作为一个Web应用，应该有403，404，500错误页面，但Qoder的初版结果并没有提供。

类似问题不再列举，总之是我无法理解的一些降智问题，我想这些开发范式不应该在每次prompt显式强调，Qoder本身就应该有妥善的默认处理。

二、遍地测试文件，不知道自己清理

Qoder干活的过程很专业，写代码的同时会进行测试。但是Qoder明显不知道工完场清这回事。一轮对话下来，项目文件夹给弄的乱七八糟。各种test脚本和过程输出，注释。不显式要求删除，从来都不知道自己处理。为了删除这些垃圾，起码白白消耗我几十上百个Credits。

三、Credits消耗速度过快

尽管官方声称Credits的使用效率至少提高30%，但实际应用中依然感受到明显不够用。本站的博客程序从开始到可以部署到生产，实际消耗超过了2000个Credits，算上试用送的1000个Credits，总共消耗了大约2500个Credits左右。关键是这些Credits两天就烧光了，想再继续流畅使用得等到下个月29号了（我是9月29号开始订阅的）

说完了槽点，也说下Qoder的优点：

一、文档清晰

Qoder生成的文档相当详细，代码中的类型注释，函数参数，返回值，异常基本都照顾到了。而且生成的md文档读起来条理非常清晰。这点对重构、测试、都很有帮助。有一些时间久远的历史代码，在Qoder的帮助下回忆起来很多过去已经忘记的细节。

二、代码质量不错

除去逻辑上犯的一些低级错误，Qoder生成的代码质量相当高，一些写法实现上能兼顾安全，效率和可读性，比如使用装饰器，枚举，with语句等等。有些技巧你也知道，但嫌麻烦可能不会去用，Qoder不会。

三、前端效果到位

这个博客的页面效果我个人还是满意的，也是改动最小的部分。基本风格就是第一版时Qoder给的那版，UI层修改很少。

四、对Bug反馈的理解到位

尽管第一版程序留下来Bug一箩筐，但Qoder的Bug反馈机制非常清晰，能快速定位到问题，并给出解决方案。Debug阶段的沟通不算费力，基本上一两轮对话就定位Bug，并给出修改方案。咱就说要是能一步到位，能节省多少Credits啊！

总结

中午和朋友吃饭，谈到了Qoder，我的看法是：Trae,Qoder这类的IDE毫无疑问是码农的未来，以后更多的需求是Debug，而不是写代码。当下这个节点，非Coder想直接用这类IDE构建一个强壮，可商业化实施的项目，还比较困难，原型可能不难生成，但距离健壮的生产部署还有些距离。