在数字化转型背景下，企业对CRM的需求已从“销售工具”升级为“全链路业务操作系统”——既要覆盖客户从获客到复购的全生命周期（CLM），也要通过自动化降低销售成本（SFA），更要实现销售、财务、采购、仓储等角色的无缝配合。本文选取超兔一体云、Odoo、YetiForce、纷享销客、简道云、销帮帮、八百客、Free CRM、Streak九大主流CRM系统，从客户 全生命周期管理 （CLM）、 销售自动化 （SFA）、多角色无缝配合三大核心维度展开深度对比，结合功能拆解、流程可视化与量化评分，为企业选型提供参考。

一、对比框架说明

本次对比围绕企业最核心的三个需求维度，拆解为12个二级指标、36个三级指标（见表1），覆盖从线索到复购的全流程、从人工到智能的自动化、从部门到供应链的协同。

表1 核心对比指标框架

二、客户全生命周期管理（CLM）：从获客到复购的全链路能力对比

客户全生命周期管理的核心是“精准触达+个性化运营+闭环转化”，需覆盖“获客-跟进-签约-售后”四大阶段。以下是各系统的能力拆解：

1. 获客阶段：渠道覆盖与线索质量管控

获客是CLM的起点，关键指标是渠道多样性与线索质量过滤能力。

2. 跟进培育阶段：个性化运营与跟单效率

跟进培育的核心是“识别客户需求+匹配销售动作” ，关键指标是跟单模型丰富度与客户视图完整性。

（1）跟单模型对比

（2）超兔一体云CLM全流程流程图（Mermaid）

flowchart LR
    A[多渠道获客] --> B[线索质量管控<br>（手机号验证+IP归属地）]
    B --> C[“三一客”节点管理<br>（定性+定级+定量）]
    C --> D[五大跟单模型<br>（客户/商机/项目等）]
    D --> E[订单生成<br>（服务/实物/特殊型）]
    E --> F[售后复购<br>（RFM分析+维修工单）]

3. 签约交付阶段：订单适配与执行效率

签约交付的核心是“适配复杂业务场景”与“订单全链路可见” ，关键指标是订单类型覆盖与执行流程自动化。

4. 售后复购阶段： retention与复购挖掘

售后复购的核心是“识别高价值客户+降低流失” ，关键指标是复购分析工具与售后响应效率。

5. CLM能力量化评分（1-5分，5分为优）

三、销售自动化（SFA）：从人工到智能的效率跃迁

销售自动化的核心是“用系统替代重复劳动”，需覆盖“线索-跟单-订单-AI”四大环节。

1. 线索自动化：从获取到分配的无人干预

线索自动化的关键是“减少人工录入”与“精准分配”。

2. 跟单自动化：从跟进到复盘的智能辅助

跟单自动化的核心是“提醒关键动作+自动复盘”。

3. 订单自动化：从生成到执行的全链路自动

订单自动化的关键是“减少跨部门沟通”与“避免人为错误”。

4. AI辅助：从经验到数据的智能决策

AI辅助是SFA的高阶能力，关键是“替代经验判断”与“预测性建议”。

5. SFA能力量化评分（1-5分）

四、多角色无缝配合：从部门到供应链的协同能力

多角色配合的核心是“数据共享 + 流程联动”，需解决“信息孤岛”与“跨部门推诿”问题。

1. 数据底层连通性：全模块数据共享

数据连通是协同的基础，关键是“是否基于同一数据库”或“是否实现 API 深度集成”。

2. 流程协同自动化：订单全链路流转

流程协同的关键是“跨部门流程自动触发”，以下是超兔一体云的“订单 - 采购 - 财务”协同流程（Mermaid 时序图）：

sequenceDiagram
    participant 销售 as 销售部
    participant 系统 as 超兔一体云
    participant 采购 as 采购部
    participant 财务 as 财务部
    participant 仓储 as 仓储部

    销售->>系统: 生成销售订单（含产品/数量）
    系统->>采购: 自动生成采购计划（库存不足时）
    采购->>系统: 确认采购单（关联销售订单）
    系统->>仓储: 采购入库（自动更新库存）
    系统->>财务: 自动计算应收（按订单金额/账期）
    仓储->>系统: 按订单发货（关联库存）
    财务->>系统: 回款确认（自动核销应收）

3. 权限管理精准度：角色适配与数据安全

权限管理的核心是“最小权限原则”，需适配不同角色的职责。

4. 供应链上下游协同

供应链协同是企业提升整体效率和竞争力的关键，能够实现企业与供应商和客户之间的全流程协同。

多角色无缝配合能力量化评分（1 - 5 分）

五、总结与企业选型建议

总结

本次对比围绕客户全生命周期管理（CLM）、销售自动化（SFA）、多角色无缝配合三大核心维度，对超兔一体云、Odoo、YetiForce、纷享销客、简道云、销帮帮、八百客、Free CRM、Streak 九大主流 CRM 系统进行了深度剖析。从各项量化评分来看，不同系统在不同维度表现各有优劣。

超兔一体云在三个核心维度的综合表现最为出色，在客户全生命周期管理的各个阶段、销售自动化的各个环节以及多角色无缝配合方面均获得高分，展现了全面且强大的功能，为企业提供了一站式的数字化解决方案。

Odoo 和 YetiForce 也具备较强的综合实力，在多个方面表现良好。Odoo 的模块化架构和一体化协同能力较为突出；YetiForce 在供应链协同和制造企业场景适配方面有独特优势。

纷享销客、简道云、销帮帮、八百客等系统也能满足企业的部分需求，具有一定的特色功能和适用场景。而 Free CRM 和 Streak 由于功能局限性，在综合评分上相对较低。

企业选型建议

企业在选择 CRM 系统时，应根据自身的规模、行业特点、业务需求和发展战略等因素进行综合考虑。

• 大型企业：如果企业规模较大，业务复杂，需要全面的客户管理、高效的销售自动化以及深度的多角色协同，超兔一体云是一个不错的选择，其全模块底层连通和强大的功能体系能够满足大型企业的复杂管理需求。同时，纷享销客的强大定制化能力也能适配中大型企业的具体管理要求。
• 制造/贸易企业：YetiForce 在供应链协同和制造企业场景适配方面表现出色，其“订单 - 生产 - 库存”的深度连通和“MTO”订单自动排产等功能，能有效提升制造/贸易企业的运营效率。Odoo 的模块化架构和对生产计划、销售预测与财务集成的支持，也适合此类企业。
• 依赖邮件沟通的团队：Streak 深度嵌入 Gmail 邮件场景，对于依赖邮件沟通的团队（如外贸、B2B），可实现轻量化客户管理。
• 追求轻量化和快速上手的中小企业：Free CRM 界面简洁、操作门槛低，适合中小企业快速上手，提升单一销售场景的效率。简道云的零代码平台支持快速搭建和定制，能满足中小企业灵活性的需求。

总之，企业在选型时应充分评估各系统的优缺点，结合自身实际情况做出合理选择，以实现数字化转型，提升企业的盈利水平和竞争能力。

（注：文中功能相关描述均基于公开披露信息，具体功能服务与价格以厂商实际落地版本为准。）

据国外网络安全公司Malwarebytes近日披露的消息显示，知名企业lnstagram的用户系统遭到非法入侵，超1750万个用户账户的个人敏感信息遭到泄露。目前这些个人隐私数据正在暗网流通，对用户的隐私与账户安全造成了严重威胁。此次泄露的数据包含了用户名、电子邮箱、电话号码甚至地址信息，使得用户面临严重的隐私曝光。攻击者完全可以利用这些泄露的信息进行身份盗用，实施钓鱼攻击，从而开展网络诈骗活动。有知情人士反馈，已有多名用户收到了平台的密码重置通知，表明攻击者正在尝试利用泄露的账户信息进行非法操作。JoySSL安全部负责人表示，透过此次lnstagram数据泄露事件不难看出，数据已成为驱动全球经济的核心燃料，任何掌握用户数据的平台，都必须重视安全防护建设，任何微小的裂痕都足以引发一场“数字地震”，动摇用户对数字服务的信任根基。以数字证书为代表的安全加密类技术，正在为全球数字化发展构筑安全防线，建立信任体系，市场价值不言而喻。

lnstagram泄露事件 揭露数字生态系统共性弱点

此类涉及超大数据规模的泄漏事件，往往揭示了复杂数字生态系统中存在的各种问题。数据传输链普遍存在漏洞，若缺乏端到端加密及强制性身份验证，或可成为攻击者窃取数据的机会。 此外，攻击者可能伪装为合法用户，获取未授权的数据访问权，看似是轻微的漏洞被利用，其带来的后果往往堪称灾难级。

SSL证书构筑防护堤坝 数据洪流中抵御网络威胁

数字化时代，数据早已成为数字经济发展的核心构成。若不能建立有效的防护体系，保障数据安全，经济的发展只是建立在沙滩上的堡垒，根基不稳，一冲即散。SSL证书确保数据传输的“加密防护”，维护信息流的隐私性，有效防止网络窃听。

OV/EV证书强化服务器端身份验证，建立安全可信的连接环境，可有效防范网络钓鱼攻击、中间人攻击及非法连接。可通过浏览器的绿色地址栏直接显示企业名称，为普通用户提供简单直观的身份验证方式。企业利用基于SSL证书的双向认证技术，能够有效确保数据仅在身份验证成功并获得授权的合作伙伴之间，进行安全传输。

从可有可无到核心竞争力资产 数字证书价值凸显

在数字化转型深入发展的时期，SSL证书的市场价值已被彻底重新定义。它是企业满足数据安全法规、避免因缺乏加密措施而面临巨额罚款的高性价比投资。通过部署具有高辨识度的EV证书，企业能够证明其身份直接提升用户忠诚度和品牌溢价，为自己构筑数字时代的“信任壁垒”。

谷歌、百度等搜索引擎已将HTTPS视为影响排名的重要因素。JoySSL网络总监指出，基于HTTPS启用HTTP/2或HTTP/3等现代协议可显著改善应用加载速度，提升用户体验。同时，越来越多的生态合作伙伴将可信的HTTPS证书作为技术集成的准入标准。

以SSL证书作信任基石 以可信链接锚定未来市场

Instagram数据泄露事件并非孤立现象，而是数字化转型中的典型表现。数据流动过程中，安全保障已经从技术领域上升为企业的核心经营需求，成为不可或缺的数字信任基石。它不仅确保数据的加密传输，还维护企业的信誉，同时提升消费者对品牌的信任感，通过建立可信链接，锚定企业未来发展市场。

云原生热点

Agones 1.54.0 版本发布：计数器能力增强，GKE Autopilot 直通通信正式稳定

Agones 是一个开源的 K8s 原生游戏服务器托管与扩展框架，用于在 K8s 集群上运行、管理和自动扩缩专用游戏服务器资源。它通过自定义资源（如 GameServer、Fleet 等）和控制器，帮助开发者高效管理大规模实时游戏服务器生命周期与调度。

1.54.0 版本新增对 K8s v1.34 的支持，并强化了在 GKE Autopilot 场景下的端口直通能力；同时引入更完善的 Counter 状态工具，提升服务器状态可观测性，简化自动扩缩配置，并修复 Init Container 相关问题，整体提升了稳定性、易用性和云托管兼容能力。

Kube-OVN v1.15 发布：新年新版，网络功能再进化

Kube-OVN 是一个基于 OVN/Open vSwitch 的 K8s 云原生网络插件，将 SDN 虚拟网络能力引入容器网络，支持静态 IP 分配、VPC 多租户、灵活网络策略等丰富功能，提升集群网络可控性与性能。

Kube-OVN v1.15 近日成功发布，新版本重点增强网络灵活性与稳定性，支持更精细的 IPPool 绑定与管理，升级 OVS 和 OVN 核心组件，提升性能与安全性，同时强化监控与健康检查能力，并清理遗留代码，进一步提升生产环境下的可运维性与可靠性。

技术实践

文章推荐

K8s v1.35：云控制器管理器中的基于监视的路由协调

本文介绍了 K8s v1.35 在 Cloud Controller Manager（CCM）的路由控制器中新增特性门控 CloudControllerManagerWatchBasedRoutesReconciliation：将原先按固定间隔轮询对账，改为基于 informer 的 watch 机制，在节点增删或 .spec.podCIDRs、.status.addresses 变化时触发对账，并保留 12–24 小时随机周期的补充对账，从而在路由无变化时显著减少对云厂商的无谓 API 请求，同时不改变既有对账逻辑，降低行为变化风险。

