注册申报文档撰写

1客户嘴上要的

「注册申报资料几千页，发补回复又有时限，团队写不过来。用 AI 撰写申报资料和发补回复。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 8 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1–2

   第 1–2 周复盘上一次发补

   • 跟注册部 2 个注册专员、CMC 1 人、临床统计 1 人各坐半天，逐条复盘上一个项目的发补通知（审评中心要求补充资料的通知）和当时的回复过程。
   • 发现回复的难点在证据：一条问题往往要同时引用质量标准、方法学验证、批分析和稳定性数据，分散在已提交资料、补充研究报告和原始记录里；文档管理系统里同一份报告有多个版本，靠「谁记得在哪」去找。上一次有 3 条回复引用了非最终版本，被再次追问。
   • 更关键的是证据缺口发现得太晚：有 2 条问题需要补充实验，团队在第 3 周才意识到，实验排期把整个回复拖到了时限边缘。
   • 真问题是「在时限内找全证据、找对版本，并尽早发现缺口」。成功标准改成：每条发补问题 1 天内给出候选证据清单（文档、版本、页码）；引用非最终版本为 0；需要补充研究的问题在收到发补后第 1 周内全部识别出来。
2. 3

   第 3 周定范围 + 保密 + 版本规则

   • 砍范围：只做一个在研项目的 CMC 和临床两个模块。
   • 未上市产品的申报资料是最高级别的保密信息。和信息安全部确认：只在公司内部部署，只连文档管理系统的只读接口，访问限定在项目组。
   • 请文档管理员确认「最终版」怎么标识。很多旧文件没有状态标签，先补标再接入，否则检索会把草稿当证据。
   • 踩坑不要把申报资料放到外部模型服务里测试，哪怕只是 demo。
3. 4–6

   第 4–6 周原型 + evals

   • 检索助手：输入一条发补问题，先拆成子问题（如「杂质限度依据」拆成质量标准、方法学验证、批分析、稳定性四类证据），再逐类检索，只返回最终版文档，每条证据带版本号和页码；同时列出已提交资料里的相关表述，提醒回复要保持一致。找不到证据的子问题标为「证据缺口」，提示是否需要补充研究。
   • 回复只生成带引用的提纲，正文由注册专员撰写。
   • evals：用一个已完成审评的项目，拿 30 条发补问题回放，以当时的最终回复为标准答案：30 条中证据找全 ≥ 25 条；引用版本 100% 正确；当时需要补充研究的 6 条中识别出 ≥ 5 条。
   • 踩坑审评用语和公司内部叫法不同（如化合物代号、内部批号规则）。要和 CMC 一起建同义词表，否则检索会漏。
4. 7

   第 7 周Demo + 真实发补

   • 正好有一个项目收到发补，让注册专员本人用助手处理。第 2 天就标出 1 条证据缺口，补充实验比以往提前一周启动。
   • 有一个功能被否掉：FDE 想加「一键生成完整回复」，注册部负责人不同意——回复必须由注册专员撰写并经部门审核，系统只提供证据和提纲。
5. 8

   第 8 周交接交接

   • 本案例比默认多两周：保密审批和文档管理系统的只读接口排期多用了两周。
   • 交接给注册部一位申报文档主管：负责同义词表和子问题拆分模板；文档管理员负责最终版标识；信息技术部负责接口。运行手册写清：每次发补结束后，把问题和最终回复补进测试集。

4这个案例教给你的可复用判断