极狐GitLab 18.7 版本发布，带来了改进的 GitLab Duo 分析仪表盘与密钥有效性校验、支持为聊天和智能体选择 AI 模型，以及更多新功能！

我们非常高兴地宣布 GitLab 18.7 正式发布。本次版本包含改进的 GitLab Duo 分析仪表盘、改进的密钥有效性校验、为聊天和智能体提供模型选择能力，以及更多更新内容！

以上只是本次版本 25+ 项改进中的一部分亮点。请继续阅读，了解下面所有精彩的更新内容。

版本信息

容器镜像

• 18.7.0 容器镜像

registry.gitlab.cn/omnibus/gitlab-jh:18.7.0-jh.0

• 18.7.0 Helm Chart（JH）

helm search repo gitlab-jh
NAME                      CHART VERSION APP VERSION 
gitlab-jh/gitlab          9.7.0         v18.7.0    
gitlab-jh/gitlab-runner   0.84.0        18.7.0

18.7 关键功能

密钥有效性校验改进并正式发布

当你的某个代码仓库中泄露了一个有效密钥时，你必须迅速做出响应。
为了帮助你优先处理紧急威胁，密钥有效性校验会自动验证泄露的凭据是否仍然可以被使用。

在 GitLab 18.7 中，我们进行了以下改进：

厂商集成： 与 Google Cloud、AWS 和 Postman 集成，同时保留了对 GitLab 令牌的现有支持。

报告过滤： 可以按有效性状态（active、inactive、possibly active）过滤漏洞报告（Vulnerability Report），以便快速进行分流和优先级排序。

群组级 API： 通过一次 API 调用即可在一个群组内的所有项目上启用密钥有效性校验，从而简化在整个组织范围内的推广。

在本次发布中，密钥有效性校验已正式全面可用（generally available）。

为 Agentic Chat 和各类智能体分别选择模型

现在可以为 Agentic Chat 和所有其他智能体分别选择不同的模型，适用于顶级群组或实例。

这为 GitLab Duo Agent Platform 提供了更多模型选择选项。

改进的 GitLab Duo 与 SDLC 趋势仪表盘

GitLab Duo 与 SDLC 趋势仪表盘提供了增强的分析能力，用于衡量 GitLab Duo 对软件交付的影响。该仪表盘现在可以提供为期 6 个月的趋势分析，覆盖 GitLab Duo 功能采用情况、流水线性能，以及部署频率和平均合并时间等常见开发指标。

你现在可以跟踪 GitLab Duo Code Suggestions 的代码生成量以及 IDE 或语言趋势，并观察你的团队如何采用新的 GitLab Duo Agent Platform 流程。增强的用户级指标使团队能够更深入地洞察持续产生价值的关键 Duo 功能。

现在新增了一个用于实例级 AI 使用情况的端点，实例管理员可以从 Postgres（保留 3 个月数据）或 ClickHouse 中提取所有 Duo 数据。
https://docs.jihulab.com/api/graphql/reference/#aiinstanceusa...

得益于 ClickHouse 集成，该仪表盘可以在数百万数据点规模下实现亚秒级查询性能。对于自托管实例，请查看关于 ClickHouse 集成的改进建议和配置指导：
https://docs.jihulab.com/integration/clickhouse/

Planner Agent 的更多功能以 Beta 形式提供

Planner Agent 现在在 Beta 阶段新增了创建和编辑功能！Planner Agent 是一个基础智能体，专为在 GitLab 中直接支持产品经理而构建。你可以使用 Planner Agent 来创建、编辑和分析 GitLab 工作项。

无需再手动追踪更新、确定工作优先级或汇总规划数据，Planner Agent 可以帮助你分析待办事项列表，应用 RICE 或 MoSCoW 等框架，并突出显示真正需要你关注的内容。它就像一位主动协作的队友，能够理解你的规划工作流，并与你一起做出更优、更高效的决策。

CI/CD 流水线中的动态输入选项

你可以在通过直观的 Web 界面创建新流水线时，将 CI/CD 流水线配置为使用动态输入选择。

现在，借助动态输入选项，你可以配置流水线，使输入选项能够根据之前的选择动态更新。例如，当你在一个下拉列表中选择某个输入项时，第二个下拉列表会自动填充一组相关的输入选项。

使用 CI/CD 输入，你可以：

• 使用预配置的输入触发流水线，从而减少错误并简化部署流程。
• 允许用户从下拉菜单中选择不同于默认值的输入项。
• 现在可以使用级联下拉列表，其中选项会根据之前的选择动态更新。

这种动态能力使你能够创建更加智能、具备上下文感知能力的输入配置，引导你完成流水线创建过程，减少错误，并确保只选择有效的输入组合。

基于 AI 的 SAST 误报检测（Beta）

安全团队通常需要花费大量时间调查最终被证明是误报的 SAST 发现结果，从而分散了对真实安全风险的关注。

在 GitLab 18.7 中，我们引入了基于 AI 的 SAST 误报检测，帮助团队将精力集中在真正重要的漏洞上。当安全扫描运行时，GitLab Duo 会自动分析每一个严重级别为 Critical 和 High 的 SAST 漏洞，以判断其成为误报的可能性。

AI 评估结果会直接显示在漏洞报告中，为安全工程师提供即时上下文，从而更快、更有信心地做出分流决策。

关键能力包括：

• 自动分析： 误报检测会在每次安全扫描完成后自动运行，无需人工触发。
• 手动触发选项： 用户可以在漏洞详情页面针对单个漏洞手动触发误报检测，以进行按需分析。
• 聚焦高影响发现结果： 仅覆盖 Critical 和 High 严重级别漏洞，以最大化信噪比的提升。
• 具备上下文的 AI 推理： 每次评估都会包含关于该发现为何可能是真阳性或误报的解释，基于代码上下文和漏洞特征进行判断。
• 无缝工作流集成： 结果会直接显示在漏洞报告中，并与现有的严重级别、状态和修复信息并列展示。

新的安全仪表盘默认启用

新的安全仪表盘已经完成更新和现代化改造。此前这些仪表盘仅在 jihulab.com 上可用，现在已在 GitLab Dedicated 和 GitLab Self-Managed 中默认启用。

新功能包括：

• 漏洞随时间变化图表，支持：

  • 按项目或报告类型进行过滤。
  • 按报告类型和严重级别进行分组。
  • 直接链接到漏洞报告中的具体漏洞。
• 风险评分模块，基于 GitLab 算法为群组或项目计算估算风险评分。

用于控制向 CI/CD Catalog 发布组件的实例级设置

GitLab Self-Managed 和 GitLab Dedicated 的管理员现在可以限制哪些项目被允许向 CI/CD Catalog 发布组件。此新设置使组织能够通过控制可发布的组件范围，维护一个经过精选和可信的 CI/CD Catalog。

管理员现在可以指定一个允许发布组件的项目白名单。当白名单中配置了项目后，只有这些项目才能发布组件。这可以防止未经授权或未批准的组件充斥已发布组件列表，并确保所有组件符合组织标准和安全要求。

这解决了企业客户在希望保持对其 CI/CD 组件生态系统控制的同时，又希望支持团队发现和复用已批准组件时所面临的一项关键治理挑战。

Web IDE 支持离线的 GitLab 私有化部署环境

在离线或严格受控的网络环境中，GitLab 私有化部署（Self-Managed）的管理员现在可以配置自定义的 Web IDE 扩展主机域名，使 Web IDE 在 无外网访问的情况下仍能完整使用功能。

此前，Web IDE 需要访问外部域名 .cdn.web-ide.gitlab-static.net 来加载 VS Code 扩展和相关功能，这使得许多具有高安全要求的组织（如政府部门、公共机构、拥有严格网络隔离策略的企业）无法使用 Web IDE。

通过本次更新，管理员可以将 Web IDE 所需的资源直接由 GitLab 实例自身提供，彻底消除了对外部域名的依赖。这样你可以：

• 在完全离线环境中使用完整的 Web IDE 功能集
• 通过自定义扩展注册表服务启用扩展市场（Extension Marketplace）
• 在隔离网络中启用 Markdown 预览、代码编辑以及 GitLab Coderider Chat

这项改进大幅提升了 Web IDE 在高安全场景下的可用性与部署灵活性。

GitLab 18.7 中的其他改进

标题锚点链接的无障碍访问改进

