在 AI 环境下,一家软件公司最危险的一种＂高效＂

一、一个深夜的消息

十月的一场投标，通知是晚上十点多发过来的。

一位老板给公司的技术负责人发消息：某高校的项目要在 10 月 14 号投标，问一句，工程XX这块进度怎么样，10 月 9 号之前要全部准备好。

技术负责人的回复很实在：这条线的交付本来就是按计划排在 10 月底，现在的进度能保证 10 月底按时交出来，但提前到 10 月 9 号不可能。如果只是给客户看一个演示，那还可以。

老板听完，回了一句：大家的工作效率是不是有点低。

这句话没有下文。技术负责人没有接这个茬——接了也没用，因为两个人讨论的根本不是同一件事。他在说"东西能不能做完"，老板在说"机会能不能抓住"。这两句话都不算错，但它们不在一个频道上。

这件事真正有意思的地方，不在于谁对谁错，而在于它把一个长期潜伏在这家公司内部的分裂，从水面下顶了上来。

同一家公司，两个房间。左边是老板看到的，右边是工位上的。中间那条通道是断的。

二、两套叙事

在这家公司里，只要走得足够近，就会看到一个很分裂的画面。

老板的办公室里，是另一套叙事。电话一个接一个，新订单不断进来，客户排队，业务在扩张。老板看到的每一个信号都在告诉他：市场在要货，公司势头很好，现在就是抢时间、抢机会的时候。

而一墙之隔的工作大厅里，是这一套叙事：

同一家公司，同一批人，同一天。一个房间里看到的是增长，另一个房间里看到的是债务。前者是收入的前端，后者是交付的后端。而这两套叙事之间，没有任何一条畅通的通道。

这不是沟通问题。沟通问题是"话没说清楚"，而这里是"两边看到的现实本来就不一样"。

老板不是不想知道真相。是在这套结构里，他天然只能看到前端的繁荣。真实的一线情况——还剩多少 bug、有多少功能只是勉强能演示、有几个人已经在连轴转——这些信息要穿过项目经理、技术负责人、产品经理一层层往上走，每走一层都会被"再处理一次"：能自己消化的先消化，能往后拖的先拖，实在兜不住的才报上去。等这个消息终于落到老板桌上，它已经被打磨成四个字——"进度可控"。

所以老板不是疏忽，他是被结构性地屏蔽了。更麻烦的是，他自己那套"欣欣向荣"的叙事还在被前端不断强化——订单是真的，签约是真的，回款也是真的。这就让他更有理由相信：问题不出在方向上，出在人身上，出在效率上。

三、计划为什么会变成一张废纸

这家公司的产品研发，本来是按项目计划推进的。

计划写得很清楚：模块一个个做，节点一个个卡，什么时候出什么东西，都有约定。这套计划在纸上完全成立，而且确实一直在按它推进。

问题是，只要外面出现一个新的投标机会，计划立刻失效。

投标的时间不等人——客户给的时间就那么多，竞争对手就在旁边。老板一着急，计划就要让路。原本一个月的开发周期，被压缩成两周、十天，甚至更短。他没有说"这条线我们先不做"，他说的是"速度再快一点"。

于是所有人被推到一个不可能的位置上：既要按原计划交付已经承诺的东西，又要在被压缩的时间窗口里，把一个还没长熟的模块拉出去见客户。

这里出现了一个很典型的判断错位：老板觉得"一个月出一个新模块太慢了"。可他心里的参照物，已经不是团队过去的速度，而是他自己动手时的速度——那是一个下午就能冒出一个能跑起来的原型的速度。这个参照物真实存在，但它不属于同一个坐标系。标准是从另一个世界拿来的，压力是往这个世界的团队身上压下去的。

计划为什么会变成废纸？不是做计划的人不行，是这个组织还没有形成"计划优先于机会"的取舍习惯。机会来了就调整计划，听起来像是在快速响应市场，实际上是让整条产线永远停在半成品状态——没有一件事被真正做到底。

