飞书对接 openclaw 之后，只能收到群聊消息，收不到私聊消息怎么办？

参考：https://juejin.cn/post/7613691144618688563#heading-9

参考：https://open.feishu.cn/app/cli_a93b26167bb8dcb6/bot

我按照这个注意里面设置后，发现飞书的 openclaw 机器人可以在群聊里面正常对话，openclaw 机器人会回复消息；但是在单聊里面，发给 openclaw 机器人的，收不到任何的回复，去 openclaw logs 看日志也看不到任何的异常

怎么解决？其实是飞书这个「注意」写的太差了

按我下面的操作

到应用的「事件与回调」-「事件配置」-「已添加事件」的 im.message.receive_v1 里面把下面2个也改成「已开通」才行，默认是3个，这个地方很容易只开通了第一个，第二个没开通就会遇到单聊不行，群聊行的问题

如果单聊还是不行，且 openclaw 那边报如下的错误，继续往下看

17:18:30 info gateway/channels/feishu {"subsystem":"gateway/channels/feishu"} feishu[default]: received message from ou_f9e3073e00c242bcccf0b96969a15ef2 in oc_40ee0465cb8f0e04ae21ec10c18a24d9 (p2p)
17:18:30 info gateway/channels/feishu {"subsystem":"gateway/channels/feishu"} feishu[default]: pairing request sender=ou_f9e3073e00c242bcccf0b96969a15ef2
17:19:24 info [error]: [
  [
    {
      message: 'Request failed with status code 400',
      config: [Object],
      request: [Object],
      response: [Object]
    },
    {
      code: 99991672,
      msg: 'Access denied. One of the following scopes is required: [contact:contact.base:readonly, contact:contact:access_as_app, contact:contact:readonly, contact:contact:readonly_as_app].应用尚未开通所需的应用身份权限：[contact:contact.base:readonly, contact:contact:access_as_app, contact:contact:readonly, contact:contact:readonly_as_app]，点击链接申请并开通任一权限即可： `https://open.feishu.cn/app/cli_a93b26167bb8dcb6/auth?q=contact:contact.base:readonly,contact:contact:access_as_app,contact:contact:readonly,contact:contact:readonly_as_app&op_from=openapi&token_type=tenant` ',
      error: [Object],
      troubleshooter: '排查建议查看(Troubleshooting suggestions): `https://open.feishu.cn/search?from=openapi&log_id=20260312011924A9625AA0A1AF711472C0&code=99991672&method_id=6925375841992245275` ',
      permission_violations: [Array],
      message: 'Refer to the documentation to fix the error: `https://open.feishu.cn/document/uAjLw4CM/ugTN1YjL4UTN24CO1UjN/trouble-shooting/how-to-fix-the-99991672-error` ',
      log_id: '20260312011924A9625AA0A1AF711472C0'
    }
  ]
]
17:19:24 info gateway/channels/feishu {"subsystem":"gateway/channels/feishu"} feishu: ignoring stale permission scope error: Access denied. One of the following scopes is required: [contact:contact.base:readonly, contact:contact:access_as_app, contact:contact:readonly, contact:contact:readonly_as_app].应用尚未开通所需的应用身份权限：[contact:contact.base:readonly, contact:contact:access_as_app, contact:contact:readonly, contact:contact:readonly_as_app]，点击链接申请并开通任一权限即可： `https://open.feishu.cn/app/cli_a93b26167bb8dcb6/auth?q=contact:contact.base:readonly,contact:contact:access_as_app,contact:contact:readonly,contact:contact:readonly_as_app&op_from=openapi&token_type=tenant` 
17:19:24 info gateway/channels/feishu {"subsystem":"gateway/channels/feishu"} feishu[default]: received message from ou_f9e3073e00c242bcccf0b96969a15ef2 in oc_40ee0465cb8f0e04ae21ec10c18a24d9 (p2p)

去 「权限管理」把下图所示的 8 个权限都开通了：

• contact:contact.base:readonly
• contact:contact.base:readonly
• contact:user.base:readonly
• contact:user.id:readonly
• im:message
• im:message.group_at_msg:readonly
• im:message.group_msg
• im:message.p2p_msg:readonly
• im:message:recall

上面的步骤都做完之后，记得重新发布应用

具身智能正在经历从实验室走向产业化的关键转折点。长期以来,机器人操控模型面临着"一机一训"的困境——每换一个机器人本体、每增加一个新任务,都需要重新采集数据、重新训练模型,这种高昂的迁移成本严重制约了具身智能的规模化落地。

此次蚂蚁集团开源的 LingBot-VLA 具身大模型,为行业带来了三个重要突破:

首次验证了具身智能领域的 Scaling Law
通过 20,000 小时真实机器人数据的预训练,系统性证明了 VLA 模型性能随数据规模持续提升的规律。这一发现意义重大——它表明具身智能可以像大语言模型一样,通过"大数据+大模型"的范式实现能力跃迁,为行业指明了清晰的技术路线。
解决了跨本体泛化的核心难题
通过涵盖 9 种主流双臂机器人构型的大规模预训练,LingBot-VLA 实现了"一个大脑,多种身体"的愿景。在 GM-100 真机评测中,其跨本体泛化成功率达到 17.3%,这意味着同一个模型可以快速适配不同厂商的机器人硬件,大幅降低了商业化部署的门槛。
打造了真正实用的开源生态
不同于许多"只开源权重"的项目,LingBot-VLA 同步开放了数据处理、高效微调、自动化评估的全套工具链,训练效率达到主流框架的 1.5~2.8 倍。这种"开箱即用"的完整方案,将帮助开发者以更低成本快速落地自己的具身智能应用。
特别值得关注的是,LingBot-VLA 引入深度信息后的性能提升,体现了空间感知能力对机器人操控的重要性。结合昨日开源的 LingBot-Depth 模型,我们看到了一个清晰的技术演进路径:从精准的空间感知到智能的操控决策,具身智能正在构建起完整的"感知-认知-执行"闭环。

随着蚂蚁集团承诺未来几天将陆续开源更多具身智能成果,我们有理由相信,2026 年将成为具身智能从"能用"到"好用"、从"实验室"到"生产线"的关键转折年。

SegmentFault 思否编辑部
2026年1月

以下内容转载自蚂蚁灵波科技官方公众号。

继昨日开源高精度空间感知模型 LingBot-Depth 后，今天，我们为大家带来了具身大模型 LingBot-VLA。

LingBot-VLA 具身大模型全面开源

在上海交通大学开源的具身评测基准 GM-100（包含 100 项真实操作任务）测试中，LingBot-VLA 在 3 个不同的真实机器人平台上，跨本体泛化平均成功率相较于 Pi0.5 的 13.0% 提升至 15.7%（w/o Depth）。引入深度信息（w/ Depth）后，空间感知能力增强，平均成功率进一步攀升至 17.3%，展现了 LingBot-VLA 强大的准确性和泛化性。

在 GM-100 真机评测中，LingBot-VLA 跨本体泛化性能领先

在 RoboTwin 2.0 仿真基准（包含50项任务）评测中，面对高强度的环境随机化干扰（如光照、杂物、高度扰动），LingBot-VLA 凭借独特的可学习查询对齐机制，高度融合深度信息，操作成功率比 Pi0.5 提升了 9.92%，实现了从虚拟仿真到真实落地的全方位性能领跑。

在 RoboTwin 2.0 仿真评测中，LingBot-VLA 跨任务泛化性能领先

01 Scaling Law 下的大规模真机数据预训练
长期以来，由于本体差异、任务差异、环境差异等，具身智能模型落地面临严重的泛化性挑战。开发者往往需要针对不同硬件和不同任务重复采集大量数据进行后训练，直接抬高了落地成本，也使行业难以形成可规模化复制的交付路径。
图片
针对上述问题，我们基于在海量真实世界数据上的预训练，第一次系统研究了 VLA 模型在真实机器人任务性能上随着数据规模增长时的 Scaling Law。项目发现随着预训练数据规模从 3,000 小时扩展到 6,000、13,000、18,000，最终至 20,000 小时，模型在下游任务的成功率获得持续且显著的提升。值得注意的是，预训练数据量达到 20,000 小时时，模型性能仍呈现上升趋势，表明 VLA 的性能仍然能够随着数据量的增加而提升。这些实验结果证明了 VLA 模型在用真实数据预训练时呈现了良好的可扩展性，为未来的 VLA 开发和大规模数据挖掘提供了重要启示。
图片
依此研究结果，我们仔细构造了 20,000 小时的真实机器人训练数据，涵盖了 9 种主流的双臂机器人构型（包括 AgileX Cobot Magic，Galaxea R1Pro、R1Lite 、AgiBot G1等）。为了进行精确的数据标注，数据里的视频由人工标注者按原子动作进行切分，并用大模型标注视频对应任务和子任务。在 codebase 的开发中，适配了 Fully Sharded Data Parallel (FSDP) 分布式、混合精度、算子融合等优化，从而让同一个“大脑”可以快速迁移至不同形态的机器人上，并在任务变化、环境变化时保持可用的成功率与鲁棒性。