标题锚点链接现在会使用与其对应标题相同的文本进行朗读，从而改善屏幕阅读器用户的使用体验。这些链接还会显示在标题文本之后，从而提供更加简洁的视觉呈现效果。

这些改进使所有用户都能够更轻松地理解并导航到文档、Issue 以及其他内容中的特定章节。

在合并请求中查看子流水线报告

此前，使用父子 CI/CD 流水线的团队需要在多个流水线页面之间来回切换，以查看测试结果、代码质量报告和基础设施变更，从而打断了合并请求的评审工作流。

现在，你可以在一个统一视图中查看和下载所有报告，包括单元测试、代码质量检查、Terraform 计划以及自定义指标，而无需离开合并请求页面。

这消除了上下文切换，加快了合并请求的处理速度，使团队能够在不牺牲质量的前提下更快地交付功能。

合并请求审批策略中的警告模式

安全团队现在可以使用警告模式（warn mode）在应用强制执行之前测试和验证安全策略的影响，或者通过软门禁方式逐步推广安全策略，从而加速安全项目推进。警告模式有助于在安全策略推广过程中减少开发人员阻力，同时仍然确保检测到的漏洞能够得到处理。

当你创建或编辑一个合并请求审批策略时，现在可以在警告（warn）或强制（enforce）两种执行选项之间进行选择。
https://docs.jihulab.com/user/application\_security/policies/merge\_request\_approval\_policies/

处于警告模式的策略会生成提示性的机器人评论，但不会阻塞合并请求。可以指定可选审批人作为策略问题的联系人。这种方式使安全团队能够评估策略影响，并通过透明、渐进式的策略采用方式建立开发人员信任。

合并请求中会通过清晰的标识提示用户当前策略处于警告模式还是强制模式，审计事件会跟踪策略违规和驳回情况，用于合规报告。开发人员可以在提供策略驳回理由的情况下绕过扫描发现和许可证策略违规，从而在开发人员与安全

团队之间建立一个更有效的协作反馈闭环，以推动策略更有效地落地。

当在项目的默认分支上检测到策略违规时，策略会在项目和群组的漏洞报告中标识违反策略的漏洞。项目的依赖列表

也会显示徽标，用于指示许可证合规策略违规。

此外，你还可以使用 API 查询项目默认分支上经过过滤的策略违规列表。

对合规违规进行过滤和评论

合规违规报告提供了一个集中视图，用于展示整个组织各项目中的所有合规违规情况。该报告显示有关控制项违规的全面详细信息、相关审计事件，并支持团队有效跟踪违规状态。

在 GitLab 18.7 中，我们引入了强大的过滤能力，帮助你快速找到最重要的违规项。你现在可以按以下条件进行过滤：

• 状态（Status）
• 项目（Project）
• 控制项（Control）

团队现在还可以通过评论直接协作解决违规问题。在违规记录本身中，团队可以：

• 标记团队成员以开展调查
• 讨论修复方案
• 记录调查结论 —— 全部都在违规记录中完成

综合来看，这些功能将合规违规报告演进为一个动态协作平台，使组织能够在其群组和项目中高效地发现、分析和解决合规违规问题。

自托管版本的试用中体验增强

GitLab Self-Managed 的 Ultimate 试用用户现在可以从左侧边栏访问其当前试用状态、剩余天数、可使用功能以及到期通知。

这些增强功能有助于消除对试用周期的困惑，并使用户在购买前更容易评估付费功能。

AI 网关超时设置

对于 GitLab Duo Self-Hosted，现在可以为发送到自托管模型的请求配置一个超时时间值。

该值的范围可以设置为 60 到 600 秒。

配置基础智能体可用性

你现在可以控制在你的顶级群组或实例中哪些基础智能体（foundational agents）可用。

你可以默认开启或关闭所有基础智能体，或者按需切换单个智能体，以符合你组织的安全与治理策略。

向管理员报告智能体和流程

当你遇到有问题的内容时，现在可以将智能体（agents）和流程（flows）报告给实例管理员。你可以提交一条包含反馈的滥用报告，管理员可以选择隐藏或删除有害内容。

使用该功能可以在整个组织范围内保持你的智能体和流程的安全性。

极狐GitLab 18.8 版本正式发布，GitLab Duo Agent 平台现已全面可用，同时还发布了 GitLab Duo 规划 Agent（Planner Agent）、GitLab Duo 安全分析 Agent（Security Analyst Agent）、自动忽略无关漏洞等多项新功能！

GitLab 18.8 已正式发布，GitLab Duo Agent 平台现已全面可用，同时还发布了 GitLab Duo 规划 Agent（Planner Agent）、GitLab Duo 安全分析 Agent（Security Analyst Agent）、自动忽略无关漏洞等多项新功能！

今天，我们非常高兴地宣布 GitLab 18.8 正式发布，其中包括 GitLab Duo Agent 平台现已正式可用、GitLab Duo 规划 Agent、GitLab Duo 安全分析 Agent、自动忽略无关漏洞等众多更新内容。

以上只是本次版本中 10 多项改进中的一部分亮点。继续阅读以了解本次发布中的所有精彩更新。

了解更多信息请访问 极狐GitLab 官网：gitlab.cn

版本信息

容器镜像

• 18.8.0 容器镜像

registry.gitlab.cn/omnibus/gitlab-jh:18.8.0-jh.0

• 18.8.0 Helm Chart（JH）

helm search repo gitlab-jh
NAME                      CHART VERSION APP VERSION 
gitlab-jh/gitlab          9.8.0         v18.8.0    
gitlab-jh/gitlab-runner   0.85.0        18.8.0

18.8 关键功能

GitLab Duo Agent 平台现已正式可用

GitLab Duo Agent 平台现已正式可用，为整个软件开发生命周期带来基于 Agent 的 AI 编排能力。不同于只是在单点任务上提升效率的 AI 工具，Agent 平台可以帮助团队在规划、构建、安全与交付各阶段协同调度多个 AI Agent，弥合个人效率提升与真实协作式、多阶段软件交付之间的差距。

该平台提供了一个统一的 AI Catalog（AI 目录），团队可以在其中发现、管理并在组织内共享 Agent 与流程（flows）。内置的基础 Agent（Foundational Agents），例如 规划 Agent（Planner）、安全分析 Agent（Security Analyst） 和 数据分析 Agent（Data Analyst），可在关键决策节点处理结构化工作；同时，可定制的流程（flows）能够自动化多步骤的 Agent 与任务，覆盖从 Issue 到 Merge Request、CI/CD 迁移、流水线故障排查以及代码评审等开发工作流场景。

借助治理控制、使用可视化能力以及灵活的部署选项（包括支持离线环境的自托管模型），组织可以在具备透明度与可控性的前提下规模化采用 AI。

GitLab Premium 和 Ultimate 用户现已可以在 jihulab.com 以及 GitLab 自托管实例中使用 Agent 平台，并可使用推广期提供的 GitLab Credits。

GitLab Duo 规划 Agent 现已正式可用

规划 Agent 现已正式可用！规划 Agent 是一个基础 Agent，旨在直接支持 GitLab 中的产品经理工作。

使用规划 Agent，您可以创建、编辑和分析 GitLab 工作项（work items）。相比手动跟进更新、进行工作优先级排序或汇总规划数据，规划 Agent 可以帮助您分析待办事项列表（backlog）、应用 RICE 或 MoSCoW 等规划框架，并突出显示真正需要关注的事项。它就像一位主动协作的队友，能够理解您的规划工作流，并帮助您做出更优、更高效的决策。

GitLab Duo 安全分析 Agent 现已正式可用

GitLab Duo 安全分析 Agent（Security Analyst Agent）在 GitLab 18.5 中以 Beta 形式首次引入，如今已在 GitLab 18.8 中正式可用。

安全分析 Agent 使工程师能够通过自然语言指令，在 GitLab Duo Agentic Chat 中管理漏洞。相比手动在漏洞仪表盘中逐项操作，或为批量处理编写自定义脚本，安全团队现在可以直接在聊天会话中完成漏洞的分诊（triage）、评估以及获取处置建议。

作为一个基础 Agent，安全分析 Agent 默认已在 GitLab Duo Agentic Chat 中提供，无需进行任何手动配置即可使用。

使用漏洞管理策略自动忽略无关漏洞

GitLab 18.8 中的其他改进

GitLab Runner 18.8

我们今天同时发布了 GitLab Runner 18.8！GitLab Runner 是一个高度可扩展的构建 Agent，用于执行您的 CI/CD 作业并将结果回传至 GitLab 实例。GitLab Runner 与 GitLab CI/CD 协同工作，而 GitLab CI/CD 是 GitLab 内置的开源持续集成服务。

