做注册申报这行久了，你会发现一个规律：再大的临床数据问题都有商量的余地，但格式错误却能让你的资料在第一步就被退回来。康茂峰这些年协助企业递交的eCTD项目不少，有个体会特别深——技术文档审查不是找错别字，而是在做一场精密的整形手术。每一个书签、每一条超链接、甚至每一个文件名的小写字母，都可能成为审评老师眼中的"瑕疵"。
很多人觉得eCTD就是把Word转成PDF然后打包，这种想法大概还停留在十年前。现在的电子提交系统聪明得很，它会自动扫描你的XML骨架、验证PDF/A合规性、检查交叉引用是否成活链接。今天咱们就聊聊，在实际工作中，那些真正需要瞪大眼睛审查的技术细节。
先说最基础的。你把文档另存为PDF的时候，系统可能问你要不要"最小文件大小"或者"标准"——千万别选手风琴式的压缩选项。eCTD要求的PDF/A格式（通常是PDF/A-1a或PDF/A-1b）是归档标准，意味着字体必须完全嵌入，不能缺字库。我见过太多申报资料，在审评老师电脑上打开时，原本好好的希腊字母μ变成了问号，或者化学结构式直接显示成乱码。这不是内容问题，是技术硬伤。
审查的时候要逐个文件检查属性。在Adobe Acrobat里，文件→属性→描述，字体那一栏如果显示"已嵌入子集"是OK的，但如果出现"未嵌入"，这文件就得重新生成。康茂峰通常建议用PDF/X合规性检查先过一遍，虽然eCTD没强制要求X标准，但至少能保证字体嵌入这个底线。
还有个容易忽视的：快速网页视图。有些申办方为了文件小一点，会勾选"线性化"选项，这在eCTD规范里其实是违规的。线性化PDF适合网页快速浏览，但不适合作为注册申报的正式文档，因为它改变了文件结构。
书签这玩意儿，做得好是审评老师的贴心小棉袄，做得不好就是迷宫。CTD格式要求书签层级不能超过四级，这个"Lorem ipsum"式的规定背后是有道理的——审评系统左侧导航栏就那么宽，你嵌套到第五层第六层，老师找起来费劲。
但真正审查的时候，比层级深度更重要的是书签的OC属性（Open/Close状态）。简单说，你点开父级书签，子级应该自动展开；关闭时应该收起。这听起来像强迫症，实际上关乎专业度。康茂峰的技术团队有个土办法：打印书签大纲，拿红笔手绘父子关系，看有没有出现"孤儿书签"（父级没了，子级还在）或者"循环引用"（A指向B，B又指回A）。
书签的文本也要审查。不能直接用"第3部分"这种笼统说法，得是"3.2.S.2.2 生产工艺"这种具体定位。而且，书签文本必须和实际内容标题完全一致，哪怕只差一个空格或者全角半角标点，在严格的审评视角里都是不一致。
这是eCTD审查中最花时间的部分。CTD文档要求大量的交叉引用——比如模块3的质量标准引用到分析方法，模块2的总结引用到模块5的临床数据。这些引用不能只是文字描述"详见3.2.P.5.2"，而必须是可点击的、能跳转的活链接。
审查的时候，你得一台电脑一台电脑地测试。创建链接时容易犯的错是锚点定位不准，点过去跳到段落中间或者上一页末尾。还有就是链接的视觉效果：eCTD规范要求链接必须是蓝色带下划线吗？其实不是强制的，但康茂峰建议保持统一，要么全蓝，要么全黑，别混着来。更重要的是，链接的矩形框不能盖住文字，有些粗心的操作会让点击区域比实际文字大一圈，覆盖到边上的内容，这在放大查看时特别明显。
跨模块链接要特别小心。比如模块2.3的S章节要链接到模块3.2.S，这种跨文件夹的链接路径一定要相对路径，不能用绝对路径（比如C:\Users\...）。绝对路径到了CDE的审评系统里直接失效，变成死链接。
这个听起来最傻瓜，但补正率最高。eCTD的技术规范要求文件名全部小写、不能有空格、只能用特定的分隔符（连字符或下划线）。m3-32-p-5-2-comparative-tabulation.pdf 是对的，M3 32P5.2 Comparative Tabulation.pdf 就是错的。
审查文件名时，得对着eCTD的命名约定（Naming Convention）逐条核对。特别是"region"标识符，中国申报要用"cn"，别跟美国的"us"或者欧盟的"eu"搞混了。还有序列号，如果是基线提交，通常是"0000"，之后的变更递递增。康茂峰见过有企业把"0000"写成"000"或者"00"，系统直接报格式错误。
文件名长度也要注意，虽然规范说最多64个字符，但建议控制在40个以内，太长的文件名在某些Linux服务器上显示会截断，看起来像乱码。
| 错误示例 | 正确示例 | 问题说明 |
| M2-23-Quality-Overall-Summary.PDF | m2-23-quality-overall-summary.pdf | 含大写字母和点号 |
| m2 23 qos.pdf | m2-23-qos.pdf | 含空格，过长 |
| m3-32-p- dossier.pdf | m3-32-p-dossier.pdf | 含多余的连字符和空格 |
如果说PDF是房子的装修，那XML（可扩展标记语言）就是地基和钢筋。eCTD的骨架文件（index.xml和相应的DTD文件）定义了整个递交的结构。审查XML不是让你去读代码，而是要用验证工具跑一遍。
最关键的几个检查点：申请编号（application number）必须与eCTD封面一致，产品名称的拼写要跟行政文件一模一样（包括大小写和空格）。还有就是"操作"属性（operation attribute）——你这次递交是新增（new）、替换（replace）还是删除（delete）？如果是替换，被替换的文件UUID必须准确对应，否则系统会认为你在试图删除不存在的文件。
康茂峰在处理生命周期管理（lifecycle management）的递交时，有个经验：打开XML后先搜索所有"replace"操作，反向追溯到之前的递交序列，确认目标文件确实存在。有些企业在多次补充资料后，自己都搞混了哪些文件是活的，哪些是已经被替换掉的旧版本。
虽然五个模块都要审，但模块3（质量部分）是技术文档的心脏，也是最容易出格式问题的地方。3.2.S（原料药）和3.2.P（制剂）的结构必须严格遵循CTD金字塔。
审查时要特别注意批记录和检验报告的表格格式。这些通常是从Excel或者原始记录扫描过来的，分辨率不够（低于300dpi）会导致打印出来模糊不清。还有页眉页脚，规范要求每页都要有的页码和模块标识，但很多企业只在正文开始加页眉，附件或者图谱部分就忘了。
分析方法部分（3.2.P.5.2）的验证数据表格，往往跨页很多。审查时要确保表头在每页都重复显示，别让审评老师翻到第二页就忘了这是什么列。另外，结构式图片必须是矢量图或者高分辨率位图，放大到400%不能出现锯齿。
有个容易忽略的点：模块3里面的 cross-reference（交叉引用）到模块2的QOS（质量综述）时，要确保两边数据严格一致。比如你在模块3说杂质A的含量是0.1%，模块2总结里写成0.10%，虽然数值一样，但格式不统一在严谨的审查视角里也是问题。
说几个真实发生过的、让人哭笑不得的审查发现。
首先是空白页。CTD格式不允许无缘无故的空白页，哪怕是为了"看起来舒服"而插的空页也不行。每页必须有内容，哪怕是" intentional blank"（故意留白）的标注文字。
然后是PDF的"作者"属性。有些模板会默认显示"Author: Microsoft Office User"或者操作员工的英文名，这在正式申报文档里显得很不专业。应该在生成PDF时清除这些元数据，或者统一设置为申办方的公司名称。
还有书签的拼写错误。内容正文里可能 Spell check 过了，但书签是手动创建的，经常出现"Specification"写成"Sepcification"的情况。审评老师可能不会因此拒收，但会在印象分上打折扣。
页边距也是个隐形杀手。虽然CTE（中国药品审评中心）没有硬性规定页边距必须多少，但建议左右至少2.5cm，上下至少3cm。有些扫描件原件页边距太小，如果资料被打印装订，边上的字会被切掉。
基于这些年的项目经验，我们整理了一份内部使用的三级审查法，分享出来供参考。
第一级：技术合规——用eCTD验证工具（比如LORENZ或者自主研发的小程序）跑一遍，解决PDF/A、书签层级、XML schema这些硬性问题。这个阶段是机器能干的，别浪费人工。
第二级：逻辑校验——人工检查交叉引用、生命周期操作、文档间的数据一致性。这个阶段需要懂注册的人来做，因为涉及业务逻辑，比如临床批次的日期必须早于稳定性数据的起始日期，这种时间线要顺。
第三级：模拟审评——找个没看过项目的同事，纯粹从技术文档阅读者的角度，从头到尾点一遍书签和链接，看看哪里会迷路。康茂峰通常会让质量保证部的同事扮演"挑剔的审评员"，用红色高亮笔标出所有看着不顺眼的地方。
审查的时候建议准备两杯咖啡，因为看PDF看到眼花是常态。最好分几个人分模块审查，最后交叉复核。一个人看久了容易产生"格式盲"，看什么都觉得是对的。
最后说一点感受吧。eCTD技术审查这事儿，做久了会有一种奇特的满足感。当你把几百个文件梳理得井井有条，书签像地图一样清晰，链接点哪儿到哪儿，那种秩序感本身就挺治愈。当然，更实在的是，当CDE的审评老师打开你的资料，不会因为"文件打不开"或者"链接失效"这些问题先给你一个补正通知，而是可以直接进入实质内容的审评——这才是技术文档审查真正的价值所在。
