写代码不是瓶颈，为什么还这么慢

这几天 r/ClaudeAI 上有个帖子冲到了前排，标题很直白：I am done with this shit。发帖人转述了一段 X 上的吐槽：入职一家大公司半个月，spec、代码、测试、PRD、ticket、周报全是 Claude Code 生成的，从 L1 到 L7 每天做同一件事，跟 Claude 对话，一天 12 到 13 个小时，主要动作是按 Enter。管理层反复问的只有一句：“写代码已经不是瓶颈了，为什么还这么慢？”

评论很快过了 800 条。吐槽 AI 的不少，但有一个判断几乎没人反对：这不是 AI 的问题，是管理的问题。 同样的 Claude，在另一些团队里让工程师睡得更好、做得更多。那么反过来问一句：AI 时代，什么样的管理层才配领导卓越的工程师？

帖子本身无法核实，原文来自匿名账号，没有公司名。我更在意评论区：几百个人在对号入座，讲的都是自己公司里正在发生的事。

同样的 Claude，两种团队

崩溃的那一侧，场景出奇地一致。我的 AI 解析同事的 AI 写的需求文档，他的 AI 再读我的修改传回来，没人互相说话了。一天收到 5 万行的 PR，认真 review 至少要 10 天，经理说“用 AI review”。以前给 3 天的任务现在要求 2 到 3 小时交付，于是又写了一组 Agent 来 review 和测试，有时写代码、审代码、测代码的是同一个模型。

过得不错的那一侧，规矩听起来都很朴素。一个创业公司的人说，所有文档和代码也是 AI 写的，但每一件事都有一个负责人，必须能解释做了什么。另一个团队规定谁开的 PR 谁 100% 负责，理解不了就打回去重来，还主动收紧了 PR 的大小。一个在小型金融公司独自负责整个技术栈的 senior 说，他给 Claude 配好了 guardrail、测试和验证，现在工作时间回到了合同规定的长度。

两边的工具没有区别，区别全在管理决策上：给不给时间理解，谁对结果负责，PR 能不能被打回，什么算完成。有条评论说 AI 是放大器，先放大的是管理问题。好管理被放大成杠杆，坏管理被放大成 12 小时的 Enter。

看不见瓶颈搬家

“写代码不是瓶颈，为什么还这么慢”这句话，前半句没错，后半句暴露了管理层的模型还停在 AI 之前。

瓶颈不会消失，只会转移。代码生成快了十倍，理解代码、验证代码、判断它是否符合意图的速度没有变。继续往生成环节加压，多出来的产出只会堆在瓶颈前面，变成没人读过的在制品库存。评论里有人一句话说清了：写代码不是瓶颈，读代码和评估代码才是。

配得上好工程师的管理层，会把力气花在瓶颈处的容量上。限制 PR 的大小，给 review 和验证留出预算，把逃逸到线上的缺陷当成核心指标。这件事我自己踩过：在快，是最贵的慢里，CI 全绿、coverage 达标的项目装到机器上根本不能用，救回来的是一次两个小时的 audit。帖子里那家公司做的，正是把这两个小时从流程里删掉。

更糟的是考核方向。评论里有人说，他们公司规定 pipeline 必须“用过 AI”才能上 production，自己写的代码也得用 AI 重做一遍；有人找经理要帮手，得到的回答是再买一个 Claude seat，两个同时跑。考核 AI 使用率，得到的就只有 AI 使用率，Goodhart 定律在 AI 时代照样成立。

只给责任，不给权力

有条评论被反复引用：严格来说，你是一个用来替 Claude 承担责任的有机容器，因为 Claude 没法被追责。

研究自动化事故的 Madeleine Clare Elish 管这种位置叫 moral crumple zone：自动化系统里的人像汽车的溃缩区，控制权很小，撞击却由他来吸收。帖子里的工程师就站在这个位置上：没有时间读代码，没有权力放慢节奏，出了事却要签字。有人把整条链讲透了：经理假装看懂了，senior 假装看懂了，我也假装在一小时内看懂了 AI 生成的代码，出了问题大家就说“可能是我弄错了”。

责任要以控制为前提。管理层要求工程师对结果负责，就得同时给他拒绝的权力：可以把看不懂的 PR 打回，可以说这个 deadline 做不到验证。只给责任不给权力，最后收集到的只是一串签名。

