1. 课程导入与转译部署全景

在真实的量子计算工作流中，写出一段量子电路只是起点。你最终要面对的是：这段电路能否在目标硬件上运行、运行结果是否可信、以及如何把实验稳定地交付出去。Qiskit 把这条路径拆成两个关键阶段——转译（Transpile）与部署（Deploy）。本课程的目标，是让你从"会写电路"进阶到"能把电路可靠地跑在真实设备上"。

一、转译与部署在量子工作流中的位置

一个完整的量子计算任务通常包含五个环节：算法设计 → 电路构建 → 转译 → 执行 → 结果处理。其中"转译"是连接抽象电路与物理硬件的桥梁，"部署"则是把可执行的任务可靠地提交到后端并管理其生命周期。二者共同决定了你的算法能否真正落地。

为什么不能直接把抽象电路丢给硬件？原因有三：其一，硬件只支持有限的基门集合（如 rz、sx、cx），你写的 h、t、ccx 需要被分解；其二，量子比特之间存在连通性约束，双比特门只能作用在物理相邻的比特上，不满足时需插入 SWAP；其三，不同比特的噪声与相干时间差异显著，映射策略直接影响结果质量。转译正是系统性地解决这三类问题的过程。

二、Qiskit 转译与部署工具链概览

Qiskit 1.x 之后，工具链被重组为清晰的模块：qiskit 提供电路与基础转译原语，qiskit_ibm_runtime 负责与 IBM 量子后端交互，qiskit.transpiler 提供 generate_preset_pass_manager 等高层入口。下图展示了从电路到结果的完整数据流与各模块的职责边界。

三、转译的核心动作与可观察结果

以一段简单电路为例：qc = QuantumCircuit(3); qc.h(0); qc.ccx(0,1,2)。在 127 比特的 ibm_brisbane 上，若逻辑比特 0、1、2 被映射到物理上不相邻的位置，转译器会插入 SWAP 链。你可以通过 transpile 返回的 layout 属性查看映射关系，通过 depth() 与 count_ops() 对比转译前后的门数量与深度变化。一个典型现象是：转译后 cx 数量可能从 1 个增加到 5～7 个，深度从 3 增加到 10 以上——这正是连通性约束带来的代价，也是后续优化策略要压缩的对象。

from qiskit import QuantumCircuit, transpile
from qiskit_ibm_runtime import QiskitRuntimeService

service = QiskitRuntimeService()
backend = service.backend("ibm_brisbane")

qc = QuantumCircuit(3)
qc.h(0)
qc.ccx(0, 1, 2)

isa_qc = transpile(qc, backend=backend, optimization_level=2)
print("原始深度:", qc.depth(), "转译后深度:", isa_qc.depth())
print("转译后门统计:", isa_qc.count_ops())
print("物理映射:", isa_qc.layout)

注意 optimization_level 取 0～3，级别越高优化越激进，但编译时间也越长。实际工程中常用 1 或 2 作为默认值，只有在电路规模较小且对深度敏感时才用 3。

四、部署阶段要关注什么

转译完成后，电路还不能直接"运行"。部署阶段需要完成三件事：选择执行原语（Sampler 用于采样计数，Estimator 用于期望值估计）、提交作业（通过 Runtime 服务，注意作业队列与配额）、取回并解析结果（计数分布、期望值及其误差）。同时，务必保存转译时的 layout 与后端名称，否则结果无法与逻辑比特对应，实验也无法复现。

五、本课程的学习路径

接下来的章节将沿着这条数据流逐步深入：先掌握 QuantumCircuit 的构建与参数化，再理解基门分解与耦合图约束，随后练习 generate_preset_pass_manager 与自定义 PassManager，最后进入 Runtime 原语、作业管理与结果分析。每一节都会给出可运行的代码片段与判断依据，帮助你形成"构建—转译—执行—验证"的完整闭环能力。