使用AI开发项目的经历和感受：关于AI 编程的碎碎念

引言：一次失败的 AI 编程实验

最近AI编程的话题实在是太火了，各种"让AI一周开发一个完整项目"、"0基础用AI月入过万"的标题满天飞。说实话，我一开始也挺心动的——既然AI这么厉害，那我是不是可以躺着就能把代码写了？

正好我有个项目想法：把GitHub、Gitee这些Git平台当作存储后端，做一个类似网盘的文件存储工具。功能听起来不复杂，就是调用Git的API加上本地数据库管理而已。

于是我做了一个大胆的实验：用我完全没接触过的Go语言，0干预让AI独立把项目写完。一方面是学习Go，另一方面也想检测一下AI的真实能力到底怎么样。

结果却差强人意。

---

回顾：一路走来的心酸

[外链图片转存中...(img-Wtm9jLbM-1787411645183)]

先交代一下实验环境：我使用Cloud Code或Codex接入DeepSeek，项目目标是实现基于Git API的文件存储功能，技术栈为Go（此前从未接触过）。

我的预期相当乐观：只需将需求告知AI，让它自主查阅GitHub和Gitee的API文档、自行编写代码并完成调试，我作为最终的验收者即可。毕竟不就是常规的CRUD加API调用组合吗？

然而实际体验却与预期相去甚远。

第一天：AI用了半天时间交付了一个具备基础界面、可运行的雏形，看起来有模有样。当时我甚至有些兴奋，觉得AI的生产力确实名不虚传。

然后问题就来了：业务逻辑全是报错，基本功能完全不可用。代码风格更是一言难尽。

接下来的四天，我陷入了一个循环：发现问题 → 向AI描述现象 → AI修改代码 → 引入新的问题 → 继续沟通……五天下来，项目总算达到了勉强可用的状态，但整体开发效率与我使用熟悉的技术栈手工开发相比，几乎没有明显优势。更值得注意的是，整个过程中我的精力消耗反而比传统开发更高——与其说AI在协助我开发，不如说是我在给AI擦屁股。

这5天的经历，让我对AI编程有了完全不一样的认识。下面我将遇到的问题逐条理出，作为后来者的经验参考。

---

思考：AI开发的不足

[外链图片转存中...(img-cgkmHrNc-1787411645183)]

1. 知识错误：AI查了，但没完全查对

我的项目核心是操作GitHub和Gitee的API。一开始我让AI自己联网去查API文档，还让它总结了哪些功能能实现、哪些不行。

AI给我的总结看起来头头是道，结果一用就发现问题：有些明明支持的API，AI硬说不支持。比如Gitee是有清空仓库的API接口的，但AI斩钉截铁地告诉我这个功能实现不了。

后来还是我自己去翻文档才发现被AI坑了。你说AI没查吧，它确实查了；你说它查了吧，关键信息它就是能给你漏掉。

2. 复杂业务写不了：断点续传这些，AI根本理解不了

如果是简单的前端页面或者常规CRUD，AI确实能写得像模像样。但一涉及到需要深度理解流程的复杂业务，AI就彻底拉胯了。

我的项目中包含断点续传、下载重试、Git Tree结构化操作、并发任务队列等功能模块。仅就这些需求，我与AI反复沟通调整了好几天，代码版本迭代了多次，问题仍然是修复一处、冒出一处。

为什么？因为这些逻辑需要你在脑子里把整个数据流走一遍，哪里要做状态校验，哪里要处理异常，哪里要保证原子性——这些AI根本"想"不清楚，它只是在根据已有代码片段东拼西凑而已。

3. 代码质量差：能用就行，冗余爆炸

AI写的代码有一个特点：它只追求"跑通"，完全不管可维护性。

举几个我项目里的例子：

• API调用有公共流程（构造请求→发送→判错→解析），AI偏不封装公共函数，每个请求都把同样的逻辑复制一遍
• 代码里充斥着大量冗余的if判断和完全没用的死代码
• 有现成的相似函数，只是参数或者返回值有点不一样，AI直接新建一个函数，90%的代码完全重复——它宁可堆代码，也不肯重构
• JSON和实体类的映射，AI居然是一个字段一个字段手动赋值的，稍微正常点的项目都会用反射或者映射库吧？