四、每个人都在当两三个人用

现在这家公司里，几乎找不到一个"只干一件事"的人。

同一个人，白天给已经签下的项目改 bug、做交付，晚上和周末给下一版产品开发新功能。负责项目的人同时在负责产品，负责产品的人同时在到处救火。

老板也清楚这一点，他甚至经常把这当成一种骄傲：人少、能打仗、每个人都能顶两三个人。这话不假，团队确实是这么在用。

但这里面有一笔账，老板没算过。

一个人同时承担交付和研发两条线，听起来是"效率高"，实际上是两条线都被拉慢，而且两条线的质量都会下降。交付需要的是稳定和收敛，研发需要的是探索和试错——这两种工作在一个人身上来回切换，每次切换都要付出成本。更要命的是，交付的压力永远比研发更急，所以研发永远会被挤压到晚上和周末，而研发恰恰是最需要完整时间块的工作。于是研发的产出，只能是碎片拼出来的半成品。

在这样的节奏里，老板还乐此不疲地天天开发新功能。他亲手在往前推，团队也跟着往前推。所有人看上去都极其努力、极其忙碌、极有战斗力。整个公司的气氛甚至是积极的。

但努力的方向，是在往债务上堆。

五、他拿到了一本"武功秘籍"

要理解这家公司今天的所有问题，必须先理解一件事：这位老板不是技术出身。

他是业务专家，也是销售出身。这家公司最早的客户，几乎都是他一个人跑下来的；客户想要什么、会为什么付钱、哪个痛点值得做成功能、什么样的报价能签下来——这些事他比公司里任何人都清楚。正是这套本事，把公司从零做到了今天。在"理解客户"这件事上，他是绝对的内行。

但在软件工程这件事上，他是彻底的门外汉。他不知道一个功能从想法到上线要经过哪些环节，不知道代码里哪些东西是必需的、哪些是可以省的，更不知道"做完了"这三个字在技术上其实有很多种不同的含义。

然后，Coding Agent 来了。

对这位老板来说，这件事的意义接近于——他拿到了一本武功秘籍。过去他脑子里那些不断冒出来、又不断消失的灵感，总要等团队排期、等资源、等一个"以后再说"；而现在，他说几句话，一个真的能跑起来的东西就出来了。他不用再求人，不用再等，甚至可以整夜地试自己的想法，一个接一个。

他极度兴奋。灵感越来越多、越来越发散，而且每一个都能立刻看到成果。他开始亲自操刀——白天谈客户，晚上写系统。在团队面前，这甚至看起来像一种榜样：老板都在学新技术、都在自己动手。

但问题恰恰从这里开始。

魔法给人的最大错觉，是"它没有门槛"。武功秘籍之所以叫秘籍，是因为它有内功、有心法、有必须先练好的基本功；而 AI 给人呈现的，是"你说一句，它给你一个能跑的东西"，中间看不见任何基本功。

事实是，AI 确实把"写代码"这道门槛降到了很低，但它并没有降低"软件工程"这道门槛。门槛只是发生了转移——从"会不会写"，转移到了"知不知道该写什么、不该写什么、写完以后还要补什么"。

而这一层，恰恰是 AI 不会主动告诉你的，也恰恰是业务出身的人最不会去怀疑的地方。因为在他眼里，东西跑起来了，就是成功了。

六、Demo 和产品之间，隔着一条命

这家公司最要命的问题，藏在这句话里：

老板自己开发的东西，提交给团队的都是 demo 水平的半成品。但他自己并不这么认为——在他潜意识里，这些东西已经是可以直接拿去生产环境交付的成品了。

这是所有矛盾的根。需要说清的是，这不是某一个人的主观感受——公司里做技术的那几个人，私下里早就达成过一致的判断，只是没有人把它端到台面上说。因为他们也很难开口：怎么告诉一个刚用 AI 做出了整个系统、正处在兴奋中的人，他做的东西其实只是一个"样品"？

