对话词元无限：字节系团队、数亿元天使轮，ToB Coding、靠 FDE 拿下数十家大客户

词元无限的创业赛道很明确，ToB Coding。

做 Coding 是因为创始人杨萍之前在字节内部的 Coding 项目经历，一个好的 Coding 产品+内部的数据，就能很好在字节内部落地，真正解决问题。

不做 To C 是因为算不过来账，「每一次 Query 都会产生成本，使用量越大，账单越大。」她后来甚至劝投资人，不用再投 To C 的 Vibe Coding 项目了，它们一定活得不好。

2025 年，杨萍离开字节，与清华姚班出身的王伟共同创立词元无限，29 天完成数亿元天使轮融资。方向只有一个：All in B 端，让 Agent 进入企业的生产系统，交付可运行、可验证、可审计、可维护的结果。

一年多过去，这家公司服务了近 50 家大型客户，以金融行业为主。一个客单价千万级的客户，通常只需要一两名 FDE 对接；乐观预测，今年 ARR 在 8000 万到 1 亿元。杨萍的判断更激进：未来 8 到 18 个月，能留在国内这条赛道上的，「有可能只有大厂的一两家，加上我们」。

但他们想要的，是一个更远的位置。「如果讲互联网，大家想到 Google。操作系统，想到微软。我们的长期愿景是，当大家讲到 Agent 应用的时候，想到的就是词元无限。」

以下是 Founder Park 与词元无限联合创始人兼 CEO 杨萍、联合创始人兼 CTO 王伟的对话，经编辑整理。

01 

Coding 一定有需求，

但 C 端 Coding 账单算不平

Founder Park：创业前，你在字节做了 7 年 AI + 软件工程。AI Coding 这件事，你们是怎么一步步做起来的？

杨萍：我 2014 年从北航计算机视觉专业毕业，先在英特尔做了 4 年软件和算法工程师，2018 年加入字节。2022 年开始全力做 AI Coding。当时我们在内部有一个插件产品，虽然只有几十个人在用，每天给我们提需求。

真正的转折点是 2023 年中 DeepSeek Coder 开源。在它之上叠加相关代码数据训练了一个版本，效果一下子变得很好。两三周时间，我们把原来那个版本的产品重新迭代起来，之后不到 3 个月，用户涨到数万人。内部产品能连接飞书文档体系、打通 CI/CD 和研发流程，对需求和意图的理解更好。有一段时间，大家觉得它比 Copilot、Cursor 的效果都好。

Founder Park：这个产品后来对外商业化了？

杨萍：2024 年四五月，我们的插件和 Web IDE 外发了，对外推了两周左右，用户量就远超内部的使用量了。

早期为了获客是免费的。但我看到那张账单的时候会想，这种产品长期做下去，收入模式到底是什么？成本怎么分摊出去？我没有得到结论性的答案。

移动互联网时代，免费产品可以把投入换成广告收入，软件一次研发、持续迭代，边际成本可控。大模型时代不一样，每一次 Query 都会产生成本，算力和芯片又是紧缺资源。使用量越大，账单越大，这种成本结构很难非线性地 scale。

Founder Park：所以决定出来做 B 端，这件事没法在字节内部做吗？

杨萍：到 2024 年中，我越来越确定，需要用外部独立的方式做企业端 Coding Agent。它要完成两个使命，一是把大模型能力从模型侧搬到企业端，二是站在企业视角把商业模式跑正。

直到 2025 年春节前后，DeepSeek-R1 带来了一次能力普及，我觉得时间点合适了。大模型服务软件这件事，值得持续投入，也会带来行业变化。真正开始筹备创业，是 2025 年二三月份。

Founder Park：组建词元无限时，在 To B 和 To C 之间纠结过吗？

杨萍：完全没有。C 端没必要创业去做，你不可能在市场营销上投得过字节。更根本的是，我不看好 C 端的商业模式，过去看到的算力账单太大了，我不觉得它能把账跑正。去年我甚至会劝投资人，不用再投 To C 的 Vibe Coding 项目了，它一定活得不好。 到今天，这个判断已经被印证了一部分。

02 

企业买到的是安全可审计和「数字劳动力」

