结果上周五临下班，硬生生被个破Python脚本整破防。
需求贼简单：读个CSV，洗洗数据，写进数据库。我用文心快码三分钟生成骨架，寻思摸鱼喝口咖啡的功夫它就能把细节填完。回来一看，好家伙，这祖宗把我本地的配置文件给改了，连接字符串里“localhost”硬生生被它替换成“测试环境别删”——还特么是中文注释。我当时血压就飙上去了，不是气AI蠢，是气自己怎么又没加那行“不许碰配置文件”的咒语。
这就是咱现在写代码的真实状态。AI生成代码快是真快，捅娄子也是真捅。鹅厂那帮兄弟说得特形象，AI有时候像个“智商很高的大傻子”-3。它帮你把路铺得飞起，也可能顺手把你家门槛给拆了。
后来我冷静下来，开始正儿八经研究到底怎么让这“大傻子”既能干活又不添乱。这俩月翻了不少资料，也试了七八种工具，发现真正拉开效率差距的，根本不是谁的代码生成速度更快，而是——你会不会“整理”AI拉出来的那摊子东西。
这里头有个概念我必须先抛出来，也是我最近才想明白的——ai询问代码，这四个字不是让你去搜“AI怎么写代码”，而是指你去问AI“你手上这坨代码是啥结构、有没有冗余、为啥这么写”。
我第一次意识到这事儿有用，是看IBM那个首席架构师Gabe Goodhart的访谈。他说他每天同时跑三个项目，AI写90%的代码，但他死死攥着git commit的权限不放。为啥？因为按下commit键之前那一眼diff，是他“宣示所有权”的时刻——这代码我看懂了、我认了、出事儿我兜着-5。
我学着试了一把。现在每次让AI改完东西，我不急着点接受，而是敲一句“ai询问代码，把你这轮改动的范围和影响区域给我列清楚”。神奇的是，当你明确要求它“汇报工作”而不是“继续干活”时，它反而收敛了，不敢瞎编测试用例绕过真实API，也不敢自作主张删你觉得“没啥用”的老逻辑-3-6。
这就引出一个挺反直觉的事实：AI生成的代码越“完美”，你离真正的理解越远。
Springer今年初发的那篇论文戳破了这层窗户纸——LLM生成的代码往往比人类写的更短，但圈复杂度更高-6。翻译成人话就是：它确实帮你省了打字的时间，但也给你埋了一堆绕来绕去的逻辑地雷。你一眼扫过去觉得“嗯能跑”，等仨月后回来修Bug，当场裂开：这特么谁写的递归？
所以我现在的习惯变了。以前我喜欢Cursor那种极度顺滑的Composer模式，说句话它给你改十几个文件，爽得像开跑车。现在？我反而切回那种看着有点“笨”的工具——比如文心快码的Spec模式，或者我自己用CLI搭的简陋工作流-4-2。
笨有笨的好处。
Spec模式逼着AI在动工之前先写plan.md，把需求拆成豆腐块，你瞅一眼就知道这憨批有没有理解错你的意思-4。这多出来的两分钟，省的是你后面两小时重构的功夫。卡帕西大神推荐的那份指南里甚至说，Peter Steinberger重构旧代码时，让Codex默读文件读了好几个钟头，结果人家不仅没漏逻辑，还揪出俩隐藏Bug-2。这事儿放以前你敢信？让AI“读”代码比让它“写”代码还费算力，但这恰恰是ai询问代码的深层价值——你迫使它把隐性的理解显性化，它犯错你才能早发现。
当然，更接地气的防坑办法，还得看咱国内这帮被AI虐过的一线码农。
我特别喜欢腾讯技术工程那篇合集里一个兄弟的总结：“把rm、git这些危险命令加黑名单，agent模式下也不允许自动调。”-3 还有人说，每次让AI改东西前先git commit一下，不是因为你多爱做版本管理，是因为“AI乱写之后你方便回滚”-3。这些话带着血泪，但管用。
甚至有个老哥把AI比作“需要管理的同事”——你得给它划边界、定规则、甚至容忍它犯些小错，因为它不是万能的自动化流水线，而是一个需要磨合的协作对象-9。我太吃这套比喻了。想想也是，如果你招了个聪明但有主见的实习生，你会把root权限给他吗？不会。你会让他一个人不经过Review就把代码合进主干吗？也不会。那凭啥对AI就这么放心呢？
说到这儿，必须提一嘴ai询问代码的第三个场景：代码资产化。
这是我从CodeBuddy Code的实践里偷师的。腾讯那个团队用AI自举，90%的代码都是CodeBuddy自己生成的，但他们不是让它瞎写，而是建了一堆Skills——其实就是给AI配了专用工具箱，遇到同类需求不用从头想，直接调已有的解决方案-10。我琢磨了一下，这不就是咱程序员常说的“封装”吗？
于是我给自己定了个规矩：每次AI写了个挺巧的函数或者解决了个棘手的边界条件，我不光把代码合进去，还会开个新对话，专门拿这段代码问“提炼一下核心逻辑，写成可复用的伪代码模板，存到docs里。”几次下来，我的项目文档夹里多了七八个Markdown文件，下次遇到类似需求，直接拿模板让AI照着改，不用从零描述，也不用担心它这次写出来的跟上次好用的版本逻辑打架-2。
这事儿给了我一个挺大的满足感。以前总觉得AI生成的东西像租来的，用完就还，不留痕迹。现在通过这种“询问—提炼—归档”的闭环，那些代码好像真的变成我自己的东西了。就像Goodhart说的，写作这件事本身改变了思考方式-5。你为了把需求跟AI说清楚，必须把那些原本在脑子里混沌一片的“大概这么弄”掰开揉碎，写成一条条不能含糊的指令。这个过程累，但值。
当然，我知道有人会杠：有这功夫我自己都写完了。
对，初期确实慢。就像你刚开始学重构、学写单元测试，前几个礼拜效率甚至是下降的。但这是个典型的“滚雪球”效应——你的代码库越干净，文档越齐整，AI理解上下文的成本就越低，它产出的质量就越高，你需要返工的地方就越少。我现在的项目，从需求到交付，AI生成的代码采纳率大概六成出头，不像营销号吹的“90%自动完成”，但剩下的那四成人工决策，全是高杠杆点：选哪个依赖库、接口怎么抽象、性能瓶颈在哪儿-9。
这其实也解释了为啥今年好多大厂突然说“不招初级工程师了”-9。不是AI强到能把新人全干掉，而是AI把执行层的门槛踩平之后，传统那种“从抄代码、写小功能慢慢熬上来”的成长路径被拦腰截断了。新人如果不主动逼自己理解系统、判断取舍，很容易变成“AI操作员”——只会把需求喂给模型，再把模型吐出来的代码贴进PR，三年经验约等于一年经验重复三次。
这事儿想想挺唏嘘的。工具变强了，但对人的抽象能力、判断力的要求反而更高了。你没法再靠手快占坑，得靠脑子清楚。
所以回到标题那四个字，代码整理。
它不是洁癖，不是炫技，是你在AI时代保住“程序员”这三个字主体性的最后一道防线。每次你追问AI“为什么”，每次你把它打散的碎片拼回系统蓝图，每次你把一段临时脚本沉淀成可复用的资产——你都在说：这代码是我的作品，不是模型的排泄物。
工具会迭代，模型会换，但这种ownership的心态，才是咱吃技术饭的人立身的根。
（P.S. 今早又翻车了，让AI写个正则提取日志，它给我返回个匹配空字符串的万金油模式，跑起来全量命中，日志直接爆了。我骂骂咧咧回滚，然后老老实实在docs里加了一条：“但凡涉及正则，必须先发测试用例给我确认。”你说这坑吧，踩了八百回，可每次AI犯错的方式都能整出新花样。这大概就是人机协作的宿命——你永远不知道那个大聪明下一回会用啥姿势捅娄子，但你也清楚，回不去了，没它帮你敲那些枯燥的胶水代码，你也腾不出手来琢磨那些真正值得琢磨的问题。）