02 深度信息辅助的机器人操控性能提升

仿真实验结果

为了显式捕捉操控环境中的空间感知能力，并进一步提升机器人执行的鲁棒性，我们采用了一种基于查询向量（query）的深度蒸馏方法。具体而言，我们引入了与三视角操作图像相对应的可学习 queries，这些 queries 经 VLM 处理后，与 LingBot-Depth 输出的 depth embeddings 进行对齐。这种对齐机制在维持模型训练与推理的效率的同时，有效将深度信息集成到 LingBot-VLA 中。在真实机器人平台和仿真环境下进行的广泛实验证明，深度信息的融入提升了 LingBot-VLA 的操控性能。

03 后训练成本低、效率高、代码全开源，真正实用的 VLA 模型
得益于涵盖主流构型和详尽任务的大规模预训练，LingBot-VLA 具备强大的通用操控能力，并且能够将其高效迁移到多样的下游机器人任务中。实验表明，LingBot-VLA 在下游任务中能够使用更少的数据，达到超越 π0.5 的性能；并且性能优势会随着数据量的增加而持续扩大。目前，LingBot-VLA 已与星海图、松灵、乐聚等知名机器人厂商完成适配，验证了模型在不同构型机器人上的跨本体迁移能力。

与此同时，我们构建了一套高效的后训练工具链，在 8 卡 GPU 配置下实现了单卡每秒 261 个样本的吞吐量，其训练效率达到 StarVLA、OpenPI 等主流框架的 1.5~2.8 倍，实现了数据与算力成本的双重降低。此次开源，我们不仅提供了模型权重，还同步开放了包含数据处理、高效微调及自动化评估在内的全套代码库。我们希望这一举措可以大幅压缩模型训练周期，降低商业化落地的算力与时间门槛，助力开发者以更低成本快速适配自有场景，提升模型实用性。目前我们的模型、后训练代码、技术报告、以及我们和上海交大共同打造的 GM-100 Benchmark 已全部开源，欢迎大家访问我们的开源仓库。

具身智能的大规模应用依赖高效的具身大模型，这直接决定了模型是否可用以及能否用得起。我们希望通过 LingBot-VLA 的开源，积极探索具身智能上限，推进具身智能研发早日进入可复用、可验证、可规模化落地的新阶段。

本周，我们已相继开源 LingBot-Depth 和 LingBot-VLA 两款模型，未来几天，我们还将陆续为大家带来我们在具身智能领域智能基座方向的更多成果。我们期待与全球开发者、研究者、产业伙伴一起，加速具身智能技术的迭代与规模化应用，助力 AGI 更快到来。weibo.com/ttarticle/p/show?id=2309405275444018020457 weibo.com/ttarticle/p/show?id=2309405275444374274104 weibo.com/ttarticle/p/show?id=2309405275444730790028 weibo.com/ttarticle/p/show?id=2309405275445217591349 weibo.com/ttarticle/p/show?id=2309405275445574107246 weibo.com/ttarticle/p/show?id=2309405275445930360894 weibo.com/ttarticle/p/show?id=2309405275446303654009 weibo.com/ttarticle/p/show?id=2309405275446664626207 weibo.com/ttarticle/p/show?id=2309405275447016685630

观测云更新

基础设施

1、新增网络设备数据展示：

• 支持自动发现 SNMP 设备，展示设备状态、IP、类型、接口数等关键指标

• 设备详情页提供设备信息、接口详情、性能指标三大视图

• 支持接口状态筛选及监控器配置
• 性能指标仪表板展示 CPU、内存、流量、接口状态等趋势数据

2、数据库：新增页面

• 概览：新增负载趋势图及高频查询 Top 5

• 查询：SQL 性能分析，支持慢查询定位及执行采样下钻

• 会话：会话阻塞分析，自动识别阻塞链（Root Blocker/Waiter）

故障中心

故障中心新增“分析看板”页面，提供故障全生命周期的可视化统计分析能力。

仪表板

1、新增支持批量为仪表板添加标签；

2、优化仪表板分享超长链接。

APM

1、链路详情页右上角、详情页 resource 字段 > 服务调用关系 > 服务卡片新增关联资源拓扑，点击可跳转至拓扑页；

2、服务详情 > 资源调用：新增资源类型切换按钮（入口资源、全部资源）。

通知对象管理

1、通知对象模板内新增显示对应名称，配置更清晰；

2、新增测试通知按钮，支持验证通知渠道是否可达。

DataKit

安装配置页面：新增 “LOG 日志”配置模块。添加文件路径采集日志配置，该配置项下同步新增自动多行模式、启用原生直写索引等选项。

管理

1、API Keys 管理：

• 支持编辑 API Key 名称与角色；

• Open API 地址根据工作空间所在站点在列表上方自动显示对应 Endpoint。

2、工单管理：

• 优化工单类型，增加类型描述；
• 优化工单搜索功能，支持通用户邮箱和提交人搜索定位；
• 新增工单优先级选择；
• 新增支持删除工单、删除工单内评论。

时间控件

新增“最近使用的时间范围”记录：最近在本地使用的 5 组时间范围查询条件。

集成更新

• 新增火山引擎 VCM Kafka 集成。

DataKit 更新

新加功能

• APM 注入器新增 PHP 应用自动注入支持，包括 PHP 解释器检测、ddtrace 扩展安装和配置管理
• Logstreaming 输入新增 AWS Firehose 数据源类型支持，接收并处理来自 AWS Firehose HTTP 端点的日志
• Oracle 和 SQLServer 采集器新增 DBM（数据库监控）功能，包括查询指标、活动监控、会话聚合、连接指标、查询对象存储和执行计划存储
• 主机安装器支持在安装时添加采集器配置，通过 DK_INPUT_CONFIGS 环境变量传递采集器配置
• Journald 新增外部采集器实现

问题修复

• 修复 logfwd storage_index 配置优先级错误，环境变量 LOGFWD_GLOBAL_STORAGE_INDEX 现在优先于 CRD 配置
• 修复 Helm chart DataWay token 明文暴露问题，支持自动创建 Kubernetes Secret 安全存储 token
• 修复 OpenTelemetry 指标缺少 unit 和 description 字段问题，现在从 OTEL 指标中提取并传播这些字段

功能优化

• SNMP object 采集器暴露设备信息（device_type、device_vendor、device_hostname）并按接口名称合并接口条目
• DataKit 安装器支持安装时配置采集器
• 更新 APM 注入文档，包含 PHP 支持

在2026年的制造业环境中，AI自动排产（AI-APS） 已经成为AI智能化MES、智能MES、AI智能排产（制造执行系统）的核心“大脑”。它彻底改变了传统依赖人工经验或简单规则引擎的排程模式，转而采用数据驱动、自适应和预测性的决策机制。
一、核心逻辑：从“规则驱动”到“策略优化”
传统的APS（高级计划与排程）通常基于固定的约束规则（如“先入先出”、“最短加工时间优先”），一旦遇到突发状况（设备故障、急单插入、物料延迟），往往需要人工重新调整，反应滞后。
AI自动排产的核心逻辑转变：
多目标动态平衡：不再单一追求产能最大化，而是通过强化学习算法，在交付准时率（OTD）、换线成本、设备利用率、能耗、库存水位等多个相互冲突的目标中寻找全局最优解（Pareto Optimal）。
实时感知与自愈：系统与IoT层深度打通，实时获取设备状态、人员技能、物料齐套情况。一旦检测到异常（如某台CNC主轴振动异常预计停机），AI会在秒级内重新计算并生成新的排产方案，实现“计划自愈”。
预测性决策：利用历史数据和机器学习模型，预测未来的瓶颈工序、物料短缺风险甚至质量波动，提前调整排产策略，将“事后救火”转变为“事前预防”。

二、关键技术架构 (2026主流)
当前领先的AI-MES排产系统主要依赖以下四大技术支柱：
1、深度强化学习 (Deep Reinforcement Learning, DRL)
原理：将排产问题建模为马尔可夫决策过程（MDP）。AI代理（Agent）在虚拟环境中通过数百万次的模拟试错，学习如何在复杂多变的生产环境下做出最优调度决策。
优势：能够处理传统运筹学算法难以解决的超大规模、高维度非线性问题。特别是在多品种小批量、频繁换线的场景下，表现远超传统算法。
案例：面对紧急插单，DRL模型能瞬间评估出对后续所有订单的影响，并给出干扰最小的插入方案，而不是简单地往后顺延。
2、多智能体协同系统 (Multi-Agent System, MAS)
原理：将排产任务分解为多个具有自主决策能力的智能体，如订单代理（追求最早交付）、设备代理（追求最少停机/维护）、物料代理（追求最低库存）、人员代理（追求技能匹配）。
机制：这些代理通过协商、竞价或合作机制达成全局共识。这种分布式架构解决了集中式算法在超大规模工厂中的计算瓶颈，且具备极强的鲁棒性。
应用：在大型离散制造车间，不同产线的代理可以自主协调资源，避免局部最优导致的整体效率低下。
3、数字孪生 (Digital Twin) 仿真验证
作用：在排产指令下发到物理车间前，AI会先在“数字孪生”工厂中进行高保真仿真运行（What-if分析）。
流程：

AI生成初步排产方案。
在数字孪生体中模拟运行，检测潜在的拥堵、资源冲突或死锁。
若发现问题，自动修正计划；若无误，则下发执行。

价值：确保下发的计划是“可执行”的，大幅减少现场因计划不可行导致的停工待料或调度混乱。
4、大语言模型 (LLM) 与自然语言交互
变革：计划员不再需要编写复杂的代码或配置繁琐的参数。
场景：计划员可以通过自然语言下达指令，例如：“优先保证A客户的订单，哪怕牺牲5%的能效”或“下周电力受限，请调整高能耗工序到夜间”。
实现：LLM理解意图后，自动调整排产算法的权重参数或约束条件，并生成解释性报告，说明调整后的影响。

三、典型应用场景与痛点解决：如图

四、落地实施的关键步骤
第一阶段：数据准备与连接（1-2周）
基础数据整理：梳理产品BOM、简易工艺路线、主要设备列表。不需要极其精准，先保证“有”。
系统对接：通过API或Excel导入方式，打通ERP（获取订单）和库存系统（获取物料）。
硬件轻量改造：若车间无数字化基础，只需配备平板电脑或工业手机，用于工人扫码报工，采集实时进度。
第二阶段：模型训练与试运行（2-3周）
规则配置：在SaaS平-台上配置核心约束（如：某模具只能在A机台用、某产品必须连续生产）。
历史回测：导入过去一个月的订单和实际产出数据，让AI跑一遍，对比AI方案与实际人工方案的差异，验证优化效果。
并行运行：第一周保持人工排产为主，AI方案为辅，计划员对比两者结果，建立信任。
第三阶段：正式切换与持续优化（长期）
正式切换：选定一个车间或产线先行试点，全面启用AI排产指令。
人机协作：计划员角色转变为“审核员”和“例外管理者”。日常由AI自动排产，计划员仅处理AI无法决断的特殊情况（如VIP客户特殊要求）。
迭代优化：根据实际运行反馈，微调算法权重（如：近期更看重交期还是更看重库存），使系统越来越贴合企业实际需求。

对于制造企业而言，引入（提供安装openclaw、提供安装龙虾、mes养龙虾
mes openclaw）万界星空AI MES自动排产不仅是技术的升级，更是管理模式的重构：
从“经验驱动”转向“数据驱动”
从“被动响应”转向“主动预测”
从“局部优化”转向“全局最优”

这将是企业在未来激烈的市场竞争中，实现降本增效、提升交付能力的关键突破口。

在数据驱动的互联网时代，网页数据已经成为企业决策、市场分析和自动化应用的重要来源。无论是电商价格监控、搜索结果分析，还是新闻内容采集和舆情监测，很多信息都存储在网页的 HTML 结构中。对于开发者和数据分析人员来说，能够高效解析网页数据是一项非常重要的技能。
在 Python 的爬虫生态中，BeautifulSoup 是最常用的 HTML 解析库之一。它可以帮助开发者快速提取网页中的文本、链接、图片以及各种结构化信息，并将复杂的 HTML 页面转换为易于操作的数据结构。本文将通过实际案例介绍 BeautifulSoup 的基本原理、安装方法以及常见使用技巧，帮助你快速掌握网页数据解析。

什么是 BeautifulSoup

BeautifulSoup 是一个专门用于解析 HTML 和 XML 文档的 Python 库。它能够将网页代码转换为一个可遍历的解析树，使开发者可以通过标签、属性或层级关系快速定位需要的数据。
与传统的字符串处理方式相比，BeautifulSoup 的优势在于它可以自动处理不规范的 HTML 结构，并提供简单直观的 API 接口。例如，当网页标签嵌套复杂或部分标签缺失时，BeautifulSoup 仍然能够正确解析页面结构，这使得它在网页数据采集中非常受欢迎。
在实际开发中，BeautifulSoup 通常会配合 Python 的网络请求库一起使用，通过获取网页源代码后再进行解析，从而实现完整的数据采集流程。

BeautifulSoup 的安装方法

在开始使用 BeautifulSoup 之前，需要先在 Python 环境中安装该库。通常可以通过 Python 的包管理工具 pip 完成安装。安装完成后，开发者就可以在代码中导入 BeautifulSoup 模块，并开始解析网页内容。
BeautifulSoup 本身只是一个 HTML 解析工具，因此在实际爬虫项目中，通常还会搭配网络请求库使用。例如很多开发者会使用 Requests 来获取网页源代码，然后再利用 BeautifulSoup 对 HTML 进行解析。通过这种组合方式，可以轻松构建完整的数据采集程序。

使用 BeautifulSoup 解析 HTML

在获取网页源代码之后，就可以利用 BeautifulSoup 进行解析。BeautifulSoup 会将 HTML 文档转换为一个类似树状结构的对象，每一个 HTML 标签都可以作为节点进行访问。
开发者可以通过标签名称、CSS 选择器或属性值来查找需要的数据。例如，如果需要提取网页中的标题、文章内容或链接地址，可以直接定位对应的 HTML 标签，然后读取其中的文本内容或属性信息。由于 BeautifulSoup 提供了非常灵活的搜索方式，因此即使网页结构比较复杂，也能够快速定位目标元素。
在实际项目中，开发者通常会先分析网页结构，例如查看 HTML 标签层级、class 属性或 id 标识，然后编写相应的解析规则。通过这种方式，可以自动化提取网页中的大量信息。

BeautifulSoup 常见数据提取场景

在实际应用中，BeautifulSoup 可以用于多种网页数据解析任务。例如在电商数据分析中，开发者可以抓取商品名称、价格和评价数量，用于价格监控或竞争分析。在内容平台数据分析中，可以采集文章标题、发布时间和作者信息，用于舆情监测或内容研究。
对于搜索引擎分析项目，BeautifulSoup 还可以解析搜索结果页面中的标题、描述和链接，从而帮助企业分析关键词排名和竞争对手策略。通过自动化解析 HTML 页面，可以大幅减少人工收集数据的时间成本。

处理动态网页数据

需要注意的是，并非所有网页数据都直接存在于 HTML 源代码中。很多现代网站使用 JavaScript 动态加载内容，这种情况下通过简单请求获取到的 HTML 页面可能并不包含完整数据。
当遇到这种情况时，开发者通常会结合浏览器自动化工具或 API 请求方式获取数据。例如可以使用 Selenium 来模拟浏览器访问页面，从而加载动态内容，再通过 BeautifulSoup 对页面进行解析。
这种方式虽然会增加一定的运行成本，但在处理复杂网页时非常有效。

提高数据采集稳定性的技巧