“用 AI 审 AI”也是同一个问题的变体。同一个模型写代码、写 review、写测试，共享同一份上下文和同一类盲区，整个回路从头到尾没有碰到任何外部事实。我在还要工程师干什么？里写过，能让 Agent 通宵跑的 gate 必须锚定在真实样本、可复跑的指标和反指标上。管理层用一道没有外部事实的 gate 替代人的判断，等于在汇报里写 human-in-the-loop，实际上 loop 里只有 Enter。

惩罚判断，就是在赶走最好的人

评论区里最让我不舒服的是两个故事。一位在同一个项目上干了 15 年的 senior，因为花时间清理 AI 代码、抽象公共库被批评，被要求“降低标准”，理由是写代码现在是 Claude 的活，而项目的 bug 比任何时候都多。另一位接手公司收购后的平台迁移，产品经理让 AI 把遗留代码的功能和差距整理成一个 100 多页的 HTML 加一份 30 个 tab 的表格，他说这不是给人读的，先从高层差距开始吧，结果被当成不配合的人。

我在都 2026 了，还在考算法？里写过，AI 替代的是 execution，不是 judgment。卓越工程师在 AI 时代的价值几乎全部集中在判断上：这段代码该不该进，这个方案会在哪里出问题，这份报告有没有人能读。说“不”是判断最常见的形态。一个管理层惩罚“不”，就是在为错误的东西付钱。

而且卓越工程师比以往任何时候都更有选择。评论里有人说，自从 AI 接手之后，他所在的年收入 1000 万美元的公司，已经由他一个人加一个 Max 订阅在运转。好工程师可以换一家公司，也可以带着一群 Agent 自己干。惩罚判断的组织会发生逆向选择：能走的人先走，留下来的是最愿意按 Enter 的人。

管理层自己的 What 在哪里

把 Enter 键交给工程师的管理层，自己的工作往往也交给了 AI。有人说产品经理的 ticket 现在长了 10 倍，但和以前一样没想清楚，一段描述里自相矛盾两三次，只是看起来更专业了。有人说增长部门拿着 AI 生成的 brief 被带往 10 个方向。还有人说，很多对 AI 抱着神奇 ROI 期待的领导者，自己从来没用过这些工具。

我在谁在握着缰绳？里说过，What 是缰绳，How 是马力。AI 把 How 变得极其便宜，What 就成了整个组织最稀缺的东西：做什么，不做什么，什么算完成，哪个指标代表真的变好。工程师可以把 What 翻译成 gate 和 harness，但业务目标本身必须来自管理层，而且要清楚到可以被验收。管理层把自己的思考也外包给 AI，工程师就只能去执行一个没有人真正想过的目标，再快也是在错误的方向上加速。

用得比一线少，怎么领导

管理层用 AI 的时间，不可能比一线工程师多。一个带几十人的 director，一天被会议切成碎片，不可能连续几个小时陪 Agent 调一个 flaky test。要求领导者“比工程师更懂 AI”，是一句空话。

但帖子里的问题，出在信息来源上，和使用时长关系不大。评论里有人吐槽，领导者对新技术的了解“始于 LinkedIn 帖子，也止于 LinkedIn 帖子”；还有人说，管理层强推 AI、统计使用量，是为了在高尔夫球场上跟同行比谁更激进。厂商 demo、同行炫耀、社交媒体，这些渠道只展示成功案例，而且只展示生成那一刻，从来不展示三个月后谁在维护这些代码。用这样的信息做决策，领导者理解的其实是 AI 的广告。补救的办法是换信息源，找一组难以造假的信号。

第一，亲手做一件完整的小事，用来校准直觉。别看 demo，挑一个有验收标准的真实任务，从头做到能用，包括发现它错了、再把它改对的那一段。我在快，是最贵的慢里那个周末学到的“CI 全绿不等于能用”，比看一百场发布会都管用。

第二，看结果链条上的指标，别看使用量。PR 的大小、等待 review 的时间、revert 率、逃逸到线上的缺陷、事故的恢复时间、新人第一次独立修 bug 要多久。理解被跳过的时候，这些数字会先变坏，跟用了多少 AI 无关。

第三，随机抽一个已经合并的 PR，请作者讲一遍它在做什么、为什么这么做。这是最便宜的审计。作者讲不清楚，说明组织里的 human-in-the-loop 已经名存实亡；目的是量系统，不是罚个人。同样的道理，领导者应该坐进事故复盘，AI 用得怎么样，事故现场比任何周报都诚实。

