AI 领导力：像管理团队一样管理 AI

在 AI 浪潮席卷各行各业的当下，我们正经历一场前所未有的“原地升级”：AI 并非取代岗位，而是要求所有从业者，特别是身居管理和架构岗位的领导者，重新审视并升级其领导力范式。本文整理自腾讯专家工程师揭光发在 QCon 上海 2025 的演讲 “AI 领导力：像管理团队一样管理 AI”。他深入介绍了如何以更高效的方式管理 AI，如同管理一支高效的团队。

我们深知，对于架构师和高管而言，管理团队、协调资源、驱动项目是日常核心。然而，传统的人力管理往往伴随着反馈延迟、过程不可控等挑战。奇妙的是，“管理 AI ”恰能解决这一悖论。

AI 的即时反馈和高可控性，不仅能带来巨大的管理杠杆效应，更提供了一种前所未有的高效管理模式，让领导者能够以更精准、更可控的方式，驱动“数字员工”完成目标，重拾作为“指挥官”的掌控感和成就感。

为实现这一目标，我们将探讨“ AI 领导力”的四大核心支柱。这包括像管理团队一样知人善任地组建 AI 队伍，高层级地设定目标，以及战略性地管理过程和专家级地验收成果。

AI 不会削弱技术领导者的价值，反而会将其无限放大。未来的优秀技术领导者，将是那些能够高效管理和编排人机混合团队，共同交付卓越成果的“超级指挥官”。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

今年年初 3 月，Manus 发布时，我便广泛提及一个观点：如今我们使用 AI，已不再将其仅仅视为工具，而是实实在在地将其当作能帮我们干活的人来使用。尽管 AI 本身没有情绪，但管理人时所涉及的诸多要点，在管理 AI 时也一个都不能少，这是我今天想要表达的核心内容。

Vibe Coding ——"心流"在编码中重现

首先，我们来谈谈 Vibe Coding。对于从事技术工作，尤其是担任技术领导的人员来说，这是与 AI 直接相关且能显著提升工作效率的领域。使用 AI 来编写代码，如今已司空见惯，且在近一两年成为主流趋势。我稍后会举例说明，但可以说，我所编写的代码中，AI 的参与度几乎达到了 100%。

Vibe Coding 的概念其实无需过多解释。它主要是通过自然语言描述需求，然后让 AI Agent 来实现代码编写、测试并运行。在这个过程中，你无需过多关注代码的具体实现细节，只需不断提供反馈，指出“这里还不行”，并告知下一步该怎么做。最终，通过与 AI 的协作，完成整个软件的交付，这就是 Vibe Coding。这实际上是 AI 与工程师，乃至技术领导日常工作中频繁涉及的一项活动。

介绍一下自己在 Vibe Coding 方面的经历。2022 年 ChatGPT 发布后，我们发现除了与它对话聊天、观看它写代码外，还能有更多应用。2023 年早期，我们开始在 ChatGPT 网页上与其交流，让它编写一些代码片段。当时大家开始觉得，AI 在这一波的发展中确实表现不错。然而，真正大规模将 AI 应用于生产环节，是在 2023 年底 GitHub Copilot 插件推出之后。那时，我所编写的代码中，AI 的含量已经达到了 85%。说白了，2023 年 3 月我重新开始写代码，是因为我可以借助 AI 实现想法，而无需亲自编写代码。这使得许多小型项目，尤其是工具类技术产品，开始通过 AI 逐渐诞生。到了去年 9 月，Cursor 出现后，我更加放开手脚，真正以 Agent 的方式编写代码，直至今日。如今，Claude Code 等各种智能代码代理层出不穷，多到两只手都数不过来。对我个人而言，目前几乎 100% 的代码都是由 AI 编写的，除非我发现某行代码可以删除以节省 Token，否则我不会亲自编写。

