“AI是未来的新生产力，但现在还是差点意思。”

我们看到越来越多的AI Coding产品，但不管是企业高管、还是我们评论区的开发大佬，近期都不约而同的抛出了一个业内真相：

“我们确实在用AI写代码，但速度并没有更快。”“我们只是写出了更多代码，却没能更快交付！”

一周前，一家知名智能体平台公司CEO毫不掩饰地揭露出这一点。“AI参与代码生成没问题，但AI交付代码，没人敢这么干！”

近期，大洋彼岸也被AI带火了一个“WorkSlop”（工作糊料）的词汇，表达的也是这个意思。

“问题在于：更多的代码并不意味着你能更快测试、更快部署、更好地保障安全或合规。代码写出来之后，还有一整套需要完成的工作。”

Harness 联创兼CEO Jyoti Bansal 表示，“问题在于：更多的代码并不意味着你能更快测试、更快部署、更好地保障安全或合规。代码写出来之后，还有一整套需要完成的工作。”

越来越多企业开始意识到，用AI来“写更多代码”并不一定能加快交付速度。所有这些代码仍然需要经过测试与集成，而这些环节往往成为新的瓶颈。

所以，单纯靠AICoding工具显然是不明智的。Jyoti 认为，其实大部分开发者时间，都浪费在让代码可上线的环节，在这个环节大有机会和文章可做。

在采访中，Harness畅快聊起了自己如何在“交付环节”这个真正的开发瓶颈上持续多年的尝试。

这家公司成立于2017年，早期采用了机器学习的方法，当2022年ChatGPT爆火之后，他们自然而然把GenAI的能力内嵌到了产品之中。

当我们开始探索生成式 AI 时，第一步是用 LLM 简化配置，比如自动生成流水线、自动修复安全漏洞。这是早期的应用场景。

后来我们发现，很多问题其实更适合用 AI Agent 来解决。于是我们构建了一套基于智能体的系统——现在用户使用 Harness 时，其实是在和一组 AI 智能体打交道。我们叫它 Harness AI。

这个系统由十几个顶层智能体组成，分别服务于开发、测试、安全、SRE 等任务。每个大智能体下面还有很多专门执行小任务的子智能体。

他还跟团队强调，关键是解决问题，而非是必须使用什么技术。

比如，如果一个 AI 模型要 30 秒才能给出结论，而你写个规则只要 1 秒，那用户显然更愿意等 1 秒。“所以我们要判断哪种方法最适合：有时先用 AI 探出最优方案，再固化成确定规则，这样效率更高。AI 不是目的，它是达成目标的手段。”

此外，他也同意，目前生成式AI市场处于泡沫之中。作为活跃的创业投资人，但他对AI泡沫的态度却相对乐观。

“AI领域确实很‘泡’，但泡沫不一定是坏事。它往往出现在颠覆性技术爆发期——人们以为两年能从1做到100，结果五年才做到。但从1到100依然是巨大的飞跃。”

他以互联网泡沫为例：当年虽有崩盘，但也孕育了幸存的巨头。如今AI公司众多，最终只有少数会存活。

“这正是生态的正常演化方式。最终会有赢家，也会有老牌企业吸收创新成果。所有这些都在合理地发生，只是进展可能比预期更快。”

还有一个小插曲，Bansal 曾是上一家初创公司 AppDynamics 的主要代码编写者（后被思科以37亿美元收购）。

尽管他中途多年不再写代码，但借助AI工具，如今他又重新开始编程。

“我又开始‘危险’起来了，”他笑称。AI让他在产品管理与需求文档编写上也大幅提速。

但他并不认为AI会取代人类开发者或产品经理：

“AI改变的是节奏。竞争压力更大，以前开发新功能或进入新市场可能需要一年，如今缩短到六个月。

生产力提升后，你会少雇人吗？目前我看到的更多是——人没减少，但大家做的事情更多了。”

ok，料还很多，小编为大家整理了原汁原味的对话内容。希望对大家有所帮助和启发。

AI不是目的，解决问题最关键

主持人：这些年我们已经聊过好几次了，对吧？

Jyoti Bansal：是啊，我也记得。

