本规划面向高校计算机学院团队，用于回答三个问题：在量子通信跨学科合作中，计算机学院主导的三块内容分别做什么、怎么做、什么时间交付什么。
三类读者可按需取用：
文中所有功能条目均为可独立立项、可独立交付的工作包，括号内标注的是该条目的主要成果形态。
本章先厘清三个方向各自的定位与边界，再说明它们共用的底层资产，最后交代与物理学院的衔接关系。这三件事决定了后续所有具体工作能否被评审与团队同时理解。
三个方向不是并列的三套系统，而是同一条技术链条上的三个时间切面。区分它们的关键不在技术栈，而在所回答的问题：
| 方向 | 回答的问题 | 工作模式 | 作用对象 | 数据依赖 | 启动门槛 |
|---|---|---|---|---|---|
| 量子仿真引擎 | 如果……会怎样？ | 离线推演 | 假设中的系统 | 低（可独立启动） | 低 |
| 数字孪生平台 | 现在怎么样？ | 在线映射 | 真实运行的链路 | 高（须真实链路） | 高 |
| 自动化安全测评 | 达标吗？守得住吗？ | 对照标准的验证与度量 | 待测的制品与系统 | 中（须设备或高保真仿真） | 中 |
三者的依赖关系是：仿真引擎是塔基，测评平台是标尺，孪生平台是塔尖。 没有仿真引擎，测评平台缺少可控的攻击注入手段；没有测评平台，孪生平台的诊断结论缺乏可信度背书；而孪生平台反过来为前两者提供真实的运行数据与故障样本。这是一个闭环，但闭环的建立顺序必须是自下而上的。
在项目申报书中，"仿真""孪生""测评"极易被评审专家归并为一句"都是软件平台"，从而认为是一个内容拆成三份写，稀释创新度。破解办法是同时给出三个维度上的区分。
第一，时间性。仿真引擎处理的是尚未发生的假设情形，可以反复、穷举、并行地跑；孪生平台处理的是正在发生的真实状态，数据单向流入、不可重跑；测评平台处理的是已存在的制品，输出的是判定结论。
第二，对象的真实性。仿真引擎的对象是模型，孪生平台的对象是真实链路，测评平台的对象是被测系统。三者的"真值"来源完全不同：仿真的真值来自理论，孪生的真值来自传感器，测评的真值来自标准。
第三，输出形态。仿真引擎输出概率分布与安全边界（"在该参数下密钥率为 0.8 Mbps 以上的概率是 92%"）；孪生平台输出状态与预测（"当前健康度 83 分，预计 40 天后探测器效率跌破阈值"）；测评平台输出判定与分项得分（"接口符合性 12 项中 10 项通过，2 项不符合，安全问题 1 项高危"）。
建议做法：在申报书中明确写出上面这张对比表，并加一句话——"三者共用同一套物理模型库与数据集，是同一平台的不同工作模式，而非三个独立系统。" 这一句话既说清了关系，又保住了三块的独立创新点。
三个方向之所以能称为"一个平台"，是因为它们共享同一套底层资产。这套底座本身就是一项可申报的内容，也是全平台最难被复制的部分：
| 序号 | 共享资产 | 构成 | 服务的三个方向 |
|---|---|---|---|
| 1 | 物理与器件模型库 | 光纤信道模型、探测器模型、光源模型、器件老化模型 | 仿真、孪生 |
| 2 | 协议实现库 | BB84／诱骗态／B92／E91／MDI／TF／CV 的参考实现与后处理算法 | 仿真、测评 |
| 3 | 攻击场景库 | PNS、致盲、时移、木马等攻击的参数化模型与复现脚本 | 仿真、测评 |
| 4 | 测试数据集与标注规范 | 正常态与攻击态的时序数据集、标签体系、划分基准 | 仿真、孪生、测评 |
| 5 | 仿真与 AI 代理模型 | 高保真仿真模型、密钥率预测代理模型、异常检测模型 | 仿真、孪生、测评 |
| 6 | 接口规范 | KMS 密钥服务接口、SDN 控制与编排接口、采集接口 | 孪生、测评 |
这里有一个必须写进申报书的判断：这三块真正的壁垒不是代码，而是数据资产。 仿真内核、可视化框架、时序数据库都有成熟开源方案，任何团队都能拼出一个"看起来能用"的平台；但器件参数库、攻击数据集、测评基线无法速成，只能靠持续积累。因此申报时应当把"数据资产建设"单独作为一项研究内容或考核指标写出来，而不是隐藏在平台建设里。
物理学院与计算机学院在这三块上的关系是互为供给，不是单向配套。
物理学院向计算机学院提供：器件实测参数（探测器效率、暗计数、光学损耗）、链路实测运维数据（光功率、QBER、密钥率时序）、攻击实验样本（真实攻击下的异常波形或日志）、协议物理实现细节（用于仿真建模的工艺参数）。
计算机学院向物理学院提供：仿真设计工具（链路参数预评估，减少实验试错）、安全靶场（在仿真环境中预演攻击，再上真实链路验证）、测评平台（对自研器件与协议做标准符合性自测）、参数标定服务（用实测数据反演器件参数）。
关键机制建议：把"数据"作为交换的硬通货。第一阶段最该做的事不是关起门写引擎，而是先做出一个能替物理实验室省事的仿真工具，用它换取实测参数与链路数据。数据一旦积累起来，第二、三阶段就有了不可替代的基础。交换关系建议以书面形式固定（见附录 B 模板）。
仿真引擎是平台的地基，也是最容易独立启动的一块。本章给出六个功能模块、六条研发路线、版本节奏与考核指标，并单独说明"量子计算模拟器"这条容易被混淆的岔路。
量子仿真引擎用于在不接入真实硬件的前提下，对量子通信链路与网络的性能、安全性进行量化推演。它的核心价值是：让"这条链路能不能用""这种攻击下还安不安全""扩容到 10 个节点后密钥够不够用"这类问题在几分钟内得到有依据的数值回答，而不是等实验做完才知道。
需要先澄清一个岔路：物理学院在座谈中提到的"数字机"，如果指的是量子计算模拟器（模拟量子线路与量子态演化），那属于另一条技术子线，见本章第四节。它同样是计算机学院可以完整承接的内容，但技术栈与本节不同，不建议混为一谈。本节主体论述的是量子通信侧的仿真。
以下六个功能模块均可独立立项、独立交付。其中第四项（攻击与缺陷注入）是全平台最有价值的资产生产环节，建议优先投入。
功能描述：对量子信道与探测环节建立参数化的物理模型，输出给定条件下的期望误码率与计数率，是一切上层计算的基础。
建模对象：光纤衰减系数、色散、偏振模色散与偏振漂移、相位漂移、探测器探测效率、暗计数率、死时间、后脉冲概率、光学器件插入损耗；自由空间场景下还包括大气湍流强度与背景光噪声。
输入：器件规格参数、实测标定参数、环境条件（温度、链路长度、铺设方式、架空或地埋）。输出：给定距离与配置下的期望 QBER、单光子计数率、密钥率曲线。
技术要点：参数必须可标定而非写死为常数；支持参数不确定度的传播分析（给出置信区间而非单点值）；支持按波长与探测器类型切换模型。这三条决定了仿真结果能否被实验人员采信。
功能描述：对 QKD 协议从量子态制备到最终密钥输出的全过程做时序级模拟，输出各阶段的时间开销与资源占用。
覆盖协议：BB84（含诱骗态）、B92、E91（纠缠类）、MDI-QKD（测量设备无关）、TF-QKD（双场）、CV-QKD（连续变量）。
协议阶段：态制备 → 信道传输 → 测量 → 基矢比对（筛选）→ 参数估计 → 纠错 → 隐私放大 → 密钥输出。
技术要点：后处理算法（纠错与隐私放大）须做成可插拔模块，因为不同算法对最终密钥率影响极大，也便于引入自研算法做对比实验；须支持有限码长分析，渐进假设下的结论在小样本场景会显著乐观；须支持并发会话模拟。
功能描述：在给定的攻击假设与信道参数下，计算安全性的边界，输出"安全区域"。
计算内容：渐进密钥率与有限码长密钥率、QBER 与密钥率的对应关系、PLOB 界（无中继场景下的信道容量上界）、集体攻击与相干攻击模型下的密钥率下界。
输出：安全区域图——横轴为距离、纵轴为 QBER 的平面上，标出安全区与不安全区的分界，以及不同攻击假设下的多条分界线。
技术要点：引入有限码长修正项是体现专业性的关键；支持多攻击假设的并列呈现（保守界与乐观界同时给出）；计算过程可复现。
功能描述：把攻击模型与器件非理想性作为可配置插件注入仿真链路，生成带标签的攻击数据集。
攻击类型：光子数分离攻击（PNS）、探测器致盲攻击、时间移位攻击、木马光注入攻击、波长依赖分束攻击、探测效率不匹配攻击、死时间攻击、同步攻击。
输出：带攻击类型与强度标签的多维时序数据集，可直接用于攻击检测算法的训练与测评基准的建立。
技术要点：攻击须参数化（强度、时机、组合方式可调），而非只能开关；支持组合攻击（多个攻击同时施加，检测难度显著上升）；建立数据集标注规范，这是数据集能被外部使用的前提。
这一项是全平台最有价值的资产生产环节。 攻击数据集在公开领域极为稀缺（因涉及真实设备与实验条件），一旦形成规模并规范化，将成为对外合作与论文发表的强筹码。
功能描述：从单链路扩展到多节点网络，并与经典通信网络做联合仿真。
网络层内容：可信中继链、量子中继（量子存储与纠缠交换）、密钥路由与供给调度、密钥池管理与耗尽策略、与 SDN 控制器的交互。
与经典网的耦合：QKD 生成的密钥作为经典加密业务的密钥源，需在仿真中匹配"业务流量模型"与"密钥消耗速率"——这是判断一条量子网络能否支撑实际业务的关键计算。
技术要点：网络部分建议复用成熟网络仿真器的协议栈，将 QKD 模块作为新协议层接入，避免重造网络层；密钥调度算法是主要的自研创新点，也是可发表内容。
功能描述：让仿真引擎与真实链路对接，用实测数据反演器件参数，形成参数库。
工作模式：离线标定（用历史实测数据拟合模型参数）→ 在线在环（仿真与真实链路并行运行，用于预测与预警）。
输出：标定后的器件参数库，按厂商、型号、批次、环境条件分类。
技术要点：需要参数辨识算法与拟合优度评估方法；参数须做版本管理（同一器件在不同批次、不同老化阶段参数不同）；这一环节是"仿真可信度"的证据来源，建议配套发布"仿真与实测对照报告"。
如果物理学院所说的"数字机"指的是量子计算方向的模拟器，则构成一条独立子线，内容同样完整且可由计算机学院独立承接。
功能构成：量子态演化模拟、门级线路模拟、噪声模型（退相干、门错误、读出错误）、张量网络近似模拟、OpenQASM／QIR 互操作、GPU 与 HPC 加速。
研发路线：复用 QuTiP（开放量子系统）、Qiskit Aer 与张量网络库做基础；自研价值集中在噪声模型标定（与真实量子硬件对照）、大规模态模拟的并行分解策略、以及与本地 HPC 集群的调度适配。
建议：这条子线可独立立项，不必等物理学院的链路条件。但需要主动在座谈中提出来，否则容易被含混地归入"仿真"一项而被忽略。
六条路线中，R1 与 R2 决定技术选型的正确性，R3 决定成果可信度，R4 是最主要的可发表创新点。
| 编号 | 路线 | 具体做法 | 备注 |
|---|---|---|---|
| R1 | 仿真内核选型 | 采用离散事件仿真内核，物理模型以插件形式挂载 | 不自研内核，避免重复造轮子 |
| R2 | 复用成熟生态 | 网络层用 ns-3／OMNeT++／SimQN，物理层用 QuTiP／NetSquid，后处理复用开源 LDPC 与 Cascade 实现 | 自研价值在参数库与校准，不在框架 |
| R3 | 精度校准闭环 | 与物理实验室实测数据拟合，建立参数辨识流程 | 尽早启动，决定后续可信度 |
| R4 | 加速与代理模型 | GPU 并行蒙特卡洛；用神经网络训练"参数→密钥率"代理模型，把单次评估从分钟级降到毫秒级 | 主要可发表创新点 |
| R5 | 场景与用例库 | 攻击场景、组网场景、标准符合性场景全部配置化 | 与测评平台共用，避免二次开发 |
| R6 | 开放接口与可复现 | Python API 与配置文件驱动，固定随机种子，任意结果可一键复现 | 可复现性是测评平台的基础 |
版本节奏建议：
考核指标的设定原则是可度量、可验证。软件类成果以覆盖范围与性能指标衡量，数据类成果以规模与规范程度衡量。
| 交付物 | 形态 | 建议考核指标 |
|---|---|---|
| 量子仿真引擎 | 软件（可申请软著） | 支持协议数不少于 6 种；单链路仿真耗时；网络节点规模不少于 10 个 |
| 器件参数库 | 数据资产 | 覆盖器件类型不少于 5 类；完成实测校准的型号数 |
| 攻击数据集 | 数据资产 | 攻击类型不少于 8 种；标注样本量；组合攻击场景数 |
| 仿真与实测对照报告 | 技术报告 | 关键指标（密钥率、QBER）的相对误差 |
| 学术论文 | 论文 | 代理模型加速、网络密钥调度方向各 1 篇 |
| 标准建议稿 | 标准文档 | 参与仿真与测评相关团体标准 |
数字孪生是三块中启动条件最硬的一块。本章先给出功能与路线，再单独说明它的启动前提——如果前提不成立，这项工作应当推迟。
数字孪生平台是把真实 QKD 链路映射为可实时监测、可回溯、可预测的数字镜像，服务于运行维护与故障诊断。它与仿真引擎最本质的区别是：孪生体内的参数不是"设定"的，而是"测出来"的。
在申报材料中，建议把数字孪生明确定义为"带实时数据注入的仿真模型"——这一定义既准确，又能自然地把三者串成一个体系，避免评审认为孪生是另起炉灶。
六个功能中，前四项构成完整的"采集—评估—诊断"链路，后两项决定平台能否真正投入运行使用。
功能描述：持续采集真实链路的运行指标，构建与实体链路一一对应的数字镜像。
采集对象：设备运行状态、光功率、QBER、密钥率、密钥池余量、偏振状态、温度、告警事件。
采集方式：SNMP、NETCONF、gRPC、串口以及厂商私有接口；需建统一的协议适配层屏蔽差异。
技术要点：时钟同步（NTP 或 PTP）；采集周期可配置（秒级）；采集通道本身不得影响被采集链路的正常运行——这一条在涉密或生产环境中是硬要求。
功能描述：对全部指标做完整存证，支持趋势分析与异常事件的回放重演。
技术要点：降采样与压缩策略（原始数据量大，需分级存储）；保留策略需满足事后审计要求；事件回放须能做到"按时间轴重演当时的状态"，这是故障定责与攻击复盘的关键能力。
功能描述：综合机理模型与数据模型，评估链路健康度并定位疑似故障点。
双路径设计：机理模型路径基于光功率预算与 QBER 变化率做物理推断（可解释但不够灵敏）；数据驱动路径基于历史基线做偏差检测（灵敏但可能误报）。两路交叉验证，仅在两者一致时输出高置信度结论，可显著降低误报。
输出：健康度评分、疑似故障点、置信度、支撑证据。
功能描述：在孪生体上复现各类攻击的特征，与实时数据比对，给出"攻击嫌疑"提示。
定位说明：孪生平台的输出是嫌疑提示，不是定性结论。定性需由测评平台的攻击检测模块给出。这一分工建议在平台设计中明确，避免功能重叠。
价值：可以在完全不触碰真实链路的前提下完成攻击推演，这在运行中的生产链路上是唯一可行的做法。
功能描述：预测器件老化趋势与密钥率衰退，输出维护与割接建议。
预测对象：探测器效率衰减曲线、光源功率下降、光学连接点损耗漂移；由此推导密钥率衰退趋势与剩余可用寿命。
输出：更换或割接的时间建议、备件需求建议。
功能描述：打通告警到处置的完整流程，并提供链路拓扑与站点的可视化呈现。
流程：告警产生 → 工单派发 → 处置记录 → 归档复盘。
配置下发：与 SDN 控制器联动实现参数下发，但下发权限必须受限（见第九章保密要求），且所有下发操作须留痕。可视化：链路拓扑、站点分布、设备面板、关键指标看板。
T4 是主要的算法创新点，T6 决定平台能否满足涉密项目的合规要求，两者建议同步推进。
| 编号 | 路线 | 具体做法 |
|---|---|---|
| T1 | 划清孪生与仿真的边界 | 两者共用同一套物理模型与参数库，孪生是"接入了实时数据的仿真" |
| T2 | 机理与数据双驱动建模 | 光路机理模型与数据模型互为校验、互相补位，是降低误报的关键设计 |
| T3 | 实时数据接入与时钟同步 | 多协议适配层与统一时间基准，须保证采集不影响主链路 |
| T4 | 图神经网络故障传播分析 | 将网络拓扑建模为图，做故障传播路径分析与根因定位 |
| T5 | 平台工程化 | 时序数据库、容器编排、三维可视化，支持多链路多站点扩展 |
| T6 | 保密与隔离设计 | 数据分级脱敏、演示态与生产态物理隔离（详见第九章） |
数字孪生是三个方向中启动条件最硬的一块，申报时须明确写出前提条件，否则评审会质疑可行性：
因此建议：数字孪生放在第二阶段末启动，并以横向项目（为运营商或行业专网建设运维监测平台）作为载体。 在没有链路的条件下强行推进，做出来的只是一个三维可视化演示，在评审中是负分项。
孪生类成果的考核重点在"是否真的接入了链路"，而非功能数量。建议把示范运行时长列为核心指标。
| 交付物 | 形态 | 建议考核指标 |
|---|---|---|
| 数字孪生系统 | 软件（可申请软著） | 采集协议不少于 4 种；数据同步延迟；支持的链路与站点数 |
| 健康度评估模型 | 算法与模型 | 故障定位准确率、误报率、平均定位时间 |
| 预测性维护模型 | 算法与模型 | 关键器件剩余寿命预测误差 |
| 运维监测平台 | 系统与横向交付 | 现场部署数、示范运行时长 |
| 示范工程 | 示范应用 | 示范链路数、可对外演示的完整场景 |
| 学术论文 | 论文 | 图神经网络故障传播方向 1 篇 |
三块之中，这一块的对外出口最明确：它可以作为第三方测评服务对外提供，且国际与国内标准编号现成。本章给出功能与路线，并特别提醒表述上的分寸。
自动化安全测评是把量子通信系统的安全性评估做成标准化、可复现、可自动执行的测评体系。三块之中，这一块的对外出口最明确：它可以作为第三方测评服务对外提供，且国际与国内标准编号现成，是申报时最容易被采信的内容。
需要强调一个表述上的分寸：标准是测评的依据，不是成果本身。 成果是测评平台的自动化能力、测试用例库、攻击检测算法与评分基线。这一点在撰写申报书时极易出错（详见第七章第三节）。
六个功能中，第一项与第六项构成测评平台的骨架，第二至五项是可按需扩展的测试能力模块。
功能描述：依据现行标准对被测系统的接口与行为做自动化比对，输出符合性报告。
依据标准：ETSI GS QKD 014（密钥投递与 KMS 接口）、GS QKD 015（SDN 控制接口）、GS QKD 018（SDN 编排接口）、GS QKD 020（可互操作 KMS API）；ISO/IEC 23837（量子密钥分发的安全性评估要求）；ITU-T Y.3800 系列（量子密钥分发网络架构）。
测试内容：接口一致性、字段完整性与取值范围、错误码定义、时序要求、异常处理行为。
技术要点：标准条款需转化为可执行的测试用例（这是本功能的核心工作量，也是积累性资产）；支持标准版本升级带来的用例更新管理。
功能描述：针对密钥管理服务的接口层做安全性测试。
测试项：身份认证与鉴权（身份伪造、越权调用、凭证重放）、密钥生命周期完整性（生成、分发、更新、销毁、归档各环节）、密钥唯一性与并发安全（高并发下是否存在密钥重复下发）、异常输入处理。
技术要点：需要与被测系统建立受控的连接通道，测试过程须全程留痕；对生产系统的测试须在预生产环境或仿真环境进行。
功能描述：自动化编排侧信道攻击链，检测被测系统是否存在相关脆弱性。
攻击链结构：准备（建立连接、采集基线）→ 注入（施加攻击）→ 观测（采集响应数据）→ 判定（比对特征）。
检测对象：探测器致盲、时间移位、木马光注入、光子数分离等。输出：检测结果、攻击指纹、复现脚本。
技术要点：攻击编排须可配置（不同被测对象需要不同的攻击参数）；检测判定需有明确的阈值依据；需与物理学院配合——真实器件级攻击施加往往需要物理侧设备。
功能描述：对 QKD 输出的密钥做质量与随机性检验。
依据：NIST SP 800-22（随机性统计测试套件）、GM/T 0005（国内随机性检测规范）。
测试项：随机性统计检验、熵源评估、密钥重复率与相关性检查、在线退检（在密钥生成过程中持续抽检，发现质量下降即告警）。
技术要点：在线退检是区别于离线检测的关键能力，需在密钥生成链路上嵌入检测点而不影响吞吐。
功能描述：用形式化方法证明协议在给定攻击者模型下的安全性，并与实测结果互证。
工具：ProVerif、Tamarin。目标：证明协议在 Dolev-Yao 模型（攻击者可完全控制信道）下满足密钥保密性与认证性。
与实测互证的方法：形式化验证给出安全性的下界（在理想模型下一定安全），实测攻击给出上界（在真实器件上实际可被攻破的程度），两者结合形成完整的安全论证区间。这个"下界—上界"的论证结构本身就是一个值得写进申报书的方法论创新点。
功能描述：把测评流程配置化，建立评分模型与基线库，自动生成测评报告。
用例 DSL：将测评流程抽象为可配置用例（前置条件、执行步骤、预期结果、判定规则），使新增被测对象时无需修改代码。
评分模型：分项得分（接口符合性、密钥质量、抗攻击性、实现健壮性）与综合等级。基线库：对同一被测对象的不同版本建立基线，实现版本间对比与退化检测。
技术要点：报告须自动生成且结论可追溯（每个结论都能定位到具体用例与原始数据）；结果可复现是测评服务能被第三方采信的前提。
S1 是测评平台的核心竞争力所在，S5 决定这一方向能否形成对外服务能力。
| 编号 | 路线 | 具体做法 |
|---|---|---|
| S1 | 用例 DSL 与编排引擎 | 测评流程配置化，驱动异构被测设备；这是测评平台的核心竞争力 |
| S2 | 设备驱动适配层 | 屏蔽各厂商 QKD 与 KMS 接口差异，统一测评入口 |
| S3 | 机器学习攻击检测 | 从时序指标中提取攻击指纹，做异常检测与攻击类型归因 |
| S4 | 形式化与实测互证 | 形式化证下界、实测验上界，形成完整安全论证区间 |
| S5 | 测评规范与标准参与 | 从团体标准与测评规范建议稿入手，逐步争取第三方测评资格 |
| S6 | 安全靶场与数据集 | QKD 安全靶场、攻防演练、攻击数据集开放共享 |
下表是测评平台可直接引用的标准清单。需要提醒的是，这张表在申报书里应出现在"研究基础"或"技术依据"部分，而不应出现在"创新点"部分。
| 标准 | 组织 | 与本平台的关系 |
|---|---|---|
| GS QKD 014 | ETSI | 密钥投递与 KMS 接口，符合性测试的主要依据 |
| GS QKD 015 | ETSI | SDN 控制接口，网络级测评依据 |
| GS QKD 018 | ETSI | SDN 编排接口，网络级测评依据 |
| GS QKD 020 | ETSI | 可互操作 KMS API |
| ISO/IEC 23837 | ISO／IEC | 量子密钥分发的安全性评估要求，测评方法论依据 |
| ITU-T Y.3800 系列 | ITU-T | 量子密钥分发网络架构，架构符合性依据 |
| GM/T 0005 | 国内密码行业 | 随机性检测规范，密钥质量测评依据 |
| NIST SP 800-22 | NIST | 随机性统计测试套件 |
参与路径建议：直接进入国际标准制定门槛极高，建议按"测评规范建议稿 → 团体标准 → 行业标准"的阶梯推进。同时，在申报材料中可写"依据国际标准形成测评能力"，但不可写"制定国际标准"。
测评方向的考核指标应包含服务性指标（对外服务次数），这是区别于纯研究项目的关键。
| 交付物 | 形态 | 建议考核指标 |
|---|---|---|
| 自动化测评平台 | 软件（可申请软著） | 覆盖标准条款数；支持设备型号数；单次完整测评耗时 |
| 测评用例库 | 数据资产 | 用例数量；覆盖的标准与场景范围 |
| 评分基线与等级模型 | 方法与模型 | 基线覆盖的版本数；评分与专家评审的一致性 |
| 攻击检测模型 | 算法与模型 | 检测准确率、误报率、归因正确率 |
| 测评规范建议稿 | 标准文档 | 提交团体标准立项数 |
| 测评服务 | 横向服务 | 服务次数、服务对象数 |
底座不应与三个方向并行铺开，而应按"谁先被需要谁先建"的顺序推进。本章给出建立顺序，并说明为什么数据资产值得单独立项。
底座建设不应与三个方向并行铺开，而应按"谁先被需要谁先建"的顺序推进：
| 顺序 | 资产 | 建立时机 | 触发条件 |
|---|---|---|---|
| 1 | 物理与器件模型库 | 第一阶段 | 仿真引擎 v1 需要 |
| 2 | 协议实现库 | 第一阶段 | 仿真引擎 v1 需要 |
| 3 | 攻击场景库 | 第二阶段 | 仿真引擎 v2 与测评平台同时需要 |
| 4 | 测试数据集与标注规范 | 第二阶段 | 攻击数据集生成时一并建立 |
| 5 | 仿真与 AI 代理模型 | 第二阶段 | 代理模型加速与检测模型训练需要 |
| 6 | 接口规范 | 第二至三阶段 | 孪生平台与测评平台的数据交互需要 |
明确一个判断：平台之间的竞争最终落在数据资产上。 具体表现为三点。
第一，代码可复制，数据不可。 仿真框架、可视化组件、时序数据库都是公开技术，竞争对手可以快速实现相似功能；但一套经过实测校准的器件参数库、一套规模化的标注攻击数据集，需要真实的设备、真实的环境和持续的时间投入，无法速成。
第二，数据是合作的筹码。 在跨学院合作中，掌握数据的一方拥有主动。计算机学院应当通过"提供工具"换取物理学院的实测数据，而不是反过来。
第三，数据本身可以独立产出成果。 数据集可以发表（数据集论文）、可以共享（建立行业影响力）、可以作为测评服务的基准（形成事实标准）。
建议做法：在申报书中把"建设开源开放的量子通信仿真与测评数据集"作为一项独立研究内容，并设定明确的规模指标。这比写"建设平台"更具体、更容易被评审采信。
三个方向不是平行推进的，它们的启动条件差异很大。本章给出三阶段路线、交付物清单与里程碑检查点。
阶段一（0 至 6 月）：仿真引擎最小闭环。目标是尽快形成"可演示、可验证"的成果，同时启动与物理学院的数据交换。这一阶段不追求功能完整，追求闭环跑通。具体包括：完成单链路 BB84 诱骗态仿真，输出密钥率曲线与 QBER 关系曲线；与物理实验室实测数据做首次对照，形成误差评估报告；建立器件参数库 v0（覆盖 5 类以上器件）；交付一个可现场演示的最小场景。
阶段二（6 至 18 月）：仿真引擎 v2 与测评平台 v1。 这一阶段是功能扩张期，两个方向并行推进，共用攻击场景库与用例库。仿真引擎 v2 完成网络级组网与密钥调度、攻击参数化与组合注入、攻击数据集生成、代理模型加速；测评平台 v1 完成标准符合性测试、KMS 接口安全测评、用例 DSL 与编排引擎；同时提交测评规范建议稿，启动团体标准立项；数字孪生平台在此阶段末启动，以横向项目为载体。
阶段三（18 至 36 月）：测评平台 v2 与数字孪生平台 v1。 测评平台 v2 完成侧信道攻击检测、形式化与实测互证、评分基线与报告自动化；数字孪生平台 v1 完成一条示范链路的实时映射、健康度评估与故障定位；形成可对外展示的完整示范工程；争取第三方测评服务资格。
下表可直接作为申报书的"进度安排"部分或团队任务书的骨架。
| 阶段 | 时间 | 主要交付物 | 验收口径 |
|---|---|---|---|
| 一 | 0 至 6 月 | 仿真引擎 v1、器件参数库 v0、仿真与实测对照报告 | 单链路密钥率预测与实测相对误差在可接受范围；可现场演示 |
| 二 | 6 至 18 月 | 仿真引擎 v2、测评平台 v1、攻击数据集 v1、测评规范建议稿 | 网络节点规模不少于 10 个；攻击类型不少于 8 种；标准条款覆盖率达到设定目标 |
| 三 | 18 至 36 月 | 测评平台 v2、数字孪生系统 v1、示范工程、第三方测评服务 | 示范链路稳定运行；测评服务完成对外交付 |
建议每个里程碑都设一个明确的检查问题，用于判断是否具备进入下一阶段的条件。
| 时间点 | 里程碑 | 检查要点 |
|---|---|---|
| 第 3 月 | 仿真核心跑通 | 能否输出可解释的密钥率曲线 |
| 第 6 月 | 首次实测对照 | 仿真与实测的偏差是否在可接受范围，偏差原因是否已解释 |
| 第 12 月 | 攻击数据集成规模 | 数据规模、标注质量、是否具备对外共享条件 |
| 第 18 月 | 测评平台可用 | 能否对一台真实设备完成一次完整自动测评 |
| 第 24 月 | 孪生原型上线 | 是否接入真实链路、数据同步延迟是否达标 |
| 第 36 月 | 示范与对外服务 | 示范工程是否可展示、测评服务是否已产生横向收入 |
同一套技术内容，写法不同，评审结论可能完全相反。本章给出申报口子的选择、成果认定规则，以及五种必须避开的表述。
同一个科学问题拆成两个本子申报，互为支撑而不冲突：
| 侧 | 建议申报方向 | 文本口径要点 |
|---|---|---|
| 物理学院 | 物理口（量子光学、原子分子物理方向） | 器件性能突破、协议物理实现、实验演示、安全性物理证明 |
| 计算机学院 | 信息口（计算机科学、人工智能、网络与信息安全方向） | 可复用平台、数据资产、算法方法、标准与测评体系 |
计算机学院文本的写作要点：
跨学院合作最容易在一年后因成果分配产生分歧，建议在启动前以书面形式约定：
| 成果类型 | 归属建议 | 说明 |
|---|---|---|
| 大论文（双方共同署名） | 双通讯作者或共同第一作者 | 按实际贡献排序，前置约定 |
| 计算机侧主导的论文（仿真、AI 检测、形式化、密钥调度） | 计算机学院主导 | 物理侧按贡献挂名 |
| 物理侧主导的论文（器件、协议物理实现、实验） | 物理学院主导 | 计算机侧按贡献挂名 |
| 软件著作权与平台 | 计算机学院 | 平台代码由计算机侧编写 |
| 器件与协议物理实现 | 物理学院 | — |
| 数据资产（参数库、攻击数据集） | 共有 | 使用范围、署名方式、对外共享条件写入协议 |
| 横向项目与技术服务收入 | 按贡献分配 | 前置约定分配比例 |
以下五种表述在申报书中出现，会被评审直接质疑。
第一，把标准编号当创新点。例如写"本平台支持 ETSI GS QKD 014 标准"——这是符合性描述，不是创新。应改为"形成了将 ETSI GS QKD 014／015／018 标准条款自动转化为可执行测试用例的方法"。
第二，三个方向写成一个东西拆三次。必须在总纲中明确写出三者的边界（见第一章第二节对比表），否则会被认为内容重复。
第三，只写平台不写数据资产。"建设一个仿真平台"是工程表述；"构建经实测校准的器件参数库与规模化标注攻击数据集"是研究表述。后者更容易被采信，也更能体现不可替代性。
第四，把自研仿真内核当卖点。评审专家中若有仿真背景，会立即指出 ns-3、OMNeT++、SimQN、QuTiP 等已有成熟方案，自研内核属于重复投入。应改为"面向量子通信的器件参数标定方法与仿真精度校准技术"。
第五，把数字孪生写成不依赖真实链路的独立系统。没有链路的孪生体在技术上是空转的，评委会直接问"孪生体镜像的是哪条链路、数据从哪来、同步延迟多少"。必须在文本中明确写出依托的真实链路或示范工程。
本章给出可直接使用的任务分派矩阵、人员配置建议与协作机制，用于团队内部派活与考核对应。
矩阵按"工作包"粒度拆分，每个工作包都对应一个可独立交付、可独立署名成果的最小单元。
| 方向 | 工作包 | 所需能力 | 建议人数 | 外部依赖 |
|---|---|---|---|---|
| 仿真引擎 | 物理建模与信道模型 | 物理建模、数值计算、Python／C++ | 2 人 | 物理学院提供器件参数 |
| 仿真引擎 | 协议实现与后处理 | 密码学、编码理论、算法实现 | 1 至 2 人 | — |
| 仿真引擎 | 攻击注入与数据集生成 | 信息安全、实验设计 | 1 人 | 物理学院提供攻击样本 |
| 仿真引擎 | 加速与代理模型 | 机器学习、GPU 并行计算 | 1 人 | — |
| 数字孪生 | 数据采集与适配层 | 网络协议、后端开发 | 1 至 2 人 | 运维方开放接口 |
| 数字孪生 | 诊断与预测模型 | 机器学习、图神经网络、时序分析 | 1 至 2 人 | — |
| 数字孪生 | 平台工程与可视化 | 前端、时序数据库、容器编排 | 1 至 2 人 | — |
| 安全测评 | 用例 DSL 与编排引擎 | 软件架构、后端开发 | 1 至 2 人 | — |
| 安全测评 | 标准解读与用例转化 | 标准研读、密码学 | 1 人 | — |
| 安全测评 | 形式化验证 | 形式化方法、协议分析 | 1 人 | — |
| 安全测评 | 攻击检测算法 | 机器学习、异常检测 | 1 人 | — |
| 共性 | 数据资产管理 | 数据工程、标注规范设计 | 1 人 | — |
| 共性 | 标准与文档 | 标准研读、技术写作 | 1 人 | — |
核心原则是"每人负责一个可独立交付的工作包"，这既便于考核，也便于成果认定。
协作机制的四个要点都是为了让一年后的成果认定不产生争议。
量子通信项目往往涉及保密要求，且这一要求会贯穿平台建设全过程。建议在规划阶段就把保密设计作为一项独立研究内容，而非事后补丁。
分级的目的是明确哪些数据可以进仿真、哪些只能进演示环境。
| 级别 | 内容示例 | 处理要求 |
|---|---|---|
| 公开 | 公开论文数据、仿真默认参数 | 可自由使用 |
| 内部 | 器件参数、仿真配置、性能指标 | 内部流转，不外传 |
| 涉密 | 真实链路拓扑、实际部署位置、单位信息、精度指标 | 严格受控，脱敏后使用 |
平台必然涉及界面展示、报表导出、对外演示等环节，脱敏应当作为平台的基础能力而非附加功能。建议采用三档强度：
| 档次 | 做法 | 适用场景 |
|---|---|---|
| 静态别名 | 人名、单位名、地名、设备编号映射为代号，同一实体全文统一 | 界面文案、报表、截图 |
| 动态模糊 | 密钥率、距离、坐标区间化与量级化；号码部分屏蔽；小样本聚合 | 演示、教学、对外汇报 |
| 语义重构 | 拓扑结构、节点数、层级关系、精确时间重写，使用完全虚构但拓扑等价的演示数据集 | 示范工程、公开案例 |
架构要点：脱敏的判定与替换必须发生在服务端，客户端只接收代号与脱敏值。任何"客户端拿到真实值再替换"的方案都无效——真实值一旦到达客户端，即可通过开发者工具、缓存、截图、剪贴板、导出文件等途径获取。
兜底原则：策略缺失或解析异常时，必须回退到"屏蔽"而不是"显示原值"（fail-closed）。这一条在编码实现中极易写反，建议列为代码评审的专项检查项。
映射表管理：别名映射表等同于密码本，须加密存储、独立于代码仓库（不得提交至版本管理）、访问留痕、变更走审批。
对外演示与论文配图不能使用真实数据。建议在第二阶段同步建设一套完全虚构但拓扑结构等价的演示数据集：节点数量、链路层级、指标量级与真实场景保持一致，但所有可识别信息（名称、位置、编号、时间）均为虚构。这套数据集本身也可以作为共享资产对外提供。
验收方法建议不停留在"界面上看起来没有真名"，而是采用推理自查：将脱敏后的材料交给一位不了解情况的人员，要求其回答四个问题——涉及哪个单位、在什么位置、规模多大、什么时间活动。 只要任一问题能被推断出，即视为脱敏不彻底。
这一方法同时可覆盖"关联去匿名化"风险：即使每个字段都已脱敏，多个字段的组合仍可能唯一定位一个实体。建议在脱敏策略中加入组合唯一性控制。
以下四条与前三节同等重要，且都属于"容易被忽略、出问题却最严重"的类型。
下表汇总八类主要风险。其中第 1、2、4 项属于机制性风险，建议在合作启动前就完成约定；第 3、5、8 项属于技术性风险，需要在阶段评审中重点跟踪。
| 序号 | 风险 | 表现 | 应对措施 |
|---|---|---|---|
| 1 | 边界不清导致重复投入 | 计算机学院跑去参与光路搭建，投入大而无产出 | 明确不做器件与光路，在合作协议中写清边界 |
| 2 | 考核体系不兼容 | 物理要论文影响因子，计算机要软著与横向，成果无法互认 | 启动前签成果认定协议（见第七章第二节） |
| 3 | 仿真精度不达标 | 仿真结论与实测偏差大，被质疑"数值不可信" | 尽早做实测校准，发布仿真与实测对照报告，公开误差范围 |
| 4 | 数据拿不到 | 物理实验室不愿开放实测数据 | 以工具换数据，先提供仿真工具与标定服务，再提数据需求 |
| 5 | 孪生无链路可用 | 没有长期运行的真实链路，孪生体空转 | 推迟至第二阶段末启动，以横向项目为载体；或先做半实物仿真态孪生 |
| 6 | 保密要求阻断对外展示 | 无法对外演示，影响项目验收与影响力建设 | 提前建设虚构演示数据集（见第九章第三节） |
| 7 | 标准参与门槛高 | 国际标准无法进入，标准成果缺失 | 从测评规范建议稿与团体标准入手，阶梯式推进 |
| 8 | 数据资产积累不足 | 平台功能齐全但无核心竞争力 | 把数据资产建设列为独立考核指标，前期投入专项人力 |
本附录供团队内部对齐术语使用，也可直接作为申报书"缩略语表"的基础。
| 术语 | 全称 | 简要说明 |
|---|---|---|
| QKD | Quantum Key Distribution | 量子密钥分发，基于物理原理分发密钥 |
| BB84 | — | 首个 QKD 协议，基于四个非正交态 |
| 诱骗态 | Decoy State | 用于抵御光子数分离攻击的改进方案 |
| MDI-QKD | Measurement-Device-Independent QKD | 测量设备无关 QKD，消除探测器侧信道风险 |
| TF-QKD | Twin-Field QKD | 双场 QKD，可突破 PLOB 界 |
| CV-QKD | Continuous-Variable QKD | 连续变量 QKD，使用连续物理量编码 |
| QBER | Quantum Bit Error Rate | 量子误码率，衡量链路质量的核心指标 |
| PLOB 界 | Pirandola-Laurenza-Ottaviani-Banchi bound | 无中继场景下点对点量子通信容量上界 |
| KMS | Key Management System | 密钥管理系统 |
| PQC | Post-Quantum Cryptography | 后量子密码，基于数学难题抗量子计算攻击 |
| SDN | Software-Defined Networking | 软件定义网络，经典网络架构，非量子技术 |
下表按组织归类，可作为申报书"技术依据"部分的引用来源。
| 标准编号 | 组织 | 内容 |
|---|---|---|
| GS QKD 014 | ETSI | 密钥投递与 KMS 接口 |
| GS QKD 015 | ETSI | SDN 控制接口 |
| GS QKD 018 | ETSI | SDN 编排接口 |
| GS QKD 020 | ETSI | 可互操作 KMS API |
| ISO/IEC 23837 | ISO／IEC | 量子密钥分发安全性评估要求 |
| ITU-T Y.3800 系列 | ITU-T | 量子密钥分发网络架构 |
| GM/T 0005 | 国内密码行业 | 随机性检测规范 |
| NIST SP 800-22 | NIST | 随机性统计测试套件 |
下列工具均为成熟方案，建议直接复用，避免重复开发。
| 工具 | 用途 |
|---|---|
| ns-3 与 OMNeT++ | 网络级离散事件仿真 |
| SimQN | 量子网络仿真（基于 ns-3） |
| QuTiP | 开放量子系统模拟 |
| NetSquid | 量子网络仿真（Python） |
| ProVerif 与 Tamarin | 协议形式化验证 |
本附录是工作底稿，建议在座谈后两周内完成填写，作为后续合作的依据。
| 序号 | 数据与接口 | 内容 | 提供方式 | 频率与周期 | 密级 | 使用范围 |
|---|---|---|---|---|---|---|
| 1 | 器件参数 | 探测器效率、暗计数、损耗 | 待填 | 一次性或分批 | 待定 | 仿真参数库 |
| 2 | 链路实测数据 | 光功率、QBER、密钥率时序 | 待填 | 待填 | 待定 | 仿真校准 |
| 3 | 攻击实验样本 | 攻击下的异常波形或日志 | 待填 | 按需 | 待定 | 数据集建设 |
| 4 | 协议实现细节 | 工艺参数、时序细节 | 待填 | 一次性 | 待定 | 仿真建模 |
| 序号 | 工具与能力 | 内容 | 交付形式 | 时间节点 |
|---|---|---|---|---|
| 1 | 仿真设计工具 | 链路参数预评估 | 软件或在线服务 | 第 6 月 |
| 2 | 参数标定服务 | 用实测数据反演器件参数 | 报告或工具 | 第 6 月起持续 |
| 3 | 安全靶场 | 攻击预演环境 | 平台账号 | 第 12 月 |
| 4 | 测评平台 | 器件与协议的标准符合性自测 | 平台账号 | 第 18 月 |
以下八项建议在第一次正式合作会议上一并确认，逐项打勾归档。
本规划为基础版本，建议在实际推进过程中按季度更新，并在每个里程碑后补充进展与偏差说明。