在我的带动下，我的团队也积极投身于 AI Coding。目前，团队中大约 50% 的代码由 AI 编写。之所以没有达到 100%，原因有两方面。一方面，对于一些前端项目，AI 还原度并不高。因为视觉模型与文本模型之间存在天然的差距，目前尚未得到很好的解决，视觉还原能力这一块还存在不足，所以这部分工作仍需人工参与。另一方面，有些团队成员不想让 AI 完全包办所有工作，他们希望保留一定的掌控感。他们会编写大致的框架，然后让 AI 填充细节。这样一来，如果出现问题或故障，他们可以迅速自行修复，而无需再次求助于 AI。这种主动降低 AI 含量的做法，导致团队中并非所有人都能达到 100% 的 AI 含量。

在我们团队所在的公司，有一个名为 loki 的低代码项目。2023 年，我带领团队搭建了一个跨语言的逻辑编排平台，其中涵盖了前端和后端三种语言的运行时环境，分别是 Golang、Python 和 Node.js。这个项目是我 2023 年开始重新编写代码时着手的，当时有一两名同事在闲暇时间参与其中。此外，我们还在内部使用了一个 AI Agent 低代码搭建平台，这可能和 Coze 或 Dify 同期或更早，大约在 2023 年中后期到 2024 年早期，我就开始着手这个项目。当时我发现 AI Agent 即将兴起，并且会有广泛的应用，于是开始带领刚加入团队的实习生同学一起推进。在这个项目中，大部分后端代码是在我的指导下由 AI 编写的，其中 95% 以上的代码都由 AI 生成。但我必须强调，尽管 AI 完成了大部分代码编写工作，但这并不意味着我没有投入精力，稍后我会详细说明这一点。

最近的一个案例是大型前端组件的重构迁移项目，我们将一个大型项目从 Angular 迁移到 React。大家都知道，Angular 在国内并不算特别流行，而且技术栈相对有些过时了。迁移过程中，我们需要深入理解原有代码的逻辑，并进行大量测试以确保迁移的准确性。我们通过 AI 的方式来进行迁移，具体逻辑是：先在旧的组件代码中编写单元测试，完成单元测试后，将旧代码转换为新的组件代码，并同步迁移单元测试。但这还不够，我们还利用线上大量的数据（几十万条）作为回测数据进行测试。整个过程中，从代码翻译、测试编写到测试运行，包括测试数据验证脚本的编写，几乎都由 AI 完成。原本可能需要一两个人花费半年以上时间完成的工作，我们通过 AI 协作压缩到了一到两个月。当然，在这个过程中，我们也会进行人工抽查，以确保迁移的准确性。

我想引入一个名为“心流”的概念。有一天，我和朋友聊天时提到，我很久没有体验到一种感觉了，但最近这种感觉又回来了——那就是我找到了心流。我想每位程序员都曾有过这样的体验：戴着耳机，全神贯注地敲代码，不知不觉一个上午就过去了。在那个过程中，你沉浸于代码世界，无人打扰，从编写代码到测试、运行，再到不断调试，整个过程掌控感极强，时间也在不知不觉中流逝，这就是心流状态。其实，所有创作者都会经历这种状态。但为什么我很久没有体验到这种感觉，却又突然找回了呢？成为团队领导后，你会发现管理团队和编写代码是两件完全不同的事情。当你安排团队成员去做一件事时，你需要等待他们的反馈，这个过程往往漫长，中间还会有许多会议和沟通协调，整个流程并不顺畅。因此，成为领导后，我在很长一段时间内都失去了这种心流的感觉。然而，通过 Vibe Coding，这种感觉又回来了。原本可能需要十多天才能完成的项目，现在通过 AI 协作，我下达指令后，可能一两分钟就能得到初步结果，然后我继续给予反馈。这种反馈链条的闭环时间非常短，所以我又重新找回了那种在管理层面上的心流感觉。

在谈到 Vibe Coding 时，我们也不得不提及 Software 3.0，因为当我们说要与 AI 共事时，这里的 AI 几乎指的都是 Agent。而 Agent 的本质是一种软件形式。无论是 Software 3.0 还是 Vibe Coding，都与 Karpathy 提出的概念有关，所以在这里一并提及。那么，1.0、2.0、3.0 这三种范式是如何演进的呢？

