最常见的就是PDF版本和属性设置。很多人觉得"存成PDF不就行了"，但在eCTD世界里，PDF 1.4、1.7和PDF/A-1a完全是三回事。我们曾经有个项目，所有文件都是用最新版Acrobat存成了PDF 2.0，结果系统根本不认，因为它们不属于eCTD技术规范支持的版本范围。
还有字体嵌入这门玄学。你看着自己电脑上的文件好好的，发出去对方打开全是乱码。原因很可能是你用了系统自带的某种中文字体，或者从Word转PDF时忘了勾选"嵌入所有字体"。康茂峰的技术审核清单第一条永远是：检查字体嵌入状态，特别是那些从PPT转过来的示意图。
书签（Bookmark）层级的混乱也是个老大难。eCTD要求书签必须和CTD的目录结构对应，但很多人做成了一级书签直接跳到五级，或者中间缺了二级、三级。审评老师点开一个模块，发现书签跳来跳去像在玩迷宫，心情自然不会太美丽。
如果说PDF是外表，那XML骨架文件就是eCTD的灵魂。这个看似简单的文本文件，错一个字母整个包就废了。
最典型的错误是DTD声明写错。比如应该是"DCTD"的地方写成了"dctd"，或者引用的DTD版本号跟实际用的骨架不匹配。这种大小写敏感的问题，肉眼很难发现，但校验工具（这里康茂峰内部有一套自己的验证逻辑）一读就会报错。
还有个容易忽略的细节是叶子节点（Leaf）的对应关系。你在XML里写了一个文件路径，结果实际的PDF文件名差了一个空格，或者用了全角的括号（）而不是半角的()。系统在解析时找不到文件，就会认为你的eCTD包是残缺的。
做eCTD时间长了你会发现，越是基础的规定，越容易翻车。
审评中心对文件名长度有硬性规定：不能超过64个字符（包括扩展名）。听起来很长对吧？但当你把"化学药品补充申请第X次第Y模块第Z部分修订版最终版"翻译成英文缩写，再加上日期和版本号，很容易就超标了。
另外，千万别在文件名里用中文符号。比如"报告（终稿）.pdf"里的括号是全角的，系统可能认不出来，或者在不同操作系统环境下显示为乱码。康茂峰的项目经理们有个习惯：所有文件名只允许出现英文、数字、下划线和短横线，连空格都不要，用下划线代替。
eCTD对文件夹结构有严格定义，不能多一层也不能少一层。比如有的申办者为了"方便管理"，在m1、m2外面又套了个"某项目资料"的大文件夹，或者在里面又分了"旧版"和"新版"的子目录。这样生成的eCTD包在审评系统里解压后，路径就不对了，系统找不到m1文件夹，直接判定为结构错误。
到了序列2、序列3的时候，事情变得更复杂。这时候你要处理的是生命周期操作（Lifecycle），也就是告诉系统：这个文件是替换（replace）之前的，还是删除（delete）之前的，或者是新增（new）的。
最常见的迷糊是替换操作写成了删除。比如你在序列1提交了一个稳定性报告，序列2发现有个数据错了要更新。这时候应该用replace操作，把旧文件标记为替换状态，上传新版本。如果操作成了delete，那旧文件会被标记为删除，新文件又因为某些原因没关联上，结果就是这个稳定性报告在系统里消失了。
还有操作对象搞错的情况。eCTD要求精确指向到某个序列的某个具体节点，但有时候序列号写错了，比如想替换序列1的文件，结果写成了替换序列0的（如果存在的话）。这种错误在XML里看起来只是数字的差别，但实际后果就是文件版本管理混乱，审评老师看不到完整的变更历史。
一份CTD文档里充满了交叉引用——这里参见3.2.P.2，那里参见附录X。在纸质时代这没问题，但在eCTD里，这些引用必须是可点击的超链接。
康茂峰在审核时经常发现，超链接指向的目标不存在，或者指向了错误的文件。比如应该链接到3.2.P.2.3的文件，结果链到了3.2.P.2.2。更隐蔽的是链接目标存在，但书签（Destination）名称变了，导致点击后报错"找不到书签位置"。
还有种情况是相对路径和绝对路径的混淆。eCTD要求使用相对路径，但如果你在制作PDF时不小心用了绝对路径（比如C:\Users\XXX\Documents\...），在审评老师的系统里，这个路径根本不存在，链接自然就失效了。
每个eCTD文件都有对应的元数据（metadata），包括标题、作者、主题等。很多人随手一填，或者用软件默认的"Microsoft Word"作为作者名。
这里有个坑：标题（Title）字段必须和CTD目录完全一致。比如CTD目录里写的是"3.2.S.1.3 General Properties"，你的PDF属性里写的却是"一般性质"或者简写成了"General"，系统在进行一致性校验时就会亮黄灯。虽然不一定导致退回，但每次都要人工解释也很麻烦。
另外，日期格式要统一。有的地方写2024-01-15，有的地方写15-Jan-2024，还有的地方写2024/1/15。虽然都是同一天，但机器读取时会认为是不同的信息，给后续的数据库管理带来混乱。
| 错误类型 | 具体表现 | 康茂峰建议的防范措施 |
| PDF技术规范 | 版本不符、字体未嵌入、书签层级混乱 | 制定PDF生成SOP，强制使用PDF 1.4或指定版本，预检嵌入字体和书签结构 |
| XML骨架错误 | DTD声明错误、大小写敏感问题、节点对应不上 | 使用结构化编辑器（Manual检查不可靠），严格区分全角半角符号 |
| 文件命名 | 超过64字符、含中文符号、含空格 | 建立命名规范，所有文件名预审，只使用英文、数字、下划线 |
| 生命周期操作 | replace/delete/new操作混淆、序列号指向错误 | 建立变更控制表，双人复核机制，操作前明确每个文件的变更属性 |
| 超链接失效 | 指向不存在目标、使用绝对路径、书签名称变更 | 提交前全局点击测试，检查相对路径有效性，确保书签锚点稳定 |
| 元数据不一致 | 标题与CTD目录不符、日期格式混乱、作者信息随意 | 制作元数据填写指南，设置模板强制标准化，交叉比对目录与文件属性 |
说了这么多坑，其实大部分错误都是可预防的。康茂峰内部有个"三审三校"的流程，倒不是说要多复杂，而是形成肌肉记忆。
第一审：技术合规审。在内容还没最终定稿时，先检查一遍PDF技术规范。书签、超链接、字体、版本，这些跟内容无关，可以提前做。
第二审：结构逻辑审。XML文件生成后，不只看能不能打开，要对照CTD目录一颗一颗节点对过去，看看m2-5的每个文件是不是都在正确的位置，文件名和XML里的href属性是不是严丝合缝。
第三审：生命周期审。特别是序列2及以上的补充申请，要倒回去看序列1提交了啥，这次操作是不是正确反映了变更意图。
还有个实用技巧：做一份Checklist，但不要做成那种没人看的文档。康茂峰的项目经验是，把Checklist做成按模块分类的任务清单，每完成一项打个勾，比最后统一检查效果好得多。因为人到了提交前夜，脑子都是懵的，看着满屏文件很容易漏掉细节。
另外，别迷信制作软件的自动功能。很多eCTD制作工具号称能一键生成，但自动生成的书签往往层级不对，自动识别的文件名有时会吞掉特殊字符。工具是辅助，最后的质量把控还得靠人眼。
最后想说点题外话。做eCTD最大的敌人其实是急躁。因为赶进度，所以跳过了验证步骤；因为觉得"上次就是这样做的"，所以忽略了本次项目的特殊性；因为厌烦了重复的Checklist，所以凭感觉点了提交。
但eCTD这东西，它不讲情面，也没有差不多。一个字符的错误就是错误，不会因为你的数据质量好就网开一面。在康茂峰接手的挽救项目中，有一半以上都是申办者自己做了七八成，最后实在搞不定才找来的，这时候往往时间已经很紧张，修改成本比一开始就规范操作高得多。
所以啊，把eCTD当成搬家打包。你会把易碎品随便塞进纸箱吗？会在箱子上不写标签吗？肯定不会。每一个eCTD序列就像是寄给审评中心的一个包裹，你得确保地址写对了（XML结构），东西没摔坏（PDF技术规范），而且对方知道哪个是新寄去的，哪个是替换上次的（生命周期操作）。
刚开始可能会觉得规矩繁琐，但当你经历过一次零发补的顺利提交，那种畅快感，还是值得的。毕竟，咱们做药的人，严谨是刻在骨子里的，对吧？