Founder Park：一句话向客户介绍词元无限，你们会怎么说？

杨萍：长版本是我们的愿景，以无限的词元探索智能边界。我们现阶段不把自己定义成模型技术厂商，更像 Token 的搬运工和生产力提供者，帮企业指挥好、使用好智能体团队，也帮它们完成组织转型。

如果再短一点：企业里现在所有的软件，都可以交给我们的数字劳动力。

Founder Park：B 端客户掏钱，实际买到的是什么？

杨萍：产品形态既有能力很强的单点智能体，也有一整套平台，以标准产品和私有化部署为主，兼顾数据安全与合规。现阶段以旁路嵌入为主，客户原有的软件架构、已接入的 AI 能力和模型都可以保留。

平台会记录使用轨迹、模型和 Token 用量。这些 Trace 一方面帮企业观察过程，另一方面会成为它以后做模型学习和 Agent 学习的高价值数据。Token 的每一段消耗、审计和预测，也都在平台里。

我们要同时照顾三类人，决策者能放心批预算，整个过程清晰、可追溯、可审计；管理者能看到 Agent 和人的运行情况；终端用户的体验和使用过程也能被记录。

Founder Park：企业怎么验收？怎么证明效率真的提高了？

杨萍：代码智能体有一组过程指标和北极星指标，比如 AI 生成代码占比、组织消耗了多少 Token、产生了多少代码、节省了多少人力，平台会直接提供。

其他智能体更适合按结果评价。以质量智能体为例，线上缺陷逃逸率不能上升、质量指标不能劣化，这是基本 Baseline；在这条线之上，再追求经济性，用更少的 Token 完成更多的事。 早期由 FDE 根据客户目标配置指标，所以我们的计费方式也多样，订阅、通用计费、按结果计费都有。

Founder Park：企业服务很容易陷入定制泥潭。你们怎么控制交付成本？

杨萍：三件事。第一，选相对集中的行业，比如金融和金融软件，行业内共通性强，可以复制。金融代码量大、研发人员多、数字化基础好，最早享受到模型红利。工业的嵌入式场景差异更大，长尾行业起步更晚、空间可能更大，但每个行业都要找到自己的冷启动方式。第二，FDE 既要理解大模型的能力边界，也要理解复杂 IT 架构，能在现场快速判断个性化需求怎么处理。第三，客户用起来后会持续提问题，我们提供增值服务，FDE 自己也带着一堆 Agent 工具。

软件生产这一层的非标程度，其实没有想象中那么高。 不同企业用不同的需求管理平台，有的以平台为主，有的平台加本地文档和 IM，但我们可以用标准方式连接。所以能以个把 FDE 的人力，对接千万级的客户。

Founder Park：以银行为例，从第一次接触到落地签单，完整流程是什么样的？

杨萍：银行对数据安全、等保和私有化的要求更高，只卖纯软件决策周期很长，还要走招投标，所以我们典型的方案是软硬一体，GPU、集成和 Agent 产品打包，目前更关注中小银行和城商行。

一家银行通过官网联系我们，技术型售前通常 3 个工作日内完成第一次沟通、做技术演示。第二次交流进入解决方案和技术细节，明确私有化部署目标。通常第二周，FDE 就进场部署试用，试用 2 到 3 周，形成一份集中报告支撑采购决策。从第一次见客户到签单，典型周期是 1 到 2 个月。

03 

「牌桌上可能只剩大厂一两家，加上我们」

Founder Park：决定做 B 端 Coding 时，怎么判断时机？没想过等模型再成熟一点吗？

杨萍：当时就很合适。如果再晚一点，到了所有人都会讲这个故事的时候，它就变成共识了。共识意味着已经被别人验证过，我们得做非共识的事情。

现在回头看，比我们预期的还快。

团队规模，去年 8 月开始运营时，我们估计年底 30 个人，只租了一间孵化器小办公室，后来变成了 3 间。产品规划上，原计划 Coding、Chat、Testing 按 roadmap 推进，结果 Testing 的投入比计划提前。商业化本来预期今年先跑通商业模式、不以收入为主，结果商业 pipeline 远超预期。

很重要的一个背景是，2025 年 2 月 DeepSeek-R1 发布之后，资本和产业层对企业级 Coding Agent 形成了新共识，这也支撑我们很快完成了后面两轮融资。