1.0 时代，我们手动编写代码，经过编译后运行。代码中的逻辑是明确写好的。例如，要实现对一些词语的情感判定，我们会用 if-else 语句来编写逻辑：如果文本中包含“amazing”，就判定为褒义。

2.0 时代，出现了一种通过神经网络或机器学习训练出的小模型，比如一个纯视觉识别模型。这种模型不是通过编写代码实现的，而是通过数据训练得到的。对于情感判定，我们会用训练好的神经网络模型来预测词语的情感倾向。

到了 3.0 时代，我们所看到的是基于大语言模型的衍生程序，也就是 agent。以情感判定为例，我们直接给 Agent 一段话，用自然语言与它交互，请求它判断文本中单词的倾向。Agent 会直接给出大语言模型的判定结果。Software 3.0 的本质是智能体系统，以自然语言为接口，让 AI 能够理解人类意图并自主执行任务。

Vibe Working —"心流”延伸至所有工作

刚才我提到的主要是关于编程的内容，其实我们已经对它非常熟练了。现在我想进一步谈谈 Vibe Working，也就是“一切皆可 Vibe”的概念。如今，大家都在讨论 AI 如何渗透到各个领域，我也想分享一些我在其他方面与 AI 协同工作的例子。

比如制作幻灯片 Vibe Sliding。从今年开始，我再也不为准备 PPT 而焦虑了。过去，我总是拖延到最后一两天才开始制作幻灯片，因为虽然演讲的内容我早已了然于心，但排版、绘制图形、寻找图片并进行排版这些繁琐的工作让我感到头疼。我这份 PPT 完全是通过 AI 生成的，从风格上应该能看出来，理论上人工制作的 PPT 不会使用这么多颜色，但它的可读性依然不错，能够清晰地传达信息。整个 PPT 的制作过程就像编程一样，通过 AI 完成，包括插入的 logo 等元素也都是通过 AI 添加的。而且由于 PPT 本质上是一个网页，AI 在编写网页方面也早已驾轻就熟。现在，我再也无法回到手工制作 PPT 的时代了，基本上都是通过 AI 来完成这项工作。

还有 Vibe Writing，也就是写作助手。现在大家看到的许多文档或公众号内容，基本上都是通过 AI 流水线式生成的。尤其是今年，AI 可以通过多 Agent 的方式拆分不同章节，让不同的子 Agent 分别撰写不同章节，这让撰写大型文档变得轻而易举，甚至撰写论文、专利等也不在话下。我自己也用这种方式撰写产品文档、说明书，甚至 API 接口文档也都是通过 AI 完成的。

阅读论文曾经是一件痛苦的事，过去要读完一篇长篇 PDF 并理解其中的所有内容，需要花费大量精力。现在，我们通常让 AI 代读。对于长篇公众号文章或新发布的论文，我们首先会转发给 AI 工具，比如腾讯元宝公众号的机器人号，它会为你总结内容，这也是一个很好的 AI 使用案例。

还有一个有趣的应用场景，那就是学习新概念。比如我们学习大型语言模型的工作原理时，如果有动画可视化展示其关键动作，我们会更直观地理解。AI 在这方面可以大显身手，比如它可以为我生成动画，展示光速的测量方法，或者迈克尔逊干涉仪中不同颜色光条纹的影响。在学习层面，这让我能够与 AI 进行非常强的互动，生动地演示我想要了解的知识点。对我来说，我已经不需要再去翻阅厚重的书籍，而是直接向 AI 提问，它会为我提供答案。

再比如个人秘书，我也进行了多次迭代。最早的版本是基于 Gemini CLI，它几乎是免费的，可以记录我的日常工作、安排日程等，所有这些都可以通过命令行与它对话完成。这与我们常用的结构化 Todo List 完全不同，Todo List 需要你自己去查看和记录，而这种秘书更像是真正的秘书，它会为你搭建一套数据存储系统，但你需要提示它进行结构化存储。现在，我已经升级到了第二版，加入了 Claude Code 和其他模型，功能更加强大。我还把它与我的企业微信打通，比如今天我要做演讲，它会提前几天提醒我准备，甚至处理各种出差事宜。它就像一个真正的秘书，只是它并非人类。AI 在我的工作和生活中，除了编程之外，还能在许多方面作为我能力的延伸，帮我完成许多不同的任务。

Vibe Working 的核心在于人与 AI 的协同合作。我们需要清晰地描述自己的需求，然后将任务交给 AI 去执行。在这个过程中，AI 会根据我们的指令完成相应的工作，并将结果反馈给我们。

AI 领导力——新范式下的核心四要素

回顾过往，当我们并非领导者，而是专注于具体事务时，我们总是亲力亲为。例如编写代码，我们一行行地写，然后编译、运行、发布。那时，我们直接参与具体的工作。然而，当我们将这些任务交给 AI 去完成时，情况就发生了变化。我们不再直接动手，而是开始指导 AI 去完成这些任务。

指导 AI 的过程是怎样的呢？首先，我们需要为它设定明确的目标。但仅设定目标是不够的，我们还需要管理整个过程，指导 AI 如何行动，当它出现错误时，我们要纠正它。最终，当 AI 交付成果时，我们需要进行验收。如果验收结果不理想，那么就需要返工，重复之前的过程。这个过程，难道不像是与下属或队友沟通协作的过程吗？正是在这个过程中，我意识到，当我们开始使用 AI 时，我们其实已经从执行者变成了领导者。

你所领导的可能不是人，而是 AI。但本质上，这并没有太大区别。未来，大家会逐渐发现这一点。AI 在某些方面甚至比人类更好管理，因为它更加稳定，不会给你穿小鞋或闹情绪。但在一定程度上，管理 AI 的要求甚至比管理人更高。管理人时，你可以发脾气，施加压力，从而激励他们更好地完成任务。但对 AI 来说，如果你的指令不清晰，它就无法执行任务，而且它也不会反抗。因此，在一定程度上，管理 AI 可能比管理人更具挑战性。这实际上是沟通和认知传递能力的极致考验，也是个人素质的体现。

我们来定义一下 AI 领导力。刚刚我已经提到，我们需要设定目标、管理过程、验收结果。这其实也涉及到了“知人善任”的概念。不过，或许我们需要将其改为“知 AI 善任”。这四个关键要素可以概括为：设定目标、过程管理、结果验收以及知人（AI）善任。

首先就是知人善任，了解你的“队友”，选择合适的 AI 模型、工具和代理。如果现有的工具不适合，你可能需要打造或打磨出适合自己的工具。这其实是在开始之前，组建团队时需要考虑的事情。在人员管理中，我们讲求选、育、用、留，而在 AI 领域，选也是至关重要的第一步。

按照应用场景来划分，我们常用的场景主要有以下几种：通用的大语言模型、代码助手以及 AIGC 领域，包括图片、音频、视频生成等。我们需要在这些领域中寻找行业内的顶尖模型，当然，这需要结合自身实际情况，因为有些模型可能成本较高。我在这里仅列举了前两种场景的选型或比较案例，供大家参考。

在 AI 编程工具的选型方面，目前 Claude Code 是我的首选。除了编程之外，我之前提到的个人秘书以及 PPT 制作等 Agent 工具，也都是基于 Claude Code 构建的。它的优点在于非常简洁，其 Agent 也很简单。它的特点是将对话中的所有内容都作为上下文传回，这种“大力出奇迹”的方式使得它在处理上下文时表现得比其他工具更出色。例如 Cursor 等其他 IDE 需要进行上下文压缩，而 Claude Code 则不需要。我们了解背后的逻辑，但也不会直接使用它的 API 付费方式，而是选择它的套餐，比如 Pro 版本。不过，使用 Pro 版本很容易触发 Token 的上限。即使你选择了 20 美元的套餐，现在又增加了周上限，很容易就触发了。

Cursor 在国内进行了限制，但当然有一些技巧可以绕过。即使在自动模式下，它也可能为你提供更好的模型，因为它需要保证效果。所以在这方面，我并不太担心。不过，它的收费方式变成了不封顶，即 20 美元用完后会继续计费。但我一直保留着 20 美元 500 次的计费方式，坚持不切换。到现在我发现，它的调用限制已经从 20 次增加到 200 次了。所以对我来说，这也是一个非常充足且性价比高的方案。目前，我优先使用 Claude Code，而 Cursor 则作为备份。