demo 和产品，在传统软件领域就是两件事；在有 AI 参与的开发里，这个差距更大。一个 demo 之所以能很快跑起来，是因为它把大量东西简化掉了：硬编码的密钥、写死的路径、没有异常处理、没有超时控制、没有权限校验、没有并发考虑、没有回滚机制。演示的时候一切顺利，是因为演示走的是那条被精心设计过、最顺利的路径。

而从一个 demo 走到能在客户现场顶住真实流量的生产系统，代码量通常要翻好几倍，真正花在"核心逻辑"上的时间可能只占三成，剩下七成全是工程化的事：容错、权限、审计、性能、部署、升级、可观测性。这些事没有任何一件能在演示时被看见。

而支撑这些事的，是软件行业里一些极其朴素、极其基础、几乎不需要讨论的规则——要写测试；要有架构；要做版本管理和代码评审；要有发布流程、要能回滚。

这些词，对技术团队来说是常识，是每天都要打交道的东西。但对一个业务出身、没有工程背景的人来说，它们是陌生的——不是他反对，是他不知道它们存在。

这是一个非常关键的差别。一个人如果知道测试和架构是必需的，他会在"要不要花这两周"上做取舍；一个人如果根本不知道有这些东西，那么团队说的"还要两周"，在他耳朵里就只剩一个意思——你们太慢了。

演示的人只看得见水面上那一截。AI 让这一截长得越来越快，但不会替你长出水下那 70%。

在客户面前演示一个漂亮的半成品，这件事本身不致命。致命的是，老板把这个"漂亮"当成了完成度，把"能演示"当成了"能交付"。于是他的时间感、他的期望值、他对团队效率的判断，全建立在一个虚假的基准上。

这里还有一个被 AI 悄悄改变的事实："看起来完成"变得越来越廉价了。以前做一个能演示的东西要十天，现在一个下午；以前一个想法要等两周才能看到样子，现在当场就能。做出来的东西越来越好、越来越快、越来越像真的——但"能演示"和"能交付"之间的距离，一厘米都没有缩短。

AI 没有缩短这段距离，它只是把这段距离藏得更深了。以前差距摆在明面上，团队自己就能看见；现在水面上那一截长得又快又漂亮，水下的部分反而更不容易被察觉。

这也解释了他为什么总觉得团队效率低：他心里的及格线，是自己一个下午用 AI 做出来的那个能跑的东西；而团队手上要交的，是能签进合同、能放在客户服务器上跑三年、能在审计和检查面前站得住的产品。这两样东西，不可能一样快。

团队越拼命往"能交付"的标准上靠，他越觉得慢。这不是团队的问题，是他从来没有真正看见过这两种东西的差别——也没有人告诉过他，这个差别有多大。

七、AI 是放大器，不是解药

这里可以退后一步，看看这家公司身上到底发生了什么。

1854 年，德国物理学家克劳修斯提出了熵增定律：在一个封闭系统里，如果没有外界输入能量，系统会自发地从有序走向无序，而且这个过程不可逆。一杯热水放在桌上会自己变凉，一间屋子没人收拾会越来越乱。这不是谁的错，这是最底层的规律。

组织也是这样一个系统。它不会因为你努力就自动变得更有秩序。恰恰相反，只要没人在主动对抗混乱，组织就会自己滑向混乱：接口越来越多、依赖越来越乱、文档越来越旧、每个人对同一件事的理解越来越不一致。这些变化每天都很小，小到没人觉得需要处理——但它们在累积。

AI 的出现，让这条曲线变得更陡。

它把产出速度提高了十倍，却没有把秩序提高十倍。没有版本管理，一夜之间就能多出十几个分支和一堆散落的工作副本，谁也不知道哪个才是最新的；没有架构约束，AI 生成的东西每一次都能跑起来，但每一次长得都不一样，几个月后没人说得清这个系统到底由几层组成；没有测试，改一个地方之后，谁也不知道会坏掉哪里，于是发布变成赌博。

