量化开发环境：先把工作台搭稳

会写程序的人做量化，最容易犯的错不是代码写不出来，而是一上来就把行情、规则、结果和临时试验揉成一锅粥。炒菜前先把案板、刀、调料摆好；做量化也一样，先把工作台搭稳。

这是什么

量化开发环境，就是一套专门用来做量化交易研究的本地工作台：用 Python 处理数据，用 Notebook 快速试验，用清晰的项目目录保存行情、规则、日志和结果。说人话，它不是“装几个库”这么简单，而是让你每一次研究都能被复现、被检查、被改进。

如果把量化交易比作开一家小饭馆，开发环境就像后厨：菜谱放哪、原材料放哪、当天试菜记录放哪，都要固定。后厨乱，菜再好也很难稳定出餐；项目乱，回测曲线再漂亮也很难相信。

经验

本项目的教学数据一律用 mock/ 或本地样本，不接真实行情服务。真实行情数据的授权、清洗和质量控制都很复杂，入门阶段先把流程跑顺更重要。

为什么先搭环境

量化交易最怕“今天跑出来一个结果，明天自己也复现不了”。手动交易亏了，你还可以说是心态问题；量化研究如果连同一段数据、同一条规则、同一组参数都跑不出同一个结果，那就不是投资问题，是工作台问题。

一个合格的量化开发环境，至少解决四件事。

第一，数据和代码分开。行情文件、处理后的表格、临时输出、最终结果，不要和代码混在一起。这样你才能知道自己用的是原始数据，还是已经改过一轮的数据。

第二，试验和正式结果分开。Notebook 很适合边想边试，但它也很容易留下“跑到一半改了变量”的脏状态。临时试验可以在 Notebook 里做，最后要把能复用的逻辑沉到普通 .py 文件里。

第三，每次运行都有记录。哪一天跑的、用了哪段时间的数据、成本有没有算、参数是什么，都要留痕。否则你看到一条漂亮曲线时，根本不知道它是怎么来的。

第四，结果能被自己质疑。量化不是让程序替你制造信心，而是让程序帮你发现问题。环境越清楚，越容易看出哪里偷懒、哪里假设过强、哪里风险没算进去。

一个最小项目长什么样

不用一开始就搞得像机构系统。个人学习阶段，一个能跑通的最小项目可以长这样：

quant-lab/
  data/
    raw/          # 原始样本数据，不随手改
    processed/    # 清洗后的数据
  notebooks/      # 临时试验和图表观察
  src/
    load_data.py  # 读取和检查数据
    rules.py      # 买入、卖出、仓位规则
    run.py        # 统一运行入口
  reports/        # 输出结果和图表
  logs/           # 每次运行的参数和异常记录

这里的关键不是目录名字，而是职责清楚。raw/ 像菜市场买回来的原材料，放进去就别随便动；processed/ 像洗好切好的菜，可以给程序直接用；reports/ 是端出来的成品；logs/ 是后厨记录，方便你知道哪锅菜怎么做出来的。

教学样本可以先用一张很小的表：

date	code	open	high	low	close	volume
2024-01-02	SAMPLE_A	10.00	10.40	9.90	10.30	12 万
2024-01-03	SAMPLE_A	10.35	10.60	10.10	10.20	9.8 万
2024-01-04	SAMPLE_A	10.18	10.90	10.15	10.80	18 万

它不是为了模拟真实市场的全部复杂度，而是为了让你先确认：数据能读进来，日期能排序，价格和成交量字段没有乱，程序不会把字符串当数字处理。

风险

不要一开始就追求“大而全”。一次塞进几千只股票、十几年数据、几十个参数，出错时你根本不知道问题在哪。适用做法是先用一只教学样本票和几十行数据跑通；反例是直接拿大量真实数据开干；风险是你花很多时间调程序，却连结果错在哪里都看不出来。

老手会先检查什么

有经验的人打开一个量化项目，不会先问“收益高不高”，会先看三件小事。

第一，数据日期是不是干净。A 股不是每天都交易，周末、节假日没有行情；个股还可能停牌。如果日期没处理好，程序就可能把不存在的交易日也当成可以买卖的日子。

第二，价格字段有没有说清楚。同一只股票，开盘价、收盘价、最高价、最低价用途不同。你用收盘价判断买入，却假装自己能在同一天收盘价成交，这在很多场景里就已经占了便宜。

第三，运行结果有没有日志。比如某次运行用了 2020-01-01 到 2024-12-31 的数据，初始资金 10 万元，单只票最高 20% 仓位，手续费按多少算，都应该能查到。日志不是给别人看的，是给未来的自己救命的。

主力和机构做量化，优势不只是资金大，也在于流程严：数据有人校验，运行有人监控，异常有人复核。个人做不到那种规模，但可以先学它最朴素的一点——别让流程靠记忆，尽量让流程留痕。

新手最容易踩的坑

大坑

把 Notebook 当成最终系统。Notebook 很适合探索，但不适合长期稳定运行。单元格执行顺序一乱，变量状态就可能变脏，结果看起来对，其实已经不是你以为的那套输入。

第二个坑是原始数据随手改。今天发现一个空值，直接在原始文件里补了；明天又发现一个异常值，直接删了。几轮之后，你已经不知道这份数据到底经历过什么处理。更稳妥的做法是：原始数据只读，所有清洗都写成可重复运行的步骤。

第三个坑是只保存最终收益图，不保存过程。一张向上的曲线很容易让人兴奋，但如果你不知道它来自哪份数据、哪组条件、哪次运行，那它更像一张截图，不像一份研究。

方向性做法很简单：如果只是临时观察，用 Notebook；如果某段逻辑会重复用三次以上，就放进 .py 文件。适用条件是你已经知道这段逻辑要长期复用；反例是还没想清楚就过早封装，最后越改越绕；风险是过度工程化会拖慢学习，所以先清楚、再漂亮。

总结

量化开发环境不是装工具的清单，而是让量化研究能被复现、被检查、被迭代的一套工作台。入门阶段记住四个原则：原始数据不乱改，试验和正式逻辑分开，每次运行留日志，先用小样本跑通再扩大范围。

自检 3 问：

1. 为什么量化项目里原始数据最好只读、不随手改？
2. Notebook 适合做什么，为什么不适合直接当长期运行的系统？
3. 一次运行至少应该记录哪些信息，才能让未来的自己复盘？

股市有风险，入市需谨慎。本文不构成任何投资建议。

本章新学到：量化开发环境。