主持人：我印象最早一次是你刚提醒我的——在温哥华，大概是 2017 或 2018 年。

Jyoti Bansal：我记得更可能是 2018 年。

主持人：对，我记得那次你航班延误，我还拿这事调侃你。当时你刚以 37 亿美元卖掉 AppDynamics，却还得在机场等加拿大航空的航班。

Jyoti Bansal：（笑）对对对，没错没错。

主持人：现在你该能坐头等舱了吧？

Jyoti Bansal：（笑）是的，是的。

主持人：好，回到今天。其实我特别想请你来聊聊软件交付这件事。现在几乎所有人都在用各种 AI 工具写代码，但我觉得真正的瓶颈还是在交付环节，也就是 delivery pipeline。所以我们一会儿重点谈这个。不过在那之前，我想先问，Harness 现在也已经七八年了吧？在最初创办时，你有考虑过 AI 吗？当时的机器学习、深度学习已经开始流行，但生成式 AI 应该还没出现在视野里吧？

对，那时候当然还没有 LLM 或生成式 AI。不过有趣的是，Harness 从一开始就和 AI 有关。我们在 2017 年发布产品时，新闻稿标题就是「Harness 将人工智能引入持续交付（Continuous Delivery）」。那是 2017 年底。

之所以这么说，是因为我们的持续交付产品核心就是用 AI 来判断某次部署是否可能出错。当时的 AI 还不是语言模型，而是基于神经网络和机器学习的模型。我们一直在这方面探索。后来我们推出 CI（持续集成）时，也用了一个叫 “Test Intelligence” 的 AI 模型，通过分析代码变更来决定需要跑哪些测试，从而把构建速度提升四五倍。

所以其实在 LLM 之前，我们就已经在用 AI 优化软件工程和交付流程了。人们有时候会忘记这一点——AI 在软件开发领域的应用，并不是从 LLM 才开始的。当然，现在我们进入了一个百倍、千倍加速的新时代，但那只是延续，不是起点。

主持人：确实，有时候我们面对的一些问题，用传统机器学习也能很好解决。但现在很多公司反而强行往生成式 AI 上靠。

Jyoti Bansal：没错。我一直和团队强调一点——关键是解决问题，而不是非得用什么技术。有些问题用智能体（agent）最合适，有些则用规则引擎或者传统 ML 模型。有些问题甚至靠确定性自动化更高效。比如，如果一个 AI 模型要 30 秒才能给出结论，而你写个规则只要 1 秒，那用户显然更愿意等 1 秒。所以我们要判断哪种方法最适合：有时先用 AI 探出最优方案，再固化成确定规则，这样效率更高。AI 不是目的，它是达成目标的手段。

主持人：对，AI 还没到“万物终点”那一步。

Jyoti Bansal：（笑）那是另一个话题了。

团队70%的时间都耗在外环上

主持人：那你们在什么时候决定真正引入生成式 AI？当时的考量是什么？

Jyoti Bansal：我先解释一下我们看待软件工程问题空间的方式。我们把它分成两个环节：内环（inner loop）和外环（outer loop）。内环是开发者在本地写代码的过程；外环则是代码写完之后，从提交到上线的整个交付过程。

很多人以为软件开发主要花在写代码上，但其实大部分工程团队有 60%-70% 的时间都耗在外环上。为什么？因为交付环节涉及大量工作：各种测试（集成、负载、API）、安全扫描、开源库检查、合规审批、部署、数据库变更、基础设施配置、功能灰度发布、回滚、成本优化等等。

这大概有三十多种工作流，也正因此流程非常慢。Harness 的目标就是——能不能重新想象整个交付过程，让开发者更少重复劳动、更自动化。从最初的持续交付（CD），到持续集成（CI）、再到特性开关（Feature Flags），我们现在平台上有 16 个模块在解决这些问题。

当我们开始探索生成式 AI 时，第一步是用 LLM 简化配置，比如自动生成流水线、自动修复安全漏洞。这是早期的应用场景。

后来我们发现，很多问题其实更适合用 AI Agent 来解决。于是我们构建了一套基于智能体的系统——现在用户使用 Harness 时，其实是在和一组 AI 智能体打交道。我们叫它 Harness AI。