新增内容（What’s New）：

• 改进了作业输入插值错误时的错误提示信息
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/39163

缺陷修复（Bug Fixes）：

• WaitForServicesTimeout 不再支持使用 -1 来禁用超时
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/39172
• 自定义 URL 在使用 insteadOf 规则时会导致子模块认证失败
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/39170
• Windows 2025 上自定义 Runner 的短 Token 长度由 8 个字符变为 9 个字符
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/39122
• GitLab Runner 17.8.3 中，Docker Executor 缺少 PowerShell 默认 helper 镜像
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/38669
• 使用 Docker Autoscaler 的 GitLab Runner 无法复用已有的缓存卷
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/37906
• 当作业被取消时，VirtualBox 会遗留未清理的虚拟机
  https://jihulab.com/gitlab-org/gitlab-runner/-/work\_items/37344

所有变更的完整列表请参见 GitLab Runner 的

多容器扫描（Beta）

在 GitLab 18.8 中，我们以 Beta 形式发布了多容器扫描功能。

现在，用户可以在多个容器扫描作业中传入一个镜像数组作为扫描目标，从而在一次流水线执行中对多个容器镜像进行安全扫描。

Group Owner 可为企业用户禁用 SSH Key

现在，Group Owner 可以为其群组内的所有企业用户禁用 SSH Key。禁用后，用户将无法添加新的 SSH Key，现有的 SSH Key 也会被停用。该策略适用于群组中的所有企业用户，包括拥有 Owner 角色的用户。

感谢 Wesley Yarde 协助构建了这一功能！

GitLab Duo 功能的群组级访问控制

现在，您可以定义群组访问规则，用于控制哪些用户可以使用 GitLab Duo 功能，从而支持从“立即在整个组织范围内启用”到“分阶段逐步推广”等灵活的采用策略。

该功能提供了更精细化的治理控制能力，使您可以在保障安全性与合规性的前提下，按照自身节奏逐步扩大 GitLab Duo 的使用范围。

Advanced SAST 对 C/C++ 的支持现已正式可用

GitLab Advanced SAST 现已正式支持针对 C/C++ 的跨文件、跨函数扫描能力。

面向 Group Owner 的集中式凭据管理 API

凭据清单 API（Credentials Inventory API） 现已在 jihulab.com 上向企业用户开放。这一能力将此前仅在自托管实例中提供的凭据管理功能引入到 SaaS 环境，帮助组织更好地管理和保护其身份验证令牌与密钥。

凭据清单 API 提供了对整个组织范围内凭据的编程访问能力，包括：

• 个人访问令牌（Personal Access Tokens，PATs）
• 群组访问令牌（Group Access Tokens，GrATs）
• 项目访问令牌（Project Access Tokens，PrATs）
• SSH Key
• GPG Key

该 API 与现有的 凭据清单 UI（Credentials Inventory UI） 形成互补，使企业管理员能够将此前需要人工操作的凭据管理任务自动化。通过凭据清单 API，您可以：

• 自动化安全工作流：构建自动化流程，对凭据进行监控、审计与吊销
• 强制执行凭据策略：识别并吊销未使用或已过期的令牌
• 提升整体安全态势：通过定期审计降低凭据被滥用的风险
• 简化运维流程：将凭据管理集成到现有安全工具与工作流中

面向 GitLab Duo Self-Hosted（离线授权）的 GitLab Duo Agent 平台现已正式可用

GitLab Duo Agent 平台现已在 Duo Self-Hosted 场景下正式可用。该功能面向使用离线许可证的 GitLab 自托管客户提供，并采用按席位（seat-based）的定价模式。

自托管管理员可以为 GitLab Duo Agent 平台配置可兼容的模型（compatible models）。使用 AWS Bedrock 或 Azure OpenAI 的管理员，还可以配置 Anthropic Claude 或 OpenAI GPT 模型。

开启或关闭 GitLab Duo Agent 平台

现在，您可以在顶级群组（top-level group）或整个实例范围内，开启或关闭 GitLab Duo Agent 平台，包括 GitLab Duo Chat（Agentic）、各类 Agent 以及流程（flows）。当该设置被关闭时，这些功能将不可用。

工业AI大模型在汽车零部件制造中的应用：探索与实践
工业AI大模型作为一种先进的人工智能技术，在汽车零部件制造领域展现出强大的应用潜力。它不仅能优化生产流程，还能提升产品质量和生产效率。这种技术的核心在于其对多模态数据的处理能力和实时决策能力。通过结合计算机视觉、自然语言处理和强化学习等技术，工业AI大模型能够分析生产过程中的各种数据，从而实现高效的生产管理。
在汽车零部件制造中，工业AI大模型的应用涵盖了从设计到生产的多个环节。例如，在工艺设计阶段，AI模型可以通过历史数据和知识图谱快速生成优化方案，减少工程师的工作负担。在生产执行阶段，模型能够实时监控设备状态，预测潜在问题并提供解决方案。这种技术的引入，使得汽车零部件制造不再依赖单一的人工经验，而是转向数据驱动的智能化模式。
问题解决：工业AI大模型如何赋能汽车零部件制造？
汽车零部件制造面临诸多挑战，如复杂的工艺链、多变的市场需求以及对高精度的要求。工业AI大模型通过整合多源数据，帮助解决这些问题。首先，它通过实时分析设备传感器数据，实现预测性维护，减少设备故障导致的停机时间。其次，利用计算机视觉技术，AI模型可以自动检测产品缺陷，提高质检效率和准确性。此外，AI大模型还能优化生产排程，确保生产线的高效运转。
例如，在焊接工艺中，工业AI大模型可以实时监测电流、电压和温度等参数，动态调整焊接过程，从而避免虚焊或漏焊等问题。这不仅提高了产品的合格率，还减少了人工干预的需求。在供应链管理方面，AI模型可以预测原材料需求，优化库存管理，确保生产不会因物料短缺而中断。
案例分析：企业的实践
广域铭岛在汽车零部件制造中应用工业AI大模型，取得了显著成效。他们的多模态工业大模型在焊装车间实现了“零缺陷”闭环管理。通过实时采集焊接参数，AI模型能够快速识别虚焊和漏焊等问题，并自动生成补偿指令，将传统3小时的排查时间缩短至5分钟。这使得焊点一次合格率提升到99.5%，缺陷流出率下降了80%。

“AI不是要取代人类，而是要放大人类的价值。”当阿里在2026年开年发布“商业操作系统”（B-OS）时，这句宣言让无数产品经理热血沸腾。从ChatGPT到Sora，从大模型军备竞赛到AI视频卷出新高度，这场技术革命正以摧枯拉朽之势重塑商业格局——而产品经理，正是这场变革中最关键的“价值放大器”。

一、AI狂飙：从实验室到产业毛细血管的“真实效能”

当行业还在争论“千亿参数是否必要”时，AI早已悄然渗透到产业最深处：
汽车赛道：大搜车用AI重构二手车交易全流程，从维保记录解析到夜间直播留资，AI工具日均调用超百万次，将信息不对称的“黑箱”变成标准化数据流。某华东车商靠AI走播机器人拿下30%夜间订单，证明AI不是“炫技”，而是“印钞机”。

影视制作：Minimax的“动物奥运会”视频引爆全网，背后是Hailuo-02模型对高难度人体动作的精准复现。PixVerse的“实时世界模型”让视频生成从“重现历史”跃迁至“创造现在”，导演喊“cut”的瞬间，AI已根据新指令调整画面。

医疗领域：哈佛医学院的EVE模型预测出3200多个疾病相关基因中的3600万个致病突变，将基因诊断从“大海捞针”变为“精准打击”。DeepMind的Enformer神经网络一次编码超20万个碱基对，让基因表达预测准确率飙升。

这些案例揭示一个真相：AI的真实效能不在于参数规模，而在于能否解决具体场景的“真实痛点”。当行业从“技术炫技”转向“场景深耕”，产品经理的价值被彻底放大——他们既是技术价值的“翻译官”，也是商业闭环的“设计者”。

二、产品经理的“泼天富贵”：50万岗位缺口与百万年薪

“现在入行AI产品经理，就像2010年做移动互联网产品。”这句话正在成为现实：
薪资暴涨：初级AI产品经理年薪25-40万，专家级年薪百万已成常态。某二本机械专业学员通过4个月系统学习，成功转型AI医疗产品经理，薪资翻3倍。

