CEO · Vibe Coding · 组织变革

CEO 天天写 Demo,最忙的为什么总是下面的人

Demo跑通只是起点。权限、数据、维护和责任没有跟上,老板越会写,团队可能越忙。

公众号封面 CEO 沉迷 Vibe Coding,忙坏了下面的人
公众号封面 CEO 沉迷 Vibe Coding,忙坏了下面的人

最近见到一种很有时代感的公司景象。

一家上市公司的 CEO,每天追着 vibecoding 和 agent 的新消息跑。今天看见一个框架,晚上就做出一个 demo。明天又试一个新工具,顺手把代码丢给下面的人,要求接着维护。接活的人甚至不在研发部门,还得每天汇报进展。

老板很兴奋。员工很忙。群里的截图一张接一张。过了几周,公司的老流程照旧,新流程没有长出来,倒是多了一批需要解释、修补和续命的半成品。

这种场面很容易让人误判。老板亲自学 AI,至少比完全不懂强。这个判断没错。问题出在他把个人探索直接变成了组织任务,中间少了好几道本该由公司补上的工序。

个人做 demo,只要证明一个点子能跑。公司接一个系统,要回答的事情多得多。

数据从哪里来,权限怎么开,错误由谁兜底,旧系统怎样对接,版本谁来管,员工为什么愿意改掉原来的做法。模型升级一次,结果变了,谁负责回归测试。员工把客户资料贴进第三方工具,出了问题又算谁的。

这些工作没有 demo 那一刻好看。它们才决定 AI 最后能不能留下来。

Demo 跑通的那一刻,组织的麻烦才刚开始

我把近两年的几份企业 AI 调研对了一遍,里面反复出现同一个落差。企业采用 AI 的比例涨得很快,能把试点变成规模化收益的公司仍然不多。

斯坦福 2025 年 AI Index 收录的调查显示,2024 年有 78% 的受访组织报告正在使用 AI,上一年是 55%。麦肯锡后续的全球调查里,接近九成受访者说公司已经经常使用 AI,可多数企业从试点走到规模化收益依然很慢。

原因也不神秘。麦肯锡把高价值企业常做的事情列了出来,包括重做工作流、设立清晰的治理责任、按岗位培训、建立反馈机制、跟踪投入产出。这里面没有哪一项能靠 CEO 多写两个 demo 自动完成。

Google Cloud 旗下 DORA 的 2025 年研究给了一个很准确的说法。AI 像放大器,会把组织原有的优点和缺点一起放大。

AI 会放大组织现状,流程越乱,混乱来得越快
AI 会放大组织现状,流程越乱,混乱来得越快

一家公司的测试、文档和发布流程本来就顺,AI 可以把它推快。需求经常变,系统没人说得清,跨部门靠熟人催,AI 只会让更多代码和更多变更更快地涌进来。原先一个月积下来的混乱,现在一周就能攒够。

Demo 跑通,麻烦才刚开始
Demo 跑通,麻烦才刚开始

这也是非研发员工接手 demo 时最尴尬的地方。

他拿到了一段能运行的代码,却没有产品权限。他要对进度负责,却调不动安全、数据和研发资源。老板每天问做到哪里了,他只好先保证页面还能打开,再想办法解释今天为什么又坏了。

久而久之,组织会学到一种很坏的应对方式。老板展示新 demo 时,所有人先鼓掌。会后大家再找一个成本最低的办法,让它看上去还活着。

AI 没有进入生产,汇报先进入生产了。

CEO 当然应该亲自用 AI

CEO 亲手用 AI 很有必要。他需要知道模型擅长什么,哪里会胡说,做一个原型究竟能快到什么程度。只听供应商讲方案,判断容易失真。

亲自用和亲自包办是两回事。

CEO 最值钱的工作,在于挑出值得公司投入的问题,并为这个问题重新分配权力、预算和责任。他可以用 demo 把方向讲明白,然后交给一个同时承担产品、工程和业务责任的小组。这个小组有权删功能,有权推翻原型,也有权说当前条件不够,项目应该停。

CEO 要改组织,不要养 Demo
CEO 要改组织,不要养 Demo

