做了十一年大模型这行，我见过太多“神器”上线，然后迅速变成“神弃”。

前阵子朋友圈里，有个做全栈开发的朋友狂推一个叫 aider 的东西。说是能直接读代码库，自动改 bug，甚至能自己写测试。我一开始没太当回事，毕竟这类工具太多了，大多也就是个高级点的 ChatGPT 插件。

直到上周，我那个朋友发了个视频，展示他怎么用这个工具重构一个老旧的 Python 项目。

那速度，确实有点吓人。

我也忍不住下载下来试了试。毕竟，作为从业者，如果不亲自踩坑，就没资格说这东西好不好用。

说实话，刚上手的时候，我觉得它有点“狂”。

你给它一个任务，比如“把登录接口改成 JWT 验证”，它不会像以前那些工具一样，给你列一堆步骤让你确认。它直接就开始改代码了。

改完还会问你：“这样行吗？不行我再调。”

这种交互方式，对于习惯了指哪打哪的程序员来说，刚开始挺不适应的。你会忍不住想打断它，或者怀疑它是不是改错了。

但我耐着性子，看了它的修改记录。

嘿，你还真别说，它引用的上下文比我想象的要全。它不是只盯着当前文件，而是会去读相关的配置文件、依赖库，甚至是你之前的 commit 记录。

这就很有意思了。

很多所谓的 AI 编程助手，其实就是个代码补全工具。你敲一半，它猜你想敲啥。但 aider 开源模型 不一样，它更像是一个坐在你对面的初级工程师。

你可以跟它吵架，可以骂它改得烂，它会乖乖重写。

我拿自己手头的一个小项目练手，是个 Django 的后台管理系统。里面有些逻辑挺绕的，涉及好几个表的关联查询。

我让它优化一下查询性能。

它先是分析了我的 models.py，然后指出我用了 N+1 查询的问题。接着，它自动加上了 select_related 和 prefetch_related。

最关键的是，它没有乱改业务逻辑。

这一点很难得。很多工具为了追求“智能”，会擅自改变代码的行为，导致上线后出现诡异 bug。但 aider 似乎更倾向于在原有逻辑上做优化，或者至少会明确告诉你它改了啥。

当然，它也不是完美的。

我遇到过一个坑，它在我修改了数据库模型后，没有同步更新 migration 文件。

我当时没注意，直接运行了测试，结果报错。

后来我仔细一看，发现它确实漏了这一步。

这说明啥？说明它还不是万能的。它需要人来把关，需要人来审核它的每一行改动。

你不能完全把它当自动化工具，得把它当个搭档。

而且，它的安装配置对新手来说，稍微有点门槛。

你需要配置好环境变量，还得保证你的代码库结构清晰。如果你的项目是一团乱麻，它可能也理不清头绪。

我试过把它用在几个结构混乱的老旧项目上，效果并不好。它经常改着改着就陷入死循环，或者把无关的文件也给改了。

所以，我觉得 aider 开源模型 更适合那些代码规范比较好，或者愿意花时间整理代码结构的项目。

它不是来替代你的，是来帮你干脏活累活的。

比如写单元测试，比如重构重复代码，比如查找潜在的安全漏洞。

这些工作枯燥又耗时，但 AI 很擅长。

我最近用它写了一套完整的单元测试，大概两个小时就搞定了，而且覆盖率达到了 80% 以上。

虽然还有一些边缘情况没覆盖到，但底子已经打好了。

剩下的 20%，还得靠人来补。

这就是现状。

AI 能解决 80% 的问题，剩下 20% 的复杂逻辑和边界情况，还得靠人的经验和直觉。

所以，别指望它能一键生成完美代码。

但如果你能驾驭它，它确实能让你效率翻倍。

我建议你试试，但别太依赖。

保持警惕，保持怀疑，保持手动审核。

这才是正确的打开方式。

毕竟，代码是你写的，责任也是你的。

AI 只是个工具，别让它把你带沟里去。

希望这点经验，能帮你少走点弯路。