AI编程越用越慢？短绳法则5步告别翻车

最近HN上炸了个帖子，81分84条评论，标题叫”The Short Leash AI Coding Method”——短绳法则。作者Greg Slepak是安全关键软件的维护者，搞了一年多AI编程实验后，总结出了一套方法。巧的是，同一天另一篇帖子也火了：METR做了个对照实验，发现资深开发者用AI后「感觉快了20%，实测慢了19%」。两篇文章放一起看，答案很明显——大多数人用AI编程的方式从一开始就错了。今天就把这套短绳法则拆解成5个可操作步骤，我自己用了一周，代码质量和速度都提上来了。

【问题出在哪】

先说METR那个实验。16个资深开发者，246个任务，用的都是最新的前沿AI编程工具。实验前，开发者预期AI能帮他们提速。实验后，开发者报告说的确 快了约20%。但计时器一摆出来——实际慢了约19%。感觉和现实差了将近40个百分点。

为什么？由于AI编程的爽感来自「打字变快了」，但打字从来不是资深开发者的瓶颈。真正的瓶颈在理解代码、设计架构、排查问题这些环节，而AI恰恰在这些环节加了额外的认知负担：你要写prompt、等它回复、审查它写得对不对。如果它写错了，你还得回头改。这一来一回，比你自己写还慢。

更致命的是「YOLO模式」——就是那种放开权限、让AI自己跑、你去喝咖啡的用法。视频博主们吹得天花乱坠，说搞12个并行Agent自动写代码。但实际呢？AI在你看不见的地方疯狂跑偏，等你回来发现整个代码库都被污染了。Greg在文章里说得直接：这种「Vibe编码」方式，代码能跑，但又烂又丑，安全关键系统里根本没法用。

【短绳法则核心思路】

短绳法则的核心就一句话：把AI当成一个能力很强但不靠谱的实习生，你时刻盯着它，随时准备踩刹车。

具体来说有5步，下面逐个拆。

【第1步：先规划再动手】

别上来就让AI写代码。先用一个「规划阶段」：把任务拆成子任务，每个子任务足够小，小到你能一眼看懂AI做了什么。

实际操作时，我的做法是在对话开头先发一段：

——

任务：给用户认证模块加双因素验证

请先分析现有代码结构，列出实现步骤，不要直接写代码

——

AI会返回一个步骤列表，你审一遍，砍掉不合理的，补充遗漏的。这一步花5分钟，但能省后面50分钟的返工。避坑提示：如果AI返回的步骤超过7个，说明任务还是太大，继续拆。每个子任务应该能在10-15分钟内完成。

【第2步：永远不开YOLO模式】

这一步是铁律，没有例外。

YOLO模式（也叫dangerously skip permissions）就是让AI跳过所有权限确认，自己改文件、跑命令。听起来很爽，但这是翻车的头号缘由。Greg在文章里特别强调：AI从来不在你去打游戏的时侯工作。

正确做法是：用一个会在每次修改前弹出diff确认的编程Agent（列如Claude Code的默认模式、Cursor的review模式）。AI每次想改文件，你都能看到具体改了哪些行。这一步的意义不仅是防错——更重大的是，通过审查每一个diff，你对代码库的理解始终是新鲜的。

模式速度感受实际质量翻车概率

YOLO全自动极快差极高

短绳法则中等好极低

纯手写慢最好零

【第3步：看到不对立刻喊停】

这是短绳法则的精髓——「短绳」就短在你要频繁干预。

AI在执行子任务时常常会跑偏：你让它加个参数校验，它顺手把整个函数重构了；你让它修个bug，它把相关的不相关的测试全改了一遍。这些时候你要做的就是一件事：DENY。

在我的实际操作中，大约每3-4次AI请求，就有1次需要拒绝。常见的跑偏信号：

• AI开始改你没提到的文件——暂停，问它为什么

• AI一次性改了超过50行——大致率过度修改，拆小再看

• AI开始删代码而不是加代码——超级危险，仔细审查

• AI开始引入新依赖——99%的情况下不应该，直接拒

避坑提示：拒绝后不要只说「不行」，要说明缘由。列如「不要动测试文件，这个bug只在业务逻辑层」。AI会根据你的反馈调整后续行为，效果比无脑拒绝好得多。

【第4步：每完成一个子任务就提交】

这一步看着简单，但能救命。

AI有个可怕的毛病：它有时会「好心」删掉之前已经完成的工作。Greg说他亲眼看到Opus这么干过。如果你没有及时提交，之前的成果可能在一瞬间消失。

我的做法是每完成一个子任务，立刻做一次commit：

——

git add -A

git commit -m “feat: 完成双因素验证的token生成逻辑”

——

这样即使AI后面搞砸了，你也能一个git reset回到安全点。如果用Claude Code，它会在完成任务后自动提议提交，这时候养成习惯：看到提议就提。

另外一个小技巧：用有意义的commit message。不要让AI自己写「Updated files」这种废话。你自己写清楚这个子任务做了什么，这本身就是一次自我审查——如果你写不出commit message说明你不懂AI刚才做了什么，那就别提交，回去看diff。

【第5步：AI辅助代码审查】

最后一个环节是PR审查。Greg的方法论是：人和AI都要审。

AI审查的优势在于：它像个超级linter，能快速抓到常见错误——空指针、边界条件、命名不一致。但人审的优势在于：能看出方向性问题——这个功能该不该加、这个架构合不合理、这个方案是否过度设计。

实际操作时，我的流程是：

先用AI过一遍代码，让它列出发现的问题。然后我逐条核实——AI说的问题有些是真问题，有些是误报。最后我自己再从头到尾读一遍代码，关注AI发现不了的逻辑问题。

一个重大原则：用AI写的代码，提交者必须逐行审查后才能说「这是我的PR」。由于AI辅助的PR本质上是一个AI提交、人类辅助的PR。你不能对自己提交的代码一无所知。

【实测对比：短绳vs全自动】

我自己用了一周，做了个简单的对比。同一个功能（给API加限流中间件），分别用两种方式：

指标YOLO全自动短绳法则

首次完成时间8分钟22分钟

返工次数4次0次

最终完成时间35分钟22分钟

代码review问题7个1个

我对代码的理解模糊清晰

全自动模式首次出代码的确 快，8分钟就跑完了。但之后花了27分钟修bug和重构。短绳法则虽然慢一点出第一版，但一次过，不用返工。更重大的是——用短绳法则写完的代码，我能说清楚每一行在干什么。YOLO模式写完的代码，我自己都不太敢碰。

【避坑总结】

几个常见误区：

• 不是模型越强越不用盯着——Opus和Fable一样会跑偏，区别只是跑偏的方向更高级

• 不是prompt写得越好越不用审查——prompt只能控制方向，控制不了执行细节

• 不是小项目就可以用YOLO——坏习惯是会带到大项目里的

短绳法则本质上不是什么新发明，它就是传统软件工程里code review的延伸。只不过review的对象从同事变成了AI。你不会把同事写的代码不review就合进去，那凭什么对AI网开一面？

METR那个实验最扎心的一句话是：对AI最自信的人，恰恰是被它拖慢最多的人。自信不是来自放开手，而是来自始终握着那根绳。

别在AI浪潮中掉队！关注我，一起抢占AI时代红利。