横截面因子研究 - 术语详细解释
配套文档：
./英文术语表.md适用范围：content/quant/量化研究/横截面因子研究/展开讲/
这份文档不是再重复一遍“术语定义”，而是把第一次阅读最容易卡住的词，尽量改写成：
- 先说人话
- 再给一个最小例子
- 尽量说明它和上下游的关系
如果你看原术语表时觉得“字都认识，但不知道在研究流程里到底怎么用”，这份文档就是给这个问题准备的。
0. 先固定一个贯穿全篇的小例子
后面很多术语都会复用下面这个小场景。
假设我们在 2026-01-08 00:00 UTC 做一轮横截面比较，研究 universe 只有 4 个币：
- BTC
- ETH
- SOL
- DOGE
我们定义一个最简单的因子：
ret_20d：过去 20 天收益率
当天 4 个币的因子值如下：
| asset | ret_20d |
|---|---|
| BTC | 8% |
| ETH | 12% |
| SOL | 20% |
| DOGE | -5% |
如果第二天收益率是：
| asset | 次日收益 |
|---|---|
| BTC | 0.5% |
| ETH | 1.0% |
| SOL | 2.2% |
| DOGE | -1.3% |
那这个因子在这个时点上就算“排得还行”，因为它把 SOL 排在前面，把 DOGE 排在后面，而后续收益也确实大体对应这个顺序。
后面凡是提到：
- 排序
- 分桶
- Rank IC
- long-short
- horizon
都可以先代回这个小例子来理解。
1. 先看：哪些字段属于哪个阶段，为什么要有它
这一节不是严格的“唯一归属表”，因为少数字段会跨阶段复用。 但第一次阅读时，最重要的不是死记字段名，而是先知道：
- 这个字段通常写在哪个阶段
- 它是为了防哪一类研究错误
- 如果不写清，后面最容易出什么问题
Mandate 阶段常见字段
这一阶段主要回答“我要研究什么，边界是什么”。
如果 Mandate 不清，后面最容易发生的不是代码错误，而是研究边界漂移。
research_intent/observation/hypothesis/counter_hypothesis为什么要有：把“为什么研究这条线”写成可复核的假设，而不是事后看到结果再编故事。 不写清会怎样：后面容易变成“哪个结果好看就说自己原本想研究哪个”。research_route为什么要有：明确你是在做横截面排序、时序预测，还是别的路线。 不写清会怎样：后面会混入不属于这条路线的评价指标，比如横截面研究里混进单资产命中率。scope_contract为什么要有：锁死研究允许覆盖的范围，比如单因子还是多因子、单 venue 还是跨 venue。 不写清会怎样：后面一旦结果不好，就会偷偷扩大或缩小范围。target_market/venue_scope/universe为什么要有：明确到底比较哪些资产、在哪个市场里比较。 不写清会怎样：后面可能把完全不同交易环境的资产混在一起，导致结果不可比。time_split/horizon为什么要有：提前锁住训练窗、测试窗、holdout 窗和评价持有期。 不写清会怎样：最容易发生“看了结果再挪窗口、再换 horizon”的事后优化。portfolio_expression为什么要有：明确研究结果最终准备走long_only_rank还是long_short_market_neutral。 不写清会怎样：后面会把本来不是一个研究对象的东西硬说成“只是实现方式不同”。kill_criteria为什么要有：提前写清哪些情况出现后就该停，不再继续往下磨。 不写清会怎样：研究会进入“越失败越加码解释”的死循环。
例子：
如果你要写“这条线研究的是 binance_spot 上的日频横截面动量，评价 1d horizon，最终准备走 long_only_rank 表达”，这些内容首先属于 Mandate，因为它们在定义研究边界，而不是在报告研究成绩。
DataReady 阶段常见字段
这一阶段主要回答“后面所有人共享的数据底座长什么样”。
如果 DataReady 不清，后面表面上在比较因子，实际上是在比较不同的数据世界。
data_contract为什么要有：明确允许使用哪些数据源、哪些字段、哪些时间语义。 不写清会怎样：有人会多用一个字段，有人会换一个源，结果根本不在同一地基上。panel_contract/panel_manifest为什么要有：把date x asset面板的主键、频率、时区、覆盖范围冻结成统一合同。 不写清会怎样：不同人算出来的样本空间不一致，后续所有比较都会变味。date_key/asset_key/panel_frequency/timezone为什么要有：明确“这是什么时候、这是谁、按什么粒度、按哪个钟表”。 不写清会怎样：最容易出现错位对齐，尤其是不同频率和不同时区混用。asset_universe_membership为什么要有：记录某资产在某时点是不是 universe 成员。 不写清会怎样：后面别人无法判断某资产是本来不在 universe，还是只是数据缺失。eligibility_contract/eligibility_base_mask为什么要有：明确哪些样本在基础层面有资格进入研究。 不写清会怎样：训练、测试、回测会各自用不同过滤规则，样本口径飘来飘去。shared_feature_base为什么要有：给后续因子提供统一复用的基础字段层。 不写清会怎样：每个人都自己重算一遍基础字段，容易得到多个版本。taxonomy/taxonomy_contract为什么要有：把分类体系固定住，便于后面做group_neutral或解释风险暴露。 不写清会怎样：今天这个币算meme，明天又算defi，中性化和解释都不稳定。price_source/liquidity_source为什么要有：明确价格和流动性从哪里来。 不写清会怎样：成本、容量、收益计算会建立在不同口径的行情上。coverage_rule为什么要有：规定什么条件下一个样本才算正式覆盖。 不写清会怎样：表面 coverage 很高，实际很多样本根本不满足正式研究资格。available_after/time_semantics为什么要有：明确一个字段是什么时候可见、什么时候才算能被合法使用。 不写清会怎样：极容易产生lookahead和leakage。
例子：
如果你要写“主键是 date x asset、频率是 1d、时区是 UTC、上市不足 90 天不进入 eligibility”，这些内容优先属于 DataReady，因为它们在锁数据世界，不是在定义因子胜负。
SignalReady 阶段常见字段
这一阶段主要回答“这个因子到底是什么，扮演什么角色”。
如果 SignalReady 不清，最容易发生的是“同一个名字，大家研究的不是同一个东西”。
factor_id/factor_name为什么要有：给因子一个稳定身份，避免版本混淆。 不写清会怎样：文档里都叫“动量因子”，但实际用的公式可能完全不同。factor_identity为什么要有：明确输入字段、变换链、时间语义和最终输出到底是什么。 不写清会怎样：名字一样的因子可能已经换了芯，review 时也抓不出来。factor_role/factor_role_contract为什么要有：明确它是standalone_alpha、regime_filter还是combo_filter。 不写清会怎样：后面会拿错尺子去量，比如用独立排序能力去否定一个本来只是过滤器的对象。factor_structure/factor_structure_contract为什么要有：明确它是single_factor还是multi_factor_score，以及允许怎样组合。 不写清会怎样：后面会悄悄往一个“单因子”里塞越来越多辅助逻辑。raw_factor_fields/derived_factor_fields为什么要有：区分原始输入和派生变量，方便复现和审计。 不写清会怎样：别人看到最终公式时，不知道中间变量从哪来。factor_manifest/factor_contract为什么要有：把因子的身份、版本、依赖和使用方式形成清单。 不写清会怎样：下游容易拿错版本，或者拿了不兼容的处理方式。selected_factor_spec为什么要有：明确哪一个版本被正式选中进入下游。 不写清会怎样：后面会出现“我以为你说的是另一个版本”的歧义。signal/alpha/standalone_alpha/regime_filter/combo_filter为什么要有：这些字段不是装饰，它们在告诉下游“这个对象是排序主角，还是只是一层辅助条件”。 不写清会怎样：策略设计和证据标准都会错位。single_factor/multi_factor_score为什么要有：明确是单逻辑还是固定公式组合。 不写清会怎样：Signal 阶段会和 Train 阶段混在一起，边界越来越模糊。
例子：
如果你要写“MOM_20D_V1 由 close 派生，角色是 standalone_alpha，结构是 single_factor”，这些内容优先属于 SignalReady，因为它们在定义因子身份证。
TrainFreeze 阶段常见字段
这一阶段主要回答“后面复用的处理尺子是什么”。
如果 TrainFreeze 不清，最容易出现的问题就是：结果不好看时，处理尺子也跟着一起变。
preprocess_contract/preprocess为什么要有：把清洗、标准化、变换流程固定下来。 不写清会怎样：同一个因子在不同人手里会被洗成不同版本。winsorize/clipping为什么要有：控制极端值对横截面排序和统计量的破坏。 不写清会怎样：少数离群点可能把整个评估结论拉歪。zscore/cross_sectional_zscore/rank transform为什么要有：把不同量纲、不同分布的值转成可比较的尺度。 不写清会怎样：组合权重和分桶结论会高度依赖原始尺度，难以复现。MAD/mad_3为什么要有：提供鲁棒的异常值处理尺子。 不写清会怎样：你可能今天按标准差处理，明天按分位数处理，结果没有统一性。neutralization_contract/neutralization_policy为什么要有：明确要不要对市值、beta、分类暴露做剥离，以及怎么剥。 不写清会怎样：结果好看时不知道赚的是因子钱还是暴露钱。ranking_bucket_contract为什么要有：固定分桶方法，避免后面为了图好看临时换桶数。 不写清会怎样：今天五桶、明天十桶，单调性好坏都没法比较。bucket/quintile/decile/tercile/ties为什么要有：这些都是“排序怎么落地成比较组”的细节。 不写清会怎样：重复跑的结果可能不一致，尤其是并列值很多时。min_cross_section_size为什么要有：防止样本过少时还硬做正式统计。 不写清会怎样：极小横截面上的偶然性会被误当成有效证据。rebalance_contract/schedule_only/auxiliary_conditions为什么要有：提前锁定调仓规则和辅助触发条件。 不写清会怎样：测试和回测会隐含使用不同调仓习惯。
例子：
如果你要写“先去极值，再做截面 z-score，再对 log_market_cap 中性化，最后按 quintile 分桶”，这些内容更像 TrainFreeze，因为它们是在定尺子。
TestEvidence 阶段常见字段
这一阶段主要回答“独立样本上的证据够不够”。
如果 TestEvidence 不清，最容易出现的问题是：只看到了几个好看的数字，却不知道证据到底稳不稳。
OOS为什么要有：强调这里看的不是训练窗内表现，而是独立样本上的表现。 不写清会怎样：训练内拟合结果容易被误当成真实证据。Rank IC/IC/ICIR为什么要有：分别回答“排序对不对”“平均有没有信息”“稳定不稳定”。 不写清会怎样：你可能只汇报了均值，却掩盖了月份之间的大起大落。bucket returns/monotonicity为什么要有：看高分组和低分组是否真的形成稳定分层。 不写清会怎样：一个因子可能只是 top bucket 偶尔很强，但整体排序并不稳定。breadth/coverage为什么要有：判断这个信号是不是只靠少数资产、少数时段在贡献。 不写清会怎样：一个窄得不能再窄的偶然现象会被误当成普遍规律。qcut为什么要有：把“按分位数分桶”的方法说清楚。 不写清会怎样：分桶比较会因为实现差异而不可复现。admissibility/admissibility_contract为什么要有：明确什么叫“证据够资格进入下一阶段”。 不写清会怎样：是否推进会变成主观拍板，而不是按标准办事。audit_contract为什么要有：规定必须留下哪些证据给别人复核。 不写清会怎样：别人只能相信结论，无法重走推理链。gated vs ungated为什么要有：区分“因子本身有用”还是“过滤条件在起主要作用”。 不写清会怎样：你可能把 filter 的贡献误记到 alpha 身上。rolling OOS为什么要有：避免只挑一个好看的测试窗口。 不写清会怎样：单窗幸运很容易被误判为稳健性。variant/variant ledger/reject ledger为什么要有：把试过哪些版本、为什么保留、为什么拒绝记录下来。 不写清会怎样：团队很容易反复尝试同样的 dead end。
例子：
如果你在汇报“这个因子在测试窗里平均 Rank IC 为正，高低分桶分层明显，coverage 也足够”，这些内容主要属于 TestEvidence，因为它们是在回答“证据够不够”。
BacktestReady 阶段常见字段
这一阶段主要回答“怎么把信号变成真正的交易表达”。
如果 BacktestReady 不清，最容易发生的是：研究层看起来成立，交易层一落地就完全不是同一回事。
execution_policy/execution_contract为什么要有：明确下单时点、成交假设、延迟和执行约束。 不写清会怎样：回测收益可能建立在不可实现的成交假设上。signal to trade lag为什么要有：把信号与交易之间的时滞写死，防止偷吃未来。 不写清会怎样：研究结果很容易被虚假的“零延迟执行”美化。maker/taker为什么要有：手续费和可成交性高度依赖成交方式。 不写清会怎样：成本模型可能明显偏乐观。portfolio_policy/portfolio/portfolio_weight_panel为什么要有：明确如何从信号映射到仓位，并留下完整持仓轨迹。 不写清会怎样：别人无法重建你的组合路径，也无法检查调仓行为。weights/score weighted为什么要有：明确是等权、按分数加权，还是别的分配规则。 不写清会怎样：同样一组信号，不同人会得到完全不同收益曲线。long/short/market neutral/beta neutral/group_neutral为什么要有：明确你到底想押什么、不想押什么。 不写清会怎样：你以为自己在赚因子钱，实际上可能只是在押市场或押某个组别。risk_overlay/group exposure为什么要有：把单币暴露、分类暴露、其他集中度约束加在组合之上。 不写清会怎样：组合可能因为少数暴露过大而出现失真收益。cost model为什么要有：把手续费、滑点、资金费率这些现实损耗纳入。 不写清会怎样：gross 很美，net 很难看。liquidity/capacity/participation_rate为什么要有：回答这套东西能不能在真实市场里装下你想要的资金。 不写清会怎样：策略只在纸面上成立，一上规模就崩。engine_contract/vectorized/event-driven为什么要有：明确回测是按什么引擎、什么实现口径算出来的。 不写清会怎样：同一个策略在不同引擎里结果不同，大家却以为在讨论同一件事。
例子：
如果你要写“做多 top 20%、做空 bottom 20%、默认 taker 成交、单币权重不超过 5%、参与率不超过 10%”，这些内容优先属于 BacktestReady，因为它们在定义交易可实现性。
HoldoutValidation 阶段常见字段
这一阶段主要回答“最终未见窗口上，这套冻结方案是否还成立”。
如果 HoldoutValidation 不清，最容易发生的是：holdout 一旦不好看，就忍不住回头改上游。
window_contract为什么要有：明确 holdout 到底是哪段窗口、允许被消费几次。 不写清会怎样：holdout 会从“最终验证”变成“可以反复试到满意的测试集”。reuse_contract为什么要有：明确哪些上游冻结对象必须原样复用。 不写清会怎样：一看到 holdout 不好，就会偷偷回头改 preprocess、neutralization 或 execution。drift_audit为什么要有：解释 holdout 与上游阶段相比到底偏离了什么、偏离是否合理。 不写清会怎样：只能看到“变差了”，却说不清是市场变了、样本变了，还是方案本身不稳。holdout_backtest_compare为什么要有：把 holdout 和 backtest 放在同一坐标系下比较。 不写清会怎样：你无法判断 holdout 是轻微变差，还是结构性失真。verdict/PASS/CONDITIONAL PASS/NO_GO/CHILD LINEAGE为什么要有：给最终结论一个正式门禁结果，而不是口头印象。 不写清会怎样：团队不知道该继续推进、带条件推进，还是彻底停止。
例子：
如果你在做“holdout 与 backtest 是否一致、是否允许继续推进”的结论判断，这些字段通常属于 HoldoutValidation，因为它们在回答“最后还成不成立”。
一个最简记忆法
Mandate：研究什么，以及为什么值得研究DataReady：数据世界是什么，以及为什么这样定义SignalReady：因子身份是什么，以及为什么这样定义身份TrainFreeze：处理尺子是什么，以及为什么必须冻结TestEvidence：证据够不够，以及为什么能信BacktestReady：交易表达是什么，以及为什么可落地HoldoutValidation：最后还成不成立，以及为什么能下结论
2. 阶段与治理术语
Mandate
人话解释：研究立项合同。先锁边界，再开始干活。
例子：你在 Mandate 里写死：
- universe =
binance_spot可交易市值前 50 horizon = 1d- 表达方式 =
long_short_market_neutral
这时如果后面有人想把 universe 改成 Bybit 永续，或者把 1d 改成 5d，那就不是“小修小补”，而是动了研究合同。
DataReady
人话解释：先把“后面所有步骤都要共用的数据地基”冻住。
例子：你规定后续所有评估都只能使用：
- UTC 对齐的
1d面板 - 统一的资产主键
- 同一个
eligibility_base_mask
一旦 DataReady 冻结，下游就不能有人悄悄改时间语义或换数据源。
SignalReady
人话解释：把“这个因子到底是什么、准备拿来干嘛”说清楚。
例子：同样是 ret_20d，你可以把它定义成：
- 独立排序因子
standalone_alpha - 只做环境过滤的
regime_filter
这两个角色完全不是一回事，所以必须在 SignalReady 里冻结。
TrainFreeze
人话解释：把后面必须复用的“尺子”锁住。
例子：你在训练窗上决定：
- 先
winsorize - 再做
cross_sectional_zscore - 再做
log_market_cap中性化 - 最后按
quintile分 5 桶
这些规则一旦冻结，后面的测试和回测都得沿用，不能见结果不满意再改。
TestEvidence
人话解释：在独立样本上看，这个东西有没有证据，不是看它是不是已经可以实盘。
例子：你在测试窗里看到：
- Rank IC 为正
- 高分桶收益高于低分桶
- 单调性还可以
那可以说“有证据”，但还不能直接说“可以大资金交易”。
BacktestReady
人话解释：开始把研究对象翻译成“怎么交易、怎么算成本、怎么控风险”的正式方案。
例子：在这个阶段会明确：
- 做多前 20%，做空后 20%
- 每天调仓一次
- 使用 taker 成本
8 bps - 单币权重不超过 5%
这已经不是“因子是否有信息量”的问题，而是“怎么把它放进交易层”的问题。
HoldoutValidation
人话解释：拿最终保留、没参与设计的窗口做最后一次检查。
例子：你前面所有设计都只看到了 2024-01 到 2025-12，那 2026-01 到 2026-03 可能就是 holdout。
只有前面方案冻结后，才能看这段数据。
Backtest
人话解释：按历史数据模拟“如果当时这样交易，会发生什么”。
例子：每天收盘后按因子打分，第二天开盘调仓，扣掉手续费和滑点，累计出净值曲线，这就是回测。
Train / Test / Holdout
人话解释：
Train：用来定尺子，不是用来宣布胜利Test：用来验收证据Holdout：最后一块完全保留的“未见样本”
例子：
Train = 2022-2023
Test = 2024
Holdout = 2025
Shadow
人话解释：像实盘一样跟踪，但先不上真钱。
例子：系统每天真的生成信号、真的记录假想成交、真的算持仓收益，但不下真实订单。
PASS / CONDITIONAL PASS / NO_GO
人话解释：
PASS：通过，可以进入下一阶段CONDITIONAL PASS：能进，但要带着限制条件NO_GO：不通过，不能往下走
例子：
如果因子只在高流动性资产里有效，那可以给 CONDITIONAL PASS，并附加限制：
- 仅允许 top 30 liquidity universe
- 不允许扩到长尾资产
lineage / child lineage
人话解释：研究谱系，就是“这条研究线到底还是不是原来那条线”。
例子： 你本来做的是：
binance_spot1d horizonlong_only_rank
后来你改成：
bybit_perp5d horizonlong_short_market_neutral
那这通常不该算“同一条线继续优化”，而应视为 child lineage。
review / formal gate
人话解释：正式门禁检查，不是随便看一下。
例子：review 时会问：
- 这个阶段需要的文件齐了吗
- 时间语义有没有前视
- 下游有没有偷偷改上游冻结内容
QROS
人话解释：用阶段冻结和门禁审查来治理量化研究流程的一套操作系统式框架。
例子：它不是某个模型，也不是某个指标，而是一套“什么阶段能做什么、什么时候必须停下来审”的纪律。
kill_criteria
人话解释：明确写出“出现什么情况就该停”。
例子：
- 连续多个独立窗口 Rank IC 为负
- 容量一加就彻底失效
- 只能靠扩大 lookahead 才能好看
这些都可以写进 kill_criteria。
failure_governance
人话解释：失败以后怎么办，不靠拍脑袋决定。
例子： 如果 Holdout 失败，规则可能要求：
- 先判断是不是数据重建问题
- 再判断是不是因子失效
- 最后决定是终止，还是开
child lineage
3. 样本、市场与时间语义术语
cross_sectional_factor / cross-sectional
人话解释：同一时点，比较不同资产谁强谁弱。
例子：
在 2026-01-08 这一天，把 BTC、ETH、SOL、DOGE 放在一起排队，这就是横截面。
它不是问“BTC 明天涨不涨”，而是问“今天这几个币谁相对更值得买”。
date x asset
人话解释：每条样本都由“某一天 + 某个资产”组成。
例子：
(2026-01-08, SOL) 是一条样本，
(2026-01-08, BTC) 是另一条样本。
panel
人话解释：按 date x asset 组织的数据面板。
例子： 行可以是日期，列可以是资产，也可以是长表：
dateassetret_20dvolume_24h
universe
人话解释：这一天允许进入横截面比较的资产池。
例子： 如果你规定 universe 只能包含：
- 上市超过 180 天
- 近 24h 成交量大于 500 万美元
那新币或极度冷门币就不进来。
venue / venue_scope
人话解释：
venue：具体交易场venue_scope：允许纳入哪些交易场
例子：
venue = binance_spot 表示某条数据来自币安现货。
venue_scope = [binance_spot, okx_spot] 表示研究允许同时覆盖这两个 venue。
asset / asset_key / date_key
人话解释：
asset：资产本身asset_key：机器识别资产的唯一键date_key：机器识别时点的唯一键
例子： 如果写成：
asset_key = BTCUSDTdate_key = 2026-01-08T00:00:00Z
那系统就能唯一定位到某个样本。
panel_frequency / bar / bar_size
人话解释：面板按什么时间粒度排列。
例子：
panel_frequency = 1d：每天一条bar_size = 1h：每小时一根 K 线
如果你做日频横截面，通常不会拿分钟级 bar 直接当最终研究面板。
timezone / UTC
人话解释：所有时间到底按哪个时区解释。
例子：
如果 BTC 的日线按 UTC 收盘，SOL 却按北京时间收盘，你把它们放一起排队就会错位。
所以量化研究里很常统一用 UTC。
close_time / open / close
人话解释：
close_time：这根 bar 结束的时间open：开盘价close：收盘价
例子：
一根 1d bar 从 2026-01-08 00:00 UTC 到 2026-01-09 00:00 UTC，
它的 close_time 通常是 2026-01-09 00:00 UTC。
next_bar_open
人话解释：下一根 bar 的开盘时点，经常用来定义“最早可交易时间”。
例子：
如果你用今天收盘后的数据计算信号，那通常只能在 next_bar_open 才开始交易，不能假装今天收盘前就知道。
available_after
人话解释：某个字段到底从什么时候开始可用。
例子：
如果一个基本面数据在 T 日发布，但要到 T+1 09:00 UTC 才能拿到，那 available_after 就不应写成 T。
signal_timestamp
人话解释：信号这个数值到底归属哪个时间点。
例子：
你看到一列信号写着 2026-01-08，要搞清楚它表示的是：
2026-01-08收盘后算出的信号- 还是
2026-01-08开盘前可用的信号
这就是 signal_timestamp 要解决的问题。
time_semantics / timestamp_semantics
人话解释：这个时间到底表示“发生时间”“看见时间”还是“可交易时间”。
例子：
同样一个 2026-01-08：
- 行情发生在
2026-01-08 - 你在
2026-01-09 00:00才看见完整日线 - 你在
2026-01-09 00:01才能下单
如果这三者混在一起，就会产生前视偏差。
time_split
人话解释：训练、测试、回测、holdout 各段时间怎么切。
例子：
train: 2022-01-01 ~ 2023-12-31test: 2024-01-01 ~ 2024-12-31backtest: 2025-01-01 ~ 2025-09-30holdout: 2025-10-01 ~ 2025-12-31
horizon
人话解释：你到底看多久之后的收益。
例子：
horizon = 1d：看 1 天后收益horizon = 5d：看 5 天后收益
如果因子是慢变量，1d 可能没信号，但 5d 可能有。
best_h / best_horizon
人话解释：事后看起来最好的持有期。
例子：
你测了 1d、3d、5d、10d，发现 5d 最好，于是只汇报 5d。
这就是典型的事后最优口径，容易把研究带偏。
lag
人话解释：信号生成和交易执行之间差了几步。
例子：
今天收盘后算出信号，明天开盘才交易，这就是 lag = 1 bar。
T / T+1
人话解释：
T：当前信号时点T+1：下一期
例子：
如果说“在 T 观察，在 T+1 交易”，意思就是：
- 今天看信号
- 明天执行
market / crypto
人话解释：更大层面的市场类别。
例子：
market = crypto 说明这是加密市场研究，不是 A 股、不是商品期货。
binance_spot / binance_futures / bybit_perp / okx_spot
人话解释：具体 venue 的具体市场。
例子：
binance_spot：币安现货binance_futures：币安合约bybit_perp：Bybit 永续okx_spot：OKX 现货
同一个 BTC，在不同 venue 上也可能对应不同流动性、成本和可交易约束。
4. 数据合同与分类术语
data_contract
人话解释：规定“允许用什么数据、按什么时间语义用”。
例子： 你可以规定：
- 价格只允许来自
spot_klines - 成交量只认某个固定 source
- 所有字段都必须有
available_after
panel_contract / panel_manifest
人话解释：
panel_contract：面板应该长什么样panel_manifest：把这个面板的关键信息记录下来
例子：
panel_contract 可以规定：
- 主键是
date_key + asset_key - 频率是
1d - 时区是
UTC
panel_manifest 则把这些写成可审计的清单。
taxonomy / taxonomy_contract / category
人话解释：资产分类体系，以及这套分类从哪里来、怎么复现。
例子： 你把币分成：
layer1defimeme
如果分类规则今天和明天不一样，那 group_neutral 的结果也会跟着乱掉，所以要有 taxonomy_contract。
asset_universe_membership / membership
人话解释：记录某个时点某个资产是不是属于 universe。
例子：
DOGE 在 2026-01-08 可能因为流动性合格而属于 universe，
在 2026-02-01 也可能因为成交量跌破阈值而被剔除。
这就需要 membership 逐时点记录。
eligibility / eligibility_contract
人话解释：样本有没有资格进入正式研究。
例子： 你可以要求：
- 上市满 90 天
- 非稳定币
- 非杠杆代币
- 近 24h 有足够成交量
这些条件合在一起就是 eligibility_contract。
eligibility_base_mask / mask
人话解释：一张真假表，标记每个样本合不合格。
例子：
如果 SOL 当天满足条件，就记为 True；
如果某个新币上市才 10 天，就记为 False。
shared_feature_base
人话解释：后面很多步骤都会反复复用的基础字段层。
例子： 你可能把这些都放进共享基础层：
closevolume_24hlog_market_capdays_listed
后面不同因子就从这里继续派生。
feature / field / fields
人话解释：
field：数据列feature：拿来描述或预测的变量fields：多个字段
例子：
close 是 field，
ret_20d 是 feature，
[close, volume_24h, ret_20d] 是 fields。
market cap / log_market_cap
人话解释：
market cap：市值log_market_cap：市值取对数后的版本，常用于做中性化
例子： BTC 和小币市值差几个数量级，直接拿原值做回归会很不稳，常先取 log。
volume_24h / rolling_volume_24h
人话解释：24 小时成交量。
例子：
如果某个币 rolling_volume_24h 只有 30 万美元，而你策略一天要交易 50 万美元，那它很可能不该纳入 universe。
days_listed / listing_days
人话解释：这个资产上市了多久。
例子：
很多研究会要求 listing_days >= 90，因为新上市资产价格行为太不稳定。
beta_30d
人话解释：过去 30 天估出来的市场 beta 暴露。
例子：
如果一个因子的收益看起来很好，但其实只是“偏爱高 beta 币”，那你做 beta neutral 后可能就消失了。
stablecoin / leveraged_tokens / exchange_token
人话解释：
stablecoin：稳定币leveraged_tokens：自带杠杆结构的代币exchange_token：交易所平台币
例子： 如果你做通用动量排序，通常不会把 USDT、3L/3S 杠杆代币和某些平台币直接混进普通币 universe。
layer1 / defi / meme
人话解释：常见分类标签。
例子：
- SOL、AVAX 可能归到
layer1 - AAVE、UNI 可能归到
defi - DOGE、PEPE 可能归到
meme
这些分类常用于 group_neutral 或风险解释。
lookahead / leakage
人话解释：
lookahead：提前看到了未来leakage：信息从不该来的地方漏进来了
例子：
你用今天完整日线算信号，却假设今天开盘就能交易，这就是 lookahead。
你在训练里用了测试窗才知道的分位阈值，这也是 leakage。
replay / rebuild
人话解释：
replay：按原输入再跑一遍，结果应该一致rebuild：根据合同和产物把数据重新生成回来
例子：
review 的人拿同一个 panel_manifest 和代码，应该能把同一份面板重建出来。
price_source / liquidity_source / spot_klines
人话解释：价格和流动性字段到底来自哪里。
例子：
如果价格来自 spot_klines，但流动性来自另一个不一致的聚合源，就需要说明时间和口径如何对齐。
coverage_rule
人话解释：什么情况下才算“正式覆盖到这个样本”。
例子： 你可以规定：
- 因子值非空
- 价格可得
- 流动性合格
同时满足才算进入正式覆盖。
symbol
人话解释：交易代码。
例子：
BTCUSDT、ETHUSDT 就是 symbol。
它经常和 asset_key 很像，但不一定永远一一对应。
5. 因子、信号与角色术语
factor
人话解释：给资产打分、排序或过滤的研究对象。
例子：
ret_20d、RSI、过去 7 天换手率变化，都可以是 factor。
signal
人话解释：最终要被下游消费的分数、标签或条件。
例子：
同一个 factor 经过预处理和中性化后，可能产出最终 signal：
- SOL = 1.2
- ETH = 0.4
- BTC = -0.1
- DOGE = -1.5
alpha
人话解释：你认为可能解释超额收益的那部分信息。
例子：
如果 ret_20d 能持续把未来更强的资产排在前面，你就会说它可能含有 alpha。
standalone_alpha
人话解释：它自己单独就应该能排出有效顺序。
例子：
如果一个因子必须和别的 10 个因子拼起来才有用，那它通常不算强 standalone_alpha。
regime_filter
人话解释：不是拿来排序，而是判断“什么时候这个策略该开、什么时候该关”。
例子：
你发现动量只在高波动趋势市场有效，那“是否处于高波动趋势状态”就是 regime_filter。
combo_filter
人话解释：在组合层给策略再加一道筛子。
例子：
哪怕某资产分数很高，只要它流动性过低，combo_filter 也可以把它挡掉。
single_factor / multi_factor_score
人话解释：
single_factor：核心逻辑只有一个因子multi_factor_score：多个因子按固定公式加权组合
例子：
single_factor：只用 ret_20d 排序。
multi_factor_score：0.5 * momentum + 0.3 * turnover + 0.2 * RSI_reversal。
factor_id / factor_name / ID
人话解释：给因子一个唯一身份标签。
例子：
factor_id = MOM_20D_V1
factor_name = 20日动量
这样不同版本不会混淆。
factor_identity / identity
人话解释：这个因子到底由什么输入、什么时间语义、什么变换构成。
例子： 同样都叫“动量”， 一个可能是“过去 20 天收益率”， 另一个可能是“跳过最近 1 天后的过去 20 天收益率”。 名字相近，但 identity 已经不同。
factor_role_contract
人话解释：它以后要按什么角色被考核。
例子：
如果你把某因子定义为 regime_filter，就不该再拿“单独 long-short Sharpe 不高”来否掉它。
factor_structure_contract
人话解释：它内部结构允许长成什么样。
例子：
如果合同规定只允许 single_factor，那后来再塞进 5 个辅助字段做加权，就越界了。
factor_role / factor_structure
人话解释：
factor_role：扮演什么角色factor_structure：内部怎么搭
例子：
“动量”可以是 standalone_alpha；
“市值”可以只是中性化控制项；
二者角色不同。
raw_factor_fields / derived_factor_fields
人话解释：
raw_factor_fields：原始输入derived_factor_fields：由原始输入加工出来的字段
例子： 原始输入可能是：
closevolume_24h
派生字段可能是：
ret_20davg_turnover_7d
factor_panel
人话解释：每个时点、每个资产的因子值表。
例子： 一张表里有：
dateassetfactor_value
这就是最基本的 factor panel。
factor_selection
人话解释：候选因子里最后保留了谁。
例子： 你试了 12 个候选因子，最后只保留：
MOM_20D_V1TURNOVER_SURGE_V2
这份结果就是 factor_selection。
factor_manifest
人话解释：记录因子元信息的清单。
例子： 里面可以写：
factor_id- 输入字段
- 派生公式
- 时间语义
- 版本号
factor_coverage
人话解释：这个因子有多少样本 actually 有值。
例子：
如果 10000 个 date x asset 样本里，只有 3500 个能算出值，那 coverage 只有 35%，通常太低。
factor_contract
人话解释：所有关于因子身份、结构、角色和使用方式的约束集合。
例子： 它相当于说：“这个因子以后只能被当成什么、不能被偷偷改成什么。”
selected_factor_spec
人话解释：被正式选中、准备进入下游的因子规格书。
例子： 不是“我记得我们最后选的是那个动量版本”，而是明确写成：
- 哪个版本
- 哪套预处理
- 哪种中性化
expression / portfolio_expression
人话解释：信号最后准备怎样翻译成组合。
例子： 同样一套打分，可以有不同表达：
- 只买高分币
- 做多高分、做空低分
- 每组等权
- 按分数加权
long_only_rank
人话解释：只做多高分资产，不去做空低分资产。
例子： 每天买分数前 10 个币，低分币只是“不买”，而不是拿去做空。
long_short_market_neutral
人话解释：做多高分、做空低分，并尽量让整体市场方向暴露接近 0。
例子： 买入 top 20%，卖空 bottom 20%，多空名义金额都配成 50%。
market_beta_neutral
人话解释：尽量把组合的市场 beta 压到接近 0。
例子： 如果多头大多是高 beta 山寨币，空头大多是低 beta 大币，那表面看多空平衡，实际上还是在押注市场上涨。 这时就需要 beta neutral。
group_neutral
人话解释：尽量别让组合只是押某一类币。
例子：
如果你的高分币全是 meme，低分币全是 layer1，那你赚的可能不是因子钱，而是分类轮动的钱。
group_neutral 就是用来削掉这种偏差。
neutralization / neutralization_policy
人话解释：
neutralization：把某些已知暴露剥掉neutralization_policy：明确剥哪些、怎么剥
例子：
你可以规定“每个时点都对 log_market_cap 和 beta_30d 做截面回归残差化”。
deterministic
人话解释：同样输入一定得出同样输出。
例子：
0.6 * momentum + 0.4 * turnover 是 deterministic。
“让模型自己随机初始化再训练”就不是。
gating / filter / combo
人话解释：
gating：满足条件才放行filter：筛掉不合格对象combo：多个模块一起作用
例子： “只有在高波动 regime 才启用动量，同时过滤掉低流动性资产”，就是一个典型 combo。
gated / ungated
人话解释：
ungated：原始版本gated：加了条件限制的版本
例子：
原始动量因子对全 universe 排序，这是 ungated。
只在高波动日启用，这就是 gated。
momentum
人话解释：过去强，未来可能还强。
例子： 过去 20 天 SOL 涨得最多，如果后面几天它继续跑赢，动量逻辑就成立。
turnover
人话解释：成交活跃度或换手强度。
例子： 一个币价格没怎么涨，但成交量突然放大很多，有时会被理解为资金关注度上升。
VWAP
人话解释：成交量加权平均价，比简单均价更接近真实成交重心。
例子： 如果一天里大部分成交都发生在 105，而开收盘是 100 和 110，那么 VWAP 可能更接近 105。
RSI
人话解释：相对强弱指标，一种常见技术指标。
例子： 如果 RSI 超高，某些策略会把它解释为“短期可能过热”； 另一些动量策略则会把它当作趋势强度的辅助特征。
MOM_20D / ret_20d
人话解释：
ret_20d：过去 20 天收益率这个字段MOM_20D：可能是这个因子版本的 ID 或简称
例子：
ret_20d = close_t / close_t-20 - 1
而 MOM_20D_V2 可能表示“20 日动量 + 某种过滤规则”的版本。
score / score weighted / weights
人话解释：
score：分数score weighted：按分数大小分配权重weights：最终组合权重
例子： 如果 SOL 分数 2.0，ETH 分数 1.0，BTC 分数 0.5， 那 score weighted 组合可能给 SOL 更大权重，而不是三者等权。
6. 训练、预处理与统计证据术语
preprocess_contract / preprocess
人话解释：正式评估前，数据要怎么洗、怎么变。
例子： 可以规定流程为：
- 去掉空值
winsorize- 做截面标准化
- 做中性化
这整套就属于 preprocess。
winsorize
人话解释：不删异常值，但把它们截到边界上。
例子：
如果某天 99% 币的因子值都在 [-3, 3]，只有一个币是 25，
那 winsorize 后它可能被截成 3。
clipping
人话解释：直接按固定上下限裁剪。
例子：
你规定所有 z-score 都不能超出 [-4, 4]，超出就截断。
zscore / cross_sectional_zscore
人话解释：
zscore：变成“离均值多少个标准差”cross_sectional_zscore：每个时点在资产横截面上做 z-score
例子：
某天 4 个资产因子均值是 10，标准差是 5。
SOL 的值是 20，那它的 z-score 大约是 2。
standardize
人话解释：把不同量纲变得可比较。
例子： 一个因子原本是百分比，一个因子原本是美元金额。 不标准化就很难直接组合。
rank transform
人话解释：不用原始数值，直接用排名或分位。
例子： 当天 100 个币里：
- 排第 1 的记成 1.00
- 排第 50 的记成 0.50
- 排第 100 的记成 0.00
MAD / mad_3
人话解释：用中位数绝对偏差来判断离群，更鲁棒。
例子：
有些币数据特别跳，均值和标准差会被拉坏，这时用 MAD 比较稳。
mad_3 常表示超过 3 * MAD 的值要特殊处理。
neutralization_contract
人话解释：训练阶段规定“怎么剥暴露”的正式合同。
例子：
你写死“对 log_market_cap、beta_30d 做线性中性化”，
那测试阶段就不能临时改成“今天用市值，明天不用”。
ranking_bucket_contract
人话解释：以后分桶比较到底按几组、怎么分。
例子： 规定：
- 样本足够时按
quintile - 样本太少时不做分桶
这就避免后面为了图好看临时从 5 桶改 10 桶。
bucket / quintile / decile / tercile
人话解释：
bucket：分组quintile：5 组decile：10 组tercile：3 组
例子： 100 个币按分数排序后：
- 前 20 个是 top quintile
- 后 20 个是 bottom quintile
ties
人话解释：分数并列时怎么处理。
例子： 如果 ETH 和 BTC 分数完全相同， 你要么按 symbol 稳定排序，要么赋同 rank。 这必须固定，不然重复跑会不一致。
min_cross_section_size
人话解释：横截面至少要有多少个资产，才值得正式评估。
例子：
如果某天只有 6 个币满足 eligibility，拿它做 decile 就没有意义。
这时可能因为低于 min_cross_section_size 而跳过该日。
rebalance / rebalance_contract
人话解释：
rebalance：调仓rebalance_contract：规定何时、如何调仓
例子： 你可以规定“每天 UTC 00:00 调仓一次”，这就是 rebalance contract 的一部分。
schedule_only / scheduled_only
人话解释：只允许按预设时间表调仓，不许临时起意。
例子：
哪怕盘中某币暴涨暴跌，只要合同写的是 scheduled_only，也不能因为情绪临时加仓减仓。
auxiliary_conditions
人话解释：额外附加的条件。
例子： 除了每天调仓外，还要求：
- 当天可交易资产数不少于 30
- 市场状态必须属于高波动趋势
这些都属于 auxiliary conditions。
variant
人话解释：同一研究对象在某个轴上的不同版本。
例子： 同样是动量因子，你可能有：
- 20 日收益率版本
- 20 日收益率跳过最近 1 天版本
- 20 日收益率加流动性过滤版本
它们都是 variants。
variant ledger / reject ledger
人话解释：
variant ledger：记录保留过哪些版本reject ledger：记录淘汰了哪些版本以及原因
例子： 如果一个版本被拒绝是因为：
- 只在单个季度有效
- 容量太差
- 严重依赖小币尾部
那最好进 reject ledger，避免以后重复踩坑。
OOS / out of sample
人话解释：样本外，没参与定规则的那部分数据。
例子：
你在 2022-2023 上定了预处理尺子，再去 2024 检验，这个 2024 就是 OOS。
Rank IC / IC
人话解释：看你今天的排序，和未来收益排序是否一致。
例子： 如果你今天把 SOL 排第一，DOGE 排最后， 结果次日 SOL 真的最好、DOGE 真的最差，那 Rank IC 倾向于为正。
ICIR
人话解释：不仅看 IC 平均值，还看它稳不稳定。
例子： 两个因子平均 IC 都是 0.04：
- A：每个月都差不多 0.04
- B：一个月 0.20，下个月 -0.12
那 A 的 ICIR 通常更高。
Sharpe
人话解释：每承受一单位波动，大致赚了多少超额收益。
例子： 两个组合年化收益都 20%：
- 组合 A 波动 10%
- 组合 B 波动 30%
那 A 的 Sharpe 更高。
bps
人话解释：基点。
例子：
1 bps = 0.01%10 bps = 0.10%
如果手续费是 8 bps，就是 0.08%。
bucket returns
人话解释：每个分桶后续收益分别是多少。
例子：
如果 top quintile 平均次日收益是 1.2%，bottom quintile 是 -0.4%，
那分层就很明显。
monotonicity
人话解释：从高分桶到低分桶，收益是不是大体一路下降。
例子： 5 桶收益如果是：
- Q1 = 1.2%
- Q2 = 0.8%
- Q3 = 0.2%
- Q4 = -0.1%
- Q5 = -0.5%
这就是很好的 monotonicity。
breadth
人话解释：这个信号是不是在足够多的资产、时段里都有作用。
例子： 如果它只靠 3 个 meme 币贡献收益，breadth 就很差。
coverage
人话解释：可用样本覆盖程度。
例子： 如果一个因子只在大币上有值，在 70% 的小币上都是空值，那 coverage 不够好。
qcut
人话解释：按分位数切桶。
例子： 100 个币按 qcut 分成 5 桶时，原则上每桶各 20 个。
admissibility / admissibility_contract
人话解释：有没有资格进入下一阶段，以及资格标准是什么。
例子： 可以规定：
- Rank IC 平均值必须为正
- bucket monotonicity 不能太差
- coverage 不能低于 80%
这就是 admissibility contract。
audit_contract
人话解释：必须留下哪些证据，别人才能复核你。
例子： review 可能要求你必须提交：
- 因子定义
- 时间切分
- ungated vs gated 对比
- 成本前后对比
gated vs ungated
人话解释：比较“原始版”和“加条件版”到底谁在起作用。
例子： 如果 ungated 几乎没用，而 gated 很好，就要继续问：
- 是因子本身有用
- 还是 filter 本身在赚钱
regime
人话解释：市场处于什么状态。
例子：
- 单边趋势
- 震荡
- 高波动
- 低波动
这些都可以视为 regime。
rolling OOS
人话解释：不是只做一次 train/test，而是滚动地反复做样本外检查。
例子： 可以按季度滚动：
- 用前两年训练
- 下一季度测试
- 窗口整体往前挪
这样更能看稳定性。
7. 组合、执行、风险与容量术语
execution_policy / execution_contract
人话解释：信号最终怎样变成真实交易动作。
例子： 合同里可以规定：
- 收盘后计算信号
- 下一根 bar 开盘交易
- 默认 taker 成交
- 遇到流动性不足时缩量
execution
人话解释：从信号到成交、到持仓更新的整层动作。
例子： “算分数”还不叫 execution； “根据分数决定买谁卖谁，并扣掉成本更新净值”才是 execution。
signal to trade lag
人话解释：从看到信号到真正交易，中间隔了多久。
例子： 如果信号在日线收盘后产生，而第二天开盘才下单，那就是 1 个 bar 的 lag。
maker / taker / maker-taker
人话解释：
maker：挂单等别人来吃taker：主动吃盘
例子： 如果你假设总能用 maker 低成本成交，回测通常会更好看； 但真实里未必能成交，所以很多保守回测会优先用 taker 口径。
portfolio_policy
人话解释：怎么把信号翻译成仓位规则。
例子： 可以规定：
- 只持有 top 10%
- 每个币等权
- 单币上限 5%
portfolio
人话解释：某个时点你实际持有哪些资产、各占多少。
例子： 如果今天组合是：
- 40% SOL
- 35% ETH
- 25% BTC
这就是一份 portfolio。
portfolio_weight_panel
人话解释：记录每个时点、每个资产权重的面板表。
例子： 你可以回头查到：
2026-01-08持有 SOL 8%2026-01-09降成 5%
long / short
人话解释：
long：做多short：做空
例子： 看多 SOL 就 long SOL； 觉得 DOGE 会相对跑输就 short DOGE。
market neutral / neutral
人话解释：尽量不押注整体市场方向。
例子： 如果全市场突然普涨，你希望组合不要只是因为“整体都涨”而赚钱，而是因为“多头比空头更强”而赚钱。
risk_overlay
人话解释：在原始组合之上再加一层风控约束。
例子： 原始分数想给 SOL 18% 权重，但风险叠加层规定：
- 单币不超过 5%
meme总暴露不超过 15%
那最终权重就得被压下来。
beta neutral
人话解释：组合整体市场 beta 接近 0。
例子： 如果多头平均 beta 是 1.6，空头平均 beta 是 0.4， 那虽然名义金额对称，风险上仍然偏多。 beta neutral 就是处理这个问题。
group exposure / sector exposure
人话解释：组合在某个组上的偏斜程度。
例子：
如果你 60% 仓位都在 meme，那 meme group exposure 就过高。
drawdown
人话解释：净值从高点跌下来多少。
例子：
净值从 1.00 涨到 1.30，再跌到 1.10，
那最大回撤大致是 (1.10 / 1.30 - 1)。
tail risk
人话解释：平时看不出来，但极端时候会很伤的风险。
例子： 某些长尾小币平时很平静，但一旦流动性蒸发，单日可能暴跌 40%，这就是典型 tail risk。
cost model
人话解释：怎么把手续费、滑点、资金费率等损耗算进去。
例子： 一个因子毛收益很好，但每次调仓要扣：
- 手续费
8 bps - 滑点
12 bps
合起来可能就把 alpha 吃光了。
liquidity
人话解释：能不能以合理价格买进去、卖出来。
例子： 如果一天总成交额只有 20 万美元，而你想下 10 万美元的单，流动性显然不够。
capacity
人话解释：这套策略能承载多大资金规模。
例子： 小资金时 Sharpe 很高，大资金一上去就因为冲击成本和参与率约束而失效，这就是容量不足。
participation_rate
人话解释：你的成交量占市场成交量的比例。
例子： 如果某币 1 小时成交量是 100 万美元，而你打算成交 20 万美元，参与率就是 20%。 这个比例太高时，回测里的理想价格往往不可信。
engine_contract
人话解释：结果到底是由什么回测引擎、什么撮合逻辑算出来的。
例子：
同一策略在 vectorized 引擎和 event-driven 引擎里，结果可能不一样。
所以要明确是哪一种。
vectorized
人话解释：按矩阵或数组批量算，快，但交易细节通常简化更多。
例子： 日频 top-bottom 排序策略常能很方便地用向量化方式批量计算。
event-driven
人话解释：按事件一步一步推进，更接近真实交易过程。
例子： 撮合、部分成交、延迟、资金变化等细节，在 event-driven 引擎里更容易表达。
8. Holdout 与解释性审计术语
window_contract
人话解释：这个阶段到底允许看哪段时间，以及能看几次。
例子： 如果 holdout 只允许看一次，那你看完结果后不能再反复打磨直到满意。
reuse_contract
人话解释：进入 holdout 时，哪些上游冻结对象必须原样复用。
例子： 进入 holdout 后，你应该复用：
- 同一份 preprocess contract
- 同一份 neutralization policy
- 同一份 execution contract
不能为了让 holdout 更好看再改。
drift_audit
人话解释：检查下游结果相对上游有没有明显漂移，以及漂移可能来自哪里。
例子： 如果 backtest 时 top-bottom spread 很稳定， 到了 holdout 突然只剩下某个单月在贡献，就要做 drift audit。
holdout_backtest_compare
人话解释：比较 holdout 和历史 backtest 的一致性。
例子： 如果 backtest 里：
- Rank IC 稳定为正
- monotonicity 很顺
但 holdout 里：
- IC 频繁为负
- 分桶顺序乱掉
那对比结果就提示这套东西的稳健性有问题。
verdict
人话解释：最终正式结论。
例子： 可能的 verdict 有：
PASSCONDITIONAL PASSNO_GOCHILD LINEAGE
它不是情绪判断，而是门禁结论。
9. 常见研究字段名与意图字段
research_intent
人话解释：为什么要研究这条线。
例子： “我观察到高换手改善的中市值币，在趋势市里更容易继续跑赢，因此想验证换手变化是否能提供横截面 alpha。”
observation
人话解释：你先观察到了什么现象。
例子： “过去几轮行情里，成交活跃度提升的币种更容易在未来 1-3 天继续跑赢。”
hypothesis
人话解释：你相信这个现象背后的机制是什么。
例子： “活跃度提升意味着资金关注度上升，这种关注度会在短期内延续。”
counter_hypothesis
人话解释：你也要认真写出‘也许根本不是这么回事’。
例子： “看起来像活跃度效应，其实只是小市值 beta 暴露在趋势市里发光。”
research_route
人话解释：这到底是哪一类研究路线。
例子：
如果写成 cross_sectional_factor，
就意味着下游证据重点应该是：
- 排序能力
- 分桶分层
- 横截面稳定性
而不是单资产方向命中率。
scope_contract
人话解释：研究允许覆盖多大范围，哪些边界不能跨。
例子： 你可以规定：
- 只做现货
- 只做日频
- 允许 long-only，不允许 long-short
这就会直接约束下游表达空间。
target_market
人话解释：研究目标市场的正式定义。
例子：
target_market = liquid altcoins on binance_spot, daily frequency
意思就是：
目标不是整个加密宇宙，而是币安现货里流动性足够的一批 altcoin，按日频研究。
10. 怎么用这两份文档
建议搭配顺序是：
- 先看
./英文术语表.md，快速认词 - 再看这份“术语详细解释”，把词放回流程里理解
- 然后去读各阶段文档，例如
./Mandate阶段.md和./DataReady阶段.md
如果你读阶段文档时又看到陌生词，最简单的办法不是死记定义，而是反问自己两件事：
- 这个词是在描述“研究对象”，还是在描述“研究纪律”？
- 它是在回答“这是什么”，还是在回答“什么时候允许这样做”？
多数术语一旦放回这两个框架里，就不会那么抽象了。