Jyoti Bansal：这个系统由十几个顶层智能体组成，分别服务于开发、测试、安全、SRE 等任务。每个大智能体下面还有很多专门执行小任务的子智能体。比如当用户让系统「帮我创建一个应用的部署流水线」时，AI 会先了解：你公司的安全标准是什么？合规要求是什么？生产环境架构如何？

为了做到这一点，我们还会为每个客户生成一个知识图谱（knowledge graph），包含他们的服务依赖关系、安全工具、SLA 要求等。各个智能体在执行任务时会从这个知识图谱里提取恰当的上下文。因为你不能让一个大模型一次性处理所有上下文，那样效率太低。必须拆成多个小智能体，让它们在合适的时间获得合适的信息。

这就是我们今天的 AI 架构——一组面向具体任务的智能体，配合客户的知识图谱和上下文，共同完成交付流程中的各个环节。

智能体落地生产环境前，要让客户先信任它

主持人：这里面有几个很有意思的点。首先，你提到现在很多用户其实是通过智能体来使用 Harness 的。那你们是怎么让客户接受这种全新交互方式的？毕竟他们以前习惯了传统的工具模式，现在还得学会“信任智能体”。

Jyoti Bansal：这是个非常现实的问题。我们做的第一件事就是让客户清楚地知道：这些智能体到底在做什么。现在我们的智能体不会直接操作生产环境，而是帮你创建生产部署的流水线。

这条流水线是确定性的、可审计的——每个步骤都可以被人工复查，满足安全和合规要求。换句话说，AI 不会直接动你的生产系统。坦白讲，很多客户也暂时不会愿意让它那样做，这是合理的。

所以我们给 AI 定义的角色是——助手。它帮你创建、优化、修复流程，而不是替你直接执行。比如部署失败时，AI 会帮你快速定位问题：可能是配置错了、代码有 bug、或者版本冲突。AI 能加快诊断、减少重复劳动。

通过这种“人类在环（human-in-the-loop）”的方式，我们让客户既能享受到自动化带来的效率，又能保留控制与审查的权力。

AI参与代码生成，OK，AI交付代码？对不起

主持人：对吧？我们现在依然保留那些确定性的工具，如果我想修改某个视频内容，依然能做到。

Jyoti Bansal：是的。你知道，现在整个行业其实还没完全做好心理准备。我们现在合作的对象中，有全球前十银行里的七家。没错，他们确实在用 AI 做代码生成。

但你要看到一个关键区别——AI 写代码这件事，哪怕准确率是 95%，甚至未来能到 99%，都可以接受。

可如果 AI 参与的是“代码交付”——也就是把代码推送到生产环境——那就完全不同了。因为，一行错误的代码，就可能让整个系统瘫痪。

你看最近的 CrowdStrike 事件，就是一个例子。全世界的系统因为一行 bug 宕机。所以在这个环节，你没有犯错的余地。

这也正是为什么，软件交付过程里会有那么多检查、验证和流程。

这些流程是为了确保每一步都是确定性的、有人工审批的、符合监管标准的。监管机构会要求企业证明自己具备相应的流程，以避免那“一两行代码”引发生产事故。

优先开发哪些场景的智能体？

主持人：是的，完全理解。那么你们在决定优先开发哪些智能体时，是怎么排序的？因为我刚刚在记你们产品里提到的那些智能体，记到一半就记不下去了（笑）。那你们是怎么确定哪些要先做、哪些后做的？

Jyoti Bansal：我们会从用户面临的最核心、最迫切的问题开始。首先，排名第一的当然是流水线（pipeline）的搭建。要实现端到端自动化的交付流水线非常复杂。

你可以想象一下，如果你是一家大型银行或科技公司，从开发者写完代码到代码上线生产，要经历各种自动化测试、审批和安全校验——这整个 CI/CD 流程非常复杂。而这正是 Harness 一直以来的核心优势所在。

所以我们的第一批智能体，重点都是围绕这一流程设计的，目标是帮企业系统化、自动化地创建这些流水线。

