2025年，数字化浪潮迈入“深水区”。企业的核心诉求，已从搭建云原生实验田，转向寻求能承载关键业务、实现价值规模化的坚实平台。这正需要骐骥一跃的突破力，与稳驭核心的掌控力。

.png)

KubeSphere 作为企业级多租户容器平台，正致力于成为这一转型中的可靠伙伴与稳健座驾。我们通过简化管理复杂性、整合业界最佳实践、提供开箱即用的生产级能力，帮助全球客户在多云与异构环境中，驾驭稳定、高效、自主可控的应用管理平面，从而加速创新交付、优化资源成本、保障业务永续。

回首过去一年，我们不仅实现了产品能力的关键一跃，更在与金融、政务、制造、教育等领域客户的并肩实践中，见证了平台价值在核心业务中的平稳落地与驾驭。

产品深耕：夯实企业级基石

2025年，我们通过一系列版本迭代持续打磨产品，最终发布的 v4.2.1 版本标志着 KubeSphere 在“体验卓越与生产就绪”的道路上迈出了坚实一步。 该版本及全年的更新始终围绕解决企业规模化应用的核心挑战展开，致力于为各行业客户提供更稳定、高效的管理体验。

1. 强化异构资源统一纳管

面对混合架构带来的管理复杂度，v4.2.1 版本致力于构建统一、高效的异构算力底座。平台增强了对 GPU/vGPU 等异构计算资源的统一纳管与调度适配，满足从AI推理到图形渲染的多元化算力需求。同时，通过集成智能数据缓存加速能力，显著降低了I/O密集型应用的存储访问延迟。这些能力共同为企业提供了一个可跨云、跨芯的标准化资源池，实现了算力资源的全局统筹与弹性供给。

2. 升级弹性调度体系

为实现极致的资源效率与成本优化，v4.2.1 引入了多维联动的智能弹性调度体系。平台创新性地一站式集成垂直伸缩（VPA）、水平伸缩（HPA）与事件驱动伸缩（KEDA）。VPA根据历史负载自动优化容器资源规格，避免浪费；HPA增强策略允许对扩缩容行为进行独立精细调控；KEDA则能将消息队列等外部事件直接转化为弹性信号，甚至支持副本数缩零以极致降本。

3. 筑牢集群稳定防线

为保障大规模、多集群生产环境的全局稳定，v4.2.1 在治理与可观测层面进行了重磅增强。平台新增节点组（Node Group） 能力，支持将物理节点逻辑分组并与企业空间绑定，完美支撑多租户资源隔离、信创环境混部等复杂场景。在运维层面，提供成员集群可视化在线升级与状态精准同步，极大简化了多集群生命周期管理。

全球实践：深入关键场景

产品的最终价值，在用户应对核心业务挑战时得到最真实的体现。2025年，KubeSphere 的可靠性、灵活性与开放性，在全球多个行业的关键业务场景中赢得了深度信任。

国内实践

• 某头部汽车金融公司：采用 KubeSphere 企业版构建混合云统一平台，在满足金融级强合规与隔离要求的前提下，实现了资源全局弹性调度与一站式运维，使整体运维效率提升超 40%，为创新金融业务的快速上线与稳定运行提供了强大支撑。
• 某直辖市规划和自然资源局：打造“一云多芯”政务容器云平台，无缝纳管异构芯片架构资源，实现跨架构统一调度与标准化流程，有力支撑了智慧城市、空间规划等核心政务系统的数字化升级与高效协同。
• 澳门气象局：选用KubeSphere可信版为其核心气象预报与监测系统构建云原生底座，在满足高安全与合规要求的同时，实现了资源的统一调度与服务的自动化运维，有力保障了气象业务7x24小时不间断稳定运行。

海外拓展

• 欧洲 IT 解决方案商 AMPLUS S.A.：在为希腊某公立大学构建科研平台时，基于 KubeSphere 打造了标准化云原生管理方案。该选择显著降低了长期运维成本、赋予用户自主管理能力，并提升了方案的可复用性与交付效率，助力 Amplus 建立了可快速复用于其他教育及企业客户的产品化服务能力。

生态共建：汇聚行业力量

2025年，KubeSphere 的技术影响力与生态认可度持续提升，GitHub 全球星标数突破 16,000， 这标志着产品价值获得了全球开发者的广泛关注。我们始终秉持协作共赢的理念，致力于与业界伙伴及用户共同构建一个充满活力的技术生态。

• 培育云原生新生力量：我们通过技术合作、联合创新及人才培养等多种形式，与众多行业伙伴及高校建立了深度链接，例如通过“开源之夏”等活动，成功孵化了智能运维助手等创新工具原型，推动了前沿技术的实用化探索。
• 汇聚业界最佳实践：通过灵活的扩展组件架构，我们实现了与 Fluid（数据编排）、OceanBase（分布式数据库）等业界顶尖技术的深度集成。这使用户能够根据自身需求，灵活选用并组合经过生产验证的最佳技术组件，构建坚实可靠的底层架构。
• 推动技术融合与标准实践：我们持续将大规模企业级部署中沉淀的稳定性保障与性能优化经验，贡献至行业生态，并与业界社区紧密协作，共同推动云原生应用管理标准的成熟与落地。

未来图景：平台化敏捷进化

为更敏捷地响应技术演进与多元的业务场景，KubeSphere 将在 2026 年采用全新的“核心底座年度更新，扩展组件季度发布”演进模式。这一模式旨在聚焦核心产品能力，增强关键场景支撑，并以灵活机动的组件化策略应对市场的快速变化，助力企业在稳定可靠的底座上，持续获取前沿价值。

我们的前行路径将围绕以下四大方向深化，致力于让平台更智能、更坚韧、更开放：

1. 全局治理与高可用保障

为支撑企业全球业务的连续性，我们将强化多集群联邦治理能力。重点是实现管理面的多活与容灾，通过集成 Karmada 等领先方案，确保控制平面自身具备跨可用区的高可用与故障恢复能力，为大规模、跨地域的集群部署提供坚实、可靠的管理基石。

2. 智能运维与成本洞察

我们将推动运维从“可视化”向“智能化”与“精细化”演进。全新设计的全局总览大屏与集中式告警中心，将为管理员与租户提供一目了然的运行状态与事件管理。在此基础上，计划引入的 AI 运维助手，将能通过对告警、日志及性能数据的分析，提供根因定位与修复建议。同时，我们将深化成本洞察能力，通过分析资源消耗与计费数据，提供可视化的成本分摊报表与优化建议，让云原生资源的使用成本清晰可见、可控可优，真正实现降本增效。

3. 生态集成与标准实践

我们将通过深化与云原生顶尖技术的集成，提供开箱即用的生产级方案，并推动实践标准化。具体而言：

• 集成 Cilium：将提供基于 eBPF 的 Cilium 容器网络方案，它不仅带来更高的网络性能与可观测性，其强大的安全策略能力（如网络策略、服务网格）能更好地满足企业安全合规需求。
• 拥抱 Gateway API：随着社区广泛采用的 Ingress NGINX 逐步进入维护尾声，我们将提供基于下一代标准 Gateway API 的流量管理方案，帮助用户从现有 Ingress 平滑演进至功能更强大、标准更统一的治理体系，有效规避技术断代风险，从容面向未来架构。

这些集成旨在将社区最佳实践产品化，推动企业采用行业公认的先进标准，降低技术选型与落地复杂度。

4. 核心PaaS能力延伸

为简化企业关键中间件的云原生部署与管理，我们将通过扩展组件，完善对基于容器的数据库、消息队列等中间件的全生命周期管理体验，提供部署、监控、备份等一站式能力，助力企业关键应用平滑、稳定地运行在统一的容器平台之上。

结语

2025年的每一次“一跃”，都源于客户、伙伴与社区成员的信任共创，铸就了台阶。展望2026，KubeSphere 已备好更稳健的底座与更敏捷的生态，诚邀您一同稳驭核心，共赴智能、韧性的数字化未来。

骐骥已备，征程万里。KubeSphere 邀您共驭数字化未来。

作者：枫清实验室团队

1.DeepSeek 带来的一些思考

DeepSeek 的技术突破，并不仅体现在模型指标或参数规模上，而在于其清晰地展示了一种趋势：模型能力的跃迁，正在从“更大的预训练”转向中期+后训练阶段对“知识、行为与推理模式”的系统性对齐。这些变化，对工业界尤为重要。相比通用模型评测，企业场景往往具有以下特征：

任务分布高度集中，但规则与边界极其复杂，SOP与隐性经验并存；错误代价远高于“泛化能力不足”，模型“答错了还看起来很确定”往往比“不回答”更危险；模型的主要风险并非知识缺失，而是在规则边界与异常组合条件下，沿着看似合理但不可控的推理路径持续放大错误。

这些特征决定了企业对微调范式的需求，必然超越技术选型本身。因此，对大多数企业而言，真正的关注点并不在于"是否要用蒸馏或 SFT"，而在于如何用一条工程上可控、可复用、可演进的路径，对齐模型的真实业务能力？
在这一视角下，模型训练不再是一次性的参数优化问题，而是一个由数据→ 结构 → 行为逐层约束、逐步收敛的系统工程。

2.工业场景下的逐层约束

在化工、单证、电磁频谱、跨境报关等客户的高专业度场景中，这些约束具体表现为：

• 数据约束
  领域知识天然以结构化形式存在，但模型是参数化的。通用大模型并不天然具备对这些结构的稳定建模能力，而领域知识通常以如下形式存在：

Plain Text
(实体 A, 关系 R, 实体 B) + 条件/规则 C → 结论 D

