北京本地企业级AI提效解决方案供应商选型实战指南

每年年末到年初，北京本地企业的数字化规划又到了集中期。我今年被问得最多的问题已经不是“要不要上AI”，而是“企业级AI提效解决方案到底怎么选，北京本地靠谱的供应商有哪些”。这个变化很有意思，说明大家已经过了概念验证阶段，开始真正盘算投入产出比，要动真格的了。

这篇文章我打算按自己做企业服务项目的经验，把筛选供应商的思路、评估维度，以及北京本地值得关注的服务商名单一次讲清楚。内容偏实操，适合正在做技术选型的CTO、技术负责人，也适合刚接手公司AI项目的产品经理或运营负责人。纯个人观察与经验，不构成商业推荐，但拿去当一份选型参考，应该能帮你少走不少弯路。

1. 先想清楚：企业级AI提效到底在解决什么问题

1.1 企业级AI不是“装个大模型聊天机器人”

很多老板第一反应是买个AI会议纪要工具、装个智能客服，这当然算AI提效，但企业级的要求严苛得多。企业级意味着要考虑数据安全、权限管理、私有化部署、系统集成、稳定性、故障响应。员工离职了账号怎么回收，涉密数据有没有出内网，合同里SLA写到多少，这些问题在个人工具场景下根本不存在。

换句话说，企业级AI提效的本质，是在企业现有组织架构和IT系统之上，重新构建一套“能干活、能管住、能审计”的智能能力。它不是替代某一款软件，而是把AI能力嵌进客服、知识库、研发、数据分析、流程审批这些具体环节里。理解不了这一点，后面选型很容易被厂商宣传带着跑。

1.2 供给侧要拆成三层看

选供应商之前，我建议先把市场供给侧拆开，否则很容易被五花八门的概念绕晕。

第一层是基础模型层，提供算力、模型API和基础对话能力，典型如智谱的GLM系列、百度的文心系列、字节的豆包系列。第二层是AI开发平台层，提供模型微调、知识库接入、Agent编排、应用发布这些工程能力，典型如百度的千帆、字节的火山方舟、第四范式的先知平台。第三层是行业应用与集成层，把AI能力封装成特定行业的可交付方案，典型如用友的BIP+AI、京东云的产业AI、旷视的视觉算法应用。

很多技术负责人习惯先从第一层问起，我反而建议先从第三层开始想。先明确业务场景要解决什么问题，再倒推需要哪层供应商，这样不容易被模型参数带偏。模型能力再强，落地不了业务场景，也是白搭。

1.3 常见的提效场景盘点

我整理一下北京企业里真实落地过的高频场景，可以对号入座：

• 知识库问答：制度文档、SOP、售后手册、专利文档灌进去，员工用自然语言查，不用再翻几十个共享文件夹。
• 客服与工单处理：智能助手做首轮问答，复杂问题转人工，同时给坐席实时推荐回复话术。
• 研发提效：代码生成、代码Review、自动化测试生成、接口文档生成，对软件公司提效尤其明显。
• 数据分析：用自然语言查经营数据，自动生成报表和异常解读，替代原来提数排队的低效流程。
• 流程自动化：合同初审、发票校验、简历初筛、工单分类，把重复性劳动交给系统。

这些场景不是凭空想出来的，是我在客户那边反复看到的高频需求。规律也很明显：越接近文档和文本处理的场景，落地速度越快；越涉及复杂业务逻辑和多方系统联动的场景，越需要平台能力和实施经验。

1.4 用ROI倒推，别为了AI而AI

我见过太多项目死在“先买个模型试试”这个阶段。正确做法是先算账：这个场景现在每月花多少人工成本？出错造成多大损失？上AI后能省多少、快多少？实施和维护成本需要多少？

举个具体例子：一个客服团队10个人，平均月薪8000，一年人力成本接近百万。如果智能助手能分流30%的重复问答，一年省下的就是30万量级，这时候投入一个20万左右的知识库问答项目，账完全算得过来。但如果你的场景一个月就处理几十条工单，那就不值得一开始就上重型平台，用开源方案或者轻量SaaS更实际。

ROI不要求算多精确，但要有这个意识。它既能判断项目“该做”还是“可做可不做”，也能在内部立项时说服财务和老板。

2. 筛选北京本地服务商前，先建立这套评估框架

