状态：定稿 日期：2026-08-20 来源：由文档 docs/10-discussion.md「2026-08-20 回测机制路线」迁移而来
议题
回测短板怎么补？——直接把开源回测项目并进系统，还是自建"可信回测"机制链？
立场（系统所有者）
- 原本想"把 tickflow-stock-panel / paperswithbacktest / FinEval 并进系统补回测短板"。
- 讨论中把需求收敛清楚：真实需求不是"多一套执行工具"，而是回测框架/机制——自己不懂回测代码，只要能读懂每个论断成不成立、能不能信。
支持证据（三开源项目 2026-08-20 评估）
- tickflow-stock-panel：18 个技术+情绪策略；walkforward / 网格 / IC 能力强；Free 账号可批量日K 拉 100 标的，pro 才给分钟五档——三者里思想最值得借鉴的。
- paperswithbacktest / pwb-toolbox：基于 Backtrader + Roll-Gibbs 成本模型；无 walkforward / IC、无分钟级能力。
- FinEval：284★ 中文金融选择题知识门禁，可离线测试——偏知识基准，不是回测框架。
反方（讨论中最强反对论点）
- 直接并库 = 造黑箱：第三方框架管道一旦入库，"信号怎么算、成交怎么撮合"就成了看不见的黑箱，违背"无来源 = 不存在"铁律——与把回测当"可信证据"的目标背道而驰。
- 需求量的方向不对：用户要的是"这一条论断信不信"（判断可信度），不是"多一种策略执行工具"；并库解决的是后者，解决不了前者。
- 数据底座已够：本地 内部数据（约 2.2GB / 19 市场 / 前复权）已够当复测数据底座，不需要靠开源框架补数据。
结论（定稿）
- 0 个开源项目入库，只吸收其思想，自建"可信回测"机制链：
- 通用引擎：内部数据 共享库（吸收 tickflow 样本外/网格思路、pwb 指标思想）；
- 论断配方：
000-claims-def.md（每个论断的"定义 → 操作化 → 判据"）； - 白话论断卡：
000-FORMAT-SAMPLE-白话卡.md模板（给不写代码的人看：5 秒扫结论、30 秒懂方法）； - 可信协议：
000-PROTOCOL.md十二项清单（红绿灯验收）。
- 产品形态 = 人话卡：数学交给程序、配方交给数据、人话交给技能（读卡能力）。
系统改动
- ✅ 已实施：内部数据（共享引擎库）
- ✅ 已实施：内部数据（确定性复测引擎，挂共享层）
- ✅ 已实施：000-PROTOCOL.md / 000-claims-def.md / 白话卡模板
- ⏳ 待实施：
fengbacktest.py后续接入共享层（统一口径，避免双套判据）