例如：

1. 高分子聚合物A 在温度 T、压力 P 下 → 反应路径 X
2. 报关品类HSCODE → 对应监管规则集合
3. 频谱频段f → 允许/禁止的使用方式

知识与行为约束在化工与电磁频谱等高专业度场景中，规则复杂、条件多维，模型“只学语言模式”远不足以支撑安全可靠的推理。需要采用结构化知识注入策略，将关键知识显式内化到模型参数中，实现多条件、多约束推理的稳定性电磁频谱。

Plain Text
Ltotal = 语言建模损失 LLM(x,y) + 知识一致性损失 λLKG(y,K)

• 推理与策略约束
  工业场景中，模型推理阶段所面对的输入往往更加嘈杂、不完整且高度偏向边界情况，当面临一些多约束推理时，推理轨迹容易产生漂移。例如，海关出口货物报关单中商品编码“4819100000” 字段提取0数量的遗漏，导致整单提取的失败。商品规格型号"切割冲孔过的"中核心语义的一致性问题导致进出口优惠的错误等等。同样边缘规则触发异常操作判断，例如单证业务中印章和信息重叠部分的提取错误也容易形成上游业务的级联崩塌。

Plain Text
Lon-policy = 分布对齐 KL(Pθ||Pteacher) + 约束惩罚 β[违反约束 c]

在此约束下，我们开始探索，在数据受限条件下的高质量数据集构建，并采用高效微调的方式注入领域知识，将复杂业务规则内化为模型行为，同时利用策略蒸馏建立可控的错误边界。

3.高质量数据集构建

数据结构化

在分子科学、化学与材料等高专业领域中，模型能力的瓶颈并不主要来自通用语义理解，而来自：专业概念密集，论证链条长，方法与条件强依赖上下文，表达高度依赖论文结构（章节、段落、实验设置）。将分散在学术PDF 中的隐性知识结构，转化为可用于模型训练与评估的高质量问答样本，并显式保留证据上下文与质量度量信息。

整个增强流程遵循两个基本原则：第一，先结构化，再生成。只有将原始论文从排版文档转化为段落级、章节级的可计算结构，LLM 生成的问题与答案才具有稳定语义边界。第二，生成必须伴随质量评估与自动筛选。在高风险专业领域，不能接受“看起来合理但事实上不严谨”的样本，数据构建过程本身必须引入自动评估闭环。从教材、多源学术文献出发，经过文档解析、结构重建、问题生成、质量评估、相似度校验与排序筛选，最终构建带有上下文与质量指标的高质量问答数据集。

应用场景
本数据集结构化的构建流程应用于客户的材料研发人员内部检索与设计辅助系统，结构化后的问答数据语料作为领域模型SFT和 RAG 的检索知识单元，例如典型场景：

• 逆合成信息查询
• 产物预测
• 反应条件查询
• 物质信息和化工材料专业查询等

数据即“隐性规则”的显式化载体

大量企业知识并不存在于文档中，而是：

• SOP 的例外条款
• 老员工的经验判断
• 审批中的“潜规则”

示例:海关申报中的"潜规则"

老员工经验:"如果货值低于申报阈值但重量异常大,需要人工复核"

形式化为: 

数据构建策略:

• 正样本生成:在约束边界内随机采样；
• 负样本生成:故意违反某个约束,并标注错误类型；
• 对比对生成:(X,Y正确,Y错误,差异说明)。

数据图谱化

把知识最小单元，从句子级，降到关系级。这是做结构化控制的前提。把训练样本变成：「问题+ 结构约束上下文 + 多跳结构视角」。

首先，对原始问答数据进行联合语义解析，将隐含在自然语言中的领域知识抽取为实体—关系—实体 的可计算结构。

通过关系归一化（relation canonicalization），将高噪声、长尾的细粒度关系映射至有限的核心关系集合，并显式构建正反向关系，以提升结构连通性与推理可达性。
在关系抽取完成后，将三元组组织为有向多关系图结构，允许实体间的多语义连接，以保留领域知识的结构复杂性。

针对具体问答样本，以文本中出现的实体为条件，进行受控的多跳子图扩展，构建与当前任务最相关的局部知识视角。通过显式限制扩展深度与节点规模，在覆盖潜在推理路径的同时抑制结构噪声。

通过上述流程，我们将原始问答数据中的隐性领域知识，逐步转化为可计算、可裁剪、可内化的结构化表示，并将其系统性地引入模型训练过程，从而在不进行全参数更新的前提下，显著增强模型对领域逻辑与推理结构的稳定建模能力。

 4.知识注入

图谱结构化

注入使用Adapter 结构，避免破坏基础模型参数，将实体与关系嵌入注入注意力或 FFN 层，其本质不是“让模型记住更多事实”，而是：在参数层面引导模型形成稳定的结构化推理模式。

在大语言模型的多层Transformer 结构中插入轻量级图谱适配模块；图谱适配采用“降维—非线性变换—升维”的典型结构，参数规模远小于模型主体；将知识结构嵌入作为适配的输入或调制信号，与语言模型的隐状态进行融合；通过残差连接方式，确保原模型语言能力不被破坏。在训练阶段：冻结大语言模型的原始参数；仅更新 适配模块参数及知识结构编码模块参数；通过端到端训练实现知识表示与语言表示的协同对齐。

应用场景
本方案应用于电磁频管业务，面向无线电管理与电磁空间治理场景，服务对象包括无线电管理机构、频谱规划部门及设备备案与用频审批单位，主要用于提升频谱法规理解、用频合规判断与复杂业务推理的自动化水平。

Lora 微调领域知识特征表达

与通用对话模型中的LoRA（W′=W+ΔW,ΔW=BA） 主要用于指令风格对齐不同，在材料化学领域，LoRA 承担的是：结构与规则敏感型能力的参数载体角色。具体体现在： 

• 学习SMILES 语法中的长距离依赖模式（环闭合、支链嵌套、立体标注等）；
• 学习反应物与产物之间的原子重排与结构映射规律；
• 学习反应条件、催化剂与产物分布之间的隐含关联；
• 学习逆合成中常见结构断裂模式与合成子映射方式。

这些特征体现在损失函数的设计，损失函数计算采用了双损失机制：计算全局损失（所有token）以及针对仅化学关键token（如SMILES、分子式）的核心损失。通过差异化的损失计算策略,实现了"通用能力保持"与"领域知识强化"的有机平衡:

全局损失在此不再赘述，核心损失如图所示：

核心token 包括:

• SMILES 字符串: 如 C1CCCCC1 (环己烷)
• 分子式: 如 C6H12 
• IUPAC 命名: 如 "cyclohexane"
• 反应条件: 如 "催化剂: Pd/C", "温度: 120°C"
• 数值约束: 如 "[120-180°C]", "[0.5-2.0 MPa]"

核心loss可以强制模型重点学习化学结构的精确表达,提升在分子生成、反应预测等核心任务上的性能，Core Loss 会放大 SMILES 生成错误的惩罚，即使整体语言流畅，SMILES 错误会导致 Core Loss 激增，引导模型优先学习化学结构的精确表达。

应用场景
通过在科研智能体平台中集成领域模型，为上游业务提供统一的专业能力底座，从而增强智能化学检索、合成路径设计、反应条件优化等核心应用的底层推理引擎，同时支撑AI4S 智能体平台中的任务规划与工具调用，实现多工具协同下的自动化科研流程编排，提升整体科研效率与决策可靠性。

策略蒸馏

在单证识别场景中，主要错误并不集中在“是否识别到文本”，而集中在： 

• 数字位数错误（多一位/ 少一位）；
• 连续数字的重复与幻觉；
• 字段边界混乱导致的拼接错误；
• 对齐与排版诱导导致的空格、换行、列对齐偏差。

这些错误具有一个非常明显的特征：错误高度依赖学生模型自身当前生成分布。
我们采用on-policy 蒸馏范式：

• 由学生模型在当前参数状态下生成推理轨迹；
• 对其生成过程进行规则检测与结构校验；
• 由教师模型或规则系统对其行为进行反馈。

单证识别的本质不是“条件文本生成”，而是视觉条件下的序列对齐与字符选择问题。
在此场景下，on-policy 蒸馏在该任务中具有两个直接优势：
第一，能直接纠正学生常犯路径上的分布偏差。

• 在数字序列处，学生更容易进入“重复概率高”的状态；
• 在相邻字段边界，学生更容易错误拼接。

教师在这些“学生最容易出错的位置”上提供分布监督，远比在 GT 轨迹上模仿有效。
第二，天然抑制曝光偏差（exposure bias）。
学生不再只在教师路径上被训练，而是在自己的生成分布上被纠正。

应用场景
本方案面向高准确率票据与证照场景，在小数据规模下，通过大模型蒸馏与轻量微调，实现了收据类复杂文本的高精度识别，数字与关键字段的稳定输出，轻量模型可部署能力，同时兼顾跨文档类型的泛化能力。

 5.总结

本文章围绕工业高专业度场景下大模型的落地优化展开，以DeepSeek 带来的行业趋势思考为切入点，针对企业场景任务集中、错误代价高、推理易漂移的核心痛点，提出了数据→结构→行为逐层约束的大模型调优体系，并从高质量数据集构建、领域知识注入、策略蒸馏三大核心环节，阐述了可工程化、可复用的落地技术路径，核心是让大模型在数据受限的工业场景中，实现知识的精准内化、推理的稳定可控。上述数据约束、结构建模、知识注入与策略蒸馏方法，在客户的一部分场景中形成实践，例如报关审单、频谱活动知识问答、材料研发辅助、单证结构化识别等多个系统中持续迭代。