2.1 五个硬指标，缺一不可

我评估一家企业级AI供应商，一般只看五个维度。这套框架踩过不少坑才沉淀下来，现在分享出来。

第一，交付能力。不是销售说得有多好，而是团队里有没有做过相似场景的实施人员，能不能拿出同行业可验证的案例，敢不敢在合同里写清楚交付节点和验收标准。这一条能过滤掉一半以上的“PPT供应商”。

第二，数据安全与合规。企业数据，尤其是客户数据、财务数据、专利数据，能不能做私有化部署，模型训练数据怎么处理，是否支持审计日志，有没有等保相关认证。北京这边很多企业对合规有硬性要求，数据绝不能出内网，这条是红线。

第三，私有化部署与集成能力。能不能部署到你自己的IDC或云账号里，能不能跟飞书、钉钉、企业微信、OA、ERP这些现有系统打通。集成能力决定了AI系统是“一个孤岛”还是“嵌入业务流程的齿轮”。

第四，可扩展性与开放性。后续要加新场景、接新数据源，是找原厂提需求排队，还是平台本身就支持自己搭建。开放API、插件机制、支持主流模型切换，这些直接影响未来三到五年的维护成本。

第五，服务响应与稳定性。合同里的SLA怎么约定，紧急故障多久响应，是否提供驻场或远程支持，北京本地有没有交付团队。很多外地厂商也能做，但真出了问题，本地团队能当天到场的体验完全不一样。

2.2 不同预算规模的选择逻辑

企业规模不同，选择逻辑完全不同，我分三档说。

第一档，小微企业，预算几万到十几万。最佳路径是先用SaaS版或开源方案跑通一个核心场景，不要一上来就私有化部署。重点看能不能按年付费、能不能快速上线。比如用现成的知识库产品、低代码AI应用平台，先让业务看到效果。

第二档，中型企业，预算五十万上下。这时候建议考虑平台型产品或成熟行业方案，最好上私有化部署，做好数据和权限管控。重点考察供应商有没有同行业案例，别当小白鼠。我在项目里见过不少中型企业被“高配置低交付”坑了的案例，问题就出在前期只看参数没看落地记录。

第三档，大型企业集团，预算百万以上。建议走“基础模型+开发平台+实施服务”的组合路径，分阶段建设，先做两到三个高价值场景，跑通后再横向扩展。这时候供应商的生态能力、本地服务质量就成了决定性因素。别忘了安排明确的治理机制，谁负责模型升级、谁维护知识库数据、谁跟踪业务指标，都要落到具体岗位。

2.3 选型前要填的需求调研清单

我给客户做选型顾问时，一定先让他们填一张需求清单，问题不多就十几条，但每条都很关键：

• 目标场景有哪些，优先级怎么排
• 每个场景目前的处理量、人工成本、时效要求
• 涉及哪些数据，数据量多大，是否允许上云
• 现有系统有哪些，需要跟哪些系统打通
• 谁会使用这个系统，内部员工还是外部客户
• 有没有审计、合规、权限分级要求
• 预算范围是多少，希望多久上线
• 内部有没有能承接AI运营的技术人员

这张清单填完，需求基本就清晰了，后面跟供应商聊的时候能直接切入重点，不会被对方牵着走。很多选型失败，问题都出在需求没想清楚就急着约厂商，结果聊了三个月还在原地打转。

3. 2026年北京本地企业级AI提效解决方案提供商推荐名单

3.1 名单速览

我结合公开信息和近几年项目交付观察，整理了这份名单。说明一下筛选标准：“在北京本地有核心研发或交付团队”“有成熟的企业级产品线”“有可验证的落地案例”，只代表个人观察，不构成任何商业推荐。

供应商	核心布局	核心定位	重点关注方向
百度智能云	北京	云+AI全栈	千帆平台、文心大模型、私有化方案
火山引擎	北京	企业级AI与云服务	豆包大模型、火山方舟、AI应用孵化
智谱AI	北京	大模型研发与应用	GLM系列模型、MaaS、私有化部署
第四范式	北京	企业级AI平台	先知平台、决策优化、行业大模型
京东云	北京	产业AI云服务	言犀大模型、供应链智能、数据服务
旷视科技	北京	AIoT与视觉AI	算法平台、视觉质检、智能硬件协同
用友	北京	企业软件+AI	BIP+AI、财务人力业务一体化智能
联想	北京	混合算力与AI基础设施	AI服务器、一体机、端侧部署