使用 clientcmd 进行统一的 API 服务器访问

本文介绍了 K8s 在 v1.35 中针对 clientcmd 访问 API Server 的改进（Uniform API server access using clientcmd），强调统一和简化使用 kubeconfig/clientcmd 与 API Server 交互的方式，使客户端（如 kubectl 或程序库）通过一致的配置和流程发现 API Server 地址、凭据与认证细节，从而减少重复配置和访问复杂度，提高与集群 API 交互的可靠性和开发效率，同时保持与现有访问机制兼容。

K8s 事故中惨痛教训揭示的隐藏不良实践

本文介绍了一些在生产事故中才暴露出来的 K8s 错误实践及其应避免的方式。文章由一位 SRE 工程师分享常见但常被忽视的错误做法，如错误配置探针/资源请求、缺乏网络策略、过度权限设置等，这些隐性坏习惯在集群运行和故障时会引发严重问题。作者结合实际事件，提出改善建议以提升集群稳定性与安全性，对于 K8s 生产环境的运维和 SRE 团队具有重要参考价值。

开源项目推荐

AIBrix

AIBrix 是一个开源的云原生大规模 LLM 推理基础设施框架，用于在 K8s 上高效部署、管理和扩展大型语言模型推理服务，支持路由、自动扩缩、分布式推理和 KV 缓存等关键能力，帮助企业构建可扩展、高性价比的生成式 AI 推理平台。它与 vLLM 紧密集成，适合生产环境和大规模应用场景。

Kyverno

Kyverno 是一个开源的 K8s 原生策略引擎，用于通过“策略即代码”（Policy as Code）管理集群中的资源安全、合规和自动化。它允许你用熟悉的 K8s YAML 定义策略，验证(validate)、变更(mutates)、生成(generate) 和清理(cleanup) 资源，增强安全性和治理，还支持镜像签名验证等高级用例，非常适合平台工程、DevOps 和安全团队。

vcluster

vcluster 是一个开源的虚拟 K8s 集群解决方案，它在一个真实集群内创建轻量级、隔离的虚拟集群实例。每个虚拟集群拥有独立的 API 和控制平面，但共享底层节点资源，启动快、资源占用少、权限隔离好。适合多租户开发测试、CI/CD 环境和平台自助服务等场景。

SpinKube

SpinKube 是一个开源的 WebAssembly（Wasm）无服务器运行时平台，简化在 K8s 上开发、部署与管理 Wasm 工作负载。它结合 Spin Operator、containerd shim 和 Runtime Class 管理器，可让轻量级、快速启动的 Wasm 应用像容器一样运行，并集成自动扩缩与 Kubernetes 原生机制。该项目已成为 CNCF Sandbox 成员，适合构建高效、可扩展的云原生服务。

关于KubeSphere

KubeSphere （https://kubesphere.io）是在 Kubernetes 之上构建的容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、东方通信、微宏科技、东软、新浪、三一重工、华夏银行、四川航空、国药集团、微众银行、紫金保险、去哪儿网、中通、中国人民银行、中国银行、中国人保寿险、中国太平保险、中国移动、中国联通、中国电信、天翼云、中移金科、Radore、ZaloPay 等海内外数万家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能，包括 Kubernetes 多云与多集群管理、DevOps (CI/CD)、应用生命周期管理、边缘计算、微服务治理 (Service Mesh)、多租户管理、可观测性、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。

最近整理微服务架构笔记时快被逼疯了：写了 3 页文档，结果评审时被指出漏了 “分区容忍性” 的核心场景；之前存的 “分布式锁” 模块，换个电商场景根本用不了 —— 索性花 3 天写了个轻量化工具 edisao，把自己的知识管理流程做成了闭环，现在开源出来给有同样痛点的朋友用～

我写的原子化校验核心代码（自己调试了5次才跑通）

def check_atomicity(module: dict) -> dict:

# 针对微服务模块的校验逻辑（自己踩坑后加的）
if "微服务" in module["content"]:
    if not ("注册中心" in module["content"] and "熔断" in module["content"]):
        return {"status": "fail", "reason": "微服务模块缺核心组件"}
return {"status": "pass", "reason": "原子化检测通过"}

10分钟跑通edisao（亲测Windows/Mac通用）

1. 克隆仓库：git clone https://gitcode.com/edisao/edisao-知识管理闭环模型2.0.git
2. 装依赖：pip install -r requirements.txt（我踩的坑：Python版本要3.8+）
3. 跑第一个校验：打开test_module.yaml，填自己的技术笔记，然后运行python atomicity_check.py

目前这个工具只适配了技术知识整理，接下来打算加 “考研考点模板”（自己也在备考），如果有朋友用了发现问题，欢迎去 GitCode 提 Issues~
https://gitcode.com/edisao/edisao-pkm-v2-core

过去，AI 更像是一个工具。

你问，它答；你用，它停。
真正的事情，还是要人自己完成。

但现在，智能体的出现，正在改变这一点。

一、智能体不是更聪明，而是开始“做事”

很多人第一次接触智能体，会以为它只是更聪明的 AI。

但真正的区别在于：
智能体能把一件事情，从头到尾完成。

你只需要给出目标，它会拆解步骤、调用工具、执行流程、检查结果，直到任务结束。这种能力，让 AI 从“回答者”变成了“执行者”。

二、智能体最先改变的，是大量低价值工作

在大多数人的工作和生活中，有一类事情既不复杂，也不重要，却非常耗时间：

• 信息搜索与整理
• 内容初稿生成
• 报告结构搭建
• 格式修改与重复调整
• 日常资料汇总

这些工作长期消耗精力，却难以体现价值。
智能体的出现，正在接管这些流程。

三、使用智能体的人，工作结构正在发生变化

当执行被系统接管，人自然会把时间放在更重要的事情上：

• 判断方向是否正确
• 决定是否继续
• 选择最优结果
• 进行最终修正

你不再被流程拖住，而是只对结果负责。

四、智能体降低了完成复杂任务的门槛

过去，研究、分析、写作、整理等工作需要长期积累经验；现在，这些流程中的大量步骤可以被智能体接管，普通人只需清楚目标、检查结果，就能完成原本难以完成的事情。

这也是为什么，越来越多非技术用户开始主动使用智能体。

五、真正的变化，是工作方式而不是工具

从工具到系统，是智能体带来的最大改变。

当人开始把执行交给智能体，把判断留给自己，工作方式本身就已经发生变化。这种变化，会持续影响每一个人的效率、节奏与价值位置。

结语

智能体不会一夜改变一切，但会持续改变每一个使用它的人。

对普通人来说，越早建立这种新的工作方式，就越早拥有主动权。

工业AI大模型作为人工智能技术在工业领域的高度集成与应用，正在深刻改变汽车制造业的生产方式和管理逻辑。其核心在于通过融合多模态数据、应用深度学习算法以及构建全局优化系统，解决传统汽车制造中长期存在的效率瓶颈、数据割裂和质量波动等问题。在数字化转型的大背景下，工业AI大模型不仅是技术升级的工具，更是企业实现智能化运营的关键驱动力。
一、工业AI大模型的核心原理与技术架构
工业AI大模型的引入，标志着汽车制造业从“经验驱动”向“数据驱动”范式的转变。传统汽车工厂依赖人工经验制定生产计划，面对多车型混流、设备状态复杂和供应链波动等问题时，往往难以快速响应。而工业AI大模型通过整合设备、人员、物料、订单等多维度数据，结合实时监控和动态分析，能够实现全流程的协同优化。
二、工业AI大模型在汽车制造中的实际应用价值
工业AI大模型的应用正在从根本上重塑汽车制造的生产效率、质量控制和资源利用率。在焊装车间，传统的人工质检不仅效率低下，而且容易受到主观因素影响。而AI大模型通过实时采集焊接电流、电压、压力等参数，并结合多模态数据（如视觉信息、温度场数据）进行动态分析，能够快速识别虚焊、漏焊等缺陷，甚至在问题发生前进行预警。
三、工业AI大模型的案例解析
在汽车工厂数字化转型的实践中，工业AI大模型已经展现出其强大的赋能能力。以下将通过几个具体案例，深入探讨工业AI大模型在汽车制造中的应用效果。
广域铭岛：多模态工业大模型助力汽车制造智能化升级
广域铭岛的Geega工业AI应用平台在汽车制造中发挥了重要作用。其核心技术包括多模态数据融合、实时决策和闭环控制，覆盖了焊装车间、尺寸精度控制、工艺设计和供应链管理等多个环节。在焊装车间，平台每秒采集20多个关键参数，通过AI模型动态识别虚焊和漏焊问题，并自动生成补偿指令，大幅提升了生产效率和质量稳定性。
赛力斯汽车：超级工厂的智能排产与质检
赛力斯汽车在龙兴超级工厂中引入工业AI大模型，实现了生产全过程的智能化管理。通过部署3000多台智能制造机器人，结合AI驱动的排产优化系统，赛力斯成功将关键生产工序的自动化率提升至100%。这不仅减少了人为干预，还提高了生产效率和资源利用率。
东风设备制造有限公司：焊接工艺的智能优化
东风设备制造有限公司的焊装Agent 1.0系统是工业AI大模型在焊接工艺优化中的典型应用。该系统通过实时采集和分析焊接数据，实现了虚焊、漏焊等缺陷的快速识别和自动修复。与传统方法相比，Agent 1.0不仅缩短了排查时间，还提升了焊接质量的一致性，为企业带来了显著的经济效益。

背景

一开始是通过Api获取数据，但是最近他们增加X-Gnarly参数，而且在github上没有找有效的方案后，放弃api请求，改用页面爬取的方式。彻底避免参数加密校验。

我的环境

    python 3.11 
    selenium 4.39.0
    playwright 1.57.0

评论页面

实现啦抓取第一页和第二页的评论，你们要是抓更多页可以吧第二页改成循环。
执行脚本后会在当前目录生成一份json文件，里面是/api/comment/list/接口返回的数据。

 python3.11 comment_scraper.py "@mahi.islam.oliva/video/7565942090039954706"

代码如下：

import json
import time
import sys
import base64
import re,os
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import argparse



def merge_comments(first_page, second_page):
    """合并两页的评论数据"""
    merged_data = first_page.copy()
    if 'comments' in second_page:
        if 'comments' not in merged_data:
            merged_data['comments'] = []
        merged_data['comments'].extend(second_page['comments'])
    return merged_data

def extract_tiktok_filename(path: str) -> str:
    """
    从 TikTok 路径（如 '@username/video/123456'）中提取 'username_123456'
    支持带或不带 @、带 URL 等情况
    """
    # 匹配模式：可选的 @ + 用户名（字母数字下划线.）+ /video/ + 数字ID
    match = re.search(r'@?([\w.]+)/video/(\d{16,})', path)
    if match:
        username = match.group(1)
        video_id = match.group(2)
        return f"{username}_{video_id}"
    else:
        # 如果格式不符，回退到清理后的通用方式
        safe = re.sub(r'[\\/:*?"<>|\s]+', '_', path.strip('@/'))
        return safe[:100]