而这些智能体并不好做，因为每个企业都有不同的安全策略、治理规则和合规要求。我们必须让智能体学会理解这些企业特有的上下文，才能生成正确的流水线方案。所以这部分是我们优先投入的第一方向。

第二个重点领域是“测试”。开发者现在生成代码的速度远快于测试的速度。虽然生成式 AI 能帮你写一些测试，但那远远不够。

我们看到开发团队迫切需要的是更高效、更智能的测试体系——包括健壮性测试、端到端测试、单元测试、混沌测试等等。

AI 智能体能在这些领域显著提升效率。

第三个重点方向是“安全”。随着 AI 写代码越来越多，安全漏洞也随之激增。代码安全、应用安全变成了开发交付中的痛点。我们正在通过 AI 智能体来帮助自动检测、优先排序、甚至修复漏洞。比如，它能判断哪些漏洞是真正可触达的、哪些是虚假警报，避免开发者被大量噪音淹没。

这三个领域——流水线、测试、安全——是我们现在看到最具即时价值的 AI 应用场景。

主持人：明白。刚才你提到应用安全，你们前段时间收购了一家公司，我忘了名字的读音，好像是……Quiet？

Jyoti Bansal：对，很多人都知道它之前叫 ShiftLeft，后来改名叫 Qwiet（读音接近“quiet”），大概是两年前改的。

主持人：因为那几年大家都在说要“shift left”（左移安全），对吧（笑）？那你们为什么决定要收购它？毕竟你们过去大多数产品都是自研的，只有偶尔才会并购。你们当时是怎么做这个决定的？

Jyoti Bansal：主要原因在于：应用安全领域的问题已经发生了根本转变。过去的重点是“发现漏洞”——只要能扫描出漏洞就算合格。但现在，最大的痛点变成了“管理漏洞”。

许多企业现在面临的困境是：漏洞太多，工具太多，噪音太大。比如，一个安全扫描器可能会告诉你有 500 个漏洞，但其实只有不到 10% 是真正需要处理的。

原因很简单：假设你引用了一个开源库，这个库有 100 个功能，而你只用其中 2 个。安全扫描器依然会报告那剩下 98 个你根本不会触及的漏洞。于是工程团队被淹没在无意义的漏洞警报中。

Qwiet（原 ShiftLeft）在解决这个问题上有非常强的技术优势。他们开发了一个叫“Code Property Graph”的技术，可以分析代码的可达性关系，也就是“哪段代码能真正被执行、哪些漏洞是可被利用的”。

这样我们就能判断哪些漏洞是真实可达、必须优先修复的，哪些可以忽略。

现在我们正把这项技术整合进 Harness 的 AI 系统里，让 AI 智能体能自动检测、排序、甚至修复高风险漏洞，把安全工作从“应付噪音”变成“聚焦关键风险”。

为什么要做统一智能体

主持人：明白。那么现在你们的客户已经能使用这么多智能体，那用户体验现在是什么样的？他们需要分别和不同的智能体交互吗？还是会统一在一个界面里？实际使用时是怎样的？

Jyoti Bansal：这是个很好的问题。其实在实际使用中，用户并不会直接看到这些不同的智能体。他们看到的只是一个统一的界面——Harness AI。我们称之为“统一智能体（unified agent）”，因为它把所有功能性的智能体都整合在一起。

未来，越来越多用户会直接从这个统一界面开始，就像你打开 ChatGPT 一样。不同的是，我们会主动给出一些“可能的任务建议”，基于我们对用户行为的理解，比如他们最常做哪些操作、最关注哪些环节。

AI 的一个关键能力在于“记忆”。Harness AI 会根据每个用户的行为模式进行学习。比如，它会发现某个用户主要在处理生产环境的部署流水线，那系统就能推测出，他接下来最有可能执行的任务是什么。

于是我们会提前推荐这些操作，甚至不需要用户自己输入提示词。他们只要点一下，就能执行。

再比如，如果系统发现某个用户每次登录都在做成本优化，那下次打开界面时，我们就直接建议相关任务入口。这样，整个体验就变得非常简洁自然。

对用户来说，这就是一个“单一的 Harness AI”。至于它背后如何把任务分配给不同智能体、再由子智能体完成协作，这些全都是内部细节，用户无需感知。

