RA-02 · 发补缺口清单与证据定位

① 场景引入

一、这件事现在是什么样

注册事务 · 真实业务触发

2026 年 8 月 12 日收到 CDE 发补通知，共 5 条，80 个工作日窗口从落款日起算、截止 2026 年 12 月 2 日。第 3 条要求与竞品 KP-32 已公开数据对比并完善间质性肺炎风险管控措施。RA 经理要在两周后的项目会上拿出：每条发补的证据现状、责任部门、缺口与里程碑倒排。

二、痛点 · 每条都有来源

1发补原则上只提一次、必须一次按要求提交全部资料 —— 超出通知内容的资料不予接收，漏答一条等于白交，窗口不会重来依据 · CDE 审评期间补充资料问答 —— 原则上一次发补、80 个工作日、按落款日期计算截止日、逾期不予批准2补充资料通知的落款日期与实际收到日期有滞后，但截止日必须按落款日算 —— 起始日算错直接按不予批准处理，这是实操中最容易踩的坑依据 · CDE 审评期间补充资料问答 —— 原则上一次发补、80 个工作日、按落款日期计算截止日、逾期不予批准3第 3 条这类对比分析要跨临床、医学、注册三个部门收证据 —— 证据在谁手里、哪个版本能用，RA 一个人说不全，只能挨个部门催依据 · 注册事务从业者「一天」第一人称自述 —— 申请人之窗跟踪、模块3 与说明书规格不一致连夜修复的真实案例、跨部门催数据4对发补内容有疑问须在 10 个工作日内提出一般性技术问题咨询 —— 这个二次窗口同样会悄悄滑过去依据 · CDE 审评期间补充资料问答 —— 原则上一次发补、80 个工作日、按落款日期计算截止日、逾期不予批准5外包发补答复报价 45 万且周期贴着窗口走 —— 自己做则缺一份把证据、缺口、责任、时限放在一起的总账依据 · 注册事务从业者「一天」第一人称自述 —— 申请人之窗跟踪、模块 3 与说明书规格不一致连夜修复的真实案例、跨部门催数据

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 发补原则上只提一次、必须一次按要求提交全部资料 —— 超出通知内容的资料不予接收，漏答一条等于白交，窗口不会重来补充资料通知的落款日期与实际收到日期有滞后，但截止日必须按落款日算 —— 起始日算错直接按不予批准处理，这是实操中最容易踩的坑第 3 条这类对比分析要跨临床、医学、注册三个部门收证据 —— 证据在谁手里、哪个版本能用，RA 一个人说不全，只能挨个部门催对发补内容有疑问须在 10 个工作日内提出一般性技术问题咨询 —— 这个二次窗口同样会悄悄滑过去

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 逐条拆解 · 五条发补各要什么每条拆成「要什么证据、什么格式、归谁出」，原文条款号保留
2. 证据盘点· 现有文件能答到哪一步逐条对照卷宗清单：已有什么、在谁手里、哪个版本 —— 答不全的标缺口
3. 缺口判定· 差多少、差在哪每条发补的缺口单列：缺数据、缺分析、缺签字，各标建议责任方
4. 分工与里程碑 · 80 个工作日倒排落款日 2026-08-12 起算：+30 工作日 9 月 23 日内部初稿、+60 到 11 月 4 日医学统计复核、+78 到 11 月 30 日质控冻结、截止 12 月 2 日
5. 留证与签批 · 生成项目会用的总账每条发补一页：证据现状、缺口、责任方、里程碑，注册负责人签批后下发

要准备什么：发补通知原件（pdf / docx）五条发补的原文，一切拆解的起点申报跟踪表与卷宗清单（xlsx）现有证据的索引，谁的手里有什么先盘一遍III 期关键数据与文献口径（xlsx / docx）第 3 条对比分析的数据基础部门职责与外部资源表（xlsx · 星标）躺在这张表里的是「哪些活只能外委」—— 分工边界的依据

为什么这个场景值得做

优先级评分：痛感 5 × AI 适配 5 ÷ 落地难度 2 = 12.5

最大差异点：不要求先把发补通知拆成结构化任务表。通知 PDF 原件加现有证据文件直接进来，逐条拆解、逐条盘点证据现状，缺口与分工一次生成 —— 里程碑按 80 个工作日自动倒排，起始日落款日。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：发补缺口与分工台账.xlsx 总账本体 · 每条发补一页 · 含签批栏
• 可派发清单：证据位置索引.xlsx 可派发 · 证据在哪个文件哪个部门哪个版本
• 可派发清单：里程碑倒排表.xlsx 80 个工作日倒排 · 三级里程碑与冻结点

这套东西不承诺什么：不替人起草发补答复正文（技术判断与承诺措辞是注册与医学的责任）；不向 CDE 提交任何东西（沟通与递交走申请人之窗，由人操作）；80 个工作日的换算结果标注「不含法定节假日调整，以 CDE 认定为准」。想看具体怎么跑？Live Demo 里有一个完整案例的每一步，包括 Agent 在哪一步拦住了

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：澜屿生物医药（虚构）。2026-08-12 收到 CDE 发补通知（5 条，落款 2026-08-12），80 个工作日窗口从落款日起算、截止 2026-12-02。设定日期 2026-08-14：RA 经理要在8-26 的项目会上拿出每条发补的证据现状、责任部门、缺口与里程碑倒排。

发补条数5 条窗口截止12-02关键缺口3 项咨询窗口8-26 前