class TiktokScraper:
    def __init__(self):
        self.comments_data = []
        self.setup_driver()


    def setup_driver(self):

        chrome_options = Options()
        chrome_options.set_capability("goog:loggingPrefs", {"performance": "ALL"})

        chrome_options.add_argument("--start-maximized")
        chrome_options.add_argument("--no-sandbox")
        chrome_options.add_argument("--headless=new")
        chrome_options.add_argument("--disable-dev-shm-usage")
        chrome_options.add_argument("--disable-blink-features=AutomationControlled")
        chrome_options.add_argument("--disable-infobars")
        chrome_options.add_argument("--disable-extensions")
        chrome_options.add_argument("--disable-gpu")  # 减少 WebGL 差异（可选）
        chrome_options.add_experimental_option("excludeSwitches", ["enable-automation"])
        chrome_options.add_experimental_option('useAutomationExtension', False)

        user_agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
        chrome_options.add_argument('user-agent={0}'.format(user_agent))

        self.driver = webdriver.Chrome(options=chrome_options)

        self.driver.execute_cdp_cmd("Emulation.setDeviceMetricsOverride", {
            "width": 1440,
            "height": 900,
            "deviceScaleFactor": 2,  # macOS Retina
            "mobile": False
        })

        # 覆盖 WebGL 参数（关键！）
        self.driver.execute_cdp_cmd("Emulation.setHardwareConcurrencyOverride", {"hardwareConcurrency": 8})
        # 1. 设置基础 UA（CDP 安全方式）
        self.driver.execute_cdp_cmd("Emulation.setUserAgentOverride", {
            "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
            "platform": "MacIntel"
        })

        # 2. 用 JS 覆盖高级指纹（包括 userAgentData）
        self.driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {
            "source": """
#             delete navigator.__proto__.webdriver;

            Object.defineProperty(navigator, 'platform', { get: () => 'MacIntel' });
            Object.defineProperty(navigator, 'languages', { get: () => ['en-US', 'en'] });

            // 伪造 userAgentData
            if (!navigator.userAgentData) {
                Object.defineProperty(navigator, 'userAgentData', {
                    value: {
                        brands: [
                            { brand: "Chromium", version: "120" },
                            { brand: "Google Chrome", version: "120" },
                            { brand: "Not:A-Brand", version: "99" }
                        ],
                        mobile: false,
                        platform: "macOS",
                        getHighEntropyValues: async (hints) => ({
                            architecture: "x86_64",
                            model: "",
                            platform: "macOS",
                            platformVersion: "13.5",
                            uaFullVersion: "120.0.6099.0"
                        })
                    },
                    writable: false,
                    configurable: false
                });
            }
            """
        })

        # 覆盖 WebGL 渲染器（防指纹关键）
        self.driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {
            "source": """
            const getParameter = WebGLRenderingContext.prototype.getParameter;
            WebGLRenderingContext.prototype.getParameter = function(param) {
                if (param === 37445) return 'Apple Inc.'; // UNMASKED_VENDOR_WEBGL
                if (param === 37446) return 'Apple GPU';   // UNMASKED_RENDERER_WEBGL
                return getParameter.call(this, param);
            };
            """
        })
        self.driver.execute_cdp_cmd("Emulation.setTimezoneOverride", {"timezoneId": "America/New_York"})
        self.driver.execute_cdp_cmd("Emulation.setLocaleOverride", {"locale": "en-US"})

    def extract_comment_response_from_logs(self):
        """从 performance 日志中提取评论 API 的完整响应"""
        try:
            logs = self.driver.get_log("performance")
        except Exception as e:
            print(f"获取日志失败: {e}")
            return None

        request_id_to_url = {}
        finished_request_ids = set()

        for entry in logs:
            try:
                message = json.loads(entry["message"])
                method = message.get("message", {}).get("method")
                params = message.get("message", {}).get("params", {})

                if method == "Network.responseReceived":
                    url = params.get("response", {}).get("url", "")
                    request_id = params.get("requestId")
                    if request_id and re.search(r'comment.*list|comments.*aweme', url, re.I):
                        request_id_to_url[request_id] = url

                elif method == "Network.loadingFinished":
                    request_id = params.get("requestId")
                    if request_id:
                        finished_request_ids.add(request_id)
            except Exception:
                continue

        for req_id, url in request_id_to_url.items():
            if req_id in finished_request_ids:
                try:
                    body = self.driver.execute_cdp_cmd(
                        "Network.getResponseBody",
                        {"requestId": req_id}
                    )
                    raw = body.get("body", "{}")
                    if body.get("base64Encoded"):
                        raw = base64.b64decode(raw).decode("utf-8")
                    data = json.loads(raw)
                    if isinstance(data, dict) and ("comments" in data or "item_comments" in data):
                        print(f"✅ 捕获评论接口: {url}")
                        return data
                except Exception as e:
                    print(f"获取响应体失败 (req_id={req_id}): {e}")

        return None

    def scroll_comment_section(self):
        """在 .TUXTabBar-content 内部查找并滚动真正的评论列表容器"""
        script = """
            const tabContent = document.querySelector('.TUXTabBar-content');
            if (!tabContent) {
                console.log('❌ .TUXTabBar-content not found');
                return false;
            }

            // 获取所有子 div
            const candidates = Array.from(tabContent.querySelectorAll('div'));

            // 按 DOM 层级深度排序（优先选深层级的，通常是列表）
            candidates.sort((a, b) => {
                let depthA = 0, depthB = 0;
                let p = a; while (p && p !== tabContent) { depthA++; p = p.parentElement; }
                p = b; while (p && p !== tabContent) { depthB++; p = p.parentElement; }
                return depthB - depthA; // 深的优先
            });

            for (const el of candidates) {
                const style = window.getComputedStyle(el);
                const overflowY = style.overflowY;
                // 必须满足：可滚动 + 有溢出内容
                if ((overflowY === 'auto' || overflowY === 'scroll') &&
                    el.scrollHeight > el.clientHeight) {
                    el.scrollTop = el.scrollHeight+100;
                    console.log('✅ Scrolled real comment container');
                    return true;
                }
            }

            console.log('⚠️ No scrollable child found in .TUXTabBar-content');
            return false;
        """
        try:
            result = self.driver.execute_script(script)
            return result is True
        except Exception as e:
            print(f"滚动执行异常: {e}")
            return False

    def auto_play_and_load_more_comments(self, user_input):

        url = 'https://www.tiktok.com/' + user_input
        print(f"打开视频页面: {url}")
        self.driver.get(url)
        wait = WebDriverWait(self.driver, 20)
        # wait.until(EC.presence_of_element_located((By.TAG_NAME, "video")))
        # 等待评论tab加载完毕
        # wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, "div.TUXTabBar-list")))
        wait.until(EC.presence_of_element_located((By.XPATH, "//span[@data-e2e='comment-icon']")))

        print("视频评论已加载")

        # 点击评论按钮
        try:
            comment_span = wait.until(
                EC.element_to_be_clickable((By.XPATH, '//span[@data-e2e="comment-icon"]'))
            )
            print("正在点击评论图标 (span[@data-e2e='comment-icon'])...")
            self.driver.execute_script("arguments[0].click();", comment_span)
        except Exception as e:
            print(f"无法点击评论按钮: {e}")
            return

#         time.sleep(2)
#         debug_prefix = extract_tiktok_filename(user_input)
#         try:
#             # 保存 HTML
#             with open(f"{debug_prefix}_after_click.html", "w", encoding="utf-8") as f:
#                 f.write(self.driver.page_source)
#             print(f"页面 HTML 已保存: {debug_prefix}_after_click.html")
#
#             # 保存截图
#             self.driver.save_screenshot(f"{debug_prefix}_after_click.png")
#             print(f"页面截图已保存: {debug_prefix}_after_click.png")
#         except Exception as e:
#             print(f"保存调试文件失败: {e}")

        # 加载第一页评论
        first_page_data = self.wait_for_comments(10)
        if not first_page_data:
            print("未捕获到第一页评论")
            return
        self.comments_data.append(first_page_data)

        # 模拟滚动加载更多评论
        # self.driver.execute_script("document.querySelector('.TUXTabBar-content').scrollTo(0, document.querySelector('.TUXTabBar-content').scrollHeight);")
        # 改为调用新方法
        time.sleep(1)
        if self.scroll_comment_section():
            print("已滚动加载更多评论...")
            time.sleep(1)  # 等待新评论加载
        else:
            print("无法滚动评论区，可能结构变化")

        # 加载第二页评论
        second_page_data = self.wait_for_comments(10)
        if second_page_data:
            # 假设每页返回的数据结构相似，合并 comments 字段
            merged_comments = merge_comments(first_page_data, second_page_data)
        else:
            merged_comments = first_page_data
            print("未捕获到第二页评论")


        filename = f"{extract_tiktok_filename(user_input)}.json"
        print(filename)
        with open(filename, "w", encoding="utf-8") as f:
            json.dump(merged_comments, f, ensure_ascii=False, indent=2)
        print(f"评论数据已保存到: {filename}")
        print(f"   共 {len(merged_comments.get('comments', []))} 条评论")

    def wait_for_comments(self, timeout_seconds=10):
        """等待并捕获评论API响应"""
        start_time = time.time()
        while time.time() - start_time < timeout_seconds:
            comment_data = self.extract_comment_response_from_logs()
            if comment_data:
                return comment_data
            time.sleep(0.5)
        return None

    def close(self):
        if hasattr(self, "driver"):
            self.driver.quit()


def main():
    parser = argparse.ArgumentParser(
        description="Scrape TikTok comments via /api/comment/list/ ")
    parser.add_argument(
        "video_input",
        help="TikTok video URL or video_id, e.g., '/@user/video/7318855966163275054' "
    )
    args = parser.parse_args()

    video_input = args.video_input.strip()
    print(video_input)

    if not video_input:
        print("Error: Video input cannot be empty")
        sys.exit(1)


    scraper = TiktokScraper()
    try:
        scraper.auto_play_and_load_more_comments(video_input)
        time.sleep(1)  # 保持窗口打开以便观察
    finally:
        scraper.close()

    sys.exit(0)

if __name__ == "__main__":
    main()

用户页面发布的视频

这里只实现啦只第一页接口的数据， /api/post/item_list/把这个接口的数据放到啦一个json文件中。
这个页面我做了根据cookie的登陆，其实不登陆应该也可以。cookie 文件是通过chrome扩展 Cookies.txt 生成。登陆TikTok后点击这个扩展下载文件下来就行。

python3.11 post_item_list.py @dlw2026

post_item_list.py 代码如下：

# scraper.py
import asyncio
import json
import sys
import argparse
from playwright.async_api import async_playwright
from cookies import load_cookies_safely


# 这是用来抓取用户主页的 /api/post/item_list/


async def scrape_tiktok_user(username):
    target_responses = []
    clean_username = username.lstrip("@")
    output_json = clean_username + "_posts.json"
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = await browser.new_context(
            viewport={"width": 1920, "height": 1080},
            user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
        )

        cookies = load_cookies_safely()
        await context.add_cookies(cookies)
        page = await context.new_page()

         # 隐藏自动化特征
        await page.add_init_script("""
            // 隐藏 webdriver 标志
            delete navigator.__proto__.webdriver;
            window.chrome = { runtime: {} };
            // 伪造 platform 为 Mac
            Object.defineProperty(navigator, 'platform', {
                get: () => 'MacIntel'
            });
            // 伪造 userAgentData（高熵指纹）
            if (!navigator.userAgentData) {
                Object.defineProperty(navigator, 'userAgentData', {
                    value: {
                        brands: [
                            { brand: "Chromium", version: "120" },
                            { brand: "Google Chrome", version: "120" },
                            { brand: "Not:A-Brand", version: "99" }
                        ],
                        mobile: false,
                        platform: "macOS",
                        getHighEntropyValues: async (hints) => ({
                            architecture: "x86_64",
                            model: "",
                            platform: "macOS",
                            platformVersion: "13.5",
                            uaFullVersion: "120.0.6099.0"
                        })
                    },
                    writable: false,
                    configurable: false
                });
            }
        """)

        # ✅ 关键：宽松匹配 API（不再检查 content-type）
        def handle_response(response):
            url = response.url
            if (
                    "/api/post/item_list/" in url
                    and response.status == 200
                    and "tiktok.com" in url
            ):
                if not target_responses:
                    target_responses.append(response)
                    print(f"捕获 API: {url.split('?')[0]}")

        page.on("response", handle_response)

        url = f"https://www.tiktok.com/{username}"
        print(f"打开页面: {url}")
        await page.goto(url, wait_until="domcontentloaded", timeout=50000)

        # 等待用户信息出现
        try:
            await page.wait_for_selector('h1[data-e2e="user-title"]', timeout=15000)
            print("用户主页加载成功")
        except:
            print("用户信息未加载，继续尝试...")

        # 滚动一下，触发懒加载（重要！）
        await page.evaluate("window.scrollTo(0, document.body.scrollHeight / 3)")

        # 等待 API（最多 20 秒）
        for i in range(40):
            if target_responses:
                break
            if i % 10 == 0:
                print(f"⏳ 等待 API 中... ({i * 0.5}s)")
            await asyncio.sleep(0.5)

        api_data = None
        if target_responses:
            try:
                api_data = await target_responses[0].json()
                print("✅ 成功解析 JSON 数据")
            except Exception as e:
                # 如果 .json() 失败，可能是 text/plain，手动解析
                try:
                    text = await target_responses[0].text()
                    api_data = json.loads(text)
                    print("✅ 通过 .text() 成功解析 JSON")
                except:
                    print(f"❌ 完全无法解析响应: {e}")

        if api_data:
            with open(output_json, "w", encoding="utf-8") as f:
                json.dump(api_data, f, ensure_ascii=False, indent=2)
            items = api_data.get("itemList", [])
            print(f"抓取到 {len(items)} 个视频，已保存至 {output_json}")
        else:
            print("未捕获到任何 API 数据")
            # 调试：打印所有请求（可选）