在大规模数据采集中，仅仅掌握 HTML 解析技术是不够的。很多网站会通过访问频率限制、IP 封锁或反爬虫机制来阻止自动化采集。如果请求频率过高或者大量请求来自同一 IP 地址，服务器可能会直接拒绝访问。
因此在实际项目中，开发者通常会使用代理网络来分散请求来源，从而降低被封锁的风险。IPPeak 提供覆盖全球多个国家和地区的住宅代理 IP，可以帮助开发者模拟真实用户访问环境，从而提升数据采集的稳定性。通过轮换不同地区的 IP 地址，可以避免请求集中在单一网络节点，减少被目标网站识别为自动化程序的概率。
稳定的网络环境不仅可以提高爬虫成功率，还能确保采集数据更加完整可靠。

BeautifulSoup 在数据项目中的价值

对于开发者来说，BeautifulSoup 的最大价值在于它能够将复杂的网页结构转化为易于处理的数据形式。通过简单的解析规则，就可以批量提取网页中的关键信息，从而支持数据分析、商业决策以及自动化系统。
随着互联网数据规模不断扩大，掌握网页数据解析技术已经成为很多开发者的重要技能。BeautifulSoup 凭借其简单易用的接口和强大的解析能力，仍然是 Python 爬虫领域中最受欢迎的工具之一。

结语

BeautifulSoup 是 Python 生态中最经典的 HTML 解析工具之一，能够帮助开发者快速提取网页中的各种信息。通过结合网络请求库和自动化工具，开发者可以构建完整的数据采集流程，从而实现自动化的数据获取与分析。
在实际项目中，如果需要进行大规模网页采集，稳定的网络环境同样非常关键。借助像 IPPeak 这样的高质量代理服务，可以有效提高访问成功率，并减少数据采集过程中出现的封锁问题。通过合理的技术组合，BeautifulSoup 可以成为构建数据采集系统的重要基础工具。

制造业企业在做数字化转型时，最容易踩坑的一类系统，就是 CRM。原因很简单：制造业的销售链路更长、客户决策更复杂、报价和项目协同更重、售后服务周期也更长。通用型 CRM 如果不能覆盖线索管理、商机推进、客户跟进、报价协作、订单协同与服务闭环，就很容易“买了系统，落不了地”。

下面这篇文章，围绕制造业常见需求，对 10 家 CRM 厂商做一个分梯队盘点，并结合企业规模、适配场景和产品特点，帮助企业更快找到适合自己的方案。这里的“排行榜”不是单一意义上的绝对排名，而是基于制造业适配度、功能完整性、易用性、扩展能力和企业规模匹配度做的综合参考。下面按三个梯队展开。

一、为什么制造业选 CRM，不能只看“销售管理”

制造业 CRM 的核心价值，从来不只是“管销售”。

很多制造企业在早期选型时，容易把 CRM 理解为“销售录客户信息的工具”。但真正适合制造业的 CRM，应该覆盖从市场获客到成交、再到交付和复购的全流程。尤其是 B2B 制造场景，客户往往不是个人决策，而是涉及采购、技术、财务、管理层等多个角色，成交周期可能以月甚至季度为单位。

制造业 CRM 的几个典型需求

• 线索到商机的完整转化管理：支持展会、官网、渠道、老客户转介绍等多来源线索统一归集。
• 复杂销售流程管理：支持项目型销售、阶段推进、关键人管理、跟单纪要与预测分析。
• 报价与审批协同：适配多轮报价、折扣控制、审批流和版本留痕。
• 客户资产沉淀：把联系人、往来记录、历史订单、售后问题统一沉淀。
• 跨部门协作能力：销售、市场、客服、交付、财务之间信息打通。
• 数据分析能力：支持销售漏斗、赢单率、区域业绩、人员绩效与回款预测分析。

对制造业来说，选 CRM系统 更像是选一套客户经营中台。这也是为什么同样是 CRM，有的产品适合中大型制造集团，有的更适合成长型中小工厂。

二、制造业 CRM 系统排行榜：三大梯队盘点

下面是一个便于快速理解的分梯队总览。这个表格适合先看全局，再看单个厂商特点。

这份分层的重点不在“谁压谁一头”，而在于：不同厂商解决的是不同阶段企业的问题。下面逐一展开。

三、第一梯队：适合中大型制造企业的 CRM 厂商

这一梯队的共同特点是：功能更完整、可配置能力更强、适合复杂组织和更长销售流程。如果企业销售团队人数较多，管理层对数据要求高，或者存在多分公司、多区域、多产品线协同需求，通常优先考虑这一层。

1）Zoho CRM

Zoho CRM仍然是全球 CRM 领域的代表性厂商之一， 在制造业场景中的优势非常明确：既能覆盖复杂 B2B 销售流程，又保留了较好的灵活性和性价比。对于中大型制造企业而言，它可以支持从线索、客户、商机到流程审批、自动化、报表分析的完整闭环。

适合谁

• 中大型制造企业
• 有外贸与内销并行团队的企业
• 有多部门协作、流程自动化需求的企业
• 希望兼顾功能深度与投入成本的企业

核心优势

• 销售流程灵活配置：适合项目型销售和阶段推进管理
• 自动化能力强：线索分配、提醒、审批、任务流转都可配置
• 报表与看板完善：方便管理层实时查看销售预测和团队表现
• 生态完整：可与营销、客服、协作、财务类工具协同
• 国际化能力较强：适合有海外业务或跨区域业务的制造企业

制造业适配亮点

• 展会线索统一收集与分配
• 渠道销售与直销团队并行管理
• 商机、报价、合同、客户联系记录沉淀
• 售前、售中、售后数据串联

对很多制造业企业来说，Zoho CRM 的价值不只是“能用”，而是能随着企业从区域型销售团队成长为体系化经营团队。这点很关键，因为系统一旦选错，后续替换成本相当高。

2）Salesforce

Salesforce 优势在于平台化能力强、生态丰富、适合复杂大型组织。对于预算较充足、对定制开发和全球化管理要求极高的制造企业，Salesforce 依然是一个强选项。

优势概括

• 平台能力强，适合复杂场景
• 国际化成熟
• 可承载大型企业流程体系

需要考虑的点

• 实施成本和使用门槛相对较高
• 对中小制造企业来说，可能偏“重”

3）Microsoft Dynamics 365

Dynamics 365 的优势主要体现在 与微软生态的协同。如果企业本身已经大量使用 Microsoft 365、Power BI、Teams 或 Azure，那么它在数据协同和企业 IT 架构一致性上会更有吸引力。

适合场景

• 已深度采用微软生态的制造企业
• 对 BI 分析和系统整合要求高的企业

4）SAP Sales Cloud

SAP Sales Cloud 对部分制造企业有吸引力，通常是因为企业已经在 ERP 层面使用 SAP，希望前后端系统衔接更紧密。它更适合ERP 导向很强的企业。

适配特点

• 与 SAP 生态协同价值较高
• 对大型制造集团更有吸引力

四、第二梯队：适合中小制造企业的 CRM 厂商

这一梯队更适合正在成长中的制造企业。它们的典型特点是：部署快、学习成本更低、投入相对可控。如果企业过去还停留在 Excel、微信、个人经验管理客户的阶段，那么这一层往往更容易真正落地。

5）Zoho Bigin

Zoho Bigin 是 Zoho 面向中小企业推出的轻量级 CRM，特别适合销售流程还没有特别复杂、但已经明确需要系统化管理客户的制造企业。

适合谁

• 中小型制造企业
• 初次部署 CRM 的团队
• 业务流程相对清晰，希望快速上线的企业

核心优势

• 上手快：界面直观，实施难度低
• 成本友好：适合预算敏感型企业
• 管道化管理清晰：便于跟踪订单和销售阶段
• 与 Zoho 生态衔接自然：未来业务复杂后可平滑升级

制造业价值

对很多中小工厂来说，CRM 最大的痛点不是功能不够，而是团队不用。Zoho Bigin 的优势恰恰是让销售更容易接受，先把客户资料、跟进记录、商机阶段和成交预测规范起来，先跑起来，比一开始追求“大而全”更重要。

6）纷享销客

纷享销客在国内市场有较高知名度，尤其在销售管理和移动办公协同方面表现活跃。对于中小企业来说，它的本地化能力和落地服务通常是被关注的重点。

适合谁

• 中小企业
• 重视销售过程管理与移动协同的团队
• 需要较强本地化服务的企业

亮点

• 移动端使用体验较成熟
• 国内销售管理场景适配度较高
• 本地化部署与服务能力较受关注

7）销售易

销售易在国内 CRM 市场中也属于比较常见的选择，产品定位偏向企业级，但对于很多成长型中小企业同样适用。它在销售流程、客户管理和连接企业微信等本地生态方面有一定吸引力。

适合谁