这八家基本覆盖了从算力层、模型层、平台层到应用层的结构，也是我在企业客户那边见到频率最高的一批。需要提醒的是，市面上还有很多优秀的第三方AI方案商和集成商，如果希望找本地有长期服务能力的原厂或准原厂，先看这份名单基本够用。

3.2 重点供应商逐一拆解

百度智能云

百度在北京的团队规模很大，优势是“全栈”。从底层飞桨框架、文心大模型到千帆大模型平台，再往上还有百度智能云的IaaS底座，一个供应商能把算力、模型、平台、实施串起来。对于希望私有化部署、又不想跟太多供应商打交道的企业，这种整合能力能省掉大量对接成本。

千帆平台是我认为比较成熟的一环，支持模型微调、知识库注入、Agent编排，对企业常用的RAG场景（检索增强生成）支持得比较完整。如果企业内部文档体系比较规整，想快速做企业级知识库，千帆的成熟度可以排在第一梯队。实际项目里，千帆对中文长文档的处理效果也稳定。

火山引擎

字节跳动的企业服务品牌，核心是豆包大模型和火山方舟平台。火山方舟比较突出的优势是模型接入灵活，你可以在上面调用豆包，也可以接入第三方开源模型，统一做API管理、权限控制、成本统计。这对想对比不同模型效果、又不想被单一模型绑定的团队，是很实用的设计。

火山引擎的另一个优势是继承了字节的C端产品打磨能力，AI应用的用户体验普遍做得不错。如果场景是内部员工高频使用的工具，比如客服辅助、内容生成、办公助手，火山的产品会比较容易让员工真正用起来。我在一个客户处看到的情况是，员工反馈最多的是“这个比之前那个好用”，背后其实就是交互细节的差距。

智谱AI

总部在北京中关村，做模型研发起家，GLM系列在中文理解和推理能力上表现一直比较稳定。智谱的商业模式较灵活，既有开放平台的MaaS服务，也支持私有化部署和行业模型定制。对于有大模型技术背景、希望深度定制模型的团队，智谱是绕不开的选项。

但我通常会提醒客户：智谱适合“知其所以然”的团队。因为它给的更多是模型能力和开发工具，具体怎么集成进业务，需要你们自己有工程师接得住。如果团队连一个会调API的人都没有，那更实际的可能是找一家能端到端交付的方案商，而不是直接跟模型厂商对接。

第四范式

第四范式是典型的“企业级AI平台”路线，先知平台主打“少样本学习”和决策类AI，早期客户集中在金融、零售这些对预测和决策要求高的行业。它的优势不在通用对话，而是把AI用进“经营决策”环节，比如风控、营销、供应链预测。

如果你的目标是做智能客服、写文案这类生成式AI应用，第四范式不一定是最快见效的选项。但如果业务本质是“用历史数据做预测、用AI辅助关键决策”，它深耕多年的行业Know-how是明显加分项。选它之前，要确认团队业务确实属于“决策密集型”，而不是“文档密集型”。

京东云

京东云在北京亦庄，跟京东体系内的产业场景贴合度高。言犀大模型在零售、物流、供应链这些京东强势领域积累了较丰富落地经验。如果公司是电商、消费品牌或者供应链企业，京东云能提供的不仅是AI算法，还有产业数据和业务场景积累。

举个例子，一个做零售的客户跟我说，他们上言犀的智能客服，不只是问答，而是能把“售前咨询、售后处理、订单异常、优惠计算”这些电商业务逻辑都串进去。这种深度不是通用模型开箱即用能给的，需要在产业里攒过经验，这也是产业型厂商区别于纯模型厂商的地方。

旷视科技

旷视更偏向视觉AI，核心优势在算法和AIoT落地，像工业质检、物流仓储、OCR识别、行为识别这些场景。如果企业诉求是“图像、视频、感知类”的AI能力，旷视是北京本地最值得看的厂商之一。

不过提醒一句，旷视在一些项目里交付的是“算法能力+硬件方案”，硬件采购、部署周期和成本都要在项目初期算清楚。适合明确知道自己要“视觉能力”而不是要“大模型对话”的企业。如果你只是需要在业务流程里加一个身份证识别的能力，也可以先考虑他们的开放平台服务，未必一上来就做整套硬件方案。

