作者丨薛皓皓
编辑丨关雎
图源丨词元无限
对信息安全有着极高要求的金融业（银行、保险等），AI编程的采用率往往低于其他行业。
不是金融业抵制AI编程，而是AI编程难以匹配存有上千万行代码的金融核心系统，难以保证高敏感度的金融数据安全。
一家成立时间一年多的创业公司，词元无限，正试图解决这一问题。
创始人杨萍毕业于北京航空航天大学的计算机视觉专业，2018年开始在字节跳动组建团队研发AI编程的相关技术及产品落地。CTO王伟毕业于清华大学姚班，在软件及算法方面有着丰富的经验。
“我们率先进入金融业的核心原因在于金融软件业的市场规模大，而且存量系统复杂庞大，对安全、稳定、可追踪的要求高，适合‘降维’到其他行业应用。”杨萍说。
通过创立之初的调研，词元无限发现金融客户对AI编程需要大致分为三点：安全合规、模型的选择控制权、随业务演进而迭代的AI编程系统。
词元无限推出的第一个产品把AI编程和复杂而庞大的存量金融核心代码匹配起来，为后续AI编程开发奠定基础的“工程知识地图”。随后，推出了编程类、测试类产品，并将于年底推出为企业提供统一数据管理的平台类产品。
相比于追求个人开发者极致体验的Cursor，词元无限的定位更接近于Cognition于2024年推出的Devin，强调的是软件工程任务如何拆解、委派、Agent执行、及人类审核验收，而非更快更好地帮程序员完成工作。
截至目前，词元无限在金融业的试点客户接近50家，乐观预测，今年 ARR 在4000万左右。
2026年6月和7月，词元无限连续完成天使+和天使++轮融资，投资机构包括华控基金、水木创投、临芯投资等。
金融AI Coding不需要更快交付代码
创业邦：你在创立词元无限之前，曾在字节内部做过一些AI编程的工作，能不能介绍一下当时的主要工作？
杨萍：2019年开始，我在公司内部组建了一个团队，早期我们关注软件工程最大难题之一，就是测试和验证。
2019年，我们做过一些专门针对模型在软件测试领域应用的工作，其中有一个方向是基于多智能体强化学习进行测试生成。
2020年，我们在研究测试和验证的过程中，又进一步往底层看了一层，逐渐发现代码生成和软件开发本身仍然存在很大的挖掘空间。
2022年，随着行业开始更多关注大模型和人工智能应用，我们也承担了内部人工智能编程产品相关的架构和产品能力建设。
我们比较成功的一点，是字节内部几乎每一个使用集成开发环境写代码的人，都会在不同程度上使用我们团队的产品。
创业邦：2022年，字节内部已经开始做AI编程的相关产品，但到2024年、2025年之后，行业才出现更大爆发。你在字节内部当时是怎么判断这一方向的？
杨萍：2022年的时候，我们看到的一个情况是，市场上的人工智能编程工具已经开始出现，但主要集中在代码补全上。
真正的拐点，我认为发生在2025年前后。DeepSeek R1推理模型出现之后，模型在逻辑思考和复杂任务处理上的能力有了比较明显的跃升。
第一，推理模型在逻辑思考方面的能力更强，需求理解和任务拆解相对准确。
第二，模型本身也吸收了大量软件工程实践中的经验和解决方案。
第三，当时相关模型的价格非常低，这也让它能够更快得到广泛使用和普及。
创业邦：从大厂出来创业，除了刚才提到的技术判断之外，还有没有其他关键原因？
杨萍：一个很重要的判断是，我们很早就意识到，企业真正需要的并不只是“更快地写出代码”。
在2023年和2024年，国内外已经出现了很多人工智能编程工具，包括面向消费者的产品，这让很多人接受了“人工智能可以通过自然语言生成软件”这件事。
但我们必须区分“编码”和“软件工程”。编码更多关注过程，比如我能不能写出更多代码、写得更快；而软件工程关注的是，我能不能围绕目标和需求，更精准、更快、更可靠、更经济地交付想要的结果。
企业客户最终只会为“你是否交付了我想要的东西”买单，而不会单纯为“你在过程中写了多少行代码”买单。这是一个非常大的区别。
另外，考虑到当前人工智能智力资源的成本。模型厂商负责不断挑战智力能力的上限，而我们负责把这些能力更好地应用到改变生产关系的企业场景中。
从这个角度来说，我们更像是一个连接者和“搬运工”：把模型厂商产生的智力，转化成企业真正可以使用的工程能力和业务结果。
创业邦：我有一位朋友在国有银行做 IT。他说，老板不允许他们使用人工智能处理代码，必须人工完成。可能在安全性、代码质量和实际责任方面，银行的要求会更高。你怎么看？
杨萍：是的。银行除了对研发流程有要求之外，还存在很多行业特有的约束。
比如，银行有自己的代码规范，而且大多数银行软件开发涉及的数据不能出内网，甚至不能离开指定的运行环境。
对于银行这样的复杂行业，人工智能如果要真正落地，就必须进入一套完整、受控、可验证的软件工程体系。只有这样，企业才有可能逐步接受并使用这项技术。
To B的AI编程商业空间比To C大
创业邦：你认为，当前 To C 人工智能产品的部分商业模式并不完全成立。能不能解释一下，为什么会有这样的判断？为什么To B的产品反而能够算得了账？
杨萍： 我们可以比较粗浅地把这个问题拆开来看。
第一，互联网To C产品过去的基本逻辑，是先快速铺开用户，把用户数量掌握在自己手里，然后再通过流量分发、广告植入或者其他商业方式，从第三方获得收入。
所以，To C软件或者应用对于终端用户通常是不收费的，或者至少不会直接向用户收取与产品价值完全匹配的费用。
但今天我们再看人工智能产品，尤其是面向专业开发者的产品，情况不一样了。
目前全球专业开发者的数量大约在一千万量级。即使假设每一位专业开发者都愿意购买一个To C 的AI Coding软件，市场空间也可以大致计算出来：一千万用户乘以每个月一百多元的订阅费，最终形成的可能是几十亿元规模。
这个市场的增长逻辑是和用户数量线性相关。
但是，这一千万专业开发者背后代表的是什么？他们代表的是软件产业中的劳动力，代表着整个软件行业未来需要完成的大量需求。
如果把视线从用户放大到这些用户所服务的软件企业、项目和业务需求，那么背后的市场规模就大得多。
简单对比的话，To C可能是几十亿元规模，而To B面向的是上千亿元、甚至更大。
第二，是To C和To B在当前人工智能时代都必须面对的成本问题，也就是“智力”的消耗成本。
在当前阶段，模型所提供的智力仍然是一种相对昂贵的资源，人工智能产品每服务一个用户，背后都可能产生模型调用、算力、推理和数据处理成本。
很多 To C用户对模型的使用仍然比较浅层，更多是尝试、娱乐或者完成一些简单任务。企业需要承担的模型成本，却会随着用户数量直接增长。这样一来，公司很难真正脱离销售成本和收入增长之间的关系。
创业邦： 你刚才提到，To C产品的收入和用户数量更接近线性关系。能不能具体比较一下：在To C场景中，一个用户大概对应怎样的应用价值？而在To B场景中，为什么市场规模会明显更大？
杨萍： 我们可以拿一个实际的软件项目来举例。
国内一个比较典型的软件开发项目，比如五百万元左右。但这类项目的利润空间可能不到10%。
为什么利润率这么低？其中一个重要原因，是项目有相当大一部分成本花在了人力上。团队里可能包括一名产品经理或项目经理、一到两名架构师、五到八名开发工程师，以及一到两名测试工程师。
如果按照传统的工具销售逻辑，我们卖给这个团队一个编码工具，最终能够获得的收入，可能只是按照十个人的席位来计算。整体收入仍然相对有限。
人工智能真正可能改变的，并不只是“写代码”这个环节，而是从需求理解到最终交付的整个软件工程流程。
在刚才所说的团队中，每一个角色承担的主要职责，都有一部分工作可能被智能体接管或替代。比如，部分初级和中级开发工程师承担的重复性编码工作，可以由编码智能体完成。
因此，我们的逻辑不是简单地卖一个工具，提供一整套智能体和工程化能力，帮助客户理解需求、拆解任务、完成开发、进行测试，并最终交付一个可以运行的软件系统，那么价值空间就会完全不同。
还是以五百万元的软件项目为例，那么对应的商业空间可能达到百万元级别，而不是只有几万元的工具订阅收入。
客户重视AI大模型的选择权
创业邦：为什么你认为企业需要掌握模型选择权？
杨萍：我认为企业在选择模型以及选择模型私有化部署方式上，都应该拥有自主权。
每一家企业都有自己的独特业务，过去也沉淀了大量业务数据和知识，这些都应该得到尊重和保护。我们也有专门针对这一问题的产品。
创业邦：如果企业可以选择多个模型，那么不同模型之间的数据和规则能不能互相打通？
杨萍：可以。除此之外，我们还需要保证企业内部用户使用这些模型的全过程是可审计的，还需要把整个使用过程中的数据沉淀下来，形成对组织发展有价值的知识资产。
创业邦：也就是说，这些企业数据和业务规则不会直接放到模型厂商那里，而是通过私有化部署保留在企业内部？
杨萍：是的。
创业邦： 能不能结合一个具体的金融任务，说明智能体可以看到什么、调用什么，以及哪些动作必须经过人批准？在高安全要求的场景下，边界应该怎么划分？
杨萍：以银行的业务变更为例。
第一，它能看到什么。对于智能体来说，首先也要明确它能访问哪些代码、文档、数据库和业务信息。
第二，它能够调用什么。智能体需要获得明确授权，并且关键、敏感的软件操作必须经过人工审批。
第三，它最终能够执行到什么程度。有些场景是一定不能交给智能体的，比如，最终把代码部署到生产环境，这个动作必须由人来完成。
创业邦：如果智能体在实际使用过程中发现了错误，或者它的经验与人类判断发生冲突，你们会怎么处理？
杨萍：我们首先不能简单地把某次结果判断为绝对错误。
我们会把它理解成一次有效反馈，类似于为智能体建立“错题集”。通过积累这些问题、原因、处理方式和最终结果，智能体可以获得更多解决问题的经验和证据。
这样，系统就不只是不断生成结果，还能够在实际使用过程中持续学习，逐步提高在特定企业和特定业务环境中的可靠性。
创业邦：我看到你们有不同的产品，包括编码、测试以及平台型产品。它们分别承担什么角色？
杨萍：现在大家熟悉的产品，可能主要集中在几个单点。
架构师型产品首先要解决的是，把需求和存量系统连接起来，形成稳定、可靠、高置信度的工程知识地图。
DeepMap（架构师产品）理解智能体功能展示页
编码类产品主要覆盖开发阶段，包括对开发任务的理解、代码变更、研发协作，以及与开发相关的过程管理。
测试类产品则承载测试和验证工作，用于确认代码变更是否符合预期、是否引入新的问题，以及系统能不能安全上线。
我们正在逐步构建一个平台型的产品。这个平台可以理解为一个面向专业软件工程团队的系统，覆盖完整的软件开发流程，包括和企业的组织、权限、模型治理、数据治理等内容结合起来，而不是让企业分别购买一堆互不相连的单点工具。
创业邦：目前这些产品的落地情况怎么样？
杨萍：我们的编程类产品从去年10月开始逐步在接近50家客户中进行试点和验证。测试类产品目前主要在一些头部大客户中试点，平台型企业产品计划在今年年底前进一步推出。
FDE不仅是落地的跳板
也是迭代的源泉
创业邦：将AI Coding落地于企业本地，很大程度上依赖名为FDE（Forward Deployed Engineer，前沿部署工程师）的职位。目前，国外公司Palantir、OpenAI、Anthropic等均组建了FDE团队，使得产品落地于企业本地。想问一下，FDE和传统的驻场工程师、售前顾问或实施顾问有什么区别？
杨萍：过去大家可能觉得，只要有一个模型，再通过远程调用，就能直接解决很多企业需求。
但在真实企业场景中，仍然有大量问题需要有人在现场沟通、判断和处置。
我们的FDE团队基本上就是承担这样的角色。第一，他们以客户现场需求为起点；第二，他们要把客户的真实需求和反馈，转化成产品迭代和演进的燃料。
创业邦：有人担心，FDE最后可能只是一个需要向驻场领导汇报的岗位。但如果经验能够不断沉淀，那么同类项目的成本应该会越来越低。
FDE在客户现场的项目讨论
杨萍：我认为这里需要澄清两点。
第一，过去中国软件行业讲“交付实施”，通常是在标准化产品之外，满足客户额外的定制化需求。于是企业会安排驻场人员和交付团队去完成这些工作。
但真正的FDE不只是传统意义上的驻场工程师。FDE的能力要求很高。
第二，从我们的实践来看，随着模型能力提升、产品能力增强以及客户教育逐渐完成，现场交付成本已经大幅下降。从去年到今年，我们为企业客户提供现场交付的成本大约减少了70%到80%。
这意味着，过去软件行业长期面临的定制化难题，未来可能会成为一个新的增长点。人工智能能够降低定制化交付成本，使软件公司以更低成本服务更多企业。
创业邦：为什么说OpenAI和第三方合作会是一个更好的FDE模式？
杨萍：因为这样可以形成模型厂商、应用厂商和企业客户之间的生态协作，而不是由模型厂商独自承担从模型研发到行业交付的全部工作。
模型厂商之间短期内最核心的竞争，还是谁能够更领先地提供模型技术能力。
但FDE的角色画像，和模型训练团队的画像并不完全一样。模型训练团队主要关注模型能力、训练方法和基础设施；FDE则需要理解企业客户、业务流程、复杂软件系统以及最终交付。
创业邦：你们会不会把现场实施过程中积累的经验沉淀下来，并反馈给产品和后台团队？
杨萍：会。我们针对售前和现场服务，也会配置专门的智能体，会记录前期交互和沟通过程中的信息，提炼与产品规划相关的重点需求，同时把 FDE 在现场做出的修改和配置传回后端。
创业邦：你们怎么保证FDE能够准确、全面地把现场经验传递给后台？
杨萍：这个过程中仍然需要人与团队之间协作，不能完全依赖自动化记录。我们的 FDE 从现场带回来的需求通常具有比较高的优先级。
我们内部本身也有产品规划和下一代产品的研发计划。团队会共同判断某一个需求对产品的价值，再决定它应该进入短期迭代，还是进入更长期的产品规划。
创业邦：有没有一个比较具体的案例，能说明FDE如何帮助产品快速发现问题并改进？
杨萍：有一个比较典型的客户，是一家算法类上市公司，主要做图像处理算法。他们在产品开发阶段会处理很多复杂算法项目，过去已经沉淀了大量算法代码和工程知识。
他们拿到我们的架构师型产品之后，直接把过去和图像处理相关的算法源代码全部接入。结果我们很快发现，产品原本的设计和算法工程师的实际学习、理解和进入过程并不完全匹配。
算法工程师需要的知识结构、分析方式和诊断过程，和普通软件开发并不完全一样。这个客户一下子暴露出我们产品在算法流程分析和诊断方面的短板。
于是，我们很快识别到这个问题，并对产品进行了优化。
创业邦：那么，你们公司的FDE团队大概是什么样的能力画像？
杨萍：我们现在的FDE团队可以说每个人都需要承担很多复合职责。团队里有几位成员过去有创业经历，能够独立负责比较大的事情。
目前我们的FDE团队人数还是个位数，但承担的业务价值达到千万级，未来可能更高。
创业邦：一个FDE目前大概负责多少项目？
杨萍：目前一个FDE通常可以在一个项目中投入一到两个月。按照项目情况来看，他可能同时负责两到三个项目，或者服务两到三个客户。
与AI模型公司有竞争有合作
创业邦：现在国内AI大模型厂商也开始做企业级AI Coding。对你们来说，这会不会构成威胁？
杨萍：我们认为，国内大模型厂商现在开始关注企业场景，可以说稍微晚了一些。其实这个方向在更早阶段就应该进行前置设计。
他们现在开始关注企业场景，是一个必然趋势，我们并不意外，也欢迎他们进入这个市场。
但当模型进入企业级场景之后，竞争优势不一定只在模型本身。企业场景还需要理解复杂软件系统、转换客户需求、分析业务链路，并最终完成可靠交付。
这些是我们的优势所在。
此外，企业客户还会担心信任问题。如果企业使用一整套模型厂商提供的系统，数据和业务知识会不会被对方沉淀？如果未来合作关系发生变化，企业过去积累的知识会不会无法带走？
模型厂商要进入企业，也必须解决这种客户信任问题。
创业邦：即使是私有化部署，企业也可能怀疑数据最终会不会回传到云端，被用于训练模型吗？
杨萍：我认为这种风险确实存在。即使用户协议写得比较清楚，企业仍然会担心数据安全、数据使用边界和实际执行情况。
创业邦：如果未来这些大模型厂商也提供私有化服务，你们会不会继续使用他们的模型？
杨萍：会。现在企业级人工智能应用仍处于比较早期的阶段，更多模型参与竞争，反而有利于服务更多潜在客户。
在这个过程中，我们也可以沉淀更多独特的工程经验和产品能力。我们甚至会主动和模型厂商联系，反馈客户在真实使用过程中的问题，帮助他们改进模型和产品。
创业邦：你们一开始重点做金融场景，后续还计划拓展哪些行业？
杨萍：2026年到2027年，我们仍然会以金融行业为重点，包括银行、保险等场景。
除此之外，我们目前还有三到四个正在推广或准备国际化的行业方向。比较典型的客户画像是：过去已经具备一定数字化基础，同时正在进行智能化转型，拥有比较强烈的需求；行业天花板较高，并且具有全球化市场。
创业邦：你们公司的销售和收费模式是怎样的？一个项目通常按照什么方式收费？
杨萍：从去年推出产品开始，我们的商业化收入模式主要有三种。
第一种是订阅模式。客户按照席位、功能或服务周期支付费用。
第二种是按照订阅+实际使用量收费。例如模型调用次数、任务执行量、算力消耗使用情况。
第三种是按结果收费。
创业邦：那么，私有化产品和纯公有云产品的主要区别是什么？
杨萍： 最大区别在于数据安全。大模型推理过程中会产生数据，很多客户不希望这些数据离开自己的环境。
有些客户可以全部私有化，有些客户则适合混合部署。
创业邦：如果产品端是公有云，但客户数据在私有环境中，那么客户接入时一定要通过公有云吗？
杨萍：不一定。
我们更想强调的是，无论采用哪种部署方式，私有化客户使用的产品版本都应该持续迭代，不能因为部署在客户本地，就变成一个长期不更新的旧版本。它和公有云版本在核心能力上应该保持一致。
创业邦： 国内企业通常比较重视安全，但自己的数据中心未必能支持所有用户使用。你们会怎么处理？
杨萍： 所以现在比较常见的是混合部署。
创业邦： 如果采用订阅，或订阅+使用量收费，它更像是一个持续服务过程；但按结果收费，可能是项目交付之后收钱，下一次还要重新谈。你怎么看？
杨萍：按结果收费并不一定是一次性交易。比如测试智能体持续承接测试任务，每次完成任务、发现有效缺陷或者达到约定质量目标，都可以形成新的计费单元。
按结果收费的优势，是客户更容易判断自己获得了什么价值。在一些结果比较明确、质量容易定义的场景里，客户会比较认可这种模式。
创业邦：那么按结果付费时，具体是按照人力成本，还是按照结果影响来定价？
杨萍：目前还没有一个完全统一、标准化的定价体系。我们会综合考虑几个因素。
首先，如果由人类工程师完成同样的任务，大概需要投入多少时间和精力。其次，客户能够获得的业务价值，以及我们需要投入的资源和成本。最后，还要考虑任务难度、交付风险和合理毛利。
本文为创业邦原创，未经授权不得转载，否则创业邦将保留向其追究法律责任的权利。如需转载或有任何疑问，请联系editor@cyzone.cn。