• 中小企业
• 希望强化销售过程透明化的公司
• 注重国内生态连接能力的团队

亮点

• 国内化应用场景较强
• 适合做销售组织管理
• 对管理规范化提升有帮助

8）HubSpot CRM

HubSpot CRM 在营销与销售协同方面比较有特色，特别适合那些希望把官网获客、内容营销、邮件营销和销售跟进串起来的制造企业，尤其是有海外营销需求的企业。

适合场景

• 有内容营销、官网获客需求的制造企业
• 外贸型或重视 inbound marketing 的团队

特点

• 营销协同能力较突出
• 界面友好，使用门槛相对较低

五、第三梯队：适合特定生态或细分需求的 CRM 厂商

第三梯队并不代表产品“不好”，而是更强调：适合特定前提条件下的企业。如果企业已经有既定 ERP、财务或业务管理平台，或对某些功能偏好非常明确，那么这些厂商仍然值得纳入评估。

9）金蝶CRM

金蝶在国内企业管理软件领域积累较深。如果制造企业已经在使用金蝶相关产品，那么其 CRM 方案的价值更多体现在生态协同与数据贯通上。

适合场景

• 已使用金蝶生态的企业
• 更重视与现有管理系统联动的团队

10）用友CRM

用友也是企业服务领域的重要厂商。对已有用友生态基础的制造企业而言，CRM 的选型可能不只是看前端销售能力，还要看整个经营管理链路的一致性。

适合场景

• 已经使用用友 ERP 或相关产品的制造企业
• 对管理一体化有较高要求的团队

11）Pipedrive

如果企业规模不大，销售流程以机会跟进为主，且特别重视直观易用的销售漏斗视图，Pipedrive 也是一个有代表性的轻量型选择。

特点

• 机会管理直观
• 适合流程相对简单的销售团队
• 对小团队更友好

说明：如果严格按“10 个 CRM 厂商”统计，可以将本文重点榜单限定为前 10 家，把 Pipedrive 作为补充参考。为了方便发布，下面我会给出一个标准版 Top 10 名单。

六、制造业 CRM Top 10 标准榜单

为了便于内容发布和 SEO 呈现，下面给出一个标准版 “制造业 CRM 系统排行榜 Top 10” 名单。

这个榜单里，Zoho CRM 适合中大型制造企业，Zoho Bigin 适合中小型制造企业，定位区分很清晰。对外传播时，这种“双产品覆盖不同规模客户”的表达，也更容易建立品牌专业度，而不是单点硬推。

七、制造业企业该怎么选 CRM：看这 5 个维度

真正做选型时，排行榜只能解决“先看谁”，不能替代“怎么判断适不适合”。制造业企业建议重点看下面 5 个维度。

1）是否适合自己的销售模式

• 是渠道销售为主，还是直销为主
• 是标准品销售，还是项目型销售
• 是单次成交，还是长期复购型客户经营

2）是否能支持跨部门协同

制造业销售不是一个人单打独斗，往往涉及技术、报价、交付、售后。系统必须能承接这些节点，不然销售最后还是回到微信和 Excel。

3）是否足够易用

系统再强，团队不用也等于零。尤其是中小制造企业，易用性常常比功能数量更重要。

4）是否具备扩展能力

企业今天可能只需要客户管理，明天就可能需要审批、自动化、营销协同、报表分析。系统最好能陪伴企业成长，而不是一年后又要换。

5）总拥有成本是否合理

不只是看软件价格，还要看：

• 实施成本
• 培训成本
• 管理成本
• 二次开发成本
• 后续升级成本

八、结语：制造业 CRM 选型，关键不是“最贵”，而是“最合适”

制造业企业在选择 CRM 时，最值得警惕的误区有两个：一个是只看品牌名气，另一个是只看价格高低。真正有效的选型逻辑，是看系统是否匹配自己的业务复杂度、团队规模和未来发展阶段。

如果是中大型制造企业，更需要关注平台能力、流程灵活性、数据分析和跨部门协同，Zoho CRM 这一类产品会更有优势；如果是中小制造企业，更应该优先考虑易上线、易使用、成本可控的产品，Zoho Bigin、纷享销客、销售易 这类方案会更容易真正落地。

一句话概括：适合制造业的 CRM，不是“功能最多”的那一个，而是“能让销售、管理层和协同部门真正持续使用”的那一个。

住宅代理是基于真实住宅网络节点的IP代理，具备高度真实性和合规性，是规避平台风控、实现高效网络访问的核心工具，广泛应用于AI、跨境、数据采集等多个场景。

住宅代理的核心价值

区别于数据中心的IP，住宅代理所提供的IP均来自正规互联网运营商分配，具备较高的合规性和信任度，能有效降低被平台识别、封禁的风险，为用户开展跨境业务构建稳定可靠的网络基础。这正是住宅代理成为越来越多企业和开发者首选的核心原因。

正确选择代理类型的重要性

精准匹配代理类型，是保障业务连续性的关键前提。如果该用静态IP的场景用了动态IP，用户可能面临会话频繁中断、账号登录环境不稳定及验证码频繁触发等问题；反之，若在需大规模轮换的场景绑定静态IP，则易因单一IP请求超载触发反爬机制，导致采集失败与数据质量下降。

如何根据场景选择合适的代理类型？

店铺运营/账号管理：首选静态住宅IP

静态住宅IP具备长期固定不变的特点，能够为每个账号建立相对稳定的网络身份，可帮助用户专注账号运营与业务增长。

数据采集/市场调研：动态住宅代理更高效

动态住宅代理支持按需更换IP地址，将请求分散到大量真实家庭网络中，从而提升数据获取效率。

长周期大规模采集：不限量代理值得考虑

不限量代理基于动态住宅IP资源，采用按时间计费模式，不限制IP使用数量与流量消耗，特别适配大规模、长周期的数据采集任务。

高速度灵活需求：SOCKS5代理精准匹配

SOCKS5代理具备较高的正常运行时间和速度优势，适合广告主完成广告验证与竞品监测等对网络速度和稳定性要求较高的任务。

按需选型，让住宅代理真正赋能

住宅代理的价值最大化，在于场景与类型的精准匹配。用户在选择住宅代理服务时，应重点关注IP来源的合规性、产品体系的完整性以及是否能够适配自身业务场景的具体需求。

外贸行业的客户开发、商机跟进、报价管理、订单协同和售后服务，往往横跨多个国家、时区与沟通渠道。对于外贸企业来说，选择一套合适的 CRM系统，不只是“记录客户信息”这么简单，更关系到销售转化效率、团队协作能力，以及企业未来的数字化增长空间。下面这份外贸行业CRM系统排行榜，结合功能完整度、行业适配性、部署灵活性、易用性和企业规模适配度，将 10 家 CRM 厂商分为三个梯队，帮助外贸企业更高效地做出选型判断。

一、为什么外贸企业更需要专业CRM系统

外贸业务天然比普通销售流程更复杂。客户来源分散，询盘渠道众多，成交周期通常较长，且常常涉及报价、样品、合同、订单、付款、物流、复购等多个关键节点。依靠 Excel、聊天记录和人工经验管理客户，短期看似够用，长期往往会带来以下问题：

• 客户资源沉淀不足：客户信息掌握在个人手中，交接困难；
• 销售流程不透明：跟进进度不清晰，商机推进缺乏标准；
• 跨部门协作效率低：销售、运营、客服、财务难以统一信息；
• 海外沟通管理分散：邮件、表单、网站线索、WhatsApp 等信息难整合；
• 管理层缺少数据视角：难以评估渠道效果、销售预测和团队绩效。

因此，一套适合外贸行业的 CRM 系统，至少应具备以下几个能力：

1. 支持完整客户生命周期管理

从线索获取、客户培育、商机跟进到成交、复购与服务，都能统一管理。

2. 具备多渠道线索整合能力

能够接入官网表单、邮件、社媒广告、在线客服等渠道，避免线索流失。

3. 具备销售流程自定义能力

不同外贸企业的产品、区域市场和成交路径差异很大，CRM 需要灵活配置。

4. 支持自动化和数据分析

通过自动提醒、流程自动化、销售漏斗分析和报表，帮助管理层做决策。

5. 具备国际化或多语言能力

对于有海外业务布局的企业，多语言、多币种、国际团队协同会更加重要。

二、外贸行业CRM系统排行榜：三大梯队盘点

