说实话，第一次接触eCTD的时候，我也以为这就是把以前的纸质资料扫描成PDF打包提交的事儿。就像咱们把老照片存进手机相册那么简单。但真干起来才发现，监管部门要的压根不是"电子化的纸"，而是一套自带导航系统的数字档案馆。这套系统得让审评员不用下载任何特殊软件，点开一个XML文件就能像逛维基百科那样，在不同的章节之间自由跳转。
在康茂峰处理过的几百个申报项目里，最常见的返工原因往往不是内容写得不对，而是格式这个"门槛"没跨过去。今天咱们就掰开揉碎了聊聊，eCTD提交到底有哪些必须死守的合规底线。
很多人盯着PDF文件本身下功夫，却忽略了那个看起来只有几KB大小的XML文件才是真正的"大脑"。你可以把整个eCTD想象成一个人体：PDF文件是血肉，XML骨架才是骨骼和神经系统。
这个XML文件必须用特定的DTD（文档类型定义）或者Schema来编写，得精确到每一个标签的嵌套层级。比如模块一的行政信息要用
这里有个容易踩的坑：有些申报员觉得手动改XML太麻烦，就在软件生成的XML文件里手动删改几行。结果往往破坏了文件的校验逻辑，导致整个提交包被退回来。康茂峰的经验是，宁可多花十分钟在软件里重新调整，也别直接动XML源代码，除非你真的很懂那些标签背后的语法规则。
别以为随便导出的PDF都能用。监管部门对PDF文件的技术规格有近乎苛刻的要求，咱们一条条过。
目前主流的要求是PDF 1.4到1.7版本之间。太高了不行，用了最新版的PDF 2.0，审评系统可能打不开；太低了也不行，1.3版本以下的不支持某些必要的安全设置。字体必须全部嵌入，不能用系统默认字体。什么意思？就是你用了某个特殊字体，得把这个字体文件本身"缝"进PDF里，否则审评员电脑上没有这个字体，打开全是乱码。
这是最反直觉的一点：PDF不能设置任何密码保护，也不能限制打印、复制或者编辑权限。听起来很不可思议对吧？明明这些资料很机密，怎么能不加密？但合规要求就是这样，审评系统需要无障碍地读取、索引和打印文件。任何密码都会让自动化验证程序卡壳。
当然，这并不意味着安全性可以被忽视。康茂峰在实际操作中会建议客户通过物理介质管控（比如专用的加密U盘传输）和网络安全协议来弥补这一环节，而不是在PDF本身加密码。
每个PDF文件都必须自带书签（Bookmark），而且得有意义。不能把一百页的PDF只有一个总标题书签，也不能用"第1页"、"第2页"这种毫无信息量的命名。审评员需要通过书签快速定位到"3.2.S.2.2生产设备"或者"5.3.5.1毒理学报告"这样的具体节点。
提交文件的命名规则是合规检查的重灾区。不能用中文命名，不能用空格，不能用除了下划线之外的任何特殊符号（连横杠都得慎用）。文件名长度通常限制在64个字符以内，而且必须体现内容的归属位置。
比如一份放在模块3、第2部分、S小节、第2子项的合成工艺文件，命名可能得像这样：m3\02-synthesis\m32s22-manufacturing-process.pdf。注意看，这里的反斜杠代表文件夹层级，实际提交时会在物理文件夹里真实建立对应路径。
常见错误：用"新建文件夹"、"最终版"、"真的最终版"这种临时命名；在文件名里加日期后缀如"20231225"；使用骆驼命名法（CamelCase）而不是下划线分隔。这些在人工看起来人畜无害的习惯，在自动化校验系统眼里都是红牌。
| 合规的命名示例 | 不合规的命名示例 |
| m1_eCTD_cover_letter.pdf | M1 cover letter-final.pdf（含空格和大写） |
| m3_32s11_specification.pdf | 模块3质量标准.pdf（含中文） |
| m5_53_clinical_study_report.pdf | CSR-v2.0-final-really-final.pdf（过长且混乱） |
eCTD最大的价值之一就是交叉引用（Cross-reference）。模块2的质量概述里提到"详见模块3.2.S.2.2"，这里不能只是文字描述，必须是一个可以点击的蓝色超链接，点一下直接弹到对应的PDF具体页面。
这要求申报人员对整个资料包了如指掌。每一个"参见"、"详见"、"如..."后面，都得检查是否真的做了链接。漏做链接不算致命错误，但会大幅拉低审评效率，而且在新版的电子提交指南里，这已经被明确列为合规缺陷项。
康茂峰的技术团队有个检查小窍门：提交前把整套资料复制到一个全新的文件夹路径下测试所有超链接。因为有时候在本机测试能用，是因为绝对路径依赖了本地C盘某个固定位置，换台机器就失效了。必须用相对路径，确保链接的"可移植性"。
正式提交前，必须通过两道验证程序：技术验证和业务规则验证。
技术验证检查的是"能不能打开"的基本问题：XML格式是否合法，PDF是否损坏，文件命名是否符合正则表达式，Checksum（校验和）是否匹配。这相当于检查快递包裹的箱子有没有破、地址标签有没有贴歪。
业务规则验证则更深层，检查的是"内容逻辑对不对"：你在模块1填的申请类型和模块5的临床数据是否匹配？同一个文件在XML骨架里被引用了两次？模块3的批次信息与稳定性研究的批次是否能对得上号？
很多申报单位卡在业务规则验证上，因为这里涉及跨文档的勾稽关系。比如你发现模块2.3的品质控制说用了HPLC法，但模块3.2.S.4.1的检验方法文件里写的却是GC法，这种矛盾系统会标红。康茂峰建议在资料撰写阶段就建立交叉核查表（Cross-reference Matrix），把几百个关键信息点的对应关系列成Excel表格，最后转eCTD时一一核对。
虽然叫"电子提交"，但最后交付的载体往往不是网络直传，而是物理介质——通常是CD、DVD或者一次性写入的U盘。这里也有门道。
介质本身要符合ISO 9660标准，不能用那种花里胡哨的加密U盘或者带自动运行程序的多功能盘。文件系统必须是 Joliet 扩展兼容的，确保长文件名不会在进入系统时被截断成奇怪的乱码。
更细节的要求还包括：根目录下必须有一个README.txt文件说明内容组成；介质标签必须注明申请编号和日期；如果一套资料需要分多张光盘，每张盘还得有明确的编号标识（比如"Disc 1 of 3"）。
说几个康茂峰在实际项目中经常遇到，几乎每次都会出错的细节。
PDF/A标准：虽然基础要求是PDF 1.4-1.7，但某些特定类型的文档（比如电子签名文件）要求符合PDF/A归档标准。这要求在生成PDF时特意选择"符合PDF/A"的选项，普通打印成PDF往往通不过。
页眉页脚的一致性：整套eCTD资料里，页眉页脚的格式应当统一。不能前面用Times New Roman 10号字，后面突然变成Arial 11号。这种视觉上的不统一虽然不影响技术验证，但在官方发布的电子提交技术指南里，已经被列为需要整改的格式问题。
扫描件的分辨率：如果是把历史纸质资料扫描进eCTD，分辨率不能低于300dpi，但也不要超过600dpi（否则文件太大）。而且必须是可搜索的PDF，或者至少是经过光学字符识别（OCR）处理的。纯图片格式的扫描件现在基本会被要求重做。
说到底，eCTD合规不是单纯的技术活，也不是单纯的法规活。它卡在中间那个微妙的交叉点上。技术团队可能觉得"我能打开不就行了"，法规团队可能觉得"内容写对最重要"，但eCTD审核员看的是两者结合——内容对，并且以规定的技术格式呈现出来。
在康茂峰看来，最好的合规策略是前期就把eCTD出版（eCTD Publishing）纳入整个申报资料撰写流程，而不是等到资料都写完了再"翻译"成eCTD格式。就像盖房子，如果一开始没留好电线管道，等装修完了再凿墙布线，那代价可就大了。
另外，建议保留好中间版本的XML文件和所有原始Word/Excel源文件。因为eCTD提交后经常会有补正要求，如果只有最终的PDF而没有可编辑的源文件，改动一个小地方可能要重走整个出版流程，既费时间又容易在重新生成PDF时引入新的格式错误。
合规这件事，没有"差不多就行"的说法。系统校验是0和1的二元世界，要么通过，要么报错。但也不用被那些技术细节吓到，只要抓住XML骨架、PDF技术规格、命名规则和交叉引用这几个纲，纲举目张，剩下的都是执行层面的耐心活。
希望这些实打实的经验能帮你少走弯路。毕竟申报资料整合这事儿，一次过审比什么都强，你说是不是？
