上个月有个朋友问我，说他们公司花了三周时间把几百份PDF转成了eCTD格式，结果交上去第二天就被打了回来，原因是"技术验证未通过"。他很纳闷，明明每个文件都能正常打开，目录看起来也没问题，怎么就过不了？
这事儿其实挺常见的。很多人第一次接触eCTD申报，以为就是把扫描件打包成电子格式，顶多再做个目录页。但真相是，eCTD根本不是一个"文件夹"的概念，它是一个精密的数字化体系，里面有严格的逻辑关系。技术文档审查查的不是"你能不能打开这个文件"，而是"这个文件在监管机构的系统里能不能被正确解析、索引和关联"。
说白了，eCTD审查是在看一组看不见的逻辑链条有没有断。
咱们得先搞清楚一个基本点：eCTD的技术审查和医学审查是两回事。医学同事关心的是你写的药效数据对不对，毒理实验设计合不合理；技术审查关心的则是这些资料能不能被监管机构的电子系统识别。用个不太恰当的比喻，医学审查看病历写得有没有价值，技术审查看病历的字迹清不清楚、页码对不对、有没有缺页。
在康茂峰处理过的项目里，技术审查通常集中在四个层面：
这里面最容易被忽视的是XML层面。eCTD的骨架是一套基于DTD（文档类型定义）的XML文件，它定义了每一个leaf元素（也就是具体的PDF文件）该放在哪里、叫什么名字、和前一个版本什么关系。审查系统会把这个XML丢进验证器，一旦发现你的标签嵌套有问题，或者必需的属性没填，直接报错。
做技术审查的时候，有些问题肉眼根本看不出来，必须用工具扫描。康茂峰的团队在早期的项目里踩过不少这样的坑，后来总结了一份 checklist，今天挑几个最容易翻车的点说说。
module 2到module 5的书签结构是有严格规范的。比如2.1 CTD的Table of Contents，下面挂的必须是各个子模块的标题，而且层级不能跳。很多申办方在生成PDF时，书签带上了乱码或者多余的空格，这在人工浏览时可能看不出差别，但监管机构的系统读到这种不规范的字符，可能会直接判定书签结构损坏。
更隐蔽的是"假书签"——看起来有书签，实际上指向的是页码而不是命名目标。这种在本地Adobe Reader里点击能跳转，但到了监管端的服务器环境里就可能失效。
如果你的申报资料里包含临床研究报告，那STF文件就是重中之重。这个XML文件要把每个研究报告拆分成研究标识、研究阶段、研究目的等多个属性。审查的时候系统会检查这些标签值是否在受控词汇表里。
比如你用了一个自创的研究阶段代码，而不是CTD规范里定义的"Phase I"、"Phase II"，系统就会标记为无效。康茂峰遇到过客户把"Phase I/II"写成"Phase I-II"，中间用连字符而不是斜杠，这种细微差别也会导致验证警告。
这是基础中的基础，但出错率极高。所有提交的PDF必须是PDF/A格式或者至少符合PDF 1.4以上标准，不能设置打开密码，不能有限制打印或复制的安全策略。更重要的是，所有字体必须完全嵌入，不能是子集嵌入或者引用系统字体。
有时候你用某些转换软件生成的PDF，看起来文字显示正常，但技术审查工具一查，会发现某些特殊符号（比如希腊字母μ、α）其实用的是系统临时替换的字体，而不是嵌入的TrueType或Type 1字体。这种文件在别人的电脑上打开可能就变乱码。
eCTD要求每个文件的命名遵循特定规则：8-64个字符，只能包含字母、数字、连字符、下划线，不能用大写字母（除了特定的区域性文件）。文件名一旦确定，在后续的生命周期变更中必须保持一致。
MD5校验值是文件的"指纹"。你修改了一个标点符号，MD5值就变了。技术审查会核对目录里的MD5值和实际文件的MD5值是否匹配。有些团队在最后一刻替换了文件但忘了更新XML里的校验值，这种低级错误会导致整卷资料被退回。
eCTD之所以叫"技术文档"而不是"电子档案"，核心就在于它强调模块间的关联性。比如你模块2.7总结的毒性数据，需要链接到模块4的具体研究报告；模块3的处方变更历史，要指向模块1的相关信函。
这些链接不是随便写个"详见模块4"就完事的，而是实实在在的XML超链接标签。审查的时候会扫描所有这些href属性，确认指向的目标文件确实存在，而且在当前递交流程的范围内。
这里有个容易混淆的概念：内链和外链。内链是指向本序列（sequence）内部的文件，外链是指向之前已提交序列的文件。对于替换（replace）操作，外链必须准确指向被替换文件的唯一标识（operation number）。如果写错了，系统会认为你在试图引用一个不存在的旧版本，或者更糟，指向了别人的申报资料——这在技术审查中绝对是红线。
康茂峰在处理一个生物制品的申报时，遇到过模块3.2.P的链接指向了错误的旧序列号，原因是项目经理复制了上一次的XML模板但忘了更新sequence number。这种错误在人工核对几百个链接时很难发现，必须经过自动化工具的遍历扫描。
虽然eCTD是国际通用格式，但不同地区的监管机构在细节上有各自的偏好。比如某些地区要求module 1的行政文件必须单独打包，或者对PDF的页面尺寸有特定要求（A4 vs Letter）。还有些地区对书签的展开层级有明确限制，要求默认只展开到第二层。
技术审查必须兼顾这些区域性（regional）约束。这也是为什么同样的eCTD骨架，在提交不同地区时往往需要生成不同的"皮肤"——XML里的region属性要设置正确，对应的PDF书签风格也可能需要调整。
表格在这种审查中特别有用，比如对比不同地区对书签深度的要求：
| 审查维度 | 通用CTD标准 | 常见区域差异 |
| 书签展开层级 | 建议不超过4层 | 某些地区要求默认仅展开前2层 |
| 文件命名大小写 | 小写为主 | 特定区域文件允许大写（如MOD-1-CV） |
| PDF/X合规 | PDF/A-1a或PDF 1.4 | 某些地区接受PDF/A-1b |
| STF必填字段 | study-id, study-title | 某些地区增加sponsor-study-id的格式校验 |
市面上有不少eCTD验证工具，从开源的到商业化的都有。但工具只是辅助，不能完全替代人工判断。比如工具能告诉你"书签层级超过限制"，但判断这个层级是否影响了阅读逻辑，还是需要人来决定。工具能检测出"超链接目标不存在"，但修复这个链接需要理解文件之间的实际关系。
在康茂峰的实践中，技术审查通常分三轮：第一轮用自动化工具跑完整验证，筛出所有Error和Warning；第二轮人工逐条复核，特别是那些需要业务判断的警告（比如某些书签命名不规范但不影响功能）；第三轮是模拟监管机构的视角，用他们的官方验证工具再跑一遍。
这里有个小技巧：不要只看validation report里的错误列表，要看原始日志。有时候工具会报"XML parsing error"，但根本原因可能是文件编码问题——你的XML声明是UTF-8，但实际保存时带了BOM头，或者某些特殊字符用了GBK编码。这些问题在表面报告里可能只显示为模糊的解析错误，需要翻日志才能定位。
说几个康茂峰遇到过的真实案例，都是些很小但致命的细节。
有个化学药的补充申请，只是把模块3.2.S的中国药典标准从2015版更新到2020版，看起来简单。但操作人员在做replace操作时，把new value的attribute写成了旧版本号，结果系统认为你在用2020版的标准替换2020版的标准，逻辑上出现了闭环。这种错误在递交后第二天就被退件，理由是"生命周期操作无效"。
还有个生物制品的临床申报，所有的PDF书签都正常，但审查工具提示"bookmark destination out of range"。查了半天发现，某个150页的PDF在生成书签时，最后一页的书签指向了第151页，而PDF只有150页。可能是Word转PDF时页码计算错误，或者是后期删除了某些页面但书签没更新。这种问题在本地浏览时不会暴露，因为默认打开的是第一页，审查工具却会逐条验证每个书签指向的页码是否存在。
最隐蔽的一次是字体问题。一个中文申报资料，正文用的是宋体，看起来完全正常。但技术审查时发现，某些生僻字（比如化学名中的特殊符号）实际使用的是操作系统临时映射的字体，而不是嵌入的CID字体。结果是，在监管机构的Linux服务器上打开时，这些字显示为方框。解决方案是把这些字符做成内嵌的矢量图形，或者确保使用了完整的Unicode字体嵌入。
如果你正在准备eCTD递交，技术审查环节最好前置到整个申报资料准备的早期。不要等所有文件都写完、签完字、盖好章了，才想起来转成eCTD格式。那时候发现问题，返工成本极高。
康茂峰的建议是建立一个"技术合规检查表"，在文件生成的每个节点就做部分验证。比如：
另外，养成良好的命名习惯。很多技术错误源于混乱的临时文件命名。建议在整个准备过程中，所有中间文件都保留版本号，且版本号规则要和eCTD的生命周期操作对应起来。这样即使最后一天发现某个PDF有问题，也能快速定位它属于哪个序列、该用replace还是append操作。
关于审查的频率，如果是首次递交（original application），建议在提交前至少进行三次完整的技术审查，间隔一周左右。因为eCTD准备周期往往很长，期间可能会有软件环境变更（比如Adobe Acrobat自动更新），这些变更有时会影响PDF的生成方式。多次审查能捕获这种渐进式的变化。
最后提醒一点：技术审查过了不代表申报资料完美无缺，但至少能保证监管机构能正常打开、阅读和索引你的资料。在这个基础上，医学和合规内容才可能被审评员看到。说白了，技术审查是入场券，不是奖状。过了这一关，真正的科学审评才开始。