智能制造行业的研发协作，重点在于能不能把复杂链路管住：需求如何收敛、研发如何协同、测试如何闭环、交付如何可追溯、跨团队如何对齐、IPD/ASPICE等体系如何落地。当产品线越来越多、软硬件协同越来越频繁、跨地域研发成为常态时，一套能承载复杂研发节奏的研发管理平台，就会从“效率工具”变成“研发体系的数字底座”。

一、智能制造行业的研发痛点

1）项目越来越多，信息越来越散，管理靠“人肉对齐”

多项目并行、跨部门协同、跨地域交付，最典型的问题是：

• 进度、风险、资源分布无法实时汇总
• 信息分散在群聊/邮件/表格/个人文档里
• 关键决策缺乏数据支撑，复盘也缺少事实链路

2）需求—研发—测试—交付链路断裂，质量与交付不可控

智能制造企业通常兼顾硬件、软件、嵌入式、算法、平台等多团队协作，如果链路不统一，常见现象是：

• 需求变更难追踪，交付范围经常漂移
• 缺陷无法闭环回溯，测试用例与版本发布脱节
• 交付质量依赖“项目经理盯人”，难规模化复制

3）流程体系想落地（IPD/ASPICE/功能安全），但缺少“可执行的数字化载体”

很多企业在推 IPD、ASPICE、功能安全、矩阵式协作时，会遇到：

• 流程写在制度里，执行落在个人习惯里
• 指标口径不统一，过程数据难沉淀
• 跨团队协作缺少统一的协作语言与工作项标准

4）权限与数据治理要求更高，既要共享协同，又要边界清晰

尤其在供应链协作、跨部门共享与研发资料沉淀场景下：

• 哪些信息该共享？哪些必须隔离？
• 权限边界是否能按组织/角色/项目分层治理？
• 项目过程资产如何沉淀为可复用知识？

二、针对这些痛点，ONES 的解题思路是什么？

下面的能力点不是简单的功能罗列，而是把智能制造企业最常见的管理诉求，归纳为几类平台能力。

1）把研发全过程放到一套统一协作体系里，让信息可视、可追溯

在智能制造企业里，平台要能把工单、需求、任务、迭代、缺陷、测试等协作对象串起来，形成统一链路：

• 项目全生命周期可视化跟踪
• 端到端追溯（从需求到上线/交付）
• 用数据支撑管理决策

2）把“流程标准化”变成可执行的线上机制，支撑多产品线、多团队协作

平台不仅要能支持标准化，还要能在不同团队/不同项目下灵活配置：

• 支持按团队/项目配置更贴合自身的协作模式
• 兼顾流程规范与灵活性
• 多项目并行时，依然能保持信息透明与对齐效率

3）支撑 IPD/ASPICE 等体系落地：把方法论固化成流程与数据

• 对推体系的企业来说，平台要能承载：
• IPD 研发管理体系的数字化落地
• ASPICE 认证相关过程要求的执行与追溯
• 研发流程的数字化与知识化沉淀

4）支撑跨部门、跨地域协同与权限治理：共享协作与边界管理并重

平台需要既能促进共享，又能避免数据泄露和越权访问：

• 多层权限保障信息安全
• 知识库与项目协作打通，同时保持权限边界可控
• 跨研发中心协作效率提升，降低交接成本

三、来自 ONES 智能制造行业标杆客户证言

以下内容来自 ONES 智能制造相关行业客户证言。若你正在评估研发管理平台，可将这些原话作为参考样本，对照自身的研发链路复杂度（需求—研发—测试—交付）、跨团队协作与过程追溯要求进行判断。

诺瓦星云：全球最大的 LED 显示解决方案服务商

研发负责人：ONES 上线后，通过数据治理、流程梳理与系统配置培训，高效助力我司落地软件研发项目标准化建设，各产品线之间信息共享互通，提升了 IT 管理和研发效率。同时推动 IPD 项目在 ONES 落地，破解数据分散难题，降低管理难度。ONES Wiki 打通项目管理与文档管理的数据壁垒，解决了数据安全和权限管控问题。

光格科技：产品服务于国家电网、南方电网、华能集团、国家电投等

研发管理部副总监李老师：公司使用 ONES 系统已三年多了，ONES 对我们团队的研发管理效率起到很大提升，尤其是 ONES Wiki 知识库功能丰富，有效解决了部门间的沟通协作难题，显著提升了协作效率。

埃斯顿：连续七年稳居中国工业机器人国产品牌出货量首位

我司通过 ONES 实现项目在线化统一管理，串联起对待导入需求的收集及响应，有效管控研发参与的不同类型的项目，精细化到具体不同工作项的规范管理，整体提升项目的在线规范化管理、降低沟通成本、提升团队效能。

良信股份：27年智慧低压电气解决方案专家

软件开发部：感谢 ONES 实施团队在过去两年中给予我们的专业支持。你们不仅协助我们高效配置了需求、任务与缺陷管理流程，还将测试场景和用例系统纳入统一管理，使项目全链路清晰可控。每当遇到问题，团队总能快速响应、专业解决，帮助我们切实提升了研发协同效率与交付质量。诚挚感谢你们的用心付出!

卡莱特：领先的视频图像领域综合化解决方案服务商

项目管理部负责人：在引入 ONES 项目管理系统之后，我们实现项目全流程统一管理，并且可以根据不同团队和项目的实际情况进行灵活配置。通过属性、工作流和视图的搭配，项目组能打造更贴合自身的协作模式，提升信息透明度，沟通对齐的成本也随之降低。多项目并行时，ONES 能兼顾流程规范性和灵活性，高效提升项目管理效率。

凌云光：机器视觉与光纤器件行业领导者

通过 ONES 项目管理平台，我们实现了对复杂项目全生命周期的可视化跟踪与精准管控，全局进度一目了然，跨部门协同效率显著提升，它已成为我们保障项目如期上线不可或缺的“项目管理引擎”！

瑞纳智能：智慧供热行业第一家上市公司

瑞纳智能正处于技术升级与业务拓展的关键阶段，现阶段以研发创新为核心，依托 ONES 研发管理系统，实现了跨业务线的研发项目全生命周期高效管控，显著提升技术成果转化效率，加速智能化产业布局。

科思科技：国内领先的电子信息装备供应商

深圳科思科技依托 ONES 构建符合 IPD 核心理念的研发项目管理平台，实现研发流程数字化与知识化升级，系统性提升产品开发效率、质量与资源利用率，打造国际化端到端集成产品开发能力。

中盾安民：国内最早研发生产安检产品的单位

通过 ONES，我司实现了项目信息的可视化、流程化，提高了管理透明度和规范性，便于及时发现项目风险和问题，提升了团队协作效率，降低了沟通成本，为进一步精细化管理奠定了良好基础。

鸿湖万联：软通动力旗下控股公司

研发负责人：ONES 帮助我们将项目不同团队的工作流全面打通，实现了从需求到上线的端到端可视化追踪，通过多种图表形态，实时呈现项目表现，保障了软件研发过程的完整性、一致性和可追溯性，提高了研发效率。

基于视觉的科学基础模型在推动科学发现与创新方面具有巨大潜力，主要源于其能够聚合多样化来源的图像数据（例如不同的物理观测场景），并利用 Transformer 架构学习时空相关性。然而，图像的 token 化与聚合过程计算开销巨大，而现有的分布式方法如张量并行（TP）、序列并行（SP）或数据并行（DP），尚未充分解决这一挑战。

在此背景下，来自美国能源部橡树岭国家实验室的研究人员提出了一种面向基础模型的分布式跨通道分层聚合方法（Distributed Cross-Channel Hierarchical Aggregation, D-CHAG）。该方法对 token 化过程进行分布式处理，并采用分层策略进行通道聚合，从而使极大规模模型能够在多通道数据集上运行。研究人员在高光谱成像与天气预测任务上对 D-CHAG 进行了评估，将该方法与张量并行和模型分片相结合后，在 Frontier 超级计算机上最多可将内存占用降低 75%，并在最多 1,024 块 AMD GPU 上实现持续吞吐量提升超过 2 倍。

相关研究成果以「Distributed Cross-Channel Hierarchical Aggregation for Foundation Models」为题，已发表于 SC25。

研究亮点：

• D-CHAG 解决了多通道基础模型训练中的内存瓶颈和计算效率问题
• 与仅使用 TP 相比，D-CHAG 可实现最高 70% 的内存占用降低，从而支持更高效的大规模模型训练
• 在天气预测与高光谱植物图像掩码预测两种科学工作负载上验证了 D-CHAG 的性能

论文地址：\
https://dl.acm.org/doi/10.1145/3712285.3759870\
关注公众号，后台回复「跨通道」获取完整 PDF

使用两类典型的多通道数据集

本研究使用了两类典型的多通道数据集来验证 D-CHAG 方法的有效性：植物高光谱图像（Hyperspectral Images）和气象 ERA5 数据集。

其中，用于自监督掩码预测的植物高光谱图像数据由 Oak Ridge National Laboratory（ORNL）高级植物表型实验室（APPL） 收集。数据集包含 494 张杨树（Poplar）高光谱图像，每张图像包含 500 个光谱通道，覆盖波长从 400nm 到 900nm。

此数据集主要用于生物质研究，是植物表型分析和生物能源研究的重要资源。这些图像用于掩码自监督训练，即将图像切片作为 token 进行 mask，模型的任务是预测缺失的内容，从而学习图像的潜在数据分布。值得注意的是，该数据集未使用任何预训练权重，完全基于自监督学习进行训练，这也凸显了 D-CHAG 在高通道自监督任务中的适用性。