Founder Park：商业化数据方便分享吗？

杨萍：到现在服务过的客户接近 50 家，以重点大 KA 为主，行业集中在金融、金融软件，也有移动通信、新制造和国央企。

通过渠道伙伴接进来的商机量级比较大，激进一点预测，今年 Pipeline 有希望接近 2 亿元。但我们现阶段更看重有质量的商业化收入，数字不是唯一考核目标。乐观预测，今年 ARR 在 8000 万到 1 亿元；今年比较稳健的预期，大约是 4000 万到 5000 万元。

合同结构很多样：大客户按年度签约，折算到当年可能是千万元级；有些按结果持续计费，形成一两千万元的持续性收入；中小客户是几百万元的订单，还有在飞书上的按次收费。订阅、按人、按年、按次、按结果，我们都在试。

大语言模型的第一个大应用场景——Coding Agent，已经开始形成商业闭环了。我们要跑得更快，以更激进的姿态站稳商业化。未来 8 到 18 个月，能留在国内这条赛道上的，有可能只有大厂的一两家，加上我们。

Founder Park：怎么看竞争？大厂下场会怎么影响你们？

杨萍：有竞争，但比想象的乐观。

大厂通常要突出云业务，依托各自的云客户推产品。但还有一大块市场，公有云很难进得足够深，比如金融和金融软件，有些场景即便进去，也只先覆盖外围系统。我们早期融资引入产业方，就是希望保持独立团队的灵活性，同时借产业渠道进入这些客户。

目前在大客户侧，我们遇到的创业公司竞争并不多，偶尔碰到大厂产品，大家还在各自服务自己触达得到的客户，没有进入全面正面竞争。

之前大家的商业化都聚焦在工具订阅，你会看到做工具订阅的 AI Coding 厂商都活得不太好，停留在工具订阅，最后很容易卷价格。我们提供的是 Agent 劳动力，市场空间大得多。企业要把大模型真正用起来，还需要独立第三方提供最后一公里的能力。

我们把自己定义为生态友好的 AI Native 组织：产品可以被模型厂商和硬件厂商集成，也可以帮模型厂商输出 Token。因为没有被某一朵云或某一个模型绑定，可选的商业模式就更多。

Founder Park：To C 的 Coding Agent 都在转向通用 Agent，对你们有影响吗？

杨萍：值得关注，但不会改变我们的重点。

假如企业要海量用 Token、无限制地创建智能体，最难的部分是什么？我们认为还是在 Harness 和工程层。在企业端做这件事需要长期定力，我们现在看到的非常多产品，两年过后 95% 以上都会消失。我们要抓住的是不变的东西，企业几十年积累的经验、数据、业务逻辑，以及能让大模型变得更聪明的 Agent 自我进化能力。

Founder Park：进展比预期快，产品策略和节奏会调整吗？

杨萍：今年的主调还是产品能力。今天的竞争集中在交互入口、模型能力和单任务成功率，但我们认为交互的终局不会停留在 IDE 或 CLI，这种产品形态是过渡态，代码本身也只是中间产物。

企业真正需要的，是把业务需求变成一个可运行、可测试、可审核、可维护的结果，未来智能体作为数字劳动力，也应该围绕这个结果接受考核。

Coding Agent 从 2023 年到现在走过了 Copilot、Agent 两个阶段，现在处在 Agent 阶段末期，下一步是 Agent Team。但 Agent Team 还有大量问题没解决：组织协作、度量、治理、自我进化和轨迹学习。企业未来需要很多不同角色的数字劳动力，Coding Agent 的终局会升级为智能组织的基础设施。我们现在处于应用层，同时希望成为应用层的 Infra。

04 

模型会吃掉 Harness，

但 ToB 工程层依旧有需求

Founder Park：给企业搭 Harness，最难的点在哪？

王伟：企业有两个复杂度。一个是已有信息系统的复杂度，它又拆成两个命题，业务上怎么约定规则，技术上怎么约束。技术约束的通用性相对高，真正难的是业务的 Spec 怎么生成和维护，每个业务板块有相似性也有差异，这也是为什么前期需要 FDE 和客户的业务专家、技术专家一起打磨 Harness。