腾讯的 CodeBuddy IDE，它的特色在于贯穿了从设计到开发再到发布的完整链路。尤其是与 Figma 的深度整合，使得在界面还原方面表现出色。我们团队也尝试使用过这一功能，与直接使用 Cursor 搭配 Figma 的 MCP 相比，差异十分明显，这一点值得大家关注。

接着是 V0.dev，这是 Vercel 团队的另一款产品，专注于 Web 开发。在 V0 上进行开发的速度非常快，这也是它名字的由来——“V0”意味着“version 0”，即快速搭建原型和 Demo。虽然它的定位是用于快速原型开发，但实际上，用它来开发正式产品发布也并无太大问题，毕竟它背后有 Vercel 强大的底层支持。

再来说说 Gemini，这款模型如今可以说是厚积薄发。无论是图片生成还是代码编写的能力，都呈现出越来越好的态势。特别是它的 CLI，个人注册后几乎等同于免费使用。每分钟限制 60 次调用，但一天有两三千次的调用额度，对于日常使用来说，几乎感受不到 API 调用的限制。

不得不提的是 GLM 4.6，在我的 Claude Code 20 美元额度受限之后，我基本都用它来作为替代。从产出效果来看，它能达到 Claude Code 大约 80% 的效果，这是我的个人体验。目前我也大量使用这个 4.6 版本，不过有一点遗憾，国内模型的视觉能力相对较弱，4.6 本身并不擅长视觉处理，而是通过 MCP 的方式支持视觉功能，这种方式比较绕。我还是希望国内能尽快推出像 Sonnet 那样的多模态模型。不过，GLM 4.6 的套餐性价比很高，但如果不定制套餐，Token 消耗会比较高。

Kimi K2 是我最近用的一个加速版，它的解题速度快，无论是在质量还是成本上都优于 GPT 5。而且 Vercel CEO 大赞 Kimi K2，他在 x 公开表示，在一项内部智能体真实场景基准测试中，来自中国的 Kimi K2 模型表现优于 GPT-5 和 Claude Sonnet 4.5。

最后是 DeepSeek 3.2，它的 Token 消耗非常低，价格也特别便宜。与 Kimi 或者 GLM 相比，我自己的感受是，使用 DeepSeek 的费用不到其他两者的 1/4，甚至更低。DeepSeek 3.2 引入了稀疏注意力机制，本身就将 Token 价格降低了 75%，而且它对 Agent 的支持也非常好。有一段时间我因为 Sonnet 额度不够，切换到 DeepSeek，用了很长时间才花一两块钱，这让我非常惊讶。我觉得很多公司在评估后，如果真的要用 API，最终可能会选择 DeepSeek。它在 Coding 层面与 GLM 相比可能稍逊一筹，但问题不大，当然与 Sonnet 相比还是有差距。

我用的这些工具，其实都是在 Claude Code 上驱动的。Claude Code 可以使用不同的模型，我所说的使用 GLM 4.6、DeepSeek、Kimi 2，都是在 Claude Code 上切换模型来驱动。所以，它们的程序 Agent 逻辑还是遵循 Claude Code 的逻辑，只是模型变了，但输出质量都不错，这也得益于 Claude Code 本身的 Agent 工程素养和上下文管理方式。我推荐了多个国内的模型，但这些模型都需要搭配在 Claude Code 中使用，效果会很好，这与工程化密切相关。我也建议大家可以尝试一下这些工具，这就是我在编程层面工具选择的体会。

在与 AI 协同工作的过程中，目标设定是至关重要的第一步。很多人会问，如何设定目标？其实，核心方式就是通过精确的表达来传达需求。过去，在使用通用聊天机器人如 ChatGPT 时，我们常常需要通过复杂的提示词框架来引导机器人完成特定任务，比如编写代码。那时的提示词可能包含身份定位、角色设定以及各种指令，甚至有些奇奇怪怪的框架。然而，如今进入 Agent 时代，情况发生了变化。这是一个场景化协作的时代，需求表达变得更加直接和关键。我们不再依赖复杂的提示词技巧，而是要清晰地表达自己的需求。

