Quant Trading for Programmers: Column Roadmap

This is not a series that starts with a perfect textbook outline and then fills in chapters one by one.

I want it to be closer to an engineering log for a real project: each article advances one verifiable goal, the code has a corresponding GitHub commit and tag, and the commands, charts, and snippets in the article can be traced back to the project.

Scope

This series only covers research, backtesting, alerts, and paper trading.

It does not connect to brokers, does not place real orders, and does not package system output as investment advice. Every strategy conclusion must go through data-quality checks, backtesting, out-of-sample validation, and human review.

This boundary runs through the whole project. The more we connect real data, Feishu notifications, and model-assisted research, the more these boundaries must live in code and tests rather than only in article disclaimers.

Main Project

The main project is called ZiQuant.

The goal is not to write a few scattered scripts. It is to gradually build an A-share quant-research platform that can run, backtest, simulate, and review results. The repository will live under the GitHub ax2 organization. As the articles progress, the code will be committed to the corresponding state and tagged.

The project repository has been created on GitHub:

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

The runnable baseline for the first five articles has already been tagged as chapter-01, chapter-02, chapter-03, chapter-04, and chapter-05. Because part of the platform existed before the writing started, the first five tags point to the same working baseline.

Starting from article 6, each chapter follows the rhythm of “implement code -> run tests -> commit -> tag.” Articles 6 through 45 now correspond to chapter-06 through chapter-45.

The main line of the project is roughly:

Python project structure
  -> A-share trading rules and domain models
  -> Data sources and PostgreSQL
  -> Stock universe and market-data quality
  -> Factors and strategies
  -> Backtesting and strategy admission
  -> Paper trading and risk controls
  -> Recommendations, reviews, and alerts
  -> Model-assisted research
  -> Operations, audit, and production checks

The route will continue to adjust according to real project progress. It is more important to leave runnable code, test results, charts, and review records at each stage than to lock the whole series into a rigid table of contents.

Writing Rules

Every article should answer at least four questions.

What engineering problem does this article solve?

What code or configuration does it change in ZiQuant?

How do you run it, and how do you verify it?

What interface or constraint does it leave for the next article?

The articles will not repeat the same concepts just to fill space. Every five articles, I will do a stage review: check style, repeated content, code state, image style, and the next route. If needed, earlier articles will be revised.

Images and Code

The column covers will keep a consistent style: the ZiCode engineer as the recurring visual subject, realistic cartoon texture, a light background, clear theme objects, and enough whitespace. Inline images should use real screenshots, run results, realistic AI-generated PNGs, or project-related visualizations. I will not use pure text placeholders, and I will avoid making all images look like the same dense interface.

Code must follow the main repository. Functions, models, commands, and tests mentioned in the articles should exist in the repository or be clearly labeled as simplified examples.

Current Progress

This roadmap is maintained in groups of five articles. Each group is not only a content topic, but also a verifiable project stage: the first four articles push capability forward, and the fifth either closes the stage with a review or combines previous work into a clearer engineering boundary.

The first group focuses on getting started:

• Article 1: Why programmers are well suited to quant trading.
• Article 2: Build a Python quant-project structure from scratch.
• Article 3: Core concepts in quant trading.
• Article 4: How A-share trading rules affect code.
• Article 5: Data matters more than strategies in a quant system.

After this group, the project should have at least an installable Python package, clear domain models, testable A-share order rules, an entry point for data-layer design, and a stage-review record.

The second group runs the minimal loop from data to backtesting:

• Article 6: Make PostgreSQL schema and Alembic migrations inspectable.
• Article 7: Build a clean public A-share universe.
• Article 8: Clean raw K-line data into unified market data.
• Article 9: Calculate the first factor signals from K-lines.
• Article 10: Run the first minimal backtesting loop and complete the second stage review.

The third group moves portfolio backtesting toward strategy admission:

• Article 11: Expand from a single stock to multi-symbol portfolio backtesting.
• Article 12: Fill in backtesting performance metrics.
• Article 13: Build the first strategy-parameter grid search.
• Article 14: Save strategy candidates as experiment records.
• Article 15: Implement a strategy promotion gate and complete the third stage review.

The fourth group enters paper trading:

• Article 16: Implement a paper-trading account ledger.
• Article 17: Generate account equity snapshots.
• Article 18: Add paper-trading risk checks.
• Article 19: Generate rebalance plans from target weights.
• Article 20: Generate paper-trading daily reports and alert summaries, then complete the fourth stage review.

The fifth group makes paper trading continuously observable:

• Article 21: Generate paper-trading recommendation summaries.
• Article 22: Save daily review records.
• Article 23: Wire the daily paper-trading flow together.
• Article 24: Save paper-trading account state as JSON.
• Article 25: Add production checks and complete the fifth stage review.

The sixth group completes more of the paper-trading runtime:

• Article 26: Abstract notification channels.
• Article 27: Save daily-report sending records through a file-based channel.
• Article 28: Abstract price providers.
• Article 29: Generate target weights from candidate lists.
• Article 30: Generate runtime health reports and complete the sixth stage review.

The seventh group pushes the daily flow toward pre-operations checks:

• Article 31: Add a run window to daily tasks.
• Article 32: Archive daily-run results as JSON.
• Article 33: Summarize paper-trading run history.
• Article 34: Detect gaps in market data.
• Article 35: Generate an operations checklist and complete the seventh stage review.

The eighth group begins to narrow the “daily run” main chain:

• Article 36: Consolidate daily-run requests.
• Article 37: Generate daily-run results.
• Article 38: Build an index for report archives.
• Article 39: Convert failed checks into handling actions.
• Article 40: Compose daily-run plans and complete the eighth stage review.

The ninth group moves the daily plan toward real commands:

• Article 41: Compress daily-run plans into summaries.
• Article 42: Write daily-run artifacts to disk.
• Article 43: Define command response objects.
• Article 44: Add an execution gate.
• Article 45: Generate a daily-run runbook and complete the ninth stage review.

Articles 46 through 60 will move from “can run” toward “can run for a long time.” The tentative direction is below and will still follow the real project.

The tenth group will connect scheduling and external alerts: local scheduler first, then Feishu or file-based notifications, followed by idempotent tasks, retry handling, sending records, and alert-noise reduction.

The eleventh group will return to data sources and strategy quality: connect real A-share data sources, maintain a 500-stock universe, complete unified interfaces for fundamentals, financial reports, real-time quotes, and historical quotes, and close the loop between strategy recommendations and yesterday’s review.

The twelfth group will complete the platform experience: recommendation workbench, single-stock analysis, simulated buy/sell operations, holding returns, configuration management, and multi-user isolation. ZiQuant should gradually move from a command-line engineering project into a usable quant-research platform.

Every step must follow the runnable project. Articles can explain tradeoffs, but they cannot prove results in place of code. Once a strategy, return, recommendation, or signal appears, it must also include the data source, verification command, backtesting boundary, and risk note.

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode