巴别塔的故事里,人类因为语言分裂而停工。程序员兼作家Armin Ronacher最近写了一篇《The Tower Keeps Rising》,借用这个典故说了一件相反的事:今天的软件项目,语言分裂了,塔却没有停——它还在往上长。Simon Willison在自己的博客里转引了这段话,几乎没加评论,像是一次默认的背书。

这条转引信息量不大,但背后那篇原文的判断值得拆开看。

塔为什么没停工

Ronacher的核心论点是:一个软件项目真正的共享语言,不是Python也不是英语,而是团队对概念边界、不变量、归属权的共同理解。这种理解很少写在一个地方,它活在代码评审的争论里,活在"你得跟我解释一下这个改动"的对话里。

过去,这种理解靠摩擦维系。想改别人的存储层,你得先读代码、问问题、找相关团队协调。慢,但慢里有一部分不是浪费——是你的理解变成我的理解的过程,是双方确认"我们对这个系统的认识还一致"的过程。

agent改变的不是代码质量,是这道摩擦本身。 它能持续产出局部合理、编译通过、测试全绿的改动,不需要任何人拥有系统的整体认知模型。巴别塔因为语言分裂而停工,今天的代码库因为语言分裂反而继续升高——这才是Ronacher想让人后背发凉的地方。

摩擦消失后,流失的是什么 人类协作时代 改动前先读代码、问问题 跨团队协调、代码评审 慢,但双方理解被迫同步 摩擦 = 成本 + 知识同步机制 agent协作时代 局部改动,编译通过 测试全绿,无需人类解释 快,但没人被迫同步理解 无摩擦 = 省了成本,也丢了同步

老问题的新加速器

这其实不是全新的命题。Peter Naur在《Programming as Theory Building》里早就说过,代码库承载的不只是文本,还有维护者头脑里的理论;Fred Brooks在《人月神话》里讲过沟通成本随团队规模指数增长;Conway定律说系统架构会复刻组织的沟通结构。三条线索汇成一个共识:代码能跑,不等于有人真的懂它。

agent没有发明这个问题,它做的是把"局部理解不足会挡住代码合并"这道闸门直接拆掉。过去理解不够,change request就卡在评审里;现在agent能把局部知识缺口"翻译"成一份能过测试的diff,让改动照样往前流。

塔不会因为语言分裂而停工,这才是危险所在

专家吃杠杆,新手吃技术债

Ronacher这篇文章在Hacker News上引出不少分歧,几条线索都值得记一下。有人用俄罗斯方块类比:agent擅长把眼前这一块拼进去,却没有"消除已完成行"的全局目标,拼着拼着屏幕就满了。更扎心的一条观察是:熟练工程师用agent获得的是杠杆,经验不足的开发者用agent积累的是债务——同一个工具,在不同的人手里产出完全相反的组织后果。

也有建设性的提案:维护一份agent可以随时查询、也需要遵守的"模式语言",把隐性的架构约定显性化,逼agent像逼人一样先理解边界再动手。还有人干脆说,现在写代码越来越像"管理工作"——你不再是执行者,是要不断复核别人(哪怕这个别人是模型)工作的人。

诊断精准,解药呢

Ronacher这篇文章的问题在于,它把病灶描述得很准,却几乎没给药方。真正能落地的补救措施——比如强制在系统边界处做人工评审、维护架构决策记录、给每个模块划清显式所有权——原文里基本没提。

  • 风险.测试全绿不等于理解全在,大量真实故障发生在测试集覆盖不到的运维假设和跨系统边界上,这类风险不会在合并那一刻暴露,只会在事故、迁移或安全审查时集中兑现。

《左传》有句话,"其兴也勃焉,其亡也忽焉"。塔楼式的代码库,兴起得又快又猛,一旦某天因为没人懂全局而出事,坍塌也会又快又急。对工程团队来说,现在能做的判断很朴素:agent省下来的摩擦里,哪些是纯粹浪费,哪些其实是团队理解彼此的唯一渠道——分不清楚这两者,塔迟早要还债。