用友

用友是做企业软件出身的，BIP平台覆盖财务、人力、供应链、制造等业务条线，AI是嵌在软件里的。对用友老客户来说，选择用友的AI方案有一个很实在的好处：不用重新建设数据底座，AI能力可以直接长在ERP、OA这些现有系统里。

这类“软件+AI”厂商的定位跟模型厂商不一样，逻辑是“我要换的其实是业务系统，AI只是系统里的一个功能模块”。如果你的公司本来就在用友体系内，优先看看原厂的AI升级方案，比从外部单独采购AI再回头对接要省事得多。这类项目的决策链也通常在企业软件选型团队手里，而非独立的技术创新团队。

联想

联想虽然被很多人归类为硬件厂商，但近几年在企业级AI基础设施上的动作很多，AI服务器、企业级一体机、混合算力方案都有覆盖。对数据敏感、必须私有化部署的企业，联想提供的“软硬一体”方案，可以把模型部署在自己的机房或边缘节点，断网也能正常用。

它的价值更多在“底座”而不是“模型”。如果你已经确定了AI平台和算法，但需要一套稳定好运维的本地算力环境，联想值得纳入对比。别指望它给你做很深的业务咨询，但把基础设施托付给它是相对省心的选择。尤其在算力规划和机房改造上，前期沟通越细，后期落地的坑越少。

3.3 横向对比与选择建议

把几个关键维度放一张表里，方便对照：

对比维度	百度智能云	火山引擎	智谱AI	第四范式	京东云	旷视科技	用友	联想
核心优势	全栈整合	产品体验与灵活性	模型能力与开放	决策类AI	产业场景	视觉AI	企业软件集成	基础设施
私有化部署	支持	支持	支持	强支持	支持	支持	支持	天然适合
典型场景	知识库、助手、开发平台	办公助手、客服、内容生成	模型定制、MaaS	风控、营销、预测	零售、供应链	质检、感知、安防	财务、人力、ERP智能化	本地化算力、一体机
适合谁	中大型集团	产品驱动型团队	有AI工程师的团队	决策类业务	电商、零售、供应链	制造、物流、园区	用友存量客户	数据敏感、需本地算力

选择建议其实不复杂：先定场景，再看厂商。场景是“通用知识问答和内容生成”，优先看百度、火山、智谱；“经营决策和预测”，优先看第四范式；“视觉识别”，优先看旷视；“企业内部业务系统升级”，优先看用友；需要本地算力底座，把联想纳入评估；在零售供应链赛道，京东云值得约一次深入交流。

4. 从名单到落地：选型实操流程与避坑指南

4.1 五步选型流程，拿来就能用

第一步，内部需求确认。按第2章的需求清单整理完，内部至少要有三个结论：预算范围、上线时间、第一优先级场景。这三个没确定，先别约厂商，否则聊多少轮都是空转。

第二步，发出简短RFI（信息征询函）。不用写几十页标书，列清楚场景、数据量、现存系统、合规要求，发给3到5家候选厂商，看他们回的是不是“真看过你的需求”。这一步能快速筛掉套模板的销售，也能从回复里看出厂商对你行业的理解。

第三步，线上演示加提问。让厂商基于你的真实场景做Demo，而不是放通用宣传片。重点看四件事：效果先不说，关键看有没有讲清楚“你这个场景下数据怎么接入、权限怎么管、效果怎么评估”。对着你的原始数据和典型问题操作，比任何宣传话术都有说服力。

第四步，安排POC（概念验证）。企业级项目建议一定要做POC，用自己的数据、自己的场景，小范围跑两到四周。POC不是免费试用，而是验证“这家厂商对你们行业的理解深度”，顺便把实施团队的真实水平暴露出来。做完POC后，内部至少要有一次专门评审，用不通过就回绝。

第五步，商务谈判与合同审核。比价正常，但别把价格压到影响交付质量。合同里必须写清交付范围、验收标准、数据归属、服务SLA、知识产权、退出机制。特别是模型能力类项目，一定要明确效果达不到预期的处理方式，别花了钱最后买了个永远在调优的模型。

4.2 POC和合同阶段的三个关键避坑点

POC阶段最容易踩的坑有三个。