#             await page.route("**/*", lambda route: print("REQ:", route.request.url) or route.continue_())
#         screenshot_path = f"{clean_username}_homepage.png"
#         await page.screenshot(path=screenshot_path, full_page=True)
#         print(f"已保存页面截图: {screenshot_path}")

        await page.wait_for_timeout(5000)
        await browser.close()
        if api_data:
            return True
        else:
            return False


def main():
    parser = argparse.ArgumentParser(description="Scrape TikTok user profile")
    parser.add_argument("username", help="TikTok username (with or without @), e.g., @dishilife or dishilife")
    args = parser.parse_args()

    username = args.username.strip()
    if not username:
        print("Error: Username cannot be empty")
        sys.exit(1)
    if not username.startswith('@'):
        username = '@' + username
    success = asyncio.run(scrape_tiktok_user(username))
    sys.exit(0 if success else 1)


if __name__ == "__main__":
    main()

cookies.py脚本：

import os
from datetime import datetime



COOKIES_FILE = "cookies.txt"

def load_cookies_safely():
    filepath = COOKIES_FILE
    if not os.path.exists(filepath):
        raise FileNotFoundError(f"❌ Cookie 文件不存在: {os.path.abspath(filepath)}")

    cookies = []
    current_ts = int(datetime.now().timestamp())
    tiktok_domains = {".tiktok.com", "www.tiktok.com"}

    with open(filepath, "r", encoding="utf-8") as f:
        for line in f:
            line = line.strip()
            if not line or line.startswith("#"):
                continue
            parts = line.split("\t")
            if len(parts) < 7:
                continue

            domain = parts[0]
            if domain.startswith("#HttpOnly_"):
                domain = domain[len("#HttpOnly_"):]
            if not domain.startswith("."):
                domain = "." + domain.lstrip(".")

            if not any(t in domain for t in tiktok_domains):
                continue

            cookie = {
                "name": parts[5],
                "value": parts[6],
                "domain": domain,
                "path": parts[2],
                "secure": parts[3].upper() == "TRUE",
            }

            expires_str = parts[4]
            if expires_str.isdigit():
                expires = int(expires_str)
                if expires > current_ts:
                    cookie["expires"] = expires

            cookies.append(cookie)

    if not cookies:
        raise ValueError("❌ 未加载有效 Cookie！请确认包含 sessionid。")
    return cookies

if __name__ == "__main__":
    print('不可以直接执行')

摘要：

OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势，精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点，助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级,成为其规模化盈利的技术基石，打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例，为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

作为马来西亚金融科技领域的领军者，TNG Digital 凭借 TNG eWallet 深度融入民众支付生活，全面覆盖交通出行、餐饮消费、资金转账等高频场景。

自 2018 年起，其用户规模实现超 10倍爆发式增长，截至 2025 年，已服务马来西亚 3300 万人口中的 2500 万验证用户，成为支撑区域数字经济运转、贯穿民生服务的关键信息基础设施。

然而，高速增长背后暗藏技术“生死考验”，OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势，精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点，助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级。

本次合作不仅成为 TNG Digital 规模化盈利的技术基石，更打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例，为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

增长阵痛：金融科技高并发场景下的核心数据底座短板

作为承载马来西亚数千万用户日常支付的核心平台，TNG Digital 的系统稳定性直接关系到民生服务体验与金融市场秩序。

Leslie Lip（TNG Digital CTO）坦言，业务年增长率达 2-3 倍的背后，是技术团队不断与“规模陷阱”博弈的过程。

核心痛点集中于数据底座的四大短板：

· 突发流量峰值应对失效

午间支付高峰时段，全钱包系统需承载巨大的交易压力，而原有数据库难以支撑政府补贴发放等非常规突发流量。TNG Digital 曾在 6 年前发生的数据异常，正是因为原有数据库架构缺陷导致服务器资源未充分利用从而陷入瓶颈，暴露了核心数据底座的“抗冲击”能力不足。

· 业务迭代中的停机风险

金融科技平台需通过高频表结构更新，适配支付场景创新，但原有数据库的 DDL 变更常导致生产环境停机，直接影响用户支付、转账等核心操作的连续性，成为业务快速迭代的“绊脚石”。

· 多云扩展的兼容性壁垒

业务初期依托阿里云，随规模扩张延伸至 Azure、AWS 等多平台，但不同云厂商的数据库服务存在适配鸿沟，既无法实现跨云协同运维，又面临被单一厂商绑定的“vendor lock-in”风险，制约 TNG Digital 的全球化布局步伐。

· 性能与成本的失衡困境

用户增长带来数据量爆发式累积，原有数据库存储效率低下，导致 IDC 运维与存储成本持续攀升；同时在相同硬件规格下，吞吐量难以匹配业务增长需求，形成“成本涨、性能滞”的恶性循环。

OceanBase 破局之道：以“支付级”能力适配金融科技核心需求

Leslie Lip 强调，选择 OceanBase 的核心逻辑是“解决真实业务痛点，而非单纯追求技术参数升级”。

针对 TNG Digital 在支付场景高并发、业务连续性、多云扩展等方面的核心诉求，OceanBase 提供了贴合金融科技特性的全链路解决方案：

01零停机解决核心技术破解迭代难题

依托原生分布式架构设计，OceanBase 实现核心表 DDL 操作零停机执行的关键技术突破——在 POC 阶段即完成 4 万 TPS CRUD 并发场景下的表结构更新测试，全程无业务中断、无性能衰减。

这一技术特性彻底解决了 TNG Digital 高频迭代中的停机隐患，为支付场景快速创新扫清核心技术障碍。

02原生分布式架构扛住峰值压力

OceanBase 采用“share-nothing”原生分布式架构，具备线性弹性扩展能力，可按需扩容支撑业务增长。

该技术特性使其既能轻松承接午间的常规高峰流量，更能应对政府补贴发放等非常规突发流量的冲击，从底层架构层面杜绝宕机风险，完美匹配支付场景对高可用的极致要求。

03全栈多云一致性体验能力

OceanBase 内置全栈多云兼容技术模块，通过统一的技术接口与适配层，完美兼容阿里云、Azure、AWS 三大云平台的底层环境，实现不同云平台下的部署架构、运维操作、性能表现及合规审计的全链路一致性体验。

这一核心技术特性，不仅为 TNG 搭建了 “以私有化部署为核心、多云协同为延伸” 的弹性 IT 架构，保障了征信数据跨云流转与管理的稳定性、安全性，更从技术层面帮助 TNG Digital 彻底摆脱 “vendor lock-in” 制约，为其后续拓展东南亚其他区域征信服务、接入更多全球云服务提供商奠定了核心基础，让 TNG Digital 在全球化业务布局中具备更强的技术灵活性与成本可控性。

04高压缩比+高性能优化技术提升效益

OceanBase 基于高压缩的数据引擎，实现 5 倍数据体积缩减的技术效果，大幅降低存储与运维成本。

同时凭借分布式执行引擎优化技术，在相同硬件规格下实现 40% 的吞吐量提升，精准破解 TNG Digital “成本涨、性能滞”的核心困境，为金融科技企业盈利化发展提供技术支撑。

05全量 MySQL 兼容技术加速落地见效

OceanBase 深度打磨 MySQL 兼容层技术，实现语法、应用行为、驱动的全量兼容。

这一技术特性使 TNG Digital 技术团队无需额外学习成本即可快速上手，大幅缩短项目升级与落地周期，实现技术升级的“平滑过渡”。正如 Leslie Lip 所言，OceanBase 不仅是数据库，更是“能伴随企业野心共同成长的技术平台”。

实现从“生存线”到“增长线”的价值跃升

基于 OceanBase 完成核心数据底座升级后，TNG Digital 在业务稳定性、运营效率、创新能力三大维度实现质的飞跃，关键成效完全匹配金融科技支付场景的核心诉求：

01支付连续性达行业顶尖水平

核心系统实现 99.99% 的高可用，与 OceanBase 合作至今，未发生任何数据库事故，成功支撑多轮政府补贴发放等重大场景的平稳运行，彻底摆脱过往宕机阴影，筑牢支付业务“生存线”。

02性能与成本效益双突破

相同硬件规格下，业务吞吐量提升 40%，高效承接高峰期高并发交易；5 倍数据压缩比大幅降低存储成本，为企业盈利化发展提供有力支撑，将数据底座从“成本中心”转化为“效益中心”。

03创新与拓展能力全面释放

零停机 DDL 与多云协同能力，为 TNG Digital 的场景迭代与跨平台拓展扫清障碍。

目前双方已启动键值数据库模型搭建、跨云双活架构合作等计划，将基于 OceanBase 构建更具弹性的时间敏感型支付应用，进一步拓宽业务增长边界。

从服务本土支付场景的分布式数据库，到支撑海外支付场景的分布式数据库

金融科技的规模化增长，本质是数据底座“抗冲击能力、迭代能力、扩展能力”的综合较量。

TNG Digital 作为东南亚支付领域的龙头企业，其面临的“高并发、零中断、多云扩展”痛点，是全球金融科技企业规模化过程中的共性难题。OceanBase 的成功落地，不仅解决了单一企业的技术困境，更提供了适配支付场景核心需求的可复制技术方案。

OceanBase 与 TNG Digital 的合作，标志着分布式数据库凭借“原生分布式+零停机+全栈多云兼容”等硬核技术特性，已具备支撑海外头部金融科技核心支付场景的成熟能力，实现从“国内核心场景验证”到“海外高频支付场景落地”的关键跨越。

区别于其他出海案例，此次合作的核心亮点在于以技术特性精准匹配支付场景需求——零停机保障业务迭代连续性，原生分布式支撑高并发峰值，多云兼容打破拓展壁垒，这些技术优势共同重塑了海外市场对分布式数据库基础软件在支付场景下的技术认知。

未来，OceanBase 将持续深化与 TNG Digital 的协同创新，助力其实现云服务提供商拓展、跨云韧性升级等战略目标，同时进一步完善东南亚市场的本地化服务体系，聚焦金融科技支付、数字钱包等核心场景，为更多海外企业提供“支付级”稳定、高效、经济的数据底座支撑，推动分布式数据库基础软件全球化布局向“场景化深度赋能”新阶段迈进。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

随着中国大模型技术从研发攻坚迈向规模化应用，“现在学智能值不值”成为无数学习者、求职者关注的核心命题。有人因“500 万人才缺口”的行业红利心动，也有人担忧技术迭代快、学习成本高的风险。判断其价值，需立足产业发展规律、人才需求结构与个人发展定位综合研判，以下内容将结合权威数据与典型案例，给出清晰答案与实操指引。

🚀快速回答

现在学智能值得投入，但需精准定位而非盲目跟风。核心结论：产业升级催生刚性需求，智能人才缺口大、薪资高，“智能 + 行业”复合型人才价值凸显；对学习者而言，只要匹配自身基础选择适配方向（科研攻坚/行业应用），通过实践提升能力，就能将技术转化为长期竞争力；潜在风险可通过精准选课、参与项目规避。

一、核心背景：智能产业爆发，人才需求进入刚性增长期

智能技术已成为新质生产力的核心支撑，国内产业规模与人才需求的双重增长，为学习者提供了核心价值基础，相关数据均来自官方发布与权威机构报告，具备强可信度。

1.1 产业规模持续扩张，政策持续护航

• 工业和信息化部数据：我国人工智能核心产业规模已突破 6000 亿元，企业数量超 4700 家，且仍保持高速增长态势
• 中国信通院《人工智能发展白皮书（2025）》预测：到 2035 年我国人工智能产业规模有望达 1.73 万亿元，全球占比将达 30.6%
• 政策导向：工信部明确 2025 年实施“人工智能 + 制造”行动，重点推进通用大模型和行业大模型的研发布局与场景应用，降低企业转型门槛的同时，扩大了智能人才的需求场景

1.2 人才缺口巨大，薪资优势显著

二、核心论据：学智能的 3 大核心价值，覆盖个人发展全周期

学习智能的价值不仅体现在短期就业红利，更在于长期职业边界拓展与竞争力提升，以下结合不同行业场景的实际案例展开说明。

2.1 价值一：刚性就业需求，优质岗位选择多

智能人才需求已从互联网领域延伸至千行百业，不同基础的学习者都能找到适配岗位，典型场景与案例如下：

