案子里连听证都排好了：技术团队在并购审查期要准备的六张清单
一、结果未定的窗口期，清单必须提前齐
据公开报道，监管机关在一场关于经营者集中简易案件审查制度成效的发布会上披露了一起平台领域股权收购案的审查细节，该案被描述为这一领域首起未达申报标准但依法被要求申报的集中案件，多家同业企业参加了听证，后续审查将依法推进。案件本身的事实与结果不由本文判断，参与各方的经营行为也不在本文评价范围。要看的是这件事对技术团队的那一层含义：一旦进入这种“计划已定但结果未定”的窗口，工程侧的处境会变得很别扭——既不能抢跑整合，否则把未定的事情做成了既成事实；又必须在任何一次被要求说明时，立刻交得出整合所需的底账。这六张清单临时补一定补不出来，因为里面的多数条目只能靠平时的记录，事后回溯既不可信也来不及。要先把话说清楚：下面全是技术与交付侧的准备方法，不构成任何法律意见，具体行为边界应由法务和外部顾问判定，技术侧的责任是把家底整理成可交接的形态。
二、第一张与第二张：资产权限清单、数据边界清单
第一张是资产与权限清单。它回答的问题是“什么东西归谁管、谁能改”。逐项列域名与子域名及其注册主体与托管方、云上资源按账号与项目的归属、证书与其私钥存放位置、密钥与令牌按用途分列、服务账号与机器人账号（这类最容易漏，它们往往挂在某个离职同事名下的项目里）、第三方软件服务的席位与合同主体、以及每一项的变更批准人。每张条目要有归属主体和批准人两列，缺一项就等到交割时重新问一遍，而那时候问不到人。
第二张是数据边界清单。要写的不是“有什么数据”这种目录，而是能判定边界的字段：数据类别与分级、是否含个人信息及其处理依据的登记位置、存储地域与跨境流向、留存与删除策略、两边系统之间是否存在直接数据通路（这条最关键：库对库的直连、共享的数据仓库、彼此可查的埋点、共用的日志项目，都属于通路）、打通是在什么时候因为什么原因建立的。这一张在窗口期会被反复问到，而“我们从来没有直连过”这种口头结论没有任何价值，必须是能出示的记录。
三、第三张与第四张：共用依赖清单、在途承诺清单
第三张是共用依赖清单。共同的中间件与基础镜像、共享库及其版本、共用的监控与告警通道、共用的日志采集管道、共用的模型端点与密钥、共用的构建与制品仓库、共用的消息主题与回调地址。这一张的难点不在列出名字，而在每项后面加两列：交割后由谁保留、谁拆出，以及拆出的技术代价与前置条件。很多共用项看着小，实际是双方的发布流程绑在一起，拆它要重排发布节奏；这类事情如果被留到交割后再讨论，会变成双方都不肯动的僵局。
第四张是在途项目与承诺清单：已签但未交付的合同及其里程碑、对外承诺过的能力与时间点、已公开的路线图与产品说明、正在排期但尚未公告的功能。这张清单的用途很具体：窗口期内哪些事项不宜继续推进、哪些只能按原样交付不得扩展范围，需要一份有边界的判断输入。工程团队不能凭感觉决定“这个先缓缓”，也不能一边收到暂缓判断一边照原计划推。每条在途项要有状态、外部承诺对象与推进结论三列，结论由决策层给，技术侧负责如实维护状态与影响。
四、第五张与第六张：组织知识清单、技术约束清单
第五张是组织与知识清单，也是最容易在交割当天崩掉的一张。内容是：关键系统的单点人物（只有他能改的那类模块）、没有文档但所有人都照做的内部约定、只有一个人看懂的运维脚本与定时任务、口头传承的应急操作、散在个人电脑里的配置与证书备份。交接验收方式不能是“给他一份文档”，而应该是可验证的三件事：对方能独立完成一次部署、独立完成一次故障演练、能说出该系统的已知限制。做不到就继续算单点，别写成已交接。
第六张是技术约束清单，写的是窗口期内要避免的“提前打通”动作。常见的红线项包括：不做跨系统的账号互通与统一登录、不合并用户数据与标签体系、不新建实时经营数据的共享接口、不把对方的数据接入自家的模型训练与推荐链路、不在共享基础设施上扩大对方的可见范围。这些动作在工程上都非常自然，恰恰因此必须显式列出并规定由谁把关。落地方式是把它接入架构评审：评审模板里加一栏“本方案是否涉及跨主体打通”，涉及即转专门评审，由指定角色签字。谁把关、写在哪份文档里，这两项不落实，清单就只是一页纸。
五、为什么补不出来，以及台账怎么维持
| 清单 | 为什么事后补不出来 | 最小维护动作 |
|---|---|---|
| 资产与权限 | 密钥轮换有窗口期，临时轮换会打断线上服务 | 每次新增资产即登记归属与批准人 |
| 数据边界 | 历史数据的流向无法回溯取证，只能凭日志 | 每季度核对一次跨境与直连项 |
| 共用依赖 | 版本与镜像的对应关系随构建漂移 | 构建流水线自动输出版本快照 |
| 在途承诺 | 合同授权条款需要重新审阅，不是工程能补的 | 每次对外承诺变更同步进表 |
| 组织知识 | 单点人物的表达能力在离职后不可恢复 | 演练验证而非文档验收 |
| 技术约束 | 打通一旦完成，回退即是一次迁移 | 架构评审新增专门一栏 |
维持节奏上有三个要点：固定更新周期且周期长度要写进模板，不能“想起来才更新”；每次更新有签字人与时间，作为台账自身的可采信依据；变更要留痕，即只追加不覆盖，谁改的哪一列都必须可回溯。长期不动的台账会自动退化成考古材料，等到真要用的时候，没人敢拿它去回答任何问题。
六、我们作为技术服务方的位置
还有一层身份要单独说：客户之间发生并购或股权变动时，我们自己常常就是那张被盘点的资产。这时最要紧的两件事是服务合同的主体归属与数据归属。合同归谁，决定了服务是否随交易自动延续、价格与范围是否重议；数据归谁，决定了迁移时间表由谁说了算。要防的三种情况：一是把两个客户的租户环境在物理资源上提前混用，届时拆开就是停机；二是接口密钥与回调地址绑定在某个人的账号或某个主体名下，主体一变全线失效；三是响应级别与人员安排没有书面约定，交割后各方按自己的理解提要求。我们的做法是在合同附件里就把归属、迁移决策人、可预期的变更窗口和交接验收方式写实，交割期间不接“先把两个环境打通”这类口头要求。窗口期里，最值钱的工程能力不是快，而是随时能把家底讲清楚——这份能力平时看不见，用到时补不回来，而洹拓把它当作交付质量的一部分，不是附加服务。