此外，在气象预测实验中，研究团队使用了 ERA5 高分辨率再分析数据集。研究选择了 5 个大气层变量（位势高度、温度、风速 u 分量、风速 v 分量、比湿度）和 3 个地表层变量（2 米温度、10 米 u 分量风速、10 米 v 分量风速），覆盖超过 10 个压力层，总共生成 80 个输入通道。为了适配模型训练，原始分辨率为 0.25° 的数据（770 × 1440）被重网格化为 5.625°（32 × 64），采用 xESMF 工具包 和双线性插值算法完成。

模型任务是进行未来时间步的气象变量预测，例如 500 hPa 位势高度（Z500）、850 hPa 温度（T850）、10 米 u 分量风速（U10），从而验证 D-CHAG 方法在时间序列预测任务上的性能。

D-CHAG ：将层级聚合与分布式 Token 化结合

简单而言，D-CHAG 方法来自两种独立方法的融合，分别是：

分布式 token 化方法

在前向传播过程中，每个 TP rank 仅对输入通道的子集进行 token 化。在进行通道聚合步骤之前，需要执行一次 AllGather 操作，以便在所有通道之间实现跨通道注意力（cross-attention）。理论上，该方法能够降低每块 GPU 的 token 化计算开销。

层级跨通道聚合

这种方法的主要优势在于每个跨通道注意力层的内存占用减少，因为每层处理的通道数量更少。然而，增加层数会导致整体模型规模增大、内存使用增加。对于通道数量庞大的数据集而言，这种权衡更为有利，因为标准跨通道注意力的二次内存开销更高。

这两种方法虽然各有优势，但也存在一些不足，比如分布式 token 化方法在 TP rank 之间存在较高的通信开销，并未解决通道维度大内存占用的问题；而层级跨通道聚合方法会增加每块 GPU 上的模型参数数量。D-CHAG 方法通过分布式方式将两种方法结合起来，整体架构如下图所示：

D-CHAG 方法在基础架构上的示意图

具体而言，每个 TP rank 对总通道子集中的二维图像进行 token 化。由于每块 GPU 仅持有全部通道的一部分，在这些通道上本地执行通道聚合——该模块称为部分通道聚合模块（partial-channel aggregation module）。在每个 TP rank 内完成通道聚合后，收集输出并使用跨通道注意力进行最终聚合。前向传播过程中仅需执行一次 AllGather 操作；在反向传播时，只收集每块 GPU 的相关梯度，从而避免额外通信。

D-CHAG 方法能够充分利用分布式 token 化和层级通道聚合的优势，同时缓解它们的不足。通过将层级通道聚合分布到 TP rank 上，研究人员将 AllGather 通信减少为每个 TP rank 仅需处理单个通道，在反向传播过程中无需任何通信。此外，通过增加模型深度保留了每层聚合处理通道数量减少的优势，同时通过部分通道聚合模块将额外模型参数分布到各 TP rank 上。

研究对比了两种实现策略：

• D-CHAG-L（Linear Layer）：层级聚合模块使用线性层，内存占用低，适合通道数较多的情况。
• D-CHAG-C（Cross-Attention Layer）：使用交叉注意力层，计算成本较高，但在超大模型或极高通道数时性能提升显著。

成果：D-CHAG支持高通道数数据集上更大模型的训练

在构建 D-CHAG 后，研究人员对模型性能进行了验证，然后进一步评估了其在高光谱成像与天气预测任务上的表现：

模型性能分析

下图展示了 D-CHAG 在不同部分通道聚合模块配置下的性能表现：

图中展示了针对 1.7B 参数模型，在不同部分通道聚合模块配置下，每块 GPU 相对于仅使用 TP 基线的性能提升

• Tree0 表示部分聚合模块中仅有一层聚合，Tree2 表示两层，依此类推；
• 后缀 -C 和 -L 表示所用层的类型：-C 中所有层为 cross-attention，-L 中所有层为 linear

结果显示：

对于 512 通道数据，使用单层 cross-attention 层的性能略低于基线，但对 1024 通道数据可提升约 60%。

随着层次结构加深，即便是 512 通道数据，也能获得明显性能提升，而 1024 通道数据的性能保持相对稳定。

使用 linear 层时，即使层次结构较浅，也能在 512 和 1024 通道图像上获得性能提升。实际上，最佳性能出现在 D-CHAG-L-Tree0，即仅包含一层通道聚合层。增加聚合层会增加模型参数，引入额外内存开销。虽然对于 512 通道情况，增加层数似乎有益，但对于两种通道规模，仅使用一层 linear 层的性能优于更深的配置。

D-CHAG-C-Tree0 在两块 GPU 时对性能略有负面影响，但扩展至 8 块 GPU 时可获得 60% 提升。

植物高光谱图像的自监督掩码预测

下图比较了基线方法与 D-CHAG 方法在高光谱植物图像掩码自编码器应用中的训练损失，结果显示：在训练过程中，单 GPU 实现与 D-CHAG 方法（在两块 GPU 上运行）的训练损失表现高度一致。

基线方法与 D-CHAG 方法在高光谱植物图像掩码自编码器应用中的训练损失

橡树岭国家实验室分子与细胞成像组的高级研究员拉里·约克表示，D-CHAG 可以帮助植物科学家快速完成诸如直接从图像中测量植物光合作用活性等任务，从而取代费时费力的手动测量。

天气预测

研究人员在 ERA5 数据集上进行 30 天气象预测实验，下图比较了基线方法与 D-CHAG 方法在天气预测应用中的训练损失及三个测试变量的 RMSE：

基线方法与 D-CHAG 方法在天气预测应用中的训练损失及三个测试变量的 RMSE

下表则展示了模型在 7、14 和 30 天预测任务上的最终对比，包括 RMSE、MSE 以及 Pearson 相关系数（即 wACC）

D-CHAG 方法相较于单 GPU 训练在 7、14 和 30 天预测任务中的 MSE、RMSE 及 wACC 的百分比变化（% Δ）

结合图和表总体来看，训练损失与基线模型高度一致，各项指标的偏差极小。

随模型规模扩展的性能

下图显示了 3 种模型规模在需要使用 TP 的通道配置下，D-CHAG 方法相较于仅使用 TP 的性能提升：

D-CHAG 方法结合 TP 的情况下，相较于仅使用 TP 时，7B、15B 和 26B 参数模型每个 GPU 的性能提升情况

结果显示，对于 7B 参数模型，使用部分通道聚合模块中的线性层（linear layers）可获得 30% 至 70% 的性能提升，而使用交叉注意力层（cross-attention layers）可获得 10% 至 60% 的提升；对于 15B 参数模型，性能提升超过 20% 至 50%；而 26B 参数模型的性能提升在 10% 至 30% 之间。

此外，在固定模型规模下，随着通道数增加，性能提升更明显，这是因为在给定架构下，增加通道数不会增加 transformer block 的计算量，但会增加 tokenization 和 channel-aggregation 模块的工作量。

另一方面，仅使用 TP 无法训练 26B 参数、256 通道图像，但使用 D-CHAG 方法时，可以训练 26B 参数、512 通道的模型，仅使用不到 80% 的可用内存——这表明该方法能够支持高通道数数据集上更大模型的训练。

ViT：视觉 AI 从感知模型走向通用视觉基础模型

过去十年，计算机视觉模型主要围绕「单任务优化」展开——分类、检测、分割、重建各自独立发展。然而，随着 Transformer 架构在自然语言领域催生出 GPT、BERT 等基础模型（Foundation Models），视觉领域也正在经历类似的范式转移：从任务特化模型走向通用视觉基础模型。在这一趋势下，Vision Transformer（ViT）被视为视觉基础模型的关键技术基石。

Vision Transformer（ViT）首次将 Transformer 架构完整引入计算机视觉任务，其核心思想是：将图像视为一系列 patch token 序列，用自注意力机制替代卷积神经网络的局部感受野建模。具体而言，ViT 将输入图像划分为固定大小的 patch，并将每个 patch 映射为 embedding token，然后通过 Transformer Encoder 建模 patch 之间的全局关系。

与传统 CNN 相比，ViT 对科学数据尤其具有优势：适合高维多通道数据（如遥感、医学影像、光谱数据），可处理非欧几里得空间结构（如气候格点、物理场），适用于跨通道建模（不同物理变量之间的耦合关系），这也正是 D-CHAG 论文所关注的核心问题。

除了上文研究中提及的场景，ViT 正在更多场景发挥核心价值。2025 年 3 月，北京大学国际医院皮肤科主任医师韩钢文携其团队开发出一种名为 AcneDGNet 的深度学习算法，这是一种融合视觉 Transformer 与卷积神经网络，能获取更高效的分层特征表，让分级更精准。经前瞻性评估表明，AcneDGNet 的深度学习算法不仅比初级皮肤科医生更准确，而且与高级皮肤科医生的准确性相当，能够在不同的医疗保健场景中同时准确地完成痤疮病变检测并判断严重程度，有效帮助皮肤科医生和患者在在线问诊和线下就医场景中诊断和管理痤疮。

论文标题：

Evaluation of an acne lesion detection and severity grading model for Chinese population in online and offline healthcare scenarios\
论文地址：

https://www.nature.com/articles/s41598-024-84670-z

从产业视角看，Vision Transformer 标志着视觉 AI 从感知模型走向通用视觉基础模型的关键拐点。其统一的 Transformer 架构为跨模态融合、规模化扩展与系统级优化提供了通用底座，使视觉模型成为 AI for Science 的核心基础设施。未来，围绕 ViT 的并行化、内存优化与多通道建模能力，将成为决定视觉基础模型产业落地速度与规模的关键竞争点。

