8月3日,程序员Niklas Gruhn在自己的博客上发了一篇不到千字的短文,造了个词:meat proxy,直译"肉体代理"。他说的是这样一种人——把AI的输出原封不动转发给同事,自己既没读懂也没验证,只是充当了一具搬运的躯壳。同一天,知名技术博主Simon Willison把这篇文章转到了自己的link blog上,只写了90个英文单词做评论,核心一句话:用AI没问题,但不能只转发答案,得自己读懂、验证,再用自己的话说一遍。
这条转发本身信息量很小,但它戳中的问题不小。这不是一个新问题,而是一个被自动化研究反复验证、又在AI协作场景里重新发作的老毛病。
审查代码时,谁才是真正在写代码的人
Gruhn原文点出三个具体场景:Slack讨论、代码审查(pull request)、私人对话。三者里,代码审查最值得细看,因为它涉及一次隐蔽的权力转移。
正常流程里,审查者(reviewer)提意见,作者(author)理解、判断、修改代码,签上自己的名字。但如果作者把审查意见原样丢给AI,让AI直接生成修改,再原样提交——这时候真正"写代码"的人变成了审查者加AI,作者只是个传话筒。挂名的责任人,和实际做判断的人,已经不是同一个人。
这不是效率问题,是责任归属问题。代码出了bug,该找谁?表面上找作者,作者却可能从未真正理解过那段修改逻辑。
这毛病,四十年前就有名字
"肉体代理"听着新鲜,但它描述的现象,自动化研究领域早就反复命名过。1983年,Lisbeth Bainbridge提出"自动化的讽刺":系统越自动,人类监督者越容易失去手感,一旦出问题反而更不知所措。1997年,Parasuraman和Riley把自动化的误用、滥用、弃用分成三类,专门讨论人类何时会盲目信任机器。1999年,Skitka等人的实验证明,人在有自动化建议时,会系统性地忽略自己本该发现的错误——这叫"自动化偏见"。2019年,Madeleine Elish提出"道德皱褶区"(moral crumple zone):自动系统出错时,责任会挤压到最靠近人类的那个环节,哪怕这个人根本没有真正的控制权。
四十年间,战场从飞机驾驶舱、医疗诊断,换到了今天的Slack消息框和代码审查页面。工具变了,人性弱点没变。
新词好记,但解决不了老问题
"肉体代理"的价值不在理论创新,在传播。学术术语没人在Slack里随口说,但"别当meat proxy"这种话,程序员之间能直接互相调侃着提醒。这也是它比"automation bias"更容易在开发者社区流传的原因。
代价也在这里:原文只有90词加一句引言,没有案例,没有数据,更没有回应一个明显的反面意见——如果矫枉过正,把所有AI辅助都当成"偷懒",反而可能吓退真正有用的自动化,这在研究里叫"算法厌恶"(algorithm aversion)。工具本身没有错,错在有没有人真的对结果负责。
- 风险.过度强调"别当肉体代理",可能让团队对AI辅助产生不必要的排斥,反而拖慢正常协作。
内容社区如Lobsters、Hacker News,目前的治理规则大多盯着"AI生成内容"本身,却很少专门界定"人类签名转发AI输出"这种更隐蔽的绕过方式。"肉体代理"这个词,某种程度上是在替这类社区补一条尚未写进规则的红线。
转发答案不难,难的是敢为答案签名负责。
怎么才算真的读懂,而不是转发
对知识工作者,尤其是程序员和审查者,一个简单的自查方法是:在看到AI答案之前,先自己写一句判断。如果最后提交的内容和你最初的判断对不上,又说不出为什么变了,那大概率就是在当肉体代理。
- 建议.提交任何AI辅助的修改前,先问自己一句——如果现在没有AI,我能不能独立讲清这个改动为什么对。答不上来,就不该签名提交。
企业管理层和开源项目维护者,接下来值得盯的是:会不会有团队正式把"不得盲传AI输出"写进代码审查规范,把这条自查从个人自觉,变成流程上的硬要求。目前看,这个词才刚刚开始流传,能不能真正改变协作习惯,还得看后续有没有制度跟上。