另一个复杂度是人。在 Agent 完全取代工程师之前，团队怎么上手？你搞出一个看上去很牛的复杂 Harness 框架，别人用不起来、效率很低，最后效果也不好。

我们做了两件事。第一，FDE 团队先把每个行业的路径跑通，比如银行、保险，提炼出典型的 Harness 框架和模板，和客户共创打磨后，赋能给合作伙伴批量推广。第二，把共性知识抽象成 Agent，比如 Harness Agent，部分替代 FDE 去构建 Harness。

坦诚讲，指不定「Harness」这个词哪天也过时了。但大模型之上、智能体之下，一定还有工程层的大量工作，只是各个团队会用不同的视角去组织和描述它。

Founder Park：模型能力持续增强，会不会把这一层逐步吃掉？

杨萍：企业场景不太一样。就算模型把部分能力内化了，对我们来讲，只是站在了 70 分、80 分的模型肩膀上。模型进了企业，你依旧要跟企业现有的知识、权限、数据、环境做打通，工程层依旧在。而且企业不会在每个环节都用能力最强的模型，太贵了。企业永远要回答的问题是，用智力适当的模型，在成本可控的前提下提供服务。

王伟：我更愿意把模型和 Agent 理解成水涨船高。模型覆盖了更多工作，Agent 就去拓展模型外延够不到的地方。短期内模型迈过某个水位，那个位置的 Harness 确实不用做了，但可以去爬更高的地方，同时做好这块未来被模型吃掉的准备。

但还有很多事模型搞不定。不管是 Claude Fable 5 还是 OpenAI 最新的模型，去真正解决企业内部复杂的分布式应用架构时，其实还 handle 不好，这里面有大量场景必须靠 Harness。

再退一步，「更强的模型 + 更简单的 Harness」和「更弱的模型 + 更复杂的 Harness」，综合 Token 成本谁的性价比更高？这是一个开放问题。 很多 B 端客户因为合规或算力受限，需要在受限条件下找性能平衡点。

Agent 的 ROI 会越来越重要，24 到 25 年大家还在不计成本地 All in AI，到了一定周期一定会看投入回报。我们推出 TokenHub 做多智能体组合优化，本质就是回答这个问题，经济账能不能支撑当前的技术，实打实地服务好客户。

Founder Park：所以强模型配更高自由度，弱模型配更强的框架，应该按目标选模型和 Agent 框架？

王伟：这个表述更精确。打个比方，招一个 MIT 或清华的博士做创新课题，就该给更高的自由度。要完成一个工业化场景，就给更多流程和限制让它不出错。模型也有性格，Claude Fable 5 和 GPT 5.6，GPT 更严谨、指哪打哪，但发散性不够。Fable 5 有时天马行空，做创造性的事会让你喜出望外，但也会做出离谱的事。

未来真正重要的，是能不能统一建模任务特征和目标，反向找到更优的方式去调度模型和 Agent。现在这件事还依赖个人经验，新模型一出，经验就要重建。我们想把它变成可量化、可泛化的能力。

Founder Park：模型的编排调度，也是你们 Harness 层的核心功能？

王伟：是。我们在技术层面提了两个核心理念，自组织和自进化。

自组织，是多 Agent 通过算法驱动动态调度编排的机制。我们希望用算法解决多条件优化问题，比如成本、效率、精度，甚至未来还有审计和透明性的要求。通过算法反向推演应该使用什么样的一组智能体，它们是通过合作还是博弈对抗的机制去完成特定任务。

举个例子，Anthropic 提过用 Sonnet 和 Opus 协同来兼顾经济性和精度，这其实就是自组织算法窄化后的一个场景：成本优化。我们想做更复杂的多条件约束，比如任务准确率 95% 以上、Token 消耗不超过某个值、且必须用国产化模型，反向算出该靠什么样的 Agent 组合完成。这方面我们在跟清华、北航做联合研究。

自进化有两个飞轮。一个是传统的数据飞轮，客户的大量数据在智能体上运行，持续生成和沉淀更多数据。另一个是大家关注不多的 Harness 飞轮，客户业务在持续发展，以前不做移动应用开发、后面要做了，Harness 就得迭代。

