乐于分享
好东西不私藏

AI辅助开发的一些实践体会

AI辅助开发的一些实践体会

我用AI写了三个月代码,终于明白:它快的是刀,慢的是脑子。纯黑盒就是玄学编程,上线必崩,而且你修不了。

三个月前,我以为自己摸到了编程的终极捷径。

需求丢进去,函数吐出来。一个周末就能干完过去一周的活。Ctrl+C、Ctrl+V,回车键敲得比心跳还快。

那时候我觉得,AI编程,稳了。

三个月后,我坐在电脑前,对着一个线上bug发了四小时呆。那段AI生成的代码,像一座漆黑的屎山压在我胸口——它跑得通,但我看不懂。 想改,无从下手;想重写,牵一发动全身。

那一刻我终于醒了:纯黑盒,就是玄学编程。

短期能跑,上线必崩。而且你修不了。

一、屎山是怎样炼成的

最开始,我犯了一个几乎所有新手都会犯的错:把AI当成项目经理。

项目搭好,结构定好,剩下的代码全让它写。它写得飞快,我review得懒惰。一个函数一个函数地过,看着输出结果没错,就放行了。

半个月后,代码量上来了,问题也上来了。

某个边界条件没处理,某个状态流转逻辑有漏洞,某个函数看似正常,实则内部逻辑完全经不起推敲。更要命的是——这些东西搅在一起,根本拆不开。

AI写的代码,往往没有清晰的模块边界,没有一致的设计风格,甚至变量命名都随心情。它像是一个从不用维护别人代码的程序员,写完就跑,哪管身后洪水滔天。

你省下来的写代码时间,全都在看代码、猜代码、骂代码里翻倍还回去了。

二、唯一铁律:你必须看得懂

痛定思痛,我给自己立了一条铁律——

AI写的每一行代码,在合入项目之前,我必须能把它讲给别人听。

这就是底线。做不到,那就重来,或者自己重写。

具体操作上,我改了一整套工作流:

· 架构设计,人来做。 模块怎么划、接口怎么定、数据怎么流,全在自己脑子里过清楚。
· AI只填具体函数。 我告诉它入参、出参、核心逻辑,它负责把语法细节填上。
· 写一个,看一个。 绝不让AI连续生成超过一个函数,写完立即review,逻辑走不通当场改或当场删。

这套流程的核心就一句话:人可以写框架,让AI填实现。 但review这道关,半步不能退。

因为你一旦退了一步,AI就会进三步。最后你打开项目,看到的全是陌生的、别人的思路——而你的项目,从此不再姓你的姓。

三、文档和Plan,比代码值钱

后来我发现,真正省力的,不是让AI写代码,而是让AI写方案。

接到一个新需求,我现在的第一反应不是让它写代码,而是:

“你先别写,给我出技术方案、改动点、流程图。”

它出一版,我对着看。能讲明白,再让它动代码。讲不明白,就继续追问,直到理清楚为止。

但这里有个坑:AI写的文档,别全信。

它常常会把看似合理实则矛盾的逻辑藏在流畅的表述里。你以为它讲清楚了,其实它只是写得好听。

我的解法是:再拉一个模型怼一遍。

把A模型出的方案丢给B模型,让它挑刺、找矛盾、问问题。两个AI吵完一轮,方案里的坑能少一半。

但注意,这只是处理复杂问题时的“重型武器”,日常开发别这么干——太累了。平时自己review,比让两个AI辩论快得多。

四、“效率”的真相

聊到这儿,必须承认一个反直觉的事实:

用AI写代码,整体不一定省力。

来算笔账:

· 写代码的时间,确实省了。以前写一天,现在可能两小时。
· 看代码的时间,翻倍了。你得读懂它的逻辑、验证它的边界、修正它的风格。
· 调试的时间,翻倍了。自己写的bug,自己大概知道去哪找。AI写的bug,你得先猜它当时“在想什么”。

整体下来,工作量未必减少。唯一的收获,是你会被逼着更快理解代码背后的原理。

这是一个被动的学习加速。它逼你去看文档、去查设计模式、去思考架构——因为你不这样干,屎山就等着埋你。

五、新的工作流

所以我彻底换了一种方式。现在的流程是这样:

先自己理清流程和模块 → 拆成小单元 → 让AI写每个小函数 → 写一个看一个 → 通过一个合入一个。

再也不做“AI项目经理+吵架调解员”了。

那种日子太荒唐了:白天写prompt让AI干活,晚上对着bug让另一个AI解释第一个AI写了什么——你从一个创造者,沦为了两个模型之间的传话筒。

最后一句话

这三个月的折腾,我悟出来的东西其实特别简单:

AI是凿子,你才是雕刻师。

凿子再快、再锋利,方向错了,就是白费力气。它砍掉的石头,最后都得你用手一块一块地补回去。

别把灵魂外包。

代码可以AI写,但主意必须自己拿,逻辑必须自己懂,每一行代码必须自己认。

这才是AI编程,唯一正确的方式。

相关学习资料