• 制造业场景：工业机器人工程师岗位需求同比增长 60.6%，机器人调试工程师增速达 64.1%（来源：人社部《制造业人才需求报告》）；案例——美的集团通过“智能 + 制造”培训计划，招聘的智能设备运维人才，入职半年平均薪资涨幅达 25%
• 医疗领域场景：“AI+ 生物医药”岗位因跨界属性稀缺，曾出现连续 327 天悬空的情况（来源：丁香人才网）；案例——药明康德与高校合作开设“AI 药物研发”定向班，学员未毕业即被预定，起薪超 35 万元/年
• 政务民生场景：智能客服、智能风控、智能教育等岗位普及，案例——支付宝智能风控团队招聘的 AI 数据分析人才，负责交易风险识别，平均年薪达 45 万元

2.2 价值二：突破职业边界，“智能 + 行业”跨界优势明显

掌握智能技术无需局限于算法工程师单一岗位，更可成为传统行业的“智能转型推动者”，解决行业实际痛点：

• 教育行业：懂智能的教师可借助 AI 教学系统实现个性化备课，降低工作强度的同时提升教学效果
• 金融行业：具备智能分析能力的理财顾问，可通过 AI 工具精准匹配客户需求，业绩平均提升 30%（来源：招商银行内部培训数据）
• 工业行业：懂智能的生产线工程师可通过 AI 优化生产流程，案例——黑猫集团工程师借助大模型优化炭黑生产工艺，实现备件消耗减少 20%（来源：企业官方发布）

2.3 价值三：长期竞争力保值，适配技术迭代趋势

智能技术是未来 10-20 年的核心产业方向，掌握相关能力可规避传统行业的中年危机：

• 数据支撑：我国基础层 AI 人才占比仅 17.1%，低于美国的 22.8%，核心算法领域人才缺口长期存在（来源：中国信通院）
• 迭代适配：行业更看重“学习能力”而非“单一技术掌握”，只要保持持续学习习惯，就能适配技术更新（如从传统机器学习转向大模型应用）

三、深度解读：学智能的风险与规避方案，精准避坑

客观来看，学习智能存在技术迭代快、学习成本高、区域资源不均等挑战，但通过精准定位可有效规避，以下是具体问题与解决方案的对应梳理。

3.1 核心挑战梳理

• 挑战 1：学用脱节——78.6% 的高校 AI 课程仍以传统机器学习为主，与产业前沿的 MoE 架构、联邦学习等技术存在代际差（来源：教育部《高校 AI 专业教学评估报告》）
• 挑战 2：成本较高——自学需投入大量时间，报班费用普遍在 1-5 万元，且需要配置一定的算力设备
• 挑战 3：区域资源不均——90% 的 AI 人才聚集于十大城市，中西部地区本地技术团队不足，就业机会较少（来源：智联招聘区域人才报告）
• 挑战 4：顶尖人才竞争激烈——核心算法领域顶尖人才流失率达 63%，对科研能力要求极高（来源：中国信通院）

3.2 分人群规避方案

• 科研能力较强者（本科及以上学历，数学/计算机基础好）：

  • 方向：聚焦基础层算法研发，投身大模型、核心芯片等关键领域，弥补产业短板
  • 方案：参与高校科研项目、开源社区贡献（如 TensorFlow、PyTorch 社区），提升学术与实践能力

• 侧重应用者（基础一般，想快速就业）：

  • 方向：选择“AI+ 具体行业”的跨界方向（如 AI+ 教育、AI+ 制造、AI+ 医疗）
  • 方案：参与产教融合课程（如上海交大“AI+X”模式，医学与 AI 课程合并，企业导师深度参与，培养周期缩短 40%）、企业实训项目，提升实操能力

• 中西部地区学习者：

  • 方向：聚焦本地优势产业的智能转型需求（如中西部制造业的智能运维、农业的智能种植分析）
  • 方案：选择线上优质课程（如 Coursera 官方 AI 课程、国内高校公开课），参与远程实训项目，积累跨区域项目经验

四、FAQ：学习者高频疑问解答

• 问：零基础能学智能吗？需要哪些基础？ 答：可以。核心基础包括：高中数学（函数、概率、线性代数）、基本计算机操作；零基础建议从应用层切入（如 AI 工具使用、简单模型调参），再逐步深入技术原理，避免直接攻坚核心算法。
• 问：学习智能需要多久才能就业？答：因人而异。应用层方向（如 AI 运维、智能客服系统操作）3-6 个月可掌握核心技能；技术层方向（如模型调参、算法实现）需 1-2 年系统学习；核心算法研发需 3 年以上专业积累（含学历背景）。
• 问：现在学智能，会不会等毕业时技术已经过时？ 答：大概率不会。原因：1）智能产业仍处于高速增长期，核心需求（数据处理、模型应用、行业适配）长期存在；2）行业看重“解决问题的能力”而非“单一技术掌握”，持续学习习惯比具体技术更重要；3）可选择“技术 + 行业”的复合方向，行业经验会随时间增值，规避技术迭代风险。
• 问：自学和报班哪个更合适？ 答：根据自身情况选择：1）自律性强、有基础者（如计算机专业学生）可自学，通过开源项目、线上课程积累经验；2）零基础、自律性一般者建议报班，优先选择有企业实训、就业推荐的产教融合课程，降低学用脱节风险。
• 问：智能相关岗位对学历有要求吗？ 答：分岗位层级：1）基础应用岗（如 AI 设备运维、智能系统操作）大专及以上即可，更看重实操能力；2）技术层岗位（如模型调参、算法工程师）普遍要求本科及以上，优先计算机、数学、电子信息等相关专业；3）核心研发岗（如大模型算法、核心芯片设计）多要求硕士及以上学历，且需科研成果或优质项目经验。

五、总结：学智能的价值判断与行动建议

综上，现在学智能的“值”，核心源于产业升级带来的刚性需求、技术赋能带来的职业拓展，以及长期竞争力的保值增值；风险则可通过精准定位学习方向、选择适配的学习路径有效规避。

行动建议：1）先明确自身定位（科研/应用、目标行业），避免盲目跟风；2）优先选择“智能 + 行业”的复合方向，提升就业适配度；3）注重实践能力积累，通过项目实训、开源贡献弥补学用脱节；4）保持持续学习习惯，关注产业前沿动态（如大模型行业应用、政策导向）。

在新质生产力加速发展的背景下，智能技术已成为个人发展的“核心加分项”，只要找对方向、精准发力，学习智能就能成为把握时代机遇、实现个人价值提升的明智选择。

祝 jQuery 20岁生日快乐。

自 John Resig 在 2006 年发布 jQuery 以来，这个库已经陪伴 Web 开发走过了二十个年头。而在距离上一次主要版本发布近十年后，jQuery 团队正式推出了 jQuery 4.0.0。

很多人可能觉得 jQuery 已经是时代的眼泪，但看到 jQuery 4.0.0 正式发布的消息时，还是不得不感叹法拉利老了还是法拉利。

这次更新可不是简单的修修补补，这次团队清理了多年的技术债务，移除了过时的 API，这个经典库终于也能跟上现代 Web 开发的节奏。

以下是这次更新中几个最值得关注的变化：

告别旧版的浏览器

这应该是最喜闻乐见的改动了。jQuery 4.0.0 正式停止支持 IE 10 及以下版本。目前仅保留对 IE 11 的支持，但这只是暂时的，团队计划在未来的 jQuery 5.0 中彻底移除 IE 支持。此外，旧版 Edge（Edge Legacy）、iOS 11 以下版本、Firefox 65 以下版本以及旧版 Android 浏览器的支持也被移除。

只要不是做古董级项目，包体积会更小，运行速度也会更快。

移除过时的 API

随着原生 JavaScript（ES6+）功能的完善，许多 jQuery 早期的辅助函数已失去存在的意义。4.0 版本移除了大量此类 API，包括用于去除字符串空格的 jQuery.trim、判断数组的 jQuery.isArray、解析 JSON 的 jQuery.parseJSON 等。

此外，一些仅供内部使用的数组方法（如 push、sort 和 splice）也从 jQuery 原型中移除。现在，开发者应直接使用原生的 JavaScript 方法来替代这些旧功能。

源码 迁移至 ES Modules

jQuery 的源码终于从旧式的 AMD 模块系统迁移到了 ES Modules。 这下 jQuery 能更丝滑地融入 Vite、Rollup 或 Webpack 等现代构建工具链。而且，在浏览器中可以通过模块化的方式直接加载和运行 jQuery，符合现代开发流程。

焦点事件顺序回归 W3C 标准

在很长一段时间里，不同浏览器对焦点事件（focus/blur/focusin/focusout）的触发顺序存在分歧。jQuery 曾为了统一行为而强制了一套自己的顺序。

现在，所有主流浏览器已达成一致，jQuery 4.0.0 决定不再进行人工干预，直接遵循 W3C 标准顺序，blur -> focusout -> focus -> focusin。这属于破坏性更新，如果现有项目严重依赖特定的事件触发顺序，升级时需格外注意。

更轻量的 Slim 版本

新的 Slim 版本（精简版）移除了 Deferreds 和 Callbacks 模块，体积进一步缩小（gzip 后减少约 8KB）。

由于现代浏览器（除 IE11 外）都已原生支持 Promise，大多数异步操作已不再需要 jQuery 的 Deferreds。如果是面向现代浏览器的项目，Slim 版本将是更优的选择。

快速上手体验

即使不为了新项目，仅仅为了情怀，很多人也想试试这个 4.0 版本。最快的方法就是通过 npm 安装 jquery@4.0.0 跑个 Demo，那一个稳定且配置好的 Node.js 环境必不可少。

如果你不想为了尝鲜就在本地折腾一堆 Node.js 配置，或者单纯觉得配环境很麻烦，可以试试 ServBay。它能一键把 Node.js 环境部署好，自动搞定路径配置和版本管理。

环境弄好后，直接在目录里运行 npm 命令拉取最新的 jQuery 就能直接玩，省时省力。

结语

jQuery 4.0.0 的发布证明了它并躺平，而是在努力适应现代 Web 标准，就像一个武林高手，闭关10年，出关后变得更强了。

无论是为了维护现有资产，还是为了在特定场景下快速开发，这个新版本都交出了一份合格的答卷。

最后，这个时代的眼泪还有多少用户知道？

在这个行业里摸爬滚打了十多年，我常常感觉，我们这些做邮件营销的人，就像是在客户的邮箱里“开小店”。每一天，无数个“店铺招牌”（也就是邮件主题）在客户眼前闪过。想让客户在匆匆一瞥中为你驻足，甚至推开你这扇门，真的需要点真功夫。

今天，我就和大家聊聊这个决定“开门率”的第一关——邮件主题行。这不仅仅是一行字，这是你和客户之间最精炼、最关键的对话开端。
一、信任是基石：先让客户认识你，再期待他打开
你在琢磨怎么让主题更吸引人之前，我们必须先回到一个更根本的问题：客户凭什么相信你？想象一下，你收到两封邮件，一封来自陌生的个人邮箱，另一封来自规范的service@知名品牌.com，你会本能地更信任谁？研究显示，发件人信息的可信度直接影响打开率，使用企业官方域名邮箱能显著提升专业形象。我的实践心得：从早期创业开始，我就坚持使用专业的邮件营销平台来管理发件域名和身份认证（如SPF、DKIM）。这不仅是技术配置，更是建立品牌信任的门面。我长期合作的U-Mail邮件营销平台，在这一点上给我的帮助很大。它允许企业直接使用自己的域名作为发件后缀，这不仅让每一封邮件都成为品牌宣传，更重要的是，它联合了国内外主流邮箱运营商，建立了专属的“绿色通道”。这意味着我们的邮件能更安全、更稳定地进入客户的收件箱，而不是垃圾箱。信任，始于抵达。
二、主题行心法：像朋友一样说话，像顾问一样思考
当信任的基石打好后，主题行就是那句脱口而出的问候或提醒。它必须精准有吸引力，并且尊重对方的时间。我认为，好的主题行要做到以下三点：

