夜雨聆风我用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编程，唯一正确的方式。
