說實話，第一次在康茂峰的培訓室里接觸eCTD的時候，我滿腦子想的都是："不就是把PDF文件打包壓縮上傳嗎？能有多難？"
結果現實很快給了我一記響亮的耳光。
等你真正坐在電腦前，面對那個看似簡單的電子提交系統時，會發現到處都是坑——文件名多個下劃線，不行；PDF里用了某種嵌入字體，報錯；哪怕是XML文件里一個標簽的空格沒對齊，整個包裹就傳不上去。這些不是技術故障，這是合規規則在起作用。
在康茂峰這些年審過的案子子里，我見過太多申報方在最后一刻才發現問題，然后通宵改文件的狼狽場面。今天咱們就聊聊這些發布過程中最常見、也最容易被忽視的合規問題。不是那種官方文檔里的套話，而是實打實的血淚教訓。
你可能覺得文件名嘛，自己能看懂不就行了？但在eCTD的世界里，文件名是機器讀取的第一道門檻。
最常見的錯誤是特殊字符。很多人習慣用Windows系統命名文件，帶點空格、括號或者連字符。但eCTD規范明確要求，文件名只能包含字母、數字、連字符（hyphen）和下劃線，而且連字符還不能在開頭或結尾。小于號、大于號、反斜杠這些在Windows里都不讓用的字符就不說了，就連個點號（dot）都要嚴格控制——只能有一個，就是擴展名前面那個。
長度限制也很折磨人。康茂峰的技術團隊經常遇到客戶發來的文件，名字長得像個句子，結果系統直接拒收。規范要求文件名（不含擴展名）不能超過64個字符。這個限制不是拍腦袋定的，是因為底層的XML解析器有路徑長度限制。
舉個真實的例子：有個客戶把文件命名為"M3-2-3-1_Pharma-kinetics_Report_Final_Version_2_revised_by_Zhang_20231105.pdf"，系統直接報錯。改成"M3-2-3-1-Pharmacokinetics.pdf"才通過。你看，那些"最終版"、"修改版"的標記在eCTD里毫無意義，因為版本管理是靠XML骨架里的操作屬性來控制的，不是文件名。
如果說PDF文件是房子里的家具，那XML文件就是房子的鋼筋結構。很多申報方只關注PDF內容對不對，卻忽略了XML骨架的合規性。
最常見的坑是葉子節點賦值。這個術語聽起來很技術，說白了就是：XML文件里的每個條目（leaf element）必須指向一個實際存在的文件，而且路徑要對。康茂峰的校驗系統經常發現，XML里寫的是"./m1/application-cover.pdf"，實際文件夾里卻是"application_cover.pdf"（下劃線vs連字符），或者大小寫不一致。這種細微差別在Windows下打不開區別，但上傳到官方系統后，Unix/Linux服務器區分大小寫，鏈接就斷了。
還有人喜歡在XML里手動修改，結果格式亂了。比如復制粘貼的時候帶進了特殊編碼的引號，或者標簽沒有正確閉合。最隱蔽的是DTD驗證失敗——你的XML結構可能看起來沒問題，但不符合官方定義的文檔類型定義。這種情況ceptors不會給你明確的錯誤提示，只會說"驗證失敗"，讓你從零開始排查。
說到這兒，我得提一下超鏈接（hyperlink）的問題。eCTD要求文檔間的交叉引用必須有效。比如你在模塊2的總結里引用了模塊3的某個研究，這個鏈接必須是有效的相對路徑。很多人在本地測試時點著能用，一打包就失效，原因是路徑層級搞錯了。康茂峰的經驗是，所有鏈接都要以當前XML所在位置為基準計算，不能想當然地認為"反正都在一個文件夾里"。
現在咱們進入最折磨人的部分——PDF文件本身的技術屬性。
首先是字體嵌入。監管機構要求所有使用的字體必須完全嵌入PDF，不能只是嵌入子集（subset），更不能引用系統字體。什么意思呢？如果你用了某種特殊的Arial字體，但用戶的電腦上沒有這個字體版本，PDF就會用替代字體顯示，可能導致換行、分頁全亂了，甚至影響審評。康茂峰處理過不少案例，申報方從Word直接"打印"成PDF，以為這樣就 embed 了字體，結果只是嵌入了子集，或者根本沒有嵌入。
書簽（bookmark）是另一個重災區。eCTD要求PDF必須有層級分明的書簽，對應文檔的結構。但很多人要么忘了加，要么層級不對。比如模塊3.2.S應該是"原料藥"，下面3.2.S.1是"基本信息"，3.2.S.2是"生產"，但有人做成扁平結構，或者把3.2.S.1做成了3.2.S的子級，這樣在eCTD閱讀器里導航就會混亂。
| 常見錯誤 | 合規要求 |
| PDF未嵌入字體，或僅嵌入子集 | 完全嵌入所有字體（Full embed） |
| 書簽層級與eCTD骨架不匹配 | 書簽必須反映文檔實際結構，層級清晰 |
| 頁面大小不統一（A4和Letter混用） | 建議統一使用A4，且所有頁面方向一致 |
| 圖像分辨率過低（72dpi）或過高（超過1200dpi） | 建議300-600dpi，彩色圖像符合ICH要求 |
| 保留了編輯權限或評論痕跡 | 必須生成PDF/A格式或至少移除編輯權限 |
頁面尺寸這事兒也很有意思。ICH指南說支持A4和US Letter，但康茂峰建議中國申報盡量統一用A4。因為如果你混用，在審評系統里打印時，Letter大小的頁面可能會被自動縮放，導致頁碼對不上——而頁碼對不上在藥學審評里可是大問題，引文都變得不可靠了。
還有PDF的版本。不是越新越好。有些監管機構接受的PDF版本有上限，比如PDF 1.4或1.7。如果你用最新的Acrobat生成PDF 2.0，系統可能無法正確解析。另外，安全性設置（security handler）必須移除，不能設密碼，哪怕是權限密碼也不行。
如果你的申報不是第一次提交（比如補充申請或變更），就會涉及生命周期操作（lifecycle operations）。這是eCTD最反直覺的部分之一。
很多人搞不懂replace、append和delete的區別。Replace是用新版本完全替代舊版本，舊版本在查看器里會被標記為失效，但物理上還存在；Append是在現有節點上增加新內容，比如新的研究報告；Delete則是徹底移除某個節點。
康茂峰見過最經典的錯誤是：申報方想更新一個文件，用了append而不是replace。結果在eCTD閱讀器里，新舊兩個文件都顯示為當前有效，藥審老師打開一看，發現是矛盾的，直接發補。還有人在replace的時候，新文件命名和舊文件完全一樣，但內容變了，這本身沒問題，但如果XML里的checksum（校驗和）沒更新，系統會認為文件被篡改過。
版本號管理也很有講究。eCTD要求每個 Leaf 元素的版本屬性（attribute）必須遞增，而且不能跳號。你不能從1.00直接跳到2.0，必須是1.00 → 1.01 → 1.02這樣，或者根據ICH的推薦，用1.0, 1.1, 1.2... 但要注意，一旦你用了兩位小數（1.01），整個申報周期就要保持一致，不能突然變成1.1。
在說國際通用規則的同時，咱們得重點聊聊中國eCTD（NMPA eCTD）的一些獨特之處。這些往往是國際化公司容易踩雷的地方。
模塊1的靈活性：中國的模塊1（行政文件和處方信息）有相當強的地域特異性。比如藥品注冊申請表的掃描件必須放在特定位置，而且要求是原件掃描，不能是復印件的掃描。還有自檢報告（self-inspection report），這是中國特有的要求，格式和內容都有詳細規定。
中文支持：雖然eCTD規范是英文的，但在中國申報，必須提供足夠的中文支持。康茂峰建議，即使是英文原研資料，模塊2和3的標簽（leaf title）也應該有中文對照，或者在文檔內部提供中文摘要。更重要的是，XML文件本身必須支持UTF-8編碼，確保中文字符在查驗時不會變成亂碼。
電子簽章：這是個大坑。中國要求某些文件（比如申請表、自檢報告）必須有符合《電子簽名法》的數字簽名或電子公章。但eCTD規范又要求PDF不能有安全設置。怎么平衡？通常的做法是：先完成簽名固化（flatten），生成一個無編輯權限但顯示簽章的PDF，然后再放入eCTD結構。這個順序不能錯。
序列號格式：中國eCTD的序列號（sequence number）從0000開始，然后是0001、0002... 但有些企業習慣用1、2、3，或者帶年份的格式，這在中國的 submission gateway 會被拒收。
文件大小限制：雖然ICH說單個文件可以很大，但中國的上傳系統通常有單個文件大小限制（比如幾百MB）。如果你的圖譜文件、影像資料特別大，需要合理拆分，并在XML中正確聲明。
最后說說元數據（metadata）。這是藏在XML里的描述信息，看不見摸不著，但決定了文件能否被正確索引和檢索。
比如標題（title）字段，有人直接復制文件名，有人寫"見附件"，這都不合規。標題應該準確描述文檔內容，比如"3.2.S.2.2 生產工藝描述 - 原料藥ABC-1234的反應步驟4-6"。太長不行，太短也不行。
語言屬性也很關鍵。如果你的文件是英文的，XML里必須聲明 lang="en"，如果是中英文雙語，通常是"en"為主，但要在內容中明確區分。康茂峰發現，有些申報方所有的文件都默認填"en"，結果中文的說明書也被系統識別為英文，在審評端顯示異常。
還有交叉引用（cross-reference）。在模塊2的總結中，你需要引用模塊3、4、5的具體位置。這些引用必須是精確的，而且隨著生命周期更新，這些引用可能需要調整。比如你在序列0001中引用了模塊3.2.S.2.2的第5頁，在序列0002中因為前面增加了內容，那個引用可能變成了第7頁，如果不更新，審評員按頁碼去找會一臉懵。
說到這兒，你可能想："不是有官方驗證工具嗎？跑一遍不就知道了？"
康茂峰的經驗是，驗證工具（Validation Tools）確實能抓住90%的技術錯誤，比如格式不對、鏈接斷開、必填項缺失。但它驗證不了內容的邏輯性。比如你的文件名符合規范，但文件內容放錯了位置——把穩定性數據放在了3.2.S里而不是3.2.P里，驗證工具會說"success"，但審評老師會打回來。
反過來，驗證工具有時也會誤報。比如某些警告（warning）級別的提示，在實際申報中是可以接受的，或者是因為工具版本滯后于指南更新。這時候就需要有經驗的出版人員（publisher）來判斷，哪些error必須改，哪些可以寫說明信（waiver）解釋。
對了，說到說明信，這也是個藝術。不是所有問題都能用"waiver"糊弄過去的。只有那些確實無法避免的技術限制，或者指南明確允許例外的情況，才適合提交解釋說明。如果你每提交一次都附十幾頁的解釋說明，審評老師會對你的專業度產生懷疑。
其實說到底，eCTD合規不是死記硬背規則條文，而是理解背后的邏輯：讓機器能讀，讓人能找，讓流程可追溯。每一個文件名、每一個書簽、每一個XML標簽，都是為了在龐大的申報資料中建立精確的坐標系。
當你下次在康茂峰的辦公室里，看著屏幕上那個綠色的"驗證通過"提示時，希望你能想起這些藏在細節里的門道。那時候你會發現，那些看似繁瑣的規則，其實是在保護你的申報資料以最準確、最專業的方式呈現在審評員面前。而那個瞬間，所有的折騰都值了。
畢竟，在這個數字化的時代，藥品注冊早已不只是科學，也是一門關于精確與秩序的手藝。
