其实之前在社区里聊过不少关于AI写代码的话题有人觉得我现在这套全靠自己控上下文的搞法不够自动化甚至有点老派。今天索性敞开聊聊不是想争个谁对谁错就是分享一下我真实的开发状态。这几年各种AI编码工具满天飞TRAE、CodeX、Claude Code、DSH大家都在讨论怎么让AI自动去读仓库、自动去改代码。很多人容易陷入一种“差生文具多”的怪圈总觉得工具用得越花哨写出来的代码行数越多自己就越牛。但我觉得写代码真不是按斤卖的它拼的不是你敲键盘的速度而是你对项目架构的把控力。我自己是怎么用AI编程的呢怎么说呢其实听起来挺像个笨办法的。我的项目是用Go语言写的代码拆得非常散一个Go文件可能也就三十到一百行。我从来不直接把整个库扔给AI让它自己去悟。我要改个功能会先在本地建个临时文件从项目里挑出相关的五六个核心文件加上我自己梳理好的上下文约束、边界条件一起发给网页版的AI。等它像拿着手术刀一样精准地把那几个文件改好发回给我我再去本地直接替换。而且我习惯每一个小版本、一个小改动就往GitHub推一次这样各个diff之间追溯起来特别清晰方便我跨越几个版本拉出一段特别长的变更再喂回给AI去重新对齐边界。有人可能会问这样来回倒腾不嫌慢吗如果是那种需要短时间内大量冲刺做新项目把做项目当成一种“活儿”去干的场景我这办法确实效率低。但我这种已经做了五六年的独立开发项目早就过了那种需要快速开发堆功能的阶段了。说实话我一个月三十天真正在熬夜敲代码的时间可能只有一两天。那剩下的二十多天我在干嘛全在想。我花大量的时间去琢磨用户的反馈去推敲业务流的边界去把底层SQL到展现层的每一个细节都闭环到AI根本没有自行发挥空间的程度。在这个功能还完全没有落成代码的时候它只是我脑子里的一堆流程和状态但在这个阶段我已经开始对它进行Debug了。我会反复模拟它跑起来的样子推演各种极端情况提前把那些可能引发技术债和连环bug的隐患给约束掉。等这二十多天我想透了最后花一天时间写出来的代码基本是一次成型的后期极少需要再去大修。如果你全靠自动化的AI去瞎改它每次控制不好边界引发一堆新问题你反反复复去修修补补最后导致的往往是代码品质的整体下降那效率其实还不如我这种笨办法高。当一个初级程序员把时间都花在反复修改代码上的时候高级程序员可能已经把时间都花在了前置的思考上。这就好比现在大家拍照和听音乐。手机拍照太方便了掏出来咔嚓一下就行。但为什么还是有人愿意扛着沉重的大镜头单反支起脚架在特定的时间和地点去死磕一个光影构图因为门槛本身就会让人变得慎重。听音乐也一样用手机刷汽水音乐很爽但如果你玩黑胶唱片或者CD你要专门去淘碟要养护一套音响设备这种门槛和仪式感会让你对听什么音乐有更深的思考体验也会更加深刻。门槛往往不是坏事它是一种隐性的质量控制。如果写代码变得毫无门槛工具太顺手人就会天然地管不住手去无脑堆砌大量实际上毫无必要的代码而忽略了自己在架构上到底投入了多少心智。看现在的AI编程圈子我觉得其实已经慢慢分化出了几种不同的流派可以同时存在。一种是Agent工厂模式给AI定个目标让人工智能去探索、去生成代码人主要在后面当包工头负责验收。这种模式适合短平快的流水线作业要的是速度。一种是Loop Agent循环模式给AI设定目标和权限用目标去驱动代码开发的迭代让它自己不断去跑循环这更像是个研究室自主探索能力很强。还有一种就是我现在倾向的Harness架构模式。在这个模式里开发者本人牢牢掌握着整个项目的世界模型和全局上下文AI仅仅是一个能力极强、但行动受限的局部执行器。我们用强约束去控制它小步慢跑地去演化系统。这几种派别没有谁绝对先进只是适用的项目阶段不同。但我想表达的观点是无论工具怎么进化不要困于形式里面。你成为一个多么优秀的摄影师和你拍了多少张照片是没有绝对关系的同样一段优秀架构的代码它的效率不是体现在你花了几分钟把它生成出来而是当它持续投入到这个项目实际使用时它的表现有多稳定。大道至简。别被眼花缭乱的工具蒙蔽了多思考少盲从真正决定你项目能走多远的永远是你脑子里的那个世界模型。