最离谱的是判断文件是否上传完毕的逻辑：AI的做法是下载所有文本文件，然后字符串比对。实际上明明可以通过API拿到Git Tree里所有文件的SHA，跟本地比对一下就行了。

AI写的代码，就是那种"能跑，但谁接手谁骂娘"的水平。

4. 架构混乱：分层？不存在的

正常开发我们都会讲究个分层，业务层、数据层、API层各干各的。AI呢？你一开始明确告诉它要分层，它确实会分。但写着写着就忘了。

比如我项目里的数据库操作，一开始AI确实规规矩矩地写在了DB层。后来我要加个功能，没特意强调分层，AI直接把SQL语句写进了业务层代码里。前后风格完全割裂，好好的分层架构被它糟蹋得不成样子。

AI没有全局观，它只能看到你当前给它的那点上下文。

5. 只管局部不管全局：为了新功能，把旧功能改坏

这一点我印象特别深。

我的文件传输一开始是流式传输的，因为要避免大文件把内存撑爆。后来我让AI加断点续传功能，不知道为什么，它居然把文件一次性全部加载到内存里，然后逐块比对哪些已经上传了——流式传输的设计直接被它干没了。

这还是我发现的。那些没发现的地方，天知道它偷偷改坏了多少东西。

6. AI的思路你永远猜不到，优化只会越改越屎

给你们讲个最搞笑的例子。

我有个获取Git账号信息的功能，获取信息的API早就写好了，调用一下就行。我以为这是最简单的需求，结果你猜AI怎么干的？

它把账号下所有仓库全量拉取下来，取第一个仓库路径的前缀当作用户名。

我：？？？

当时我就气笑了，让它改。正常人的思路应该是把那坨屎删掉，直接调用现成的API对吧？AI不，它在那坨屎后面加了个判空操作，然后才调用获取用户信息的API。

AI优化代码的逻辑是：永远不删，只往后加。代码越堆越多，屎山越垒越高。

7. 别指望AI能帮你找Bug

我这个后端才不到20个文件，说实在的算是个很小的项目了。但因为业务逻辑不是常规的CRUD，出了问题AI根本找不到Bug在哪。

更坑的是那种看起来流程没问题、但死在细微处的静默Bug。

面对简单的需求，AI写的代码大框架大部分是对的，但出问题往往出在某些极其细微的地方。比如我后来重构项目的时候，发现很多地方的问题只是传错了字段——比如根据某个字段删除数据、级联删除关联记录的时候，AI可能理解错了字段的意思，用了另一个相似的字段，结果就是删除没生效，但代码不报错，流程看着全对，就是结果不对。

这种Bug你丢给AI，给它20分钟它都查不到。因为AI"知道"整个流程逻辑是没问题的，它只会在流程结构上反复检查，根本不会去怀疑一个"看起来很合理"的字段传错了。最气人的是，查不到问题也就算了，它还会跟你一起怀疑是不是流程设计有问题，让你改结构改逻辑，结果越改越挫。

每次都是我先看出点苗头，比如"这里是不是状态没更新对"，然后去问AI，AI才一脸惊喜地回答"对对对，就是这里！"。

8. 记忆如同金鱼，改完这里漏那里

复杂的项目往往有很多需要注意的地方，AI是真记不住。

你让它改一个问题，改完A处忘了B处，甚至同一个文件里的相似问题都改不全。因为AI的"视角"是受限的，它看不到整个项目的全貌，只能根据你给它的那点上下文来干活。

更气人的是，有时候你问它"这个问题是不是全改完了"，它信心满满地说"改完了"，结果一跑，还有一半漏网之鱼。

---

自省：查找自己的问题

上面说的都是AI的锅，但有一类问题其实出在我们自己身上。

如果你自己不看代码，你连怎么问AI都不知道。

