第一次接触eCTD系统的时候，我盯着电脑屏幕发了整整十分钟的呆。那时候刚入行，手里攥着一摞纸质申报资料，领导说"下周要转成eCTD格式提交"，我以为是简单地把PDF打个包传上去就行。结果打开系统一看，满屏的XML骨架、DTD校验、STF文件这些词儿，瞬间有种外文考试的错觉。后来才明白，eCTD（电子通用技术文档）压根不是简单的数字化搬运，而是一场对技术文档完整性、规范性和逻辑性的全方位体检。今天就想结合这几年在康茂峰经手的项目，聊聊到底要准备哪些技术文档才能顺利过审，避免那种填报到一半发现缺材料的绝望感。
很多人理解eCTD，就是扫描件+电子表格。说白了，这理解还停留在十年前。现在的eCTD体系，特别是按照ICH M4要求的格式，核心在于XML（可扩展标记语言）驱动的结构性提交。你可以把它想象成人体的骨架——XML就是那套骨骼系统，而PDF文档、数据集、研究报告这些是挂在骨头上的肌肉和组织。骨骼要是搭错了，长再多肉也是畸形。
所以准备技术文档的时候，你得同时准备两套东西：看得见的内容（各种研究报告、图谱、记录）和看不见的架构（技术规范文件、DTD定义、Envelope信息）。康茂峰去年处理的一个ANDA项目，客户前期花了三个月准备PDF，结果临提交发现没做XML映射，差点错过PDUFA日期。这种教训太典型了。
ICH把eCTD分成五个模块，每个模块对应的技术文档侧重点完全不同。别想着一套模板走天下，那只会让你返工到死。
这是地区特异性最强的模块，在中国申报（NMPA）和美国申报（FDA）要求的材料差别挺大。但核心逻辑一致：证明你是个合法合规的申请者，有权提交这份申请。
必须准备的技术文档包括：
这里有个容易踩的坑：很多申请人觉得行政文件就是走形式，随便扫描上传。实际上康茂峰遇到过因为营业执照副本缺了最新年检章，导致整个申请被搁置的案例。行政文件的技术规范在于"一致性验证"，系统会比对所有文档中的企业名称、地址、联系方式是否完全匹配。
这是评审员最先看的部分，也是技术文档中最考验写作功底的。包括质量综述（QOS）、非临床综述（NCS）、临床综述（CS）和临床总结（CTD Safety/Efficacy Summary）。
准备这些文档时，技术重点在于超链接的完整性。Module 2里的每一个结论性描述，都必须能链接到Module 3、4、5中的原始数据。比如你在QOS里说"有关物质检测方法经过验证"，这句话得链接着具体的分析方法验证报告（通常在新3.2.S.4.3或3.2.P.5.3）。
格式上必须使用CTD规定的标题层级，字体嵌入要完整。康茂峰的建议是：别用宋体或Times New Roman以外的花体字，系统有时候解析不了特殊字符，会变成乱码方块。
这是篇幅最大、技术文档最繁杂的模块。原料药（3.2.S）和制剂（3.2.P）的研究资料全部在这里。我列个表，你看看这工作量：
| 文档类别 | 具体内容 | 技术注意点 |
| 基本信息 | 命名、结构、一般性质 | 化学结构式要用专业绘图软件生成，分辨率300dpi以上，不能有毛边 |
| 生产信息 | 工艺流程图、批生产记录、供应商资质 | 流程图需要可搜索的PDF（即包含文本层），不能是纯图片扫描 |
| 质量标准 | 分析方法、验证报告、杂质谱分析 | 验证报告必须包含完整色谱图，保留时间、峰面积数据要可检索 |
| 稳定性数据 | 加速试验、长期试验图谱与趋势分析 | 图谱文件通常很大，需要优化压缩，单个PDF不能超过监管要求的大小限制（一般是50MB或100MB，看具体地区） |
| 包装系统 | 浸出物、提取物研究、相容性报告 | 需要引用EDS（向内分泌物研究）的文献或实验数据 |
| 辅料与复验 | COA、复验期依据 | 辅料的基因毒性杂质评估报告现在几乎是必选项 |
处理Module 3的时候，最容易出现的问题是指交叉引用失效。比如你在制剂部分引用了原料药的某个图谱，这两个文档之间的hyperlink必须准确。康茂峰通常会在内部做三轮技术校验：第一轮查文档完整性，第二轮查超链接有效性，第三轮查书签层级（Bookmark不能超过四级，这是FDA和NMPA的硬性规定）。
到了这两个模块，技术文档的性质变了。不仅仅是PDF narrative（叙述性报告），还包括原始数据集（Raw Data Sets）、分析数据集（Analysis Datasets）和病例报告表（CRF）。
关键概念要搞清楚：
这两个模块的技术门槛在于数据的可追溯性。每一个数字都要能溯源到源数据，PDF书签必须对应到具体的表格编号。之前康茂峰审查一份IND申请，发现Module 5的临床总结里引用了某张疗效表格，但书签跳转到的是安全性数据页，这种错误在官方验证（Validation）中会被标记为"Error"级别，直接导致申请被拒绝接收。
上面说的是大模块，但eCTD要顺利发布，还得准备一堆"基础设施类"的技术文档，这些往往被忽视，但缺了它们系统根本不接受提交。
Envelope技术文件：这是包裹整个申请的"信封信息"，包括申请编号、申请类型（如NDA、ANDA、IND）、序列号、提交说明等。XML格式的Envelope必须严格符合地区要求，比如FDA要求特定的DTD版本，NMPA有自己的eCTD技术规范。康茂峰见过最离谱的错误是有人把序列号写成了"000"，结果系统识别为初始序列，覆盖了之前的提交历史。
MD5校验文件：每个电子文档都需要生成MD5哈希值，用于完整性校验。这不是手工填的，是用专门的eCTD出版工具生成的技术文档，需要单独提交。
DTD和Schema文件：虽然通常是系统自带的，但如果你做本地验证，必须确保有对应版本的DTD定义文件，否则XML解析会报错。
目录索引文件（Index.xml）：这是eCTD的导航系统，定义了每个模块下有哪些文档、什么格式、什么属性。准备这个文件需要极其仔细，因为一旦定义了某个文件是"new"（新增）还是"replace"（替换），后续序列就不能随意更改。
说到准备流程，不能临时抱佛脚。康茂峰内部有个"90-30-7"的时间节点供大家参考：
D-90天（三个月前）：这时候应该完成所有原始技术文档的撰写和内部审核。包括实验报告的终稿、分析数据集的锁定、临床数据库的清理。记住，eCTD不接受"草稿版"，提交的必须是终稿。
D-30天：开始eCTD的组装和出版（Publishing）。这个阶段要把所有文档转成符合技术规范的PDF（PDF/A-1a或PDF/A-1b格式为佳），建立超链接，生成书签，制作XML骨架。这时候往往会发现格式不兼容的问题，比如某个色谱图旋转了90度、某个表格跨页断裂。
D-7天：最终的技术验证（Validation）。使用官方验证工具（如FDA的eCTD Validation Specifications或NMPA的验证标准）跑一遍，处理所有Error和Warning。同时要准备提交当天的网络环境测试，确认上传通道畅通。
最后说几个技术文档格式上的死穴，都是血泪教训：
命名规则：文件名不能有空格、不能有中文字符（虽然NMPA现在支持中文文件名，但建议还是全英文+下划线）、不能有特殊符号如&、%、#。建议用"模块编号_文档类型_版本号"的方式，比如"m3_quality_overall_summary_v2.pdf"。
字体嵌入：所有PDF必须嵌入字体。有时候你用了某个特殊字体，自己电脑上有，但评审系统上没有，没嵌入的话打开就是乱码。
页面尺寸：Letter还是A4？建议统一成A4，特别是中国申报。有些美国来的资料是Letter尺寸，直接合并进去会导致显示异常。
书签（Bookmark）层级：前面提过，不能超过四级。而且书签必须对应到具体的章节节点，不能随意设置。
透明通道：PDF中的图片如果带了透明通道（Transparency），在某些阅读器里会显示成黑块。建议全部转成无透明的TIFF或高质量JPG再插入。
说实话，准备eCTD技术文档这事儿，细致程度堪比给精密仪器拧螺丝。每一个文档的完整性、每一个超链接的有效性、每一个元数据字段的准确性，都关乎着申报能否顺利进闸。康茂峰这些年代办的几百个项目里，至少有三成在初始阶段都会发现这样那样的文档缺失或格式错误。所以最好的办法，就是建立一套标准化的文档核查清单（Checklist），在准备阶段逐项打钩，别指望评审员会帮你补材料。
做这行久了你就会发现，eCTD不只是个技术门槛，它其实倒逼着药企把研发资料管理得更规范。以前纸质时代，缺一页可能还能蒙混过关；现在电子系统里，少个XML节点都验证通不过。从这个角度看，虽然准备过程痛苦，但确实是行业进步的体现。希望这些实打实的经验，能让你下次面对eCTD系统时，心里更有底一些。