需求表达能力成为与 AI 协同工作的核心能力。为了让 AI 理解并执行任务，我们需要非常精确地描述需求。这其实比管理人还要复杂，因为 AI 没有情绪，但它需要清晰的指令。现在，为了让 AI 完成任务，我需要详细地写出任务细节、想法和思路。如果 AI 不理解，我还需要继续补充。有时，我输入的内容可能多达几百字，这是前所未有的。所以，管理 AI 并不比管理人轻松，你需要全方位地表达清楚，对业务场景有深刻的理解，知道领域的专业知识，并且对期望的成果有准确的预期。你不能不确定结果就随意给出需求，否则 AI 给出的结果多半不符合你的期望。此外，你还需要设定约束条件，甚至需要对任务进行拆分，明确是让 AI 一竿子插到底完成任务，还是分步骤执行。这些都需要在需求表达中体现出来。

关于是否使用提示词，我在设计 AI Agent 时会用到提示词来设定其功能，但在使用 AI Agent 时，关键在于清晰地表达需求。当你输入的需求比较模糊，比如只有一句话时，AI 给出的结果往往是笼统的。在这种情况下，你可能觉得 AI 给出的 50 分或 60 分的结果已经很不错了。但如果你想让 AI 给出 80 分、90 分甚至满分的结果，你就需要从不同角度、细分地描述你的需求，明确你希望的产出是什么。这不是提示词技巧，而是深度挖掘你对目标的定义，具象化你的想法。

接下来是过程管理。当我们让 AI 执行任务时，可以选择让它一竿子插到底，从下午 2 点开始工作，到 5 点回来验收成果。这是一种方式。但另一种方式是将任务拆分成多个子目标，这涉及到所谓的粒度管理。当我们需要将任务拆分时，还需要考虑是通过串行还是并行的方式来实现。并行处理是常见的选择，比如同时打开多个窗口让 AI 完成不同任务。然而，在并行处理时，我们可能会遇到工作目录污染的问题，尤其是在编写代码时，如何避免多个 feature 之间的相互干扰是一个挑战。当所有 AI 任务完成后，我们如何验收结果？人类是否能够在短时间内切换多个上下文？这反过来挑战了人类的上下文管理能力。这些就是过程管理中的一些核心挑战。

在编程领域，我们并非总是采用“一竿子捅到底”的方式。事实上，软件工程的思想一直存在，而这些思想同样适用于 AI 编程。Kiro 提出了一个概念，即 Spec-Driven 的 AI 编程。这实际上是在 AI 编程领域的一种标准化或流程化方式。其过程通过几份标准文档来驱动整个任务的推进。首先，通过需求文档与用户梳理需求，然后根据需求文档编写设计文档，设计文档再驱动任务的拆分，最终由 AI Agent 根据这些任务逐步实现具体需求，从而完成整个项目。这并不是一气呵成的方式，而是一个有规划、有步骤推进任务的过程。

与此同时，社区还存在其他框架，例如 BMAD-METHOD。这种框架涉及多种角色，包括产品经理、设计师以及 Scrum Master，他们共同规划项目目标。Scrum Master 负责用户故事的切片，随后进入敏捷循环开发、验证和交付等环节，多个 Agent 协同完成整个项目。

在工作区隔离方面，常见的做法是让 Agent 在本地工作，例如使用 Claude Code 处理本地事务。通常有两种隔离方式：容器隔离和 Git Worktree 方式。我更推荐后者，因为它更轻量级，且是 Git 自带的功能，可以直接在你的工作目录下使用。

最后是验收环节，验收方式主要有两种：自动化验收和人工验收。我们尽可能实现自动化验收，但自动化验收需要逻辑清晰，例如编写和运行单元测试、编译或格式检查等，这些通常适用于明确的编程和数学场景。然而，人工验收有时是不可避免的。人工验收涉及多个方面，包括你在该行业的专业知识水平、审美能力以及对用户体验的感知能力等。这些都有一定的要求。因此，在验收层面，我们应尽可能实现自动化，同时通过人工验收来兜底。