换句话说：AI 按下了生产键，但没有装上刹车和方向盘。

于是这家公司出现在一个非常典型的高熵状态里：每个人都在极度努力，但这些努力在互相抵消——一个人晚上加班写出来的新功能，让另一个人白天要花两天去适配；今天为了赶投标临时打的补丁，变成了三个月后一次线上事故的引线。老板办公室看到的是"新订单不断"，这是表象；真正致命的是内部的信息熵增，一线的真实情况传到老板那里时早已失真。

所以我们大概可以总结出这个时代最危险的一种组合：业务能力极强 + 工程能力极弱 + AI 工具极强。

三者相加，等于以极高的速度、极大的规模、毫无节制地生产技术债务。而且它的可怕之处在于，中间的每一步都是积极、努力、充满热情的——没有人觉得自己在做错事。

AI 从来不是解药。它是一个放大器：它放大你原本就有的能力，也放大你原本就有的认知缺陷。一个组织如果本来是混乱的，AI 只会让它更快地混乱。

八、努力悖论：方向错了，跑得越快越远

巴菲特有一句被引用得很多的话："在错误的道路上，奔跑也没有用。"

这句话在投资里成立，在企业经营里同样成立。投资领域有个概念叫努力悖论：一个决策是否优秀，并不取决于投入了多少努力，而取决于是否看清了约束条件、识别出哪些因素是自己真正能操控的。在不确定的环境里，方向判断的价值远大于努力本身。

如果方向错了，越努力，离目标越远——因为努力会放大错误的后果，同时消耗掉组织纠正错误所需要的资源。

这家公司现在就是典型的"在错误的道路上狂奔"。老板以为问题出在速度上，所以他的动作是催促、加需求、加功能，再加上一个他刚刚获得的、看起来能无限加速的工具。但真正的问题不在这里：

方向错了，速度只会让人更快地到达终点。

这些认知不改变，他的每一次努力，都会让技术债务积累得更快，让团队士气消耗得更狠。于是就有了那句听起来很重的话——

加缪在《西西弗斯神话》里写："登上顶峰的斗争本身足以充实人的心灵。应该设想，西西弗斯是幸福的。"这句话常被用来鼓励人。但它的前提是——推石头这件事本身是有意义的。如果一个团队每天都在把石头推上山顶，而山上根本没有人在接，那这不是悲壮，这是消耗。

九、这不是效率问题，是认知问题

回到最初那条深夜的消息。

一条投标通知，两个日期，一句"10 月 9 号要准备好"，和一句"大家效率是不是有点低"。

看起来是一次排期冲突，实际上是把这家公司的完整病灶照了一遍 X 光：交付与研发互相挤压、计划让位于机会、demo 冒充产品、信息在传递中失真、老板的认知与一线的现实分属两个世界。而 AI 的出现，给这套病灶装了一个加速器。

需要说清楚的是：这位老板没有做错任何一件"努力"的事。他没有偷懒，没有贪图安逸，他甚至比任何人都更积极地去拥抱新技术。他唯一的问题是——他站在一个错误的认知基点上，用最快的工具，把错误加速了。

这是 AI 时代刚刚出现的、还很新的一种困境：工具的进步跑在了认知的前面。以前一个人不懂工程，最多是慢——他的笨拙会自然地限制他的破坏半径；现在一个人不懂工程，却拿着一个极快的工具，他的破坏半径被放大了无数倍，而且他自己毫无察觉。

所以这些问题有一个共同点：它们都不会在短期内爆发，所以很容易被忽视；它们都会在长期里累积，所以一旦爆发就很难挽回。

而它们全都指向同一个源头——认知。

一个人对自己公司的判断，如果建立在他自己想看到的那套叙事上，那么他所有的勤奋、所有的投入、所有的加班，都会变成加速器。这个时代尤其如此：过去勤奋只是勤奋，现在勤奋是一台被踩到底的油门。

方向，永远比速度重要。