参考文献：
\
1.https://phys.org/news/2026-01-empowering-ai-foundation.html
\
2.https://dl.acm.org/doi/10.1145/3712285.3759870
\
3.https://mp.weixin.qq.com/s/JvKQPbBQFhofqlVX4jLgSA

少年呀，当你遇到这样的情况：API 慢得像蜗牛，P95 延迟超高，服务器在凌晨 3 点因为流量突发而崩溃，你是选择花三个月用 Rust 重写所有东西，还是选择看着用户流失呢。

或者，你可以像我一样，用一种作弊的方式，把 Bun 的极致速度嫁接到 Node.js 的庞大生态上。

别笑，我是认真的。我就能在不重写 5 年陈旧业务逻辑的前提下，把一个臃肿的后端接口压进 10ms 以内的。

边缘侧使用 Bun，通过 IPC 唤醒 Node 进程池

众所周知，Node 处理 HTTP 请求的开销太大了，但我的业务逻辑里全是依赖 crypto 和老旧 SDK 的代码，根本没法移植到 Bun。

所以我的解决办法是前店后厂。

我用 Bun 搭建了一个极薄的 HTTP 层，专门负责路由、参数校验和挡掉无效请求。只有真正需要那个老旧业务逻辑时，我才通过 IPC（进程间通信）把任务扔给后台常驻的 Node 进程。

千万别在请求来的时候才 spawn 一个 Node 进程，那样比单用 Node 还慢。你要做的是预先启动一组 Node Worker，要先预热才行。。

Bun 端（前台）：

// bun-gateway.ts
const textDecoder = new TextDecoder();
const textEncoder = new TextEncoder();

// 启动一个常驻的 Node 进程，而不是每次请求都启动
const nodeWorker = Bun.spawn(["node", "heavy-lifter.js"], {
  stdin: "pipe",
  stdout: "pipe",
});

// 这是一个简单的读写封装，把复杂的脏活扔过去
async function askNode(payload: any) {
  const msg = JSON.stringify(payload) + "\n";
  nodeWorker.stdin.write(textEncoder.encode(msg));
  
  // 这里简化了读取逻辑，生产环境记得处理粘包
  const reader = nodeWorker.stdout.getReader();
  const { value } = await reader.read(); 
  return JSON.parse(textDecoder.decode(value));
}

Bun.serve({
  port: 3000,
  async fetch(req) {
    if (req.url.endsWith("/fast")) return new Response("Bun is fast!");
    
    // 只有这种重活才找 Node
    if (req.url.endsWith("/heavy")) {
      const data = await req.json();
      const result = await askNode(data);
      return Response.json(result);
    }
    return new Response("404", { status: 404 });
  },
});

Node 端（后台）：

// heavy-lifter.js
const readline = require('readline');

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout,
  terminal: false
});

rl.on('line', (line) => {
  const data = JSON.parse(line);
  // 假装我们在做一个很重的加密运算
  // Node 生态里的老代码都在这儿跑，不用改
  const result = { processed: true, echo: data };
  console.log(JSON.stringify(result));
});

这样搞，路由和 I/O 也是亚毫秒级的，而 Node 只需要处理纯计算，效率直接翻倍。

别让 CPU 搬砖，学会利用 Bun 的零拷贝特性

我发现服务器 CPU 居高不下，居然是因为我们在读取本地的配置文件和静态 JSON，然后序列化发给用户。

在 Node 里，通常会 fs.readFile 然后 res.send。这中间发生了好几次数据拷贝：从磁盘到内核，到用户空间 buffer，再到 socket。

在 Bun 里，我改用 Bun.file()。这不仅是写法上的区别，这是直接告诉操作系统：“把这个文件扔到网卡上去，别经过我的手。”

// 别再 readFile 了，直接流式传输
Bun.serve({
  fetch(req) {
    if (req.url.endsWith("/config")) {
      return new Response(Bun.file("./big-config.json"));
    }
    return new Response("404");
  }
});

这一行代码改动，让我的静态资源吞吐量提升了 3 倍。

排好队，微批处理（Micro-batching）

高并发最可怕的是什么？是 1000 个请求同时涌进来，每个都要单独去调一次数据库或者调一次 Node 进程。就像刚下课，一堆学生全涌到食堂打饭。

而我加了一个极小的缓冲窗口。

如果在 3 毫秒内来了 50 个请求，我把它们打包成一个数组，一次性发给 Node 或者数据库。

let buffer: any[] = [];
let timer: Timer | null = null;

function processBatch() {
  const currentBatch = buffer;
  buffer = [];
  timer = null;
  // 一次性把 50 个任务发给 Node，而不是发 50 次
  askNode({ type: 'batch', items: currentBatch });
}

function enqueue(item: any) {
  buffer.push(item);
  // 只有在第一次推进来时启动计时器
  if (!timer) {
    timer = setTimeout(processBatch, 3); // 3ms 的延迟用户无感，但吞吐量巨大提升
  }
}

这 3 毫秒的等待，换来的是 CPU 负载降低 60%。

别在循环里 new 对象，求你了

我审查代码时发现，很多人喜欢在 fetch 或者 handleRequest 里写 const db = new DatabaseClient() 或者 const regex = new RegExp(...)。

每次请求都重新分配内存、建立连接、编译正则，GC（垃圾回收）不炸才怪。

把所有能复用的东西——数据库连接池、TextEncoder、正则表达式、加密 Key，全部提到全局作用域。在 Bun 和 Node 混合架构里，这一点非常重要，因为我们追求的是极致的低延迟。

双层缓存：内存不够，磁盘来凑

以前我只用 Redis，但网络请求还是有开销。后来我发现，Bun 读取文件的速度超级快。

于是我搞了个双层缓存：

1. L1 内存缓存：用 LRU 存最热的 1000 个 Key，微秒级响应。
2. L2 文件缓存：把稍微冷一点的数据直接写成 JSON 文件放在 /tmp/cache/ 下。

检查文件是否存在，比发起一个 TCP 请求去连 Redis 要快得多。

丢掉那些臃肿的 npm 包

以前在 Node 里，为了生成个 UUID 或者解析个参数，我们习惯性 npm install uuid 或者 qs。

在 Bun 里（其实现代 Node 也是），crypto.randomUUID()、URLSearchParams 都是内置的，而且是 C++ 层面优化的。

我把代码里所有非必要的 npm 依赖全部剔除，改用原生 API。这不仅让冷启动快了，更重要的是减少了 node_modules 的 I/O 噩梦。

解决精神分裂的开发环境

这一套架构就是Bun 做网关，Node 做计算。但在本地开发时，我差点崩溃。

我的电脑上本来跑着 Node 22，为了维护老项目，又要装 Node 14，还要装 Bun，甚至偶尔还要用 Deno 跑个脚本。

nvm 切换来切换去让我心力交瘁，端口冲突、路径报错、环境变量乱成一锅粥。我经常是修好了 Bun 环境，Node 的老项目又跑不起来了。

直到我发现了 ServBay，开发者的救命稻草，它不是那种简陋的版本切换器，它是一个完整的、隔离的运行环境平台。

• 多版本并存：我可以同时开启 Node 14、Node 22 和 Bun 1.1 的环境，它们之间完全隔离，互不打架。
• 一键全家桶：我需要的 Redis（做缓存）、PostgreSQL（存数据）、Caddy（做反代），它全都能一键安装并运行。

• 零配置：我不由得感叹，以前为了配 Docker 和 Homebrew 浪费了不少时间啊。

有了 ServBay，我在本地完美复刻了线上的混合架构：Bun 监听 3000 端口，Node 监听内部管道，Redis 跑在后台。我再也不用担心这是环境问题还是代码问题了。

总结

只要能把响应时间压进 10ms，我不在乎混用多少种运行时。

Bun 给了我速度，Node 给了我稳定性，ServBay 给了我一个不发疯的开发环境。

别再纠结用 Bun 还是用 Node.js了，都成年人了，为什么不能两个都要。把它们结合起来，现在就去把你的 API 延迟砍掉 90%。

全文链接：https://tecdat.cn/?p=44965
原文出处：拓端数据部落公众号
关于分析师

在此对 Hongxuan Liu 对本文所作的贡献表示诚挚感谢，他完成了应用统计专业的硕士学位，专注机器学习、风险管控领域。擅长 R 语言、Python，在机器学习、风险管控领域具备扎实的技术功底，可熟练运用相关软件开展数据分析、建模及风险管控相关工作。Hongxuan Liu 曾在中国农业银行从事数据分析工作，深耕金融领域数据分析与风险管控相关业务，负责银行各类数据的整理、分析与建模，为银行的风险防控、投资决策等核心业务提供数据支撑与实操建议，积累了丰富的金融行业数据分析实战经验。

专题：2025年智能优化算法在A股投资组合配置中的实践与创新

引言

在国内A股市场的投资实践中，普通投资者和中小机构始终面临一个核心难题：如何在多只股票间分配资金，既能控制波动风险，又能实现资产稳健增值。早年间，多数投资者依赖经验或“等权重均分”的方式配置资产，这种缺乏量化支撑的策略，在2020年后市场波动加剧的背景下，资产波动幅度比科学配置方案高出30%以上。
马科维茨的均值-方差模型为量化配置提供了理论基础，但该模型对应的优化问题存在非凸性，传统梯度下降算法极易陷入局部最优，无法找到真正的全局最优配置。粒子群优化算法（PSO）凭借全局搜索能力强的优势成为解决这类问题的有效工具，但传统PSO初始粒子随机分布，导致收敛速度慢、无效计算多。基于此，我们结合为金融机构提供投资组合优化咨询项目的实战经验，提出将重要性采样（IS）与PSO融合的IS-PSO算法，通过定向生成高质量初始粒子群，解决传统PSO“盲目搜索”的痛点。本文将拆解该算法的设计逻辑、落地步骤及在沪深A股样本上的应用效果，让读者既能掌握实操方法，也能理解背后的核心原理。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。

 项目文件目录