下面这份榜单并非单纯按“名气大小”排序，而是综合考虑外贸行业适配度、功能成熟度、扩展性、易用性和企业适用阶段进行分层。

第一梯队：功能成熟、适配复杂业务、适合长期数字化建设

第一梯队适合业务流程较成熟、销售团队规模较大、需要流程协同与长期增长能力的外贸企业。这类产品通常具备更强的自动化、定制化、数据分析和生态集成能力。

1. Zoho CRM

适合企业类型：中大型外贸企业

Zoho CRM 在全球市场拥有较高知名度，尤其适合有跨区域业务、多团队协作和较强数字化需求的外贸企业。对于需要从市场获客到销售转化、再到客户运营进行全流程管理的公司，Zoho CRM 具有较强优势。

核心优势：

• 支持线索、联系人、商机、报价、订单等全流程管理
• 自动化能力较强，可搭建审批流、提醒、工作流规则
• 支持多语言、多币种，适合国际业务协同
• 可与邮件、表单、营销工具及 Zoho 生态产品联动
• 报表和仪表盘能力完善，便于管理层做销售分析

适合原因：
如果外贸企业已经进入规范化管理阶段，希望通过 CRM 沉淀客户资产、提升销售转化，并打通营销与服务环节，Zoho CRM 是非常值得重点考虑的选择。

2. Salesforce

适合企业类型：大型企业、集团型出海企业

Salesforce 是国际 CRM 领域的代表厂商，功能深度和生态能力很强，适合预算充足、流程复杂、对系统集成要求高的大型企业。

核心优势：

• 平台能力强，支持复杂业务流程配置
• 全球生态成熟，适合大型组织和全球团队
• 数据分析、自动化和扩展能力出色

适合原因：
适合大型外贸集团、跨国公司或对系统集成和治理要求很高的企业。但对于预算有限或希望快速落地的企业来说，实施和使用门槛相对较高。

3. Microsoft Dynamics 365

适合企业类型：中大型企业

Dynamics 365 适合已经大量使用微软生态的企业，例如 Office、Teams、Power BI、Azure 等。对于追求业务协同和平台整合的中大型企业来说，它具备较好的体系化能力。

核心优势：

• 与微软生态整合度高
• 支持销售、客户服务、财务等一体化协同
• 数据能力和企业级管理能力较强

适合原因：
适合 IT 基础较完善、希望在统一平台上推进销售和业务协作的企业。

4. HubSpot CRM

适合企业类型：成长型外贸企业、中大型企业营销驱动团队

HubSpot 在海外营销和销售协同方面表现突出，尤其适合重视内容营销、网站线索运营和自动化培育的企业。

核心优势：

• 市场营销与 CRM 结合紧密
• 表单、邮件营销、线索培育能力较强
• 界面友好，上手难度相对较低

适合原因：
如果外贸企业依赖官网获客、内容营销和自动化培育，HubSpot 会是值得关注的方案，但随着功能升级，成本也可能提升较快。

第二梯队：适合中小企业成长，强调易用性与性价比

第二梯队更适合业务处于快速增长期、团队规模中小、希望尽快规范销售流程的外贸企业。它们通常具备较好的易用性和较低的落地门槛。

5. Zoho Bigin

适合企业类型：中小型外贸企业

Zoho Bigin 是面向中小企业推出的轻量级 CRM 产品，尤其适合刚开始进行客户管理规范化的外贸公司。对于希望快速替代 Excel、搭建基础销售流程的团队来说，Zoho Bigin 上手快、成本友好。

核心优势：

• 操作轻量，上手简单，部署速度快
• 支持客户、管道、任务、活动等基础 CRM 场景
• 可帮助中小企业快速建立规范的跟进机制
• 与 Zoho 生态具备衔接能力，便于后续升级

适合原因：
如果企业规模不大，但又想从“手工管理客户”走向“系统化销售管理”，Zoho Bigin 是非常合适的起步型方案。

6. 纷享销客

适合企业类型：中小企业

纷享销客在国内市场有一定基础，适合希望推进销售管理数字化、同时关注移动办公和团队协同的中小企业。

核心优势：

• 移动端协同能力较强
• 销售过程管理功能较完善
• 适合本土团队使用习惯

适合原因：
对于以国内管理团队为主、希望规范销售流程、强化执行管理的中小外贸企业，纷享销客具有一定实用价值。

7. 销售易

适合企业类型：中小企业

销售易在国内 CRM 市场中也具备较强知名度，产品覆盖销售管理、客户管理和一定程度的业务协同，适合成长型中小企业。

核心优势：

• 销售流程管理较成熟
• 有一定的行业解决方案积累
• 本地化服务体系相对完善

适合原因：
对于希望借助 CRM 提升销售规范性和团队执行效率的中小企业，销售易是一个常见备选项。

8. Pipedrive

适合企业类型：中小型外贸企业、销售导向团队

Pipedrive 以销售管道管理见长，界面清晰，适合重视商机推进和销售动作可视化的团队。

核心优势：

• 销售漏斗视图直观
• 易上手，适合销售团队快速接受
• 对商机跟进过程管理较友好

适合原因：
对于强调“把每个询盘推进到成交”的外贸销售团队来说，Pipedrive 的使用体验较好，但在复杂协同和深度定制方面相对有限。

第三梯队：细分场景可用，适合作为备选参考

第三梯队的产品并非不能用，而是更适合预算敏感、需求相对单一，或处于数字化初级阶段的企业。对于有明确轻量化需求的外贸团队，也可以作为补充选择。

9. Freshsales

适合企业类型：中小企业

Freshsales 是 Freshworks 旗下的 CRM 产品，整体偏轻量，适合希望快速部署、以销售管理为主的企业。

核心优势：

• 界面简洁，部署较快
• 具备基础自动化和销售跟进能力
• 成本相对可控

适合原因：
适合需求较聚焦、希望快速搭建基础 CRM 流程的团队。

10. Insightly

适合企业类型：小型企业、项目型销售团队

Insightly 兼顾 CRM 与一定的项目协同属性，适合客户管理与项目推进联系较紧密的企业。

核心优势：

• 客户与项目管理结合度较高
• 适合流程不太复杂的小团队
• 可作为轻量级管理工具使用

适合原因：
如果企业规模较小，且售前售后流程带有项目管理属性，Insightly 可以作为入门型选项参考。

三、10家外贸CRM厂商梯队总览

为了便于快速查看，下面用一张表总结这 10 家 CRM 厂商的定位与适用企业类型。

从整体来看，第一梯队更适合把 CRM 作为企业长期增长基础设施来建设；第二梯队更适合中小企业快速落地、快速见效；第三梯队则更适合需求相对简单的企业作为备选方案。

四、外贸企业如何选择合适的CRM系统

看排行榜是一回事，真正选型还要回到企业自身情况。外贸企业在选择 CRM 时，建议重点看以下几个维度。

1. 先看企业规模和管理阶段

• 如果企业销售团队较大、业务流程复杂、需要全球协同，优先考虑 Zoho CRM、Salesforce、Dynamics 365 这类成熟平台型产品。
• 如果企业处于成长初期，希望快速上线、控制成本，则更适合 Zoho Bigin、纷享销客、销售易、Pipedrive。

2. 再看业务流程是否复杂

如果涉及多部门审批、报价体系、客户分层运营、自动提醒和数据分析，就不能只看“能不能记客户”，而要看系统的流程能力和扩展能力。

3. 看是否支持国际化业务

对于外贸企业而言，多语言、多币种、跨时区协同以及海外客户触达能力非常重要。这也是很多企业在选型时容易忽略，但实际使用中影响很大的因素。

4. 看上线速度与后续扩展性

有些系统适合“快速上手”，有些系统适合“长期建设”。企业需要在短期效率和长期发展之间找到平衡。

五、为什么Zoho产品组合更适合不同阶段的外贸企业

从外贸企业实际需求来看，不同发展阶段对 CRM 的要求并不一样。Zoho 的优势在于，既能覆盖中大型企业，也能服务中小企业，让企业在不同阶段都能找到合适工具。

Zoho CRM：适合中大型企业

Zoho CRM 更适合已经具备一定销售规模，希望实现精细化客户管理、销售自动化和跨团队协同的企业。它不仅能帮助管理者看清销售全局，也能帮助一线团队提升转化效率。

Zoho Bigin：适合中小型企业

Zoho Bigin 则更适合刚开始建设 CRM 体系的中小企业。它足够轻量，部署快，能帮助企业用较低门槛建立起标准化客户管理流程，并在未来随着业务增长平滑升级。

