-
技术解读：鸿蒙系统深色模式功能详解与开发适配指南
深色模式是一种满足用户个性化需求的界面显示模式，它基于人因研究设计了深色环境下舒适的颜色范围。当深色模式开启后，原本浅色主题的应用界面背景会变为深色，而文字、图标等前景元素则变为浅色。
-
从标准解读到场景落地:美创Q3数据安全热点干货合集
2026 年夏秋之交，数据安全行业迎来密集新规落地。与此同时，AI 智能体数据安全引发行业关注与热议。美创科技精选近三个月 10 篇热点主题干货，涵盖 AI 安全前沿、新规落地、行业实践等主题，一文回顾数据安全进阶之路。标准引领美创参编｜GA/T 2390-2026《信息安全技术 数据脱敏产品安全技术要求》正式实施2026 年 7 月 1 日，公安行业标准GA/T 2390-2026《信息安全技术
-
做好数据语义层的关键是什么？
导语：数据语义层正在成为企业数据栈中的热门话题。它试图在物理数据与业务理解之间架起一座桥梁。但要做好它，远不止是选一个工具那么简单。本文从概念出发，梳理做好数据语义层需要关注的核心问题。 什么是数据语义层？ 在讨论“怎么做”之前，先要厘清“是什么”。 数据语义层（Data Semantic Layer）通常指位于物理数据存储与上层消费应用之间的一层抽象。它的核心目标，是把数据库中晦涩的表名、字段名和复杂的关联关系，翻译成业务人员能够理解的指标、维度和实体。 换句话说，它让“营收”“活跃用户”“转化率”这些业务概念，有了统一、可复用的技术定义，而不必让每个分析师或每张报表都各自写一遍 SQL。 关键一：统一的指标与业务定义 数据语义层最直接的价值，是消除“同名不同义”和“同义不同名”的混乱。 同一个“活跃用户”，
-
AI 赋能数据治理，提升治理自动化水平
数据治理长期面临“规则多、人力少、响应慢”的结构性矛盾。随着大模型与机器学习能力逐步嵌入数据平台，治理工作正在从“人工巡检 + 事后补救”转向“智能识别 + 自动处置”。本文围绕 AI 赋能数据治理的路径与自动化提升方向展开讨论。 一、为什么数据治理需要 AI 数据治理的核心目标，是让数据“找得到、看得懂、信得过、用得好”。但在实际落地中，团队普遍会遇到几类难题： 元数据规模庞大：表、字段、指标、标签数量随业务扩张快速增长，人工维护成本高。 规则难以穷举：数据质量规则、脱敏规则、权限规则往往依赖专家经验，难以覆盖全部场景。 问题发现滞后：传统方式多为定时巡检或人工反馈，异常往往在业务受影响后才被察觉。 责任边界模糊：数据血缘、归属、变更影响难以快速定位，跨团队协作效率低。 AI 的价值在于：把大量依赖人工判断的
-
数据血缘在数据治理中的应用与价值
当企业的数据链路从几张报表扩展到数百个任务、数千张表、跨多个计算引擎时，"这张表的数据从哪来、到哪去、中间经过了哪些加工"会迅速成为数据团队最常被问到、也最难回答的问题。数据血缘（Data Lineage）正是为回答这类问题而生的能力。它记录数据在系统间的流转路径与加工关系，是数据治理体系中连接元数据、质量、安全与成本的枢纽环节。 一、什么是数据血缘 数据血缘描述的是数据资产之间的依赖关系，通常包含两个方向： 上游血缘（溯源）：某张表、某个指标或某份报表的数据，来源于哪些原始表、哪些任务、哪些字段。 下游血缘（影响）：某张源表或某个字段发生变化后，会影响到哪些下游表、任务、指标和报表。 从粒度上看，血缘通常分为几个层次： 表级血缘：表与表之间的依赖关系，最容易实现，也最常用于任务调度与影响分析。 字段级血缘：字
-
主数据管理：打通多系统数据孤岛
企业在数字化进程中往往会不断引入新的业务系统：ERP、CRM、MES、WMS、OA、数据仓库……系统越多，数据越分散，同一个客户、同一件物料、同一个供应商在不同系统里可能有着不同的编码、名称和属性。这种"数据孤岛"不仅让跨部门协作变得困难，也让数据分析和智能决策失去可信基础。主数据管理（Master Data Management，MDM）正是为解决这一问题而生的方法论与技术体系。 一、什么是数据孤岛 数据孤岛指的是数据被分散存储在相互隔离的系统中，缺乏统一的定义、标准和流转机制，导致： 同一实体多种表述：同一个客户在 CRM 里叫"某某科技有限公司"，在 ERP 里叫"某某科技"，在财务系统里又是另一个编码。 数据无法对齐：跨系统的报表口径不一致，汇总时需要对账、清洗，耗时且易错。 重复录入与冲突：各系统各自
-
数据治理落地难点：如何避免“纸上治理”
数据治理几乎成了企业数字化转型的“标配项目”，但真正落地见效的却不多。制度上墙、流程上会、平台上线，最后数据质量依旧堪忧——这就是典型的“纸上治理”。本文尝试从落地难点出发，梳理避免治理空转的关键思路。 一、什么是“纸上治理” “纸上治理”并不是指完全没有做数据治理，而是指治理动作停留在文档、会议和汇报层面，没有真正嵌入到日常的数据生产与消费流程中。常见表现包括： 制度、规范、标准文档齐全，但一线团队并不知晓或并不执行； 数据治理平台上线后，元数据、血缘、质量规则长期无人维护； 数据质量问题反复出现，却始终停留在“通报—整改—再通报”的循环； 治理指标好看，但业务侧对数据可信度的体感没有改善。 这些现象背后，往往不是工具能力不足，而是治理没有和业务、组织、流程真正咬合。 二、落地难的几个核心症结 依据行业普遍观
-
数据底座：从“成本中心”到“生产力引擎”的范式转移
过去十年，企业谈数字化转型，谈的是“上云”；未来十年，企业谈数字化深耕，谈的将是“数据底座”。当大模型与AI应用从演示走向生产，数据底座不再是后台的“仓库管理员”，而是决定企业智能化上限的“中央厨房”。本文尝试从技术演进与产业实践的交叉视角，给出三个判断。 重新定义数据底座：它不是数据库，而是“数据操作系统” 很长一段时间里，行业对“数据底座”的理解是模糊的。有人把它等同于数据仓库，有人把它看作数据中台换了个说法，还有人把它简化为“一堆数据库的集合”。这些理解在各自的历史阶段都有合理性，但放在今天，已经明显不够用了。 依据现有素材判断，我们倾向于给出这样一个定义：数据底座是企业范围内、支撑所有数据消费场景的底层能力集合，它至少包含四个层次——存储与计算引擎、数据治理与语义层、数据开发与调度体系、以及面向AI的数
-
SAP Joule Studio 如何靠五大能力支持企业治理？
Joule Studio 提供的五大企业级 AI 治理能力（身份及访问控制、发布前测试与验证、性能持续评估、行为可视化监控、托管运行时与合规），解决企业在 AI 智能体上线后的安全、合规、可控焦虑。
-
数据治理陷入反复反弹，企业到底该如何根治？
不少企业投入大量人力、物力开展数据治理，但始终陷入“治理-反弹-再治理”的恶性循环：业务填报不规范、核心数据不统一、流转数据易出错、分析数据不可信。究其根本，是治理思路出现偏差，多数企业只聚焦末端数据清洗，忽略了源头管控的核心作用，缺乏一套覆盖全链路、可落地、可闭环的标准化质量防护体系。想要彻底根治企业数据乱象，必须打破单一末端治理的局限，搭建源端前置防错、末端闭环提质的四重质量防护体系，从数据产
-
AI原生的MDM平台到底有多强大？对话即操作，业务人员终于能自己管数据了
传统主数据管理平台给用户的印象，往往是一排排菜单、层层嵌套的表单、需要专门培训才能掌握的配置界面。业务人员想维护一条供应商数据，得先找到对应菜单，进入表单，逐字段填写，再提交审批。这套逻辑延续了二十多年，直到AI原生MDM的出现才开始松动。以中翰软件推出的AI原生MDM平台为例，它做了一件看起来简单但底层逻辑完全不同的事：把对话框变成了主要入口。用户登录后几乎看不到传统软件界面，无论是新增数据、变
-
数据质量管控：脏数据识别与闭环治理
数据质量是数据平台、数据分析和 AI 应用的地基。地基不稳，上层的报表、模型和决策都会失真。本文围绕“脏数据识别”与“闭环治理”两个核心环节，梳理一套可落地的思路框架。需要说明的是，本文不涉及具体产品版本、性能数据或案例引用，属于方法论层面的整理。 一、为什么脏数据必须被“治理”而不只是“发现” 很多团队对数据质量的理解停留在“监控告警”层面：发现异常、发个通知、人工修一修。但脏数据的问题往往不是单点故障，而是系统性、反复性的： 同一类空值、重复、格式错误，今天修完明天又来； 上游业务系统变更，下游数据链路被动“中毒”； 问题发现靠人肉排查，定位慢、责任边界模糊。 因此，真正有效的做法是把数据质量当成一个闭环系统：识别 → 定位 → 修复 → 预防 → 再验证。只做“识别”不做“闭环”，数据质量永远在原地打转。
-
元数据与数据地图：赋能数据治理可视化
当数据规模从 GB 走向 PB，从单库走向湖仓一体、多云与混合云，企业面对的核心难题往往不再是"有没有数据"，而是"数据在哪里、是什么意思、能不能信、该找谁"。元数据与数据地图，正是回答这些问题的关键基础设施。本文围绕元数据与数据地图的关系、能力构成与落地路径展开讨论，帮助读者建立数据治理可视化的整体认知。 一、为什么数据治理需要"看得见" 数据治理的常见困境，可以概括为三类： 找不到：业务人员想用某个指标，却不知道它落在哪张表、哪个主题域、哪个系统。 看不懂：字段名是 amt_01、flag_x，缺少业务含义、口径说明与责任人信息。 不敢用：不清楚数据来源、更新频率、血缘链路和质量状况，无法判断能否作为决策依据。 这些问题的共同根源，是数据的"描述信息"没有被系统化管理。而描述数据的数据，就是元数据。把元数据
-
数据治理不是「上工具」，而是组织的一场管理变革
很多企业把数据治理等同于采购一套平台、部署一套系统，结果工具上线了，数据质量依旧、口径依旧、扯皮依旧。问题往往不在技术，而在组织。数据治理的本质，是一场关于权责、流程与协作方式的管理变革。 一、一个常见的误区：把治理当成采购项目 在不少企业里，数据治理的启动方式高度相似：业务部门抱怨报表对不上，管理层要求"把数据管起来"，于是 IT 牵头调研厂商、比选平台、走采购流程。几个月后，一套数据治理平台上线，元数据管理、数据标准、数据质量、数据血缘等功能一应俱全。 然后呢？ 数据标准文档躺在知识库里，没人认领； 数据质量问题被记录，但没人负责整改； 指标口径在会议上反复争论，最后仍各说各话； 平台逐渐沦为"看板展示工具"，而非治理抓手。 这不是工具的问题，而是把一件管理问题当成了技术问题来处理。 二、为什么数据治理本质
-
企业做好数据治理为什么这么难？
导语：数据治理几乎成了每一家数字化企业的“必修课”，但真正把这件事做成的企业并不多。本文尝试从组织、业务、技术、成本等多个角度，拆解数据治理难做的深层原因，并给出一些可落地的思考方向。 一、先厘清：数据治理到底在治理什么 在讨论“为什么难”之前，有必要先明确数据治理的边界。数据治理并不是简单地“把数据洗干净”，它通常涉及： 数据标准 ：统一指标口径、命名规范、编码规则； 数据质量 ：准确性、完整性、一致性、及时性； 数据安全与合规 ：权限、脱敏、审计、隐私保护； 数据资产 ：元数据、数据血缘、数据目录； 组织与流程 ：谁负责、谁使用、谁维护。 也就是说，数据治理本质上是一项 横跨业务、技术、组织的系统性工程 ，而不是一个可以一次性交付的项目。这决定了它的难度天然高于一般的 IT 建设。 二、难点一：它本质上是“
-
跳出内卷！中翰软件新战略：用数据+知识双治理，搭起企业AI落地桥梁
AI浪潮席卷各行各业的当下，多数企业的智能化转型都陷入了同一个困境：跟风上线大模型、智能系统，看似布局前沿，实则底层数据杂乱、知识零散，最终AI沦为“空有外壳的摆设”。简单来说，很多企业不是缺AI工具，而是缺能支撑AI高效运转的优质“原料”。在一众扎堆做AI应用、卷场景落地的厂商中，老牌数据治理企业中翰软件近期交出了一份差异化答卷。品牌正式完成战略重新定位，提出以数据+知识双治理架构为核心，聚焦搭
-
网络安全风险排查：漏洞扫描和渗透测试的区别与适用场景
一、什么是漏洞扫描、什么是渗透测试漏洞扫描与渗透测试，是企业信息系统风险排查里两类互补的安全检测手段，很多企业会组合使用。漏洞扫描，以自动化工具为主，批量探测服务器、网站、APP、接口等资产，识别已知安全漏洞、弱口令、配置错误、过期组件等问题，快速梳理资产的基础风险清单。优势是覆盖范围广、周期短，适合常态化巡检。但自动化扫描容易产生误报，也很难发现业务逻辑层面的深层隐患。渗透测试，是在企业书面授权
-
业务梳理这件事，正在从专家项目变成日常流水线
在传统数据治理项目中，业务梳理往往是最耗时也最依赖专家的环节。请咨询团队、组织访谈、梳理指标口径、绘制关系图，一套流程走下来，周期以月计。更麻烦的是，项目结束后成果多以文档沉淀，下一次遇到类似业务域，几乎需要重新来过。中翰软件是数据质量和知识专家，这家成立于2006年的老牌数据治理厂商近日推出中翰业务智能盘点平台v2.0，试图将业务梳理从“专家项目”转变为“日常流水线”。该平台定位为“让业务人员自
-
数据标注治理：众包、专家与自动标注质量
在大模型与各类 AI 系统落地的过程中，数据标注往往被视为“脏活累活”，但它直接决定了模型能力的上限。标注质量治理的核心问题并不只是“标得准不准”，而是如何在成本、速度、一致性、可追溯性之间取得平衡。当前主流路径有三条：众包标注、专家标注、自动标注。三者并非互相替代，而是越来越多地被组合进同一套数据生产流水线。本文围绕这三种模式的治理要点展开讨论。 一、为什么标注治理是系统工程 标注质量问题的根源通常不在标注员个人，而在流程设计。常见失效模式包括： 标准漂移：同一概念在不同批次、不同标注员之间理解不一致。 激励错位：按件计酬鼓励速度，牺牲边界样本的准确性。 反馈缺失：标注结果没有回流机制，错误无法被系统性纠正。 责任模糊：出现质量问题时，无法定位到具体环节与责任人。 因此，标注治理应被理解为一条包含规范制定、任
-
数据是 Agent 进入企业业务流程的最重要前提
过去一年，Agent 几乎成了企业软件领域出现频率最高的词。从客服自动应答、销售线索跟进，到财务对账、供应链异常处理，几乎所有厂商都在讲同一个故事：让 Agent 接管流程，让人类只做决策。但真正进入企业核心业务流程的 Agent 项目，落地比例远没有演示视频里那么乐观。依据现有素材判断，制约 Agent 从“能演示”走向“能上岗”的最大瓶颈，不是模型能力，而是数据。 Agent 的能力上限，由它能看到的数据决定 1.1 模型决定“会不会”，数据决定“准不准” 大模型解决的是通用推理与语言理解问题，它让 Agent 具备了理解指令、拆解任务、调用工具的基础能力。但企业业务流程里的每一个动作，都依赖具体、实时、可追溯的业务数据：这张订单当前处于什么状态、这个客户的历史履约记录如何、这笔款项对应哪份合同、这个物料在
