人工智能放大“盲点”：没人愿意直说的根因

我周末都在写代码，不是因为被迫，而是因为我真的享受其中的乐趣。最近我发现了一件事，让我一直无法释怀：有了人工智能工具后，我独立开发的效率提升到过去的100到1000倍。

周一早上走进办公室，本该是一条让人振奋的消息。但结果却并不如此。

我的工程师们至少和我一样聪明，他们用的也是同样的工具。可为什么我看不到那样的100倍加速？为什么各项指标几乎没有起色？我反复琢磨之后，得到的答案却让人不安：根子不在个人，也不在技术，而是在我们自己——在习惯、在流程。更准确地说，是我们的文化出了问题：这种文化在人工智能出现之前被搭建起来，却从未跟上它带来的变化。

人工智能并不是这些问题的最初制造者，它只是把原本可以被忽略的缺陷，变成了必须面对的现实。

有个很具体的例子。我们一直以来对内部工具和组件的态度都比较“松”：实用程序、共享库，甚至在做其他项目时顺手写出来的小型基础设施，都属于“能用就用、用完就放”的类型。它们没有明确负责人，也没有维护计划。安全补丁经常缺失，bug 会越积越多，文档也越来越过时。在人工智能出现之前，这种情况还能被控制，因为组件数量相对有限，维护它们本来就要花大量精力，所以数量自然不会失控。但现在人工智能打破了门槛：组件到处都是，一下午就能生成，然后被塞进组织里的各个代码库，却始终无人负责。责任缺失依旧存在，只是生产速度被加快了。曾经那种“小修小补”的问题，已经发展成一套庞大、缺乏文档、无人维护、未打补丁的组件库，我们正被迫努力应对。人工智能并非所有权失效的起点，它只是让这种失效规模化爆发。

在推出人工智能的阶段，没人愿意公开承认这一点：它会在你意识到之前就暴露你的短板。忽视文档的团队会更快交付无文档代码；不做代码审查的团队会更快发布未经审查的实现；责任边界不清的团队会产生大量无人真正完全负责的工作。人工智能就像一个放大器，它不会在乎自己放大的到底是什么。

谈论人工智能的应用时，大多数人都会从工具本身开始。但我想把讨论往前挪：在谈工具前，先问一个更早的问题——在这个团队里，“所有权”到底意味着什么？

理论上答案可能并不复杂，但现实会证明不是这样。每位工程师都清楚自己工作被视为“完成”的标准吗？他们能否明确成功与失败的含义，以及在什么情况下需要主动提出问题？这些并不是所谓的“软技能”，而是高效工程组织真正运转所依赖的基础架构。一旦这个基础出现问题，人工智能带来的往往不是修复，而是把摇摇欲坠的感觉推得更明显。

在人工智能出现之前，一支高效团队的运作方式是我所说的“责任自主”。领导者对各自领域有真正的掌控力，会主动发现并解决问题，而不是等别人发指令。他们沟通积极，尤其在遇到问题时更是如此。他们内部有一套共享且清晰的框架：用来分配工作、界定成功标准，并建立反馈机制。当团队开始使用人工智能工具时，效率提升并不只是线性增加，而是会成倍增长。他们知道如何引导人工智能、纠正错误、优化提示内容。对他们来说，人工智能就像指挥家带领交响乐团：不需要指挥每一个乐器的具体演奏，但必须掌握整套运作的节奏与方向。

如果没有这种基础，你等于把一个声音更大的乐器交给一个不会演奏的人。

有些团队确实不适合在现在就上人工智能编码工具，甚至可能比我们想得更普遍。如果工程师还在摸索如何真正严谨地进行代码审查，那么引入人工智能只会让他们产出更多仍需反复返工的代码。若迭代计划会议只是走流程，人工智能只会帮你更快把更多错误的工作塞进这些迭代周期里。先守住纪律，再谈加速器。

领导者常犯的另一个误区，是衡量回报的方式。大多数讨论都会把重点放在产出量上：生成的代码行数、解决的问题数量、速度指标。没错，这些数字确实会变化。但这恰恰是错误的视角，它遮住了真正值得追求的机会。

真正的结构性问题在这里。多数工程组织采用两周为一个迭代周期。迭代周期本质上是最小的工作量估算单位，这意味着即使人工智能执行得再快，你的“工作量容器”也不会被自动缩小。工作就像气体，会膨胀以填满你预留的空间。因此现实会变成：原本需要一周完成的任务，被人工智能压缩到了两天；剩下的时间工程师会继续用在其他迭代周期里的工作上。于是速度指标小幅上涨，领导层就把这当作胜利。但工具的复利潜力几乎被浪费殆尽。

真正的投资回报率难题不在于“我们是不是变快了”，而在于“我们现在开始尝试哪些以前从未做过的事？”人工智能应该改变的是计划的目标，而不只是现有任务的执行速度。那些真正领悟到这一点的团队，正在重塑的并非只是完成工作的方式，而是对工作的思考方式。也正因如此，我一直在尝试更短的迭代周期：这并不是为了追逐更高的产出，而是为了迫使大家重新思考，在执行不再是瓶颈的情况下，应该如何估算并界定工作范围。

判断人工智能应用是否有效，其实信号很直接：工程师是否把更多时间用在思考上，而不是仅仅盯着键盘输出？这才是关键。因为在编写代码这件事上，人工智能已经比你的工程师更强。它读过每一份文档，不会忘记语法，也不会因为状态不佳而失手。那就让它来写代码吧。

工程师接下来要做的是：引导与指导人工智能，质疑它的输出，并把那些人工智能自身难以正确构建的问题补齐。这项工作需要更多的认知投入，而不是更少。意味着要提出更深层的问题，指出人工智能明显错漏的地方，并做出任何模型都无法复制的判断。等我看到团队真正按这种方式运转——让人工智能负责机械执行，让人类负责判断——他们的产出才会重新变得像我周末亲身感受到的那样出色。

这种放大效应已经开始显现。唯一要确认的是：你喂给系统的素材，是否真的值得被放大并大规模传播。