1. 课程导入与全景认知

量子算法并不是“把经典程序翻译成量子门”这么简单。一个真实工程任务通常从一句模糊的业务或科学需求开始，例如“为某类组合优化问题寻找更优解”或“模拟某分子的基态能量”。要把它变成可执行的量子方案，中间必须经过问题形式化、量子编码、算法选择、线路构造、资源估算与可行性判断等多个环节。问题编码负责把数学问题映射为量子态与哈密顿量或酉算子；资源估算负责回答“需要多少量子比特、多少门、多深线路、多大误差、多长时间”。两者共同决定了量子方案是否值得做、能否在目标硬件上跑通。

本课程的核心对象可以归纳为四类：问题模型（变量、约束、目标函数）、编码表示（比特编码、振幅编码、哈密顿量编码、块编码等）、算法与线路（Oracle、Ansatz、演化算子、测量方案）、资源账本（逻辑量子比特、T 门数、CNOT 数、线路深度、T 深度、测量次数、采样shots）。学习路径遵循“问题→编码→算法→线路→资源→评估”的端到端主线，每一环都可能反向修正前一环：资源超预算时，往往需要回到编码或算法层面重新设计。

上图把整门课的主线压缩成一张全景图：上方是五个阶段的主链，下方是资源账本。需要特别注意的是两条橙色虚线反馈回路——它们体现了量子工程与经典软件工程最大的差异之一：资源估算不是最后一步的“报表”，而是贯穿设计全程的约束条件。当估算结果显示 T 门数或线路深度远超目标硬件能力时，正确的做法不是硬着头皮优化实现，而是回到编码或算法层重新选择表示方式。

为什么“编码”决定了资源的上限

同一个问题，换一种编码，资源量可能相差几个数量级。以组合优化中的二次无约束二值优化（QUBO）为例，若采用比特编码，n 个二值变量直接对应 n 个量子比特，目标函数写成对角哈密顿量，态制备相对直接；若采用振幅编码，则把 2^n 个候选解的权重压进 n 个量子比特的振幅中，比特数少了，但态制备线路的深度和门数会显著上升。再比如哈密顿量模拟，采用 Trotter 分解时，资源随演化时间 t、精度 ε 和项数 L 变化，通常需要把总演化切成 r 段，每段误差受控；而采用块编码加量子奇异值变换，则可能获得更好的精度缩放，但块编码本身的构造代价又成为新的账本项。因此，编码选择本质上是在比特数、门数、深度、精度之间做权衡，没有脱离具体硬件预算的“最优编码”。

一个可操作的估算示例

下面用一个教学示例说明估算的落账方式。假设我们要用变分量子本征求解（VQE）估计一个 8 比特哈密顿量的基态能量，采用硬件高效 Ansatz，层数 p=4，每层包含 8 个单比特旋转门和 8 个 CNOT 门，测量时对每个 Pauli 项分别采样，每项 shots=4096。这是一个合理假设的示例参数，用于演示计算过程，并非实测结果。

逻辑量子比特数  = 8（数据比特）
单比特旋转门数  = 8 × 4 = 32
CNOT 门数       = 8 × 4 = 32
线路深度（估算）≈ 4 层 × (1 旋转 + 1 CNOT) = 8
Pauli 项数       = 假设 20 项
总采样次数      = 20 × 4096 = 81920 shots
统计误差量级    ≈ 1/√4096 ≈ 1.6%（单次估计）

把这份账本与目标硬件对照：若硬件单次采样加线路执行约需 20 微秒，则 81920 次采样约需 1.6 秒，尚可接受；但若 Pauli 项数增长到 200 项，采样时间就上升到约 16 秒，再叠加参数优化迭代（例如 100 次迭代），总时间将达数十分钟。此时应优先考虑测量分组（把可对易的 Pauli 项合并测量）或改用更紧凑的 Ansatz，而不是单纯增加 shots。这个例子说明：资源估算的输出不是单一数字，而是一张能指导设计决策的账本。

工程意义与学习路径

掌握这套端到端视角的工程价值在于三点。第一，可比较：不同编码、不同算法方案可以在同一张资源账本上横向对比，避免凭直觉选型。第二，可预判：在写第一行代码之前，就能判断方案是否落在目标硬件的可行域内，节省大量无效实现。第三，可迭代：当资源超预算时，知道应该回退到哪一层修改，而不是盲目调参。后续章节将沿着“问题形式化→编码表示→算法与线路→资源估算→可行性评估”的顺序逐层展开，每一层都会给出具体的表示方法、计算方式和判断依据。学习时建议始终带着一张自己的资源账本，把每节的示例参数代入计算，逐步建立对量子资源量级的直觉。