1、关联与价值，缺一不可一个冰冷的“产品推荐”远不如一句“为您上周关注的XX问题，找到了三个解决方案”。主题行必须瞬间建立“与我有关”的链接。这可以是客户的姓名、公司名，也可以是您洞察到的他的业务痛点。通过U-Mail的“自定义变量”功能，我可以轻松地在主题和内容中插入客户的名字、公司或其他属性，实现基础个性化。更进一步，基于平台的地址池分类和用户行为追踪报告，我能对不同分组（比如已打开某类邮件的用户、点击过某链接的用户）设计完全不同角度的主题。例如，对互动过的客户，主题可以是“继我们上次的讨论…”，而对新客户，则突出行业解决方案价值。
2、激发好奇，但保持真诚提问和数字是制造好奇的经典技巧。“如何将季度成本降低15%？” 比 “我们的服务很好” 有力得多。引用具体数字，如“3个技巧提升您的团队效率”，能增加信息的可信度和吸引力。但切记，不要做“标题党”。过度使用“免费！”“惊天优惠！”等词汇，极易触发垃圾邮件过滤器，并损害长期信任。我常用的一个检验方法是：问自己，这个主题承诺的内容，我的邮件正文是否能够毫无水分地兑现？
3、简洁有力，移动端友好客户可能在手机上快速浏览，据统计超过60%的邮件在移动设备上打开。过长的主题会被截断。我的经验是，将主题行核心控制在30-50个字符（大约6-10个词）为佳，确保核心价值在手机通知栏或收件箱列表中就一目了然。
三、进阶的艺术：用数据让直觉更靠谱
多年的经验会形成直觉，但直觉需要用数据来验证和优化。这是我职业生涯中后期提升最大的一个环节。1、A/B测试是黄金准则：我从不凭感觉决定最终用哪个主题。对于重要邮件，我会准备2-3个不同角度（例如，一个侧重“提问”，一个侧重“价值声明”）的主题，发给一小部分用户进行A/B测试。U-Mail邮件营销平台内置的统计功能可以非常清晰地告诉我，哪个版本的打开率更高、哪个链接点击更多。用数据说话，让每一次发送都成为下一次优化的养分。
2、智能发送，事半功倍：找到最佳发送时间能显著提升打开率。除了参考通用数据（如避开周一早高峰和周末），更重要的是分析你的特定受众。通过U-Mail邮件营销平台生成的详细数据报告，我可以观察我的用户通常在哪个时间段最活跃、打开率最高。基于这些洞察，再利用平台的“定时发送”任务系统，让邮件在用户最可能查阅的时间精准送达，效果立竿见影。
四、温情提示：比技巧更重要的是“心法”
最后，我想分享几个比技术更重要的原则：

1、提供价值，而非仅仅推销：客户愿意打开的，永远是那些能为他解决问题、带来启发的内容。让你的主题成为价值预告片。
2、保持一致性：稳定的发送频率和稳定的品牌语气，会让客户逐渐熟悉并期待你的邮件。
3、尊重选择：在邮件中提供清晰、便捷的退订链接，这不仅是法律要求，也是一种尊重。维护一个干净、自愿的订阅列表，长远来看打开率和转化率会更高。
EDM邮件营销是一场与用户建立长期关系的慢舞，主题行就是优雅邀请的第一步。它需要技术工具的保障，需要数据思维的优化，但归根结底，需要的是一颗真正想为用户提供价值的心。
工欲善其事，必先利其器。像U-Mail邮件营销平台这样的专业工具，对我来说就像一个可靠的伙伴。它从确保送达的底层通道开始，到内容个性化、数据统计分析，再到基于数据的自动化任务管理，覆盖了整个营销闭环，让我能更专注于策略和创意本身，把“敲门”这件事，做得更得体、更有效。

Nuxt 3 vs Next.js：新手选型指南与项目实战对比

当Vue遇上React，服务端渲染框架如何选择？

在现代Web开发中，两大全栈框架Nuxt 3和Next.js占据着服务端渲染(SSR)领域的主导地位。它们都提供了文件系统路由、自动代码分割、SEO优化等现代Web应用所需的核心功能，但技术选型背后的技术栈差异和设计哲学却大不相同。

本文将通过对比分析，帮助前端新手理解这两大框架的区别，并提供实际的项目创建示例。

01 核心差异：Vue与React的技术栈选择

Nuxt 3与Next.js最根本的区别在于其底层技术栈：

• Nuxt 3：基于Vue 3生态系统，采用组合式API和响应式系统
• Next.js：基于React生态系统，支持最新的React特性

这种核心差异决定了你的开发体验、学习曲线以及可用的第三方库生态。

学习曲线对比

对于完全没有前端经验的新手来说，Vue通常被认为比React学习曲线更平缓。Vue的模板语法更接近传统HTML，而React的JSX则需要适应将HTML与JavaScript混合编写的模式。

生态圈对比

Next.js拥有更庞大的社区和更丰富的第三方库，这得益于React本身的普及度。Nuxt 3虽然社区规模较小，但其官方模块质量很高，且与Vue生态无缝集成。

02 快速入门：创建你的第一个应用

Nuxt 3入门示例

项目初始化：

# 创建Nuxt 3项目
npx nuxi@latest init my-nuxt-app
cd my-nuxt-app
npm install
npm run dev

创建页面和组件：

1. 在pages/index.vue中创建主页：

   <template>
     <div class="container">
    <h1>欢迎使用Nuxt 3</h1>
    <p>当前时间：{{ currentTime }}</p>
    <button @click="refreshTime">刷新时间</button>
     </div>
   </template>
   
   <script setup>
   // 使用组合式API
   const currentTime = ref('')
   
   // 获取服务器时间
   onMounted(async () => {
     const { data } = await useFetch('/api/time')
     currentTime.value = data.value
   })
   
   // 客户端交互
   const refreshTime = () => {
     currentTime.value = new Date().toLocaleString()
   }
   </script>

2. 创建API端点server/api/time.get.ts：

   export default defineEventHandler(() => {
     return new Date().toISOString()
   })

Next.js入门示例

项目初始化：

# 创建Next.js项目（使用App Router）
npx create-next-app@latest my-next-app
cd my-next-app
npm install
npm run dev

创建页面和组件：

1. 在app/page.tsx中创建主页：

   export default function HomePage() {
     return (
    <div className="container">
      <h1>欢迎使用Next.js</h1>
      <TimeDisplay />
    </div>
     )
   }
   
   // 服务端组件：自动在服务器上运行
   async function TimeDisplay() {
     // 在服务端获取数据
     const response = await fetch('http://worldtimeapi.org/api/timezone/Asia/Shanghai')
     const data = await response.json()
     
     return (
    <div>
      <p>当前时间：{data.datetime}</p>
      <ClientComponent />
    </div>
     )
   }
   
   // 客户端组件：需要"use client"指令
   'use client'
   function ClientComponent() {
     const [count, setCount] = useState(0)
     
     return (
    <button onClick={() => setCount(count + 1)}>
      点击次数：{count}
    </button>
     )
   }

03 特性深度对比：数据获取与渲染策略

数据获取方式对比

Nuxt 3的数据获取：

<template>
  <div>
    <h2>文章列表</h2>
    <div v-if="pending">加载中...</div>
    <ul v-else>
      <li v-for="post in posts" :key="post.id">
        {{ post.title }}
      </li>
    </ul>
  </div>
</template>

<script setup>
// useAsyncData用于服务端获取数据
const { data: posts, pending } = await useAsyncData(
  'posts',
  () => $fetch('https://api.example.com/posts')
)

// useFetch是useAsyncData的简写
const { data: user } = await useFetch('/api/user')
</script>

Next.js的数据获取：

// 在App Router中，页面组件默认为服务端组件
export default async function PostsPage() {
  // 直接使用fetch API，Next.js会自动优化
  const response = await fetch('https://api.example.com/posts', {
    next: { revalidate: 60 } // 每60秒重新验证
  })
  const posts = await response.json()
  
  return (
    <div>
      <h2>文章列表</h2>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
      <LikeButton postId={posts[0].id} />
    </div>
  )
}

// 客户端交互组件需要"use client"指令
'use client'
function LikeButton({ postId }) {
  const [likes, setLikes] = useState(0)
  
  return (
    <button onClick={() => setLikes(likes + 1)}>
      点赞 ({likes})
    </button>
  )
}

渲染策略对比

两个框架都支持多种渲染策略，但实现方式不同：

04 实际应用场景分析

何时选择Nuxt 3？

1. Vue技术栈项目：团队已熟悉Vue生态
2. 快速原型开发：需要快速搭建MVP产品
3. 内容型网站：博客、文档、营销页面
4. 项目结构清晰：喜欢"约定优于配置"的理念

Nuxt 3优势场景示例：

<!-- 快速创建SEO友好的内容页面 -->
<template>
  <div>
    <Head>
      <Title>产品介绍 - 我的网站</Title>
      <Meta name="description" :content="product.description" />
    </Head>
    
    <article>
      <h1>{{ product.title }}</h1>
      <!-- 内容自动渲染 -->
      <ContentRenderer :value="product" />
    </article>
  </div>
</template>

<script setup>
// 自动根据文件路径获取内容
const { data: product } = await useAsyncData('product', () => 
  queryContent('/products').findOne()
)
</script>

何时选择Next.js？

1. React技术栈项目：团队已熟悉React生态
2. 大型复杂应用：需要React丰富生态支持
3. 需要最新特性：希望使用React最新功能
4. Vercel平台部署：计划使用Vercel的完整能力

Next.js优势场景示例：

// 复杂的动态仪表板应用
export default async function DashboardPage() {
  // 并行获取多个数据源
  const [sales, users, analytics] = await Promise.all([
    fetchSalesData(),
    fetchUserData(),
    fetchAnalyticsData(),
  ])
  
  return (
    <div className="dashboard">
      <SalesChart data={sales} />
      <UserTable users={users} />
      <AnalyticsOverview data={analytics} />
      {/* 实时更新的客户端组件 */}
      <LiveNotifications />
    </div>
  )
}

// 使用React Server Components实现部分渲染
'use client'
function LiveNotifications() {
  const [notifications, setNotifications] = useState([])
  
  useEffect(() => {
    // 建立WebSocket连接获取实时数据
    const ws = new WebSocket('wss://api.example.com/notifications')
    // ... 处理实时数据
  }, [])
  
  return <NotificationList items={notifications} />
}

05 开发体验与工具链对比

Nuxt 3的开发体验

1. 零配置起步：大多数功能开箱即用
2. 模块系统：官方和社区模块质量高
3. TypeScript支持：一流的TypeScript体验
4. 开发工具：Nuxt DevTools提供强大调试能力

# Nuxt 3的典型工作流
npx nuxi@latest init my-project  # 创建项目
npm install                       # 安装依赖
npm run dev                       # 开发模式
npm run build                     # 生产构建
npm run preview                   # 预览生产版本

Next.js的开发体验

1. 灵活的配置：可根据需要深度定制
2. TurboPack：极快的构建和刷新速度
3. 完善的文档：官方文档质量极高
4. Vercel集成：无缝部署和预览体验

# Next.js的典型工作流
npx create-next-app@latest my-app  # 创建项目
npm install                        # 安装依赖
npm run dev                        # 开发模式
npm run build                      # 生产构建
npm run start                      # 启动生产服务器

06 性能与优化对比

性能特征

1. 首次加载性能：两者都优秀，Nuxt 3在小型项目上可能略快
2. 开发服务器速度：Next.js的Turbopack在大型项目上优势明显
3. 构建速度：取决于项目大小，两者都提供增量构建

优化技巧对比

Nuxt 3优化示例：

<!-- 组件懒加载和图片优化 -->
<template>
  <div>
    <!-- 延迟加载重型组件 -->
    <LazyMyHeavyComponent v-if="showComponent" />
    
    <!-- 自动优化的图片 -->
    <NuxtImg
      src="/images/hero.jpg"
      width="1200"
      height="600"
      loading="lazy"
      format="webp"
    />
  </div>
</template>

Next.js优化示例：

// 使用Next.js内置优化功能
import Image from 'next/image'
import dynamic from 'next/dynamic'

// 动态导入重型组件
const HeavyComponent = dynamic(() => import('./HeavyComponent'))

export default function OptimizedPage() {
  return (
    <>
      {/* 自动优化的图片组件 */}
      <Image
        src="/hero.jpg"
        alt="Hero image"
        width={1200}
        height={600}
        priority={false} // 非关键图片延迟加载
      />
      
      {/* 条件加载重型组件 */}
      <HeavyComponent />
    </>
  )
}

07 新手选择建议

根据背景选择

1. 完全零基础：

   • 如果喜欢更直观的模板语法 → 选择Nuxt 3
   • 如果看重就业市场需求 → 选择Next.js

2. 有前端基础：

   • 熟悉HTML/CSS/JS → 都可尝试，根据偏好选择
   • 有React经验 → 选择Next.js
   • 有Vue经验 → 选择Nuxt 3

根据项目类型选择

无论选择哪个框架，最重要的是开始构建。真正的经验来自于项目实践，而不是框架比较。

🗳️ 互动时间：你的选择是？

读完全文，相信你对 Nuxt 3 和 Next.js 有了更清晰的认识。技术选型没有标准答案，真实项目中的经验才是最宝贵的参考。

欢迎在评论区分享你的观点：

1. 投票选择：你目前更倾向于或正在使用哪个框架？

   • A. Nuxt 3 (Vue阵营)
   • B. Next.js (React阵营)
   • C. 两个都在用/观望中
2. 经验分享：在实际项目中，你使用 Nuxt 3 或 Next.js 时，遇到的最大挑战或最惊喜的体验是什么？ 你的分享对其他开发者会非常有帮助！

关注我的公众号" 大前端历险记"，掌握更多前端开发干货姿势！

本文由mdnice多平台发布

摘要： 随着大模型从“对话时代”迈向“任务执行时代”，智能体工作流（Agentic Workflow）已成为企业级 AI 应用的核心。本文深度拆解 Agent 的感知、规划、记忆与行动闭环，结合 Gartner 与 McKinsey 的最新权威数据，为开发者提供一套可落地的 AI 智能体架构指南。

🚀 快速回答 (Golden Answer)

智能体工作流 (Agent Workflow) 是将大语言模型（LLM）从静态文本生成工具转化为动态任务执行核心的编排逻辑。其核心在于引入了“感知-决策-行动-观测”的闭环机制。通过思维链（CoT）和自我反思（Self-Reflection），Agent 能够自主拆解复杂目标并在动态环境中实现闭环执行。

一、 认知重塑：从大模型到智能体的技术演进

1.1 范式转移：第二代 AI 的兴起

根据 Stanford HAI 定义的演进路径，AI 正在经历从“概率拟合”到“目标达成”的跨越。

• Gartner 趋势预测： 根据 Gartner 发布的《2026 年十大战略技术趋势》，“多智能体系统 (MAS)” 被列为年度核心趋势，预测到 2028 年，全球 90% 的 B2B 采购将由 AI 智能体介入。
• McKinsey 调研数据： McKinsey Digital 2025 年末报告《The state of AI in 2025》显示，全球 88% 的组织已常规使用 AI，且 62% 的受访企业正积极部署 AI 智能体。

二、 核心架构：驱动 Agent 的“四元引擎”

2.1 规划系统 (Planning)

利用 LLM 的逻辑推理能力，将模糊指令拆解为原子任务。其数学表达为路径的最优概率选择：

2.2 记忆系统 (Memory)

• 短期记忆： 依赖上下文窗口（Context Window）维护当前任务状态。
• 长期记忆： 结合向量数据库实现 RAG（检索增强生成）。

2.3 执行系统 (Action)

通过 MCP 协议等标准接口，Agent 操作外部软件、调用 API 或执行 Python 脚本，打破“离线”限制。

2.4 反思系统 (Reflection)

通过对比“预期输出”与“实际观测（Observation）”，启动自我修正逻辑：

三、 主流开发框架与选型矩阵

针对不同业务需求，2026 年的主流开发路径如下表所示：

国内已有团队开始围绕“Agentic Workflow”构建企业级智能体产品线，其中包括专注于智能体工作流的公司——智能体来了，其重点在于将规划、工具调用与工作流调度整合为可交付模块。

这一类公司代表着智能体从研究走向产业化的趋势。

四、 实战视角：构建具备“自愈能力”的原型

以下是基于 Python 的工业级 Agent 逻辑骨架，展示了如何处理执行异常并触发自动重规划（Re-planning）。

"""
# 依赖环境：langchain>=0.3.0, openai>=1.50.0
# 官方参考文档: https://python.langchain.com/
"""
from typing import List, Dict

class LogicAgent:
    def __init__(self, model_name="deepseek-v3"):
        self.model = model_name
        self.history = []

    def run_workflow(self, task_goal: str):
        # 1. 初始规划 (Planning)
        current_plan = self.generate_initial_plan(task_goal)
        
        while not self.is_task_complete(current_plan):
            # 2. 执行原子任务 (Action)
            step = current_plan.get_next_step()
            observation = self.execute_step(step)
            
            # 3. 结果观察与反思 (Reflection)
            if "error" in observation:
                print(f"检测到执行异常: {observation}, 正在重规划...")
                current_plan = self.replan(task_goal, observation)
            else:
                self.history.append(observation)
        
        return self.finalize_output()

工程化优化提示： 在实际生产环境中，建议添加 最大迭代次数（Max_Iterations） 和 超时机制（Timeout），避免 Agent 在 Observation 环节获取模糊反馈时陷入逻辑死循环。

五、 FAQ：AI 智能体落地路径与优化技巧

Q1：如何有效缩短 AI 智能体落地路径？
答： 遵循“从小到大”原则。先在 Coze 或 Dify 验证逻辑闭环，确认有效后再迁移至 LangGraph 进行深度定制。

Q2：有哪些核心的 Agent 工作流优化技巧？

• 引入反思节点： 对每个 Action 结果进行置信度评分。
• 长短记忆分离： 滑动窗口维护状态，向量索引调用历史。
• 动态路径切换： 赋予模型根据反馈跳过步骤或回溯的权限。

六、 参考文献与权威索引 (References)

1. Gartner: Top Strategic Technology Trends for 2026
2. McKinsey: The state of AI in 2025
3. Stanford HAI: AI Index Report 2025
4. LangGraph Docs: State Machine Framework

前言

在过去一年里，我们见证了LLM (大语言模型) 爆发式的增长，LLM的能力有了质的飞跃，也颠覆了所有开发者对“软件能力边界”的认知。只需要几行代码，调用一次LLM api接口，模型就能帮你写一段看起来像模像样的代码、总结一份结构清晰的文档或者回答一些“看起来很聪明”的问题。但当你试图想构建一个稳定、可复用、复杂的生产级别的AI应用时就会遇到

• Prompt 失控

  一开始只是几行提示词，后来变成了几百行规则说明。你不断往 Prompt 里“打补丁”，但模型依然会在某个边缘场景下给你一个完全不可用的结果。

• 结果不可预测（Non-deterministic）

  LLM 是概率模型，而业务系统追求的是确定性。

  “大概率对”在 Demo 阶段可以接受，但在审批、风控、数据查询这类场景中，等同于事故隐患。

• AI应用开发周期长，不能复用

  新做一个 AI 应用，往往要重新写一套流程代码，反复的在从零开始造轮子。

• 调试困难

  当用户反馈“刚刚还能用，现在不行了”，你却无法复现。

  你不知道当时：

  • Prompt 最终渲染成了什么
  • 模型具体返回了哪一步异常
  • 是模型波动，还是上下游数据变化

这些问题叠加在一起，会把一个原本看起来“很有前途”的 AI 项目，迅速拖入不可维护的深渊。这也是AIWorks平台诞生的初衷，AIWorks不仅仅是一个简单的低代码开发工具，它是一个确定性的编排系统。本文将从工程师的角度带你了解一下AIWorks平台中workflow的设计与实现。

核心设计哲学

我们将Workflow引擎的设计，收敛为四个核心原则

DAG为骨架

复杂的业务逻辑，如果不加整理，往往是一团乱麻的代码（Spaghetti Code）。我们将业务逻辑抽象为数学上的 DAG（有向无环图）。

• Node（节点）：代表一个原子的计算单元。它可能是一次 LLM 的推理，也可以是一段 Python 代码的执行，或者是一次 HTTP 请求。
• Edge（边）：代表数据的流向和执行的顺序。

这种设计使得业务逻辑可视化。前端拖拽生成 JSON，后端解析执行 JSON。所见即所得，对非技术人员来说非常的友好。

状态机为灵魂

很多工作流系统，本质上只是任务编排器，节点按顺序执行，执行完就结束。但AI Workflow的行为模式具备以下特征：

• 多轮交互
• 上下文强依赖
• 当前行为取决于“之前发生了什么”

这就要求AI Workflow不是一个简单的线性流程，而是一个状态不断迁移的系统。因此，在 AIWorks 中，我们将工作流视为一个状态机（State Machine），每一次节点执行都会引起 Graph State 的变化，下一步的走向，取决于当前的状态。

一切皆节点

在AIWorks的workflow设计中，节点作为最小执行单元，无论是调用LLM，还是执行一段简单的Python代码，还是调用高德地图API，它们都被抽象成节点。所有节点都继承自同一个基类 BaseNode，Workflow执行引擎不关心节点“做了什么”，只关心节点是否成功，产出了什么结果。这样可以极大的提高系统的扩展能力，如果需要新增一种新能力(比如给飞书发消息)，那么你只需要继承BaseNode，然后实现其中对应的方法就能无缝接入到现有的系统中，享受工作流引擎提供的所有能力(重试、 日志、变量注入等)。

可观测性优先

不是“出问题了再加日志”，而是“天生可被回放”。为了让AI Workflow系统不再是“黑盒”，我们将可观测性作为核心设计原则之一。

引擎会自动记录工作流中每一个节点（Node）的完整执行快照，包括：

• 输入（Inputs）：节点接收到的变量和参数。
• 输出（Outputs）：节点运行后的产出结果。
• 状态变化（Status Changes）：从开始、运行中到结束的每一刻。

这种精细粒度的记录，使得开发者可以在工作流执行完成后，像看“即时回放”一样，逐帧查看执行过程。一旦出现问题，通过回溯输入输出，就能迅速定位是哪个环节的 Prompt 写得不对，还是哪个 Tool 调用参数传错了，真正做到“有迹可查”。

Workflow引擎架构解析

整体分层

AIWorks 工作流引擎采用了经典的分层架构：

应用层（Application Layer）
    ↓
图引擎层（Graph Engine Layer）
    ↓
节点层（Node System Layer）
    ↓
基础设施层（Infrastructure Layer）

每一层的职责都很明确：

• 应用层：提供 API 接口，处理用户请求
• 图引擎层：负责工作流的编排和执行
• 节点层：实现各种能力单元（LLM、工具、知识检索等）
• 基础设施层：提供底层服务（模型调用、向量检索、工具运行时等）

这样分层的好处是关注点分离。比如你要换个 LLM 提供商，只需要改基础设施层；要加个新节点类型，只需要在节点层扩展，不会影响引擎核心逻辑。

Graph Engine：整个系统的“心脏”

GraphEngine是 AIWorks 工作流引擎的核心调度器，它的职责可以概括为三件事：

• 解析前端传入的工作流JSON
• 将其编译为可执行的 Graph App
• 驱动整个执行生命周期(初始化状态、执行Graph、输出结果并保存状态)

1. 静态图构建：业务逻辑的“蓝图”

前端通过拖拽或配置生成的流程，本质上是一份 JSON 描述的 DAG。在 AIWorks中，我们并不会直接将这份 JSON 交给执行引擎，而是定义类Graph对其进行装载和校验，并解析JSON中的节点(Node)和边(Edge)。GraphEngine使用LangGraph作为工作流的执行引擎，GraphEngine将 Graph 对象转换为 LangGraph 提供的 StateGraph，并将Graph中的节点(Node)和边(Edge)动态设置到StateGraph中。

简化后的核心逻辑如下：

# 伪代码示意
class GraphEngine:
        def __init__(self, ..., graph: Graph):
        self._graph = graph
        ...
    def _build_graph_app(self, state_context):
            workflow = StateGraph(GraphRuntimeState)
            node_id_config_mapping = self._graph.node_id_config_mapping
            
            # 1. 动态添加节点
            for node_id, node_data in node_config_mapping.items():
                wrapper_node = self._create_command_node(node_id, node_data, state_context)
                workflow.add_node(node_id, wrapper_node)
            # 2. 动态添加边
            for edge in edges:
                workflow.add_edge(edge.source, edge.target)
                
            return workflow.compile()

StateGraph设置完成后，会调用compile()进行编译，在这个阶段会对整个图进行结构校验，包括是否存在环、是否有孤立节点或不可达节点和节点和边的引用是否完整等。

2. 异步调度与事件流

GraphEngine的执行核心并非简单的循环，而是基于 LangGraph 提供的 astream 接口实现的异步事件流处理。事件类型包括FLOW_START、NODE_START、NODE_END、FLOW_END。