主持人：明白了，也就是说未来用户甚至能自己创建自主型智能体？

Jyoti Bansal：没错。我们正在推出这样的功能，用户可以自己创建一个自主智能体来完成特定任务。比如，你可以让它自动把代码库从某个依赖库的 1.7 版本升级到 2.0，智能体会在后台执行相关任务——验证所有测试是否通过、检查 CI/CD 流水线是否正常，并在确认一切无误后完成升级。这类能力正在逐步开放给用户。

主持人：那这样一来，你们的系统其实也会直接触达用户的代码，对吧？

Jyoti Bansal：是的，确实如此。这也是最有意思的地方之一。

AI转型带来的技术栈变化：AI重构软件交付智能体驱动工作流自动化

主持人：我还挺好奇的——像你们这样的公司，在这几年 AI 转型的过程中，技术栈和团队能力结构上发生了什么变化？

Jyoti Bansal：这个变化确实很大。其实早在 2017 年 Harness 创立之初，我们就开始在做 AI 和机器学习相关的工作，所以公司内部一直有比较强的数据和 AI 基础架构能力。这也让我们比很多开发者工具公司更早意识到，可以通过 AI/ML 来解决开发与交付中的问题。

Jyoti Bansal：不过，现在我们确实进入了一个“AI 优先（AI-first）”阶段。有趣的是，我们发现几乎所有优秀工程师，都有潜力成为“AI 工程师”。写智能体代码，和写传统软件代码的技能本质上是相通的。人们乐于学习这种新方式。

Jyoti Bansal：当然，我们仍然需要一些特定的基础能力。比如，必须有非常扎实的数据基础设施，还需要懂模型原理的数据科学家。但我们并不自己训练基础模型。我们建立在 Anthropic、OpenAI、Gemini 等平台之上。我们的重点是“在应用层构建智能体”，让这些智能体具备深厚的领域知识，能理解上下文、解决真实的开发交付问题。

所以我们的工程文化也在经历转型。现在整个团队都在向“AI-first”的思维方式转变——用 AI 重构软件交付过程，用智能体驱动工作流自动化。可以说，我们的工程团队已经很好地完成了这种转变。

按人头收费，按Token量收费？

主持人：AI-first 不仅是技术方向的转变，对商业模式来说也意味着新的挑战。现在几乎所有 AI 模型都是基于“按量计费”（consumption-based），模型调用越多，花费越高。你们在运行这些模型时成本也不低吧？怎么平衡这种变化？

Jyoti Bansal：这是个很现实的问题。其实对我们来说，这种转变相对自然。Harness 从创立开始就是一个“按使用量计费”的平台，我们的主要定价逻辑从来不是“按人头（seat-based）”收钱。

我们的产品是一个模块化平台，现在大概有 16 到 17 个模块，覆盖代码部署、CI/CD、特性开关、可观测性、安全测试等多个领域。客户可以按需选择要用的模块，然后根据实际使用量计费。这套逻辑本身就和“消费导向”的模式天然契合。

举例来说，部署模块的计费逻辑是：你部署了多少个服务；成本优化模块看的是：你通过我们节省了多少云成本；特性管理模块则根据你运行的实验数量计费。

所以我们早就不是“按用户数收费”的模式，而是“按消耗计费”的模式。

现在加入 AI 后，我们的定价仍然保持一致：

AI 成本已经内嵌在这些模块的使用计费里，不会单独收取“AI 版本”的额外费用。有些厂商会推出“非 AI 版”和“AI 加强版”，价格不同；但我们不希望团队在体验层面人为区分“有 AI”和“无 AI”。我们希望 AI 成为体验中无缝的一部分。

比如，持续交付模块过去是按部署量计费，现在我们在其中内嵌了智能体功能，但价格结构并没有因为 AI 而拆分成两种版本。

我们认为，AI 是交付体验的自然组成部分，不需要额外标签。

写更多代码，不等于更快上线！

主持人：明白，这样你们也不用维护两套产品逻辑（AI 与非 AI），不然确实会变得复杂。那现在的客户在使用这些智能体时，有什么出乎意料的地方吗？

