AI 演示智能体，该用氛围编程自己做吗？

能用氛围编程（vibe coding）自己做一个 AI 演示智能体吗？能，一个周末就能做出一个能跑的版本。但要让它每天在您真实的产品上，面对真实的买家，那就是另一个项目了。而您的销售管线，靠的正是这第二个项目。

下面是第二个项目包含的工作，以及每一部分的难度：

考量因素	需要做什么	难度
操控您的线上产品	登录、验证器验证码、机器人防护，以及在界面改版后依然可用的流程	极难
延迟	在约一秒内完成聆听、思考、说话和点击	极难
语音技术	自然的嗓音、话轮转换、打断、口音和噪音	困难
沙盒	逼真的演示数据，每次会话后自动重置，并与您的产品保持同步	困难
提示词与护栏	始终紧扣核心信息，绝不编造价格、功能或安全声明	困难
评估	为对话打分，并在每次调整提示词或更换模型后发现效果倒退	困难
CRM 与销售管线对接	线索采集、信息补全、HubSpot 或 Salesforce 同步，以及后续跟进	中等
维护	每次产品发版和模型更换后，把以上各项全部重新检查一遍	永无止境

在评估 Karumi 的团队那里，我们经常听到这句话：“我们团队随便找个人用氛围编程就能做出来。”这种想法可以理解。如今的编程智能体已经非常强大。把大模型接上无头浏览器，再加一个语音 API，指向您的应用，到周日晚上，就有个东西能开口说话、在您的产品里点来点去了。

我们也见过这件事最后的走向。那些自建的团队，在发现这套系统搭建和运维有多难、多贵之后，又回来找了我们。本文讲的，就是原型跑通之后他们遇到的问题。

氛围编程做出的演示智能体，做对了什么？

核心循环如今确实很简单。大模型能读懂页面、决定点击什么，并解释它看到的内容。语音 API 能让它开口说话。编程智能体几个小时就能把这些全部搭好。

用来做内部演示，这已经够了。但面对买家还远远不够，因为原型只需要成功一次，而且是在一个盼着它成功的人面前。

	周末原型	面向买家的智能体
受众	为它喝彩的自己团队	心存疑虑、一出故障就离开的买家
产品状态	笔记本电脑上一个已登录的会话	成千上万个会话，各有各的登录、数据和时序
对话内容	顺风顺水的常规问题	价格、竞品、安全，以及“它能做 X 吗？”
出故障时	一笑了之	丢掉一笔交易，留下糟糕的第一印象
使用周期	一场演示	每一天，经历每一次发版
负责人	周六动手做它的那个人	需要一位长期负责人

这两列之间的差距，才是真正的项目。而演示恰恰是生产环境中最不能出错的地方：它一旦出问题，就是在您最想打动的买家面前出问题。

要运行一个演示智能体，您需要精通什么？

生产级演示智能体不是一项技术，而是至少四项，每一项都是独立的专业领域：

• 语音技术。语音转文字、文字转语音、话轮转换、打断、口音和背景噪音。让声音听起来自然，并且知道买家什么时候说完了，这本身就是一门学问。
• 沙盒。一份带有逼真数据的产品副本，每次会话后自动重置，与您发布的版本保持同步，并且绝不暴露任何真实客户。
• 提示词。一套指令，让智能体在成千上万场从未见过的对话中，始终紧扣核心信息、聚焦您的产品，并守在护栏之内。
• 评估。一套为对话打分、发现效果倒退的方法，让您确认每次调整提示词或更换模型都是让效果变好，而不是变差。

此外还有贯穿这四项的延迟。在语音对话中，停顿超过一秒左右就会让人觉得出了故障，而智能体必须在这点时间内完成聆听、思考、说话，并在线上产品中完成点击。要把延迟压下来，就得让每个环节都流式处理，选模型时既看质量也看速度，还要在买家开口之前预加载页面。延迟至关重要，也是最难做好的部分之一。

为什么操控线上产品才是最难的部分？

我们自己的大部分工程时间都花在这里，而不是对话上。要展示您真实的产品而不是一段录屏，就必须解决下面所有问题：

• 处处设卡的登录。SSO、先输邮箱的登录页、魔法链接、验证器验证码，以及演示到一半就过期的会话。失败往往看起来像成功：智能体以为自己已经登录，其实还停在登录页上。
• 机器人防护。Cloudflare、Akamai 等工具的存在，就是为了拦截自动化浏览器。如果频繁用脚本访问您自己的应用，您的演示账号可能会被锁定。
• 安全的演示数据。买家不应该看到真实的客户记录，也不应该把共享账号搞坏。您需要一个看起来真实、能干净重置、并且绝不触碰生产环境的沙盒。
• 不断变化的界面。每次发版都会挪动按钮、重命名页面。写死的点击路径会悄无声息地失效，所以您需要检查机制，在买家发现之前先发现流程坏了。
• 速度。每个页面都要等八秒的演示，会让人觉得出了故障。预加载、缓存，以及让讲解与页面加载在时间上衔接，每一项都是一份单独的工作。
• 打断。真实的买家会插话说“等等，退回去”。智能体必须停下来、回答问题，再从刚才中断的地方继续。