第四，把说“不”的人当成传感器。那个坚持要先看高层差距的工程师，那个被要求降低标准的 senior，恰恰是真正读过代码的人，他们给出的是组织里分辨率最高的信号。上一节说惩罚判断会赶走最好的人，它还有另一个代价：领导者会把自己的眼睛也蒙上。

反过来，也不能把用得最多的人当成标准答案。我在谁在握着缰绳？里写过那些停不下来的重度用户，用得最多的人，也可能就是被马拖着跑的人。领导者的优势恰恰是距离：他能同时看到好几个团队，看到哪种用法三个月后留下的是资产，哪种留下的是事故。

领导者不需要比工程师更懂 AI，但必须比任何人都清楚，自己对 AI 的判断从哪里来。

看不清能力边界，怎么定方向

如果领导者对 AI 的能力边界本来就看不清，对 frontier model 也不熟，方向怎么定？

能力边界其实谁都看不清太久。模型几个月换一代，一线重度用户上个季度总结的“这个它做不了”，这个季度可能已经不成立了；反过来，发布会上宣称的能力，放到你自己的代码库里也可能打个对折。把方向押在对模型能力的准确预测上，本身就是错的赌法。

帖子评论里最伤的决策，恰好都是这种赌法：先相信 AI 能做到，再做不可逆的动作。一个被收购的团队，对方原来 20 多人做的平台，要求他们 5 个人接手，一开始甚至觉得 1 个工程师就够了，公司计划两年内把 200 多人裁到六七十人。有实习生说公司把业务代码从 Go 整体重写成 Java，理由是有了 Codex 写得一样快，直接部署到生产，让用户去测 bug。裁员、停招新人、取消 review，这些都是单向门，走过去就很难退回来。

看不清边界的时候，方向应该押在不随模型版本变化的东西上。业务目标、用户、风险底线、什么算正确，这些不会因为下一代模型发布而改变。我在Test Case 才是软件的核心资产里写过，Source Code 可以被重新生成，Test Case 里沉淀的真实世界不能。投资真实样本、eval、harness、可复核的验收标准，哪个模型胜出都不亏，这是少有的无悔投入。

能力边界本身，应该由组织自己测出来，而不是靠领导者相信。从自己的真实任务和历史事故里攒一套 eval，新模型一出来就重跑一遍，看它在你的场景里能做到哪一步。领导者不需要读懂模型，只需要养成一个习惯：别问“这个模型厉不厉害”，问“我们自己的 eval 怎么说”。

边界越模糊，越要用双向门的方式推进。小范围试点，事先写好成功和叫停的标准，结果好再扩大。不可逆的决定，比如砍掉多少人、要不要继续招新人、能不能取消人工 review，应该排在自己的数据之后，而不是排在别人的发布会之后。

这些做法靠的是一种比 AI 老得多的管理能力：在不确定性里分清哪些判断可以错、哪些不能错。

下一代工程师从哪里来

评论区里问得最少的，是新人。有人说新人入职第一年，几乎没有 senior 带，任务却一点都不简单，所有问题的答案都是问 Claude。有人换工作三周，问 lead 业务逻辑和整体架构，得到的回答是“用 Claude Code 自己问”。一位在 1500 人工程团队里的工程师说，以前新人要花几年积累对代码库的上下文，现在他们团队在做的工具，就是让 AI 比任何一个 IC 都更懂代码库。

今天的卓越工程师，是过去十年里一次次读代码、踩坑、半夜排查事故养出来的。管理层如果把理解当成可以省掉的成本，省掉的不只是今天的 review 时间，还有五年后能在凌晨三点看懂系统的那个人。这笔账最后记在管理层头上。

坏管理再也没人兜底

卓越的工程师在 AI 时代并不需要管理层来分配工作，Agent 会把工作拆得比人还细。他们需要的是另外几样东西：一个清楚的 What，一个看得见瓶颈在哪里、也知道自己信息从哪里来的人，一份和责任配套的权力，一个说“不”不会被惩罚的环境，以及一个愿意为下一代人的理解付成本的组织。

这些都不新，好的管理层十年前就该做到。AI 做的只是把差距放大了：过去坏管理还能被工程师的勤奋和手艺兜住，现在勤奋被 Agent 替代，手艺被要求降低标准，兜底的东西没了。

回到那个问题：写代码已经不是瓶颈了，为什么还这么慢？因为剩下唯一的瓶颈是理解，而管理层明令禁止大家在那里花时间。能回答出这一点的管理层，才配得上那些知道系统在干什么的人。