我们有一个专门帮用户构建和迭代 Harness 的 Agent，从客户现有系统里收集数据和运行环境，反向生成、更新所有智能体该用的 Harness 底座。一旦扎下根，客户会发现这套环境越用越好、越贴合业务。这就形成了竞品短期内很难替代的壁垒。

05 

FDE 的终极形态，是 FDE as Agent

Founder Park：你们怎么定义 FDE？这个角色具体做什么？

王伟：要求有两条。第一是广度，要理解企业级信息系统，能快速学习客户业务，也要理解 AI 技术和 AI Coding。对 Agent 底层技术的深度要求不像算法岗那么高，但视野一定要宽。第二，他自己就得是 AI 原生的，和 Agent 协同工作。

FDE 的工作不只是传统交付，还要把客户需求提炼出来，甚至在现场自己构建产品原型带回团队。我们内部正在孵化的 Harness Agent，就是 FDE 团队从客户现场做出来的，这类问题在一批客户身上有明显共性，它现在已经逐步成为核心产品。在我们设计的 FDE 体系里，人和 AI 从第一天起就是协作关系，而不是靠堆人天给客户做集成交付。

Founder Park：为什么坚持用工程师做 FDE？懂 AI 又懂业务的 PM 不是更适合对接需求吗？

王伟：很多人觉得 AI Coding 降低了技术门槛，产品或运营背景的人更容易转全栈。但我们看下来，鸿沟不在代码写得好不好，而在于真正理解企业级信息系统在 AI 转型中的现实挑战。

最简单的例子是权限隔离。一个纯产品背景的人要理解其中的复杂性，再判断怎么用 Agent 解决，学习成本很高，有 AI 也补不齐这些经验。所以我们反而倾向招一些年龄大一点的架构师，他们可能慢慢脱离一线了，但 AI Coding 能把执行能力补回来，而他们对复杂系统、技术风险和行业问题的经验还在。

Founder Park：FDE 和传统售前、外包的核心区别是什么？

王伟：售前更靠前，把新理念和行业动态传递给客户，一个人覆盖很多客户。FDE 更强调落地，自己用 AI，也帮客户设计具体方案，把产品接进真实系统。

至于和外包的关系，不用纠结名称，看一个更直接的问题，这种工作方式是否低效、重定制、持续消耗人力，最后会不会拖垮公司？

以我们现在的客户为例，一个客单价千万级的客户，平均投入 1 到 2 名 FDE，典型情况 1 名就够。这件事能成立，是因为 AI 原生模式下，FDE 是带着一堆 Agent 去做交付部署和定制开发的。对创业公司来说，这样的规模化扩张完全负担得起。

Founder Park：FDE 模式有没有天花板？客户从 50 家到 200 家，就要一直招人？

王伟：不会。我们的 FDE 和合作伙伴的 FDE，是开拓者和建设者的关系。进入新行业时，我们自己的 FDE 先把路径跑通，过程中把行业能力蒸馏成 Agent，再交给合作伙伴做行业扩散。

理想情况下，我们可以自己 host 一万个、十万个 Agent 把所有客户需求搞定。现阶段，需求沟通还很依赖人类工程师，跟客户系统的对接也有不够标准化的环节，但在 AI 加持下，这个模式已经非常高效。未来我们设想过，在某些领域做到端到端的「黑灯工厂」，全自动的智能体流水线，一个系统搞定一个行业的所有需求。

Founder Park：那 B 端的终局竞争，会变成 FDE 团队之间的竞争吗？

王伟：不会。词元无限长期的核心竞争力，还是 Agent 和 Agent Infra。Agent 层我们长期专注 SDLC，Coding 和 Testing 是拳头产品，Agent 平台是长期方向。

FDE 是我们切入行业的必修课，它是加成关系。但光有 FDE、没有核心产品和 Agent Infra，对客户来说就是你有很多熟练工人，但流水线没搭好，工人只能在旁边干着急。

从规模化角度，FDE 要不断消灭重复工作。FDE 的终极形态是 FDA，FDE as Agent。 每做完一个新问题，下一次就该尽量交给 Agent，团队不能靠持续加人重复同样的事。

06 