输入药企研发侧手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_发补通知原文.docx 五条发补的原文 · 一切拆解的起点申请人之窗下载 · 落款 2026-08-12（8-12 收到）
• 02_申报跟踪表与卷宗清单.xlsx 现有证据的索引 · 谁的手里有什么先盘一遍注册经理维护 · 发补当日已更新
• 03_证据现状盘点表.xlsx 逐条发补的证据覆盖度 · 差多少、差在哪RA 经理 8-13 初盘
• 04_部门职责与外部资源表.xlsx 哪些活只能外委 · 分工边界的依据项目管理部年度更新
• 05_申请人之窗往来摘录.docx 与审评机构的全部官方交互记录 · 咨询窗口的依据注册部归档 · 每次往来即归档

注意标橙色那一份 —— 04_部门职责与外部资源表.xlsx。它项目管理部年度更新，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这是 8 月 12 日的发补通知，五条，受理号 CXSS2600016。连同申报跟踪表和卷宗清单一起看。 每条发补拆成「要什么、已有什么、还缺什么、归谁」。里程碑按 80 个工作日从落款日倒排，截止 12 月 2 日。 外委还是自己做的建议只列成本和窗口风险，决定留给我们项目会。

发补拆解规则与工作日换算在能力包里。现场说清通知落款日，其余自动算。

触发事情是这么来的

落款 8-12 · 80 个工作日 · 8-26 项目会要交总账

发补原则上只提一次、必须一次按要求提交全部资料 —— 漏答一条等于白交。第三条要跟竞品 KP-32 对比，证据在临床、医学、注册三个部门手里，RA 一个人说不全，只能带着总账上会。

第 1 步 · 逐条拆解 · 五条发补各要什么

每条拆成「要什么证据、什么格式、归谁出」· 原文条款号保留

第 2 步 · 证据盘点 · 现有文件能答到哪一步

逐条对照卷宗清单 · 已有什么、在谁手里、哪个版本

这一步的看点 · 从上一个项目的发补里想起了教训上一个品种的发补答复把内部研讨版数据当成了定稿版引用，被 CDE 二次问询，当时补正多花了 20 个工作日。这次同样的特征—— 第三条要引用的 CSR 口径版本关系（12 例 vs 13 例）正在核对中 —— 总账里直接标「版本未定稿，先锁版本再引用」。这条不靠当年补正的人还在不在职。

第 3 步 · 缺口判定 · 差多少、差在哪

每条发补的缺口单列 · 缺数据、缺分析、缺签字各标建议责任方

第 4 步 · 分工与里程碑 · 80 个工作日倒排

落款日 2026-08-12 起算 · 跳过周末 · 三级里程碑加冻结点

这一步的看点 · 把技术动作翻译成钱外包整包 45 万 vs 分项外委（竞争格局专项 8.5 万 + 伦理顾问 1.6 万 = 10.1 万）—— 差价 34.9 万摆给管理层，同时把两条路的窗口风险各写一句：整包外包周期贴着窗口走，分项自建要多占内部约一个季度的人力。

第 5 步 · 留证与签批 · 生成项目会用的总账

每条发补一页 · 证据现状、缺口、责任方、里程碑

不讲省了多久 · 讲少了几个隐患、沉淀了什么

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

发补缺口清单与证据定位 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

deficiency-gaplist.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是药企研发侧手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁RA-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

• 01_发补通知原文.docx 五条发补的原文 · 一切拆解的起点
• 02_申报跟踪表与卷宗清单.xlsx 现有证据的索引 · 谁的手里有什么先盘一遍
• 03_证据现状盘点表.xlsx 逐条发补的证据覆盖度 · 差多少、差在哪下载
• ↓XLS04_部门职责与外部资源表.xlsx 哪些活只能外委 · 分工边界的依据
• 05_申请人之窗往来摘录.docx 与审评机构的全部官方交互记录 · 咨询窗口的依据

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这是 8 月 12 日的发补通知，五条，受理号 CXSS2600016。连同申报跟踪表和卷宗清单一起看。 每条发补拆成「要什么、已有什么、还缺什么、归谁」。里程碑按 80 个工作日从落款日倒排，截止 12 月 2 日。 外委还是自己做的建议只列成本和窗口风险，决定留给我们项目会。

为什么这么短就够了：发补拆解规则与工作日换算在能力包里。现场说清通知落款日，其余自动算。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• RA-02_发补缺口与分工台账.xlsx 总账本体 · 每条发补一页 · 含签批栏
• RA-02_证据位置索引.xlsx 可派发· 证据在哪个文件哪个部门哪个版本
• RA-02_里程碑倒排表.xlsx 80 个工作日倒排 · 三级里程碑与冻结点 Skill 里固化了什么：从上一个项目的发补里想起了一个教训该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：发补通知原件（pdf / docx）五条发补的原文，一切拆解的起点申报跟踪表与卷宗清单（xlsx）现有证据的索引，谁的手里有什么先盘一遍III 期关键数据与文献口径（xlsx / docx）第 3 条对比分析的数据基础部门职责与外部资源表（xlsx · 星标）躺在这张表里的是「哪些活只能外委」—— 分工边界的依据

人工边界：不替人起草发补答复正文（技术判断与承诺措辞是注册与医学的责任）；不向 CDE 提交任何东西（沟通与递交走申请人之窗，由人操作）；80 个工作日的换算结果标注「不含法定节假日调整，以 CDE 认定为准」。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

注册事务 · 产出即下一步输入

RA-01 · BLA 卷宗模块间一致性核对 — 每个模块单看都对 · 合在一起讲的是三个略有出入的故事 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。