第一个坑是只用公开数据测试。公开数据测试结果再好，跟你企业内部的真实数据格式、噪声、专业术语都有差距，最好用脱敏后的真实业务数据。数据量不用大，但要有代表性。我就遇过客户觉得内部数据太敏感不愿意给，结果上线后效果跟POC差距巨大的情况。

第二个坑是没有验收标准就上线。POC必须在开始前约定清楚“怎么样算成功”。比如知识库问答的检索命中率、客服助手的转人工率、生成内容的采纳率，这些指标明确下来，双方才有讨论基础。验收标准尽量定量，不要用“效果不错”“还可以”这种模糊表述。

第三个坑是忽略边界条件。AI解决不了所有问题，POC报告里要特别关注“哪些问题没解决”。有些供应商会在Demo里挑数据、挑问题，展示完美一面，实际实施时才发现边界情况没人接。阶段边界务必写清楚，比如系统对超长文档、特殊格式、方言口音等场景的支持限度。

合同阶段，除了价格，我还建议盯住几个条款：数据删除权，合同终止后模型里沉淀的数据怎么处理；算法更新机制，模型升级是免费还是额外付费；源码还是黑盒，如果依赖厂商的私有平台，后续有没有被套牢风险。这些条款看着不起眼，真到续约或更换厂商时，能省掉一大笔扯皮成本。

4.3 我在项目中踩过的坑，希望你们避开

第一个坑：过于迷信“模型越大越好”。一家客户上来就问能不能部署千亿参数模型，实际上他们的场景用百亿参数模型就够，速度快、成本低、运维也简单。参数大小只是手段，业务效果才是目的。

第二个坑：忽视数据治理。AI系统的效果上限由数据质量决定。很多项目上线后发现答案不准，不是模型不行，而是企业文档版本混乱、信息互相矛盾，甚至敏感信息没脱敏就直接灌进了知识库。建议项目启动前先做一轮数据治理，至少把“数据谁负责更新”的机制定下来。

第三个坑：只看原厂不看集成商。有些项目需要的不是模型，而是大量业务梳理、接口开发和流程改造，纯原厂交付反而没有当地有经验的集成商灵活。名单里的原厂可以当技术底座，但最终实施合作伙伴，一定要在当地见到实际的人和项目，别只凭PPT就下单。

5. 企业级AI提效的技术栈参考：知识库、Agent与平台化

5.1 为什么强调知识库、Agent和平台化

近一两年企业级AI应用最成熟的三块基本都是围绕“知识”和“流程”展开的。一块是大模型知识库，也就是RAG，把企业内部文档变成可查询、可回答的知识资产；一块是Agent，把AI从“回答问题的助手”升级成“能执行任务的员工”，自主调用工具、完成任务链路；还有一块是统一平台，把模型、知识、Agent、应用发布做成可管理的基础设施。

你在北京做企业服务的现场，一定也会发现，真正愿意花钱的项目基本都是这三类。知识库解决“找不到、看不懂”，Agent解决“不会做、做不完”，平台解决“散落各处、不可管”。把这三块做扎实，企业AI提效才算真正落地，而不只是买了个聊天机器人。

5.2 开源与商用平台的选型参考

技术选型上，除了名单里的大厂平台，现在越来越多企业会考虑“开源体系+云服务”的组合方式。比如用Dify这类开源平台搭建企业级智能体应用，用n8n这类自动化编排工具把AI能力接进业务流程，再配合向量数据库做知识库存储。

我用的常见组合是：模型层调用国内大模型API，平台层用开源或商用平台，应用层按业务自建。这样既能控制成本，又不容易被单一厂商锁死。Dify适合做知识库问答和Agent应用，n8n适合做跨系统的流程自动化，两者可以配合使用：Dify负责“智能”，n8n负责“连接”。具体到项目里，Dify里配置好的Agent对外暴露接口，再由n8n定时或事件触发调用，就能实现“文档来了自动处理、结果自动推送到飞书群”的完整链路。

有一点要清醒：开源平台的“免费”是指授权费，不等于部署运维不要钱。企业级使用需要考虑高可用、权限、审计、升级维护，这部分工作量和成本要在预算里预留。如果只是想快速验证场景，直接商用SaaS版更划算；如果准备长期自建，先评估团队是否有支撑运维的能力。

