AI编程助手更常见的用法,是让模型直接改代码、自动提交PR,人工评审,追求吞吐量。开发者Ankur Sethi反着来:他在项目的agents配置文件里立规矩,禁止AI擅自创建、编辑、移动或删除文件,也不允许AI未经授权运行会改变仓库状态、安装依赖的命令。AI只能在对话框里给代码和命令,剩下的敲键盘工作,全部由他自己一行行完成。
这套做法牺牲了生成式编程的速度红利,换来的是对代码库的理解、更早发现错误的能力,以及长期维护的底气。它的价值集中在个人项目和关键代码上,不能证明手动敲代码适合所有开发场景。
从自动执行退回人工敲键盘
Sethi早就对"AI一键生成整个功能"保持警惕。但完全弃用AI,又让重复性代码变得难以忍受。
折中方案,是把AI降级成一个只会"动嘴"的建议工具。AI在对话里给方案,他照着方案手动输入,顺手做重构、加注释、调整命名。
这个过程慢。但每一行代码经过他手,他都清楚它为什么在那儿,和其余代码怎么衔接。
这套流程和早年学编程"不许复制粘贴,照书敲一遍"的老规矩是同一个逻辑:用手上的重复动作,换脑子里的理解深度。
认知债务,不是技术债
Sethi把这个问题叫"认知债务":开发者对自己代码库的理解越来越薄,直到出问题时不知道从哪儿改起。
这和技术债不是一回事。技术债说的是代码架构差、维护成本高。认知债务说的是人脑子里那张"代码地图"在丢失。
手敲代码能治的,只是后一种问题。它逼着开发者逐行接触代码,但不会自动挑出模型编造的API、架构上的坏设计。安全漏洞和依赖链风险,它也挡不住——测试、静态分析、依赖审计、同行评审,一个都省不了。
2倍效率,谁会真的这么用
按Sethi自己的说法,这套流程比完全不用AI快,比放手让AI自动执行慢——大约是不用AI速度的两倍,不是行业里常说的"十倍提效"。
这个数字来自他一个人的项目体验。没有统一任务,没有对照组,只能当个人感受看,不能当生产力基准。
| 场景 | 更可能怎么用AI权限 |
|---|---|
| 个人维护的核心项目 | 收窄权限,AI只建议,手动敲入,换理解深度 |
| 团队日常迭代 | 保留AI直接改代码、自动提PR,靠评审把关速度 |
| 团队里的高风险模块(支付、鉴权、核心算法) | 局部收紧,参考Sethi做法,人工逐行过一遍 |
真正会用这套方法的,是那些打算长期维护自己代码库的个人开发者。他们本就更看重理解,不是交付速度。
对赶迭代节奏的团队,把AI权限收窄到"只能说不能做",大概率只会用在最核心、最经不起出错的模块。不会变成默认流程。
接下来更值得看的,是会不会有团队把这种权限分级写进正式的AI使用规范,而不是只靠个人开发者自发实践。
【锐评】手敲代码防的是脑子偷懒,防不住机器犯错。审查这道关,谁都省不了。