整体流程脉络

<pre data-index="0" name="code" style="color: rgb(0, 0, 0); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><img alt="" src="https://i-blog.csdnimg.cn/direct/fa519e9285cd4756b5c826972a17bbba.png" style="border: 0px; max-width: 650px;">
</pre>

1 投资组合优化的行业痛点与技术基础

对于A股投资者而言，“分散投资却没分散风险”是普遍痛点——不少投资者将资金分散到多只股票后，要么收益跑不赢大盘，要么遇到市场调整时亏损远超预期。这背后的核心原因，是没有科学量化不同股票的收益和风险特征，仅依靠经验或简单的行业均分策略，无法适配复杂的市场环境。
马科维茨均值-方差模型为解决这一问题提供了核心框架：将投资组合的收益定义为各资产预期收益率的加权平均值，风险用收益率的标准差衡量，核心目标是找到“有效前沿”——即在给定风险下收益最高，或给定收益下风险最低的资产组合。这一目标转化为数学问题后，核心是最大化效用函数：max (ω^Tμ - λ/2*sqrt(ω^TΣω))。其中ω是资产权重向量（各股票配置比例），μ是资产预期收益率向量，λ是风险厌恶系数（数值越大代表投资者越不愿承担风险），Σ是资产收益率的协方差矩阵。
但这个效用函数具有非凸性，传统梯度下降算法依赖目标函数的梯度信息迭代，很容易停在局部最优解，无法找到真正的全局最优权重配置，这也是传统算法在实际投资中效果不佳的关键原因。

2 IS-PSO算法的创新设计与实现

粒子群优化算法（PSO）是模拟鸟群觅食行为的智能优化算法，每个“粒子”对应一组资产权重，通过迭代更新粒子的位置（权重）和速度，跟踪个体最优位置（pbest）和全局最优位置（gbest），最终找到最优权重配置。但传统PSO的初始粒子是随机生成的，大量粒子落在无效解区域，导致算法收敛慢、计算效率低。
我们的核心创新点在于，用重要性采样（IS）优化初始粒子群的生成逻辑：先随机生成大量权重样本，筛选出目标函数值前20%的“优质样本”，再基于这些样本的分布生成80%的初始粒子，剩余20%粒子随机生成（保证群体多样性）。这种方式让初始粒子聚焦在最优解附近，大幅减少无效迭代，提升收敛效率。

2.1 IS-PSO算法的R语言核心实现

以下是修改后的核心代码（变量名、代码结构均做调整，英文注释已翻译为中文，省略部分通用迭代逻辑）：

# ===== 融合重要性采样的改进粒子群优化算法（IS-PSO） =====enhanced_pso_with_is <- function(converge_threshold = 1e-6, min_diversity = 1e-4, rand_seed = NULL) { # 设置随机种子，保证结果可重复 if (!is.null(rand_seed)) { set.seed(rand_seed) }# 步骤1：重要性采样预生成大量权重样本 pre_sample_total <- 500 # 预生成500个随机权重样本 pre_weight_matrix <- matrix(runif(pre_sample_total * asset_num), pre_sample_total, asset_num) # 权重归一化处理（确保所有资产权重和为1） pre_weight_matrix <- t(apply(pre_weight_matrix, 1, function(x) x / sum(x))) # 计算每个预生成样本的目标函数值 pre_obj_scores <- apply(pre_weight_matrix, 1, calc_objective_func)# 步骤2：筛选前20%的优质权重样本 top_sample_indexes <- order(pre_obj_scores, decreasing = F)[1:(pre_sample_total * 0.2)] top_weight_samples <- pre_weight_matrix[top_sample_indexes, ] sample_central <- colMeans(top_weight_samples) # 优质样本的中心位置 sample_cov_matrix <- cov(top_weight_samples) # 优质样本的协方差矩阵# 步骤3：生成初始粒子群（80%来自优质区域，20%随机生成） particle_positions <- matrix(0, particle_total, asset_num) for (i in 1:particle_total) { if (i <= particle_total * 0.8) { # 80%粒子从优质样本区域生成，考虑资产间相关性 asset_dim <- asset_num # 尝试对协方差矩阵做Cholesky分解（添加小值保证矩阵正定） chol_matrix <- try(chol(sample_cov_matrix + 1e-6 * diag(asset_dim)), silent = TRUE) if (inherits(chol_matrix, "try-error")) { # 分解失败时，使用对角协方差生成扰动值 disturbance_val <- sqrt(diag(sample_cov_matrix)) * rnorm(asset_dim) } else { # 分解成功则生成符合协方差分布的扰动值 disturbance_val <- chol_matrix %*% rnorm(asset_dim) } # 调整扰动幅度（0.2为实战验证的经验系数） temp_weight <- sample_central + 0.2 * disturbance_val temp_weight <- pmax(temp_weight, 0) # 保证权重非负（不允许卖空） } else { # 20%粒子随机生成，维持粒子群的多样性 temp_weight <- runif(asset_num) } # 对生成的权重做归一化处理 particle_positions[i, ] <- temp_weight / sum(temp_weight) }# 省略：粒子速度初始化、个体最优/全局最优参数初始化代码 ......# 省略：粒子位置/速度迭代更新、收敛条件判断的核心循环代码 ......# 返回算法最优结果 return(list( best_weight_config = global_best_pos, best_objective_val = -(global_best_score), portfolio_annual_return = sum(global_best_pos * return_vector), portfolio_annual_risk = sqrt(t(global_best_pos) %*% cov_mat %*% global_best_pos), converge_iterations = iter_count ))}

代码说明：

• 核心逻辑是通过预采样筛选优质权重样本，让80%的初始粒子聚焦在最优解附近，减少无效搜索；
• 变量名如n_pre_samples改为pre_sample_total、n_assets改为asset_num，更贴合中文使用习惯；
• 省略部分为PSO算法通用的迭代更新逻辑（如粒子速度调整、收敛判断循环），可参考常规PSO实现补充。

相关文章

专题：2025年游戏科技的AI革新研究报告

原文链接：https://tecdat.cn/?p=44082

3 IS-PSO算法在A股中的实际应用效果

我们选取沪深A股10只不同行业的股票（覆盖装备制造、信息技术、环保、医药等领域），以2020年7月至2025年6月共1198个交易日的收盘价为基础数据，先计算日对数收益率（Rt = ln(Pt/Pt-1)），再年化处理得到预期收益率和协方差矩阵，对比等权重配置、梯度下降算法、传统PSO、IS-PSO四种方式的应用效果。

3.1 收敛效率大幅提升

传统PSO算法平均需要120次迭代才能收敛，而IS-PSO仅需31次迭代，收敛速度提升74.4%。在计算效率上，IS-PSO平均运行时间为66.789毫秒，远低于传统PSO的232.732毫秒，这意味着在实际应用中，IS-PSO能更快给出最优配置方案，降低计算资源消耗。

3.2 收益风险比更优

在高风险厌恶场景（λ=0.9）下，IS-PSO配置的投资组合平均收益达到0.165，高于传统PSO的0.157；且IS-PSO生成的权重呈现“稀疏性”——仅聚焦2只核心股票，却实现了更高的收益风险比。这对中小投资者而言，大幅降低了选股和资金配置的门槛，无需分散到多只股票就能实现风险与收益的平衡。

3.3 权重配置结果可视化

（空行）

（空行）
上图清晰展示了不同算法的权重配置差异：梯度下降算法配置的资产数量多，但收益表现不如PSO类算法；IS-PSO与传统PSO均聚焦少数核心资产，但IS-PSO在收敛速度和高风险场景下的收益表现更优，更适合普通投资者使用。

4 应急修复服务与落地建议

针对算法落地过程中可能出现的代码运行异常、结果不符合预期等问题，我们提供24小时响应的应急修复服务，相比投资者自行调试，问题解决效率提升40%，能快速定位并解决代码报错、参数设置不当、数据适配异常等问题。
在实际落地层面，IS-PSO算法可直接适配中小投资者的需求：只需导入股票收盘价数据，设置风险厌恶系数，算法就能自动输出最优权重配置。后续可进一步优化方向包括：纳入债券、基金等多元资产，考虑交易成本、流动性等实际交易约束，通过贝叶斯优化实现算法参数的自动调整。

总结

1. 针对A股投资组合优化的非凸性问题，融合重要性采样的PSO算法（IS-PSO）通过优化初始粒子群分布，将收敛速度提升74.4%，大幅提升计算效率；
2. IS-PSO在高风险厌恶场景下收益表现更优，且生成的稀疏权重配置降低了中小投资者的实操门槛；
3. 该算法已通过实际咨询项目验证，配套的24小时应急修复服务可保障算法稳定落地应用。

作者：延枚

云效 MCP Server 已正式发布。它是一个为研发全生命周期提供统一可编程能力的元控制平面，旨在打通工具间的壁垒，实现研发流程的高度自动化。

目前，MCP Server 已提供超过 150 个原子能力（API），全面覆盖云效的核心模块，包括：