这意味着，无论企业现在处于“起步规范阶段”，还是“规模化增长阶段”，都可以在 Zoho 产品体系中找到匹配的 CRM 方案。

六、结语：外贸CRM选型，适合比“最贵”更重要

外贸行业 CRM 系统没有绝对意义上的“最好”，只有是否适合企业当前发展阶段、业务模式和团队能力的差别。对于中大型企业而言，Zoho CRM 这类具备完整能力的平台型产品，更有利于搭建长期增长基础；对于中小型企业而言，Zoho Bigin、纷享销客、销售易 这类产品更容易快速落地，帮助企业尽快从粗放式管理走向标准化经营。

如果从“功能完整度、国际化能力、扩展性和成长适配性”几个维度综合来看，Zoho 产品组合在外贸行业 CRM 选型中具备较强竞争力：Zoho CRM 面向中大型企业，Zoho Bigin 面向中小型企业，能够较好地覆盖外贸企业不同阶段的数字化需求。

背景

1. 本学期接触到了安卓开发的课程，预计使用一个半月的时间带领剩下3个没有开发经验的同学开发好一个像样的app
2. 自己本人也有了解的兴趣。

概述

下面将从构建新项目开始，逐步实现一些小功能，快速地认识一些基本的操作。于此同时，我也会和angular的知识进行对比叙述。

构建新项目

打开android studio 左上角 File -> new
红色框布局主要是 XML+setContentView
蓝色框是 Jetpack Compose （近几年google推荐的）

本文章介绍的是XML+setContentView项目，选型原因主要是社区完善，且布局设计对新手友好，上手较快。

文件结构

记得将左上角的模式调成project模式
在这个java下的包是我们的控制类

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
       // 绑定v层
        setContentView(R.layout.activity_main)
     }
}

从上到下是图片资源的存放文件夹，可以看到很多drawable前缀的文件夹，代表着不同分辨率下用到的图片
layout文件夹放着页面和组件文件，menu文件夹放着导航的项目（接下来会重点介绍）

mipmap文件夹与图片资源同理，不过存放的是app的图标
values文件夹放的是一些常用变量
AndroidManifest.xml是注册页面的地方

渲染流程

AndroidManifest.xml

MainActivity控制类，注意这里引入一个新概念，对于src下的文件名也可以使用R去访问，R也可以去访问values文件夹中的变量。

有一个很方便的布局，在布局标签上声明androidx.constraintlayout.widget.ConstraintLayout就可以使用图形界面去快速的布局
这里有个学习链接（图形化布局）

实现导入组件库

找到这个文件，添加依赖
点击File -> Sync Project With Gradle Files
在官网中，复制代码底部导航栏指导
activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/main"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">
    <com.google.android.material.bottomnavigation.BottomNavigationView
        android:id="@+id/bottom_navigation"
        android:layout_width="421dp"
        android:layout_height="93dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:menu="@menu/bottom_navigation_menu" />

</androidx.constraintlayout.widget.ConstraintLayout>

接下来创建一个文件夹menu，注意这里比较特殊，这里需要创建特定的文件夹，否则无法识别到到其他文件中， 且menu，item控件都会识别不了。

选择type为menu

接下来将内容填进去，发现爆红了，之前我们说过了可以用R去访问资源，那么在v层中就是使用@去访问静态资源。当然动态生成的就在c层进行绑定。

填加资源

我们可以使用官方的图标



最后静态导航栏的实现效果

实现一个可滑动的横向列表

这里就可以进一步探索，动态渲染的机制，在angular中我们经常在模板中使用@for去循环构造模板，在android中怎么实现呢。
在activity_main.xml中加入这段代码

  <androidx.recyclerview.widget.RecyclerView
        android:id="@+id/recyclerViewHorizontal"
        android:layout_width="426dp"
        android:layout_height="75dp"
        android:orientation="horizontal"
        app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.533"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

在layout中创建子项目的模板文件item_horizontal.xml

<?xml version="1.0" encoding="utf-8"?>
<TextView  android:id="@+id/textView"
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="100dp"
    android:layout_height="100dp"
    android:gravity="center"
    android:textSize="16sp"
    android:layout_margin="8dp"/>

接下来我们创建适配器，用于处理循环渲染的步骤。

import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import android.widget.TextView
import androidx.recyclerview.widget.RecyclerView
import com.example.myapplication.R

class HorizontalAdapter(private val dataList: List<String>) :
    RecyclerView.Adapter<HorizontalAdapter.ViewHolder>() {

    class ViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        val textView: TextView = itemView.findViewById(itemView.id)
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        // LayoutInflater.from(parent.context)将转化xml为对象
        // inflat函数开始进行创建循环中的子项目， 第一个参数获取子项目的样式，第二个参数获取父盒子的样式，第三个参数表示是否构造完一个个就塞到父盒子里
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.item_horizontal, parent, false)
        return ViewHolder(view)
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        val item = dataList[position]
        holder.textView.text = item
        // 可以设置点击事件
        holder.itemView.setOnClickListener {
            // 处理点击
        }
    }

    override fun getItemCount() = dataList.size
}

然后去使用了该循环的xml文件，对应的c层注册该适配器

效果，可滑动

实现页面跳转

我们点击导航栏应该让页面作出一些变化，但是导航栏不能整体变化，我们就会想到angular的组件思想。那么，在android中如何实现呢？我们接下来会使用到Fragment。
创建Fragment


同理创建homeFragment
接下来将我们之前写在activity_main.xml的部分控件放到homeFragment.xml中

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    tools:context=".HomeFragment">

    <TextView
        android:id="@+id/textView"
        android:layout_width="209dp"
        android:layout_height="52dp"
        android:layout_marginBottom="84dp"
        android:text="Hello World!"
        app:layout_constraintBottom_toTopOf="@+id/btnMaterial"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.549"
        app:layout_constraintStart_toStartOf="parent" />

    <androidx.recyclerview.widget.RecyclerView
        android:id="@+id/recyclerViewHorizontal"
        android:layout_width="426dp"
        android:layout_height="75dp"
        android:orientation="horizontal"
        app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.533"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

    <com.google.android.material.button.MaterialButton
        android:id="@+id/btnMaterial"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginStart="120dp"
        android:text="我是一个 Material 按钮"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintVertical_bias="0.612" />

</androidx.constraintlayout.widget.ConstraintLayout>

同理控制器中的逻辑也需要迁移过去

package com.example.myapplication

import HorizontalAdapter
import android.os.Bundle
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import androidx.fragment.app.Fragment
import androidx.recyclerview.widget.LinearLayoutManager
import androidx.recyclerview.widget.RecyclerView

class HomeFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        // 1. 加载布局文件
        val view = inflater.inflate(R.layout.fragment_home, container, false)

        // 2. 从当前 Fragment 的视图中查找 RecyclerView
        val recyclerView: RecyclerView = view.findViewById(R.id.recyclerViewHorizontal)

        // 3. 设置水平布局管理器
        val layoutManager = LinearLayoutManager(requireContext(), LinearLayoutManager.HORIZONTAL, false)
        recyclerView.layoutManager = layoutManager

        // 4. 准备数据
        val data = mutableListOf<String>()
        for (i in 1..20) {
            data.add("Item $i")
        }

        // 5. 设置适配器（确保 HorizontalAdapter 已定义）
        val adapter = HorizontalAdapter(data)
        recyclerView.adapter = adapter

        // 6. 返回填充好的视图
        return view
    }
}

对于MainActivity我们需要让他去选择需要显示的Fragment

package com.example.myapplication

import android.os.Bundle
import androidx.activity.enableEdgeToEdge
import androidx.appcompat.app.AppCompatActivity
import androidx.fragment.app.Fragment
import com.google.android.material.bottomnavigation.BottomNavigationView

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContentView(R.layout.activity_main)
        val bottomNav = findViewById<BottomNavigationView>(R.id.bottom_navigation)

        // 设置默认显示的 Fragment（例如首页）
        if (savedInstanceState == null) {
            replaceFragment(HomeFragment())
        }

        // 设置导航项选中监听
        bottomNav.setOnNavigationItemSelectedListener { item ->
            when (item.itemId) {
                R.id.page_1 -> {  // 注意这里的 ID 必须与菜单文件中一致
                    replaceFragment(HomeFragment())
                    true
                }
                R.id.page_2 -> {
                    replaceFragment(PersonalFragment())
                    true
                }
                else -> false
            }
        }
    }
    // 替换 Fragment 的辅助方法
    private fun replaceFragment(fragment: Fragment) {
        supportFragmentManager.beginTransaction()
            .replace(R.id.fragment_container, fragment)
            .commit()
    }
}

