数据进入系统之前，先进入同一种语言

一张床，要怎样才能变成一个可以相加的数字？

美国政府问责局在 2021 年 8 月发布的审计中，记下了一个看似细小的问题。美国卫生与公众服务部（HHS）的数据平台 HHS Protect 于 2020 年 4 月实施时，部分受访方认为缺少清楚的数据字典：重症监护床位怎样算，婴儿床位是否计入，各方存在疑问。HHS 后来发布说明，并通过网络会议澄清定义。¹ 数据能够被送到一起，含义却还需要人一起弄明白。

这里不宜把报送困难全部归咎于软件，更不能凭审计记录认定某个 FDE 团队犯了什么错。它揭示的是一个比产品品牌更基础的工程问题：一列名称相同的数字，是否在回答同一个问题？若这一点没有建立，汇总越快，误解也可能传播得越快。

本章沿一条明确标为教学的数据记录前进：甲院报来一个数字，18。甲院、数值以及下面的转换过程都是教学构造，不是 HHS Protect 的内部实现。我们暂不讨论医疗决策，只问一名工程师如何让这个数字成为别人能够正确理解和使用的信息。

18，首先是谁的 18

假设一份表写着“甲院”，另一份写着“甲院东区”。先把两张表接通，再按照名称相似程度合并，可能使同一家机构被算两次，也可能把不同院区挤成一个。名称看起来很清楚，却未必适合承担身份判断。

这时需要一个稳定的编号，以及说明不同系统编号如何对应的记录。编号不是给事物起一个更难读的名字，而是避免名称变化时失去同一对象。医院更名以后，历史记录仍可关联；同一个名称在不同地区出现时，也不必误认为同一家机构。

HHS Protect 的一份隐私影响评估在 2022 年 2 月 9 日签署。文件说明，平台为具体实体分配唯一标识，以帮助去重和数据管理。² 这是一项系统设计说明，不等于所有对象都已经匹配无误。编号解决的是“以后怎样稳定指向它”，最初的对应关系仍须有依据。

在教学系统里，FDE 可以请数据负责人确认甲院编号与院区的关系，再让程序按已确认的对应取数。若某条记录无法确定归属，先标为待核比自动塞进最相近的名称更有解释力。待核也有成本：数字暂时不完整，业务人员需要处理例外。但把不确定性藏进一个看似完整的总数，会把核查成本推给更远的使用者。

对象还可能随时间变化。两个院区合并，或者一个院区拆为独立机构，旧编号对应的范围便不能无声改写。如果今天的报表要与去年比较，就要知道当时统计的边界。并非每个项目都需要一套庞大的主数据系统；即使只维护一张对应表，也应说清楚何时生效、由谁确认，以及旧记录怎样解释。

做到这一步，我们知道了 18 属于谁。但仍不知道它是什么意思。

即使对象确认无误，连接也可能把数复制。教学系统里，甲院有两位联系人；若把数量表与联系人表接在一起，18 可能各出现在两行。随后直接求和便得到 36。联系人没有重复，原上报也没有错误，错误发生在两张表所描述的粒度不同：一张每个机构一条，一张每位联系人一条。工程师需要先明确结果的一行应代表什么，再决定哪些信息可以一起计算。

把它摊开看，只需要几行教学数据。

修复不能只在最终表里写“36除以2”。下一家机构也许有三位联系人，另一家没有联系人；也不能把所有相同数字删掉，因为两家机构都上报18完全可能成立。应当固定“机构、观察时间、指标定义”这一统计单位，再在该单位内选择已确认的报告版本。联系人是一组附加关系，不是多出来的容量。

同一个名称，可能有几种正确含义

“床位数”可以用来描述房间里的物理设施，也可以描述符合某种条件、实际能够使用的容量。教学系统如果把两者都叫作“可用”，就可能让填报者各自作出合理判断，却使接收者得到不能比较的数据。

因此，下一步不是把所有字段翻译成统一英文，而是把计算对象讲清楚。18 统计哪些类别，排除哪些情况，表示当下状态还是一段时期内的变化？哪些信息缺失时不能给数？这些定义最好连着具体例子讨论。两方都同意一句抽象说明，不代表遇到边缘情况时还会作出相同判断。

一个办法是挑几条足以区分定义的记录，请业务人员分别判断是否计入。在教学情境中，一条暂时不能使用的床位记录，可能比十条普通记录更快暴露分歧。工程师负责把分歧准确呈现；怎样界定相关业务容量，必须由有资格作出该判断的人确认。

这就是数据字典的实际用途。它不只是解释“这一列是整数”，还需要帮助别人知道整数指什么。一个可用的定义，可以连接字段名称、适用范围、计算办法、例外和解释责任人。没有必要一开始收齐全公司的所有字段；先把当前工作真正依赖的定义建立起来，再随着使用扩展。