• 组织管理： 组织列表、部门信息、角色、成员信息等
• 代码管理： 代码仓库、分支、合并请求、文件树操作等
• 项目管理： 项目、工作项、字段配置、评论、工时管理等
• 流水线管理： 流水线、资源、标签、部署等
• 制品仓库管理： 制品仓库、制品列表等
• 应用交付： 部署单、应用、应用标签、变量组等
• 测试管理： 测试用例、用例目录、测试计划、测试结果等

通过将云效 MCP Server 与自定义脚本，或与通义灵码、Cursor、iFlow-Cli 等本地/云端大模型工具结合，研发团队可以赋予程序直接“操作云效”的能力，从而高效完成各类重复性工作。

例如，在项目协作场景中，你可以实现：

• 智能查询： 快速获取指定项目、迭代或成员名下的需求列表。
• 自动编排： 将复杂需求自动拆解为子任务，并生成验收标准。
• 批量处理： 一次性更新多个工作项的状态、负责人或标签。
• 数据同步： 读取 Excel 或其他系统的数据，批量在云效中创建工作项。

为了帮助大家快速上手，我们推出了 【玩转云效 MCP】 系列专题文章。

本篇作为系列的第一篇，将聚焦于项目管理与协作场景，提供一系列“即刻可用”的 Prompt 示例与实战演练，手把手教你如何利用 MCP 实现项目管理的自动化。

前期环境准备

1. 在本地准备好你的 AI 工具：

• 通义灵码

  https://lingma.aliyun.com/

• Qoder

  https://qoder.com/

• Cursor

  https://cursor.com/cn

• Iflow-Cli

  https://iflow.cn/

• ……

2. 按照云效 MCP Server 的说明完成配置（包含 Token、组织信息等）。

• 配置说明参考：GitHub 文档

  https://github.com/aliyun/alibabacloud-devops-mcp-server/blob/master/README.zh-cn.md

配置完成后，你的 AI 工具就可以通过 MCP 协议直接调用云效的项目 / 工作项等接口。

检查 MCP Server 配置是否生效

完成配置后，可以先用两条最简单的 Prompt 做“自检”。本文中演示示例的 AI 工具为 Qoder。

1. 查看当前组织信息

查看云效当前的组织信息

预期：AI 会调用 YUNXIAO/GET_CURRENT_ORGANIZATION_INFO，并返回：

• 组织 ID（lastOrganization）
• 用户 ID
• 用户名

这些信息后续会被用来继续检索项目、工作项等。

2. 查看当前用户信息

查看云效当前的用户信息

预期：AI 会调用 YUNXIAO/GET_CURRENT_USER，并返回用户名、邮箱、组织 ID 等相关信息。

只要上述两个调用能正常返回结果，基本可以认为 MCP Server 配置是正确的。

实用场景 1：检索+统计/批量处理

云效 MCP 提供了非常丰富的检索能力：

• 项目级： 按项目名称、状态、创建时间等检索项目
• 工作项级： 按标题、描述、状态、优先级、负责人、标签等检索工作项

你可以先让 AI 告诉你“有哪些可用条件”，再组合场景：

云效中检索项目都有哪些条件可使用？
云效中对于检索工作项都提供了哪些条件？

拿到条件后，就可以开始“场景编排”了。

1. 按创建人检索工作项

查看 云效正式自动化 组织中 bowentestmcp 项目 我自己创建的工作项

AI 一般会自动完成：

1. 查询你所属组织列表
2. 切换到“云效正式自动化”组织
3. 查询该组织下名为 bowentestmcp 的项目
4. 在该项目下检索“我创建的工作项”

2. 基于结果做统计 / 批量修改

拿到工作项列表后，可以继续下发指令：

把这两个工作项的状态改为已完成

AI 会：

1. 查询该项目的工作流信息，确认“已完成”状态的 ID（比如：100014）
2. 使用 YUNXIAO/UPDATE_WORK_ITEM 批量更新状态
3. 再次检索校验修改是否成功

3. 更多检索 + 批量处理示例 Prompt

以下 Prompt 都是可以直接用的“套路”：

• 按标签批量打标

某某项目下近一周我创建的需求，请统一加上「一期」标签

• 按迭代统计

统计一下某某项目下，迭代名为「xx」的需求数以及完成情况分析

• 按状态批量流转

请帮我找出 bowentestmcp 项目中所有状态为「已完成」的需求，然后统一将它们的状态改为「已关闭」

• 按标题关键词 + 批量调优先级

查询 xx 项目中所有标题包含「登录」或「注册」的需求，将它们的优先级统一调整为「高」

• 按创建人 + 批量改负责人

找出我创建的所有待处理状态的任务，把它们全部指派给张三（工号：xxx）

实用场景 2：拆分需求

大模型 + MCP 非常适合做“把一个大需求拆成很多小需求并直接录入云效”这类工作。

1. 按功能点拆分父需求

示例：已有父需求 QAAB-3，描述里包含一段“功能列表”：

• 支持加法运算
• 支持减法运算
• 支持乘法运算
• 支持除法运算

你只需要一句：

QAAB-3 这个工作项，请按照里面的功能点描述建立相应的子需求

AI 会：

1. 查询 QAAB-3 的详细描述
2. 自动解析描述中的有序列表（1/2/3/4）
3. 通过 YUNXIAO/CREATE_WORK_ITEM 依次创建 4 个子需求
4. 每个子需求继承父需求的类型、负责人等

最终在云效需求列表页就能看到新创建的需求：

2. 更多拆分需求的示例 Prompt

• 按实现层拆分

找到「实现用户登录功能」这个需求，将它拆分成：前端 UI、后端接口、数据库设计三个子任务

• 按列表自动拆分

查看 QAAB-8 的需求描述，自动识别其中的功能点列表（如 1. 2. 3.），为每个功能点创建一个独立的子需求

• 按开发阶段拆分

将「实现用户注册机制」这个需求拆分为：
- 需求分析
- 技术方案设计
- 前端开发
- 后端开发
- 联调测试
- 上线部署每个阶段创建一个子任务

• 按 INVEST 原则拆分大需求

QAAB-5 这个需求过大，请按照 INVEST 原则将它拆分成：
- 独立的（Independent）
- 可协商的（Negotiable）
- 有价值的（Valuable）
- 可估算的（Estimable）
- 小的（Small）
- 可测试的（Testable）
多个小需求

实用场景 3：优化需求内容

很多需求最初往往只是“半句话”，比如：

支持乘法运算：实现计算器的乘法运算功能，输入两个数，输出两数之积。

这类需求很难直接用于评审 / 开发 / 测试。借助 MCP，你可以让 AI：

• 补全为用户故事形式
• 写出业务流程与影响分析
• 给出可测试的验收条件
• 关键是：写回云效原工作项中

1. 完整优化一个需求示例（QAAB-5）

QAAB-5 这个需求，请进行业务分析优化：
要求：
1. 改为用户故事的结构
2. 分析业务流程和影响
3. 提供验收条件

AI 典型的处理步骤：

1. 读取 QAAB-5 的原始描述（“实现计算器的乘法运算功能...”）

2. 生成：

   • 用户故事（作为谁 / 我希望 / 以便）
   • 业务流程（打开计算器 → 输入数字 → 选择乘号 → 输入第二个数 → 点击等号 → 展示结果）
   • 业务影响（对前端 / 后端 / 错误处理 / 测试等的影响）
   • 验收条件（覆盖正数、负数、小数、0、边界值、非法输入、性能等场景）
3. 使用 YUNXIAO/UPDATE_WORK_ITEM 将上述内容整体写回 QAAB-5 的描述字段

优化完成后，在云效中查看 QAAB-5，就会看到一个完整、可评审、可测试的需求说明。

2. 更多需求优化的示例 Prompt

• 改写为用户故事格式

查看「实现用户登录功能」这个需求，将它改写为用户故事格式：
- 作为【谁】
- 我希望【做什么】
- 以便【达成什么价值】
并直接更新回工作项

• 批量用户故事化技术需求

找出所有技术描述类的需求（标题以「实现」开头），将它们统一改写为用户故事格式，突出用户角色和业务价值

• 补充验收条件

QAAB-8 缺少验收标准，请根据需求描述补充至少 5 条可量化的验收条件，
包括：
- 功能性验收
- 性能要求
- 边界条件
- 异常处理
并更新回原需求

• 补充测试场景

查看「支持乘法运算」需求，补充完整的测试场景：
- 正常场景（正数、负数、小数）
- 边界场景（0、极大值、极小值）
- 异常场景（非法输入、溢出）
更新回原需求的验收条件部分

• 批量为无验收条件的需求补充标准

找出所有没有验收条件的需求（描述中不包含「验收」关键词），
为每个需求根据其标题和描述自动生成 3-5 条验收标准，并写回工作项

实用场景 4：批量导入需求

当你已经有一份 Excel / CSV 需求列表时，可以直接让 AI + MCP 帮你“批量录入到云效”。

1. 从 Excel 表格导入示例

假设有一个 Excel：

只需要一句 Prompt：

请将「需求列表.xlsx」中的内容录入到云效 bowentestmcp 这个项目中

AI 的典型处理流程：

1. 解析 Excel 结构（首行是表头：标题 / 内容 / 优先级）

2. 将每一行映射为：

   • subject → 标题
   • description → 内容
   • priority → 优先级（高 / 中 / 低）
3. 调用 YUNXIAO/CREATE_WORK_ITEM 创建 4 条新需求

回到云效 bowentestmcp 项目的需求列表页，就能看到刚刚导入的 4 条需求。

2. 更多批量导入的示例 Prompt

• 从“产品需求.xlsx”导入

从「产品需求.xlsx」导入需求，全部创建为「产品类需求」类型，指派人统一设置为我本人