我曾遇到一个例子，当时我在编写一个 MCP 多节点传输功能。那时的 AI 还不理解 MCP 是什么，生成的代码无法运行。如果我不了解背后的原理，就无法完成这个任务。因为如果 AI 生成的代码无法运行，而我对这个领域一无所知，就会陷入死循环，项目也就无法继续。这在一定程度上反映了，如果没有专业知识，我们无法让 AI 输出我们想要的结果。后来，我通过阅读文档、理解原理，再反过来告诉 AI 应该如何设计和实现，最终才成功生成了可以运行的代码。

这让我得出一个结论：虽然大家都在使用 Claude 等 AI 工具，但不同人使用的结果却千差万别。这背后的原因在于我们对行业的认知、专业知识以及个人经验的差异。例如，我之前举办的一些 Vibe Code 沙龙活动中，让大家开发一个待办管理应用。那些没有任何技术背景的人，生成的应用可能只能达到 50～60 分，勉强可用。而有产品经理经验的人，能够清晰表达产品需求，生成的应用效果则大不相同；技术人员则会指定技术栈，提出具体的技术要求，他们的应用可能会更深入、更完善。

我很喜欢米开朗基罗的一个比喻：每块大理石里都藏着一件作品，雕刻师只是将它找出来。在实践中，我感觉 AI 就像人类知识的压缩器或浓缩器，它本身蕴含着丰富的知识。关键在于我们这些使用者，如何通过语言这个“刻刀”去雕琢它，让它将已知的知识或能力精确地输出给我们。

行业影响————软件世界的"板块漂移"

无论是 Vibe Coding 还是 Vibe Working，AI 对我们行业的冲击是显著且深远的。AI 的出现让整个市场进入了一个增量的过程。这种增量并非凭空产生，而是源于原本就存在的需求。过去，许多需求因为技术门槛过高而被压抑。例如，一些个人想要开发个性化的小工具，但由于不会编程，也没有足够的资金聘请开发者，这些需求一直未能得到满足。然而，AI 的出现打破了这一局面，它降低了技术门槛，使得这些被压抑的需求得以释放。

这种需求的释放也带来了矛盾。尽管市场需求在增加，但与之相对应的工作岗位却可能在收缩。这是因为 AI 能够高效地完成许多任务，原本需要人力完成的工作现在被 AI 所取代。这种现象导致了人才结构的变化。未来，我们会看到大量非专业人士，甚至可以说是“小白”，借助通用的 AI 能力满足中小规模的需求，这将成为市场的主流。而在顶端，会有少数专业人士结合 AI 的力量，处理更复杂、更高端的任务。无论在哪一层，AI 都将发挥重要作用。

这种变化意味着中间部分的人才将面临分流。一部分人可能会努力提升自己，进入顶端的专业领域；而大部分人可能会下沉，与普通“小白”处于同一水平。这实际上是对行业格局的一次重新洗牌。在数字化行业尤其如此，未来人和组织都将朝着 AI Native 的方向发展，即人们会习惯于在工作中依赖 AI，这样才能适应未来的趋势。如果仍然单靠个人力量，不借助 AI，很快就会被时代抛弃。组织也是如此，传统的组织架构将逐渐转变为扁平化且 AI Native 的模式。未来，这将是一个超级个体崛起的时代。

演讲嘉宾介绍

揭光发（Jeff）是腾讯云架构师联盟社群管理主席，腾讯专家工程师。

20 年研发与团队管理经验，前腾讯云 TVP，现腾讯全栈技术专家，公司级低代项目负责人，是 IEEE 低代码标准及大湾区企业低代码标准的主撰写人；大模型应用早期实践者与布道师，是国内顶级行业 / 技术峰会相关话題优秀讲师及出品人。在低代码与 LLM 结合场景有深度的实践，愿景是“人人能编程”。带领团队深度践行 LLM 对研发提效、探索 Vibe Coding 在专业程序员与准开发者群体的落地，个人代码全栈 AI 含量几近 100%。

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：揭光发，编辑：Kitty，36氪经授权发布。