然而，共同语言也不意味着所有地方必须使用同一种细度。做总体分析的人可能只需要一个合计，安排具体工作的人需要知道分布和限制。前者的数字未必错误，只是不能直接回答后者的问题。强迫两者完全一致，可能让简单分析变得昂贵；完全不说明差别，又会诱使别人把合计当作可执行的信息。

这类差异需要“映射”，也就是说明一套定义如何对应另一套定义。医疗信息交换标准 HL7 FHIR 的 ConceptMap，明确把对应关系放在具体用途和方向中：从甲分类映到乙分类成立，不代表可以反过来；一种用途下的对应，也不能自动移到另一种用途。³ 本章借它说明方法，并不声称 HHS 使用了这项资源。

用普通语言说，几类细分对象可以合成一类，但合计不能自行拆回原来的几类。在教学系统中，若我们只收到总数 18，就不能让模型凭常识推算各院区分别有多少。需要更多原始资料，或者承认这个问题暂时无法回答。所谓数据理解，有时表现为知道哪些转换不应该发生。

空白也需要定义。如果另一家机构尚未上报，空格并不自动表示数量为零。把空格都改成零，可以让图表更整齐，却把“我们不知道”变成了“我们知道它没有”。若计算某项平均值，是否把这家机构放进分母，也会改变结果。团队应先保留未报告、确认为零和不适用这些状态，再决定当前用途怎样处理；转换过程不能为了让程序少遇到分支，就把不同含义提前抹平。

这会使初次交付看起来没有那么整洁：结果可能同时包含已知总数、覆盖范围和待核情况。但这些信息使使用者能够判断结果是否足够。发现缺口后，可以补取资料，也可以缩小本次回答的范围。两种选择都比把未知藏掉更容易维护，因为下次有人改进数据时，能够知道自己究竟补上了哪一部分。

数字后面还应有一只钟

现在给这条记录补上身份和定义，问题仍未结束：18 是什么时候的情况？

假设记录描述上午八点的状态，中午才被接收，下午又被重新计算。这里已经有三个时间：现实中被观察的时刻、系统得到它的时刻、处理结果生成的时刻。如果页面只显示最后一次刷新，使用者可能把“刚刚重算”看成“刚刚更新的现实”。

因此，刷新频繁不等于资料新鲜。一个每分钟重画的图，可以反复呈现同一份早晨记录。FDE 需要沿着数据走回起点，确认更新发生在哪里：原始记录是否改变，传送是否完成，转换是否重新运行，以及页面现在显示的是哪一版。每一步都正常，也可能因为源头尚未更新而得到旧答案。

这不是要求所有信息都实时传输。若工作是回顾上月变化，按月核实的数据可能足够；若使用者需要了解当前状况，同样的数据就可能不适合。时效要求应随决定来定。追求更快更新会增加连接、监控和核对成本，未必为每一种用途带来相同价值。

教学系统可以把结果写得更完整：甲院按某项定义上报的数量为 18，观察时刻是上午八点，接收时刻是中午十二点。这样做会让页面多出几个字，却给使用者一个重要判断条件。若超过业务约定的有效时间，可以提示需要重新确认，而不是让模型用流畅的语言掩盖资料已经变旧。

迟到的修正也需要位置。原始记录下午被纠正时，今天的报表应重新计算；但更正前曾经发布过什么，也可能仍需解释。可以把修正后的结果和当时发布的版本分别保存，并说明它们的关系。若只留下最后一个数字，团队便很难回答：当时作决定的人究竟看到了什么？

到这里，18 已经不再是孤零零的单元格。它有对象、定义和时间，才有可能被另一支团队正确使用。

从一张表，走到可以做事的对象

组织的软件通常不会只关心数字。它还需要把数字与相应的人、地点和行动联系起来。

Palantir 的入门文档用数据层和对象层说明这种区别：前者保存表格等数据及其转换关系，后者用对象、对象间的关系和可执行的行动表达业务。公司把这一组定义称为 Ontology，本书在这个产品语境里译为本体。⁴ 读者不必先记术语，可以先问：一张表中的甲院，怎样成为应用里可以理解和操作的甲院？

在教学系统中，一行可能保存院方编号、上报时间和一个数量。业务对象则把相关信息组织到同一个对象周围：它是哪家机构，属于哪个地区，谁解释它的上报，以及当前哪些记录需要复核。关联的意义，是让使用者不必每次自己找出几张表之间的对应关系。