Jyoti Bansal：最大的惊喜来自企业客户的“主动性”。我们开放了基于 MCP的接口，让企业能将 Harness 的 AI 智能体接入他们自己的系统。

令人意外的是，连那些传统印象中“行动缓慢”的大型企业，都在迅速采用这种集成方式。

比如，我们有一家全球最大的航空公司客户，他们基于 Harness 的 AI 打造了自己的内部工具链，让所有工程师都能通过统一界面操作各种任务，从部署到优化全部整合在一起。我们看到很多类似的创造性用法，企业正在用 AI 重塑软件工程流程。

这其实反映了一个更深层的趋势。过去大家都在热衷“AI 写代码”，但后来发现——写更多代码，并不等于更快上线。因为测试、部署、安全和合规等环节仍然滞后。于是企业开始意识到，真正的突破不在“生成代码”，而在“交付代码”。他们现在用 AI 去解决这部分的问题。

MCP究竟好在哪里

主持人：为什么这股采用 MCP 的浪潮会来得这么快？十个月前几乎没人提这个协议。

Jyoti Bansal：我认为原因很简单：灵活性。MCP 本质上是“新一代 API”。过去人们通过传统 API 集成系统；现在，MCP 提供了一种更智能的方式去“传递上下文”。

MCP 允许你把外部智能体无缝接入自己的工作流，并在上下文中共享信息和任务。以前企业会自建一个开发者门户，让工程师集中操作各种工具；现在，这个门户就是他们的“AI 界面”，MCP 则成为它的集成底座。

主持人：那这对 Backstage（开发者门户平台）意味着什么？

Jyoti Bansal：Backstage 依然很重要。事实上，我们是企业级 Backstage 最大的服务提供商之一。

我们有一个专门的 IDP 模块，就是基于 Backstage 搭建的，帮助企业快速落地，不用花一两年时间自建。

更有意思的是，我们现在在 Backstage 上叠加了 AI 能力。比如我们新推出的“知识智能体（Knowledge Agent）”，它能通过 Backstage 的服务目录回答问题，查询服务、环境、基础设施等信息，还能帮助新开发者自动化上手流程。

40%以上的代码是AI生成

主持人：明白，那我好奇——你们现在内部写代码时，AI 的使用比例大概有多高？

Jyoti Bansal：几乎所有开发者都在用 AI。目前大概有 90% 到 95% 的工程师每天都依赖 AI 编码。我们内部甚至讨论过是否要把“使用 AI 编码”设为默认要求（笑）。

有三四十位工程师是 AI 的“重度用户”，他们熟练使用 Cursor、Windsurf 等工具，效率极高。我们做过一次内部评估，现在大约 40% 以上的代码是通过 AI 生成或辅助生成的。我相信这个比例未来还会继续上升。

如何用好AI Coding工具？这点两点最重要

主持人：那么，你认为在使用这些工具时，什么能让开发者特别高效？你在观察到哪些特征？有哪些最佳实践是你从优秀开发者身上学到的？

Jyoti Bansal：这是个很好的问题。我们其实一直在研究这个——为什么有些开发者的效率特别高？后来我们就安排他们做一些“午餐学习会”，让他们分享：你为什么比别人更高效？

总体来看，现在大家都在逐渐摸索怎么更高效使用 AI。这已经不再像一年前那样，优秀开发者和普通开发者之间的差距那么大了，整体水平在提升。

不过，最关键的一个点是“配置”。花一点时间去设置规则、定义 Markdown 模板、明确参数。比如，你让编码智能体帮你写代码，但如果你不给它任何参数或上下文，来回沟通就会很慢。

相反，如果你花几个小时写清楚代码风格、公司内部规范、设计约束，这样 AI 生成的代码质量会更高，来回修改的次数也会更少。这可以算是我认为最值得推广的最佳实践之一。

还有一点很重要：任务拆解能力。很多人以为可以把一个大任务丢给 AI，但实际上 AI 更擅长处理被拆成 5 到 10 个小任务的工作。优秀的工程师其实正在进化成“任务拆解者”——他们懂得怎么分解问题、设定好每个任务的边界和参数，然后审查输出。