如果老板交下来的每个 demo 都必须维护,创新很快就会变成欠债。员工不敢删,因为那是老板写的。研发不愿接,因为代码没有测试和文档。业务也不敢真用,因为出了错还是自己担责。

最后留下的往往是一片 demo 博物馆。每件展品都曾让老板兴奋十分钟,旁边站着一个负责擦灰的人。

每天汇报又会把问题推得更远。探索性项目需要快速验证,也需要快速判死刑。日更汇报逼着团队每天制造可见进展,最诚实的答案往往说不出口。模型效果不稳定,数据拿不到,用户根本不需要,这些都可能是好结论。可它们写进日报,看上去像没干活。

于是团队继续修界面、补按钮、改提示词。项目的生命靠汇报延长,价值并没有跟着长。

AI-Native 改造,先改谁能做决定

许多公司谈 AI-Native,先想到模型、算力和 agent 平台。技术当然要买,组织里的决定方式也得跟着动。

一个业务问题交给谁,谁能访问所需数据,谁能让旧流程停下来,谁来判断结果是否可信,谁承担上线后的后果。公司没有把这些关系说清,agent 能做的事情越多,扯皮的地方也越多。

合适的试点通常很小,边界却很完整。选一个有明确负责人的流程,找到当前要花多少时间、错多少次,再让业务和工程一起改。效果达标就扩大,达不到就关掉。老板看结果和障碍,不接管每天怎么写提示词。

这套做法没有 CEO 现场写代码那么热闹。它会碰权限,会改考核,也会让一些部门交出原来握着的东西。组织改造从来比做 demo 难,所以人很容易躲进工具里。工具立刻给反馈,组织只会给阻力。

一个掌舵者沉迷于即时反馈,这才是最值得警惕的部分。

那点木匠活

说到这里,就能明白那句"一家之主每天沉浸于那点儿木匠活"为什么损得很准。

故宫博物院介绍明熹宗朱由校时,提到他喜欢油漆木工和房屋营造,也爱各种机巧。后世给他留下了"木匠皇帝"的名号。一个人手艺好,本来不算罪过。皇帝的位置却不能只按作品精不精巧来评价。朝堂上的权力怎样运行,奏章落到谁手里,才是坐在那张椅子上的人该处理的事。

拿这个典故说今天的 CEO,重点也不在嘲笑他写代码。

一个 CEO 能在半天里做出 demo,说明工具确实进步了。第二天,他若能让公司把权限、流程、责任和考核一起改掉,才说明这家公司也进步了。

否则,台上的人日日精进手艺,台下的人忙着替手艺收拾残局。木件越做越多,房子还是那座旧房子。

参考资料

• 麦肯锡企业如何通过组织改造获得 AI 价值

• 麦肯锡 2025 年全球 AI 调查

• 斯坦福 2025 年 AI Index

• DORA 2025 年 AI 辅助软件开发报告

• 故宫博物院藏明熹宗朱由校像

— 完 —

常见问题 · FAQ

这篇文章主要讲什么?

CEO亲自做AI Demo之后,组织为何可能更忙,以及如何避免把原型变成技术债。

「组织的麻烦才刚开始」具体怎么做?

我把近两年的几份企业 AI 调研对了一遍,里面反复出现同一个落差。企业采用 AI 的比例涨得很快,能把试点变成规模化收益的公司仍然不多。 斯坦福 2025 年 AI Index 收录的调查显示,2024 年有 78% 的受访组织报告正在使用 AI,上一年是 …

「CEO 当然应该亲自用 AI」是什么意思?

CEO 亲手用 AI 很有必要。他需要知道模型擅长什么,哪里会胡说,做一个原型究竟能快到什么程度。只听供应商讲方案,判断容易失真。 亲自用和亲自包办是两回事。 CEO 最值钱的工作,在于挑出值得公司投入的问题,并为这个问题重新分配权力、预算和责任。

「先改谁能做决定」具体怎么做?

许多公司谈 AI-Native,先想到模型、算力和 agent 平台。技术当然要买,组织里的决定方式也得跟着动。 一个业务问题交给谁,谁能访问所需数据,谁能让旧流程停下来,谁来判断结果是否可信,谁承担上线后的后果。