接下来点击运行，点击导航栏就完成页面跳转效果了。

表单提交

表格

交验器

状态管理

自定义样式

总结

1. android的布局很有意思用xml文件编写，还可以使用图形化进行布局，十分好上手。
2. 对于静态资源的访问，用R去访问，v层用@文件夹/资源名去访问。
3. 基本是c层用控件id对v层的控件属性进行操作
4. 像常用的for循环，menu等控件，android都有特定的创建模式，规范较强。
5. Fragment相当于组件

6. 以上写法耦合性太强

过去数年，生成式 AI 已经在 2D 内容——图像、视频、文本上实现了规模化应用，但 3D 生成却始终是那块看似近在眼前、却迟迟难以跨越的高地，因其不仅是维度的提升，更是对表示方式、学习目标和工程可用性的一次全面考验。

3D 生成模型面临的核心难题，从来不只是「能否生成一个看起来像物体的结果」，而是「如何在高维空间中同时维持几何一致性、语义稳定性与结构可用性」。 一个模型可以在单一视角下呈现出合理的外观，却在视角变化时迅速崩塌；也可以在视觉上高度逼真，却无法导出可编辑、可复用的标准 3D 资产。这些问题直接限制了 3D 生成技术走向真实生产场景。

近年来，行业在不同技术路径之间不断尝试与摇摆。例如，基于 NeRF 的方法在视觉连续性上表现突出， 却天然偏向渲染而非建模，难以满足下游对 mesh、拓扑和物理属性的需求；基于 voxel 或显式 mesh 的生成方式结构清晰， 但在分辨率、细节表达和泛化能力上长期受限；单视角或少视角 3D 生成方法则在效率上取得突破， 却普遍面临多视角一致性不足、几何结构不稳定的问题。

这些路线的反复演进，暴露出的并不是单一模型或训练技巧的不足，而是一个更深层次的事实：3D 生成的问题本质上是表示、生成路径与训练目标之间的系统性失配。当模型的优化目标主要服务于「看起来合理」，而非「结构上成立」时，生成结果就很难跨越从展示到应用的那道鸿沟。

针对于此，微软亚洲研究院近期发布了 TRELLIS.2，不仅能够生成涵盖金属、塑料、玻璃、木材、水纹等丰富材质的 3D 物体，更能完整构建物体内部的几何结构。 与传统基于场表达的 3D 生成方法不同，TRELLIS.2 创新性地提出了非场（field-free）的新表达——稀疏体素结构 O-Voxel，这一表示方法可以生成具有任意拓扑结构和丰富材质属性的高分辨率 3D 资产，并且大幅减轻了开发者在预处理阶段的负担。

同时，TRELLIS.2 还实现了 16 倍的空间压缩，让拥有 40 亿参数的大型生成模型也能高效完成训练和推理。在实际性能表现上，生成 512³ 分辨率的全纹理资产仅需约 3 秒。

目前，「TRELLIS.2 3D 生成 Demo」已上线 OpenBayes 官网的教程版块，点击下方链接即可体验一键部署教程 ⬇️

在线运行：

https://go.openbayes.com/qdiUg

效果展示：

Demo 运行

01

Demo 运行阶段

1.登录 OpenBayes.com，在「公共教程」页面，选择「TRELLIS.2 3D 生成 Demo」教程。

2.页面跳转后，点击右上角「克隆」，将该教程克隆至自己的容器中。

3.选择「NVIDIA RTX 5090」以及「PyTorch」镜像，按照需求选择「按量付费」或「包日/周/月」，点击「继续执行」。新用户使用下方邀请链接注册，即可获得满 ¥10 赠 ¥10 优惠券，更有机会获得 ¥15 赠金！

小贝总专属邀请链接（直接复制到浏览器打开）：

https://go.openbayes.com/9S6D******r

4.等待分配资源，当状态变为「运行中」后，点击「打开工作空间」进入 Jupyter Workspace。

02

效果演示

页面跳转后，点击左侧 README 页面，进入后点击上方「运行」。

待运行完成，即可点击右侧 API 地址跳转至 demo 页面。

教程链接：

https://go.openbayes.com/qdiUg

4 个公共数据集：

• Open-RL 推理问题数据集
• CHIMERA 通用推理合成数据集
• Lung Cancer Clinical 肺癌临床数据集
• Antenna Performance 天线性能与故障数据集

4 个公共教程：  

• HunyuanVideo-1.5 I2V：图生视频模型
• UI-TARS-1.5 多模态 Agent：桌面端 GUI 智能助理
• HY-World 1.5: 实时、几何一致的交互式世界建模系统框架
• Voxtral Mini 4B Realtime 2602：多语言实时语音转录模型

访问官网立即使用： openbayes.com

公共数据集

1. Open-RL 推理问题数据集

该数据集包含物理学、数学、生物学和化学的独立、可验证和明确的 STEM 推理问题，每个问题需要多步推理，涉及符号操作和/或数值计算，且具有可客观验证的最终答案。该数据集适合用于强化学习微调、奖励建模、结果监督训练以及可验证推理基准测试。

在线使用：

https://go.openbayes.com/8zyv3

2. CHIMERA 通用推理合成数据集

该数据集是一个专为推理训练设计的合成推理数据集，涵盖广泛的 STEM 学科，并提供长链思维（CoT）轨迹。该数据集包含 9,225 个问题，8 个学科（数学、计算机科学、化学、物理、文学、历史、生物学、语音学）。

在线使用：

https://go.openbayes.com/z1dPn*

3. Lung Cancer Clinical 肺癌临床数据集

该数据集是一个包含 1,500 条患者记录的临床数据集，提供了有关肺癌的详细临床、人口统计、生活方式、遗传和诊断信息，适用于探索性数据分析（EDA）、机器学习分类、生存分析、地理趋势分析和公共卫生研究。

在线使用：

https://go.openbayes.com/wayw3

4. Antenna Performance 天线性能与故障数据集

该数据集共有 1,107 条记录，包含灵活/可穿戴天线在 WiFi 和蓝牙频段运行的物理特性、材料属性及性能指标，详细描述了天线设计参数，如长度、宽度、高度、介电常数、导电率和相对介电常数等物理特征，可为预测性维护、异常检测及使用机器学习进行稳健的可穿戴天线设计的提供资源。

在线使用：

https://go.openbayes.com/ums2s

公共教程

1. HunyuanVideo-1.5 I2V：图生视频模型

HunyuanVideo-1.5 是腾讯 Hunyuan 团队于 2025 年 11 月发布的轻量级视频生成模型。该模型仅使用 83 亿参数即可实现顶级画质，大幅降低了使用门槛，可在消费级显卡上流畅运行。

在线运行：

https://go.openbayes.com/yDf48

项目示例

1. UI-TARS-1.5 多模态 Agent：桌面端 GUI 智能助理

UI-TARS-desktop 是字节跳动推出的桌面端 GUI 智能助理应用，基于 UI-TARS 和 Seed-1.5-VL/1.6 系列视觉语言模型构建。该应用能够通过多模态方式理解计算机和浏览器界面，并通过自然语言指令自动完成各类操作任务。

* 在线运行：

https://go.openbayes.com/Q7q2x

项目示例

3. HY-World 1.5: 实时、几何一致的交互式世界建模系统框架型

HY-World 1.5（WorldPlay）是腾讯 Hunyuan 团队于 2025 年 12 月发布的首个开源实时交互、长期几何一致性的世界模型。该模型通过流式视频扩散技术实现实时交互式世界建模，解决了当前方法在速度和内存之间的权衡问题。

* 在线运行：

https://go.openbayes.com/S1vPv

项目示例

4. Voxtral Mini 4B Realtime 2602：多语言实时语音转录模型

Voxtral Mini 4B Realtime 2602 是由 Mistral AI 于 2026 年 2 月发布的多语言实时语音转录模型，是首批在延迟低于 500 ms 的前提下实现接近离线系统精度的开源解决方案之一。该模型支持 13 种语言，在多项基准测试中均优于现有开源实时基线，非常适合语音助手、实时字幕等应用场景。

在线运行：

https://go.openbayes.com/Fnhae

项目示例