学AI编程这件事，快的部分很快，一天就能做出一个能跑的页面；慢的部分很慢，有些坑不掉进去一次，你根本不知道它存在。下面这5个是我自己踩过的，按疼的顺序排。第3个让我白耗了整整两周，那两周我没有学到任何新东西，只是在把同一个错误重复地修。这5个坑有个共同点，它们都不来自工具本身，而来自使用它的人。工具的能力在涨，但人的习惯不会自动跟着涨，很多问题就出在这个落差里。下面按我踩的顺序说，越靠前的越常见，越靠后的越伤。
第一个坑，把AI当成搜索引擎用。很多人第一次接触它，开口就是“帮我写一个登录功能”，然后拿到一段看起来能用的代码，贴进项目里发现跑不起来，于是回头质疑工具不行。问题不在工具，在于你只给了一句话，它对你的项目一无所知——用的是哪个框架、已有的代码风格是什么、数据库怎么连，全是空白。
同一个需求，把项目结构和相关文件一起给它，出来的代码质量完全是两回事。这中间的差别不在提问的技巧，而在你愿不愿意先花十分钟，把你知道而它不知道的背景交代清楚。学习阶段最容易省掉的就是这十分钟，而这十分钟恰恰最不能省。差别具体体现在哪？同一个需求，给不给上下文，出来的代码可能连命名风格都不一样。前者能直接接着用，后者你还要花时间调整，调完才发现不如自己写。省下的那十分钟，最后是加倍还回去的。
第二个坑，一次让它改太多地方。新手往往想一步到位，把需求写成一大段，让它把七八个文件全改一遍。结果是改动混在一起，出了问题你根本分不清是哪一处引起的。更麻烦的是，一旦改坏，你连回退到哪个版本都说不清，因为所有改动都发生在同一次提交里。判断改动是不是太多，有个简单的标准：如果这次涉及的文件超过三个，就值得先停下来拆一拆。不是不能一次改，是改完你没时间逐个核实。改动越集中，出问题时你能定位的范围就越小。
比较稳的节奏是一次只推进一件事，跑通了、看明白了，再往下走。慢一点，但每一步都是你能说清楚的状态。用AI写代码最大的错觉，就是以为快是省出来的——其实快是省在不用返工上，而不是省在少点几次确认上。还有一个具体的做法：让每次改动都有一个明确的验收动作。改完之后跑一遍，看结果对不对，再看它到底动了哪些文件。两件事都做完，这一次才算结束。听起来像流程，其实是在给后面的自己省时间。
第三个坑，也就是让我白耗两周的那个：不看它改了什么就直接提交。当时我在做一个后台接口，AI给出的改动看着很合理，我扫了一眼没发现问题就提交了。真正的问题在后面才浮出来——它顺手改了一个公共函数的行为，那个函数被另外几个地方调用，表面上一切正常，直到另一个功能开始出现奇怪的返回值。
排查的过程比想象中长得多。我先怀疑新写的接口，再怀疑数据库，最后才想到去看这次提交到底动了哪些文件。那两周里我反复在做同一件事：验证一个又一个错误的方向。回头总结，最该做的是提交前花两分钟看一眼改动清单，尤其是那些你没有明确要求它改的文件——它动了，就一定有你该知道的原因。那次之后我改了习惯：每次提交之前，先看一遍改动的文件清单和每一处的具体差异。如果某个文件我没让它改，它却出现在清单里，我会先停下来问清楚再继续。这一步大约两分钟，换回来的是我不用再花两周去猜哪里出了问题。
第四个坑，没有版本控制兜底就开始用。有人觉得反正是个人项目，随手改改就行，结果在AI连续改动几轮之后，发现想回到某个能跑的状态都做不到。版本控制在这里不只是备份，它给你的是“随时可以退回去”的底气。有了这层底气，你才敢让它放手改，也才敢在改坏的时候不慌。版本控制还有一层作用常被忽略：它让你能对比。当结果不对的时候，你可以直接看这一次改了什么，而不需要靠回忆。用AI写代码，改动往往又快又碎，没有对比能力，等于每次出问题都要从头猜一遍。
第五个坑，工具换得太勤。这类工具更新很快，每隔几天就有新的讨论和新的推荐，于是有人把大量时间花在换工具上，每个都试一点，每个都没用顺。工具之间的差别，远没有“你用得熟不熟”来得重要。与其追新，不如先把手上这一个用透，把它的脾气摸清楚。判断一个工具要不要换，可以看一个简单的信号：你在这个工具上遇到的问题，是不是已经开始重复出现。重复出现说明你已经摸到了它的边界，这时候换工具才有意义。如果问题还很零散，那多半不是工具的问题，是你还没用熟。
这五个坑里，前两个费时间，后两个费心态，只有第三个是真正伤到项目的。它们的共同点也很简单：都出在“想省一点”的地方。想省那十分钟的背景交代，想省那两分钟的改动检查，最后都要用几倍的时间还回去。说到底，这几个坑教的都是同一件事：把该花的时间花在前面。AI把写代码这一步变快了，但没有让判断这一步变快。判断这件事还是得人来做，而且做得越早越省事。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