个人提效和组织 10 倍提效，

是两个不同的命题

Founder Park：过去半年的落地实践里，企业通常卡在哪些环节？

杨萍：互联网公司实践得早。像字节这样的组织，AI Coding 覆盖率可能已经超过 90%，但典型团队的效率提升是 40% 到 50%，拉长到整个组织，水位就降到 20% 左右。最领先的模型在代码生成环节能做到十倍提效，放到软件开发全流程，最后可能只剩 10% 到 20%。

效率损失在哪？企业数字化程度不均匀，需求、设计、文档、测试、评审、运维之间有大量断点。编码快了，上下游没有同步改变，整体交付速度不会自然跟上。 所以企业现在最大的问题是，单点工具只能解决单点问题，他们要的是 All in One 的整套方案，把个人工具的能力转化成组织的结果。

这里要同时照顾三层人。第一层是决策者，怎么让他舒服地掏预算。龙虾一开始看上去每个人都很香，但当老板要给每个人配龙虾的时候，看到账单他会崩溃。第二层是各级管理者，未来碳基员工和硅基员工的工作模式会变成什么样？这个变革可能先于单点能力的落地。第三层是一线员工，有人积极拥抱，但不是所有人都积极。让智能体真正跟人以比较 peace 的方式协作、产生对等价值，很重要。

Founder Park：一线员工会担心被 Agent 替代吗？

杨萍：会，而且很直接。研发场景相对容易推进，因为加班多，提效能直接减轻压力。有些工作原本就很难靠人完成，比如完整理解一个大型代码仓的全部历史，企业里架构师数量有限，一个能持续理解代码仓的 Agent，更像研发人员的伙伴。

我们希望数字劳动力最终与人形成共生关系。但站在今天，我没有完美解法。现在通常先解决两三个明确痛点，让用户理解怎么和 Agent 协作。人的角色一定会变，但会变成什么、新工作怎么被创造出来，需要所有 AI 公司共同回答。

Founder Park：企业在 AI 转型中，你们观察到哪些常见的坑？

王伟：与其说误区，不如说不同阶段踩过的坑。之前有个阶段是 All in AI，大家喊「人人都是十倍工程师」。还有个阶段是看谁 Token 花得多。可以理解，因为要调动组织积极性，但事后看有很多不理性。

个人十倍提效和组织十倍提效，完全是两个命题。 组织规模大了，上下文同步更困难，Agent 也一样。把 Token 当简单指标，就跟以前评价谁代码写得多一样，最后变成为指标的边际效应做各种不合理优化。

好在认知在持续迭代。客户过去问 Agent 有没有搭起来、Demo 能不能跑。现在问解决了什么问题、是不是核心业务、ROI 怎么样。这就又回到了商业本质。

B 端还有个有意思的现象，管理层往往比中层、执行层更焦虑，因为他们掌握着企业生死。这个学习过程可能很粗粒度，一开始比谁烧的 Token 多，后来比谁的 Agent 多，再后来发现有些东西没用、有些场景是真的好，经过外部反馈，最终回归理性。

07 

现在是拓荒时代，

到处都是金矿石

Founder Park：你们自己团队的 AI Native 实践是什么样的？

王伟：也在摸索。公司仍然有产品岗和研发岗，但边界没有划那么深。产品和设计团队会输出自己的 Skill，让研发小团队独立开发创新产品，从功能范围到 UI、UX 基本不需要产品介入。InfCode、InfTest 这些核心产品做得更重，人类产品经理介入更深。研发基本是 3 到 5 人的小团队，写更多文档和 Spec，交给 AI 开发，人来验证。我们自己的 Coding Agent、Testing Agent、Code Review Agent 都在其中，TokenHub 和 InfOne 做内部度量。

但坦诚讲，即使在我们这样一家 AI Coding 公司内部，也有非常优秀的资深程序员，对 AI 主导的模式不放心，永远让 AI 一个问题一个问题地答。后来他专门抽时间用 SDD（Spec-Driven Development）驱动开发，发现效果远超预期，才慢慢认可。