需求井喷：2025年全球AI大模型市场规模突破5000亿美元，中国核心企业超300家，AI产品经理岗位缺口达50万。阿里、腾讯等大厂明确要求产品经理“必须具备大模型落地经验”。

跨界红利：文科生、非科班背景正成为AI产品经理的主力军。某日语专业硕士通过强化数据分析能力，成功转型AI产品经理，年薪超40万；翻译专业出身的点点用低代码平台开发AI智能体，年入百万。

这场风口的核心逻辑是：AI技术普惠化后，企业需要大量“懂业务、会翻译、能闭环”的产品经理，将技术能力转化为商业价值。正如阿里B-OS的逻辑：算力、模型、连接管道都由平台提供，产品经理只需定义“当A发生时，参考B规则，执行C动作”——这直接将AI创业门槛从“算法科学家”拉低到“资深业务专家”。

三、破局关键：从“PRD写手”到“价值定义者”

当AI能自动生成PRD、分析用户反馈、甚至写竞品报告时，产品经理的核心价值在哪里？答案藏在三个真实案例中：
客服系统的情感革命：某团队用AI优化客服系统，上线后用户投诉激增。原因很简单：AI能正确回答问题，却无法处理“我等了三天”的情绪。后来加入“情绪识别+人性化话术”模块，用户满意度提升23%。

物流延误的“上帝视角”：传统AI只能回答“物流受天气影响”，而业务专家会调用CRM数据发现客户是VIP，协调杭州仓补发顺丰空运，并在钉钉同步处理进度——这需要AI理解“业务流”而非“关键词”。

二手车估值的“数据炼金术”：大搜车的AI估值模型融合车况、区域行情、历史成交等268维因子，将经验判断转化为数据标签。这背后是产品经理对“非标品标准化”的深度理解。
这些案例揭示AI时代产品经理的三大核心能力：
业务洞察力：比AI更懂“上下文图谱”，知道“这个客户昨天在钉钉里特批了什么折扣”。
场景定义力：将技术能力转化为具体功能，如用RAG系统让大模型精准输出行业知识。
闭环设计力：从“提示词工程”到“Agent编排”，确保AI输出能反哺业务系统。

四、未来已来：2026年的三大生存法则

别被“千亿参数”迷惑：企业更关注推理成本，参数量超500亿的项目落地率不足20%。掌握模型量化压缩技术（如AWQ），用4bit量化实现80%精度保留，才是硬通货。
数据质量大于数量：某电商评论分析项目因爬虫数据含敏感信息被下架，血泪教训证明：构建数据清洗SOP（去重→脱敏→质量评分）比盲目收集数据更重要。
懂部署者得天下：阿里P7级产品岗需掌握vLLM部署与负载测试，能用Docker快速搭建本地测试环境。技术大厂要求产品经理“像系统设计师一样思考”，构建能随时间产生复利价值的系统。

结语：站在风口的“价值放大器”

当OpenAI与马斯克为“非营利初心”对簿公堂时，真正的AI革命正在产业深处发生：它不追求“无人驾驶”的乌托邦，而是用AI重构二手车检测、客服对话、视频生成等具体场景；它不制造“算法霸权”，而是让文科生、传统行业从业者通过“业务理解+AI工具”实现价值跃迁。
对于产品经理而言，这是最好的时代——AI放大了他们的效率、洞察力与商业敏感度；这也是最坏的时代——那些只会写PRD、做竞品分析的“执行者”，终将被AI取代。但有一点毋庸置疑：当技术成为基础设施时，定义价值的人，永远站在风口之上。

在日常开发工作中，我们经常会遇到需要自动化处理文档的场景，尤其是PowerPoint演示文稿。无论是批量生成报告、根据数据动态创建演示文稿，还是对现有PPT进行内容调整，手动操作都显得效率低下且容易出错。如何利用Java的强大能力，实现对PowerPoint幻灯片的添加、隐藏和删除，从而极大地提高工作效率，成为了许多开发者关注的焦点。本文将深入探讨这一需求，并提供一套高效实用的解决方案。

库介绍与环境配置：Spire.Presentation for Java

要实现Java对PowerPoint幻灯片的自动化操作，我们需要借助一个功能强大的第三方库。Spire.Presentation for Java 正是这样一个专门为Java应用程序设计，用于创建、读取、编辑、转换和打印PowerPoint文件的API。它支持多种PPT格式，并提供了丰富的接口，让开发者能够轻松控制幻灯片的各个方面，包括文本、图片、表格、图表以及幻灯片本身的操作。

Maven依赖配置：

<repositories>
    <repository>
        <id>com.e-iceblue</id>
        <name>e-iceblue</name>
        <url>https://repo.e-iceblue.cn/repository/maven-public/</url>
    </repository>
</repositories>
<dependencies>
    <dependency>
        <groupId>e-iceblue</groupId>
        <artifactId>spire.presentation</artifactId>
        <version>11.1.1</version>
    </dependency>
</dependencies>

环境配置说明：

在开始编程之前，请确保您的开发环境已正确配置。这包括安装Java Development Kit (JDK) 1.8或更高版本，并配置好Maven或Gradle构建工具。此外，推荐使用IntelliJ IDEA或Eclipse等IDE，它们能提供更好的代码提示和调试体验。

Java 在 PowerPoint 中添加幻灯片

添加幻灯片是构建演示文稿的基础。Spire.Presentation for Java 允许我们创建全新的PPT文件，并在其中添加各种类型的幻灯片，甚至可以向幻灯片中添加内容。

代码示例：

Java

import com.spire.presentation.*;

public class Slides {
    public static void main(String[] args) throws Exception {

        //创建一个 PowerPoint 文档并加载示例文档

        Presentation presentation = new Presentation();
        presentation.loadFromFile("/Sample.pptx");

        //在文档末尾添加新幻灯
        presentation.getSlides().append();

        //在第二页插入空白幻灯片
        presentation.getSlides().insert(1);

       //保存文档
        presentation.saveToFile("output/AddSlide.pptx", FileFormat.PPTX_2010);
    }

}

代码解析：

1. new Presentation()：创建一个空的PowerPoint演示文稿对象。
2. presentation.getSlides().append()：在PowerPoint文件的末尾添加一个新的空白幻灯片。
3. presentation.getSlides().insert(1)：在指定位置添加一张新的幻灯片，这里是添加为第二张。
4. presentation.saveToFile(...)：将修改后的演示文稿保存到指定路径和格式。

Java 在 PowerPoint 中隐藏指定幻灯片

有时我们需要在不删除幻灯片的前提下，使其在演示模式下不可见。Spire.Presentation 提供了简便的方法来实现这一功能。

代码示例：

import com.spire.presentation.*;

public class Slides {
    public static void main(String[] args) throws Exception {

        //创建一个 PowerPoint 文档并加载示例文档
        Presentation presentation = new Presentation();
        presentation.loadFromFile("/Sample.pptx");

        //隐藏第二张幻灯片
        presentation.getSlides().get(1).setHidden(true);

        //保存文档
        presentation.saveToFile("output/Hideslide.pptx", FileFormat.PPTX_2010);
    }

}

代码解析：

1. presentation.loadFromFile(...)：加载一个已存在的PowerPoint文件。
2. presentation.getSlides().get(1).setHidden(true)：通过索引获取需要操作的幻灯片对象。然后将setHidden的参数设置为true使该幻灯片隐藏。
3. presentation.saveToFile(...)：保存修改后的演示文稿。

Java 删除 PowerPoint 中指定幻灯片

当某些幻灯片不再需要时，我们可以将其从演示文稿中彻底移除。Spire.Presentation for Java 同样提供了直接的方法来删除幻灯片。

代码示例：

import com.spire.presentation.*;

public class Slides {
    public static void main(String[] args) throws Exception {

        //创建一个 PowerPoint 文档并加载示例文档
        Presentation presentation = new Presentation();
        presentation.loadFromFile("/Sample.pptx");

        //删除第二张幻灯片
        presentation.getSlides().removeAt(1);

        //保存文档
        presentation.saveToFile("output/Removeslide.pptx", FileFormat.PPTX_2010);
    }

}

代码解析：

