别给 AI 捡烂摊子！我是如何用“非最强模型”搞定项目开发的

最近折腾了个小项目，顺便测试了一下手头现有的 AI 编程助手（类似 longcat-2.0 这种非 SOTA 模型）。说实话，一开始我是拒绝的，毕竟大家都盯着 GPT-4 或者 Claude 3.5 这种“地表最强”。但实际用下来，只要套路对路，这种平替模型也能把你伺候得服服帖帖，甚至能完成像 Telegram 列表管理工具这种稍微复杂一点的增强开发。

今天就来聊聊，预算有限或者模型能力有限时，怎么用正确的姿势让 AI 帮你干活，以及最重要的——别让它把你做好的东西给改坏了。

背景小科普：我让它干了啥？

这次的项目是对 GitHub 上的一个 Telegram 对话分组小工具 TeleFolders 进行魔改。原作者是个俄语大佬，项目功能也比较简陋。我的目标很明确：

1. 国际化：把全俄语界面改成英语（毕竟我不懂俄语，也不想学）。
2. 功能补全：原来的“创建分组”只是个摆设，得把它真的跑通。
3. 高级过滤：增加了 bot、group、channel 等维度的过滤器，不像原来只能躲 archived。
4. 数据迁移：加上 CSV 导入导出，方便备份。

这种活儿，交给顶级 AI 可能就是“一句话魔法”的事儿，但手头这个 AI（我们就叫它“小猫”吧）显然没那么听话。如果直接上指令：“帮我改写这个项目”，它立马给你整出一堆不可名状的代码。

核心心法：把 AI 当“实习生”，别当“全知大神”

用小猫的感觉，就像带一个刚入门的实习生：态度很好，干活积极，但经常听不懂重点，而且容易丢三落四。针对这种性格，我总结了一套三板斧。

第一招：方案一定要“写死”，别搞 One-shot

很多大佬喜欢“许愿式编程”，直接发给 AI 一句：“帮我实现一个功能”，然后坐等成品。对小猫这种级别的模型，这简直是灾难。

它很难一次性理解你的全部需求，写着写着就会“想入非非”，开始尝试一些你没提过的方案。

正确做法是：

1. 多轮讨（pī）论（píng）：先让它出几个设计方案，或者你自己心里有数后，引导它往你的思路上靠。
2. 生成 MD 文档：这是最关键的一步！当你确定方案后，强制 AI 把最终确定的方案总结成一个 Markdown 文档。
3. 按图施工：你再扫一眼这个 MD 文档，确认无误后，丢给 AI：“请严格按照这个 MD 文件的内容实施代码。”

这就好比你给实习生写了一份极其详细的《操作手册》，防止它在写代码途中突然“灵光一闪”，把你的需求给篡改了。如果是用 Mimo v2.5 这种高级模型，这一步可能不需要，但对 Longcat-2.0 来说，这是保命符。

第二招：善用 Commit，做你的“后悔药”

AI辅助编程场景

小猫有个让人抓狂的毛病：顾头不顾尾。

有时候你让它做“功能 A”，它咔咔一顿写，结果回头一看，之前写好的“功能 B” 被它改崩了，甚至直接删了。这时候别慌，也别在聊天窗口里跟它对线：“你为什么把 B 删了？”，它大概率会一本正经地胡说八道。

我的土法炼钢解决方案：

每完成一个功能点，验证没问题后，立刻提交代码到 GitHub。

我知道本地 Git 也能回滚，但考虑到 AI 有时候会发疯把目录删了，远程仓库才安全。

一旦发现它把新功能写崩了旧功能，你可以直接在 GitHub 上找到那个正常的 Commit。然后给 AI 下达死命令：

“去分析 Commit ID 为 xxxxx 的代码变更，特别是关于功能 B 的部分，然后对比现在的代码，告诉我哪里不一样，给我修回来。”

给它具体的证据链，它修复的成功率会高很多。

第三招：别跟 AI 耗在“查文档”上

有些任务属于“上下文无关”的知识点查询。比如我在对接 Telegram API 时，小猫死活找不到 updateDialogFilter 官方文档的正确用法，一直在上下文里瞎猜。

这时候千万别陪着它纠结。这就是带实习生的分水岭：有些时候你得亲自下场教。

我直接切到 Claude 免费网页版，把方法定义、类型定义、业务逻辑说明全查到了，然后直接把核心内容粘贴给小猫：

“不用找了，文档在这里，根据这个参数定义去改。”

效率瞬间拉满。记住，AI 是用来帮你写逻辑代码的，不是用来帮你做谷歌搜索的。

总结

虽然现在大家都在卷 SOTA（最先进模型），但很多时候我们手头的资源有限，或者想省点 token 费用。实际上，只要你能忍受稍微多一点的交互成本，“方案文档化 + 版本控制 + 人工辅助查询” 这套组合拳，完全能把一个平平无奇的模型调教成高效的开发助手。

这项目最终也顺利完工了，界面也变成了亲切的英语，导入导出也丝般顺滑。这也算是给想尝试 AI 辅助开发但又不想花大钱的朋友一个参考思路：工具强不强是一回事，会不会用又是另一回事。