你用AI编程用到什么深度了?我把自己的真实用法摊开说

      这个问题下面的回答，基本分两派。

　　一派是“我早已不写代码了，全交给AI，一晚上跑三个项目”；另一派是“AI写的都是垃圾，我从不用”。

　　两边我都不信。我就把自己真实的使用深度摊开讲，包括哪些环节我完全交给它，哪些我死活不给。

先说我现在的真实状态

　　我干了十年开发，Java 为主，现在做物联网、水务监测平台，也接外包。按代码量算，现在我手里交付的东西大概有一半是它先写的。

　　但这句话很容易引起误解，所以得拆开说。

它是我的手，不是我的脑，方向盘得自己握着

一、样板活，全给它。接口骨架、DTO、参数校验、分页查询、Excel 导入导出、定时任务壳子。这种活我以前一天写三个，现在一上午能出十个，而且它写得比我认真，注释、命名、日志一样不落。

二、不熟的语言和框架，靠它入门。我 Python 就是这么补上来的。以前碰一个陌生技术栈要磨两天文档，现在先让它给我一个能跑的最小例子，我跑通了再反过来问为什么。

三、看不懂的代码，让它翻译。接外包最怕接手别人的烂摊子。现在我把类丢进去，让它给我画调用链、说清楚这个方法到底干什么。这一项省的时间比写代码还多。

四、测试用例，它写初稿。特别是边界值，它能想到我懒得想的那些。

再说我坚决不交出去的部分

　　重点在这里。

　　我不让它大批量写核心代码，不是因为它写不出来，是因为工程不是搭积木，是汤里加盐。

　　搭积木是一块一块往上叠，加错了拿下来就行。汤里加盐不是，盐一下去就化在整锅里了，你拿不出来。局部的一个设计，会悄悄影响整个结构。

　　我写东西的时候，几十行代码可能几天内被我推翻重写七八次。不是因为写得差，是因为我在想三件事：这段代码能不能放进现有工程里；如果不行，是新代码的错还是老代码该改；以后的需求进来时，现在这个设计撑不撑得住。

我缺的从来不是写那几十行的时间。

　　而AI最大的问题就在这儿：它面对问题，默认选择局部修补。哪里报错补哪里，哪里不兼容加个判断。于是本来应该早早暴露的架构问题，被一层层 patch 盖住了。

哪里报错补哪里，底下那块歪的没人管

　　等你再添一个新需求，一天都改不完。很多 vibe 出来的项目后期特别卡，都是这个原因。

关于“让AI审AI”我的看法

　　现在很流行一个玩法：一个线程写代码，另一个线程 review。

　　听着很自动化，但我自己试下来感受很一般。因为两边的盲区是一致的。它写代码时不检查错误，它 review 时也想不起来该检查错误。两边配合得很好，给你造出一个“一切正常”的假象。

　　所以我现在只把它当第一道筛子：筛拼写错误、空指针、没关的资源、忘处理的异常分支。这层它确实很快。至于“这个设计到底对不对”，还得我自己看。

它负责吐得快，挑次品的活还得你来

那些方法论为什么没用

　　每隔几天就能刷到一篇“AI编程最佳实践”，里面写着：优先复用现有函数、降低耦合、遵循第一性原理。

　　我每次看到都想问一句：到底什么叫合理的复用？跨模块复用算不算好设计？你一边要求“优先复用”，一边要求“降低耦合”，这两句很多时候是矛盾的。

　　这种话对人说没用，对AI说更没用。它会很乖地回答“好的，我会遵循高内聚低耦合”，然后接着按它原来的方式写。

　　真正有用的约束都是具体的：这个模块只能依赖那两个包；这个接口返回结构固定成这样；设备离线超过五分钟要进告警队列、不允许直接写库。

约束越能被验证，AI干得越好。

我现在的干活流程

　　不玩虚的，就四步：

• 我自己先把数据结构和模块边界想清楚，这一步不假手；
• 把改动拆成一小块一小块，每块让它先说方案，我看一眼再动手；
• 它写完我自己跑，关键数字一定自己验；
• 连续两次改不对，我就不跟它较劲了，自己上手。

　　最后一条是我踩坑踩出来的。人很容易在“再试一次就行了”里陷半小时，而那个 bug 我自己上手五分钟就完了。

所以回到那个问题

　　我用到什么深度？

　　大概是：它是我的手，不是我的脑。能把活干快三到五倍，但方向、结构、验收标准这三样，我一样都没交出去。

　　我也不觉得这是保守。接外包的人都懂，交付出问题是你赔钱、你半夜起来改，不是模型赔。

　　最后说句实话：现在网上吹得最狠的那批人，很少把自己的工程拿出来给人看。而真正天天交付的人，说法都差不多——特别好用，但不能撒手。