将策略研究接入真实市场，难点在于让每一次判断、委托与成交都有据可查，让系统在行情变化、网络波动和服务重启之后，仍能找到自己所处的位置。TrendML 是我围绕这些问题，面向国内期货市场独立设计与开发的量化交易系统。
整个实盘系统由我独立完成，覆盖系统架构、策略工程化、行情与数据处理、交易后端、风险与持仓管理、Web 前端，以及部署、监控和日常迭代。目前模型策略以人民币 100 万元规模进行实盘运行，项目持续优化中。
从一条行情，到一笔真实成交
行情进入数据中枢后，先完成时间与交易日对齐、数据落地及缺口追踪；模型和因子服务据此更新计算状态，产生策略决策。策略运行层按顺序接收决策，将交易意图交给账本记录，再由执行服务结合风险检查、持仓情况和实时报价处理报单、撤单与后续委托。
柜台返回的订单与成交结果进入统一账本，更新实际持仓，并参与下一轮策略执行和账户核对。监控服务持续观察这条链路；前端通过独立的数据网关展示运行状态、绩效和执行差异。研究信号、交易请求与真实成交分别留痕，便于定位偏差发生在哪一环。
模型与因子，两种节奏的趋势研究
模型策略面向中长期趋势及其延续，将市场信息转化为模型判断，再通过持仓与执行流程落实交易方向；它是目前 100 万元实盘运行的策略主体。
因子策略关注日内波段趋势，通过多周期市场状态与信号筛选补充交易机会。模型与因子保留各自的计算和交易状态，共用执行、账本、核对与监控基础设施；两条路线可以分别验证，也可以开展组合研究。
策略研究结果与实盘执行结果分开评估：既观察收益、回撤和品种间相关性，也追踪滑点、未成交及未匹配信号，辨别差异来自策略本身、市场条件还是执行过程。
七个常驻服务，十个功能模块
v0.7 实盘版本由数据中枢、模型算法、因子算法、策略运行、交易执行、监控告警和管理后台七个常驻服务协作。按业务与工程职责，我将整套系统划分为以下十个功能模块；模块与服务并非一一对应，账本、恢复和前端等能力各有独立边界。
01 / 行情接入与数据治理
细分能力：数据源会话、历史行情归档、实时行情存储、交易日历、合约元数据、缺口修复与历史修订。为策略提供统一的数据入口，并记录已处理到的时间位置。
优势：行情事实集中维护，各策略共用数据口径，减少重复拉取和各自修补数据造成的分歧。盘中计算与后台维护分工，异常数据可以追踪到对应的修复任务。
工程难点：期货夜盘、休市、迟到数据和历史修订会打乱简单的时间顺序。我将正常新增行情与历史变更分开处理，依据交易日历识别缺口，在数据提交后通知计算层继续推进或重放受影响区间。
02 / 模型计算与理论交易状态
细分能力：行情加工、特征计算、模型推理、判断整合、目标方向与理论持仓状态管理。将研究模型封装为能够持续接收行情、更新状态和输出决策的计算核心。
优势：模型计算与数据库、网络、账户和交易柜台解耦。同一套核心支持历史重建、实时增量与恢复重放，便于替换模型、定位差异和验证计算结果。
工程难点：离线算出的结果需要与盘中逐步推进的结果保持同一口径。通过状态检查点与多条计算路径的对照验证，约束优化前后的行为；理论交易记录与实际成交独立保存，避免混淆研究表现和真实执行表现。
03 / 日内因子与多周期计算
细分能力：多周期行情聚合、增量因子计算、市场状态更新、候选信号筛选和理论交易生命周期。不同周期分别维护状态，为日内波段策略提供连续输入。
优势：因子计算核心同样与交易基础设施解耦，策略研究可以独立演进；实时运行、历史重建与修订重放共用计算规则，减少多套实现长期产生的口径偏差。
工程难点：跨夜盘、午休或行情缺失时，周期边界不能随实际收到的数据漂移。系统依据交易日计划组织周期，同时保存尚未完成的计算状态，使中断恢复后能够继续原有进度。
04 / 算法运行、检查点与恢复
细分能力：策略计算执行体、任务调度、计算资源限制、状态检查点、历史锚点、恢复重放与信号队列。负责把模型和因子核心接入可长期运行的服务。
优势：盘中以增量计算推进，将较重的历史重建和修订重放放入受控任务中，减少重复全量计算，也避免计算任务占满事件循环、拖慢服务响应。
工程难点：新行情、后台修订和进程重启可能同时发生。恢复过程中需要校验计算进度与状态版本，将检查点和对应的输出一起提交，避免出现状态已推进、信号却丢失，或旧计算结果覆盖新状态的情况。
05 / 策略编排与信号生命周期
细分能力：决策顺序投递、策略启停、执行资格、信号有效期、目标持仓转换与开平仓依赖。将算法给出的判断，转化为可以执行、等待或拒绝的明确请求。
优势：计算与执行之间保留独立的策略层，各策略分别推进；一个策略出现队列缺口或状态异常时，可以定位到该策略，减少对其他策略的牵连。
工程难点：重复投递、乱序和方向切换可能引发重复开仓或错误平仓。系统核对下一条应处理的决策及其版本，并显式记录请求依赖，让开平仓动作遵循实际执行状态。
06 / 交易账本与持仓归属
细分能力：执行事件、逻辑交易请求、实际委托尝试、订单身份、成交明细、策略持仓和处理进度。将策略意图、柜台订单与成交结果串联为可追溯的记录。
优势：集中管理交易事实及其写入规则，相关业务状态在本地事务中统一提交。同一笔交易可以从信号追到委托与成交，也可以反向核查它属于哪个策略、改变了多少持仓。
工程难点：同一请求可能经历多次委托，成交回报也可能重复或迟到。将请求与委托分别建模，对成交去重，并把入账和持仓变更放在一致的事务边界内，降低重复记账和仓位失真的风险。
07 / 柜台连接与订单执行
细分能力：统一柜台会话、实时报价、报单、撤单、后续委托、部分成交处理、平今平昨、止盈与换月执行。把策略请求转化为实际市场委托，并持续跟踪结果。
优势：交易动作经由统一执行入口，策略无需各自维护柜台连接和报撤单流程。委托身份与执行进度持续留存，方便跨进程恢复和交易追踪。
工程难点：请求已发出、柜台已接受和订单已成交，是不同阶段。系统分别跟踪这些状态，结合真实成交处理剩余数量和持仓占用，处理部分成交、撤单期间回报、平仓限制及换月依赖。
08 / 风险检查、账户核对与异常恢复
细分能力：开仓风险检查、报价与交易时段校验、平仓数量占用、策略持仓与账户持仓核对、断线重启恢复，以及结果未确认订单的追踪。
优势：将明确拒绝、暂时等待和结果不确定分别处理，便于选择相应的恢复路径。账户、账本和订单状态共同决定是否具备继续执行的条件。
工程难点：超时不能直接等同于下单失败。对结果不明确的委托保留原始订单身份与相关占用，后续依据柜台回报核对处理；持仓异常则进入核对与恢复流程，减少盲目重试、重复报单和错误平仓的风险。
09 / 监控告警、运维与发布验证
细分能力：进程管理、健康与就绪检查、策略运行状态、队列连续性、数据新鲜度、账户差异、告警通知、命令行运维和版本发布。把盘中问题定位到具体服务及其依赖。
优势：监控覆盖运行进程、计算进度和交易状态多个层面，可以区分服务存活与业务是否具备运行条件；前端数据同步问题也能与交易主链路问题分别观察。
工程难点：系统升级需要延续已有订单、持仓和计算状态。围绕状态保留建立发布检查，并针对行情修订、事务回滚、断线重启、迟到成交和部分成交编写回归用例，在优化时对照计算与恢复结果。
10 / Web 前端、数据网关与绩效归因
细分能力：回测绩效、净值与收益曲线、品种相关性、实盘对账、滑点分析、未匹配信号、实时持仓，以及数据访问控制和 WebSocket 推送。独立完成前端页面、接口衔接与部署。
优势：把研究、执行和运行状态放到同一观察体系中，既能查看整体表现，也能下钻到品种、策略和具体交易。展示数据通过独立网关提供，浏览器不持有数据库服务密钥和柜台凭据。
工程难点：回测与实盘的时间、价格及交易记录并不天然一致，需要统一匹配口径，并保留无法匹配的差异；实时页面还要区分连接成功、收到快照和数据更新是否及时，避免把过期数据显示成当前状态。
在真实运行中，继续完善系统
当前迭代围绕实盘稳定性、恢复边界、执行可观测性和计算效率持续展开。每一次优化都需要回到同一个问题：行情相同、初始状态相同时，计算结果与交易状态是否仍然一致，异常之后能否继续追溯和恢复。
下一阶段同步推进 v0.8 的 C++ 计算核心与 CTP 执行链重构，逐步验证数据接入、状态持久化、柜台连接和恢复流程。这部分属于持续研发与验证工作，与现有实盘运行版本分别管理。
主要技术：Python / asyncio、SQLite、Linux / systemd、RQData、TqSdk、Next.js、React、TypeScript、ECharts、Cloudflare Workers / Durable Objects、Supabase；下一代架构持续推进 C++ 与 CTP。
让长期投资有章可循，也让生活不必围着行情转。我围绕这一目标，将多资产配置研究、分层因子、风险管理与 Web 产品连接起来，完成正式策略的模块化重构、数据与计算服务、前端交互及云端部署，形成一套可以日常使用的投资辅助系统。
组合覆盖红利、标普、纳指、黄金、豆粕与政金债六类资产，通过境内 ETF 与债券基金承载配置，另设现金仓位。策略坚持不做空、不加杠杆，以较低操作频率管理跨市场敞口。目前实盘资金规模达到人民币 120 万元，研究与产品持续迭代。
回测表现：两位数年化，较低回撤
按当前正式规则，2020 年 3 月 25 日至 2026 年 9 月 8 日的历史回测，年化收益约 14.66%，最大回撤幅度约 2.77%，卡玛比率约 5.29。在这段超过六年的历史区间内，组合以不到 3% 的最大回撤取得两位数年化回报，展现出突出的收益与回撤平衡，这是项目最重要的研究成果之一。
回测按信号后的交易日执行，并计入佣金和流动性冲击估计。策略将资产分散、仓位约束、单品种利润保护与组合止损放在同一套框架内，持续评估收益、回撤和操作负担。上述指标属于该区间的历史回测，实盘规模为当前资金投入，两者分别呈现；历史结果不构成未来收益承诺。
L0–L4：五层架构，十二组核心因子
L0 · 基础配置。建立长期资产配置的起点，明确权益、商品与防守资产各自的职责。L1–L4 在这一基础上逐层调整，各层都有独立的输入、输出和仓位约束，便于追踪某次配置变化来自哪类信息。
L1 · 宏观环境。结合美国实际国债收益率与美元环境，分析黄金所处的宏观背景，为配置提供低频环境判断。处理跨时区和数据发布时间，使信号使用当时已经可以获取的信息。
L2 · 通用趋势。通过多周期动量与趋势信息，形成可跨品种复用的判断框架，协调不同资产的风险预算。研究重点包括趋势变化对回撤的影响，以及调整幅度与组合稳定性的平衡。
L3 · 品种特征。结合股息与利率关系、资产自身的价格状态，以及商品的期限结构、成交量、持仓量和供需信息开展分析。针对不同资产采用具有经济含义的研究方向，将收益机会与风险约束分别纳入判断。
L4 · 相对价值与跨市场协同。研究资产间的相对强弱、权益市场压力及跨资产联动，在组合层面协调资金配置。正式启用的核心因子按模块归为 12 组，部分模块包含多个子因子；基础仓位、组合优化和止盈止损另行管理。
双月配置，持有期持续风控
常规配置以每两个月一次的节奏更新，信号在收盘后确认并确定目标配置，用户在下一共同交易日按新目标调仓。提前看到资产比例与调整方向，可以减少临盘判断和频繁追涨杀跌带来的操作负担。
持有期间继续按日观察风险：组合层关注波动、回撤、相关性和量价压力，单品种层关注盈利后的回吐。触发后按既定规则降低相应风险敞口，并通过周期状态控制重复触发。定期调仓的防守调整与持有期转入现金分别处理，使资金去向和事件原因可追溯。
组合构建始终校验单资产边界、防守资产约束、非负仓位及资金总额。在追求收益的同时，将可承受的风险与可执行的操作节奏纳入策略设计。
研究价值：每一层都有保留的理由
因子研究同时考察经济逻辑、数据质量和对组合的实际贡献。通过模块开关对照、分阶段检验及边际贡献分析，区分改善收益的信号与控制风险的信号；对已有信息进行去重，减少多个因子反复表达同一种市场暴露。
商品研究将价格与交易活跃度、产业链相对表现、公开供需报告结合，并区分收益信息与风险信息。相关研究记录包含跨年份检验、执行延迟和交易成本压力测试，帮助判断收益贡献是否过于依赖少数年份或理想化成交条件。
正式版本也保留了主动做减法的过程：剔除更新不稳定的数据依赖，比较不同风控版本的操作次数、回撤恢复时间与收益取舍。经过评估的规则和参数单独冻结，后续研究形成候选，再经过对照验证进入正式链路，让迭代具有依据。
五个部分协作，让研究进入日常运行
本地正式策略负责研究成果复现、模块验证与回归；Supabase 数据采集层组织多源数据更新；独立的 Vercel 数据中转服务处理需要 Python 适配的来源；Vercel 计算服务执行因子、组合构建和净值回放；Next.js 前端负责绩效展示与调仓交互。Turso 连接这些部分，统一保存原始数据、每日净值和调仓事件。
数据更新后，计算服务读取统一的数据快照，依次完成 L0–L4 与组合优化，再纳入持有期止盈止损，生成净值、策略估值权重、目标配置与事件记录。前端经服务端接口读取这些结果，将研究输出转成用户可以理解和使用的信息。
采集、计算和展示各自有明确职责。行情来源可以独立维护，策略模块可以单独验证，前端功能也可以持续扩展，使系统具备长期演进的空间。
工程难点一 · 把不同数据对齐到同一时点
ETF 行情、基金净值、利率、指数和供需报告的发布时间、交易日历与数值尺度各不相同。我将数据源适配、日期与单位校验、历史重叠更新及缺失检查组织为统一的数据处理流程，并处理期货连续序列和换月数据，降低输入口径差异对策略的影响。
估值与信号采用不同的数据要求：晚发布的基金净值允许暂估，补齐后修正历史；正式调仓依赖的关键因子缺失时则进入等待状态。宏观数据和报告按可用时点对齐，避免将尚未发布的信息提前用于判断。
工程难点二 · 让信号、执行与净值保持一致
目标配置在信号日确定并记录为待执行，后续行情到达后，回放按已确定的目标执行并更新同一事件。事件身份贯穿前后两个阶段，使重复计算、次日价格变化和状态更新能够遵循一致的处理规则。
系统分别保存随价格漂移的估值权重与已确定的目标权重：前者用于净值核算，后者用于配置展示和调仓计算。止盈止损同时保留周期约束、触发原因与调整明细，让净值变化、风险动作和前端展示之间可以相互核查。
工程难点三 · 历史可修正，任务可重复运行
多来源更新需要处理超时、重复请求和部分失败。数据层采用增量扫描、受控并发、退避重试和任务锁；已成功更新的品种可以独立保留，失败项后续继续补齐，减少单个来源异常对整条链路的影响。
计算层通过历史回放重新核对净值与事件，再按业务内容指纹比较已有记录，只写入新增或发生变化的数据。这样既能处理迟到净值和历史修订，也能减少重复写入；同一调仓事件使用稳定编号，避免反复计算生成多份记录。
前端协作 · 把配置比例转成可执行的金额
前端提供净值走势、收益与风险指标、日期及品种筛选，以及调仓和风险事件记录。服务端分别提供净值序列与调仓数据，页面按用途使用估值权重或目标权重，避免将“当前如何估值”与“接下来如何配置”混为一谈。
调仓计算器支持输入总资金或各资产的已有持有金额，依据策略目标换算配置金额，并显示买入、卖出、持有及现金调整建议。浏览器缓存、响应数据校验与版本比对帮助页面快速恢复内容、识别数据变化，移动端也能完成查询和金额换算。
产品面向愿意长期配置、按规则定期调整，但没有精力持续盯盘的普通投资者。将日常使用收敛为查看配置、核对事件、按自身资金计算调整金额，让复杂研究有一个清楚、低负担的使用入口。
主要技术：Python、Pandas、NumPy、FastAPI、Deno、TypeScript、Next.js、React、Tailwind CSS、ECharts、Turso、Supabase、Vercel 与 Cloudflare Workers。