因为不了解业务代码的具体逻辑，你很可能会问出一些无厘头的问题，或者让AI去执行一些完全错误的任务。而AI呢？它才不会告诉你"你这思路有问题"，它只会顺着你的话头往下说，把错误的事情给你干出来。

还是前面那个获取用户名的例子。AI一开始写的代码是全量拉取仓库取路径前缀当用户名，那当账号下没有仓库的时候，用户名自然就无效了。我就去问AI这个问题怎么解决，AI说得头头是道：加个条件判空，再用获取用户数据的API兜底。当时我没看代码，觉得AI说得很有道理啊，逻辑通顺，完美。结果后来我去审代码的时候差点没吐出来——判空是加了，兜底API也调用了，但前面那坨拉取所有仓库取前缀的屎代码，AI一行都没删。

最后的结果就是：你瞎指挥，AI瞎执行，代码越写越烂，最后还得自己背锅。

---

总结：这些经历告诉了我什么

说实话，这5天折腾下来，我最大的收获不是那个勉强能用的项目，而是对AI编程有了一个清醒的认知：

别把AI当外置大脑，代码要自己了解，思路要自己把握。

AI确实会写代码，但它写的是"你让它写的代码"，而不是"应该写的代码"。它根本不会去考虑业务逻辑合不合理，架构清不清晰，代码健不健壮——它只负责把代码生成出来，至于好不好，那是你的事。

以前我用AI的模式是：把需求、文档、技术栈全丢给AI，等着它产出。

现在我的模式完全变了：我只把AI当一个代码生成器，具体要生成什么，我自己完全掌握，写出来的代码我必须自己审一遍。

简单来说：AI负责敲键盘，我负责动脑子。

---

反思：使用方式AI的正确方式

总结了几条我自己现在在用的原则，大家可以参考：

1. 你必须完全掌握代码

在让AI改代码之前，你得知道它会改什么、改了之后会有什么影响。心里没底就别乱让AI动代码，否则改出问题你都不知道去哪找。

2. 先让AI写工作清单，再让它动手

不要上来就说"给我加个XX功能"。先让AI把它打算怎么改、改哪些文件、每一步做什么，列一个详细的工作清单给你。你先审一遍清单，觉得没问题了再让它开工。

3. 需求要具体，改之前先让AI分析范围

特别是你要改AI之前写的代码的时候，这一点尤为重要。AI对自己写的代码其实也没什么"记忆"，你说"我觉得这里有点问题，你改一下"，它很可能完全get不到你的点。

正确的做法是：把需求说清楚，把改动范围说清楚，甚至把你的思路也告诉它，让它基于你的想法去写代码，而不是让它自己"自由发挥"。

4. 提示词不要模糊

"给我的项目加个XX功能"这种话就是典型的反面教材。要么AI理解不了你的意思，要么写出来的代码完全没有架构可言。

你得明确告诉它：这个功能加在哪个层、用什么模式、遵循什么规范、跟现有代码怎么衔接。越具体越好。

5. 代码规划自己来，别指望AI给你出主意

我试过让AI帮我优化某段代码，AI说"不推荐优化，这样就挺好"。我说了几句我的理由，把代码细节给它讲了讲，AI立刻改口说"你说得对，确实应该优化"。

看到没有？AI就是个墙头草，它没有能力做全局的架构决策。代码怎么规划、怎么设计，这些得你自己来，AI只是执行的工具。

---

写在最后

[外链图片转存中...(img-zFVxovVe-1787411645183)]

说了这么多AI的坏话，我并不是觉得AI没用。恰恰相反，现在的我每天都离不开AI辅助编程。

但我觉得现在的风气有点走偏了——到处都在吹"AI全栈开发"、"AI替代程序员"，搞得好像明天程序员就要失业了一样。

实际上呢？AI离"会写代码"还差得远。它能帮你省去很多敲重复代码的时间，能帮你查文档、写样板代码、做一些机械性的工作。但涉及到业务理解、架构设计、代码质量这些真正考验程序员水平的地方，AI目前还远远不够看。

AI只是写代码的工具，而代码背后的思考，永远得靠我们自己。

别把思考的权力让渡给AI，这是我这5天踩坑踩出来的最大教训。