1. presentation.loadFromFile(...)：加载一个已存在的PowerPoint文件。
2. presentation.getSlides().removeAt(1)：这是删除幻灯片的关键API。它会从幻灯片集合中移除指定索引的幻灯片，此处删除了第二张幻灯片。
   注意事项： 删除幻灯片后，后续幻灯片的索引会自动更新。例如，如果删除了索引为1的幻灯片，原来索引为2的幻灯片将变为索引1。在进行批量删除操作时，应特别注意这一变化，通常建议从后往前删除，或者每次删除后重新获取幻灯片集合的大小和索引。
3. presentation.saveToFile(...)：保存修改后的演示文稿。

总结

本文详细介绍了如何使用 Spire.Presentation for Java 库在Java应用程序中实现PowerPoint幻灯片的添加、隐藏和删除操作。通过这些实用的代码示例，我们展示了如何创建新的演示文稿、向其中添加自定义内容的幻灯片，以及如何根据需求灵活地隐藏或移除现有幻灯片。掌握这些技能，将极大地提升您在自动化办公、数据报告生成和演示文稿管理方面的效率。Spire.Presentation 的强大功能远不止于此，它在自动化文档处理领域拥有广阔的应用前景，期待各位开发者能利用它创造更多有价值的解决方案。

前言

在做图片相关功能时，有一个需求几乎绕不开：
用户拖动参数，图片实时变化。

比如：

• 调整模糊强度
• 改变对比度、饱和度
• 预览滤镜效果，再决定是否应用

在 UIKit 时代，我们可能会用 UIImageView + CoreImage + GCD 硬撸。
但到了 SwiftUI，很多人第一反应是：

SwiftUI + CoreImage + 实时预览，这事靠谱吗？

答案是：靠谱，但得用对方式。

这篇文章就从一个最小可用 Demo开始，一步一步把实时滤镜预览这件事讲清楚。

先说结论：实时预览的关键点是什么？

在 SwiftUI 里做 CoreImage 实时预览，核心其实只有三点：

1. 图片渲染要尽量轻
2. 滤镜计算不能阻塞主线程
3. UI 状态变化要最小化

如果你一上来就把所有滤镜计算都丢进 body，
那基本等于在和 SwiftUI 的刷新机制正面硬刚。

一个最基础的目标效果

我们先定一个目标：

• 显示一张原图
• 拖动 Slider
• 实时调整高斯模糊强度
• 图片随着 Slider 连续变化

这是绝大多数滤镜编辑页的基础形态。

Step 1：准备 CoreImage 的基础组件

先把 CoreImage 的几个核心对象准备好：

import SwiftUI
import CoreImage
import CoreImage.CIFilterBuiltins

let context = CIContext()
let filter = CIFilter.gaussianBlur()

这里有两个细节值得注意：

• CIContext 应该尽量复用
• 不要在 body 里反复 new CIContext

CIContext 本身是重量级对象，频繁创建会直接拖垮性能。

Step 2：一个最简单的 SwiftUI 结构

我们先搭一个最基础的页面结构：

struct ContentView: View {
    @State private var intensity: Double = 0.5
    let image = UIImage(named: "example")!

    var body: some View {
        VStack {
            Image(uiImage: image)
                .resizable()
                .scaledToFit()

            Slider(value: $intensity)
                .padding()
        }
    }
}

到这一步，UI 是没问题的，但还没有任何滤镜逻辑。

Step 3：把 CoreImage 滤镜接进来

关键思路是：
不要直接操作 UIImage，而是用 CIImage 作为中间态。

我们先写一个专门负责“生成滤镜图片”的方法：

func applyProcessing() -> UIImage {
    let beginImage = CIImage(image: image)
    filter.inputImage = beginImage
    filter.radius = Float(intensity * 20)

    guard let outputImage = filter.outputImage else {
        return image
    }

    if let cgimg = context.createCGImage(outputImage, from: beginImage!.extent) {
        return UIImage(cgImage: cgimg)
    }

    return image
}

这段代码做了几件事：

1. 把 UIImage 转成 CIImage
2. 设置滤镜参数
3. 通过 CIContext 渲染成 CGImage
4. 再转回 UIImage

Step 4：把实时预览“接”到 SwiftUI 状态上

接下来是最关键的一步：
让 SwiftUI 在 Slider 变化时刷新图片，但不炸性能。

先引入一个新的状态：

@State private var processedImage: UIImage?

然后改造 body：

var body: some View {
    VStack {
        Image(uiImage: processedImage ?? image)
            .resizable()
            .scaledToFit()

        Slider(value: $intensity)
            .padding()
            .onChange(of: intensity) { _ in
                processedImage = applyProcessing()
            }
    }
}

此时你已经可以看到：

• Slider 一动
• 图片跟着变
• 滤镜是实时的

但——
这还不是一个“能上线”的写法。

性能问题从哪开始暴露？

当你快速拖动 Slider 时，会发现：

• UI 有轻微卡顿
• 真机上比模拟器更明显
• 图片越大，问题越严重

原因也很直接：

滤镜计算跑在主线程。

Slider 的 onChange 本身就在主线程，
CoreImage 渲染又是 CPU / GPU 混合操作，
自然会影响 UI 响应。

Step 5：把滤镜计算移出主线程

一个简单、有效的方式是：
用 Task + MainActor 控制线程切换。

改造 onChange：

.onChange(of: intensity) { _ in
    Task.detached {
        let output = applyProcessing()
        await MainActor.run {
            processedImage = output
        }
    }
}

这样做之后：

• 滤镜计算在后台执行
• UI 只负责展示结果
• 拖动 Slider 明显顺滑很多

这一步，是“能不能实时预览”的分水岭。

再往前一步：为什么 SwiftUI 特别适合做这件事？

如果你用 UIKit 做过类似功能，会发现：

• 手动管理线程
• 手动刷新 ImageView
• 状态和 UI 同步很痛苦

而 SwiftUI 的优势在于：

• 状态驱动 UI
• 图片只是状态的一个映射
• 滤镜逻辑和 UI 逻辑可以完全解耦

你只需要保证一件事：

状态更新是轻的，计算是异步的。

一点真实项目里的经验总结

在真实项目中，我一般会遵守这几个原则：

1. Slider 变化频繁时，必要时做节流
2. 滤镜链尽量复用，不要每次 new
3. 大图先 downscale 再做预览
4. 最终导出时再跑一次“高质量渲染”

实时预览追求的是“看起来对”，
而不是“每一帧都是最终质量”。

总结

SwiftUI 并不是不适合做图像处理，
而是不能用同步思维去写异步计算。

一旦你把：

• CoreImage 的计算
• SwiftUI 的状态刷新
• 主线程和后台线程的职责

这三件事理顺了，
实时滤镜预览这件事，其实比 UIKit 时代要轻松得多。

汽车供应链作为制造业中最复杂的网络之一，正面临着前所未有的挑战。全球化的供应链布局、多级供应商体系、频繁的需求波动以及外部环境的不确定性，使得传统管理方式显得力不从心。近年来，随着人工智能技术的成熟，"工业超级智能体"逐渐成为解决这些痛点的关键工具。它不仅仅是技术的堆砌，更是一种全新的供应链管理范式，通过数据驱动和智能决策，实现供应链的全链路协同与自主优化。
一、供应链的复杂挑战与智能体的必要性
汽车供应链的复杂性远超一般人的想象。一辆汽车包含上万个零部件，涉及数百家直接供应商和数千家间接供应商，任何环节的延迟或异常都可能导致整个生产线的停滞。例如，2021年的芯片短缺就让全球汽车产量减少了超过1000万辆。与此同时，市场需求的个性化趋势日益明显，消费者对配置、颜色和功能的定制化需求使得排产计划变得极其复杂。再加上疫情、地缘政治等外部风险的频繁冲击，传统基于经验和局部优化的管理方法已经难以应对。
工业超级智能体的价值正是在这种背景下凸显出来。它不同于传统的ERP或SCM系统，后者更多是流程的电子化记录工具，而智能体则具备主动感知、分析和决策的能力。通过接入物联网设备、ERP系统、物流平台等多源数据，智能体能够实时监控供应链状态，预测潜在风险，并自动生成应对方案。举个例子，当某个供应商的原材料质量出现波动时，智能体不仅能立即预警，还能通过历史数据和替代方案库，在几分钟内推荐最优的供应商切换策略，甚至自动触发订单调整流程。这种能力使得供应链从"被动响应"转向"主动防控"，大幅提升了整体韧性。
二、智能体技术的核心架构与运作机制
工业超级智能体的落地离不开一套成熟的技术架构。以Geega供应链智能体为例，其系统分为三层：数据感知层、智能决策层和执行协同层。数据感知层通过物联网设备和系统接口，实时采集供应商产能、物流状态、库存水平等300余类数据；智能决策层则融合了机器学习算法和行业知识图谱，能够进行需求预测、风险评级和方案模拟；执行协同层通过与ERP、WMS等系统的集成，将决策转化为实际操作指令。
这套架构的独特之处在于其"感知-决策-执行"的闭环能力。例如，当预测到未来两周某车型需求将上升20%时，智能体会自动模拟三种供应方案：增加现有供应商订单、启用备用供应商或调整生产节奏。它会综合考虑成本、交货期和风险系数，选择最优方案并自动下发执行指令。整个过程无需人工干预，但却能保持95%以上的决策准确率。更值得一提的是，智能体具备持续学习能力。每次决策执行后，它会对比实际结果与预测结果，自动优化算法模型。这种自我迭代的机制使得系统越用越智能，逐步降低对人工经验的依赖。
三、从理论到实践：行业案例深度解析
广域铭岛在其打造的供应链智能体中，实现了对500余家核心供应商的实时监控。系统通过智能算法，将供应商的交货准时率从82%提升至96%，同时将库存周转天数减少了18天。
特斯拉通过其自主研发的供应链智能体，实现了电池原材料采购的精准预测，将采购周期从60天压缩至35天
某国外汽车集团则通过智能体系统，将全球工厂的设备备件库存降低了30%，同时保证了99.5%的供应及时率。这些案例共同证明，工业超级智能体正在重塑汽车供应链的运作模式，使其变得更加敏捷、高效和抗风险。