这件事给我的触动是，如果一个工程师自己都没有 All in AI，他设计出来的产品，怎么可能发挥出 AI 的极限性能？从根源上，你要有信仰，带着信仰做事，才能找到新模式。先找到 Agent 的边界，才知道怎么突破。很多时候我们固步自封，还没碰到边界就开始说这个问题那个问题。对创业公司来说，这是一个隐性的挑战。

Founder Park：接下来公司的核心目标是什么？

王伟：商业化增长在当前阶段肯定不是最重要的。最重要的是触达更多场景，把这些场景变成产品迭代、数据飞轮和 Harness 飞轮的价值点，这也是我们成立之初就拿产业方融资的原因。

某种意义上，现在就是一个拓荒时代，到处都是金矿石。 我们要快速抢占领域，拿下好机会。商业化是后续的事，水到渠成。

Founder Park：拓荒有没有完成标准？

王伟：我没有完整想过终点，但可以确定，现在离终点还很远。

中国软件开发行业是 10 万亿甚至更高的市场空间，如果整个行业都值得被 AI 改写一遍，现在可能只发生了 1% 到最多 5%，还没算上具身智能这些新领域的新机会。我们会选最有价值、最难的场景突破，比如从银行核心系统开始，然后继续找能力边界，需求能做到什么程度、DataOps 能覆盖多少、物理世界的数据怎么进来，很多问题还没有答案。

Founder Park：具身是接下来要切的方向吗？

王伟：从第一性原理出发，具身的软件研发到数据链路，很多问题跟软件工程本质类似。不同硬件上的软件环境、存量开源项目、分层系统，复杂度和企业级软件开发差不多，也很难靠单一模型覆盖。我们的 Agent 基础设施有很多环节跟它有共性，比如 DeepMap 能把具身里繁杂的硬件文档、软件代码、不同 Layer 的差异 handle 到一起。仿真和真机误差的持续对齐，本质上也是 Harness 过程。

我们跟很多具身和世界模型公司聊过，他们内部对语言大模型用得最多的场景，其实就是 AI Coding，比如让 AI 写 Blender 或 3D 引擎代码来渲染模型、做数据采集，关键就在 Coding 的 Harness 够不够好。对我们来说，这是 Coding 能力从数字世界，延伸到数字与物理混合世界的必经路径。

08 

知道终点时焦虑，

不知道终点时也焦虑

Founder Park：当下最焦虑的是什么？

王伟：行业角度，最焦虑的是模型会不会见顶。我们现在还没看到顶，但它有没有可能明天、明年就到顶？我们并不担心谁发布了类似功能、技术迭代太快。跑得快不快，是自己的主观能动性能解决的，永远的担心是天花板有多高。

公司角度，我焦虑的永远是自己的竞争力。我们是不是能一直跟上最 AI Native 的组织？从产品、研发、算法到商业化交付，整个团队是不是按最契合当前模型和智能体能力的方式在组建？我们的智能组织本身够不够先进？只有这样，一家创业公司才可能跑出来。

Founder Park：如果模型真的见顶了呢？

王伟：逻辑上，见顶了反而可以不焦虑，知道终局长什么样，奔着去就完了。但人就是这样，知道终点时焦虑，不知道终点时也焦虑。 不知道终点，你不知道什么时候停下来。知道终点，又觉得也就这样了。

如果模型能力到顶，可能 5 年、10 年后进入存量市场博弈。我们经历过 AI 1.0、AI 2.0，知道当 AI 能力触到天花板时，各种其他因素会左右市场。未必我们 handle 不好，但那一定不是我们希望所处的状态，大家会转向抢存量市场，而不是把能力打到最优先。

Founder Park：最后一个问题，你们怎么定义词元无限的成功和失败？

王伟：成立公司取名的时候，目标就很明确：我们要做 AI 时代的、代表互联网和移动互联网之后第三代信息化主体的公司。所以选了 Token，还带着一个梦想，Token 是无限的。

长期来看，每一个企业客户，不管是要往 Agent 转型，还是转型之后要管理内部的无数 Agent，词元无限永远都是他的一个选项。

如果讲互联网，大家想到 Google。移动互联网，想到字节。操作系统，想到微软。我们的长期愿景是，当大家讲到 Agent 应用的时候，想到的就是词元无限。

文章来自于微信公众号 “Founder Park”，作者 “Founder Park”