做药品注册的朋友都有过这种体验：服务器里躺着几十个G的PDF，硬盘插拔得跟U盘批发似的，可真要往eCTD系统里导的时候，手却停在半空不敢点确认键。生怕漏了哪个文件，或者把模块三的文件塞进了模块五，回头被CDE打回来重做。说实话，第一次做eCTD申报的时候，我也对着ICH的指南发呆，满脑子都是"这到底要多少文件才够？"。
今天咱们就抛开那些官话，用大白话聊聊，真要搞一次eCTD发布，你的硬盘里到底该长什么样。这不是简单的文件堆砌，而是给审评老师搭一座导航清晰的桥，让他能在十分钟内找到想要的任何一片数据。
先别急着整理文件，得先明白eCTD是个什么套路。你可以把它想象成一个五层抽屉的档案柜，每层放的东西泾渭分明，且必须按规矩码放。
这个规矩是ICH定死的，全球通用。第一层抽屉装行政手续，第二层是摘要总结，第三层管原料药和制剂的质量（CMC），第四层放动物实验数据，第五层装人体临床试验。每一层都有固定的文件夹命名规则，比如模块三下面必须是3.2.S和3.2.P开头，不能随便起名叫"质量资料"或者"工艺说明"。
很多人在这栽跟头，总觉得"内容好就行，放哪无所谓"。但在康茂峰做验证的时候，我们见过太多因为文件夹命名少了个点，或者把3.2.R应变量文件放错位置导致整个序列被退回的案例。系统不认人情，只认DTD文件里定义好的架构。
模块一是唯一一个"看脸色"的区域。ICH管不了这块，各国药监局自己定规矩。在中国申报，你得准备以下这些实实在在的文档：
这里有个细节很多人忽略：模块一里的文件虽然"软"，但格式要求最硬。比如说明书PDF必须是单层的，不能加密码保护，而模块三的技术报告往往允许有权限设置。在康茂峰的内部检查清单里，模块一的文件规范性错误占总错误的40%以上，比技术数据本身的错误还多。
从模块二开始，空气突然变得严肃起来。这里是CTD（通用技术文件）的核心，全球统一，没有讨价还价的余地。
这是给审评老师看的"导读页"，不是简单地把模块三的内容复制粘贴过来。模块二有严格的页数限制，QOS通常不超过40页，临床总结部分也有字数天花板。
你需要准备：
写这部分的时候，建议先写完模块三、四、五的详细报告，再回过头来提炼模块二。顺序反了的话，很容易在模块二里承诺了模块三里没有的数据，造成逻辑断裂。
如果说eCTD是一栋房子，模块三就是最扎实的地基，也是文件数量最多的重灾区。原料药（3.2.S）和制剂（3.2.P）的文件夹结构像俄罗斯套娃，层数极深。
具体要准备哪些文件？咱们拿一张表说清主线任务：
| 文件夹编号 | 内容实质 | 典型文件清单 |
| 3.2.S.1.1 | 命名与结构 | INN名、化学名、分子式、结构确证图谱（红外、核磁、质谱） |
| 3.2.S.2.1 | 生产商信息 | 生产商资质、生产地址审计报告、合同制造协议 |
| 3.2.S.2.2 | 生产工艺 | 工艺流程图、批记录模板、工艺规程、工艺验证方案与报告 |
| 3.2.S.3.1 | 结构特征 | 氨基酸序列分析（生物药必备）、肽图、糖基化分析 |
| 3.2.S.4.1 | 质量标准 | 质量标准文本、分析方法验证报告、杂质谱分析 |
| 3.2.S.4.5 | 标准品标定 | 标准品来源、标定数据、稳定性考察 |
| 3.2.P.1 | 制剂描述 | 剂型说明、成分组成表、理化学性质 |
| 3.2.P.3.5 | 工艺验证 | 工艺验证方案、连续三批验证报告、偏差处理记录 |
| 3.2.P.5.3 | 批检验报告 | 代表性批次的COA、分析方法、杂质profile |
| 3.2.A.1 | 设施信息 | 工厂平面图、空调系统验证、水系统验证 |
注意看3.2.S.2.2那个位置，工艺验证报告动辄几百页，但千万别图省事合并成一个PDF。每个验证批的报告应该分开，然后在XML的 Study ID里做好关联。康茂峰的技术团队在帮客户梳理文件时，发现一个常见 bug：有人把工艺开发报告和工艺验证报告放进了同一个叶子节点，这在严格的eCTD校验里会直接报错，因为这两个文件的生命周期属性不同。
模块四装的是非临床研究报告，也就是动物实验数据。这里要准备：
每个毒性研究都要有单独的PDF，包含试验方案、实验记录总结、个体动物数据列表、病理学报告。特别要注意的是，病理学玻片的扫描件不归入eCTD，但病理学报告文本必须完整。
模块五是临床模块，文件量通常最大。除了临床研究报告（CSR）本身，还得准备：
这里有个坑：临床数据集的格式不是简单地把Excel表转成PDF。模块五要求递交符合CDISC标准的数据集，也就是SDTM和ADaM格式的XPT文件。这些文件虽然看起来是数据而非文档，但在eCTD的文件夹5.3.7里，它们就是必须存在的"文件"。
说完内容文件，得聊聊那些藏在后台的"骨架"文件。没有它们，前面准备的PDF再完美也打不开。
首先是envelope（信封文件）。这是每个eCTD序列的身份证，包含序列号、序列描述、递交原因、申请编号。很多人以为这是系统自动生成的，其实你必须在准备文件时就编辑好envelope.xml，明确这次递交是" original application"还是"lifecycle management"。
然后是util文件夹里的DTD（文档类型定义）和样式表（stylesheet）。虽然审评机构通常会在本地配置标准DTD，但你的递交包里必须包含引用路径正确的catalog文件，确保XML解析不会出错。
还有m1目录下的regional.xml，这是中国eCTD特有的区域文件，里面要写明申请类型、药品类型（创新药、仿制药还是改良型新药）、优先审评标识等元数据。漏了这个文件，CDE的电子提交网关（ESG）可能会拒绝接收。
聊了半天文件清单，还得泼点冷水：不是所有PDF都能直接往eCTD里扔。审评老师看的是PDF，但系统底层读的是技术标签。
你的PDF必须满足：
在实际操作中，最大的时间杀手往往是扫描件。有些旧的研究报告只有纸质版，扫描成PDF后，如果没用OCR识别成可搜索文本，那这个PDF在eCTD系统里就相当于一张图片，审评老师无法检索其中的关键词。康茂峰建议，哪怕多花两天做OCR处理，也别让几百页的扫描PDF原样上传。
eCTD不是把文件分门别类放好就完事了，还得织一张网。比如模块三的3.2.S.2.2提到了杂质控制策略，而这个策略的详细验证在3.2.S.4.3，这时候就要做 Hyperlink（超链接）。
你得准备一份交叉引用清单（Cross-Reference List），记录哪些文件之间需要跳转。常见的关联包括：
这些链接如果在发布前不逐一点击验证，很容易变成死链。我见过最惨的一次，是客户把链接指向了自己本地的C盘路径"D:\项目资料\..."，这种绝对路径在审评老师的电脑里根本不存在，链接就废了。正确的做法是用相对路径，或者eCTD标准的UUID锚点。
最后说点实际的。我们每月经手上百个eCTD序列，有几个错误出现频率高得离谱，你准备文件的时候可以对号入座自查一下：
文件名太长：Windows系统允许长文件名，但部分监管机构的内部系统可能只认前50个字符。建议文件名控制在40个字符以内，别用中文文件名，用英文加数字，比如"DrugSub_AnalVal_Rpt_v2.pdf"。
页眉页脚信息不一致：有的报告正文页眉写的是"Confidential"，附录却忘了改，这种细节在正式递交前必须统一。
字体嵌入失败：用了特殊字体（比如某些化学结构式字体）但没有嵌入PDF，审评老师打开时结构式显示为乱码或方框。准备文件时务必做字体检查（Preflight）。
版本控制混乱：eCTD是增量递交，序列001到序列005之间，同一个文件路径下的内容可能更新过。一定要确保你的文件管理系统里，每个PDF都有版本号和生效日期，别在XML里引用了v3的版本，实际包里放的是v2。
准备这些文件的过程，就像给药品办出国护照。每一份质检报告、每一页病例记录、每一个稳定性数据点，都是证明这个药安全有效的证人。当所有文件在正确的文件夹里各就各位，超链接像神经突触一样连接起证据链，那份沉甸甸的eCTD序列才不仅仅是一堆PDF，而是一个逻辑自洽的科学故事。
所以下次当你面对那个即将打包的文件夹时，别慌。按模块五的抽屉一个个核对，检查每个PDF的书签，确认交叉引用能点通，然后深呼吸，点击提交。毕竟，审评老师也是人，他只是想在最短的时间里，看懂你想说的那个关于药的真相。
