第三部分 — 信任层的九项原则

原则八 — 吸收，而非重建

每个工程团队迟早都会面对那个诱人的问题：这个组件已经存在，而且免费，但自己造一个只要一个月，还能恰好合乎我们的需要。在临床软件领域——如今开放生态已经覆盖了巨大的疆域：表格引擎、分析函数、清单、合成数据、目录——这个问题每周都会来敲门。

原则是：默认吸收；把每一次重建都当作一个必须书面自证合理的决定。 不是因为开源神圣不可侵犯，而是因为战略问题从来不是"我们造不造得出来"，而是"我们稀缺的差异化，是来自这里吗？"

信任产品的自建-外购地图

在临床报告技术栈中间画一条线。线以下是计算：表格排版引擎、标准分析、图形内核、ADaM 推导机器、合成数据生成器。线以上是证据：重放、独立比对、溯源图、验证包、门禁，以及问责本身的交付。

线以下的一切，正在被资金充裕的开源项目商品化，而且只会越来越商品化。线以上的一切，对组件生态来说是结构性 缺乏吸引力的——因为它不光鲜、在大会上不好演示，而且只有作为一个整体才有价值。这种不对称是一份礼物。它在说：把你个位数的工程产能全部花在线以上，线以下的一切，买—— 吸收——就好。

这种失效模式有它的签名。一个团队开始自研表格引擎，"只做基础的"。十八个月后，这个表格引擎有了脚注、分页、三种输出格式和一座边界情况的神龛，而信任层仍然不存在——但那个消费了开放引擎、建起了信任层的竞争对手，已经坐进了采购谈判的会议室。这个团队输，不是因为造得差，而是因为造错了层。

吸收也有自己的纪律

吸收不等于导入加祈祷。开放组件进入信任产品，走的是一套制度，而不是一辆购物车：

锁定一切。 版本是锁死的——按提交、按锁文件、按哈希。一个漂浮在"最新版"上的信任系统，等于把自己的行为外包给了陌生人的发布经理。
过自己的门禁做确认。 被吸收的引擎赢得位置的方式，与自研代码相同：经过比对机器、对着锁定的参照运行、结果记录在案。没有确认的吸收，只是换一种方式引入风险。
在契约边界处封装。 引擎坐在你的版本化契约之后，这样当更好的引擎出现——或者现在这个死掉——的那一天，替换只是稳定接口之后的一次交换，而不是一次重写。
记录溯源。 代码从哪里来、哪个版本、核验了什么：作为条目，写进与其他一切相同的图里。

什么时候重建是对的

有时答案确实是"自建"——当这项能力本身就是差异化 (一个具有单元格级三态语义的比对器，没有开放等价物), 当被吸收组件的失效模式无法被确认到可信，或者当在一个错配抽象之上糊一层薄壳的成本高过一次聚焦的重建。这条原则不禁止自建。它禁止的是反射性地自建——并且要求把每一个这样的决定写成架构记录，这样十八个月后，团队还记得线当初为什么画在那里，从而能刻意地移动它，而不是意外地移动它。

检验。 列出你系统的组件。对每一个发问："我们的差异化住在这里，还是住在我们包在它外面的东西里？" 如果你发现差异化正被花在线以下——花在某个免费包早已附带的能力上——那你正在用自己最稀缺的资源，补贴商品化的那一层。