程序员量化交易实战：专栏路线图

这不是一个先写完整大纲、再按教材目录填空的系列。

我更希望把它做成一个真实项目的工程日志：每一篇文章推进一个可验证的小目标，代码在 GitHub 上有对应提交和 tag；文章里的命令、图表和代码片段，都要能回到项目里找到依据。

专栏边界

这个系列只做研究、回测、提醒和纸面模拟盘。

不连接券商，不提交真实交易订单，不把系统输出包装成投资建议。所有策略结论都必须经过数据质量检查、回测、样本外验证和人工复核。

这条边界会贯穿整个项目。越往后接入真实数据、飞书提醒和大模型辅助，越要把边界写进代码和测试，而不是只靠文章声明。

主线项目

主线项目叫 ZiQuant。

目标不是写几个零散脚本，而是逐步形成一个能运行、能回测、能模拟、能复盘的 A 股量化研究平台。项目会放在 GitHub ax2 组织下，文章推进到哪一章，代码就提交到对应状态并创建 tag。

项目仓库已经创建在 GitHub：

https://github.com/ax2/zi-quant-platform

前五篇对应的可运行基线已经打 tag：chapter-01、chapter-02、chapter-03、chapter-04、chapter-05。因为这个项目在写作前已有一部分平台能力沉淀，前五个 tag 先指向同一个已调通基线。

从第 6 篇开始，每一章都按“实现代码 -> 跑测试 -> 提交 -> 打 tag”的节奏推进。目前第 6-45 篇已经分别对应 chapter-06 到 chapter-45。

项目主线大致是：

Python 工程骨架
  -> A 股规则与领域模型
  -> 数据源与 PostgreSQL
  -> 股票池与行情质量
  -> 因子与策略
  -> 回测与策略准入
  -> 模拟盘与风控
  -> 推荐、复盘和提醒
  -> 大模型辅助研究
  -> 运维、审计和生产检查

路线会根据真实项目推进调整，不提前把系列锁死成一份死板目录。更重要的是，每个阶段都要留下可运行代码、测试结果、图表和复盘记录。

写作规则

每篇文章至少回答四个问题。

这篇解决什么工程问题？

它在 ZiQuant 项目里改了哪些代码或配置？

怎么运行、怎么验证？

它给下一篇留下什么接口或约束？

文章不会为了凑篇幅重复解释同一套概念。每完成五篇，会做一次阶段 review：检查风格、重复内容、项目代码状态、图片风格和后续路线，必要时回头修订前文。

图片和代码

专栏封面图会保持统一风格：以 ZiCode 工程师人物为固定视觉主体，使用写实质感的卡通人物、浅色背景、明确主题道具和足够留白。正文配图会尽量使用真实截图、运行结果、写实风格的 AI PNG 图或贴近项目的可视化，不使用纯文字占位图，也不把所有图片做成雷同的密集界面。

代码必须以主线仓库为准。文章里出现的函数、模型、命令和测试，应该能在仓库里找到对应实现或明确标注为简化示例。

当前进度

这份路线图按“五篇一组”维护。每一组不只是内容主题，也是项目的一个可验证阶段：前四篇推进能力，第五篇收口 review 或把前面的能力组合成更稳定的工程边界。

第一组文章聚焦起步阶段：

• 第 1 篇：为什么程序员适合做量化交易。
• 第 2 篇：从零搭建 Python 量化项目结构。
• 第 3 篇：量化交易中的核心概念。
• 第 4 篇：A 股交易规则对程序的影响。
• 第 5 篇：量化系统最重要的是数据，不是策略。

这组文章完成后，项目应至少具备：可安装的 Python 工程、清晰的领域模型、可测试的 A 股订单规则、数据层设计入口，以及一次阶段 review 记录。

第二组文章把数据到最小回测闭环跑通：

• 第 6 篇：把 PostgreSQL schema 和 Alembic 迁移做成可检查对象。
• 第 7 篇：构建干净的 A 股公共股票池。
• 第 8 篇：把原始 K 线清洗成统一行情。
• 第 9 篇：从 K 线计算第一版因子信号。
• 第 10 篇：跑通第一个最小回测闭环，并完成第二次阶段 review。

第三组文章把组合回测推进到策略准入：

• 第 11 篇：从单只股票扩展到多标的组合回测。
• 第 12 篇：补齐回测绩效指标。
• 第 13 篇：做第一版策略参数网格搜索。
• 第 14 篇：把策略候选保存成实验记录。
• 第 15 篇：实现策略晋升门禁，并完成第三次阶段 review。

第四组文章进入纸面模拟盘：

• 第 16 篇：实现模拟盘账户账本。
• 第 17 篇：生成账户权益快照。
• 第 18 篇：加入模拟盘风控检查。
• 第 19 篇：从目标权重生成调仓计划。
• 第 20 篇：生成模拟盘日报和告警摘要，并完成第四次阶段 review。

第五组文章把模拟盘推进到可持续观察：

• 第 21 篇：生成模拟盘推荐摘要。
• 第 22 篇：保存每日复盘记录。
• 第 23 篇：串起每日运行流程。
• 第 24 篇：把模拟盘账户状态保存到 JSON。
• 第 25 篇：加入生产检查，并完成第五次阶段 review。

第六组文章继续补齐模拟盘运行链路：

• 第 26 篇：抽象提醒通道。
• 第 27 篇：用文件型通道保存日报发送记录。
• 第 28 篇：抽象价格源。
• 第 29 篇：从候选列表生成目标权重。
• 第 30 篇：生成运行健康报告，并完成第六次阶段 review。

第七组文章把每日流程推进到运维前检查：

• 第 31 篇：给每日任务加运行时间窗。
• 第 32 篇：把每日运行结果归档成 JSON。
• 第 33 篇：汇总模拟盘运行历史。
• 第 34 篇：识别行情数据缺口。
• 第 35 篇：生成运维检查清单，并完成第七次阶段 review。

第八组文章开始收束“每日运行”这条主链路：

• 第 36 篇：收束每日运行请求。
• 第 37 篇：生成每日运行结果。
• 第 38 篇：给日报归档建立索引。
• 第 39 篇：把失败检查转换成处理动作。
• 第 40 篇：组合每日运行计划，并完成第八次阶段 review。

第九组文章把每日计划继续推向真实命令层：

• 第 41 篇：把每日运行计划压成摘要。
• 第 42 篇：每日运行 artifact 落盘。
• 第 43 篇：定义命令响应对象。
• 第 44 篇：加入执行闸门。
• 第 45 篇：生成每日运行 runbook，并完成第九次阶段 review。

接下来的第 46-60 篇会从“可运行”继续走向“可长期运行”。暂定方向如下，后续仍以项目真实推进为准。

第十组文章会把调度和外部提醒接进来：先做本地 scheduler，再接飞书或文件型通知，随后补充任务幂等、失败重试、发送记录和告警降噪。

第十一组文章会回到数据源与策略质量：接入真实 A 股数据源，维护 500 只股票池，补齐基本面、财报、实时行情和历史行情的统一接口，并把策略推荐与昨日复盘串成闭环。

第十二组文章会把平台体验补完整：做工作台荐股、单股分析、模拟买卖、持仓收益、管理配置和多用户隔离，让 ZiQuant 从命令行工程逐步变成一个可用的量化研究平台。

每一步都以可运行项目为准。文章可以解释取舍，但不能替代码证明结果；只要出现策略、收益、推荐和信号，就必须同时给出数据来源、验证命令、回测边界和风险说明。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。