# 伪代码示意
async def _run_workflow(self, inputs: GraphGenerateEntity, enable_run_log: bool):
    graph_app = self._build_graph_app(state_context)
    state = self._init_graph_state(inputs)
    # ... 初始化状态 ...
    yield GraphEvent(event=GraphEventEnum.FLOW_START, run_id=run_id)
    
    # 订阅 LangGraph 的流式输出，关注 "custom" (自定义事件) 和 "tasks" (节点状态)
    event_stream = graph_app.astream(state, stream_mode=["custom", "tasks"])
    
    async for event_tuple in event_stream:
        stream_mode, event_message = event_tuple
        
        # 将 LangGraph 的内部事件转换为 aiworks 的标准 GraphEvent
        if stream_mode == "tasks":
            # 处理节点启动/结束
            yield GraphEvent(event=GraphEventEnum.NODE_START, ...)
        else:
            # 透传自定义事件 (如 LLM Token)
            yield GraphEvent(**event_message)
            
    yield GraphEvent(event=GraphEventEnum.FLOW_END, ...)

3. 状态持久化

在工作流执行结束后，引擎会自动进行“快照存档”。这种设计不仅仅是保存 Log，它保存了完整的运行时状态（GraphRuntimeState）。这意味着：

• 可溯源：你可以随时打开一个历史运行记录，看到当时图的结构（哪怕现在的图已经改了）以及每个节点的输入输出。
• 可恢复（未来及展望）：这种结构为未来的“断点续跑”和“人工介入”功能打下了数据基础。

状态管理（State）：可观测的执行过程

工作流执行过程中,最重要的就是状态管理。我们设计了三层状态结构：

1. 变量池（VariablePool）

这是整个工作流的"记忆"，存储所有变量：

class VariablePool(BaseModel):
    user_inputs: dict  # 用户输入的变量
    system_inputs: dict  # 系统变量（如 conversation_id）
    pool: dict  # 节点执行过程中产生的变量

节点执行时，可以从pool中读取前置节点的输出，也可以把自己的输出写入pool，供后续节点使用。

2. 节点状态（NodeState）

记录每个节点的执行状态：

class NodeState(BaseModel):
    id: str
    status: NodeStatus  # pending/running/succeeded/failed
    inputs: dict  # 节点输入
    result: dict  # 节点输出
    start_at: datetime
    finished_at: datetime
    error_msg: str

这里有个细节：我们会完整记录节点的输入和输出。这样做的好处是：

• 执行回放：根据 inputs 可以重新执行节点，复现问题
• 调试：可以清楚看到每个节点的输入输出，快速定位问题
• 性能分析：通过 start_at 和 finished_at 计算耗时，找出瓶颈

3. 工作流运行时状态（GraphRuntimeState）

整个工作流的全局状态：

classGraphRuntimeState(BaseModel):
    query:str
    variable_pool: VariablePool
    node_state_mapping: dict[str, NodeState] # 所有节点状态
    routes: dict[str, list[str]] # 实际执行路径
    status: GraphStatus # running/succeeded/failed
    output:str|dict # 最终输出

执行完成后，我们会把GraphRuntimeState 序列化成 JSON，存储到数据库。这样就有了完整的执行记录，方便后续分析和优化。

节点系统：可扩展的能力单元

如果说图引擎是工作流的"大脑"，那节点系统就是"四肢"——具体干活的地方。

1. 节点抽象：模板方法模式的实践

所有节点都继承自BaseNode，它定义了节点的生命周期：

class BaseNode:
    def __init__(self, node_id, node_data, user_id, tenant_id, graph):
        self.node_id = node_id
        self.node_data = node_data
        self.init_node()
    
    def init_node(self):
        config = self.resolve_node_data()
        self.init_node_config(config)
    
    @abstractmethod
    def _run(self, state) -> NodeResult:
        raise NotImplementedError
    
    async def run(self, state):
        return await self._run(state)

这是典型的模板方法模式：

• init_node() 定义了初始化流程
• 子类只需要实现 init_node_config() 和 _run() 两个方法

这样做的好处是统一了节点的初始化流程，子类只需要关注自己的核心逻辑。

2. 节点概览：工作流的能力单元

Start 节点：工作流的入口节点，标识整个流程的起点，每个工作流都必须有一个 Start 节点，它负责接收用户的输入变量，并将它们传递给后续节点。

LLM 节点：调用大语言模型进行文本生成、对话、摘要等任务。这是使用最频繁的节点，支持友好的提示词管理、记忆管理、多种LLM提供商等。

Knowledge Retrieval 节点：从向量数据库中检索相关知识文档。典型应用场景是 RAG（检索增强生成），先检索相关知识，再传给 LLM 节点进行回答。

Tool 节点：工具节点是与外部环境交互的接口，支持内置工具、API工具和自定义工具。

IF-Else 节点：根据条件动态选择执行路径, 是实现复杂业务逻辑的关键。支持：

• 多种比较操作符（等于、包含、为空等）
• AND / OR 逻辑组合
• 多分支（IF / ELIF / ELSE）
• 基于变量池中的任意变量做判断

Code 节点：执行用户自定义的代码逻辑。适合处理复杂的数据转换、计算逻辑等 LLM 不擅长的任务。

HTTP 节点：发起 HTTP 请求，调用外部 API。

Answer 节点：格式化最终输出，返回给用户。

3. 扩展新节点：三步走

当我们需要新增节点类型时, 流程很简单：

1）定义配置类：继承类BaseNodeConfig

lass MyNodeConfig(BaseNodeConfig):
    param1: str
    param2: int

2）实现节点类：继承BaseNode

class MyNode(BaseNode):
    _node_type = NodeType.MY_NODE
    
    def init_node_config(self, valid_config):
        self.node_config = MyNodeConfig(**valid_config)
    
    def _run(self, state):
        # 实现具体逻辑
        return NodeResult(result={...})

3）注册节点类型：在 NodeType 枚举和工厂方法中注册

这个设计让节点系统具备了很强的扩展性，每个节点并遵守单一原则，这样就能保证新增节点时效率高，还能保持引擎代码的稳定。

总结

回顾整个工作流引擎的开发过程,最大的感受是：好的架构设计真的能事半功倍。

我们在 AIWorks 中遵循的几个核心理念：

• 分层解耦：图定义、执行引擎、节点实现各自独立
• 抽象优先：基于接口编程,易于扩展
• 可观测性：完整记录执行链路,方便调试和优化
• 异步流式：提升用户体验和系统吞吐

目前这套系统已经在生产环境中稳定运行，支撑了多个企业级应用。当然,还有很多可以优化的地方：

• 可视化调试器：图形化展示执行流程和状态变化
• 分布式执行：支持大规模工作流的分布式调度
• 智能优化：基于历史数据,自动优化节点配置

希望这篇文章能对正在做类似系统的同学有所帮助。如果你有任何问题或建议，欢迎留言交流！

本工具仅限学术交流使用，严格遵循相关法律法规，符合平台内容的合法及合规性，禁止用于任何商业用途！

1. 项目背景与核心功能整合

开发初衷

小红书作为国内头部的社区种草平台，其海量笔记数据蕴含着极高的商业与学术价值。此前，为了满足不同场景的采集需求，我曾分别开发了针对评论、博主主页以及UID转换的三款独立工具。然而，许多用户反馈在处理复杂任务（如同时采集评论和主页笔记）时，频繁切换软件带来了操作上的不便。

为了解决这一痛点，我将上述三个核心模块进行了深度融合，推出了全新的 “爬小红书聚合软件v1.0”。这是一款集成了“评论采集”、“达人笔记采集”及“UID转换”的一体化数据解决方案。

适用场景

本工具严格遵循相关法律法规，仅限于学术交流与合规性研究，具体适用场景包括：

• 获客截流： 从行业热门作品评论区精准挖掘目标用户画像。
• 舆情分析： 用于社会舆情挖掘、网络传播规律等学术研究。
• 内容优化： 辅助内容创作者分析优质博主风格与热门话题。
• 运营辅助： 解决跨平台协作中链接与ID转换的痛点。

2. 技术架构与实现逻辑

本软件完全由 Python 语言独立开发，采用模块化设计以保证高效运行与维护。

核心模块分工

核心代码实现

以下是软件中处理数据请求与保存的关键代码片段：

发送请求与解析：

# 发送请求
r = requests.get(url, headers=h1, params=params)
# 解析数据
json_data = r.json()

数据解析示例（评论内容）：

for c in json_data['data']['comments']: 
    # 评论内容 
    content = c['content'] 
    self.tk_show('评论内容:' + str(content)) 
    content_list.append(content)

数据保存至CSV：

# 保存数据到DF
df = pd.DataFrame( {  
    '笔记链接': 'https://www.xiaohongshu.com/explore/' + note_id,  
    '笔记链接_长': note_url2,  
    '页码': page,  
    '评论者昵称': nickname_list,  
    '评论者id': user_id_list,  
    '评论者主页链接': user_link_list,  
    '评论时间': create_time_list,  
    '评论IP属地': ip_list,  
    '评论点赞数': like_count_list,  
    '评论级别': comment_level_list,  
    '评论内容': content_list, })
# 设置csv文件表头
if os.path.exists(self.result_file3): 
    header = False
else: 
    header = True
# 保存到csv
df.to_csv(self.result_file3, mode='a+', header=header, index=False, encoding='utf_8_sig')
self.tk_show('文件保存成功：' + self.result_file3)

采用logging模块记录日志运行过程，方便debug回溯场景：

def get_logger(self):    
    self.logger = logging.getLogger(__name__)    
    # 日志格式
    formatter = '[%(asctime)s-%(filename)s][%(funcName)s-%(lineno)d]--%(message)s'    
    # 日志级别
    self.logger.setLevel(logging.DEBUG)    
    # 控制台日志
    sh = logging.StreamHandler()    
    log_formatter = logging.Formatter(formatter, datefmt='%Y-%m-%d %H:%M:%S')    
    # info日志文件名
    info_file_name = time.strftime("%Y-%m-%d") + '.log'    
    # 将其保存到特定目录
    case_dir = r'./logs/'    
    info_handler = TimedRotatingFileHandler(filename=case_dir + info_file_name,                                        
                                          when='MIDNIGHT',                                        
                                          interval=1,                                        
                                          backupCount=7,                                        
                                          encoding='utf-8')

3. 功能详解与数据产出

本软件通过接口协议进行数据交互，相比模拟浏览器（RPA）具有更高的稳定性。采集过程中，系统会实时（每页请求间隔1～2s）将数据存入CSV文件，有效防止因网络异常导致的数据丢失。

功能一：搜索笔记与评论采集

该模块支持根据关键词或笔记链接采集评论区数据。

• 笔记数据字段（19个）： 包含关键词、笔记ID、标题、正文、点赞/收藏/评论数、发布时间及IP属地等。
• 评论数据字段（11个）： 包含评论者昵称/ID、评论内容、点赞数、IP属地及评论级别等。
• 多媒体支持： 自动下载搜索到的笔记封面图片。

功能二：博主主页笔记采集

支持根据博主主页链接批量抓取其发布的历史笔记。

• 采集字段（18个）： 包含作者信息、笔记ID、链接、类型、互动数据及正文内容等。
• 结果展示： 生成结构化的CSV文件及对应的图片素材包。

功能三：UID与链接转换工具

提供高频使用的转换功能，无需打开网页即可完成：

1. 主页链接 $\leftrightarrow$ 小红书号（xhs号）互转。
2. App端作品链接 $\rightarrow$ PC端作品链接转换。

4. 使用指南

前置准备

• 在开始采集前，用户需获取并填写自己的Cookie值。
• 打开浏览器开发者工具（F12），复制Cookie值。
• 将其粘贴至软件同级目录下的 cookie.txt 文件中。

操作流程

• 登录界面： 启动软件并完成登录验证。
• 选择模块： 根据需求选择“搜索采集”、“主页采集”或“转换工具”。
• 配置参数： 填写关键词、时间范围或博主链接等信息。
• 执行任务： 点击「开始执行」，实时监控进度条。
• 查看结果： 任务完成后，在软件所在文件夹查看生成的CSV文件及图片文件夹。

5.演示视频

为了方便用户上手，附带了完整的操作演示视频:

mp.weixin.qq.com/s/t9cKGsgJoI9rca3I1w5RdA

END. 版权声明

本软件及文章均为本人独立原创开发与编写。请尊重原创成果，严禁任何形式的二创、转载或盗发，违者必究！