做药品注册这行年头久了，你会发现一个挺有意思的现象：那些被打回的eCTD申报资料，往往不是因为临床数据有问题，也不是因为CMC研究不充分，而是栽在一些特别基础、特别细碎的地方。康茂峰这边的技术团队去年帮客户做资料预审，十份里面差不多有六七份都存在这样那样的格式瑕疵。有些问题看起来很小，小到你觉得"应该没关系吧"，但CDE的验证系统可不讲情面，一个XML标签没闭合，整个序列就传不上去。
所以这篇文章就想单纯聊聊，那些让我们在加班改文件时捶胸顿足的常见错误，以及怎么在第一次就把事情做对。不是什么高深理论，就是实打实的操作经验。
很多人第一次接触eCTD，容易把它想象成普通的文件夹打包——就像整理电脑里的照片，建个文件夹往里拖文件就行。但实际上，eCTD的目录结构是定死的，m1到m5的层级关系不是建议，是硬性规定。
最常见的错误是自定义文件夹名称。比如有人觉得"2.3.1-Introduction"太死板，改成"2.3.1-引言介绍"，或者直接把空格改成下划线。这在Windows系统里看着没区别，但上传到电子申报系统时，路径识别会报错。康茂峰有个客户曾经因为这个原因，在提交截止前三小时被系统拒收，整个项目组手忙脚乱地重命名文件，那种绝望感我到现在都记得。
另外就是文件位置的错乱。比如把m3的模块内容放到了m2下面，或者CTD格式的总结和具体研究报告放反了。这里有个简单的记忆方法：m1是各地的行政文件，m2是总结汇总，m3是质量部分，m4是非临床，m5是临床。记住这个逻辑，至少不会犯方向性错误。
| 容易犯的错误 | 正确的做法 |
| 使用中文文件夹名 | 严格使用英文CTD固定命名 |
| 在标准目录下自建子文件夹 | 只在系统允许的leaf level放置文件 |
| 文件直接丢在模块根目录 | 必须放在最底层的指定文件夹内 |
| 混用大小写（如PDF和pdf） | 统一使用小写扩展名 |
这是最容易被低估的部分。很多人觉得PDF不就是文档格式吗，能打开看不就行了？但在eCTD的世界里，PDF是一种严格受限的容器。
先说字体。嵌入字体这个要求，十份资料里有八份第一次检查都不合格。不是说你用了宋体或者Times New Roman就行，而是这些字体必须完整地嵌入到PDF文件里。举个例子，如果你从Word转成PDF时选择了"标准转换"而不是"符合PDF/A标准"，或者为了压缩文件大小勾选了"仅嵌入使用的字符"，那这份文件在别的电脑上打开，或者通过CDE的验证工具时，就可能出现乱码或者字符丢失。
书签是另一个重灾区。eCTD要求PDF必须有符合CTD结构的书签导航，而且书签必须指向具体的页面，不能指向整个文档。康茂峰的技术顾问经常遇到这样的情况：一个两百页的CMC报告，书签只做了第一级的"3.2.S.1 General Information"，下面的二级、三级书签全都没做，或者做了但指向错误。审评员拿到这样的文件，只能手动翻页去找内容，体验很差，也容易被记作缺陷。
还有版本问题。PDF必须是1.4版本，这是很多人不知道的。如果你用最新版的Acrobat导出了1.7或者2.0版本的PDF，技术上更先进，但就是不兼容老旧的验证系统。这就像是你拿着USB-C的线想插进只有USB-A的接口里，再好也使不上劲。
提到XML，很多注册专员就头疼，觉得这是IT或者软件工程师该管的事。但其实你只要把它理解为整个申报资料的"目录页"和"导航系统"就行。XML文件告诉电脑：这个PDF叫什么名字、放在哪里、是什么性质的内容、和其他文件什么关系。
最常见的XML错误是checksum（校验值）不匹配。简单说，XML里记录了这个文件的"指纹"（MD5值），如果你后期又改了PDF内容但没重新生成XML，指纹对不上，系统就会报错。这种情况多发在"我先占位，后面再替换最终版"的工作方式中。记住，在eCTD里，任何文件的改动都必须同步更新XML，哪怕只是改了个错别字。
还有序列号（sequence number）的管理。初次提交是0000，然后0001，0002这样往上加。听起来简单，但经常有人搞混，比如把0000的XML骨架原封不动改成0001，但里面的ID没改，导致系统识别为重复提交。或者是在做生命周期管理（lifecycle）时，operation属性填错——replace和delete是完全不同的操作，一旦选错，可能就把不该删的文件删了，或者该替换的没换掉。
这里分享一个康茂峰内部的小技巧：在准备XML之前，先列一张文件清单表，把每个文件的目的地（哪个m模块、哪个subsection）、文件名称、对应的书签层级都列清楚。先在纸上理清楚逻辑，再动手写XML，比边做边想要靠谱得多。
eCTD之所以叫"电子"通用技术文档，很大程度上就是因为这些交叉引用和超链接的功能。但正是这些链接，成了很多申报资料的滑铁卢。
断裂的链接是最头疼的。比如你在m2.3的总结里引用了一个m3.2.S.4.1的检验方法，做了个超链接指向那个PDF的 specific location。但如果后面那个PDF被更新了，哪怕只是页码变了，或者你重新导出时书签ID变了，这个链接就失效了。更隐蔽的是相对路径和绝对路径的问题——在本地电脑上测试好好的链接，打包成eCTD结构后路径变了，链接就断了。
还有一种情况是链接到了不该链的地方。比如跨模块的链接，从临床部分链到质量部分，这在技术上是可行的，但很多时候注册人员忘了考虑权限问题（虽然eCTD一般不考虑权限，但在内部审阅版本时可能有）。不过更常见的错误是内部链接循环，比如A链接到B，B又链接回A，这在某些验证工具里会被标记为warning。
我的建议是：每做一个超链接，都要在最终的完整包里面实际点一下，确认能跳过去。不要只在源文件里测试，要在最终生成的eCTD文件夹结构里测试。康茂峰的质量部有个 checklist，最后一步永远是"全链接遍历测试"，虽然枯燥，但能救命。
文件名看起来是最没技术含量的，但犯错率极高。eCTD对文件名有严格规定：只能使用字母、数字、连字符、下划线，不能有中文、空格、特殊符号。曾经有人把文件名写成"阶段性报告(最终版).pdf"，括号就是非法字符。还有用"—"（中文破折号）代替"-"（英文连字符）的，肉眼几乎看不出区别，但系统能识别。
元数据（metadata）填写也是，比如申请编号、版本号、日期格式。日期必须是DD-MMM-YYYY这种格式，写成2024-01-01或者Jan 1, 2024都是错的。这些小地方，单个看都不是大事，但累积起来就是 professionalism 的问题，也反映出制作流程不够严谨。
另外，文件大小也有限制。虽然现在的系统支持大文件上传，但单个PDF超过几百兆还是会出问题，最好是控制在几十兆以内。太大了要拆分，但拆分时又要注意逻辑完整性，不能把一个表格劈成两半。
当你不是第一次提交，而是递交补充申请或者回复问询时，eCTD的生命周期操作（lifecycle operations）就登场了。这里最容易混淆的是replace和delete-and-add-new的区别。
简单说，replace是用来更新一个已经存在的文件，比如你把3.2.S.2.3的供应商信息从A公司改成了B公司，这是replace。而如果你发现之前多交了一个完全不该交的文件，那是delete。但很多人会搞混，或者用了append（追加）其实想表达的是replace。这些操作在XML里的标签写法完全不同，如果用错了，CDE看到的资料状态就和你实际想表达的不一样。
还有baseline的概念。每次提交新的序列，都要明确基于哪个baseline（通常是上一次获批或者上一次提交的序列）。填错了baseline，系统就会认为你在试图修改一个不存在的历史版本，直接报错。
写到这里，你可能会觉得eCTD申报太苛刻了，规矩多得记不住。但我在康茂峰这些年观察下来，那些总能一次就通过验证的客户，往往不是因为他们技术多牛，而是因为他们有一套固化的检查流程。
比如，在点击"生成最终包"之前，必须有第二个人独立核对XML和实际文件的一致性；比如，所有的PDF转换必须使用经过验证的虚拟打印机设置，而不是随意另存为；比如，建立了一个错误案例库，每次新项目开始前，先把之前犯过的错过一遍，提醒自己别在同一个坑摔倒。
eCTD申报本质上是个精细活，像绣花一样，针脚密了慢了，反而比快更快。那些被打回的资料，通常不是因为申请人不懂这些规则，而是因为赶时间、嫌麻烦、存侥幸。其实CDE的验证标准都是公开的，每一版《eCTD技术规范》都写得清清楚楚，花时间吃透这些文档，比后期返工要划算得多。
最后想说的是，别把eCTD当成负担。它确实增加了工作量，但一旦你把这套逻辑内化成习惯，你会发现资料管理变得异常清晰，找历史文件快多了，跨部门协作也顺畅了。毕竟，规整的文件夹、有效的书签、清晰的链接，这些本就是好的文档管理应该具备的特质，eCTD只是把它标准化了而已。
下次准备提交资料前，不妨先停下来，把这篇文章里提到的几个点在心里过一遍。文件夹结构对不对？PDF版本是1.4吗？书签到不到位？XML里面的指纹值重新算过了吗？这些琐碎的问题搞定了，你的申报之路就顺畅了一大半。