• 指定字段映射导入

导入「backlog.xlsx」到 bowentestmcp 项目：
- 第 1 列（需求名称） → 标题
- 第 2 列（详细说明） → 描述
- 第 3 列（重要程度） → 优先级（高/中/低）
- 第 4 列（负责人姓名） → 指派人
- 第 5 列（所属模块） → 标签

• 带层级关系导入

导入「需求层级.xlsx」，根据「父需求ID」列建立父子关系：
- 第一级：Epic / 主题需求
- 第二级：Feature / 功能需求
- 第三级：Story / 用户故事
自动建立层级关联

• 自动识别表头并导入

分析「需求文档.xlsx」的表头结构，自动识别对应的字段映射关系，将数据导入 bowentestmcp 项目

• 导入前先做数据校验

导入「需求池.csv」前先验证：
- 必填字段不能为空（标题、描述）
- 优先级只能是「高/中/低」
- 负责人必须是项目成员
- 标题长度不超过 50 字
验证通过后再批量创建

更多项目管理场景示例

在前面几个场景基础上，还可以进一步组合出更复杂的“项目级”能力。

1. 项目健康度检查

分析 bowentestmcp 项目健康状况：
- 统计各状态需求分布
- 检查逾期未完成的需求
- 识别长期无人认领的需求
- 分析需求平均完成周期
- 检测可能的瓶颈（某状态停留过久）
生成健康度报告

AI 可以基于 SEARCH_WORKITEMS 等接口，做出一份结构化的项目健康度分析报告。

2. 迭代规划

为即将开始的 Sprint 5 规划任务：
1. 从需求池中筛选高优先级需求
2. 智能推荐适合本迭代的需求组合
3. 自动分配给合适的成员
4. 创建迭代并关联需求

3. 迭代回顾

为刚结束的 Sprint 3 生成回顾报告：
- 完成需求数 vs 计划需求数
- 各成员完成情况统计
- 延期需求分析
- 紧急插入需求统计
- 提取改进建议

4. 工作负载分析

分析 bowentestmcp 项目团队成员工作负载：
- 统计每人当前进行中的任务数
- 计算每人的工作时长总和
- 识别负载过重或过轻的成员
- 建议任务重新分配方案

5. 需求质量评估

批量检查 xx 项目中所有「待开发」状态的需求质量：
- 描述完整性（是否包含背景、目标、验收标准）
- 验收条件清晰度（是否可测试）
- 依赖关系完整性
- 工作量评估准确性
不合格的标记为「待补充」并通知负责人

6. Bug 关联需求分析

分析 xx 项目中 Bug 与需求的关联：
- 统计每个需求关联的 Bug 数量
- 识别高缺陷率的需求
- 分析 Bug 产生的阶段（开发/测试/生产）
- 提供质量改进建议

小结

通过本文的实战演练，我们看到：当云效 MCP Server 与自动化脚本或智能体结合，它不再仅仅是一组 API，而是一种全新的研发协作范式。它将“会用云效”的人，从大量机械操作中解放出来。总结来说，MCP 为项目管理者带来了三大核心价值的转变：

• 执行指令化： 将原本需要数十分钟的手动点击，压缩为几行指令或一句自然语言描述。
• 经验模板化： 将个人的最佳实践与团队规范，沉淀为可复用、可共享的自动化模板。
• 精力聚焦化： 将管理者从繁琐的工具操作中解放，回归到思考产品、业务和团队等更高价值的工作上。

云效 MCP Server 就像一套高效的“项目协作外骨骼”——它增强你的能力，放大你的效能，让你跑得更快、更远。而这，仅仅是开始。项目管理是 MCP 能力版图的第一块拼图。

在下一篇文章中，我们将深入 【代码管理】 场景，探索如何通过 MCP 实现分支自动创建、权限精细化管理、代码合规性检查等高阶玩法。

敬请期待！也欢迎你在评论区分享使用心得，或告诉我们你最希望 MCP 在哪个领域帮你实现自动化。

点赞 + 关注 + 收藏 = 学会了

整理了一个NAS小专栏，有兴趣的工友可以关注一下 👉 《NAS邪修》

VERT.sh 是一款开源文件转换工具，它所有转换都在本地浏览器完成，文件（除视频外）永不上传云端，支持 n 种格式（文档、图片、音频、视频），无广告、无文件大小限制，开箱即用！

这次我使用绿联的 NAS 部署 VERT.sh，其他品牌的 NAS 只要支持 Docker 的，部署步骤都是大同小异。

首先在“文件管理”应用里找到“docker”文件夹，在里面创建一个“vert”文件夹。

打开“Docker”应用，点击左侧菜单的“项目”，创建一个新项目。

• 项目名称：vert。
• 存放路径：选择上一步创建的 xxx/docker/vert 文件夹。

Compose配置 输入以下代码：

services:
  vert:
    image: ghcr.io/vert-sh/vert:latest
    container_name: vert
    ports:
      - 2340:80 
    restart: unless-stopped

这里我配置了 2340 这个端口，你根据你实际情况配置吧，只要不跟其他项目的端口冲突就行。

然后等 Docker 下载镜像和构建项目，等就行，速度取决于你的网速。

项目构建完成后，点击左侧菜单”容器“这项，找到 vert 这项，点击它右侧的小箭头会弹出端口号，点击端口这个按钮。

点击端口按钮后，浏览器会新开一个窗口运行 VERT.sh。

它默认界面是英文的，点击顶部菜单的“Settings”项，找到“Language”，切换成中文就行。

回到首页可以看到 VERT.sh 支持图片、音频、文档和视频等文件的格式转换。

测试了一下，图片是可以转格式的。

但视频要传到人家的服务器转，而且还不一定成功😮‍💨

就当没转视频格式这个功能吧😤

以上就是本文的全部内容啦，有疑问可以在评论区讨论～

想了解更多NAS玩法可以关注《NAS邪修》👏

点赞 + 关注 + 收藏 = 学会了

点赞 + 关注 + 收藏 = 学会了

整理了一个n8n小专栏，有兴趣的工友可以关注一下 👉 《n8n修炼手册》

非技术出身的工友在使用 n8n 时是否会遇到这样的困惑：爬取了一堆数据不知道存哪里，总不能每次都导出到Excel再来回导入？想让多个工作流共用一套数据，却找不到简单的方法？不想折腾MySQL、PostgreSQL这些复杂的外部数据库，也看不懂晦涩的SQL语句？

如果有以上困惑，而且你的数据结构不是那么复杂的话，可以试试 n8n 内置的 Data tables。

我用一个简单的例子介绍一下 Data tables 的用法，顺便讲讲不同格式的字段该如何转换。

我们可以在 Data tables 面板管理各个数据表，点击右上角的“Create data table”创建一个数据表。

我以“员工信息表”作为演示。

点击加号新增 name 和 married。

name 是“员工姓名”，Type 选择 string。

married 是“是否结婚”，Type 选择 boolean（这个类型只有“是”和“否”两个选项）。

创建一个工作流，添加要给表单节点。

只有2个字段，表单的“姓名”对应数据表里的 name；表单的“是否结婚”对应数据表里的 married。

但是，数据表的 married 的类型是布尔型，也就是 true 表示已结婚，false 表示未结婚。但表单的“是否结婚”的选项却是字符串的“已结”和“未结”。这里要做一下转换。

在表单节点后面添加一个「Insert row」节点，搜 table 就能找到它。

给「Insert row」节点做以下配置。

「From list」选择刚刚创建的“员工信息”表。

「Values to insert」填入 name 和 married 这两个字段。

name 这项填入 {{ $json['姓名'] }} 比较好理解，我不讲解了。

married 这项填入 {{ $json['是否结婚'] === '已结' ? true : false }}，这是 JS 的三元运算符，判断上一个节点传入的“是否结婚”这项的值是否为“已结”，如果是的话就存入 true ，否则存入 false。

测试一下整个工作流。

我提交了2次表单：

• 雷猴，已结
• 鲨鱼辣椒，未结

来到数据表就能看到这两项了。

鲨鱼辣椒突然说他今天要结婚了，作为 HR 也应该更新一下数据。

此时再提交一次表单：鲨鱼辣椒，已结。你会发现工作流又多了一条数据，这并不是我们想要的结果。

在 Data tables 里先手动删除第3项。

回到工作流这边，新增了一些节点。

• 上面那条：

  • 「If row exists」：如果传入的“姓名”已在数据表里，就走这条。
  • 「Update row(s)」：更新表中的数据。

• 下面那条：

  • 「If row does not exist」：如果传入的“姓名”不在数据表里，就走这条。
  • 「Insert row」：新增一条数据。

「If row exists」和「If row does not exist」的判断条件都是一样的，如下图所示。只不过这两个节点的功能不同而已。

在来看「Update row(s)」这个节点，通过 name 这个字段找到要修改的那行数据，找到后就修改 married 这列的值。

「Insert row」节点的配置不需要改变。

试试～

提交一项：鲨鱼辣椒，已婚

回到数据表这边就能看到鲨鱼辣椒的婚姻状态变成“true”了。

再提交一项：蝎子莱莱，未婚。

由于“蝎子莱莱”不在数据表里，所以走的是“新增”路线。

以上就是本文的全部内容啦，想了解更多n8n玩法欢迎关注《n8n修炼手册》👏

如果你有 NAS，我非常建议你在 NAS 上部署一套 n8n，搞搞副业也好，帮你完成工作任务也好 《『NAS』不止娱乐，NAS也是生产力，在绿联部署AI工作流工具-n8n》

点赞 + 关注 + 收藏 = 学会了