最近用 AI 写程序，想把碰到的问题写下来。

以前所有代码都要自己一行行输入，现在像雇了多个编程助理，我只管当设计师，想需求、定逻辑，用自然语言跟AI交流，让它去实现。对我这次做的App程序来说，大部分需求它基本都能做到。

但用久了，暴露的问题也特别明显。

我得把需求说得越详细，它写的代码就越符合我的想法。如果我把中文逻辑、伪代码全给它，那效果最好，但那样倒还不如自己写了算了。我一般会把功能拆成小功能，将小功能的需求一条条列清楚，然后丢给 AI 去写。正常情况下，描述越具体，代码就越贴合我的想法，可我若描述得笼统，它就会按自己的模型理解自由发挥，结果往往跟我想要的不一样，又得打回重写。

所以现在我的工作，很大一部分就是写提示词，把想法拆细、说透，让 AI 精准执行。但过程中几个问题，也实在讨厌。

一、模型对上下文的记忆短暂

我写后端时经常要操作数据库，单个用户对象在DB中字段特别多，数据量也大。AI 每次查库，都习惯性地把整个用户对象全读取出来，但实际需要很少字段，全量加载明显不合理。我经常提醒它：只查需要的字段，按需查找和更新。好了，它这次听懂了，也改对了，可几次任务交互后就又忘了。

过不了多久，只要我没特意再提，它立马又回到老样子，在新逻辑中依旧加载整个用户对象。我本来以为，它能记住上下文，之前定好的规范后面会自动沿用。可能是考虑到大模型的算力问题，遗忘也是为了减少算力消耗，所以必须次次重复提醒。重复劳动多了，事情变得枯燥，心情也会烦躁。

二、永远不会主动自测，全靠你催

第二个问题和上面很像：AI 写完代码几乎从不自测。我必须明确告诉它要自测，它才会去做——自测本身也是一件消耗算力的事，它总是能省则省。

后来我特意强调：每次改完代码，必须自测，检查语法错误、能否正常启动、有没有报错，有报错就要修复。前几次它还照做，可交互轮次一多，它就彻底忘了。每次改完都用十分肯定的语气说已经完成，结果我一眼就能看到代码里的语法错误告警——因为它没有执行语法检查，所以根本没发现。

我一直觉得，写代码→自测→修复，这是最基础的连贯动作，每次都要重复写提示词，实在让人受不了。可能我用的模型不是专门针对编程深度优化的，但这种基本的工程常识，理论上它不需要被反复提醒就能做到。后面我打算多试几个模型，看看有没有能主动自测的。

三、难题解决不了，就直接逃避、换方案

这点我碰到特别多次。

今天就遇到一个：本地开了代理，导致App的WebSocket客户端通过localhost连不上本地服务端。我一开始也没反应过来是代理问题，只觉得本地连接理论上不可能失败。AI 跟着一起分析，各种排查代码，折腾好几轮都找不到原因。

一旦它尝试多次都解决不了，立刻开始逃避：“要不我们别用 WebSocket 了，换成 HTTP 定时轮询吧。”

这根本不是我要的结果。我要的是解决问题，而不是绕开问题。它甚至会乱分析，把客户端端口当成服务端端口，越说越离谱。其实这个问题查起来很简单，只要查一下 localhost 被映射到什么地址就行，可它一直盯着代码和日志，没能跳出环境层面去思考。后来，我突然想到可能是代理的问题，于是关掉代理、重启电脑，问题直接就解决了——遇事不慌，重启大法好。

AI 的背后是人，能否用好 AI 也靠人。一旦遇到死局，经过几轮分析都无法解决时，它就会换方案、绕路、糊弄过去，这在我看来就是典型的逃避问题。

四、疯狂堆代码，不会抽公共方法

还有一个很明显的问题：AI 特别喜欢写重复代码。相似甚至相同的逻辑，到每个模块、每个文件，它都重新实现一遍，不会抽公共方法，不会复用。结果就是代码量巨大，尤其客户端代码，越写越臃肿。

重复代码——这是典型的代码坏味道（Code Smell）。如果后期需要修改，就得多处改动，不仅容易遗漏，测试起来也很麻烦。难道编程模型训练时，没有融入 DRY 原则吗？

所以现在 AI 写的每一段代码，我都会仔细 review 一遍。如果代码不合理，我就直接撤回，换种描述方式再让它写，同时告诉它哪些地方逻辑相似，需要合并或抽象。

对于特别复杂的逻辑，比如 App 中客户端与服务端的增量更新、数据差异互补，我干脆自己先写一遍、测通，再把代码贴给 AI，让它照着复刻，这时它就能写得很好。

最后总结一句最真实的感受

用 AI，你千万别把它当成一个经验丰富、一点就透的程序员。它更像一个动手能力强，但记性差、时刻需要人盯着、遇到难题就想躲的小孩。

其实本质上，AI 的行为背后核心是算力的考量，只要朝着算力消耗的方向去思考，它的种种看似不合理的行为，就都能找到合理的解释。

你必须把需求拆得很细，一步一步教它怎么做；你必须反复强调规则；你必须全程把关；复杂核心的东西，还得自己动手。