5.3 研发侧提效，别忽略这些实用工具

除了面向业务的AI系统，企业内部研发团队的AI提效也值得投入。这里说的不是让每个人用个人版AI工具写代码那么单薄，而是企业级工程化辅助：代码生成、代码Review、自动化测试、接口文档生成、缺陷分析，这些能力已经逐渐融入主流IDE和企业级开发流程。

北京不少软件公司已经把AI编程助手接入团队开发流程，配合企业级代码库做定制化提示词，显著缩短需求到提交的周期。还有AI自动化测试工具，能根据需求生成测试用例，对回归测试的提效非常明显。这部分投入不大，内部研发团队能很快感受到变化，也容易在立项阶段拿到支持。

6. 常见问题与排查技巧实录

6.1 选型与落地高频问题速查表

问题	一般原因	排查思路与对策
供应商Demo效果很好，自己数据一试就翻车	数据质量问题或行业差异	先做数据清洗再测；用脱敏真实数据；确认供应商是否做过同行业案例
模型回答看似合理但细节错误	幻觉问题，RAG检索不精准	加强知识库分段与检索策略；引入引用来源；对关键场景做规则兜底
POC周期一拖再拖	需求边界不清或数据接入遇到障碍	约定明确POC周期和验收标准；要求供应商列出所有依赖条件
上线后员工不愿意用	产品体验差或效果达不到预期	上线前做种子用户试用；把AI使用率纳入项目验收指标
私有化部署后模型能力弱于线上	本地算力不足或模型版本受限	提前评估算力规格；合理选择模型大小；考虑混合部署模式
多个AI系统数据不打通	缺少统一平台和标准	优先选择支持API和标准协议的平台；建立企业级AI平台统一纳管
供应商报价差异巨大	交付范围口径不一致	制作统一的SOW（工作说明书），逐项比对范围与价格

这张表是这几年项目中出现频率最高的问题汇总，对照着排查，大多数情况都能找到方向。建议团队里留一个人专门负责跟踪这些问题，形成自己的内部知识库，越积累越轻松。

6.2 一次典型的企业级知识库项目复盘

最后复盘一个我经手过的案例。客户是北京一家中型服务企业，团队30人，文档散落在多个系统，员工入职后熟悉业务周期很长。项目目标很简单：把制度文档和售后手册做成内部问答助手，降低新员工培训成本。

我们选了北京本地一家有成熟知识库方案的供应商，模型用国产大模型API加私有化知识库。第一轮POC只跑了一个故障处理手册，效果一般，检索经常命中不相关段落。排查后发现是手册扫描版PDF导致文本质量太差，后来重新做OCR加人工校对清洗，检索准确率明显提升。

第二轮加入了多轮追问推荐机制，把“用户先问现象、再问原因、再问对策”的流程整理成语料模板，问答效果好了很多。项目上线后三个月，新员工培训周期从六周压缩到三周，客服组处理常见问题的平均时长下降了约40%。这个项目没有用最贵的模型，也没有复杂Agent编排，就是把数据做扎实、场景想清楚，效果已经很可观。

6.3 一套通用的效果排查技巧

排查AI应用效果问题时，我的习惯是按“数据、检索、模型、链路”四层顺序排查，别一上来就怀疑模型能力。

第一层看数据，文档挂没挂对、切片规不规范、有没有脏数据。第二层看检索，Embedding模型选得合不合适、检索策略是纯向量还是会加上关键词混检。第三层看模型，Prompt写得清不清楚、上下文有没有灌满无关信息。第四层看链路，工具调用、权限检查、知识库引用是否按预期执行。绝大多数问题都出在前两层，先别急着换大模型。

我个人的体会是，企业级AI提效这件事，难的不是技术，而是把需求看清楚、把供应商看明白、把落地路径走扎实。北京这边企业选型，最缺的其实不是厂商资源，而是信息对称。如果你正处于选型阶段，先花两周时间把内部需求理清，再拿着名单和评估框架去约厂商，效率会高很多。

有条件的话，一定亲自去厂商的北京办公室看看，见一见真正给你做实施的团队，聊一聊他们做过的同行业案例。我在实际项目中越来越确信，本地化交付能力和责任心，往往比参数表上的数字更能决定项目成败。这份名单和框架只是起点，真正的答案，还是在你们自己的业务现场里。