其实之前在社区里聊过不少关于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仅仅是一个能力极强、但行动受限的局部执行器。我们用强约束去控制它，小步慢跑地去演化系统。
这几种派别没有谁绝对先进，只是适用的项目阶段不同。但我想表达的观点是，无论工具怎么进化，不要困于形式里面。你成为一个多么优秀的摄影师，和你拍了多少张照片是没有绝对关系的；同样，一段优秀架构的代码，它的效率不是体现在你花了几分钟把它生成出来，而是当它持续投入到这个项目实际使用时，它的表现有多稳定。
大道至简。别被眼花缭乱的工具蒙蔽了，多思考，少盲从，真正决定你项目能走多远的，永远是你脑子里的那个世界模型。
