做注册这行的都知道，从纸质资料转到eCTD，就像是 suddenly 被要求把写了十几年的毛笔字改成电脑打字——道理上都懂，但真到上手的时候，手指就是不听使唤。康茂峰这几年经手的eCTD项目大大小小也有几百个，今天就想掏心窝子聊聊，那些 submission 过程中真正会要命的关键点。
先说好，eCTD不是什么洪水猛兽，但它确实有一套自己的脾气。你按它的规矩来，大家相安无事；你要是觉得"差不多就行"，那审评老师退回补充资料的时候，可没人跟你讲情面。
很多人以为eCTD就是把Word转成PDF，然后打个包发过去。要是真这么简单，制药公司干嘛还要专门养一整个出版团队？
eCTD本质上是个结构化的对话系统。想象一下，你每提交一份资料，就是在跟审评老师写一篇长篇武侠小说。第一次提交是第一章（基础IND或者申报临床），后面每次补充资料、变更、年报，都是后续的章节。这些章节之间必须有严密的引用关系，页码变了、内容删了、位置挪了，整个索引系统都得跟着动。
它的核心骨架是XML——就是那个看起来像天书但实际很讲逻辑的东西。XML Backbone 就像是这本书的目录和索引卡片，告诉审评系统："嘿，3.2.S.1.3这部分内容在哪儿，它跟2.3.5有什么关联。"
所以第一个关键点来了：永远不要脱离XML思维看eCTD。你提交的每一个PDF，在系统眼里都不是独立文件，而是XML树状结构上的一个节点。
好，说回技术。
很多人觉得PDF就是个容器，能装东西就行。但在eCTD世界里，PDF是有生命的。它需要携带书签（Bookmarks），需要有活的超链接（Hyperlinks），需要对字体有近乎偏执的嵌入要求。
咱们先说书签。用Adobe Acrobat看过PDF的人都知道，左边那个导航栏里的书签树就是eCTD的生命线。康茂峰见过太多案例，提交前一晚通宵检查内容，第二天发现书签层级全乱套了——3.2.R变成了3.2.S的子节点，或者干脆一整节的书签消失了。
为什么呢？多半是因为源文件里的标题样式没设对。eCTD要求的书签层级必须严格对应CTD模块结构，一级一级往下，不能跳级，也不能乱序。你Word里的"标题1"、"标题2"如果手动调过，转成PDF后书签就会跟着抽风。
再说超链接。eCTD规范要求，文档内部交叉引用必须是可点击的链接。比如你在3.2.P.5里提到"详见3.2.P.4的检测结果"，这个"3.2.P.4"不能只是文字，得是蓝色下划线、一点就跳的那种链接。而且最变态的是，这些链接必须指向书签，而不是页面。
指向页面会有什么问题？因为你加了页眉页脚，或者调了个段落，页码变了，链接就死了。但书签是锚定在内容上的，内容在哪儿，书签就跟到哪儿。
XML Backbone 是eCTD的灵魂。它里头有个叫Study Tagging File（STF）的东西，专门管那些临床研究报告和试验数据。很多申办方在这里栽跟头，因为STF里的ID必须全局唯一，而且一旦定下来，后续所有的增补、变更都得沿用这个ID。
举个真实的例子。有个客户第一次提交时把 study ID 写成了"Study-001-ABC"，第二次增补时手滑写成了"STUDY-001-abc"。大小写不一致，系统就认为这是两个不同的研究，原来的交叉引用全断了。审评老师打开增补资料，点回去看原始数据，链接失效，直接打回。
所以康茂峰给团队定了个铁律：ID命名规范必须写成SOP贴在显示器旁边。用什么大小写、连字符还是下划线、日期格式是YYYYMMDD还是YYYY-MM-DD，这些细节必须在项目 kick-off 时就定死，后续任何人不能擅自发挥。
文件名不是你想怎么写就怎么写。eCTD有严格的命名规范，比如不能有空格、不能有特殊字符（连中文字符都不建议）、长度控制在一定字符以内。最坑的是，同一个序列内文件名必须唯一，哪怕你在不同模块。
曾经有人把模块3和模块5的参考文献都命名为"ref.pdf"，系统直接报错。因为eCTD在解包时是把所有文件放在一个大池子里看UUID的，同名文件会互相覆盖。
还有文件版本控制。PDF属性里的"标题"、"作者"这些元数据，看起来没用，但有些验证工具会读。如果你所有文件都显示"作者：Administrator"或者"标题：Microsoft Word 文档"，虽然技术上不一定会被退审，但给人的感觉就很不专业。
eCTD最大的特点是有生命周期——Lifecycle。你从第一次提交（0000序列）开始，后面0001、0002、0003一直往上叠。每个操作（替换、删除、增补）都有特定的 XML 标签来定义。
这里最容易混淆的是"Replace"和"New"的区别。如果你要更新一份文件，必须用 Replace 操作，并且要保证新旧文件的第一次引用关系正确。如果你误操作为"New"，系统会认为这是一份全新的文件， Old 的那份还在库里躺着，导致内容重复或者逻辑矛盾。
康茂峰建议做生命周期管理时一定要画流程图：哪些文件是长期有效的（比如模块1的授权信），哪些是随着版本迭代要替换的（比如稳定性数据），哪些是这次提交后要删除的。这张表要每周更新，特别是在准备重大增补（Major Amendment）的时候。
另外，序列号的连续性也很重要。不能跳号，也不能回头覆盖。我见过有客户因为IT备份问题，误把本地的0003序列当成0002重新提交，结果官方系统里出现了两个0002，整个申请状态都乱了。
如果你只做过美国FDA的eCTD，直接来做中国eCTD，会有很多"想当然"的坑。
中国的eCTD在2021年正式实施后，虽然整体框架跟ICH指南一致，但在 granule（粒度）和区域要求上有自己的特色。
粒度指的是一个PDF文件里装多少内容。中国NMPA对粒度的要求有时候比FDA更细。比如 module 2 的综述部分，有些内容在中国要求单独成文件，不能跟国际版的2.3合并。
康茂峰在处理中国eCTD时，通常会准备一份粒度映射表，把CTD指南里的每一个章节对应到具体的文件拆分策略。比如3.2.S.1.3的杂质谱，在中国建议单独成文件，因为审评老师经常需要反复比对这部分数据。
还有一个隐藏考点：中国eCTD要求 module 1 的某些行政文件（比如申请表、相关证明文件）必须按照特定模板填写，而且这些模板偶尔会更新。如果你用了一年前的模板，哪怕内容都对，形式上可能被要求补正。
每个eCTD系统都有自己的验证工具。中国的eCTD验证标准除了检查XML schema是否符合、PDF是否可读这些基础项，还会检查一些"中国特色"的业务规则。
比如，中国要求某些特定章节必须有书签，哪怕这个章节只有一页纸。还有，对中文字体的嵌入要求特别严格。如果你的PDF用了某种生僻的宋体或者楷体，但没有完全嵌入子集，在审评老师的电脑上打开时可能会显示为乱码或者方框。
康茂峰的内部检查清单里有个专门的"中文字体验证"步骤，确保所有PDF都用标准的 SimSun 或 SimHei，并且完全嵌入。这一步在FDA的eCTD里可能不是关键，但在中国是必查项。
说了这么多理论，来点实在的。这些翻车现场都是血泪教训：
最惨的一次，有个客户提交前用了"Ctrl+Z"撤销了最后一步书签调整，但自己没注意，直接打包上传了。结果那版资料里的 module 2 完全没有书签，审评老师只能靠手动翻页找内容，可想而知观感有多差。
说了这么多技术点，最后想聊点软技能。
eCTD提交不是技术部的独角戏，是RA（注册）、QA（质量）、Medical（医学）、甚至IT的协奏曲。康茂峰见过成功率最高的团队，都有一套三审制度：
第一审是作者自查，用PDF阅读器点一遍所有书签和链接；第二审是交叉审核，让没参与写作的同事用新鲜的眼光过一遍；第三审是用自动化工具跑验证，但不能完全依赖工具。
为什么这么说？因为验证工具只能告诉你XML格式对不对、文件在不在，它判断不了"这部分内容该不该放在这里"、"这个超链接虽然有效但指向的内容对不对"。工具是死的，人是活的。
还有时间规划。永远不要指望eCTD能在提交前三天搞定。正常的流程是：内容定稿后，至少预留一周时间做出版（Publishing），再做一周时间做QC（质量控制），最后留两三天处理突发状况。如果你周二截止，周一才开始转PDF，那基本上可以肯定要出问题。
另外，建立一份项目专属的Checklist特别重要。因为每个项目的情况不同，有的有BE试验，有的没有；有的涉及多规格，有的只有单规格。康茂峰的建议是，在CTD基础结构上，用Excel列出每一个文件的责任人、状态、最后一次更新日期。这张表要每天晨会过一遍。
最后说点心态上的事。eCTD这玩意儿，第一次接触时确实觉得到处是约束，像戴着镣铐跳舞。但当你沉下心来，把每一个tag、每一个bookmark都当成跟审评老师的对话，就会觉得这套系统其实很公平——它给所有申办方设了同样的规矩，谁能把规矩吃透，谁就能在审评环节少踩坑，把时间真正花在科学讨论上，而不是补正格式。
说到底，eCTD是形式，但形式服务于内容。把形式做到极致，不是迂腐，是对自家产品质量的尊重，也是给最终用药的患者多上一层保险。毕竟，如果因为PDF书签错了导致审评延误，晚一天上市，就意味着晚一天帮到需要这些药的人。这话说得有点重，但做这行的，心里总得揣着这根弦。
