跳转至

17 路线图

目的

本章定义未来版本的阶段性演进方向。

核心要求

路线图必须在保持架构连续性的同时,为未来一致性层、运行时层与后端扩展预留空间。

路线图原则

路线图的演进方式应当是在既有架构上逐步加深,而不是频繁改写核心定义。未来版本应优先增强一致性、诊断能力、后端覆盖面与运行能力,同时保持 UQCI IR 的 canonical 地位以及 sidecar 工件的规范性角色。

v0.1

首个公开版本聚焦于与当前仓库形态直接对应的基础能力:

  • UQCI 程序与 sidecar 工件的强类型模型
  • Bundle 读写与校验辅助
  • 与模型对齐的 JSON Schema
  • OpenQASM 兼容导出配置
  • 可运行的超导与中性原子 Mock 后端
  • 仓库原生测试、文档与 CLI 命令

这一阶段有意保持收敛。它的目标,是让规范变成可执行、可检查的参考实现,而不是过早宣称生产就绪。

v0.2

下一阶段宜在保持轻量的前提下增强工程深度,建议重点包括:

  • 可选的离子阱 Mock 后端
  • 更丰富的诊断与 trace 工件
  • 更多 Bundle 检查与 patching 工具
  • 更广的兼容导出覆盖范围
  • 后端能力发现与报告机制

这些方向与当前仓库中的扩展预留保持一致,并且能够在不改变既有架构 doctrine 的前提下逐步引入。

v0.3 及之后

更长期的方向可以包括:

  • 面向真实硬件环境的实验性适配器
  • 调度与路由原型模块
  • 更完整的校准生命周期工作流
  • 面向第三方实现的一致性测试套件
  • 超出当前仓库范围的可选运行时编排原型

如果未来推进这些方向,也应建立在现有 canonical 核心之上,而不是把架构重心重新放回某个特定后端或某个导出格式。

面向发布的指导

参考草案建议同时发布规范文档、机器可读 Schema、参考实现和示例 Bundle。当前仓库的路线图与这一建议是一致的:

  • Markdown 章节承担仓库原生规范角色
  • JSON Schema 文件承担机器可读工件层
  • Python 模块承担参考实现层
  • 示例 Bundle 与兼容导出承担可运行演示层

稳定性规则

未来版本应将以下内容视为连续性锚点:

  • QOS 是 runtime 与 systems 视角
  • UQCI 是 canonical protocol 层
  • OpenQASM 是 compatibility 与 exchange 层
  • DeviceSpecCalSetManifestBundle 是规范性 sidecar 工件

任何会削弱这些锚点的改动,都应被视为架构级修订,而不是普通功能演进。

相关章节