测试启动前的数据治理闹剧及其化解之道

故事总是如出一辙：第一幕。数据架构被精心搭建起来。团队对生产数据进行建模，将其切分为业务领域，或汇聚到中心化结构中。他们为此预留预算，并指定负责人。但在所有这些规划中，测试数据从未作为一项独立诉求出现。它之所以不成议题，是因为它不属于任何人。

测试数据问题往往源于缺少责任归属，而非沟通不畅。

数据架构的盲区：测试数据没有明确的归属者。

一个分三个层级的结构化责任模型，通过在架构设计早期就将其纳入，可以化解这一困局。

第二幕。临近测试启动，测试数据却缺席了。数量上缺席，是因为现有数据集太少，无法产生逼真的负载；质量上缺席，是因为现有数据无法反映业务场景组合。IT部门指向熟悉需求的业务部门。业务部门指向运营系统的IT部门，或者干脆指向那位据说无所不知的架构师。项目管理层则盯着时间表，等待。

智能体原生架构：为什么自主智能体首先需要控制权

利用检索日志来优先处理数据质量问题

测试启动前的数据治理闹剧及其化解之道

面向AI智能体的数据架构是否需要联邦式知识层？

遗留系统渐进式现代化的架构方法

类型化领域锚定作为面向LLM的DSL的设计原则

知识图谱作为数据与AI之间的架构：超越Data Mesh

第三幕。表演式的相互指摘开始了，用项目行话来说就是“踢皮球”。状态报告里每周都出现“测试数据待澄清”这一行，而澄清本身却毫无进展。责任真空随着每一次并未发生的升级而愈发固化。

以上就是我们heise-Plus文章《测试启动前的数据治理闹剧及其化解之道》的试读部分。订阅heise-Plus即可阅读全文。

在一款应用中管理来自iCloud、Google、Outlook及其他服务的日程：我们在iPad上演示如何兼顾私人事务与工作职责。

借助Claude和Xcode，无需自己编写代码即可开发Mac应用。我们逐步演示如何将一个想法变成可运行的应用。

Melty承诺能将任意游戏组合在一起——多亏了AI。我们试用了它，看看结果如何，以及潜在的危险在哪里。

这部刚修复的科幻经典为传送技术提供了范本，展示了通讯器、相位枪，以及一位作为柯克舰长原型的莱斯利·尼尔森。

DNS服务器Technitium以功能丰富著称，但配置起来并不简单。我们演示安装与配置过程。

自LLM出现以来，提示注入便随之而来。软件工程师Viviana Sutedjo在采访中讲述了Google如何应对这一问题。