开源星数与 Orca 的产品定位
提问者：恭喜恭喜！我刚刚看了一下，你们在 GitHub 上已经有 49,000 颗星了，马上就要突破 5 万颗星了。
津晶：谢谢，哈哈。
提问者：估计这个视频发布的时候，你们的 Star 数量就已经有 10 多万了。我们先请你介绍一下你们的公司和产品。尤其是对于平时可能在使用 Claude Code、在使用 Codex，但从来没有了解过什么是 Agentic IDE 的开发者，请讲一讲你们的产品到底是做什么的。
津晶：大家好，我是津晶。我们的产品叫 Orca。Orca 是一个 ADE，ADE 是一个很新的概念，其实你可以把它想象成 Agent IDE，是一种让人与 Agent 能够非常好地协同工作的新型工作平台。
Orca 和大家直接在 Terminal 里面使用 Claude Code 相比，最大的区别主要有以下几点：
第一个最大的区别是它的集成性。Orca 把你整个工作流（workflow）所需要的各种工具全部都集成在了一起。比如说我们的很多用户，他会使用 Orca 里面集成的 GitHub issue 或者 Linear issue，直接从他今天要做的事情开始起步。假设他今天要处理 20 条 Linear tickets，这 20 个 Linear tickets 就能直接变成 Orca 里面 20 个不同的并行线程（parallel thread）。当他的这些 thread 产生各种进展和更新（updates）的时候，它又能够自动将状态反馈同步回 Linear。到了最后阶段要做代码审查（code review）、测试等等，所有这些工具在 Orca 里面都有完整的集成。因此用户就不需要不停地在五六个不同的应用程序之间来回切换，一条完整的开发链路就能彻底跑通。
第二个不一样的点在于 Agent 的并发规模与协同能力。当你在终端 Terminal 里面跑上大概 5 个 Claude Code 的时候，可能你自己就已经搞不清楚到底谁在负责干什么样的具体活了。但是我们的用户通常是同时跑几百个 agents。也就是说，他可能会同时推进 10 到 20 个不同的功能特性（feature），然后在每一个 feature 里面，又分别有四五个 agent 在以不同的方式相互合作。在 Orca 里面，Claude Code 和 Codex 之间可以通过平台互相协作，实现非常高密度的 Agent 并行化（agent parallelization）。
第三个特点是，大部分用户在 Orca 里面也可以直接使用原生的 Claude Code 和 Codex。因为我们是一家专注于工具集成和协作层面的平台，我们并没有去自研一套专属的 Harness。所以用户会发现上手 Orca 非常快，只需要 1 分钟就能上手使用，因为他可以直接在我们自带的 Orca Terminal 里面继续使用熟悉的 Claude Code 和 Codex。
ADE 与 Harness 的概念区别
提问者：你刚才介绍的这几个点，我每一个都有好几个问题想追问。第一个问题是，你把你们的产品定义叫做 ADE，而没有使用现在比较流行的词汇，比如 Harness。那是为什么？或者说在你心中，Harness 和 ADE 它们各自不同的定义分别是什么？
第二个问题是，现在越来越多的人，哪怕是很多资深程序员，他们的使用习惯也在逐渐从纯 Terminal 转向 Codex 或 Claude Code 的图形界面（GUI）工具。在那些图形界面里，似乎我也能同时追踪很多个不同的 session 或者 worktree。那你们和他们这些原生工具的区别是什么？尤其是在那些官方工具里，其实也正在逐步集成像 Linear 或者 GitHub 这类工具，他们显然是有野心去集成越来越多的生态内容的。为什么你们可以做得比 Anthropic 或者 OpenAI 官方还要更好？
津晶：第一个问题其实相对明确一些，也就是 ADE 和 Harness 的区别。
Harness 其实你可以把它想象成一个循环回路（loop）。也就是说你面对一个 AI 模型，你每告诉它去干一件事情，给它一个 input message，它就会返回一个 output message。而 Harness 所做的事情，就是如何把这样一个“有输入就能产生输出”的 agent，包装并驱动成一个自动化运行的 loop。而且它并不是一个简简单单的死循环，这个 loop 还可以挂载并调度许多不同的工具（tools），包括 routine 处理、tool use 等等。它可以去读取你的 bash 环境，去执行系统命令，还可以去进行网页搜索（search the Web）。所以 Harness 的本质，就是像 Codex 和 Claude Code 背后那一整套 loop 与 tool use 组合逻辑的集合体。目前业界比较流行的 Harness 包括像 Pi，还有最近变得非常火热的 OpenCode，以及 Devin 等等，这些在架构上都属于 Harness。
而 ADE 则是建立在 Harness 之上的更高层级平台。ADE 本身并没有直接去与底层基础模型绑定，也没有直接去实现底层的 execution loop。它把负责跑 loop 的这些具体执行功能，交给了当前市面上现有的各种成熟 Harness。ADE 自身反而更加专注于“人与 Agent 协同管理”的工作流（human-agent workflow）。
所以像 Orca 的很多核心功能，我们的重心和侧重点都在于管理与协同。正如刚才所提到的，我们并没有自研一套封闭的 Harness，用户完全可以在 Orca 内部自由使用 Claude Code、Devin、OpenCode 等所有主流的第三方 Harness。Orca 更加聚焦在如何让用户能够清晰纵览这 100 个不同的 Agent Harness 正在并行执行的任务与中途产生的阶段性结果；当 Agent 在执行过程中需要人类介入并提供输入时，人类如何能够以最高效的方式给它们提供实时反馈；以及人类该如何高效 review 它们产出的最终代码结果，或者是中间生成的 HTML 设计稿等内容。这就是 ADE 和 Harness 之间最核心的分工与定位区别。
提问者：明白了。举个例子来说，比如我们之前做过一个文本翻译的任务，具体的做法是准备一个 Markdown 文件，然后通过终端调用 claude-code -p 传入 prompt 去修改这个 Markdown 文件。这其实就是调用了一个 Claude Code 的 Harness 去对目标文件做针对性的改动并生成结果，中间它可能还会输出一些 JSON 数据。而 ADE 的作用，就是把这样一个单点调用的过程彻底给 UI 化、系统化，让它变成一个体系化的工程，使我能够自如地调度 100 个不同的 Claude Code 来帮我协同干活。
津晶：是的，完全是这样。现在的 Orca 大概有 70% 的功能体现在 UI 层面，但同时还有 30% 是我们许多深度用户非常高频使用的 CLI 命令行工具。所以它在整体上起到的是一个中枢调度的核心作用，不仅可以在 UI 界面上实现全局调度，也可以通过我们的 CLI 来协调各个不同的 Harness 进行各自的 Loop 工程化运作（loop engineering）。
终端 TUI 与图形界面 GUI 的取舍
津晶：关于你刚才提到的第二个问题，即大家从终端界面（Terminal UI / TUI）迁移到图形界面（GUI）的趋势，在我们看来，这其实很大程度上属于个人工作流偏好的问题。对于我们团队而言，我们在这方面并没有特别主观或强加于人的 vision 或 opinion。确实有一部分工程师在 Terminal 里面操作会觉得更加顺手、高效，而另一部分人则更习惯于在 GUI 界面中进行点击和交互。
如果从纯工程实现（engineering）的角度来看，这两种形态也各自有不同的优势和技术难点，Terminal 有 Terminal 的工程挑战，GUI 也有 GUI 的复杂之处。因此在 Orca 里面，这两种模式你都可以自由选择。你可以根据自己的喜好将默认视图（default view）设定为 Terminal UI 或者 GUI，甚至可以在同一个工作 session 之中进行无缝自由切换。
不过，如果从商业战略和产品迭代（business & product）的维度来考量，我们确实有非常明确的观点和坚持。作为创业团队，我们的核心原则就是要能够与用户现有的工具生态实现极其平滑的无缝衔接。
为什么我们一开始推出 Orca 时，选择的形态是让用户优先使用 Terminal UI 呢？这是因为在实际用户群体中，Claude Code 和 Codex 的 CLI 终端用户基数，其实远远大于使用它们 Desktop APP 图形客户端的用户基数。既然已经有如此庞大数量的开发者每天都在 iTerm 或者 Ghostty 里面重度使用 Claude Code，如果我们在中间人为制造阻碍，对他们说：“嘿，你不要再用习惯了的 Claude Code Terminal UI 了，你必须来我这里适应一套全新且完全不一样的界面”，这不仅会增加用户的迁移成本，而且每当上游的 Claude Code 发布重大功能更新时（比如 Claude Code 最近推出的各种不同模式，像 Ultra mode 等等），只要上游一更新，我就必须在自己的 GUI 里面去专门适配和重新实现一套对应的 rendering 渲染逻辑，这会极大程度地拖慢我们自身的迭代速度（iteration speed）。
因此，尽管我们现在也提供了完整的 GUI 视图，但在新特性的跟进速度上，GUI 肯定不如 TUI 那么即时。因为在 TUI 模式下，上游 Claude Code 和 Codex 只要发布了任何新功能，用户在 Orca 内直接就能毫无延迟地原生享受到。
提问者：这非常有意思。也就是说，Codex 的官方 GUI 和它的 CLI 或者 TUI，功能上几乎是齐平（on par）的，可以这样理解吗？
津晶：是的，因为那是 Codex 官方自研的 first-party 第一方产品。但是如果你不是它的官方第一方产品，情况就截然不同了。比如 Claude Desktop 和 Claude Code 相比，它们的功能其实完全不是 on par 的，Claude Code 的更新节奏和能力通常会比 Claude Desktop 超前很多很多步。而且如果你选择使用 TUI 这种开放的终端接入方式，你还可以直接享受到整个开源社区里许多其他极其出色的 Harness，比如 Pi 就是一个非常优秀的 Harness，OpenCode 同样是一个十分出色的 Harness。
跨 Worktree 的 Agent 状态集成与供应商中立性
提问者：这里我想再深入追问一个问题。你前面提到，如果开发者直接在原生 Claude Code 的终端里操作，可能开到 5 个 session 的时候就已经完全看不过来、跟踪不过来了。那 Orca 具体是通过什么机制来解决这个管理难题的？Claude Code 本身其实也带有不少编排（orchestration）功能，它的编排能力比 Codex 要强不少，而且 Claude Code 自身也有一个 agent view，允许用户去查看几个并发任务的进展。那为什么 Orca 能够在 Claude Code 以及其他 agent 的基础之上更进一步呢？
津晶：这主要是因为我们在底层做了一套非常强大且统一的 Agent 状态集成（Agent Status Integration），这套系统能够帮助你横跨所有的 Git Worktree 来做统筹管理。
以我自己的日常开发为例，我现在本地同时维护着 400 多个 worktree，这意味着我同时在并行推进 400 多个不同的 feature。这些 feature 每一个都在各自的代码分支上有不同程度的推进，有的进展快一些，有的进展稍慢一些。Orca 的能力在于，它能够将所有这些分散在不同 session、不同 worktree 里的 Agent 状态，并且跨越所有不同类型的 Agent Harness（无论底层跑的是 Claude Code、Codex 还是 OpenCode），全部抽取并统一汇总到一个全局的 Agent 状态看板中。
在这个看板里，系统会清晰地标示出：这个 worktree 里面当前有哪几个 agent 在运行；哪一个正在正常工作（working）；哪一个当前遇到了阻塞（blocked），标记为“You need to answer immediately”，提醒你必须立刻介入提供输入；哪一个已经顺利执行完成，标记为“You need to review the result immediately”，提示你应当立即去审查代码成果。因此，我们在跨分支、跨工具的状态聚合上做到了极致的集成度。
我认为在很多时候，工具的“集成性”和“中立性”所蕴含的价值是被外界严重低估的。退一步讲，哪怕假设我们的单点功能做得和 Claude Code 完全一模一样，但现实中并不是所有开发者都在单一使用 Claude Code。而且从我们的真实用户群体以及我们观察到的行业大趋势来看，大家正在逐渐从过去单一采购 Claude Code 这种中心化模式，转向采购多供应商（multi-vendor）以及更多开源权重模型（open-weight models）的混合模式。
所以，即使单看某些功能表面上与 Claude Code 类似，但 Orca 作为一个能够原生支持多工具、统一汇聚各种 Agent 状态、允许用户自由搭配不同 Agent 与不同底层模型的平台，本身就具备了极其独特且不可替代的优势。更何况在 Claude Code 现有的能力基础之上，我们还额外增加了更为先进的全局 Agent 状态集成与任务分流筛选（triage）机制。
提问者：把你们的价值拆开来看确实非常重要。比如首先是供应商中立（vendor agnostic）这一点。其实在平时的开发实践中，大家非常强调中立性。因为在如今这个 AI 时代，如果你被深度绑定（vendor lock-in）在某一个特定的厂商生态里，风险是很大的。谁也不知道哪家大模型厂商明天会不会突然调整策略、变更接口或者服务出现波动，而且各大模型之间的竞争追赶速度极快。所以我们在平时做技术交流和指导时，也极其强调一定要跨工具使用，想方设法去沉淀属于自己的通用资产和使用习惯，比如把自定义的 skills 放到公共共享目录下，而不是深度耦合到某一个工具私有的特定目录里。
多 Harness 的成本控制与模型转交
津晶：是的，除了中立性之外，还有一个极其现实且关键的维度，就是使用成本（cost）和账单花费。个人开发者的 AI 使用习惯和大型企业的采购支出模式非常不同，这两个层面我都具体分享一下，因为成本控制本质上也是衡量工具效能极其核心的一环。
拥有支持多 Harness、多 Agent 供应商架构的一个巨大好处在于容灾与成本调度。举个例子，当你在开发过程中，你的 Claude Code 账号的 usage 突然触达到了用量上限（rate limit），在 Orca 里面你完全不需要中断当前的工作流。我们甚至内置了一个转交（handoff）功能，你可以一键直接把当前正在进行的 Claude Code 任务无缝移交给 Codex，Codex 接收到完整的上下文之后，就像什么都没发生过一样，立刻继续顺着原来的逻辑往下推进工作。
这个能力在实际开发中非常实用。因为我们自己在高强度写代码的时候经常会遇到这种情况：哪怕你手里准备了好几个不同的 Claude Code 账号可以随时切换，但官方的并发和用量限制始终是存在的，你不可能无限制地去增加账号数量。所以当我的 Claude Code 额度暂时跑完的时候，我可以一秒切换到 Codex；最近 DeepSeek 非常强，我也可以直接切换到 OpenCode Go 去跑 DeepSeek；随后我还可以切换调用 xAI 的 Grok；如果 Grok 也用得差不多了，我还可以换到 Google Antigravity 继续跑。所以成本与可用性是一个非常重要的考量维度。
对于企业级客户（enterprise）来说，这个痛点就更加剧烈了。为什么现在越来越多的大企业对 Codex 以及各种开源权重（open-weight）模型表现出极度浓厚的兴趣？原因在于 Anthropic 的 API 账单已经悄然变成了他们企业内部的第一大开销，甚至这个费用支出已经超过了支付给软件工程师团队的人力成本总和。所以无论是从纯粹的研发效能提升角度，还是从企业整体的成本优化角度来考量，支持多 Harness 并行的架构都具有压倒性的优势。
为什么大厂官方无法取代 Orca
提问者：我们顺着这个话题聊，我又冒出了几个新问题。我们先回到刚才那个核心疑问：为什么你们做的这个产品，不会沦为 Anthropic 或者 OpenAI 官方产品里的一个附带功能（feature）？也就是说，大厂未来如果也想做，为什么他们做不好？
津晶：关于这一点，虽然从功能表面上看，我们和 Claude Desktop 以及 Codex 确实存在不少重合的地方，但我可以直接引用我们社区里面许多资深核心成员（community members）的原话。基本上所有深度体验过 Orca 的开发者，特别是那些极度追求 100 倍效能（100x engineer）的极客工程师，他们在用过之后都会发出类似的感叹：“我不知道为什么，但 Claude Code 和 Codex 官方做出来的产品体验就是没有 Orca 顺手和好用。”
当然，单靠这种当下的体验优势，并不是一个能够长期高枕无忧、具备极强防御性（defensible）的壁垒。但就目前的发展现状而言，Orca 团队的迭代速度是极其惊人的：我们目前保持着每天发布一个稳定版本（stable release）的高频节奏，而且每一个 stable release 里面通常都包含了社区提交的上百个 PR。我们始终在源源不断地推出各种最新的人机协同功能，包括前面提到的能够让单个 Agent 跨多个 Terminal 终端进行统筹编排，以及将一个复杂的开发 workflow 从某一个 Agent 顺畅 handoff 转交给另一个 Agent 的能力。
顺便提一下，这就是 Orca 这个名字的真正来源——它代表的就是“Orchestration for Agent”（Agent 的协同编排）。
这套编排和上下文转交的理念，是我们从项目创立第一天起就确立的核心构想。在那个时候，Codex 官方的 Agent 甚至都还不具备自我感知（self-aware）的能力，一个 Agent 被困在单一的 session 里面，根本没有任何机制能够把当前上下文完整 handoff 给另外一个 Codex session，更不用说跨工具转交了。
提问者：对，跨 session 传递 context 这种特性，官方好像是最近这一周才刚刚开始推出的新功能。
津晶：是的。所以我们在产品演进上一直处于领先身位，永远在提前布局下一步该如何让人与 AI 实现更极致的工作协同。
我觉得这背后的原因主要有两点：
第一点在于我们的迭代敏捷度以及真实的开发者身份。因为 Orca 本身是一个开源项目，而且我们自己团队就是最重度的真实开发者（builders）。我们和市面上众多初创团队的 builder，以及那些处于高速增长阶段（hyper-scaling）的技术团队有着完全相同的处境和体感。这种强烈的感同身受让我们的产品直觉（product sense）非常敏锐和精准。
相比之下，像 Anthropic 的 Claude Code 团队或者 OpenAI 的 Codex 团队，他们内部通常拥有无限量的免费 token 额度（unlimited token），他们根本不需要考虑如何精细化管理不同的订阅计划（subscription）、哪个账号额度要见底了该怎么办、如何通过工具协同尽快把 feature 交付出去。因为他们处在一个极其优渥且有缓冲的环境（cushion environment）之中，他们日常眼中看到的技术问题、感受到的工作痛点，和我们这种处于一线真实开发战场上的开发者是完全不一样的。
第二点，也是更长远、更根本的原因，在于商业激励机制（incentives）的本质冲突。大厂的商业动机是不可能与真正的中立协同保持一致的。无论是 Anthropic 还是 OpenAI，他们官方工具的核心商业逻辑都是为了将开发者深度锁定（lock-in）在他们自己的模型生态和产品体系之内。
敏捷开发与小团队的同理心优势
提问者：这就非常清晰了。抛开技术层面的中立性和集成度不谈，大厂和第三方工具在商业动机（incentive）上本身就是不一致的。能够自由跨越 Claude Code 和 Codex 去混合使用，是你们的核心价值主张（value proposition）之一。而且沿着这个中立协作的思路去推演，整个产品的底层架构和交互设计也会完全不同，而这种设计思路反而更契合一线开发者最真实的日常使用习惯。
津晶：没错。作为一个真正想要依靠 AI 将单个工程师武装成超级个体、以极致速度进行日常产品迭代的人，我认为在当下的 AI 时代，研发迭代最快的方式就是你自己既是产品经理，同时又是核心工程师。当你对所要解决的技术痛点有极其深刻且切肤的同理心时，你的迭代速度就会飞快。而大厂团队在做产品时，不可避免地需要经过层层的产品经理或者其他冗长的中间流程，去调研收集用户的痛点是什么，然后再排期规划如何迭代，这在响应速度上就会形成明显的代差。
提问者：国内像腾讯、美团这类大厂，他们平时可能还会惊讶于 Anthropic 的迭代速度，觉得 Anthropic 的演进已经非常快了。但实际上，你们这种敏捷的小团队跑得比 Anthropic 还要更快，确实有一种长江后浪推前浪的感觉。
那么总结一下，核心优势主要包括：第一是本身的工具集成性与中立性；第二是人机协同与编排的设计哲学；第三是团队自身处于真实开发一线，与用户有着极强的同理心；第四则是远超大厂的极速迭代能力。
你们团队现在一共有几个人？
津晶：我们团队目前一共是 4 个人。
提问者：厉害厉害！感觉以这个势头，很快就要被 OpenAI 或者 Anthropic 抢着收购了。
与 OpenCode、Pi 的生态哲学差异
提问者：我们再聊聊开源生态。关于 Pi 或者 OpenCode 这类工具，你们为什么能够在它们的基础之上，做出如此大体量的额外价值和全新功能呢？
津晶：我认为根本原因在于我们的生态理念比它们更加开放。Orca 有一个非常宏大的产品哲学，这也是当前软件工程领域的一个全新趋势——生成式 UI（Generative UI）。我们认为未来会出现一种全新的软件形态，那就是“一切皆可以以插件（plugin）的形式进行无缝集成”。Orca 目前也在全面朝这个架构方向演进，并且我们内部的技术愿景和产品哲学已经完全构建在这个基石之上了。
先说说我们和 OpenCode 的区别。OpenCode 所谓的“开放（open）”，主要体现在它允许你接入和集成各种不同的底层模型。但是至于你在上层该如何组织执行 loop、如何与 Agent 进行具体的交互，它其实是非常固执己见的（opinionated），在交互层面上并不开放，你必须强制使用它所提供的那一套特定 Harness。而且从实际的社区数据来看，OpenCode 的受众广泛程度和受欢迎程度，依然远远比不上官方的 Claude Code 和 Codex。
Orca 的核心策略与擅长之处在于，我们要懂得借力 Claude Code 和 Codex 的巨大优势。如果你平时习惯且喜欢使用 Claude Code，或者你喜欢使用 Codex，那完全没有问题，你直接来 Orca 里面用就可以了。Claude Code 具备的能力我们全都有，Codex 拥有的特性我们也全部支持，但与此同时，我们还提供了它们所没有的全局编排、跨分支状态管理等高级能力。
而 OpenCode 的逻辑则不同，它虽然在底层模型接入上提供了更多选择，但在 Harness 工具层面，它是逼着用户去做二选一的抉择：“你到底是喜欢 Claude Code，还是喜欢 OpenCode？如果你想用 OpenCode，你就必须放弃 Claude Code 的工具体验。”我们与 OpenCode 以及 Pi 最大的区别就在于，我们绝不逼迫用户做这种排他性的选择，而是以最大程度的兼容性来迎合开发者已有的使用习惯。
提问者：那 Pi 也会逼着大家做选择吗？
津晶：Pi 当然也是这样。你选择了 Pi，你就必须把 Pi 作为你唯一的 Harness，在 Pi 里面你就无法直接享受到原生 Claude Code Harness 的交互体验。
提问者：在 Pi 里面不能调用 Claude Code 吗？
津晶：在 Pi 里面，你可以去调用 Anthropic 的模型，可以使用 Claude 的底层模型，但是你无法使用 Claude Code 这套官方精心打造的 Harness 逻辑。要知道，Claude Code 本身是一个工程打磨极其出色的 Harness。我甚至知道在实际开发中，有些开发者哪怕在本地安装了 Pi 的情况下，他依然会选择通过配置中转 API 的方式，在 Claude Code 的框架内部去调用像 DeepSeek、GLM、Kimi 等国内外的其他模型，因为他舍不得放弃 Claude Code 这套极其流畅的 Harness 交互。
灵感来源与优化 Ghostty/iTerm 的三大痛点
提问者：你之前在对话中还提到过一个终端工具的名字——Ghostty。所以你们做 Orca 这个产品，是完全凭空构想出来的，还是说你们也是在实际使用中看到并体验了一些现有的工具，然后在这之上进行了深入的思考与迭代？
津晶：这是一个非常好的问题。Orca 的诞生主要来自于两方面的灵感（inspiration）：
第一个是来自我们团队内部的积累。因为过去这两年我们团队一直在深耕开发者工具（devtools）赛道，之前我们也自主研发过很多不同类型的 Agent，比如我们之前做过专门用于 UI 自动化测试的 Agent。所以我们团队对于如何构建 Agent、如何管理 Agent 的运行 session 已经非常熟悉。当时我们的一些 UI 测试 Agent 的深度用户在体验过后就建议说：“你们做的这个 Agent session 管理系统体验非常出色，为什么不尝试用它来管理通用的编码 Agent（general coding agent）呢？”这是来自团队内部的第一个灵感触发点。
第二个是来自外部工具的使用体验。我们团队自身的工程师也极度渴望能够实现 100 倍甚至 1000 倍的研发效能跃升，所以在日常工作中我们深度尝试了市面上的许多终端工具，我们用过 Ghostty，也长期使用过 iTerm。当时我们非常喜欢 Ghostty 和 iTerm 所支持的分屏能力，也就是在同一个屏幕窗口内可以同时并排运行多个不同的 Agent，这也是后来成为 Orca 核心功能之一的切屏/分屏模式。
但是在深度使用之后，我们发现 Ghostty 和 iTerm 存在三个非常致命的局限性（limitations），而这些局限性恰好为我们留出了巨大的优化与创新空间。于是我们决定动手去彻底解决这些痛点，最终就孕育出了 Orca。
这三个核心痛点具体包括：
第一个痛点是，传统终端工具并不是以 Worktree 为中心构建的（Not worktree-centric）。虽然 Ghostty 和 iTerm 能够让你在屏幕上切分多个终端窗口来跑不同的 Agent，但是在真实的复杂工程开发中，Git worktree 的创建（creation）、维护和删除（deletion）其实有着一套非常复杂的完整生命周期（lifecycle）。虽然现在开源社区里有越来越多的辅助库可以使用，但是 Orca 从底层就把这一套流程彻底产品化了，能够极其平滑地帮助你统一管理所有的 Git worktree 以及对应的 Pull Request（PR）完整生命周期。
第二个痛点在于 Agent 运行状态（Agent Status）的展示与管理机制非常原始。在 iTerm 和 Ghostty 里面，虽然像 Claude Code 这类工具可以动态去修改终端标签页的标题（Terminal title），但它能够展示的信息非常有限，根本无法呈现出一个 Agent 完整而结构化的运行状态（比如：当前是正在执行中，还是遇到了错误，亦或是需要用户紧急介入交互）。当你在终端里打开了几十上百个 Tab 标签页时，你单看那些被截断的简短标题，是完全无法感知全局 Agent 的真实状态的。
提问者：对，那充其量只是一个静态文本标题而已，根本算不上真正意义上的状态看板。
津晶：没错，它仅仅是个标题，不是真正的 status。而 Orca 是把 Agent Status 做成了一套标准化的 API 集成。甚至在目前的版本中，Orca 已经全面支持了扩展插件（extension），任何开发者都可以直接调用我们这套聚合后的 Agent Status API，去自主开发和定制他们自己喜欢的专属管理视图。
第三个痛点则是版本更新机制（Updates）。我认为这是一个在日常开发中极容易被忽视但影响极其深远的痛点。为什么 Orca 现在能在开发者社区里迅速流行起来？一个很重要的原因就是我们保持每日高频更新（日更），而且广大用户也非常乐意每天跟着我们一起更新升级，因此大家永远能在第一时间用上我们最新、最强大的特性，而不会出现其他工具出了新功能而 Orca 用户用不上的情况。
然而对于 Ghostty 和 iTerm 这类传统终端而言，只要你点击软件更新或者重启，你当前正在运行的所有终端会话将会全部瞬间丢失（completely gone）。假设你原本在本地后台并发跑着 50 个 Agent，一旦终端更新重启，虽然你事后也许能通过某些日志把历史记录找回来，但是在这 50 个 Agent 里面，到底哪些是正在运行中被强行掐断的、哪些是已经正常跑完的，每一次更新之后你都必须耗费巨大的精力去手动排查和重新恢复。这就导致 Ghostty 和 iTerm 的用户根本不敢轻易去升级更新，工具的迭代和演进速度在用户端也就被大幅拖慢了。
PTY 会话快照与海量并发性能优化
提问者：那在技术实现上，你们是怎么做到在软件高频更新的同时，完全不丢失任何终端会话状态的？
津晶：这在底层实现上确实耗费了我们团队非常多的心血和工程精力。
在操作系统底层，每一个 Terminal session 对应的是一个伪终端设备（PTY）。在 Orca 里面，每次进行版本热更新时，我们都会自动对当前所有的 PTY 进程进行状态恢复（restore）。具体而言，我们在本地构建了一个轻量级的本地数据库（local database），用来对每一个运行中的 PTY 实时拍摄并持久化状态快照（snapshot）。
当软件完成更新并重新加载时，系统不仅会把之前的全部交互历史记录完整拉取回来，而且如果某个任务在更新前原本就处于执行流程中，系统会确保它能够无缝继续往下执行。包括你在本地终端里启动的各种开发服务器（Dev Server）等等，在整个更新过程中都不会被杀死，原生的 PTY 会话得以完整保留。
提问者：这确实是一项非常细致且复杂的底层硬核工程。
津晶：确实非常不容易。单纯做一个状态快照（snapshot）和恢复（restore）的 demo 雏形本身并不算太难，但难的是如何在保持海量并发的同时，让整个系统依然维持极其极致的高性能（performance）。
因为一旦系统里保存的上下文数据过多，而每一个独立的 Terminal 终端在底层其实都非常消耗系统内存。想象一下，当你在本地开启了几百个并发 session，并且每一个 session 你都要实时跟踪、捕获并持久化它的完整运行状态时，对内存和 CPU 的开销是极其巨大的。
为了解决这个性能瓶颈，我们在底层专门研发了一整套完整的缓存架构（caching system）以及冷热数据分层存储机制（cold storage），通过这一系列深度的性能优化手段，才最终保证了在几百个 Agent 并发运行时依然丝滑流畅。
提问者：这听上去虽然表面上是一个产品 idea，但实际上你们平时必须投入海量的时间和精力，去打磨这种极其底层、极其细致的工程硬功夫。
津晶：是的。很多外行或者初看的人可能会觉得：“哎，你们这个界面看起来跟 Ghostty 好像差不多嘛，UI 分屏长得也挺像。”但实际上整个软件的实际交互体验、在海量并发下的稳定性，以及很多极其微小的操作细节上，我们在底层都倾注了极大的工程功夫。
提问者：我经常对很多工程师说，从一个简单的原型（prototype）演进到一个真正可用于严肃生产环境（production）的工程级产品，这两者之间其实横亘着一条巨大的鸿沟。如果一个人的工程能力和技术积累不够深，他甚至根本看不见这条鸿沟的存在。AI 的确可以把我们以更快的速度带到这条鸿沟的边缘，但是想要真正平稳地跨越这条鸿沟，依然需要开发者投入极多的时间、精力和极其扎实的软件工程水平。刚才你分享的这个会话恢复与性能优化的例子，虽然听起来只是一个小切口，但足以让人真切感受到这件事情有多么考验团队扎实的软件工程底子，以及你们真正愿意沉下心来做这件事的匠心。4 个人的团队能做到这种工程深度，再次向你们表示由衷的钦佩。
海量任务下的注意力管理与索引搜索
提问者：我们接着刚才的脉络继续深入探讨。前面提到你们的那些核心高阶用户（power users），他们平时的开发状态都是同时开启几百个 session，在后台并发编排管理几百个 Agent 一起协同干活。在这么庞大的并发量下，工程师个人的注意力（attention）真的能够管理得过来吗？大家在日常工作中具体是如何进行操作和调度的？你身边可能全都是这种极客工程师，所以大家会觉得这种工作状态非常自然且习以为常，但在整个开发者群体中，这类人绝对属于极其罕见的极少数。可能需要你带着对普通开发者的同理心，来帮大家具象化地描绘一下这些高阶用户的日常工作图景，以及他们究竟是如何把控全局的。
津晶：我们可以先从最基础的操作层面讲起。首先第一点，就是要选用一个趁手且专门为此设计的优秀工具，比如像 Orca 这样的系统。因为 Orca 在立项之初，它的很多 UI 交互界面以及 CLI 命令行工具的设计初衷，就是为了让开发者能够以最直观、一目了然的方式看清自己当前到底有哪些正在进行的任务与工作内容。
除了基础架构之外，我们在 UI 交互层面针对海量并发场景做了非常多的专项优化，这也是我们的用户能够轻松驾驭管理如此庞大数量 Agent 的关键所在。其中一个最核心的优化就是我们强大的即时搜索系统（Search）。
我们可以拿日常办公来打个生动的比方：大家都重度使用过像 Google Docs 或者 Notion 这类在线文档工具。如果你在工作区里一共只有两个文档，那我哪怕只给你一个极其简陋的列表界面，第一行显示第一个文档，第二行显示第二个文档，你一眼就能看清楚。但是，当你的工作区里逐渐积累了比如 1,000 个甚至上万个文档的时候，在绝大多数情况下，你不可能再靠肉眼滚动列表去查找，你必须完全依赖高效的搜索机制来定位。
因此我们在 Orca 内部针对多任务检索做了极其深度的优化。我们的搜索排序算法会自动实时抓取并索引大量的多维关键特征，包括但不限于：当前 Agent 会话的标题（session title）、关联的 Git worktree 分支名称，以及与该 worktree 深度绑定的 Linear tickets 任务工单里面的各种核心业务关键词。
通过这种多维度的关键词毫秒级全文索引，无论你的工作流多么庞大，系统都能让你瞬间找回上下文。比如你想起来：“哎，我三天前好像针对某个特定功能做过一些尝试和改动，它现在的执行进展到底怎么样了？”此时你只需要在搜索框中敲入对应的关键词一搜，Orca 就能一键瞬间将你直接导航跳转到三天前那个专属的 Terminal 会话页面中，所有上下文完整呈现。
试想一下，如果你是在原生的 Ghostty 里面开着 100 个终端 Tab 标签页，在没有任何结构化索引的情况下，你根本不可能搞清楚这 100 个 Tab 里面哪一个到底在干什么。
提问者：这种搜索并不是指那种调用 LLM 进行慢速推理的 Agentic 语义搜索，而是指底层极其迅速、高效的毫秒级即时索引搜索（Index Search）。
津晶：对，它就是一种纯粹为了极致响应速度而设计的轻量高效 Index 搜索。
提问者：我觉得这不仅体现了索引搜索在工程上的高效性，更深层次的原因在于，你们团队自己在一线真切体验并实践了这样一种全新的 AI 原生开发工作流，在亲身经历了海量并发带来的各种繁杂痛点之后，针对性地自研出了最契合这种工作方式的解决方案。我相信你们这个搜索功能的打磨与诞生，正是源于这种最真实的一线实践。
终端与跨 Worktree 的全局信息搜索
带了很多之前大家不会想到放到搜索结果里的信息，到我们这个搜索结果里边去。
是的是的，就说大家以前会有搜索 Linear、Google Doc 这种，但大家没有想到我要把 Terminal 终端什么的，以及各种 worktree 之间的那些关键词，都拿来做搜索。
对，到现在，Claude Code 或者是 Codex 的搜索其实不是很好用。我觉得我想搜索什么东西，现在还是搜不出来的，我不是很 trust 他们的搜索。
这个也是，我们并不觉得我们做到完美了，我们还有很多搜索方面想要提升的地方。搜索总是在 index 它的那个 freshness，和你的 retrieval speed 之间做抉择和权衡的，所以我们还有很多可以提升的空间。
让 Agent 管理 Agent：从需求到 PR 的全自动编排
这是其中的一个方式，就是我们的用户如何在几百个 agent 之间能够跟进的一个方式。
然后第二个方式，就是让 agent 来管理 agent。Orca CLI 它是自带 orchestration（编排调度）的。我们看到我们的很多用户，他会写一个 orchestration 的 script，其实跟 Claude Code 内部的那个 sub-agent 它是很相似的。就是说，你看我的 Linear ticket，然后你把它收集所有的 requirements，然后写一个 design doc，然后再 review 好多遍。review 完了之后呢，然后再去 implement，然后再做 QA testing。
然后像 Orca 自带那个 browser use 和 Mobile emulator，所以你可以用 Orca 自带的这些工具来做 QA testing。然后全部搞定完了之后，给我一个 PR 和一个 HTML report。并且 Orca 也自带 artifact sharing 这种功能，所以很多用户他就已经把这样一个 recipe 弄好了。他直接从 Linear ticket 一开始，然后就让 Claude Code 驾驭着 Codex 或者其他的模型，最后直接给他交付一个 PR 和一个 artifacts 来让他 review。
明白，它其实是我有一个 task，然后这个 task 呢我有一个目标，把这个 criteria 讲好，我要的什么是好的、什么是不好的，然后可能我过去有什么问题，和我大概在做这个目标的时候，我希望你去做哪些步骤。比如说你要先 plan，然后写，写完了以后呢可能还要互相校对，校对了以后你可能还要在实际产品上去看。其实这个过程呢，人就几乎不参与了，人就看第一步和最后一步，看他交出来的东西是不是合理就行了。
是的是的。以及如果你需要参与的话，其实一开始也可以跟 AI 写好规则：如果有重大决定，你不太确定的时候，你可以让我参与。但你让我参与的时候，你得给我那种很容易去 review 的东西。因为我们自带一个 browser，其实我们发现我们很多 user，他都会让 AI 哪怕中间问他一些问题，都是说“给我一个 visualization 的解释”。也就是说，“这是我想要做的事情，然后你看一下这个 HTML 的页面，觉得 ok 不 ok；然后 ok 你就继续”。
每日自动化调度与多渠道社区运营
这一步我觉得了解了，然后信息的更好编排、组织和呈现也了解了。但是 again，就是你到底每天要管多少事？你真的能看得过来这些东西吗？我觉得大家去想了这些以后，还是觉得哇，400 多个我怎么管得过来，我怎么想得过来，然后我怎么跟进得过来？
OK，这是好问题。我就想说到第三点，第三点就是说还是要自动化。其实比如说像我管的 400 多个 agent，其实可能 200 多个它已经是自动化在跑了，就是跑成 SOP。就像大家以前用 OpenClaw 一样，它有一个像 manager thread 一样的机制，每天会定时跑。
为什么 Orca 能够做到日更呢？整个 release 过程其实还是一个挺复杂的过程。你得找一个很好的 branch to cut, right？然后你还要搜集，比如说我们的 AI，它会去搜集我们的 Linear，还有 Slack 里面有没有大家 report 内测版本有没有 bug。它会搜集所有信息，它会做出决定。然后呢，它如果需要问我问题，它还会自己给我发 Slack 信息。但它整体就是一个很流程化的东西。每天都有一个负责 release 的 agent，每一个小时它跑一次，看一下这个 release 发布到什么地方了，它会自动把这样一个发布流程给跑完。
所以包括我们 Discord——就是我们四个人，不仅是做所谓的工程，我们还有一个非常大的 Discord community，和我们微信也有 community。
你们微信也有社群？
对，我们微信也有。哦对，应该邀请你的，都已经忘了这事，应该邀请你到我们微信的 community。然后我们在 X（Twitter）上面也是有好多万的 follower。所以这些所有的管理，其实都是自动化的。它每天会做 triage，分析你该怎么回这些 user，然后有哪些信息是我们今天收集到的。
所以 Orca 自带这个 Automation feature，它可以连接你的 remote host，像这些 Automation 都是跑在我们 team 的一个 shared remote host 里面。
API 成本与 200 美元订阅套餐的算力杠杆
那大家可能关心的问题就是，这些东西到底要花多少 token，和要花多少钱？
token 的话，肯定还是不少的。如果你是纯按 API 来计算，那其实还挺贵的。我也会看我自己的一些 API usage，纯按 API 算那肯定是每个月好几万刀的。
但是大家现在都知道，像 Claude Code、Codex，还有 Kimi 这些第一方的 subscription，它有非常多的 subsidizing（补贴）。因为按 API 计算的话它自己的 profit margin 很高，比如 Claude Code 和 OpenAI，它都是 90% 的 profit margin；但是如果你买它的 subscription plan，它是 heavily subsidize（深度补贴）的。
所以的话，通过买不同的 subscription plan，我觉得都还挺好的。我基本上每一个 provider 买上一两个，就够我一个月做所有的 Automation 和这种快速 proactive 迭代的 agent 使用了。
买上一两个 200 美元的是吧？
对，基本上我只买 200 美元的，因为那个是最好的 deal 嘛。所以我 Claude Code、OpenCode、Codex、Grok、Antigravity 这些我都有，然后每个都用一下就行了。
插件哲学的分歧：GUI 与多格式编辑器扩展
对。刚刚其实你说了一个点挺重要，我没有展开，就是你说你们用 plugin。我的理解是你这里边可能不光模型 Harness，包括你的工具，可能包括其他的东西也是 plugin。你们的这个 plugin 的 philosophy（哲学），和比如说 Codex 有什么不一样？你这里边为什么是用 plugin 而不是用 skill？
skill 的话，他们两个之间有很多共通的地方。但我们想的 plugin 可能更偏向于 UI 方面的 plugin，就是带有用户界面的。
I see。
用户界面的 plugin，我觉得在未来很长一段时间，UI 和 AI 的结合使用都挺重要的。相当于人和 AI 其实都需要一个工具上的提升。所以有针对 AI 的 plugin，它跟 skill 很相像，就是 skill 和一些 command 的集成；然后呢，我们的 plugin 可能更偏向于 UI 方面的。
比如说举几个例子吧。现在 Orca 的话能够直接在 Orca 内部打开很多不同的文件格式。比如说我们有一个 Markdown file 的 editor，我们有 HTML 的 editor 和 annotator，你可以在 HTML 上面画图批注等等。但是用户他有很多不同的文件格式想要支持。比如说我们有些用户他是做芯片设计的，他有他们公司自己的私有文件格式，想有自己的那种编辑器；以及 PPT 的编辑器，以及 video editor。
就比如说 Claude Code 在左边的 panel 给他生成了一个 video，他直接想在右边、就在 Orca 里面可以打开这个 video，就像他打开一个 Markdown file 可以 edit 一样。可能我们核心的 Orca 就没有办法说把所有的这些模式和 editor 全都自带支持了，所以用户就可以通过 plugin 的形式，在 Orca 里面干上很多自己想干的事。
Power User 的真实画像与大厂工程师的工作流
理解了。最后一个关于用户的问题，你的这些 power users 们，他们用这么多 AI，那你知不知道他们大概都是在干些什么事的？大部分还是 engineer 在公司打工，然后去疯狂地卷 PR 吗？还是干嘛？
其实我们的用户跟可以说早期的 Cursor 和早期的 Claude Code 有很多重合，可能都是最早的这批用 AI 来提升效率的人。一般的 pattern 就是他会用我们做一些 personal project，然后觉得非常好的话，他也想在办公的时候用我们。
personal project 的话就有 Web APP，有 Mobile APP，然后现在我们看到比较 popular 的还有大家会 build 越来越多的 Desktop APP，因为现在越来越容易写这种 Electron APP 了。这是 personal project 方面。
然后也有很多用来做 automation 的。比如他每天要炒股，可以用我们来搜集信息。然后左边是 Claude Code，右边是 Claude Code 给他的 HTML 格式的今日股票分析。他可以在 HTML 上面加一些 comments 和 annotation，然后再发给 Claude Code，两个人一起 cowork。所以 personal use 就是什么场景都有。
但是我想说的是，我们有非常大的用户群体是作为他的 day to day work 日常工作使用的。比如说我看 Twitter 上有人分享他的用户案例，他是一个 Cloudflare 的 engineer。他把每天他要 review 的 PR，就用一个 master 的 agent；然后因为我们支持 nested worktree，他在 top level 的 worktree 下面，可以开比如 20 个小的不同 sub-worktree，同时开 20 个 worktree 来管理并同时跟进他的 20 个 PR review。
所以也有很多这种大公司的员工，他觉得如果我更 efficient，我是不是可以留出更多时间做其他的 project 也好，或者他也可以升职更快等等。
就是 Cloudflare 的工程师呢，每天上班打开一看：“哦，我今天有 20 个活。”然后就找一个 agent，把这 20 个活丢到那个 agent 里边，开了 20 个 sub-worktree。然后下班的时候喝喝咖啡，看看是不是都干完了，干完了以后交一下。
对，哈哈哈。
对，今天的活就干完了。
今天的活就干完了，中间他自己去干什么就不知道了。
创业起点：从量化投资、Google 到进入 YC
产品本身我觉得已经给我们介绍很多了，包括大家的 usage。有机会如果大家感兴趣的话在下面提问，你应该也在社区里边，可以跟大家来多多交流一些。
那我们讲讲你的创业经历吧。大学毕业之后——你是 16 年毕业的？
嗯，16 年，对。
然后先做 quant（量化投资），然后再去 Google 的对吧？然后创业大概是四五年的样子。
是的，对。
你是第二个创业项目进的 YC（Y Combinator）？
呃，其实是第一个。
第一个？那好，讲讲你的故事。
因为其实我从小就看我爸创业做他自己的 business，比起在公司里面打工，我就特别想成为自己拍板决定做什么的一个人，所以从大学里面就一直想做这个。
但是因为当时是国际学生嘛，来美国你不可能说突然一下大学一毕业就要创业，因为我们毕竟还有很多身份的问题。所以大学毕业之后也是循规蹈矩地做了大厂里面的工作。
但是 Google 刚好在湾区，在湾区这边创业氛围其实是非常浓厚的。其实在 Google 的时候，我业余就会参加各种各样的创业活动，从这些优秀的湾区创业人才身上也学到了很多。所以当时就觉得自己想做一个什么东西。
那是几年前了，当时 AI 还没有火起来，当时也没有特别好的点子，所以就觉得管他呢，随便做一个点子，什么能上手就行。
当时的第一个点子其实是做一个直播的平台，给那种 special events 做线上直播，就像婚礼、公司的一些 events。那个项目的增长也比较好，用户和收入增长都比较好，所以也是拿着那个项目进了 YC。
但是在 YC 毕业之后，我们就发现做 event space 它是非常有巨大挑战性的。为什么呢？因为要做成一个很大的 business，其实最重要的一点就是用户的留存性。如果你永远的增长都要来自于不停地去外面吸收新用户，那是一个非常危险的境况。因为你永远不可能保证说，我下个月广告的费用会不会增加，能不能吸引到那么多新用户。
而在 event space，它的留存性是比较差的。哪怕它一年之后回来使用了，比如像婚礼那就更差了对吧。所以我们当时也是意识到，这个项目可以有很好的收入，但是要做到十亿级别（one billion）、百亿级别的一个公司，它还是得要做那种非常高频使用的产品。
从软件测试工具 Stably 到通用 Agent 工具 Orca
所以我们的第二个点子叫 Stably，它是用 AI 来做软件测试。这个我觉得在当时来说也是一个非常合理、扎实的选择。Stably 做的也算比较成功，因为也有不少的企业客户。
但是为什么最近几个月我们更专注在做 Orca 上面呢？是因为我们发现，以前做 B2B SaaS 和 Dev tool，你做一个 niche area 是非常值得去深入做扎实的。但现在我们发现，是不是所有的 Dev tool 都 collapse（收敛坍缩）到一个方面了？就是说全部收敛到用 AI 来生成。
包括现在很多做 video editor 的，你的 workflow 其实很多时候可以用 Claude Code 帮你查看一些 video frame，甚至用它来帮你做 editing，让 Claude Code 去 prompt Seedance 来做很多事情。所以我们发现这种 general coding 的 workflow，它其实可以取代以前很多 B2B 的 specialized workflow。
所以我们觉得，既然我们已经投入了那么多精力来做这个 AI testing agent，我们可以把我们的很多投入放在这种更 general purpose 的 agent 上面。
四人团队与五万 Star：靠产品 Taste 与借力趋势
这里边就有一个你轻描淡写、但是大家觉得可能很不可思议的事情。你做 Orca 取得了现象级的成功，然后这个现象级的成功基本上是——你看，首先从功能上来说，大家会问为什么 Anthropic 或者 OpenAI 这么牛逼的公司没有做出来？然后从增长上，在你的 focus 还没有放在增长上、且团队只有四个人的情况下，能增长到 GitHub 有 5 万颗星。我不知道你们的日活或者 download 是什么样子，应该也是一个比例非常高的程度对吧？这还是最近做出来的东西。
然后你前面的两次创业，大家一般不是说创业 10 个里边 9 个失败嘛，但是为什么你做一个成一个这样子？
可能我对于成功的定义是要到 one billion 这种级别吧。
但是我觉得至少每个都做起来了。
我觉得有两项吧。一个就是说我们确实是一个非常技术的团队。我和我的 co-founder，我之前在 Google，然后他在 Uber，所以基本上我们想做什么点子，我们都能把它做到最好。可能在选点子上面、在 business 方面、Monetization 这些还有很多要尝试的，但是产品方面确实是可以把它做到最好。
我觉得可以分享的经验就是说，即使大家说现在 AI 捏一个产品就可以了，但是我觉得在未来的一年之内，要做成一个好的产品，其实还是会需要非常多的时间和 token 消耗去打磨的。所以好的 taste 还是可以给你一个很大的领先机会，这是第一点。
第二点我觉得更多的是 Orca 方面的成功。我觉得 Orca 增长这么快，是在非常少的 marketing 投入的情况下做到的。我们可能 95% 的时间都在做产品，可能 5% 的时间就是想什么发什么、今天发一下 Twitter 那种情况下能做这么好。我觉得关键还是得借力，赶上那个趋势得借力。
包括回到我最开始说的这个 TUI 和 GUI 之争，我想说的是我们本身没有一个 strong opinion。我们更多想做的就是大家想用什么，我们就很好地支持大家用这个，而不是去摆在一个对立面的位置上，逼用户做选择说“你要么用 Claude Code，要么用我们”。我觉得那种做法你的 marketing 投入得非常大，你才能改变用户的使用习惯。
而你作为一个“我能让你把 Claude Code 和 Codex 用得更好、更容易”的工具，不需要改变他的使用习惯，他就可以用上你。他也非常愿意分享给他的同事，说：“哎，我知道我们刚买了 Claude Code 对吧，但我不是说让你换一个新工具，而是你用这个可以让 Claude Code 用起来更好。”所以他的分享和使用 adoption 都会做得比较高。
你们现在 download 方便透露大概是多少吗？
不会透露具体数字，但是 download 肯定是比 GitHub star 还要高很多的。
杠杆营销与中立生态：为何不把任何人当竞品
这里边大概有多少是来自于口碑？我想知道的是大家是怎么知道你们的。对于任何一家公司，awareness 和 trust 都是非常高的 barrier。大家能知道你们，然后大家还信任到足够愿意去试一下，你觉得为什么你们可以这么快地让大家愿意去试用？
我觉得确实是这个赛道的原因，其实这个赛道很容易传播。因为现在不停地有新的 tool 出来，大家都愿意尝试一下有什么好的方法能管理自己的 agent。可能大家直接用 iTerm 和 Ghostty 遇到了很多我刚才说到的问题，大家也不是很满意，所以大家总是非常愿意去尝试新的 tool。
所以我觉得得到 traffic in（流量获取）其实还挺容易的，但是我们其实比较在乎的是留存率。我们留存率也挺高的，留存率高你才能有 viral growth（病毒式传播增长），才能 1 传 2 等等。如果第一天没有转化、没有留存，看一眼就走了，他没办法去散播到第二个人、第三个人。所以我们就非常看重留存率。
我们会发现我们的用户有一个规律：他基本上是试了所有的工具，有时候刚好最后一个试的是 Orca，有时候刚好是先试了 Orca 又去试了一圈新工具，或者他是同时试 Orca。不管他的先后顺序是怎样，他基本上只要试了，最后都会选择留用 Orca。
我觉得留存是产品决定的，而且产品好到一定程度是带传播指数的，1 传 2、2 传 3，一个人会推荐给几个人。可是在那之前，你说很简单，获取流量很简单，但对于一个没有做过的人来说可能并不简单。同赛道有很多人试图在做这件事，他们可能都不觉得简单。想想你的 YC 同学们对吧，他们很多人在做这个，他们并不觉得简单。为什么你觉得简单？
可能是我没花很多精力在上面。我可以想一下我觉得我们做得不一样、可能有帮助的地方吧。
包括我们做 marketing，我们还是偏 leverage marketing（杠杆式借力营销）。怎么解释这个 leverage marketing 呢？它其实跟我们产品的设计思路是非常一致的，就是我们都非常擅长借力。
我能看到一些跟我们同类型的产品，看他发的 X post，全都是关于“我们这个产品今天上线了一个新功能”。因为他会觉得他的责任就是去宣传他自己产品的功能。他不敢提一句比如 Claude Code，因为他永远会把 Claude Code 和 Codex 这种看成是竞争关系。就比如说 Claude Code 今天推出了一个 agent 功能，他就觉得天塌了，担心大家会不会都去用 Claude Code 了。
但就像我刚才说的一样，不管 Claude Code 更新了什么，只要还有 Codex 在，我们保持中立的生态位，它总是有存在的价值。更何况现在不仅是两家独大，现在有非常多的 player。
我们的松弛感就在于我们不把任何一家视为我们的 competitor（竞争对手）。虽然有的产品目的是想来 compete，但是我们觉得这是一个非常 open 的 ecosystem。
这体现在我们的 marketing 里面就是：Claude Code 发布了新功能，我们会点赞说“太好了，大家可以在 Orca 里面这么来用 Claude Code”；然后 Codex 发布了，我们也会说“新功能 Codex 做得好，可以在 Orca 里面这样用”。
所以其实大家非常愿意看这种 content，大家很喜欢学“有什么新的 Claude Code tricks，有什么新的 Codex tricks”。所以基本上我们可能想什么发什么，花 5 分钟发一个内容，发出来基本上都有好几百个赞，就是因为发到了大家喜欢的这种干货内容。
真正的执行力：深度访谈 100 位用户挖掘痛点
Google 码农千千万对吧，Uber 码农千千万，很多人我觉得从 Google 出来也没有能力去做一个那么好的产品。在你看来，你们所谓的这种好的技术和好的产品能力是怎么培养的？或者说 great 和 good 的区别是什么？
技术方面比我们好的有很多，我觉得核心还是要能 land，能把一个想法真正执行和落地。我甚至觉得当时我们能进 YC，这可能也是当时 YC 面试我们时最看重的一点。虽然我们的第一个点子并不算是最好的点子，甚至我们之后确实抛弃了那个点子，但是不管面对什么点子，我们都有极强的执行力。
作为工程师，执行力并不仅仅体现在你的技术编码功能，而是能把各个方面都打通去找到一个好的方向，然后能了解这个方向上的玩家有哪些，以及大家的痛点是什么。找到大家最共鸣的那个痛点，然后能很快地解决这个痛点，并且每一步你都能很精准地做正确的事。它听起来很简单，但其中每一个步骤可能都包含 10 个不同的细分步骤。
我们展开其中一个吧，稍稍展开一下怎么找到痛点？用具体的例子来给大家解释一下当时你是怎么找到痛点和解决痛点的？为什么其他人没有找到和解决？
我们第一个点子做线上 event 直播的时候，找痛点的方式有几个。一个是身边的朋友。我们做每一个点子的时候，包括我们做最近的 Orca，我们都像回到了最初在黑板上第一次头脑风暴一样，严格按照步骤走：我们都会去问上 100 个人，而且是深度的沟通交流，不是说发 100 份问卷那种，而是做婚礼直播时，我们会跟最开始的很多 couple（新人）沟通，问可不可以给你打一个电话，然后跟他做非常深入的沟通交流。问他：你为什么会想到要用我们这个产品呢？这是一个很好的 insight。
你在里边具体会问什么问题？
我一般会问：第一，你为什么会想到这个需求；第二，你为什么会想到找这样一个解决方案，有没有考虑过其他的解决方案？比如说第一个点子，我会问：你为什么没有考虑 Zoom 呢，Zoom 完全可以做直播，你有试过 Zoom 吗？从他的回答里你就可以得到一个很好的反馈，知道我的优势具体在什么地方，那我就一定得加大投入我的优势。以及他可能也考虑了其他哪些产品。
然后第三点就是要问变现相关的问题。你可以问：你既然说这个问题对你来说这么重要，你要到处找解决方案，那你之前在类似的产品上面花了多少钱？这都是非常重要的。
你看过《The Mom Test》（妈妈测试）那本书吗？
对对对，我看过那本书。
为什么我想到这本书，就是因为你问的是“你在类似产品上已经花了多少钱”，而不是问“你愿不愿意为我的产品花钱”。
对对对。然后像我们 YC 的 Adviser、我们的 YC group partner 是 Michael Seibel，他就非常直白地跟我们说：你要对你的用户了解到这种程度——比如说做 B2B，你要清楚他去年的收入是多少，他的收入增幅是多少，他们公司目前最大的开销是什么。你能不能做到成为他们第一大或者第二大的开销？你能帮他们解决一个多大价值的问题，才能让你成为他们第一大、第二大的开销支出项？
他说你如果都不知道你的客户公司的收入是多少、增长是多少、他最大的问题是什么、公司里面每个不同岗位的人想解决的问题是什么，如果你做不到对用户有这样的了解程度，那可能不管是你的宣传也好，你的产品设计也好，你都是在隔靴搔痒，没办法做到很准确。
那你是怎么去了解这些信息的？听到了你想去了解，你会怎么做？
我就直接问客户。
直接问？
直接问，直接问。很多人可以问。可能我们在湾区，对我们现在的赛道来说有一些天然的优势：第一，我本身在湾区，基本上我身边的朋友你都可以直接问到：你们公司到底采购了什么软件，你们公司营收怎么样，今年的 AI 工具预算（budget）是多少，你上次采购的那个工具你们花了多少钱。
比如我就知道很多公司，他们现在的第一大开销已经变成 AI 了；在 AI 之前，他们第一大开销其实是 Datadog，甚至都不是 AWS。
哦对，Datadog 真贵。
对对，是的。然后去问你们今年的预算是多少。如果问一个人问不到，你就不停地问不同的人。我们发现各个公司给出的回答其实都大同小异，问上这么多家之后，你大概就知道了行业现状。
其实这是一个现在来说很好的机会，就是你要 develop 对用户的一个 true understanding（真实理解）。而且这个 true understanding 其实比大家想象中的要深很多，很多时候大家以为自己了解了，其实还是停留在表面，在这里边一定要不停地深挖追问下去。
从痛点到解决方案：假设、借力与多版本快速迭代
访谈 100 个客户，问他们非常具体的问题，在里边不断去寻找真实的痛点是什么。那找到了真实痛点，你们怎么样把它转化成你们的 solution 呢？
先听一下他们已有的 solution。一般来说还是回到借力（leverage），很多公司内部其实已经有了各种各样的尝试，你可以去了解：你尝试了这个方案行不行，或者那个行不行？这已经是一个非常好的 baseline 了。
另外的话就是我们要快速迭代。一个是要有很好的前期判断，但我不能保证我们的判断每一次都是百分之百正确的，所以快速迭代并得到反馈还是非常重要的。这也是我们做得比较好的一点。
特别是现在有了 AI 的赋能，虽然你确认了痛点是真实的，但解决它的方式你可能可以同时推出 3 版不同的解决方案，当然 3 版都是你猜想可能最好的方案。
包括我们产品里 AI status 的集成显示，其实也是经过了好几个版本迭代的。现在有很多人会抄我们 AI status 集成的 UI 显示方式，但最开始第一版我们是把它放在很中心的位置，后来我们又觉得这个可能大家只是想看的时候看一眼，就很随意地放在了右边的一个角落，结果我们发现放在角落根本没有任何用处。然后我们就会把它放在不同的地方试了好多个版本，根据大家的反馈调整了很多次。
根据大家的反馈，你的真实 feedback loop 怎么建立？因为很多时候大家得到的是一个 biased sample（有偏样本），或者说是那种声音很大、但其实不代表真实用户的反馈。你怎么样去得到有效反馈，从而在快速迭代中找到方向？
可能这个不太科学，因为我觉得我们现在还没有做任何特别科学的实验，很多时候还是靠自己最后的一些综合判断。反正我们的原则就是……
社区反馈、信息收集与团队决策权
包括我们社区里有非常多的PR（Pull Request），还有很多issue，以及各个论坛上面对我们的反馈，我们都会把这些作为一个参考。我们也会对这些反馈做定性（qualitative）和定量（quantitative）的一些集成与分析。比如如果发现有50%的反馈都来自于某一类需求或问题，那这个我们肯定是要去正视的，毕竟大家确实有这种建议。
但是我觉得，这些东西归根结底都只是作为一种信息输入。特别是在现在的AI时代，你获取信息的方式和渠道其实是越来越多的，但无论信息多丰富，我们都只把它当作参考信息来看待。最终的决定权，依然在我们团队这4个人手里。我们团队有非常好的产品感（product sense），这其实也是属于大家相信自己吧。核心的逻辑就是，先去广泛收集足够多的信息，然后再结合你最好的判断来做出一个决定。
在访谈很多投资人的时候，他们也提到过类似的观点，认为很多时候最后拼的就是一种体感。在数据科学领域，数据能明确告诉你的东西，可能也就占百分之二三十，你最终要看的还是你自己的心智模型（mental model），也就是前面说的product sense，或者大家有时所说的审美与品味（taste）。
Product Sense的建立节点与开悟时刻
关于product sense和taste的建立过程，如果回顾比较关键的节点、里程碑（milestone）或者某些顿悟的时刻——也就是可能在某段时间之前觉得自己并没有找到一个很好的product sense，但在某个节点突然感觉开悟了——其中一个悟出来的点就是：如果在不同的产品功能（feature）之间犹豫不决、不知道该怎么做抉择的时候，那就以我自己作为标准用户。
这恰好也是因为我所处赛道的原因，我自己就是一个非常标准、非常合适的用户。我们团队本身又有很多人，所以我们自己就可以在团队内部去体验很多团队之间需要协作的AI工作流（workflow）。再加上我们之前做产品时也有把产品卖给大公司的经历，所以我也清楚大公司内部的具体workflow是怎样的。同时，我们团队现在又处在一个快速迭代的状态中。综合这些因素，我就觉得我们自己就是一个非常好的目标用户。
因此，每当我在做产品决策犹豫不决的时候，我就亲自去试一下，看看能不能切实提升我们自己的效率。哪怕这个功能再不济、大家可能一开始并不喜欢，但只要它确实提升了我们团队自身的效率，这往往在最后反而会演变成一个非常好的结果。这算是最近一段时间比较开悟的一点。
而在这之前另一个开悟的点，则是意识到了AI发展的一个大趋势。当时开悟的一点就是意识到很多时候、很多产品，其实都可以通过编程智能体（coding agent）来解决。
现在的产品形态正在发生两个方向的分化：一种就是像我们现在做的这种通用的编程智能体（general coding agent），也就是帮助大家更好地去使用Claude Code、Codex这一类的工具；另外一种形态，则是很多现有产品在其原本的UI界面里面嵌入一些聊天框（Chatbox）。尽管在现有UI里加Chatbox做出了很多提升用户体验的尝试，但我认为这种方式带来的上下文丢失（context loss）实在太多了。
这也给我带来了很大的产品设计方向上的启发：现有的很多成熟产品，它们的大方向和基础其实已经非常好了，你不能去对抗它（fight against it），而是必须要建立在它的基础之上（build on top of it）。
早期创业项目的获客与平台分发流量
回顾从第一个创业项目开始，让别人知道项目并能够成功实现商业变现、收上钱来的过程，时间点是非常关键的。回顾所有项目的总体主线（theme），基本上每个项目在最开始启动的时候，都会迎来非常多的自然流入（inbound）。
比如现在的Orca，刚好切中了大家在管理智能体（agent）上面遇到困难的痛点，包括很多企业级客户（enterprise）也都在积极寻找解决方案（look for solutions）；而再往前的一个项目Stably，做的是AI测试（AI testing），当时也是因为AI生成了太多垃圾代码（junk code），大家都在思考如何用AI来做自动化测试；至于最早做的那款虚拟活动（Virtual event）产品，当时正好赶上了新冠疫情（COVID）尾声的特殊时间节点。当时我们刚把产品放到App Store上，正想着要不要告诉身边的朋友，结果立刻就有好几个完全不认识的陌生人在App Store里直接搜索并下载了我们的产品。
总结下来，核心就在于：在正确的时间节点去解决正确的问题。
第二点就是要充分相信并利用平台自身的分发流量。以Orca为例，我们很大一部分流量其实是来自于GitHub本身。当时大家会在GitHub里面搜索诸如“ADE”这样的词。ADE是一个全新的概念和词汇，当时我们是唯一一个在项目上明确标明自己是ADE的产品。当时团队内部也会纠结：大家会好奇ADE到底是什么，我们直接标这样一个新词，风险会不会太大了？但我当时就觉得不管那么多了，我们就是要去创造这个叫ADE的新词。随着后来在GitHub上搜索ADE或者agentic development的人越来越多，很大一部分流量就顺理成章地来自于GitHub。在不同的平台上去充分利用其平台的原生流量，是一件非常有价值的事情。能够打造出一个优秀的产品，并且准确抓到时代的脉搏，把脉能力就显得格外重要。
创业心态与乐观主义的底层逻辑
在创业心态上之所以能够保持相对平稳、没有那么焦虑与着急，觉得机会总是在那里、只要想去干就总能干成，是因为坚信这个市场和蛋糕（饼）其实是非常大的。
很多人可能会把当前的AI竞争想象成一场零和游戏（zero-sum game），觉得Anthropic或者OpenAI把这块市场吃掉了，其他人就没有任何机会了。但如果从人类漫长的历史长河来看，我们目前可能仅仅处在非常初期的起步阶段。没有人能够预料到，未来人类文明作为一个整体，我们的经济总量（GDP）以及技术能力能够达到何等的高度。
现在可能很多人觉得传统SaaS要完蛋了，但即便SaaS的旧模式面临冲击，这世界上依然有太多值得去构建（build）的东西。我们现在连真正的家庭机器人都没有普及，连做饭机器人都还没做出来；人类还没有真正实现大规模登月，也还没有登上火星；更不用说在生物医药等生命科学领域，还有极其庞大的未知空间等待突破。
作为一名创造者（builder），未来可以做的事情实在是太多了。这个方向如果不行，那就再去尝试下一个方向。我们身上的松弛感，很大程度上就来自于切身经历过很多次“这个不行就做下一个”的过程。只要还有饭吃，就可以一直做下去。
人类智能与AI智能的互补性及社会财富分配
虽然当前很多人认为AI和科技发展存在巨大的泡沫，甚至认为AI目前对宏观GDP并没有产生特别显著的正面推动作用，但即便在充分知晓这些悲观论调的前提下，依然选择坚定地持有更乐观的信念。
这种乐观的前提在于，我不相信AI能够完全取代人类。我认为AI所具备的智能，和人类自身的智能之间虽然有很多相似之处，但本质上是高度互补的。两年前我可能还没有现在这么乐观，两年前我也会担心AI是否真的会彻底取代人类。因为这和第二次工业革命完全不同：当时蒸汽机的出现取代的是人类的体力劳动，人类至少还有脑力劳动作为依托；但如果现在AI真的把脑力也彻底取代了，那人类还有什么存在的价值？
但在深入实践后发现，脑力本身并不是一个单一维度的概念。就像我自身的智力和Orca（Orca在英文中是虎鲸的意思）相比一样，虎鲸是一种非常聪明的动物，但它的智能和人类的智能完全不在同一个维度上。有虎鲸擅长的事情，也有人类擅长的事情。同理，AI有AI擅长的领域，人类也有人类独特的擅长之处。
AI可能会朝着一个与人类完全不同的智能方向去演进。虽然目前业界都在努力把AI训练得越来越像人类，但即便训练得再深入，很多时候AI依然无法像当年的爱因斯坦提出相对论那样去进行开创性的思考。当然，很多AI领域的专家可能会反驳并认为AI在任何维度上都可以对人类实现降维打击。但在我的认知框架里，只要AI和人类是互补的关系，那么AI就是一个能够带来巨大生产力跃升的工具。
过去人类有太多未能解决的重大难题，比如生物医疗的攻坚、深层矿产资源的勘探与对地球资源的开发等。在卡尔达肖夫文明等级中，I类文明（Type I civilization）指的是能够完全驾驭和利用整个行星能量的文明。我们人类目前在迈向I类文明的漫漫长路上，可能仅仅走到了十亿分之一的位置。我们未来能够做、需要做的事情还有极其广阔的空间，这也是我整体保持乐观的根源所在。就像数百年前的人类无法想象当生产力彻底解放之后会爆发出多大的可能性一样。
如果说存在一些隐忧，那可能主要来自于未来财富的分配机制。而财富分配的走向，高度取决于人类与AI的智能究竟是互补的还是完全替代的。如果AI与人类智能不是互补的，也就是说AI可以完全无缝替代人类的所有工作，那么确实会引发极其严重的财富分配危机，因为绝大多数人都会被掌握AI技术的极少数人视为没有价值的存在，社会财富也就不会再向大众分配；但如果在现实情况下，无论AI变得多么聪明，它依然需要人类的参与——哪怕是普通人也能提供某种AI无法企及的互补性智能，那么社会的分配形态和财富流转机制就依然能够延续下去。
工业革命的转型之痛与教育体系的调整
从另一个角度来看，人类确实具有不可替代性，AI无论怎样训练都与人类有着本质区别。然而目前的问题在于，我们现行的教育体系在培养过程中，过度强调了那些恰恰最容易被AI所取代的标准化技能，反而忽视了人类身上那些真正独特的东西。
对于在AI原生（AI native）环境中成长起来的下一代人，他们反而会更加强调和彰显人性中独特的部分，比如手艺（craft）、个人兴趣、热情（passion）以及对某项领域的深度造诣（mastery）。而自工业革命以来，整个社会的教育和培养模式倾向于把人塑造成为标准化的零件，而这种高度标准化的能力，在AI时代正是最容易被替代的。
这种转型期间的过渡阶段确实会带来很大的阵痛。从历史维度来看，这种剧烈的社会转型已经发生过很多次，不仅在工业革命时期屡见不鲜，甚至在工业革命之前也反复上演。比如在英国机器纺织技术刚刚普及的时期（如维多利亚女王统治早期等历史阶段），全英国有80%甚至90%的年轻人都面临失业，那一整代青年人的处境都极其艰难。但对于整个国家和社会的长远演进来说，大家最终都找到了新的出路，人们开始转向更为深入的科学研究以及其他新兴领域。
转型过程固然极其痛苦，但最终在宏观历史中都会成为一个转瞬即逝的节点。不过对于身处其中的每一个具体个体而言，那几年的转型期往往决定了整个人生轨迹。因此无论是当下的AI创业者，还是各行各业的从业人员，身上普遍背负着一定程度的焦虑感。面对这种时代变局，关键在于调整心态并保持快速适应的能力，只要坚信自己能够持续适应变化，其实就能够坦然面对。
近期创业机会之一：ToC产品的价值回归与ROI提升
展望近期较为明确的创业机会，主要集中在三个核心方向：
第一个方向是重新做回面向消费者的ToC业务。
在过去很长一段时间里，B2B被普遍认为是一种更优越的商业模式（business model）。因为把软件卖给企业客户虽然难度较大、前期门槛高，但只要成功切入，通常签下的都是至少为期1年的合同（contract），如果给予一定的折扣优惠甚至可以锁定两到三年的长约；而且即便只签约1年，企业客户的粘性也极高，因为企业内部替换系统的切换成本（switching cost）非常高昂。
但在当前AI时代的背景下，B2B的销售周期（sales cycle）不仅没有因为AI技术的引入而缩短，反而变得更加冗长而艰难。因为有了AI之后，企业客户的采购心态变得极为犹豫。过去企业会明确知道自己需要采购什么工具，而现在企业在采购时会反复权衡：到底该买现成工具还是直接购买底层AI用量（AI usage）？到底应该采购多少额度？整个决策过程变得异常漫长。更棘手的是，即便好不容易走完了漫长的采购流程，很多企业在仅仅使用了3个月之后，就会开始琢磨着如何解除合同（contract）。
因此，对于很多向我寻求创业建议的海内外创业者，我都会建议他们重点关注ToC方向，去尝试打造面向终端用户的App等产品。
ToC正在变好的底层原因在于整体投入产出比（ROI）的显著改善。在过去开发一个ToC App往往需要耗费大量的时间、人力和工程成本，而现在借助AI工具，很多开发者一个人在一个月内就能连续做出好几个App，前期的研发投资成本被大幅压缩。
虽然市面上的应用供给量可能增加了上百倍、竞争加剧，但关键在于所切入的App赛道属性。如果做的是争夺用户有限注意力的零和游戏类App（比如试图与TikTok争夺用户屏幕时间），那竞争自然异常残酷；但如果开发的是能够将市场整体蛋糕做大的App——去解决过去用户想做却受制于开发成本而做不到的实际痛点，或者打造出原生内置AI能力的新型应用——这种产品并不需要去和娱乐平台抢夺时间，而是在通过解决实际问题创造全新的增量价值。
此外，ToC的投资回报（return）变好的另一个核心原因，在于终端用户的付费意愿得到了实质性的增强。在过去的移动互联网时代，大量的ToC App依赖于广告驱动的免费经济模式（ADS powered economy），用户长期习惯了由巨头提供的免费补贴，认为地图、文档等各种软件服务理所当然都应该是完全免费的。但在AI时代，由于背后伴随着高昂的模型调用成本，没有任何厂商能够长期进行无底线的全额补贴。当产品开始针对AI的实际用量（usage）向用户收取合理费用时，用户是真正愿意掏钱付费的。多项数据表明，C端用户的整体付费意愿正在稳步提高。
近期创业机会之二：国内硬件供应链与软硬件结合
第二个非常明确的方向在于硬件，特别是对于国内的创业者而言。
国内在硬件制造和供应链整合方面拥有无可比拟的绝对优势，这种深厚的产业壁垒是美国在很多年内都难以赶超的。即便很多在美国本土创业的跨国团队，只要其业务涉及硬件开发，就必须极度依赖国内的供应链体系。比如我之前有一位做美国本土供暖系统（heating system）及自研空调温控硬件（AC system）的朋友，在创业期间几乎每个月都必须亲自飞一趟中国，因为离开国内的供应链体系，很多生产和制造环节根本无法高效运转。
因此，国内的创业者应该充分利用这种先天的硬件优势，去深度探索硬件与软件AI能力的有机结合。像Plaud就是软硬件结合领域一个非常具有代表性的成功范例。
近期创业机会之三：算力（Compute）、模型托管与软件优化层
第三个方向则是回归到第一性原理（First Principles）去思考，那就是算力（Compute），涵盖底层芯片、存储以及将其高度集成所形成的综合算力服务。这在未来一到两年内依然会是极其火热的赛道。
在最新的Y Combinator（YC）批次（batch）中，出现了大量紧扣这一热点的初创公司。这些公司的核心业务模式高度集中在：帮助客户托管开源模型（model hosting）、帮助企业级客户在私有环境中进行模型的自主托管（self-host），以及帮助客户四处寻找并调度紧缺的算力资源——无论是用于驱动智能体（agent）运行的推理算力，还是运行模型本身的计算资源。
目前全球范围内的算力资源都处于极度稀缺的状态。举一个具象的数据例子：在当下的硅谷湾区，消费者去任何一家苹果官方零售店、百思买（Best Buy）或电脑商城，高配版的MacBook Air基本上全部处于脱销和严重缺货（back order）的预定状态。算力的稀缺性导致谁掌握了算力资源，谁就能在竞争中占得先机，这其中蕴藏着大量的套利与商业化机会。虽然算力基础设施最终需要大型云厂商来提供核心底座，但在如此庞大的增量市场中，依然为初创公司留出了充足的生存与套利空间。
如果参考黄仁勋所提出的“五层蛋糕”（five layers cake）架构模型，在底层的物理算力与上层的AI模型之间，还存在着一层至关重要的芯片级优化层，这是一个纯粹的软件层（software layer）。在AI大爆发之前，这一领域几乎由英伟达的CUDA生态一统天下；但在大模型普及之后，从物理芯片到底层生成Token之间的全链路性能优化，正在涌现出比以往更多的软件优化机会。这与算力集成、算力托管和算力推理服务（serving）一样，构成了极具前景的发展方向。
传统行业的AI赋能与流程鸿沟填补
除了纯技术层面的算力与软件优化之外，在传统垂直行业中同样蕴藏着巨大的落地机会。
在诸如建筑等高度传统的重工业行业中，很多将AI深度引入业务流程的团队都获得了非常健康的营收（revenue）。对于这些传统行业而言，AI扮演的是纯粹的赋能者（enabler）角色。像Anthropic这类基础模型厂商在定义产品设计模式时，往往脱离了传统行业的具体作业环境，其通用交互方式与建筑工地等极其复杂的实际作业场景之间存在着一道巨大的鸿沟。
在传统流程中，由于充斥着十几年前搭建的老旧低效系统，哪怕是采购一件售价数十美元的普通标准化商品，从下单到最终交付往往需要耗费长达一个月的时间，中间经过多层公司的邮件确认与人工流转，层层加价且效率低下。创业者只要能够深入到这些传统场景中去填平技术与现实场景之间的鸿沟、补齐流程断点，就能在传统产业的智能化改造中发掘出大量极具价值的商业机会。
结语与社区互动展望
在Superlinear社区中，可以看到很多开发者发布了大量优秀的新产品，整个社区展现出了极高的创新活力。在当前的这股AI技术浪潮中，希望大家都能找到属于自己的定位、掘得属于自己的一桶金。
如果大家在日常的AI产品迭代和具体业务工作流中遇到了效率瓶颈或不够满意的环节，也十分欢迎大家尝试使用Orca。团队目前保持着每天上线新功能（feature）的高速迭代节奏，致力于帮助每一位用户和团队始终保持最快的产品演进速度。后续访谈内容也将第一时间同步至Superlinear社区，让更多走在AI应用前沿的开发者深入了解并使用相关产品，共同探索AI时代的无限可能。