“行动”则是允许对这个对象做什么。例如请求复核一条记录，需要指定哪条记录、为什么存疑、交给谁；记录得到更正后，要保留新旧关系。这只是教学系统的设计选择，不是上述平台在某家医院的已知配置。它说明，从看数据走向用数据，增加的不只是一个按钮，还有行动成立的条件。

因此，业务对象不是一个可以替代原始资料的漂亮外壳。如果甲院这一对象关联了错误院区，再友好的界面也只会让误操作更方便。对象定义要能回到原记录，相关的行动也应受明确规则约束。人的决定进入软件以后，别人应当能够看出究竟改了什么，而不是只看到一个新的状态。

针对同一项“汇总18并处理更正”的工作，可以比较两条路线。若每天只出一张报表，一张经确认的机构对应表、一张定义表与版本选择程序，就能保留18的身份和出处。新增院区时，维护对应表；定义变化时，更新规则并重算受影响日期。它的代价是，多个应用若各写一遍复核流程，容易逐渐不一致。

如果调度、复核和分析等多个应用都要使用同一机构，并共同执行“申请更正—确认—重算”，对象层才有较强理由。它把重复关系和动作集中维护，却也增加公共版本、权限和迁移工作：改一个对象可能影响所有应用。前一条路线可能在重复维护上变贵，后一条可能在尚无复用时建得过重。决定依据是实际出现的第二个使用处，而非架构图是否漂亮。这里没有要求所有FDE项目先建立本体。

能够连接，不表示每个人都能看见

到目前为止，我们一直在讨论如何让信息更容易使用。接下来必须补上另一个条件：谁可以为了什么工作使用它？

同一份 HHS Protect 隐私影响评估，把这件事分成行政判断与技术实现。文件说明，HHS 和数据来源方决定访问安排，系统可按项目、数据集乃至行列施加控制，对敏感信息只开放履职所需的范围。² 这些是管理方公开的设计安排，不能单凭文件存在就认定实际执行没有缺口。

在教学系统里，负责核对原始记录的人，可能需要看到更细的信息；只看地区总量的人，未必需要同样的明细。工程师不能因为资料已经连到同一平台，就自动把权限合并。原来隔在不同系统中的限制，仍可能对应真实的职责差别。

尤其要注意转换后的结果。把一张明细表汇总，可能减少细节，也可能通过小范围组合重新暴露敏感情况。哪种结果适合哪种角色，不能只看文件是不是“汇总表”。具体判断需要数据责任人参与，工程实现再把判断落到允许读取、允许变更和可审计的动作上。

当模型加入这条链路，问题不会因为输入是自然语言而消失。一个用户能向模型提出问题，不等于模型可以代表他读取所有底层资料。系统需要在实际取数时按授权判断，并使后续显示和保存的内容遵守相应边界。否则，原本藏在复杂查询步骤后的信息，可能被一句简单提问带出来。

这里也要区分“没有”和“你目前不能看”。把权限拒绝转换成空值，可能使模型误以为某项记录不存在；把没有记录说成权限限制，又会妨碍排查。程序可以保留不同的返回状态，向使用者给出与其权限相符的解释，并将必要的诊断信息交给有权限处理的人。

权限设计会影响体验，也会影响工作能否继续。若一个问题需要更高权限，应说明合法的接续路径，而不是在界面上留下一个毫无解释的空白。接续可以是请适当人员核实，或改用适合当前目的的汇总；不一定是扩大所有人的访问范围。清楚的边界，使团队有机会改进流程而不混淆职责。

结果错了，能不能沿路找回去

终于，18进入了一个地区汇总。稍后，有人发现总数不对。

如果系统只保存最终结果，排查要重新猜一遍：原始上报错了，对象对应错了，字段转换错了，还是用了不同日期的记录？几种错误最后都表现为一个不可信的数字，修复办法却完全不同。让模型再解释一次，并不会补回已经丢失的过程。

W3C 在 2013 年发布的 PROV-DM 推荐标准，提供了记录来源关系的通用方法：哪些信息经过什么活动形成，又有哪些责任主体参与。⁵ 它不是一张“数据正确”的证书，而是一种帮助人追查信息怎样产生的表达方式。记录来源，可以缩小疑问；不能免除对源头和处理过程的判断。

回到教学系统，数据契约可以理解为发送方与接收方约定的“这一行到底算什么”。本例将它填成：机构A、08:00观察、12:00接收、定义D1、报告r1、值18；汇总只能使用一份有效版本，未报与零分开，联系人数量不得改变结果。数据负责人确认含义，工程人员执行检查，报表使用者看到观察时刻及覆盖范围。

随后又发生另一种更正：14:00，甲院确认同一08:00观察的r2替代r1，值改为16。修掉错误连接后得到的18并非永久正确，它需要随源头更正成为16。这里的r标记源报告，P标记对外发布，两者各有版本：