在上篇文章，我们学会了现代 CSS 颜色的基础用法。

本篇我们进入更高级的领域：如何像设计师一样操纵颜色。

CSS 现在能做的事情，甚至比设计软件还要强大！

1. 操纵颜色

1.1. 基础回顾

先复习一下上篇文章的内容：

:root {
  --primary: #ff0000;
}

.primary-bg-50-opacity {
  /* h s l 不是字母，是变量！ */
  background: hsl(from var(--primary) h s l / 0.5);
}

注意： h s l 这三个字母其实是变量，分别存储了色相（hue）、饱和度（saturation）、亮度（lightness）的值。

我们可以替换这些变量，比如给绿色（#00ff00）加点蓝：

/* 基础绿色没有蓝色成分 */
.green-with-a-touch-of-blue {
  /* 在蓝色通道加 25 */
  color: rgb(from #00ff00 r g calc(b + 25));
}

这就像调色板，在基础的绿色中，添加点“蓝色颜料”。

1.2. 实用技巧

掌握了基础用法，我们就可以讲些实际开发中会用到的场景了。

1. 创建互补色（色轮对面的颜色）：

:root {
  --color-primary: #2563eb; /* 蓝色 */

  /* 色相加 180 度，跳到对面 */
  --color-secondary: hsl(from var(--color-primary) calc(h + 180) s l);
}

2. 创建三色组合：

:root {
  --color-primary: #2563eb;

  /* 色轮上均匀分布 120 度 */
  --color-secondary: hsl(from var(--color-primary) calc(h + 120) s l);
  --color-tertiary: hsl(from var(--color-primary) calc(h - 120) s l);
}

就像时钟：12 点是主色，4 点和 8 点是配色，完美对称！

使用效果如下：

<!-- 这是一张图片，ocr 内容为：CHANGE THE PRIMARY COLOR: -->

3. 相对调整

:root {
  --color-primary-base: #2563eb;

  /* 比基础色亮 25% */
  --color-primary-lighter: hsl(from var(--color-primary-base) h s calc(l + 25));

  /* 比基础色暗 25% */
  --color-primary-darker: hsl(from var(--color-primary-base) h s calc(l - 25));
}

使用这种方法，不管基础色是多亮，都会相对地变亮或变暗。

这就像调空调，“比现在低 5 度”比“设定到 20 度”更灵活。

使用效果如下：

<!-- 这是一张图片，ocr 内容为：CHANGE THE PRIMARY COLOR: -->

2. 暗黑模式的层次感

现在我们能相对调整颜色了，可是究竟有什么用呢？

让我给你举个具体的使用场景。

在浅色主题中，我们可以根据阴影来区分层次：

<!-- 这是一张图片，ocr 内容为：LEVEL 1 LEVEL 2 LEVEL 3 -->

但在深色背景下，阴影的效果并不明显。

因此在深色主题中，我们希望每个层次的颜色略微变浅。

借助上篇讲过的 light-dark()和相对颜色调整，我们便可以实现：

:root {
  --surface-base-light: hsl(240 67% 97%);
  --surface-base-dark: hsl(252 21% 9%);
}

/* 第一层：基础层 */
.surface-1 {
  background: light-dark(var(--surface-base-light), var(--surface-base-dark));
}

/* 第二层：稍微亮一点 */
.surface-2 {
  background: light-dark(var(--surface-base-light), hsl(from var(--surface-base-dark) h s calc(l + 4)));
}

/* 第三层：再亮一点 */
.surface-3 {
  background: light-dark(var(--surface-base-light), hsl(from var(--surface-base-dark) h s calc(l + 8)));
}

想象一下深海：越接近水面，光线越充足。暗色模式的层次就是这个原理。

使用效果如下：

<!-- 这是一张图片，ocr 内容为：LEVEL 1 LEVEL 1 LEVEL 2 LEVEL 2 LEVEL LEVEL 3 -->

3. 完整配色方案

设计师创建配色方案时，不只是简单地调整亮度，还会同时微调色相和饱和度，比如

• 变亮时：饱和度增加，色相向冷色调偏移
• 变暗时：饱和度降低

这便可以通过 CSS 来实现：

:root {
  --primary-base: hsl(221 83% 50%);

  /* 400: 亮度60%，色相-3度，饱和度+5% */
  --primary-400: hsl(from var(--primary-base) calc(h - 3) calc(s + 5) 60%);

  /* 300: 亮度70%，色相-6度，饱和度+10% */
  --primary-300: hsl(from var(--primary-base) calc(h - 6) calc(s + 10) 70%);

  /* 以此类推... */
}

为什么要这么麻烦呢？

因为只调亮度会让浅色看起来“失去活力”。

就像拍照：自动模式能拍，但手动调整曝光、对比度、色温会更漂亮。

为了让你更直观地看到变化：

<!-- 这是一张图片，ocr 内容为：PRIMARY COLOR SCALE SYSTEMS PERCEPTUAL SCALE(ADJUSTS HUE & SATURATION) 200 700 900 600 1000 100 400 800 500 300 FLAT SCALE(ONLY LIGHTNESS CHANGES) 600 500 400 300 100 700 1000 900 800 200 -->

第一排是都调整的版本，第二排是未调整色相和饱和度的版本。

最明显的区别在于 100、200 和 300 这几个色块，当仅调整亮度值时，颜色看起来失去了一些鲜艳度。

4. OKLCH 更科学的配色方式

4.1. 问题：HSL

HSL 虽然很棒，但在使用时，你会发现一些问题，让我们看个例子：

.green-bg {
  /* 饱和度 100%，亮度 50% */
  background: hsl(100 100% 50%);
  color: white;
}

.blue-bg {
  /* 同样饱和度 100%，亮度 50% */
  background: hsl(220 100% 50%);
  color: white;
}

你会发现，色和蓝色的饱和度、亮度虽然完全一样，但视觉效果完全不同：

<!-- 这是一张图片，ocr 内容为：BLUE GREEN -->

明显蓝色背景上的文字清晰易读，对比度超过 5，而绿色背景上的文字却很难看清，对比度仅略高于 1。

之所以会这样，是因为 HSL 的“亮度”不符合人眼感知。

人眼对绿色比蓝色更敏感，所以同样的“50%亮度”，绿色看起来更亮。

4.2. 解决：OKLCH

而这就是 oklch() 的优势。

OKLCH 是基于感知亮度设计的：

.consistent-green {
  background: oklch(0.54 0.23 261);
}

.consistent-blue {
  background: oklch(0.54 0.23 146);
}

使用效果如下：

<!-- 这是一张图片，ocr 内容为：BLUE GREEN -->

现在不管什么颜色，亮度值相同，人眼看起来的亮度就相同！

4.3. 讲解：OKLCH 的三个参数

在 LCH 颜色模型中：

第一个值是亮度（Lightness），取值范围为 0 到 1。它的计算方式与 HSL 略有不同，因为它基于感知亮度，但概念相同，即 0 是黑色，1 是白色。

第二个值是色度（Chroma），类似于饱和度，0 是灰色，越大越鲜艳，但最大值不固定，取决于亮度和色相（这是 OKLCH 最麻烦的地方）

第三个值是色相（Hue），和 HSL 一样是色轮，0 到 360 度，区别是 0 度是洋红色（HSL 里 0 度是红色）

OKLCH 的尴尬之处就在于色度（Chroma）的最大值会变：

/* 某些色相+亮度组合，0.4 已经是极限 */
.max-chroma-1 {
  background: oklch(0.6 0.4 120);
}

/* 但另一些组合，0.4 可能太高或太低 */
.max-chroma-2 {
  background: oklch(0.8 0.4 200); /* 可能超出范围 */
}

就像不同口味的饮料，有的最浓是“3 勺糖”，有的最浓是“5 勺糖”，没有统一标准。

4.4. 实用技巧：结合相对颜色

虽然直接写 OKLCH 值很麻烦，但我们可以用 HSL 定义基础色，然后用 OKLCH 保持一致性：

.toast {
  --base-color: hsl(225, 87%, 56%); /* 用熟悉的 HSL 定义 */
}

[data-toast="info"] {
  /* 只改变色相，保持亮度和色度 */
  --toast-color: oklch(from var(--base-color) l c 275);
}

[data-toast="warning"] {
  --toast-color: oklch(from var(--base-color) l c 80);
}

[data-toast="error"] {
  --toast-color: oklch(from var(--base-color) l c 35);
}

使用效果如下：

<!-- 这是一张图片，ocr 内容为：USING OKLCH SOME GENERAL INFO TOAST THIS MIGHT END BADLY OH NO, SOMETHING HAS GONE WRONG! USING HSL SOME GENERAL INFO TOAST THIS MIGHT END BADLY OH NO,SOMETHING HAS GONE WRONG! -->

这样做的好处在于：不同颜色的提示框，边框对比度、整体饱和度感觉都很一致。

5. 混合颜色

有的时候，我们可能需要混合两种颜色：

.purple {
  /* 红色和蓝色各占 50% */
  color: color-mix(in srgb, red, blue);
}

就像调颜料：红色颜料加蓝色颜料，得到紫色。

目前必须定义一个颜色空间，所以必须写 in srgb 或 in oklab 等，未来会默认用 oklab。

不同颜色空间混出来的结果不一样：

<!-- 这是一张图片，ocr 内容为：SRGB OKLCH OKLAB XYZ XYZ -->

一般推荐：

1. 先试 oklab
2. 再试 oklch
3. 不满意就换其他的

5.1. 控制混合比例

默认情况下，使用该功能时 color-mix()，每种颜色将使用 50% 的强度。

当然，我们也可以控制特定颜色的具体强度。

/* 90% 红色 + 10% 蓝色 */
.red-with-a-touch-of-blue {
  background: color-mix(in oklab, red 90%, blue);
}

/* 或者反过来写 */
.or-like-this {
  background: color-mix(in oklab, red, blue 10%);
}

5.2. 创建半透明色

有两种方法可以获得透明的值：

方法一：让总量小于 100%

/* 60% + 20% = 80%，所以透明度是 80% */
.semi-opaque {
  background: color-mix(in oklab, red 60%, blue 20%);
}

方法二：混入 transparent

/* 30% 的不透明红色 */
.thirty-percent-opacity-red {
  background: color-mix(in oklch, red 30%, transparent);
}

不过如果只是想降低透明度，还是用相对颜色更直接：

.better-way {
  background: rgb(from red r g b / 0.3);
}

5.3. 小技巧：分段渐变

/* 不用手动算中间的每个颜色，color-mix 帮你搞定 */
.banded-gradient {
  background: linear-gradient(to right, red, color-mix(in oklch, red 75%, blue), color-mix(in oklch, red 50%, blue), color-mix(in oklch, red 25%, blue), blue);
}

使用效果如下：

<!-- 这是一张图片，ocr 内容为： -->

6. 未来更简单

重复写这些代码很烦？

CSS 自定义函数快来了：

/* 定义函数 */
@function --lower-opacity(--color, --opacity) {
  result: oklch(from var(--color) l c h / var(--opacity));
}

/* 使用函数 */
.lower-opacity-primary {
  background: --lower-opacity(var(--primary), 0.5);
}

或者定义整套色阶函数：

@function --shade-100(--color) returns <color> {
  result: hsl(from var(--color) calc(h - 12) calc(s + 15) 95%);
}

@function --shade-200(--color) returns <color> {
  result: hsl(from var(--color) calc(h - 10) calc(s + 12) 85%);
}
/* 以此类推... */

.call-to-action {
  background: --shade-200(var(--accent));
}

.hero {
  background: --shade-800(var(--primary));
  color: --shade-100(var(--primary));
}

一次定义，到处使用，完美！

7. 总结

最后总结下本篇文章的重点：

1. 用 calc() 操纵颜色 - 数学生成配色方案
2. OKLCH - 基于人眼感知的颜色系统，不同色相亮度一致
3. color-mix() - 像调颜料一样混合颜色

在实际使用时：

• 简单需求：相对颜色 + HSL
• 需要视觉一致性：OKLCH
• 需要混合颜色：color-mix()
• 暗黑模式层次：light-dark() + 相对颜色

本篇整理自《A pragmatic guide to modern CSS colours - part two》，希望能帮助到你。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。

在工程项目的复杂运作中，高效的工程协同对于确保各方顺畅合作、项目顺利推进至关重要。筑业软件的工程协同功能，以其独特的资料共享模式，为项目团队搭建了便捷的协作桥梁。
云端资料便捷分享
筑业软件赋予资料员强大的资料分享能力。资料员可将存储于云端丰富的工程资料，通过简单操作，依据接收方的账号或手机号进行分享。例如，在项目施工过程中，资料员整理好最新的施工进度资料，只需在软件界面选择分享功能，输入相关人员的手机号或账号，即可快速完成分享，确保资料及时传递给需要的团队成员。
即时查看与编辑
接收方一旦收到分享通知，登录云资料软件，就能立即查看与编辑接收到的工程资料。这种即时性极大地提升了工作效率，避免因等待资料传递或格式转换等问题造成的时间浪费。比如，项目技术负责人收到资料员分享的工程变更资料后，可即刻登录软件查看详细内容，并根据实际情况进行编辑批注，提出专业意见，为后续施工决策提供支持。
保障协作流畅性
该功能确保了项目团队成员之间资料的实时同步与更新，使得各方始终基于最新信息开展工作。无论是在施工现场的一线人员，还是位于办公室的管理层，都能通过云资料软件获取一致的资料，有效避免因信息不一致导致的误解和错误。例如，在多部门协作完成一项复杂工程任务时，各部门成员可随时查看和编辑共享资料，实时沟通协作，确保任务顺利推进，各个环节紧密衔接。
筑业软件的工程协同功能，通过云端资料分享、即时查看编辑、保障协作流畅以及灵活权限设置等特性，为工程项目各方提供了高效、便捷且安全的协作环境，有力推动项目的顺利实施与成功交付。

随着数字化发展的深入，合同作为一个重要的应用基础，也是第一时间进行数字化的转型，电子合同逐步替代了传统纸质合同。但是电子合同的厂商市场上却有很多，那这些厂商生成的电子合同是不是都是安全有保障的呢？今天我们便简单剖析一下各个厂商。

首先，我们要先明确一点的便是，国内并没有一个官方、绝对的“安全性排名”，因为不同厂商的安全架构、合规侧重和客户群体有所不同。但是，我们可以通过一套核心的安全评估框架，对国内主流的电子合同厂商进行对比分析，帮助判断哪家更符合您的安全要求。

1. 核心安全评估框架

1) 合规性与认证（基础门槛）

