一行 drop_collection 引发的生产事故
从一次静默的 stock_list 清空，看「先删后取」这颗隐形炸弹
S0017 策略的一个隐蔽 Bug，今天被修了
信号扫描越界，一笔还没走完就开始检查下一笔
fqcopilot 信号值规范体系
从数字读懂每一个交易信号
听见笔的回声：缠论分型确认信号的设计与实现
一笔之中，除了顶点，还有确认顶点的那一刻
一次调用18个模型一次输出信号，DLL批量计算的设计与实践
一次调用18个模型一次输出信号，DLL批量计算的设计与实践 当18次重复计算变成1次共享，DLL性能优化的真实落地 「量化实战手记」— 记录从想法到落地的真实开发历程 引言：一张图看懂所有信号 想象一下：通达信主图上，所有 18 个选股模型的买卖信号一次性标注在K线上，每个信号值里自带模型编号——看到 5107 就知道是 S0005 的买点，看到 -1403 就知道是 S0014 的卖点。一张图，所有模型的信号一目了然。 这就是批量计算要实现的效果。在这之前，fqcopilot 的 18 个选股模型（S0000 ~ S0017）各自独立计算，每次都要从头做一轮完整的缠论分析——识别笔、线段、中枢，再算 MA5、MACD、ATR。18 个模型做的是同一套缠论分析，但每个都从头算一遍。 这不是算法问题，是架构问题。解法很清晰：把缠论分析的结果提取出来，
信号身份错位：缠论模型编码缺陷的发现与修复
信号身份错位：缠论模型编码缺陷的发现与修复 fqcopilot 中两个模型输出了错误的信号身份——一次全量排查与修复记录 「量化实战手记」— 记录从想法到落地的真实开发历程 引言：信号值里的身份信息 fqcopilot 是一个缠论量化信号引擎，内置 18 个策略模型（S0000 ~ S0017）。每个模型对行情数据做独立分析后，输出一个整型信号值——这个值不仅包含买卖方向，还携带了模型编号、触发次数、入场类型三层信息。 信号编码公式如下： signal_value = direction × (model_id × 1000 + occurrence × 100 + entrypoint) 比如信号值 14107 可以解码为：买入方向、14 号模型、第 1 次触发、MACD 交叉入场。 这套编码规则是下游选股系统、回测框架、实盘交易信号路由的基础。如果信号值里的模型编号不正确，下游就无法判断信号的真实来源。 +1 方向
一句话查完 A 股数据，30 秒完成个股调研
一句话查完 A 股数据，30 秒完成个股调研 给 AI 编程助手装了个 A 股数据引擎，效果超预期 「量化实战手记」— 记录从想法到落地的真实开发历程 引言：做投研最大的效率黑洞 用 AI 做股票研究，最痛苦的不是 AI 不够聪明，而是数据到不了它手里。 想问「茅台 PE 多少」—— 先打开东方财富看一眼，把数字粘给 AI。想问「今天龙虎榜谁上榜了」—— 先截图，再让 AI 帮你分析。想算个股估值—— 东财看价格、同花顺看 EPS、Excel 算 PEG，五六个窗口来回切。 来回切换，效率归零。 我一直在想：如果 AI 能直接拉 A
行情引擎的「体检」机制
行情引擎的「体检」机制 每 5 分钟一次全量扫描，让数据缺口无处藏身 「量化实战手记」— 记录从想法到落地的真实开发历程 引言：一块砖的缺失 行情引擎在实时推送 Bar 数据时，每根 Bar 到达后都会与上一根做时间连续性检查。如果中间有空档，立刻补数据。这套机制在大多数场景下运行良好。 但有一个盲区：如果最后一根 Bar 的时间完全正确，但前面的某些 Bar 丢了，系统是发现不了的。 这就好比一栋楼，顶层好好的，但中间某几层少了砖——你站在楼顶往下看，一切正常。只有把每层都走一遍，才能发现那些空洞。 第一章：为什么相邻检测不够 先看看现有的缺口检测是怎么工作的。引擎收到每一根 Bar 时，GapDetector 会记住「上次 Bar 到了哪个时间」，然后推算下一个应该出现的时间。 这种「相邻检测」能发现连续两根
让计划自由启停：跨进程任务同步的 Redis 实践
让计划自由启停：跨进程任务同步的 Redis 实践 当 WebUI 和调度器各走各的路，谁来牵线搭桥？ 「量化实战手记」— 记录从想法到落地的真实开发历程 引言：一个被忽视的断层 量化系统通常由多个进程协作运行。Web 服务负责用户交互，后台引擎负责定时任务执行。用户在前端轻轻一点「停止计划」，期待一切随之安静下来——但事实并非如此。 在我们的系统中，Flask API 处理 WebUI 请求，APScheduler 在另一个进程里默默驱动选股、做T、终止检查三类定时任务。两者通过 MongoDB 共享计划状态，却对彼此的运行时状态一无所知。 用户停掉一个计划，MongoDB 里状态确实变成了 STOPPED。但 APScheduler 进程里，那个计划的选股 cron 任务还在忠实地每隔一段时间触发一次——像一台没人关掉的机器，在空荡荡的工厂里反复运转。 第一章：问题全貌 先来看看 APScheduler
让策略自由生长：投资计划配置编辑器的设计与实现
让策略自由生长：投资计划配置编辑器的设计与实现 10 个策略配置段，从后端数据类到前端折叠面板的完整落地 「量化实战手记」— 记录从想法到落地的真实开发历程 引言：一个完整的后端，一个空白的入口 投资计划模块的后端已经具备完整的策略配置体系：10 个强类型数据类，覆盖选股、开仓、止损、仓位管理等全部交易环节。PATCH 接口支持按段更新，浅合并逻辑确保每次只提交改动部分。 但用户看到的是什么？7 个 Tab 页，包含概览、股票池、持仓、交易记录……唯独没有一个地方可以修改策略参数。 后端准备好的 10 把钥匙，锁在柜子里，没人能拿到。这就是本文要解决的问题。 第一章：问题的全貌 先看看这 10 个配置段到底是什么。后端用 Python dataclass 定义，每个段对应交易流程中的一个决策环节： 每个配置段都有各自的字段类型：布尔开关、百分比数值、枚举选择、
缩量整固日的自愈：市场结构与行情引擎故障转移
5月18日：一边观察市场结构消化，一边让系统学会自己站起来。
投资计划引擎：把策略配置变成自动执行的利器
配置写好了，谁来执行？从「被动等信号」到「主动跑策略」的架构跃迁