三条发布记录不能压成一个不停变化、看不见历史的单元格。另一家机构B仍未上报，所以P2应写“已报告1／2家、已知合计16”，不能假装覆盖完整。

从18到36再到更正值的数据契约提供原表、错误连接、修正汇总、版本与空值规则，以及空白契约。读者可以检查两个相互独立的问题：36来自连接错误，16来自源头后续更正。重算哪些报表、通知哪些使用者，要沿各自的输入版本查找，不能把这两次修改合写成“数据已清洗”。

有时错误甚至不在计算里。一条转换规则完全按说明执行，得到的数字仍不适合当前工作，因为使用目的已经变化。保留来源只回答“怎么算出来”，还要保留用途才能回答“为什么这样算”。这也是工程师与业务负责人需要共同维护定义的原因：程序不会从结果被打开的方式中自动知道组织已经换了问题。

记录也应便于别人理解。如果排查一条数字必须请最初作者在场读半天代码，追踪能力就仍然依附于个人。可以从当前最关键的结果开始，让接手者尝试说明它的来源、条件和限制；哪里说不清，就补哪里。详细程度应服务真实调查，不必把每一次微小动作都永久保存成无人使用的日志。

还有一种不同的代价：完整追踪本身可能扩大资料保存范围。原始信息、转换中间结果和访问记录并非都应该保存同样久，也不应给所有人看。保存期限和访问范围应由用途、相关要求与责任共同确定，工程方案再把它们落实为可以执行的安排。追查所需的资料保存下来，不意味着所有资料都要无限留存。

把共同语言留在日常工作里

一条数据走完这段路，FDE 得到的不是一份永远不会变的定义。

新业务出现，原来的对象可能不够用；旧系统调整，字段含义可能改变；负责人离开，过去默认的判断可能失去解释者。因此，数据治理若只在接入时发生一次，几个月后系统仍可能继续运行，却逐渐回答另一个问题。

Anthropic的数据团队在2026年6月回顾内部自助分析时，给出了一个具体教训。他们试过让模型从原始表格和历史查询自动归纳指标定义，结果看似合理，却不如由人维护的业务定义可靠。团队还报告，一套分析能力的离线准确率曾在约一个月内从约95%漂移到约65%；后来，他们把数据模型和相关使用说明放到一起维护，让一次定义变更同时触发文档更新。⁶ 这是内部经验，文章没有提供足够材料让外部逐题复算，也不能把这个下降幅度推广到其他企业。

它让本章的“共同语言”多了一个时间维度。昨天正确的定义，今天可能已经不适合；从过去的查询里找到一段成功代码，也未必知道当时为什么排除了某类记录。历史做法可以帮助提问，却不能自动获得继续适用的资格。

回到甲院18的例子：若统计口径从“可使用设施”变成“已有人员安排的可用容量”，即使表名、字段和查询都没有报错，旧说明也需要复核。维护者要同时知道谁改了定义、哪些结果依赖它，以及如何发现仍按旧意思回答的问题。否则，最初节省下来的取数时间，会在之后变成反复核对答案的时间。

更可持续的办法，是让重要变化有明确入口。在教学系统中，甲院新增一种报送类别时，先说明它如何对应现有定义；无法对应时保留待处理状态；确认新规则后再决定从何时适用、哪些旧结果需要重算。工程师不必亲自裁定所有业务含义，却要确保改变不会无声通过。

这种安排也可以很轻。小项目用一张维护中的定义表、少量检查和明确负责人，可能已经足够。随着对象、用户和行动增加，再把重复判断写入系统。关键是扩展有理由：新增结构要解决已经遇到的歧义，或者防止具体、可解释的错误，而不是因为一幅完整架构图看上去更像成熟企业。

数据质量原本就是专业数据团队的工作，很多项目由客户自己的数据工程师就能完成。FDE 的潜在作用不是取代这些人，而是围绕当前要交付的工作，把分散在接口、业务定义和使用权限之间的问题带到一起。若这些条件已经清楚，额外增加一层协调未必有价值。

反过来，当技术人员认为已经连通、业务人员认为数字仍不能用时，FDE 可以帮助双方指向同一条记录：哪里相同，哪里不同，差别会怎样改变工作，谁能作出决定。这种具体合作，才是“懂业务又懂技术”可以被检查的含义。

回到 18。它能够被运到一张表里，只说明传输完成；它拥有可解释的对象、含义、时间、来源和权限，才开始具备成为工作依据的条件。下一章讨论系统怎样持续运行，而这些条件会一直跟着它。若没有共同语言，工程师可能把每一步都运行正确，最后却认真地完成了另一件事。