代码写得好不好，不看AI有多聪明，看人有多较真。
有个叫“短 leash”的AI编程法，专门用来打脸那些号称能自动写代码的“故事大王”AI。它说到底就一句话：把AI当个跑得快的实习生，你当那个脑子清醒的项目经理，每一行代码的生死都由你定。
这个方法的核心反直觉：你要像个20世纪来的疯子，死死盯着AI提交的每一处改动，批准或拒绝。这非但不会拖慢你，反而能让你对代码库的理解深到骨髓里，写出比纯AI生成或纯人工手写都干净得多的代码。
程序员恨AI是有道理的
这年头打开视频网站，满屏都是“我用12个AI代理并行工作，自己喝着咖啡看它们写代码”的爽文。这些视频播放量动不动上百万，看得人心里痒痒。但真相往往很残酷：那些AI代理早就跑偏了，只是博主自己还不知道。等到真要上线跑软件的时候，各种隐藏bug就像地雷一样炸开。
这种“放羊式”编程有个致命伤：你完全丢失了对代码库的掌控感。AI一顿操作猛如虎，改了几十个文件，你看着一堆绿红相间的diff（代码改动对比），心里只剩茫然。你根本不知道它为什么要这么改，改了之后会不会引发别的问题。更惨的是，下回你再开一个新会话，AI会自信满满地重复它上次犯过的错，因为它根本没有跨会话的记忆，除非你亲自把教训写进设计文档里。
所以，如果你真在乎代码质量，就得换一副脑子。那些AI明星产品吹得再神，生成的代码也经常是能跑但丑得要命，效率低下，逻辑拧巴。尤其是你碰上那种网上资料极少的冷门领域，AI就更靠不住了。某CEO吹的“模型能思考”纯属扯淡，它们充其量是在训练数据的范围里玩高级拼图游戏。
短 leash 方法：把AI当狗遛
这个“短 leash”（短牵绳）方法，核心就一条：永远不让AI脱离你的视线。它不是给新手准备的，只有专业的、对自己手艺有要求的开发者才能驾驭。但它的好处是，哪怕你不用最顶尖的收费模型，照样能干翻那些号称无敌的AI编程工具。
具体操作起来，你的工作流大概是这样的：第一步先做计划，把任务拆成细碎的小步骤，就像写购物清单一样，完成一项勾掉一项。这和那些“氛围编程”流派有点像，但接下来就分道扬镳了。你打死都不能开那个“YOLO”（只管冲）模式，那种让AI一口气改完所有东西的权限，绝对不能给。AI干活的时候，你别想溜去打游戏，你就得坐在那儿，像上世纪出活儿的手艺人一样，聚精会神。
最关键的环节来了：AI每提一个改动建议，你的编程代理会弹出一个显示具体改了什么内容的diff窗口。你的任务就是像海关安检一样，一行一行地审视这些改动。看懂了，觉得没问题，才点批准；觉得不对劲，立马点拒绝。你全程都在操作，保持对每一行代码进出的绝对控制。每一次审核diff，都是你更新自己对整个代码库认知的最佳时机。
这么做还有个额外的好处：你可以随时打断AI的“抽风”行为。AI经常写着写着突然就放飞自我了，开始往代码里塞些莫名其妙的玩意儿。这时候你因为有diff预览，一眼就能看穿，直接毙掉它的方案，把它拽回正道。每个小任务做完，就立刻提交一次代码版本，防止AI抽风把你之前好好的工作成果给抹了。这种事真的会发生，我就亲眼见过某知名模型干过这种蠢事。
审核比写代码还重要
好代码是审出来的，不是写出来的。这个道理在AI时代被无限放大了。一个只靠人审的PR（代码合并请求），和一个只靠AI审的PR，都不如“人+AI”一起审的效果好。你可以把AI当成一个超级敬业的“拼写检查员”和“语法警察”，它能飞快地抓出那些低级错误，比如少个括号、变量名拼错、空指针没判断。但那些更高层面的架构跑偏、业务逻辑方向不对、设计模式选错，得靠人脑来把关。
我们的做法是，每一个PR都必须经过AI先扫一遍。AI审查的时候得有足够的上下文，它得知道这个PR是干嘛的，改了哪些东西，代码库整体是什么样的。甚至，我们要求PR的描述里必须老老实实交代用了哪个AI模型来辅助写代码。这既是告知维护者，也是给自己提个醒。如果别人推荐了更好的模型，你下次可以升级。更重要的是，这态度就端正，表明你是个“好人”，没想着偷偷摸摸把AI的活儿塞进代码库。
但最最核心的，是那个“作者自审”的环节。请记住一个残酷的事实：AI辅助的PR，本质上就是AI写的，人只是搭了把手。所以，提交PR的那个人，有责任、也必须吃透自己提交的所有代码。怎么证明你吃透了？就是把这个PR当成别人写的，自己从头到尾、一行不落地过一遍。只有当你自己给自己点了“通过”之后，才有底气去喊维护者来合并。
这个自审的过程，就是把你对代码库的理解从“听说过”变成“我亲手摸过”。它的价值甚至超过了编写代码本身，因为这才是真正让你成长、让你成为项目主人的途径。
评论区里的大实话：短 leash 的现实碰撞
这篇文章发出来后，评论区的反应比正文还精彩，全是实打实的实践智慧。有一条高赞评论说得特准，它说短 leash 方法好是好，但有个坑：AI的失误经常发生在会话间隙。你上一轮告诉它“方案X不行，会搞坏Y”，它当时记住了。可下回你新开一个会话，它就像失忆了一样，又自信满满地给你推荐方案X。所以这个老哥的绝招是，专门弄个地方，把那些“此路不通”的死胡同清清楚楚写下来，确保下次会话开始时，AI能读到这个“黑名单”。光拴着绳子不够，还得在狗脖子上挂个“不准吃屎”的牌子。
另一个哥们则提出了更系统性的“反脆弱”思路。他觉得开发者不该跟AI的每次决策较劲，那太累了。正确的做法是花大把时间设计“结构性护栏”，比如给AI一个只读的AWS（亚马逊云服务）账号，权限精确到毛细血管。然后，把主要精力都放在打磨功能计划书上。如果AI跑出来的结果是一坨屎，别改代码，直接推翻重来，去修你的计划书和护栏。如此循环，AI慢慢就能学会你的套路，知道什么时候该问你，什么时候自己拿主意。这是一种把AI当成新员工来培养的长期主义，而非一个随叫随到的苦力。
还有人直接点破了这方法背后的心理障碍：既然绳子勒得这么紧，我干嘛不自己写代码呢？这话问到点子上了。对于很多习惯“放羊式”编程或者追求“心流”体验的老手来说，当个微管理器确实比亲手敲代码还要心累。短 leash 方法要求你时刻保持一种清醒、挑剔、略带强迫症的状态，这本身就是一个巨大的精力消耗。所以，这个方法挑人，它不适合所有人，但它适合那些对“代码为什么这么写”有偏执追求的人。
原文期刊：okTurtles Blog
发表日期：2026年7月2日
原文标题：The Short Leash AI Coding Method For Beating Fable
作者单位背景：Greg Slepak，安全关键软件维护者、协议开发者、okTurtles创始人