Ø 等保三级：国内非银行机构最高备案认证，必备项。

Ø 商用密码产品认证：使用国密算法对数据进行加密的合规证明，必备项。

Ø ISO系列：27001（信息安全管理）、27701（隐私保护）、22301（业务连续性）等，国际通用标准。

Ø 行业特定合规：如公安行业的电子签章标准、医疗行业的HIPAA/GDPR（如涉及出海业务）等。

2) 技术安全性

Ø 加密技术：是否全链路采用SSL/TLS、数据存储加密、关键信息是否使用硬件加密机（HSM） 进行私钥保护。国密算法支持是重要加分项。

Ø 数据隔离与主权：是否为大型客户提供数据隔离部署（公有云、混合云、私有云），数据能否明确存储在国内。

Ø 安全运维与审计：是否有完善的内部安全管控、渗透测试、灾备体系。

3) 司法实践与证据效力

Ø 是否与公证处直连，形成在线争议解决闭环。

Ø 是否有大量的法院判例支持，其证据链是否被司法机构普遍采信。

Ø 是否提供从合同起草、签署到存证、出证的一站式服务。

2. 主流厂商安全性特点分析（按综合安全能力排序参考）

基于以上框架，以下是国内市场主流厂商的特点分析：

第一梯队：综合安全能力最强，服务大型企业及政府机构

