QSS 到 QTS 重命名迁移方案
日期: 2026-04-07 当前结论: 推荐先做对外命名切换，再做代码层重命名 当前状态: 对外交付物已切换为 QTS，代码目录与 import 路径仍为
qss/
1. 为什么考虑从 QSS 改为 QTS
当前对外简称最初是 QSS，但从语义上看，交易执行主系统更容易被理解为:
QTS = Quantitative Trading System
相比之下，QSS 更容易让人联想到 Strategy System，而不是“交易执行主系统”。
因此，从品牌和沟通角度，QTS 的确更直观。
2. 当前现状
本次快速评估显示，仓库中与 QSS / qss/ / qss. 相关的引用约 178 处。
这些引用分布在:
- 文档
- PPT 生成脚本
- Python import
- 调度脚本
- 测试代码
- 架构图与说明文本
这意味着，QSS -> QTS 不是一个“只改几行字”的动作。
3. 风险评估
低风险部分
以下内容可以先改，不会影响系统运行:
- 架构文档
- 汇报 PPT
- 对外介绍口径
- 模块说明
- 管理层摘要
中风险部分
以下内容改动后，需要回归验证:
- 日志文案
- 调度脚本中的显示文本
- 文档里的目录说明
- 测试里的描述文字
高风险部分
以下内容一旦修改，会直接影响代码运行与导入路径:
- 目录名
qss/ -> qts/ from qss.xxx import ...相关 importpython qss/main.py相关启动脚本pytest中依赖qss路径的用例- 任何硬编码路径、日志文件名、配置说明
4. 推荐策略
推荐方案 A: 先统一对外名称，代码层暂不改
这是当前最优方案。
做法:
- 所有汇报材料、架构文档、PPT 统一使用 QTS
- 明确说明:
代码目录当前仍为 qss/ - 等系统接口进一步稳定后，再决定是否做代码级重命名
优点:
- 几乎不影响运行
- 立即提升对外表达清晰度
- 不打断当前开发节奏
缺点:
- 对外简称与代码目录短期内不完全一致
备选方案 B: 一次性做代码级正式重命名
做法:
- 目录
qss/改为qts/ - 所有 import 路径统一替换
- 所有启动脚本、测试、文档同步调整
- 全量回归验证
优点:
- 对内对外彻底统一
缺点:
- 迁移成本高
- 回归范围大
- 当前阶段收益不一定覆盖风险
5. 正式迁移建议分阶段执行
Phase 0: 已完成
- 对外文档切换到 QTS
- PPT 切换到 QTS
- 增加说明:
代码目录仍为 qss/
Phase 1: 非运行时文本统一
建议后续可继续补齐:
- 日志与注释中的
QSS文案改为QTS - 面向管理层与用户的文档统一用
QTS - 保留技术文档中的
qss/目录说明
Phase 2: 兼容层准备
如果未来真的要改代码层，建议先准备兼容层:
- 新建
qts/包，但内部先做转发 - 保留
qss/一段时间作为兼容入口 - 调度脚本和测试逐步切换到
qts
Phase 3: 正式代码迁移
迁移动作建议顺序:
- 新建
qts/包结构 - 替换内部 import
- 替换脚本入口
- 替换测试依赖
- 回归执行、监控、AI、回测四条主链路
- 删除
qss/兼容层
6. 代码级迁移影响面
如果未来做正式重命名，至少需要覆盖以下区域:
scripts/scheduler.pyscripts/jobs/nightly_screener.pyits/*中对qss的依赖tests/*中所有qssimport- 所有架构文档与研发文档
pyproject.toml、README、运行说明- PPT 生成脚本和导出文档
7. 回归验证清单
代码层迁移时，建议至少验证以下事项:
交易主链路
main.py是否能正常启动- 配置是否正常加载
- EventBus 是否正常工作
- 模拟执行器是否正常下单
监控链路
- SPS 是否能正常拉行情
- 消息推送链路是否仍正常
AI 链路
- ITS 是否仍能调用
llm、indicators、event_bus - 候选池是否仍能被 QTS 消费
研究链路
- TSS 是否仍能正常读取数据与回测
测试链路
- 单测能否通过
- 关键端到端测试是否仍可运行
8. 最终建议
当前建议非常明确:
- 短期: 统一对外名称为 QTS
- 中期: 保持代码目录
qss/不变，减少运行风险 - 长期: 等架构进一步稳定后，再评估是否正式做
qss -> qts代码级迁移
9. 一句话决策建议
现在把名字改成 QTS 是对的，但当前更适合“先改对外口径，不急着改代码目录”。等系统边界和入口稳定后，再做正式迁移，风险和收益会更匹配。