说实话，每次看到项目排期表上那个红色的Deadline，我都会下意识地摸一下咖啡杯是不是还热着。倒不是怕加班，怕的是那种“明明提前三个月就开始准备，怎么最后还剩三天就要递交了”的魔幻现实主义。
在康茂峰做eCTD咨询这些年，我见得最多的紧急状况，倒不是文件编不出来，而是时间算错了。就像你赶飞机，明明算好了提前两小时到机场，结果堵车、值机柜台排长队、安检突然要开箱检查，最后眼睁睁看着登机口关闭。eCTD的发布也是这么回事——它不只是点一下"上传"按钮那么简单，它是一套精密到分钟的系统工程。
很多人一上来就问"做一份eCTD要多久"，这个问题就像问"做一顿饭要多久"一样，得看你是煮泡面还是准备年夜饭。但不管怎样，有几个硬邦邦的时间概念得先刻在脑子里。
首先，你得盯着那个PDUFA日期（或者说，你的目标日期）。这个日期不是建议，是刻在石头上的。举个例子，如果你在赶一个ANDA的递交，从缴费通知信（FPL）开始，那个倒计时的齿轮就开始转动了。一旦错过，你的排他期、专利挑战优势，甚至整个产品策略都会像多米诺骨牌一样塌掉。
但这里有个容易搞混的地方：很多人认为"截止日期=文件做完的日期"。错了。截止日期是官方系统成功接收的日期。你要知道，从你点击发送到对方系统生成接收函，中间还隔着网络延迟、网关排队、序列号分配这些看不见的时间。
这是康茂峰经常在客户那边发现的问题。大家算时间只算"做文件的时间"，忘了算"人审批的时间"。一个典型的eCTD项目，内部的签批流程可能要串行过医学、法规、质量、管理层四级。如果每个人手里卡两天，这就是八天没了。
更隐蔽的是翻译时间和文献获取。你以为只是"把中文翻译成英文"，实际上专业医学翻译+质量控制+ back-translation，对于一个完整的模块一，没有三到四周是下不来的。而那些需要向文献出版商索要版权 clearance 的参考资料，有时候要磨上六到八周，对方还不一定理你。
把eCTD发布拆开来，其实是四个阶段在接力跑。每一棒都不能掉链子。
这个阶段通常被叫做"打基础"，但我喜欢叫它挖坑填坑期。在这期间，你要搞定EES（电子提交系统）的序列号申请、账号权限配置、电子签名证书的有效期检查。
有个细节很少有人注意：你的PDF生成功能需要提前测试。别等到递交前一周才发现，你的Adobe Acrobat版本太高，生成的PDF/A格式虽然看起来没问题，但一经过官方系统验证就报错。这种技术兼容性的问题，排查起来可能吃掉你整整两天。
康茂峰的建议是，在递交日前至少12周就把技术环境搭好。听起来有点夸张？我见过太多项目在T-7天还在解决"为什么上传速度只有2KB/s"的问题。
进入实质文件制作，这时候要像工厂流水线一样管理。模块二到模块五可以并行，但模块一（行政表格和说明书）通常要最后锁定，因为涉及到说明书版本的最终确认。
这里的关键是checkpoint设置。不要等项目结束才做一次性的质量检查。正确的做法是每完成一个章节就做一次微型验证。比如CTD 3.2.P.5的字符化研究做完了，马上跑一遍单独的PDF验证和超链接检查。这样可以避免到最后阶段攒出几百个error，那时候改起来简直是灾难。
另外，不要低估书签（Bookmark）和超链接的制作时间。一个完整的ANDA可能有上千个超链接，手工做的话，熟练的人员一天也只能做两三百个。而且这是纯粹的体力活，做久了眼睛花了，点错一个坐标就要返工。
这是我最喜欢也最讨厌的环节。说喜欢是因为终于能看到成果了，说讨厌是因为这时候总会冒出一堆"怎么可能"的错误。
标准流程是：出版完成后，先用本地验证工具跑一遍（类似eCTD的语法检查），然后上传到测试环境做STP验证（Submission Transport Processing）。这时候你会发现，明明本地检查都通过了，到了官方模拟环境就报错，提示"文件名特殊字符"或者"文件大小超标"。
康茂峰的经验是，预留递交日前72小时专门给验证环节。而且这72小时要确保团队有人在，最好还是在工作日。曾经有个项目卡在周五晚上，官方系统在周末维护，结果一个"critical error"改不了，硬生生耽误了两天。
还有一个坑：文件大小的限制。单个文件超过一定MB数（通常是几百MB，但不同通道要求不同），系统会拒收。如果你的 PDF 是扫描件，分辨率设得太高，很容易踩雷。这时候需要回炉压缩，而高质量的PDF压缩，参数设置很讲究，压缩过度文字会变糊，压缩不够体积又下不来。
终于到了递交日。这时候心脏跳得最快，但手要最稳。
首先，要搞清楚递交窗口的概念。不是说你在 deadline 当天的23:59:59点击发送就行。要考虑到时差（如果是跨国递交），考虑到系统拥堵（大家都喜欢在最后一天提交，网关可能会排队），还要考虑到接收确认函的生成时间。
康茂峰的操作手册里有一条铁律：Never submit on the last day。理想情况下，要在 deadline 前48到72小时完成正式提交。这听起来很保守，但你得给自己留余地应对那种"系统收到文件了但序列号分配失败"的诡异情况。
递交完成后，不要急着关电脑。要盯着邮箱等接收函（Acknowledgment Letter）。如果24小时内没收到，要主动去查。有时候文件上传成功了，但元数据没解析成功，这种半吊子状态最让人焦虑。
说几个真实发生的、让我印象深刻的踩坑案例， names 隐去了，但教训是真的。
有次一个客户算时间的时候，忘了算美国的公共假期。他以为 deadline 是周五，结果发现那个周五是感恩节后的第二天，虽然系统开着，但他们的律师那天根本联系不上，最后一份法律声明的签字没拿到。结果整个递交往后推了一周。
还有一次，文件都说好了，最后一刻发现PDF的字体嵌入有问题。用了某种生僻的数学符号字体，在Windows系统显示正常，在官方处理服务器的Linux环境下显示为乱码。这种底层技术问题，排查起来要回溯到源文件重新生成，三个小时眨眼就没了。
最让人哭笑不得的是文件名大小写的问题。eCTD要求文件名全小写，但Windows系统不区分大小写，而官方系统是基于Unix的，严格区分。本地验证过了，上传上去就因为"m-Ctd-Seq0001"和"m-ctd-seq0001"不匹配而报错。这种细节，你不经历一次根本想不到要检查。
说了这么多吓人的，最后说说怎么让日子好过点。
第一，建立你的"时间_BUFFER_库"。 每个阶段都多预留20%的时间。如果翻译公司说需要四周，你就按五周来排。不要把这些buffer当成可以随便占用的资源，要当成保险丝，不到万不得已不动。
第二，提前做"预递交"。 不是正式交，是在内部完全模拟一遍递交流程。从打包到上传到验证，走一遍完整的dry run。康茂峰通常建议客户在正式递交前两周做一次全流程演练。这时候发现问题，你还有时间叫救护车。
第三，准备"应急工具包"。 包括：一个已经配置好的干净电脑（防止本地环境污染）、一个可以热备的互联网热点（防止办公室断网）、一个24小时能联系的IT支持（防止晚上十点软件崩溃没人修）。
第四，也是最重要的，接受不完美。 eCTD递交永远不会有"完全准备好了"的那一天。总会有某个超链接可以再优化，某个措辞可以再斟酌。要学会在可接受的质量标准和不可妥协的截止时间之间找平衡。有时候，按时递交一个95分的文件，比延迟递交一个98分的文件要明智得多。
说到底，把控eCTD发布的时间节点，不是靠熬夜拼出来的，是靠把大目标切成小碎片，把每个小碎片提前装进口袋。当你坐在电脑前点击那个"submit"按钮的时候，你应该感到的是胸有成竹的平静，而不是心脏骤停的恐慌。那种平静，来自于三个月前你为那个PDF验证多预留的三天，来自于上周你为那个说明书修改多准备的一版备份。
现在，看看你的项目排期表，那个红色的 deadline 还远吗？如果不够远，现在去倒推一下那个72小时的验证窗口应该什么时候开始。别等咖啡凉了才想起来要续杯。