在 Harness，我们自己的工具链也让开发效率非常高。我们通过自研工具优化交付流程，从部署、构建、测试到安全和治理，几乎都自动化了。

我们相信，编码环节用 AI 提效是一面，交付环节用 AI 优化是另一面。我们在两端都在用 AI。

有了AI，人并没有变得更轻松

主持人：老实说，如果你们自己不用 AI，我反而会失望（笑）。那现在你自己还写代码吗？

Jyoti Bansal：哈哈，有一点。我之前确实很久没写代码了。在我创办第一家公司时，我写了大概一半的产品代码，因为团队太小。后来在 Harness 我基本没怎么写。但现在有了 AI，我又开始“危险地动手”了（笑）。不过我更多是在用 AI 帮我做产品管理和规格文档。

以前写一份产品规格要花我很多时间，我会跟产品经理沟通，来回几周才能定稿。现在我直接用 AI 花一个小时就能做出一个结构清晰的初稿，再交给团队完善。整个过程从原本的三四周缩短到一两天。对我来说，这种在产品文档上的效率提升是最明显的。

主持人：那以前那个你常去找的产品经理，现在怎么办？我想问的是——你怎么看“AI增强人类”与“AI取代人类”的关系？你觉得现在还处在“增强”的阶段吗？

Jyoti Bansal：我觉得更准确地说，是整体节奏变快了。AI 让竞争压力、创新速度都加快了。以前某个功能从想法到落地要花一年，现在可能六个月就得上线。

所以虽然 AI 提高了生产力，但并不是大家因此“更轻松”了，而是做得更多。

企业的选择很现实：要么用同样的人做更多事，要么落后。现在基本上是前者——大家更高效，也更忙（笑）。

AI真的在重塑一切

主持人：你同时也是一位活跃的投资人。最后一个问题——在 Harness 之外、在 CI/CD 之外，你最近对哪些方向最感兴趣？

Jyoti Bansal：我共同创立了一家早期投资机构 Unusual Ventures，专注种子轮。我们会非常深度地参与被投公司的成长，不只是投钱，而是帮助他们搭建销售、市场、运营等能力。

现在是一个非常令人兴奋的阶段。我们在看很多 AI 基础设施项目，也在投不少垂直领域 AI——比如医疗、金融、制造等行业的专用解决方案。

我最近问团队：我们收到的项目里，有多少是 AI 相关的？我以为答案是 50% 或 60%，结果他们说：100%。这说明所有创业者都在用 AI 重塑各自领域。

我们在投的方向包括：AI 重新定义 CRM、重新定义 SRE、重新定义制造、设计等。几乎每个领域都有人在用 AI 重新发明流程。

所有AI领域都存在泡沫，问题是谁会死掉，谁能活着

主持人：我这周刚去了 OpenAI Dev Day，Sam Altman 当时提到某些 AI 领域有点泡沫化。我问他是哪些领域，他没回答（笑）。那我来问你：你觉得现在有泡沫吗？

Jyoti Bansal：我觉得 所有 AI 领域都有泡沫，但这并不是坏事。每当有颠覆性技术出现时，市场都会高估它的短期速度、低估它的长期影响。互联网就是这样——人们以为“一年后人人都上网”，但其实花了更久才实现。

AI 也一样。是的，现在有些估值虚高、竞争过热的现象，但从长远看，AI 的变革是真实的。

在任何热门赛道里，也许 20 家创业公司中最终只有 4、5 家能活下来，其余都会失败。但这正是创新生态的本质——竞争、试错、进化。泡沫本身不一定是坏事，它往往是大浪潮前的必经阶段。

主持人：是啊，说到这里，从“泡沫中的死亡”到“幸存者的成功”，真是个既现实又振奋的话题。今天非常感谢你的时间，跟你聊天总是很有启发。

Jyoti Bansal：谢谢，真的很高兴聊这个话题。

主持人：同感，谢谢你。

好了，文章到这里结束了。这篇文章的采访对象本身就是一位技术大牛，所以他的视角可以说非常真实。现阶段，AI的确存在成分，市场估值远超其现在所能创造的表现。

但泡沫什么时候不存在呢？既然注定是未来，那问题就变成了：怎么在这场泡沫中成为赢家！