1. 北京安证通信息科技股份有限公司

优势：

Ø 历史积淀与技术创新：拥有二十年电子签名领域经验，技术架构历经多次迭代，形成高稳定性、高扩展性的产品体系。

Ø ·大型企业服务经验：服务超过300家央企、国企及中国500强企业，包括中石油、中建五局等，积累大量复杂业务场景解决方案。

Ø ·全栈安全能力：从身份认证、电子签名到合同存证，构建多层次安全防护体系，通过等保三级认证，符合金融、政务等高安全要求场景。

Ø ·定制化服务能力：针对大型企业复杂业务流程，提供从咨询、实施到运维的全流程定制化服务，确保系统深度贴合业务需求。

安全侧重点：

在政府、集团企业、住建行业、工程建设行业等领域安全口碑突出，尤其注重行业合规与隐私保护等。

2. 法大大

优势：

市场覆盖极广，生态集成度高。合规资质齐全（等保三级、密评、ISO系列等）。与腾讯云深度合作，背靠其安全能力。司法衔接广泛，已对接多家法院和仲裁委。

安全侧重点：

在各类行业均有大量标杆案例，安全体系经过海量业务验证，平衡了安全性与产品易用性。

3. e签宝

优势：

行业头部厂商，阿里系投资，在政务和大企业市场占有率很高。拥有全链条的电子签名服务，从CA机构到签署平台。在政务领域的合规经验非常丰富。

安全侧重点：

特别符合国内政务和大型国企的安全与合规要求，对国内标准理解深刻。

第二梯队：在特定领域或场景有安全优势

1. 腾讯电子签

优势：

背靠腾讯的安全能力和C端生态（微信），在个人与小B场景的便捷性和安全结合得很好。内生于腾讯云的安全体系，合规资质齐全。

安全侧重点：

依托腾讯整体安全防护，在防攻击、数据安全方面有天然优势。适合已使用腾讯生态的企业。

2. 字节跳动电子签（飞书合同）

优势：

深度集成于飞书，主打内部管理和供应链协同场景。享有字节跳动的安全技术底座，在用户体验和内部风控流程结合上做得较好。

安全侧重点：

更适合飞书生态内的企业，实现办公、签约、数据的一体化安全管理。

3. 契约锁

优势：

专注于电子印章的统一管理，常与OA、ERP系统集成，提供一体化印控方案。支持混合部署，满足集团型客户对物理印章和电子印章的统一管控需求。

安全侧重点：

印控安全和一体化管理，适合对内部用印流程风控要求极高的中大型组织。

技术架构的核心突破
工业智造超级智能体正在彻底改变汽车制造业的数字化转型路径。与传统的自动化系统不同，这种智能体采用了一种全新的架构设计——它不仅仅是简单的机器替代人力，而是构建了一个能够自主感知、分析和决策的智能生态系统。这个系统的核心在于将物联网、人工智能和大数据技术深度融合，形成一个能够自我学习和持续优化的智能网络。
在汽车制造领域，这种技术架构表现得尤为突出。以Geega平台为例，其架构设计专门针对汽车制造的特殊需求，包含了三个关键层次：实时数据感知层、智能决策层和自主执行层。数据感知层通过部署数以万计的传感器，实时采集生产线、设备状态、物料流动等全方位数据；智能决策层则运用机器学习算法对这些数据进行分析，生成最优的生产调度方案；自主执行层则将决策转化为具体的生产指令，实现从冲压、焊装、涂装到总装的全流程智能化控制。
这种架构设计使得汽车制造企业能够实现从被动响应到主动预测的根本转变。比如在焊装车间，系统能够实时监测焊接机器人的工作状态，预测可能出现的设备故障，提前安排维护计划，避免生产线停摆。这种预见性维护能力，正是传统制造系统所欠缺的。
实施过程中的关键考量
汽车制造工厂的数字化转型绝非易事，它需要一个系统性的实施路径。首先面临的挑战是数据基础的构建。汽车制造涉及上百个工序、数千个零部件，数据采集的复杂程度远超一般制造业。
接下来是算法模型的训练和优化阶段。这个阶段往往需要3-6个月的时间，期间需要工程师与产线人员密切配合，不断调整和优化模型参数。值得注意的是，每个汽车工厂的生产线布局、设备型号都有差异，这就需要智能体系统具备很强的自适应能力。某新能源汽车工厂在实施过程中就遇到了这样的问题——原有的质量检测算法在新产线上准确率只有85%，经过两个月的持续迭代才提升到99%以上。
最后是实现全价值链协同的阶段。智能体不仅要优化单个车间的生产效率，更要实现跨车间、跨工厂的协同运作。例如，当总装车间出现生产延误时，系统能够自动调整焊装和涂装车间的生产节奏，同时协调供应商调整零部件配送计划。这种全链路的协同能力，正是数字化转型带来的最大价值。
实践案例与成效分析
在具体实践方面，广域铭岛为某知名汽车集团打造的数字化转型方案取得了显著成效。该企业通过部署生产优化智能体，实现了焊装生产线效率提升38%，质量缺陷率降低65%。更令人印象深刻的是，系统能够实时预测设备故障，提前12-24小时发出预警，使非计划停机时间减少了85%。这些改进直接带来了每年数亿元的成本节约。
另一个典型案例来自某新能源汽车电池工厂。通过引入质量检测智能体，将电池检测准确率提升至99.8%，同时检测效率提高了6倍。这套系统不仅能够识别表面缺陷，还能通过分析生产过程中的数百个参数数据，预测潜在的质量风险。在实际运行中，系统成功预警了多次批量性质量事故，避免了数千万元的损失。
吉利汽车集团的数字化转型案例同样值得关注。通过构建智能供应链系统，实现了从订单到交付的全流程数字化管理。客户下单后，系统能够自动生成生产方案，实时调度生产线资源，将定制车型的交付周期从4周缩短到2周。这种柔性制造能力使得企业能够快速响应市场需求变化，在激烈的市场竞争中占据优势。
这些案例表明，工业智造超级智能体正在成为汽车制造业数字化转型的关键驱动力。它不仅提升了生产效率和产品质量，更重要的是改变了汽车制造企业的运营模式和价值创造方式。随着技术的不断成熟，预计未来三年内，采用智能体技术的汽车制造企业将获得25-35%的综合效益提升，这将成为决定企业竞争力的重要因素。

1月13日，Zoho宣布在迪拜、阿布扎比投建的两座数据中心正式投入运营。这是继2024年沙特利雅得、吉达数据中心落地后，Zoho在中东的又一重要基建动作。至此，Zoho在中东地区自建的数据中心已达四座，将用来全面提升对当地客户的服务响应效率与数据安全保障能力。

两座数据中心目前已获得迪拜电子安全中心 (DESC)颁发的CSP安全标准认证，并且符合 ISO 27001、ISO 22301、ISO 27017和CSA STAR二级数据中心认证标准。这意味着，Zoho有资格为当地政府、机构、企业及出海中东的海外企业提供安全可靠的数字化服务。

Zoho联合创始人沙伊莱什•戴维说到：「阿联酋是Zoho在中东的核心战略市场，目前已投资8000万迪拉姆(约合人民币1.52亿)，两座数据中心的启用是我们持续投资中东市场战略的重要一步，更好地帮助企业实现本地数据存储，增强数据主权，并支持国家网络安全议程。」

过去五年，Zoho在中东市场的发展势头持续攀升，成功从早期的市场探索者蜕变为中东企业数字化转型的关键伙伴。仅在2025年，Zoho在阿联酋的业务就增长了38.7%，合作伙伴网络扩大了29%，本地员工人数增加了35%，助力7000多家企业实现数字化转型升级。