这些问题在原型视频里一个都看不到，却会在买家面前全部暴露出来。

要让对话值得信赖，需要做些什么？

演示智能体代表的是您的品牌。一个当着买家的面胡编您产品信息的智能体，比没有智能体危害更大。让它保持可信，是一项持续的工作：

• 有据可依的回答。它应该基于您的文档、客户案例和产品定位来回答，遇到价格或产品路线图这类问题时转交给您的团队，而不是乱猜。
• 护栏。关于竞品、折扣、法律或安全声明的问题，以及各种越狱尝试，都需要有意识地妥善处理。
• 自然的语音。低延迟、应对打断和沉默，讲解内容与屏幕画面保持同步。
• 多语言。如果您在多个市场销售，每一段脚本、每一个流程、每一条回答都必须在每种语言下正常运作。
• 复盘。每周都得有人阅读对话、打分并修正薄弱的回答。否则质量会悄悄下滑，而且没人察觉。
• 安全问题。您的安全团队会问：对话记录存放在哪里？哪些模型提供商能看到它们？您需要在他们开口之前就准备好答案。

智能体不就是产品的全部吗？

不是。演示智能体的价值在于它能为您的销售管线带来什么，而自建的机器人通常止步于对话本身。销售和营销团队需要的是围绕对话的一整套能力：

• 按营销活动区分的入口，让 LinkedIn、线下活动、官网和外呼拓客各有专属的链接、开场白和起始流程，您也能看出哪个渠道最有效。
• 线索采集与信息补全：访客是谁、来自哪家公司、是否符合您的 ICP。
• 对接您的技术栈：合格的会话连同摘要自动进入 HubSpot 或 Salesforce，对应的销售代表会收到通知，跟进邮件也会自动发出。
• 洞察：买家问得最多的问题、他们在哪里流失，以及会提出哪些异议。
• 无代码编辑，让营销人员和售前工程师无需提工单，就能修改脚本和流程。

每一项本身都是一个小产品。如果全部自己开发，您的演示机器人就会变成一个有自己路线图的内部平台。

自建的真实成本是多少？

氛围编程让第一个版本几乎零成本。但接下来的一百个版本并不免费，成本恰恰就在这里。

• 每次产品更新，都是一次演示更新。每次发版都可能挪动按钮、重命名页面或改变流程。每次您发布新版本，都得有人重新检查各条演示路径、刷新沙盒、更新脚本并重跑评估。
• 必须有人对它负责。当做它的人回到核心产品上，或者离职，机器人就会悄无声息地坏掉。没人完全看得懂的生成代码，很难交接。
• 底层技术栈一直在变。大模型、语音和浏览器自动化供应商每隔几个月就会更换模型、调整价格和 API。每次变化都意味着又一轮测试，而且往往需要重写。
• 它会挤占您的产品路线图。花在演示机器人上的每一周工程时间，都是没花在您真正销售的产品上的一周。
• 见效周期。一个能跑的内部版本，通常还要再过好几个月，才能放心地展示给买家。而当初让这个项目立项的销售管线，在此期间只能干等。

所以，客观的比较不是订阅费对比一个周末的编码，而是订阅费对比一支无限期投入的兼职工程团队，再加上开发期间丢掉的那些交易。

什么情况下自建才合理？

只有以下三点同时成立时，自建才是正确的选择：

1. AI 演示智能体是您所售产品的核心，而不是用来销售其他产品的渠道。
2. 您能为它长期配备专门的团队，而不只是投入一个冲刺周期。
3. 您可以接受等上好几个月，买家才能看到它。

如果不是这样，您的团队用氛围编程能做出的最有价值的东西，是一个体现需求的原型。把这份需求清单交给一个已经搞定登录、沙盒、护栏、语音、数据分析和 CRM 对接的平台，再把工程时间花在您自己的产品上。

这正是 Karumi 在做的事。智能体通过自主探索来学习您的产品，在与买家对话的同时实时操控产品，并把每一场会话同步到您的 CRM。大多数团队两周内即可上线，维护工作由我们承担。

常见问题

我们能不能先做个原型，以后再切换？

可以，原型是梳理需求的好办法。只是要为切换预留预算：原型之后的工作才是大部分成本所在，而看过一次故障演示的买家，不会再回来看第二次。

如果我们的产品每周都在变呢？

这正是反对写死流程最有力的理由。Karumi 会随着产品变化重新学习您的产品，所以页面改了名、按钮换了位置，演示也不会因此中断。

如果不自建，我们会失去控制权吗？

不会。脚本由您的团队编写，流程由您挑选，护栏由您设定。您交出去的只是基础设施：浏览器、登录、语音、沙盒和各类集成。

怎样公平地比较这两种方案？

挑一个买家最关心的核心流程，让两者在上面跑一周：您的原型和一个 Karumi 智能体，回答同样的问题。统计每一方有多少次能顺利完成演示、不出故障。