From e47d197ff448faa0682eb546d0895eff6e3237e8 Mon Sep 17 00:00:00 2001 From: Codex Date: Wed, 6 May 2026 11:45:07 +0800 Subject: [PATCH] Phase 1 trading plan core --- AGENTS.md | 23 + README.md | 11 + docs/AI_ICT_Dealing_Range_规格书_v1.md | 410 - docs/AI_ICT_Displacement_规格书_v1.md | 494 - docs/AI_ICT_FVG_规格书_v1.md | 466 - docs/AI_ICT_Liquidity_Pool_规格书_v1.md | 429 - docs/AI_ICT_MSS_判定规格书_v1.md | 472 - docs/AI_ICT_MVP_规则规格书_v1.md | 761 - docs/AI_ICT_Migration_拆分计划_v1.md | 493 - docs/AI_ICT_OKX_数据接入规格书_v1.md | 433 - docs/AI_ICT_PostgreSQL_Schema_v1.md | 806 - docs/AI_ICT_Session_生成器规格书_v1.md | 421 - docs/AI_ICT_Sweep_识别规格书_v1.md | 479 - docs/AI_ICT_Swing_识别规格书_v1.md | 494 - ...aining_Case_Engine_外部产品化MVP计划_v1.md | 671 - ...AI_ICT_Training_Case_Engine_开发方案_v1.md | 612 - docs/AI_ICT_主线进度摘要_v1.md | 66 - docs/AI_ICT_交易模块缺口清单_v1.md | 212 - docs/AI_ICT_双主线研发治理计划_v1.md | 422 - docs/AI_ICT_实盘交易分析系统开发计划_v1.md | 978 + docs/AI_ICT_当前开发方案_v2.md | 229 - docs/AI_ICT_总体设计文档_v1.md | 516 - docs/AI_ICT_数据库_Migration_SQL_草案_v1.md | 454 - docs/AI_ICT_文档索引与命名规范_v2.md | 156 - ...AI_ICT_第一批正式_Migration_文件草案_v1.md | 489 - ...AI_ICT_第二批正式_Migration_文件草案_v1.md | 462 - docs/AI_ICT_项目代码骨架规范_v1.md | 492 - ...al_Content_Intelligence_Upgrade_Plan_v1.md | 828 - docs/ICT交易全书_出版终校版.md | 18157 ++++++++++++++++ docs/archive/README.md | 15 - .../history/AI_ICT_主线开发检查点_v1.md | 455 - .../history/AI_ICT_当前工作断点_2026-04-24.md | 71 - .../history/AI_ICT_报告样本_2026-04-24.md | 151 - .../AI_ICT_离线自动化推进记录_2026-04-29.md | 431 - .../obsolete_plans/AI_ICT_开发路线图_v1.md | 592 - .../obsolete_plans/AI_ICT_执行检查清单_v1.md | 339 - .../AI_ICT_文档索引与命名规范_v1.md | 291 - .../AI_ICT_重复文档清理计划_v1.md | 217 - .../obsolete_plans/AI_ICT_项目启动清单_v1.md | 250 - .../training_case_package_smoke_m6.md | 27 - ...aining_case_engine_m1_m6_product_readme.md | 199 - docs/workflow/AI_协作自动化工作规程_v1.md | 338 - docs/workflow/AI_自动化协作迁移清单_v1.md | 239 - .../CLAUDE_template_autonomy_first.md | 225 - docs/workflow/README.md | 7 - ...automation_workflow_migration_checklist.md | 182 - docs/workflow/标准_CLAUDE_md_模板_v1.md | 166 - ...020_create_training_case_engine_tables.sql | 69 + migrations/021_create_trading_plans.sql | 27 + package.json | 10 + scripts/run_autonomous_cycle.py | 1 + scripts/run_trading_plans.py | 114 + src/api/__init__.py | 2 + src/api/server.py | 6 + src/api/trading_plans.py | 29 + src/models/__init__.py | 2 + src/models/trading_plan.py | 27 + src/repositories/__init__.py | 2 + src/repositories/trading_plan_repository.py | 222 + src/services/trading_plans/__init__.py | 19 + .../trading_plans/trading_plan_service.py | 391 + tests/unit/test_trading_plan_service.py | 250 + 62 files changed, 20340 insertions(+), 15962 deletions(-) create mode 100644 AGENTS.md delete mode 100644 docs/AI_ICT_Dealing_Range_规格书_v1.md delete mode 100644 docs/AI_ICT_Displacement_规格书_v1.md delete mode 100644 docs/AI_ICT_FVG_规格书_v1.md delete mode 100644 docs/AI_ICT_Liquidity_Pool_规格书_v1.md delete mode 100644 docs/AI_ICT_MSS_判定规格书_v1.md delete mode 100644 docs/AI_ICT_MVP_规则规格书_v1.md delete mode 100644 docs/AI_ICT_Migration_拆分计划_v1.md delete mode 100644 docs/AI_ICT_OKX_数据接入规格书_v1.md delete mode 100644 docs/AI_ICT_PostgreSQL_Schema_v1.md delete mode 100644 docs/AI_ICT_Session_生成器规格书_v1.md delete mode 100644 docs/AI_ICT_Sweep_识别规格书_v1.md delete mode 100644 docs/AI_ICT_Swing_识别规格书_v1.md delete mode 100644 docs/AI_ICT_Training_Case_Engine_外部产品化MVP计划_v1.md delete mode 100644 docs/AI_ICT_Training_Case_Engine_开发方案_v1.md delete mode 100644 docs/AI_ICT_主线进度摘要_v1.md delete mode 100644 docs/AI_ICT_交易模块缺口清单_v1.md delete mode 100644 docs/AI_ICT_双主线研发治理计划_v1.md create mode 100644 docs/AI_ICT_实盘交易分析系统开发计划_v1.md delete mode 100644 docs/AI_ICT_当前开发方案_v2.md delete mode 100644 docs/AI_ICT_总体设计文档_v1.md delete mode 100644 docs/AI_ICT_数据库_Migration_SQL_草案_v1.md delete mode 100644 docs/AI_ICT_文档索引与命名规范_v2.md delete mode 100644 docs/AI_ICT_第一批正式_Migration_文件草案_v1.md delete mode 100644 docs/AI_ICT_第二批正式_Migration_文件草案_v1.md delete mode 100644 docs/AI_ICT_项目代码骨架规范_v1.md delete mode 100644 docs/AI_Legal_Content_Intelligence_Upgrade_Plan_v1.md create mode 100644 docs/ICT交易全书_出版终校版.md delete mode 100644 docs/archive/README.md delete mode 100644 docs/archive/history/AI_ICT_主线开发检查点_v1.md delete mode 100644 docs/archive/history/AI_ICT_当前工作断点_2026-04-24.md delete mode 100644 docs/archive/history/AI_ICT_报告样本_2026-04-24.md delete mode 100644 docs/archive/history/AI_ICT_离线自动化推进记录_2026-04-29.md delete mode 100644 docs/archive/obsolete_plans/AI_ICT_开发路线图_v1.md delete mode 100644 docs/archive/obsolete_plans/AI_ICT_执行检查清单_v1.md delete mode 100644 docs/archive/obsolete_plans/AI_ICT_文档索引与命名规范_v1.md delete mode 100644 docs/archive/obsolete_plans/AI_ICT_重复文档清理计划_v1.md delete mode 100644 docs/archive/obsolete_plans/AI_ICT_项目启动清单_v1.md delete mode 100644 docs/examples/training_case_package_smoke_m6.md delete mode 100644 docs/training_case_engine_m1_m6_product_readme.md delete mode 100644 docs/workflow/AI_协作自动化工作规程_v1.md delete mode 100644 docs/workflow/AI_自动化协作迁移清单_v1.md delete mode 100644 docs/workflow/CLAUDE_template_autonomy_first.md delete mode 100644 docs/workflow/README.md delete mode 100644 docs/workflow/automation_workflow_migration_checklist.md delete mode 100644 docs/workflow/标准_CLAUDE_md_模板_v1.md create mode 100644 migrations/021_create_trading_plans.sql create mode 100644 package.json create mode 100644 scripts/run_trading_plans.py create mode 100644 src/api/trading_plans.py create mode 100644 src/models/trading_plan.py create mode 100644 src/repositories/trading_plan_repository.py create mode 100644 src/services/trading_plans/__init__.py create mode 100644 src/services/trading_plans/trading_plan_service.py create mode 100644 tests/unit/test_trading_plan_service.py diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..ebb2e21 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,23 @@ +## gstack (REQUIRED — global install) + +**Before doing ANY work, verify gstack is installed:** + +```bash +test -d ~/.Codex/skills/gstack/bin && echo "GSTACK_OK" || echo "GSTACK_MISSING" +``` + +If GSTACK_MISSING: STOP. Do not proceed. Tell the user: + +> gstack is required for all AI-assisted work in this repo. +> Install it: +> ```bash +> git clone --depth 1 https://github.com/garrytan/gstack.git ~/.Codex/skills/gstack +> cd ~/.Codex/skills/gstack && ./setup --team +> ``` +> Then restart your AI coding tool. + +Do not skip skills, ignore gstack errors, or work around missing gstack. + +Using gstack skills: After install, skills like /qa, /ship, /review, /investigate, +and /browse are available. Use /browse for all web browsing. +Use ~/.Codex/skills/gstack/... for gstack file paths (the global path). diff --git a/README.md b/README.md index bebee43..1c7a662 100644 --- a/README.md +++ b/README.md @@ -217,6 +217,7 @@ Record the current commit as the last-known-good SHA before deploy. If any gate - `python3 scripts/run_displacement.py` - rebuild displacement events - `python3 scripts/run_mss.py` - rebuild MSS structure events - `python3 scripts/run_fvg.py` - rebuild FVG zones +- `python3 scripts/run_trading_plans.py` - generate today's structured BTC/ETH trading plans before signal generation; active plans require a Draw and at least one Invalidation - `python3 scripts/run_signals.py` - generate bias and signals - `python3 scripts/run_execution.py` - run paper execution gating, create an execution record, then auto-settle the latest execution for that signal - `python3 scripts/run_backtest.py` - run backtest and write results @@ -251,6 +252,7 @@ Optional utility JSON output variables: - `MIGRATION_CHECKS_OUTPUT_JSON` - `SCRIPT_CHECKS_OUTPUT_JSON` - `SHOW_MODELS_OUTPUT_JSON` +- `TRADING_PLANS_OUTPUT_JSON` - `TRADING_REHEARSAL_OUTPUT_JSON` Optional structure script JSON output variables: @@ -374,6 +376,14 @@ Optional signal quality environment variables used by `run_signals.py` and `run_ - `SIGNALS_OUTPUT_JSON` - set to `1`, `true`, `yes`, or `on` for machine-readable `run_signals.py` output - `SIGNAL_EVIDENCE_MODE` - `strict` by default, or `minimal` to allow the older reduced evidence set +Optional trading plan environment variables used by `run_trading_plans.py`: + +- `TRADING_PLANS_OUTPUT_JSON` - set to `1`, `true`, `yes`, or `on` for machine-readable plan output +- `TRADING_PLAN_SYMBOLS` - comma-separated symbols; defaults to `BTC-USDT,ETH-USDT` +- `TRADING_PLAN_BIAS_TIMEFRAME` +- `TRADING_PLAN_SETUP_TIMEFRAME` +- `TRADING_PLAN_TRIGGER_TIMEFRAME` + ## Lightweight API helpers The `src/api/` package exposes internal query helpers and HTTP routes for: @@ -381,6 +391,7 @@ The `src/api/` package exposes internal query helpers and HTTP routes for: - `GET /health` - `GET /candles?instrument_id=1&timeframe=1m&limit=100` - `GET /sessions?instrument_id=1&limit=20` +- `GET /trading-plans?instrument_id=1&limit=20` - `GET /signals?instrument_id=1&limit=20` - `GET /executions?instrument_id=1&limit=20` - `GET /backtests?instrument_id=1&limit=10` diff --git a/docs/AI_ICT_Dealing_Range_规格书_v1.md b/docs/AI_ICT_Dealing_Range_规格书_v1.md deleted file mode 100644 index 58801b4..0000000 --- a/docs/AI_ICT_Dealing_Range_规格书_v1.md +++ /dev/null @@ -1,410 +0,0 @@ -# AI ICT Dealing Range 规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 Dealing Range 识别规则，用于从结构高低点中建立当前工作区间，并为后续位置、目标和执行质量判断提供空间坐标。 - -Dealing Range 位于以下链路中： - -`Candles -> Sessions -> Swings -> Dealing Range -> Liquidity -> Bias -> Signal` - -本模块的输出将直接影响： - -- 当前价格位置判断 -- Premium / Discount / Equilibrium 标签 -- IRL / ERL 目标分层 -- Bias 强度判断 -- 追价 / 等回补 / 放弃交易的执行判断 - -因此，Dealing Range 是基础规则中的“位置坐标模块”。 - ---- - -## 2. 模块职责 - -### 2.1 本模块负责 - -1. 选取当前工作区间的上边界和下边界 -2. 计算 equilibrium -3. 输出 premium / discount / equilibrium 位置标签 -4. 维护当前 timeframe 的 active range -5. 写入 `dealing_ranges` - -### 2.2 本模块不负责 - -- swing 识别 -- liquidity pool 识别 -- draw on liquidity -- bias 判定 -- 目标是否可执行 - -这些都属于下游模块。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -本模块依赖： - -- `swings` -- 当前价格 -- timeframe - -至少需要： - -- swing high -- swing low -- ts -- strength -- confirmed 状态 - ---- - -## 3.2 输出 - -输出写入 `dealing_ranges` 表，字段包括： - -- instrument_id -- timeframe -- high -- low -- equilibrium -- high_swing_id -- low_swing_id -- state -- ts_start -- ts_end -- meta - -并输出运行时标签： - -- location = premium | discount | equilibrium - ---- - -## 4. 基础定义 - -## 4.1 Dealing Range - -Dealing Range 指当前分析层级下，价格活动的工作区间，至少由一个有效高点和一个有效低点界定。 - -它不是装饰线，而是后续位置判断、目标判断和执行质量判断的统一坐标系。 - ---- - -## 4.2 Key High / Key Low - -- Key High：当前工作区间上边界锚点 -- Key Low：当前工作区间下边界锚点 - -这两个锚点一般来自已确认的 swing。 - ---- - -## 4.3 Equilibrium - -Equilibrium 为当前 range 的中值，第一阶段采用： - -`equilibrium = (high + low) / 2` - -说明： - -- 第一阶段不做复杂加权平衡 -- 统一使用简单中值，避免口径漂移 - ---- - -## 4.4 Premium / Discount - -以 equilibrium 为中轴： - -- 当前价格 > equilibrium -> premium -- 当前价格 < equilibrium -> discount -- 当前价格接近 equilibrium -> equilibrium 区 - -说明： - -- Premium / Discount 是位置概念，不是方向概念 -- 方向由上游结构和 narrative 决定 -- 位置只决定“值不值得在这里做” - ---- - -## 5. 当前 active range 选择规则 - -Dealing Range 最核心的问题不是“能不能画 range”，而是“当前应使用哪个 range 作为工作区间”。 - ---- - -## 5.1 第一阶段选择原则 - -MVP 先采用简化规则： - -1. 每个 timeframe 同时只保留一个 active range -2. active range 必须由已确认 swing high / swing low 组成 -3. 优先选最近一组仍具执行意义的 confirmed anchors - ---- - -## 5.2 推荐选取逻辑 - -对于某个 timeframe： - -1. 获取最近 confirmed swing highs -2. 获取最近 confirmed swing lows -3. 从中选出最近有效的一组上边界和下边界 -4. 形成当前 active range - -要求： - -- high 必须大于 low -- 两个锚点时间顺序可不同，但必须逻辑上构成同一工作区间 - ---- - -## 5.3 不采用的做法 - -第一阶段不建议： - -- 在同一 timeframe 同时输出多个 competing active ranges -- 引入过于复杂的 fractal priority engine -- 让 range 频繁抖动 - -原因： - -- 会导致下游 bias 和 signal 口径不稳定 -- 第一阶段目标是先打稳基础坐标，不追求极致复杂表达 - ---- - -## 6. 位置判定规则 - -## 6.1 基础规则 - -给定当前价格 `p`： - -- `p > equilibrium` -> premium -- `p < equilibrium` -> discount - ---- - -## 6.2 equilibrium 区间处理 - -为了避免价格刚好围绕中值来回抖动，建议设置一个中值缓冲带。 - -例如： - -- 若价格在 equilibrium 附近阈值范围内，则标记为 `equilibrium` - -建议阈值： - -- 按百分比 -- 或按 tick / ATR 的极小比例 - -第一阶段建议： - -- 配置项形式实现 -- 但默认值保持简单 - ---- - -## 7. 重绘与更新规则 - -## 7.1 何时重算 range - -以下情况应触发重算： - -1. 新 confirmed swing 出现 -2. 当前 active range 的边界失去代表性 -3. 下游明确要求重排上下文 - ---- - -## 7.2 何时结束旧 range - -当 active range 被新结构替代时： - -- 旧 range 设置 `state = inactive` 或 `closed` -- 写入 `ts_end` -- 新 range 成为 `state = valid` - ---- - -## 7.3 更新频率建议 - -- 增量运行时，只重算最近窗口 -- 历史回测时，可按 timeframe 全量重算 - ---- - -## 8. 边界与异常处理 - -## 8.1 swing 不足 - -若当前 timeframe 缺少足够 confirmed swing： - -- 不生成 dealing range -- 或输出 `state = invalid` - ---- - -## 8.2 high <= low - -若选出的边界不满足 `high > low`： - -- 立即判定为异常 -- 不允许写入有效 dealing range - ---- - -## 8.3 数据缺口 - -若关键 swing 来源区间存在数据缺口： - -- 可生成 range，但应在 `meta` 中标记不完整 -- 若缺口严重，建议拒绝输出 valid range - ---- - -## 8.4 多层级冲突 - -同一价格在不同 timeframe 可能同时是： - -- H4 discount -- H1 equilibrium -- M15 premium - -这是正常现象。 - -处理原则： - -- 每个 timeframe 独立存储 range -- 下游模块按职责读取对应 timeframe -- 不在本模块中处理跨 timeframe 冲突 - ---- - -## 9. 写入策略 - -## 9.1 幂等要求 - -相同 timeframe、相同 anchor 组合重复计算时： - -- 不应产生重复 dealing range 记录 -- 已存在的 active range 应更新而不是复制 - ---- - -## 9.2 状态建议 - -第一阶段建议支持： - -- valid -- inactive -- invalid - -说明： - -- valid：当前 active range -- inactive：已被新 range 替代 -- invalid：输入异常或条件不足 - ---- - -## 10. 下游依赖约定 - -Dealing Range 输出将被下游这样使用： - -### Liquidity -- 边界外目标识别 -- IRL / ERL 层级参考 - -### Bias -- 当前位置在 premium / discount / equilibrium -- 是否允许追价 - -### Signal -- 判断 entry 是否处于合理位置 -- 决定是否等待回补 - -因此，Dealing Range 模块必须稳定输出： - -- current active range -- equilibrium -- location label - ---- - -## 11. 推荐任务拆分 - -### T1. active range anchor 选取 -- 从 swings 中选 high / low - -### T2. equilibrium 计算 -- high / low -> equilibrium - -### T3. location 判定 -- premium / discount / equilibrium - -### T4. dealing_ranges 入库 -- valid / inactive / invalid - -### T5. 增量更新逻辑 -- 新 swing 出现后的 range 重算 - ---- - -## 12. 验证检查点 - -## 12.1 最低验证 - -至少验证： - -- [ ] H1 能生成 active range -- [ ] M15 能生成 active range -- [ ] current location 可输出 -- [ ] equilibrium 计算正确 - ---- - -## 12.2 数值验证 - -- [ ] high > low -- [ ] equilibrium = (high + low) / 2 -- [ ] valid range 同时存在 high_swing_id / low_swing_id -- [ ] location 与当前价格关系一致 - ---- - -## 12.3 人工抽查 - -随机抽取图表样本检查： - -- [ ] 选取的 high / low 符合肉眼结构 -- [ ] premium / discount 判断合理 -- [ ] range 未频繁无意义抖动 - ---- - -## 13. 完成标准 - -只有满足以下全部条件，Dealing Range 模块才算完成： - -1. 能从 swings 生成当前 active range -2. 能稳定计算 equilibrium -3. 能输出 premium / discount / equilibrium 标签 -4. 能幂等写入 `dealing_ranges` -5. 能在新结构出现时更新 active range -6. 可直接供 bias 与 signal 模块使用 - ---- - -## 14. 当前结论 - -Dealing Range 模块是执行系统的空间坐标层。 - -如果 Swing 是结构锚点，那么 Dealing Range 就是把这些锚点组织成“当前位置是否值得出手”的空间判断系统。 - -在真实开发中，它应被视为基础规则层中的核心模块之一。 \ No newline at end of file diff --git a/docs/AI_ICT_Displacement_规格书_v1.md b/docs/AI_ICT_Displacement_规格书_v1.md deleted file mode 100644 index 414b1f2..0000000 --- a/docs/AI_ICT_Displacement_规格书_v1.md +++ /dev/null @@ -1,494 +0,0 @@ -# AI ICT Displacement 规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 Displacement 识别规则，用于从价格行为中识别“有效位移”事件，并为后续 MSS、Bias、Signal 生成提供结构强度依据。 - -Displacement 模块位于以下链路中： - -`Candles -> Liquidity -> Sweep -> Displacement -> MSS -> Signal` - -本模块输出将直接影响： - -- 是否出现真正有意义的方向表达 -- Sweep 后是否出现足够强的反向承接 -- MSS 是否具备更高可信度 -- FVG 是否具有更高解释力 -- Signal 是否达到执行门槛 - -因此，Displacement 是“结构强度确认层”。 - ---- - -## 2. 模块职责 - -### 2.1 本模块负责 - -1. 检测价格是否出现明显位移 -2. 判断位移方向 -3. 给出位移强度评分 -4. 记录位移与 FVG 的联动关系 -5. 为后续 MSS 和 Signal 提供结构强度证据 - -### 2.2 本模块不负责 - -- MSS 最终判定 -- Bias 最终判定 -- Signal 最终生成 -- FVG 本体识别 - -这些都属于下游或相邻模块。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -本模块依赖： - -- `candles` -- 可选：`sweep_events` -- 可选：`fvg_zones` -- timeframe - -至少需要： - -- open -- high -- low -- close -- ts - ---- - -## 3.2 输出 - -输出写入 `displacement_events`，字段建议包括： - -- instrument_id -- timeframe -- direction -- start_ts -- end_ts -- strength_score -- body_ratio -- has_fvg -- is_valid -- meta - -其中： - -- `direction = bullish | bearish` -- `strength_score` 为归一化强度评分 -- `body_ratio` 表示相对实体扩张程度 -- `has_fvg = true | false` - ---- - -## 4. 基础定义 - -## 4.1 Displacement - -Displacement 指价格在短时间内以明显的方向性、实体性和推进性脱离原平衡状态的行为。 - -它不是普通波动，而是： - -1. 有明确方向 -2. 有明显实体扩张 -3. 有推进性而非来回噪音 -4. 往往伴随低效率定价或 FVG - ---- - -## 4.2 为什么 Displacement 重要 - -在 ICT 结构语境中，Displacement 是“控制权表达”的关键线索。 - -例如： - -- Sweep 之后若没有 Displacement，则后续 reversal 解释力较弱 -- MSB 之后若没有 Displacement，则 MSS 可信度较低 - -因此，Displacement 不能只是“涨得快”或“跌得快”，而应是结构上有意义的位移事件。 - ---- - -## 5. 识别维度 - -第一阶段建议至少从以下 4 个维度综合判断： - -1. 实体扩张 -2. 方向推进 -3. 脱离平衡 -4. FVG / 低效率联动 - ---- - -## 5.1 实体扩张 - -若某根或连续几根 candle 的实体显著大于近期平均实体，则位移解释力增强。 - -建议指标： - -- 当前实体 / 最近 N 根平均实体 = `body_ratio` - -其中： - -`body_size = abs(close - open)` - -第一阶段建议： - -- 不使用特别复杂的波动模型 -- 先用滚动平均实体做相对比较 - ---- - -## 5.2 方向推进 - -位移不应只是单根大 K，而应体现短时段方向推进能力。 - -例如： - -- bullish displacement：连续向上推进、回撤弱、收盘位置强 -- bearish displacement：连续向下推进、反弹弱、收盘位置弱 - -说明： - -- 单根异常长影线不一定代表 displacement -- 更关键的是方向推进的连续性 - ---- - -## 5.3 脱离平衡 - -位移通常表现为价格快速脱离原有平衡区、中值区或短期整理区。 - -第一阶段建议： - -- 可通过短期整理区脱离来增强 displacement 解释 -- 但不要一开始把平衡定义复杂化 - ---- - -## 5.4 FVG 联动 - -若位移同时产生 FVG / imbalance，则说明： - -- 市场在快速再定价 -- 位移并非普通来回振荡 - -因此： - -- `has_fvg = true` 应显著提升位移可信度 - ---- - -## 6. 方向判定 - -## 6.1 bullish displacement - -若价格表现出以下特征： - -1. 实体向上扩张 -2. 向上推进明显 -3. close 位置强 -4. 可伴随 bullish FVG - -则判定为 bullish displacement。 - ---- - -## 6.2 bearish displacement - -若价格表现出以下特征： - -1. 实体向下扩张 -2. 向下推进明显 -3. close 位置弱 -4. 可伴随 bearish FVG - -则判定为 bearish displacement。 - ---- - -## 7. 评分建议 - -第一阶段建议保留一个简单强度评分： - -- `strength_score` 范围可设为 0 ~ 1 - -评分可综合以下因素： - -1. body_ratio -2. 连续推进程度 -3. close 强弱位置 -4. 是否伴随 FVG -5. 是否发生在关键事件之后（如 sweep） - -说明： - -- 第一阶段不要求极致数学精确 -- 更重要的是评分口径一致 - ---- - -## 8. 最低成立条件 - -为了避免把普通波动误判为 displacement，第一阶段建议要求至少满足以下两项： - -1. `body_ratio` 超过阈值 -2. 存在短时连续推进 -3. close 表现强 / 弱明显 -4. 同时出现 FVG - -只有单一条件成立，不建议直接记为强 displacement。 - ---- - -## 9. 与 Sweep 的联动 - -## 9.1 sweep 后 displacement - -若某一侧 pool 被 sweep 后，在观察窗口内出现反向 displacement： - -- 该 displacement 的解释力显著增强 -- 可作为后续 MSS 的重要前提证据 - -因此，建议在 `meta` 中保留： - -- related_sweep_id -- sweep_after_bars - ---- - -## 9.2 无 sweep 的 displacement - -没有前置 sweep 也可以存在 displacement，但解释语义不同： - -- 可能是普通趋势推进 -- 可能是整理区突破 -- 其结构意义不一定等于“先清理后递送” - -因此，下游模块应区分： - -- pure displacement -- sweep-backed displacement - ---- - -## 10. 与 FVG 的联动 - -## 10.1 has_fvg - -若 displacement 同时生成 FVG： - -- `has_fvg = true` -- 强度评分提升 - -### 原因 -FVG 往往说明价格出现快速再定价，提升 displacement 的结构解释力。 - ---- - -## 10.2 无 FVG 情况 - -无 FVG 并不代表一定不是 displacement，但可信度通常略低。 - -第一阶段建议： - -- 无 FVG 可以保留为 displacement -- 但评分较低 -- 若其他维度也不强，则不应升级为高质量 displacement - ---- - -## 11. 时间窗口与确认 - -## 11.1 观察窗口 - -Displacement 识别建议在短窗口内完成，不应拖得过长。 - -例如： - -- 观察最近 N 根 candle 的方向推进质量 - -第一阶段建议： - -- N 按 timeframe 配置 -- 不同 timeframe 单独设定 - ---- - -## 11.2 confirmed displacement - -当观察窗口内多个条件已满足时，可记为 confirmed displacement。 - -若条件不足： - -- 可忽略 -- 或作为低可信候选，不进入主链路 - -第一阶段建议： - -- displacement 事件尽量只记录 confirmed 结果 -- 避免大量低质量候选污染数据库 - ---- - -## 12. 边界与异常处理 - -## 12.1 单根长影线 - -若只有很长影线，但实体不够、推进不连续： - -- 不应轻易判为 displacement - ---- - -## 12.2 高波动但无方向 - -若波动剧烈，但上下反复、close 无明显优势： - -- 视为高噪音，不应判为 displacement - ---- - -## 12.3 数据缺口 - -若窗口内 candles 不连续： - -- 不建议输出高可信 displacement -- 若仍输出，必须在 `meta` 中标记不完整 - ---- - -## 13. 写入策略 - -## 13.1 幂等要求 - -同一主事件窗口重复计算时： - -- 不应重复生成多个 identical displacement 事件 - -建议幂等参考： - -- instrument_id -- timeframe -- direction -- start_ts -- end_ts - ---- - -## 13.2 有效性标记 - -建议字段： - -- `is_valid = true | false` - -用于表示： - -- 是否达到最小成立条件 -- 是否可进入 MSS / signal 主链路 - ---- - -## 14. 下游依赖约定 - -Displacement 输出将被下游这样使用： - -### MSS -- 判断结构切换是否真的有控制权表达 - -### Bias -- 判断当前位置是否已经出现方向表达 - -### Signal -- 判断 setup 是否达到执行强度门槛 - -因此，本模块必须稳定输出： - -- direction -- strength_score -- has_fvg -- is_valid - ---- - -## 15. 推荐任务拆分 - -### T1. body_ratio 计算 -- 当前实体 vs 历史平均实体 - -### T2. 推进性判断 -- 连续方向推进检测 - -### T3. close 强弱检测 -- candle 收盘位置质量 - -### T4. FVG 联动 -- has_fvg 标记 - -### T5. displacement 评分 -- 生成 strength_score - -### T6. 入库与幂等控制 -- 写入 `displacement_events` - ---- - -## 16. 验证检查点 - -## 16.1 最低验证 - -至少验证： - -- [ ] bullish displacement 可识别 -- [ ] bearish displacement 可识别 -- [ ] body_ratio 可计算 -- [ ] has_fvg 可联动标记 - ---- - -## 16.2 行为验证 - -- [ ] 单根长影线不会轻易误判为高质量 displacement -- [ ] 纯高波动噪音不会误判为 displacement -- [ ] 有 sweep 背景的 displacement 评分更高 - ---- - -## 16.3 人工抽查 - -至少抽样检查： - -- [ ] displacement 起止窗口合理 -- [ ] 方向判定合理 -- [ ] 与 FVG 联动合理 -- [ ] 评分排序大致符合肉眼感知 - ---- - -## 17. 完成标准 - -只有满足以下全部条件，Displacement 模块才算完成： - -1. 能识别 bullish / bearish displacement -2. 能计算基础强度评分 -3. 能与 FVG 联动 -4. 能与 sweep 事件联动 -5. 能幂等写入 `displacement_events` -6. 可直接供 MSS 模块使用 - ---- - -## 18. 当前结论 - -Displacement 模块不是单纯的“大阳线/大阴线识别器”，而是市场是否真正表达出一侧控制权的强度确认层。 - -在真实开发中，它应作为 Sweep 和 MSS 之间的关键桥梁模块，优先保证： - -- 规则口径稳定 -- 评分一致 -- 不被噪音 K 线污染 diff --git a/docs/AI_ICT_FVG_规格书_v1.md b/docs/AI_ICT_FVG_规格书_v1.md deleted file mode 100644 index f90ac6e..0000000 --- a/docs/AI_ICT_FVG_规格书_v1.md +++ /dev/null @@ -1,466 +0,0 @@ -# AI ICT FVG 规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 FVG（Fair Value Gap）识别与使用规则，用于把位移过程中形成的低效率定价区结构化存储，并为后续 retrace entry、目标管理与 signal 生成提供关键参考。 - -FVG 模块位于以下链路中： - -`Sweep -> Displacement -> MSS -> FVG -> Retrace Entry -> Signal` - -本模块输出将直接影响： - -- 是否存在可回补的低效率定价区 -- Displacement 是否具备更强结构解释力 -- MSS 之后是否有可执行的 retrace 区域 -- Signal 是否能获得更清晰的 entry zone -- 后续 fill / mitigation / invalidation 管理 - -因此，FVG 是 MVP 主模型中最关键的入场区域模块之一。 - ---- - -## 2. 模块职责 - -### 2.1 本模块负责 - -1. 识别 bullish / bearish FVG -2. 记录 FVG 的上下边界 -3. 跟踪 fill_pct 与 mitigation 状态 -4. 标记与 displacement 的联动关系 -5. 为 retrace entry 提供结构区间 - -### 2.2 本模块不负责 - -- Displacement 成立判定 -- MSS 成立判定 -- Signal 最终下单许可 -- 仓位管理 - -这些由上下游模块分别负责。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -本模块依赖： - -- `candles` -- 可选：`displacement_events` -- timeframe - -至少需要： - -- open -- high -- low -- close -- ts - ---- - -## 3.2 输出 - -输出写入 `fvg_zones`，字段建议包括： - -- instrument_id -- timeframe -- direction -- upper -- lower -- start_ts -- end_ts -- fill_pct -- status -- related_displacement_id -- meta - -其中： - -- `direction = bullish | bearish` -- `status = open | touched | mitigated | invalidated` - ---- - -## 4. 核心定义 - -## 4.1 FVG（Fair Value Gap） - -FVG 指价格在快速位移过程中形成的低效率定价区，表现为三根 candle 之间出现未被充分交易覆盖的区间。 - -在 ICT 语境中，FVG 往往具有两层含义： - -1. 位移强度的副产物 -2. 后续回补与承接的候选区域 - -因此： - -- FVG 既是结构表达 -- 也是 retrace entry 的候选位置 - ---- - -## 4.2 为什么 FVG 重要 - -对于 MVP 主模型： - -`Sweep -> MSS -> FVG Retrace` - -FVG 的作用是把“结构切换”转成一个更可执行的 entry zone。 - -若只有 MSS，没有清晰 FVG： - -- 可以有结构解释 -- 但入场位置往往不够标准化 - -因此，FVG 是把结构分析连接到执行区域的关键模块。 - ---- - -## 5. 识别逻辑 - -第一阶段采用标准三根 candle 逻辑。 - -## 5.1 bullish FVG - -对于连续三根 candle： - -- 若第 1 根的 high < 第 3 根的 low - -则认为存在 bullish FVG。 - -区间定义： - -- lower = candle1.high -- upper = candle3.low - -说明： - -- 这表示中间位移过程中价格上移过快，留下未充分交易覆盖区间 - ---- - -## 5.2 bearish FVG - -对于连续三根 candle： - -- 若第 1 根的 low > 第 3 根的 high - -则认为存在 bearish FVG。 - -区间定义： - -- lower = candle3.high -- upper = candle1.low - -说明： - -- 这表示中间位移过程中价格下移过快，留下未充分交易覆盖区间 - ---- - -## 6. FVG 与 Displacement 的联动 - -第一阶段建议： - -- FVG 不单独脱离价格背景解释 -- 若 FVG 来自有效 displacement，其价值显著提高 - -因此建议保留字段： - -- `related_displacement_id` -- `meta.has_displacement_context` - ---- - -## 6.1 有 displacement 背景的 FVG - -若 FVG 伴随 displacement 出现： - -- 其作为 retrace zone 的解释力更强 -- 更适合作为 signal 候选入场区 - ---- - -## 6.2 无 displacement 背景的 FVG - -无 displacement 背景的 FVG 仍可识别，但执行价值通常较弱。 - -第一阶段建议： - -- 允许保留 -- 但优先级低于 displacement-backed FVG - ---- - -## 7. 状态管理 - -第一阶段建议支持以下状态： - -- open -- touched -- mitigated -- invalidated - ---- - -## 7.1 open - -FVG 刚形成，尚未被后续价格触达。 - ---- - -## 7.2 touched - -价格已进入 FVG 区间，但尚未完全回补。 - ---- - -## 7.3 mitigated - -价格已完成较充分回补，FVG 的执行价值显著下降。 - -第一阶段建议： - -- 当 fill_pct 达到预设阈值，可标记为 mitigated - ---- - -## 7.4 invalidated - -若后续价格行为表明该 FVG 不再具有结构价值，则标记 invalidated。 - -例如： - -- 结构方向被彻底否定 -- 价格长时间在区间内无意义穿梭 -- FVG 对应的 MSS 已失效 - ---- - -## 8. fill_pct 计算 - -为了追踪 FVG 被回补的程度，建议计算： - -- `fill_pct` - -其含义是： - -- 当前价格对 FVG 区间已回补的比例 - -第一阶段不必追求复杂公式，但应固定统一口径。 - -建议要求： - -- 0.0 表示完全未回补 -- 1.0 表示完全回补 - ---- - -## 9. retrace entry 使用规则 - -FVG 最重要的用途之一，是作为 retrace entry zone。 - -## 9.1 bullish FVG retrace - -若上游结构为 bullish： - -- 等待价格回补到 bullish FVG 区间 -- 结合 MSS、session、RR 再决定是否进入 signal 候选 - ---- - -## 9.2 bearish FVG retrace - -若上游结构为 bearish： - -- 等待价格回补到 bearish FVG 区间 -- 再结合下游模块决定是否进入执行候选 - ---- - -## 9.3 不建议直接用法 - -第一阶段不建议： - -- 只看到 FVG 就直接做单 -- 脱离 MSS / sweep / displacement 背景使用 FVG - -因为 FVG 本身不是方向确认工具，它只是位置工具。 - ---- - -## 10. 多个 FVG 并存的处理 - -同一时间窗口可能出现多个 FVG。 - -第一阶段建议： - -1. 允许多个 FVG 并存 -2. 优先考虑最近的、与当前 displacement 直接相关的 FVG -3. 若多个 FVG 高度重叠，可由下游模块再做优先级筛选 - -本模块不负责最终优先级排序，只负责正确识别和状态追踪。 - ---- - -## 11. 边界与异常处理 - -## 11.1 极窄 gap - -若 gap 极小，可能是噪音，不一定有执行价值。 - -第一阶段建议： - -- 仍可识别 -- 但可在 `meta` 中记录 width -- 下游再决定是否过滤过窄 FVG - ---- - -## 11.2 已完全回补后再次识别 - -若同一 FVG 已被充分回补并 mitigation 完成： - -- 不应反复当作新鲜主执行区 - ---- - -## 11.3 数据缺口 - -若 candles 本身存在数据缺口： - -- 可能误判为假 FVG -- 此时应在 `meta` 中记录数据质量异常 -- 不建议进入高质量执行链路 - ---- - -## 12. 写入策略 - -## 12.1 幂等要求 - -同一组三根 candle 重复计算时： - -- 不应重复生成 identical FVG - -建议幂等参考： - -- instrument_id -- timeframe -- direction -- start_ts -- end_ts -- upper -- lower - ---- - -## 12.2 更新策略 - -后续运行时： - -- 更新 fill_pct -- 更新 status -- 更新 related_displacement 信息（若后补识别） - ---- - -## 13. 下游依赖约定 - -FVG 输出将被下游这样使用： - -### Signal 模块 -- 作为 retrace entry zone - -### Bias / Context 模块 -- 作为结构解释增强项 - -### Risk 模块 -- 可辅助 stop 位置思考（但不是本模块职责） - -因此，本模块至少应稳定输出： - -- direction -- price zone -- fill_pct -- status -- displacement 关联 - ---- - -## 14. 推荐任务拆分 - -### T1. 三根 candle FVG 识别 -- bullish / bearish 基础规则 - -### T2. FVG 入库 -- 写入 `fvg_zones` -- 做幂等控制 - -### T3. fill_pct 追踪 -- 跟踪后续价格回补程度 - -### T4. status 更新 -- open / touched / mitigated / invalidated - -### T5. displacement 关联 -- 标记 related_displacement_id - ---- - -## 15. 验证检查点 - -## 15.1 最低验证 - -至少验证： - -- [ ] bullish FVG 可识别 -- [ ] bearish FVG 可识别 -- [ ] upper / lower 边界正确 -- [ ] fill_pct 可更新 -- [ ] status 可变化 - ---- - -## 15.2 行为验证 - -- [ ] 有 displacement 背景的 FVG 可正确关联 -- [ ] 已完全回补的 FVG 会进入 mitigated -- [ ] 无结构背景的 FVG 不会自动变成高质量执行区 - ---- - -## 15.3 人工抽查 - -至少抽取图表样本： - -- [ ] FVG 边界与肉眼观察一致 -- [ ] fill 过程合理 -- [ ] retrace zone 解释符合走势 -- [ ] mitigated / invalidated 状态切换合理 - ---- - -## 16. 完成标准 - -只有满足以下全部条件，FVG 模块才算完成： - -1. 能识别 bullish / bearish FVG -2. 能稳定输出 price zone -3. 能追踪 fill_pct -4. 能维护 status -5. 能与 displacement 关联 -6. 可直接供 retrace signal 模块使用 - ---- - -## 17. 当前结论 - -FVG 模块是把“结构变化”转成“可回补入场区域”的关键执行桥梁。 - -在 MVP 主模型里，它不是附属概念，而是： - -> 从 MSS 走向可执行 retrace entry 的核心位置模块。 diff --git a/docs/AI_ICT_Liquidity_Pool_规格书_v1.md b/docs/AI_ICT_Liquidity_Pool_规格书_v1.md deleted file mode 100644 index 94d4ee6..0000000 --- a/docs/AI_ICT_Liquidity_Pool_规格书_v1.md +++ /dev/null @@ -1,429 +0,0 @@ -# AI ICT Liquidity Pool 规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 Liquidity Pool 识别规则，用于结构化标记市场中可能被优先处理的流动性区域，并写入 `liquidity_pools` 表。 - -Liquidity Pool 模块位于以下链路中： - -`Candles -> Sessions -> Swings -> Dealing Range -> Liquidity Pools -> Sweep -> MSS` - -本模块的输出会直接影响： - -- buy-side / sell-side liquidity 识别 -- prior highs / lows 标记 -- equal highs / lows 标记 -- session high / low 标记 -- sweep 检测 -- draw on liquidity 候选目标 - -因此，Liquidity Pool 是后续 sweep 与目标判断的直接前置模块。 - ---- - -## 2. 模块职责 - -### 2.1 本模块负责 - -1. 识别 prior high / prior low -2. 识别 equal highs / equal lows -3. 识别 session highs / lows -4. 给出 pool 的 side、type 和价格区间 -5. 维护 pool 状态变化 -6. 写入 `liquidity_pools` - -### 2.2 本模块不负责 - -- sweep 是否成立 -- draw 优先级排序 -- MSS 判定 -- bias 方向 - -这些属于下游模块。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -本模块依赖： - -- `swings` -- `market_sessions` -- 当前 timeframe -- equal-high/equal-low 阈值配置 - -至少需要： - -- swing high / low -- price -- ts -- session high / low - ---- - -## 3.2 输出 - -输出写入 `liquidity_pools` 表，字段包括： - -- instrument_id -- timeframe -- side -- pool_type -- price_low -- price_high -- reference_ids -- status -- created_ts -- updated_ts -- meta - -其中： - -- `side` = `buy_side | sell_side` -- `pool_type` = `prior_high | prior_low | equal_highs | equal_lows | session_high | session_low` - ---- - -## 4. 基础定义 - -## 4.1 Buy-Side Liquidity - -通常指位于价格上方、容易吸引向上处理的流动性区域。 - -第一阶段主要来自： - -- prior high -- equal highs -- session high - ---- - -## 4.2 Sell-Side Liquidity - -通常指位于价格下方、容易吸引向下处理的流动性区域。 - -第一阶段主要来自： - -- prior low -- equal lows -- session low - ---- - -## 4.3 Pool 的本质 - -Pool 不是“一个点”，而是一个可能被处理的价格区间。 - -因此： - -- 对于单一 prior high / low，可允许 price_low = price_high -- 对于 equal highs / lows，应允许一个窄区间 - ---- - -## 5. prior high / prior low 识别规则 - -## 5.1 prior high - -来源： - -- 已确认 swing high - -输出： - -- `side = buy_side` -- `pool_type = prior_high` -- `price_low = swing price` -- `price_high = swing price` - ---- - -## 5.2 prior low - -来源： - -- 已确认 swing low - -输出： - -- `side = sell_side` -- `pool_type = prior_low` -- `price_low = swing price` -- `price_high = swing price` - ---- - -## 6. equal highs / equal lows 识别规则 - -这是第一阶段最需要参数化的部分。 - -## 6.1 equal highs - -若多个 swing highs 的价格足够接近，且落在定义阈值内，则可合并标记为 equal highs pool。 - -输出： - -- `side = buy_side` -- `pool_type = equal_highs` -- `price_low = min(high prices)` -- `price_high = max(high prices)` - ---- - -## 6.2 equal lows - -若多个 swing lows 的价格足够接近，且落在定义阈值内，则可合并标记为 equal lows pool。 - -输出： - -- `side = sell_side` -- `pool_type = equal_lows` -- `price_low = min(low prices)` -- `price_high = max(low prices)` - ---- - -## 6.3 阈值建议 - -阈值必须配置化。 - -第一阶段建议： - -### BTC / ETH -- 可使用百分比阈值，例如极小百分比 - -### XAU -- 可使用固定 tick 阈值 - -原则： - -- 不同品种不能硬套同一个固定数值 -- 第一阶段可以先设保守阈值 - ---- - -## 7. session high / low 识别规则 - -Session-based liquidity 来源于 `market_sessions` 表。 - -## 7.1 session high - -来源： - -- ASIA high -- LONDON high -- NY_AM high -- NY_LUNCH high -- NY_PM high - -输出： - -- `side = buy_side` -- `pool_type = session_high` -- `price_low = session high` -- `price_high = session high` - ---- - -## 7.2 session low - -来源： - -- ASIA low -- LONDON low -- NY_AM low -- NY_LUNCH low -- NY_PM low - -输出： - -- `side = sell_side` -- `pool_type = session_low` -- `price_low = session low` -- `price_high = session low` - ---- - -## 8. Pool 状态机 - -第一阶段建议支持以下状态： - -- untouched -- swept -- consumed -- invalid - -含义： - -- untouched：尚未被价格处理 -- swept：已被刺穿 / 处理 -- consumed：后续不再作为主要 pool 使用 -- invalid：来源异常或数据不完整 - ---- - -## 8.1 touched 与 swept 的处理 - -第一阶段不单独引入 `touched`，统一收敛为： - -- 若已明确被价格刺穿，则标记 `swept` - -更细粒度状态可在后续引入。 - ---- - -## 9. 幂等与合并规则 - -## 9.1 同来源重复识别 - -若同一来源对象重复计算： - -- 不应重复生成多个 pool -- 应按 `reference_ids + type + timeframe` 做幂等更新 - ---- - -## 9.2 合并规则 - -对于 equal highs / equal lows： - -- 相同 cluster 中的多个点应合并成一个 pool -- 不建议每个近似价格点各生成一条 pool - -否则下游 sweep 识别会混乱。 - ---- - -## 10. 边界与异常处理 - -## 10.1 不完整 session - -若 session 状态为 `incomplete` 或 `invalid`： - -- 第一阶段建议不生成正式 session pool -- 或在 `meta` 中显式标记风险 - ---- - -## 10.2 未确认 swing -n -第一阶段建议： - -- prior high / prior low 只使用 confirmed swings -- provisional swings 不进入正式 liquidity pool - -这样可避免未来数据偏差污染。 - ---- - -## 10.3 重复 cluster - -若 equal highs / lows cluster 高度重叠： - -- 应优先合并为一个 pool -- 不允许生成多个高度重复 pool - ---- - -## 11. 下游依赖约定 - -Liquidity Pool 输出将被下游这样使用： - -### Sweep 模块 -- 判断某一侧 pool 是否被刺穿 - -### Draw 模块 -- 判断当前未处理目标 - -### Signal 模块 -- 判断当前路径是否具备先清理后递送特征 - -因此，本模块输出至少要稳定提供： - -- side -- pool_type -- price range -- status -- reference_ids - ---- - -## 12. 推荐任务拆分 - -### T1. prior high / low 识别 -- 从 confirmed swings 生成 pool - -### T2. equal highs / lows cluster -- 按阈值聚类 -- 生成区间型 pool - -### T3. session high / low pool -- 从 `market_sessions` 生成 session pool - -### T4. pool 入库与幂等更新 -- 写入 `liquidity_pools` -- 更新 status - -### T5. 合并与去重 -- 处理重叠 cluster -- 避免重复 pool - ---- - -## 13. 验证检查点 - -## 13.1 最低验证 - -至少验证： - -- [ ] prior high 可生成 buy-side pool -- [ ] prior low 可生成 sell-side pool -- [ ] equal highs 可生成区间型 pool -- [ ] equal lows 可生成区间型 pool -- [ ] session high / low 可生成 pool - ---- - -## 13.2 数据验证 - -- [ ] buy_side pool 位于上方目标语义 -- [ ] sell_side pool 位于下方目标语义 -- [ ] equal-highs pool 的 `price_low <= price_high` -- [ ] status 初始为 untouched -- [ ] reference_ids 可追溯来源 - ---- - -## 13.3 人工抽查 - -随机抽样检查： - -- [ ] prior highs / lows 与 swing 来源一致 -- [ ] equal highs / lows 聚类合理 -- [ ] session pools 与 session high/low 一致 -- [ ] 没有明显重复 pool 污染 - ---- - -## 14. 完成标准 - -只有满足以下全部条件，Liquidity Pool 模块才算完成： - -1. 支持 prior highs / lows -2. 支持 equal highs / lows -3. 支持 session highs / lows -4. 支持 status 管理 -5. 支持幂等写入 `liquidity_pools` -6. 可直接供 sweep 模块使用 - ---- - -## 15. 当前结论 - -Liquidity Pool 模块是市场“待处理目标”的结构化表达层。 - -如果 Swing 提供锚点、Dealing Range 提供空间坐标，那么 Liquidity Pool 就提供“价格下一步可能优先处理哪里”的候选目标集合。 - -在真实开发中，它应被视为进入 sweep 和 draw 模块之前必须稳定完成的关键基础模块。 \ No newline at end of file diff --git a/docs/AI_ICT_MSS_判定规格书_v1.md b/docs/AI_ICT_MSS_判定规格书_v1.md deleted file mode 100644 index 3304386..0000000 --- a/docs/AI_ICT_MSS_判定规格书_v1.md +++ /dev/null @@ -1,472 +0,0 @@ -# AI ICT MSS 判定规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 MSS（Market Structure Shift）判定规则，用于把结构破坏、位移、承接和路径重排组合成一个可执行的“控制权切换”事件。 - -MSS 模块位于以下链路中： - -`Swing -> Liquidity -> Sweep -> Displacement -> MSB -> MSS -> Signal` - -本模块的输出将直接影响： - -- 旧路径是否只是不稳，还是已经发生控制权切换 -- reversal / continuation 叙事是否成立 -- FVG retrace 是否值得进入候选执行链路 -- Daily Bias 是否可被增强或重排 -- trade signal 是否有资格进入 awaiting_confirmation - -因此，MSS 是基础结构链中最关键的“控制权确认模块”。 - ---- - -## 2. 模块职责 - -### 2.1 本模块负责 - -1. 区分 MSB 与 MSS -2. 识别结构是否发生控制权切换 -3. 要求位移与承接证据闭合 -4. 输出 bullish / bearish MSS 事件 -5. 为下游 signal 提供结构确认依据 - -### 2.2 本模块不负责 - -- Bias 最终生成 -- Signal 最终下单许可 -- FVG 本体识别 -- 账户风控判断 - -这些都由下游模块处理。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -本模块依赖： - -- `swings` -- `displacement_events` -- 可选：`sweep_events` -- 当前价格与后续 retest 行为 - -至少需要： - -- 被破坏的 swing -- 破坏方向 -- displacement 方向与强度 -- retest / acceptance 信息 - ---- - -## 3.2 输出 - -输出建议写入 `structure_events`，字段包括： - -- instrument_id -- timeframe -- event_type -- direction -- broken_level -- reference_swing_id -- displacement_event_id -- accepted -- ts -- meta - -其中： - -- `event_type = MSS` -- `direction = bullish | bearish` -- `accepted = true | false` - ---- - -## 4. 核心定义 - -## 4.1 MSB（Market Structure Break） - -MSB 表示： - -- 旧路径被破坏 -- 但新路径未必已经成立 - -它解决的是： - -> 原结构还能不能继续稳定维持？ - -MSB 不是最终交易结论。 - ---- - -## 4.2 MSS（Market Structure Shift） - -MSS 表示： - -- 旧路径已被破坏 -- 且反向控制权已经通过位移与承接被确认 - -它解决的是： - -> 新的主导权是否已经开始接管？ - -因此： - -- 不是每个 MSB 都能升级成 MSS -- MSS 必须是“证据链闭合”后的结果 - ---- - -## 5. MSS 的证据链 - -第一阶段建议把 MSS 定义为以下 4 个环节组成： - -1. 结构破坏（MSB） -2. 有效位移（Displacement） -3. 回补后的承接（Retest / Acceptance） -4. 主路径重排（New Draw becomes meaningful） - -只有这 4 个环节基本闭合，才进入 MSS。 - ---- - -## 5.1 环节 1：结构破坏 - -必须先出现关键 swing 被有效破坏。 - -例如： - -- bearish 环境下，某关键高点被向上破坏 -> 候选 bullish MSB -- bullish 环境下，某关键低点被向下破坏 -> 候选 bearish MSB - -要求： - -- 破坏对象必须来自有效 swing -- 不能用随机局部波动当关键结构点 - ---- - -## 5.2 环节 2：有效位移 - -MSB 之后必须出现与候选新方向一致的 displacement。 - -要求： - -- displacement 方向必须与 MSS 方向一致 -- displacement 不能只是噪音波动 -- 若伴随 FVG，则解释力更强 - -说明： - -- 没有 displacement 的 MSB，通常不应升级为 MSS - ---- - -## 5.3 环节 3：承接 / Acceptance - -新方向不能只靠一次冲击成立，还需要后续承接。 - -常见表现： - -- 回补后未失守关键接管边界 -- 回测后继续保持新方向控制权 -- 未被快速重新夺回原区间 - -第一阶段建议用布尔标记： - -- `accepted = true | false` - ---- - -## 5.4 环节 4：路径重排 - -若 MSS 成立，下游应能看到： - -- 原来的主 Draw 不再占优 -- 新的目标方向开始具备解释力 - -说明： - -- 路径重排不一定在本模块里完全算完 -- 但 MSS 至少应在 `meta` 中保留足够信息，供下游确认“新路径已具备可叙述性” - ---- - -## 6. bullish MSS 判定 - -第一阶段建议： - -若满足以下条件，则可判为 bullish MSS： - -1. 先出现候选 bullish MSB -2. 后续出现 bullish displacement -3. 回补后未重新跌回关键失效边界下方 -4. 新的上方递送路径开始具备解释力 - -输出： - -- `event_type = MSS` -- `direction = bullish` -- `accepted = true` - ---- - -## 7. bearish MSS 判定 - -若满足以下条件，则可判为 bearish MSS： - -1. 先出现候选 bearish MSB -2. 后续出现 bearish displacement -3. 回补后未重新站回关键失效边界上方 -4. 新的下方递送路径开始具备解释力 - -输出： - -- `event_type = MSS` -- `direction = bearish` -- `accepted = true` - ---- - -## 8. 不成立情况 - -以下情况第一阶段不应升级为 MSS： - -### 8.1 只有 MSB，没有 displacement - -- 旧结构虽然不稳 -- 但没有新方向控制权表达 - -结论： -- 保留为 MSB -- 不升级 MSS - ---- - -### 8.2 有 displacement，但没有承接 - -- 价格冲击后又被快速夺回 -- 回补后无法守住新方向边界 - -结论： -- 可视为 failed shift -- 不升级 MSS - ---- - -### 8.3 假突破 / 流动性清理后立即反夺回 - -- 刺穿看似结构破坏 -- 但后续并未形成真正接管 - -结论： -- 更接近 liquidity event -- 不应升级 MSS - ---- - -### 8.4 时间框架错位 - -若低周期破坏试图越权改写高周期主结构： - -- 在本周期可记为局部 MSS 候选 -- 但不能自动等于更高周期结构切换 - -说明： -- MSS 必须绑定 timeframe - ---- - -## 9. 与 Sweep 的联动 - -若 MSS 前存在相关 sweep： - -- 该 MSS 的解释力更强 -- 更符合“先清理，后位移，再切换”的链路 - -建议在 `meta` 中记录： - -- related_sweep_id -- sweep_side -- bars_between_sweep_and_mss - -说明： - -- 没有 sweep 也可能出现 MSS -- 但存在 sweep 背景时，更符合 ICT 核心路径 - ---- - -## 10. 与 FVG 的联动 - -若 displacement 同时产生 FVG： - -- 后续可作为 retrace entry zone -- MSS 的可执行意义增强 - -因此建议在 `meta` 中记录： - -- related_fvg_id -- has_related_fvg - -说明： - -- FVG 不是 MSS 必须条件 -- 但它会显著增强下游执行价值 - ---- - -## 11. 时间确认与窗口 - -## 11.1 观察窗口 - -MSS 不应无限期挂起等待。 - -第一阶段建议： - -- 在 MSB 与 displacement 出现后，给一个有限 retest / acceptance 观察窗口 - -若窗口结束仍未形成 acceptance： - -- 不应继续保留 MSS 候选 - ---- - -## 11.2 confirmed MSS - -第一阶段建议只把 confirmed MSS 写入主结构事件表。 - -原因： - -- 如果把大量候选 shift 都写入数据库，会污染下游 signal 逻辑 - -因此： - -- 候选状态可以在运行时内存中存在 -- 最终落库尽量只保留 confirmed MSS - ---- - -## 12. 写入策略 - -## 12.1 幂等要求 - -相同结构切换重复计算时： - -- 不应产生多个 identical MSS 记录 - -建议幂等参考： - -- instrument_id -- timeframe -- direction -- reference_swing_id -- displacement_event_id -- ts 所在主事件窗口 - ---- - -## 12.2 `accepted` 字段 - -第一阶段建议： - -- `accepted = true` 才进入高可信 MSS -- 若后续验证失败，可更新为 false 或不写入主表 - ---- - -## 13. 下游依赖约定 - -MSS 输出将被下游这样使用： - -### Bias -- 判断控制权是否已切换 - -### Signal -- 判断结构确认是否已经足够进入候选执行链路 - -### FVG Retrace Model -- 只有在 MSS 成立后，FVG retrace 才更具执行意义 - -因此 MSS 至少必须稳定输出： - -- direction -- broken_level -- accepted -- displacement 关联 -- timeframe - ---- - -## 14. 推荐任务拆分 - -### T1. MSB 识别 -- 判断关键 swing 是否被有效破坏 - -### T2. displacement 关联 -- 检查候选方向是否存在有效位移 - -### T3. acceptance 检测 -- 回补后是否守住新方向边界 - -### T4. MSS 事件入库 -- 写入 `structure_events` -- 标记 `event_type = MSS` - -### T5. sweep / FVG 关联 -- 增强下游执行语义 - ---- - -## 15. 验证检查点 - -## 15.1 最低验证 - -至少验证： - -- [ ] bullish MSS 可识别 -- [ ] bearish MSS 可识别 -- [ ] 只有 MSB 不会误升为 MSS -- [ ] displacement 缺失时不会误判 MSS - ---- - -## 15.2 行为验证 - -- [ ] acceptance 失败时不会保留 confirmed MSS -- [ ] 低周期 MSS 不会越权改写高周期结构 -- [ ] 有 sweep 背景的 MSS 更易进入高质量链路 - ---- - -## 15.3 人工抽查 - -至少抽查样本图表： - -- [ ] 被破坏 swing 选取合理 -- [ ] displacement 方向匹配 -- [ ] retest / acceptance 解释合理 -- [ ] confirmed MSS 与图表主观结构变化一致 - ---- - -## 16. 完成标准 - -只有满足以下全部条件，MSS 模块才算完成： - -1. 能稳定区分 MSB 与 MSS -2. 能要求 displacement 作为必要证据 -3. 能要求 retest / acceptance 作为确认条件 -4. 能输出 bullish / bearish MSS -5. 能幂等写入 `structure_events` -6. 可直接供 signal 模块使用 - ---- - -## 17. 当前结论 - -MSS 模块不是“突破后换个名字”，而是把“旧结构失效 + 新方向接管”闭合为一个可执行事件。 - -在真实开发中，它是从结构观察进入执行许可之前最关键的一道结构确认门。 \ No newline at end of file diff --git a/docs/AI_ICT_MVP_规则规格书_v1.md b/docs/AI_ICT_MVP_规则规格书_v1.md deleted file mode 100644 index 24f3ff2..0000000 --- a/docs/AI_ICT_MVP_规则规格书_v1.md +++ /dev/null @@ -1,761 +0,0 @@ -# AI ICT MVP 规则规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段 MVP 的规则规格，用于指导后续规则引擎、信号生成、回测、报告与执行模块开发。 - -第一阶段只围绕一个核心模型： - -`Sweep -> MSS -> FVG Retrace -> IRL/ERL` - -支持资产： - -- BTC -- ETH -- XAU - -支持目标： - -- 规则识别 -- 候选信号生成 -- 回测验证 -- 半自动执行 -- 复盘归因 - ---- - -## 2. 规则设计原则 - -1. 规则引擎主判定，AI 不主判单 -2. 所有判断尽量结构化、可存储、可回测 -3. 高周期定向，低周期触发 -4. 先条件、再触发、再确认、再执行、再退出 -5. 会话过滤和风控过滤属于硬规则 -6. 不在 MVP 阶段同时推进过多模型 - ---- - -## 3. 时间框架职责 - -### 3.1 默认职责 - -- bias_tf：方向与背景 -- range_tf：工作区间与位置 -- setup_tf：结构与路径 -- trigger_tf：触发与执行 - -### 3.2 MVP 默认配置 - -#### BTC / ETH - -- bias_tf: H4 -- range_tf: H1 -- setup_tf: M15 -- trigger_tf: M5 - -#### XAU - -- bias_tf: H1 -- range_tf: M15 -- setup_tf: M5 -- trigger_tf: M1 - -原则：低周期不能越权改写高周期方向，只能优化执行。 - ---- - -## 4. 核心对象 - -## 4.1 Candle - -标准 K 线对象，作为全部规则输入基础。 - -关键字段： - -- symbol -- venue -- timeframe -- ts_open -- ts_close -- open -- high -- low -- close -- volume - ---- - -## 4.2 SwingPoint - -用途：标记结构高低点。 - -关键字段： - -- kind: swing_high / swing_low -- strength: ST / IT / LT -- price -- ts -- left_bars -- right_bars -- confirmed - ---- - -## 4.3 DealingRange - -用途：建立当前工作区间与位置坐标。 - -关键字段： - -- high -- low -- equilibrium -- timeframe -- high_swing_id -- low_swing_id -- state - -输出位置： - -- premium -- discount -- equilibrium - ---- - -## 4.4 MarketSession - -用途：建立会话边界和会话 pivot。 - -关键字段： - -- session_code -- start_ts -- end_ts -- high -- low -- midpoint -- status - -默认会话： - -- ASIA -- LONDON -- NY_AM -- NY_LUNCH -- NY_PM - ---- - -## 4.5 LiquidityPool - -用途：标记待处理流动性区域。 - -关键字段： - -- side: buy_side / sell_side -- pool_type -- price_low -- price_high -- reference_ids -- status - -第一版 pool_type： - -- prior_high -- prior_low -- equal_highs -- equal_lows -- session_high -- session_low - ---- - -## 4.6 SweepEvent - -用途：标记一侧流动性被清理。 - -关键字段： - -- side_swept -- pool_id -- sweep_high -- sweep_low -- close_back_inside -- displacement_after -- ts - ---- - -## 4.7 DisplacementEvent - -用途：标记有效位移。 - -关键字段： - -- direction -- start_ts -- end_ts -- strength_score -- body_ratio -- has_fvg -- is_valid - ---- - -## 4.8 StructureEvent - -用途：保存 MSB / MSS。 - -关键字段： - -- event_type: MSB / MSS -- direction -- broken_level -- reference_swing_id -- displacement_event_id -- accepted -- ts - ---- - -## 4.9 FVGZone - -用途：作为 retrace entry zone。 - -关键字段： - -- direction -- upper -- lower -- start_ts -- end_ts -- fill_pct -- status - -状态： - -- open -- touched -- mitigated -- invalidated - ---- - -## 4.10 BiasSnapshot - -用途：保存某一时刻的偏向判断。 - -关键字段： - -- daily_bias -- confidence -- execution_intensity -- narrative_code -- draw_side -- range_id -- reason_codes - ---- - -## 4.11 TradeSignal - -用途：保存候选交易信号。 - -关键字段： - -- model_code -- side -- status -- entry_low / entry_high -- stop_loss -- tp1 -- tp2 -- rr_tp1 -- rr_tp2 -- invalidations -- evidence - ---- - -## 5. 规则清单 - -## R1. Swing 识别规则 - -### 目标 -识别结构锚点，供 range、liquidity、MSB/MSS 使用。 - -### 输入 -- 连续 candles -- 参数：left_bars, right_bars - -### 判定 -#### swing high -当前 K 线高点高于左右指定数量 K 线高点。 - -#### swing low -当前 K 线低点低于左右指定数量 K 线低点。 - -### 默认参数 -- M1/M5: 2 / 2 -- M15/H1: 3 / 3 -- H4/D: 3 / 3 - -### 输出 -- SwingPoint[] - -### 注意 -- 未完成右侧确认前，可仅标 provisional -- 最终回测时只以 confirmed swing 为准 - ---- - -## R2. Dealing Range 识别规则 - -### 目标 -建立工作区间和位置坐标。 - -### 输入 -- 指定周期 swings - -### 判定 -1. 选取最近有效 swing high / swing low -2. high = range 上边界 -3. low = range 下边界 -4. equilibrium = (high + low) / 2 - -### 输出 -- DealingRange -- 当前价格位置：premium / discount / equilibrium - -### MVP 简化 -- 每个 timeframe 同时只保留一个主工作区间 - ---- - -## R3. Liquidity Pool 识别规则 - -### 目标 -标记可能被优先处理的流动性区域。 - -### 输入 -- swings -- session pivots -- equal highs/lows 检测结果 - -### 判定对象 -1. prior high / prior low -2. equal highs / equal lows -3. Asia high / low -4. London high / low - -### 输出 -- LiquidityPool[] - -### 等高等低阈值 -应配置化，不同品种分开： - -- BTC / ETH：建议按百分比阈值 -- XAU：建议按固定 tick 阈值 - ---- - -## R4. Sweep 识别规则 - -### 目标 -识别“先清理，再递送”。 - -### 输入 -- candles -- liquidity pools - -### 判定 -#### buy-side sweep -1. 价格刺穿 buy-side pool -2. 随后回落或重新收回池内 -3. 后续出现反向 displacement 更优 - -#### sell-side sweep -反向。 - -### 分类 -- weak_sweep -- validated_sweep - -### validated_sweep 要求 -- sweep 后 N 根内出现反向 displacement - -### 输出 -- SweepEvent - ---- - -## R5. Displacement 识别规则 - -### 目标 -识别有效位移，避免把普通波动当趋势接管。 - -### 输入 -- candles -- ATR / 平均实体参考 -- FVG 检测结果 - -### 建议判定 -满足以下至少两条： - -1. 实体明显大于过去 N 根平均实体 -2. 单向推进明显 -3. 同时产生 FVG / imbalance -4. 快速脱离平衡区 - -### 输出 -- DisplacementEvent - ---- - -## R6. MSB 规则 - -### 目标 -判断旧路径被破坏。 - -### 输入 -- swings -- displacement -- current price - -### 判定 -1. 关键结构位被有效破坏 -2. 不只是 wick 穿越 -3. 最好伴随位移 - -### 输出 -- StructureEvent(event_type = MSB) - -### 说明 -- MSB 只代表旧路径稳定性下降 -- 不自动等于反转机会 - ---- - -## R7. MSS 规则 - -### 目标 -确认控制权切换。 - -### 输入 -- MSB -- displacement -- retest / acceptance -- updated draw - -### 判定 -必须满足： - -1. 已出现反向 MSB -2. 出现有效 displacement -3. 回补后未重新夺回原控制权 -4. 主 Draw 已重排 - -### MVP 简化版 -- MSB = true -- has_displacement = true -- retest 后未破失效边界 -- 新目标已可定义 - -### 输出 -- StructureEvent(event_type = MSS) - ---- - -## R8. FVG 识别规则 - -### 目标 -生成 retrace entry zone。 - -### 输入 -- 三根连续 candles - -### 判定 -#### bullish FVG -第一根高点 < 第三根低点 - -#### bearish FVG -第一根低点 > 第三根高点 - -### 输出 -- FVGZone - -### 附加属性 -- fill_pct -- first_touch_ts -- is_mitigated - ---- - -## R9. Bias 规则 - -### 目标 -输出可执行偏向，而不是自由观点。 - -### 输入 -- higher timeframe range -- liquidity state -- narrative inputs -- current location -- session - -### 输出字段 -- daily_bias: bullish / bearish / neutral -- confidence -- execution_intensity: low / medium / high -- reason_codes[] - -### 降级条件 -满足任一则降级： - -1. 价格回到 equilibrium 附近 -2. 明显 consolidation hurdles -3. 主 Draw 不清晰 -4. 当前 session 不支持当前路径 - ---- - -## R10. Session Filter 规则 - -### 目标 -把会话作为硬过滤器。 - -### 默认规则 -- ASIA：默认观察，不主动追单 -- LONDON：允许主触发 -- NY_AM：允许主触发 / 延续 -- NY_LUNCH：默认降频，只做管理或等待 -- NY_PM：允许延续或重构 -- OFF_HOURS：默认禁开新仓 - -### 输出 -- session_code -- execution_permission - ---- - -## R11. Entry Zone 规则 - -### 目标 -把结构链路转换为可执行信号。 - -### 做空链路 -1. higher timeframe bias 偏空 -2. buy-side liquidity 被 sweep -3. 出现 bearish displacement -4. 形成 bearish MSS -5. 出现 bearish FVG -6. 回补进入 FVG -7. stop 可定义 -8. RR 达标 -9. session 允许执行 - -### 做多链路 -反向。 - -### 输出 -- TradeSignal - ---- - -## R12. Invalidation 规则 - -### 目标 -定义否定叙事的硬边界。 - -### 空单默认失效条件 -任一满足即失效： - -1. trigger_tf 收盘重新站上 sweep high -2. 回补后出现反向强 displacement -3. 上游 range 重绘并否定原 narrative -4. 超过有效会话仍未触发 - -### 多单 -反向。 - ---- - -## R13. TP 规则 - -### 目标 -用 IRL / ERL 管理退出。 - -### 定义 -- TP1 = IRL -- TP2 = ERL - -### 默认执行逻辑 -- TP1 平部分仓位 -- TP2 留余仓争取延伸 -- 若到 TP1 后结构退化，可提前平余仓 - ---- - -## 6. MVP 主模型 - -## 模型名 -`SWEEP_MSS_FVG` - -## 做空链路 -1. 高周期偏空 -2. 当前价格不在明显 discount 追空 -3. buy-side liquidity 被 sweep -4. 出现 bearish displacement -5. 形成 bearish MSS -6. 出现 bearish FVG -7. 回补进入 FVG -8. stop 可定义 -9. TP1 / TP2 可定义 -10. RR >= 阈值 - -## 做多链路 -完全反向。 - -## 最低 RR -- tp2_rr >= 2.0 -- 若 tp1_rr < 1.0，拒绝信号 - ---- - -## 7. Signal 状态机 - -```text -draft --> awaiting_context --> awaiting_confirmation --> active --> tp1_hit --> tp2_hit --> invalidated --> expired --> cancelled -``` - ---- - -## 8. 回测标签定义 - -## 8.1 结果标签 - -- win -- loss -- breakeven -- missed - -## 8.2 过程指标 - -- mfe -- mae -- tp1_hit -- tp2_hit -- invalidated_before_entry -- session_code -- entry_triggered -- same_candle_priority -- same_candle_ambiguous - -## 8.3 错误归因标签 - -- late_entry -- poor_location -- no_displacement -- fake_mss -- session_mismatch -- range_redefined -- rr_too_low -- no_future_candles -- entry_not_triggered -- stopped_out -- same_candle_entry_exit_ambiguous - -## 8.4 回测成交语义 - -第一版回测只使用 OHLC K 线，无法知道同一根 K 线内部的真实触价顺序。因此必须采用保守、可追溯的假设： - -1. 若 entry、stop、TP 在同一根 K 线内同时可能发生，默认按 `stop_first` 处理 -2. 发生同根歧义时，结果仍按配置输出，但必须在 meta 中记录 `same_candle_ambiguous = true` -3. `invalidated_before_entry` 只表示入场前信号已经失效，不表示入场后的普通止损 -4. 入场后的止损使用 `outcome = loss` 与 `stopped_out` 标签表达 -5. session 覆盖结果必须写入 meta，便于后续按 session 统计与排错 - -## 8.5 统计维度 - -至少按以下维度分析： - -- symbol -- venue -- session -- weekday -- setup_tf -- trigger_tf -- side -- bias -- range location - ---- - -## 9. AI 报告接口边界 - -AI 不直接判单，只解释规则结果。 - -### 输入给 AI 的内容 -- higher timeframe context -- session -- sweep event -- structure event -- fvg zone -- trade signal - -### 输出给用户的内容 -- 简要结构说明 -- 当前动作建议 -- 关键失效边界 - -原则： - -- 规则层负责真值 -- AI 负责自然语言表达 - ---- - -## 10. 第一阶段开发顺序 - -### 阶段 1：基础数据 -- candles -- market_sessions - -### 阶段 2：结构基础 -- swings -- dealing_ranges -- liquidity_pools - -### 阶段 3：核心触发 -- sweep_events -- displacement_events -- structure_events -- fvg_zones - -### 阶段 4：决策与信号 -- bias_snapshots -- trade_signals - -### 阶段 5：验证与执行 -- backtest labels -- trade_executions -- reports - ---- - -## 11. 当前结论 - -MVP 的关键不是把 ICT 所有术语一次性实现完，而是稳定打通这一条最小闭环： - -`Candles -> Sessions -> Swings -> Range -> Liquidity -> Sweep -> MSS -> FVG -> Signal -> Execution -> Backtest` - -后续所有复杂模型都应建立在这条主链路稳定可验证的前提上。 diff --git a/docs/AI_ICT_Migration_拆分计划_v1.md b/docs/AI_ICT_Migration_拆分计划_v1.md deleted file mode 100644 index d6cbac6..0000000 --- a/docs/AI_ICT_Migration_拆分计划_v1.md +++ /dev/null @@ -1,493 +0,0 @@ -# AI ICT PostgreSQL Migration 拆分计划 v1 - -## 1. 文档目标 - -本文档把 `AI_ICT_PostgreSQL_Schema_v1.md` 中定义的数据库结构拆分成可实际执行的 migration 批次，明确建表顺序、依赖关系、验证点和回滚注意事项。 - -目标： - -- 避免一次性建全部表导致排查困难 -- 确保基础共享表优先落地 -- 让后续开发可以按 migration 批次推进 -- 每一批 migration 都具备可验证完成标准 - ---- - -## 2. 拆分原则 - -1. 按依赖顺序拆分，而不是按功能名堆叠 -2. 先基础字典表，再时间序列表，再结构事件表，再信号执行表 -3. 每批 migration 最好能独立验证 -4. 每批 migration 结束都要有回滚边界 -5. candles 分区单独处理，不混在其他逻辑里 - ---- - -## 3. 总体批次划分 - -建议拆成 6 批 migration： - -1. 基础字典层 -2. 时间序列与会话层 -3. 基础结构层 -4. 核心事件层 -5. 决策与执行层 -6. 回测与分析层 - ---- - -## 4. Migration Batch 1：基础字典层 - -## 4.1 包含表 - -- `venues` -- `instruments` - -## 4.2 依赖关系 - -- 无上游依赖 -- 所有后续表都依赖 `instruments` - -## 4.3 建议拆分 - -### migration_001_create_venues -建立： -- venues 主键 -- code 唯一键 -- timezone -- status -- created_at / updated_at - -### migration_002_create_instruments -建立： -- instruments 主键 -- venue_id 外键 -- symbol -- asset_class -- tick_size -- lot_size -- price_scale -- qty_scale -- meta jsonb -- unique (venue_id, symbol) - -## 4.4 验证点 - -- [ ] 可插入 OKX / LMAX -- [ ] 可插入 BTC / ETH / XAU instrument -- [ ] 重复 symbol + venue 被唯一键阻止 - -## 4.5 回滚边界 - -- 该批可整体回滚 -- 若已被下游表依赖，不应单独删除 `venues` - ---- - -## 5. Migration Batch 2：时间序列与会话层 - -## 5.1 包含表 - -- `candles` -- `market_sessions` - -## 5.2 依赖关系 - -- 依赖 `instruments` - -## 5.3 建议拆分 - -### migration_003_create_candles -建立： -- candles 主表 -- instrument_id 外键 -- timeframe -- ts_open / ts_close -- OHLCV -- source -- created_at -- unique (instrument_id, timeframe, ts_open) - -### migration_004_create_candles_indexes -建立： -- candles 查询索引 -- instrument + timeframe + ts_open desc -- instrument + timeframe + ts_close desc - -### migration_005_create_market_sessions -建立： -- market_sessions -- session_date -- session_code -- timezone -- start_ts / end_ts -- high / low / midpoint -- status -- meta jsonb -- unique (instrument_id, session_date, session_code, timezone) - -## 5.4 candles 分区说明 - -建议： -- candles 主表创建后立即加入月分区策略 -- 第一版先建立当前月和下个月分区 - -示例命名： -- candles_2026_04 -- candles_2026_05 - -## 5.5 验证点 - -- [ ] candles 可插入样本数据 -- [ ] 相同 `instrument_id + timeframe + ts_open` 无法重复插入 -- [ ] market_sessions 可插入单日会话样本 -- [ ] session 唯一键有效 - -## 5.6 回滚边界 - -- 可先删除 `market_sessions` -- candles 若已有大量数据，不应轻易整体回滚 - ---- - -## 6. Migration Batch 3：基础结构层 - -## 6.1 包含表 - -- `swings` -- `dealing_ranges` -- `liquidity_pools` - -## 6.2 依赖关系 - -- 依赖 `instruments` -- `dealing_ranges` 依赖 `swings` - -## 6.3 建议拆分 - -### migration_006_create_swings -建立： -- swings -- kind -- strength -- price -- ts -- left_bars / right_bars -- confirmed -- meta jsonb - -### migration_007_create_dealing_ranges -建立： -- dealing_ranges -- high / low / equilibrium -- high_swing_id / low_swing_id -- state -- ts_start / ts_end -- meta jsonb - -### migration_008_create_liquidity_pools -建立： -- liquidity_pools -- side -- pool_type -- price_low / price_high -- reference_ids jsonb -- status -- created_ts / updated_ts -- meta jsonb - -## 6.4 验证点 - -- [ ] swings 可写入样本数据 -- [ ] dealing_ranges 可引用 swings -- [ ] liquidity_pools 可写入 prior/session pool 样本 -- [ ] 索引查询有效 - -## 6.5 回滚边界 - -- 若 `dealing_ranges` 已引用 `swings`，回滚顺序必须反向 -- 推荐回滚顺序： - 1. liquidity_pools - 2. dealing_ranges - 3. swings - ---- - -## 7. Migration Batch 4：核心事件层 - -## 7.1 包含表 - -- `displacement_events` -- `structure_events` -- `fvg_zones` - -## 7.2 依赖关系 - -- 依赖 `instruments` -- `structure_events` 可依赖 `swings` 与 `displacement_events` -- `fvg_zones` 可依赖 `displacement_events` - -## 7.3 建议拆分 - -### migration_009_create_displacement_events -建立： -- direction -- start_ts / end_ts -- strength_score -- body_ratio -- has_fvg -- is_valid -- meta jsonb - -### migration_010_create_structure_events -建立： -- event_type -- direction -- broken_level -- reference_swing_id -- displacement_event_id -- accepted -- signal_relevant -- ts -- meta jsonb - -### migration_011_create_fvg_zones -建立： -- direction -- upper / lower -- start_ts / end_ts -- fill_pct -- status -- related_displacement_id -- meta jsonb - -## 7.4 验证点 - -- [ ] displacement_events 可写入正例样本 -- [ ] structure_events 可关联 swings / displacement -- [ ] fvg_zones 可关联 displacement -- [ ] 事件查询按 timeframe 和时间排序正常 - -## 7.5 回滚边界 - -- 推荐反向删除： - 1. fvg_zones - 2. structure_events - 3. displacement_events - ---- - -## 8. Migration Batch 5：决策与执行层 - -## 8.1 包含表 - -- `bias_snapshots` -- `trade_signals` -- `trade_executions` - -## 8.2 依赖关系 - -- `bias_snapshots` 依赖 `dealing_ranges` -- `trade_signals` 依赖 `bias_snapshots` -- `trade_executions` 依赖 `trade_signals` - -## 8.3 建议拆分 - -### migration_012_create_bias_snapshots -建立： -- bias_tf / setup_tf / trigger_tf -- snapshot_ts -- daily_bias -- confidence -- execution_intensity -- narrative_code -- draw_side -- range_id -- reason_codes jsonb -- meta jsonb - -### migration_013_create_trade_signals -建立： -- model_code -- side -- status -- bias_snapshot_id -- entry_low / entry_high -- stop_loss -- tp1 / tp2 -- rr_tp1 / rr_tp2 -- session_code -- created_ts / expires_ts -- invalidations jsonb -- evidence jsonb -- meta jsonb - -### migration_014_create_trade_executions -建立： -- signal_id -- venue_order_id -- execution_mode -- side -- entry_price -- stop_loss -- take_profit_1 / take_profit_2 -- size -- risk_pct -- status -- opened_ts / closed_ts -- pnl -- meta jsonb - -## 8.4 验证点 - -- [ ] bias snapshot 可插入样本 -- [ ] trade_signals 可引用 bias snapshot -- [ ] trade_executions 可引用 trade_signals -- [ ] 信号和执行链路主外键正常 - -## 8.5 回滚边界 - -- 推荐反向回滚： - 1. trade_executions - 2. trade_signals - 3. bias_snapshots - ---- - -## 9. Migration Batch 6：回测与分析层 - -## 9.1 包含表 - -- `backtest_runs` -- `backtest_results` - -## 9.2 依赖关系 - -- `backtest_results` 依赖 `backtest_runs` -- 可选关联 `trade_signals` - -## 9.3 建议拆分 - -### migration_015_create_backtest_runs -建立： -- model_code -- instrument_id -- timeframe_set jsonb -- started_ts / ended_ts -- config jsonb -- summary jsonb - -### migration_016_create_backtest_results -建立： -- backtest_run_id -- signal_id -- outcome -- mfe / mae -- tp1_hit / tp2_hit -- invalidated_before_entry -- error_tags jsonb -- meta jsonb - -## 9.4 验证点 - -- [ ] 可创建一次 backtest run -- [ ] 可写入多条 result -- [ ] 可按 backtest_run_id 查询完整结果 - -## 9.5 回滚边界 - -- 推荐反向回滚： - 1. backtest_results - 2. backtest_runs - ---- - -## 10. 索引拆分建议 - -为了避免 migration 过重，建议表创建和重索引拆开。 - -### 10.1 表创建时保留 -- 主键 -- 唯一键 -- 必要外键 - -### 10.2 批量追加索引时处理 -- 高频查询索引 -- 多列排序索引 -- 状态查询索引 - -### 10.3 特别建议 -对 `candles` 的索引和分区单独处理，不要与业务事件表混在同一 migration 中。 - ---- - -## 11. 数据初始化建议 - -基础 migration 完成后，立即执行一批 seed： - -### seed_001_venues -- OKX -- LMAX - -### seed_002_instruments -- OKX BTC -- OKX ETH -- LMAX XAU - -说明： -- XAU 若真实合约代码尚未最终确定，可先留占位 instrument，但要明确标记 `active=false` 或在 meta 标出待确认状态。 - ---- - -## 12. 推荐执行顺序 - -实际落地时建议严格按以下顺序： - -1. migration_001_create_venues -2. migration_002_create_instruments -3. migration_003_create_candles -4. migration_004_create_candles_indexes -5. migration_005_create_market_sessions -6. migration_006_create_swings -7. migration_007_create_dealing_ranges -8. migration_008_create_liquidity_pools -9. migration_009_create_displacement_events -10. migration_010_create_structure_events -11. migration_011_create_fvg_zones -12. migration_012_create_bias_snapshots -13. migration_013_create_trade_signals -14. migration_014_create_trade_executions -15. migration_015_create_backtest_runs -16. migration_016_create_backtest_results - ---- - -## 13. 第一轮最小落地目标 - -如果要最快进入真实开发，第一轮只需先完成以下 migration： - -- 001 venues -- 002 instruments -- 003 candles -- 004 candles indexes -- 005 market_sessions -- 006 swings -- 007 dealing_ranges - -这 7 个 migration 完成后，就能开始搭建： - -`Candles -> Sessions -> Swings -> Ranges` - -这也是全系统第一条必须打通的基础链路。 - ---- - -## 14. 当前结论 - -Migration 拆分的关键不是数量，而是让每一批都具备： - -- 明确依赖 -- 明确验证点 -- 明确回滚顺序 - -后续真实开发时，应以本文件作为 migration 执行顺序的标准参考，不建议跳批次直接建后面的表。 \ No newline at end of file diff --git a/docs/AI_ICT_OKX_数据接入规格书_v1.md b/docs/AI_ICT_OKX_数据接入规格书_v1.md deleted file mode 100644 index 4a4dd43..0000000 --- a/docs/AI_ICT_OKX_数据接入规格书_v1.md +++ /dev/null @@ -1,433 +0,0 @@ -# AI ICT OKX 数据接入规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 OKX 数据接入方案，用于指导市场数据层的真实实现。 - -本规格书聚焦： - -1. BTC / ETH 行情接入 -2. K 线标准化 -3. 历史补数与增量同步 -4. PostgreSQL 入库 -5. 可验证的数据质量控制 - -第一阶段只把 OKX 作为主数据源，用于先打通： - -`OKX -> Candles -> Sessions -> Swings -> Ranges` - ---- - -## 2. 接入目标 - -第一阶段只处理最小必需数据。 - -### 2.1 支持品种 - -- BTC-USDT-SWAP 或你最终选定的 BTC 交易标的 -- ETH-USDT-SWAP 或你最终选定的 ETH 交易标的 - -说明： - -- 最终采用现货、永续、期货中的哪一种，需要在启动开发前固定 -- 如果目标是日内交易模型，优先建议统一用流动性更稳定的一类合约，不要混用多个产品类型 - -### 2.2 支持周期 - -第一阶段建议： - -- 1m -- 5m -- 15m -- 1H -- 4H - -### 2.3 第一阶段不接入 - -- 深度订单簿 -- 逐笔成交 -- 账户资产信息 -- 下单接口 -- WebSocket 实时执行流 - -这些可留到后续阶段。 - ---- - -## 3. 数据对象定义 - -## 3.1 原始对象 - -OKX 返回的原始 K 线数据需要先保存在抓取层对象中。 - -建议原始对象字段： - -- instId -- bar -- ts -- o -- h -- l -- c -- vol -- volCcy -- volCcyQuote -- confirm - -说明： - -- 原始对象仅用于抓取与排障 -- 不建议原样直接写入业务主表 - ---- - -## 3.2 标准化 Candle 对象 - -写入业务层前统一转换为： - -- symbol -- venue -- timeframe -- ts_open -- ts_close -- open -- high -- low -- close -- volume -- source - -对应数据库表：`candles` - ---- - -## 4. 品种映射规则 - -## 4.1 instrument mapping 原则 - -必须建立 OKX 原始标的与系统内部 instrument 的映射表，不允许在业务代码中硬编码散落的 instId。 - -建议至少维护： - -- venue_code = OKX -- raw_inst_id -- internal_symbol -- asset_class -- product_type -- active - ---- - -## 4.2 建议做法 - -统一在配置层维护，例如： - -```yaml -okx: - instruments: - - raw_inst_id: BTC-USDT-SWAP - symbol: BTC-USDT - product_type: swap - active: true - - raw_inst_id: ETH-USDT-SWAP - symbol: ETH-USDT - product_type: swap - active: true -``` - -说明： - -- 若后续切成现货或期货，只改映射配置，不改抓取主流程 -- 内部 symbol 命名要固定，避免后续信号和回测口径混乱 - ---- - -## 5. 时间框架映射规则 - -OKX 周期值需要统一映射为系统内部 timeframe。 - -建议映射： - -- OKX 1m -> 1m -- OKX 5m -> 5m -- OKX 15m -> 15m -- OKX 1H -> 1h -- OKX 4H -> 4h - -要求： - -- 系统内部统一使用小写：`1m`, `5m`, `15m`, `1h`, `4h` -- 所有数据库写入和规则引擎都只识别内部格式 - ---- - -## 6. 抓取模式设计 - -第一阶段建议同时支持两种模式： - -1. 历史补数 -2. 增量同步 - ---- - -## 6.1 历史补数模式 - -### 目标 -把某个品种某个 timeframe 的历史 K 线补齐到本地数据库。 - -### 输入 -- symbol -- timeframe -- from_ts -- to_ts - -### 输出 -- 分页抓取后的 candles -- 去重写入数据库 - -### 要求 -- 允许断点续传 -- 允许分段回补 -- 每批抓取后立即落库 -- 不应先全放内存再统一写入 - ---- - -## 6.2 增量同步模式 - -### 目标 -持续更新最新 K 线。 - -### 方式 -第一阶段先用轮询，不强依赖 WebSocket。 - -### 输入 -- symbol -- timeframe -- last_ts_open - -### 输出 -- 自上次已入库时间后的新增 candles - -### 要求 -- 支持幂等执行 -- 支持重复轮询不重复写入 -- 遇到单次接口失败可重试 -- 重试失败要记录日志，不静默吞掉 - ---- - -## 7. 数据标准化规则 - -## 7.1 数值字段 - -抓取层统一转换： - -- open -> numeric -- high -> numeric -- low -> numeric -- close -> numeric -- volume -> numeric - -要求： - -- 不在业务层保留字符串数字 -- 所有价格字段统一用高精度 decimal / numeric - ---- - -## 7.2 时间字段 - -### 原则 -所有数据库字段统一转成 `timestamptz` 语义处理。 - -### 要求 -- `ts_open` 必须是 candle 起始时间 -- `ts_close` 必须能由 timeframe 推导或明确计算 -- 所有入库时间统一使用 UTC 存储 -- session 层再按 `America/New_York` 做切分 - ---- - -## 7.3 confirm 字段处理 - -若 OKX 原始数据带 `confirm`： - -- confirm = 1：已完成 candle，可直接进入稳定数据链路 -- confirm = 0：未完成 candle，仅用于实时观察，不作为正式规则输入 - -第一阶段建议： - -- 历史补数只写 confirmed candles -- 增量同步默认只将 confirmed candle 写入规则主表 -- 若需要观察未闭合 K，可另建缓存逻辑，不写正式主表 - ---- - -## 8. 数据入库规则 - -## 8.1 写入目标表 - -- `candles` - -### 唯一键 - -`(instrument_id, timeframe, ts_open)` - -### 写入策略 - -- 存在则跳过或更新（按最终策略固定） -- 第一阶段建议使用幂等 upsert - ---- - -## 8.2 幂等策略 - -要求： - -- 同一批历史补数重复执行，不得产生重复数据 -- 同一轮增量同步重复执行，不得产生重复数据 -- 数据库唯一键必须作为最后防线 - -建议： - -- 应用层先去重 -- 数据库层再唯一键兜底 - ---- - -## 9. 错误处理规范 - -## 9.1 可重试错误 - -- 网络超时 -- 临时 5xx -- 限频返回 -- 短暂连接失败 - -处理要求： - -- 有限次重试 -- 指数退避或固定退避 -- 每次重试记录日志 - -## 9.2 不可重试错误 - -- 无效 instId -- 无效 timeframe -- 配置缺失 -- 映射错误 - -处理要求： - -- 立即失败 -- 输出清晰错误信息 -- 标记为配置问题，而不是抓取异常 - ---- - -## 9.3 限频处理 - -必须考虑 OKX 接口限频。 - -要求： - -- 同一时间不要无节制并发多个 timeframe + symbol 请求 -- 增加抓取节流 -- 错误日志中要能区分： - - 网络失败 - - 限频失败 - - 配置失败 - ---- - -## 10. 推荐任务拆分 - -实现时建议拆成以下小任务： - -### T1. OKX 配置模块 -- 定义 base URL -- 定义 instrument mapping -- 定义 timeframe mapping - -### T2. 原始 API client -- 单次请求能力 -- 参数校验 -- 错误处理 - -### T3. 历史补数任务 -- 分页抓取 -- 批量标准化 -- 入库 - -### T4. 增量同步任务 -- 读取 last_ts_open -- 拉新增数据 -- 幂等入库 - -### T5. 数据验证任务 -- 查询 DB 样本 -- 检查连续性 -- 检查重复 - ---- - -## 11. 验证检查点 - -## 11.1 最低验证要求 - -实现后至少验证以下内容： - -- [ ] BTC 1m 数据可入库 -- [ ] BTC 5m 数据可入库 -- [ ] ETH 1m 数据可入库 -- [ ] ETH 5m 数据可入库 -- [ ] 指定时间范围查询结果连续 -- [ ] 无重复 candle -- [ ] timeframe 映射正确 - ---- - -## 11.2 样本验证 - -至少对一段时间窗口做以下核查： - -- [ ] `open <= high` -- [ ] `low <= close <= high` -- [ ] `low <= open <= high` -- [ ] ts_open 连续性正确 -- [ ] 同一 instrument/timeframe 无重复 ts_open - ---- - -## 11.3 session 前置验证 - -在进入 session generator 前，必须保证： - -- [ ] 目标交易日 candles 已完整 -- [ ] 时区转换无误 -- [ ] 缺口已识别 - -否则 session high / low 可能失真。 - ---- - -## 12. 第一阶段交付标准 - -只有满足以下全部条件，OKX 数据接入模块才算完成： - -1. BTC / ETH 至少两个 timeframe 可稳定入库 -2. 历史补数可重复执行且不重复写入 -3. 增量同步可重复执行且不重复写入 -4. candles 查询样本通过完整性检查 -5. 下游 session 生成器可直接消费数据 - ---- - -## 13. 当前结论 - -第一阶段的 OKX 数据接入不是“能拉到数据就算完成”，而是必须满足： - -> 可映射、可标准化、可幂等入库、可重复验证、可直接供下游规则使用 - -后续真实实现时，应优先按本规格书完成 BTC / ETH candles 数据链路，再进入 session、swing 和 range 模块。 \ No newline at end of file diff --git a/docs/AI_ICT_PostgreSQL_Schema_v1.md b/docs/AI_ICT_PostgreSQL_Schema_v1.md deleted file mode 100644 index 1435caf..0000000 --- a/docs/AI_ICT_PostgreSQL_Schema_v1.md +++ /dev/null @@ -1,806 +0,0 @@ -# AI ICT PostgreSQL Schema 设计稿 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 交易辅助系统第一阶段的 PostgreSQL 数据库设计方案，用于指导后续开发、建表、索引、分区和数据落库规范。 - -目标： - -- 支撑 K 线与时间序列数据 -- 支撑 ICT 结构事件与信号建模 -- 支撑回测、复盘和审计 -- 支撑半结构化 evidence / narrative / labels 存储 - ---- - -## 2. 设计原则 - -1. PostgreSQL 作为主库 -2. 时间序列主表优先做唯一键与分区设计 -3. 结构事件独立存表，不混入自由文本 -4. AI 相关说明使用 `jsonb`，但不替代核心字段 -5. 回测与实盘使用同一事件口径 -6. 先保守建模，预留扩展字段，不做过早复杂抽象 - ---- - -## 3. 命名规范 - -- 表名：复数下划线风格，如 `trade_signals` -- 主键：统一使用 `bigserial` 或 `uuid` -- 时间字段：统一使用 `timestamptz` -- 创建更新时间：`created_at`, `updated_at` -- 逻辑状态：`status` -- 配置或证据：`jsonb` - -建议： - -- 若系统由 Python / TypeScript 混合开发，业务主键可用 `uuid` -- 若偏简洁开发，内部主键可用 `bigserial`，外部展示再加 `public_id` - -第一版建议： - -- 主表内部主键：`bigserial` -- 对外引用可追加 `code` / `public_id` - ---- - -## 4. 核心实体关系概览 - -```text -venues - -> instruments - -> candles - -> market_sessions - -> swings - -> dealing_ranges - -> liquidity_pools - -> displacement_events - -> structure_events - -> fvg_zones - -> bias_snapshots - -> trade_signals - -> trade_executions - -backtest_runs - -> backtest_results -``` - ---- - -## 5. 基础表设计 - -## 5.1 venues - -用途：交易所定义表。 - -建议字段： - -```sql -id bigserial primary key -code text not null unique -name text not null -timezone text not null -status text not null default 'active' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -示例数据： - -- OKX -- LMAX - ---- - -## 5.2 instruments - -用途：交易品种定义表。 - -建议字段： - -```sql -id bigserial primary key -venue_id bigint not null references venues(id) -symbol text not null -asset_class text not null -base_asset text -quote_asset text -price_scale integer not null -qty_scale integer not null -tick_size numeric(20,10) not null -lot_size numeric(20,10) -active boolean not null default true -meta jsonb not null default '{}' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -唯一约束： - -```sql -unique (venue_id, symbol) -``` - -说明： - -- `meta` 存放交易所特定扩展信息 -- 如 XAU 在不同 venue 上合约不同，可通过 `meta` 补充合约属性 - ---- - -## 6. 行情与时间表设计 - -## 6.1 candles - -用途：标准化 K 线主表。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -ts_open timestamptz not null -ts_close timestamptz not null -open numeric(20,10) not null -high numeric(20,10) not null -low numeric(20,10) not null -close numeric(20,10) not null -volume numeric(28,10) -source text not null default 'api' -created_at timestamptz not null default now() -``` - -唯一约束： - -```sql -unique (instrument_id, timeframe, ts_open) -``` - -核心索引： - -```sql -index on (instrument_id, timeframe, ts_open desc) -index on (instrument_id, timeframe, ts_close desc) -``` - -分区建议： - -- 第一版按月范围分区 -- 分区键建议使用 `ts_open` - -例如： - -- `candles_2026_04` -- `candles_2026_05` - -说明： - -- `timeframe` 先使用文本：`1m`, `5m`, `15m`, `1h`, `4h`, `1d` -- 后期可引入枚举或维表 - ---- - -## 6.2 market_sessions - -用途：保存会话级别数据与 pivot。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -session_date date not null -timezone text not null -session_code text not null -start_ts timestamptz not null -end_ts timestamptz not null -high numeric(20,10) -low numeric(20,10) -midpoint numeric(20,10) -status text not null default 'closed' -meta jsonb not null default '{}' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -唯一约束： - -```sql -unique (instrument_id, session_date, session_code, timezone) -``` - -建议的 `session_code`： - -- ASIA -- LONDON -- NY_AM -- NY_LUNCH -- NY_PM - -说明： - -- `meta` 可保存 broken / mitigated / extension 信息 -- 该表是会话 pivot、killzone 和执行许可的重要基础 - ---- - -## 7. 结构识别表设计 - -## 7.1 swings - -用途：保存结构高低点。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -kind text not null -strength text not null -price numeric(20,10) not null -ts timestamptz not null -left_bars integer not null -right_bars integer not null -confirmed boolean not null default true -meta jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -索引建议： - -```sql -index on (instrument_id, timeframe, ts desc) -index on (instrument_id, timeframe, kind, ts desc) -index on (instrument_id, timeframe, strength, ts desc) -``` - -约束建议： - -- `kind in ('swing_high', 'swing_low')` -- `strength in ('ST', 'IT', 'LT')` - ---- - -## 7.2 dealing_ranges - -用途：保存当前工作区间。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -high numeric(20,10) not null -low numeric(20,10) not null -equilibrium numeric(20,10) not null -high_swing_id bigint references swings(id) -low_swing_id bigint references swings(id) -state text not null default 'valid' -ts_start timestamptz not null -ts_end timestamptz -meta jsonb not null default '{}' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -索引建议： - -```sql -index on (instrument_id, timeframe, ts_start desc) -index on (instrument_id, timeframe, state, ts_start desc) -``` - -说明： - -- 同一时刻可能存在多个 timeframe 的 range -- 第一版允许一个 timeframe 存多条历史记录，由 `state` 标识当前有效项 - ---- - -## 7.3 liquidity_pools - -用途：保存流动性目标区域。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -side text not null -pool_type text not null -price_low numeric(20,10) not null -price_high numeric(20,10) not null -reference_ids jsonb not null default '[]' -status text not null default 'untouched' -created_ts timestamptz not null -updated_ts timestamptz not null default now() -meta jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -建议约束： - -- `side in ('buy_side', 'sell_side')` -- `status in ('untouched', 'swept', 'consumed')` - -`pool_type` 建议值： - -- prior_high -- prior_low -- equal_highs -- equal_lows -- session_high -- session_low - -索引建议： - -```sql -index on (instrument_id, timeframe, status, created_ts desc) -index on (instrument_id, timeframe, side, created_ts desc) -``` - ---- - -## 7.4 displacement_events - -用途：保存有效位移事件。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -direction text not null -start_ts timestamptz not null -end_ts timestamptz not null -strength_score numeric(8,4) -body_ratio numeric(8,4) -has_fvg boolean not null default false -is_valid boolean not null default true -meta jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -索引建议： - -```sql -index on (instrument_id, timeframe, end_ts desc) -index on (instrument_id, timeframe, direction, end_ts desc) -``` - ---- - -## 7.5 structure_events - -用途：保存 MSB / MSS 等结构事件。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -event_type text not null -direction text not null -broken_level numeric(20,10) not null -reference_swing_id bigint references swings(id) -displacement_event_id bigint references displacement_events(id) -accepted boolean -signal_relevant boolean not null default true -ts timestamptz not null -meta jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -约束建议： - -- `event_type in ('MSB', 'MSS')` -- `direction in ('bullish', 'bearish')` - -索引建议： - -```sql -index on (instrument_id, timeframe, ts desc) -index on (instrument_id, timeframe, event_type, ts desc) -``` - ---- - -## 7.6 fvg_zones - -用途：保存 FVG / imbalance 区域。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -timeframe text not null -direction text not null -upper numeric(20,10) not null -lower numeric(20,10) not null -start_ts timestamptz not null -end_ts timestamptz not null -fill_pct numeric(8,4) not null default 0 -status text not null default 'open' -related_displacement_id bigint references displacement_events(id) -meta jsonb not null default '{}' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -约束建议： - -- `direction in ('bullish', 'bearish')` -- `status in ('open', 'touched', 'mitigated', 'invalidated')` - -索引建议： - -```sql -index on (instrument_id, timeframe, start_ts desc) -index on (instrument_id, timeframe, status, start_ts desc) -``` - ---- - -## 8. 决策与执行表设计 - -## 8.1 bias_snapshots - -用途：保存特定时刻的 bias 结果。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -bias_tf text not null -setup_tf text not null -trigger_tf text not null -snapshot_ts timestamptz not null -daily_bias text not null -confidence numeric(8,4) -execution_intensity text not null -narrative_code text -draw_side text -range_id bigint references dealing_ranges(id) -reason_codes jsonb not null default '[]' -meta jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -约束建议： - -- `daily_bias in ('bullish', 'bearish', 'neutral')` -- `execution_intensity in ('low', 'medium', 'high')` - -索引建议： - -```sql -index on (instrument_id, snapshot_ts desc) -index on (instrument_id, daily_bias, snapshot_ts desc) -``` - ---- - -## 8.2 trade_signals - -用途：保存候选交易信号。 - -建议字段： - -```sql -id bigserial primary key -instrument_id bigint not null references instruments(id) -model_code text not null -side text not null -status text not null -bias_snapshot_id bigint references bias_snapshots(id) -entry_type text not null -entry_low numeric(20,10) -entry_high numeric(20,10) -stop_loss numeric(20,10) -tp1 numeric(20,10) -tp2 numeric(20,10) -rr_tp1 numeric(8,4) -rr_tp2 numeric(8,4) -session_code text -created_ts timestamptz not null -expires_ts timestamptz -invalidations jsonb not null default '[]' -evidence jsonb not null default '{}' -meta jsonb not null default '{}' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -建议状态值： - -- draft -- awaiting_context -- awaiting_confirmation -- active -- tp1_hit -- tp2_hit -- invalidated -- expired -- cancelled - -索引建议： - -```sql -index on (instrument_id, created_ts desc) -index on (instrument_id, status, created_ts desc) -index on (instrument_id, model_code, created_ts desc) -``` - -说明： - -- `evidence` 保存 rule engine 引用对象，如 `range_id`, `sweep_event_id`, `structure_event_id`, `fvg_id` -- 核心交易字段必须显式建列，不应只放进 JSON - ---- - -## 8.3 trade_executions - -用途：保存实际执行记录。 - -建议字段： - -```sql -id bigserial primary key -signal_id bigint not null references trade_signals(id) -venue_order_id text -execution_mode text not null -side text not null -entry_price numeric(20,10) -stop_loss numeric(20,10) -take_profit_1 numeric(20,10) -take_profit_2 numeric(20,10) -size numeric(28,10) -risk_pct numeric(8,4) -status text not null -opened_ts timestamptz -closed_ts timestamptz -pnl numeric(28,10) -meta jsonb not null default '{}' -created_at timestamptz not null default now() -updated_at timestamptz not null default now() -``` - -建议枚举： - -- `execution_mode in ('paper', 'semi_auto', 'live')` -- `status in ('pending', 'open', 'partially_closed', 'closed', 'cancelled', 'rejected')` - -索引建议： - -```sql -index on (signal_id) -index on (status, created_at desc) -index on (execution_mode, created_at desc) -``` - ---- - -## 9. 回测与分析表设计 - -## 9.1 backtest_runs - -用途：保存回测任务定义与结果摘要。 - -建议字段： - -```sql -id bigserial primary key -model_code text not null -instrument_id bigint references instruments(id) -timeframe_set jsonb not null default '{}' -started_ts timestamptz not null -ended_ts timestamptz -config jsonb not null default '{}' -summary jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -索引建议： - -```sql -index on (model_code, started_ts desc) -index on (instrument_id, started_ts desc) -``` - ---- - -## 9.2 backtest_results - -用途：保存回测明细结果。 - -建议字段： - -```sql -id bigserial primary key -backtest_run_id bigint not null references backtest_runs(id) -signal_id bigint references trade_signals(id) -outcome text not null -mfe numeric(20,10) -mae numeric(20,10) -tp1_hit boolean -tp2_hit boolean -invalidated_before_entry boolean -error_tags jsonb not null default '[]' -meta jsonb not null default '{}' -created_at timestamptz not null default now() -``` - -建议枚举： - -- `outcome in ('win', 'loss', 'breakeven', 'missed')` - -索引建议： - -```sql -index on (backtest_run_id) -index on (outcome) -``` - ---- - -## 10. JSONB 边界建议 - -适合放入 `jsonb` 的内容： - -- evidence 引用集合 -- narrative reason codes -- 回测 error tags -- 风控检查详情 -- 第三方交易所扩展字段 -- 会话扩展状态 - -不应只存在于 `jsonb` 的内容： - -- side -- status -- timeframe -- symbol / instrument_id -- stop_loss -- tp1 / tp2 -- bias -- event_type -- direction -- ts - -原则： - -- 查询高频、过滤高频、排序高频字段必须单独建列 -- JSONB 仅用于补充与扩展 - ---- - -## 11. 索引策略建议 - -### 11.1 时间序列表 - -优先索引： - -- `(instrument_id, timeframe, ts_open desc)` -- `(instrument_id, timeframe, ts desc)` -- `(instrument_id, status, created_ts desc)` - -### 11.2 事件表 - -优先索引： - -- 按 `instrument_id + timeframe + time` -- 按 `event_type` -- 按 `status` - -### 11.3 回测表 - -优先索引： - -- `backtest_run_id` -- `outcome` -- `instrument_id + started_ts` - ---- - -## 12. 分区建议 - -### 12.1 必须优先分区的表 - -1. `candles` -2. 后期若数据量变大，可考虑： - - `trade_signals` - - `trade_executions` - - `backtest_results` - -### 12.2 第一版建议 - -- `candles` 采用月分区 -- 其他表先普通表 + 合理索引 -- 不要一开始对所有事件表做过度分区 - -原因： - -- candles 数据量增长最快 -- 其余表前期量可控 -- 先简化迁移和开发成本 - ---- - -## 13. 当前优先落地的 5 张基础表 - -按照基础模块优先，建议先建： - -1. `venues` -2. `instruments` -3. `candles` -4. `market_sessions` -5. `swings` - -然后再建： - -6. `dealing_ranges` -7. `liquidity_pools` - -之后进入： - -8. `displacement_events` -9. `structure_events` -10. `fvg_zones` -11. `bias_snapshots` -12. `trade_signals` -13. `trade_executions` -14. `backtest_runs` -15. `backtest_results` - ---- - -## 14. 建表顺序建议 - -### 第一阶段 - -- venues -- instruments -- candles -- market_sessions - -### 第二阶段 - -- swings -- dealing_ranges -- liquidity_pools - -### 第三阶段 - -- displacement_events -- structure_events -- fvg_zones - -### 第四阶段 - -- bias_snapshots -- trade_signals -- trade_executions - -### 第五阶段 - -- backtest_runs -- backtest_results - ---- - -## 15. 当前结论 - -Schema v1 的目标不是一次性穷尽全部 ICT 概念，而是先稳定支撑以下主链路： - -`Candles -> Sessions -> Swings -> Ranges -> Liquidity -> Sweep -> MSS -> FVG -> Signal -> Execution -> Backtest` - -后续开发中，所有新增字段和表都应优先服从这条主链路的一致性，不要为了术语完整性提前引入过多复杂实体。 diff --git a/docs/AI_ICT_Session_生成器规格书_v1.md b/docs/AI_ICT_Session_生成器规格书_v1.md deleted file mode 100644 index aa28e03..0000000 --- a/docs/AI_ICT_Session_生成器规格书_v1.md +++ /dev/null @@ -1,421 +0,0 @@ -# AI ICT Session 生成器规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 Session 生成器实现规格，用于把标准化后的 candles 数据转换为可供规则引擎使用的会话数据，并写入 `market_sessions` 表。 - -本模块是基础共享模块，位于： - -`Candles -> Sessions -> Swings -> Ranges` - -Session 生成器的输出会直接影响： - -- Asia high / low -- London high / low -- NY AM / Lunch / PM high / low -- session midpoint -- session-based liquidity pools -- 后续 bias 与 intraday 路径判断 - -因此，这个模块必须优先稳定。 - ---- - -## 2. 模块职责 - -Session 生成器只负责 4 件事： - -1. 把 UTC candles 映射到目标时区 -2. 按会话切分 candle 集合 -3. 计算会话 high / low / midpoint -4. 写入或更新 `market_sessions` - -本模块不负责： - -- swing 识别 -- liquidity pool 识别 -- sweep 判定 -- bias 输出 - -这些都属于下游模块。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -输入数据来自 `candles` 表，必须至少包含： - -- instrument_id -- timeframe -- ts_open -- ts_close -- open -- high -- low -- close - -说明： - -- Session 生成器第一阶段建议以 `1m` 或 `5m` candles 作为输入 -- 若数据粒度过大，会影响会话 high / low 精度 - ---- - -## 3.2 输出 - -输出写入 `market_sessions` 表，字段包括： - -- instrument_id -- session_date -- timezone -- session_code -- start_ts -- end_ts -- high -- low -- midpoint -- status -- meta - ---- - -## 4. 时区规则 - -## 4.1 标准存储规则 - -上游 `candles` 表中的时间统一按 UTC 存储。 - -Session 生成器运行时，必须： - -1. 先读取 UTC 时间 -2. 再转换到业务时区 -3. 按业务时区进行 session 切分 - -第一阶段业务时区固定： - -- `America/New_York` - ---- - -## 4.2 基本原则 - -- 数据库存 UTC -- 会话逻辑用纽约时间 -- 最终写回的 `start_ts` / `end_ts` 仍建议保存为 UTC 对应时刻 - -这样可以避免： - -- 本地机器时区污染 -- 夏令时处理混乱 -- 多环境运行结果不一致 - ---- - -## 5. 默认会话定义 - -第一阶段采用以下默认会话： - -- ASIA: 20:00 - 00:00 -- LONDON: 02:00 - 05:00 -- NY_AM: 09:30 - 11:00 -- NY_LUNCH: 12:00 - 13:00 -- NY_PM: 13:30 - 16:00 - -说明： - -- 以上时间均以 `America/New_York` 为准 -- 会话窗口必须配置化，不应硬编码散落在逻辑里 - -建议配置结构： - -```yaml -sessions: - timezone: America/New_York - items: - - code: ASIA - start: "20:00" - end: "00:00" - - code: LONDON - start: "02:00" - end: "05:00" - - code: NY_AM - start: "09:30" - end: "11:00" - - code: NY_LUNCH - start: "12:00" - end: "13:00" - - code: NY_PM - start: "13:30" - end: "16:00" -``` - ---- - -## 6. 会话日期归属规则 - -这是 Session 生成器中最容易错的地方。 - -## 6.1 基本定义 - -`session_date` 不是简单取 candle 的 UTC 日期，而是取 candle 在 `America/New_York` 下所属交易日的日期。 - ---- - -## 6.2 跨午夜会话处理 - -例如 ASIA: `20:00 - 00:00` - -该会话跨越自然日边界，因此必须先明确归属规则。 - -建议规则： - -- ASIA 会话归属到其起始日 -- 即纽约时间某日 20:00 开始到次日 00:00 结束的这段，统一记为该起始日的 ASIA 会话 - -例： - -- 2026-04-23 20:00 ~ 2026-04-24 00:00 -- `session_date = 2026-04-23` - -这样更方便后续和日内叙事对齐。 - ---- - -## 7. 切分逻辑 - -## 7.1 切分步骤 - -对于某个 `instrument_id + session_date`： - -1. 将候选 candles 转换为纽约时间 -2. 根据 session 配置匹配属于哪个 session -3. 汇总该 session 内所有 candles -4. 计算 high / low / midpoint -5. 生成 `market_sessions` 记录 - ---- - -## 7.2 Session high / low 计算 - -- high = 该 session 内所有 candle.high 的最大值 -- low = 该 session 内所有 candle.low 的最小值 -- midpoint = (high + low) / 2 - -要求： - -- midpoint 必须用 high / low 计算，不允许用 open / close 近似 - ---- - -## 7.3 会话状态 - -第一阶段建议支持以下状态： - -- open -- closed -- incomplete -- invalid - -含义： - -- open：当前会话尚未结束 -- closed：会话结束且数据完整 -- incomplete：会话结束但 candle 缺失 -- invalid：时间映射或数据异常导致不可用 - ---- - -## 8. 数据完整性检查 - -Session 生成器必须先检查输入 candles 是否足够完整。 - -## 8.1 最低检查项 - -- 时间窗口是否有 candle -- candle 是否连续 -- 是否存在重复 ts_open -- 是否存在明显缺口 - ---- - -## 8.2 缺口处理策略 - -第一阶段建议： - -### 若缺口很小 -- 允许写入 session -- 但标记 `status = incomplete` -- 在 `meta` 中记录缺口信息 - -### 若缺口严重 -- 不生成正式 session -- 或标记 `status = invalid` - -说明： - -- 不建议静默忽略缺口 -- 否则 session high / low 可能误导后续规则 - ---- - -## 8.3 重复数据处理 - -若发现同一 `instrument_id + timeframe + ts_open` 重复： - -- 视为上游数据问题 -- Session 生成器不负责去重修复 -- 但应记录错误并拒绝继续处理该窗口 - ---- - -## 9. 写入策略 - -## 9.1 幂等要求 - -对于同一个： - -- instrument_id -- session_date -- session_code -- timezone - -重复执行生成器时，不应产生重复记录。 - -建议： - -- 使用 upsert -- 若结果一致则更新 `updated_at` -- 若结果变化则更新 high / low / midpoint / status / meta - ---- - -## 9.2 更新场景 - -### 场景 A：会话仍在进行 -- 可周期性刷新 high / low -- `status = open` - -### 场景 B：会话已结束 -- 最终固化为 `status = closed` 或 `incomplete` - -### 场景 C：历史重算 -- 允许全量覆盖旧结果 -- 但必须保留 `updated_at` - ---- - -## 10. 下游依赖输出 - -Session 生成器完成后，下游至少应能直接使用： - -- Asia high / low -- London high / low -- NY_AM high / low -- NY_LUNCH high / low -- NY_PM high / low -- 各 session midpoint -- 当前会话状态 - -这些输出会被下游用于： - -- session-based liquidity pools -- session range 展示 -- intraday context -- time filter - ---- - -## 11. 推荐任务拆分 - -### T1. session 配置模块 -- timezone -- session window -- session_date 归属规则 - -### T2. 时间转换模块 -- UTC -> America/New_York -- 夏令时验证 - -### T3. 单会话切分逻辑 -- 给定 session_date + session_code -- 找出对应 candles - -### T4. 聚合逻辑 -- 计算 high / low / midpoint -- 生成状态 - -### T5. DB 写入逻辑 -- upsert `market_sessions` - -### T6. 校验逻辑 -- 缺口检测 -- 重复检测 -- incomplete / invalid 判定 - ---- - -## 12. 验证检查点 - -## 12.1 最低验证 - -至少验证以下内容： - -- [ ] ASIA 会话可生成 -- [ ] LONDON 会话可生成 -- [ ] NY_AM 会话可生成 -- [ ] NY_LUNCH 会话可生成 -- [ ] NY_PM 会话可生成 - ---- - -## 12.2 数值验证 - -每个 session 至少检查： - -- [ ] high >= low -- [ ] midpoint = (high + low) / 2 -- [ ] start_ts < end_ts -- [ ] session_code 正确 -- [ ] timezone 正确 - ---- - -## 12.3 样本人工抽查 - -至少抽查一个交易日： - -- [ ] session 起止时间正确 -- [ ] session high / low 与图表一致 -- [ ] ASIA 跨午夜归属正确 -- [ ] NY 时段未被本地系统时区污染 - ---- - -## 13. 完成标准 - -只有满足以下全部条件，Session 生成器模块才算完成： - -1. 能从 candles 正确生成 5 类 session -2. 支持纽约时区切分 -3. 支持跨午夜 session 归属 -4. 能检测不完整数据 -5. 能幂等写入 `market_sessions` -6. 可供下游 liquidity / context 模块直接使用 - ---- - -## 14. 当前结论 - -Session 生成器不是一个“简单聚合器”，而是日内结构语言的基础坐标系统。 - -只要这个模块出错，后续以下模块都会连锁失真： - -- liquidity pools -- sweep -- time filters -- daily bias -- intraday model - -因此在真实开发中，Session 生成器应被视为第一批必须严格验证的基础模块之一。 \ No newline at end of file diff --git a/docs/AI_ICT_Sweep_识别规格书_v1.md b/docs/AI_ICT_Sweep_识别规格书_v1.md deleted file mode 100644 index 1103db1..0000000 --- a/docs/AI_ICT_Sweep_识别规格书_v1.md +++ /dev/null @@ -1,479 +0,0 @@ -# AI ICT Sweep 识别规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 Sweep 识别规则，用于判断某一侧流动性池是否被价格清理，并为后续 displacement、MSS 和信号生成提供前置事件。 - -Sweep 模块位于以下链路中： - -`Candles -> Sessions -> Swings -> Dealing Range -> Liquidity Pools -> Sweep -> Displacement -> MSS` - -本模块输出将直接影响： - -- buy-side / sell-side pool 是否已被处理 -- 先清理后递送的结构判断 -- 是否存在 reversal / continuation 的前置条件 -- Displacement 是否具备更高解释力 -- Signal 是否进入候选链路 - -因此，Sweep 是“流动性事件层”的核心模块。 - ---- - -## 2. 模块职责 - -### 2.1 本模块负责 - -1. 检测价格是否刺穿某个 liquidity pool -2. 区分 sweep 与普通接触 / 突破 -3. 记录被处理的是 buy-side 还是 sell-side liquidity -4. 输出 weak / validated sweep 分层 -5. 写入 sweep 事件 - -### 2.2 本模块不负责 - -- Displacement 最终成立判定 -- MSS 成立判定 -- Daily Bias 判定 -- 目标优先级最终排序 - -这些属于下游模块。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -本模块依赖： - -- `candles` -- `liquidity_pools` -- timeframe -- pool 当前 status - -至少需要： - -- candle high / low / close -- pool side -- pool type -- pool price range -- pool status - ---- - -## 3.2 输出 - -建议输出对象 `SweepEvent`，并最终写入 sweep 事件表或事件流。 - -关键字段： - -- instrument_id -- timeframe -- side_swept -- pool_id -- sweep_high -- sweep_low -- sweep_ts -- close_back_inside -- displacement_after -- validation_level -- status -- meta - -其中： - -- `side_swept`: `buy_side | sell_side` -- `validation_level`: `weak | validated` -- `status`: `active | confirmed | cancelled` - ---- - -## 4. 基础定义 - -## 4.1 Sweep - -Sweep 指价格对某个流动性池发生了明显处理行为，通常表现为： - -1. 价格刺穿 pool -2. 价格未稳定站稳并继续同向递送 -3. 后续出现反向收回、位移或控制权切换迹象 - -说明： - -- Sweep 不是“摸到就算” -- Sweep 也不是“所有突破都算” -- 它是一个需要结合后续表现解释的流动性事件 - ---- - -## 4.2 Buy-Side Sweep - -当价格向上刺穿 buy-side liquidity pool 时，称为 buy-side sweep。 - -常见对象： - -- prior high -- equal highs -- session high - ---- - -## 4.3 Sell-Side Sweep - -当价格向下刺穿 sell-side liquidity pool 时，称为 sell-side sweep。 - -常见对象： - -- prior low -- equal lows -- session low - ---- - -## 5. 识别逻辑 - -## 5.1 基础刺穿条件 - -若 candle 的价格范围与某个 pool 发生以下关系： - -### 对 buy-side pool -- `candle.high > pool.price_high` - -### 对 sell-side pool -- `candle.low < pool.price_low` - -则视为发生了池子刺穿候选事件。 - -说明： - -- 这只是 sweep 候选，不代表 sweep 已成立 - ---- - -## 5.2 close back inside 条件 - -第一阶段建议增加一个重要辅助判断： - -### buy-side pool 被处理后 -若后续 close 回到 pool 内或回落到 pool 下方，则增强 sweep 解释力。 - -### sell-side pool 被处理后 -若后续 close 回到 pool 内或回升到 pool 上方，则增强 sweep 解释力。 - -该信号可记录为： - -- `close_back_inside = true | false` - ---- - -## 5.3 wick 与 close 的关系 - -第一阶段建议： - -### wick-only 刺穿 -- 可先记为 `weak sweep candidate` - -### wick 刺穿 + close 收回 -- 更接近有效 sweep - -### close 同向站稳并继续扩张 -- 更接近真实 breakout，而不是 sweep - -因此： - -- 不能只看 wick -- 也不能只看单根 close -- 需要结合后续几根 candle 的行为 - ---- - -## 6. validation 分层 - -第一阶段建议 Sweep 至少分两级： - -- weak -- validated - ---- - -## 6.1 weak sweep - -满足： - -1. pool 被刺穿 -2. 但尚未看到更强反向证据 - -适用场景： - -- 先作为候选事件挂起 -- 等待 displacement 或后续结构确认 - ---- - -## 6.2 validated sweep - -满足： - -1. 已刺穿 pool -2. 出现 close back inside 或明显回收 -3. 后续 N 根内出现反向 displacement 候选 - -说明： - -- 第一阶段 validated sweep 不必直接等于反转 -- 它只代表“这个流动性事件的解释力更强” - ---- - -## 7. breakout 与 sweep 的区分 - -这是最重要的边界之一。 - -## 7.1 更接近 breakout 的情况 - -若出现以下特征： - -1. 价格刺穿 pool 后继续同向稳定推进 -2. close 连续站在 pool 外侧 -3. 没有明显回收或反向位移 - -则应更倾向解释为 breakout，而不是 sweep。 - ---- - -## 7.2 更接近 sweep 的情况 - -若出现以下特征： - -1. pool 被刺穿 -2. 价格快速回收 -3. 后续出现反向 displacement -4. 原刺穿方向没有继续稳定扩张 - -则更应解释为 sweep。 - ---- - -## 8. 时间窗口规则 - -## 8.1 后续确认窗口 - -Sweep 不是永远挂起等待。 - -第一阶段建议为每个 sweep candidate 设置观察窗口： - -- 在刺穿后的 N 根 candle 内观察是否出现回收和反向证据 - -若窗口结束仍没有强化证据： - -- 可保持 weak -- 或降级为无效候选 - -N 应配置化，按 timeframe 设置。 - ---- - -## 8.2 会话影响 - -Session 信息可作为解释增强因子，但第一阶段不让 session 直接决定 sweep 成败。 - -建议： - -- 先基于价格行为判 sweep -- 再由下游 bias / context 模块结合 session 增强解释 - ---- - -## 9. Pool 状态联动 - -Sweep 模块成立后，必须联动更新对应 pool 的状态。 - -### 9.1 基础联动 - -若 sweep 已确认： - -- 对应 pool `status -> swept` - -### 9.2 后续处理 - -若下游确认该 pool 已不再具备主要参考价值： - -- 后续模块可将其更新为 `consumed` - -说明： - -- Sweep 模块只负责把 untouched 更新为 swept -- consumed 更适合下游结构模块决定 - ---- - -## 10. 边界与异常处理 - -## 10.1 一个 candle 同时触达多个 pool - -若单根 candle 同时刺穿多个 pool： - -- 允许生成多个 sweep candidate -- 但必须通过 `pool_id` 区分来源 -- 不可合并成一个模糊事件 - ---- - -## 10.2 pool 已 swept - -若 pool 已经是 `swept`： - -- 默认不应重复生成同一主要 sweep 事件 -- 除非系统明确支持重复处理逻辑 - -第一阶段建议： - -- 同一 pool 只保留首次主要 sweep - ---- - -## 10.3 数据缺口 - -若刺穿区间附近存在 candle 缺失： - -- 可生成候选事件 -- 但应在 `meta` 中标记数据不完整 -- 不建议直接升为 validated - ---- - -## 10.4 未确认 pool - -若 pool 来源不稳定或 session 本身不完整： - -- 该 sweep 不应提升为高可信级别 - ---- - -## 11. 写入策略 - -## 11.1 幂等要求 - -同一 pool 在同一主要处理事件下： - -- 不应重复生成多个 identical sweep 记录 - -建议幂等判定参考： - -- instrument_id -- timeframe -- pool_id -- sweep_ts 所在主事件窗口 - ---- - -## 11.2 状态建议 - -第一阶段 sweep 事件建议状态： - -- active -- confirmed -- cancelled - -含义： - -- active：候选事件已出现，等待进一步确认 -- confirmed：已达到 validated 标准 -- cancelled：后续走势表明不应继续保留为有效 sweep 事件 - ---- - -## 12. 下游依赖约定 - -Sweep 输出将被下游这样使用： - -### Displacement -- 判断反向位移是否具有前置清理背景 - -### MSS -- 判断结构切换前是否有流动性事件 - -### Signal -- 判断是否满足“先清理，后递送”的路径逻辑 - -因此 Sweep 必须稳定输出： - -- 哪一侧被处理 -- 处理的是哪个 pool -- 是否回收 -- 是否被验证 - ---- - -## 13. 推荐任务拆分 - -### T1. pool 刺穿检测 -- candle 与 pool 的交互检测 - -### T2. close back inside 检测 -- 记录回收行为 - -### T3. validated 规则 -- 结合后续 displacement 候选 - -### T4. pool 状态联动 -- untouched -> swept - -### T5. 幂等入库 -- 避免同一事件重复写入 - ---- - -## 14. 验证检查点 - -## 14.1 最低验证 - -至少验证： - -- [ ] buy-side pool 刺穿可生成 sweep candidate -- [ ] sell-side pool 刺穿可生成 sweep candidate -- [ ] close back inside 可正确记录 -- [ ] validated sweep 可生成 - ---- - -## 14.2 行为验证 - -- [ ] wick-only 刺穿不会自动当作 confirmed sweep -- [ ] 持续同向扩张不会被误判为 validated sweep -- [ ] pool 状态会从 untouched 更新到 swept - ---- - -## 14.3 人工抽查 - -至少抽取样本图表检查： - -- [ ] buy-side sweep 标记合理 -- [ ] sell-side sweep 标记合理 -- [ ] breakout 与 sweep 未明显混淆 -- [ ] validated 逻辑与后续走势一致性较高 - ---- - -## 15. 完成标准 - -只有满足以下全部条件，Sweep 模块才算完成： - -1. 能识别 buy-side / sell-side pool 刺穿 -2. 能区分 weak / validated -3. 能记录 close back inside -4. 能联动更新 pool 状态 -5. 能幂等写入 sweep 事件 -6. 可直接供 displacement / MSS 模块使用 - ---- - -## 16. 当前结论 - -Sweep 模块是把“流动性目标”转换为“已发生处理事件”的桥梁层。 - -如果 Liquidity Pool 是待处理目标集合，那么 Sweep 就是市场是否已经开始处理这些目标的事件表达。 - -在真实开发中，它应被视为进入 displacement 和 MSS 前必须稳定完成的关键事件模块。 \ No newline at end of file diff --git a/docs/AI_ICT_Swing_识别规格书_v1.md b/docs/AI_ICT_Swing_识别规格书_v1.md deleted file mode 100644 index 779b5b9..0000000 --- a/docs/AI_ICT_Swing_识别规格书_v1.md +++ /dev/null @@ -1,494 +0,0 @@ -# AI ICT Swing 识别规格书 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的 Swing 识别规则，用于从标准化 candles 数据中提取结构高低点，为后续模块提供基础锚点。 - -Swing 模块是以下链路中的关键基础层： - -`Candles -> Sessions -> Swings -> Dealing Range -> Liquidity -> MSS` - -下游直接依赖 Swing 的模块包括： - -- Dealing Range -- Prior High / Prior Low -- Equal Highs / Equal Lows -- MSB / MSS -- IRL / ERL 目标定位 - -因此，Swing 模块必须首先做到： - -- 输出稳定 -- 参数明确 -- 多周期一致 -- 可验证、可回放 - ---- - -## 2. 模块职责 - -Swing 模块只负责识别结构高低点，不负责解释结构意义。 - -### 2.1 本模块负责 - -1. 识别 swing high -2. 识别 swing low -3. 给出 confirmed / provisional 状态 -4. 给出 ST / IT / LT 强度层级 -5. 写入 `swings` 表 - -### 2.2 本模块不负责 - -- bias 判断 -- Dealing Range 计算 -- liquidity pool 生成 -- sweep 判定 -- MSS 判定 - -这些都由下游模块处理。 - ---- - -## 3. 输入与输出 - -## 3.1 输入 - -输入来自 `candles` 表，至少包含： - -- instrument_id -- timeframe -- ts_open -- ts_close -- open -- high -- low -- close - -说明： - -- Swing 模块按 timeframe 分开运行 -- 不同 timeframe 的 swing 不能混算 - ---- - -## 3.2 输出 - -输出写入 `swings` 表，字段包括： - -- instrument_id -- timeframe -- kind -- strength -- price -- ts -- left_bars -- right_bars -- confirmed -- meta - -其中： - -- `kind`: `swing_high | swing_low` -- `strength`: `ST | IT | LT` - ---- - -## 4. 基础定义 - -## 4.1 swing high - -在指定窗口下，某根 candle 的高点高于左侧与右侧指定数量 candles 的高点，则该点可定义为 swing high。 - ---- - -## 4.2 swing low - -在指定窗口下，某根 candle 的低点低于左侧与右侧指定数量 candles 的低点，则该点可定义为 swing low。 - ---- - -## 4.3 confirmed swing - -只有当右侧确认 candles 足够后，swing 才可标记为 confirmed。 - -这意味着： - -- swing 是滞后确认的 -- 最新几根 candle 附近的结构点通常只能先标 provisional - ---- - -## 4.4 provisional swing - -若左侧条件已满足，但右侧确认尚未结束，则可以先生成 provisional swing，仅用于实时观察，不作为严格回测真值。 - ---- - -## 5. 参数化规则 - -## 5.1 基本参数 - -Swing 识别至少需要两个参数： - -- `left_bars` -- `right_bars` - -定义： - -- `left_bars`: 左侧比较窗口 -- `right_bars`: 右侧确认窗口 - ---- - -## 5.2 第一阶段建议参数 - -### M1 / M5 -- left_bars = 2 -- right_bars = 2 - -### M15 / H1 -- left_bars = 3 -- right_bars = 3 - -### H4 / D -- left_bars = 3 -- right_bars = 3 - -说明： - -- 这是 MVP 默认值，不是永久值 -- 后续可按品种波动差异调整 -- 第一阶段先固定，避免回测口径漂移 - ---- - -## 6. 判定逻辑 - -## 6.1 swing high 判定逻辑 - -对于第 i 根 candle： - -若满足： - -- `high[i] > high[i-1..i-left_bars]` -- `high[i] > high[i+1..i+right_bars]` - -则判定为 swing high。 - -### 等值情况处理 - -若出现高点相等： - -- 第一阶段建议不直接视为 swing high -- 优先交给 equal highs / liquidity 模块处理 - -即： - -- 使用严格大于 `>` -- 不使用大于等于 `>=` - ---- - -## 6.2 swing low 判定逻辑 - -对于第 i 根 candle： - -若满足： - -- `low[i] < low[i-1..i-left_bars]` -- `low[i] < low[i+1..i+right_bars]` - -则判定为 swing low。 - -### 等值情况处理 - -若出现低点相等： - -- 第一阶段建议不直接视为 swing low -- 优先交给 equal lows 模块处理 - -即： - -- 使用严格小于 `<` -- 不使用小于等于 `<=` - ---- - -## 7. 强度分层规则 - -Swing 不是只有一个层级，需要支持： - -- ST：short-term -- IT：intermediate-term -- LT：long-term - ---- - -## 7.1 ST 定义 - -ST 是基础层 swing，由窗口参数直接识别得到。 - -第一阶段建议： - -- 所有原始识别结果默认先标为 ST - ---- - -## 7.2 IT 定义 - -IT swing 由 ST swing 再聚合识别得到。 - -建议规则： - -- 若一个 ST swing high 高于其邻近 ST swing highs，则可提升为 IT swing high -- 若一个 ST swing low 低于其邻近 ST swing lows，则可提升为 IT swing low - -说明： - -- IT 不直接从 candles 识别 -- IT 来自 ST 的二次结构提炼 - ---- - -## 7.3 LT 定义 - -LT swing 由 IT swing 再聚合识别得到。 - -建议规则： - -- 若一个 IT swing high 高于其邻近 IT swing highs，则可提升为 LT swing high -- 若一个 IT swing low 低于其邻近 IT swing lows，则可提升为 LT swing low - -说明： - -- LT 用于高阶结构，不要求第一阶段就做到极致复杂 -- MVP 阶段可先实现 ST，IT/LT 可做简化版 - ---- - -## 8. 时间确认规则 - -## 8.1 为什么 swing 必然滞后 - -因为 swing 的成立依赖右侧 candles。 - -所以： - -- 实时运行时，当前附近结构会持续变化 -- 回测时必须只用 confirmed swing -- 不允许用未来数据提前宣布 swing 成立 - ---- - -## 8.2 实时模式建议 - -实时运行时： - -- 可输出 provisional swing -- 但必须显式标记 `confirmed=false` -- 下游严格信号模块默认应只使用 confirmed swing - ---- - -## 8.3 历史模式建议 - -历史回测时： - -- 只写 confirmed swing -- 不将 provisional swing 作为真值结果 - ---- - -## 9. 边界与异常处理 - -## 9.1 序列开头与结尾 - -在 candle 序列开头： - -- 左侧数据不足，不应判定 swing - -在 candle 序列末尾： - -- 右侧确认不足，可最多只标 provisional - ---- - -## 9.2 数据缺口 - -若窗口内存在缺失 candle： - -- 第一阶段建议不输出 confirmed swing -- 或在 `meta` 中记录不完整窗口 - -否则会误判局部高低点。 - ---- - -## 9.3 重复时间点 - -若同一 `instrument_id + timeframe + ts_open` 出现重复： - -- 视为上游数据异常 -- Swing 模块不负责修复 -- 应拒绝本轮计算并记录错误 - ---- - -## 9.4 极端长影线 - -第一阶段 swing 判定只基于 high / low，不单独过滤长影线。 - -说明： - -- 长影线是否有流动性意义，是下游 liquidity / sweep 模块的职责 -- Swing 模块只负责结构锚点抽取 - ---- - -## 10. 写入策略 - -## 10.1 幂等要求 - -同一批数据重复计算时： - -- 不应生成重复 swing 记录 -- 已存在相同关键结果时应跳过或更新 - -建议唯一逻辑键： - -- instrument_id -- timeframe -- kind -- price -- ts -- strength - -第一阶段也可先用应用层幂等控制。 - ---- - -## 10.2 更新策略 - -### 历史重算 -- 允许按 timeframe 全量重算 -- 再覆盖该时间窗口内旧结果 - -### 增量运行 -- 仅重算最近一段窗口 -- 防止每次都全量扫描 - -建议重算窗口至少覆盖： - -- `right_bars * 2 + 额外缓冲` - ---- - -## 11. 下游依赖约定 - -Swing 输出会被下游这样使用： - -### Dealing Range -- 取最近有效 swing high / low 形成 range - -### Liquidity Pools -- prior highs / lows -- equal highs / lows 候选 - -### Structure Events -- MSB / MSS 破坏对象 - -### Targets -- IRL / ERL 候选目标 - -因此要求： - -- ts 清晰 -- kind 清晰 -- strength 清晰 -- confirmed 清晰 - ---- - -## 12. 推荐任务拆分 - -### T1. ST swing 识别 -- 按 timeframe 对 candles 扫描 -- 生成 provisional / confirmed swing - -### T2. Swing 入库 -- 写入 `swings` -- 做幂等控制 - -### T3. 增量重算窗口 -- 最近窗口重算逻辑 - -### T4. IT / LT 提升逻辑 -- 从 ST -> IT -- 从 IT -> LT - -### T5. 数据完整性防护 -- 缺口检测 -- 重复数据拒绝 - ---- - -## 13. 验证检查点 - -## 13.1 最低验证 - -至少验证： - -- [ ] M5 可生成 swing highs -- [ ] M5 可生成 swing lows -- [ ] M15 可生成 swing highs -- [ ] M15 可生成 swing lows -- [ ] confirmed / provisional 状态可区分 - ---- - -## 13.2 结构验证 - -至少检查： - -- [ ] 相邻 swing 时间顺序正确 -- [ ] swing high 的 price 来自 candle high -- [ ] swing low 的 price 来自 candle low -- [ ] confirmed swing 不使用未来数据作弊 - ---- - -## 13.3 人工抽查 - -至少随机抽取一段图表： - -- [ ] 样本内 swing high / low 与肉眼结构大致一致 -- [ ] 边界窗口未误报 -- [ ] 等高等低未被错误吞并 - ---- - -## 14. 完成标准 - -只有满足以下全部条件，Swing 模块才算完成： - -1. 支持按 timeframe 识别 swing high / low -2. 支持 confirmed / provisional 区分 -3. 支持 ST 基础层识别 -4. 支持幂等写入 `swings` -5. 至少完成一轮样本人工抽查 -6. 可直接供 range 与 liquidity 模块使用 - ---- - -## 15. 当前结论 - -Swing 模块不是简单找高点低点，而是整个结构语言的最底层锚点系统。 - -如果这个模块不稳定，后续会同时影响： - -- dealing range -- liquidity pool -- MSB / MSS -- targets - -因此在真实开发中，Swing 应与 Candles、Sessions 一起被视为第一批必须稳定的基础模块。 \ No newline at end of file diff --git a/docs/AI_ICT_Training_Case_Engine_外部产品化MVP计划_v1.md b/docs/AI_ICT_Training_Case_Engine_外部产品化MVP计划_v1.md deleted file mode 100644 index 3e79527..0000000 --- a/docs/AI_ICT_Training_Case_Engine_外部产品化MVP计划_v1.md +++ /dev/null @@ -1,671 +0,0 @@ -# AI ICT Training Case Engine 外部产品化 MVP 计划 v1 - -## 1. 产品定位 - -Training Case Engine 是 AI Exchange 的对外产品模块，定位为基于真实市场数据和 ICT 规则识别的训练、标注、评分、复盘系统。 - -核心定位： - -```text -AI ICT Trading Engine = 真实市场数据与规则识别基础设施 -Training Case Engine = 面向外部用户的训练产品与成长系统 -``` - -第一阶段不是做完整教育平台，而是先做一个可真实使用的训练 MVP： - -```text -真实 K 线 -> 自动生成案例 -> 隐藏未来回放 -> 用户标注/答题 -> 规则评分 -> 薄弱点反馈 -``` - -必须坚持的产品边界： - -1. Training Case Engine 可以读取真实市场数据和规则事件。 -2. Training Case Engine 的用户行为、标注、评分、进度只写入训练域。 -3. 训练数据与实盘、信号、执行严格隔离。 -4. 训练结果不得直接驱动真实下单、信号生成或执行策略。 - -## 2. 目标用户与使用场景 - -### 2.1 目标用户 - -MVP 面向： - -1. 正在学习 ICT/SMC 交易框架的外部用户。 -2. 需要反复训练结构识别、流动性判断、入场区域判断的交易学习者。 -3. 需要用真实市场案例建立纪律和复盘习惯的用户。 -4. 后续可能接入课程、训练营、教练服务的学员。 - -### 2.2 核心使用场景 - -第一阶段聚焦： - -1. 用户选择一个训练主题。 -2. 系统展示隐藏未来的历史 K 线片段。 -3. 用户逐根推进并做标注或选择。 -4. 用户提交答案。 -5. 系统给出分项评分和标准答案。 -6. 系统记录用户弱点并推荐后续训练方向。 - -## 3. MVP 范围 - -### 3.1 必做能力 - -MVP 必须覆盖： - -1. 案例库：从真实市场事件生成训练案例。 -2. 回放：按 `decision_ts` 隐藏未来，支持逐根推进。 -3. 标注：支持 Range、Draw、FVG、Invalidation 等基础标注。 -4. 答题：支持选择题、判断题、简短文本。 -5. 评分：基于规则评分，输出分项得分。 -6. 反馈：展示 answer_key、得分、错误类型与薄弱点。 -7. 进度：按 skill_tag 记录尝试次数、平均分、弱点标签。 -8. Training Lab：提供完整训练流程的前端页面。 - -### 3.2 首批训练题型 - -MVP 首批题型： - -1. `Dealing Range` 标注题。 -2. `Premium / Discount / Equilibrium` 位置判断题。 -3. `Liquidity Pool` 主次目标判断题。 -4. `Sweep` 真假识别题。 -5. `MSS + Displacement` 结构接管题。 -6. `FVG` 入场区域与失效判断题。 - -### 3.3 暂不纳入 MVP - -MVP 暂不做： - -1. 复杂账户系统。 -2. 付费订阅和订单系统。 -3. 多人课堂。 -4. 老师批改后台。 -5. 真实下单训练。 -6. 跟单或信号订阅。 -7. AI 自动主判。 -8. 用户训练结果驱动交易策略。 - -## 4. 数据隔离与安全边界 - -这是本模块的最高优先级约束。 - -### 4.1 数据流向 - -允许的数据流： - -```text -market candles -> training case generation -ICT rule events -> training case generation -backtest summaries -> training case context -training attempts -> training scoring -training scores -> training progress -``` - -禁止的数据流： - -```text -training annotations -> trade_signals -training scores -> trade_executions -training progress -> live execution -training feedback -> account/order state -``` - -### 4.2 表级隔离 - -Training MVP 只写训练相关表： - -```text -training_cases -training_case_tasks -training_attempts -training_annotations -training_scores -training_progress -``` - -禁止写入： - -```text -trade_signals -trade_executions -orders -account_balances -execution_logs -live_strategy_state -``` - -如果某些表名在当前项目中不同，以实际交易信号、执行、订单、账户资金相关表为准。 - -### 4.3 服务边界 - -Training 服务可以调用只读查询： - -1. candles 查询。 -2. ICT rule events 查询。 -3. backtest summary 查询。 - -Training 服务不得调用： - -1. 下单服务。 -2. execution service。 -3. live signal writer。 -4. 账户资金修改接口。 -5. 任何会触发真实交易的适配器。 - -## 5. 用户流程 - -### 5.1 首次进入 Training Lab - -流程： - -```text -进入 Training Lab --> 选择训练主题 --> 选择难度或默认推荐 --> 打开训练案例 --> 查看任务说明 --> 开始回放 -``` - -页面需要呈现： - -1. 当前训练主题。 -2. 案例难度。 -3. 任务目标。 -4. K 线图。 -5. 答题和标注工具。 -6. 提交入口。 - -### 5.2 单个案例训练流程 - -流程： - -```text -打开 case --> 创建 attempt --> 只显示 decision_ts 之前的 candles --> 用户逐根推进 --> 用户标注或答题 --> 用户提交 --> 系统评分 --> 展示 feedback 和 answer_key --> 更新 progress -``` - -关键要求： - -1. 提交前不得提前暴露标准答案。 -2. 回放不得提前暴露未来 K 线。 -3. 评分必须可解释，至少给出分项得分。 -4. 训练结果只影响 Training progress。 - -### 5.3 复盘与成长流程 - -流程： - -```text -完成多个 attempts --> 汇总 skill_tag 表现 --> 识别 weakness_tags --> 推荐下一组案例 --> 用户继续训练 -``` - -MVP 可以先用简单规则推荐： - -1. 平均分最低的 skill_tag 优先。 -2. 最近错误最多的 case_type 优先。 -3. attempt_count 过少的基础能力优先。 - -## 6. 核心实体 - -### 6.1 training_cases - -用途：保存一个可训练的市场案例。 - -关键字段： - -```text -id -instrument_id -timeframe -case_type -chapter_ref -skill_tags -source_event_type -source_event_id -window_start_ts -decision_ts -window_end_ts -difficulty -answer_key jsonb -status -meta jsonb -``` - -要求： - -1. `decision_ts` 是隐藏未来的边界。 -2. `answer_key` 只在提交后或显式显示答案时返回给前端。 -3. `source_event_type/source_event_id` 用于追溯真实市场来源。 - -### 6.2 training_case_tasks - -用途：保存一个案例下的任务。 - -关键字段： - -```text -id -case_id -task_type -prompt -required_annotation_types -max_score -sort_order -meta jsonb -``` - -要求： - -1. 一个 case 可以包含多个 task。 -2. task 应对应明确技能点。 -3. 评分服务应能按 task 输出分项结果。 - -### 6.3 training_attempts - -用途：保存用户一次训练尝试。 - -关键字段： - -```text -id -case_id -user_id -status -current_frame_index -started_ts -submitted_ts -total_score -meta jsonb -``` - -MVP 可先使用本地用户： - -```text -user_id = "local" -``` - -后续接入正式账号系统时再迁移到真实用户 ID。 - -### 6.4 training_annotations - -用途：保存用户标注。 - -关键字段： - -```text -id -attempt_id -annotation_type -payload jsonb -created_ts -``` - -常见类型： - -```text -dealing_range -equilibrium -draw -liquidity_pool -fvg -mss -invalidation -tp_sl -multiple_choice -free_text -``` - -要求： - -1. payload 必须有基础结构校验。 -2. 坐标、时间、价格必须可被评分服务读取。 -3. 标注只属于 training attempt。 - -### 6.5 training_scores - -用途：保存分项得分和反馈。 - -关键字段： - -```text -id -attempt_id -category -score -max_score -feedback jsonb -``` - -要求： - -1. 分项得分可解释。 -2. feedback 可以包含错误类型、正确答案引用、改进建议。 -3. AI 后续可用于解释增强，但 MVP 不作为主评分裁判。 - -### 6.6 training_progress - -用途：保存用户能力成长统计。 - -关键字段： - -```text -id -user_id -skill_tag -attempt_count -avg_score -last_attempt_ts -weakness_tags jsonb -meta jsonb -``` - -要求： - -1. progress 来源于 training attempts 和 training scores。 -2. progress 不写入交易策略、信号或执行域。 -3. progress 可以用于训练推荐。 - -## 7. API 分期 - -### 7.1 API M1：案例浏览与生成 - -接口： - -```text -GET /training/cases -GET /training/cases/{id} -POST /training/cases/generate -``` - -目标： - -1. 能列出训练案例。 -2. 能查看单个案例元数据。 -3. 能从真实事件生成案例。 - -验收： - -1. 列表支持 `case_type`、`difficulty`、`skill_tag` 过滤。 -2. 未提交 attempt 前，接口不返回完整 `answer_key`。 -3. 生成案例不会写入交易主链路。 - -### 7.2 API M2：Attempt 与回放 - -接口： - -```text -POST /training/attempts -GET /training/attempts/{id} -POST /training/attempts/{id}/advance -POST /training/attempts/{id}/reset -``` - -目标： - -1. 创建一次训练尝试。 -2. 返回当前可见 K 线。 -3. 支持逐根推进、推进 5 根、重置。 - -验收： - -1. `decision_ts` 后的未来数据不会提前返回。 -2. `current_frame_index` 与实际返回 candles 一致。 -3. reset 后回到初始可见状态。 - -### 7.3 API M3：标注与提交 - -接口： - -```text -POST /training/attempts/{id}/annotations -GET /training/attempts/{id}/annotations -POST /training/attempts/{id}/submit -``` - -目标： - -1. 保存用户标注。 -2. 支持提交评分。 -3. 锁定已提交 attempt。 - -验收： - -1. 支持 Range、Draw、FVG、Invalidation 基础标注。 -2. annotation payload 校验失败时返回明确错误。 -3. submitted attempt 不允许随意覆盖答案。 - -### 7.4 API M4：评分与进度 - -接口： - -```text -GET /training/attempts/{id}/score -GET /training/progress -GET /training/recommendations -``` - -目标： - -1. 返回总分和分项得分。 -2. 汇总用户弱点。 -3. 推荐下一组训练案例。 - -验收： - -1. Sweep / FVG / Range 至少三类题可评分。 -2. progress 按 skill_tag 汇总。 -3. recommendation 不依赖交易执行结果。 - -## 8. 前端 Training Lab 分期 - -### 8.1 Frontend M1：案例列表与训练入口 - -页面能力： - -1. 显示训练案例列表。 -2. 支持按题型和难度筛选。 -3. 进入单个训练案例。 - -验收： - -1. 用户能从列表进入训练页面。 -2. 空状态、加载状态、错误状态清晰。 -3. 不展示未授权的答案内容。 - -### 8.2 Frontend M2：回放视图 - -页面能力： - -1. 显示 K 线回放图。 -2. 支持下一根、推进 5 根、重置。 -3. 显示当前任务说明。 - -验收： - -1. 回放进度与 API 返回一致。 -2. 图表不会显示未来数据。 -3. 提交前不暴露 answer_key。 - -### 8.3 Frontend M3：标注工具与答题 - -页面能力： - -1. 标注 Range。 -2. 标注 Draw。 -3. 标注 FVG。 -4. 标注 Invalidation。 -5. 完成选择题、判断题、简短文本。 - -验收： - -1. 标注 payload 能成功提交。 -2. 用户能编辑未提交的标注。 -3. 提交后状态锁定或明确提示不可修改。 - -### 8.4 Frontend M4：评分反馈与复盘 - -页面能力： - -1. 展示总分。 -2. 展示分项得分。 -3. 展示标准答案。 -4. 展示错误类型和改进建议。 - -验收： - -1. 用户提交后能看到完整评分。 -2. 标准答案只在提交后显示。 -3. 评分反馈能对应用户标注。 - -### 8.5 Frontend M5：Progress 面板 - -页面能力： - -1. 展示 skill_tag 平均分。 -2. 展示尝试次数。 -3. 展示薄弱项。 -4. 展示推荐训练。 - -验收： - -1. 至少能展示 Range、Sweep、FVG 三类能力表现。 -2. 用户能从推荐进入下一题。 -3. 进度数据只来自训练域。 - -## 9. 验收标准 - -### 9.1 MVP 功能验收 - -MVP 完成时必须满足： - -1. 能从真实市场数据生成至少 30 个训练案例。 -2. 至少支持 Sweep、FVG、Range 三类题完整闭环。 -3. 每个案例有 `window_start_ts`、`decision_ts`、`window_end_ts`。 -4. 回放严格隐藏未来。 -5. 用户能完成基础标注并提交。 -6. 系统能返回总分、分项得分和反馈。 -7. 用户 progress 能统计 skill_tag 表现。 -8. Training Lab 能完成从选题到复盘的完整流程。 - -### 9.2 隔离验收 - -必须通过： - -1. Training 写入仅限训练相关表。 -2. Training 服务不调用下单、执行、信号写入接口。 -3. 提交训练答案不会改变 trade_signals。 -4. 提交训练答案不会产生 trade_executions。 -5. 训练评分不会改变 backtest_results。 -6. 前端不会把 answer_key 提前暴露给未提交用户。 - -### 9.3 质量验收 - -必须通过： - -1. 相关单元测试通过。 -2. API 流程测试覆盖 create attempt、advance、annotation、submit、score。 -3. 至少有防未来函数测试。 -4. 至少有训练数据不污染交易主链路的回归测试。 -5. 文档与实现一致。 - -## 10. 风险 - -### 10.1 未来函数风险 - -风险：训练回放提前暴露 `decision_ts` 后的 K 线或答案。 - -控制： - -1. replay service 统一裁剪可见 candles。 -2. API 层不直接返回完整窗口数据。 -3. 测试覆盖边界时间点。 - -### 10.2 交易主链路污染风险 - -风险：训练标注、评分或用户偏好反向影响信号、回测或执行。 - -控制： - -1. 表级隔离。 -2. service 层隔离。 -3. API 路由隔离。 -4. 写入权限隔离。 -5. qishu 对跨域调用单独审查。 - -### 10.3 评分可信度风险 - -风险：规则评分过于粗糙，用户不认可。 - -控制： - -1. MVP 先覆盖客观标注类题型。 -2. 分项评分透明展示。 -3. AI 只做解释增强，不做主判。 -4. 保留人工精选案例和标准答案修订能力。 - -### 10.4 产品范围膨胀风险 - -风险：过早加入账户、付费、课堂、AI 教练，拖慢训练闭环。 - -控制： - -1. MVP 只做训练闭环。 -2. 外部产品化架构先留扩展点。 -3. 复杂商业化功能进入后续阶段。 - -### 10.5 数据质量风险 - -风险：自动生成案例质量不稳定，训练体验受影响。 - -控制： - -1. case status 支持 draft/reviewed/published。 -2. 先生成候选案例，再筛选发布。 -3. 保留人工精选和下架能力。 - -## 11. 非目标 - -MVP 非目标： - -1. 不做真实下单训练。 -2. 不做交易信号订阅产品。 -3. 不做用户训练结果自动调参。 -4. 不做复杂课程 CMS。 -5. 不做老师批改后台。 -6. 不做多人实时课堂。 -7. 不做资金账户接入。 -8. 不做 AI 主导评分裁判。 -9. 不把训练数据写回实盘、信号或执行系统。 - -## 12. 推荐阶段计划 - -建议按以下阶段推进： - -```text -M1: training tables + repository -M2: case generator for Sweep/FVG/Range -M3: replay API with no-future guarantee -M4: annotations + submit -M5: rule-based grading -M6: Training Lab MVP -M7: progress and recommendations -``` - -每个阶段由 Codex 落地后，qishu 审查： - -1. 是否符合产品定位。 -2. 是否通过质量门禁。 -3. 是否保持训练域与交易域隔离。 -4. 是否可以形成独立 Git commit。 diff --git a/docs/AI_ICT_Training_Case_Engine_开发方案_v1.md b/docs/AI_ICT_Training_Case_Engine_开发方案_v1.md deleted file mode 100644 index a9414c9..0000000 --- a/docs/AI_ICT_Training_Case_Engine_开发方案_v1.md +++ /dev/null @@ -1,612 +0,0 @@ -# AI ICT Training Case Engine 开发方案 v1 - -## 1. 方案结论 - -在 `/Users/yuqei/AI Exchange` 内新增独立 `Training` 模块，复用现有 OKX 数据、ICT 规则识别、Replay、Backtest，但训练数据与实盘、信号、执行严格隔离。 - -开发目标不是先做大而全，而是先做一个能真实跑通的 MVP： - -```text -真实 K 线 -> 自动生成训练案例 -> 隐藏未来回放 -> 用户标注/答题 -> 系统评分 -> 形成薄弱点 -``` - -核心产品定位： - -```text -AI Exchange = 真实市场数据与规则识别引擎 -Training Case Engine = 学习、标注、评分、复盘、成长系统 -``` - -## 2. 总体架构 - -新增模块边界： - -```text -AI Exchange -├─ market/rule engine 现有：OKX、candles、sessions、swings、ranges、liquidity、sweep、MSS、FVG -├─ trading engine 现有：bias、signals、backtest、execution、reports -└─ training engine 新增：case generation、replay、annotation、grading、progress -``` - -核心依赖规则： - -```text -现有交易数据/规则 -> Training 只读消费 -Training 用户行为 -> 不反向影响 signals / executions / backtest -``` - -训练系统可以读取 `candles`、`sweep_events`、`fvg_zones`、`structure_events`、`backtest_results` 等数据，但不能污染交易主链路。 - -## 3. 第一阶段 MVP 范围 - -第一版只做 6 类训练题，覆盖书中最重要的基础能力： - -1. `Dealing Range` 标注题 -2. `Premium / Discount / Equilibrium` 位置判断题 -3. `Liquidity Pool` 主次目标判断题 -4. `Sweep` 真假识别题 -5. `MSS + Displacement` 结构接管题 -6. `FVG` 入场区域与失效判断题 - -第一阶段暂不做： - -1. 复杂账户系统 -2. 多人课堂 -3. 真实下单训练 -4. 付费体系 -5. 大型用户权限系统 - -## 4. 数据库新增表 - -建议新增 migration，表名： - -```text -training_cases -training_case_tasks -training_attempts -training_annotations -training_scores -training_progress -``` - -### 4.1 training_cases - -核心字段： - -```text -id -instrument_id -timeframe -case_type -chapter_ref -skill_tags -source_event_type -source_event_id -window_start_ts -decision_ts -window_end_ts -difficulty -answer_key jsonb -status -meta jsonb -``` - -说明： - -- `case_type` 用于区分 `range`、`premium_discount`、`liquidity_pool`、`sweep`、`mss_displacement`、`fvg`。 -- `chapter_ref` 用于绑定书中章节，例如 `chapter_02`、`chapter_10`。 -- `decision_ts` 是隐藏未来的关键时间点。 -- `answer_key` 保存标准答案或规则答案。 -- `source_event_type/source_event_id` 追溯案例来自哪个真实市场事件。 - -### 4.2 training_case_tasks - -核心字段： - -```text -id -case_id -task_type -prompt -required_annotation_types -max_score -sort_order -meta jsonb -``` - -说明： - -- 一个案例可以包含多个任务。 -- 例如 Sweep 案例可以包含：识别流动性池、判断是否 close back inside、写失效条件。 - -### 4.3 training_attempts - -核心字段： - -```text -id -case_id -user_id -status -current_frame_index -started_ts -submitted_ts -total_score -meta jsonb -``` - -第一版 `user_id` 可先使用 `"local"`，以后再接正式用户系统。 - -### 4.4 training_annotations - -核心字段： - -```text -id -attempt_id -annotation_type -payload jsonb -created_ts -``` - -常见 `annotation_type`： - -```text -dealing_range -equilibrium -draw -liquidity_pool -fvg -mss -invalidation -tp_sl -multiple_choice -free_text -``` - -### 4.5 training_scores - -核心字段： - -```text -id -attempt_id -category -score -max_score -feedback jsonb -``` - -### 4.6 training_progress - -核心字段： - -```text -id -user_id -skill_tag -attempt_count -avg_score -last_attempt_ts -weakness_tags jsonb -meta jsonb -``` - -## 5. 后端服务新增 - -新增目录： - -```text -src/services/training/ - __init__.py - case_generator.py - case_repository.py - replay_case_service.py - grading_service.py - annotation_service.py - progress_service.py -``` - -### 5.1 case_generator.py - -职责： - -1. 从真实事件生成案例。 -2. 从 `sweep_events` 生成 Sweep 训练题。 -3. 从 `fvg_zones` 生成 FVG 训练题。 -4. 从 `dealing_ranges` 生成 Range 训练题。 -5. 自动绑定 `chapter_ref` 与 `skill_tags`。 - -第一版案例来源： - -```text -sweep_events -> sweep 案例 -fvg_zones -> fvg 案例 -dealing_ranges -> range / premium_discount 案例 -structure_events + displacement_events -> mss_displacement 案例 -liquidity_pools -> liquidity_pool 案例 -``` - -### 5.2 replay_case_service.py - -职责： - -1. 基于已有 `src/services/backtest/replay.py`。 -2. 只返回 `decision_ts` 之前或逐根推进后的 candles。 -3. 防止未来函数。 -4. 支持 `advance 1 candle`、`advance 5 candles`、`reset`。 - -### 5.3 grading_service.py - -职责： - -1. 对用户标注打分。 -2. 第一版采用规则评分，不让 AI 主判。 -3. AI 后续只负责解释反馈。 -4. 评分结果写入 `training_scores`。 - -### 5.4 annotation_service.py - -职责： - -1. 保存用户画的 Range、FVG、SL、TP、Draw、Invalidation 等。 -2. 校验 annotation payload 的基本结构。 -3. 为评分服务提供用户提交内容。 - -### 5.5 progress_service.py - -职责： - -汇总用户能力雷达： - -1. Range 准确率 -2. Draw 判断率 -3. Sweep 误判率 -4. 无效点完整率 -5. 风险违规率 -6. FVG 识别准确率 -7. 结构接管判断准确率 - -## 6. API 设计 - -新增 `src/api/training.py`，路由接入 `src/api/server.py`。 - -建议接口： - -```text -GET /training/cases -GET /training/cases/{id} -POST /training/cases/generate - -POST /training/attempts -GET /training/attempts/{id} -POST /training/attempts/{id}/advance -POST /training/attempts/{id}/annotations -POST /training/attempts/{id}/submit - -GET /training/progress -``` - -典型流程： - -```text -1. GET /training/cases?case_type=sweep -2. POST /training/attempts { case_id } -3. POST /training/attempts/{id}/advance -4. POST /training/attempts/{id}/annotations -5. POST /training/attempts/{id}/submit -6. 返回 score + feedback + answer_key -``` - -## 7. 前端 Training Lab - -新增： - -```text -src/web/training/ - index.html - training.js - training.css -``` - -第一版页面结构： - -1. 左侧：章节/能力选择 -2. 中间：K 线回放图 -3. 右侧：任务卡、答题区、评分反馈 -4. 底部：推进按钮、提交按钮、显示答案按钮 - -第一版交互控件： - -1. 下一根 K 线 -2. 推进 5 根 -3. 重置 -4. 标注 Range -5. 标注 Draw -6. 标注 FVG -7. 标注 Invalidation -8. 选择题 / 判断题 -9. 提交评分 - -图表层第一版可以先沿用 Canvas，但要封装成训练图表组件。第二版再考虑升级专业图表库。 - -## 8. 评分规则 MVP - -每个案例总分 100： - -```text -Range / 位置判断：20 -Draw / 目标判断：20 -结构事件识别：20 -Invalidation：20 -执行纪律：20 -``` - -### 8.1 Sweep 题评分 - -```text -是否识别正确流动性池：20 -是否判断 close back inside：20 -是否等待确认而非立刻反手：20 -是否写出失效条件：20 -是否符合会话/时间过滤：20 -``` - -### 8.2 FVG 题评分 - -```text -是否识别正确 FVG 区间：20 -是否判断方向正确：20 -是否区分 open / touched / mitigated / invalidated：20 -是否写出有效失效条件：20 -是否符合当前 Bias / MSS 上下文：20 -``` - -### 8.3 Range 题评分 - -```text -是否选择合理 Key High：20 -是否选择合理 Key Low：20 -是否标注 Equilibrium：20 -是否判断 Premium / Discount：20 -是否能说明当前位置是否适合执行：20 -``` - -## 9. 开发里程碑 - -建议按 7 个小里程碑推进。 - -### M1：Training 数据模型与 migration - -完成： - -1. 新增训练表 migration。 -2. 新增 repository。 -3. 新增基础单测。 - -验收： - -1. training tables 可创建。 -2. case / attempt / annotation / score 可写入与读取。 -3. 不影响现有 migrations 与主链路测试。 - -### M2：案例生成器 MVP - -完成： - -1. 支持 `sweep` 案例生成。 -2. 支持 `fvg` 案例生成。 -3. 支持 `range` 案例生成。 - -验收： - -1. 能从真实事件生成至少 30 个训练案例。 -2. 每个案例有 `window_start_ts`、`decision_ts`、`window_end_ts`。 -3. 每个案例有 `answer_key`。 - -### M3：Replay API - -完成： - -1. 用户只能看到当时已知 K 线。 -2. 支持逐根推进。 -3. 支持重置。 - -验收： - -1. `decision_ts` 之后的 candle 不会提前暴露。 -2. replay frame 与当前进度一致。 -3. 输入 candles 通过合法性校验。 - -### M4：Annotation + Submit - -完成： - -1. 前端可提交用户标注。 -2. 后端保存 annotation。 -3. attempt 可从 started 进入 submitted。 - -验收： - -1. 至少支持 Range、Draw、Invalidation 三种标注。 -2. 标注 payload 可被评分服务读取。 - -### M5：Grading MVP - -完成： - -1. 规则评分。 -2. 返回分项得分。 -3. 返回反馈和 answer_key。 - -验收： - -1. Sweep / FVG / Range 至少三类题可评分。 -2. 分数写入 `training_scores`。 -3. attempt 总分更新。 - -### M6：Training Lab 前端 - -完成： - -1. 训练案例列表。 -2. K 线回放图。 -3. 任务卡。 -4. 标注提交。 -5. 评分反馈。 - -验收： - -1. 一个用户可以完整跑通训练闭环。 -2. UI 能清楚区分未提交、已提交、已评分状态。 -3. 不与现有 dashboard 互相干扰。 - -### M7：Progress 面板 - -完成： - -1. 汇总用户能力弱点。 -2. 输出初版 `Precision Maturity`。 -3. 展示按 skill_tag 的得分趋势。 - -验收： - -1. 能看到每类训练题尝试次数与平均分。 -2. 能看到主要薄弱项。 -3. 能基于弱点推荐下一组训练案例。 - -## 10. 第一版验收标准 - -第一版完成时必须满足： - -1. 能从真实 OKX 数据生成至少 30 个训练案例。 -2. 每个案例能隐藏未来并逐根推进。 -3. 用户能完成至少 3 种标注。 -4. 提交后能得到分项评分。 -5. Training 数据不影响 `trade_signals` 和 `trade_executions`。 -6. 单元测试覆盖 case generation、replay、grading。 -7. 前端能完整跑通一个训练闭环。 - -## 11. 推荐立即开始的第一步 - -先做 M1 + M2： - -```text -新增 training_cases -新增 training_case_tasks -实现 TrainingCaseGenerator -先从 sweep_events / fvg_zones / dealing_ranges 各生成一类案例 -``` - -这一步完成后，就能把书中的章节真实挂到市场样本上，后面的回放、标注、评分会自然长出来。 - -## 12. 长期演进方向 - -第一阶段完成后，可继续扩展： - -1. 精选教学案例 + 自动行情案例混合案例库。 -2. AI 教练解释反馈，但不作为主评分裁判。 -3. 章节闯关系统。 -4. 个人框架自动生成器。 -5. 多人训练营与老师批改。 -6. 高阶 replay：隐藏成交量、显示/隐藏指标、按会话切片。 -7. 真实交易日志与训练弱点联动。 - -## 13. 核心原则 - -1. 训练模块只读消费交易主链路数据。 -2. 训练用户行为不反向影响信号、执行、回测。 -3. 第一版以规则评分为主，AI 只做解释增强。 -4. 防未来函数是训练系统的生命线。 - -## 14. 外部产品化定位与研发治理补充 - -Training Case Engine 已确认为 AI Exchange 的对外产品模块。后续研发应按产品化模块设计，但 MVP 阶段仍以训练闭环和可扩展架构为第一目标。 - -### 14.1 产品化定位 - -Training Case Engine 的对外定位是： - -```text -基于真实市场数据与 ICT 规则识别的训练、标注、评分、复盘产品 -``` - -它面向外部学习者和训练用户，提供： - -1. 真实市场案例。 -2. 隐藏未来的回放训练。 -3. 结构、流动性、FVG、Range 等核心能力标注。 -4. 规则化评分与标准答案反馈。 -5. 按 skill_tag 汇总的薄弱项与训练进度。 - -第一阶段不追求完整教育平台、付费系统、多人课堂或复杂账号体系，而是先证明： - -```text -真实样本可生成 -> 用户可训练 -> 系统可评分 -> 进度可沉淀 -``` - -### 14.2 MVP 优先目标 - -MVP 优先保证： - -1. 案例生成链路稳定。 -2. `decision_ts` 隐藏未来严格可靠。 -3. 用户可以完成标注和答题。 -4. 提交后可得到分项评分与反馈。 -5. 训练进度可按能力标签累计。 -6. 架构预留对外账号、案例审核、课程化、付费化扩展空间。 - -MVP 暂不优先： - -1. 真实下单训练。 -2. 训练结果驱动交易策略。 -3. AI 主导评分。 -4. 复杂权限与商业化后台。 -5. 多人教学协作。 - -### 14.3 研发治理要求 - -Training Case Engine 研发按独立主线管理： - -1. qishu/麒枢负责规划、监督、验收。 -2. Codex 负责具体实现、文档落地、测试执行与变更汇报。 -3. 每个阶段形成清晰 Git 边界，便于审查和回滚。 -4. Codex 默认不提交 commit，由 qishu 审查后决定是否提交。 -5. 涉及数据库 migration、API contract、前端训练流程的变更必须写明验收标准。 - -建议阶段提交边界： - -```text -docs -> migration -> repository/service -> API -> frontend -> tests -``` - -### 14.4 隔离红线 - -Training Case Engine 可以只读消费 Trading Engine 的数据与规则事件，但训练域数据不得污染实盘、信号、执行链路。 - -允许： - -1. 读取 candles。 -2. 读取 sweep_events、fvg_zones、structure_events、dealing_ranges 等规则事件。 -3. 读取 backtest summary 作为案例上下文。 -4. 将用户训练行为写入 training attempts、annotations、scores、progress。 - -禁止： - -1. 将 training annotations 写入 `trade_signals`。 -2. 将 training scores 写入 `trade_executions`。 -3. 用 training progress 自动调整实盘策略。 -4. 通过 Training Lab 触发真实下单。 -5. 在训练 API 中返回或记录数据库密码、交易密钥、账户凭证。 - -### 14.5 验收补充 - -除原 MVP 验收标准外，产品化方向还需补充： - -1. Training Lab 能完整跑通选题、回放、标注、提交、评分、复盘流程。 -2. 提交前不暴露 `answer_key` 或未来 K 线。 -3. Training 写入仅限训练相关表。 -4. 与 Trading Engine 的接口保持只读和可追溯。 -5. 每个阶段都能通过 Git 回滚到上一可用状态。 -6. 文档、API、数据模型、前端流程保持一致。 -7. 先跑通真实案例闭环，再扩展复杂教学玩法。 diff --git a/docs/AI_ICT_主线进度摘要_v1.md b/docs/AI_ICT_主线进度摘要_v1.md deleted file mode 100644 index 50ef261..0000000 --- a/docs/AI_ICT_主线进度摘要_v1.md +++ /dev/null @@ -1,66 +0,0 @@ -# AI ICT 主线进度摘要 v1 - -## 当前数据库核心行数 - -- candles: 400 -- market_sessions: 5 -- swings: 78 -- dealing_ranges: 2 -- liquidity_pools: 47 -- sweep_events: 37 -- displacement_events: 113 -- structure_events: 3 -- fvg_zones: 100 -- bias_snapshots: 3 -- trade_signals: 3 -- backtest_runs: 5 -- backtest_results: 10 - -## 当前已经形成的真实主线 - -OKX -> candles -> market_sessions -> swings -> dealing_ranges -> liquidity_pools -> sweep_events -> displacement_events -> MSS -> FVG -> bias -> signals -> backtest - -## 当前已经验证完成的阶段 - -1. 远程 PostgreSQL 专用库 ai_ict 已建立并完成迁移 -2. OKX 数据已成功写入真实数据库 -3. Session / Swing / Range / Liquidity 链已跑通 -4. Sweep / Displacement / MSS / FVG 事件链已跑通 -5. Bias / Signal 组合层已跑通 -6. Backtest 已开始基于真实后续 candles 产出结果 - -## 当前仍需继续增强的质量点 - -1. backtest 中同根 K 线 stop / TP 优先级规则已采用保守 `stop_first`，并已补充歧义标记与单元测试 -2. session filter 已进入 backtest meta 与 signal 生成层 -3. larger backfill 样本进一步扩大 -4. equal highs / lows 第一版已接入 liquidity pool，后续继续做更精细 liquidity merge / 去重 -5. MSS acceptance 与 FVG mitigation 逻辑进一步细化 - -## 本轮代码推进记录 - -已完成： - -1. 抽出 `evaluate_signal_outcome` 纯函数，便于无数据库单测 -2. 修正 `invalidated_before_entry`，避免把入场后止损误写成入场前失效 -3. 对同根 K 线 entry / stop / TP 歧义写入 `same_candle_ambiguous` 与 `same_candle_entry_exit_ambiguous` -4. backtest result meta 写入 `session_codes` 与 `session_filter` -5. signal 生成时读取当前 session，允许 LONDON / NY_AM / NY_PM，降级 ASIA / NY_LUNCH / OFF_HOURS -6. equal highs / equal lows 按 swing 价格聚类生成 liquidity pool -7. 新增 backtest、signal session filter、liquidity equal pool 单元测试 - -## 本轮需求规划审查结论 - -原规划的总体方向合理：先数据、再规则、再信号、再回测、再执行，符合交易系统从可验证到可执行的工程顺序。 - -需要修正的地方： - -1. `开发路线图` 的下一步仍描述为项目起步任务，与当前代码已经跑到 backtest 层不一致 -2. `MVP 规则规格书` 对回测同根 K 线、入场前失效、session 元数据追溯的定义不够细 -3. `执行检查清单` 中多个已落地阶段仍保持未勾选状态，容易误导后续开发回头重做 -4. 自动化开发边界需要保持清晰：可以自动推进文档、规则、回测、paper trading，但真实下单仍必须保留显式确认 - -## 当前主线结论 - -系统已经从“能生成结构”推进到“能生成信号并写入回测结果”。 -下一阶段主线重点不是再扩文档，而是继续提高回测真实性与结果稳定性，然后再推进 signal/session 联动和结构质量增强。 diff --git a/docs/AI_ICT_交易模块缺口清单_v1.md b/docs/AI_ICT_交易模块缺口清单_v1.md deleted file mode 100644 index 485c87b..0000000 --- a/docs/AI_ICT_交易模块缺口清单_v1.md +++ /dev/null @@ -1,212 +0,0 @@ -# AI ICT 交易模块缺口清单 v1 - -## 1. 文档目标 - -本文档用于把当前交易模块“还没做完什么”整理成一份稳定、可复用的缺口清单，避免每次继续开发都要重新从 `SESSION.md`、`TASKS.md`、代码状态和聊天记录里手工拼接结论。 - -本文档只覆盖交易主线，不覆盖： - -- Training 产品新功能 -- `legal_content/` 法务内容资产 -- 已归档启动期路线图中的过期任务 - -## 2. 统计口径 - -本清单以当前有效主线文档和现有代码实现为准： - -1. 当前开发优先级与阶段目标：`AI_ICT_当前开发方案_v2.md` -2. 当前 active backlog：`TASKS.md` -3. 当前交付状态与风险：`SESSION.md` -4. 当前代码实现范围：`src/`、`scripts/`、`src/web/` - -说明： - -- `P0` 表示当前进入目标环境验证或市场验证前的 blocker。 -- `P1` 表示当前交易主线仍应优先补齐的代码与闭环缺口。 -- `P2` 表示总体设计中仍有价值，但不是当前上线前必须完成的中后期能力。 - -## 3. 统计结果 - -按当前口径统计： - -- `P0` 功能实现缺口: `0` -- `P0` 剩余运行结果 blocker: `1` -- `P1` 功能实现缺口: `0` -- `P2`: `5` 项 - -其中： - -- 明确未完成的当前 active backlog 项：`2` -- 当前已经不再存在未实现的 `P1` 代码项 -- `P0` 当前剩余问题已经不再是“缺脚本或缺流程入口”，而是“脚本化闭环存在，但目标环境运行结果仍待转绿” - -## 4. P0 缺口 - -### P0 已完成的功能闭环 - -当前 `P0` 所需的功能入口已经补齐： - -1. 已有锁定后的 `Trading Delivery Checklist` -2. 已有 `scripts/check_trading_delivery_readiness.py` 做 checklist 漂移检查 -3. 已新增 `scripts/run_trading_delivery_rehearsal.py` 作为单一编排入口，串联： - - checklist drift check - - historical repair dry-run / optional safe apply / post-apply rescan - - database readiness / auto-backfill / guarded pipeline - - target deploy / health-check - - post-deploy readiness / reports observe -4. 已把高风险 liquidity 引用迁移默认策略固化为显式 defer，而不是继续停留在未决聊天结论里 - -因此，`P0` 当前已不再缺少流程脚本或闭环入口。 - -### P0-1 市场验证 gate 仍未通过 - -状态： - -- 当前不是“模块不存在”，也不是“缺少脚本入口”，而是“运行结果仍然不满足进入市场验证”。 -- 已观测到 candle 数据陈旧与 backtest quality gate 失败。 - -当前已暴露的问题： - -- `candles_too_stale` -- `backtest_quality_gate.passed = false` - -阻断原因： - -- 在 freshness 和 quality gate 未转绿之前，交易闭环仍停留在实验验证态，不应视为可进入市场验证 - -## 5. P1 已完成的功能闭环 - -### P1-1 `sweep_events.pool_id` 引用迁移与 liquidity 合并执行器已实现 - -- 当前已新增 exact duplicate pool 的 reference migration planning / apply 路径。 -- 支持 dry-run、显式 apply 和 sweep timestamp conflict protection。 -- `run_historical_compatibility_repair.py` 已支持显式 `--apply-liquidity-reference-migrations`。 - -闭环结果： - -- 在 exact duplicate 且引用可安全迁移的前提下，提供 `sweep_events.pool_id` 重绑与冗余 pool 清理执行器 -- 对 duplicate sweep timestamp 冲突提供阻断，而不是盲迁移 -- 已接入现有 historical compatibility repair 主入口，而不是额外散落一个新脚本 - -### P1-2 signal evidence / session gate 已切到 strict 默认闭环 - -- 当前 signal 链已经把 `sweep_id / displacement_id / liquidity_target_id` 补进 strict evidence。 -- `run_signals.py` 与交易主闭环默认已切到 strict mode，而不是 minimal default。 -- strict 不再只是“代码里能选”，而是当前交易主线的默认运行口径。 - -### P1-3 execution / settlement 已升级到显式 observation 驱动状态机 - -- 当前 execution settlement 不再只有“直接拿 backtest 结果改状态”一条路。 -- 已支持显式 observation source，并区分： - - `backtest_projection` - - `manual` -- 已新增 `settlement_source / fill_state / position_state / close_reason` 元语义。 -- `run_execution_settlement.py` 已支持 manual observation 输入路径。 - -当前边界： - -- 这还不等于已经接上真实 broker / exchange -- 但 execution 状态机已经不再是“只有 backtest 结果直写库”的单一路径 - -### P1-4 多 timeframe 已形成端到端运行与分析闭环 - -- 主运行链已支持 `bias_tf / setup_tf / trigger_tf` -- backtest 已按 `timeframe_set` 过滤 candidate signals，并使用 signal 对应的 trigger timeframe 取 future candles -- backtest summary 已新增 `by_timeframe` -- dashboard backtest cards 已增加 timeframe breakdown 展示 - -当前边界： - -- `market_sessions` 仍保持单记录模型，不做多 timeframe 平行副本 -- 但 `P1` 需要的主闭环、多 timeframe signal/backtest、以及 timeframe 维度分析已经落地 - -## 6. P2 缺口 - -### P2-1 `session pivots` 模块 / API / UI 未落地 - -状态： - -- 总体设计和 context 面板里明确有 `session pivots` -- 当前代码树里没有对应交易服务、模型或 API surface - -影响： - -- 设计文档里的一块上下文信息仍停留在概念层，没有进入真实运行链路 - -### P2-2 完整风控接口 `risk_check(signal, account_state, market_state) -> allow / reject / downgrade` 未落地 - -状态： - -- 当前已有账户级限制和 allow/reject reasons -- 但还没有完整的 `market_state` 输入，也没有 `downgrade` 路径 - -影响： - -- 风控存在，但离总体设计中的独立风控接口还差一层抽象与状态输入 - -### P2-3 重大新闻时间窗 gate 未落地 - -状态： - -- 总体设计里明确写了“重大新闻时间窗禁开新仓” -- 当前 signal / execution 路径里没有对应 gate - -影响： - -- 风控设计和实际执行边界之间还有明显缺口 - -### P2-4 Dashboard 仍是最小监控面，没有把 Context / Reports 视图做全 - -状态： - -- 当前 dashboard 已能展示 health、candles、signals、sessions、executions、backtests -- 但总体设计里的 Context 视图与 Reports 面板还没完整落地为独立前端 surface - -影响： - -- 后台规则和报告能力已经存在一部分，但前端可消费面没有完全展开 - -### P2-5 `semi_auto` 还不是真实交易所执行集成 - -状态： - -- 当前 `semi_auto` 已有显式确认边界 -- 但执行记录仍没有真实 broker / exchange order 回执链 - -影响： - -- `semi_auto` 更接近“受控模拟执行”而不是真正的交易执行集成 - -## 7. 当前不计入缺口的内容 - -以下内容不再视为当前交易模块缺口： - -- 启动期骨架、数据库第一批表、基础闭环搭建 -- replay/no-lookahead backtest 的第一版接入 -- liquidity safe repair 的低风险范围 -- MSS/FVG richer state 的第一版状态收敛 -- execution / backtest / report 生命周期第一版统一 -- dashboard 最小交易监控面 - -这些能力都已经存在，不应再按“未做”重复计入。 - -## 8. 建议的推进顺序 - -当前建议的真实推进顺序是： - -1. 先在目标环境执行 `scripts/run_trading_delivery_rehearsal.py`，拿到一次完整、可复用的 rehearsal 结果 -2. 先把 `P0-1` 的 freshness / quality gate 结果转绿 -3. 在 `P0` 转绿后，再进入 `P2` 的中后期能力补全 -4. `P2` 不应和当前目标环境交付 blocker 混排 - -## 9. 当前结论 - -当前交易模块的真实状态可以概括为： - -- 主链功能已经基本具备 -- 当前真正缺的不是“大量模块没做”，也不再是“P0 缺编排入口”或 “P1 缺实现”，而是少数关键运行结果没有转绿 -- 进入市场验证前，优先级最高的是执行 scripted rehearsal 并把 freshness / quality gate 转绿 - -因此，当前最准确的判断不是“交易模块还没做出来”，而是： - -> 交易模块已经形成最小闭环，P0 与 P1 所需功能入口和实现层闭环都已补齐，但离可验证交付仍差一次真正转绿的目标环境结果。 diff --git a/docs/AI_ICT_双主线研发治理计划_v1.md b/docs/AI_ICT_双主线研发治理计划_v1.md deleted file mode 100644 index 7ec6978..0000000 --- a/docs/AI_ICT_双主线研发治理计划_v1.md +++ /dev/null @@ -1,422 +0,0 @@ -# AI ICT 双主线研发治理计划 v1 - -## 1. 文档目标 - -本文档用于约束 AI Exchange 后续研发推进方式，确保两条主线可以并行演进、分阶段验收、可审查、可回滚。 - -当前系统两条主线： - -```text -A. AI ICT Trading Engine -B. Training Case Engine -``` - -治理目标： - -1. qishu/麒枢负责研发规划、技术监督、阶段验收。 -2. Codex 负责具体编码、文档落地、测试执行与变更说明。 -3. 每个阶段形成清晰 Git 边界，便于审查与回滚。 -4. Training Case Engine 按对外产品模块治理，但不得污染实盘、信号、执行主链路。 -5. 数据库、密钥、交易执行相关变更必须走更高等级审查。 - -## 2. 角色分工 - -### 2.1 yuqei - -yuqei 作为钰麒科技 CEO，负责： - -1. 确认产品方向、商业优先级与阶段目标。 -2. 决定双主线资源倾斜与发布节奏。 -3. 对关键里程碑给出业务验收意见。 -4. 对是否进入公开演示、内测、外部产品化阶段作最终确认。 - -### 2.2 qishu/麒枢 - -qishu/麒枢作为研发/技术总监，负责： - -1. 拆解研发阶段与技术路线。 -2. 定义 Codex 的具体任务边界、验收标准与禁止事项。 -3. 审查 Codex 产出的代码、文档、migration、测试结果。 -4. 判断变更是否可以提交 Git commit。 -5. 管控数据库结构、密钥使用、交易执行边界与回滚方案。 -6. 对阶段性交付进行签收或退回修改。 - -### 2.3 Codex - -Codex 作为一线开发代理，负责： - -1. 按 qishu 派发的任务落地代码或文档。 -2. 在动手前读取相关上下文，避免破坏现有设计。 -3. 严格遵守任务边界，不主动扩大修改范围。 -4. 在每次变更后运行对应检查，并汇报结果。 -5. 输出清晰的修改文件列表、验证命令与剩余风险。 -6. 不擅自提交 Git commit，除非任务明确要求。 - -Codex 不负责： - -1. 绕过 qishu 审查直接合并关键变更。 -2. 修改生产密钥、数据库密码或真实资金执行配置。 -3. 在未授权情况下调整交易执行、安全边界或账户权限。 -4. 将训练用户行为接入实盘信号、执行或资金管理链路。 - -## 3. 双主线边界 - -### 3.1 A 主线：AI ICT Trading Engine - -目标： - -1. 建立真实市场数据接入。 -2. 完成 ICT 规则识别。 -3. 形成 bias、signal、backtest、execution、report 的交易研究与执行链路。 - -核心资产： - -```text -market data -rule events -bias -signals -backtest -execution -reports -``` - -治理要求： - -1. 任何影响 signal、execution、资金、账户、交易 API 的变更必须单独立项。 -2. Trading Engine 的数据结构和事件语义是 Training Case Engine 的只读上游。 -3. 未经 qishu 明确验收，不允许把训练评分、训练标注、训练偏好反向写入交易决策。 - -### 3.2 B 主线：Training Case Engine - -目标： - -1. 将真实市场样本转化为可训练案例。 -2. 支持隐藏未来、逐根回放、用户标注、规则评分、能力进度。 -3. 按对外产品模块设计，形成可演示、可内测、可扩展的 Training Lab。 - -核心资产： - -```text -training_cases -training_case_tasks -training_attempts -training_annotations -training_scores -training_progress -Training Lab -``` - -治理要求： - -1. Training 数据与实盘、信号、执行严格隔离。 -2. Training 可以只读消费 candles、rule events、backtest summaries。 -3. Training 不得写入 trade_signals、trade_executions、execution orders 或账户资金状态。 -4. 第一阶段先保证训练闭环与架构可扩展，不追求复杂商业化系统。 - -## 4. 双主线优先级 - -### 4.1 总体优先级 - -当前优先级为： - -```text -P0：安全边界、可回滚、数据隔离 -P1：Training Case Engine 外部产品化 MVP -P2：Trading Engine 规则链路稳定性与数据质量 -P3：高级 AI 反馈、多人课堂、付费与运营体系 -``` - -### 4.2 阶段优先级 - -近期阶段建议： - -1. 先固化研发治理、Git 策略、验收标准。 -2. 推进 Training Case Engine MVP，让训练闭环可被真实使用。 -3. 保持 Trading Engine 主链路稳定，避免为了训练功能破坏交易数据与信号链路。 -4. 在 Training MVP 成型后，再规划对外账号、权限、课程、付费与内容运营。 - -### 4.3 冲突处理原则 - -当两条主线发生资源或设计冲突时： - -1. 涉及资金、交易执行、密钥、生产数据库安全时，Trading Engine 安全优先。 -2. 涉及产品演示、训练闭环、外部用户体验时，Training MVP 优先。 -3. 涉及共享数据模型时，以只读消费和事件追溯为默认方案。 -4. 涉及不可逆数据变更时，必须先写回滚策略，再进入实现。 - -## 5. Git 提交策略 - -### 5.1 基本原则 - -1. 一个阶段一个清晰提交，避免大而混杂的提交。 -2. 文档、后端、前端、migration、测试可以按阶段拆分提交。 -3. 每个提交必须能被解释、审查、回滚。 -4. Codex 默认不提交 commit，由 qishu 审查后决定是否提交。 - -### 5.2 推荐提交粒度 - -Training Case Engine 推荐拆分： - -```text -commit 1: docs - governance and MVP planning -commit 2: db - training tables migration -commit 3: backend - repository and case generator -commit 4: backend - replay and annotation APIs -commit 5: backend - grading and progress services -commit 6: frontend - Training Lab MVP -commit 7: tests - integration and acceptance coverage -``` - -Trading Engine 推荐拆分： - -```text -commit 1: docs/spec - rule or data contract update -commit 2: db - schema or migration update -commit 3: backend - rule detection/service change -commit 4: tests - deterministic cases and regression tests -commit 5: reports/ui - visualization or report changes -``` - -### 5.3 提交信息规范 - -建议格式： - -```text -: -``` - -示例： - -```text -docs: add dual-track governance plan -training: add case generation schema -training-api: add attempt replay endpoints -ict-rules: refine sweep confirmation logic -``` - -每个提交说明至少包含： - -1. 修改范围。 -2. 验证命令。 -3. 是否涉及数据库。 -4. 是否涉及密钥、交易执行或外部 API。 -5. 回滚影响。 - -## 6. 回滚策略 - -### 6.1 文档变更回滚 - -文档类变更可通过普通 Git revert 回滚： - -```text -git revert -``` - -要求： - -1. 不与业务代码混在同一提交。 -2. 不夹带 `.env`、密钥、数据库密码或本地配置。 - -### 6.2 后端与前端代码回滚 - -代码变更必须满足： - -1. 每个阶段提交前运行对应测试。 -2. 提交说明写明入口、影响模块、回滚注意事项。 -3. 回滚后系统应至少回到上一阶段可运行状态。 -4. 若引入新 API，回滚时必须确认前端调用不会残留破坏页面。 - -### 6.3 数据库 migration 回滚 - -数据库变更必须更谨慎： - -1. migration 必须单独提交或与极小范围代码提交绑定。 -2. migration 文档必须写明新增表、字段、索引、默认值、约束。 -3. 涉及删除、重命名、数据迁移时，必须先写回滚方案。 -4. 不允许把真实数据库密码写入 migration、脚本、日志或文档。 -5. 对不可逆 migration，必须在提交说明中明确标注并经 qishu 确认。 - -Training 表优先采用新增表方式，避免侵入 Trading Engine 现有表结构。 - -### 6.4 密钥与环境配置回滚 - -密钥与环境配置不应进入 Git： - -1. `.env` 不提交。 -2. 数据库密码不写入文档。 -3. API key 不写入测试样例、日志、截图、commit message。 -4. 若误提交密钥，必须立即停止后续开发，由 qishu 组织密钥轮换和 Git 历史处理。 - -## 7. Codex 派发与验收流程 - -### 7.1 派发格式 - -qishu 给 Codex 派发任务时，建议包含： - -```text -目标： -允许修改： -禁止修改： -验收标准： -必须运行的检查： -是否允许 git commit： -特殊安全要求： -``` - -示例： - -```text -目标：新增 Training Case Engine 文档 -允许修改：docs/*.md -禁止修改：业务代码、.env、数据库密码 -验收标准：三份文档完成，git diff --check 通过 -是否允许 git commit：不允许，由 qishu 审查后提交 -``` - -### 7.2 Codex 执行流程 - -Codex 每次任务应按以下顺序执行： - -1. 读取任务约束与禁止事项。 -2. 检查当前工作区状态。 -3. 读取相关文档或代码上下文。 -4. 输出简短执行计划。 -5. 在允许范围内修改文件。 -6. 运行约定检查。 -7. 汇报修改文件、验证结果、未处理事项。 - -### 7.3 qishu 验收流程 - -qishu 验收时重点检查： - -1. 是否严格符合任务边界。 -2. 是否存在越权修改。 -3. 是否触碰 `.env`、密钥、数据库密码。 -4. 是否影响 Trading Engine 主链路。 -5. 是否具备回滚边界。 -6. 文档与代码是否一致。 -7. 测试与静态检查是否覆盖本阶段风险。 - -验收结论可分为： - -```text -ACCEPT：可提交 -REQUEST_CHANGES：需修改后复审 -REJECT：方向或边界不符合，停止本轮 -``` - -## 8. 质量门禁 - -### 8.1 文档类任务 - -最低门禁： - -1. `git diff --check` -2. 文件命名符合 `docs/` 既有规范。 -3. 章节完整，覆盖派发要求。 -4. 不包含密钥、数据库密码、真实账号、不可公开配置。 - -### 8.2 后端任务 - -最低门禁： - -1. Python 语法检查或项目已有 lint/test 命令。 -2. 关键 service/repository 单元测试。 -3. API schema 或返回结构与前端调用一致。 -4. 不引入未来函数。 -5. 不让训练数据反向影响 signal/execution/backtest 主链路。 - -### 8.3 前端任务 - -最低门禁： - -1. 页面可启动或静态资源可被加载。 -2. Training Lab 核心流程可走通。 -3. 未提交、已提交、已评分状态清楚。 -4. 移动端和桌面端不出现明显布局重叠。 -5. 不泄露 answer_key，除非用户提交后或明确点击显示答案。 - -### 8.4 数据库任务 - -最低门禁： - -1. migration 可执行。 -2. 新增表和索引有明确用途。 -3. Training 表与交易执行表无强耦合写入。 -4. 不在 migration 中包含密码或真实连接串。 -5. 回滚或恢复方案已写明。 - -## 9. 数据库与密钥安全规则 - -### 9.1 禁止事项 - -任何阶段都禁止： - -1. 修改 `.env` 后提交。 -2. 在文档中写入数据库密码。 -3. 在代码中硬编码 API key、secret、passphrase。 -4. 在日志中打印完整连接串或认证信息。 -5. 将训练标注直接写入交易信号或真实执行表。 -6. 用训练用户行为自动触发真实下单。 - -### 9.2 数据隔离规则 - -Training Case Engine 必须遵守： - -```text -Trading data/rule events -> Training read only -Training attempts/annotations/scores -> Training storage only -Training user behavior -> no writes to signals/executions/orders -``` - -允许： - -1. Training 读取 candles。 -2. Training 读取 sweep、FVG、MSS、dealing range 等规则事件。 -3. Training 读取 backtest summary 作为案例来源或上下文。 - -禁止： - -1. Training 写入 trade_signals。 -2. Training 写入 trade_executions。 -3. Training 修改 backtest_results。 -4. Training 使用用户答题结果改变实时交易策略。 - -### 9.3 最小权限原则 - -开发和运行时建议： - -1. Training 读市场数据使用只读权限。 -2. Training 写入只限训练相关表。 -3. 交易执行相关凭证独立保管，不进入训练模块。 -4. 外部产品化时，用户账号权限与交易账户权限彻底分离。 - -## 10. 阶段交付标准 - -每个阶段完成时，Codex 应汇报： - -1. 修改文件列表。 -2. 主要变更摘要。 -3. 已运行检查。 -4. 检查结果。 -5. 未运行检查及原因。 -6. 风险或需要 qishu 决策的问题。 - -qishu 审查通过后，再决定是否形成 Git commit。 - -## 11. 当前阶段建议 - -当前阶段建议形成一个文档类提交： - -```text -docs: add dual-track governance and training MVP plans -``` - -包含： - -1. 双主线研发治理计划。 -2. Training Case Engine 外部产品化 MVP 计划。 -3. Training Case Engine 开发方案补充章节。 - -该提交只应包含 `docs/` 文档变更，不应包含业务代码、`.env`、数据库密码或本地运行产物。 diff --git a/docs/AI_ICT_实盘交易分析系统开发计划_v1.md b/docs/AI_ICT_实盘交易分析系统开发计划_v1.md new file mode 100644 index 0000000..44666ed --- /dev/null +++ b/docs/AI_ICT_实盘交易分析系统开发计划_v1.md @@ -0,0 +1,978 @@ +# AI ICT 实盘交易分析系统开发计划 v1 + +## 1. 文档目标 + +本文档用于替代旧的分散方案文档，把项目重新收束到一个目标： + +> 尽快完成实盘交易分析主线，让系统从“规则事件识别与回测工具”升级为“书本驱动的半自动实盘交易分析与执行辅助系统”。 + +当前只聚焦实盘交易分析主线，暂不展开 Training Case Engine、法务内容资产或通用协作流程文档。 + +根依据： + +- `docs/ICT交易全书_出版终校版.md` + +开发原则： + +1. 书本是理论与流程源头。 +2. 规则引擎负责结构化真值。 +3. AI 智能体负责叙事、解释、监督、计划生成与复盘总结。 +4. 风控、下单、仓位、熔断必须由硬规则控制，不能交给 LLM 自由决定。 +5. 先做半自动实盘辅助，再考虑极小风险 live adapter；不直接进入全自动实盘。 + +## 2. 核心判断 + +现有系统已经具备良好的底层能力： + +- 行情接入 +- session / swing / range / liquidity +- sweep / displacement / MSS / FVG +- bias / signal +- backtest / quality gate +- paper / semi-auto execution 雏形 + +但它目前更像： + +```text +规则事件识别器 + 信号生成器 + 回测闸门 +``` + +离书中要求的实盘执行系统还缺一层： + +```text +盘前叙事 -> 盘中监控 -> 确认链授权 -> 风险闸门 -> 半自动执行 -> 仓位管理 -> 盘后复盘 +``` + +因此，后续不应继续优先堆更多零散 ICT 术语识别器，而应优先把书中的执行顺序固化为系统状态机。 + +## 3. 书本抽象出的实盘主流程 + +从《ICT交易全书》抽象出的可执行顺序如下： + +```text +Narrative +-> Draw on Liquidity +-> Bias +-> Dealing Range / Location +-> Time Window +-> Setup Type +-> Confirmation Chain +-> Trade Plan +-> Risk Gate +-> Execution +-> Position Management +-> Journal / Review +``` + +对应系统语言： + +1. `Narrative`：当前市场正在讲什么故事。 +2. `Draw`：价格更可能优先处理哪一侧流动性或失衡。 +3. `Bias`：当前只允许偏多、偏空、中性还是观察。 +4. `Location`：当前是否处在有风险效率的位置。 +5. `Time Window`：当前时段是否授权执行。 +6. `Setup Type`：当前机会是否属于模型内机会。 +7. `Confirmation Chain`：是否完成 sweep / displacement / MSS / FVG / retest 等闭环。 +8. `Trade Plan`：入场、止损、目标、失效、过期、管理动作。 +9. `Risk Gate`：账户、时段、新闻、质量门槛、持仓限制。 +10. `Execution`：paper 或 semi-auto；后续才接 live adapter。 +11. `Position Management`：TP1、TP2、保本、部分止盈、失效退出。 +12. `Journal`：区分模型失效和执行违规，反哺下一轮计划。 + +## 4. 新系统定位 + +系统不是“AI 自动喊单器”，而是： + +```text +AI-assisted ICT Trading Operations System +``` + +中文定位： + +```text +AI 辅助 ICT 实盘交易分析与半自动执行系统 +``` + +核心能力： + +1. 自动整理盘前结构化交易计划。 +2. 自动监控盘中是否出现模型内机会。 +3. 自动生成交易计划票据，而不是直接喊买卖。 +4. 用硬规则判断是否允许执行。 +5. 半自动执行时必须人工确认。 +6. 自动追踪订单、仓位、止盈止损和失效条件。 +7. 自动生成盘后复盘和下一轮改进项。 + +## 5. 总体架构 + +建议采用三层架构。 + +### 5.1 Layer A：Market Truth Layer + +负责事实层，不做主观建议。 + +输入： + +- OKX candles +- 当前价 +- sessions +- market calendar +- economic calendar +- account state +- positions +- orders + +输出： + +- market state +- session state +- freshness state +- data quality state +- account risk state +- open position state + +要求： + +- 完全结构化。 +- 不依赖 LLM。 +- 可回测、可审计、可复现。 + +### 5.2 Layer B：Rule Intelligence Layer + +负责 ICT 结构识别。 + +已有模块继续保留： + +- session +- swing +- dealing range +- liquidity pool +- sweep +- displacement +- MSS +- FVG +- bias +- signal +- backtest + +需要升级： + +- bias 从 `latest_mss` 升级为 `Narrative -> Draw -> Bias` +- signal 从单一 `SWEEP_MSS_FVG` 升级为 `TradePlanCandidate` +- target 从固定百分比升级为 `IRL / ERL / liquidity / ADR / STD` +- invalidation 从简单标签升级为结构化退出条件 + +### 5.3 Layer C：AI Agent Layer + +负责解释、计划、监督和复盘。 + +LLM 可以参与： + +- 盘前叙事摘要 +- setup 解释 +- 交易计划自然语言说明 +- 风险提示 +- 复盘归因 +- 周度报告 + +LLM 不允许参与： + +- 绕过风控 +- 直接下单 +- 修改风险上限 +- 自行扩大仓位 +- 在无结构证据时生成交易建议 + +## 6. 智能体划分 + +### 6.1 Market Truth Agent + +职责： + +- 检查行情新鲜度。 +- 检查 candle 连续性。 +- 维护当前 session。 +- 识别新闻窗口和开盘波动窗口。 +- 读取账户与持仓状态。 + +输出： + +```json +{ + "market_data_fresh": true, + "session_code": "NY_AM", + "news_window_state": "clear", + "opening_volatility_state": "normal", + "account_risk_state": "normal" +} +``` + +第一阶段必须落地为纯规则模块。 + +### 6.2 Narrative Agent + +职责： + +- 盘前生成 `Narrative`。 +- 定义主 Draw、次 Draw。 +- 生成 Bias。 +- 写明失效条件。 +- 生成当天不可做环境。 + +输出： + +```json +{ + "narrative_code": "bullish_after_sell_side_sweep", + "primary_draw": { + "side": "buy_side", + "target_type": "external_liquidity", + "target_id": 123 + }, + "secondary_draw": { + "side": "sell_side", + "target_type": "internal_liquidity", + "target_id": 88 + }, + "bias": "bullish", + "execution_intensity": "medium", + "invalidation": [ + "price_reclaims_old_control", + "mss_invalidated", + "news_window_active" + ] +} +``` + +LLM 可用于解释，但结构化字段必须由规则和证据填充。 + +### 6.3 Setup Watcher Agent + +职责： + +- 盘中监控是否出现模型内机会。 +- 不做全天随机扫描，只监控计划内方向和时段。 +- 当前第一模型锁定为： + +```text +Daily Range / OSOK ++ Sweep ++ MSS ++ FVG retrace ++ IRL / ERL target +``` + +输出： + +```json +{ + "candidate_type": "OSOK_SWEEP_MSS_FVG", + "status": "candidate", + "side": "buy", + "evidence": { + "sweep_id": 1, + "mss_id": 2, + "fvg_id": 3, + "liquidity_target_id": 4 + } +} +``` + +### 6.4 Confirmation Agent + +职责： + +- 判断确认链是否闭合。 +- 确认流动性处理是否已经发生。 +- 确认 displacement 是否有效。 +- 确认 MSS 是否 accepted。 +- 确认 FVG 是否仍可执行。 +- 确认当前时段是否允许执行。 + +输出： + +```json +{ + "confirmation_state": "confirmed", + "missing_requirements": [], + "quality_score": 4, + "quality_reasons": [ + "sweep_confirmed", + "mss_accepted", + "fvg_open", + "allowed_session" + ] +} +``` + +硬规则： + +- 缺 confirmation 不允许进入标准风险执行。 +- 低质量机会只能观察，不能创建 semi-auto 执行票。 + +### 6.5 Trade Plan Agent + +职责： + +- 生成标准交易计划票据。 +- 把 setup 转成可执行计划。 + +计划字段： + +- symbol +- side +- model_code +- session_code +- entry_zone +- stop_loss +- tp1 +- tp2 +- invalidation +- expiry +- risk_pct +- management_rules + +目标规则： + +- TP1 优先来自 IRL。 +- TP2 优先来自 ERL。 +- 不再使用固定百分比作为默认 TP。 +- 若 IRL / ERL 不明确，则交易计划不成立。 + +### 6.6 Risk Governor + +职责： + +- 最终执行闸门。 +- 必须是纯规则系统。 + +检查项： + +1. 行情是否新鲜。 +2. 回测质量门槛是否允许该模型执行。 +3. 是否处于允许 session。 +4. 是否处于新闻禁运或开盘高噪音窗口。 +5. 是否存在 stop。 +6. RR 是否达标。 +7. 单笔风险是否在上限内。 +8. 日亏损是否触发熔断。 +9. 连亏是否触发熔断。 +10. 是否已有持仓。 +11. 是否同向暴露过高。 +12. 是否超出每日最大交易次数。 + +输出： + +```json +{ + "allowed": false, + "decision": "reject", + "reasons": [ + "news_window_active", + "quality_gate_not_passed" + ] +} +``` + +### 6.7 Execution Agent + +阶段一只做： + +- paper +- semi_auto + +semi_auto 必须： + +- 生成执行票。 +- 等待人工确认。 +- 记录确认人、确认时间、确认版本。 +- 下单前再次跑 Risk Governor。 + +后续 live adapter 必须支持： + +- bracket order / OCO +- partial take profit +- stop move +- cancel all +- kill switch +- order reconciliation +- exchange error handling + +### 6.8 Journal Agent + +职责： + +- 盘后自动生成复盘。 +- 区分模型问题和执行问题。 +- 统计框架内执行率。 +- 统计模型外交易率。 +- 统计风险违规次数。 + +输出： + +```json +{ + "trade_id": 1, + "model_compliance": true, + "risk_compliance": true, + "execution_error": false, + "model_failure": false, + "review_tags": [ + "valid_model", + "tp1_hit", + "managed_by_plan" + ], + "next_actions": [ + "keep_same_model", + "review_fvg_fill_behavior" + ] +} +``` + +## 7. 数据模型新增与调整 + +### 7.1 新增 `market_states` + +用途： + +- 记录当前市场事实快照。 + +核心字段： + +- instrument_id +- snapshot_ts +- session_code +- data_freshness +- candle_age_seconds +- news_window_state +- opening_volatility_state +- account_state jsonb +- position_state jsonb +- meta jsonb + +### 7.2 新增 `trading_plans` + +用途： + +- 保存盘前计划。 + +核心字段： + +- instrument_id +- plan_date +- plan_type +- narrative_code +- primary_draw jsonb +- secondary_draw jsonb +- bias +- execution_intensity +- allowed_sessions jsonb +- invalidations jsonb +- no_trade_conditions jsonb +- status +- ai_summary +- evidence jsonb +- created_at + +### 7.3 新增 `trade_plan_candidates` + +用途： + +- 保存盘中机会候选。 + +核心字段： + +- trading_plan_id +- instrument_id +- model_code +- side +- session_code +- candidate_state +- confirmation_state +- quality_score +- entry_low +- entry_high +- stop_loss +- tp1 +- tp2 +- rr_tp1 +- rr_tp2 +- expiry_ts +- invalidations jsonb +- management_rules jsonb +- evidence jsonb +- ai_explanation + +### 7.4 调整 `trade_signals` + +方向： + +- `trade_signals` 不再作为“泛信号候选”，而是作为已经通过计划和确认链的执行候选。 +- 新字段或 meta 必须包含： + - trading_plan_id + - candidate_id + - primary_draw + - target_plan + - risk_governor_decision + - confirmation_quality + +### 7.5 调整 `trade_executions` + +方向： + +- 从模拟执行记录升级为订单生命周期记录。 + +新增语义： + +- execution_ticket_id +- confirmation_required +- confirmed_by +- confirmed_at +- broker_order_ids +- bracket_state +- fill_state +- position_state +- close_reason +- reconciliation_state + +### 7.6 新增 `trading_journal_entries` + +用途： + +- 保存盘后复盘。 + +核心字段： + +- trade_signal_id +- execution_id +- plan_id +- model_code +- compliance_state +- model_failure +- execution_violation +- risk_violation +- review_tags jsonb +- metrics jsonb +- ai_review +- next_actions jsonb + +## 8. API 设计 + +### 8.1 盘前计划 + +```text +POST /trading/plans/generate +GET /trading/plans/latest +GET /trading/plans/{id} +POST /trading/plans/{id}/activate +POST /trading/plans/{id}/cancel +``` + +### 8.2 盘中监控 + +```text +GET /trading/market-state +POST /trading/watch/run +GET /trading/candidates +GET /trading/candidates/{id} +POST /trading/candidates/{id}/confirm-check +``` + +### 8.3 交易计划票 + +```text +POST /trading/candidates/{id}/build-ticket +GET /trading/tickets +GET /trading/tickets/{id} +POST /trading/tickets/{id}/risk-check +``` + +### 8.4 执行 + +```text +POST /trading/tickets/{id}/paper-execute +POST /trading/tickets/{id}/semi-auto-submit +POST /trading/tickets/{id}/confirm +POST /trading/executions/{id}/cancel +POST /trading/executions/{id}/sync +``` + +### 8.5 复盘 + +```text +POST /trading/journal/generate +GET /trading/journal +GET /trading/journal/summary +GET /trading/research/weekly-review +``` + +## 9. 前端工作台 + +当前前端不应做成普通 dashboard，而应做成实盘工作台。 + +### 9.1 顶部状态条 + +展示： + +- symbol +- session +- data freshness +- news state +- account risk state +- open position +- kill switch + +### 9.2 盘前计划区 + +展示： + +- Narrative +- primary Draw +- secondary Draw +- Bias +- allowed sessions +- no-trade conditions +- invalidation + +### 9.3 盘中候选区 + +展示： + +- setup candidate +- confirmation chain +- quality score +- missing requirements +- evidence links + +### 9.4 执行票区 + +展示： + +- side +- entry zone +- stop +- TP1 / TP2 +- RR +- risk amount +- expiry +- management rules +- risk governor result + +### 9.5 仓位管理区 + +展示： + +- current position +- fill state +- TP progress +- stop state +- invalidation alerts +- cancel / close / sync actions + +### 9.6 盘后复盘区 + +展示： + +- model compliance +- risk compliance +- execution violations +- model failure vs execution failure +- next actions + +## 10. 实施阶段 + +## Phase 0：文档收束与旧方案冻结 + +目标： + +- 删除旧的分散 docs。 +- 保留书稿和本计划。 +- 后续所有实盘主线开发引用本计划。 + +交付： + +- `docs/ICT交易全书_出版终校版.md` +- `docs/AI_ICT_实盘交易分析系统开发计划_v1.md` + +验收： + +- docs 下不再混放旧方案。 + +## Phase 1：Trading Plan 核心结构 + +目标： + +- 让系统先会写“盘前计划”，而不是直接生成信号。 + +任务： + +1. 新增 `trading_plans` migration / model / repository。 +2. 新增 `TradingPlanService`。 +3. 把现有 range / liquidity / MSS / FVG / session 汇总成计划输入。 +4. 生成结构化 plan： + - Narrative + - primary Draw + - secondary Draw + - Bias + - allowed sessions + - invalidations + - no-trade conditions +5. 新增计划单元测试。 + +验收： + +- 能生成当天 BTC / ETH 的结构化交易计划。 +- 计划中必须有 Draw 和 Invalidation。 +- 缺 Draw 或 Invalidation 时，计划不得进入 active。 + +## Phase 2：Market State 与 Risk Governor + +目标： + +- 建立实盘执行前的事实和风险闸门。 + +任务： + +1. 新增 `MarketStateService`。 +2. 新增行情 freshness 检查。 +3. 新增 session state。 +4. 新增 news window / opening volatility 占位接口。 +5. 新增 `RiskGovernorService`。 +6. 把现有 `AccountRiskState` 扩展为完整 `RiskContext`。 +7. 为每个拒绝原因建立稳定 code。 + +验收： + +- 风险闸门能独立运行。 +- 数据陈旧时拒绝执行。 +- 新闻窗口 active 时拒绝新开仓。 +- 低质量 backtest gate 时拒绝 semi-auto。 + +## Phase 3：Trade Plan Candidate + +目标： + +- 把 setup 从“信号”升级为“交易计划候选”。 + +任务： + +1. 新增 `trade_plan_candidates`。 +2. 新增 `SetupWatcherService`。 +3. 新增 `ConfirmationService`。 +4. 第一模型锁定： + - OSOK / Daily Range + - Sweep + - MSS + - FVG retrace +5. 候选必须绑定 active trading plan。 +6. 候选必须绑定 confirmation state。 + +验收： + +- 没有 active plan 不生成 candidate。 +- 缺 sweep / MSS / FVG 不生成 executable candidate。 +- 候选可以说明缺少哪些确认条件。 + +## Phase 4：目标与退出重构 + +目标： + +- TP1 / TP2 从固定百分比改为书本式 IRL / ERL。 + +任务： + +1. 新增 `TargetSelectionService`。 +2. 从 liquidity pools / dealing ranges / session pivots / ADR / STD 中选择目标。 +3. TP1 优先内部目标。 +4. TP2 优先外部目标。 +5. 增加 `management_rules`： + - TP1 partial + - move stop + - invalidate on reclaim + - expire by session + +验收： + +- 交易计划没有结构目标时不得执行。 +- TP1 / TP2 必须能追溯来源。 +- 退出规则必须进入 backtest 和 execution meta。 + +## Phase 5：Backtest 升级为 Plan Replay + +目标： + +- 回测不再只测 signal，而是测完整 trading plan candidate。 + +任务： + +1. 支持 `trading_plan_id` 维度。 +2. 支持 plan active 后逐根 replay。 +3. 记录 candidate 何时出现、何时确认、何时入场、何时失效。 +4. 统计： + - plan win rate + - candidate confirmation rate + - executed expectancy + - model compliance + - session performance + - draw target hit rate + +验收： + +- 回测能证明某个模型是否值得进入 semi-auto。 +- quality gate 基于 executed sample，而不是泛信号数量。 +- 输出可解释失败原因。 + +## Phase 6：Semi-auto Execution Ticket + +目标： + +- 形成安全的人工确认执行票。 + +任务： + +1. 新增 execution ticket。 +2. ticket 生成前跑 Risk Governor。 +3. ticket 确认前再次跑 Risk Governor。 +4. 半自动确认记录： + - confirmed_by + - confirmed_at + - ticket_snapshot +5. 支持 paper execute。 +6. 支持 semi-auto pending。 + +验收： + +- 未确认不得进入 semi-auto pending。 +- 风险检查失败不得创建 execution。 +- execution ticket 可完整复盘。 + +## Phase 7：Live Adapter 预备层 + +目标： + +- 为未来真实交易所执行建立接口，但不默认开启。 + +任务： + +1. 定义 `BrokerAdapter` 接口。 +2. 定义 OKX order adapter 占位。 +3. 支持 bracket / OCO 语义。 +4. 支持 order reconciliation。 +5. 支持 cancel all。 +6. 支持 kill switch。 +7. 默认 `LIVE_TRADING_ENABLED=0`。 + +验收： + +- live adapter 不会被误触发。 +- 无显式环境变量和人工确认不能下真实单。 +- 所有 live 操作有审计记录。 + +## Phase 8：Journal 与 Weekly Review + +目标： + +- 把实盘行为变成可迭代研究闭环。 + +任务： + +1. 新增 `trading_journal_entries`。 +2. 自动生成单笔复盘。 +3. 区分： + - model failure + - execution violation + - risk violation + - plan violation +4. 生成周报： + - 框架内执行率 + - 模型外交易率 + - 风险违规次数 + - high quality session + - low quality session + - 下周三条调整动作 + +验收： + +- 每笔交易都有 journal。 +- 每周能输出复盘 summary。 +- 系统能指出下一轮应该改什么，而不是只展示盈亏。 + +## 11. 最小可实盘版本定义 + +MVP 不等于 live auto trading。 + +最小可实盘版本定义为： + +1. 能生成当天 active trading plan。 +2. 能监控 plan 内 candidate。 +3. 能给出 confirmation chain。 +4. 能生成 execution ticket。 +5. Risk Governor 能拒绝不合格交易。 +6. 人工确认后能 paper / semi-auto 记录。 +7. 能按计划管理 TP1 / TP2 / invalidation。 +8. 能生成盘后 journal。 + +不包含： + +- 全自动真实下单。 +- 多策略自动切换。 +- LLM 自由生成交易方向。 +- 高频 scalping。 +- 未经验证的新模型上线。 + +## 12. 推荐立即执行顺序 + +第一轮建议只做以下 5 个文件/模块层： + +1. `trading_plans` +2. `market_states` +3. `risk_governor` +4. `trade_plan_candidates` +5. `execution_tickets` + +不要先做： + +- 更多 ICT 术语识别器。 +- 大型前端重写。 +- live 下单。 +- Training 产品增强。 + +## 13. 第一轮验收清单 + +第一轮完成时，必须能回答： + +1. 今天系统给出的 Narrative 是什么？ +2. 主 Draw 是哪个目标？ +3. Bias 是什么？为什么？ +4. 当前是否允许交易？为什么？ +5. 如果出现机会，确认链缺什么？ +6. 如果确认链完整，entry / stop / TP1 / TP2 来自哪里？ +7. 风险闸门是否放行？如果拒绝，原因是什么？ +8. 这笔交易若执行，如何退出？ +9. 这笔交易若失败，是模型失败还是执行违规？ + +如果这 9 个问题不能结构化回答，系统还不具备实盘交易分析能力。 + +## 14. 当前结论 + +最重要的方向调整是： + +```text +从“事件识别优先” +切换到 +“交易计划与执行授权优先” +``` + +现有代码底座可以保留，但主线要变成： + +```text +Trading Plan +-> Candidate Watch +-> Confirmation +-> Risk Governor +-> Execution Ticket +-> Position Management +-> Journal +``` + +这条线更贴近《ICT交易全书》的核心精神，也更接近真正可用的实盘交易分析系统。 diff --git a/docs/AI_ICT_当前开发方案_v2.md b/docs/AI_ICT_当前开发方案_v2.md deleted file mode 100644 index bfa1783..0000000 --- a/docs/AI_ICT_当前开发方案_v2.md +++ /dev/null @@ -1,229 +0,0 @@ -# AI ICT 当前开发方案 v2 - -## 1. 方案目标 - -本文档用于替代已经过时的“项目启动期”规划文档，在当前代码现实下重新定义项目需求边界、优先级和开发顺序。 - -当前项目不是从零开始，而是已经形成两条主线： - -- 交易主线：已打通从市场数据到回测、报告、paper/semi-auto execution 的最小闭环。 -- 训练主线：已形成对外产品模块，公开成熟度通过 M40。 - -因此，新方案必须以“质量增强、状态收敛、可验证推进”为主，而不是重复基础搭建。 - -## 2. 当前项目现实 - -### 2.1 交易主线现状 - -已具备： - -- `OKX -> candles -> market_sessions -> swings -> dealing_ranges -> liquidity_pools -> sweep_events -> displacement_events -> MSS -> FVG -> bias -> signals -> backtest` -- execution / settlement / report / dashboard 的第一版闭环 -- offline checks、质量门槛、脚本静态检查和无人流程入口 - -当前主要问题不再是“有没有模块”，而是： - -1. 回测是否真正无未来函数、足够接近真实决策过程。 -2. 结构状态是否足够稳定，便于 signal 和 training 复用。 -3. execution / report 是否已经建立可信的后验解释链。 - -### 2.2 训练主线现状 - -已具备： - -- 公开 API 路由 -- Training dashboard 面板 -- offline package import/export -- public error contract -- privacy contract coverage -- 文档成熟度通过 `M40` - -结论： - -- Training 不是空白模块。 -- 当前不应优先再扩大量新功能。 -- Training 的新增能力应建立在交易规则语义稳定的前提上。 - -## 3. 对旧方案的判断 - -### 3.1 仍然合理、继续保留的部分 - -以下原则继续成立： - -1. 双主线边界必须严格保持：Training 只读消费 Trading，上游和下游不能反向污染。 -2. 先规则、再信号、再回测、再执行的工程顺序是对的。 -3. offline validation 和可回滚原则必须继续保持。 -4. 当前阶段仍不应进入真实全自动交易。 - -### 3.2 需要明确修正的部分 - -以下旧文档判断已不再合理： - -1. 把项目视作“刚启动，需要先建骨架和第一批表”的规划已过期。 -2. 把 Training 当作尚未落地的 MVP 0->1 项目已不准确；它已是已交付模块，当前应以维护和输入质量提升为主。 -3. 继续优先补更多 planning/checklist 文档，不如直接提升交易主线的可验证质量。 -4. 在 replay/backtest 可信度不足前，继续扩展 execution 自动化或大型 Training 新功能，收益低且风险高。 - -## 4. 新的开发优先级 - -当前建议优先级： - -### P0 文档治理与当前入口收敛 - -目标： - -- 清理重复、过期、历史快照文档 -- 只保留当前有效入口 -- 固定 active / archive 边界 - -状态： - -- 本轮执行 - -### P1 交易主线回测真实性 - -目标： - -- 让回测从“结果可算”提升到“过程可信” - -重点： - -1. 把 replay/no-lookahead 能力接入 backtest 路径 -2. 明确 frame、decision point、confirmation window 的统一口径 -3. 让 backtest 结果可解释地对应当时可见的信息集合 - -为什么先做这个： - -- 这是交易主线当前最大真实性缺口 -- 也是 Training 案例生成和评分可信度的上游基础 - -### P2 交易规则状态质量 - -目标： - -- 提高结构事件的稳定性和下游可用性 - -重点： - -1. liquidity equal highs / lows merge 与去重 -2. MSS accepted / rejected / invalidated 语义收敛 -3. FVG mitigation / invalidation / gap warning 元数据向下游传播 -4. signal evidence completeness 与 session gate 继续收紧 - -### P3 执行与报告语义闭环 - -目标： - -- 让 execution 和 report 更贴近真实后验复盘 - -重点： - -1. position lifecycle / settlement 语义继续细化 -2. backtest / execution / report 的指标口径统一 -3. 增加按 session、weekday、symbol 的质量拆分统计 - -### P4 Training 维护与小步增强 - -目标： - -- 保持 M40 公开契约稳定，同时只做低风险增强 - -重点： - -1. 保持 dashboard / API / package / privacy / error contract 绿色 -2. 优先做 case quality 提升，而不是扩更多前台功能 -3. 只有当 P1-P2 稳定后，才扩展新的自动 case generator 能力 - -## 5. 新阶段划分 - -## 阶段 A：文档治理 - -交付物： - -- 新文档索引 -- archive 结构 -- 过期/重复/历史文档归档 - -验收： - -- `docs/` 根目录阅读路径清晰 -- active 文档与 archive 文档边界明确 - -## 阶段 B：Replay-backed Backtest - -交付物： - -- replay/no-lookahead 路径接入 backtest 服务或独立 backtest 入口 -- 定向单元测试 -- offline 验证命令 - -验收： - -- 回测在 decision point 之后不读取未来信息 -- replay 结果可输出质量门槛与失败原因 - -## 阶段 C：Rule State Hardening - -交付物： - -- liquidity / MSS / FVG 状态增强 -- signal evidence / session gating 补强 - -验收： - -- 结构状态更可追踪 -- signal 过滤理由更清晰 - -## 阶段 D：Execution / Report Hardening - -交付物： - -- 更细 execution lifecycle -- 更一致的 backtest/report 统计 - -验收： - -- report 能更直接对应 backtest 与 execution 结果 - -## 阶段 E：Training Upstream Quality Lift - -交付物： - -- 基于更稳定规则事件的 case quality 增强 -- 必要时扩展训练案例生成器 - -验收： - -- 不破坏 M40 公开契约 -- 训练案例更贴近真实高质量结构事件 - -## 6. 当前非目标 - -当前明确不做： - -1. 真实全自动下单 -2. 以 Training 用户行为反向影响交易决策 -3. 大规模新增 Training 产品面功能 -4. 仅为“文档完整”而继续堆积启动期/计划期文档 - -## 7. 当前建议的下一步开发任务 - -按照本方案，下一步应该直接进入： - -`Replay-backed Backtest` - -具体第一刀： - -1. 为 backtest 增加 replay/no-lookahead 入口或模式。 -2. 让回测在每个 decision point 只看到当时可见 candles / swings / 结构状态。 -3. 为该路径补 focused unit tests 和 offline validation。 - -## 8. 当前验证基线 - -在进入下一轮代码开发前，继续以以下命令作为最小验证基线： - -```bash -.venv/bin/python3 -m unittest discover -s tests/unit -p "test_*.py" -.venv/bin/python3 scripts/run_offline_checks.py -.venv/bin/python3 scripts/check_local_demo_readiness.py -``` diff --git a/docs/AI_ICT_总体设计文档_v1.md b/docs/AI_ICT_总体设计文档_v1.md deleted file mode 100644 index b992eeb..0000000 --- a/docs/AI_ICT_总体设计文档_v1.md +++ /dev/null @@ -1,516 +0,0 @@ -# AI ICT 交易辅助系统总体设计文档 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 交易辅助系统第一阶段的总体设计，目标是把 ICT 交易知识转化为可执行、可回测、可复盘、可风控的工程系统。 - -第一阶段不追求全自动交易，而是优先构建： - -1. 统一市场数据底座 -2. ICT 规则识别引擎 -3. 结构化 Bias / Signal 生成 -4. 半自动执行与严格风控 -5. 可审计、可复盘的报告体系 - -系统核心原则： - -- API 优先，不以桌面点击为主执行通道 -- 规则引擎主判定，AI 负责解释和总结 -- 先回测验证，再半自动，再考虑自动化 -- 所有交易建议都必须结构化、可审计 - ---- - -## 2. 数据库选型 - -本项目选用 PostgreSQL，不选 Oracle。 - -### 2.1 选择 PostgreSQL 的原因 - -1. 更适合时间序列数据 - - K 线、结构事件、信号快照天然适合 PostgreSQL - - 支持分区表、物化视图、窗口函数 - -2. 更适合半结构化数据 - - Narrative、evidence、回测标签、AI 报告摘要适合 `jsonb` - -3. 更适合策略研发迭代 - - 交易研发阶段 schema 变化频繁 - - PostgreSQL 迭代成本低，生态更灵活 - -4. Python / 数据分析生态更友好 - - 便于后续接入 Pandas、Polars、SQLAlchemy、Airflow / APScheduler 等 - -### 2.2 Oracle 不作为当前主库的原因 - -- 更适合重企业流程和传统核心业务 -- 对策略研发和事件型数据建模不如 PostgreSQL 灵活 -- 当前阶段会增加建模和调整成本 - -结论： - -- 主库：PostgreSQL -- Oracle：当前阶段不采用 - ---- - -## 3. 系统目标与边界 - -## 3.1 第一阶段目标 - -构建一个 AI ICT 交易辅助系统 MVP，支持： - -- BTC -- ETH -- XAU - -支持能力： - -- 行情采集 -- 会话划分 -- Swing / Range / Liquidity / Sweep / MSS / FVG 识别 -- Bias / Signal 生成 -- 回测与复盘 -- 半自动执行 - -## 3.2 第一阶段不做 - -- 不做自由发挥式 AI 主判单 -- 不做全自动实盘交易 -- 不以桌面自动点击作为主执行方式 -- 不把 SMT 作为核心独立入场信号 -- 不先做多模型自治系统 - ---- - -## 4. 总体架构 - -```text -[交易所 API] - | - v -[行情采集层] - | - v -[市场数据层] - |- candles - |- sessions - |- instrument metadata - |- market calendar - | - v -[规则识别层] - |- swings - |- dealing ranges - |- session pivots - |- liquidity pools - |- sweep events - |- displacement - |- MSB/MSS - |- FVG/BPR - | - v -[叙事/信号层] - |- daily bias - |- narrative snapshot - |- signal generation - | - v -[执行与风控层] - |- paper trading - |- semi-auto execution - |- risk engine - |- audit log - | - v -[报告与复盘层] - |- pre-market plan - |- intraday explanation - |- post-trade review - |- backtest analytics -``` - ---- - -## 5. 模块划分 - -### 5.1 market-data-service - -职责： - -- 拉取 OKX / LMAX 行情 -- 标准化 K 线 -- 生成 session 数据 -- 生成交易日边界 -- 入库 PostgreSQL - -输入： - -- OKX API -- LMAX API - -输出： - -- candles -- market_sessions -- instruments metadata - -### 5.2 rule-engine-service - -职责： - -- 识别 swing -- 识别 dealing range -- 识别 session pivots -- 识别 liquidity pools -- 识别 sweep -- 识别 displacement -- 识别 MSB / MSS -- 识别 FVG / BPR - -输出： - -- swings -- dealing_ranges -- liquidity_pools -- sweep_events -- displacement_events -- structure_events -- fvg_zones - -### 5.3 signal-service - -职责： - -- 汇总高低周期上下文 -- 计算 daily bias -- 生成 narrative snapshot -- 产生交易信号 -- 维护 signal 状态机 - -输出： - -- bias_snapshots -- trade_signals - -### 5.4 execution-service - -职责： - -- 模拟下单 -- 半自动下单 -- 止损止盈管理 -- 风控拦截 -- 审计日志 - -输出： - -- trade_executions -- risk decisions -- audit records - -### 5.5 report-service - -职责： - -- 生成盘前计划 -- 生成盘中解释 -- 生成盘后复盘 -- 生成回测统计摘要 -- 向 LLM 提供结构化输入 - ---- - -## 6. 周期职责分层 - -参考 ICT Top-Down 分层，执行原则为：下层优化执行，不越权改向。 - -### 6.1 默认职责 - -- D / H4：背景、方向、主叙事 -- H1 / M15：路径、工作区间、主 Draw -- M5 / M1：触发、执行、风控 - -### 6.2 MVP 默认配置 - -#### BTC / ETH - -- bias_tf: H4 -- range_tf: H1 -- setup_tf: M15 -- trigger_tf: M5 - -#### XAU - -- bias_tf: H1 -- range_tf: M15 -- setup_tf: M5 -- trigger_tf: M1 - ---- - -## 7. 会话模型设计 - -结合参考指标文件，第一版采用以下默认会话，时区统一为 `America/New_York`。 - -### 7.1 默认会话 - -- ASIA: 20:00 - 00:00 -- LONDON: 02:00 - 05:00 -- NY_AM: 09:30 - 11:00 -- NY_LUNCH: 12:00 - 13:00 -- NY_PM: 13:30 - 16:00 - -### 7.2 执行含义 - -- ASIA：观察、构建范围、形成库存 -- LONDON：优先观察 sweep 与首段位移 -- NY_AM：延续或重构的高质量窗口 -- NY_LUNCH：默认降频、只做管理或等待 -- NY_PM：延续或重构的次高优先窗口 - -### 7.3 会话模块输出 - -- session high -- session low -- midpoint -- mitigated status -- broken status -- execution permission - ---- - -## 8. 规则优先级 - -第一版只围绕一个主模型： - -`Sweep -> MSS -> FVG Retrace -> IRL/ERL` - -### 8.1 第一批必须实现的规则 - -1. candles -2. market sessions -3. swings -4. dealing ranges -5. liquidity pools -6. sweep events -7. displacement -8. MSB / MSS -9. FVG -10. bias snapshots -11. trade signals - -### 8.2 暂缓实现的规则 - -- Order Block 作为主触发 -- Breaker / Mitigation Block 深化建模 -- SMT 作为主信号 -- 跨市场复杂联动 -- 多模型并行自治 - ---- - -## 9. 信号生成主链路 - -```text -行情入库 --> 生成会话数据 --> 识别 swings --> 识别 dealing range --> 标注 liquidity pools --> 判断是否 sweep --> 判断 displacement --> 判断 MSB / MSS --> 识别 FVG --> 汇总 higher timeframe bias --> 生成 trade signal --> 人工确认 --> 执行 --> 记录结果 -``` - ---- - -## 10. Signal 状态机 - -```text -draft --> awaiting_context --> awaiting_confirmation --> active --> tp1_hit --> tp2_hit --> invalidated --> expired --> cancelled -``` - -说明： - -- draft：局部结构已出现，但条件未闭合 -- awaiting_context：缺高周期背景或 bias -- awaiting_confirmation：上游条件成立，等待回补触发 -- active：已进场 -- tp1_hit：已达 IRL -- tp2_hit：已达 ERL -- invalidated：叙事被否定 -- expired：超时段未触发 -- cancelled：人工取消 - ---- - -## 11. 风控设计 - -风控必须独立于 AI，不允许被聊天逻辑覆盖。 - -### 11.1 账户级风控 - -- 单笔风险 <= 0.25% 或 0.5% -- 日亏损上限 <= 1.5% ~ 2% -- 连续亏损达到阈值后停止 -- 同方向暴露受限 -- 同时持仓数量受限 - -### 11.2 信号级风控 - -- 无 stop 不下单 -- RR 不足不下单 -- 非允许会话不下单 -- bias neutral 默认不主动开仓 -- 重大新闻时间窗禁开新仓 - -### 11.3 风控检查接口 - -`risk_check(signal, account_state, market_state) -> allow / reject / downgrade` - ---- - -## 12. AI 的职责边界 - -AI 只负责： - -1. 解释规则结果 -2. 生成盘前计划 -3. 生成盘中说明 -4. 生成盘后复盘 -5. 总结错误模式 - -AI 不负责： - -- 绕过规则直接下单 -- 覆盖风控决策 -- 以自由文本替代结构事件 - -原则： - -- 规则引擎负责“判定” -- AI 负责“说明” - ---- - -## 13. 前端建议 - -第一版建议一个轻量 Web 控制台，包含： - -1. Dashboard - - 当前 bias - - 当前 session - - 当前候选信号 - -2. Context - - current dealing range - - session pivots - - liquidity pools - - sweeps - - MSS - - FVG - -3. Signals - - 全部候选信号 - - 状态流转记录 - -4. Execution - - 模拟 / 半自动下单 - - 仓位与风控结果 - -5. Backtest - - 模型结果统计 - - 按 session / symbol / timeframe 分析 - -6. Reports - - AI 报告 - - 复盘记录 - ---- - -## 14. 里程碑计划 - -### M1 基础数据 - -- PostgreSQL schema 初始化 -- instrument 配置 -- candles 入库 -- session 生成器 - -### M2 基础规则 - -- swings -- dealing ranges -- session pivots -- liquidity pools - -### M3 核心触发 - -- sweep -- displacement -- MSB / MSS -- FVG - -### M4 信号层 - -- bias snapshots -- trade signal 生成 -- 失效规则 -- TP1 / TP2 - -### M5 验证层 - -- 回测 -- MFE / MAE -- error tags -- 报告生成 - -### M6 执行层 - -- paper trading -- semi-auto execution -- 审计日志 - ---- - -## 15. 当前开发优先级 - -按基础共享模块优先： - -1. candles -2. market_sessions -3. swings -4. dealing_ranges -5. liquidity_pools - -这些模块是后续全部规则和信号的前提，必须先稳定。 - ---- - -## 16. 当前结论 - -第一阶段的核心不是“做一个会下单的 AI”，而是： - -> 把 ICT 交易认知变成结构化规则系统，并在 PostgreSQL 上建立可回测、可复盘、可审计的工程底座。 - -后续所有开发都应以此文档为总参考，并优先保证： - -- 数据一致性 -- 规则可解释性 -- 风控刚性 -- 回测与实盘口径一致 diff --git a/docs/AI_ICT_数据库_Migration_SQL_草案_v1.md b/docs/AI_ICT_数据库_Migration_SQL_草案_v1.md deleted file mode 100644 index ec38c48..0000000 --- a/docs/AI_ICT_数据库_Migration_SQL_草案_v1.md +++ /dev/null @@ -1,454 +0,0 @@ -# AI ICT 数据库 Migration SQL 草案 v1 - -## 1. 文档目标 - -本文档把前面已经确定的 PostgreSQL Schema 与 Migration 拆分计划进一步落到可执行 SQL 草案层，供后续正式 migration 文件编写时直接参考。 - -本草案聚焦第一轮最小可落地范围： - -1. `venues` -2. `instruments` -3. `candles` -4. `market_sessions` -5. `swings` -6. `dealing_ranges` -7. `liquidity_pools` - -目标是先打通： - -`PostgreSQL -> Candles -> Sessions -> Swings -> Dealing Range -> Liquidity Pools` - ---- - -## 2. 使用原则 - -1. 本文档是 SQL 草案，不代表最终 migration 工具格式 -2. 正式落地时可拆分成多份 migration 文件 -3. 先保留 PostgreSQL 原生 SQL 语义，避免过早绑定 ORM -4. 所有时间字段使用 `timestamptz` -5. 数值价格字段使用 `numeric` - ---- - -## 3. migration_001_create_venues - -```sql -create table if not exists venues ( - id bigserial primary key, - code text not null unique, - name text not null, - timezone text not null, - status text not null default 'active', - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); -``` - -### 说明 - -- `code` 用于程序引用，例如 `OKX`, `LMAX` -- `timezone` 保存交易所或主业务时区信息 -- `status` 暂保持文本，后续如稳定再改枚举 - ---- - -## 4. migration_002_create_instruments - -```sql -create table if not exists instruments ( - id bigserial primary key, - venue_id bigint not null references venues(id), - symbol text not null, - asset_class text not null, - base_asset text, - quote_asset text, - price_scale integer not null, - qty_scale integer not null, - tick_size numeric(20,10) not null, - lot_size numeric(20,10), - active boolean not null default true, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now(), - unique (venue_id, symbol) -); -``` - -### 建议索引 - -```sql -create index if not exists idx_instruments_venue_id on instruments(venue_id); -create index if not exists idx_instruments_active on instruments(active); -``` - ---- - -## 5. migration_003_create_candles - -### 5.1 主表 - -```sql -create table if not exists candles ( - id bigserial not null, - instrument_id bigint not null references instruments(id), - timeframe text not null, - ts_open timestamptz not null, - ts_close timestamptz not null, - open numeric(20,10) not null, - high numeric(20,10) not null, - low numeric(20,10) not null, - close numeric(20,10) not null, - volume numeric(28,10), - source text not null default 'api', - created_at timestamptz not null default now(), - primary key (id, ts_open), - unique (instrument_id, timeframe, ts_open) -) partition by range (ts_open); -``` - -### 5.2 说明 - -- `candles` 是最核心的大表，按 `ts_open` 做 range partition -- 第一阶段可接受联合主键，只要唯一约束稳定 -- 若后续 ORM 对分区主键有特殊要求，可再调整 - ---- - -## 6. migration_004_create_candles_partitions_and_indexes - -### 6.1 示例分区 - -```sql -create table if not exists candles_2026_04 -partition of candles -for values from ('2026-04-01 00:00:00+00') to ('2026-05-01 00:00:00+00'); - -create table if not exists candles_2026_05 -partition of candles -for values from ('2026-05-01 00:00:00+00') to ('2026-06-01 00:00:00+00'); -``` - -### 6.2 索引 - -```sql -create index if not exists idx_candles_instrument_tf_open_desc -on candles (instrument_id, timeframe, ts_open desc); - -create index if not exists idx_candles_instrument_tf_close_desc -on candles (instrument_id, timeframe, ts_close desc); -``` - -### 6.3 检查约束（可选） - -```sql -alter table candles - add constraint candles_high_ge_low check (high >= low); - -alter table candles - add constraint candles_high_ge_open check (high >= open); - -alter table candles - add constraint candles_high_ge_close check (high >= close); - -alter table candles - add constraint candles_low_le_open check (low <= open); - -alter table candles - add constraint candles_low_le_close check (low <= close); -``` - -说明： - -- 若担心历史脏数据导入失败，可先不加 check，后续数据稳定后再加 - ---- - -## 7. migration_005_create_market_sessions - -```sql -create table if not exists market_sessions ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - session_date date not null, - timezone text not null, - session_code text not null, - start_ts timestamptz not null, - end_ts timestamptz not null, - high numeric(20,10), - low numeric(20,10), - midpoint numeric(20,10), - status text not null default 'closed', - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now(), - unique (instrument_id, session_date, session_code, timezone) -); -``` - -### 建议索引 - -```sql -create index if not exists idx_market_sessions_instr_date -on market_sessions (instrument_id, session_date desc); - -create index if not exists idx_market_sessions_instr_code_date -on market_sessions (instrument_id, session_code, session_date desc); -``` - ---- - -## 8. migration_006_create_swings - -```sql -create table if not exists swings ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - kind text not null, - strength text not null, - price numeric(20,10) not null, - ts timestamptz not null, - left_bars integer not null, - right_bars integer not null, - confirmed boolean not null default true, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); -``` - -### 建议索引 - -```sql -create index if not exists idx_swings_instr_tf_ts_desc -on swings (instrument_id, timeframe, ts desc); - -create index if not exists idx_swings_instr_tf_kind_ts_desc -on swings (instrument_id, timeframe, kind, ts desc); - -create index if not exists idx_swings_instr_tf_strength_ts_desc -on swings (instrument_id, timeframe, strength, ts desc); -``` - -### 可选检查约束 - -```sql -alter table swings - add constraint swings_kind_check - check (kind in ('swing_high', 'swing_low')); - -alter table swings - add constraint swings_strength_check - check (strength in ('ST', 'IT', 'LT')); -``` - ---- - -## 9. migration_007_create_dealing_ranges - -```sql -create table if not exists dealing_ranges ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - high numeric(20,10) not null, - low numeric(20,10) not null, - equilibrium numeric(20,10) not null, - high_swing_id bigint references swings(id), - low_swing_id bigint references swings(id), - state text not null default 'valid', - ts_start timestamptz not null, - ts_end timestamptz, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); -``` - -### 建议索引 - -```sql -create index if not exists idx_dealing_ranges_instr_tf_start_desc -on dealing_ranges (instrument_id, timeframe, ts_start desc); - -create index if not exists idx_dealing_ranges_instr_tf_state_start_desc -on dealing_ranges (instrument_id, timeframe, state, ts_start desc); -``` - -### 可选检查约束 - -```sql -alter table dealing_ranges - add constraint dealing_ranges_high_gt_low check (high > low); -``` - ---- - -## 10. migration_008_create_liquidity_pools - -```sql -create table if not exists liquidity_pools ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - side text not null, - pool_type text not null, - price_low numeric(20,10) not null, - price_high numeric(20,10) not null, - reference_ids jsonb not null default '[]'::jsonb, - status text not null default 'untouched', - created_ts timestamptz not null, - updated_ts timestamptz not null default now(), - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); -``` - -### 建议索引 - -```sql -create index if not exists idx_liquidity_pools_instr_tf_status_created_desc -on liquidity_pools (instrument_id, timeframe, status, created_ts desc); - -create index if not exists idx_liquidity_pools_instr_tf_side_created_desc -on liquidity_pools (instrument_id, timeframe, side, created_ts desc); -``` - -### 可选检查约束 - -```sql -alter table liquidity_pools - add constraint liquidity_pools_side_check - check (side in ('buy_side', 'sell_side')); - -alter table liquidity_pools - add constraint liquidity_pools_price_range_check - check (price_high >= price_low); -``` - ---- - -## 11. 初始种子数据草案 - -### 11.1 venues - -```sql -insert into venues (code, name, timezone) -values - ('OKX', 'OKX', 'UTC'), - ('LMAX', 'LMAX', 'UTC') -on conflict (code) do nothing; -``` - -### 11.2 instruments（示例） - -```sql -insert into instruments ( - venue_id, - symbol, - asset_class, - base_asset, - quote_asset, - price_scale, - qty_scale, - tick_size, - lot_size, - active, - meta -) -select - v.id, - 'BTC-USDT', - 'crypto', - 'BTC', - 'USDT', - 2, - 6, - 0.01, - 0.000001, - true, - jsonb_build_object('raw_inst_id', 'BTC-USDT-SWAP', 'product_type', 'swap') -from venues v -where v.code = 'OKX' -on conflict (venue_id, symbol) do nothing; -``` - -说明： - -- ETH 与 XAU 可按同样方式扩充 -- XAU 若合约尚未最终确定，建议先不插入 active=true 的正式 instrument - ---- - -## 12. 第一轮验证 SQL - -## 12.1 验证表存在 - -```sql -select tablename -from pg_tables -where schemaname = 'public' - and tablename in ( - 'venues', - 'instruments', - 'candles', - 'market_sessions', - 'swings', - 'dealing_ranges', - 'liquidity_pools' - ) -order by tablename; -``` - -## 12.2 验证唯一键 - -```sql -select indexname, indexdef -from pg_indexes -where tablename in ('candles', 'instruments', 'market_sessions') -order by tablename, indexname; -``` - -## 12.3 验证 candles 分区 - -```sql -select - parent.relname as parent_table, - child.relname as partition_table -from pg_inherits -join pg_class parent on pg_inherits.inhparent = parent.oid -join pg_class child on pg_inherits.inhrelid = child.oid -where parent.relname = 'candles'; -``` - ---- - -## 13. 正式迁移时的建议拆分 - -后续真正落 migration 文件时，建议按以下顺序拆分： - -1. `001_create_venues.sql` -2. `002_create_instruments.sql` -3. `003_create_candles.sql` -4. `004_create_candles_partitions_and_indexes.sql` -5. `005_create_market_sessions.sql` -6. `006_create_swings.sql` -7. `007_create_dealing_ranges.sql` -8. `008_create_liquidity_pools.sql` - -这样可以确保： - -- 先打通基础字典表 -- 再打通数据主链 -- 再进入基础规则主链 - ---- - -## 14. 当前结论 - -本 SQL 草案已经把前期方案文档推进到“可直接开始写 migration 文件”的程度。 - -第一阶段真正落地时，应先用本草案实现： - -`venues -> instruments -> candles -> market_sessions -> swings -> dealing_ranges -> liquidity_pools` - -只要这一段建库完成并验证通过，后续真实代码开发就可以直接进入数据接入和基础规则实现。 \ No newline at end of file diff --git a/docs/AI_ICT_文档索引与命名规范_v2.md b/docs/AI_ICT_文档索引与命名规范_v2.md deleted file mode 100644 index dc259bc..0000000 --- a/docs/AI_ICT_文档索引与命名规范_v2.md +++ /dev/null @@ -1,156 +0,0 @@ -# AI ICT 文档索引与命名规范 v2 - -## 1. 文档目标 - -本文档用于在当前代码现实下重建一份清晰、可维护的文档入口，解决以下问题： - -1. 根目录 `docs/` 文件过多，阅读入口不清晰。 -2. 存在重复命名、双语平行版本、历史快照和过期规划混放的问题。 -3. 旧规划文档仍停留在“项目启动期”，和当前代码已进入交易闭环与 Training M40 阶段不一致。 - -本版规则： - -- `docs/` 根目录只保留当前仍有直接指导意义的 active / canonical 项目文档。 -- 历史和过期规划统一进入 `docs/archive/`。 -- 通用工作流辅助文档统一进入 `docs/workflow/`。 -- 同一主题只允许一个当前主文件名。 - -## 2. 当前推荐阅读顺序 - -第一次进入项目，按以下顺序阅读： - -1. `AI_ICT_当前开发方案_v2.md` -2. `AI_ICT_交易模块缺口清单_v1.md` -3. `AI_ICT_双主线研发治理计划_v1.md` -4. `AI_ICT_主线进度摘要_v1.md` -5. `training_case_engine_m1_m6_product_readme.md` -6. `AI_ICT_总体设计文档_v1.md` -7. `AI_ICT_PostgreSQL_Schema_v1.md` -8. `AI_ICT_MVP_规则规格书_v1.md` - -如果要进入具体模块开发，再按模块规格书继续读： - -- `AI_ICT_OKX_数据接入规格书_v1.md` -- `AI_ICT_Session_生成器规格书_v1.md` -- `AI_ICT_Swing_识别规格书_v1.md` -- `AI_ICT_Dealing_Range_规格书_v1.md` -- `AI_ICT_Liquidity_Pool_规格书_v1.md` -- `AI_ICT_Sweep_识别规格书_v1.md` -- `AI_ICT_Displacement_规格书_v1.md` -- `AI_ICT_MSS_判定规格书_v1.md` -- `AI_ICT_FVG_规格书_v1.md` - -## 3. 当前 active / canonical 文档 - -### 3.1 项目治理与当前主计划 - -- `AI_ICT_当前开发方案_v2.md` - - 当前唯一的开发优先级与阶段计划入口。 -- `AI_ICT_交易模块缺口清单_v1.md` - - 当前交易模块的交付 blocker、已完成的 P0/P1 闭环状态，以及剩余 P2 能力补全清单。 -- `AI_ICT_双主线研发治理计划_v1.md` - - 交易主线和训练主线的边界治理规则。 -- `AI_ICT_主线进度摘要_v1.md` - - 当前代码闭环和结构状态的高层摘要。 - -### 3.2 训练产品当前入口 - -- `training_case_engine_m1_m6_product_readme.md` - - 当前对外可见的 Training M1-M40 成熟度、验证方式、公开契约入口。 -- `AI_ICT_Training_Case_Engine_外部产品化MVP计划_v1.md` - - Training 的产品边界和核心需求来源。 -- `AI_ICT_Training_Case_Engine_开发方案_v1.md` - - Training 模块内部结构与实体设计背景。 - -### 3.3 系统设计与数据库/规则主参考 - -- `AI_ICT_总体设计文档_v1.md` -- `AI_ICT_PostgreSQL_Schema_v1.md` -- `AI_ICT_MVP_规则规格书_v1.md` -- `AI_ICT_Migration_拆分计划_v1.md` -- `AI_ICT_数据库_Migration_SQL_草案_v1.md` -- `AI_ICT_第一批正式_Migration_文件草案_v1.md` -- `AI_ICT_第二批正式_Migration_文件草案_v1.md` - -### 3.4 交易模块规格书主参考 - -- `AI_ICT_OKX_数据接入规格书_v1.md` -- `AI_ICT_Session_生成器规格书_v1.md` -- `AI_ICT_Swing_识别规格书_v1.md` -- `AI_ICT_Dealing_Range_规格书_v1.md` -- `AI_ICT_Liquidity_Pool_规格书_v1.md` -- `AI_ICT_Sweep_识别规格书_v1.md` -- `AI_ICT_Displacement_规格书_v1.md` -- `AI_ICT_MSS_判定规格书_v1.md` -- `AI_ICT_FVG_规格书_v1.md` - -### 3.5 工作流辅助文档 - -以下文档仍保留，但已移出项目主阅读路径，统一放入 `docs/workflow/`： - -- `AI_协作自动化工作规程_v1.md` -- `AI_自动化协作迁移清单_v1.md` -- `CLAUDE_template_autonomy_first.md` -- `automation_workflow_migration_checklist.md` -- `标准_CLAUDE_md_模板_v1.md` - -## 4. 已归档类别 - -### 4.1 deleted duplicate-language / duplicate-theme files - -以下重复文件已直接删除，不再保留归档副本： - -- `AI_ICT_Codebase_Skeleton_Spec_v1.md` -- `AI_ICT_Dealing_Range_Spec_v1.md` -- `AI_ICT_PostgreSQL_Migration_SQL_Drafts_v1.md` -- `AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` -- `AI_ICT_Session_Generator_Spec_v1.md` -- `AI_ICT_Sweep_Identification_Spec_v1.md` -- `AI_ICT_Swing_Identification_Spec_v1.md` - -对应 canonical： - -- `AI_ICT_项目代码骨架规范_v1.md` -- `AI_ICT_Dealing_Range_规格书_v1.md` -- `AI_ICT_数据库_Migration_SQL_草案_v1.md` -- `AI_ICT_Migration_拆分计划_v1.md` -- `AI_ICT_Session_生成器规格书_v1.md` -- `AI_ICT_Sweep_识别规格书_v1.md` -- `AI_ICT_Swing_识别规格书_v1.md` - -删除依据： - -- 当前仓库已有明确主版本。 -- Git 历史已经保留被删版本。 -- 再保留物理副本只会继续制造阅读噪音。 - -### 4.2 obsolete plans - -以下文件已进入 `docs/archive/obsolete_plans/`： - -- `AI_ICT_开发路线图_v1.md` -- `AI_ICT_项目启动清单_v1.md` -- `AI_ICT_执行检查清单_v1.md` -- `AI_ICT_文档索引与命名规范_v1.md` -- `AI_ICT_重复文档清理计划_v1.md` - -这些文件的问题不是“没有价值”，而是都建立在项目尚处启动期或清理前的状态上，已不适合作为当前入口。 - -### 4.3 history - -以下文件已进入 `docs/archive/history/`： - -- `AI_ICT_主线开发检查点_v1.md` -- `AI_ICT_当前工作断点_2026-04-24.md` -- `AI_ICT_报告样本_2026-04-24.md` -- `AI_ICT_离线自动化推进记录_2026-04-29.md` - -这些文件保留历史上下文，但不再作为当前需求和计划入口。 - -## 5. 后续命名规则 - -1. 同一主题只保留一个当前 canonical 文件名。 -2. 重大重写使用 `v2`、`v3`，不要再创建平行同义文件。 -3. 双语平行版本不再在根目录长期并存；确定为重复后直接删除。 -4. 含明确日期的工作断点、报告样本、推进记录，默认进入 `archive/history/`。 -5. 只要文档不再匹配当前代码阶段，就必须归档或重写，不能继续留在根目录冒充当前计划。 diff --git a/docs/AI_ICT_第一批正式_Migration_文件草案_v1.md b/docs/AI_ICT_第一批正式_Migration_文件草案_v1.md deleted file mode 100644 index 346f0d3..0000000 --- a/docs/AI_ICT_第一批正式_Migration_文件草案_v1.md +++ /dev/null @@ -1,489 +0,0 @@ -# AI ICT 第一批正式 Migration 文件草案 v1 - -## 1. 文档目标 - -本文档把 `AI_ICT_数据库_Migration_SQL_草案_v1.md` 进一步拆成“文件级 migration 草案”，让后续真实项目实现时可以直接按文件落地。 - -目标： - -1. 固定第一批 migration 文件名 -2. 固定执行顺序 -3. 提供每个文件的建议 SQL 内容 -4. 提供每个文件的执行注意事项 -5. 让后续开发能直接从文档进入建库实现 - ---- - -## 2. 第一批 migration 范围 - -本批次只覆盖基础共享模块所需数据表： - -1. `venues` -2. `instruments` -3. `candles` -4. `market_sessions` -5. `swings` -6. `dealing_ranges` -7. `liquidity_pools` - -这是第一条必须打通的基础链路： - -`venues -> instruments -> candles -> market_sessions -> swings -> dealing_ranges -> liquidity_pools` - ---- - -## 3. 建议 migration 文件顺序 - -建议后续正式建库时使用以下文件顺序： - -1. `001_create_venues.sql` -2. `002_create_instruments.sql` -3. `003_create_candles.sql` -4. `004_create_candles_partitions_and_indexes.sql` -5. `005_create_market_sessions.sql` -6. `006_create_swings.sql` -7. `007_create_dealing_ranges.sql` -8. `008_create_liquidity_pools.sql` -9. `009_seed_venues.sql` -10. `010_seed_instruments.sql` - -说明： - -- 前 8 个是 schema migration -- 后 2 个是 seed migration -- 如果你后面使用某个 migration 工具，也建议保持同样的执行顺序编号 - ---- - -## 4. 001_create_venues.sql - -```sql -create table if not exists venues ( - id bigserial primary key, - code text not null unique, - name text not null, - timezone text not null, - status text not null default 'active', - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); -``` - -### 注意事项 - -- `code` 后续会成为程序引用键 -- 不建议后续轻易修改 `code` - ---- - -## 5. 002_create_instruments.sql - -```sql -create table if not exists instruments ( - id bigserial primary key, - venue_id bigint not null references venues(id), - symbol text not null, - asset_class text not null, - base_asset text, - quote_asset text, - price_scale integer not null, - qty_scale integer not null, - tick_size numeric(20,10) not null, - lot_size numeric(20,10), - active boolean not null default true, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now(), - unique (venue_id, symbol) -); - -create index if not exists idx_instruments_venue_id on instruments(venue_id); -create index if not exists idx_instruments_active on instruments(active); -``` - -### 注意事项 - -- `symbol` 必须是系统内部标准名，不建议直接等于交易所原始 instId -- 原始交易所代码建议放到 `meta` - ---- - -## 6. 003_create_candles.sql - -```sql -create table if not exists candles ( - id bigserial not null, - instrument_id bigint not null references instruments(id), - timeframe text not null, - ts_open timestamptz not null, - ts_close timestamptz not null, - open numeric(20,10) not null, - high numeric(20,10) not null, - low numeric(20,10) not null, - close numeric(20,10) not null, - volume numeric(28,10), - source text not null default 'api', - created_at timestamptz not null default now(), - primary key (id, ts_open), - unique (instrument_id, timeframe, ts_open) -) partition by range (ts_open); -``` - -### 注意事项 - -- 这是分区主表，不直接长期存放所有数据行 -- 真实数据主要写入各月分区 - ---- - -## 7. 004_create_candles_partitions_and_indexes.sql - -```sql -create table if not exists candles_2026_04 -partition of candles -for values from ('2026-04-01 00:00:00+00') to ('2026-05-01 00:00:00+00'); - -create table if not exists candles_2026_05 -partition of candles -for values from ('2026-05-01 00:00:00+00') to ('2026-06-01 00:00:00+00'); - -create index if not exists idx_candles_instrument_tf_open_desc -on candles (instrument_id, timeframe, ts_open desc); - -create index if not exists idx_candles_instrument_tf_close_desc -on candles (instrument_id, timeframe, ts_close desc); -``` - -### 可选扩展 - -如果想在第一批就加检查约束，可追加： - -```sql -alter table candles - add constraint candles_high_ge_low check (high >= low); - -alter table candles - add constraint candles_high_ge_open check (high >= open); - -alter table candles - add constraint candles_high_ge_close check (high >= close); - -alter table candles - add constraint candles_low_le_open check (low <= open); - -alter table candles - add constraint candles_low_le_close check (low <= close); -``` - -### 注意事项 - -- 若担心历史脏数据导入失败，检查约束可以放第二批 migration -- 分区创建建议始终超前至少一个月 - ---- - -## 8. 005_create_market_sessions.sql - -```sql -create table if not exists market_sessions ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - session_date date not null, - timezone text not null, - session_code text not null, - start_ts timestamptz not null, - end_ts timestamptz not null, - high numeric(20,10), - low numeric(20,10), - midpoint numeric(20,10), - status text not null default 'closed', - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now(), - unique (instrument_id, session_date, session_code, timezone) -); - -create index if not exists idx_market_sessions_instr_date -on market_sessions (instrument_id, session_date desc); - -create index if not exists idx_market_sessions_instr_code_date -on market_sessions (instrument_id, session_code, session_date desc); -``` - -### 注意事项 - -- 该表直接支撑 session generator 模块 -- `session_code` 后续建议只允许固定集合，例如 `ASIA`, `LONDON`, `NY_AM`, `NY_LUNCH`, `NY_PM` - ---- - -## 9. 006_create_swings.sql - -```sql -create table if not exists swings ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - kind text not null, - strength text not null, - price numeric(20,10) not null, - ts timestamptz not null, - left_bars integer not null, - right_bars integer not null, - confirmed boolean not null default true, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_swings_instr_tf_ts_desc -on swings (instrument_id, timeframe, ts desc); - -create index if not exists idx_swings_instr_tf_kind_ts_desc -on swings (instrument_id, timeframe, kind, ts desc); - -create index if not exists idx_swings_instr_tf_strength_ts_desc -on swings (instrument_id, timeframe, strength, ts desc); -``` - -### 可选检查约束 - -```sql -alter table swings - add constraint swings_kind_check - check (kind in ('swing_high', 'swing_low')); - -alter table swings - add constraint swings_strength_check - check (strength in ('ST', 'IT', 'LT')); -``` - ---- - -## 10. 007_create_dealing_ranges.sql - -```sql -create table if not exists dealing_ranges ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - high numeric(20,10) not null, - low numeric(20,10) not null, - equilibrium numeric(20,10) not null, - high_swing_id bigint references swings(id), - low_swing_id bigint references swings(id), - state text not null default 'valid', - ts_start timestamptz not null, - ts_end timestamptz, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); - -create index if not exists idx_dealing_ranges_instr_tf_start_desc -on dealing_ranges (instrument_id, timeframe, ts_start desc); - -create index if not exists idx_dealing_ranges_instr_tf_state_start_desc -on dealing_ranges (instrument_id, timeframe, state, ts_start desc); -``` - -### 可选检查约束 - -```sql -alter table dealing_ranges - add constraint dealing_ranges_high_gt_low check (high > low); -``` - ---- - -## 11. 008_create_liquidity_pools.sql - -```sql -create table if not exists liquidity_pools ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - side text not null, - pool_type text not null, - price_low numeric(20,10) not null, - price_high numeric(20,10) not null, - reference_ids jsonb not null default '[]'::jsonb, - status text not null default 'untouched', - created_ts timestamptz not null, - updated_ts timestamptz not null default now(), - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_liquidity_pools_instr_tf_status_created_desc -on liquidity_pools (instrument_id, timeframe, status, created_ts desc); - -create index if not exists idx_liquidity_pools_instr_tf_side_created_desc -on liquidity_pools (instrument_id, timeframe, side, created_ts desc); -``` - -### 可选检查约束 - -```sql -alter table liquidity_pools - add constraint liquidity_pools_side_check - check (side in ('buy_side', 'sell_side')); - -alter table liquidity_pools - add constraint liquidity_pools_price_range_check - check (price_high >= price_low); -``` - ---- - -## 12. 009_seed_venues.sql - -```sql -insert into venues (code, name, timezone) -values - ('OKX', 'OKX', 'UTC'), - ('LMAX', 'LMAX', 'UTC') -on conflict (code) do nothing; -``` - ---- - -## 13. 010_seed_instruments.sql - -### 13.1 BTC 示例 - -```sql -insert into instruments ( - venue_id, - symbol, - asset_class, - base_asset, - quote_asset, - price_scale, - qty_scale, - tick_size, - lot_size, - active, - meta -) -select - v.id, - 'BTC-USDT', - 'crypto', - 'BTC', - 'USDT', - 2, - 6, - 0.01, - 0.000001, - true, - jsonb_build_object('raw_inst_id', 'BTC-USDT-SWAP', 'product_type', 'swap') -from venues v -where v.code = 'OKX' -on conflict (venue_id, symbol) do nothing; -``` - -### 13.2 ETH 示例 - -```sql -insert into instruments ( - venue_id, - symbol, - asset_class, - base_asset, - quote_asset, - price_scale, - qty_scale, - tick_size, - lot_size, - active, - meta -) -select - v.id, - 'ETH-USDT', - 'crypto', - 'ETH', - 'USDT', - 2, - 6, - 0.01, - 0.000001, - true, - jsonb_build_object('raw_inst_id', 'ETH-USDT-SWAP', 'product_type', 'swap') -from venues v -where v.code = 'OKX' -on conflict (venue_id, symbol) do nothing; -``` - -### 13.3 XAU 建议 - -- 若 LMAX 的实际合约代码与最小变动单位还未最终确定，第一批不要急着插 `active=true` 的正式 XAU instrument -- 更稳妥的做法是等 LMAX 接入规格确认后单独补 seed - ---- - -## 14. 建议执行步骤 - -实际建库时建议： - -1. 先执行 001 ~ 008 schema migration -2. 再执行 009 ~ 010 seed migration -3. 然后运行验证 SQL -4. 再开始接 OKX 数据 -5. 再跑 session generator -6. 再跑 swing / dealing range / liquidity pool - ---- - -## 15. 第一轮验证 SQL 草案 - -### 15.1 检查基础表 - -```sql -select tablename -from pg_tables -where schemaname = 'public' - and tablename in ( - 'venues', - 'instruments', - 'candles', - 'market_sessions', - 'swings', - 'dealing_ranges', - 'liquidity_pools' - ) -order by tablename; -``` - -### 15.2 检查 candles 分区 - -```sql -select - parent.relname as parent_table, - child.relname as partition_table -from pg_inherits -join pg_class parent on pg_inherits.inhparent = parent.oid -join pg_class child on pg_inherits.inhrelid = child.oid -where parent.relname = 'candles'; -``` - -### 15.3 检查 seed 数据 - -```sql -select v.code, i.symbol, i.meta -from instruments i -join venues v on v.id = i.venue_id -order by v.code, i.symbol; -``` - ---- - -## 16. 当前结论 - -这份文档已经把数据库准备工作推进到了“文件级 migration 草案”的粒度。 - -下一步如果要真正开始代码实现，已经不需要再从零设计 migration，只需要把这里的内容按项目使用的 migration 工具格式落地即可。 - -对第一阶段来说，这已经足够支撑： - -`建库 -> seed -> 接 OKX -> 生成 sessions -> 跑 swings -> 跑 dealing range -> 跑 liquidity pools` diff --git a/docs/AI_ICT_第二批正式_Migration_文件草案_v1.md b/docs/AI_ICT_第二批正式_Migration_文件草案_v1.md deleted file mode 100644 index cb2ba86..0000000 --- a/docs/AI_ICT_第二批正式_Migration_文件草案_v1.md +++ /dev/null @@ -1,462 +0,0 @@ -# AI ICT 第二批正式 Migration 文件草案 v1 - -## 1. 文档目标 - -本文档在第一批 migration 文件草案的基础上，继续把数据库层推进到“核心事件层 + 决策层 + 回测层”，覆盖 MVP 主模型后半段所需的数据结构。 - -本批次主要覆盖： - -1. `displacement_events` -2. `structure_events` -3. `fvg_zones` -4. `bias_snapshots` -5. `trade_signals` -6. `trade_executions` -7. `backtest_runs` -8. `backtest_results` - -目标是把数据库主线推进到： - -`Liquidity -> Sweep -> Displacement -> MSS -> FVG -> Bias -> Signal -> Execution -> Backtest` - ---- - -## 2. 与第一批 migration 的关系 - -本批次默认依赖第一批 migration 已全部完成： - -1. `venues` -2. `instruments` -3. `candles` -4. `market_sessions` -5. `swings` -6. `dealing_ranges` -7. `liquidity_pools` - -如果第一批基础库对象未稳定，不建议直接进入本批次。 - ---- - -## 3. 建议 migration 文件顺序 - -建议后续正式建库时按以下文件顺序继续追加： - -11. `011_create_displacement_events.sql` -12. `012_create_structure_events.sql` -13. `013_create_fvg_zones.sql` -14. `014_create_bias_snapshots.sql` -15. `015_create_trade_signals.sql` -16. `016_create_trade_executions.sql` -17. `017_create_backtest_runs.sql` -18. `018_create_backtest_results.sql` - -说明： - -- 事件表先落地 -- 决策与执行表后落地 -- 回测表最后落地 - ---- - -## 4. 011_create_displacement_events.sql - -```sql -create table if not exists displacement_events ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - direction text not null, - start_ts timestamptz not null, - end_ts timestamptz not null, - strength_score numeric(8,4), - body_ratio numeric(8,4), - has_fvg boolean not null default false, - is_valid boolean not null default true, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_displacement_events_instr_tf_end_desc -on displacement_events (instrument_id, timeframe, end_ts desc); - -create index if not exists idx_displacement_events_instr_tf_dir_end_desc -on displacement_events (instrument_id, timeframe, direction, end_ts desc); -``` - -### 可选检查约束 - -```sql -alter table displacement_events - add constraint displacement_direction_check - check (direction in ('bullish', 'bearish')); -``` - ---- - -## 5. 012_create_structure_events.sql - -```sql -create table if not exists structure_events ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - event_type text not null, - direction text not null, - broken_level numeric(20,10) not null, - reference_swing_id bigint references swings(id), - displacement_event_id bigint references displacement_events(id), - accepted boolean, - signal_relevant boolean not null default true, - ts timestamptz not null, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_structure_events_instr_tf_ts_desc -on structure_events (instrument_id, timeframe, ts desc); - -create index if not exists idx_structure_events_instr_tf_event_ts_desc -on structure_events (instrument_id, timeframe, event_type, ts desc); -``` - -### 可选检查约束 - -```sql -alter table structure_events - add constraint structure_events_type_check - check (event_type in ('MSB', 'MSS')); - -alter table structure_events - add constraint structure_events_direction_check - check (direction in ('bullish', 'bearish')); -``` - ---- - -## 6. 013_create_fvg_zones.sql - -```sql -create table if not exists fvg_zones ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - timeframe text not null, - direction text not null, - upper numeric(20,10) not null, - lower numeric(20,10) not null, - start_ts timestamptz not null, - end_ts timestamptz not null, - fill_pct numeric(8,4) not null default 0, - status text not null default 'open', - related_displacement_id bigint references displacement_events(id), - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); - -create index if not exists idx_fvg_zones_instr_tf_start_desc -on fvg_zones (instrument_id, timeframe, start_ts desc); - -create index if not exists idx_fvg_zones_instr_tf_status_start_desc -on fvg_zones (instrument_id, timeframe, status, start_ts desc); -``` - -### 可选检查约束 - -```sql -alter table fvg_zones - add constraint fvg_direction_check - check (direction in ('bullish', 'bearish')); - -alter table fvg_zones - add constraint fvg_status_check - check (status in ('open', 'touched', 'mitigated', 'invalidated')); -``` - ---- - -## 7. 014_create_bias_snapshots.sql - -```sql -create table if not exists bias_snapshots ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - bias_tf text not null, - setup_tf text not null, - trigger_tf text not null, - snapshot_ts timestamptz not null, - daily_bias text not null, - confidence numeric(8,4), - execution_intensity text not null, - narrative_code text, - draw_side text, - range_id bigint references dealing_ranges(id), - reason_codes jsonb not null default '[]'::jsonb, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_bias_snapshots_instr_snapshot_desc -on bias_snapshots (instrument_id, snapshot_ts desc); - -create index if not exists idx_bias_snapshots_instr_bias_snapshot_desc -on bias_snapshots (instrument_id, daily_bias, snapshot_ts desc); -``` - -### 可选检查约束 - -```sql -alter table bias_snapshots - add constraint bias_snapshots_daily_bias_check - check (daily_bias in ('bullish', 'bearish', 'neutral')); - -alter table bias_snapshots - add constraint bias_snapshots_execution_intensity_check - check (execution_intensity in ('low', 'medium', 'high')); -``` - ---- - -## 8. 015_create_trade_signals.sql - -```sql -create table if not exists trade_signals ( - id bigserial primary key, - instrument_id bigint not null references instruments(id), - model_code text not null, - side text not null, - status text not null, - bias_snapshot_id bigint references bias_snapshots(id), - entry_type text not null, - entry_low numeric(20,10), - entry_high numeric(20,10), - stop_loss numeric(20,10), - tp1 numeric(20,10), - tp2 numeric(20,10), - rr_tp1 numeric(8,4), - rr_tp2 numeric(8,4), - session_code text, - created_ts timestamptz not null, - expires_ts timestamptz, - invalidations jsonb not null default '[]'::jsonb, - evidence jsonb not null default '{}'::jsonb, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); - -create index if not exists idx_trade_signals_instr_created_desc -on trade_signals (instrument_id, created_ts desc); - -create index if not exists idx_trade_signals_instr_status_created_desc -on trade_signals (instrument_id, status, created_ts desc); - -create index if not exists idx_trade_signals_instr_model_created_desc -on trade_signals (instrument_id, model_code, created_ts desc); -``` - -### 可选检查约束 - -```sql -alter table trade_signals - add constraint trade_signals_side_check - check (side in ('buy', 'sell')); -``` - -说明： - -- `status` 先保持文本，后期如状态机稳定再做枚举收敛 - ---- - -## 9. 016_create_trade_executions.sql - -```sql -create table if not exists trade_executions ( - id bigserial primary key, - signal_id bigint not null references trade_signals(id), - venue_order_id text, - execution_mode text not null, - side text not null, - entry_price numeric(20,10), - stop_loss numeric(20,10), - take_profit_1 numeric(20,10), - take_profit_2 numeric(20,10), - size numeric(28,10), - risk_pct numeric(8,4), - status text not null, - opened_ts timestamptz, - closed_ts timestamptz, - pnl numeric(28,10), - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now(), - updated_at timestamptz not null default now() -); - -create index if not exists idx_trade_executions_signal_id -on trade_executions (signal_id); - -create index if not exists idx_trade_executions_status_created_desc -on trade_executions (status, created_at desc); - -create index if not exists idx_trade_executions_mode_created_desc -on trade_executions (execution_mode, created_at desc); -``` - -### 可选检查约束 - -```sql -alter table trade_executions - add constraint trade_executions_mode_check - check (execution_mode in ('paper', 'semi_auto', 'live')); -``` - ---- - -## 10. 017_create_backtest_runs.sql - -```sql -create table if not exists backtest_runs ( - id bigserial primary key, - model_code text not null, - instrument_id bigint references instruments(id), - timeframe_set jsonb not null default '{}'::jsonb, - started_ts timestamptz not null, - ended_ts timestamptz, - config jsonb not null default '{}'::jsonb, - summary jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_backtest_runs_model_started_desc -on backtest_runs (model_code, started_ts desc); - -create index if not exists idx_backtest_runs_instr_started_desc -on backtest_runs (instrument_id, started_ts desc); -``` - ---- - -## 11. 018_create_backtest_results.sql - -```sql -create table if not exists backtest_results ( - id bigserial primary key, - backtest_run_id bigint not null references backtest_runs(id), - signal_id bigint references trade_signals(id), - outcome text not null, - mfe numeric(20,10), - mae numeric(20,10), - tp1_hit boolean, - tp2_hit boolean, - invalidated_before_entry boolean, - error_tags jsonb not null default '[]'::jsonb, - meta jsonb not null default '{}'::jsonb, - created_at timestamptz not null default now() -); - -create index if not exists idx_backtest_results_run_id -on backtest_results (backtest_run_id); - -create index if not exists idx_backtest_results_outcome -on backtest_results (outcome); -``` - -### 可选检查约束 - -```sql -alter table backtest_results - add constraint backtest_results_outcome_check - check (outcome in ('win', 'loss', 'breakeven', 'missed')); -``` - ---- - -## 12. 推荐执行顺序 - -若第一批 migration 已成功执行，本批建议顺序如下： - -1. `011_create_displacement_events.sql` -2. `012_create_structure_events.sql` -3. `013_create_fvg_zones.sql` -4. `014_create_bias_snapshots.sql` -5. `015_create_trade_signals.sql` -6. `016_create_trade_executions.sql` -7. `017_create_backtest_runs.sql` -8. `018_create_backtest_results.sql` - -原因： - -- 先把主模型的事件层打通 -- 再把 bias / signal / execution 层打通 -- 最后补 backtest - ---- - -## 13. 第一轮验证 SQL 草案 - -### 13.1 检查表存在 - -```sql -select tablename -from pg_tables -where schemaname = 'public' - and tablename in ( - 'displacement_events', - 'structure_events', - 'fvg_zones', - 'bias_snapshots', - 'trade_signals', - 'trade_executions', - 'backtest_runs', - 'backtest_results' - ) -order by tablename; -``` - -### 13.2 检查外键关系 - -```sql -select - tc.table_name, - kcu.column_name, - ccu.table_name as foreign_table_name, - ccu.column_name as foreign_column_name -from information_schema.table_constraints as tc -join information_schema.key_column_usage as kcu - on tc.constraint_name = kcu.constraint_name -join information_schema.constraint_column_usage as ccu - on ccu.constraint_name = tc.constraint_name -where tc.constraint_type = 'FOREIGN KEY' - and tc.table_name in ( - 'structure_events', - 'fvg_zones', - 'bias_snapshots', - 'trade_signals', - 'trade_executions', - 'backtest_runs', - 'backtest_results' - ) -order by tc.table_name, kcu.column_name; -``` - ---- - -## 14. 当前结论 - -这份文档已经把数据库层推进到信号层和回测层的 migration 文件草案粒度。 - -也就是说，数据库设计现在已经基本完整，覆盖了： - -- 基础数据层 -- 基础规则层 -- 事件层 -- 信号层 -- 执行层 -- 回测层 - -后续若要继续高价值推进，已经不需要再扩数据库文档，而应转入： - -1. 项目代码骨架 -2. migration 工具格式化 -3. OKX 数据接入真实实现 -4. Session / Swing / Range 第一轮代码实现 diff --git a/docs/AI_ICT_项目代码骨架规范_v1.md b/docs/AI_ICT_项目代码骨架规范_v1.md deleted file mode 100644 index 086dcda..0000000 --- a/docs/AI_ICT_项目代码骨架规范_v1.md +++ /dev/null @@ -1,492 +0,0 @@ -# AI ICT 项目代码骨架规范 v1 - -## 1. 文档目标 - -本文档定义 AI ICT 项目第一阶段的代码骨架与模块组织方式，用于把前面已经完成的设计文档、规则规格和 migration 草案落到一个可持续开发的工程结构中。 - -目标： - -1. 固定项目目录结构 -2. 明确各模块职责边界 -3. 明确配置与运行入口 -4. 明确第一波实现顺序 -5. 避免后续实现过程中代码散落、边界混乱 - ---- - -## 2. 项目骨架设计原则 - -### 原则 1：先基础共享模块 -优先落地会被后续模块反复依赖的内容： - -- config -- db -- market-data -- sessions -- swings -- ranges - -### 原则 2：按数据流组织，而不是按零散术语组织 -优先围绕主链路组织模块： - -`Candles -> Sessions -> Swings -> Ranges -> Liquidity -> Sweep -> Displacement -> MSS -> FVG -> Signal` - -### 原则 3：规则层与执行层分离 -- 规则层负责“识别事实” -- 信号层负责“组合条件” -- 执行层负责“风险表达与下单” - -### 原则 4：AI 说明层后置 -AI 报告模块只消费结构化结果，不参与底层真值判定。 - ---- - -## 3. 推荐项目目录 - -建议项目根目录结构如下： - -```text -ai-ict/ - docs/ - migrations/ - seeds/ - scripts/ - src/ - config/ - db/ - models/ - repositories/ - services/ - market_data/ - sessions/ - swings/ - ranges/ - liquidity/ - sweeps/ - displacement/ - structure/ - fvg/ - bias/ - signals/ - execution/ - backtest/ - reports/ - domain/ - api/ - utils/ - main.py - tests/ - unit/ - integration/ - fixtures/ - .env.example - pyproject.toml - README.md -``` - -说明： - -- `docs/` 用于保存当前这些长期参考文档 -- `migrations/` 保存正式 migration 文件 -- `seeds/` 保存初始化数据 -- `scripts/` 保存一次性导入、补数、维护任务 - ---- - -## 4. 模块职责划分 - -## 4.1 config/ - -职责： - -- 读取环境变量 -- 管理 PostgreSQL 配置 -- 管理 OKX 配置 -- 管理 session 配置 -- 管理 timeframe 配置 -- 管理阈值参数配置 - -建议文件： - -- `settings.py` -- `database.py` -- `okx.py` -- `sessions.py` -- `thresholds.py` - ---- - -## 4.2 db/ - -职责： - -- 数据库连接 -- session factory -- migration 工具接入点 -- 基础 SQL 辅助 - -建议文件： - -- `engine.py` -- `session.py` -- `base.py` - ---- - -## 4.3 models/ - -职责： - -- 定义 ORM 模型或数据表映射 - -建议第一阶段覆盖： - -- `venue.py` -- `instrument.py` -- `candle.py` -- `market_session.py` -- `swing.py` -- `dealing_range.py` -- `liquidity_pool.py` -- `displacement_event.py` -- `structure_event.py` -- `fvg_zone.py` -- `bias_snapshot.py` -- `trade_signal.py` -- `trade_execution.py` -- `backtest_run.py` -- `backtest_result.py` - ---- - -## 4.4 repositories/ - -职责： - -- 屏蔽底层数据库读写细节 -- 为 services 提供统一数据访问接口 - -建议： - -- 一个核心实体一个 repository -- 不在 service 里到处写原始 SQL - -例如： - -- `candle_repository.py` -- `session_repository.py` -- `swing_repository.py` -- `range_repository.py` - ---- - -## 4.5 services/ - -这是项目主核心。 - -### market_data/ -职责： -- OKX 历史补数 -- OKX 增量同步 -- 原始对象转标准 candle -- 入库 - -### sessions/ -职责： -- UTC -> 纽约时间转换 -- session 切分 -- high / low / midpoint 生成 -- 写入 `market_sessions` - -### swings/ -职责： -- ST / IT / LT swing 识别 -- confirmed / provisional 处理 - -### ranges/ -职责： -- active range 选择 -- equilibrium 计算 -- premium / discount 标记 - -### liquidity/ -职责： -- prior highs / lows -- equal highs / lows -- session highs / lows -- pool 状态管理 - -### sweeps/ -职责： -- pool 刺穿检测 -- weak / validated sweep -- close back inside - -### displacement/ -职责： -- body_ratio -- 推进性 -- has_fvg -- strength_score - -### structure/ -职责： -- MSB -- MSS -- acceptance -- displacement 关联 - -### fvg/ -职责： -- bullish / bearish FVG -- fill_pct -- mitigation / invalidation - -### bias/ -职责： -- higher timeframe bias -- execution_intensity -- reason_codes - -### signals/ -职责： -- `SWEEP_MSS_FVG` 模型组合 -- invalidation 条件 -- RR 过滤 -- session 过滤 - -### execution/ -职责： -- paper trading -- semi-auto execution -- risk engine - -### backtest/ -职责： -- backtest run -- mfe / mae -- outcome tags - -### reports/ -职责： -- pre-market -- intraday explanation -- post-trade review - ---- - -## 4.6 domain/ - -职责： - -- 放与业务含义强相关、但不直接依赖数据库的对象定义 -- 如 enums、状态机、共享 schema - -建议内容： - -- `timeframes.py` -- `sessions.py` -- `signal_status.py` -- `pool_status.py` -- `event_types.py` - ---- - -## 4.7 api/ - -职责： - -- 暴露查询与控制接口 - -第一阶段可先保留轻量 API： - -- `health.py` -- `candles.py` -- `sessions.py` -- `signals.py` -- `backtest.py` - -说明： - -- 第一阶段 API 不必过重 -- 先服务内部开发和调试即可 - ---- - -## 4.8 utils/ - -职责： - -- 公共工具函数 - -例如： - -- 时间转换 -- 数值精度处理 -- 批量分片工具 -- 日志包装 - -原则： - -- 不要过度抽象 -- 仅放明确被多个模块复用的内容 - ---- - -## 5. 运行入口建议 - -## 5.1 主入口 - -建议保留一个明确主入口： - -- `src/main.py` - -职责： - -- 加载配置 -- 初始化数据库连接 -- 启动 API 或任务调度入口 - ---- - -## 5.2 脚本入口 - -第一阶段建议把任务型入口放在 `scripts/` 下，例如： - -- `run_okx_backfill.py` -- `run_session_generator.py` -- `run_swings.py` -- `run_ranges.py` -- `run_liquidity.py` - -说明： - -- 第一阶段用脚本驱动模块非常合适 -- 不必一开始就做复杂编排平台 - ---- - -## 6. 配置文件建议 - -建议准备： - -### `.env.example` -包含： - -- `DATABASE_URL` -- `OKX_BASE_URL` -- `OKX_TIMEOUT` -- `DEFAULT_TIMEZONE` -- `SESSION_TIMEZONE` -- `LOG_LEVEL` - -### `src/config/sessions.py` -包含： - -- ASIA -- LONDON -- NY_AM -- NY_LUNCH -- NY_PM - -### `src/config/thresholds.py` -包含： - -- equal highs / lows 阈值 -- displacement 阈值 -- FVG 最小宽度过滤阈值 -- equilibrium 缓冲带阈值 - ---- - -## 7. 第一波实现顺序 - -建议严格按以下顺序开始写代码： - -### Step 1 -- config/ -- db/ -- models/ -- migrations/ - -### Step 2 -- market_data/ -- scripts/run_okx_backfill.py - -### Step 3 -- sessions/ -- scripts/run_session_generator.py - -### Step 4 -- swings/ -- scripts/run_swings.py - -### Step 5 -- ranges/ -- scripts/run_ranges.py - -### Step 6 -- liquidity/ -- scripts/run_liquidity.py - -说明： - -- 到 Step 6，第一条基础规则链就真正跑起来了 -- 后面再继续写 sweep / displacement / MSS / FVG - ---- - -## 8. 测试结构建议 - -### unit/ -每个核心模块一组单元测试： - -- `test_market_data.py` -- `test_sessions.py` -- `test_swings.py` -- `test_ranges.py` -- `test_liquidity.py` - -### integration/ -跨模块流程测试： - -- OKX backfill -> candles -- candles -> sessions -- sessions -> swings -> ranges - -### fixtures/ -- 样本 candles -- 样本 session 数据 -- 样本 swing 数据 - ---- - -## 9. 第一阶段“可运行”定义 - -第一阶段不是把全部系统写完，而是先做到： - -1. 数据库可初始化 -2. OKX 数据可入库 -3. sessions 可生成 -4. swings 可生成 -5. dealing range 可生成 -6. liquidity pools 可生成 - -只要做到这 6 项，项目就已经从“文档阶段”跨进“真实运行阶段”。 - ---- - -## 10. 当前结论 - -本代码骨架规范的作用，是把前面已经完成的大量文档收束成一个可持续实现的工程结构。 - -到这里为止，你已经拥有： - -- 设计文档 -- 规格文档 -- migration 草案 -- 代码骨架规范 - -这意味着下一步已经不该再停留在继续补外围文档，而是可以直接进入： - -`建项目骨架 -> 写 migration -> 接 OKX -> 跑 sessions -> 跑 swings -> 跑 dealing range -> 跑 liquidity` diff --git a/docs/AI_Legal_Content_Intelligence_Upgrade_Plan_v1.md b/docs/AI_Legal_Content_Intelligence_Upgrade_Plan_v1.md deleted file mode 100644 index 7b48a29..0000000 --- a/docs/AI_Legal_Content_Intelligence_Upgrade_Plan_v1.md +++ /dev/null @@ -1,828 +0,0 @@ -# AI 法务平台内容智力升级方案 v1 - -## 1. 目标 - -当前平台功能主干已基本完成，但系统“智力层”明显不足： -- 法规资料不全 -- 合同模板库薄弱 -- 条款库/审查规则库几乎空白 -- 行业资料覆盖不足 -- 训练/导入导出框架存在，但缺少高质量内容资产 - -本方案目标不是再做一套新功能，而是把平台从“会点按钮的法务工具”升级为“具备中国法律体系、合同实务、行业差异、审查逻辑、生成逻辑”的高智力法务平台。 - -核心目标： -1. 建立可持续扩充的内容底座 -2. 建立标准化合同模板体系 -3. 建立法规/司法解释/案例/条款/规则之间的结构化关系 -4. 建立首批高价值内容资产包 -5. 让现有训练/导入/展示框架成为内容升级的承载器 - -## 2. 基于当前仓库的真实现状 - -我已检查当前仓库，结论如下： - -### 2.1 已有可复用能力 - -1. Training Case 导入导出框架已经存在 -- `src/services/training/case_import_export.py` -- `src/services/training/training_case_service.py` -- `src/repositories/training_case_repository.py` -- `scripts/run_training_case_package.py` -- `tests/fixtures/training_case_package_m6.json` - -这说明系统已经有一套“内容包 -> 校验 -> 导入 -> 导出 -> 前台展示”的基础管道。 - -2. Dashboard 已经有 Training 区域 -- `src/web/index.html` -- `src/web/app.js` - -页面已经具备： -- Import / Export -- Case list -- Case detail -- Progress -- Attempt / Annotation / Submit - -这意味着平台已经不是从零开始，已经有“内容对象承载界面”。 - -3. 当前 package 数据结构具有很强可复用性 -以 `training_case_package_m6.json` 和 `case_import_export.py` 看，已有这些稳定结构： -- `version` -- `metadata` -- `items[]` -- `title` -- `scenario` -- `skill_tags` -- `difficulty` -- `rubric` -- `tasks` -- `status` -- `external_id` -- `meta/metadata` - -这套结构可以平移为法务内容对象，例如： -- 法规解读案例 -- 合同模板包 -- 审查规则训练样本 -- 行业合规资料包 -- 条款风险识别训练集 - -### 2.2 当前不足 - -当前仓库没有看到成体系的： -- 法规库模块 -- 司法解释库模块 -- 案例库模块 -- 合同模板库模块 -- 条款库模块 -- 审查规则库模块 -- 行业法务资料库模块 - -也就是说： -- 功能壳子已有 -- 内容中台没有真正建立 -- 当前最大瓶颈不是页面、接口，而是“高质量结构化内容资产” - -### 2.3 结论 - -现阶段最正确的方向不是继续堆功能，而是建设“法务内容中台”。 - -## 3. 目标知识架构 - -建议把平台知识分成 7 层。 - -### 3.1 法源层 -承载权威法律依据： -- 宪法相关基础制度 -- 民法典 -- 公司法 -- 劳动法、劳动合同法 -- 仲裁法、民事诉讼法 -- 数据安全法、个人信息保护法、网络安全法 -- 电子签名法 -- 反不正当竞争法 -- 消费者权益保护法 -- 招标投标法 -- 建筑法 -- 著作权法、商标法、专利法 -- 最高法司法解释 -- 国务院行政法规 -- 部委规章 -- 地方性法规（按需） - -字段建议： -- law_id -- title -- level（法律/行政法规/司法解释/部门规章/地方性法规） -- issuing_body -- effective_date -- status -- chapter/article -- article_text -- keywords -- industry_tags -- source_url -- version_note - -### 3.2 裁判与实务层 -承载裁判规则与实务导向： -- 指导性案例 -- 公报案例 -- 典型案例 -- 高院裁判规则 -- 仲裁案例摘要 -- 监管问答/窗口指导摘要 - -字段建议： -- case_id -- title -- court_or_body -- date -- dispute_type -- key_issue -- holding -- rule_summary -- cited_laws -- applicable_scenarios -- risk_tags - -### 3.3 条款知识层 -承载合同条款本体： -- 定义条款 -- 标的条款 -- 价款条款 -- 交付条款 -- 验收条款 -- 保密条款 -- 知识产权条款 -- 数据合规条款 -- 违约责任条款 -- 争议解决条款 -- 不可抗力条款 -- 解约条款 - -字段建议： -- clause_id -- clause_type -- clause_title -- clause_text -- plain_explanation -- risk_level -- common_risks -- negotiation_points -- applicable_contract_types -- prohibited_patterns -- recommended_variants -- linked_laws - -### 3.4 审查规则层 -这是平台智力的核心层。 - -每条规则至少要表达： -- 审什么 -- 为什么审 -- 依据是什么 -- 什么情况触发风险 -- 给什么修改建议 -- 哪些行业/交易要加强 - -字段建议： -- rule_id -- rule_name -- contract_type -- clause_scope -- trigger_pattern -- risk_description -- severity -- review_question -- suggested_fix -- legal_basis -- fallback_clause_ids -- industry_scope -- version - -### 3.5 模板层 -模板不能只是一份 docx，而要是“结构化模板系统”： -- 主模板 -- 必选条款 -- 可选条款包 -- 替代条款版本 -- 行业增强条款包 -- 客户偏好条款包 -- 问卷变量 - -字段建议： -- template_id -- template_name -- contract_type -- industry -- scenario -- jurisdiction -- template_version -- clauses[] -- variables[] -- generation_questions[] -- review_rules[] -- fallback_templates[] - -### 3.6 行业知识层 -按行业建立增强包： -- 电商 -- SaaS/软件开发 -- AI/数据服务 -- 劳务派遣/人力资源 -- 制造与供应链 -- 建工/装修 -- 医疗器械/医药 -- 教培 -- MCN/直播/广告 -- 跨境贸易 - -每个行业包应包含： -- 常见合同类型 -- 监管关注点 -- 常见争议点 -- 必审条款 -- 高风险表达 -- 行业特有术语 -- 行业必备附件清单 - -### 3.7 训练与反馈层 -把实际使用中发现的问题回流为： -- 审查误判样本 -- 漏判样本 -- 优秀审查案例 -- 高质量生成结果 -- 用户修改痕迹 -- 业务行业新增需求 - -这层用于持续把平台从“博士入门”推进到“博士后”。 - -## 4. 内容来源矩阵 - -以下是建议的来源体系。 - -### 4.1 法规与司法解释 -1. 国家法律法规数据库 -- 权威性：最高 -- 内容：法律、行政法规、司法解释、监察法规等 -- 自动化可行性：中 -- 风险：需注意抓取频率、使用方式、展示引用规范 -- 更新频率：高 - -2. 中国政府网 / 国务院 / 部委官网 -- 权威性：高 -- 内容：行政法规、部门规章、政策文件 -- 自动化可行性：中 -- 风险：站点结构不稳定 -- 更新频率：中高 - -3. 最高人民法院官网 -- 权威性：高 -- 内容：司法解释、典型案例、指导性案例、会议纪要等公开材料 -- 自动化可行性：中 -- 风险：页面结构差异大 -- 更新频率：中 - -### 4.2 案例与实务 -4. 中国裁判文书相关公开渠道/官方案例公开栏目 -- 权威性：高 -- 内容：案例、裁判要旨 -- 自动化可行性：低到中 -- 风险：版权、平台规则、数据可得性、公开范围限制 -- 更新频率：高 - -5. 高院/仲裁委/监管机构官网公开案例与问答 -- 权威性：高 -- 自动化可行性：中低 -- 风险：来源分散 - -### 4.3 模板与实务资料 -6. 政府示范文本、协会示范合同 -- 权威性：中高 -- 自动化可行性：中 -- 风险：版本差异、行业适用性有限 - -7. 自建模板体系 -- 权威性：依赖内部质量 -- 自动化可行性：高 -- 风险：必须建立法审与版本治理，否则容易失控 - -8. 用户上传真实合同脱敏沉淀 -- 权威性：高价值实务数据 -- 自动化可行性：中 -- 风险：隐私、商业秘密、授权边界极高 -- 必须：脱敏、分级、授权、审计 - -### 4.4 结论 -内容来源必须分三类治理： -1. 权威法源类：优先建设，做平台根基 -2. 公开实务类：精选建设，做平台判断力 -3. 私有沉淀类：严格治理，做平台竞争壁垒 - -## 5. 合同模板体系设计 - -建议采用“四维分类法”。 - -### 5.1 第一维：法律关系 -- 买卖 -- 服务 -- 技术开发 -- 技术服务 -- 技术许可 -- 劳动/劳务 -- 委托/代理 -- 租赁 -- 借款 -- 保证/担保 -- 股权投资/股权转让 -- 保密/NDA -- 数据处理/数据合作 -- 知识产权授权 - -### 5.2 第二维：业务场景 -- B2B 采购 -- SaaS 销售 -- 定制开发 -- AI 模型服务 -- 电商代运营 -- MCN/达人合作 -- 品牌广告投放 -- 人力外包 -- 工程施工 -- 装修服务 -- 跨境贸易 -- 医疗器械采购 - -### 5.3 第三维：文档角色 -- 主合同 -- 补充协议 -- 附件 -- 订单 -- SLA -- DPA/数据处理附件 -- 验收单 -- 保密协议 -- 授权书 -- 对账确认单 - -### 5.4 第四维：版本属性 -- 平台标准版 -- 平台审慎版 -- 平台偏甲方版 -- 平台偏乙方版 -- 行业增强版 -- 客户定制版 - -## 6. 首批 100 个高优先级内容资产建议 - -下面不是“100 部法律全文”，而是“最值得优先落库的 100 类资产”。 - -### A. 法规/司法解释基础包（20） -1. 民法典总则与合同编核心条文 -2. 民法典侵权责任编中与合同履行相关规则 -3. 公司法 -4. 劳动合同法 -5. 劳动法 -6. 社会保险法中用工关键条文 -7. 仲裁法 -8. 民事诉讼法中管辖、证据、保全、执行相关条文 -9. 电子签名法 -10. 消费者权益保护法 -11. 反不正当竞争法 -12. 著作权法 -13. 商标法 -14. 专利法 -15. 网络安全法 -16. 数据安全法 -17. 个人信息保护法 -18. 招标投标法 -19. 建筑法 -20. 与合同效力、违约责任、保证、格式条款相关的最高法司法解释合集 - -### B. 高优先级合同模板包（25） -21. 通用买卖合同 -22. 采购框架协议 -23. 销售框架协议 -24. 供货合同 -25. 服务合同 -26. 技术服务合同 -27. 技术开发合同 -28. 软件开发合同 -29. SaaS 服务协议 -30. 数据处理委托协议 -31. 数据合作协议 -32. 保密协议 NDA -33. 劳动合同（标准员工） -34. 劳务合同 -35. 兼职顾问协议 -36. 委托代理合同 -37. 渠道合作协议 -38. 品牌推广/广告投放合同 -39. MCN 达人合作协议 -40. 电商代运营协议 -41. 房屋租赁合同（商用） -42. 借款合同 -43. 保证合同 -44. 股权转让协议 -45. 投资意向书/Term Sheet 基础版 - -### C. 条款库优先建设（20） -46. 合同目的与定义条款 -47. 标的描述条款 -48. 交付方式条款 -49. 验收标准条款 -50. 付款条件条款 -51. 发票条款 -52. 违约责任条款 -53. 赔偿范围限制条款 -54. 保密条款 -55. 知识产权归属条款 -56. 知识产权侵权担保条款 -57. 数据处理与数据安全条款 -58. 个人信息保护条款 -59. 竞业限制/不招揽条款 -60. 期限与续约条款 -61. 解除与终止条款 -62. 不可抗力条款 -63. 通知送达条款 -64. 争议解决条款 -65. 法律适用与管辖条款 - -### D. 审查规则优先包（20） -66. 主体资格审查规则 -67. 签约权限审查规则 -68. 合同名称与交易实质不一致规则 -69. 标的不明确规则 -70. 付款条件不清规则 -71. 验收标准缺失规则 -72. 自动续约风险规则 -73. 单方免责/责任失衡规则 -74. 违约责任过轻/过重规则 -75. 赔偿上限缺失规则 -76. 知识产权归属不清规则 -77. 数据合规条款缺失规则 -78. 个人信息处理合法性规则 -79. 保密范围过宽/过窄规则 -80. 解约条件失衡规则 -81. 管辖约定不利规则 -82. 附件与主合同冲突规则 -83. 印章/签字页完整性规则 -84. 生效条件不明规则 -85. 行业许可/资质前置条件缺失规则 - -### E. 问答知识包（10） -86. 甲方最常问的付款风险问答 -87. 乙方最常问的验收风险问答 -88. 劳动用工高频问答 -89. SaaS/软件开发合同高频问答 -90. 数据合规高频问答 -91. 保密协议高频问答 -92. 广告投放/代运营争议问答 -93. 股权转让常见陷阱问答 -94. 租赁合同常见争议问答 -95. 借款与担保高频风险问答 - -### F. 行业资料包（5） -96. SaaS/软件行业法务包 -97. AI/数据服务行业法务包 -98. 电商/代运营行业法务包 -99. 建工/装修行业法务包 -100. 人力资源/劳务外包行业法务包 - -## 7. 仓库内建议新增的目录与数据结构 - -建议在当前仓库中新增一个独立内容中台目录，而不是把所有内容散落在 docs 里。 - -建议结构： - -```text -legal_content/ - laws/ - national/ - regulations/ - judicial_interpretations/ - local/ - cases/ - guiding/ - typical/ - court_rules/ - arbitration/ - templates/ - by_contract_type/ - by_industry/ - clause_modules/ - questionnaires/ - rules/ - general_review/ - industry_review/ - generation_rules/ - knowledge/ - faq/ - playbooks/ - industry_guides/ - seeds/ - laws/ - templates/ - clauses/ - rules/ - faq/ - manifests/ - content_packages/ - release_index/ -``` - -### 7.1 建议文件格式 - -1. 法规：JSON 或 JSONL -2. 模板：JSON + Markdown 双格式 -3. 条款：JSON -4. FAQ：Markdown + frontmatter -5. 行业资料：Markdown / JSON -6. 训练包：沿用当前 training package 结构扩展 - -### 7.2 建议的种子对象格式 - -法规种子： -- id -- title -- source -- level -- effective_date -- articles[] -- tags[] - -模板种子： -- template_id -- template_name -- contract_type -- industry -- version -- variables[] -- clauses[] -- required_rules[] - -规则种子： -- rule_id -- rule_name -- trigger -- severity -- legal_basis[] -- suggestion - -### 7.3 与现有 training package 的关系 - -当前 training package 可用于三类内容： -1. 合同审查训练样本 -2. 条款识别训练样本 -3. 法规适用判断训练样本 - -建议不要废弃现有 training 框架，而是把它升级为“内容验证与训练入口”。 - -## 8. 分阶段执行路线图 - -### 第一阶段：2 周 -目标：搭建内容底座骨架，先把“空脑子”变成“有骨架的大脑”。 - -产出： -1. 内容分类法定稿 -2. legal_content 目录落地 -3. 首批法规清单定稿 -4. 首批模板清单定稿 -5. 首批审查规则清单定稿 -6. 内容包 schema 定稿 -7. 建立内容编制规范 -8. 先做 20-30 个高优先级资产样板 - -第一阶段不要贪多，重点是： -- 格式统一 -- 命名统一 -- 版本统一 -- 来源统一 -- 引用统一 - -### 第二阶段：6 周 -目标：形成“可用的法务专家底座”。 - -产出： -1. 20 个法规基础包 -2. 25 个主模板初版 -3. 20 个核心条款模块 -4. 20 条通用审查规则 -5. 10 组高频问答 -6. 5 个行业资料包 -7. 训练样本开始与模板/规则联动 - -到这一步，平台应具备： -- 常见合同可生成 -- 常见合同可审查 -- 常见问题可回答 -- 高频行业有基本覆盖 - -### 第三阶段：12 周 -目标：把平台从“可用”推进到“专业且可扩张”。 - -产出： -1. 行业增强模板批量扩展 -2. 地方性规则与行业监管资料增强 -3. 审查规则扩展到 100+ 条 -4. 条款替代版本与甲乙方立场版本 -5. 用户脱敏合同沉淀流程 -6. 内容更新与发布机制 -7. 质量评分机制 - -## 9. 主要风险与治理建议 - -### 9.1 版权与授权风险 -- 法律法规原文通常可合理引用，但仍需明确来源与更新时间 -- 商业模板、第三方数据库内容不可直接无授权复制 -- 真实客户合同必须做授权、脱敏、审计 - -### 9.2 内容过时风险 -- 法律更新频繁 -- 司法解释、监管口径变化快 -- 必须设置版本号、更新时间、失效标记 - -### 9.3 幻觉式法务风险 -如果只堆大模型，不做规则与法源绑定，系统会“说得像律师，但不一定对”。 -必须坚持： -- 每条关键审查建议要有法源依据 -- 每个高风险结论要有规则链路 -- 每个模板要有适用范围声明 - -### 9.4 行业覆盖失衡风险 -一开始不要追求“所有行业一网打尽”。 -建议优先行业： -1. 通用买卖/服务 -2. 软件/SaaS/AI -3. 电商/代运营/广告 -4. 劳动/劳务/顾问 -5. 租赁/借款/担保 - -### 9.5 治理机制建议 -建立四道治理： -1. 来源治理：来源、日期、链接、授权说明 -2. 结构治理：统一 schema -3. 审校治理：法务审校 + 产品审校 + 技术校验 -4. 发布治理：版本化发布，不允许内容野生上线 - -## 10. 我建议的下一步实际动作 - -如果你同意，我建议立刻把这条主线拆成 4 个并行子任务： - -A. 内容架构与 schema 线 -- 定义 laws/templates/clauses/rules/faq 的统一 schema - -B. 法规与司法解释采集线 -- 先做首批 20 个法规基础包 - -C. 模板与条款线 -- 先做首批 25 个主模板 + 20 个条款模块 - -D. 审查规则线 -- 先做首批 20 条通用规则 + 5 个行业包规则 - -## 11. 需要你协助的关键事项 - -为了把这项工作真正推进成产出，而不是停留在方案层面，我需要你给我 4 个决策支持： - -1. 确认首批优先行业 -建议默认： -- 软件/SaaS/AI -- 电商/代运营/广告 -- 劳动/劳务/顾问 -- 通用买卖/服务 -- 租赁/借款/担保 - -2. 确认是否允许建立“内部标准模板” -也就是不完全依赖网上现成模板，而是由我们自建平台模板体系。 - -3. 确认是否允许把客户真实合同做脱敏沉淀 -如果允许，需要建立授权与脱敏规则。 - -4. 确认内容交付形式 -我建议： -- 仓库内结构化种子文件 -- 配套管理清单 -- 后续再接入前台后台 - -## 12. Codex 并行研究补充结论 - -Codex 并行研究完成后，补充了几个非常关键、适合直接纳入实施路线的结论： - -### 12.1 包命名与发布单元建议 -建议内容包命名遵循统一风格，便于版本化、导入导出、审校与灰度发布，例如： -- `laws_cn_core_v1.json` -- `judicial_interpretations_cn_contract_v1.json` -- `contract_templates_cn_official_v1.json` -- `review_rules_cn_contract_v1.json` - -建议未来所有内容资产都按“主题 + 范围 + 版本”命名，而不是自由命名。 - -### 12.2 分阶段演进补充 -在原有 2 周 / 6 周 / 12 周规划基础上，可以继续扩成更完整的 5 阶段： - -1. Phase 1（2-4 周） -- 建立 source registry（来源注册表） -- 建立 taxonomy（内容分类法） -- 建立首批 100 个内容资产 -- 只使用权威公开来源 + 明确归属的内部原创内容 -- 先让平台具备 laws + judicial interpretations + official templates 的检索能力 - -2. Phase 2（4-8 周） -- 建立 clause library（条款库） -- 建立 rule engine 基础层 -- 覆盖前 20 个最常见合同审查问题 -- 要求每条规则都绑定：法源依据 + 至少 1 个案例 - -3. Phase 3（8-12 周） -- 建立行业增强包 -- 首批重点行业：互联网/SaaS、劳动用工、电商/平台、建工/不动产 -- 开始客户模板接入，但必须做 tenant isolation（租户隔离） - -4. Phase 4（12-20 周） -- 如预算允许，引入 1 个商业法律数据库作为编辑检索与历史补全工具 -- 扩大参考案例和历史版本覆盖 - -5. Phase 5（专家级） -- 让系统具备 time-aware（时间生效意识）与 source-aware（来源意识）能力 -- 每一个结论、每一条红线建议，都应尽量展示： - `authority -> interpretation -> case -> clause -> suggestion` -- 同时支持： - - 生效日期过滤 - - 历史版本识别 - - 客户级政策覆盖 - -### 12.3 一个非常重要的架构原则 -真正的专家级法务系统，不是“只会吐答案”，而是要会给出证据链。 - -也就是说，最终平台应尽量做到： -- 不是只说“这条合同有风险” -- 而是能说清楚： - - 法律依据是什么 - - 司法解释怎么说 - - 哪类案例支持这个判断 - - 对应条款为何有问题 - - 建议替换成什么表达 - -这才是平台从“会回答”升级到“可信可用”的关键。 - -### 12.4 Codex 提醒的 5 个核心风险 -1. Authority risk（权威性风险） -- 官方公开文本具有权威性，但“可公开查看”不等于“可无限制商业再分发” -- 因此必须设计来源、引用、展示与授权边界 - -2. Versioning risk（版本风险） -- 法律、行政法规、司法解释经常修订 -- 如果没有时间与版本字段，系统极易给出过时结论 - -3. Product-liability risk（产品责任风险） -- 审查规则、清单、风控建议是价值最高的一层 -- 同时也是最容易因编辑错误带来责任的一层 -- 必须有审校与发布治理 - -4. Confidentiality risk（保密风险） -- 客户模板、客户规则、客户知识卡片必须租户隔离 -- 默认不得进入公共导出包 - -5. Coverage risk（覆盖风险） -- 官方示范文本对消费、公用、部分监管行业很强 -- 但对现代 B2B、SaaS、AI、平台型业务支持不够 -- 因此内部原创模板与规则体系几乎不可避免 - -## 13. 当前结论 - -这件事非常值得做，而且现在正是做的时机。 - -因为： -- 功能壳子已经差不多了 -- 内容智力才是真正决定平台上限的核心 -- 一旦内容中台建立起来，后续 PDF 审查、合同生成、问答、训练、行业扩展都会一起被拉升 -- Codex 的并行研究进一步证明：真正拉开差距的，不是页面数量，而是“可追溯证据链 + 可版本化内容包 + 可治理的规则系统” - -一句话总结： -接下来平台最重要的研发，不是“再多做一个按钮”，而是“建立一个可持续扩充、可审校、可版本化、可追溯证据链的中国法务知识与模板中台”。 - -## 14. 推荐的立即执行顺序 - -如果现在就进入实做，我建议顺序固定为： - -1. 先定内容 taxonomy 与 schema -2. 再建 source registry（来源注册表） -3. 再做首批 100 个资产清单与命名规范 -4. 再开始填充 laws / interpretations / templates / rules 四大主包 -5. 最后把这些内容挂到现有 training / import-export / dashboard 承载链路上 - -这样做的好处是：先把脑子骨架搭对，再往里装知识，不会越做越乱。 - -## 15. 你最需要提供的协助 - -为了让我和 Codex 真正开始“填内容”，而不只是停留在方案阶段，你最重要的协助是 4 个授权/决策： - -1. 确认首批优先行业 -2. 确认是否允许建立内部标准模板体系 -3. 确认是否允许脱敏沉淀客户真实合同 -4. 确认是否愿意后续采购商业法律数据库作为编辑检索/历史回溯增强源（不是现在必须买，但要提前定方向） - -一旦这 4 个点明确，我就可以正式进入内容底座建设执行阶段。 diff --git a/docs/ICT交易全书_出版终校版.md b/docs/ICT交易全书_出版终校版.md new file mode 100644 index 0000000..01cdca6 --- /dev/null +++ b/docs/ICT交易全书_出版终校版.md @@ -0,0 +1,18157 @@ +# 《ICT交易全书：从基础认知到专业执行》 + +## 目录说明 + +为避免手工目录在多轮修订后失真，本稿在 `Markdown` 源文件中不再保留手填页码目录块。 +电子书与印刷导出版统一由排版引擎自动生成可点击目录与书签导航，并在导出阶段写入真实页码。 + +--- + +## 体例说明 + +1. 全书各章统一采用 `X.1 ~ X.11` 结构，分别覆盖核心问题、定义、逻辑、执行、误区、深化与训练。 +2. 术语首次出现时采用中英并列，并在后文保持同一语义边界，避免同词多义。 +3. 章末注释用于说明来源锚点与方法边界，确保论述可追溯、可复核。 +4. 训练清单与达标标准用于教学与复盘，不构成任何收益承诺。 + +--- + +# 第一部分　市场语言：Price Delivery、Dealing Range 与交易框架 + +第一部分是全书起点。 +它不急于讲复杂模型，而是先回答一个根问题： + +**市场到底该如何被阅读。** + +如果一开始只看形态与信号，后续术语会很快碎片化； +只有先建立统一语言，后面所有章节才有共同坐标。 + +--- + +## 本部分定位 + +本部分的任务是建立六个基础支点： + +1. 价格不是随机波动，而是递送过程。 +2. 递送总发生在可定义的范围中。 +3. 交易搭建必须先环境、后锚点。 +4. 价格会被目标吸引，方向必须目标化。 +5. 同方向里仍有位置优劣。 +6. 退出必须内部/外部分层，而非单点拍板。 + +--- + +## 六章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第1章 | 价格为何应被理解为递送而非随机涨跌 | +| 第2章 | 递送发生在什么空间（Dealing Range） | +| 第3章 | Setup 如何由 Context 与 Reference Point 构成 | +| 第4章 | Draw on Liquidity 如何定义方向目标 | +| 第5章 | Premium/Discount/OTE 如何决定同向执行质量 | +| 第6章 | IRL/ERL 如何把退出从感觉变成结构 | + +--- + +## 学习边界 + +第一部分最容易被误学成“术语记忆”。 +请固定原则： + +**先建立统一阅读框架，再谈局部入场技巧。** + +也就是说，先回答“市场在做什么、在哪做、往哪去”，再回答“我在哪里做”。 + +--- + +## 学完应具备 + +完成第一部分后，你应能： + +1. 用递送视角描述价格，而非只说涨跌。 +2. 先定义范围，再判断方向与位置。 +3. 为每笔交易写出目标与失效，而非口头看法。 +4. 在同方向中筛选更优位置。 +5. 用内部/外部目标做分层兑现。 + +--- + +## 与后续章节的连接 + +第一部分回答“语言与骨架”，第二部分将回答“为什么先清理再递送”，第三部分将回答“价格在哪些位置更容易反应”。 +没有第一部分，后续所有工具都会退化为图形识别。 + +--- + +## 章末注释 + +[1] 本导读用于建立第一部分的学习边界与章节职责，不替代各章定义与执行规则。 +[2] 建议进入第二部分前，先复核第4章（Draw）与第6章（IRL/ERL）的执行模板。 + + + +# 第1章　Price Delivery 与 IPDA：价格不是随机波动，而是被递送 + +## 1.1　本章核心问题 + +本章只解决一个主问题： + +**为什么在 ICT 框架中，价格应被理解为“递送过程”，而非“随机涨跌”？** + +围绕该主问题，本章回答四个子问题： + +1. `Price Delivery` 的工作定义与边界是什么。 +2. `IPDA` 如何为日内价格运动提供节律框架。 +3. 为什么“先识别递送状态”比“先判断涨跌方向”更有效。 +4. 该认知如何转化为后续章节的执行前提。 + +--- + +## 1.2　一句话结论 + +**交易不是先猜涨跌，而是先定义当下 Range、识别 Draw、确认 Path 与 Time，并在入场前写明 Invalidation；五项缺一，不应交易。** + +--- + +## 1.3　基础定义 + +### 一、Price Delivery（价格递送） + +**定义：** +价格在特定时间窗口与区间结构中，朝向流动性目标或再定价目标推进的过程。 + +**边界：** + +1. 它描述“过程”，不是单根 K 线结果。 +2. 它强调“有条件的方向性”，不是机械预测。 +3. 它依赖可验证证据，不是事后解释话术。 + +### 二、IPDA（Interbank Price Delivery Algorithm，银行间价格递送算法） + +**定义：** +用于描述价格在日内不同会话中递送节律的框架语言，核心作用是把“价格变化”组织为“时间分布下的递送行为”。 + +**边界：** + +1. IPDA 是观察框架，不是阴谋论叙事。 +2. IPDA 不能替代结构与流动性证据。 +3. IPDA 不保证每个交易日都出现清晰机会。 + +### 三、本章统一术语卡（首现定义） + +| 术语 | 英文 | 工作含义 | +| --- | --- | --- | +| 递送范围 | Dealing Range | 当前价格主要活动空间，由 Key High 与 Key Low 约束 | +| 流动性牵引 | Draw on Liquidity | 价格更可能优先处理的一侧流动性目标 | +| 递送路径 | Delivery Path | 价格到达目标所采用的阶段过程 | +| 失效点 | Invalidation | 使原叙事不再成立的结构条件 | +| 扩张 | Expansion | 从均衡或区间中脱离并形成方向推动 | +| 回撤 | Retracement | 同方向内部的回补与修复 | +| 反转 | Reversal | 原方向失效并由反向结构接管 | +| 整理 | Consolidation | 波动压缩、订单积累、尚未有效扩张 | + +### 四、四状态先后约束（状态机） + +在可执行语境下，优先遵循： + +`Consolidation -> Expansion -> (Retracement / Reversal)` + +含义是：没有清晰扩张证据前，不宜过早定义“反转”。 + +--- + +## 1.4　底层逻辑 + +### 一、递送逻辑解决的是“组织问题” + +交易并不需要解释每一次报价跳动，而是要识别可组织、可验证、可管理风险的行为段落。 +当我们把价格放入“范围—状态—目标—时间—失效”框架时，噪音会显著下降，决策标准会显著提高。 + +### 二、价格通常在“待处理问题”之间移动 + +市场常见的两个“待处理问题”： + +1. **流动性问题：** 一侧高低点、等高等低、会话极值处存在订单堆积。 +2. **再定价问题：** 快速位移后，局部定价效率不足，后续常有回补与再平衡需求。 + +因此，价格并非无目的摆动，而是经常在“清理流动性”与“修复定价效率”之间切换推进。 + +### 三、递送是阶段过程，不是直线运动 + +典型递送常包含： + +1. 先清理一侧流动性； +2. 再出现位移与结构表达； +3. 随后回补至关键区域； +4. 最终延续至下一目标。 + +“中途回撤”不等于“叙事失效”，关键在于回撤是否破坏了原失效边界。 + +### 四、时间是递送变量，不是装饰变量 + +同一结构在不同时间窗口，质量差异显著。 +时间过滤的意义在于：把“可能发生”收敛为“更可能在何时发生”。 + +### 五、Price Delivery 的真实作用 + +Price Delivery 不是为了制造确定性，而是为了： + +1. 提出可验证叙事； +2. 标注无效边界； +3. 在错误时快速退出； +4. 在正确时有层级地兑现目标。 + +--- + +## 1.5　结构关系 + +### 一、与前后章节的接口 + +1. 本章回答“价格在做什么”（递送）。 +2. 第2章回答“价格在什么空间里做”（Dealing Range）。 +3. 第3章回答“哪些条件构成可执行 Setup”（Context/Framework/Reference Point）。 +4. 第4章回答“价格为何被目标吸引”（Draw on Liquidity）。 +5. 第5章与第6章回答“同方向中哪里更优”（Premium/Discount 与 Internal/External）。 + +### 二、本章在全书中的地位 + +后续所有工具（FVG、Order Block、MSS、Session 模型）都只是递送语言的局部实现。 +如果缺少本章框架，工具会退化为“图形识别技巧”。 + +--- + +## 1.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境（可复现） + +**情境：偏空日内递送** + +1. 亚洲时段形成窄幅整理区间； +2. 伦敦时段先上扫买方流动性； +3. 随后出现向下位移，形成结构接管证据； +4. 纽约时段回补后继续下行，触达卖方目标。 + +**可观察特征：** + +1. “先清理，后递送”； +2. “位移后回补，再延续”； +3. “时间窗口与路径一致”。 + +### 二、反例情境（应回避） + +1. 全天多数时间围绕均衡点来回摆动； +2. 多次假突破但无有效位移； +3. 关键时段过去后仍无清晰路径。 + +在此情境下，最优决策通常是等待，而非强行解释。 + +### 三、实盘与复盘差异 + +复盘是“已知答案看过程”；实盘是“过程未完成做决策”。 +因此，实盘要使用“条件触发式判断”，而非“结果导向式解读”。 + +--- + +## 1.7　执行意义 + +本章对执行系统的核心贡献是第一道过滤器： + +**没有清晰递送，就不进入执行。** + +### 条件—触发—确认—执行—退出（五步标准） + +| 步骤 | 执行标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 明确当前 Dealing Range 与主要 Draw | 未定义 Key High/Low 不开仓 | +| 触发 | 出现流动性事件与有效位移 | 至少 1 次清理 + 1 次方向位移 | +| 确认 | 回补后未破坏失效边界 | 回补不应夺回关键接管结构 | +| 执行 | 仅在叙事、时间、位置同向时入场 | 单笔风险固定（如账户风险上限 0.5%-1%） | +| 退出 | 按目标层级兑现，失效立即离场 | 先内部目标，后外部目标；触发失效则平仓 | + +### 执行模板（可直接用于交易计划） + +1. `Range`：当前范围是 ________ +2. `Draw`：优先目标是 ________ +3. `Path`：预期路径是 ________ +4. `Time`：有效窗口是 ________ +5. `Invalidation`：失效条件是 ________ + +--- + +## 1.8　常见误区 + +### 误区一：把递送当作“必然到达” + +**识别信号：** 目标位被当成必到位。 +**纠偏动作：** 每笔交易先写失效条件，再写目标。 + +### 误区二：把递送理解为“单边直线” + +**识别信号：** 一次回撤就认定叙事终结。 +**纠偏动作：** 先判定回撤性质，再判定是否反转接管。 + +### 误区三：只看图形，不看时间 + +**识别信号：** 结构相似就机械复制。 +**纠偏动作：** 把时间窗口列为入场前置条件。 + +### 误区四：先选工具，再拼叙事 + +**识别信号：** 先找 FVG/OB，再找理由。 +**纠偏动作：** 先写“Range+Draw+Path”，后选工具。 + +### 误区五：只讲方向，不讲位置 + +**识别信号：** 只说看涨/看跌，不标注 Premium/Discount。 +**纠偏动作：** 方向判断必须绑定位置质量。 + +### 误区六：复盘全会，实盘全乱 + +**识别信号：** 事后解释完整，事前计划空白。 +**纠偏动作：** 用同一模板做“事前-事中-事后”三段记录。 + +--- + +## 1.9　高阶深化 + +### 一、多周期嵌套：局部服从全局 + +低周期信号只有在高周期叙事中才有稳定意义。 +工作顺序建议固定为：`高周期定叙事 -> 中周期定路径 -> 低周期找触发`。 + +### 二、路径切换：延续与反转的分水岭 + +路径切换不靠主观感受，靠“接管证据”： + +1. 反向位移是否成立； +2. 关键结构是否被夺回； +3. 回补后是否出现同向续推失败。 + +满足两项以上，再考虑“递送切换”。 + +### 三、叙事质量评分（进阶） + +可用 5 分制筛选交易： + +1. Range 清晰度（0/1） +2. Draw 清晰度（0/1） +3. Path 可验证性（0/1） +4. Time 匹配度（0/1） +5. Invalidation 明确度（0/1） + +**总分低于 4 分，不建议执行。** + +### 四、从“术语学习者”到“框架执行者” + +成熟交易者的关键转变不是会更多术语，而是能回答： + +**这个 Setup 是否服务于一条高质量递送叙事？** + +--- + +## 1.10　本章总结 + +1. Price Delivery 是全书第一层市场语言，核心在“过程组织”，不在“结果描述”。 +2. IPDA 提供日内递送节律框架，但不能替代结构、流动性与时间证据。 +3. 有效判读遵循“整理 -> 扩张 ->（回撤/反转）”的状态约束。 +4. 可执行交易必须同时具备：Range、Draw、Path、Time、Invalidation。 +5. 本章真正目的不是提高预测幻觉，而是提升决策边界与风险控制质量。 + +--- + +## 1.11　训练清单 + +### 一、观察任务（20 日状态标注） + +任务：连续 20 个交易日标注四状态转换。 +达标：至少 15 天的状态判读在复盘复核中保持一致。 + +### 二、标注任务（五字段日志） + +任务：每个样本必须写满 `Range-Draw-Path-Time-Invalidation`。 +达标：样本中 100% 含明确失效点，不允许只写目标位。 + +### 三、反例任务（无交易环境识别） + +任务：收集 10 个“看似有机会但应回避”的样本。 +达标：每个样本都能指出“不做”的客观原因（范围不清、时间错配、位移无效等）。 + +### 四、嵌套任务（多周期映射） + +任务：任选 15 个 5M 信号，回溯其在 1H/4H 的叙事位置。 +达标：至少 10 个样本可明确判断“顺上位叙事”或“逆上位叙事”。 + +### 五、复盘任务（亏损归因） + +任务：抽取最近 10 笔亏损交易，按以下类别归因： +状态误判 / 时间错配 / 路径错判 / 失效执行失败。 + +达标：每一类至少产出 1 条可执行改进规则，并在下一周实盘执行。 + +### 六、执行前检查清单（每笔交易必填） + +1. 我定义了当前 Range 吗？ +2. 我知道优先 Draw 吗？ +3. 我识别了当前 Path 阶段吗？ +4. 我在有效 Time 窗口内吗？ +5. 我写了 Invalidation 并愿意执行吗？ + +五题有任意一题为“否”，本笔交易自动取消。 + +--- + +## 章末注释 + +[1] 本章术语与路径结构，基于 ICT 课程资料中关于 Price Delivery、IPDA、四状态框架、日内时间分布与流动性递送逻辑的共同定义整理。 +[2] 本章中的“量化锚点（示例）”用于训练执行一致性，不构成收益承诺；具体参数应由交易者依据市场品种、波动水平与账户约束完成个性化校准。 +[3] 本章与第2章的接口为“空间定义”，与第3章的接口为“Setup 条件化”，与第4章的接口为“目标牵引机制”。 + + + +# 第2章　Dealing Range：市场始终在区间、象限与均衡中工作 + +## 2.1　本章核心问题 + +第1章回答了“价格在递送”，本章回答“价格在什么空间里递送”。 + +本章只解决一个主问题： + +**如何把 Price Delivery 放进可标注、可验证、可执行的范围框架（Dealing Range）？** + +围绕该主问题，展开四个子问题： + +1. 什么是当前可交易的 Dealing Range。 +2. 为什么 Key High、Key Low、Equilibrium 是范围阅读三要素。 +3. Premium / Discount 为什么会直接影响执行质量。 +4. Internal / External Range Liquidity 如何用于分层目标管理。 + +--- + +## 2.2　一句话结论 + +**交易不是先判断涨跌，而是先定义 Dealing Range，再确认价格处于 Premium、Discount 还是 Equilibrium，最后决定执行方向、目标层级与持仓风格。** + +换句话说： + +1. Price Delivery 解决“价格在做什么”。 +2. Dealing Range 解决“价格在什么空间里做”。 + +--- + +## 2.3　基础定义 + +### 一、Dealing Range（交易区间） + +**定义：** +当前分析层级下，价格主要活动的工作区间，至少由一个有效高点与有效低点界定。 + +**边界：** + +1. Dealing Range 不是装饰线，而是交易坐标系。 +2. Dealing Range 不等于“只有横盘才存在”的箱体。 +3. Dealing Range 可以在不同时间框架同时成立。 + +### 二、Key High / Key Low（关键高低点） + +**定义：** +用于确定当前范围上边界与下边界的关键锚点。 + +**作用：** + +1. 提供位置判断基准。 +2. 约束止损与目标表达。 +3. 连接内部与外部流动性目标。 + +### 三、Equilibrium（均衡） + +**定义：** +当前范围的中值平衡区域，实务中常用 50% 位置作为工作中轴。 + +**关键认知：** + +1. Equilibrium 是信息压缩区，不是方向确认区。 +2. 在中值附近，单边信号质量通常下降。 +3. 中值区更适合等待“证据展开”，不适合放大主观仓位。 + +### 四、Premium / Discount（溢价区 / 折价区） + +| 术语 | 含义 | 执行含义 | +| --- | --- | --- | +| Premium | 相对范围中值偏高区域 | 顺多追价质量下降，顺空位置改善 | +| Discount | 相对范围中值偏低区域 | 顺空追价质量下降，顺多位置改善 | + +**关键认知：** +Premium / Discount 不是“预测方向”工具，而是“同方向下的位置优劣”工具。 + +### 五、IRL / ERL（内部 / 外部范围流动性） + +| 术语 | 含义 | 常见对象 | +| --- | --- | --- | +| IRL | Internal Range Liquidity，范围内部目标 | 内部高低点、内部失衡、内部数组 | +| ERL | External Range Liquidity，范围外部目标 | 边界外侧流动性、外部旧高旧低 | + +**执行含义：** + +1. 先内部兑现，后外部扩展。 +2. 先锁定可得收益，再争取延伸收益。 + +### 六、范围层级（Fractal Range） + +同一时刻可存在多个范围：日线范围、4H 范围、日内范围可并存。 +关键不在“唯一正确范围”，而在“当前执行依据的是哪一层级范围”。 + +### 七、与普通支撑阻力的区别 + +Dealing Range 不仅用于“看区间震荡”，更用于： + +1. 定义 Premium / Discount。 +2. 组织 IRL / ERL 目标分层。 +3. 校准止损、目标与持仓风格。 + +--- + +## 2.4　底层逻辑 + +### 一、没有范围，就没有位置；没有位置，就没有执行质量 + +“高位、低位、贵、便宜”都必须相对于某个范围才有意义。 +缺少范围定义的方向判断，通常只剩主观感受。 + +### 二、范围是 Bias 的执行过滤器 + +方向偏见只能回答“倾向哪边”，范围位置回答“是否值得现在做”。 +方向与位置冲突时，优先等待位置改善。 + +### 三、Equilibrium 附近是“高噪音低效率”地带 + +中值区常见问题： + +1. 止损逻辑不清。 +2. 目标空间不足。 +3. 双向扫动频繁。 + +因此，中值区更适合轻仓试探或观望，而非重仓押注。 + +### 四、市场常先在范围内处理，再从范围扩张 + +很多高质量推进都经历： + +1. 先定义边界； +2. 再累积流动性； +3. 然后在关键时段完成扩张。 + +Range 不是“没行情时才有用”，而是“行情启动前最重要的组织结构”。 + +### 五、范围的本质是“空间约束 + 目标分层” + +一旦范围建立，内部与外部目标就可拆分管理： +内部目标用于兑现效率，外部目标用于收益扩展。 + +### 六、Dealing Range 是 Price Delivery 的空间化表达 + +第1章解决“递送是什么”，本章解决“递送在哪个容器里发生”。 +没有范围容器，后续 Draw、PD Arrays、结构切换都无法统一坐标。 + +### 七、成熟表达从“涨跌”升级为“从哪里到哪里” + +专业交易语言应能表达： + +1. 从 Discount 到 Equilibrium。 +2. 从内部目标到外部目标。 +3. 从边界清理到反向递送。 + +--- + +## 2.5　结构关系 + +### 一、承接第1章 + +第1章解决“价格在做什么”；第2章解决“价格在什么空间里做”。 +缺少本章，递送叙事会退化为事后解释。 + +### 二、通向第3章 + +本章建立“范围坐标”，第3章建立“环境与锚点配对”。 +即：`Location -> Context -> Setup Type`。 + +### 三、通向第4章 + +范围定义完成后，下一步是目标牵引： +价格更可能先处理哪一侧流动性，这就是 Draw on Liquidity。 + +### 四、通向第5章与第6章 + +第5章深化 Premium / Discount；第6章深化 Internal / External。 +二者不是新体系，而是本章的执行深化。 + +### 五、与全书执行系统的关系 + +后续几乎所有入场触发都要经过本章过滤： +范围不清、位置不优、目标不明时，信号价值显著下降。 + +--- + +## 2.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：范围内部往返** + +1. 价格在明确高低之间反复处理内部位置。 +2. 小级别冲高回落频繁出现，但未完成有效扩张。 +3. 边界价值通常高于中部波动价值。 + +**标准情境B：趋势中的范围回补** + +1. 更高周期方向不变。 +2. 价格回到当前范围的 Discount 或 Premium。 +3. 先处理 IRL，再评估是否延伸至 ERL。 + +**标准情境C：先处理一端，再递送另一端** + +1. 先清理 Range High 或 Range Low 一侧流动性。 +2. 随后转向另一端目标递送。 +3. Range、Liquidity、Delivery 三者在同一叙事中闭环。 + +**反例情境：均衡粘滞** + +1. 价格长时间围绕中值。 +2. 方向信号反复失真。 +3. 最优动作常是降频、快进快出或等待。 + +### 二、交易中的真实表现 + +实盘常见“看不懂”，本质是“没先定范围”： + +1. 用局部范围解释高周期方向。 +2. 用高周期结论忽视局部回补。 +3. 把范围噪音误判为结构切换。 + +方向错误并非最常见问题，**位置错误**才是慢性亏损源头。 +本章的核心价值就是减少“方向对、执行错”。 + +### 三、简化示例 + +若日线偏多，4H 形成工作范围，5M 回落到 4H Discount： +5M 下跌不必然是“转空”，更可能是“高周期递送中的位置修复”。 +范围视角可以显著降低低周期噪音误导。 + +--- + +## 2.7　执行意义 + +本章将执行前流程固化为“3B 判断 + 五步动作”。 + +### 一、3B 判断 + +| 步骤 | 问题 | +| --- | --- | +| B1 | 当前结构背景与 Bias 是什么 | +| B2 | 当前主要 Draw on Liquidity 是什么 | +| B3 | 当前价格在本级 Range 的哪里（Premium / Discount / Equilibrium） | + +**关键原则：** +B1 与 B2 成立，但 B3 位置不优时，执行质量仍会大幅折扣。 + +### 二、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 先定义 Key High/Low 与 Equilibrium | 三要素未定义，不开仓 | +| 触发 | 位置与方向一致后再等触发 | 不在中值区强行找单边 | +| 确认 | 确认非随机穿越而是路径展开 | 回补后不破关键失效边界 | +| 执行 | 只在有位置优势时表达风险 | 单笔风险上限可设 0.5%-1% | +| 退出 | 先 IRL，再评估 ERL | 不把内部交易强行拖成外部扩张 | + +### 三、失效硬规则 + +1. 价格回到 Equilibrium 且方向证据退化，原叙事降级为“待验证”。 +2. 范围边界被新结构重绘时，旧范围不再是主执行坐标。 +3. 目标与位置冲突时，优先守位置，不为叙事强行入场。 + +### 四、执行前五问 + +1. 我依据的是哪个时间框架的 Range？ +2. 当前价格在该 Range 的哪里？ +3. 我做的是内部回归还是外部扩张？ +4. 我的失效边界是否明确？ +5. 若失效出现，我是否会机械执行退出？ + +五问有一项答不清，本笔交易延后。 + +--- + +## 2.8　常见误区 + +### 误区一：不定义范围就交易 + +**识别信号：** 只说看涨看跌，不标注 Key High / Key Low。 +**纠偏动作：** 每笔交易先写范围，再写方向。 + +### 误区二：把 Range 当成“只有盘整才有” + +**识别信号：** 只有横盘时才画范围。 +**纠偏动作：** 趋势中的推动与回撤同样可形成工作范围。 + +### 误区三：把 Equilibrium 当成高胜率起点 + +**识别信号：** 中值区重仓押单边。 +**纠偏动作：** 中值区降预期、降仓位、等证据。 + +### 误区四：混淆 IRL 与 ERL + +**识别信号：** 内部结构交易却按外部扩张管理。 +**纠偏动作：** 先内部分批，后评估外部延伸。 + +### 误区五：方向对但位置差 + +**识别信号：** Premium 追多、Discount 追空。 +**纠偏动作：** 把“位置优劣”设为入场门槛。 + +### 误区六：把范围画成静态框 + +**识别信号：** 结构变化后仍使用旧边界。 +**纠偏动作：** 随新高低点与新结构动态更新范围。 + +### 误区七：执着寻找“唯一正确范围” + +**识别信号：** 多层级范围并存时陷入分析瘫痪。 +**纠偏动作：** 先选执行层级，再检验上下级一致性。 + +### 误区八：只会画范围，不会用范围 + +**识别信号：** 图上画满线，执行仍无标准。 +**纠偏动作：** 每次画完都要回答“它服务哪个目标与哪种路径”。 + +--- + +## 2.9　高阶深化 + +### 一、范围是分形结构，不是单一框 + +高周期给边界与方向约束，低周期给执行精度。 +高质量执行依赖主从范围的协同，而非单层级孤立判断。 + +### 二、同一价格在不同范围中意义不同 + +同一价位可能在 15M 是 Premium，在 4H 是 Equilibrium，在日线是 Discount。 +位置永远是相对概念，不是绝对标签。 + +### 三、内部逻辑与外部逻辑必须分离 + +内部逻辑：做区间内回归与内部兑现。 +外部逻辑：做边界处理后的扩张与外部递送。 +混用两套逻辑，是多数持仓回吐的根源。 + +### 四、位置与目标冲突时的优先级 + +目标叙事再好，位置无优势也应等待。 +专业执行遵循“先位置，后冲动”。 + +### 五、分层兑现是账户稳定器 + +先兑现 IRL 可降低回吐压力，再用余仓争取 ERL。 +它不追求每次吃满，而追求长期权益曲线稳定。 + +### 六、成熟执行的本质 + +不是“找到更多机会”，而是“在更优位置只做更少机会”。 + +### 七、本章工作公式 + +`Trade Location = Range State + Premium/Discount + Objective Layer (IRL/ERL) + Invalidation` + +该公式与第1章递送公式互补，贯穿后续模型与执行章节。 + +--- + +## 2.10　本章总结 + +1. Dealing Range 是交易定位系统，不是画图装饰。 +2. Key High、Key Low、Equilibrium 构成范围阅读三要素。 +3. Premium / Discount 决定同方向内的执行质量差异。 +4. Equilibrium 区域信息压缩，应降低主观强度。 +5. IRL / ERL 分层兑现，是从会分析到能执行的关键步骤。 + +--- + +## 2.11　训练清单 + +### 一、观察任务：逐日标注范围三要素 + +任务：抽取 30 个样本日，标注 Key High、Key Low、Equilibrium 与收盘分区。 +达标：至少 24 个样本的分区判读与后续叙事一致。 + +### 二、观察任务：三层级范围对照 + +任务：同一段行情在日线、4H、15M 各定义一个 Range。 +达标：可清楚表达“在 X 周期是 Premium，在 Y 周期是 Discount”。 + +### 三、标注任务：两级目标拆分 + +任务：每个样本同时给出 IRL 与 ERL。 +达标：100% 样本均有内部目标与外部目标，不只写单一终点。 + +### 四、标注任务：内部或外部逻辑判别 + +任务：找 20 个样本判断当前主要是内部处理还是外部扩张。 +达标：至少 15 个样本能给出一致判读理由。 + +### 五、复盘任务：范围错误统计 + +任务：复盘 20 笔交易，统计四类错误： +未定义范围入场 / 中值区重仓 / IRL-ERL 混用 / 范围失效未更新。 +达标：每类沉淀 1 条可执行前置检查。 + +### 六、复盘任务：目标管理重演 + +任务：抽取 10 笔历史单，重演“中值目标—边界目标—外部目标”三层止盈。 +达标：每笔可明确说明若分层管理，回吐是否下降。 + +### 七、连接任务：进入第3章 + +任务：在已标注 Range 的图表上继续回答： +当前属于哪种状态，哪个参考点最相关，是否已具备 Setup 条件。 +达标：能够自然从“位置语言”过渡到“搭建语言”。 + +--- + +## 章末注释 + +[1] 本章内容依据 ICT 课程中关于 Dealing Range、Equilibrium、Premium/Discount 与 IRL/ERL 的核心定义统一整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种波动与账户约束自行校准。 +[3] 本章与第3章接口为“位置到搭建”：先定空间坐标，再做环境与参考点配对。 + + + +# 第3章　Elements of a Trade Setup：Context / Framework 与 Reference Point + +## 3.1　本章核心问题 + +第1章解决“价格在递送”，第2章解决“价格在什么空间里递送”。 +本章继续回答执行前最后一个基础问题： + +**什么才是 ICT 语境下“结构上成立”的 Trade Setup？** + +本章聚焦四个子问题： + +1. 为什么 Setup 不是单图形，而是“环境 + 锚点”的配对结构。 +2. 四类 Context / Framework 分别该配哪些 Reference Point。 +3. 为什么配对错误会导致“方向对、执行错”。 +4. 为什么在信息不清时，等待本身就是流程动作。 + +--- + +## 3.2　一句话结论 + +**ICT 交易搭建的核心不是找图形，而是先识别当前环境（Context / Framework），再把环境与对应参考点（Reference Point）正确配对；配对正确，Setup 才具备可执行性。** + +三章逻辑到此形成闭环： + +1. 第1章：价格在做什么（Price Delivery）。 +2. 第2章：价格在什么空间里做（Dealing Range）。 +3. 第3章：在该空间与状态下该搭哪类 Setup（Location -> Context -> Setup Type）。 + +--- + +## 3.3　基础定义 + +### 一、Trade Setup 的双要素 + +一个完整 Setup 由两部分组成： + +| 构成 | 含义 | +| --- | --- | +| Context / Framework | 当前市场状态与叙事环境 | +| Reference Point | 与该状态匹配的机构参考锚点 | + +**关键认知：** + +1. 只有环境，没有锚点，无法执行。 +2. 只有锚点，没有环境，容易误触发。 +3. 二者配对，才形成可验证的 Setup。 + +### 二、四类 Context / Framework + +| 状态 | 含义 | +| --- | --- | +| Expansion | 从均衡脱离并形成方向推进 | +| Retracement | 在既有推进后进行回补修复 | +| Reversal | 原方向失效并由反向结构接管 | +| Consolidation | 区间内积累，暂未出现有效扩张 | + +### 三、Reference Point 配对映射 + +| Context | 优先 Reference Point | +| --- | --- | +| Expansion | Order Block | +| Retracement | Fair Value Gap / Imbalance / Liquidity Void | +| Reversal | Liquidity Pool / Stop Run | +| Consolidation | Equilibrium | + +这张映射表不是记忆口诀，而是 Setup 语法。 + +### 四、Market Efficiency Paradigm（本章用法） + +本章采用其核心操作原则： +**先识别环境，再选择工具；顺序不可倒置。** + +### 五、状态先后约束（硬规则） + +在执行语境中，优先遵循： + +`Consolidation -> Expansion -> (Retracement / Reversal)` + +含义是： + +1. 没有清晰扩张证据，不应提前定义回撤或反转。 +2. 跳过先后顺序，会把“未成立路径”误当“既定事实”。 + +### 六、Anticipatory Skill Set（预判技能） + +它不是主观猜测，而是结构化预判能力： + +1. 先识别当前最可能状态。 +2. 再定义下一步应观察的关键证据。 +3. 最后用新证据确认或否定原假设。 + +--- + +## 3.4　底层逻辑 + +### 一、Setup 质量来自“语义匹配”，不是“工具数量” + +同一工具在不同环境中意义完全不同： + +1. FVG 在 Retracement 中常是高相关回补锚点，在无序整理中段常是噪音空隙。 +2. OB 在有效位移起点附近常有价值，在区间中部随机反向 K 线中价值显著下降。 +3. Liquidity Pool 在 Reversal 语境中是切换前提，在其他语境中可能只是普通边界。 + +### 二、先后顺序是执行硬约束 + +若跳过状态顺序，常见后果是： + +1. 在盘整中途提前判回撤或反转。 +2. 在未位移时提前激活锚点。 +3. 在错误阶段持续表达风险。 + +### 三、四环境对应四类“最相关证据” + +1. Expansion 重点看 OB，因为它常对应位移起点语义。 +2. Retracement 重点看 FVG / Imbalance，因为其核心任务是修复低效率定价。 +3. Reversal 重点看 Liquidity Pool / Stop Run，因为真实切换常由流动性处理触发。 +4. Consolidation 重点看 Equilibrium，因为它是区间状态的中轴。 + +### 四、等待是 Setup 的组成部分 + +当环境不可辨识时，等待不是“空白动作”，而是“正确动作”。 +无清晰 Context 时强行配对工具，通常只会提升试错频率。 + +### 五、环境识别决定“先看什么” + +图形交易思路是“先找信号”；框架交易思路是“先定环境”。 +这一步差异，决定了执行是否可重复、可复盘、可迭代。 + +--- + +## 3.5　结构关系 + +### 一、承接第2章 + +第2章解决“你在范围的哪里”；第3章解决“在这个位置该搭什么 Setup”。 +两章合并后，才形成完整的执行前提。 + +### 二、通向第4章 + +本章定义“怎么搭”，第4章定义“往哪去”（Draw on Liquidity）。 +没有目标牵引，Setup 容易停留在局部图形反应。 + +### 三、通向 PD Arrays 章节 + +第13-17章将展开本章 Reference Point 体系： +FVG、OB、Liquidity Pool、Breaker/Mitigation 都是本章配对逻辑的深化。 + +### 四、通向模型与执行章节 + +后续第35章起的模型化执行，本质都可还原为： +`先环境 -> 后锚点 -> 再触发 -> 再风险表达`。 + +### 五、在全书中的定位 + +第3章是“认知到执行”的桥梁章节： +没有这座桥，前两章知识难以稳定转化为下单流程。 + +--- + +## 3.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Expansion + OB** + +1. 先有 Consolidation。 +2. 后有位移脱离均衡。 +3. 再识别与位移语义一致的 OB。 + +**标准情境B：Retracement + FVG / Imbalance** + +1. 先有推进。 +2. 再有回补。 +3. 回补目标多落在先前低效率区域。 + +**标准情境C：Reversal + Liquidity Pool / Stop Run** + +1. 先处理一侧流动性。 +2. 再出现方向接管证据。 +3. 反转叙事才具备结构基础。 + +**标准情境D：Consolidation + Equilibrium** + +1. 价格围绕区间中轴反复波动。 +2. 中轴与边界共同约束后续位移观察。 +3. 中段信号价值通常低于边界信号价值。 + +**反例情境：工具对了，环境错了** + +1. 在无扩张的整理中段机械用 FVG 做延续。 +2. 在无流动性事件前提前定义反转。 +3. 在位移未完成时过早把局部回踩当确认。 + +### 二、交易中的真实表现 + +实盘最常见问题不是“不懂术语”，而是“术语激活顺序错误”： +看到工具就想做，而不是先判定环境再选工具。 + +当你稳定回答“当前是何种 Context”，工具选择会自然收敛， +交易会从“多术语试错”升级为“少模型高一致性”。 + +--- + +## 3.7　执行意义 + +本章将 Setup 执行流程固定为“二阶段 + 五步动作”。 + +### 一、二阶段 + +| 阶段 | 动作 | +| --- | --- | +| 阶段A | 先判定 Context（Expansion / Retracement / Reversal / Consolidation） | +| 阶段B | 再激活对应 Reference Point，不混用主锚点 | + +若阶段A不可辨识，阶段B自动停止。 + +### 二、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | Context 可辨识 | 30 秒内说不清状态则不交易 | +| 触发 | 出现环境一致的锚点互动 | 只做“状态-锚点”同向机会 | +| 确认 | 非随机穿越而是路径展开 | 至少具备位移或结构接管证据之一 | +| 执行 | 结构成立后表达风险 | 单笔风险上限可设 0.5%-1% | +| 退出 | 环境失效或叙事切换即离场 | 先执行失效，再谈主观解释 | + +### 三、失效硬标准 + +以下任一出现，应重建 Setup： + +1. 原环境被新证据推翻。 +2. 关键锚点被无条件穿透且语义失效。 +3. 价格退回不可判别整理区并丧失路径连续性。 + +### 四、执行前六问 + +1. 当前环境是什么？ +2. 我使用的锚点是否与环境匹配？ +3. 状态先后顺序是否成立？ +4. 我的失效边界是什么？ +5. 若失效出现，我是否会机械退出？ +6. 若环境不清，我是否愿意等待？ + +六问有一项答“否”，本笔交易取消。 + +--- + +## 3.8　常见误区 + +### 误区一：把 Setup 学成“单图形点击术” + +**识别信号：** 先找 FVG / OB，再补叙事。 +**纠偏动作：** 先写环境标签，再允许工具入场。 + +### 误区二：环境与锚点配对错位 + +**识别信号：** Reversal 语境却执着 Retracement 工具。 +**纠偏动作：** 严格执行四环境—四锚点映射表。 + +### 误区三：跳过先后约束 + +**识别信号：** 从 Consolidation 直接定义 Retracement 或 Reversal。 +**纠偏动作：** 没有 Expansion 证据，不进入后续状态判断。 + +### 误区四：不可辨识环境中硬做 + +**识别信号：** 一天多次试错，每次逻辑都不同。 +**纠偏动作：** 把“等待”写入策略，视为标准动作。 + +### 误区五：有目标无失效 + +**识别信号：** 笔记只写“看哪里”，不写“错在哪里”。 +**纠偏动作：** 每笔 Setup 必须绑定客观失效条件。 + +### 误区六：把四状态当孤立标签 + +**识别信号：** 会命名状态，不会说明前后阶段关系。 +**纠偏动作：** 每次判定都要写“前一阶段 + 下一分化路径”。 + +### 误区七：把工具当作确定性来源 + +**识别信号：** 认为“只要碰到某工具就应反应”。 +**纠偏动作：** 工具只在正确环境中才有统计意义。 + +### 误区八：复盘解释完整，实盘流程空白 + +**识别信号：** 事后逻辑很完整，事前没有标准。 +**纠偏动作：** 同模板记录“事前-事中-事后”三段证据。 + +--- + +## 3.9　高阶深化 + +### 一、环境识别的优先级体系 + +高低周期冲突时，优先服从更高层级叙事， +再在低周期寻找匹配锚点与触发。 + +### 二、锚点语义会随环境变化而漂移 + +同一 FVG 或 OB 会从“入场锚点”变成“失效证据”。 +高阶能力不是记更多区域，而是及时更新区域语义。 + +### 三、真正的 Anticipatory Skill + +预判不是猜方向，而是： + +1. 先提出“当前最可能状态”； +2. 再定义“什么证据会确认它”； +3. 同时定义“什么证据会否定它”。 + +### 四、状态感是结构交易分水岭 + +状态感建立后，你会从“看到信号就想做”， +转为“先判断是否轮到我的模型”。 + +### 五、本章工作公式 + +`Setup Quality = Context Clarity x Reference Match x Sequence Validity x Invalidation Discipline` + +四项任一缺失，Setup 可执行性显著下降。 + +### 六、与第1章和第2章公式的联动 + +1. 第1章：`Price Delivery = Range + Objective + Path + Time + Invalidation` +2. 第2章：`Trade Location = Range State + Premium/Discount + Objective Layer + Invalidation` +3. 第3章：`Setup Quality = Context Clarity x Reference Match x Sequence Validity x Invalidation Discipline` + +三式共同构成执行前完整门控。 + +--- + +## 3.10　本章总结 + +1. Trade Setup 的本质是“环境判定 + 锚点配对”，不是工具堆叠。 +2. 四类环境与四类参考点有稳定映射，不应混用。 +3. 状态先后顺序是硬约束，跳过顺序会显著增加误判。 +4. 不可辨识环境中的等待，是专业执行的一部分。 +5. Setup 质量由匹配质量决定，而非图形数量决定。 + +--- + +## 3.11　训练清单 + +### 一、观察任务：每日先做环境标签 + +任务：回放 30 个交易日，每日先做 Context 标签；不可辨识标注 `No Clear Context`。 +达标：至少 24 天的环境判定可稳定复述。 + +### 二、标注任务：环境对应锚点 + +任务：对每个样本追加匹配锚点，并写一句“为何匹配”。 +达标：100% 样本都能完成“状态-锚点-理由”三联记录。 + +### 三、标注任务：先后约束检查 + +任务：所有 Retracement / Reversal 样本必须回查是否先有 Expansion。 +达标：识别并修正全部“跳序判断”样本。 + +### 四、复盘任务：定位配对错误 + +任务：复盘 20 笔交易，归类四类失败： +环境错判 / 锚点错配 / 顺序违规 / 失效缺失。 +达标：每类至少沉淀 1 条前置检查规则。 + +### 五、复盘任务：练习“不做”的专业性 + +任务：在 30 个样本中找出至少 5 个 No Clear Context，写明为何不做。 +达标：5 个样本均能给出“等待触发条件”。 + +### 六、执行任务：二阶段打卡 + +任务：连续 10 个交易日，每笔潜在交易都先完成“阶段A + 阶段B”记录。 +达标：执行记录中“先判环境后选锚点”一致率达到 100%。 + +### 七、连接任务：进入第4章 + +任务：在已完成 Setup 配对的样本上继续回答： +它服务哪个目标？价格更可能被哪侧流动性吸引？ +达标：能够自然从“搭建语言”过渡到“目标语言”。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 课程中关于四状态框架、Reference Point 映射与执行顺序的核心定义整理。 +[2] 文中量化锚点仅用于流程一致性训练，不构成收益承诺；参数需按品种与账户约束自行校准。 +[3] 本章是“认知到执行”的桥梁，建议与第2章联读，再进入第4章目标牵引模块。 + + + +# 第4章　Draw on Liquidity：价格为何会被目标吸引 + +## 4.1　本章核心问题 + +前3章分别回答了三件事： + +1. 价格在递送（第1章）。 +2. 价格在什么空间递送（第2章）。 +3. 在该空间与状态下如何搭建 Setup（第3章）。 + +本章继续回答执行前最关键的问题之一： + +**价格要递送到哪里？为什么是那个方向？** + +若没有目标牵引，“从 A 到 B”就会退化为事后描述。 +本章主问题是： + +**什么是 Draw on Liquidity，如何把它转化为可执行目标，而非复盘话术？** + +围绕该主问题，展开四个子问题： + +1. Draw on Liquidity 的工作定义与边界是什么。 +2. 哪些目标最常成为 Draw（Liquidity Pool、Imbalance / FVG）。 +3. Draw 如何与 Narrative、Daily Bias、Dealing Range 联动。 +4. 什么时候应坚持目标，什么时候应降级或切换。 + +--- + +## 4.2　一句话结论 + +**Draw on Liquidity 是当前叙事下价格最可能优先处理的目标；先由高时间框架定义主目标，再由日线与日内结构跟踪路径，在失效条件触发前保持叙事一致性。** + +--- + +## 4.3　基础定义 + +### 一、Draw on Liquidity（流动性牵引） + +**定义：** +在当前叙事与结构条件下，价格最可能优先处理的目标。 + +**边界：** + +1. Draw 是方向组织工具，不是“任何旧高旧低都必扫”。 +2. Draw 必须服务于“事前判断”，而非“事后解释”。 +3. Draw 永远与失效条件成对出现。 + +### 二、目标类型A：Liquidity Pool（流动性池） + +常见对象包括： + +1. Old High / Old Low（旧高旧低） +2. Clean High / Clean Low（清晰高低） +3. Equal Highs / Equal Lows（等高等低） +4. Session High / Session Low（会话高低） + +这类目标可见性高、订单聚集明显，常成为价格优先处理对象。 + +### 三、目标类型B：Imbalance / FVG（失衡目标） + +Draw 不只来自流动性池，也常来自失衡回补需求。 +当价格快速位移后，FVG 或其他失衡区域会形成“待处理区”，在某些阶段会成为更近、更高相关的目标。 + +### 四、Opposing Liquidity（对侧流动性） + +当一侧流动性被处理且结构接管完成后，下一目标常转向对侧流动性。 +即：叙事切换后，Draw 方向也会切换。 + +### 五、Draw 三层目标体系 + +| 层级 | 含义 | 常见示例 | +| --- | --- | --- | +| Local Draw | 近端、短周期可达目标 | 最近 Session 高低、最近 FVG 边缘 | +| Working Draw | 当日或 4H 级主要目标 | 日内主流动性池、日线失衡区 | +| Narrative Draw | 高时间框架主叙事目标 | 周线旧高旧低、月度关键流动性 | + +三层目标不是三套系统，而是同一方向的“近-中-远”分层。 + +### 六、Draw 与 Bias 的链路 + +本书统一链路为： + +`Narrative -> Draw on Liquidity -> Daily Bias` + +Bias 不是主观口号，而是目标驱动下的执行偏向。 +先有目标，再谈方向执行。 + +--- + +## 4.4　底层逻辑 + +### 一、目标先于图形，Draw 先于入场 + +没有目标约束，任何触发都可能变成局部噪音。 +Draw 提供“目的地”，触发只负责“上车时点”。 + +### 二、Draw 判定必须自上而下 + +推荐固定顺序： + +1. 周线定义 Narrative Draw。 +2. 日线跟踪 Working Draw 是否延续。 +3. 1H 及以下负责 Local Draw 路径与执行触发。 + +低周期目标若脱离高周期牵引，稳定性会显著下降。 + +### 三、Draw 不是可随意翻转的主观故事 + +高频换边通常不是市场无序，而是叙事纪律缺失。 +在主目标被处理或失效前，原则上应保持目标一致性。 + +### 四、Draw 与 Narrative 强绑定 + +Draw 不是独立标签，而是叙事函数。 +叙事决定目标，目标完成或失败又反向更新叙事，形成闭环。 + +### 五、目标可持续，路径可回撤 + +主目标不等于直线到达。 +中途回撤、节奏放缓、局部反向波动都可能属于路径修正。 +关键在于区分“路径修正”与“叙事切换”。 + +### 六、Draw 让交易从反应式升级为目标式 + +无 Draw：看到图形即反应。 +有 Draw：先定目标，再等路径证据，再表达风险，再按层级退出。 +这一步是执行一致性的核心分水岭。 + +--- + +## 4.5　结构关系 + +### 一、承接第3章 + +第3章回答“怎么搭”，第4章回答“往哪走”。 +Setup 若脱离 Draw，只剩局部图形反应。 + +### 二、通向第5章 + +本章先定目标方向，第5章再定同方向内的位置优劣。 +即：`Direction -> Location`。 + +### 三、通向第6章 + +本章给出“要去哪里”，第6章细化“先拿哪里、后拿哪里”（IRL / ERL）。 +即：`Objective -> Layered Exit`。 + +### 四、通向后续执行章节 + +后续所有入场、持仓、止盈都应回到一句话： +**当前动作是否服务于既定 Draw。** + +### 五、与全书的关系 + +Draw 是“叙事到执行”的中轴概念： +没有 Draw，方向、位置、触发、止盈会各自为战。 + +--- + +## 4.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Draw 到 Liquidity Pool** + +1. 高时间框架先给出一侧目标倾向。 +2. 价格在整理后向该侧流动性推进。 +3. 推进中可出现回补与节奏切换，但主指向保持一致。 + +**标准情境B：Draw 到 Imbalance / FVG** + +1. 价格先位移并留下失衡。 +2. 市场优先回补近端失衡。 +3. 回补后再决定是否推进至更远流动性目标。 + +**标准情境C：结构切换后的对侧 Draw** + +1. 一侧流动性先被处理。 +2. 随后出现结构接管证据。 +3. Draw 转向对侧流动性目标。 + +**反例情境：目标频繁翻转** + +1. 目标未完成前反复换边。 +2. 把正常回撤误判为叙事终结。 +3. 在不同时间框架目标间来回跳转，失去主目标锚定。 + +### 二、交易中的真实表现 + +实盘常见问题不是“没有目标”，而是“目标太多且无优先级”。 +真正可执行的目标管理必须回答三件事： + +1. 主 Draw 是什么。 +2. 次 Draw 是什么。 +3. 何种证据触发目标降级或切换。 + +若这三件事答不清，持仓通常会在波动中失去纪律。 + +--- + +## 4.7　执行意义 + +本章将目标识别固化为“4步决策 + 五步动作”。 + +### 一、目标决策四步 + +| 步骤 | 核心问题 | +| --- | --- | +| 1 | 周线主 Draw 在哪一侧 | +| 2 | 日线 24h 反馈是否继续支持主 Draw | +| 3 | 当前位于本级 Range 的什么位置 | +| 4 | 日内路径证据是否与主 Draw 同向 | + +### 二、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 已定义 HTF 主 Draw | 主目标未定义，不开仓 | +| 触发 | 出现朝向 Draw 的路径证据 | 至少具备流动性事件或位移证据之一 | +| 确认 | 低周期证据与 HTF 叙事一致 | 若冲突，延后执行 | +| 执行 | 位置有优势且目标清晰时入场 | 单笔风险上限可设 0.5%-1% | +| 退出 | 目标处理完成或失效触发时离场 | 先次目标，后主目标 | + +### 三、持仓纪律 + +1. 目标未达前，不因小波动无纪律换边。 +2. 允许路径回撤，但持续检查叙事是否仍成立。 +3. 日内目标完成后，回到高周期判断是否延续或降档。 + +### 四、失效硬规则 + +以下任一出现，需降级或重建 Draw： + +1. 反向结构接管并否定原叙事。 +2. 价格持续偏离原路径且无回归证据。 +3. 日线节奏显著变形并破坏执行假设。 + +### 五、执行前六问 + +1. 我的主 Draw 是什么？ +2. 次 Draw 是什么？ +3. 当前路径是否仍服务主 Draw？ +4. 回撤是路径修正还是叙事切换？ +5. 我的失效边界写清了吗？ +6. 若失效触发，我是否机械退出？ + +六问有一项答不清，本笔交易延后。 + +--- + +## 4.8　常见误区 + +### 误区一：把所有显眼目标当主 Draw + +**识别信号：** 目标等权处理，无主次。 +**纠偏动作：** 先定 HTF 主 Draw，再补 LTF 次 Draw。 + +### 误区二：目标未达就频繁换边 + +**识别信号：** 几根反向 K 线就反手。 +**纠偏动作：** 失效未触发前，保持叙事一致。 + +### 误区三：只盯流动性池，不看失衡目标 + +**识别信号：** 只看旧高旧低，忽略 FVG / Imbalance。 +**纠偏动作：** 将 Liquidity Pool 与 Imbalance 作为并列目标集合。 + +### 误区四：把回撤当终结 + +**识别信号：** 回撤即否定主目标。 +**纠偏动作：** 先判定是路径修正还是结构切换。 + +### 误区五：只做日内，不接高周期叙事 + +**识别信号：** 每天从零开始，目标不连续。 +**纠偏动作：** 日内执行必须服务高周期 Draw。 + +### 误区六：把 Draw 当“必到位” + +**识别信号：** 把目标当确定性承诺。 +**纠偏动作：** Draw 只表达“最可能”，必须配失效条件。 + +### 误区七：有目标无退出规则 + +**识别信号：** 会写去哪里，不写到哪里减仓。 +**纠偏动作：** 强制写“次目标减仓 + 主目标清仓”。 + +### 误区八：目标切换无客观标准 + +**识别信号：** 凭情绪切换目标。 +**纠偏动作：** 仅在结构接管证据出现时切换 Draw。 + +--- + +## 4.9　高阶深化 + +### 一、主次 Draw 分层能力 + +主 Draw 用于方向约束，次 Draw 用于路径管理与分批兑现。 +目标越少越好，层级越清晰越好。 + +### 二、Narrative-Draw-Bias 闭环 + +高阶执行遵循： + +`Narrative changes -> Draw changes -> Bias changes` + +若 Bias 高频变化，通常是上游叙事锚点缺失。 + +### 三、对侧流动性模型 + +当一侧流动性被处理且结构接管成立，对侧目标的吸引力会上升。 +这是 Reversal 场景中最关键的目标迁移逻辑。 + +### 四、多时间框架目标映射 + +建议每次交易前建立三层映射： + +1. 周线 Narrative Draw +2. 日线 Working Draw +3. 日内 Local Draw + +三层一致时，持仓稳定性通常更高；冲突时应降频或等待。 + +### 五、本章工作公式 + +`Draw Plan = HTF Narrative + Primary Objective + Secondary Objective + Path Evidence + Invalidation` + +该公式用于后续模型章节的目标规划与持仓管理。 + +### 六、与前3章公式联动 + +1. 第1章：`Price Delivery = Range + Objective + Path + Time + Invalidation` +2. 第2章：`Trade Location = Range State + Premium/Discount + Objective Layer + Invalidation` +3. 第3章：`Setup Quality = Context Clarity x Reference Match x Sequence Validity x Invalidation Discipline` +4. 第4章：`Draw Plan = HTF Narrative + Primary Objective + Secondary Objective + Path Evidence + Invalidation` + +四式联动后，方向、位置、搭建、目标形成完整闭环。 + +--- + +## 4.10　本章总结 + +1. Draw on Liquidity 是方向与执行的目标核心。 +2. 主目标常来自 Liquidity Pool 与 Imbalance / FVG，两类并列。 +3. 目标判定应先高后低，低周期路径必须服务高周期叙事。 +4. 目标未完成前应保持叙事纪律，回撤不等于失效。 +5. 没有失效条件的 Draw，不具备可执行价值。 + +--- + +## 4.11　训练清单 + +### 一、观察任务：主 Draw 标注 + +任务：抽取 30 个“周-日”样本，先标本周主 Draw，再看日线反馈是否支持。 +达标：至少 24 个样本能给出“主目标 + 反馈结论”。 + +### 二、标注任务：主次目标双轨 + +任务：每个样本强制写 `Primary Draw + Secondary Draw + 切换条件`。 +达标：100% 样本都具备可复核切换标准。 + +### 三、标注任务：三层目标映射 + +任务：选 10 个样本，分别写周线、日线、日内 Draw。 +达标：每个样本都能明确“三层一致”或“三层冲突”。 + +### 四、复盘任务：目标管理错误统计 + +任务：复盘 20 笔交易，统计四类错误： +无主 Draw 入场 / 目标未达换边 / 回撤误判失效 / 无失效条件。 +达标：每类沉淀 1 条前置检查规则。 + +### 五、复盘任务：路径与失效区分 + +任务：选 15 个“中途回撤”样本，判断属于路径修正还是叙事切换。 +达标：至少 12 个样本能给出一致判据。 + +### 六、执行任务：六问门控打卡 + +任务：连续 10 个交易日，每笔潜在交易先完成“执行前六问”。 +达标：门控完成率 100%，且无“无主 Draw 入场”记录。 + +### 七、连接任务：进入第5章 + +任务：在已完成 Draw 标注的图表上继续回答： +当前在 Range 的什么位置，位置是否支持当前方向。 +达标：能够自然从“目标语言”过渡到“位置语言”。 + +--- + +## 章末注释 + +[1] 本章基于 ICT 框架中关于 Draw on Liquidity、Narrative、Bias 与多时间框架目标组织原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 本章建议与第2章、第3章联读，再进入第5章位置质量模块。 + + + +# 第5章　Premium、Discount、Equilibrium 与 OTE：同方向中的更优位置 + +## 5.1　本章核心问题 + +前4章已经建立了方向框架： + +1. 价格在递送（第1章）。 +2. 价格在范围中递送（第2章）。 +3. Setup 需要环境与锚点配对（第3章）。 +4. 执行必须服务明确 Draw（第4章）。 + +但实盘里仍会反复出现一个问题： + +**方向看对了，交易质量却很差。** + +根源通常不是方向错误，而是位置错误。 +本章主问题是： + +**在同一方向里，什么位置更优，什么位置更差？** + +围绕该主问题，展开四个子问题： + +1. Premium、Discount、Equilibrium 的边界如何定义。 +2. 为什么方向正确不等于交易质量高。 +3. 为什么在 Equilibrium 附近应切换执行风格。 +4. OTE 的正确定位与使用边界是什么。 + +--- + +## 5.2　一句话结论 + +**交易质量首先由位置决定：Discount 更利于多头表达、Premium 更利于空头表达，Equilibrium 属于低优势区；OTE 只能在已成立叙事与范围框架内作为位置精化工具使用。** + +--- + +## 5.3　基础定义 + +### 一、Equilibrium（均衡） + +**定义：** +当前 Range 的中值平衡区域，实务中常以 50% 作为工作中轴。 + +**作用：** + +1. 划分 Premium 与 Discount。 +2. 提供空间参考，不提供方向保证。 +3. 评估“当前位置是否具备优势”。 + +### 二、Premium（溢价区） + +**定义：** +相对当前 Range 中值偏高的区域。 + +**执行语义：** + +1. 对空头：更优风险表达区。 +2. 对多头：更常见的兑现区。 +3. 对追多：回撤与盈亏比压力上升。 + +### 三、Discount（折价区） + +**定义：** +相对当前 Range 中值偏低的区域。 + +**执行语义：** + +1. 对多头：更优风险表达区。 +2. 对空头：更常见的兑现区。 +3. 对追空：回撤与盈亏比压力上升。 + +### 四、OTE（Optimal Trade Entry） + +**定位：** +位置微调器，不是独立策略入口。 + +**使用边界：** + +1. 高周期叙事与 Bias 已明确。 +2. 当前 Range 与位置分区已定义。 +3. 有数组或结构证据配合（如 OB、FVG、位移路径）。 +4. 失效条件已写明。 + +缺任一条件，OTE 只作观察，不作触发。 + +### 五、Liquidity Matrix（位置与目标映射） + +它用于把三件事统一到同一坐标中： + +1. 我在 Range 的哪里（位置）。 +2. 我往哪里去（目标）。 +3. 我怎么分层兑现（路径）。 + +### 六、位置语言的本质 + +Premium / Discount 是相对语言，不是绝对价格。 +同一价格在不同 Range 层级中的位置可能不同，必须先声明“你依据哪个 Range 在决策”。 + +--- + +## 5.4　底层逻辑 + +### 一、方向决定“做哪边”，位置决定“做得好不好” + +同样看多： + +1. 在 Discount 参与，通常盈亏结构更友好。 +2. 在 Premium 追价，通常回撤容忍度更差。 + +方向对但位置差，依然可能出现“看对却亏钱”。 + +### 二、Equilibrium 是低优势区，不是高优势区 + +中值区常见问题： + +1. 止损逻辑不清。 +2. 目标空间有限。 +3. 双向扫动频繁。 +4. 方向信息压缩。 + +因此，中值区更适合降预期、缩持仓、快兑现。 + +### 三、位置判断必须绑定 Range + +不先定义 Key High / Key Low，就不存在有效的 Premium / Discount 判断。 +脱离 Range 讨论位置，属于“悬空分析”。 + +### 四、位置与目标是联动关系 + +位置不仅影响入场，也决定退出层级： + +1. 在 Discount 做多，先看内部目标，再看外部目标。 +2. 在 Premium 做空，先看内部目标，再看外部目标。 + +即：位置定义风险起点，IRL / ERL 定义兑现路径。 + +### 五、OTE 误用的本质 + +OTE 常被误用为“单点信号”。 +正确做法是：叙事先行、范围先行、结构先行，OTE 最后微调。 +否则等同于把位置工具当预测工具。 + +### 六、位置优势是风险效率，不是方向保证 + +Discount 不保证必涨，Premium 不保证必跌。 +它们提升的是盈亏结构与容错空间，而不是胜率神话。 + +--- + +## 5.5　结构关系 + +### 一、承接第4章 + +第4章解决“往哪去”，第5章解决“从哪里去更优”。 +即：`Direction Quality = Draw x Location`。 + +### 二、通向第6章 + +本章解决入场质量，第6章细化退出结构（IRL / ERL）。 +即：`Entry Quality -> Exit Architecture`。 + +### 三、通向执行系统 + +后续所有触发都应先过“位置闸门”： +位置不优时，触发价值显著打折。 + +### 四、通向风险章节 + +第44-45章的止损与仓位管理，本质上建立在本章位置判断之上。 +没有位置过滤，风控参数很难稳定。 + +### 五、与全书的关系 + +第5章让“方向正确”升级为“执行可持续”： +方向、位置、目标、失效四项从这里开始强绑定。 + +--- + +## 5.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Discount 买入路径** + +1. 多头叙事成立。 +2. 价格回到 Discount 并出现执行证据。 +3. 先向内部目标推进，再评估外部目标。 + +**标准情境B：Premium 卖出路径** + +1. 空头叙事成立。 +2. 价格回到 Premium 并出现执行证据。 +3. 优先向折价目标推进。 + +**标准情境C：Equilibrium 粘滞** + +1. 价格围绕中值来回震荡。 +2. 单边信号质量下降。 +3. 更适合短持仓或等待扩张证据。 + +**反例情境：方向对但位置错** + +1. Premium 追多或 Discount 追空。 +2. 后续方向虽正确，但中途回撤先触发止损。 +3. 结果变成“分析正确、执行亏损”。 + +### 二、交易中的真实表现 + +实盘常见偏差是：先定方向，再把任何触发都当可执行点。 +本章要求顺序反转： + +1. 先过位置闸门。 +2. 再审触发质量。 +3. 最后决定是否执行。 + +在位置不优处，图形再漂亮也应降仓或放弃。 +在位置有优势处，才值得提高关注与耐心。 + +--- + +## 5.7　执行意义 + +本章将位置过滤固化为“5步流程 + OTE 硬约束”。 + +### 一、位置优先五步 + +| 步骤 | 核心动作 | +| --- | --- | +| 1 | 定义当前 Range 高低点 | +| 2 | 标注 Equilibrium | +| 3 | 判定 Premium / Discount / Equilibrium | +| 4 | 仅在优势分区接受触发 | +| 5 | 按 IRL -> ERL 分层兑现 | + +### 二、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | Range 与分区已定义 | 未定义分区，不开仓 | +| 触发 | 触发发生在优势分区 | 做多优先 Discount，做空优先 Premium | +| 确认 | 未退回中值噪音区且叙事未退化 | 若回到 Equilibrium 且证据弱化，降级处理 | +| 执行 | 位置与方向同向时表达风险 | 单笔风险上限可设 0.5%-1% | +| 退出 | 按层级兑现或失效离场 | 先内部目标，后外部目标 | + +### 三、风格切换规则 + +1. 优势区（Discount / Premium）：按叙事执行标准持仓。 +2. 中值区（Equilibrium）：降预期、缩持仓、快兑现。 + +### 四、OTE 硬约束（本章规则） + +OTE 仅在以下条件同时满足时可用于触发： + +1. Direction Validity：方向叙事已成立。 +2. Range Validity：范围分区已成立。 +3. Structure Support：有结构或数组证据支持。 +4. Invalidation Ready：失效边界已写明。 + +四项缺一，OTE 只观察不执行。 + +### 五、失效条件 + +以下任一出现，应降级或退出： + +1. 位置优势消失且无修复证据。 +2. 价格长期粘滞 Equilibrium 并破坏持仓节奏。 +3. 叙事切换导致当前分区语义失效。 + +--- + +## 5.8　常见误区 + +### 误区一：把分区当固定价格带 + +**识别信号：** 结构变化后仍沿用旧分区。 +**纠偏动作：** Range 更新后立即重算分区。 + +### 误区二：在 Equilibrium 维持重仓趋势思维 + +**识别信号：** 中值震荡中仍押大单边。 +**纠偏动作：** 中值区改为轻仓、短持仓、快兑现。 + +### 误区三：OTE 脱离上下文独立交易 + +**识别信号：** 只看回撤比例，不看叙事与结构。 +**纠偏动作：** OTE 必须嵌入“叙事 + 范围 + 结构 + 失效”框架。 + +### 误区四：入场看位置，退出不看位置 + +**识别信号：** 入场讲分区，止盈拍脑袋。 +**纠偏动作：** 退出同样执行分区与层级逻辑。 + +### 误区五：把位置判断与目标判断割裂 + +**识别信号：** 目标讲 Draw，入场靠感觉。 +**纠偏动作：** 每笔交易强制写“目标 + 位置”二联单。 + +### 误区六：把位置当方向 + +**识别信号：** “在 Discount 所以必做多”。 +**纠偏动作：** 方向由叙事决定，位置只做质量过滤。 + +### 误区七：忽视时间窗口 + +**识别信号：** 只看位置，不看会话与时段。 +**纠偏动作：** 位置正确还需时间窗口可执行。 + +### 误区八：只追求“完美位置”，忽视失效纪律 + +**识别信号：** 入场很挑剔，止损却随意。 +**纠偏动作：** 位置优势必须配失效纪律才有意义。 + +--- + +## 5.9　高阶深化 + +### 一、位置优势的统计意义 + +位置不是方向保证，而是提升长期盈亏结构的统计工具。 +同等胜率下，优势位置可显著改善期望值。 + +### 二、位置与时间窗耦合 + +同一 Discount 或 Premium，在不同会话质量不同。 +高阶过滤应为“双条件”：位置正确 + 时间可执行。 + +### 三、位置驱动的分批兑现 + +以多头为例： + +1. Discount 入场。 +2. Equilibrium 或 IRL 做第一层兑现。 +3. Premium 或 ERL 做第二层兑现。 + +这样可以把“盈利确认”与“趋势延伸”分离管理。 + +### 四、多时间框架位置嵌套 + +同一价位在日内、4H、日线可能分处不同分区。 +决策前必须声明“本次交易服务哪个层级 Range”。 + +### 五、位置冲突处理优先级 + +当高周期与低周期分区冲突时，优先级建议为： + +1. 先服从交易周期目标。 +2. 再看上位周期是否允许。 +3. 冲突过大则降频等待一致。 + +### 六、本章工作公式 + +`Execution Quality = Direction Validity x Location Advantage x Timing Fit x Invalidation Discipline` + +四项任一缺失，执行质量都会显著下降。 + +### 七、与前4章公式联动 + +1. 第1章：`Price Delivery = Range + Objective + Path + Time + Invalidation` +2. 第2章：`Trade Location = Range State + Premium/Discount + Objective Layer + Invalidation` +3. 第3章：`Setup Quality = Context Clarity x Reference Match x Sequence Validity x Invalidation Discipline` +4. 第4章：`Draw Plan = HTF Narrative + Primary Objective + Secondary Objective + Path Evidence + Invalidation` +5. 第5章：`Execution Quality = Direction Validity x Location Advantage x Timing Fit x Invalidation Discipline` + +到本章为止，方向、位置、目标、触发已形成统一执行语法。 + +--- + +## 5.10　本章总结 + +1. Premium / Discount / Equilibrium 是同方向内的质量过滤器。 +2. 位置判断必须绑定当前 Range，脱离范围讨论位置无效。 +3. Equilibrium 属于低优势区，应主动切换执行风格。 +4. OTE 是位置精化工具，不是脱离上下文的独立策略。 +5. 高质量执行来自“方向—位置—目标—失效”四项一致。 + +--- + +## 5.11　训练清单 + +### 一、观察任务：逐日分区标注 + +任务：抽取 30 个样本日，标注 Range 高低、中值与收盘分区。 +达标：至少 24 个样本可明确给出“方向—位置一致性”判断。 + +### 二、标注任务：条件化执行语句 + +任务：每个样本写两句规则： +“若在 Discount，我只接受哪些触发”； +“若在 Premium，我只接受哪些触发”。 +达标：每条语句都包含失效条件。 + +### 三、标注任务：多层级位置判定 + +任务：选 10 个样本，在日内、4H、日线分别判定分区。 +达标：每个样本都能清楚说明层级位置差异。 + +### 四、复盘任务：位置错误统计 + +任务：复盘 20 笔交易，统计四类错误： +Premium 追多 / Discount 追空 / Equilibrium 过度停留 / OTE 脱框架。 +达标：每类提炼 1 条规避规则并跟踪下周执行率。 + +### 五、复盘任务：位置驱动退出回测 + +任务：抽取 10 笔盈利样本，重演“分层兑现”与“单点止盈”对比。 +达标：至少 7 笔样本给出明确优劣结论。 + +### 六、执行任务：位置闸门打卡 + +任务：连续 10 个交易日，每笔潜在交易先完成“位置五步”。 +达标：无“未判分区即入场”记录。 + +### 七、连接任务：进入第6章 + +任务：在已完成位置标注的图表上继续回答： +哪些是 IRL、哪些是 ERL，先拿哪里、后拿哪里。 +达标：能自然从“位置语言”过渡到“目标层级语言”。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中关于 Equilibrium、Premium/Discount、OTE 与位置-目标联动原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 本章建议与第2章、第4章联读，再进入第6章 IRL/ERL 模块。 + + + +# 第6章　Internal Range / External Range：从内部目标到外部目标 + +## 6.1　本章核心问题 + +前五章已经完成了执行前链路： + +1. 价格在递送（第1章）。 +2. 递送发生在 Range 容器中（第2章）。 +3. Setup 需要环境与锚点配对（第3章）。 +4. 执行必须服务明确 Draw（第4章）。 +5. 同方向里要先选优势位置（第5章）。 + +到这一步，交易者常出现同一个新问题： + +**入场后，不知道该在哪里、分几步退出。** + +本章主问题是： + +**如何区分 Internal Range 与 External Range，并把它们转化为可执行的分层退出结构？** + +围绕该主问题，回答四个子问题： + +1. 什么是 IRL（Internal Range Liquidity）与 ERL（External Range Liquidity）。 +2. 两者在“范围保持 / 范围突破”情境下的角色差异是什么。 +3. 为什么高质量执行通常“先内部、后外部”。 +4. 如何把 IRL / ERL 写成标准化流程，而非情绪化止盈。 + +--- + +## 6.2　一句话结论 + +**IRL 用于范围内部的阶段性兑现，ERL 用于范围外部的扩展目标；高质量交易通常先在 IRL 锁定部分收益，再在叙事延续时争取 ERL 完整兑现。** + +--- + +## 6.3　基础定义 + +### 一、ERL（External Range Liquidity，外部流动性） + +**定义：** +当前 Range 边界之外、可被价格处理的流动性目标。 + +**常见对象：** + +1. Range High 上方 Buy-side Liquidity。 +2. Range Low 下方 Sell-side Liquidity。 +3. 边界外侧旧高旧低、等高等低、上位周期外部目标。 + +**特征：** + +1. 距离更远，收益空间更大。 +2. 到达通常依赖边界推进与扩张证据。 +3. 并非所有交易都能走到 ERL。 + +### 二、IRL（Internal Range Liquidity，内部流动性） + +**定义：** +当前 Range 内部可被优先处理的目标。 + +**常见对象：** + +1. 内部 FVG / Imbalance / Liquidity Void。 +2. 内部 Order Block 触及位。 +3. 内部局部高低点与短线流动性。 + +**特征：** + +1. 距离更近，触达概率通常更高。 +2. 更适合作为第一退出层（partial）。 +3. 可用于将浮盈转为已实现收益。 + +### 三、IRL Exit 与 ERL Exit（退出语义） + +| 退出层级 | 动作语义 | 常见用途 | +| --- | --- | --- | +| IRL Exit | 部分兑现（partial） | 锁定阶段收益，降低回吐风险 | +| ERL Exit | 完整退出（full close） | 获取扩展收益，结束本笔叙事 | + +这不是“二选一”，而是“分阶段”。 + +### 四、Liquidity Matrix（本章底图） + +本章执行底图由三层组成： + +1. Range 边界（Key High / Key Low）。 +2. 位置分区（Premium / Discount / Equilibrium）。 +3. 目标层级（IRL -> ERL）。 + +它把前五章的语言统一为可执行坐标。 + +### 五、范围状态与目标权重 + +| 范围状态 | 目标权重 | 执行倾向 | +| --- | --- | --- | +| 范围保持概率高 | IRL 权重上升 | 内部兑现优先，扩展仓位保守 | +| 范围扩张证据强 | ERL 权重上升 | IRL 后保留仓位争取外部 | + +### 六、ERL 的阻力差异（低阻力 / 高阻力） + +即使边界被突破，ERL 推进效率也不同： + +1. 低阻力：推进顺畅、回撤浅、节奏连续。 +2. 高阻力：推进反复、回撤深、易重回 Range。 + +这决定了你是否应继续持有扩展仓位。 + +--- + +## 6.4　底层逻辑 + +### 一、IRL / ERL 解决的是“兑现结构”，不是“方向判断” + +方向由 Narrative、Draw、Bias 决定； +IRL / ERL 决定的是“盈利怎么拿、拿到哪里”。 + +### 二、内部目标偏高概率，外部目标偏高回报 + +这是概率与收益的经典权衡： + +1. IRL：更近、更常到，但空间相对有限。 +2. ERL：更远、空间更大，但不确定性更高。 + +“先 IRL 后 ERL”本质是先锁定可得收益，再争取扩展收益。 + +### 三、范围保持与范围突破对应不同退出重心 + +1. 若范围保持概率高：IRL 优先，ERL 从严。 +2. 若范围突破证据强：IRL 后保留仓位争取 ERL。 + +错误常见于把“范围内逻辑”与“范围外逻辑”混用。 + +### 四、分层兑现本质是分离“收益路径”和“风险路径” + +很多回吐来自单目标持仓。 +IRL 减仓可以先把部分浮盈转为已实现，再用剩余仓位追扩展。 + +### 五、IRL / ERL 必须服从高周期叙事 + +若 HTF 叙事支持延续，可提高 ERL 权重； +若 HTF 接近终点或节奏减弱，应提高 IRL 落袋权重。 + +### 六、退出纪律决定收益曲线稳定性 + +“看对方向却不赚钱”常发生在退出阶段。 +本章价值在于把退出从情绪反应改造成规则执行。 + +--- + +## 6.5　结构关系 + +### 一、承接第5章 + +第5章解决“从哪里做更优”，第6章解决“做到哪里、分几步退出”。 +即：`Entry Quality -> Exit Architecture`。 + +### 二、通向第7章 + +本章先讲“内部/外部目标分层”，第7章将讲这些目标的流动性来源（BSL / SSL）。 + +### 三、通向模型执行章节 + +后续第35章起的“部分止盈 + 结构持有”几乎都可还原为 IRL / ERL 双层架构。 + +### 四、通向风险章节 + +不做分层常导致两类风险： + +1. 过早全平，错失扩展行情。 +2. 过晚全平，盈利回吐严重。 + +第44-45章将在本章基础上量化分批比例与仓位管理。 + +### 五、作为第一部分收口 + +本章完成第一部分最后一块拼图： +从“会入场”推进到“会退出、会管理持仓”。 + +--- + +## 6.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Discount 入场 -> IRL 部分 -> ERL 完整** + +1. 在优势位置入场。 +2. 价格先触及内部目标（IRL）。 +3. 部分减仓后，若结构继续，剩余仓位推进至 ERL。 + +**标准情境B：范围保持日（IRL 主导）** + +1. 价格在 Range 内反复处理内部目标。 +2. 外部边界未出现有效推进。 +3. IRL 兑现价值显著高于盲等 ERL。 + +**标准情境C：范围扩张日（ERL 主导）** + +1. 边界处理后出现位移接管。 +2. 内部目标完成后，外部牵引增强。 +3. 剩余仓位可转向 ERL 目标管理。 + +**反例情境：只设单一终点** + +1. 全仓等待 ERL。 +2. 中途回撤导致浮盈回吐。 +3. 结果从“正确交易”变成“低效率收益”。 + +### 二、交易中的真实表现 + +实盘常见问题不是“没目标”，而是“不会分层”： + +1. 没有预设 IRL，导致落袋时机全靠情绪。 +2. IRL 到位不减仓，扩展失败后回吐盈利。 +3. 每次都在 IRL 全平，拿不到趋势扩展段。 + +IRL / ERL 的价值，就是让退出动作前置标准化，而不是盘中临场猜测。 + +### 三、简化示例 + +若你在 4H Discount 做多： + +1. 先把内部 FVG 或 Equilibrium 作为 IRL。 +2. 把 Range High 外侧流动性作为 ERL。 +3. IRL 到位先减仓，ERL 到位再全平。 + +这样即使 ERL 失败，账户也更容易保持正向贡献。 + +--- + +## 6.7　执行意义 + +本章将退出管理固化为“标准流程 + 五步动作 + 失效规则”。 + +### 一、标准执行流程 + +| 步骤 | 动作 | +| --- | --- | +| 1 | 定义 Range 与位置分区 | +| 2 | 写出 IRL 第一目标 | +| 3 | 写出 ERL 扩展目标 | +| 4 | IRL 触及执行部分兑现 | +| 5 | 叙事延续时持有至 ERL 完整退出 | + +### 二、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 已写明 IRL + ERL 两级目标 | 写不出两级目标，不开仓 | +| 触发 | 入场来自前5章门控通过 | 位置不优则不开仓 | +| 确认 | 价格先朝 IRL 推进且叙事一致 | 结构冲突则降级目标 | +| 执行 | 执行预设分层动作 | IRL 到位必须有减仓动作 | +| 退出 | ERL 到位全平或失效离场 | ERL 失败不硬扛 | + +### 三、仓位管理建议（示例） + +1. IRL：至少减掉一部分风险暴露（如 30%-70%，由系统校准）。 +2. ERL：剩余仓位按主目标完整退出。 +3. 若推进失速：优先保护已得利润，而非坚持“必须到 ERL”。 + +### 四、多周期过滤规则 + +1. 低周期 IRL / ERL 必须与高周期叙事方向一致。 +2. 若 HTF 不支持扩展，ERL 权重下调。 +3. 若 HTF 强支持扩展，IRL 后可保留更大扩展仓位。 + +### 五、失效硬规则 + +以下任一出现，需重建退出架构： + +1. IRL 未到前，原叙事已被反向结构破坏。 +2. IRL 到位后无延续且关键推进结构被回收。 +3. 边界突破后快速回归 Range，ERL 推进证据失效。 + +--- + +## 6.8　常见误区 + +### 误区一：把 IRL / ERL 当入场信号 + +**识别信号：** 只谈目标不谈入场依据。 +**纠偏动作：** 入场由前5章决定，IRL / ERL 只管退出。 + +### 误区二：不判断范围状态，机械等 ERL + +**识别信号：** 无论何种盘面都坚持外部终点。 +**纠偏动作：** 先判“范围保持 vs 范围扩张”。 + +### 误区三：不分层，单点全押 + +**识别信号：** 全仓只设一个远端目标。 +**纠偏动作：** 强制双层目标：IRL 部分 + ERL 完整。 + +### 误区四：IRL 到位即反手 + +**识别信号：** 把阶段目标当方向终点。 +**纠偏动作：** 先检验叙事是否延续，再决定剩余仓位。 + +### 误区五：低周期目标对抗高周期叙事 + +**识别信号：** 小周期频繁逆主叙事处理仓位。 +**纠偏动作：** 目标层级服从 HTF 方向约束。 + +### 误区六：只看单周期目标 + +**识别信号：** 目标不做跨周期映射。 +**纠偏动作：** 同时标注 HTF / MTF / LTF 的 IRL / ERL。 + +### 误区七：ERL 失败后死扛 + +**识别信号：** 扩展失效仍不调整。 +**纠偏动作：** ERL 推进失败即执行降级退出。 + +### 误区八：有目标无执行动作 + +**识别信号：** 图上写了 IRL / ERL，盘中无预设减仓单。 +**纠偏动作：** 目标必须绑定具体动作与触发条件。 + +--- + +## 6.9　高阶深化 + +### 一、IRL / ERL 是收益曲线稳定器 + +它把收益拆成两层： + +1. 确定层（IRL）负责锁定可得收益。 +2. 扩展层（ERL）负责捕捉趋势红利。 + +这会显著降低“盈利大幅回吐”的频率。 + +### 二、阻力类型决定 ERL 到达效率 + +低阻力可更耐心持有扩展仓位； +高阻力应更积极管理剩余仓位与保护利润。 + +### 三、多周期目标映射能力 + +同一价位在不同周期可扮演不同语义： + +1. 某周期 IRL 可能是下一级 ERL。 +2. 某周期 ERL 可能是上一级 IRL。 + +高阶执行不是机械套公式，而是做层级主次映射。 + +### 四、内部逻辑与外部逻辑的深层区分 + +内部逻辑交易： + +1. 目标更近。 +2. 持仓更短。 +3. 预期以范围内处理为主。 + +外部逻辑交易： + +1. 目标更远。 +2. 波动容忍更高。 +3. 预期以边界推进与扩张为主。 + +两套逻辑混用，是多数退出失效的根源。 + +### 五、本章工作公式 + +`Exit Architecture = IRL (Partial) + ERL (Full) + Resistance Context + HTF Alignment + Invalidation` + +该公式用于后续模型章节的退出与持仓标准化。 + +### 六、与前5章公式联动 + +1. 第1章：`Price Delivery = Range + Objective + Path + Time + Invalidation` +2. 第2章：`Trade Location = Range State + Premium/Discount + Objective Layer + Invalidation` +3. 第3章：`Setup Quality = Context Clarity x Reference Match x Sequence Validity x Invalidation Discipline` +4. 第4章：`Draw Plan = HTF Narrative + Primary Objective + Secondary Objective + Path Evidence + Invalidation` +5. 第5章：`Execution Quality = Direction Validity x Location Advantage x Timing Fit x Invalidation Discipline` +6. 第6章：`Exit Architecture = IRL (Partial) + ERL (Full) + Resistance Context + HTF Alignment + Invalidation` + +到此，第一部分形成“入场前—持仓中—退出后”的完整闭环。 + +--- + +## 6.10　本章总结 + +1. IRL / ERL 属于退出架构层，不替代入场逻辑。 +2. IRL 偏高概率兑现，ERL 偏高回报扩展。 +3. 高质量执行通常“先 IRL 后 ERL”。 +4. ERL 到达效率受阻力类型与叙事延续性影响。 +5. 目标分层必须服从高周期叙事，不可孤立使用。 + +--- + +## 6.11　训练清单 + +### 一、观察任务：两级目标标注 + +任务：抽取 30 笔样本，逐笔标注 Range、IRL、ERL，并记录最终到达层级。 +达标：至少 24 笔能明确区分“只到 IRL”与“到达 ERL”。 + +### 二、标注任务：分层退出动作脚本 + +任务：每笔写两条规则： +IRL 的减仓动作；ERL 的全平动作；并补“ERL 失败分支”。 +达标：100% 样本都包含失败分支。 + +### 三、标注任务：范围保持 / 扩张判别 + +任务：对 20 笔样本判定当时更偏“保持”还是“扩张”，并解释证据。 +达标：至少 15 笔给出一致且可复述判据。 + +### 四、复盘任务：退出错误统计 + +任务：复盘 20 笔交易，统计四类错误： +未设 IRL / IRL 不减仓 / ERL 未到全平 / ERL 失败死扛。 +达标：每类提炼 1 条前置检查规则。 + +### 五、复盘任务：分层 vs 单点对比 + +任务：对 10 笔历史交易做 A/B 回放： +A=IRL 部分 + ERL 完整；B=单点全平。 +达标：至少 7 笔能给出哪种方式更优的明确结论。 + +### 六、执行任务：退出预案前置 + +任务：连续 10 个交易日，入场前必须写完 IRL / ERL 与失效分支。 +达标：无“入场后再想退出”的记录。 + +### 七、连接任务：进入第二部分 + +任务：在已完成 1-6 章标注的图表上继续回答： +这些 IRL / ERL 目标背后的流动性来源是什么，为什么会被优先处理。 +达标：能自然过渡到第7章 BSL / SSL 语言。 + +--- + +## 第一部分结语 + +第一部分六章完成后，你应当具备完整基础语言： + +1. 从“波动视角”切换到“递送视角”。 +2. 在 Range 坐标中定义位置与状态。 +3. 用 Context + Reference Point 搭建 Setup。 +4. 用 Draw 统一方向与目标。 +5. 用 Premium / Discount 过滤执行质量。 +6. 用 IRL / ERL 构建分层退出架构。 + +从第二部分开始，重点将转向流动性来源与清理机制。 +但后续所有章节都建立在本部分六章之上。 +若任何一环仍不稳定，建议先回到本部分做重复标注与复盘训练。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中关于 IRL / ERL、Liquidity Matrix、分层退出与多周期叙事联动原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种、波动与账户约束校准。 +[3] 建议本章与第4章（Draw）和第5章（位置）联读，再进入第7章流动性来源模块。 + +# 第二部分　流动性：市场为什么先清理再递送 + +第一部分建立了“递送—范围—搭建—目标—位置—退出”的基础框架。 +第二部分要回答一个更贴近实盘的问题： + +**为什么市场总是先扫高扫低，再走真正递送路径？** + +--- + +## 本部分定位 + +本部分的任务不是增加术语数量，而是建立一套可执行的流动性语言，把以下体感问题结构化： + +1. 为什么显著高低点反复被触及。 +2. 为什么很多“突破”只是短暂清理。 +3. 为什么价格常先处理对侧流动性，再展开主方向。 +4. 为什么“看起来被洗”的动作，本身常是递送的一部分。 + +--- + +## 与第一部分的衔接 + +第一部分回答了： + +1. 价格在递送（第1章）。 +2. 递送在范围里发生（第2章）。 +3. Setup 需环境与锚点配对（第3章）。 +4. 执行需服务明确 Draw（第4章）。 +5. 同方向要做位置过滤（第5章）。 +6. 持仓要做 IRL/ERL 分层退出（第6章）。 + +第二部分继续回答： + +**这些目标为何存在、为何会被优先处理、处理后路径为何常发生切换。** + +--- + +## 六章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第7章 | BSL 与 SSL：流动性最基础的两侧对象是什么 | +| 第8章 | Liquidity Pool：同一侧上哪些目标更值得优先跟踪 | +| 第9章 | Liquidity Void：真空区为何改变路径速度与回补预期 | +| 第10章 | Stop Run / Sweep / Raid：扫高扫低有哪些行为差异 | +| 第11章 | Judas Swing / Manipulation：为何常先诱导再递送 | +| 第12章 | 从流动性到目标选择：两边都有目标时如何排序 | + +--- + +## 学习边界 + +本部分最容易被误学成“阴谋论叙事”。 +请固定一个边界： + +**我们不是神话市场，而是在描述可重复观察到的订单聚集与路径响应。** + +也就是说： + +1. 不是“市场故意针对谁”。 +2. 而是“显著位置会产生一致性订单行为”。 +3. 价格处理这些位置后，路径会出现可验证变化。 + +--- + +## 学完应具备 + +完成第二部分后，你应能： + +1. 区分 BSL 与 SSL，并建立层级感。 +2. 识别高质量 Liquidity Pool，并做主次排序。 +3. 理解 Liquidity Void 对速度与回补的影响。 +4. 区分 Stop Run / Sweep / Raid 的行为语义。 +5. 理解“先诱导后递送”的执行意义。 +6. 在两侧目标并存时给出清晰优先级。 + +--- + +## 与执行系统的连接 + +第二部分不是独立模块，而是把前六章“目标与路径”变成更可执行的触发语言。 +从本部分开始，你的流程应固定为： + +`HTF Narrative -> Draw -> Liquidity Target -> Post-Event Confirmation -> Execution -> Layered Exit` + +这条流程会在第7-12章逐步细化并标准化。 + +--- + +## 章末注释 + +[1] 本导读用于承接第一部分与第二部分，不替代各章的定义与规则。 +[2] 建议进入第7章前，先复核第4章（Draw）与第6章（IRL/ERL）的执行模板。 +[3] 第二部分核心目标是“把流动性现象变成可复盘、可执行的语言”，而非增加解释性话术。 + + + +# 第7章　Buy-Side Liquidity 与 Sell-Side Liquidity + +## 7.1　本章核心问题 + +前六章已经建立了执行框架，但实盘里仍有一个高频问题： + +**价格到底会先去处理哪一侧？** + +交易者常见困惑是： + +1. 前高被破后追多，随即回落。 +2. 前低被破后追空，随即反弹。 +3. 误把“扫一下”当成“趋势确认”。 + +本章主问题是： + +**什么是 BSL（Buy-Side Liquidity）与 SSL（Sell-Side Liquidity），以及它们为何反复成为价格优先处理对象？** + +围绕该主问题，回答四个子问题： + +1. BSL / SSL 的标准定义与订单来源是什么。 +2. 哪些图表位置最常承载这两侧流动性。 +3. 流动性被处理后，路径为何常出现分化。 +4. 如何把“看见流动性”转化为“执行流程”。 + +--- + +## 7.2　一句话结论 + +**BSL / SSL 不是一条线，而是可被动员的订单群；价格常以“先处理一侧流动性，再展开下一阶段递送”的方式推进。** + +--- + +## 7.3　基础定义 + +### 一、BSL（Buy-Side Liquidity，买方流动性） + +**定义：** +显著高点上方聚集、被触发后转化为买入成交的订单集合。 + +**常见来源：** + +1. 空头止损单（stop-loss buy）。 +2. 突破追多单（breakout buy）。 + +**常见承载位：** + +1. 旧高、清晰高点。 +2. 等高上沿（Equal Highs）。 +3. Session High、前日高、前周高。 +4. Range High 外侧。 + +### 二、SSL（Sell-Side Liquidity，卖方流动性） + +**定义：** +显著低点下方聚集、被触发后转化为卖出成交的订单集合。 + +**常见来源：** + +1. 多头止损单（stop-loss sell）。 +2. 破位追空单（breakdown sell）。 + +**常见承载位：** + +1. 旧低、清晰低点。 +2. 等低下沿（Equal Lows）。 +3. Session Low、前日低、前周低。 +4. Range Low 外侧。 + +### 三、Clean High / Clean Low（清晰高低点） + +清晰度高、可见性强的位置更易形成一致性订单行为， +因此通常比噪音摆点更 relevant。 + +### 四、BSL / SSL 的对象属性 + +BSL / SSL 首先是“可处理对象”，不是方向结论。 +例如： + +1. 先拿 BSL 再下跌。 +2. 先拿 SSL 再上涨。 +3. 拿掉后继续同向扩展。 + +所以“拿到了”只是阶段节点，不是方向终判。 + +### 五、层级约束 + +同一高低点在不同周期语义不同。 +必须先声明： + +1. 你在什么时间框架判断。 +2. 它位于哪个 Dealing Range 层级。 +3. 它属于 Internal 还是 External 对象。 + +### 六、与 Draw 的关系 + +BSL / SSL 是 Draw 的最常见具体化对象。 +从执行语言看： + +`Narrative -> Draw -> (BSL or SSL) -> Path Confirmation -> Execution` + +--- + +## 7.4　底层逻辑 + +### 一、BSL / SSL 是“订单密度地图”，不是画线装饰 + +显著高低点之所以重要，不因线段本身，而因其背后存在可撮合订单密度。 +价格进入该区域时，成交与波动释放条件通常更充分。 + +### 二、显著高低点天然容易聚集止损 + +大量交易者采用相似风险管理： + +1. 空头止损放前高上方。 +2. 多头止损放前低下方。 + +一致性行为本身会制造流动性聚集。 + +### 三、突破参与会强化聚集 + +除止损外，突破追单会进一步增加订单厚度： +高点上方增买单，低点下方增卖单。 + +### 四、“处理一侧后路径分化”是常态 + +拿掉 BSL / SSL 后常见三种路径： + +1. 同向延续（继续扩展）。 +2. 反向递送（路径切换）。 +3. 回归范围（扩展失败）。 + +分化关键不在“是否扫到”，而在“扫后结构证据”。 + +### 五、与 Narrative-Draw-Bias 闭环联动 + +流程应固定为： + +1. 叙事给出主方向。 +2. Draw 指向优先目标侧。 +3. BSL / SSL 提供可观察对象。 +4. 结构确认决定是否执行。 + +### 六、流动性是高相关命题，不是必扫命题 + +看见流动性不等于立刻交易。 +至少还需满足： + +1. 位置条件。 +2. 时间窗口。 +3. 结构确认链。 + +### 七、成熟优势在“不过度反应” + +人人看得见前高前低。 +真正差异在于谁能在最拥挤区域保持流程纪律，不追第一根情绪 K 线。 + +--- + +## 7.5　结构关系 + +### 一、承接第6章 + +第6章定义了 IRL / ERL 退出层级。 +第7章补上这些目标的最常见来源：BSL / SSL。 + +### 二、通向第8章 + +本章先定义方向维度（上方/下方流动性）。 +第8章进入质量维度（哪些位置形成高质量 Liquidity Pool）。 + +### 三、通向第9-11章 + +1. 第9章：流动性真空如何影响路径速度。 +2. 第10章：Stop Run / Sweep / Raid 的行为差异。 +3. 第11章：先诱导后递送的机制化表达。 + +### 四、通向第12章 + +当两侧都存在目标时，第12章将给出优先级排序框架。 +第7章是该排序系统的输入层。 + +### 五、与全书模型关系 + +后续几乎所有入场模型都可还原为： + +`Liquidity Event + Structure Confirmation + Context Alignment` + +--- + +## 7.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：先拿 SSL，再上行到 BSL** + +1. HTF 偏多。 +2. 先下探处理近端 SSL。 +3. 出现上行位移后转向上方 BSL。 + +**标准情境B：先拿 BSL，再下行到 SSL** + +1. HTF 偏空。 +2. 先上冲处理近端 BSL。 +3. 反向位移后转向下方 SSL。 + +**标准情境C：同向连续处理** + +1. 处理一层 BSL/SSL 后仅短暂回补。 +2. 继续推进到更远同侧目标。 +3. 常见于强趋势阶段。 + +**反例情境：把“靠近流动性”当确认** + +1. 目标未被处理就提前押注。 +2. 处理瞬间追单。 +3. 缺少扫后确认链，易被噪音洗出。 + +### 二、交易中的真实表现 + +实盘高频错误是“太早交易流动性”。 +正确流程是： + +1. 先写主 Draw 在 BSL 还是 SSL。 +2. 等待该侧被处理。 +3. 观察处理后结构链是否闭合。 +4. 再执行，而非在触发瞬间冲动追单。 + +--- + +## 7.7　执行意义 + +本章执行口径统一为“条件—触发—确认—执行—退出”。 + +### 一、五步动作 + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | HTF 主 Draw 已明确（BSL 或 SSL） | 两侧同权时不交易 | +| 触发 | 目标侧流动性被实际处理 | 仅“接近”不算触发 | +| 确认 | 出现位移、接管或有效回补承接 | 缺确认链不入场 | +| 执行 | 在回补锚点执行，不追第一冲动 | 单笔风险上限可设 0.5%-1% | +| 退出 | 按第6章 IRL/ERL 分层，失效即离场 | 不因情绪频繁换边 | + +### 二、执行前五问 + +1. 当前最 relevant 的 BSL 与 SSL 各在哪里？ +2. 哪个是主 Draw，哪个是次 Draw？ +3. 它属于 Internal 还是 External？ +4. 处理后需要看到什么确认链？ +5. 若处理后反向接管，我的失效动作是什么？ + +五问任意一项答不清，延后执行。 + +### 三、降级规则 + +以下任一出现，流动性事件降级为观察： + +1. 处理后无结构确认。 +2. 与 HTF 叙事明显冲突。 +3. 发生在低信息时段且无后续承接。 + +--- + +## 7.8　常见误区 + +### 误区一：把 BSL / SSL 直接当方向 + +**识别信号：** “上方有 BSL=看涨”。 +**纠偏动作：** BSL / SSL 是对象，不是结论。 + +### 误区二：认为“扫完必反” + +**识别信号：** 被扫后立刻逆向满仓。 +**纠偏动作：** 先看扫后结构链，再定方向。 + +### 误区三：把所有高低点当同级目标 + +**识别信号：** 图上标注过密，信号过载。 +**纠偏动作：** 高周期优先、清晰度优先、时段优先。 + +### 误区四：目标未处理就换 Bias + +**识别信号：** 日内反复多空切换。 +**纠偏动作：** 失效未触发前保持叙事一致。 + +### 误区五：把流动性位当入场按钮 + +**识别信号：** 一到位就抢单。 +**纠偏动作：** 必须等待处理后确认链。 + +### 误区六：完全低周期化 + +**识别信号：** 只看 1M/5M，不看 HTF Draw。 +**纠偏动作：** 先写日线/4H 主 Draw，再下沉执行。 + +### 误区七：忽略时间框架语义 + +**识别信号：** 把微观扫点当宏观结构结论。 +**纠偏动作：** 每次判断必须声明层级与 Range。 + +### 误区八：把“看见流动性”当“已经有优势” + +**识别信号：** 无位置过滤直接执行。 +**纠偏动作：** 流动性事件必须通过第5章位置闸门。 + +--- + +## 7.9　高阶深化 + +### 一、真正优势是“排序能力”而非“识别能力” + +高阶交易者区别不在看到更多点，而在更早排序主次： + +1. 哪个是主服务目标。 +2. 哪个是被利用目标。 +3. 哪个只是噪音对象。 + +### 二、“被利用的一边”与“被服务的一边”需区分 + +有时市场先利用一侧流动性制造错位， +真正递送却服务另一侧更高层级目标。 + +### 三、四维一致性门控 + +| 维度 | 核心检查 | +| --- | --- | +| Narrative | 上游叙事是否支持该侧优先 | +| Range | 当前位置是否允许表达风险 | +| Time | 是否处于有效处理窗口 | +| Structure | 处理后是否出现接管或延续证据 | + +四维一致性越高，执行容错越高。 + +### 四、与时间窗口耦合 + +同一流动性位在不同时段含义不同。 +高信息时段（会话切换、关键波动窗口）通常更具可执行价值。 + +### 五、本章工作公式 + +`Liquidity Targeting = Side Priority + Event Confirmation + Structure Response + Time Window + Invalidation` + +### 六、与前六章公式联动 + +1. 第1章：`Price Delivery = Range + Objective + Path + Time + Invalidation` +2. 第2章：`Trade Location = Range State + Premium/Discount + Objective Layer + Invalidation` +3. 第3章：`Setup Quality = Context Clarity x Reference Match x Sequence Validity x Invalidation Discipline` +4. 第4章：`Draw Plan = HTF Narrative + Primary Objective + Secondary Objective + Path Evidence + Invalidation` +5. 第5章：`Execution Quality = Direction Validity x Location Advantage x Timing Fit x Invalidation Discipline` +6. 第6章：`Exit Architecture = IRL (Partial) + ERL (Full) + Resistance Context + HTF Alignment + Invalidation` +7. 第7章：`Liquidity Targeting = Side Priority + Event Confirmation + Structure Response + Time Window + Invalidation` + +--- + +## 7.10　本章总结 + +1. BSL / SSL 是订单群概念，不是单线概念。 +2. 显著高低点之所以重要，在于一致性订单聚集。 +3. 流动性被处理后，路径可能延续、反转或回归范围。 +4. 交易必须使用“流动性事件 + 结构确认”联合规则。 +5. 本章是第二部分的语法底座，为第8章池化质量排序做准备。 + +--- + +## 7.11　训练清单 + +### 一、观察任务：两侧对象标注 + +任务：抽取 30 个样本，仅标 BSL / SSL，不做进场。 +达标：主次侧判断与后续处理方向一致率达到 80%。 + +### 二、标注任务：主次 Draw 三行记录 + +任务：每个样本写三行：主 Draw、次 Draw、失效条件。 +达标：100% 样本都具备三行记录。 + +### 三、观察任务：扫后路径分类 + +任务：记录 30 个流动性事件，分类为延续/反向/回归范围。 +达标：至少 24 个样本可给出一致分类理由。 + +### 四、执行任务：只做确认链闭合样本 + +任务：连续 10 个交易日，仅执行“处理后确认链闭合”的机会。 +达标：无“仅触发未确认”入场记录。 + +### 五、复盘任务：冲动追单统计 + +任务：复盘近 20 笔，统计“流动性触发瞬间追单”占比。 +达标：每笔冲动单写出 1 条纠偏规则。 + +### 六、多周期任务：层级语义对照 + +任务：同一时刻在 4H/15M/5M 对照 BSL / SSL 语义。 +达标：能明确说明同一位置在不同层级的语义差异。 + +### 七、连接任务：进入第8章 + +任务：在已标 BSL / SSL 的图表上继续问： +哪些是单点，哪些已形成“池化聚集”，谁是主池。 +达标：可自然过渡到 Liquidity Pool 分级语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 BSL / SSL、旧高旧低流动性与结构确认原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第4章（Draw）和第6章（IRL/ERL）联读，再进入第8章池化质量模块。 + + + +# 第8章　Liquidity Pool：Old High/Low、Clean High/Low 与止损聚集 + +## 8.1　本章核心问题 + +第7章定义了流动性两侧（BSL / SSL）， +本章进入执行更关键的一步： + +**同一侧上通常有多个候选位置，哪些才是值得优先跟踪的 Liquidity Pool？** + +交易者常见问题： + +1. 图上高低点太多，不知主次。 +2. 看见池就想交易，结果噪音过载。 +3. 只会“识别池”，不会“管理池”。 + +本章主问题是： + +**什么是高质量 Liquidity Pool，如何将其转化为主次排序与执行流程？** + +围绕该主问题，回答四个子问题： + +1. Liquidity Pool 的定义、边界与典型形态。 +2. Old/Clean/Equal/Session 等池的语义差异。 +3. 池为什么会“变厚”、为什么会“失效”。 +4. 如何建立主池-次池-噪音池的分层执行法。 + +--- + +## 8.2　一句话结论 + +**Liquidity Pool 不是某个孤立点，而是“高可见度、高订单聚集、与当前叙事同向”的目标簇；只有完成主次排序并通过确认链的池，才有执行价值。** + +--- + +## 8.3　基础定义 + +### 一、Liquidity Pool（流动性池） + +**定义：** +在某价位带附近形成的订单聚集区，由止损、突破单与挂单叠加构成。 + +**关键词：** + +1. 集中（Clustering） +2. 区域（Zone） +3. 可处理（Actionable Target） + +### 二、“Pool”是区域，不是单线 + +成熟表达应把池理解为“带状区域”，而非“绝对精确单点”。 +市场订单天然存在分布厚度，过度追求点位精度会降低执行鲁棒性。 + +### 三、Old High / Old Low（历史池） + +历史显著高低点具有记忆效应与群体可见性， +在当前叙事中若仍“未充分处理”，常具高相关目标价值。 + +### 四、Clean High / Clean Low（清晰池） + +结构清晰、视觉突出的高低点更易形成一致性订单堆积， +通常比噪音摆动点更值得优先跟踪。 + +### 五、Equal Highs / Equal Lows（等高等低池） + +等高等低之所以重要，不是图形神秘，而是三重叠加： + +1. 可见性极高。 +2. 止损聚集更集中。 +3. 突破参与意愿更强。 + +### 六、Session Pool（时段池） + +亚洲、伦敦、纽约时段高低点可形成日内池化目标。 +日内交易需同时维护两张地图： + +1. 历史结构池（HTF） +2. 当日时段池（ITF） + +### 七、Confluence Pool（叠加池） + +多个流动性来源重合时，池质量通常上升。 +常见叠加： + +1. Range Edge + Previous Day High/Low +2. Equal High/Low + 旧高旧低 +3. Session High/Low + 外部边界目标 + +### 八、Relevance（有效性）条件 + +池不是永久同级。需同时检查： + +1. 是否仍未被有效处理。 +2. 是否仍在当前叙事路径内。 +3. 是否仍位于当前执行层级的核心坐标。 + +--- + +## 8.4　底层逻辑 + +### 一、池价值首先来自“可见性一致性” + +可见性越高，群体行为越一致，订单堆积越明显。 +这就是池与普通摆动点的本质差异。 + +### 二、越整齐、越公开、越重复测试，池通常越“厚” + +重复测试但未扩张的边界，常不断吸引新止损与新突破挂单， +从而形成更厚的池化区域。 + +### 三、池与结构变化耦合 + +池被处理后，常成为路径重组节点。 +但“处理池”不等于“自动反转”，必须看后续结构证据。 + +### 四、池优先级由叙事控制，不由距离单独决定 + +同侧多个池并存时，优先级通常遵循： + +1. 与 HTF Bias 一致的主池。 +2. 路径中继池（次池）。 +3. 局部噪音池（观察池）。 + +### 五、池通常是过程节点，不是终局结论 + +处理某池后常见三种后续： + +1. 同向延续至下一池。 +2. 反向接管并转向对侧池。 +3. 回归范围并继续池间博弈。 + +### 六、池管理的本质是“排序 + 证据 + 切换” + +高质量执行不在“标更多池”，而在： + +1. 先排序。 +2. 等证据。 +3. 再切换。 + +--- + +## 8.5　结构关系 + +### 一、承接第7章 + +第7章解决“流动性在上方还是下方”。 +第8章解决“同一侧上哪个位置更重要”。 + +### 二、通向第9章 + +池与池之间的低成交区将引出第9章 Liquidity Void（速度与回补问题）。 + +### 三、通向第10章与第11章 + +Stop Run / Sweep / Raid 与 Judas / Manipulation 的目标对象， +往往就是本章定义的高质量池。 + +### 四、通向第12章 + +第12章的“目标优先级系统”需要本章提供池质量输入。 +本章是排序引擎，第12章是决策引擎。 + +### 五、与执行模型关系 + +后续模型中“处理主池后入场”本质来自本章： +先定义池质量，再看处理后的结构响应。 + +--- + +## 8.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：旧高池被处理后反向接管** + +1. 价格上刺处理旧高池。 +2. 后续无延续并出现反向位移。 +3. 路径切向对侧目标。 + +**标准情境B：Session 池触发当日主波段** + +1. 时段高低点形成当日池。 +2. 关键会话处理该池后启动主波段。 +3. 后续路径按 HTF 叙事延展。 + +**标准情境C：重复测试形成厚池** + +1. 边界多次触及未破。 +2. 外侧订单不断堆积。 +3. 后续处理时更易出现剧烈行为。 + +**反例情境：细碎摆动全当池** + +1. 标注密度过高。 +2. 主次混乱。 +3. 执行噪音化。 + +### 二、交易中的真实表现 + +Pool 区域常伴随最强情绪： + +1. 突破冲动。 +2. 害怕错过（FOMO）。 +3. 即时反手冲动。 + +因此 Pool 不是“最快按键区”，而是“最需要慢确认区”。 +正确顺序应是： + +1. 池排序。 +2. 池处理。 +3. 结构确认。 +4. 再执行。 + +--- + +## 8.7　执行意义 + +本章落地为“池筛选模板 + 五步动作”。 + +### 一、主池筛选四维模板 + +| 维度 | 检查问题 | +| --- | --- | +| 清晰度 | 是否明显可见、可复述 | +| 层级 | 是否与 HTF 叙事同向 | +| 时段 | 是否处于可执行窗口 | +| 反应 | 处理后是否有结构证据 | + +### 二、池质量评分（5 分制） + +每项 0/1 分： + +1. Visibility（可见度） +2. Symmetry（整齐度） +3. Repetition（重复测试） +4. Time Significance（时间意义） +5. Confluence（叠加度） + +建议门槛： + +1. 4-5 分：主池候选 +2. 3 分：次池候选 +3. 0-2 分：噪音池（仅观察） + +### 三、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 主 Draw 与主池已定义 | 主池未定不交易 | +| 触发 | 主池被实际处理 | 仅“接近”不算触发 | +| 确认 | 处理后出现位移/接管/承接链 | 缺确认链降级 | +| 执行 | 在确认后的锚点执行 | 单笔风险上限可设 0.5%-1% | +| 退出 | 主池目标兑现后分层退出 | 失效即切换次池逻辑 | + +### 四、执行前五问 + +1. 我的主池与次池各是什么？ +2. 主池评分是否达到执行门槛？ +3. 处理后确认链需要哪些证据？ +4. 若主池失效，切换到哪个次池？ +5. 当前时段是否支持该池的执行价值？ + +--- + +## 8.8　常见误区 + +### 误区一：池画得越多越专业 + +**识别信号：** 图上每段摆动都标“关键池”。 +**纠偏动作：** 只保留高评分主池与次池。 + +### 误区二：池一触及就反手或追单 + +**识别信号：** 无确认链直接进场。 +**纠偏动作：** 先确认后执行。 + +### 误区三：只看历史池，忽略时段池 + +**识别信号：** 日内节奏总错位。 +**纠偏动作：** 盘前将 Session Pool 纳入预案。 + +### 误区四：不做主次排序 + +**识别信号：** 盘中目标频繁切换。 +**纠偏动作：** 主池失效前，不更换核心叙事。 + +### 误区五：把 Pool 当绝对精确线 + +**识别信号：** 用“差一两个点”判定失败。 +**纠偏动作：** Pool 应按区域厚度理解。 + +### 误区六：等高等低必须数学完全相等 + +**识别信号：** 过度追求像素级一致。 +**纠偏动作：** 交易上以“可见性近似水平聚集”为准。 + +### 误区七：旧高旧低永远同级 relevant + +**识别信号：** 已处理目标仍长期当主池。 +**纠偏动作：** 每轮重评 Relevance 与叙事适配度。 + +### 误区八：有池无切换规则 + +**识别信号：** 只会标注，不会在失败后切换。 +**纠偏动作：** 主池必须配次池与失效分支。 + +--- + +## 8.9　高阶深化 + +### 一、高阶能力是“管理池”而非“识别池” + +可将池分为三层： + +1. 主池：当前方向与主要目标。 +2. 次池：主池达成或失效后的接续。 +3. 噪音池：观察但不触发执行。 + +### 二、池是动态目标地图，不是静态标签 + +市场常呈现“池到池”的迁移： + +1. 内部池 -> 边界池 -> 外部池。 +2. 对侧小池 -> 同侧主池。 + +必须用动态路径思维更新池优先级。 + +### 三、Internal Pool 与 External Pool 的管理差异 + +1. Internal Pool：更适合阶段兑现与节奏管理。 +2. External Pool：更适合扩展目标与结构延续交易。 + +这一差异直接影响仓位、持仓时间与退出策略。 + +### 四、池质量与时间窗口耦合 + +同一主池在不同会话执行价值不同。 +高信息窗口中，主池更易给出可执行确认链。 + +### 五、Pool 质量冲突时的优先级 + +当“层级高但清晰度一般”与“层级低但清晰度极高”冲突时，建议： + +1. 先服从 HTF 叙事。 +2. 再在低层级等确认链。 +3. 冲突过大则降低交易频率。 + +### 六、本章工作公式 + +`Pool Quality = Visibility + Clustering + Time Significance + Layer + Confluence` + +### 七、与前七章公式联动 + +在第7章 Liquidity Targeting 基础上，本章新增“质量排序”维度： +先定目标侧，再定池优先级，再看处理后结构响应。 + +--- + +## 8.10　本章总结 + +1. Liquidity Pool 是订单聚集区，不是随意画线。 +2. Pool 应理解为区域厚度，而非单点精度。 +3. Old/Clean/Equal/Session/Confluence 是核心识别框架。 +4. 池被处理后需看路径重组，不可直接下结论。 +5. 主池/次池/噪音池分层是实盘稳定执行的关键。 + +--- + +## 8.11　训练清单 + +### 一、观察任务：主池/次池/噪音池分层 + +任务：抽取 30 个样本，逐一分层标注三类池。 +达标：主池判断与后续主要处理方向一致率至少 80%。 + +### 二、标注任务：主池优先级证据 + +任务：每个样本写两条“主池优于次池”的证据。 +达标：100% 样本均可复述优先级逻辑。 + +### 三、标注任务：池质量评分 + +任务：按五维给每个候选池打分并排序。 +达标：评分结果与后续处理优先级有一致对应关系。 + +### 四、执行任务：仅交易主池确认链闭合样本 + +任务：连续 10 个交易日，只做“主池处理 + 确认链闭合”交易。 +达标：无“噪音池冲动入场”记录。 + +### 五、复盘任务：噪音池损失统计 + +任务：复盘近 20 笔，统计噪音池触发损失占比。 +达标：每笔错误输出 1 条纠偏规则。 + +### 六、多周期任务：池层级映射 + +任务：同一时刻在 4H/15M/5M 对照池层级语义。 +达标：能清晰说明同位点在不同周期的主次变化。 + +### 七、连接任务：进入第9章 + +任务：在已完成池分层图表上继续问： +池间快速穿越区域是否存在真空，如何影响速度与回补。 +达标：可自然过渡到 Liquidity Void 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Liquidity Pool、等高等低、时段高低与结构确认原则整理。 +[2] 文中评分与门槛用于训练一致性，不构成收益承诺；需按品种波动与账户约束校准。 +[3] 建议本章与第7章联读，再进入第9章 Liquidity Void 模块。 + + + +# 第9章　Liquidity Void：速度、真空与失衡 + +## 9.1　本章核心问题 + +第7章定义了流动性两侧（BSL / SSL），第8章完成了池质量排序。 +本章继续回答一个高频实盘问题： + +**为什么价格有时会在某段区域突然加速穿越，几乎不给双向交易机会？** + +交易者在这类场景里常走向两个极端： + +1. 追速度尾段。 +2. 逆速度强猜回补。 + +两者都忽略了同一个前提： +**这段快速穿越的结构语义是什么，它在后续路径中将如何被处理？** + +本章主问题是： + +**什么是 Liquidity Void，以及如何把“速度现象”转化为可执行的回补与确认框架？** + +围绕该主问题，回答四个子问题： + +1. Void 与 Imbalance / FVG 的关系是什么。 +2. Void 为何形成，何时更 relevant。 +3. Void 后常见路径分支有哪些。 +4. 执行上如何避免“追尾”和“逆冲”两类错误。 + +--- + +## 9.2　一句话结论 + +**Liquidity Void 不是单纯的大 K 线，而是成交密度不足导致的快速递送区；它常与 Imbalance 共现，并在后续通过回补与再平衡被部分或阶段性修复。** + +--- + +## 9.3　基础定义 + +### 一、Liquidity Void（流动性真空） + +**定义：** +价格在某段区间快速推进、双向成交密度明显不足而形成的低交换效率带。 + +**识别要点：** + +1. 推进速度快，重叠与往返少。 +2. 区段相对连续，不是单根孤立长 K。 +3. 常与流动性处理事件或位移接管相邻出现。 + +### 二、Imbalance、FVG 与 Void 的关系 + +三者相关但不等同： + +1. Imbalance：广义成交不均衡现象。 +2. FVG：Imbalance 的精细化三根 K 线表达。 +3. Void：更偏“路径级速度带”的表达，通常尺度更大。 + +实盘中常用“Void 定范围，FVG 定锚点”。 + +### 三、Rebalancing（再平衡） + +**定义：** +价格在快速递送后回到低效率区，进行再交换与再定价的过程。 + +**关键边界：** + +1. 再平衡不等于必须全填。 +2. 再平衡可能浅补、深补或阶段补。 +3. 再平衡后的结构反应才决定下一步路径。 + +### 四、Void 的触发语境 + +高质量 Void 常出现在以下语境： + +1. 池被处理后出现位移释放。 +2. 关键时段内成交集中释放。 +3. 结构接管后的第一波路径展开。 + +脱离语境的“快线条”不自动等于可交易 Void。 + +### 五、Void 的路径角色 + +Void 通常扮演三类角色： + +1. 中继区：回补后延续原方向。 +2. 分歧区：回补中发生路径切换。 +3. 吸收区：反复回补后失去速度优势。 + +### 六、层级约束 + +同一 Void 在不同周期语义不同。 +执行前必须明确： + +1. 当前 Void 属于 HTF 主路径还是 LTF 噪音路径。 +2. 当前交易服务哪个层级的叙事与目标。 + +--- + +## 9.4　底层逻辑 + +### 一、Void 的本质是“路径效率过高” + +市场在某段路径上交换效率过低，导致价格以更少对手盘快速迁移。 +这既非利多也非利空，而是“状态描述”。 + +### 二、Void 常是阶段节点，不是自动终点 + +Void 后常见两类主分支： + +1. 回补后延续（中继）。 +2. 回补中接管（切换）。 + +因此，Void 提供“路径信息”，不提供“单独方向承诺”。 + +### 三、Void 与 Pool 是联动关系 + +常见序列为： + +`Pool Processing -> Displacement -> Void Formation -> Rebalancing -> Next Leg` + +Pool 提供触发，Void 显示速度，Rebalancing 提供执行窗口。 + +### 四、执行价值来自“速度差”，不是“追速度” + +成熟做法不是抓第一段冲动，而是利用冲动后的再平衡窗口。 +这会显著改善入场性价比与失效可控性。 + +### 五、Void 质量取决于前置条件 + +由明确流动性事件触发并伴随结构变化的 Void， +通常比随机放量 K 线更有后续交易价值。 + +### 六、回补深度是条件变量，不是固定常数 + +不要机械假设“必回到某个百分比”。 +应根据叙事强度、时段节奏、结构反应动态评估。 + +### 七、真正优势在“等待确认” + +Void 本身只给出“哪里快”， +执行必须等“回补后是否被承接”这一关键信息。 + +--- + +## 9.5　结构关系 + +### 一、承接第8章 + +第8章解决“哪些池更重要”， +第9章解决“池被处理后路径为何突然加速”。 + +### 二、通向第10章 + +第10章将细化动作语言（Stop Run / Sweep / Raid）。 +第9章是“动作后速度响应”的桥梁。 + +### 三、与第3章配对逻辑一致 + +本章是 `Retracement + FVG/Imbalance/Void` 的具象化章节。 +Void 的自然使用环境即“位移后回补”。 + +### 四、与第6章退出架构联动 + +Void 回补窗口常是 IRL 层面的管理节点， +Void 延续段常关联 ERL 扩展兑现。 + +### 五、通向第12章目标排序 + +Void 读取结果会影响“先内部修复还是先外部推进”的优先级判断。 + +--- + +## 9.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Pool 处理后形成 Void，回补后延续** + +1. 先处理关键池。 +2. 出现连续快速位移形成 Void 带。 +3. 回补到 Void 内关键 FVG 后继续原方向推进。 + +**标准情境B：关键时段短促 Void，回补后再推进** + +1. 会话关键窗口触发快速递送。 +2. 形成短促 Void。 +3. 回补承接后继续服务主 Draw。 + +**标准情境C：Void 回补中发生接管** + +1. 回补过程失去原方向承接。 +2. 出现反向位移与结构接管。 +3. Void 从中继区转为切换节点。 + +**反例情境：把任何快线条都当 Void** + +1. 无触发池。 +2. 无结构位移。 +3. 无回补语义。 + +这类样本应降级为噪音波动。 + +### 二、交易中的真实表现 + +实盘两类高频错误： + +1. 追 Void 尾段，在回补起点被动止损。 +2. 逆 Void 盲猜全回补，在延续段连续亏损。 + +成熟做法： + +1. 先确认 Void 语境。 +2. 再等待回补与承接证据。 +3. 最后在锚点执行，而非速度末端执行。 + +--- + +## 9.7　执行意义 + +本章执行统一为“条件—触发—确认—执行—退出”。 + +### 一、五步动作 + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 主 Draw 与关键池已定义 | 无上游目标不做 Void 交易 | +| 触发 | 池处理后出现连续快速递送区 | 仅单根大 K 不构成触发 | +| 确认 | 等待回补深度与结构承接/接管证据 | 缺确认链不执行 | +| 执行 | 在回补锚点执行，不追速度尾段 | 单笔风险上限可设 0.5%-1% | +| 退出 | 承接失败或结构夺回失败即离场 | 有效承接则按 IRL/ERL 管理 | + +### 二、Void 质量三项门控 + +1. Trigger Pool：是否由 relevant pool 处理触发。 +2. Displacement：是否具备位移质量。 +3. HTF Alignment：是否与高周期叙事一致。 + +三项缺一，降级处理。 + +### 三、执行前五问 + +1. 这段 Void 是主路径还是噪音路径？ +2. Void 触发前的 Pool 是什么？ +3. 我预设的回补观察位在哪里？ +4. 什么证据代表延续，什么代表切换？ +5. 失效条件触发后我怎么退出？ + +--- + +## 9.8　常见误区 + +### 误区一：Void 必回到起点 + +**识别信号：** 一见 Void 就逆向重仓。 +**纠偏动作：** 回补是概率事件，不是义务事件。 + +### 误区二：Void 不会回头 + +**识别信号：** 追在速度尾段。 +**纠偏动作：** 速度末端通常不是高性价比入场位。 + +### 误区三：把普通加速误判为真空 + +**识别信号：** 任何大 K 线都标 Void。 +**纠偏动作：** 必须叠加触发池与位移语义。 + +### 误区四：只看速度不看层级 + +**识别信号：** LTF Void 与 HTF 叙事冲突仍强做。 +**纠偏动作：** 方向服从高周期，低周期只做执行细化。 + +### 误区五：无回补计划 + +**识别信号：** 知道有 Void，不知道哪里等。 +**纠偏动作：** 先定 Void 范围，再定 FVG 锚点。 + +### 误区六：把回补深度机械固定 + +**识别信号：** 固定比例不看结构反应。 +**纠偏动作：** 用“深度 + 节奏 + 承接”联合判断。 + +### 误区七：回补出现即判反转 + +**识别信号：** 回补与切换混为一谈。 +**纠偏动作：** 先看是否发生反向接管再下结论。 + +### 误区八：忽略时间窗口 + +**识别信号：** 非关键窗口同等权重执行。 +**纠偏动作：** 关键时段 Void 的执行价值通常更高。 + +--- + +## 9.9　高阶深化 + +### 一、Void 是路径概率管理工具 + +高阶问题不是“会不会回补”，而是： + +1. 回补后更可能延续还是切换。 +2. 我的交易是在利用再平衡，还是在情绪追速。 + +### 二、Void 与 FVG 的分层协作 + +实战建议： + +1. Void 定大区（路径级）。 +2. FVG 定小区（执行级）。 +3. 结构响应定方向（决策级）。 + +### 三、Void 宽度与执行策略 + +1. 宽 Void：可分层等待，执行更灵活。 +2. 窄 Void：窗口更短，需更严格确认。 + +### 四、三段式读取 + +`形成 -> 回补 -> 响应` + +若三段任一缺失，Void 交易价值下降。 + +### 五、本章工作公式 + +`Void Reading = Trigger Pool + Displacement Quality + Void Width + Rebalancing Depth + HTF Alignment + Invalidation` + +### 六、与前八章公式联动 + +在第7章目标侧选择与第8章池质量排序基础上， +第9章新增“速度与回补”维度，补齐路径节奏语言。 + +--- + +## 9.10　本章总结 + +1. Liquidity Void 是成交密度不足导致的快速递送区。 +2. Void 与 Imbalance/FVG 共现频繁，但语义层级不同。 +3. Void 提供路径信息，不提供单独方向承诺。 +4. 专业执行重心在“Void 后回补确认窗口”。 +5. 学会 Void 读取，是从形态交易走向路径交易的关键步骤。 + +--- + +## 9.11　训练清单 + +### 一、观察任务：Void 与触发池配对 + +任务：抽取 30 个样本，标注 Void 区与其触发前置池。 +达标：至少 24 个样本可清晰写出“池 -> Void”链路。 + +### 二、标注任务：回补深度记录 + +任务：记录每个样本的回补深度、回补时长、后续方向。 +达标：100% 样本均有可复核记录。 + +### 三、执行任务：仅做回补确认样本 + +任务：连续 10 个交易日，禁止追 Void 尾段，只做回补确认。 +达标：无“速度尾段冲动单”。 + +### 四、复盘任务：追速单 vs 回补单 + +任务：对比近 20 笔“追速单”与“回补确认单”的绩效。 +达标：输出胜率、盈亏比、回撤三项差异。 + +### 五、标注任务：中继与切换分类 + +任务：将 30 个样本分类为“Void 中继”或“Void 切换”。 +达标：至少 24 个样本分类理由一致。 + +### 六、多周期任务：Void 语义映射 + +任务：同一时刻在 4H/15M/5M 对照 Void 语义。 +达标：能明确写出主路径 Void 与噪音 Void 区别。 + +### 七、连接任务：进入第10章 + +任务：在已识别 Void 的图表上继续问： +这段 Void 由哪类动作触发（Stop Run/Sweep/Raid），动作后确认链是否闭合。 +达标：可自然过渡到流动性动作语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Liquidity Void、Imbalance/FVG 与再平衡路径逻辑整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第8章（Pool）及第10章（动作语言）联读。 + + + +# 第10章　Stop Run、Liquidity Sweep、Raid 与 Stop Hunt + +## 10.1　本章核心问题 + +第8章解决“池在哪里”，第9章解决“池后速度如何变化”。 +本章继续回答： + +**流动性池到底是如何被处理的？** + +实盘中最容易引发冲动的画面是“高低点被扫过”。 +但关键问题不是“扫没扫”，而是： + +1. 这次动作属于什么语义。 +2. 动作后是否出现确认链。 +3. 该动作是否具备执行价值。 + +本章主问题是： + +**如何把 Stop Run / Sweep / Raid / Stop Hunt 统一为可执行的动作语言，而非情绪触发器？** + +围绕该主问题，回答四个子问题： + +1. 四个术语的共性与差异是什么。 +2. 为什么“动作本身”不等于方向信号。 +3. 动作后如何构建确认链。 +4. 如何把动作事件写进标准执行流程。 + +--- + +## 10.2　一句话结论 + +**Stop Run / Sweep / Raid / Stop Hunt 都属于流动性处理动作族；动作只说明“订单被动员”，不自动说明方向，交易价值必须来自动作后的结构确认与锚点承接。** + +--- + +## 10.3　基础定义 + +### 一、术语重叠前提 + +这四个词在实战中经常重叠，不应僵硬互斥。 +更实用的做法是按“观察重心”区分。 + +### 二、Stop Run + +**重心：** 止损触发。 +常用于描述价格快速触发某侧止损簇的动作事件。 + +### 三、Liquidity Sweep + +**重心：** 池被扫过。 +强调动作发生在明确流动性池上，关注“扫后反应”。 + +### 四、Raid + +**重心：** 清理深度与攻击性。 +常用于描述更深、更猛、更具穿透性的池处理动作。 + +### 五、Stop Hunt + +**重心：** 交易者视角的“止损收割”描述。 +在本书中可视为动作族的通俗上位词，不单独作为执行信号。 + +### 六、动作后的确认链 + +本书统一确认链： + +`Liquidity Action -> Structure Shift/Displacement -> Entry Anchor (FVG/Array) -> Execution` + +动作未进入确认链，默认不可执行。 + +### 七、与层级的关系 + +同样一次 Sweep： + +1. 在 Internal Pool 上，可能只是局部路径优化。 +2. 在 External Pool 上，可能是叙事阶段切换前奏。 + +层级不明，术语价值大幅下降。 + +--- + +## 10.4　底层逻辑 + +### 一、先处理流动性，再表达路径 + +动作是过程节点，不是结果宣判。 +市场常先动员订单，再显示真正路径。 + +### 二、动作不等于方向 + +同一类动作可导向两种结局： + +1. 扫后延续。 +2. 扫后反向。 + +差异来自扫后结构是否被接管，而非动作名称本身。 + +### 三、关键时段提升动作质量 + +高信息窗口（如重要数据/开盘时段）更易出现高质量动作事件。 +同一动作在不同时间窗可执行价值不同。 + +### 四、无确认动作应降级为观察事件 + +若动作后无位移、无接管、无锚点承接， +最优动作通常是“放弃”，不是“硬找理由入场”。 + +### 五、Acceptance vs Reclaim 是动作后关键分叉 + +动作后需判断： + +1. 是否在外侧被接受（acceptance）。 +2. 是否快速被收回（reclaim）。 + +这比动作名称更决定后续交易方向。 + +### 六、动作族价值在“去情绪化” + +把“被扫画面”翻译为“流程节点”， +可以显著降低追单冲动与反手冲动。 + +### 七、动作必须绑定失效边界 + +若预设动作未出现，或出现后确认链失败， +应按预案取消叙事，而非临场改写标准。 + +--- + +## 10.5　结构关系 + +### 一、承接第8章和第9章 + +第8章给出池对象，第9章给出速度响应， +第10章给出“池被处理”的动作语法，三者构成闭环。 + +### 二、通向第11章 + +第11章将解释“为何常先诱导再递送”。 +第10章讲“动作形态”，第11章讲“动作意图”。 + +### 三、通向第12章 + +第12章将把动作事件纳入目标优先级重排机制。 +本章是“重排触发器”的来源层。 + +### 四、与后续结构章节关系 + +后续 MSS / Displacement 章节会频繁调用本章： +先动作，再确认，再执行。 + +### 五、与执行系统关系 + +本章将“刺激事件”转化为“可复盘事件”， +是从反应式交易走向流程式交易的关键一章。 + +--- + +## 10.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Equal High 被扫后迅速回收** + +1. 上方池被处理。 +2. 外侧停留短暂。 +3. 迅速回到原范围，后续转向对侧目标。 + +**标准情境B：趋势中内部池被扫后延续** + +1. 内部池处理动作出现。 +2. 回补浅、承接强。 +3. 按原方向推进到下一层目标。 + +**标准情境C：关键窗口触发动作并闭合确认链** + +1. 动作发生在高信息时段。 +2. 随后出现位移/接管证据。 +3. 锚点承接后给出高质量执行窗口。 + +**反例情境：动作瞬间情绪入场** + +1. 只看“被扫”不看确认。 +2. 无锚点承接。 +3. 易被二次波动清理。 + +### 二、交易中的真实表现 + +大多数人都能看到“扫了高点/低点”， +真正差异在于是否执行以下顺序： + +1. 识别动作层级（Internal/External）。 +2. 等待结构确认链。 +3. 在锚点执行，而非动作瞬间执行。 + +--- + +## 10.7　执行意义 + +本章执行统一为“条件—触发—确认—执行—退出”。 + +### 一、五步动作 + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 盘前已标主池/次池与关键窗口 | 无预案不做动作交易 | +| 触发 | 出现 Stop Run / Sweep / Raid 事件 | 仅接近不算触发 | +| 确认 | 出现 MSS/Displacement/锚点承接链 | 缺确认链不执行 | +| 执行 | 在确认后入场，不抢动作瞬间 | 单笔风险上限可设 0.5%-1% | +| 退出 | 无延续或确认失效即离场 | 不为动作名称强撑持仓 | + +### 二、动作有效性三项门控 + +1. Relevance：动作是否发生在 relevant pool。 +2. Timing：动作是否发生在有效时段。 +3. Follow-through：动作后是否有结构跟随。 + +三项不足两项，降级为观察事件。 + +### 三、执行前五问 + +1. 这是主池还是噪音池动作？ +2. 动作后我需要看到什么确认证据？ +3. 我的入场锚点在哪里？ +4. 无确认时是否无条件放弃？ +5. 失效后退出动作是否已预设？ + +--- + +## 10.8　常见误区 + +### 误区一：Stop Run = 自动反转 + +**识别信号：** 扫完立刻逆向满仓。 +**纠偏动作：** 先确认结构再定方向。 + +### 误区二：忽略时段条件 + +**识别信号：** 任何时段同权重执行。 +**纠偏动作：** 把关键窗口写入预案。 + +### 误区三：有动作无路径 + +**识别信号：** 只会说“被扫了”。 +**纠偏动作：** 强制写“扫后第一目标与失效点”。 + +### 误区四：无动作硬交易 + +**识别信号：** 预案有触发条件，盘中未出现仍强做。 +**纠偏动作：** 无触发不交易。 + +### 误区五：任何 Wick 都叫 Sweep + +**识别信号：** 术语泛化导致误判。 +**纠偏动作：** 必须验证池相关性与事件强度。 + +### 误区六：只看动作，不看锚点 + +**识别信号：** 动作后直接追单。 +**纠偏动作：** 等待 FVG/Array 承接。 + +### 误区七：层级混淆 + +**识别信号：** 把微观动作当宏观结论。 +**纠偏动作：** 每次标注必须注明周期层级。 + +### 误区八：无失效纪律 + +**识别信号：** 叙事错了仍持仓。 +**纠偏动作：** 确认链失败即退出。 + +--- + +## 10.9　高阶深化 + +### 一、四词差异的正确用法 + +高阶不在抠词，而在明确“我此刻强调哪一面”： + +1. Stop Run：强调订单触发。 +2. Sweep：强调池处理。 +3. Raid：强调深度力度。 +4. Stop Hunt：强调交易者体感。 + +### 二、Acceptance/Reclaim 作为高阶分叉器 + +动作后若外侧被接受，延续概率上升； +动作后若快速收回，反向或回归概率上升。 + +### 三、Internal Sweep vs External Raid + +1. Internal Sweep：多用于路径优化与中继。 +2. External Raid：多用于阶段切换与目标重排。 + +### 四、三问法（实战） + +1. 动作处理的是主池还是次池？ +2. 扫后结构是延续还是接管？ +3. 我的执行在确认阶段还是情绪阶段？ + +### 五、本章工作公式 + +`Action Validation = Liquidity Event + Time Window + Post-Event Structure + Entry Anchor + Invalidation` + +### 六、与前九章公式联动 + +本章在第9章 Void Reading 之上增加“动作验证层”， +把“看到事件”升级为“验证事件”。 + +--- + +## 10.10　本章总结 + +1. Stop Run / Sweep / Raid / Stop Hunt 属于同一动作族。 +2. 动作只提供触发，不提供终局方向。 +3. 关键窗口会提升动作可执行价值。 +4. 无确认链不交易，是本章核心纪律。 +5. 本章将“被扫画面”转化为标准化执行流程。 + +--- + +## 10.11　训练清单 + +### 一、观察任务：动作样本库 + +任务：标注 30 个动作样本并记录时段。 +达标：100% 样本均注明层级与动作类型。 + +### 二、标注任务：确认链记录 + +任务：每个样本填写“动作后 MSS/位移/锚点”是否出现。 +达标：至少 24 个样本链路记录完整。 + +### 三、执行任务：只做确认链闭合样本 + +任务：连续 10 个交易日，仅执行确认链完整机会。 +达标：无“动作瞬间冲动单”。 + +### 四、复盘任务：动作即入场 vs 确认后入场 + +任务：比较两类入场的胜率、盈亏比与回撤。 +达标：输出三项对比并沉淀改进规则。 + +### 五、标注任务：Acceptance / Reclaim 分类 + +任务：对 30 个动作样本分类为接受或收回。 +达标：至少 24 个样本可给出一致分类依据。 + +### 六、多周期任务：动作层级映射 + +任务：同一事件在 4H/15M/5M 标注语义差异。 +达标：能明确区分“局部动作”与“阶段动作”。 + +### 七、连接任务：进入第11章 + +任务：在已标动作样本上继续问： +哪些动作前存在明显诱导，哪些属于纯路径清理。 +达标：可自然过渡到 Judas / Manipulation 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Stop Run、Sweep、Raid、关键窗口与确认链原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第9章（Void）和第11章（Manipulation）联读。 + + + +# 第11章　Judas Swing、Manipulation 与 Market Conditioning + +## 11.1　本章核心问题 + +第10章解释了“流动性如何被处理”， +本章继续回答一个更贴近交易心理的问题： + +**为什么市场常常先诱导，再走主路径？** + +实盘高频痛点： + +1. 方向最终看对，却总被第一段反向波动先洗掉。 +2. 看到突破就追，随后被回收。 +3. 被多次“假动作”条件化后，在真正机会前不敢执行。 + +本章主问题是： + +**什么是 Judas / Manipulation / Market Conditioning，以及如何把诱导阶段和确认阶段严格分离？** + +围绕该主问题，回答四个子问题： + +1. Judas 与 Manipulation 的工作定义是什么。 +2. 诱导为何常在关键时段出现。 +3. 如何区分“被利用的一边”与“被服务的一边”。 +4. 如何只交易确认，不交易猜测。 + +--- + +## 11.2　一句话结论 + +**Judas / Manipulation 的核心是先动员流动性与预期错位，再展开真实递送；专业执行必须把“诱导阶段”与“确认阶段”分离，只在确认链闭合后表达风险。** + +--- + +## 11.3　基础定义 + +### 一、Judas Swing + +**定义：** +会话关键时段内，先出现短时反向微扩张，随后切回主要路径的诱导性动作。 + +**要点：** + +1. 常发生在开盘与数据窗口附近。 +2. 核心功能是“先取流动性、再走主路”。 +3. 不等于大级别反转。 + +### 二、Manipulation（本书语义） + +**定义：** +在主路径递送前，先通过错位动作动员订单、清理对侧流动性、改善定价条件的过程。 + +**边界：** + +1. 不是阴谋论叙事。 +2. 是可观察的路径工程。 +3. 需要通过后续确认链验证。 + +### 三、Market Conditioning（市场条件化） + +**定义：** +市场通过重复的假突破、反向拉扯与时段波动，逐步塑造交易者的反应习惯。 + +**交易层影响：** + +1. 过早追单。 +2. 过早反手。 +3. 真机会来临时执行犹豫。 + +### 四、Inducement（诱导位） + +**定义：** +能够自然吸引一致性错误预期、追单与止损布局的位置结构。 + +常见诱导位： + +1. 过于整齐的 Equal High/Low。 +2. 公开边界突破形态。 +3. 会话高低点临界带。 + +### 五、诱导后的确认链 + +本书统一确认链： + +`Inducement -> Liquidity Take -> Reclaim/Displacement -> Entry Anchor -> Execution` + +缺任一环，诱导事件不进入交易阶段。 + +### 六、两阶段协议 + +1. 诱导阶段：观察，不押方向。 +2. 确认阶段：执行，绑定失效。 + +这是一条硬纪律，不是风格偏好。 + +--- + +## 11.4　底层逻辑 + +### 一、诱导核心是“成交条件 + 认知偏移” + +诱导不只清理订单，还会制造“错误确认感”。 +这为后续主路径提供更顺畅的对手盘条件。 + +### 二、关键时段会放大诱导可见度 + +高信息窗口中，订单与预期集中释放， +诱导动作更容易形成可观察结构。 + +### 三、Bullish Manipulation 常先下，Bearish 常先上 + +典型模式： + +1. 偏多叙事下先取 SSL 再上行。 +2. 偏空叙事下先取 BSL 再下行。 + +这与第5章位置优化逻辑一致： +先改善定价，再服务主 Draw。 + +### 四、诱导阶段与执行阶段必须剥离 + +亏损高发点在于把“诱导画面”当“入场信号”。 +正确顺序是：先流动性事件，再结构确认，再锚点执行。 + +### 五、不是每次诱导都成功转化 + +诱导可失败，叙事可失效。 +流程纪律应高于主观确信。 + +### 六、核心关键词不是“骗”，而是“错位” + +更成熟表达是： +市场先制造错误定位，再完成目标递送。 + +### 七、高阶优势来自行为去条件化 + +从“情绪追动作”转为“只做确认链”， +是摆脱被条件化交易行为的关键。 + +--- + +## 11.5　结构关系 + +### 一、承接第10章 + +第10章讲“动作形态”，第11章讲“动作意图”。 +前者是怎么扫，后者是为什么先这样扫。 + +### 二、承接第7-8章 + +诱导最常发生在高可见度流动性位与主池附近。 +池越公开，诱导成本越低、效果越强。 + +### 三、承接第5章 + +诱导常服务于定价改善： +先回到更优位置，再展开主方向递送。 + +### 四、通向第12章 + +第12章将把“诱导事件”纳入目标重排触发器。 +本章是目标重排系统的行为机制基础。 + +### 五、与执行系统关系 + +本章输出的是“二阶段协议”， +它直接决定你是否能避免在诱导段反复受损。 + +--- + +## 11.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Bullish Manipulation（先扫 SSL 后上行）** + +1. HTF 偏多。 +2. 开盘先下破近端 SSL。 +3. 快速收回并形成上行位移，后续转向 BSL。 + +**标准情境B：Bearish Manipulation（先扫 BSL 后下行）** + +1. HTF 偏空。 +2. 先上冲处理 BSL。 +3. 回收后转向下行递送。 + +**标准情境C：会话切换的先反向后主向** + +1. 前时段形成明显边界。 +2. 新时段先反向拉扯触发错误参与。 +3. 随后沿主叙事展开。 + +**反例情境：把每次假突破都当 Judas** + +1. 过度标签化。 +2. 忽略确认链。 +3. 模型过拟合导致过度交易。 + +### 二、交易中的真实表现 + +最常见心理陷阱： + +1. 诱导段最有速度，最想追。 +2. 确认段更慢，反而不敢做。 + +流程化纠偏： + +1. 诱导段只观察。 +2. 确认段才执行。 +3. 未确认则不交易。 + +--- + +## 11.7　执行意义 + +本章执行落地为“二阶段协议 + 五步动作”。 + +### 一、二阶段协议 + +| 阶段 | 动作 | +| --- | --- | +| 诱导阶段 | 记录事件，不下结论、不重仓 | +| 确认阶段 | 结构链闭合后执行，绑定失效 | + +### 二、五步动作（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 盘前标注潜在诱导池与关键窗口 | 无预案不做 | +| 触发 | 出现反向拉扯/扫池诱导事件 | 只触发不执行 | +| 确认 | 出现 Reclaim/Displacement + 锚点 | 缺确认链不入场 | +| 执行 | 在确认后执行并绑定失效 | 单笔风险上限可设 0.5%-1% | +| 退出 | 诱导未转确认或确认失效即离场 | 不与叙事争辩 | + +### 三、执行前五问 + +1. 当前事件是诱导还是确认？ +2. 被利用的一边与被服务的一边分别是谁？ +3. 确认链缺哪一环？ +4. 我的失效边界是什么？ +5. 若无确认，我是否愿意放弃？ + +### 四、降级规则 + +以下任一出现，诱导事件降级： + +1. 非关键窗口出现且无后续承接。 +2. 与 HTF 叙事严重冲突。 +3. 结构链长时间不闭合。 + +--- + +## 11.8　常见误区 + +### 误区一：把 Judas 当反向按钮 + +**识别信号：** 一有反向波动就立即反手。 +**纠偏动作：** 必须等待确认链闭合。 + +### 误区二：忽略时段权重 + +**识别信号：** 任何时段同权重看诱导。 +**纠偏动作：** 关键窗口高权重，其他时段降权。 + +### 误区三：把所有假突破都叫 Manipulation + +**识别信号：** 标签过多、证据过少。 +**纠偏动作：** 回到“流动性语义 + 确认链”双条件。 + +### 误区四：无失效边界 + +**识别信号：** 故事一旦相信就不退出。 +**纠偏动作：** 诱导未转确认，立即取消叙事。 + +### 误区五：每天都期待标准诱导模板 + +**识别信号：** 非模板日无法交易。 +**纠偏动作：** 接受并非每天都给 textbook 诱导。 + +### 误区六：把 Manipulation 学成阴谋论 + +**识别信号：** 讨论偏离执行流程。 +**纠偏动作：** 回到“路径工程”与证据链语言。 + +### 误区七：确认前过度预测 + +**识别信号：** 诱导段反复试错。 +**纠偏动作：** 确认前只观察，不表达风险。 + +### 误区八：确认后又犹豫不执行 + +**识别信号：** 真正机会来时不敢下单。 +**纠偏动作：** 把确认链与仓位规则预写成机械动作。 + +--- + +## 11.9　高阶深化 + +### 一、Manipulation 的高阶定义：路径工程 + +完整链条： + +`Visible Inducement -> Liquidity Take -> Mispositioning -> Repricing -> True Delivery` + +### 二、被利用侧 vs 被服务侧 + +高阶判断核心是区分： + +1. 被利用侧：先被扫的一边。 +2. 被服务侧：最终递送的一边。 + +### 三、交易者行为去条件化 + +推荐三栏日志： + +1. 诱导证据。 +2. 确认证据。 +3. 失效证据。 + +长期可显著降低情绪触发交易。 + +### 四、与第10章动作语言融合 + +动作族提供“事件”， +Manipulation 提供“事件为何先反向”的解释层。 +两者合并后，执行稳定性显著提升。 + +### 五、本章工作公式 + +`Manipulation Framework = Bias + Visible Inducement + Opposite-Side Take + Reclaim/Displacement + True Draw + Invalidation` + +### 六、与前十章公式联动 + +本章在第10章 Action Validation 之上增加“意图层与阶段层”， +把动作事件升级为可解释、可执行的路径机制。 + +--- + +## 11.10　本章总结 + +1. Judas / Manipulation 是先诱导后递送的行为机制。 +2. 关键时段会放大诱导可见度与执行价值。 +3. 诱导阶段只能观察，确认阶段才可执行。 +4. 无确认不交易，是本章最重要纪律。 +5. 机制认知只有流程化后，才会转化为稳定绩效。 + +--- + +## 11.11　训练清单 + +### 一、观察任务：Judas 样本库 + +任务：回放 30 个可疑样本，记录时段与前置池。 +达标：100% 样本都有“时段 + 池”信息。 + +### 二、标注任务：三栏日志 + +任务：每个样本填写诱导证据、确认链、失效点。 +达标：至少 24 个样本记录完整。 + +### 三、执行任务：只做确认段交易 + +任务：连续 10 个交易日，禁止诱导段入场。 +达标：诱导段冲动单为 0。 + +### 四、复盘任务：诱导段 vs 确认段 + +任务：对比两类入场的胜率、盈亏比与回撤。 +达标：输出差异并形成 3 条执行规则。 + +### 五、标注任务：被利用侧/被服务侧 + +任务：在 30 个样本中标明两侧对象。 +达标：至少 24 个样本可给出一致判据。 + +### 六、多周期任务：诱导层级映射 + +任务：在 4H/15M/5M 对照同一诱导事件语义。 +达标：能区分局部诱导与阶段性诱导。 + +### 七、连接任务：进入第12章 + +任务：在已标注样本上继续问： +当两侧目标并存时，应如何设主 Draw、次 Draw 与重排触发器。 +达标：可自然过渡到目标排序系统。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Judas Swing、Manipulation、关键时段与确认链原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第10章（动作）及第12章（目标排序）联读。 + + + +# 第12章　从流动性事件到目标选择：价格如何决定先处理哪一侧 + +## 12.1　本章核心问题 + +这是第二部分收官章。 +第7-11章分别建立了： + +1. 流动性对象（BSL / SSL）。 +2. 池质量分层（主池/次池/噪音池）。 +3. 速度与回补语言（Void）。 +4. 动作族识别（Stop Run/Sweep/Raid）。 +5. 诱导机制（Judas/Manipulation）。 + +本章将它们收束为一个实盘核心问题： + +**当两边都有目标时，价格更可能先处理哪一边？** + +若不能稳定回答这个问题， +前面术语会在盘中变成“各说各话”，执行会反复摇摆。 + +本章主问题是： + +**如何建立“主 Draw / 次 Draw / 重排触发器”的目标排序系统，并在盘中保持一致性？** + +围绕该主问题，回答四个子问题： + +1. 主 Draw 与次 Draw 如何定义。 +2. 优先级由哪些上游变量决定。 +3. 何时允许重排，何时必须坚持。 +4. 如何把目标排序转化为可执行计划。 + +--- + +## 12.2　一句话结论 + +**目标选择必须遵循“叙事 -> Draw -> Bias -> 位置 -> 确认”链路：盘前先定主次目标与重排触发器，触发器未出现前保持排序一致，触发器出现后再系统重排。** + +--- + +## 12.3　基础定义 + +### 一、主 Draw / 次 Draw + +1. 主 Draw：当前叙事下优先级最高、主导执行方向的目标。 +2. 次 Draw：主 Draw 达成后或失效后的接续目标。 + +### 二、观察 Draw（观察级目标） + +盘中可存在“观察 Draw”，用于监测但不直接触发交易。 +这样可避免把所有候选目标都升级为执行对象。 + +### 三、Current Working Draw（当前工作目标） + +在当前上下文中，最可能被优先处理且可进入执行流程的目标。 +它是“静态地图”向“动态优先级”升级的关键概念。 + +### 四、目标候选集合 + +本章候选目标默认来自两类： + +1. Liquidity Pools（内部/外部池） +2. Imbalance / FVG（再定价候选带） + +目标管理的关键不在“无限扩容”，在“有限候选排序”。 + +### 五、目标一致性 + +一致性不是固执，而是： +在同一证据框架下保持连续决策，不因噪音频繁换边。 + +### 六、重排触发器 + +本章统一三类重排触发器： + +1. 结构触发：关键结构被夺回/失守。 +2. 时段触发：关键窗口后路径显著偏离预案。 +3. 叙事触发：高周期前提被新证据否定。 + +--- + +## 12.4　底层逻辑 + +### 一、排序先于执行 + +交易失败高发原因不是“没方向”，而是“目标顺序混乱”。 +不先排序，入场与退出会互相冲突。 + +### 二、高周期决定“先哪边”，低周期决定“怎么到” + +HTF 给目标优先级，LTF 给执行路径。 +把 LTF 当方向引擎，最易导致盘中反复打脸。 + +### 三、优先级的六个核心变量 + +| 变量 | 作用 | +| --- | --- | +| HTF Bias | 决定主服务侧 | +| 位置分区 | 决定是否需先改善定价 | +| Internal/External 层级 | 决定第一站与终局站 | +| 时间窗口 | 决定当前处理概率 | +| 流动性新鲜度 | 决定目标 relevance | +| 后处理反应 | 决定是否保持或重排 | + +### 四、目标竞争通常是“先后关系”，不是二选一 + +常见竞争： + +1. 对侧流动性池目标。 +2. 当前方向内再平衡目标。 + +两者多为“先后链路”，不应机械对立。 + +### 五、重排必须客观触发 + +无触发重排=情绪重排。 +单根反向 K 线不应触发核心排序切换。 + +### 六、先被处理侧与被服务侧要区分 + +承接第11章： + +1. 先被处理的一边可能只是被利用。 +2. 真正被服务的一边才是主路径目标。 + +### 七、一致性是可持续执行的底层资产 + +盘中可以动态更新，但必须同一规则驱动。 +“动态一致性”比“即时正确”更重要。 + +--- + +## 12.5　结构关系 + +### 一、承接第7-11章 + +本章把“对象、池、速度、动作、诱导”合并为目标排序系统。 +它是第二部分方法论收束层。 + +### 二、通向第13章 + +第三部分 PD Arrays 将把目标排序进一步映射到反应位矩阵。 +本章先回答“去哪边”，第13章回答“到哪一带更易反应”。 + +### 三、与第4章 Draw 形成闭环 + +第4章定义 Draw，本章定义多目标环境下 Draw 的优先级管理。 +两章合并后，方向语言才具备盘中稳定性。 + +### 四、与第6章退出架构联动 + +主次 Draw 直接决定 IRL/ERL 的兑现权重与节奏。 + +### 五、与全书执行系统关系 + +后续所有模型章节都应回到本章核心句： +“当前动作是否服务既定 Working Draw，重排是否触发。” + +--- + +## 12.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：偏多日先扫 SSL，再服务上方 BSL** + +1. HTF 偏多。 +2. 开盘先处理下方近端 SSL（被利用侧）。 +3. 回收后转向上方主池（被服务侧）。 + +**标准情境B：先内部再外部** + +1. 先处理 Internal Pool。 +2. 再推进到边界池。 +3. 条件满足后延伸至 External Pool。 + +**标准情境C：主 Draw 保持，次 Draw 递延** + +1. 主目标未达且未失效。 +2. 次目标仅用于路径管理。 +3. 盘中不因噪音切换主叙事。 + +**反例情境：每次波动都重排** + +1. 目标频繁切换。 +2. 规则被情绪覆盖。 +3. 最终“每段都看懂，整体没抓住”。 + +### 二、交易中的真实表现 + +实盘最大痛点是“目标太多且不断变”。 +标准化解决方案： + +1. 盘前写主 Draw / 次 Draw / 观察 Draw。 +2. 盘中只允许触发器驱动重排。 +3. 每次重排都记录证据来源。 + +--- + +## 12.7　执行意义 + +本章执行模板统一为“五步排序流程 + 三类触发器”。 + +### 一、五步排序流程（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 盘前写明 Narrative 与 HTF Bias | 无 Bias 不排优先级 | +| 触发 | 定义主 Draw、次 Draw、观察 Draw | 至少 1 主 1 次 1 观察 | +| 确认 | 用流动性事件与结构反应验证主 Draw | 无验证不升级执行 | +| 执行 | 所有入场注明服务主/次 Draw | 不允许“无服务对象”交易 | +| 退出 | 仅触发重排器才改排序，否则维持一致 | 无触发不重排 | + +### 二、三类重排触发器 + +| 触发器 | 判定要点 | +| --- | --- | +| 结构触发 | 主叙事关键结构被反向夺回 | +| 时段触发 | 关键窗口后路径显著偏离预案 | +| 叙事触发 | HTF 前提被新证据否定 | + +### 三、条件式计划模板 + +1. 若先扫对侧且快速回收 -> 维持主 Draw。 +2. 若扫后被外侧接受 -> 评估主 Draw 降级。 +3. 若无关键触发 -> 保持原排序不变。 + +### 四、执行前六问 + +1. 当前 Working Draw 是哪一边？ +2. 次 Draw 是什么？ +3. 观察 Draw 是什么？ +4. 当前事件是否触发重排器？ +5. 若重排，证据来自结构/时段/叙事哪一类？ +6. 若不重排，我是否能保持执行一致？ + +--- + +## 12.8　常见误区 + +### 误区一：只写方向，不写主次目标 + +**识别信号：** 计划只有“看多/看空”。 +**纠偏动作：** 每笔强制写主 Draw、次 Draw、重排器。 + +### 误区二：目标未达就频繁翻转 + +**识别信号：** 盘中不断改故事。 +**纠偏动作：** 无触发器不重排。 + +### 误区三：把正常回撤当失效 + +**识别信号：** 每次回补都改主 Draw。 +**纠偏动作：** 先判路径修正还是结构切换。 + +### 误区四：低周期覆盖高周期 + +**识别信号：** 5M 波动推翻日线目标。 +**纠偏动作：** 方向服从 HTF，LTF 负责执行。 + +### 误区五：两边都有流动性就不敢做 + +**识别信号：** 因候选过多而停滞。 +**纠偏动作：** 接受并存常态，用排序系统决策。 + +### 误区六：重排无证据记录 + +**识别信号：** 事后说不清为何改目标。 +**纠偏动作：** 每次重排必须记录触发器类型。 + +### 误区七：主 Draw 与退出架构脱节 + +**识别信号：** 主目标明确但 IRL/ERL 管理混乱。 +**纠偏动作：** 主次目标必须映射到分层退出。 + +### 误区八：把排序系统做成静态规则 + +**识别信号：** 不会动态更新或过度僵化。 +**纠偏动作：** 动态更新，但只允许触发器驱动。 + +--- + +## 12.9　高阶深化 + +### 一、真正成熟的问题是“当前 Working Draw 是谁” + +人人看得见流动性， +高阶差异在于能否给出当下优先侧并持续一致执行。 + +### 二、Internal 决定路径细节，External 决定叙事方向 + +常见成熟路径： + +1. 先围绕 Internal 完成路径组织。 +2. 再围绕 External 完成叙事递送。 + +### 三、动态一致性 + +允许动态更新，但更新规则必须稳定统一。 +这能兼顾灵活性与纪律性。 + +### 四、重排器权重管理 + +建议优先级： + +1. 叙事触发 > 结构触发 > 时段触发。 +当触发器冲突时，优先服从更高层级证据。 + +### 五、本章工作公式 + +`Side Priority = HTF Narrative + Current Range + Location + Layer (IRL/ERL) + Time Window + Post-Take Reaction + Reorder Triggers` + +### 六、与前十一章公式联动 + +本章是第二部分公式收束层： +将 Liquidity Targeting、Pool Quality、Void Reading、Action Validation、Manipulation Framework 统一进排序决策。 + +--- + +## 12.10　本章总结 + +1. 多目标环境下，排序比单点判断更重要。 +2. 主 Draw 与次 Draw 必须盘前定义。 +3. 重排必须由客观触发器驱动。 +4. “被利用侧”与“被服务侧”必须区分。 +5. 第二部分核心产出是可执行的目标排序系统。 + +--- + +## 12.11　训练清单 + +### 一、观察任务：多目标样本排序 + +任务：抽取 30 个样本，写主 Draw / 次 Draw / 观察 Draw。 +达标：100% 样本有完整三层目标。 + +### 二、标注任务：重排证据记录 + +任务：盘中每次目标调整记录触发器类别与证据。 +达标：至少 24 次调整记录完整可复核。 + +### 三、执行任务：禁止无触发重排 + +任务：连续 10 个交易日执行“无触发不重排”规则。 +达标：无情绪型重排记录。 + +### 四、复盘任务：重排质量对比 + +任务：比较“有触发重排”与“无触发重排”的绩效差异。 +达标：输出胜率、盈亏比、回撤三项变化。 + +### 五、标注任务：被利用侧/被服务侧 + +任务：在 30 个样本中标明两侧角色。 +达标：至少 24 个样本可给出一致判据。 + +### 六、多周期任务：排序一致性 + +任务：在日线/4H/15M 上对照同一时刻目标排序。 +达标：能明确说明层级冲突时的服从规则。 + +### 七、连接任务：进入第三部分 + +任务：在已完成排序样本上继续问： +当目标确定后，价格更可能在哪些 PD Arrays 区域反应。 +达标：可自然过渡到第13章 PD Arrays 总论。 + +--- + +## 第二部分结语 + +第二部分的核心闭环已经完成： + +1. 第7章：流动性两侧对象（BSL / SSL）。 +2. 第8章：池质量分层（主池/次池/噪音池）。 +3. 第9章：速度与再平衡（Void 语言）。 +4. 第10章：动作语法（Stop Run/Sweep/Raid）。 +5. 第11章：诱导机制（Judas/Manipulation）。 +6. 第12章：目标排序系统（Working Draw 与重排器）。 + +到此你应能把“被扫”“假突破”“两边都像目标”这类情绪化描述， +转化为结构化决策语言： + +1. 先识别对象。 +2. 再排序目标。 +3. 等事件触发。 +4. 看确认链闭合。 +5. 最后执行与分层退出。 + +如果第一部分建立的是“递送框架与执行骨架”， +第二部分建立的就是“流动性驱动与目标优先级引擎”。 + +第三部分将进入 PD Arrays，回答： + +**当目标已确定，价格最可能在哪些位置发生高质量反应。** + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Narrative-Draw-Bias 链路、目标一致性与重排触发原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第4章（Draw）及第6章（IRL/ERL）回看后，再进入第13章。 + +# 第三部分　PD Arrays：价格在哪些位置更容易反应 + +前两部分已经回答了两件大事： + +1. 价格如何在范围中递送、如何定义方向与退出。 +2. 市场为何会先清理流动性，再展开路径。 + +第三部分要回答的是执行层最关键的一步： + +**当方向和目标都成立时，价格最可能在哪些位置产生高质量反应。** + +--- + +## 本部分定位 + +本部分的核心任务是把“会找位置”升级为“会评估位置质量与层级”。 +可以用一句话压缩： + +1. 流动性更像“目标对象”。 +2. PD Arrays 更像“反应位置矩阵”。 + +两者并非绝对切割，但这个学习顺序最利于执行落地。 + +--- + +## 与前两部分的衔接 + +你已经具备两张地图： + +1. 空间与目标地图：Range、位置、Draw、IRL/ERL。 +2. 流动性事件地图：Pool、Sweep、Void、Manipulation、排序重排。 + +第三部分补上第三张地图： + +**反应位置地图：价格更可能在哪些结构位承接、拒绝、再平衡与再定价。** + +--- + +## 五章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第13章 | 什么才算 institutionally relevant 的 PD Array | +| 第14章 | FVG/Imbalance/Fair Valuation 的定义与联动 | +| 第15章 | BPR 与 Rebalancing：失衡如何走向平衡 | +| 第16章 | Order Block：什么样的区块才算有效参考位 | +| 第17章 | Breaker/Mitigation：失效订单流如何再利用 | + +--- + +## 学习边界 + +本部分最容易误学成“画框游戏”。 +请固定原则： + +**PD Arrays 不是让你画更多位置，而是让你删除大多数低质量位置，只保留少数真正 relevant 的位置。** + +--- + +## 学完应具备 + +完成第三部分后，你应能： + +1. 把 PD Arrays 当作位置语言，而非图形标签。 +2. 区分 FVG、BPR、OB、Breaker、Mitigation 的功能角色。 +3. 识别“失衡 -> 回补 -> 再平衡 -> 再递送”的路径关系。 +4. 在多位置并存时做主次排序，而非信号堆叠。 +5. 为后续结构与执行模型建立高质量位置底座。 + +--- + +## 与执行系统的连接 + +第三部分会把执行流程进一步精细化为： + +`Narrative -> Draw -> PD Array Priority -> Confirmation -> Execution -> Layered Exit` + +这条流程将把“目标正确”进一步升级为“入场位置也正确”。 + +--- + +## 章末注释 + +[1] 本导读用于连接第二部分与第三部分，不替代各章细节定义。 +[2] 建议进入第13章前，先复核第12章主次 Draw 与重排触发器模板。 +[3] 第三部分核心产出是“位置质量系统”，而非“术语数量增长”。 + + + +# 第13章　PD Array 总论：什么位置才算 institutionally relevant + +## 13.1　本章核心问题 + +到第12章为止，我们已经能回答“价格更可能先处理哪一边目标”。 +本章进入执行层下一道核心门槛： + +**即便方向与目标都成立，价格到底会在哪些位置产生高质量反应？** + +实盘常见两类困境： + +1. 事后看什么都合理，事前不知道该等哪里。 +2. 图上位置越画越多，执行反而越不稳定。 + +本章主问题是： + +**什么是 PD Array，以及如何从“会找位置”升级到“会评估位置质量与层级”。** + +围绕该主问题，回答四个子问题： + +1. PD Array 的定义与边界是什么。 +2. 为什么它不是普通支撑阻力替代词。 +3. 什么条件下一个 Array 才算 relevant。 +4. 多个 Arrays 并存时如何排序。 + +--- + +## 13.2　一句话结论 + +**PD Array 是机构参考位置的矩阵系统，不是单一工具；位置是否 relevant 取决于叙事、层级、时间与结构的一致性，而非名称本身。** + +--- + +## 13.3　基础定义 + +### 一、什么是 PD Array + +**定义：** +价格递送过程中具有机构参考意义的位置集合，用于承接、拒绝、回补、再平衡与再定价观察。 + +### 二、PD Array 是“位置语言组”，不是单术语 + +第三部分主要覆盖以下数组类别： + +1. FVG / Imbalance / Liquidity Void +2. BPR（Balanced Price Range） +3. Order Block +4. Breaker / Mitigation Block + +这些并非彼此替代，而是不同语义位置工具。 + +### 三、PD Array 与普通支撑阻力的区别 + +普通支撑阻力常是“结果描述”。 +PD Array 更强调“结构成因”与“递送痕迹”，例如： + +1. 是否由位移产生。 +2. 是否带有失衡残留。 +3. 是否与流动性事件前后链条相连。 + +### 四、PD Array 的位置依赖 + +同一数组在不同位置语义不同： + +1. Discount 中 Bullish Array 常具更高承接价值。 +2. Premium 中 Bearish Array 常具更高承压价值。 +3. Equilibrium 区的数组通常需更高确认强度。 + +### 五、HTF Array 优先原则 + +高周期数组先决定方向框架，低周期数组再负责执行细化。 +跳过 HTF 容易导致“低周期看对、高周期路径错”。 + +### 六、PD Array 首先是“位置”，不是“方向” + +Array 只说明“这里值得观察反应”， +不自动承诺“到位必反转”或“到位必延续”。 + +### 七、Relevant Array 的七维筛选 + +| 维度 | 核心问题 | +| --- | --- | +| Range | 处在哪个 Dealing Range 层级 | +| Draw | 是否服务当前主 Draw | +| Position | 位于 Premium/Discount/Equilibrium 哪一侧 | +| Layer | 属于 Internal 还是 External | +| Freshness | 是否 Fresh，是否被反复处理 | +| Formation | 是否由有效位移/结构事件形成 | +| Time | 当前时段是否支持其表达 | + +七维大多不成立时，该位置应降级。 + +--- + +## 13.4　底层逻辑 + +### 一、从点位思维升级到矩阵思维 + +点位思维会导致信号过载。 +矩阵思维要求每个位置先回答： + +1. 它属于哪类 Array。 +2. 它位于哪个层级。 +3. 它服务哪条叙事。 +4. 它是否在当前时段可执行。 + +### 二、为何“Liquidity + Imbalance”常居优先层 + +机构路径通常先围绕流动性对象与失衡修复展开， +PD Arrays 的核心价值就在于把这两类信息落到具体位置。 + +### 三、Draw 只有落在具体数组上才可执行 + +抽象“看多/看空”不够。 +执行必须具体到： + +1. 去哪类目标。 +2. 在哪类数组反应。 +3. 哪个数组是主执行位。 + +### 四、Array 价值来自“递送残留” + +高质量 Array 本质是过去递送不均匀留下的结构记忆： +位移、失衡、接管、再定价痕迹都可沉淀为后续反应位。 + +### 五、有效性来自“多维共振”，不是术语堆叠 + +至少四维共振成立时才进入主执行序列： + +1. 叙事共振。 +2. 层级共振。 +3. 时间共振。 +4. 结构共振。 + +缺两项以上通常降级为观察。 + +### 六、Freshness 是边际价值核心 + +Fresh Array 常保留未完成工作。 +反复回踩与穿越会显著降低边际价值。 + +### 七、成熟交易者的优势是“删减能力” + +不是画得多，而是删得准。 +能持续删掉低质量 Array，才会留下高质量执行窗口。 + +--- + +## 13.5　结构关系 + +### 一、承接第12章 + +第12章解决“先去哪边”， +第13章解决“到了哪类位置更易反应”。 + +### 二、通向第14章 + +第14章将下钻最核心数组：FVG / Imbalance / Fair Valuation。 + +### 三、通向第15章 + +第15章继续“失衡如何走向平衡”（BPR / Rebalancing）。 + +### 四、通向第16-17章 + +第16章深入 Order Block， +第17章处理 Breaker / Mitigation 的失效再利用。 + +### 五、与全书执行系统关系 + +PD Arrays 是“目标语言”到“入场语言”的关键桥梁。 +后续模型章几乎都依赖本章的相关性筛选框架。 + +--- + +## 13.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：HTF 叙事明确，价格回到 Discount 主数组承接** + +1. 方向与目标先定。 +2. 回补进入主数组区域。 +3. 出现结构承接后开启新段递送。 + +**标准情境B：向上 seek Premium 数组，数组成为中继反应带** + +1. 主路径上行。 +2. 上方数组被触及后出现减速或再平衡。 +3. 再决定是延续还是切换。 + +**标准情境C：流动性与失衡竞争排序** + +1. 同时存在对侧池与失衡带。 +2. 先处理更高优先对象。 +3. 另一对象转为次级路径节点。 + +**标准情境D：Array 链条优于单点 Array** + +1. Sweep 发生。 +2. Displacement 形成。 +3. FVG/OB 连续出现并承接。 +4. 最终服务主 Draw。 + +**反例情境：低周期数组即刻执行** + +1. 忽略 HTF。 +2. 无优先级。 +3. 执行漂移、止损密集。 + +### 二、交易中的真实表现 + +实盘里多数冲动单都发生在“位置未筛选完成”时。 +本章实用价值是提升等待质量： + +1. 不是等任何位置。 +2. 而是等少数 relevant 位置。 + +--- + +## 13.7　执行意义 + +本章执行统一为“五步模板 + 三层矩阵”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 写明 HTF Narrative 与主 Draw | 无主 Draw 不做数组交易 | +| 触发 | 列 2-4 个候选 Arrays（主/次/观察） | 超过 4 个默认过载 | +| 确认 | 用七维筛选与四维共振做降噪 | 缺两项以上降级 | +| 执行 | 仅在主数组确认链闭合时入场 | 单笔风险上限可设 0.5%-1% | +| 退出 | 主数组失效按预案切换次数组 | 不做盘中漂移重定义 | + +### 二、PD Array 三层矩阵 + +| 层级 | 角色 | 典型用途 | +| --- | --- | --- | +| 方向层 | HTF 主导数组 | 定主路径与主 Draw | +| 路径层 | MTF 中继数组 | 定回补与再推进节奏 | +| 触发层 | LTF 执行数组 | 定入场锚点与失效点 | + +三层同向时执行容错通常最高。 + +### 三、执行前六问 + +1. 主数组与次数组分别是什么？ +2. 它们服务主 Draw 还是仅观察？ +3. 当前时段是否支持该数组表达？ +4. 它是否 Fresh 且未被过度处理？ +5. 到位后确认链是什么？ +6. 失效后切换对象是什么？ + +--- + +## 13.8　常见误区 + +### 误区一：把 PD Array 当单术语 + +**识别信号：** 只说“这里是数组”。 +**纠偏动作：** 强制写“类别+周期+角色”。 + +### 误区二：数组越多越安全 + +**识别信号：** 图上密集框导致犹豫。 +**纠偏动作：** 每周期只保留少数高一致数组。 + +### 误区三：低周期覆盖高周期 + +**识别信号：** 5M 反复推翻日线框架。 +**纠偏动作：** HTF 定方向，LTF 定执行。 + +### 误区四：忽略时间维度 + +**识别信号：** 非活跃窗口同权重执行。 +**纠偏动作：** 将时间窗口写入数组评分。 + +### 误区五：名称成立即视为有效 + +**识别信号：** “叫 FVG 就应该反应”。 +**纠偏动作：** 名称不等于 relevance。 + +### 误区六：只看 Array，不看位置 + +**识别信号：** Premium/Discount 信息缺失。 +**纠偏动作：** 数组必须嵌入位置分区。 + +### 误区七：画完 Array 就结束分析 + +**识别信号：** 无目标、无路径、无失效。 +**纠偏动作：** Array 需绑定 Draw 与执行链。 + +### 误区八：不删减旧数组 + +**识别信号：** 历史数组长期保留不降级。 +**纠偏动作：** 周期性清理低 freshness 数组。 + +--- + +## 13.9　高阶深化 + +### 一、PD Array 是“结构记忆系统” + +高质量反应位往往记录了市场过去的不均匀递送。 +读 Arrays 本质是读“市场记忆”。 + +### 二、Array 链条通常强于单点 + +实战更应关注： + +`Liquidity Event -> Displacement -> Array Formation -> Retest Reaction -> Target Delivery` + +链条完整度常比单点命中率更重要。 + +### 三、Array 同样有 Internal / External 层级 + +1. Internal Array：常用于中继与细化执行。 +2. External Array：常用于阶段切换与终局目标。 + +### 四、动态优先级而非静态框 + +Arrays 优先级会随叙事、时段、处理状态动态变化。 +高阶能力在“更新优先级”，不在“增加标注”。 + +### 五、本章工作公式 + +`Array Relevance = Range Location + Liquidity Relationship + Formation Quality + Freshness + Timeframe Alignment + Time Window + Reaction Quality + Invalidation` + +### 六、与前十二章公式联动 + +第13章在“目标排序系统”上新增“位置质量系统”， +把 Draw 转化为可执行的反应位矩阵。 + +--- + +## 13.10　本章总结 + +1. PD Array 是机构参考位置矩阵，不是单一工具。 +2. Relevance 来自叙事、层级、时间、结构共振。 +3. 高周期数组优先是稳定执行的关键。 +4. Draw 必须落到具体数组才可执行。 +5. 本章完成了“目标选择”到“位置分级”的关键过渡。 + +--- + +## 13.11　训练清单 + +### 一、观察任务：少量高质量标注 + +任务：30 张图每张最多标 2-4 个 Arrays。 +达标：主数组样本稳定性显著高于观察数组样本。 + +### 二、标注任务：四维共振评分 + +任务：为每个候选数组评分叙事/层级/时间/结构。 +达标：100% 样本有完整评分记录。 + +### 三、标注任务：相关与不相关对照 + +任务：同图标 3 个 relevant 与 3 个 non-relevant 位置。 +达标：可清楚解释差异来源。 + +### 四、执行任务：仅交易主数组确认链 + +任务：连续 10 个交易日只做主数组闭合样本。 +达标：无观察数组冲动单。 + +### 五、复盘任务：主数组 vs 观察数组 + +任务：对比两类交易的胜率、盈亏比、回撤。 +达标：输出三项统计差异。 + +### 六、删减任务：历史笔记清理 + +任务：把旧图表标注删减至少 50%，仅留高相关 Arrays。 +达标：每张图保留位置不超过 4 个。 + +### 七、连接任务：进入第14章 + +任务：在已筛选 Arrays 中继续问： +哪些属于失衡类，回补深度如何影响后续路径。 +达标：可自然过渡到 FVG/Imbalance/Fair Valuation 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 PD Array Matrix、HTF 优先与位置相关性原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第12章（目标排序）联读，再进入第14章失衡数组模块。 + + + +# 第14章　Fair Value Gap、Imbalance 与 Fair Valuation + +## 14.1　本章核心问题 + +第13章建立了 PD Array 总框架， +本章进入最核心、也最易误用的一类数组： + +**FVG、Imbalance 与 Fair Valuation。** + +常见误区集中在三点： + +1. 会画 FVG，不会定义其角色（目标位还是入场位）。 +2. 把 Imbalance 机械理解为“必回补”。 +3. 把回补直接等同于反转。 + +本章主问题是： + +**三者如何区分、如何联动、如何转化为可执行流程。** + +围绕该主问题，回答四个子问题： + +1. Imbalance、FVG、Fair Valuation 的定义边界是什么。 +2. FVG 如何在路径中扮演不同角色。 +3. 回补深度如何读取，不同深度意味着什么。 +4. 如何避免“见缺口就做”的低质量执行。 + +--- + +## 14.2　一句话结论 + +**Imbalance 是成交效率失衡现象，FVG 是其最可操作的结构表达，Fair Valuation 是失衡向再平衡回归的过程；高质量交易交易的是“失衡后的行为”，而不是“失衡标签本身”。** + +--- + +## 14.3　基础定义 + +### 一、Imbalance（失衡） + +**定义：** +价格递送中成交匹配不均衡、交换效率偏低的状态。 + +**要点：** + +1. Imbalance 是“效率概念”，不是图形名词。 +2. 它描述的是路径交换不足，不是单根 K 线大小。 + +### 二、FVG（Fair Value Gap） + +**定义：** +Imbalance 的精细化三根 K 线表达，体现局部未充分交换区间。 + +**标准识别：** + +1. Bullish FVG：第1根高点低于第3根低点，中间形成未重叠区。 +2. Bearish FVG：第1根低点高于第3根高点，中间形成未重叠区。 + +### 三、CE（Consequent Encroachment） + +**定义：** +FVG 区间中点，用于衡量“半修复”与回补深度。 + +**功能：** + +1. 提供回补工作基准。 +2. 辅助判断承接强弱。 +3. 不作为神奇精确线使用。 + +### 四、Fair Valuation（公平估值回归） + +**定义：** +价格回到失衡区进行再交换与再定价，使效率向更平衡状态回归的过程。 + +**边界：** + +1. 是过程，不是瞬时信号。 +2. 不等于趋势必反转。 + +### 五、Fill、Rebalance 与 Full Fill 的区别 + +1. Fill：价格触及或进入失衡区。 +2. Rebalance：失衡得到阶段修复（可浅、可深）。 +3. Full Fill：完整填补全部缺口区。 + +执行中应关注“修复程度 + 修复后结构”，而非执着“必须全补”。 + +### 六、FVG 不是普通跳空 + +FVG 主要是递送内部的结构失衡，不等同于隔夜跳空。 +识别必须基于位移语义与三根结构关系。 + +### 七、FVG 的双角色属性 + +同一 FVG 可扮演两类角色： + +1. 目标型 FVG：作为价格将去处理的再定价对象。 +2. 入场型 FVG：作为回补后的承接/承压执行带。 + +角色不同，执行动作不同。 + +--- + +## 14.4　底层逻辑 + +### 一、FVG 形成源于位移 + +当位移发生，双向交换常来不及完成， +于是留下局部失衡区。 +FVG 的价值来自位移残留，不来自图形美观。 + +### 二、Draw 常在“池”和“失衡”间竞争 + +价格下一步可能先处理流动性池，也可能先回补失衡区。 +执行关键是排序，不是术语偏好。 + +### 三、Fair Valuation 是再定价，不是反转承诺 + +回到 FVG 只说明修复效率， +是否反转仍需结构接管证据。 + +### 四、高质量 FVG 通常出现在流动性事件后 + +常见链条： + +`Sweep/Raid -> Displacement -> FVG -> Retest -> Delivery` + +脱离链条的孤立 FVG，执行价值通常下降。 + +### 五、回补深度本身就是信息 + +| 深度 | 常见语义 | +| --- | --- | +| 仅触近侧边缘 | 原方向强，回补需求浅 | +| 回到 CE | 典型半修复，最常见 | +| 深补至全填 | 修复需求更强，节奏更慢 | +| 穿透并接受在另一侧 | 原 FVG 语义降级或失效 | + +### 六、FVG 价值高度依赖位置分区 + +同一 Bullish FVG： + +1. 在 Discount 中常更具承接价值。 +2. 在 Premium 中可能仅是中继或风险区。 + +Array 脱离位置分区会显著降质。 + +### 七、成熟执行是“等行为”，不是“赌标签” + +“看到 FVG”只是候选触发， +“回补后承接/接管行为”才是执行依据。 + +--- + +## 14.5　结构关系 + +### 一、承接第13章 + +第13章给出位置矩阵框架， +第14章先深讲失衡类数组。 + +### 二、通向第15章 + +第15章将继续“失衡如何走向平衡”（BPR/Rebalancing）。 + +### 三、与第3章 Retracement 配对 + +本章是 `Retracement + FVG/Imbalance` 的核心落地章节。 +位移后回补是 FVG 最自然工作语境。 + +### 四、与第16章 Order Block 的协同 + +常见高质量执行是： + +1. HTF OB 给位置框架。 +2. LTF FVG 给精细入场锚点。 + +### 五、与第6章退出架构联动 + +FVG 不只用于入场，也常用于： + +1. 阶段目标管理。 +2. 减仓区观察。 +3. 失效后退出决策。 + +--- + +## 14.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：流动性清理后形成 Continuation FVG** + +1. 先有对侧流动性处理。 +2. 随后位移形成 FVG。 +3. 回踩 FVG 后继续服务主 Draw。 + +**标准情境B：Reversal FVG（切换后首个高质量回测）** + +1. Sweep 后出现结构接管。 +2. 新方向位移留下 FVG。 +3. 首次回测成为高质量执行窗口。 + +**标准情境C：FVG 作为路径中继目标** + +1. 价格先服务池目标。 +2. 再回补对手方向 FVG。 +3. 随后决定继续还是切换。 + +**反例情境：见 FVG 即逆向抄回补** + +1. 忽略 HTF 叙事。 +2. 忽略位置分区。 +3. 在强趋势日连续逆势受损。 + +### 二、交易中的真实表现 + +实盘高频错误： + +1. 首触即下单，不看确认。 +2. 把任何空隙都当 FVG。 +3. 回补后无承接仍强扛。 + +成熟流程： + +1. 先定义 FVG 角色（目标/入场）。 +2. 再看回补深度与结构反应。 +3. 最后按确认链执行。 + +--- + +## 14.7　执行意义 + +本章执行统一为“五步模板 + 角色先定”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 先写当前叙事是延续还是切换 | 角色不清不交易 | +| 触发 | 标注主 FVG/次 FVG，注明角色 | 每周期主触发不超过 2 个 | +| 确认 | 进入 FVG 后等待承接/接管证据 | 首触无确认不入场 | +| 执行 | 在确认锚点执行 | 单笔风险上限可设 0.5%-1% | +| 退出 | 无应有反应按失效退出 | 不为标签硬扛 | + +### 二、执行前六问 + +1. 该 FVG 是 Continuation 还是 Reversal 场景？ +2. 它是目标型还是入场型？ +3. 形成前是否有流动性事件与位移？ +4. 它位于 Premium/Discount 哪侧？ +5. 当前是 Fresh 还是已被反复处理？ +6. 到位后确认链是什么？ + +### 三、三段读取协议 + +`形成 -> 回补 -> 响应` + +三段缺一，执行价值显著下降。 + +### 四、失败分支预案 + +1. 到位无承接 -> 放弃。 +2. 穿透并接受在另一侧 -> 失效。 +3. 与 HTF 叙事冲突扩大 -> 降级观察。 + +--- + +## 14.8　常见误区 + +### 误区一：FVG 必完整回补 + +**识别信号：** 固定等待全填。 +**纠偏动作：** 用深度与结构反应联合判断。 + +### 误区二：看到 FVG 就默认反转 + +**识别信号：** 回补即逆向。 +**纠偏动作：** 回补不等于切换，先看接管证据。 + +### 误区三：所有空隙都当 FVG + +**识别信号：** 标注泛滥。 +**纠偏动作：** 仅保留有位移语义的标准结构。 + +### 误区四：不区分目标型与入场型 + +**识别信号：** 同一 FVG 承担冲突任务。 +**纠偏动作：** 盘前定义角色，盘中不漂移改义。 + +### 误区五：把 CE 当神奇精确线 + +**识别信号：** 点位误差即判失效。 +**纠偏动作：** CE 是工作参考，不是迷信线。 + +### 误区六：只看 FVG 不看 Liquidity + +**识别信号：** 不知道当前主 Draw。 +**纠偏动作：** FVG 必须嵌入流动性排序。 + +### 误区七：Fresh 与旧 FVG 不区分 + +**识别信号：** 旧区反复交易。 +**纠偏动作：** Fresh 优先，旧区降权。 + +### 误区八：首次触及就重仓 + +**识别信号：** 无确认链放大仓位。 +**纠偏动作：** 首触仅观察，确认后再执行。 + +--- + +## 14.9　高阶深化 + +### 一、建立“失衡叙事链” + +高阶不是画更多 FVG，而是管理三层失衡链： + +1. HTF 主失衡（方向约束）。 +2. MTF 中继失衡（路径管理）。 +3. LTF 触发失衡（执行锚点）。 + +### 二、Continuation FVG vs Reversal FVG + +1. Continuation FVG：服务原方向中继。 +2. Reversal FVG：服务新方向首次承接。 + +角色不同，仓位与预期应同步调整。 + +### 三、嵌套式 FVG + +HTF FVG 定大区，LTF FVG 定入场精度。 +多层嵌套常优于单层孤立触发。 + +### 四、再平衡后需重估结构层级 + +失衡被重平衡后，局部结构语义常发生升级/降级， +应同步更新后续目标排序。 + +### 五、本章工作公式 + +`FVG Quality = Displacement + Location + Liquidity Event + Freshness + Timeframe Alignment + Time Window + Reaction Quality + Invalidation` + +### 六、与前十三章公式联动 + +第14章在第13章 Array Relevance 基础上， +新增“失衡形成-回补-响应”的执行细则层。 + +--- + +## 14.10　本章总结 + +1. Imbalance 是效率失衡，FVG 是可操作表达。 +2. FVG 可做目标也可做入场，角色必须事前定义。 +3. Fair Valuation 是再定价过程，不是反转承诺。 +4. Draw 常在池与失衡间竞争，必须先排序。 +5. 高质量执行交易的是“回补后行为”，不是“缺口标签”。 + +--- + +## 14.11　训练清单 + +### 一、观察任务：标准 FVG 样本库 + +任务：抽取 30 段图表，严格按三根结构标注 Bull/Bear FVG。 +达标：100% 样本满足标准结构定义。 + +### 二、标注任务：FVG 质量评分 + +任务：按位移、事件、位置、freshness、层级、时段六项评分。 +达标：至少 24 个样本评分与后续表现一致。 + +### 三、标注任务：回补深度统计 + +任务：记录 40 个样本的回补深度与后续方向。 +达标：可清晰分类边缘/CE/全填/失效。 + +### 四、执行任务：只做确认后入场 + +任务：连续 10 个交易日，禁止“首触即入场”。 +达标：无无确认冲动单。 + +### 五、复盘任务：首触单 vs 确认单 + +任务：比较两类样本的胜率、盈亏比、回撤。 +达标：输出三项差异并沉淀规则。 + +### 六、连接任务：FVG 与流动性联读 + +任务：每个样本补写“当前主 Draw 在池还是在失衡”。 +达标：100% 样本可说明 FVG 在路径中的角色。 + +### 七、连接任务：进入第15章 + +任务：在已标 FVG 的样本上继续问： +当对向失衡重叠时，如何形成 BPR 与再平衡带。 +达标：可自然过渡到 BPR/Rebalancing 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Imbalance、FVG、Return to Fair Value 与再平衡逻辑整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第13章（总论）及第15章（BPR）联读。 + + + +# 第15章　Balanced Price Range 与 Rebalancing 逻辑 + +## 15.1　本章核心问题 + +第14章讲清了 Imbalance 与 FVG。 +本章继续解决一个更贴近实盘的问题： + +**当价格开始“再平衡”时，如何区分正常修复、延续中继与结构切换？** + +本章还要回答另一个关键问题： + +**什么是 Balanced Price Range（BPR），它与 Rebalancing 的关系是什么？** + +常见误区有三类： + +1. 把所有回撤都叫“回到 BPR”。 +2. 把任何横盘都叫“平衡区”。 +3. 把回补直接等同于趋势反转。 + +本章主问题是： + +**如何把“失衡 -> 平衡”的过程变成可执行的路径语言。** + +围绕该主问题，回答四个子问题： + +1. BPR 的定义边界与形成条件是什么。 +2. Rebalancing 与 Return to Fair Value 如何联动。 +3. 回补完成后如何判断延续还是切换。 +4. 如何把 BPR 写入执行模板而非事后解释。 + +--- + +## 15.2　一句话结论 + +**Rebalancing 是价格修复前期失衡的过程，BPR 是该过程可回归或再展开的平衡参照区；两者提供的是路径信息，不是方向承诺。** + +--- + +## 15.3　基础定义 + +### 一、Balanced Price Range（BPR） + +可用两种互补视角理解： + +1. **结构视角：** 对立方向失衡相互重叠后形成的平衡交易带。 +2. **路径视角：** 价格从偏离状态回到更充分交换区的参照范围。 + +核心边界： +BPR 是“范围”，不是单点。 + +### 二、Rebalancing an Imbalance + +**定义：** +价格返回前期低效率区，重新完成双向交换与再定价的过程。 + +关键边界： + +1. 可浅补、可深补、可阶段补。 +2. 不等于必须全填。 +3. 回补后结构响应比回补动作本身更重要。 + +### 三、Return to Fair Value + +**定义：** +价格从偏离状态回到相对更公平交换状态的路径行为。 + +在执行上，它与 Rebalancing 同向： +都强调“效率修复”，不自动承诺“趋势终结”。 + +### 四、再平衡后的结构烙印 + +再平衡完成后，局部结构层级可能升级或降级。 +因此“修复结束”通常意味着“结构重估开始”。 + +### 五、BPR 与 Equilibrium 的关系 + +1. Equilibrium：Range 的中值分界参考。 +2. BPR：再平衡的工作区间参考。 + +两者相关但不等同。 + +### 六、BPR 与普通盘整的区别 + +普通盘整未必是 BPR。 +BPR 更强调“由失衡修复导出的平衡区语义”， +而不是“看起来横着走”。 + +### 七、BPR 的路径角色 + +BPR 常扮演三类角色： + +1. 内部修复目标带。 +2. 风格切换观察带。 +3. 再推进前的再定价带。 + +--- + +## 15.4　底层逻辑 + +### 一、市场常在“失衡—再平衡—再推进”间循环 + +单边位移后常出现效率修复， +修复后再决定延续或切换。 +这是一种循环，不是异常。 + +### 二、Rebalancing 不等于反转 + +最重要分界： +修复效率不等于改写方向。 +方向切换仍需结构接管证据。 + +### 三、BPR 的价值在“给路径定参照” + +它回答三个执行问题： + +1. 回到哪里算正常修复。 +2. 回到哪里算修复过深。 +3. 超出哪里应启动叙事重排。 + +### 四、再平衡会重塑结构层级 + +修复完成后继续沿用旧结构， +是“方向看对但执行滞后”的常见来源。 + +### 五、Range 保持时，内部修复权重上升 + +当当前范围更可能维持时： + +1. Void/FVG 的内部填充更 relevant。 +2. BPR 的执行价值上升。 +3. 外部扩张预期应降权。 + +### 六、BPR 语义不能脱离 Draw + +BPR 的对手不是“趋势”，而是“外部目标优先级”。 +若主 Draw 已转向外部，BPR 可能只是中继站； +若主 Draw 仍在内部，BPR 就可能是主要工作区。 + +### 七、周内反转常回到前一平衡范围 + +这使 BPR 在 Swing 语境中不仅是“修复区”， +也可能是周内路径的重要目的地或中继地。 + +--- + +## 15.5　结构关系 + +### 一、承接第14章 + +第14章定义“失衡在哪里”， +第15章定义“失衡如何被修复”。 + +### 二、通向第16章 + +再平衡后最常见执行锚点之一是 Order Block。 +本章提供其路径背景层。 + +### 三、通向第17章 + +若再平衡失败并发生结构失效， +Breaker / Mitigation 的再利用语义才成立。 + +### 四、与第6章 IRL/ERL 联动 + +BPR 更偏 IRL 语言： +强调范围内修复与阶段兑现， +再视条件过渡到 ERL 扩展。 + +### 五、与第12章目标排序联动 + +“先修复失衡还是先取外部流动性” +是本章与第12章共同解决的排序问题。 + +--- + +## 15.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：位移后回到平衡带再延续** + +1. 先有明显位移与失衡。 +2. 价格回到 BPR 工作区修复。 +3. 修复后沿原叙事继续推进。 + +**标准情境B：日线完成再平衡后结构重估** + +1. 失衡被阶段修复。 +2. 结构高低点层级调整。 +3. 后续目标顺序随之更新。 + +**标准情境C：回补过深触发重排** + +1. 回补超出预设参照区。 +2. 原方向承接不足。 +3. 启动切换预案而非继续硬扛。 + +**标准情境D：周内回到前平衡范围** + +1. 先有单边偏离。 +2. 后有周内回归。 +3. BPR 充当中继或目的地。 + +**反例情境：把任何回补都当反转** + +1. 过早逆势。 +2. 在趋势环境中连续试错。 +3. 忽略“修复 != 接管”。 + +### 二、交易中的真实表现 + +实盘常见问题： + +1. 内部修复单硬拿外部扩展。 +2. 外部扩展单在内部区过早全平。 + +解决核心是先分类： + +1. 这笔是 Internal Repair Trade。 +2. 还是 External Expansion Trade。 + +分类不同，持仓预期与退出节奏应完全不同。 + +--- + +## 15.7　执行意义 + +本章执行统一为“五步模板 + 分类先行”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 定义当前是延续优先还是切换优先 | 叙事未定不交易 | +| 触发 | 标注失衡区与 BPR 工作区 | 无参照区不执行回补 | +| 确认 | 回补后观察承接/接管证据 | 缺确认链不入场 | +| 执行 | 只做“再平衡+确认”样本 | 单笔风险上限可设 0.5%-1% | +| 退出 | 超失效边界且接管成立则重排 | 不为“必须回补”硬扛 | + +### 二、两类交易分类模板 + +| 类型 | 目标 | 管理重点 | +| --- | --- | --- | +| Internal Repair Trade | 回到 BPR / 内部修复 | 快兑现、重确认 | +| External Expansion Trade | 外部流动性扩展 | 容忍回补、重延续 | + +### 三、执行前六问 + +1. 当前交易属于内部修复还是外部扩展？ +2. BPR 参照区在哪里？ +3. 当前回补深度是浅/中/深哪类？ +4. 承接证据是否出现？ +5. 何种证据触发重排？ +6. 退出动作是否与交易类型匹配？ + +### 四、风格切换规则 + +价格回到中性平衡区时应主动降预期： +降低“爆发执念”，提高“确认密度”。 + +--- + +## 15.8　常见误区 + +### 误区一：把 Rebalancing 当必反信号 + +**识别信号：** 回补即重仓反手。 +**纠偏动作：** 先判结构接管，再判方向切换。 + +### 误区二：把 BPR 当固定静态区 + +**识别信号：** 结构变化后仍沿用旧参照。 +**纠偏动作：** 每次再平衡后重估结构层级。 + +### 误区三：执着“必须全补” + +**识别信号：** 错过浅补延续。 +**纠偏动作：** 用深度+行为判断，不执着几何完美。 + +### 误区四：忽略 HTF 平衡参照 + +**识别信号：** LTF 逻辑频繁被 HTF 打断。 +**纠偏动作：** 先高后低设定参照。 + +### 误区五：把任何横盘都叫 BPR + +**识别信号：** 无失衡前提仍标 BPR。 +**纠偏动作：** 必须有失衡修复语义支撑。 + +### 误区六：交易分类错误 + +**识别信号：** 内部单硬拿外部，外部单过早跑。 +**纠偏动作：** 盘前写清交易类型。 + +### 误区七：回补深度与结构反应脱节 + +**识别信号：** 只看深度不看承接。 +**纠偏动作：** 深度与结构必须联合读取。 + +### 误区八：无重排触发器 + +**识别信号：** 回补过深仍拒绝调整。 +**纠偏动作：** 重排器前置并机械执行。 + +--- + +## 15.9　高阶深化 + +### 一、BPR 的高阶价值是“交易分类器” + +它帮助你区分当下状态： + +1. 偏离扩张态。 +2. 再平衡修复态。 +3. 修复后延续/切换态。 + +### 二、再平衡不是预测工具，而是状态工具 + +高阶优势不在预测终点， +在于识别当前阶段并匹配执行强度。 + +### 三、BPR 与 IRL/ERL 权重联动 + +1. 内部修复权重高 -> IRL 优先。 +2. 外部扩展证据强 -> ERL 权重提升。 + +### 四、层级嵌套 + +同一 BPR 在不同周期可有不同语义： +LTF 终点可能是 HTF 中继点。 + +### 五、本章工作公式 + +`Rebalancing Assessment = HTF Narrative + Current Range Condition + Imbalance Origin + Return Depth + Structure Response + IRL/ERL Priority + Invalidation` + +### 六、与前十四章公式联动 + +第15章在第14章失衡语言基础上新增“修复阶段分类器”， +把路径从“失衡识别”推进到“修复管理”。 + +--- + +## 15.10　本章总结 + +1. Rebalancing 是效率修复过程，不是方向承诺。 +2. BPR 是路径参照区，不是机械拐点位。 +3. 回补与反转必须依赖结构证据区分。 +4. 再平衡后要重估结构层级与目标顺序。 +5. 本章为 OB、Breaker/Mitigation 提供路径背景层。 + +--- + +## 15.11　训练清单 + +### 一、观察任务：失衡-平衡路径标注 + +任务：抽取 40 个样本，标注失衡区、BPR 参照区、后续路径。 +达标：至少 32 个样本链路完整。 + +### 二、标注任务：回补后延续/切换分类 + +任务：记录每个样本的后续结果。 +达标：至少 32 个样本可给出一致分类判据。 + +### 三、执行任务：仅做回补后确认链 + +任务：连续 10 个交易日只交易确认后样本。 +达标：无“回补即猜反转”单。 + +### 四、复盘任务：误把回补当反转统计 + +任务：统计近 20 笔该类错误占比。 +达标：下一轮降低 50% 以上。 + +### 五、区分任务：内部修复 vs 外部扩展 + +任务：回看 10 笔历史单，逐笔判定交易类型与管理是否匹配。 +达标：每笔均给出修正规则。 + +### 六、标注任务：回补深度与承接联读 + +任务：记录浅补/中补/深补对应的结构反应。 +达标：形成可复用的三档决策模板。 + +### 七、连接任务：进入第16章 + +任务：在已识别 BPR 的样本上继续问： +再平衡后哪些 Order Block 成为下一段执行锚点。 +达标：可自然过渡到 OB 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Rebalancing、Return to Fair Value、BPR 相关语义整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第14章（失衡）及第16章（OB）联读。 + + + +# 第16章　Order Block：定义、验证与多周期联动 + +## 16.1　本章核心问题 + +Order Block 是最常见、也最易误用的 ICT 工具。 +典型误区是“看到反向蜡烛就画 OB”，导致： + +1. 图上 OB 过载。 +2. 实盘触区即止损。 +3. 复盘解释成立，盘中执行失真。 + +本章主问题是： + +**什么是有效 Order Block，如何验证，并如何与叙事、结构、时间和 Draw 联动。** + +围绕该主问题，回答四个子问题： + +1. OB 的标准语义与形成前提是什么。 +2. Bullish / Bearish OB 如何验证。 +3. Parent / Subordinate OB 如何做多周期协同。 +4. 如何把 OB 写入可执行流程，而非标签工具。 + +--- + +## 16.2　一句话结论 + +**Order Block 不是任意反向蜡烛，而是特定叙事与结构条件下的机构参考区；高质量 OB 必须满足位移、验证、结构支持、时间窗口与数组配对的一致性。** + +--- + +## 16.3　基础定义 + +### 一、OB 属于 Expansion 语境 + +OB 的原始语义属于 Expansion： +价格离开均衡、启动再定价时留下的机构参考区。 +无位移/无扩张背景时，OB 语义显著降级。 + +### 二、Bullish Order Block + +**工作定义：** +在上行路径中，代表机构性买入参考的下行蜡烛区间。 + +**有效前提：** + +1. 后续价格先向上离开该区。 +2. 结构支持该离开行为。 +3. 回访时仍服务上游 Draw。 + +### 三、Bearish Order Block + +**工作定义：** +在下行路径中，代表机构性卖出参考的上行蜡烛区间。 + +**有效前提：** + +1. 后续价格先向下离开该区。 +2. 结构支持该离开行为。 +3. 回访时仍服务下游 Draw。 + +### 四、Validation（验证） + +OB 不是“画出来就生效”，必须通过价格验证： + +1. 先离开（move away）。 +2. 再回访（return）。 +3. 在回访处出现承接/承压证据。 + +缺失任一步，执行应降级。 + +### 五、Parent / Subordinate OB + +| 层级 | 作用 | +| --- | --- | +| Parent OB | HTF 定方向与区域边界 | +| Subordinate OB | LTF 定触发与风险精细化 | + +原则：Parent 先行，Subordinate 跟随。 + +### 六、OB 与 FVG 配对 + +高质量 OB 常与 FVG 共振： + +1. OB 给区域语义。 +2. FVG 给失衡语义。 +3. 两者重叠提高执行精度。 + +### 七、OB 不是方向本身 + +OB 首先是参考区，不是自动方向承诺。 +方向仍来自 Narrative、Draw 与结构链。 + +--- + +## 16.4　底层逻辑 + +### 一、OB 的价值来自“路径服务” + +若 OB 不服务当前 Narrative 与 Draw， +它只是一段历史蜡烛形状。 + +### 二、OB 执行需“回归 + 时段”双条件 + +可执行 OB 通常需要： + +1. 价格回到 relevant OB 区。 +2. 发生在有效时段窗口。 + +“位置对 + 时间错”同样会降质。 + +### 三、结构支持是硬前提 + +OB 到位前后若结构不支持， +即便标签成立也应降级观察。 + +### 四、失效边界优先于盈利想象 + +当关键结构被破坏， +应先承认 OB 语义失效，再讨论其他可能。 + +### 五、OB 也可出现在内部修复语境 + +当 Range 更可能维持时， +内部 OB 可成为再分配工作区， +其角色更偏中继而非终局转向。 + +### 六、高质量 OB 本质是多维授权 + +一个 OB 要进入主执行序列，通常需： + +1. 位移授权。 +2. 结构授权。 +3. 叙事授权。 +4. 时间授权。 +5. 目标授权。 + +### 七、成熟执行是“条件化等待”，不是“首次触区冲动” + +真正优势在等待确认链，而不是抢第一触碰。 + +--- + +## 16.5　结构关系 + +### 一、承接第15章 + +第15章给出再平衡路径背景， +第16章给出该背景下最常见执行锚点（OB）。 + +### 二、通向第17章 + +当 OB 失效后， +Breaker / Mitigation 才进入再利用语义。 + +### 三、与第14章关系 + +OB 记录“启动参考”，FVG 记录“回补失衡”。 +二者协同优于单独使用。 + +### 四、与第6章退出联动 + +OB 可用于： + +1. 入场锚点。 +2. 加仓/减仓节奏点。 +3. 失效触发退出点。 + +### 五、与模型章节关系 + +后续执行模型里，大量“回到 OB 再执行”的步骤， +都以本章验证框架为前提。 + +--- + +## 16.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Consolidation -> Displacement -> OB -> Retrace** + +1. 先盘整。 +2. 再位移离开。 +3. 留下 OB 参考区。 +4. 回访后承接继续服务主目标。 + +**标准情境B：HTF 明确 + MTF 回归 + LTF 确认** + +1. Parent OB 给区域。 +2. Subordinate OB 给触发。 +3. FVG 配对提高精度。 + +**标准情境C：Aggressive 与 Conservative 路径** + +1. Aggressive：区内更早确认。 +2. Conservative：等待更完整结构确认。 + +两者都需 HTF 框架先成立。 + +**标准情境D：OB 作为加仓区** + +主目标未完成时， +回访 relevant OB 可作为风险受控的加仓窗口。 + +**反例情境：反向蜡烛即 OB** + +1. 无位移。 +2. 无结构。 +3. 无叙事。 + +这类 OB 应降级为噪音标签。 + +### 二、交易中的真实表现 + +实盘常见错误： + +1. 首触即做。 +2. 不看 Parent/Subordinate。 +3. 不写失效边界。 + +成熟流程： + +1. 先判是否“被市场授权”。 +2. 再看确认链。 +3. 最后执行与管理。 + +--- + +## 16.7　执行意义 + +本章执行统一为“五步模板 + 授权检查”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 写明 Narrative/Bias/主 Draw | 无目标不做 OB 交易 | +| 触发 | 标注 Parent 与 Subordinate OB | 每层主触发不超过 2 个 | +| 确认 | 检查结构支持 + FVG 配对 + 时间窗口 | 缺两项以上降级 | +| 执行 | 按 Aggressive/Conservative 预案执行 | 单笔风险上限可设 0.5%-1% | +| 退出 | 关键结构失效即离场 | 不为“看起来像OB”硬扛 | + +### 二、OB 授权清单（执行前六问） + +1. 价格是否仍服务主 Objective？ +2. 结构是否支持该 OB？ +3. 它是 Parent 还是 Subordinate？ +4. 是否有 FVG 或其他数组共振？ +5. 当前时段是否支持表达？ +6. 失效边界写清了吗？ + +### 三、OB 质量工作公式 + +`OB Quality = Displacement + Validation + Market Structure Support + HTF Narrative/Draw + FVG Pairing + Time Window + Location + Invalidation` + +### 四、仓位与加仓规则（示例） + +1. 首次确认入场为基础仓位。 +2. 后续回访 relevant OB 且目标未完成时可分批加仓。 +3. 加仓必须同步下调单次新增风险。 + +--- + +## 16.8　常见误区 + +### 误区一：OB 可脱离叙事独立交易 + +**识别信号：** 只看区块不看 Draw。 +**纠偏动作：** 每个 OB 必须绑定服务目标。 + +### 误区二：触区即入场 + +**识别信号：** 无确认链、无时段过滤。 +**纠偏动作：** 先结构支持，再锚点执行。 + +### 误区三：忽略父子级关系 + +**识别信号：** LTF OB 与 HTF 冲突。 +**纠偏动作：** Parent 定方向，Subordinate 定执行。 + +### 误区四：无失效边界 + +**识别信号：** 区块失效后继续补仓。 +**纠偏动作：** 结构失效即退出。 + +### 误区五：OB 画得太多 + +**识别信号：** 几乎每段都有“关键 OB”。 +**纠偏动作：** 只留有位移、有验证、有叙事授权的区块。 + +### 误区六：把颜色当标准 + +**识别信号：** 反向颜色蜡烛即 OB。 +**纠偏动作：** 颜色是表象，验证才是核心。 + +### 误区七：忽略时间窗口 + +**识别信号：** 任意时段同权重执行。 +**纠偏动作：** 将时段写入 OB 评分。 + +### 误区八：不区分入场区与加仓区 + +**识别信号：** 同一规则处理所有回访。 +**纠偏动作：** 先区分角色，再配置仓位。 + +--- + +## 16.9　高阶深化 + +### 一、OB 是机构 Sponsorship 的可视化足迹 + +其价值来自“市场曾从这里真实离开并重定价”， +而非区块外观本身。 + +### 二、OB 记录的是“顺势利用对手回抽” + +Bullish Narrative 下，下行回抽常是买入机会； +Bearish Narrative 下，上行回抽常是卖出机会。 + +### 三、Parent/Subordinate 是 Top-Down 的落地核心 + +HTF 负责“该不该做”， +LTF 负责“怎么做得更好”。 + +### 四、OB 可升级为仓位组织工具 + +当目标未完成时， +retest OB + 风险受控加仓可提升收益效率。 + +### 五、本章工作公式 + +`OB Framework = HTF Direction + Structural Validation + Displacement Origin + Pairing Arrays + Timing + Risk Control + Invalidation` + +### 六、与前十五章公式联动 + +第16章将“位置相关性”推进到“启动参考区执行化”， +为第17章失效再利用提供前置语义。 + +--- + +## 16.10　本章总结 + +1. OB 是路径工具，不是孤立形态。 +2. 结构支持与位移验证是可执行前提。 +3. 高质量 OB 常见于 FVG 配对与时段过滤。 +4. Parent/Subordinate 联动决定执行稳定性。 +5. 本章是第17章 Breaker/Mitigation 的前置基础。 + +--- + +## 16.11　训练清单 + +### 一、观察任务：Parent/Subordinate 样本库 + +任务：抽取 40 个样本，标注父级与子级 OB。 +达标：至少 32 个样本层级标注一致。 + +### 二、标注任务：三条件核验 + +任务：记录每个样本是否具备结构支持、FVG 配对、有效时段。 +达标：100% 样本有核验表。 + +### 三、执行任务：只做三条件共振样本 + +任务：连续 10 个交易日仅执行三条件同时满足机会。 +达标：无“标签型 OB 冲动单”。 + +### 四、复盘任务：首触单 vs 确认单 + +任务：比较两类执行的胜率、盈亏比、回撤。 +达标：输出三项差异并形成规则。 + +### 五、标注任务：授权与降级记录 + +任务：对每个 OB 写“授权理由 + 降级理由”。 +达标：至少 32 个样本记录完整。 + +### 六、执行任务：失效边界机械化 + +任务：连续 10 个交易日执行“结构失效即离场”。 +达标：无失效后逆势补仓记录。 + +### 七、连接任务：进入第17章 + +任务：在已标 OB 样本上继续问： +当有效 OB 失效后，如何转化为 Breaker 或 Mitigation 语义。 +达标：可自然过渡到失效再利用语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 OB 定义、结构支持、父子级联动与时段过滤原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第15章（BPR）及第17章（Breaker/Mitigation）联读。 + + + +# 第17章　Breaker 与 Mitigation Block：失效订单流的再利用 + +## 17.1　本章核心问题 + +第16章讲了“有效 OB 如何利用”。 +本章继续回答执行中最关键却最常被忽略的场景： + +**当原本有效的订单流区域被击穿后，是否还能再利用？** + +很多交易者只会做“首触 OB”， +一旦失效就丢失路径感。 +而在 ICT 语境中，失效往往不是终点， +而是新阶段机会的起点。 + +本章主问题是： + +**什么是 Breaker 与 Mitigation Block，它们为何成立，如何进入可执行流程。** + +围绕该主问题，回答四个子问题： + +1. Breaker 与 Mitigation 的定义边界是什么。 +2. “失效后再利用”的订单流逻辑为何成立。 +3. 如何区分可交易再利用与事后贴标签。 +4. 如何把这类区块纳入标准执行模板。 + +--- + +## 17.2　一句话结论 + +**Breaker 与 Mitigation 的核心不是新形态，而是失效订单流的重定价再利用：关键关系被破坏后，价格回访相关区块时会出现新的交易语义；但可执行前提仍是叙事、结构、时间与目标一致。** + +--- + +## 17.3　基础定义 + +### 一、Breaker Block（工作定义） + +**定义：** +原关键参考位失效后，被重新解释为新方向参考区的区块。 + +**核心条件：** + +1. 先有旧结构关键位。 +2. 再有关键关系被破坏。 +3. 最后回访该失效位并出现新语义。 + +### 二、Bearish Breaker（概念镜像） + +常见链条： + +1. 旧高被突破。 +2. 先前关键低点随后被打破，旧多头关系失效。 +3. 回访失效位时，原多头减损与新空头介入共振。 + +### 三、Bullish Breaker（概念镜像） + +常见链条： + +1. 旧低被突破。 +2. 先前关键高点随后被夺回，旧空头关系失效。 +3. 回访失效位时，原空头回补与新多头承接共振。 + +### 四、Mitigation Block（减损修复区） + +**定义：** +价格回到特定订单流残留区，触发错误库存减损/对冲的参考区域。 + +其核心语义是： + +1. 先有建仓逻辑。 +2. 再有该逻辑被证明错误。 +3. 回访时出现“减损出场”需求。 + +### 五、Breaker 与 Mitigation 的共同语言 + +二者都属于“结构变化后的再利用工具”， +而非“初次反应工具”。 + +共同前提是： + +**被困仓位不会消失，只会在回访时转化为新订单流。** + +### 六、在 PD Array 矩阵中的位置 + +Breaker/Mitigation 必须与 OB、FVG、Void、Liquidity Pool 同框排序， +不可孤立使用。 + +### 七、激活条件边界 + +没有“失效前提”，就不应启动 Breaker 语义。 +没有“错误库存背景”，就不应强贴 Mitigation 标签。 + +--- + +## 17.4　底层逻辑 + +### 一、失败本身会生成新机会 + +关键关系破坏后，原仓位被迫调整， +这会重塑局部流动性分布， +为回访区块提供新交易语义。 + +### 二、Breaker 是顺新结构，不是逆旧结构 + +它不是抄顶抄底工具， +而是结构切换后顺势再利用工具。 + +### 三、被困仓位是 Breaker 的真正燃料 + +反应强弱核心不在蜡烛外观， +在于“谁在这里被迫出场”。 + +### 四、Mitigation 是修复信息，不是反转承诺 + +它首先告诉你库存修复正在发生， +是否转向仍需结构证据确认。 + +### 五、Repricing Arrays 是一条连续链 + +常见序列： + +`OB -> FVG/Void -> Liquidity Event -> Failure -> Breaker -> Mitigation` + +不同数组记录同一递送在不同阶段的痕迹。 + +### 六、必须服从 HTF 与目标链 + +Breaker/Mitigation 不能脱离： + +1. HTF Bias/Narrative。 +2. Premium/Discount 位置关系。 +3. Current Draw 优先级。 + +### 七、高阶优势在“识别何时不在重定价” + +若市场仅在区间内部消化、无明显重定价驱动， +强行交易 Breaker/Mitigation 往往低效。 + +--- + +## 17.5　结构关系 + +### 一、承接第16章 + +第16章讲“有效 OB 利用”， +第17章讲“OB 失效后的再利用”。 + +### 二、承接第14-15章 + +FVG/BPR 解决效率修复， +Breaker/Mitigation 解决失败结构与库存修复。 + +### 三、承接第7-12章流动性语言 + +无流动性事件、无结构破坏、无排序框架， +Breaker 语义难以成立。 + +### 四、通向第四部分结构章节 + +本章是“数组识别”到“结构转换识别”的桥梁， +直接连接后续 MSS / BOS / Displacement 章节。 + +### 五、作为第三部分收口 + +第三部分至此形成完整位置工具链： + +1. 失衡类（FVG/Imbalance） +2. 修复类（BPR/Rebalancing） +3. 启动类（OB） +4. 失效再利用类（Breaker/Mitigation） + +--- + +## 17.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Bearish Breaker 回访** + +1. 旧多头关键位失效。 +2. 回访该失效位。 +3. 出现减损卖出与新空承接，共同推动下行。 + +**标准情境B：Bullish Breaker 回访** + +1. 旧空头关键位失效。 +2. 回访该失效位。 +3. 出现空头回补与新多承接，共同推动上行。 + +**标准情境C：Mitigation 回访修复** + +1. 先有一段可识别建仓路径。 +2. 后被结构变化证明失败。 +3. 回访原参考位时出现库存修复行为。 + +**标准情境D：与 FVG/Void 共振** + +失效再利用区与失衡修复区重叠时， +可显著提高区域 relevance。 + +**反例情境：未失效先贴 Breaker 标签** + +1. 无关键破坏前提。 +2. 仅凭回踩命名。 +3. 执行语义错位。 + +### 二、交易中的真实表现 + +实盘高频错误： + +1. 把普通回踩当 Breaker。 +2. 把 Mitigation 当必反区。 +3. 无 HTF 约束逆向硬做。 + +成熟流程： + +1. 先验失效前提。 +2. 再等回访确认。 +3. 最后执行与风控。 + +--- + +## 17.7　执行意义 + +本章执行统一为“五步模板 + 失效先验”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 先确认关键结构已破坏 | 无失效前提不启动 Breaker | +| 触发 | 标注 Breaker/Mitigation 候选区与主 Draw 关系 | 每周期主候选不超过 2 个 | +| 确认 | 回访后出现承接/位移证据 | 首触无确认不入场 | +| 执行 | 在确认锚点执行，风险绑定失效点 | 单笔风险上限可设 0.5%-1% | +| 退出 | 回访后无应有反应即退出 | 不做信念加码 | + +### 二、执行前六问 + +1. 失效前提是否客观成立？ +2. 被困的一侧是谁？ +3. 回访区与当前 Draw 是否一致？ +4. 是否有数组共振（FVG/Void/Pool）？ +5. 当前时段是否支持表达？ +6. 失效后退出动作是否前置？ + +### 三、HTF-LTF 协同规则 + +1. HTF 定方向与主区。 +2. LTF 定触发与风险精度。 +3. 若两者冲突，优先 HTF。 + +### 四、风险管理硬规则 + +1. 无“失效先验”不交易。 +2. 无“回访确认”不交易。 +3. 无“失效退出”不持仓。 + +--- + +## 17.8　常见误区 + +### 误区一：把所有回踩都叫 Breaker + +**识别信号：** 无关键关系破坏。 +**纠偏动作：** 先验失效前提，再命名 Breaker。 + +### 误区二：把 Mitigation 当必反区 + +**识别信号：** 触区即重仓反向。 +**纠偏动作：** 先读修复行为，再读方向证据。 + +### 误区三：单独使用不做矩阵排序 + +**识别信号：** 区块脱离 Draw/时间/层级。 +**纠偏动作：** 放回 PD Array 矩阵统一排序。 + +### 误区四：无失效边界 + +**识别信号：** 反应失败后持续补仓。 +**纠偏动作：** 触发失效即退出。 + +### 误区五：逆 HTF Order Flow 硬做 + +**识别信号：** 局部语义对抗主叙事。 +**纠偏动作：** 优先服从 HTF 框架。 + +### 误区六：把数组学成散装标签 + +**识别信号：** 知道名词，不知当前主导类型。 +**纠偏动作：** 每次必须回答“当前谁在主导重定价”。 + +### 误区七：忽略被困侧 + +**识别信号：** 只画区不识别库存压力。 +**纠偏动作：** 先识别被困对象再执行。 + +### 误区八：忽略时段与反应质量 + +**识别信号：** 任意时段同权重。 +**纠偏动作：** 关键窗口与反应质量联合过滤。 + +--- + +## 17.9　高阶深化 + +### 一、Breaker 的高阶本质：失败防线再利用 + +旧防线失效后，原支持方转为被迫出场方。 +这个角色转换是 Breaker 反应的核心驱动。 + +### 二、Mitigation 的高阶本质：错误库存释放阀 + +它记录“错误库存最愿意被释放的位置”， +是风险修复行为的结构表达。 + +### 三、统一 Repricing 链条 + +高阶读取应把数组看成连续系统： + +1. 启动（OB） +2. 失衡（FVG/Void） +3. 清理（Liquidity Event） +4. 失效转换（Breaker） +5. 库存修复（Mitigation） + +### 四、何时不做 Breaker/Mitigation + +若无明显重定价驱动、无被困侧压力、 +仅有普通区间消化，则应主动降级为观察。 + +### 五、本章工作公式 + +`Breaker/Mitigation Relevance = Structural Failure + Trapped Side Pressure + Return Quality + HTF Alignment + Liquidity Objective + Time Window + Invalidation` + +### 六、与前十六章公式联动 + +第17章是第三部分“失效再利用”收束层， +将前序位置工具统一为订单流转换语言。 + +--- + +## 17.10　本章总结 + +1. Breaker/Mitigation 是失效订单流再利用工具。 +2. 失效前提成立是启动语义的硬条件。 +3. 被困仓位压力是反应燃料，不是蜡烛外观。 +4. 这类区块必须放入 HTF+Draw+时间统一框架。 +5. 本章完成了第三部分从“位置识别”到“转换识别”的升级。 + +--- + +## 17.11　训练清单 + +### 一、观察任务：标准 Breaker 样本库 + +任务：回看 30 段图表，严格按“失效前提 + 回访”标注 Bull/Bear Breaker。 +达标：至少 24 个样本满足完整链条。 + +### 二、标注任务：Mitigation A-B-C 复盘 + +任务：找 20 个样本，记录建仓段、失效段、回访修复段。 +达标：至少 16 个样本可复述库存修复逻辑。 + +### 三、对照任务：Breaker vs 普通 Flip + +任务：同图选 1 个 Breaker 与 1 个普通翻转位，比较后续反应。 +达标：能清晰说明两者差异来源。 + +### 四、执行任务：只做“失效+回访+确认”样本 + +任务：连续 10 个交易日仅执行三条件齐备样本。 +达标：无“无失效前提”入场记录。 + +### 五、复盘任务：标签驱动 vs 证据驱动 + +任务：比较两类入场的胜率、盈亏比、回撤。 +达标：输出三项差异并形成改进规则。 + +### 六、多周期任务：HTF-LTF 协同 + +任务：在 4H/15M/5M 对照同一 Breaker/Mitigation 语义。 +达标：能明确 Parent 区与执行区分工。 + +### 七、连接任务：进入第四部分 + +任务：在已标注样本上继续问： +何时只是波动，何时已发生结构接管与层级切换。 +达标：可自然过渡到第18章结构语言。 + +--- + +## 第三部分结语 + +第三部分五章至此完成完整位置工具闭环： + +1. 第13章：PD Array 总论，建立相关性筛选与矩阵排序。 +2. 第14章：FVG/Imbalance/Fair Valuation，建立失衡读取语言。 +3. 第15章：BPR/Rebalancing，建立修复阶段语言。 +4. 第16章：Order Block，建立启动参考区语言。 +5. 第17章：Breaker/Mitigation，建立失效再利用语言。 + +如果第二部分解决的是“先清理哪边”， +第三部分解决的就是“在路径上哪里更值得反应与执行”。 + +到此你应能把“位置很多、信号很杂”的图表， +压缩成少数高相关执行位，并用统一流程处理： + +1. 先定目标。 +2. 再排数组。 +3. 等确认链。 +4. 执行与分层退出。 + +第四部分将进入结构与位移： +回答“什么时候只是波动，什么时候已经发生结构接管”。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Breaker、Mitigation 与失效订单流再利用原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第16章（OB）联读，再进入第18章结构模块。 + +# 第四部分　结构与位移：从 Swing 到接管 + +前三部分已经建立了三张地图： + +1. 空间与目标地图：Range、位置、Draw、IRL/ERL。 +2. 流动性地图：BSL/SSL、Pool、Sweep、Manipulation、目标排序。 +3. 反应位置地图：FVG、BPR、OB、Breaker、Mitigation。 + +第四部分要补上的，是最关键的一张： + +**结构与接管地图。** + +--- + +## 本部分定位 + +本部分的核心任务是把“会画工具”升级为“会读控制权转移”。 +一句话概括： + +**市场到了位置，不代表一定会转；真正决定执行质量的是结构是否开始接管。** + +--- + +## 六章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第18章 | 四大状态如何作为上游引擎驱动工具选择 | +| 第19章 | Swing High/Low 如何成为结构锚点并分层 | +| 第20章 | ST/IT/LT 三层如何分工到方向、路径、触发 | +| 第21章 | Displacement 何时可视为接管证据 | +| 第22章 | MSB 与 MSS 如何区分“破坏”与“切换” | +| 第23章 | 预判与确认如何划清执行边界 | + +--- + +## 与前三部分的衔接 + +前三部分回答了“去哪、为何去、在哪里反应”。 +第四部分回答： + +1. 现在只是波动，还是已经结构切换。 +2. 哪些破位只是流动性处理，哪些破位是控制权转移。 +3. 什么时候该等确认，什么时候可做预判。 + +--- + +## 学习边界 + +本部分最容易误学成“见破就做”。 +请固定原则： + +**结构语言不是追单语言，而是等待条件成熟的语言。** + +也就是说： + +1. 线被碰掉不等于结构切换。 +2. 大 K 线不等于位移接管。 +3. 只有证据链闭合才有执行价值。 + +--- + +## 学完应具备 + +完成本部分后，你应能： + +1. 先识别状态，再调用对应工具。 +2. 给 Swing 高低点分层赋权，而非同级处理。 +3. 用 ST/IT/LT 拆分方向、路径、触发任务。 +4. 识别位移是否构成“接管证据”。 +5. 区分 MSB 与 MSS 的执行含义。 +6. 管理预判与确认的边界，降低冲动交易。 + +--- + +## 与执行系统的连接 + +第四部分将把流程进一步收敛为： + +`State -> Structure Hierarchy -> Displacement Evidence -> Shift Confirmation -> Execution` + +这条链路会成为后续模型化执行（第35章以后）的结构底座。 + +--- + +## 章末注释 + +[1] 本导读用于连接第三部分位置工具与第四部分结构接管语言。 +[2] 建议进入第18章前，先复核第12章目标排序与第16-17章失效再利用规则。 +[3] 第四部分核心产出是“结构证据链”，不是“更多破位标签”。 + + + +# 第18章　四大价格状态：Expansion、Retracement、Reversal、Consolidation + +## 18.1　本章核心问题 + +到第17章为止，我们已经掌握了大量工具与位置语言。 +但没有状态识别，这些工具会变成离散碎片。 + +实盘最常见错误并非“看不到信号”，而是： + +1. 在 Consolidation 中按 Expansion 逻辑追单。 +2. 在 Reversal 初期按 Retracement 逻辑逆向抗单。 +3. 在 Expansion 中后段把正常回踩误判为趋势终结。 + +本章主问题是： + +**如何用四大价格状态作为执行上游引擎，决定该用哪类工具、何时切换策略。** + +围绕该主问题，回答四个子问题： + +1. 四大状态的定义边界是什么。 +2. 各状态应对应哪些参考点。 +3. 状态如何循环与切换。 +4. 如何把状态识别写入执行流程。 + +--- + +## 18.2　一句话结论 + +**四大状态不是术语标签，而是交易框架引擎：先识别状态，再调用对应参考点；状态识别正确，工具才有执行意义。** + +--- + +## 18.3　基础定义 + +### 一、四状态是执行上游 + +四状态（Expansion、Retracement、Reversal、Consolidation） +定义当前市场处于哪种递送阶段， +并决定工具语义是否成立。 + +### 二、Expansion（扩张） + +**定义：** +价格从均衡快速离开，开始方向性重定价。 + +**典型特征：** + +1. 位移明显。 +2. 方向效率提升。 +3. 目标牵引清晰。 + +**优先参考点：** Order Block。 + +### 三、Retracement（回撤） + +**定义：** +价格回到近期位移区间内部，修复先前低效率成交。 + +**典型特征：** + +1. 回补失衡。 +2. 回访先前递送带。 +3. 尚未证明方向切换。 + +**优先参考点：** FVG / Imbalance / Liquidity Void。 + +### 四、Reversal（反转） + +**定义：** +原方向失效并由反向结构开始接管。 + +**典型特征：** + +1. 常先处理一侧流动性。 +2. 随后出现反向位移与结构接管。 +3. 原路径关键前提被改写。 + +**优先参考点：** Liquidity Pool / Stop Run。 + +### 五、Consolidation（盘整） + +**定义：** +价格受限于区间，订单在两侧累积，暂未有效离开。 + +**典型特征：** + +1. 中轴往返。 +2. 边界多次测试。 +3. 方向语义压缩。 + +**优先参考点：** Equilibrium。 + +### 六、状态与工具配对总表 + +| 状态 | 工具优先级 | 语义核心 | +| --- | --- | --- | +| Expansion | OB | 启动与重定价 | +| Retracement | FVG/Imbalance/Void | 修复与承接 | +| Reversal | Pool/Stop Run | 处理后切换 | +| Consolidation | Equilibrium | 累积与等待 | + +### 七、状态不是静态标签 + +同一交易日可经历状态切换。 +关键是识别“当前主状态”，而非执着历史标签。 + +--- + +## 18.4　底层逻辑 + +### 一、先定状态，后选工具 + +工具有效性依赖状态语境。 +状态错配时，“工具看对”也可能“执行做错”。 + +### 二、状态循环而非单向直线 + +常见循环： + +`Consolidation -> Expansion -> Retracement -> (Continuation or Reversal) -> ...` + +交易优势来自识别“切换节点”，不是记住固定形态。 + +### 三、Retracement 与 Reversal 必须严格区分 + +1. Retracement：修复，不自动改向。 +2. Reversal：接管，需要结构证据。 + +把二者混同，是趋势日逆势试错主因。 + +### 四、状态误判会导致整链错位 + +状态一旦错， +后续 Draw、数组排序、入场、退出都会联动偏离。 + +### 五、状态语义与流动性事件联动 + +很多“看似反转”只是流动性处理后的回补阶段； +很多“看似延续”在接管证据出现后其实已切换。 + +### 六、状态识别应跨层级 + +1. HTF 主状态定方向。 +2. MTF 次状态定路径。 +3. LTF 执行状态定触发。 + +层级一致时执行质量显著提升。 + +### 七、成熟优势是“等状态成熟” + +不是先有交易冲动再找状态解释， +而是先有状态证据再允许交易动作。 + +--- + +## 18.5　结构关系 + +### 一、承接第17章 + +第17章完成 PD Arrays 工具链， +第18章把工具放回统一状态引擎。 + +### 二、通向第19章 + +第19章将回答状态落地后的结构锚点问题： +哪些 Swing 真正 relevant。 + +### 三、通向第20章 + +第20章将把层级进一步固化为 ST/IT/LT 三层分工。 + +### 四、通向第21-22章 + +第21章给出位移证据标准， +第22章给出结构破坏与切换标准。 + +### 五、与执行系统关系 + +本章是第四部分“结构证据链”的入口层。 +后续模型若跳过状态识别，稳定性会显著下降。 + +--- + +## 18.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Consolidation -> Expansion -> Retracement** + +1. 区间累积。 +2. 位移离开。 +3. 回补失衡后继续主路径。 + +**标准情境B：流动性处理后 Reversal 成立** + +1. 先扫一侧池。 +2. 反向位移接管。 +3. 目标转向对侧流动性。 + +**标准情境C：Consolidation 中央噪音** + +1. 中值区反复拉扯。 +2. 边界未真正接管。 +3. 执行应降频等待。 + +**反例情境：回撤即反转** + +1. 把修复当切换。 +2. 趋势环境中逆势重仓。 +3. 高频被动止损。 + +### 二、交易中的真实表现 + +实盘中最常见问题不是“没工具”，而是“错状态用工具”。 +本章的实用价值是把工具调用顺序固定化： + +1. 先状态。 +2. 后工具。 +3. 再确认。 +4. 再执行。 + +--- + +## 18.7　执行意义 + +本章执行统一为“五步模板 + 三层状态法”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 先给市场打状态标签 | 状态不清不交易 | +| 触发 | 仅调用该状态对应参考点 | 跨状态调用降级 | +| 确认 | 检查是否出现状态切换证据 | 仅事件不够，需结构链 | +| 执行 | 只做状态一致样本 | 单笔风险上限可设 0.5%-1% | +| 退出 | 状态反向证据出现即降级/离场 | 不与新状态对抗 | + +### 二、三层状态法 + +| 层级 | 任务 | +| --- | --- | +| HTF 主状态 | 定方向与主 Draw | +| MTF 次状态 | 定路径与节奏 | +| LTF 执行状态 | 定触发与风控 | + +### 三、执行前五问 + +1. 当前主状态是什么？ +2. 我调用的工具是否匹配该状态？ +3. 当前证据是延续还是切换？ +4. 上下级状态是否冲突？ +5. 若状态切换，我的预案是什么？ + +--- + +## 18.8　常见误区 + +### 误区一：把四状态当理论标签 + +**识别信号：** 任何环境都用同一模板。 +**纠偏动作：** 盘前先写状态，再写工具。 + +### 误区二：把 Retracement 当 Reversal + +**识别信号：** 回补即反手。 +**纠偏动作：** 反转必须有接管证据。 + +### 误区三：Consolidation 中部高频追单 + +**识别信号：** 中轴区连续被扫。 +**纠偏动作：** 等边界或切换证据。 + +### 误区四：忽略状态循环 + +**识别信号：** 策略不随状态变化更新。 +**纠偏动作：** 建立状态切换日志。 + +### 误区五：低周期状态覆盖高周期 + +**识别信号：** LTF 噪音推翻 HTF。 +**纠偏动作：** HTF 优先，LTF 执行。 + +### 误区六：把位移等同状态切换 + +**识别信号：** 一根大 K 就宣判反转。 +**纠偏动作：** 位移需连同结构确认。 + +### 误区七：状态确认后仍犹豫 + +**识别信号：** 等到确认却不执行。 +**纠偏动作：** 预先写触发动作与仓位规则。 + +### 误区八：无状态失效规则 + +**识别信号：** 证据反向仍坚持旧判断。 +**纠偏动作：** 状态失效即降级处理。 + +--- + +## 18.9　高阶深化 + +### 一、高阶能力是“识别状态切换速率” + +同样从 Consolidation 进 Expansion， +切换速率不同，仓位与容错应不同。 + +### 二、状态读取本质是控制权读取 + +核心问题不再是“涨跌”， +而是“谁在接管、接管是否持续”。 + +### 三、状态与数组应双向验证 + +状态决定工具语义， +工具反应反过来验证状态判断。 + +### 四、动态一致性 + +允许状态更新，但更新必须证据驱动， +不能情绪驱动。 + +### 五、本章工作公式 + +`Execution Relevance = Current State + Matching Reference Point + State Transition Evidence + Timeframe Alignment + Invalidation` + +### 六、与前十七章公式联动 + +第18章把前三部分“目标-流动性-位置”语言 +统一接入“状态引擎”，开启结构模块。 + +--- + +## 18.10　本章总结 + +1. 四状态是执行上游，不是附加理论。 +2. 状态与工具必须配对，错配会放大亏损。 +3. 市场在状态间循环，策略应动态切换。 +4. Retracement 与 Reversal 必须严格区分。 +5. 本章为结构层级与接管证据提供统一入口。 + +--- + +## 18.11　训练清单 + +### 一、观察任务：状态标注 + +任务：抽取 40 个样本，为每个样本标四状态之一。 +达标：至少 32 个样本可给出一致判据。 + +### 二、标注任务：状态-工具配对 + +任务：每个样本写对应参考点与执行模板。 +达标：100% 样本配对完整。 + +### 三、执行任务：只做状态匹配单 + +任务：连续 10 个交易日仅执行状态一致机会。 +达标：状态错配单为 0。 + +### 四、复盘任务：匹配单 vs 错配单 + +任务：比较两类样本的胜率、盈亏比、回撤。 +达标：输出三项差异并沉淀规则。 + +### 五、标注任务：切换证据库 + +任务：收集 30 个状态切换样本，记录触发证据。 +达标：至少 24 个样本链路完整。 + +### 六、多周期任务：三层状态协同 + +任务：在 HTF/MTF/LTF 同步标注状态并判冲突。 +达标：可稳定说明冲突时的执行策略。 + +### 七、连接任务：进入第19章 + +任务：在已标状态样本上继续问： +哪些 Swing 高低点是当前状态下真正的结构锚点。 +达标：可自然过渡到结构层级语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中四状态定义与 Context/Reference 配对原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第3章（配对逻辑）及第19章（结构层级）联读。 + + + +# 第19章　Swing High / Swing Low 与结构层级 + +## 19.1　本章核心问题 + +第18章确立了状态引擎。 +要把状态真正落地到执行，还需解决一层关键问题： + +**哪些高低点只是波动，哪些高低点是真正结构锚点？** + +交易者常见痛点不是“看不到波动”，而是“看到了却不会分层”： + +1. 所有高低点同权重。 +2. 方向偏见频繁摇摆。 +3. 入场与失效边界缺乏客观性。 + +本章主问题是： + +**什么是 Swing High/Low，如何把 Swing 放进层级框架并赋予执行权重。** + +围绕该主问题，回答四个子问题： + +1. Swing 的定义边界是什么。 +2. Swing 与流动性、Range 的关系是什么。 +3. Swing 如何按层级赋权。 +4. 如何把 Swing 写入执行与失效规则。 + +--- + +## 19.2　一句话结论 + +**Swing High/Low 不是图形标签，而是结构锚点；只有放入层级框架（高/中/低）并绑定流动性语义与失效边界，Swing 才具备执行价值。** + +--- + +## 19.3　基础定义 + +### 一、Swing High / Swing Low + +**Swing High：** 阶段上行后形成、对后续路径有约束意义的高点。 +**Swing Low：** 阶段下行后形成、对后续路径有约束意义的低点。 + +最基础可由三 K 线摆点识别，但“形状成立”仅是起点， +“路径权重”由后续行为赋予。 + +### 二、Swing 的结构语义 + +Swing 的关键价值在于三件事： + +1. 约束后续路径。 +2. 定义当前控制权。 +3. 提供失效边界。 + +### 三、Swing 与流动性的双重身份 + +同一位置可同时是： + +1. 结构锚点（Swing 语义）。 +2. 订单聚集位（Liquidity 语义）。 + +结构与流动性在 Swing 上天然耦合。 + +### 四、Swing 与 Dealing Range + +无 Swing 边界，就无 Range 高低。 +无 Range 高低，就无 Premium/Discount。 +因此 Swing 是位置语言与目标语言的起点。 + +### 五、层级化读取前提 + +Swing 必须按层级读取，不能平面同权： + +1. 高层 Swing：方向与框架约束。 +2. 中层 Swing：路径与节奏管理。 +3. 低层 Swing：触发与风险精细化。 + +### 六、Swing 的“候选”与“确认” + +摆点出现时是候选锚点； +只有当后续价格行为持续围绕它组织路径时， +它才升级为关键 Swing。 + +### 七、Swing 的权重来源 + +权重通常来自： + +1. 层级位置（HTF > MTF > LTF）。 +2. 清晰度与可见性。 +3. 是否承载主 Draw 语义。 +4. 是否被后续价格尊重或破坏。 + +--- + +## 19.4　底层逻辑 + +### 一、市场结构不是平面，而是分层系统 + +高低点很多，关键高低点很少。 +若不分层，任何波动都像信号，执行必然漂移。 + +### 二、同一高低点在不同层级权重不同 + +LTF Swing 可能只是 HTF 回补噪音； +HTF Swing 失守则可能改写整段叙事。 +层级权重决定执行优先级。 + +### 三、Swing 的价值在“约束未来”而非“解释过去” + +关键问题不是“这里曾经怎么走”， +而是“这里被破坏后该怎么做”。 + +### 四、很多“破位”只是流动性处理 + +近端 Swing 被扫不等于大级别切换。 +必须区分： + +1. 流动性清理。 +2. 结构接管。 + +### 五、结构层级本质是任务分工 + +1. 大局层：定义叙事环境。 +2. 中局层：定义工作路径。 +3. 短局层：定义执行触发。 + +层级混用是“分析对、执行乱”的主因之一。 + +### 六、Swing 读取必须与状态引擎联动 + +不同状态下，Swing 语义不同： + +1. Consolidation：边界 Swing 更重要。 +2. Expansion：启动与延续 Swing 更重要。 +3. Retracement：修复级 Swing 更重要。 +4. Reversal：接管级 Swing 更重要。 + +### 七、成熟优势在“等关键 Swing 的证据” + +不是每个摆点都值得交易， +关键是等待“层级一致 + 结构一致 + 目标一致”。 + +--- + +## 19.5　结构关系 + +### 一、承接第18章 + +第18章给出状态框架， +第19章给出状态内的结构锚点系统。 + +### 二、通向第20章 + +第20章将把层级正式固化为 ST/IT/LT 三层分工模板。 + +### 三、通向第21章 + +第21章将定义位移何时能证明“Swing 接管”成立。 + +### 四、与第12章目标排序关系 + +Swing 层级直接影响主次 Draw 的执行权重与重排触发器。 + +### 五、与 PD Array 的关系 + +Swing 定骨架，PD Array 给反应位。 +两者组合后执行才稳定。 + +--- + +## 19.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：摆点先出现，权重后形成** + +1. 初始摆点只是候选。 +2. 后续被反复尊重/利用后权重升级。 +3. 最终演化为关键结构边界。 + +**标准情境B：处理一侧流动性后完成主次 Swing 替换** + +1. 先扫一侧池。 +2. 后发生结构接管。 +3. 关键 Swing 权重发生转换。 + +**标准情境C：HTF 未失守时，LTF 回撤仅作节奏调整** + +1. 低层结构频繁变化。 +2. 高层关键 Swing 保持。 +3. 主叙事不应被低层噪音推翻。 + +**反例情境：所有高低点同级** + +1. 频繁宣判切换。 +2. 多空来回反手。 +3. 绩效呈现高噪音特征。 + +### 二、交易中的真实表现 + +实盘中最大差异不在“会不会画 Swing”， +而在“会不会给 Swing 分权重”。 +分层后，交易计划会从“见破就做”变成“先判层级再执行”。 + +--- + +## 19.7　执行意义 + +本章执行统一为“五步模板 + 层级赋权”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 先定义当前主层级与主 Draw | 无层级定义不交易 | +| 触发 | 标注 LT/IT/ST 关键 Swing | 每层主锚点不超过 2 个 | +| 确认 | 判断被处理的是流动性清理还是结构接管 | 无接管证据不升级结论 | +| 执行 | 仅做层级一致样本 | 单笔风险上限可设 0.5%-1% | +| 退出 | 关键层级 Swing 失守即执行失效预案 | 不与高权重失效对抗 | + +### 二、Swing 三层执行价值 + +1. LT：方向与框架闸门。 +2. IT：路径与目标管理闸门。 +3. ST：入场与风控闸门。 + +### 三、执行前六问 + +1. 当前主导层级是 LT/IT/ST 哪一层？ +2. 被扫的是主 Swing 还是次 Swing？ +3. 这次是流动性处理还是结构接管？ +4. 它对主 Draw 有何影响？ +5. 我的失效边界在哪层？ +6. 上下层冲突时我服从哪层？ + +--- + +## 19.8　常见误区 + +### 误区一：所有 Swing 同级处理 + +**识别信号：** 图上同权重标注。 +**纠偏动作：** 先分层，再赋权。 + +### 误区二：只看形状不看流动性语义 + +**识别信号：** 结构与目标脱节。 +**纠偏动作：** 每个关键 Swing 必写对应流动性对象。 + +### 误区三：关键 Swing 失效后仍坚持旧叙事 + +**识别信号：** 被证伪后继续补仓。 +**纠偏动作：** 失效边界前置并机械执行。 + +### 误区四：低周期覆盖高周期 + +**识别信号：** LTF 噪音频繁推翻 HTF。 +**纠偏动作：** 高周期定方向，低周期定执行。 + +### 误区五：任何高低点都叫结构 + +**识别信号：** 无权重、无筛选。 +**纠偏动作：** 只保留能约束后续行为的锚点。 + +### 误区六：把流动性扫点当结构切换 + +**识别信号：** 一扫就改 Bias。 +**纠偏动作：** 先看扫后是否接管。 + +### 误区七：无层级冲突处理规则 + +**识别信号：** 冲突时随机决策。 +**纠偏动作：** 预写“冲突服从优先级”。 + +### 误区八：无行为日志 + +**识别信号：** 事后无法复盘为何切换。 +**纠偏动作：** 建立结构-目标-行为三栏记录。 + +--- + +## 19.9　高阶深化 + +### 一、Swing 是“结构权重原材料” + +高阶不是看见拐点， +而是看见拐点如何演化为边界、池、目标与失效闸门。 + +### 二、真正问题是“谁在定义 Narrative” + +分层后可稳定回答： +当前叙事由哪层结构主导， +哪些变化只是噪音，哪些变化是转折。 + +### 三、三栏记录法（推荐） + +| 栏位 | 内容 | +| --- | --- | +| 结构栏 | LT/IT/ST 关键 Swing | +| 目标栏 | 每层对应主次 Draw | +| 行为栏 | 失效触发后的执行动作 | + +三栏一致时，盘中漂移显著下降。 + +### 四、动态赋权 + +Swing 权重不是固定值， +应随状态、时段、流动性处理动态更新。 + +### 五、本章工作公式 + +`Structure Weight = Swing Layer + Liquidity Significance + Range Role + Reaction Quality + Failure Impact + Invalidation` + +### 六、与前十八章公式联动 + +第19章在状态引擎上增加“结构赋权引擎”， +为第20章 ST/IT/LT 分工提供执行框架。 + +--- + +## 19.10　本章总结 + +1. Swing 是结构锚点，不是普通高低点标签。 +2. Swing 必须分层赋权才有执行意义。 +3. Swing 与流动性语义天然耦合。 +4. 关键 Swing 失效应直接驱动持仓管理。 +5. 本章为第20章三层结构分工奠定基础。 + +--- + +## 19.11　训练清单 + +### 一、观察任务：三层 Swing 标注 + +任务：抽取 40 个样本，标 LT/IT/ST 关键 Swing。 +达标：至少 32 个样本层级标注一致。 + +### 二、标注任务：主 Draw 与失效边界 + +任务：每个关键 Swing 写主 Draw 与失效动作。 +达标：100% 样本记录完整。 + +### 三、执行任务：仅做层级一致样本 + +任务：连续 10 个交易日只做层级一致机会。 +达标：无未分层执行记录。 + +### 四、复盘任务：同级误判统计 + +任务：统计近 20 笔“未分层误判”占比。 +达标：下一轮下降至 20% 以下。 + +### 五、标注任务：扫点与接管区分 + +任务：收集 30 个“破位事件”，分类为扫点或接管。 +达标：至少 24 个样本分类可复述。 + +### 六、多周期任务：层级冲突处理 + +任务：记录 20 次层级冲突并写服从规则。 +达标：形成固定冲突决策模板。 + +### 七、连接任务：进入第20章 + +任务：在已分层样本上继续问： +ST/IT/LT 三层在方向、路径、触发上如何分工。 +达标：可自然过渡到第20章分工框架。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Swing 结构、层级视角与流动性语义联动原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第18章（状态）及第20章（层级分工）联读。 + + + +# 第20章　Short-Term、Intermediate-Term、Long-Term High/Low + +## 20.1　本章核心问题 + +第19章建立了 Swing 分层语言，本章要把它彻底执行化： + +**ST（短期）、IT（中期）、LT（长期）High/Low 如何协作，才能把方向、路径、触发拆分清楚。** + +这是从“会分析”走向“会执行”的关键分水岭。 +层级分工不清，常见后果是： + +1. 用 ST 噪音推翻 LT 方向。 +2. 用 LT 偏见强压 IT 失效信号。 +3. 入场、止损、目标跨层错配，持仓逻辑断裂。 + +本章主问题是： + +**如何建立 LT/IT/ST 三层职责，并把它们写成统一执行流程。** + +围绕该主问题，回答四个子问题： + +1. 三层高低点各自负责什么。 +2. 层级之间如何传递信息。 +3. 关键边界被破坏时如何降级或重排。 +4. 如何在实盘中避免层级冲突。 + +--- + +## 20.2　一句话结论 + +**LT High/Low 负责方向边界，IT High/Low 负责路径管理，ST High/Low 负责执行触发；三层必须同向协作，任一关键层失效都应触发计划降级或重排。** + +--- + +## 20.3　基础定义 + +### 一、LT High/Low（Long-Term） + +**角色：方向层。** +LT 负责定义主叙事边界与主 Draw 方向，不用于频繁触发入场。 + +**典型任务：** + +1. 给出“做哪边”。 +2. 定义主失效边界。 +3. 决定是否允许顺势执行。 + +### 二、IT High/Low（Intermediate-Term） + +**角色：路径层。** +IT 负责管理主方向内部的推进、回补、降速与重启节奏。 + +**典型任务：** + +1. 识别当前路径是否健康。 +2. 决定持仓是延续还是降级。 +3. 给出“当前该走到哪一步”。 + +### 三、ST High/Low（Short-Term） + +**角色：触发层。** +ST 负责入场锚点、微结构确认与风险精细化，不独立定义大方向。 + +**典型任务：** + +1. 给出“何时进”。 +2. 给出“放在哪里错”。 +3. 给出“触发失败时如何快速退出”。 + +### 四、层级职责总表 + +| 层级 | 核心问题 | 主要输出 | +| --- | --- | --- | +| LT | 做哪边 | 方向偏见、主边界、主目标 | +| IT | 怎么走 | 路径节奏、中继结构、计划有效性 | +| ST | 怎么进 | 触发时机、入场锚点、短损控制 | + +### 五、层级传递顺序 + +标准传递应为： + +`LT Direction -> IT Path -> ST Trigger` + +反向传递（ST 推翻 LT）只在“层级失效触发器”成立时才允许。 + +### 六、层级转换线索 + +常见转换信号包括： + +1. 再平衡后关键 Swing 升级。 +2. IT 关键位被有效破坏。 +3. ST 连续触发与 IT 方向脱节。 + +这些信号用于“是否重排”，而非“立刻反手”。 + +### 七、层级一致性的定义 + +三层一致并不要求“每根 K 线同向”， +而是要求： + +1. LT 不被 IT/ST 随意推翻。 +2. IT 不长期对抗 LT。 +3. ST 触发始终服务上游目标。 + +--- + +## 20.4　底层逻辑 + +### 一、三层分工本质是“降低决策冲突” + +LT 解决方向，IT 解决路径，ST 解决触发。 +不分工时，同一笔交易会出现互相矛盾的解释。 + +### 二、IT 边界是执行纪律闸门 + +实盘里最常见的问题不是 LT 看错， +而是 IT 失效后仍按旧计划持仓。 +因此 IT 层是计划“继续/降级”的核心开关。 + +### 三、ST 信号必须服务 LT/IT 目标 + +ST 出现“漂亮信号”但不服务上游目标时， +通常属于低质量交易或纯噪音反应。 + +### 四、持仓管理同样分层 + +层级化不仅用于入场，还用于持仓： + +1. LT 决定是否允许持有扩展仓位。 +2. IT 决定是否减仓/保留。 +3. ST 决定移动止损与短线兑现。 + +### 五、层级冲突是常态，不是异常 + +真正专业能力不是“永不冲突”， +而是冲突出现时能按优先级处理。 + +### 六、层级优先级应前置书面化 + +建议固定优先级： + +1. 叙事层（LT）优先。 +2. 路径层（IT）次之。 +3. 触发层（ST）最后。 + +这样可显著减少盘中情绪反复。 + +### 七、成熟执行是“层级一致性管理” + +执行稳定性来自三层一致性， +而非单次信号命中率。 + +--- + +## 20.5　结构关系 + +### 一、承接第19章 + +第19章解释“为什么要分层”， +第20章给出“分层如何执行”。 + +### 二、通向第21章 + +第21章将引入 Displacement， +作为层级切换是否成立的强证据。 + +### 三、通向第22章 + +MSB/MSS 的结构语言将直接依赖本章层级分工。 + +### 四、与第12章目标排序联动 + +主 Draw/次 Draw 的稳定性依赖层级一致性。 +层级错配会直接导致排序漂移。 + +### 五、与后续模型关系 + +后续执行模型的“方向-路径-触发”三段式， +本质就是本章层级框架的流程化表达。 + +--- + +## 20.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：LT 定向，IT 管路，ST 入场** + +1. LT 偏向先明确。 +2. IT 给出回补与继续节奏。 +3. ST 在关键时段提供触发。 + +**标准情境B：再平衡后 IT 重定义** + +1. 失衡完成阶段修复。 +2. IT 高低点层级更新。 +3. ST 触发模型同步切换。 + +**标准情境C：IT Swing 保持，ST 回撤仅作节奏调整** + +1. ST 出现反向波动。 +2. IT 关键边界未失守。 +3. 主计划保持而非反手。 + +**反例情境：LT 看多，ST 见空就重仓反手** + +1. 层级错配。 +2. 方向与触发断裂。 +3. 高频被噪音消耗。 + +### 二、交易中的真实表现 + +实盘常见失败模式： + +1. LT 讲趋势，ST 做逆势。 +2. IT 已失效，持仓不降级。 +3. ST 入场却用 LT 止损硬扛。 + +层级化模板能把这些冲突前置暴露并规避。 + +--- + +## 20.7　执行意义 + +本章执行统一为“五步模板 + 三层一致性评分”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 写清 LT 偏见与关键 LT 边界 | 无 LT 边界不做方向决策 | +| 触发 | 标注 IT 关键高低点与路径状态 | IT 未定义不执行 ST 信号 | +| 确认 | 在 ST 等待锚点与时段配合 | 无确认链不入场 | +| 执行 | ST 入场注明服务哪个 IT/LT 目标 | 单笔风险上限可设 0.5%-1% | +| 退出 | IT 失效先降级，LT 失效再重排 | 不跨层硬扛 | + +### 二、三层一致性评分（0/1） + +1. LT 一致：方向与主目标清晰。 +2. IT 一致：路径仍被关键结构支持。 +3. ST 一致：触发与时段、数组共振。 + +评分解释： + +1. 3 分：可正常执行。 +2. 2 分：降仓执行。 +3. ≤1 分：优先等待。 + +### 三、执行前六问 + +1. LT 边界在哪里？ +2. IT 关键位是否完整？ +3. ST 触发是否服务上游目标？ +4. 入场、止损、目标是否层级映射一致？ +5. 冲突时先服从哪层？ +6. 若 IT 失效，降级动作是什么？ + +--- + +## 20.8　常见误区 + +### 误区一：把 ST 当方向层 + +**识别信号：** 5M 变色即改日线偏见。 +**纠偏动作：** ST 只定执行，不定主方向。 + +### 误区二：忽略 IT 失效边界 + +**识别信号：** IT 关键位破坏后仍坚持旧计划。 +**纠偏动作：** IT 失效即计划降级。 + +### 误区三：LT 偏见绝对化 + +**识别信号：** 无视 IT/ST 现实环境。 +**纠偏动作：** LT 给方向，IT/ST 给执行权限。 + +### 误区四：入场、止损、目标跨层错配 + +**识别信号：** ST 入场 + LT 止损硬抗。 +**纠偏动作：** 三要素必须同层或有明确映射。 + +### 误区五：层级冲突时临场改规则 + +**识别信号：** 每次冲突解释不同。 +**纠偏动作：** 盘前固定冲突优先级。 + +### 误区六：只记方向不记路径 + +**识别信号：** LT 对，但 IT 节奏全错。 +**纠偏动作：** 每笔必须写 IT 路径假设。 + +### 误区七：只看触发不看任务 + +**识别信号：** 触发成立但不知这笔单任务。 +**纠偏动作：** 明确是“内部修复单”还是“外部扩展单”。 + +### 误区八：无分层复盘 + +**识别信号：** 复盘只写盈亏，不写层级错位。 +**纠偏动作：** 强制记录 LT/IT/ST 三栏。 + +--- + +## 20.9　高阶深化 + +### 一、层级一致性比命中率更接近专业能力 + +高阶交易者不是“每次都猜对”， +而是让每次决策在同一层级体系内自洽。 + +### 二、层级冲突是最有价值的预警信号 + +冲突出现时，不应硬做， +而应视为“风险上升”并主动降频降仓。 + +### 三、三层日志法（推荐） + +| 栏位 | 内容 | +| --- | --- | +| LT 栏 | 方向、边界、主目标 | +| IT 栏 | 路径状态、关键位、降级条件 | +| ST 栏 | 触发证据、入场锚点、失效点 | + +### 四、层级动态更新节奏 + +1. LT：低频更新。 +2. IT：中频更新。 +3. ST：高频更新。 + +更新频率错位会导致执行迟滞或过度反应。 + +### 五、本章工作公式 + +`Hierarchy Coherence = LT Direction Clarity + IT Path Integrity + ST Trigger Quality + Cross-Layer Mapping + Invalidation Discipline` + +### 六、与前十九章公式联动 + +第20章把“状态+Swing”升级为“执行分工系统”， +为第21-23章接管证据链提供结构底盘。 + +--- + +## 20.10　本章总结 + +1. LT/IT/ST 分工是结构化执行稳定性的核心。 +2. LT 定方向，IT 定路径，ST 定触发。 +3. IT 关键边界是计划有效性闸门。 +4. ST 信号必须服务上游目标。 +5. 本章为位移、结构切换与确认边界提供统一分层语言。 + +--- + +## 20.11　训练清单 + +### 一、观察任务：三层高低点标注 + +任务：抽取 40 个样本，标注 LT/IT/ST 关键高低点。 +达标：至少 32 个样本分层一致。 + +### 二、标注任务：方向-路径-触发映射 + +任务：每个样本写清三层证据与对应动作。 +达标：100% 样本映射完整。 + +### 三、执行任务：只做三层一致样本 + +任务：连续 10 个交易日仅执行三层一致机会。 +达标：层级错配单为 0。 + +### 四、复盘任务：错配交易统计 + +任务：比较“层级错配”与“一致性交易”绩效差异。 +达标：错配入场比例降至 20% 以下。 + +### 五、标注任务：IT 失效降级演练 + +任务：选 20 个样本，写 IT 失效后的降级动作。 +达标：每个样本有可执行降级规则。 + +### 六、多周期任务：冲突优先级回放 + +任务：回放 20 次层级冲突，按预设优先级处理。 +达标：形成固定冲突处理模板。 + +### 七、连接任务：进入第21章 + +任务：在已分层样本上继续问： +哪些位移能构成真正接管证据。 +达标：可自然过渡到 Displacement 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 LT/IT/ST 视角分工与结构纪律原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第19章（Swing 层级）及第21章（Displacement）联读。 + + + +# 第21章　Displacement：位移为何是接管证据 + +## 21.1　本章核心问题 + +第20章已经完成 LT/IT/ST 三层分工。 +接下来要回答第四部分最关键的证据问题： + +**什么样的价格推进才算“真正的位移（Displacement）”，并且足以说明控制权开始接管。** + +实盘里最常见误判有三类： + +1. 把任何大阳线/大阴线都当位移。 +2. 看到速度就追，不看它是否改写结构。 +3. 只看位移本身，不看位移前后的流动性与数组承接。 + +本章主问题是： + +**Displacement 的可执行定义是什么，为什么它是接管证据而非单纯波动现象。** + +围绕该主问题，回答四个子问题： + +1. Displacement 与普通推进的边界。 +2. 位移与流动性处理、失衡形成的顺序关系。 +3. 位移如何在 LT/IT/ST 三层里赋权。 +4. 位移失效时如何快速降级与重排。 + +--- + +## 21.2　一句话结论 + +**Displacement 的交易价值不在“走得快”，而在“走得快且改写了路径约束”：当位移同时满足流动性前置、结构重定价、失衡留痕与后续承接时，它才构成可执行的接管证据。** + +--- + +## 21.3　基础定义 + +### 一、Displacement（位移） + +Displacement 指价格在短时间内以明显效率优势离开当前均衡区、突破原路径约束、并留下可追踪失衡痕迹的推进过程。 +它不是“单根很大”，而是“路径被重新组织”。 + +### 二、位移与普通推进的区别 + +| 维度 | 普通推进 | Displacement | +| --- | --- | --- | +| 速度 | 可快可慢 | 明显加速 | +| 结构影响 | 常不改写主路径 | 通常会改写局部或中层路径 | +| 失衡痕迹 | 可有可无 | 常伴随 FVG / Void | +| 后续意义 | 更多是噪音或中继 | 可作为接管证据候选 | + +### 三、位移前置条件 + +高质量位移常见于以下前置之一： + +1. 一侧流动性被处理后。 +2. Consolidation 边界被有效离开后。 +3. 关键时段（如主要 Session）中资金集中释放后。 + +缺少前置条件时，所谓位移常退化为随机放大波动。 + +### 四、位移后的核心产物 + +位移之后最有价值的不是“涨跌幅”，而是三类可执行产物： + +1. **结构产物：** 关键 Swing 权重变化。 +2. **位置产物：** FVG / Imbalance / Void 留痕。 +3. **目标产物：** Draw 优先级被重排。 + +### 五、位移与接管的关系 + +位移是接管证据的核心候选，但不是自动结论。 +“位移成立”与“接管成立”之间还需要后续确认链： + +1. 位移后是否被接受（继续在外侧建立价值）。 +2. 位移后回补是否被承接。 +3. 对侧关键结构是否被有效夺回。 + +### 六、三层位移语义（LT/IT/ST） + +1. **LT 位移：** 可能改写阶段叙事。 +2. **IT 位移：** 决定当前工作路径是否切换。 +3. **ST 位移：** 提供执行触发，但不能单独改写 LT 方向。 + +### 七、位移失效的基本定义 + +位移失效通常表现为： + +1. 位移后迅速回收并重新接受旧区间。 +2. 位移留下的关键失衡被穿透且无承接。 +3. 位移对应的结构增益在短周期内被完全抹平。 + +--- + +## 21.4　底层逻辑 + +### 一、位移本质是“效率优势 + 路径改写” + +市场每时每刻都在波动， +但只有少数波动具备“改写约束”的能力。 +Displacement 的核心，是让原本有效的路径被迫重排。 + +### 二、位移是流动性事件后的高价值读取窗口 + +很多高质量位移并不是凭空出现， +而是发生在某一侧流动性被处理之后。 +这时位移不仅告诉你“动了”，更告诉你“谁在接手”。 + +### 三、位移与失衡是同一过程的两面 + +位移提供“方向与强度信息”， +失衡提供“回补与再入场坐标”。 +只看位移不看失衡，会陷入追单； +只看失衡不看位移，会陷入逆势抄底。 + +### 四、位移必须与层级权重绑定 + +同样强度的位移，在不同层级含义不同。 +ST 位移更多是执行机会； +IT 位移才是路径重排的主战场； +LT 位移才足以重写阶段叙事。 + +### 五、位移后的“接受/拒绝”决定执行方向 + +位移后若价格持续在新区域组织成交，属于接受； +若快速回收并重返旧区间，属于拒绝。 +两者执行动作应完全不同。 + +### 六、位移不是越大越好，而是越“可延续”越好 + +单次冲击很大但无法延续， +交易价值通常低于“中等强度但可持续承接”的位移。 +可延续性优先于瞬时幅度。 + +### 七、成熟读取是“位移链”而非“位移点” + +高质量位移通常形成完整链条： + +`Liquidity Event -> Displacement -> Imbalance -> Retracement -> Continuation / Failure` + +执行优势来自对整条链的管理，而非某一根 K 线的情绪反应。 + +--- + +## 21.5　结构关系 + +### 一、承接第20章 + +第20章给出 LT/IT/ST 分工， +第21章给出“层级切换的强证据标准”。 + +### 二、通向第22章 + +第22章将正式区分 MSB 与 MSS。 +而 Displacement 正是两者判断中最关键的证据质量来源。 + +### 三、通向第23章 + +第23章的“预判与确认边界”， +将以本章位移证据链作为确认侧核心输入。 + +### 四、与 PD Array 的关系 + +位移决定哪些数组升权： + +1. 位移起点附近 OB 升权。 +2. 位移过程中形成的 FVG 升权。 +3. 位移失败后 Breaker/Mitigation 才有语义空间。 + +### 五、与目标排序关系 + +位移会直接影响主 Draw 与次 Draw 的重排。 +无位移时以原排序为主； +有效位移出现后才允许系统性更新。 + +--- + +## 21.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：流动性处理后位移接管** + +1. 先扫一侧流动性。 +2. 随后出现方向性位移。 +3. 位移留下失衡并在回补后继续。 + +**标准情境B：Consolidation 离开后的有效位移** + +1. 区间累积完成。 +2. 边界被位移离开。 +3. 回补不回收，路径延续成立。 + +**标准情境C：位移失败回收** + +1. 有初始冲击。 +2. 但迅速回到原区间并接受旧价格。 +3. 原位移语义降级为噪音或假突破。 + +**反例情境：把所有大 K 线都当接管** + +1. 无前置事件。 +2. 无结构增益。 +3. 无后续承接。 +结果：高频追单被反复回收。 + +### 二、交易中的真实表现 + +实盘中最难的是“忍住不追第一段”。 +位移发生时情绪最强、FOMO 最大， +但真正高质量位置往往在“位移后回补确认”。 + +--- + +## 21.7　执行意义 + +本章执行统一为“五步模板 + 位移评分”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 先写主 Draw 与主层级 | 无主 Draw 不评位移 | +| 触发 | 标记疑似位移段 | 仅幅度不足以触发执行 | +| 确认 | 检查前置事件、结构增益、失衡留痕、回补承接 | 四项至少三项成立 | +| 执行 | 以回补确认入场，不追位移尾段 | 单笔风险上限可设 0.5%-1% | +| 退出 | 位移失效（回收/穿透）即降级或离场 | 不与失效证据对抗 | + +### 二、位移四项评分（0/1） + +1. 有流动性前置事件。 +2. 有明确结构增益。 +3. 有失衡留痕。 +4. 有回补承接。 + +评分解释： + +1. 4 分：高质量位移，可正常执行。 +2. 3 分：可降仓执行。 +3. ≤2 分：观察优先。 + +### 三、执行前六问 + +1. 这是 ST、IT 还是 LT 位移？ +2. 它改写了哪一层结构？ +3. 它留下了哪些可执行数组？ +4. 回补后的承接是否出现？ +5. 目标排序是否需要重排？ +6. 若位移失效，我的降级动作是什么？ + +--- + +## 21.8　常见误区 + +### 误区一：位移 = 大阳线/大阴线 + +**识别信号：** 只看幅度不看结构。 +**纠偏动作：** 必须加入“改写约束”判定。 + +### 误区二：位移发生即追单 + +**识别信号：** 追在第一段情绪末端。 +**纠偏动作：** 等回补确认链。 + +### 误区三：位移后不看接受/拒绝 + +**识别信号：** 方向不变、计划不变。 +**纠偏动作：** 先判是否接受新价格。 + +### 误区四：ST 位移推翻 LT 叙事 + +**识别信号：** 小级别冲击频繁改大方向。 +**纠偏动作：** 分层赋权，HTF 优先。 + +### 误区五：位移失败后拒绝降级 + +**识别信号：** 回收后继续死扛。 +**纠偏动作：** 回收触发即执行失效预案。 + +### 误区六：只看位移不看失衡 + +**识别信号：** 没有回补坐标，执行随意。 +**纠偏动作：** 位移与 FVG/Void 必须联读。 + +### 误区七：把所有假突破都叫位移失败 + +**识别信号：** 无评分体系，主观命名。 +**纠偏动作：** 用四项评分统一判定。 + +### 误区八：无位移日志 + +**识别信号：** 复盘只记盈亏不记证据。 +**纠偏动作：** 建立“前置-位移-回补-结果”四栏记录。 + +--- + +## 21.9　高阶深化 + +### 一、高阶能力是“识别位移质量曲线” + +不是只有“有/无位移”， +而是能读出位移质量的递增或递减： + +1. 前置事件密度是否增加。 +2. 回补深度是否恶化。 +3. 承接效率是否衰减。 + +### 二、位移与接管的最小充分链 + +可执行层建议使用“最小充分链”： + +`Liquidity Take -> Displacement -> Structural Gain -> Retest Hold` + +任一环节缺失，执行应降级。 + +### 三、位移也是仓位管理工具 + +位移不只用于入场， +也用于加仓与减仓： + +1. 有效位移延续可允许保留扩展仓位。 +2. 位移质量下降应优先收缩风险暴露。 + +### 四、三层位移日志法 + +| 栏位 | 内容 | +| --- | --- | +| 证据栏 | 前置流动性、位移形态、结构增益 | +| 承接栏 | 回补深度、反应质量、时段匹配 | +| 动作栏 | 加仓/减仓/退出规则 | + +### 五、本章工作公式 + +`Displacement Quality = Pre-Liquidity Event + Structural Gain + Imbalance Footprint + Retest Acceptance + Timeframe Weight + Invalidation` + +### 六、与前二十章公式联动 + +第21章把“层级分工”升级为“接管证据标准”， +为第22章 MSB/MSS 判定提供硬门槛。 + +--- + +## 21.10　本章总结 + +1. 位移价值在“改写约束”，不在“波动变大”。 +2. 高质量位移需同时具备前置事件、结构增益、失衡留痕与后续承接。 +3. 位移是接管候选证据，不是自动方向结论。 +4. 位移必须按 LT/IT/ST 分层赋权，避免小级别冲击推翻大级别叙事。 +5. 本章为第22章 MSB/MSS 的“破坏与切换”判定建立证据底盘。 + +--- + +## 21.11　训练清单 + +### 一、观察任务：位移样本库 + +任务：抽取 50 个疑似位移样本，标注前置事件与后续结果。 +达标：至少 40 个样本完成四项评分。 + +### 二、标注任务：位移四项评分 + +任务：为每个样本给出四项评分并分层（LT/IT/ST）。 +达标：评分与结果相关性可复述。 + +### 三、执行任务：仅做“回补承接后”位移单 + +任务：连续 10 个交易日，禁止追位移首段。 +达标：追单比例降至 10% 以下。 + +### 四、复盘任务：位移失败成本统计 + +任务：统计“无承接追单”与“确认后执行”的绩效差异。 +达标：无承接追单占比降至 20% 以下。 + +### 五、标注任务：接受/拒绝分型 + +任务：收集 30 个位移后回补样本，分类为接受或拒绝。 +达标：至少 24 个样本分类准确并可说明理由。 + +### 六、多周期任务：层级冲突演练 + +任务：记录 20 次 ST 强位移与 LT 方向冲突案例，写处理规则。 +达标：形成固定冲突处置模板。 + +### 七、连接任务：进入第22章 + +任务：在已判定有效位移样本上继续问： +这次只是结构被破坏（MSB），还是控制权已切换（MSS）？ +达标：可自然过渡到 MSB/MSS 语言。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Displacement、Structure 与 Liquidity 联动原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第20章（层级分工）及第22章（MSB/MSS）联读。 + + + +# 第22章　Market Structure Break 与 Market Structure Shift + +## 22.1　本章核心问题 + +第21章给出了位移质量标准。 +本章进入结构语言最容易混淆的核心区： + +**什么叫 Break（破坏），什么叫 Shift（切换）；为什么不是每次 Break 都有交易意义。** + +实盘高频错误通常是： + +1. 见破即做，把流动性清理当结构切换。 +2. 只看单次穿越，不看后续是否接管。 +3. 把 ST 破坏误当 LT 切换，导致方向来回翻转。 + +本章主问题是： + +**如何建立 MSB（破坏）与 MSS（切换）的判定边界，并将其写入执行流程。** + +围绕该主问题，回答四个子问题： + +1. MSB 与 MSS 的定义差异。 +2. 结构破坏到结构切换的证据链。 +3. 三层结构（LT/IT/ST）中的判定优先级。 +4. 何时重排叙事，何时仅做路径降级。 + +--- + +## 22.2　一句话结论 + +**MSB 说明“旧路径被破坏”，MSS 才说明“新控制权已接管”；交易应建立在“破坏 + 位移 + 回补承接 + 目标重排”的完整链路上，而非单次穿越。** + +--- + +## 22.3　基础定义 + +### 一、MSB（Market Structure Break） + +MSB 指关键结构位被价格有效破坏， +其核心语义是： + +**旧路径的稳定性下降。** + +MSB 解决的是“旧的还能不能继续”， +不自动解决“新的是否已经成立”。 + +### 二、MSS（Market Structure Shift） + +MSS 指在结构破坏之后，反向控制权通过位移与承接被确认， +其核心语义是： + +**主导权发生转移。** + +MSS 必须包含“切换证据链”，而不是单点命名。 + +### 三、MSB 与 MSS 的最简区别 + +| 项目 | MSB | MSS | +| --- | --- | --- | +| 解决的问题 | 旧路径是否受损 | 新路径是否接管 | +| 证据需求 | 关键位被破坏 | 破坏后有反向位移与承接 | +| 执行含义 | 计划降级/谨慎 | 可启动新叙事执行 | +| 误用风险 | 过早反手 | 过晚错过 | + +### 四、结构切换证据链（建议模板） + +1. 关键 Swing 被破坏（MSB 触发）。 +2. 出现反向 Displacement（接管候选）。 +3. 留下可执行失衡区（FVG/Void）。 +4. 回补后出现承接（MSS 确认）。 +5. 目标排序重排并被价格继续服务。 + +### 五、层级化 MSB/MSS + +1. **ST-MS​​B/MSS：** 执行层节奏变化。 +2. **IT-MS​​B/MSS：** 工作路径重排核心层。 +3. **LT-MS​​B/MSS：** 阶段叙事切换层。 + +不同层级不可混判。 + +### 六、有效破坏与无效刺破 + +有效破坏通常具备： + +1. 非单根 Wick 刺破。 +2. 有后续收盘与延续行为。 +3. 与位移质量和流动性语义一致。 + +无效刺破更像流动性处理或噪音探测。 + +### 七、结构重排的权限边界 + +默认规则： + +1. ST 仅可重排 ST 执行计划。 +2. IT 可重排交易日工作路径。 +3. 只有 LT 级别证据才可重排阶段叙事。 + +--- + +## 22.4　底层逻辑 + +### 一、Break 是“否定旧逻辑”，Shift 是“建立新逻辑” + +两者不是同义词。 +先有否定，再有建立； +只有“建立”成立，执行才可切换主方向。 + +### 二、市场常先给 MSB，再决定是否 MSS + +实盘里大量破坏最终没有发展成切换， +因为缺少后续接管与承接。 +这正是“见破就做”长期绩效不稳的根源。 + +### 三、MSB 的首要任务是风险收缩 + +MSB 出现时，专业动作往往是： + +1. 降杠杆。 +2. 缩目标。 +3. 等确认。 +而不是立刻满仓反手。 + +### 四、MSS 的首要任务是叙事更新 + +MSS 一旦成立， +应同步更新： + +1. 主 Draw/次 Draw。 +2. 优先数组层级。 +3. 持仓风格（延续/修复）。 + +### 五、MSB/MSS 与流动性事件耦合 + +许多高质量 MSS 都发生在“先扫流动性后反向接管”的序列中。 +没有流动性语义的结构切换，质量通常偏低。 + +### 六、MSB/MSS 不是“预测工具”，而是“证据工具” + +它们用于组织证据与动作优先级， +不是用于强化主观确信。 +真正稳定性来自“证据够才做”。 + +### 七、层级一致性决定切换质量 + +ST 出现 MSS 而 IT/LT 不配合时， +更适合短打或观望； +IT 与 LT 同向配合时， +才具备更高持仓质量与扩展空间。 + +--- + +## 22.5　结构关系 + +### 一、承接第21章 + +第21章提供“位移质量”门槛， +第22章把门槛应用到“破坏与切换”判定。 + +### 二、通向第23章 + +第23章将把 MSB/MSS 纳入“预判与确认边界管理”， +回答何时可预判、何时必须等待确认。 + +### 三、与第19-20章关系 + +第19章给结构锚点， +第20章给层级分工， +第22章给切换判定规则。 +三章合起来才是完整结构执行系统。 + +### 四、与 PD Array 的关系 + +MSB/MSS 会直接改变数组优先级： + +1. 旧方向数组降级。 +2. 新方向位移数组升级。 +3. 失效再利用类数组（Breaker/Mitigation）进入主序列。 + +### 五、与目标排序关系 + +结构切换成立后，主 Draw 必须同步更新。 +若结构已变而目标不变，执行必然失真。 + +--- + +## 22.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：MSB 但未 MSS** + +1. 关键位被破坏。 +2. 但反向位移弱、回补后无承接。 +3. 价格回归旧路径或继续震荡。 + +**标准情境B：MSB -> MSS 成立** + +1. 先破坏旧结构。 +2. 再出现高质量反向位移。 +3. 回补承接后继续服务新目标。 + +**标准情境C：多层冲突** + +1. ST 出现切换。 +2. IT 仍未确认。 +3. LT 保持原方向。 +结论：只允许低权重执行或等待。 + +**反例情境：单次刺破即宣判切换** + +1. 无位移质量。 +2. 无承接确认。 +3. 结果常为被动反手亏损。 + +### 二、交易中的真实表现 + +实盘中，MSB 往往伴随高情绪与高噪音。 +最难的不是识别“破坏”， +而是克制“立刻切换”的冲动。 +真正优势来自等待 MSS 证据闭合。 + +--- + +## 22.7　执行意义 + +本章执行统一为“五步模板 + 切换闸门”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 写清当前 LT/IT 主叙事与关键结构位 | 无关键位不判 Break | +| 触发 | 出现有效结构破坏（MSB） | 非 Wick 刺破优先 | +| 确认 | 检查反向位移、失衡留痕、回补承接（MSS） | 三项至少两项成立 | +| 执行 | MSB 阶段降级，MSS 阶段再切换 | 未确认不重仓反手 | +| 退出 | 新切换失效即快速退出并回收风险 | 不与证据对抗 | + +### 二、切换三闸门 + +1. **破坏闸门（MSB）：** 旧逻辑降级。 +2. **接管闸门（MSS）：** 新逻辑生效。 +3. **重排闸门（Reorder）：** 目标与数组同步更新。 + +三闸门未全开，不做完整切换。 + +### 三、执行前六问 + +1. 这是哪一层级的 Break？ +2. 这个 Break 是清理还是破坏？ +3. 反向位移质量是否足够？ +4. 回补承接是否出现？ +5. 新目标排序是否已更新？ +6. 若切换失败，我如何回退？ + +--- + +## 22.8　常见误区 + +### 误区一：MSB = MSS + +**识别信号：** 破坏后立刻反手。 +**纠偏动作：** 必须等待接管链。 + +### 误区二：只看 ST 切换 + +**识别信号：** 小级别反复改大方向。 +**纠偏动作：** 分层赋权，IT/LT 优先。 + +### 误区三：把 Wick 刺破当有效 Break + +**识别信号：** 单次刺破触发交易。 +**纠偏动作：** 结合收盘、延续与位移质量。 + +### 误区四：切换后不更新目标排序 + +**识别信号：** 结构变了仍执行旧目标。 +**纠偏动作：** MSS 成立即重排主次 Draw。 + +### 误区五：MSB 阶段重仓反手 + +**识别信号：** 降级阶段当确认阶段做。 +**纠偏动作：** MSB 先做风险收缩。 + +### 误区六：MSS 失败后拒绝回退 + +**识别信号：** 新叙事被证伪仍死扛。 +**纠偏动作：** 预设回退条件并机械执行。 + +### 误区七：无分层日志 + +**识别信号：** 复盘说不清哪层切换。 +**纠偏动作：** 强制记录 LT/IT/ST 三层判定。 + +### 误区八：标签驱动而非证据驱动 + +**识别信号：** 用名词替代确认链。 +**纠偏动作：** 每次判定必须附证据序列。 + +--- + +## 22.9　高阶深化 + +### 一、高阶能力是“切换概率管理” + +不是追求每次都抓到拐点， +而是把切换分成阶段并匹配不同风险暴露： + +1. MSB 阶段低暴露。 +2. MSS 确认后正常暴露。 +3. 重排后再评估扩展仓位。 + +### 二、结构切换与库存转换 + +MSS 的深层意义是： + +1. 旧方向库存被迫出清。 +2. 新方向库存开始主导。 +这与 Breaker/Mitigation 的订单流再利用逻辑一致。 + +### 三、三层切换日志法 + +| 栏位 | 内容 | +| --- | --- | +| 破坏栏 | 哪个关键位被破坏、属于哪层 | +| 接管栏 | 位移质量、回补承接、数组配合 | +| 动作栏 | 降级/切换/回退规则 | + +### 四、切换质量评分（推荐） + +1. 结构破坏质量。 +2. 位移质量。 +3. 承接质量。 +4. 层级一致性。 +5. 目标重排一致性。 + +总分越高，越接近可持续切换。 + +### 五、本章工作公式 + +`Shift Validity = Break Quality + Displacement Quality + Retest Acceptance + Timeframe Alignment + Draw Reordering + Invalidation` + +### 六、与前二十一章公式联动 + +第22章把“位移证据”升级为“切换判定体系”， +为第23章“预判与确认边界”提供规则化输入。 + +--- + +## 22.10　本章总结 + +1. MSB 与 MSS 必须区分：前者否定旧逻辑，后者建立新逻辑。 +2. 单次穿越不足以切换，需“破坏 + 位移 + 承接”证据链。 +3. 切换判定必须分层，避免 ST 噪音推翻 LT 叙事。 +4. MSB 阶段核心动作是风险收缩，MSS 阶段才允许系统切换。 +5. 本章为第23章“预判与确认”建立统一闸门语言。 + +--- + +## 22.11　训练清单 + +### 一、观察任务：MSB/MSS 样本分拣 + +任务：抽取 50 个“疑似切换”样本，分类为仅 MSB 或 MSS 成立。 +达标：至少 40 个样本分类可复述。 + +### 二、标注任务：证据链记录 + +任务：每个样本记录“破坏-位移-承接-重排”四步。 +达标：四步完整率 90% 以上。 + +### 三、执行任务：分阶段暴露 + +任务：连续 10 个交易日执行“MSB 降仓、MSS 正仓”规则。 +达标：见破重仓行为降至 10% 以下。 + +### 四、复盘任务：见破即做成本统计 + +任务：比较“见破即做”与“确认后做”的绩效差异。 +达标：前者占比降至 20% 以下。 + +### 五、标注任务：层级冲突案例 + +任务：收集 30 个 ST 与 IT/LT 冲突样本，写优先级决策。 +达标：至少 24 个样本处理规则一致。 + +### 六、多周期任务：切换回退演练 + +任务：记录 20 次 MSS 失败案例并写回退动作。 +达标：形成固定回退模板。 + +### 七、连接任务：进入第23章 + +任务：在已分类样本上继续问： +哪些场景可以提前预判，哪些场景必须等确认？ +达标：可自然过渡到 Anticipation/Confirmation 边界管理。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Structure Break / Shift、Liquidity 与 Displacement 联动原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第21章（位移证据）及第23章（预判与确认边界）联读。 + + + +# 第23章　Anticipation 与 Confirmation：从预判到确认 + +## 23.1　本章核心问题 + +第22章解决了 MSB/MSS 的切换判定。 +本章进入执行层最后一道边界管理： + +**什么时候可以预判（Anticipation），什么时候必须等待确认（Confirmation）。** + +多数执行失误并非分析能力不足， +而是边界管理失败： + +1. 该等确认时提前猜向。 +2. 该果断执行时过度犹豫。 +3. 预判仓位与确认仓位混用，风险暴露失控。 + +本章主问题是： + +**如何把“预判-确认”从主观习惯变成规则化流程。** + +围绕该主问题，回答四个子问题： + +1. Anticipation 与 Confirmation 的职责分工。 +2. 两阶段在证据强度、仓位强度、失效处理上的差异。 +3. 如何把前22章证据链接入两阶段执行。 +4. 如何避免“永远提前”或“永远迟到”的两极错误。 + +--- + +## 23.2　一句话结论 + +**Anticipation 的价值在“提前定义条件”，Confirmation 的价值在“证据闭合后执行”；专业执行不是二选一，而是用分阶段风险暴露把“前瞻性”与“确定性”连接起来。** + +--- + +## 23.3　基础定义 + +### 一、Anticipation（预判） + +Anticipation 是基于上游叙事、层级结构与路径条件，对“可能发生的高概率场景”做前置准备。 +它的目标不是提前证明自己正确， +而是提前定义： + +1. 我在等什么。 +2. 什么出现才可执行。 +3. 什么出现我就放弃。 + +### 二、Confirmation（确认） + +Confirmation 是在关键证据链闭合后，正式进入执行阶段。 +确认不是“看起来差不多”， +而是满足预设触发器并通过失效门槛。 + +### 三、两阶段角色分工 + +| 阶段 | 核心任务 | 允许动作 | +| --- | --- | --- | +| Anticipation | 定条件、排优先级、设边界 | 低暴露试探或纯观察 | +| Confirmation | 证据闭合后执行 | 标准仓位执行与持仓管理 | + +### 四、预判不是猜顶猜底 + +预判本质是“条件化计划”，不是“方向赌注”。 +典型表达应是： + +1. 如果先扫下侧并回收，我看上侧目标。 +2. 如果接受在下侧，则下调目标并重排。 + +### 五、确认链的最小组成 + +建议至少包含三项： + +1. 结构证据（MSB/MSS 或关键 Swing 变化）。 +2. 位移证据（Displacement 质量达标）。 +3. 位置证据（回补到 relevant Array 并出现承接）。 + +### 六、仓位分级语义 + +1. **预判仓位：** 低权重、短容错、快退出。 +2. **确认仓位：** 标准权重、可按计划扩展。 + +两者不可混同。 + +### 七、失效语义 + +1. 预判失效：条件未成或被反证，快速取消计划。 +2. 确认失效：已执行后证据反向，按既定止损和降级规则处理。 + +--- + +## 23.4　底层逻辑 + +### 一、预判解决“准备度”，确认解决“可执行性” + +只有预判，没有确认，会过早承担噪音。 +只有确认，没有预判，会错过位置与时机。 +两阶段结合，才能兼顾效率与稳定。 + +### 二、两阶段本质是风险预算管理 + +不是“谁对谁错”， +而是“在不同证据强度下，承担多少风险”。 +证据弱时小暴露，证据强时正常暴露。 + +### 三、确认不是拖延，而是质量过滤 + +很多“慢一步”并非坏事。 +确认阶段的存在，正是为了过滤“看起来像、但不够完整”的机会。 + +### 四、预判阶段最重要的是写反证条件 + +没有反证条件的预判， +最终会变成主观执念。 +真正成熟的预判，必须能被快速证伪。 + +### 五、确认阶段最重要的是一致执行 + +一旦确认链闭合， +就不应继续在“要不要做”上内耗。 +确认后犹豫，等于把前置工作浪费掉。 + +### 六、两阶段要与层级系统绑定 + +1. LT 主要提供预判框架。 +2. IT 主要提供确认上下文。 +3. ST 主要提供执行触发。 + +脱离层级，预判和确认都会漂浮。 + +### 七、最稳定的执行来自“条件树” + +将预判写成条件树，再由确认触发动作： + +`Scenario -> Trigger -> Action -> Invalidation` + +这样可显著降低盘中情绪化切换。 + +--- + +## 23.5　结构关系 + +### 一、承接第22章 + +第22章给出 MSB/MSS 判定， +第23章给出“判定之后怎么下手”的执行边界。 + +### 二、收束第四部分 + +第18-23章形成完整链条： + +1. 状态识别。 +2. 结构分层。 +3. 位移证据。 +4. 破坏与切换。 +5. 预判与确认边界。 + +### 三、通向第五部分 + +第五部分将进入 Narrative 与 Bias 深化。 +第23章提供的是“执行阶段闸门”， +它会成为后续叙事落地的统一接口。 + +### 四、与前12章关系 + +预判依赖前12章的目标排序； +确认依赖第13-22章的位置与结构证据。 +本章把全书前半段真正合流到执行动作。 + +### 五、与风险章节关系 + +第44-45章风控的核心（仓位、止损、分批）， +本质都要建立在本章“两阶段风险暴露”之上。 + +--- + +## 23.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：先预判、后确认的顺势执行** + +1. 预判阶段写明主 Draw 与候选数组。 +2. 盘中出现流动性事件与位移。 +3. 回补承接后确认执行。 + +**标准情境B：预判被证伪，及时取消** + +1. 盘前偏向成立。 +2. 盘中关键反证出现。 +3. 不强行执行，等待下一条件。 + +**标准情境C：确认成立后分层持仓** + +1. ST 触发入场。 +2. IT 路径支持持有。 +3. LT 目标未达前按规则管理。 + +**反例情境：把预判当确认** + +1. 条件未闭合即重仓。 +2. 被噪音触发止损。 +3. 真正确认来时已无纪律与信心。 + +### 二、交易中的真实表现 + +最常见的两极： + +1. **永远提前：** 看到可能性就下单。 +2. **永远等待：** 条件全到还不执行。 + +本章的目的不是让你更激进或更保守， +而是让你在不同证据强度下有一致动作。 + +--- + +## 23.7　执行意义 + +本章执行统一为“五步模板 + 两阶段仓位协议”。 + +### 一、五步模板（条件—触发—确认—执行—退出） + +| 步骤 | 标准 | 量化锚点（示例） | +| --- | --- | --- | +| 条件 | 盘前写 Scenario 与反证条件 | 无反证条件不进入预判 | +| 触发 | 出现关键前置信号（流动性事件/结构破坏） | 仅触发不等于确认 | +| 确认 | 证据链闭合（结构+位移+位置） | 三项至少两项成立 | +| 执行 | 预判仓与确认仓分级执行 | 预判仓位可设确认仓的 1/3-1/2 | +| 退出 | 预判失效快退，确认失效按规则退 | 不混用两类失效处理 | + +### 二、两阶段仓位协议（建议） + +1. **仅预判阶段：** 可零仓观察，或极低权重试探。 +2. **确认阶段：** 才允许标准仓位和分层持有。 +3. **反证出现：** 先清预判暴露，再评估是否切换。 + +### 三、执行前七问 + +1. 我的预判条件写清了吗？ +2. 反证条件写清了吗？ +3. 当前证据属于触发还是确认？ +4. 仓位权重是否匹配证据强度？ +5. 当前执行服务哪个层级目标？ +6. 失效后是取消、降级还是切换？ +7. 我是否在用情绪替代流程？ + +--- + +## 23.8　常见误区 + +### 误区一：预判 = 提前重仓 + +**识别信号：** 条件未闭合已高暴露。 +**纠偏动作：** 预判仓与确认仓严格分级。 + +### 误区二：确认标准随盘中情绪变化 + +**识别信号：** 同类场景判定不一致。 +**纠偏动作：** 盘前固定确认链。 + +### 误区三：预判失效后拒绝取消 + +**识别信号：** 反证出现仍继续寻找理由。 +**纠偏动作：** 反证触发即取消该预判。 + +### 误区四：确认成立后仍不执行 + +**识别信号：** 错失计划内机会。 +**纠偏动作：** 预写“确认即动作”规则。 + +### 误区五：用 ST 触发推翻 LT 框架 + +**识别信号：** 小级别波动反复改大逻辑。 +**纠偏动作：** 层级优先级前置固定。 + +### 误区六：预判与确认止损混用 + +**识别信号：** 同一止损管理两类仓位。 +**纠偏动作：** 两阶段独立失效规则。 + +### 误区七：没有条件树 + +**识别信号：** 盘中只能临场猜测。 +**纠偏动作：** 用 Scenario 条件树管理动作。 + +### 误区八：复盘只看结果不看阶段 + +**识别信号：** 无法复现执行错误来源。 +**纠偏动作：** 复盘按“预判-确认-执行-失效”四栏记录。 + +--- + +## 23.9　高阶深化 + +### 一、高阶能力是“证据强度映射仓位强度” + +真正专业化不是提高主观确信， +而是让风险暴露严格跟随证据质量。 + +### 二、两阶段可与多模型并行 + +可将不同模型放进同一框架： + +1. 预判阶段共用上游叙事与排序。 +2. 确认阶段由各模型触发器竞争。 +3. 统一用失效协议管理风险。 + +### 三、四栏日志法（推荐） + +| 栏位 | 内容 | +| --- | --- | +| 预判栏 | 场景、主次 Draw、反证条件 | +| 确认栏 | 结构/位移/位置证据 | +| 动作栏 | 仓位级别、入场与管理 | +| 结果栏 | 失效类型、改进规则 | + +### 四、阶段化绩效评估 + +建议分开统计： + +1. 预判单胜率与回撤。 +2. 确认单胜率与盈亏比。 +以避免“整体结果掩盖阶段问题”。 + +### 五、本章工作公式 + +`Execution Discipline = Anticipation Clarity + Confirmation Integrity + Position Sizing Alignment + Invalidation Speed + Review Consistency` + +### 六、第四部分总公式收束 + +`Structure Execution Quality = State Identification + Swing Hierarchy + Displacement Evidence + Shift Validation + Anticipation/Confirmation Discipline` + +该公式将直接作为第五部分“叙事与偏见”的执行接口。 + +--- + +## 23.10　本章总结 + +1. 预判与确认不是对立关系，而是阶段分工关系。 +2. 预判负责条件准备，确认负责执行授权。 +3. 仓位强度必须匹配证据强度，避免阶段错配。 +4. 反证条件必须前置，否则预判会演变为执念。 +5. 本章完成第四部分“从结构识别到执行边界”的闭环。 + +--- + +## 23.11　训练清单 + +### 一、观察任务：两阶段样本标注 + +任务：抽取 50 个交易样本，标注“预判触发点”和“确认触发点”。 +达标：至少 40 个样本阶段区分清晰。 + +### 二、标注任务：条件树编写 + +任务：连续 10 个交易日，每天写 2 套 Scenario 条件树。 +达标：100% 包含反证条件与动作分支。 + +### 三、执行任务：分级仓位协议 + +任务：连续 10 个交易日执行“预判低权重、确认标准权重”规则。 +达标：阶段错配仓位降至 10% 以下。 + +### 四、复盘任务：阶段化绩效统计 + +任务：分别统计预判单与确认单的胜率、盈亏比、回撤。 +达标：形成至少 3 条可执行改进规则。 + +### 五、标注任务：反证速度训练 + +任务：收集 30 个预判失效案例，记录反证出现到执行退出的时间。 +达标：平均反证响应速度较上一轮提升 30%。 + +### 六、多周期任务：层级-阶段联动 + +任务：在 20 个样本中同时记录 LT/IT/ST 与预判/确认阶段映射。 +达标：至少 16 个样本映射一致。 + +### 七、连接任务：进入第五部分 + +任务：在已完成阶段化执行样本上继续问： +在不同宏观叙事下，Bias 如何形成并如何稳定传导到日内执行？ +达标：可自然过渡到第24章 Narrative 与 Daily Bias。 + +--- + +## 章末注释 + +[1] 本章依据 ICT 框架中 Anticipatory Skill、确认链与执行纪律原则整理。 +[2] 文中量化锚点仅用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第22章（MSB/MSS）及第24章（Narrative）联读。 + +# 第五部分　叙事与偏见：从大局到交易方向 + +完成前四部分后，你已经具备结构、流动性、数组与接管语言。 +第五部分要解决的是： + +**如何把这些证据收敛成“当下该做哪边”的方向决策。** + +--- + +## 本部分定位 + +本部分不是增加新信号，而是建立方向决策链： + +`Narrative -> Draw -> Daily Bias -> Top-Down -> 宏观/跨市场过滤` + +它的目标是让“方向判断”从主观立场变成可验证流程。 + +--- + +## 六章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第24章 | Narrative 如何组织市场故事与失效边界 | +| 第25章 | Daily Bias 与 Consolidation Hurdles 如何落地日常判断 | +| 第26章 | Market Efficiency Paradigm 如何做状态-工具匹配 | +| 第27章 | Big/Intermediate/Short-Term 三层视角如何分工 | +| 第28章 | Top-Down 如何从 Monthly 下钻到 5M | +| 第29章 | Macro、利率、跨市场、COT、情绪、OI 如何做过滤 | + +--- + +## 学习边界 + +第五部分最容易误学成“观点输出”。 +请固定原则： + +**有叙事，才有方向；有失效，才有执行。** + +没有失效边界的 Bias，不属于交易模型。 + +--- + +## 学完应具备 + +完成第五部分后，你应能： + +1. 用统一链路生成当日偏向，而非凭感觉看多看空。 +2. 区分上层方向判断与下层执行触发。 +3. 在盘中按证据维护或重排叙事。 +4. 用宏观与跨市场做风险加减，而非替代价格证据。 + +--- + +## 与后续章节的连接 + +第六部分将把方向链进一步落入“时间与会话过滤”， +把“做哪边”推进到“在何时做、用多大强度做”。 + +--- + +## 章末注释 + +[1] 本导读用于连接第四部分结构语言与第五部分方向决策链，不替代各章细节定义。 +[2] 建议进入第六部分前，先复核第28章 Top-Down 模板与第29章过滤评分规则。 + + + +# 第24章　Narrative：市场当前在讲什么故事 + +## 24.1　本章核心问题 + +从第1章到第23章，我们一直在用“递送、目标、结构、位移、确认”这些语言观察市场。 +但只要把它们拆开看，执行就会很快退化成“看到什么做什么”。 + +因此本章只解决一个上游问题： + +**在 ICT 语境里，Narrative 到底是什么，它如何把分散信息组织成可执行决策。** + +围绕这个主问题，本章回答四个子问题： + +1. Narrative 的工作定义与边界是什么。 +2. Narrative 与 Draw、Daily Bias 的先后关系是什么。 +3. 一条叙事要具备哪些证据，才算可执行而非可讲述。 +4. 叙事在盘中何时维持、何时降级、何时重排。 + +--- + +## 24.2　一句话结论 + +**Narrative 不是观点，而是“在当前证据下最有解释力的路径假设”；它先决定 Draw，再决定 Bias，再决定执行权限，且必须预先写明失效条件。** + +--- + +## 24.3　基础定义 + +### 一、Narrative（叙事）的工作定义 + +本书定义：Narrative 是对“市场当前递送任务”的结构化描述。 +它至少要回答四件事： + +1. 市场刚刚处理了什么（流动性或失衡）。 +2. 市场更可能优先处理什么（主 Draw）。 +3. 当前位置是否支持这条路径（Range 与 Premium/Discount）。 +4. 何种证据出现时应放弃该叙事（Invalidation）。 + +### 二、Narrative 与 Draw、Bias 的关系 + +执行顺序固定为： + +`Narrative -> Draw -> Daily Bias -> Execution` + +也就是：先有路径语义，再有目标方向，再有执行偏向。 +若顺序倒置（先定 Bias 再补叙事），盘中几乎必然出现频繁换边。 + +### 三、Narrative 的四类证据输入 + +叙事要落地，至少要有四类输入： + +1. 流动性输入：哪一侧已经被处理，哪一侧仍未处理。 +2. 失衡输入：是否存在更高优先级的回补/再平衡任务。 +3. 位置输入：价格处于哪个 Dealing Range 的哪个分区。 +4. 时间输入：当前时段是否支持该路径表达。 + +### 四、Current Working Narrative（当前工作叙事） + +同一时刻可以有多个候选解释，但执行层只能保留一条“当前工作叙事”。 +其余叙事只能作为备选，不可同权并行。 + +### 五、叙事不是“故事化解释” + +故事化解释只要求“事后讲得通”；Narrative 要求“事前做得到”。 +区别在于是否具备： + +1. 前置条件。 +2. 触发条件。 +3. 失效条件。 + +### 六、叙事的层级属性 + +1. HTF Narrative：回答阶段方向与主目标。 +2. MTF Narrative：回答当前路径与中继任务。 +3. LTF Narrative：回答执行窗口与风控细节。 + +层级可以不同步，但必须可映射。 + +### 七、叙事最小书写格式 + +建议固定为： + +1. 单句叙事（当前最可能先做什么）。 +2. 三条证据（流动性、失衡、位置/时间）。 +3. 一条失效（出现什么就取消叙事）。 + +--- + +## 24.4　底层逻辑 + +### 一、Narrative 的核心作用是“统一信息” + +市场信息天然碎片化：高低点、流动性、数组、时段、会话、结构切换。 +Narrative 的价值在于把这些碎片组织成一条可验证路径，避免每个局部信号都抢解释权。 + +### 二、Narrative 不是预测确定性，而是组织概率 + +它不承诺“必到位”，只回答“在当前证据下最该优先服务哪条路径”。 +成熟交易不是追求永远正确，而是让“错时可退、对时可拿”。 + +### 三、可证伪性决定叙事质量 + +没有失效条件的叙事，本质上是立场而非模型。 +叙事质量高低，不看目标写多远，而看失效写得是否具体、是否可执行。 + +### 四、叙事是动态维护，不是盘前口号 + +周线给方向假设，日线给24小时反馈，日内给执行证据。 +当反馈连续背离时，应降级或重排；当反馈持续同向时，才允许提高执行强度。 + +### 五、叙事决定“权限”，而非只决定“方向” + +同一技术形态，在叙事支持与叙事冲突环境下，执行权限应不同： +包括是否入场、仓位大小、持仓时长、目标远近。 + +### 六、叙事退化的典型路径 + +最常见的失败链：先有看法、再找术语佐证、证据变化也不更新。 +结果通常是两种极端：频繁反手，或长期硬扛。 + +### 七、成熟标准是“稳定但不僵化” + +无失效证据前保持叙事一致；失效证据出现后快速重排。 +这条纪律比“临盘聪明”更能保护长期曲线。 + +--- + +## 24.5　结构关系 + +### 一、承接第23章 + +第23章解决“预判与确认边界”；本章解决“预判内容从哪里来”。 + +### 二、通向第25章 + +第25章会把叙事收敛为 Daily Bias 与 Consolidation Hurdles 的日常流程。 + +### 三、通向第26章 + +第26章会把叙事进一步转成“状态-工具-模型”的范式选择器。 + +### 四、与第12章关系 + +第12章给了“目标排序”，本章给了“排序依据”。 +没有叙事，排序会漂移；有叙事，排序才可维护。 + +### 五、与后续模型关系 + +后续任何执行模型都应先回答：这笔交易服务哪条叙事、哪一段路径。 +答不出这两句，模型应降级。 + +--- + +## 24.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：叙事先定“先处理哪类任务”** + +1. 若上游任务是“先回补失衡”，日内回撤更应被解释为路径内修复。 +2. 若上游任务是“先处理外部流动性”，则内部波动权重应下调。 +3. 低周期触发只负责“怎么到达”，不负责改写“去哪”。 + +**标准情境B：叙事稳定时，执行稳定** + +1. 目标排序不频繁改写。 +2. 仓位强度与持有风格连续一致。 +3. 盘中噪音对决策影响显著降低。 + +**标准情境C：叙事失效后快速重排** + +1. 关键前提被结构性反证。 +2. 旧叙事降级，模型权限收回。 +3. 新叙事接管并重建执行计划。 + +**反例情境：复盘会讲、盘中不会做** + +1. 盘前无叙事字段。 +2. 盘中随波动改口。 +3. 盘后才“讲得通”。 + +### 二、交易中的真实表现 + +实盘中最有破坏力的问题不是单笔看错， +而是长期缺少叙事字段，导致每次错误都无法归因到同一个流程节点。 +一旦把叙事写进计划和日志，系统稳定性会明显提升。 + +--- + +## 24.7　执行意义 + +本章执行统一为“叙事卡片 + 五步流程”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +| 步骤 | 执行标准 | +| --- | --- | +| 条件 | 盘前写出单句 Narrative、主次 Draw、失效条件 | +| 触发 | 仅在叙事映射到具体路径段时等待触发 | +| 确认 | 盘中证据持续支持叙事，且未触发失效 | +| 执行 | 每笔单必须标注“服务叙事哪一段” | +| 退出 | 失效触发后停止原模型并重排，不与反证对抗 | + +### 二、叙事卡片（建议字段） + +1. 今日工作叙事（1句）。 +2. 主 Draw / 次 Draw。 +3. 支持证据（3条内）。 +4. 失效触发器（客观）。 +5. 失效后动作（降级/重排）。 + +### 三、执行前六问 + +1. 这是路径假设还是观点表达。 +2. 主次目标是否已排序。 +3. 当前证据在支持还是削弱叙事。 +4. 这笔单服务叙事哪一段。 +5. 失效条件是否前置写清。 +6. 失效后动作是否可机械执行。 + +--- + +## 24.8　常见误区 + +### 误区一：Narrative 等于“我觉得会涨/跌” + +**识别信号：** 叙事无法拆成证据。 +**纠偏动作：** 强制使用“单句+三证据+一失效”。 + +### 误区二：先有 Bias 再找 Narrative + +**识别信号：** 先定结论，再补理由。 +**纠偏动作：** 恢复 `Narrative -> Draw -> Bias` 顺序。 + +### 误区三：盘前写叙事，盘中不维护 + +**识别信号：** 关键证据变化后仍机械坚持。 +**纠偏动作：** 在会话切换或关键结构点强制重评。 + +### 误区四：叙事与执行断裂 + +**识别信号：** 计划完整但下单随意。 +**纠偏动作：** 每笔交易必须标注叙事映射段。 + +### 误区五：只有目标，没有失效 + +**识别信号：** 目标越写越远，止损越放越宽。 +**纠偏动作：** 失效优先于目标。 + +### 误区六：多条叙事同权并行 + +**识别信号：** 同时能解释多空。 +**纠偏动作：** 指定 Current Working Narrative，其余降级为备选。 + +### 误区七：失效后做“证明单” + +**识别信号：** 被证伪后加码。 +**纠偏动作：** 失效触发即切断原模型权限。 + +### 误区八：复盘不记录叙事字段 + +**识别信号：** 只能复盘结果，不能复盘逻辑。 +**纠偏动作：** 复盘固定四栏：叙事-证据-动作-结果。 + +--- + +## 24.9　高阶深化 + +### 一、高阶叙事追求“最少解释、最大约束” + +好的叙事不是更复杂，而是更可执行：一句话能定义路径，几条证据能维护路径，一条失效能切断错误路径。 + +### 二、叙事强度分级 + +1. 强叙事：证据同向且路径清晰。 +2. 中叙事：证据部分同向，需确认后执行。 +3. 弱叙事：证据冲突明显，降频或观望。 + +### 三、叙事与模型权限联动 + +1. 强叙事可用延续模型与扩展目标。 +2. 中叙事优先确认型模型。 +3. 弱叙事以防守型模型或空仓为主。 + +### 四、叙事维护日志（建议） + +| 栏位 | 内容 | +| --- | --- | +| 叙事栏 | 当前工作叙事与主次目标 | +| 证据栏 | 流动性、失衡、位置、时间 | +| 动作栏 | 模型权限、仓位强度、持仓策略 | +| 结果栏 | 失效类型、重排质量、改进规则 | + +### 五、本章工作公式 + +`Narrative Quality = Path Clarity + Evidence Coherence + Draw Stability + Time Alignment + Invalidation Discipline` + +### 六、与前文联动 + +本章把前四部分的结构、流动性与确认语言，统一接入“叙事引擎”， +为第25章 Daily Bias 的日常化执行提供上游输入。 + +--- + +## 24.10　本章总结 + +1. Narrative 是路径假设，不是主观看法。 +2. Narrative 决定 Draw，Draw 决定 Bias，Bias 决定执行权限。 +3. 高质量叙事必须可验证、可失效、可重排。 +4. 叙事字段写进执行日志后，系统稳定性会显著提升。 +5. 本章是第五部分的上游总开关，为第25章日常偏见流程打底。 + +--- + +## 24.11　训练清单 + +### 一、观察任务：叙事卡片训练 + +任务：连续30个交易日，每日写“单句叙事 + 三证据 + 一失效”。 +达标：至少24天逻辑一致、可复述。 + +### 二、标注任务：叙事支持率统计 + +任务：记录每个交易日叙事是否被盘中证据持续支持。 +达标：100%样本有支持/反证记录。 + +### 三、执行任务：叙事映射下单 + +任务：每笔交易必须标注“服务叙事哪一段”。 +达标：无映射下单比例降至10%以下。 + +### 四、复盘任务：失效后动作一致性 + +任务：统计叙事失效后是否按预案降级或重排。 +达标：失效后违规继续执行比例降至20%以下。 + +### 五、标注任务：冲突叙事管理 + +任务：收集20个叙事冲突日，记录如何指定 Working Narrative。 +达标：至少16个样本处理规则一致。 + +### 六、多周期任务：叙事映射链 + +任务：在20个样本中同时写 HTF/MTF/LTF 叙事映射关系。 +达标：至少16个样本映射完整。 + +### 七、连接任务：进入第25章 + +任务：在已完成叙事卡片样本上继续问： +今天 Daily Bias 应如何分级？哪些 Consolidation Hurdles 触发后必须降级？ +达标：可自然过渡到第25章执行流程。 + +--- + +## 章末注释 + +[1] 本章术语与流程基于两份PDF中 Narrative、Draw、Daily Bias 与流动性/失衡优先原则整理。 +[2] 文中模板用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第23章（预判与确认边界）及第25章（Daily Bias）联读。 + + + +# 第25章　Daily Bias 与 Consolidation Hurdles + +## 25.1　本章核心问题 + +第24章建立了上游叙事引擎，本章把它落地到日常执行最关键的一步： + +**今天到底该偏多、偏空，还是中性；以及在什么条件下必须主动降级。** + +多数交易者在 Daily Bias 上的长期失真，不是“方向常错”，而是“强度常错”： + +1. Bias 还没稳定就重仓表达。 +2. 价格回到 Equilibrium 仍按趋势日打法执行。 +3. 明明处于整理阻碍阶段，却持续用突破思维追单。 + +因此本章主问题是： + +**如何把 Daily Bias 从主观结论升级为流程化决策，并把 Consolidation Hurdles 写成可执行的降级规则。** + +围绕该主问题，本章回答四个子问题： + +1. Daily Bias 的标准来源与构建顺序。 +2. Bias 与 Premium/Discount/Equilibrium 的耦合关系。 +3. Consolidation Hurdles 的识别与执行含义。 +4. Bias 错误与 Bias 无效的差异化处置。 + +--- + +## 25.2　一句话结论 + +**Daily Bias 必须由 Narrative 与 Draw 推导，再由 Dealing Range 位置校准执行强度；当价格位于 Equilibrium 或进入明显整理阻碍阶段时，Bias 可信度下降，应切换为低暴露、快验证、快兑现模式。** + +--- + +## 25.3　基础定义 + +### 一、Daily Bias 的定义 + +Daily Bias 不是“今天看涨/看跌”的口号， +而是叙事在日内层面的执行翻译：它同时包含方向与强度两个维度。 + +### 二、构建顺序 + +标准顺序固定为： + +`Narrative -> Draw -> Daily Bias` + +含义是：先明确路径，再明确目标，再决定当天执行偏向。 +若先定 Bias 再找理由，盘中通常会出现频繁换边。 + +### 三、3B 流程（Bias 构建主轴） + +1. B1：当前 Framework 是什么。 +2. B2：下一优先 Draw 在哪里。 +3. B3：当前位于 Premium、Discount 还是 Equilibrium。 + +3B 的价值是把“方向判断”与“位置判断”绑定，避免方向对而位置差。 + +### 四、Consolidation Hurdles（整理阻碍） + +本书定义：Consolidation Hurdles 是一组降低方向表达效率的环境条件。 +常见表现是中轴附近反复拉扯、边界假突破增多、R 扩展空间被压缩。 + +### 五、Bias 的双维度 + +高质量 Bias 至少包含： + +1. 方向维度：偏多、偏空、中性。 +2. 强度维度：强、中、弱（对应仓位与持仓风格）。 + +只有方向没有强度，执行会长期失真。 + +### 六、Bias 错误与 Bias 无效 + +1. Bias 错误：叙事被反证，需重排方向。 +2. Bias 无效：方向未必错，但当前环境不支持高强度表达（常见于 Equilibrium 与整理段）。 + +前者改向，后者降级，这两者不能混用。 + +### 七、Bias 最小输出模板 + +建议每日固定四行： + +1. 今日 Bias（方向+强度）。 +2. 主 Draw / 次 Draw。 +3. 不做条件（Consolidation Hurdles 触发器）。 +4. 失效后动作（降级或重排）。 + +--- + +## 25.4　底层逻辑 + +### 一、Daily Bias 是上游叙事的日内翻译器 + +周线与日线提供方向与目标，日内执行负责“如何到达”。 +Bias 的职责正是把这条上游链路翻译成当天可执行强度。 + +### 二、Bias 稳定性取决于 Draw 清晰度 + +当 Draw 清晰且路径证据同向，Bias 更容易稳定。 +当 Draw 冲突、位置中性、时段噪音高，Bias 应主动降级，而不是强做。 + +### 三、Equilibrium 阶段的核心风险是“效率下降” + +在中轴附近，最常见问题不是方向完全错误，而是： + +1. 止损边界不清。 +2. 目标空间不足。 +3. 回撤频率上升。 +4. 单笔扩展下降。 + +这就是为什么“方向对但赚不到”的情况大多发生在中轴区强做。 + +### 四、Consolidation Hurdles 是风格切换信号 + +整理阻碍出现后，成熟动作不是立即改向， +而是先切执行风格：降仓、缩目标、缩时长、提高确认阈值。 + +### 五、Bias 管理先于盈利管理 + +若 Bias 的失效边界不清，交易者会在错误环境里不断加码证明自己。 +把“何时不再有效”写在计划最前面，通常比多写几个目标更有价值。 + +### 六、Bias 是维护过程，不是静态标签 + +盘前给初始 Bias，盘中做证据维护，盘后做误差归因。 +三步缺一，Bias 会退化为情绪判断。 + +### 七、成熟优势来自“方向与强度分开管理” + +方向判断可以正确，但强度管理仍可能失败。 +长期稳定来自两条线同时正确：方向不漂移、强度不越界。 + +--- + +## 25.5　结构关系 + +### 一、承接第24章 + +第24章回答“市场在讲什么故事”，第25章回答“这个故事今天该以多大强度执行”。 + +### 二、通向第26章 + +第26章将进一步回答：在当前效率状态下，该调用哪类模型，禁用哪类模型。 + +### 三、与第5章关系 + +第5章给出位置优劣语言，本章把位置正式接入 Bias 强度决策。 + +### 四、与第12章关系 + +第12章给目标排序，本章给“是否值得高强度服务该排序”的闸门。 + +### 五、与后续模型关系 + +第35章以后所有模型章节的仓位强弱、持有时长、兑现节奏，都应先服从本章 Bias 分级。 + +--- + +## 25.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Bias 稳定日** + +1. 上游叙事清晰。 +2. 主 Draw 与位置同向。 +3. 会话节奏支持路径表达。 +结果：执行一致性高，反手次数少。 + +**标准情境B：Bias 过渡日** + +1. 方向仍可表达。 +2. 但位置不优或时段配合不足。 +结果：应降仓、缩目标、等待更清晰确认。 + +**标准情境C：Consolidation Hurdles 日** + +1. 价格围绕中轴反复摆动。 +2. 假突破增多。 +3. 延续效率下降。 +结果：应转防守模板或观望。 + +**反例情境：方向正确但强度错误** + +1. 在低优势阶段持续高暴露。 +2. 盈利单回吐、止损频率上升。 +3. 最终表现为“看对但做坏”。 + +### 二、交易中的真实表现 + +实盘里最容易被忽略的是： +Bias 错误并不可怕，Bias 无效时硬做才最伤账户。 +本章的核心价值就是提前识别“今天是否值得打重”。 + +--- + +## 25.7　执行意义 + +本章执行统一为“Bias 分级 + 五步流程”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +| 步骤 | 执行标准 | +| --- | --- | +| 条件 | 按3B写出今日 Bias（方向+强度） | +| 触发 | 标注主 Draw / 次 Draw 与阻碍触发器 | +| 确认 | 盘中证据持续支持 Bias，且未进入无效环境 | +| 执行 | 强Bias 用标准模板；弱Bias 用防守模板 | +| 退出 | Bias 失效则重排；Bias 无效则降级或观望 | + +### 二、Bias 强度三级（建议） + +1. 强Bias：叙事、目标、位置、时段高度一致。 +2. 中Bias：部分一致，需确认后执行。 +3. 弱Bias：整理阻碍明显，仅轻仓试探或观望。 + +### 三、执行前六问 + +1. 今天的方向与强度分别是什么。 +2. 主 Draw 与次 Draw 是否已排序。 +3. 当前位置在 Premium、Discount 还是 Equilibrium。 +4. 是否触发 Consolidation Hurdles。 +5. 这是 Bias 错误还是 Bias 无效。 +6. 降级与重排动作是否前置写明。 + +--- + +## 25.8　常见误区 + +### 误区一：Daily Bias 等于固定多空观点 + +**识别信号：** 盘中证据变化后仍机械坚持。 +**纠偏动作：** Bias 必须可维护、可更新、可失效。 + +### 误区二：忽略 B3（位置） + +**识别信号：** 方向常对、入场常差。 +**纠偏动作：** 每日 Bias 必写位置分区。 + +### 误区三：在 Equilibrium 仍追求趋势日收益 + +**识别信号：** 盈利反复回吐、交易密度上升。 +**纠偏动作：** 转短兑现、防守执行。 + +### 误区四：忽视整理阻碍 + +**识别信号：** 整理阶段持续执行突破模板。 +**纠偏动作：** 把阻碍条件写入盘前禁做清单。 + +### 误区五：Bias 无效时仍高暴露 + +**识别信号：** 弱环境重仓表达。 +**纠偏动作：** 证据弱则风险弱，强制绑定仓位。 + +### 误区六：混淆“失效”与“无效” + +**识别信号：** 两种情况使用同一处置动作。 +**纠偏动作：** 失效重排方向，无效仅降级强度。 + +### 误区七：无 Bias 日志 + +**识别信号：** 复盘无法区分方向误差与强度误差。 +**纠偏动作：** 复盘固定分“方向评分”与“强度评分”。 + +### 误区八：无触发器地频繁改 Bias + +**识别信号：** 每次波动都改观点。 +**纠偏动作：** 仅允许客观触发器驱动 Bias 更新。 + +--- + +## 25.9　高阶深化 + +### 一、高阶 Bias 管理本质是“强度管理” + +长期稳定并不要求每天都猜对方向， +而要求在高质量环境敢于表达、在低质量环境主动收缩。 + +### 二、Bias 与模型权限映射 + +1. 强Bias：允许延续模型与扩展持仓。 +2. 中Bias：优先确认型模型。 +3. 弱Bias：防守模型或空仓。 + +### 三、双评分框架（建议） + +1. 方向评分：Narrative 与 Draw 的一致度。 +2. 强度评分：位置、时段、效率支持度。 + +双评分能显著降低“看对方向但交易结果差”的问题。 + +### 四、Bias 日志法 + +| 栏位 | 内容 | +| --- | --- | +| 框架栏 | 3B结果、主次目标 | +| 环境栏 | 位置、时段、阻碍条件 | +| 动作栏 | 仓位强度、模型权限 | +| 结果栏 | 方向误差/强度误差归因 | + +### 五、本章工作公式 + +`Daily Bias Quality = Narrative Integrity + Draw Clarity + Location Advantage + Session Support - Consolidation Friction + Invalidation Discipline` + +### 六、与前文联动 + +本章把叙事引擎转成每日执行参数， +为第26章“范式匹配与模型切换”提供稳定输入。 + +--- + +## 25.10　本章总结 + +1. Daily Bias 是叙事的日内执行翻译，不是主观口号。 +2. 3B 是 Bias 构建的标准路径。 +3. Bias 必须同时包含方向维度与强度维度。 +4. Consolidation Hurdles 出现时，应主动降级执行强度。 +5. 本章把“看法”转成“可执行偏见”，为第26章范式章节打底。 + +--- + +## 25.11　训练清单 + +### 一、观察任务：3B 连续标注 + +任务：连续30个交易日按3B写 Daily Bias。 +达标：至少24天流程完整且可复述。 + +### 二、标注任务：Bias 强度分级 + +任务：每日将 Bias 分为强/中/弱并写明依据。 +达标：100%样本有强度标注。 + +### 三、执行任务：强度绑定仓位 + +任务：连续10个交易日执行“弱Bias 不重仓”。 +达标：弱Bias高暴露行为降至10%以下。 + +### 四、复盘任务：方向错 vs 强度错 + +任务：对近30笔交易分类“方向误差/强度误差”。 +达标：形成至少3条可执行纠偏规则。 + +### 五、标注任务：整理阻碍样本库 + +任务：收集30个 Consolidation Hurdles 样本并记录降级动作。 +达标：至少24个样本规则一致。 + +### 六、多周期任务：Bias 传导检查 + +任务：在20个样本中检查 HTF 叙事到 LTF 执行是否一致。 +达标：至少16个样本传导链完整。 + +### 七、连接任务：进入第26章 + +任务：在已分级 Bias 样本上继续问： +当前效率状态下，哪些模型应启用，哪些模型应禁用。 +达标：可自然过渡到 Market Efficiency Paradigm。 + +--- + +## 章末注释 + +[1] 本章术语与流程基于两份PDF中 Narrative、Draw、Daily Bias、3B流程与 Equilibrium/Consolidation 语义整理。 +[2] 文中模板用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第24章（Narrative）及第26章（Market Efficiency Paradigm）联读。 + + + +# 第26章　Market Efficiency Paradigm（补充） + +## 26.1　本章核心问题 + +第25章解决了“今天偏哪边、强度多大”，但执行层仍有一个更深的失真来源： + +**模型错配。** + +典型表现是： + +1. Consolidation 里按 Expansion 模型追单。 +2. Reversal 早期仍按延续模型加仓。 +3. 状态不可辨识时仍强行下单。 + +这些问题往往不是方向判断失败，而是“环境-工具-模型”匹配失败。 +因此本章主问题是： + +**如何把 Context/Framework 与 Reference Point 的配对规则，升级为可执行的 Market Efficiency Paradigm（MEP）。** + +围绕该主问题，本章回答四个子问题： + +1. MEP 的工作定义与边界。 +2. 状态-工具-模型的配对关系。 +3. 范式切换触发器与禁做条件。 +4. 如何把范式匹配写入日常执行纪律。 + +--- + +## 26.2　一句话结论 + +**MEP 的核心不是预测方向，而是先识别当前效率状态，再匹配对应工具与模型；当状态不可辨识或处于低效整理阶段时，等待本身就是被授权的高质量决策。** + +--- + +## 26.3　基础定义 + +### 一、什么是 MEP + +本书定义：MEP 是“基于当前价格效率状态，动态选择工具与执行模型”的规则系统。 +它不回答“下一根K线涨跌”，它回答“现在该用哪种打法、该禁用哪种打法”。 + +### 二、MEP 的三层对象 + +1. 状态对象：Expansion、Retracement、Reversal、Consolidation。 +2. 工具对象：OB、FVG/Imbalance/Void、Liquidity Pool、Equilibrium。 +3. 模型对象：延续、回补、切换、防守/等待。 + +### 三、状态-参考点基础配对 + +| 状态 | 参考点优先 | 模型倾向 | +| --- | --- | --- | +| Expansion | Order Block | 延续表达 | +| Retracement | FVG / Imbalance / Void | 回补承接 | +| Reversal | Liquidity Pool / Stop Run | 切换确认 | +| Consolidation | Equilibrium | 防守或等待 | + +这张表不是口诀，而是默认优先级：环境先行，工具后置。 + +### 四、效率标签 + +建议将效率简化为三档： + +1. 高效：路径清晰、位移有效、承接顺畅。 +2. 中效：路径可读但噪音偏高。 +3. 低效：区间拉扯、假突破频发、延续困难。 + +效率标签直接决定仓位与模型权限。 + +### 五、不可辨识状态 + +当状态与效率无法稳定归类时，进入“不可辨识”标签： + +1. 禁止新方向重仓。 +2. 降频等待证据展开。 +3. 优先维护已有仓位而非新增风险。 + +### 六、Paradigm Switch（范式切换） + +范式切换不是“临场改主意”，而是满足以下条件后才发生： + +1. 状态发生实质演化。 +2. 效率标签显著变化。 +3. 工具与模型权限同步更新。 + +只换工具不换风险，或只换风险不换模型，都属于半切换。 + +### 七、MEP 最小输出模板 + +建议每日输出五项： + +1. 当前状态。 +2. 当前效率等级。 +3. 当前优先工具。 +4. 当前允许模型。 +5. 当前切换触发器。 + +--- + +## 26.4　底层逻辑 + +### 一、MEP 的价值是减少“错配成本” + +市场并非每天都授权同一打法。 +MEP 的价值不在增加信号，而在减少“错误环境中的正确动作”。 + +### 二、范式决定执行风格，而非方向预测 + +同样是看多： + +1. 高效阶段可做延续模型。 +2. 中效阶段应提高确认阈值。 +3. 低效阶段应主动降级。 + +方向可以不变，风格必须可变。 + +### 三、状态演化是切换主触发器 + +常见演化链： + +`Consolidation -> Expansion -> Retracement -> (Continuation / Reversal)` + +每个节点都可能触发模型权限变化。 +忽略节点，系统会僵化。 + +### 四、HTF 约束是范式稳定器 + +低周期范式若长期对抗高周期叙事， +往往会退化为噪音追逐。 +因此默认优先级应是 HTF 授权、LTF 执行。 + +### 五、等待是 MEP 的正式动作 + +等待并非空白动作，而是： + +1. 保护资本。 +2. 保护注意力。 +3. 等待边际回归。 + +在不可辨识状态下，等待通常优于“为了做而做”。 + +### 六、错配的典型链条 + +1. 状态识别模糊。 +2. 工具调用错配。 +3. 模型强度过载。 +4. 回撤在低质量时段集中放大。 + +### 七、成熟优势是“同范式下的一致动作” + +长期绩效更依赖流程一致性，而非单笔灵感。 +MEP 的作用，正是把一致性制度化。 + +--- + +## 26.5　结构关系 + +### 一、承接第25章 + +第25章回答“今天偏哪边、强度多大”，第26章回答“今天该用哪种模型”。 + +### 二、通向第27章 + +第27章将把 MEP 放入 Big Picture / Intermediate / Short-Term 三层权限系统。 + +### 三、与第18章关系 + +第18章给四状态语法，第26章把四状态升级为“模型切换中枢”。 + +### 四、与第3章关系 + +第3章给 Context/Reference 配对，第26章把配对规则流程化、纪律化、仓位化。 + +### 五、与后续模型章节关系 + +第35章以后所有模型都应受 MEP 管理：何时启用、何时降级、何时禁用。 + +--- + +## 26.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：Consolidation -> Expansion 切换** + +1. 区间累积完成。 +2. 出现有效位移离开均衡。 +3. 模型由等待切到延续。 + +**标准情境B：Expansion -> Retracement 切换** + +1. 先有推进。 +2. 后有失衡回补。 +3. 模型由追动能切到回补承接。 + +**标准情境C：状态不可辨识** + +1. 路径冲突高。 +2. 假信号密集。 +3. 模型降级为防守或空仓。 + +**反例情境：全天坚持单一模型** + +1. 市场已切换状态。 +2. 执行仍按旧模板。 +3. 结果表现为“有触发、无边际”。 + +### 二、交易中的真实表现 + +实盘里最常见的问题不是“不会找入场”， +而是“没判断今天是否被当前环境授权”。 +MEP 的核心，就是把授权前置。 + +--- + +## 26.7　执行意义 + +本章执行统一为“范式仪表板 + 五步流程”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +| 步骤 | 执行标准 | +| --- | --- | +| 条件 | 盘前完成状态标签与效率标签 | +| 触发 | 按标签调用对应工具与模型 | +| 确认 | 检查与 Bias、Draw、位置是否同向 | +| 执行 | 仅执行范式授权模型 | +| 退出 | 状态/效率切换时同步降级、切模或离场 | + +### 二、范式仪表板（建议） + +1. 状态栏：当前主状态与层级。 +2. 工具栏：当前优先参考点。 +3. 模型栏：当前允许打法。 +4. 风险栏：仓位强度与持有上限。 +5. 切换栏：触发器与动作。 + +### 三、执行前六问 + +1. 当前状态与效率是否清晰。 +2. 当前模型是否与状态匹配。 +3. 当前工具是否与模型匹配。 +4. 当前 Bias 是否支持该模型强度。 +5. 是否进入不可辨识环境。 +6. 若切换发生，动作是否预写。 + +--- + +## 26.8　常见误区 + +### 误区一：MEP 只是理论，不影响下单 + +**识别信号：** 工具与模型切换靠情绪。 +**纠偏动作：** 盘前必须输出“状态+效率+模型权限”。 + +### 误区二：状态不清也要做 + +**识别信号：** 不可辨识环境里连续试单。 +**纠偏动作：** 执行“不可辨识即降级”。 + +### 误区三：忽略切换节点 + +**识别信号：** 市场状态变了，打法不变。 +**纠偏动作：** 用状态演化节点驱动切换。 + +### 误区四：低周期范式脱离高周期 + +**识别信号：** LTF 打法长期对抗 HTF。 +**纠偏动作：** HTF 定权限，LTF 定触发。 + +### 误区五：只切工具不切风险 + +**识别信号：** 模型变了，仓位不变。 +**纠偏动作：** 范式切换必须联动风险参数。 + +### 误区六：把等待视为浪费 + +**识别信号：** 无边际环境也强行开仓。 +**纠偏动作：** 把等待写成正式动作选项。 + +### 误区七：模型过多、范式过少 + +**识别信号：** 会很多模板，但不知道何时用。 +**纠偏动作：** 先做范式分类，再做模型调用。 + +### 误区八：复盘不记录错配类型 + +**识别信号：** 只记亏损，不记错配。 +**纠偏动作：** 复盘强制分类状态错配/工具错配/模型错配。 + +--- + +## 26.9　高阶深化 + +### 一、高阶 MEP 是“授权系统管理” + +成熟执行并非拥有更多模型， +而是知道在何种状态授权哪些模型，并在状态变化时及时撤销授权。 + +### 二、范式一致性优先于单笔最优点 + +长期收益更依赖“同范式内重复正确动作”， +而非每笔都追求最漂亮入场。 + +### 三、三栏范式日志法 + +| 栏位 | 内容 | +| --- | --- | +| 识别栏 | 状态、效率、层级归属 | +| 匹配栏 | 工具选择、模型选择、风险权限 | +| 结果栏 | 错配类型、切换质量、改进规则 | + +### 四、范式质量评分（建议） + +1. 状态清晰度。 +2. 工具配对度。 +3. 模型匹配度。 +4. 风险联动度。 +5. 切换一致性。 + +### 五、本章工作公式 + +`Paradigm Fit = State Clarity + Reference Match + Model Alignment + Risk Synchronization + Switch Discipline` + +### 六、与前文联动 + +本章把 Narrative 与 Daily Bias 进一步升级为“模型授权中枢”， +为第27章多层视角分工提供方法底盘。 + +--- + +## 26.10　本章总结 + +1. MEP 是状态到工具、工具到模型的配对系统。 +2. 先识别状态与效率，再选择打法与强度。 +3. 状态不可辨识时，等待是被授权动作。 +4. 范式切换应由证据驱动，而非情绪驱动。 +5. 本章为第27章三层视角与后续模型化执行提供中枢规则。 + +--- + +## 26.11　训练清单 + +### 一、观察任务：状态与效率打标 + +任务：连续30个交易日为每个时段打状态与效率标签。 +达标：至少24天标签可复述且一致。 + +### 二、标注任务：范式仪表板 + +任务：每日输出“状态-工具-模型-风险-切换”五栏。 +达标：100%样本记录完整。 + +### 三、执行任务：不可辨识禁做 + +任务：连续10个交易日执行“不可辨识环境不开新仓”。 +达标：违规开仓降至10%以下。 + +### 四、复盘任务：错配交易统计 + +任务：分类统计状态错配、工具错配、模型错配的绩效差异。 +达标：形成至少3条可执行纠偏规则。 + +### 五、标注任务：范式切换样本库 + +任务：收集30个范式切换样本，记录触发器与执行动作。 +达标：至少24个样本切换链完整。 + +### 六、多周期任务：HTF 授权检查 + +任务：在20个样本中验证 LTF 模型是否获得 HTF 授权。 +达标：至少16个样本授权链清晰。 + +### 七、连接任务：进入第27章 + +任务：在已完成范式管理样本上继续问： +Big Picture、Intermediate、Short-Term 三层如何分工，才能避免上下层互相越权。 +达标：可自然过渡到第27章。 + +--- + +## 章末注释 + +[1] 本章术语与流程基于两份PDF中 Context/Framework 与 Reference Point 配对、状态演化与执行纪律原则整理。 +[2] 文中模板用于执行一致性训练，不构成收益承诺；参数需按品种与账户约束校准。 +[3] 建议本章与第25章（Daily Bias）及第27章（三层视角）联读。 + + + +# 第27章　Big Picture、Intermediate、Short-Term Perspective + +## 27.1　本章核心问题 + +到第26章为止，我们已经建立了叙事、偏见、范式与执行规则。 +但在真实交易中，很多系统并不是因为“不会分析”而失效，而是因为“分析层级混用”： + +1. 把5分钟级别的一次反向波动，当成日线级别叙事改写； +2. 把高周期方向当成万能理由，忽略中短周期已经出现的失效迹象； +3. 把方向判断、路径管理、入场触发放在同一层处理，导致计划在盘中频繁漂移。 + +因此，本章要解决的主问题是： + +**如何把 Big Picture（大局）、Intermediate（中局）、Short-Term（短局）三层视角明确分工，并形成可执行的层级协作系统。** + +围绕这一主问题，本章回答四个子问题： + +1. 三层视角分别负责什么。 +2. 上下层信息应如何传递，才能避免越权。 +3. 何时下层可以优化，何时必须服从上层。 +4. 如何把三层分工写入盘前、盘中、盘后的统一流程。 + +--- + +## 27.2　一句话结论 + +交易稳定性并不来自“看更多周期”，而来自“各周期做各自该做的事”：Big Picture 定方向与主目标，Intermediate 定路径与管理，Short-Term 定触发与风险表达；三层同向协作时，模型稳定度显著提升。 + +--- + +## 27.3　基础定义 + +### 一、Big Picture（大局视角） + +Big Picture 是方向层。它回答的是“市场这段时间更可能服务哪一侧目标”。 +在工作上，大局层只做三件事： + +1. 定主叙事。 +2. 定主目标。 +3. 定主失效边界。 + +它不直接给入场点，也不处理微观噪音。 + +### 二、Intermediate（中局视角） + +Intermediate 是路径层。它负责把“大方向”翻译成“可管理的过程”。 +中局层通常回答： + +1. 当前是在推进、回补还是重排。 +2. 哪些关键结构位决定持仓继续或降级。 +3. 哪些位置应分批兑现，哪些位置可继续持有。 + +### 三、Short-Term（短局视角） + +Short-Term 是触发层。它解决的是执行效率问题： + +1. 何时进。 +2. 错在哪。 +3. 失败后如何快速退出。 + +短局层的价值是“优化风险收益比”，不是“替代方向层”。 + +### 四、父级与从属结构 + +在多层结构中，父级结构提供解释权，从属结构提供执行精度。 +这意味着：短局反向波动默认先解释为“父级路径内节奏变化”，而不是立刻解释成“父级反转”。 + +### 五、三层输出契约 + +为了避免越权，本书建议固定三层输出契约： + +1. Big Picture 输出方向、目标、失效。 +2. Intermediate 输出路径、管理、降级触发器。 +3. Short-Term 输出触发、止损、再入条件。 + +若某一层输出越界，系统会迅速进入高频改向与情绪化交易。 + +### 六、三层传递顺序 + +默认顺序应固定为： + +`Big Picture -> Intermediate -> Short-Term` + +只有当上层失效条件被客观触发，下层才获得“重排上层结论”的权限。 + +### 七、三层一致性的最低标准 + +三层一致并不要求每根K线都同向，而要求三件事同时成立： + +1. 上层叙事未被下层噪音反复推翻。 +2. 中层路径能解释当前波动阶段。 +3. 下层触发明确服务上层目标。 + +--- + +## 27.4　底层逻辑 + +### 一、分层的本质是降低信息冲突成本 + +市场是分形的，同一时刻不同周期一定会出现看似矛盾的信号。 +如果不先分层，交易者会把每一次局部反向都当成方向事件，最终在不断“修正观点”中耗尽执行纪律。 + +### 二、中局是把“看对方向”变成“拿到结果”的关键层 + +很多人方向判断并不差，却长期拿不到稳定结果，核心原因通常不是方向层错误，而是中局缺位。 +没有中局，交易者只能在“长期观点”和“短线触发”之间来回跳跃，仓位管理与目标管理都会失去结构。 + +### 三、短局的价值在效率，不在解释权 + +短周期模型可以显著改善止损距离与盈亏比，但它不应该单独决定叙事方向。 +当短局被错误地提升为“方向层”，系统会在连续小胜后累积风险，并在一次上层反向中集中回吐。 + +### 四、上层失效会连带下层失效 + +一旦上层关键边界被破坏，短局里再漂亮的同向信号都应降级。 +这条规则看似保守，实际上是在保护系统的可持续性：先保结构一致，再谈单笔收益。 + +### 五、同一结构在不同层级语义不同 + +一个5分钟结构破位，在1小时里可能只是回补；一个1小时结构变形，在日线里可能仍是中继。 +因此，任何“结构变化”都必须先回答：它属于哪一层，是否有权限改写上层叙事。 + +### 六、三层越权是系统漂移主因 + +最常见漂移链路是：短局表现好 -> 误把短局当方向层 -> 频繁改向 -> 回撤放大。 +解决方式不是增加术语，而是恢复层级权限。 + +### 七、成熟执行是“分层授权” + +高质量系统不要求每层都完美，而要求三层之间“职责清楚、交接清楚、回退清楚”。 +这就是从“会看图”走向“可复制执行”的分水岭。 + +进一步说，三层授权真正解决的是“决策延迟与过度反应”的两端问题： +没有上层授权时，下层会过度反应；只有上层结论、没有下层触发时，又会决策过慢。 +三层并行后的目标，就是在“该慢时慢、该快时快”之间找到稳定节奏。 + +--- + +## 27.5　结构关系 + +### 一、承接第26章 + +第26章解决“范式选择”；第27章解决“范式由谁授权”。 +没有分层授权，任何范式都可能在盘中被临场情绪改写。 + +### 二、通向第28章 + +第28章会把本章三层分工展开为完整 Top-Down 流程，形成从 Monthly 到 5M 的标准作业链。 + +### 三、通向第29章 + +宏观、利率、跨市场等变量主要作用于 Big Picture 与 Intermediate 层，随后再由 Short-Term 落地执行。 + +### 四、与第19—23章关系 + +结构层级、位移证据、MSB/MSS、预判与确认边界，都将在本章“三层职责”里获得清晰归位。 + +### 五、与后续模型章节关系 + +后续每个执行模型都应标注其层级归属： + +1. 方向归属哪层。 +2. 管理归属哪层。 +3. 触发归属哪层。 + +--- + +## 27.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：三层同向协作。** +大局给主目标，中局给路径节奏，短局给执行触发。此时交易计划连续性强，换向频率低。 + +**标准情境B：父级未失效时，下层反向被解释为路径波动。** +交易者不会因一次短局回撤立刻推翻上层叙事，而是先检查中层结构是否仍然支持原路径。 + +**标准情境C：上层失效后，执行链同步降级。** +当上层边界被破坏，交易者会先撤销旧模型，再重建新叙事，而不是靠补仓对抗反证。 + +**反例情境：短局越权。** +盘中每次5M反向都触发改向，最终形成“每段都参与、每段都不完整”的高摩擦执行。 + +### 二、交易中的真实表现 + +实盘里真正的难点不是“看不见机会”，而是“知道哪个层级有权决定这次机会能不能做”。 +层级权限一旦明确，执行焦虑会显著下降，复盘归因也会更干净。 + +在复盘层面，三层框架还有一个常被低估的收益： +它会把“错了”拆成可改进的错误类型。 +例如你能清楚区分是方向层错误、路径层错误，还是触发层错误。 +这种可分解性，是系统持续迭代的基础。 + +--- + +## 27.7　执行意义 + +本章可直接落地为“层级执行卡 + 五步流程”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：先写大局叙事、主目标、主失效。 +2. 触发：中局标注路径阶段与管理位。 +3. 确认：短局仅等待与上两层一致的触发链。 +4. 执行：每笔单必须写明“服务哪层目标”。 +5. 退出：上层失效先停，中层失效先降，短层失效先减。 + +### 二、盘前最小填写模板 + +1. Big Picture：方向、主Draw、主失效。 +2. Intermediate：当前阶段、关键中继位、管理规则。 +3. Short-Term：触发条件、止损点、再入条件。 + +### 三、执行前六问 + +1. 这笔交易服务哪一层目标。 +2. 下层信号是否越权改向。 +3. 中层路径是否仍支持上层叙事。 +4. 上层失效边界是否已接近。 +5. 本次仓位强度是否与层级一致。 +6. 若失败，先执行哪一层的退出规则。 + +--- + +## 27.8　常见误区 + +### 误区一：用短局定义方向 + +**识别信号：** 5分钟结构每次反向都触发改向。 +**纠偏动作：** 方向必须由大局层授权，短局只优化进场与风控。 + +### 误区二：缺少中局管理层 + +**识别信号：** 入场不错，但持仓与减仓完全靠感觉。 +**纠偏动作：** 强制写中局管理位与降级触发器。 + +### 误区三：父子结构不分 + +**识别信号：** 低周期信号长期与高周期方向冲突。 +**纠偏动作：** 先确认父级边界，再解释子级波动。 + +### 误区四：同一信号同时承担多重职责 + +**识别信号：** 一个短线结构同时被当作方向证据、入场证据和止损证据。 +**纠偏动作：** 方向、管理、触发分栏记录，禁止职责重叠。 + +### 误区五：上层失效后仍按旧计划执行 + +**识别信号：** 明显反证出现后继续“等它回来”。 +**纠偏动作：** 把上层失效写成硬规则，不做主观协商。 + +### 误区六：只做层级分析，不做层级执行 + +**识别信号：** 盘前写得清楚，盘中临场全部失效。 +**纠偏动作：** 每笔交易前复核“这单属于哪层授权”。 + +--- + +## 27.9　高阶深化 + +### 一、高阶能力不是“看更多周期”，而是“管理层级冲突” + +真正成熟的交易者并不会追求信息最多，而是追求冲突最少。 +他会优先处理“哪一层应当拥有解释权”，再处理“是否进场”。 + +### 二、三层联动的核心是“授权链不断裂” + +可把层级联动理解为一条授权链： + +1. 大局给许可。 +2. 中局给路径。 +3. 短局给动作。 + +链条完整时，执行稳定；链条断裂时，收益曲线会明显恶化。 + +### 三、建议使用3R审查 + +1. Role：每层是否只做本层职责。 +2. Relay：上层信息是否正确传给下层。 +3. Risk：仓位与退出是否按层级规则执行。 + +3R 任一失真，当天执行质量都应主动降级。 + +### 四、统一工作公式 + +> Decision Stability = Big Picture Clarity × Intermediate Continuity × Short-Term Precision × Permission Discipline + +把这个公式落到实务，可以进一步写成四个日常检查项： +`方向是否清楚`、`路径是否连贯`、`触发是否干净`、`权限是否越界`。 +每天盘后只需复核这四项，就能快速识别系统退化点。 + +--- + +## 27.10　本章总结 + +1. 三层分工的核心是防止越权，不是增加复杂度。 +2. Big Picture 定方向，Intermediate 定路径，Short-Term 定触发。 +3. 中局是连接“看对方向”与“拿到结果”的关键层。 +4. 上层失效会连带下层失效，必须先保系统一致。 +5. 本章为第28章 Top-Down 标准流程提供职责底座。 + +--- + +## 27.11　训练清单 + +1. 观察任务：抽取40个样本，分别标注方向层、路径层、触发层。 +2. 标注任务：每笔交易写清“本单服务哪层目标”。 +3. 执行任务：禁止任何“短局越权改向”的计划外交易。 +4. 复盘任务：统计“层级冲突交易”的次数与损益贡献。 +5. 达标标准：将“未分层直接执行”的比例降至20%以下并连续保持四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Long-term / Intermediate-term / Short-term 视角分工、主从结构与多层执行权限的相关章节整理。 +[2] 文中“分层职责卡、3R复盘法、稳定性公式”属于方法化表达，用于把原有语义落地为可复盘流程。 +[3] 延伸内容仅用于执行标准化，不引入与原始框架冲突的新定义。 + + + +# 第28章　Top-Down Analysis：Monthly → Weekly → Daily → 4H → 1H → 15M → 5M + +## 28.1　本章核心问题 + +第27章解决了“谁负责方向、谁负责路径、谁负责触发”。 +本章要把这个分工落成一条可复用的作业流程： + +**如何从 Monthly 一路下钻到 5M，并在每一层只输出该层应输出的结论。** + +很多交易者“会看多周期”却仍不稳定，根源通常不是知识不够，而是流程错位： + +1. 下钻顺序不固定，今天先看5M，明天先看日线； +2. 每层输出不明确，导致结论互相覆盖； +3. 下层信号越权，频繁改写上层叙事。 + +因此，本章主问题是： + +**如何把 Top-Down 从“多图浏览”升级为“分层递交输出”的执行系统。** + +围绕这一主问题，本章回答四个子问题： + +1. 七层链路各层职责是什么。 +2. 上下层如何交接，才不会发生越权。 +3. 不同交易风格如何在同一框架下做周期组合。 +4. 如何把 Top-Down 写进盘前、盘中、盘后闭环。 + +--- + +## 28.2　一句话结论 + +Top-Down 的本质不是“看更多周期”，而是“按层级递交不同输出”：Monthly/Weekly 给背景与方向，Daily 给 Bias 与主Draw，4H/1H 给路径与管理，15M/5M 给触发与风控；下层只能优化执行，不能越权改向。 + +--- + +## 28.3　基础定义 + +### 一、什么是 Top-Down Analysis + +Top-Down 不是随意从大到小切图，而是一个有顺序的传递系统： +上层先给假设，下层再给验证与执行。 +若没有固定顺序，系统会从“结构化决策”退化为“临场反应”。 + +### 二、七层链路的默认职责 + +1. Monthly：长期结构背景与大方向约束。 +2. Weekly：本周主任务与主目标。 +3. Daily：当日 Bias、主次Draw、范围位置。 +4. 4H：路径阶段与中继管理区。 +5. 1H：执行框架桥接与结构过滤。 +6. 15M：触发准备与入场前确认。 +7. 5M：最终触发、止损、执行精度。 + +### 三、每层最小输出字段 + +为了可复盘，每层至少要交付一个“可验证字段”： + +1. Monthly：长期约束边界。 +2. Weekly：本周优先目标。 +3. Daily：当日方向偏见与强度。 +4. 4H：路径阶段（推进/回补/重排）。 +5. 1H：关键结构是否支持当前计划。 +6. 15M：候选触发区。 +7. 5M：最终触发与失效点。 + +### 四、层级交接原则 + +交接规则固定为三句： + +1. 上层定“做哪边、做到哪”。 +2. 中层定“怎么走、何时降级”。 +3. 下层定“何时进、错在哪”。 + +任何层级直接跳过中间层，都会放大执行波动。 + +### 五、不同风格的周期组合 + +交易风格可以不同，但分工原则不变。 +短线可用 `Daily -> 1H -> 5M`，日内可用 `Weekly -> Daily -> 15M/5M`，波段可用 `Monthly -> Weekly -> Daily`。 +组合可以调整，权限不可混用。 + +### 六、Top-Down 与 Entry Refinement + +下钻到更低周期的目的，是改善入场效率，而不是改写上层方向。 +这条边界若被打破，精修就会变成越权。 + +### 七、最小文档化要求 + +建议固定三段记录： + +1. 盘前：七层输出摘要。 +2. 盘中：触发与重排日志。 +3. 盘后：越权与失效复盘。 + +--- + +## 28.4　底层逻辑 + +### 一、Top-Down 的真正价值是压缩不确定性 + +上层先过滤大噪音，下层再做精细执行。 +顺序正确时，交易次数可能减少，但单次质量会明显提升。 + +### 二、Weekly 与 Daily 是执行中枢 + +Monthly 提供大环境，Weekly 给本周主任务，Daily 给当天可执行偏向。 +若 Weekly/Daily 缺位，低周期触发将失去方向锚，执行会高度情绪化。 + +### 三、1H 是桥，15M/5M 是刀 + +1H 负责把叙事翻译成框架；15M/5M 负责把框架翻译成动作。 +桥断了，刀越锋利，误伤越快。 + +### 四、Top-Down 终点不是入场，而是一致性 + +高质量 Top-Down 最终要回答： + +1. 这笔交易服务哪条上层叙事。 +2. 它位于哪段中层路径。 +3. 触发失败后为什么应立即退出。 + +### 五、越权是 Top-Down 失效主因 + +典型越权路径包括： + +1. 5M 反向波动推翻 Weekly 假设； +2. 15M 局部结构改写 Daily Bias； +3. 4H 管理位被破坏后仍按旧叙事硬扛。 + +### 六、下钻是为了更准，不是更复杂 + +周期越多不等于质量越高。 +只有每层都能交付明确输出，下钻才有边际价值。 + +### 七、成熟优势在流程复用 + +真正有效的 Top-Down 必须“今天能用、明天能用、换市场也能用”。 +可复用性比单次灵感更重要。 + +--- + +## 28.5　结构关系 + +### 一、承接第27章 + +第27章给出三层职责，本章把职责扩展成七层作业流，补齐“谁给谁授权”的执行链。 + +### 二、通向第29章 + +第29章的宏观、利率、跨市场过滤，会优先作用于上层（Monthly/Weekly/Daily），再传导到下层执行。 + +### 三、与第24—26章关系 + +第24章给 Narrative，第25章给 Bias，第26章给范式匹配；本章把三者固化成分层流程。 + +### 四、与第30章关系 + +第30章的 Relative Strength、Correlation、SMT 等过滤器，本质上是 Top-Down 上层与中层的校验模块。 + +### 五、与后续模型章节关系 + +后续所有执行模型都应标注“来自哪层授权”。 +若无法标注层级来源，模型应降级为观察，不应直接执行。 + +--- + +## 28.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：链路一致。** +Weekly 给主方向，Daily 给主Draw，4H/1H 给路径，15M/5M 给触发。交易节奏稳定，改向次数少。 + +**标准情境B：上层不变、下层精修。** +上层叙事未变时，下层只优化入场效率，不改方向结论。 + +**标准情境C：上层失效触发全链降级。** +当 Weekly 或 Daily 前提被否定，下层执行权限同步收缩，先保护系统再等待新链路。 + +**反例情境：先找低周期机会，再补高周期理由。** +这种顺序会让计划后置，证据错序，结果是盘中不可复制、盘后却“看起来合理”。 + +### 二、交易中的真实表现 + +多数临盘崩坏并非“信号太少”，而是“交接断层”：上层没写清，中层没承接，下层先开仓。 +Top-Down 的作用正是修复这个断层。 + +--- + +## 28.7　执行意义 + +本章执行统一为“七层交接表 + 五步流程”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：先完成 Monthly/Weekly/Daily 三层输出。 +2. 触发：在 4H/1H 写路径位与管理位。 +3. 确认：在 15M/5M 等待与上层一致的触发链。 +4. 执行：仅做七层无关键冲突的样本。 +5. 退出：上层前提失效时，下层执行自动降级或离场。 + +### 二、日内最小作业单 + +1. 上层一句话：今天主要服务哪一侧目标。 +2. 中层两条线：关键管理位与降级位。 +3. 下层三条件：触发、止损、失效后动作。 + +### 三、执行前六问 + +1. 上层结论是否已经写成可验证字段。 +2. 中层是否给出清晰路径阶段。 +3. 下层是否在服务上层而非对抗上层。 +4. 当前信号是否越权。 +5. 若失败，退出动作是否预先写明。 +6. 这笔交易是否可以被盘后完整复现。 + +--- + +## 28.8　常见误区 + +### 误区一：Top-Down 等于多看几个周期 + +**识别信号：** 图看得多，但每层没有固定输出。 +**纠偏动作：** 为每层设置最小输出字段。 + +### 误区二：下层越权改向 + +**识别信号：** 5M 的短时波动频繁推翻 Daily/Weekly 结论。 +**纠偏动作：** 恢复“上层定向、下层定时”的权限边界。 + +### 误区三：只有上层分析，没有下层触发 + +**识别信号：** 方向常对，但执行总慢、总迟。 +**纠偏动作：** 固定 15M/5M 触发链，不跳步。 + +### 误区四：周期组合与交易风格错配 + +**识别信号：** 持仓周期和分析周期长期错位。 +**纠偏动作：** 先按风格选主组合，再嵌入七层总框架。 + +### 误区五：盘前有流程，盘中无纪律 + +**识别信号：** 一到波动阶段就放弃层级规则。 +**纠偏动作：** 盘中每次改计划必须注明“触发了哪一层失效”。 + +### 误区六：把下钻当成“找更高频机会” + +**识别信号：** 周期越低，交易越频繁。 +**纠偏动作：** 下钻只为提高质量，不为增加次数。 + +--- + +## 28.9　高阶深化 + +### 一、高阶 Top-Down 是权限管理系统 + +可把七层简化为三类权限： + +1. 定向权（Monthly/Weekly/Daily）。 +2. 管理权（4H/1H）。 +3. 触发权（15M/5M）。 + +当触发权试图越权定向时，系统回撤会显著放大；当定向权长期压制触发权时，又会错失高质量执行点。 + +### 二、建立“层级冲突处理规则” + +建议提前写好冲突处理： + +1. 轻冲突：降仓，不改向。 +2. 中冲突：暂停触发，等待中层重建。 +3. 重冲突：撤销旧叙事，重做上层分析。 + +### 三、用“可复现性”评估流程质量 + +若你无法在盘后复现“从上到下为什么会做这笔单”，说明 Top-Down 还没真正落地。 + +### 四、统一工作公式 + +> Top-Down Quality = Direction Authority × Path Continuity × Trigger Discipline × Conflict Handling + +--- + +## 28.10　本章总结 + +1. Top-Down 是分层输出流程，不是多周期浏览。 +2. Weekly 与 Daily 是偏见与反馈中枢。 +3. 4H/1H 负责路径桥接，15M/5M 负责执行触发。 +4. 下层精修可以增强效率，但不能越权改向。 +5. 本章为第29章外生过滤与后续模型执行提供流程主干。 + +--- + +## 28.11　训练清单 + +1. 观察任务：连续30个交易日完成七层Top-Down记录。 +2. 标注任务：每层至少输出一条可验证结论。 +3. 执行任务：仅交易“七层无关键冲突”样本。 +4. 复盘任务：统计“下层越权交易”的次数与损益贡献。 +5. 达标标准：将“下层越权入场”比例降到20%以下并连续保持四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Top-Down 分层下钻、风格分层、主从结构与执行权限的核心段落整理。 +[2] 文中“冲突处理分级、流程质量公式”用于把原有原则转写为可复盘模板。 +[3] 延伸表达仅用于执行标准化，不改变原始框架语义。 + + + +# 第29章　Macro、Interest Rates、Intermarket、Seasonality、COT、Market Sentiment、Open Interest + +## 29.1　本章核心问题 + +第28章我们完成了 Top-Down 的技术流程。 +但在真实市场里，仅靠图表信息仍会遇到一个长期问题： + +**为什么技术结构看起来成立，路径却在关键阶段反复失真。** + +这往往不是技术模型本身的问题，而是上层环境没有被纳入过滤。 +具体表现通常有三类： + +1. 完全不看宏观背景，结果在周期拐点反复逆风； +2. 过度解读宏观消息，结果“逻辑很强，执行很弱”； +3. 把宏观变量当入场按钮，导致高波动时段冲动交易。 + +因此，本章要解决的主问题是： + +**宏观与跨市场变量如何进入 ICT 执行框架，成为“叙事过滤器”，而不是“信号替代器”。** + +围绕这一主问题，本章回答四个子问题： + +1. Macro、利率、跨市场、季节性、COT、情绪、持仓各自解决什么问题。 +2. 这些变量如何与 Narrative、Draw、Bias 联动。 +3. 它们在执行中影响什么，不影响什么。 +4. 如何把宏观过滤写成可复盘的风险管理规则。 + +--- + +## 29.2　一句话结论 + +宏观变量在 ICT 体系中的主要角色是“提高或降低叙事可信度”：它们不直接给入场点，但会显著改变仓位强度、持仓预期与目标管理优先级。 + +--- + +## 29.3　基础定义 + +### 一、Macro（宏观背景） + +在本书语境中，Macro 指会改变中长期资金行为的上层条件。 +它回答的不是“下一根K线涨跌”，而是“当前叙事处于顺风还是逆风环境”。 + +### 二、Interest Rates（利率） + +利率本质上是资金成本。 +当资金成本变化时，资产之间的相对吸引力会变化，市场递送路径也会随之改变。 +因此，利率更像“方向摩擦系数”，而不是“即时触发器”。 + +### 三、Intermarket（跨市场关系） + +跨市场关系用于检验主叙事是否获得外部市场配合。 +若相关市场协同，叙事稳定性提高；若相关关系出现裂缝，执行应降级。 + +### 四、Seasonality（季节性） + +季节性不是机械模板，而是长期行为倾向。 +它的价值在于给叙事增加“背景权重”，而不是替代结构证据。 + +### 五、COT（持仓报告） + +COT 用于观察大类参与者的持仓倾向，帮助交易者判断当前市场是否处于“资金结构支持”状态。 +它主要作用于中长期叙事，不用于短周期点位触发。 + +### 六、Market Sentiment（市场情绪） + +情绪用于衡量拥挤程度。 +当市场情绪极端一致时，路径更容易出现反身性波动，执行应更重视风险控制而非情绪跟随。 + +### 七、Open Interest（未平仓量） + +Open Interest 反映持仓扩张或收缩状态。 +它可作为“趋势健康度”观察项：价格推进若伴随持仓扩张，趋势延续性通常更好；若推进与持仓收缩背离，路径稳定性可能下降。 + +--- + +## 29.4　底层逻辑 + +### 一、宏观变量的正确定位是“过滤”，不是“替代” + +在 ICT 的链路中，执行核心仍是价格证据。 +宏观变量的任务是给既有叙事加权： + +1. 同向时，提高模型优先级； +2. 冲突时，降低执行强度； +3. 明显逆风时，优先保护资本。 + +### 二、利率影响的是“路径阻力” + +同样的技术结构，在利率顺风与逆风环境下，推进效率和持仓难度往往不同。 +这意味着：利率维度更该进入“仓位与持有计划”，而不是进入“短线触发按钮”。 + +### 三、跨市场裂缝是风险告警，而非立即反向 + +相关性裂缝出现时，最专业的动作通常不是立刻反手，而是先降级确定性： + +1. 缩小仓位； +2. 缩短目标； +3. 等待结构确认。 + +### 四、COT、情绪与 OI 共同描述“资金温度” + +这三者分别从持仓结构、行为拥挤、仓位扩张角度观察市场。 +它们不提供精确点位，却能帮助你判断：这条叙事是“顺资金”还是“逆资金”。 + +### 五、宏观过滤的真正价值是“减少低质量交易” + +很多交易系统的问题不在“抓不到大机会”，而在“低质量机会做太多”。 +宏观过滤做得好，首先会减少不该做的交易，其次才是提升单笔收益。 + +### 六、宏观输入必须服务 Top-Down + +宏观变量应优先作用于 Monthly/Weekly/Daily 层，然后再下传到 4H/1H 与 15M/5M。 +若反过来在低周期临场“临时引用宏观”，大多会变成事后合理化。 + +### 七、成熟标准是“可量化降级” + +宏观冲突出现时，系统应产生可执行动作，而不是情绪争论： + +1. 降仓； +2. 缩目标； +3. 延后执行； +4. 暂停模型。 + +--- + +## 29.5　结构关系 + +### 一、承接第28章 + +第28章给出多层流程，本章给出上层过滤器。 +它补上的是“技术链路之外的外生约束”。 + +### 二、通向第30章 + +第30章将把跨市场过滤细化到 Relative Strength、Correlation、Bellwether、SMT 的执行级工具。 + +### 三、与第24—26章关系 + +Narrative、Bias、范式在本章获得“外部环境加权”，从而减少内部一致但外部逆风的执行误差。 + +### 四、与时间章节关系 + +宏观过滤决定“做不做、做多大”，时间过滤决定“什么时候做”；两者互补，不可互代。 + +### 五、与后续模型章节关系 + +后续模型若不考虑宏观过滤结果，常会在特定周期段出现“模型对、收益差”的执行偏差。 + +--- + +## 29.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：技术叙事与宏观过滤同向。** +这类环境下，路径稳定性更高，交易者可按标准持有计划执行。 + +**标准情境B：技术信号成立，但跨市场裂缝扩大。** +此时交易仍可做，但应下调仓位和目标，不宜按趋势日强度处理。 + +**标准情境C：价格推进与 OI 背离。** +当价格延续而持仓未同步扩张，趋势健康度需复核，止盈与风险保护应前置。 + +**反例情境：宏观明显逆风仍重仓。** +这类交易在单笔上可能偶尔盈利，但长期回撤通常更大，收益曲线不稳定。 + +### 二、交易中的真实表现 + +实盘中，宏观过滤做得好的账户，通常有两个特征： + +1. 低质量交易明显减少； +2. 逆风阶段回撤明显可控。 + +这比“单次抓到大行情”更能决定账户长期表现。 + +--- + +## 29.7　执行意义 + +本章可直接落地为“技术计划 + 宏观过滤”双层执行卡。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：先写技术叙事（Narrative + Draw + Bias）。 +2. 触发：加入宏观过滤（利率、跨市场、季节性、COT、情绪、OI）。 +3. 确认：根据过滤结果给叙事打分并决定执行强度。 +4. 执行：顺风环境按标准执行，逆风环境降仓降频。 +5. 退出：宏观与技术持续背离时，主动降风险并缩短持有。 + +### 二、建议的过滤评分法 + +可将六项过滤器各记 0—2 分： + +1. 利率环境； +2. 跨市场一致性； +3. 季节性顺逆； +4. COT 结构； +5. OI 健康度； +6. 情绪拥挤度。 + +总分高：可用标准执行；总分中：保守执行；总分低：旁观或极轻仓。 + +### 三、执行前六问 + +1. 当前宏观环境是顺风还是逆风。 +2. 跨市场是否在支持当前叙事。 +3. 持仓结构是否支持路径延续。 +4. 当前仓位强度是否与过滤结果匹配。 +5. 若宏观冲突扩大，是否有降级动作。 +6. 本次决策能否在盘后被量化复盘。 + +--- + +## 29.8　常见误区 + +### 误区一：把宏观变量当入场信号 + +**识别信号：** 消息一出就下单。 +**纠偏动作：** 宏观只做过滤，不替代结构触发。 + +### 误区二：完全忽略宏观 + +**识别信号：** 每次大级别逆风都归因于“运气不好”。 +**纠偏动作：** 至少保留利率、跨市场、OI 三项基础过滤。 + +### 误区三：信息过载 + +**识别信号：** 看的变量越来越多，决策却越来越慢。 +**纠偏动作：** 固定少量高价值过滤器，长期一致使用。 + +### 误区四：宏观逆风不降仓 + +**识别信号：** 明知逆风仍用趋势日仓位。 +**纠偏动作：** 把过滤结果写入仓位规则，自动触发降级。 + +### 误区五：只做盘前过滤，不做盘中更新 + +**识别信号：** 盘中环境已变化，执行仍按旧评分。 +**纠偏动作：** 在关键会话切换点重评过滤器。 + +### 误区六：把过滤冲突当“方向反转证明” + +**识别信号：** 一有宏观冲突就立刻反手。 +**纠偏动作：** 先降级风险，再等待结构证据。 + +--- + +## 29.9　高阶深化 + +### 一、高阶优势来自“过滤一致性” + +成熟交易者不是每次都能预测宏观结果，而是能长期一致地把过滤结果转换成风险动作。 +这会让系统在不同市场阶段都保持可控。 + +### 二、把宏观争论转为执行动作 + +高阶处理方式不是讨论“谁更懂宏观”，而是提前约定： + +1. 过滤冲突到什么程度要降仓。 +2. 冲突持续多久要暂停模型。 +3. 何时恢复标准仓位。 + +### 三、宏观过滤与账户生存直接相关 + +账户曲线长期稳定，通常不依赖“每次都做对”，而依赖“逆风阶段少亏、顺风阶段拿住”。 +宏观过滤恰好服务这两个目标。 + +### 四、统一工作公式 + +> Macro Filter Value = Regime Alignment × Cross-Market Confirmation × Positioning Health × Execution Adaptation + +--- + +## 29.10　本章总结 + +1. 宏观变量是叙事过滤器，不是入场触发器。 +2. 利率、跨市场、季节性、COT、情绪、OI 共同决定叙事可信度。 +3. 宏观过滤最直接影响仓位强度、持仓时长与目标管理。 +4. 宏观与技术背离时，先降风险，再等结构确认。 +5. 本章为第30章跨市场执行过滤提供上游框架。 + +--- + +## 29.11　训练清单 + +1. 观察任务：连续30个交易日记录六项宏观过滤评分。 +2. 标注任务：每笔交易写“过滤总分 + 实际仓位强度”。 +3. 执行任务：低分环境禁止重仓推进。 +4. 复盘任务：比较“过滤同向交易”与“逆风交易”的绩效差异。 +5. 达标标准：将“宏观逆风重仓交易”比例降到20%以下并连续保持四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于利率、跨市场关系、季节性、COT、情绪与未平仓量模块整理，并与前文 Narrative/Bias/Top-Down 链路衔接。 +[2] 文中评分法与仓位降级阈值用于执行量化训练，不作为固定收益承诺。 +[3] 延伸部分仅用于风险管理落地，不增加与原始材料冲突的新理论。 + +# 第六部分　时间理论与跨市场过滤 + +前五部分解决了“做哪边、为什么做、在哪里做”。 +第六部分要解决的是： + +**什么时候做，质量更高。** + +--- + +## 本部分定位 + +本部分把时间与会话从背景信息升级为执行条件： + +1. 用跨市场过滤提升样本质量； +2. 用周内与日内时间骨架约束交易节奏； +3. 用会话分工和投影模型管理日内目标； +4. 用事件窗口规则控制高波动风险。 + +--- + +## 五章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第30章 | Relative Strength/Correlation/Bellwether/SMT 如何做执行过滤 | +| 第31章 | Day of Week、True Day、Weekly/Daily Range 如何做时间约束 | +| 第32章 | Asian/London/New York 与 Kill Zones 如何做会话分工 | +| 第33章 | CBDR、ADR、标准差与轮廓如何做空间投影 | +| 第34章 | 经济日历、新闻窗口、开盘波动如何做事件日管理 | + +--- + +## 学习边界 + +第六部分最容易误学成“到点就做”或“看新闻就做”。 +请固定原则： + +**时间与事件只提高或降低执行权限，不替代结构确认。** + +--- + +## 学完应具备 + +完成第六部分后，你应能： + +1. 把时间窗口写成执行许可，而非事后解释。 +2. 把会话分工与流动性路径联动。 +3. 用空间投影做分层目标管理。 +4. 在事件日执行“窗口后确认”的纪律。 + +--- + +## 与后续章节的连接 + +第七部分将把前六部分全部收束到模型层， +实现从“框架认知”到“可重复执行模板”的跃迁。 + +--- + +## 章末注释 + +[1] 本导读用于连接第五部分方向链与第六部分时间执行链。 +[2] 建议进入第七部分前，先复核第31章时间评分与第33章目标分层模板。 + + + +# 第30章　Relative Strength、Correlation、Bellwether 与 SMT Divergence + +## 30.1　本章核心问题 + +第29章把宏观变量定位为上层过滤器。 +本章继续下沉到执行层最常用的一组跨市场工具： + +- Relative Strength +- Correlation +- Bellwether +- SMT Divergence + +这四个概念被误用的频率很高。常见失真有三类： + +1. 把 SMT 当成独立入场信号； +2. 把相关性裂缝当成“立刻反向”的命令； +3. 不先建立日内框架，直接在低周期追逐分歧。 + +因此，本章主问题是： + +**如何把这四个工具放回正确位置，使其成为“执行质量过滤器”，而不是“冲动交易放大器”。** + +围绕主问题，本章回答四个子问题： + +1. 四个工具各自解决什么问题。 +2. 它们之间如何协作而非互相替代。 +3. 它们在执行链中位于哪个环节。 +4. 如何把“跨市场确认”写成可复盘规则。 + +--- + +## 30.2　一句话结论 + +Relative Strength 用来选强弱标的，Correlation 用来判同步性，Bellwether 用来框定当日执行语境，SMT Divergence 用来确认或降级叙事；四者组合的核心价值是过滤低质量交易，而不是制造更多入场冲动。 + +--- + +## 30.3　基础定义 + +### 一、Relative Strength（相对强弱） + +Relative Strength 回答“同类资产里谁更值得做”。 +它不是预测工具，而是交易对象筛选工具：在同一叙事下，优先选择结构更清晰、递送更干净的强弱标的。 + +### 二、Correlation（相关性） + +Correlation 用于观察市场是否保持协同。 +相关关系并非永远稳定，但在多数时间具有“默认同步”特征。 +当同步关系出现裂缝时，应优先做风险降级，而非直接反向下注。 + +### 三、Bellwether（风向锚） + +Bellwether 的作用是“先框定当日语境，再讨论触发”。 +在指数日内框架中，15分钟图常被用作 Bellwether： + +1. 给出日内高低与结构骨架； +2. 帮助判断当前处于推进、回补还是整理； +3. 约束5分钟以下触发的解释权。 + +### 四、SMT Divergence（跨市场分歧） + +SMT 关注的是“相关市场在关键高低点上的不同步表现”。 +它的角色是确认器，不是独立入场器。 +换言之，SMT 只在主叙事已经成立时加分，不能单独替代主模型。 + +### 五、四者的职责分工 + +可用一句话概括四者关系： + +1. Relative Strength：选谁做。 +2. Correlation：看是否同步。 +3. Bellwether：定今天怎么读盘。 +4. SMT：确认当前分歧是否支持或削弱叙事。 + +### 六、四者与 Top-Down 的关系 + +这组工具主要作用于中上层过滤，然后下传到执行层。 +若在没有上层叙事的前提下直接调用，通常会退化为“多图找理由”。 + +### 七、四者的边界 + +它们都不应直接替代： + +1. 结构确认； +2. 位置确认； +3. 风险定义。 + +--- + +## 30.4　底层逻辑 + +### 一、这四个工具本质是“质量控制模块” + +市场噪音无法消除，但可以被分层过滤。 +四工具组合的意义，就是在入场前先回答“这笔交易是否值得做得更重”。 + +### 二、相关性裂缝是告警，不是反手按钮 + +当相关市场不同步，首先说明的是确定性下降。 +最专业的动作通常是降仓、缩目标、等待确认，而不是立即押注反向。 + +### 三、Bellwether 把日内执行从“追K线”变成“框架交易” + +没有 Bellwether，低周期波动会不断争夺解释权。 +有 Bellwether，交易者先有主框架，再允许触发发生，执行稳定性会明显提高。 + +### 四、SMT 的正确位置是“确认链后段” + +SMT 最有效的用法，是在主模型已成立时判断是否提高置信度。 +若主模型本身不成立，仅凭 SMT 开仓，长期表现通常不稳定。 + +### 五、相对强弱决定“做谁”比“做不做”更关键 + +许多执行问题并非方向错误，而是标的选择错误。 +在同向叙事下，选择更强的多头标的或更弱的空头标的，往往比频繁优化入场点更有效。 + +### 六、四工具的价值在一致性，不在单次神奇命中 + +这四个工具都不该被神化。它们真正提供的是长期一致的过滤纪律。 +一致使用时，低质量样本会持续减少，收益分布会更平滑。 + +### 七、跨市场过滤应服务“做减法” + +成熟交易者使用这组工具，通常不是为了增加交易次数，而是为了删除不该做的交易。 +这正是它们在账户层面的核心价值。 + +--- + +## 30.5　结构关系 + +### 一、承接第29章 + +第29章解决“宏观是否顺风”，第30章解决“跨市场是否协同”。 +两者共同构成外生过滤层。 + +### 二、通向第31章 + +第31章时间理论会与 Bellwether 和 SMT 在时段层面进一步联动，形成“结构+时间”双过滤。 + +### 三、与第27—28章关系 + +第27—28章给层级权限与下钻流程；本章给跨市场一致性校验，避免低周期越权。 + +### 四、与后续执行模型关系 + +后续任何日内模型都可把本章四工具作为“执行前过滤评分”，而非入场条件本身。 + +### 五、与风险章节关系 + +相关性裂缝、强弱反转、Bellwether失真都应触发风险降级机制，这将直接关联后续仓位管理章节。 + +--- + +## 30.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：相关市场协同。** +主市场与对照市场结构同步，Bellwether 结构清晰，SMT 无明显冲突。此时执行可维持标准强度。 + +**标准情境B：出现相关性裂缝。** +主市场仍在推进，但相关市场不同步。此时交易仍可做，但应降低仓位并缩短目标。 + +**标准情境C：主模型成立后出现 SMT 支持。** +SMT 可作为加分项，提高执行置信度，而不是替代主模型。 + +**反例情境：先看分歧后找模型。** +交易者先在相关市场找出“看起来有意思的背离”，再回主图拼叙事，这会显著增加事后解释交易。 + +### 二、交易中的真实表现 + +实盘里最常见错误不是“不会看分歧”，而是“在错误阶段使用分歧”。 +把 SMT 放在确认后段、把 Bellwether 放在触发前段，执行质量会明显改善。 + +--- + +## 30.7　执行意义 + +本章可落地为“跨市场四项过滤表”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：先有主叙事与主模型。 +2. 触发：用 Bellwether 定义当日框架。 +3. 确认：用 Relative Strength、Correlation、SMT 做质量过滤。 +4. 执行：过滤通过才表达风险，过滤冲突则降级。 +5. 退出：相关性裂缝扩大或 Bellwether 失真时主动减仓。 + +### 二、四项评分建议（0/1） + +1. 强弱是否同向支持。 +2. 相关结构是否协同。 +3. Bellwether 是否清晰。 +4. SMT 是否支持主叙事。 + +总分高：可标准执行；总分中：保守执行；总分低：旁观或轻仓。 + +### 三、执行前六问 + +1. 我先有主模型，还是先有分歧故事。 +2. Bellwether 是否已经给出框架。 +3. 当前相关性是协同还是裂缝。 +4. SMT 是在加分，还是被我拿来替代模型。 +5. 过滤结果是否已经映射到仓位强度。 +6. 若过滤恶化，是否有自动降级动作。 + +--- + +## 30.8　常见误区 + +### 误区一：把 SMT 当入场按钮 + +**识别信号：** 只要出现分歧就开仓。 +**纠偏动作：** SMT 只能在主模型成立后作为确认项。 + +### 误区二：相关性破裂就立刻反手 + +**识别信号：** 轻微裂缝即重仓反向。 +**纠偏动作：** 先降级风险，再等待结构接管证据。 + +### 误区三：不先定 Bellwether 就下钻执行 + +**识别信号：** 低周期反复试错，无法解释当日框架。 +**纠偏动作：** 先用15M建立日内骨架，再做5M触发。 + +### 误区四：相对强弱只做盘前一次 + +**识别信号：** 盘前强弱结论与盘中状态长期脱节。 +**纠偏动作：** 在关键会话切换点动态复核强弱排序。 + +### 误区五：跨市场过滤只用于“加仓理由” + +**识别信号：** 过滤器只在顺风时被提及，逆风时被忽略。 +**纠偏动作：** 明确写入“逆风降级规则”。 + +### 误区六：四工具职责混用 + +**识别信号：** 同一信号同时被当作选标的、定方向、入场点。 +**纠偏动作：** 恢复四工具职责边界，分模块记录。 + +--- + +## 30.9　高阶深化 + +### 一、高阶用法是“过滤矩阵”而非“单点判断” + +成熟执行不依赖某一项神奇信号，而依赖矩阵一致性。 +当四项共振时，执行容错更高；当四项冲突时，最优动作通常是降频。 + +### 二、把四工具嵌入账户风险分层 + +可将账户日内风险预算与过滤评分绑定： + +1. 高评分：标准风险预算； +2. 中评分：半风险预算； +3. 低评分：观察或极轻仓。 + +这样可把“质量判断”直接转换成“风险动作”。 + +### 三、真正优势在“不过度反应” + +人人看得见跨市场分歧，真正稀缺的是不被分歧牵着走。 +把分歧当确认器而非方向器，系统稳定性会显著提升。 + +### 四、统一工作公式 + +> Cross-Market Quality = Relative Strength Alignment × Correlation Stability × Bellwether Clarity × SMT Confirmation + +--- + +## 30.10　本章总结 + +1. Relative Strength、Correlation、Bellwether、SMT 各有明确分工。 +2. 四工具的核心价值是过滤，不是触发。 +3. Bellwether 先定框架，SMT 后做确认。 +4. 相关性裂缝优先触发风险降级，而非冲动反手。 +5. 本章为时间理论与会话执行章节提供跨市场校验层。 + +--- + +## 30.11　训练清单 + +1. 观察任务：连续30个交易日记录四项过滤评分。 +2. 标注任务：每笔交易写“过滤前评分—过滤后动作”。 +3. 执行任务：评分≤1 环境禁止重仓推进。 +4. 复盘任务：比较“高评分执行”与“低评分强做”的绩效差异。 +5. 达标标准：将“低评分环境强做”比例降到20%以下并连续保持四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Relative Strength、Correlation、Bellwether 与 SMT 作为确认工具的核心内容整理。 +[2] 文中评分法与分级动作用于执行流程化训练，不构成固定仓位建议。 +[3] 延伸表达仅用于把过滤逻辑落地为可复盘流程，不新增与原始体系冲突的定义。 + + + +# 第31章　Time Theory：Day of Week、True Day、Weekly Range、Daily Range + +## 31.1　本章核心问题 + +到第30章为止，位置、流动性、结构、跨市场过滤都已经具备。 +但很多交易者仍会遇到同一个瓶颈： + +1. 方向判断经常不差，执行节奏却总是早一步或晚一步； +2. 同一模型在某些时段连续有效，在另一些时段连续失真； +3. 复盘时路径清晰，实盘时却被日内噪音反复打断。 + +这类问题的根源，通常不是工具不足，而是忽略了时间本身就是递送结构的一部分。 +在 ICT 框架里，价格不仅要回答“去哪里”，还要回答“更可能在什么时候推进”。 + +因此，本章主问题是： + +**如何把 Time Theory 从概念层变成执行层，使 Day of Week、True Day、Weekly Range、Daily Range 成为可操作的时间约束系统。** + +围绕这一主问题，本章回答四个子问题： + +1. 周内该如何使用 Day of Week。 +2. 日内该如何理解 True Day 的边界。 +3. Weekly Range 与 Daily Range 应如何按阶段读取。 +4. 如何把时间约束写入执行许可，而不是作为事后解释。 + +--- + +## 31.2　一句话结论 + +Time Theory 不是附加滤镜，而是 Price Delivery 的时间骨架：做周内交易要先处理 Day of Week 的阶段权重，做日内交易要先处理 True Day 与会话窗口，时间与结构同向时才提高执行强度。 + +--- + +## 31.3　基础定义 + +### 一、Time Theory 的工作定义 + +在本书中，Time Theory 指价格递送在时间维度上的分布规律。 +它不是预测“几点一定涨跌”，而是回答“哪类递送更可能在什么时段发生”。 + +### 二、Day of Week（周内节律） + +Day of Week 用于周内路径分工。 +当你交易 Weekly Range 时，重点不在每一根低周期K线，而在周内阶段角色： + +1. 哪些日子更常出现方向证据； +2. 哪些日子更常出现回补、兑现或重排。 + +这让“周内叙事”从模糊判断变成阶段判断。 + +### 三、True Day（日内核心时段） + +True Day 的核心价值，是把“可执行时段”和“低效时段”分开。 +按 IPDA 的工作表达，日内存在更高可读性的核心交易时段，也存在可预测性下降的边缘时段。 +这不是让你机械看时间，而是让你把主要风险表达放在更有结构机会的窗口。 + +### 四、Weekly Range（周区间） + +Weekly Range 是周内从一个关键数组或流动性区，递送到另一个关键数组或流动性区的过程。 +它强调的是“周内任务推进”，而不是“周K涨跌结果”。 + +### 五、Daily Range（日区间） + +Daily Range 不是一个单点方向，而是一个阶段序列。 +在 ICT 的日内框架里，常见的阶段顺序是： + +1. 先平衡； +2. 再清理； +3. 后扩张； +4. 其间可能回补、重构、收束。 + +### 六、Time of Day 与 Kill Zone 的层级关系 + +Time Theory 是上层，Kill Zone 是下层执行窗口。 +先有时间骨架，后有会话触发；若颠倒顺序，交易会退化成“到点就做”。 + +### 七、时间一致性的最低标准 + +时间一致性并不要求每天走同一剧本，而要求三件事： + +1. 周内角色清晰； +2. 日内阶段可识别； +3. 触发发生在高质量时段。 + +--- + +## 31.4　底层逻辑 + +### 一、时间是触发概率分布，不是装饰变量 + +同样一个位置、同样一组结构，在不同时间窗口的执行质量会显著不同。 +这就是为什么“模型没变、表现却波动很大”常常是时间失配，而不是模型失效。 + +### 二、周内路径不是均匀推进 + +周内交易最大的错误之一，是把每一天看成同等权重。 +更成熟的处理是：先定义本周主任务，再判断当前日子在这条任务链里的角色。 +这能显著减少“当天波动很大但并不服务主任务”导致的误做。 + +### 三、True Day 的核心价值是过滤低效试错 + +多数账户回撤不是来自一次大错，而是来自大量低质量时段的小亏损。 +True Day 的意义，就是把主要风险表达集中到更有概率发生有效递送的时段，把其余时段降频管理。 + +### 四、Daily Range 必须按阶段读，不可按结果读 + +很多人只看“今天涨还是跌”，忽略“今天是如何涨跌”。 +而执行层真正有价值的是阶段顺序：平衡何时结束、清理何时发生、扩张何时确认、回补何时进入。 +阶段读图会直接改善持仓管理与止盈节奏。 + +### 五、时间理论不会替代结构确认 + +时间窗口只能提高机会质量，不能替代结构证据。 +“到点”不是入场理由，“到点且结构成立”才是入场理由。 + +### 六、时间与会话交接是误判高发区 + +会话切换前后（尤其数据窗口附近）常出现叙事重估需求。 +若此时仍按旧计划机械执行，最容易把回补当反转，或把诱导当延续。 + +### 七、成熟标准是“时间驱动的执行降级机制” + +当时间条件不足时，系统应自动降级： + +1. 减少频率； +2. 降低仓位； +3. 提高确认门槛。 + +这比“任何时段都找机会”更能保护长期曲线。 + +--- + +## 31.5　结构关系 + +### 一、承接第30章 + +第30章解决跨市场过滤，本章解决时间过滤。 +两者共同构成“执行前质量门槛”。 + +### 二、通向第32章 + +本章给时间骨架，第32章将下钻到 Asian/London/New York 与 Kill Zones 的会话分工。 + +### 三、通向第33章 + +有了时间骨架后，第33章才能进一步讨论 CBDR、ADR、标准差与日内投影。 + +### 四、与第24—26章关系 + +Narrative、Bias、范式只有放进时间骨架，才会从“方向正确”走向“节奏正确”。 + +### 五、与后续模型章节关系 + +后续所有日内模型都应把“时间条件”写进 Condition，而不是仅写价格条件。 + +--- + +## 31.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：日区间按阶段推进。** +先出现平衡段，随后发生一侧清理，再出现扩张，之后进入回补或收束。 +这类路径最适合做“阶段化执行”，不适合做“单点预测”。 + +**标准情境B：周内先推进后兑现。** +周前半形成方向证据，周后半更多出现再平衡与管理动作。 +若持续按“周前半强推进思维”做到周后半，执行质量通常下降。 + +**标准情境C：方向对但时段错。** +交易者看对 Bias，却在低效时段频繁试错，真正窗口到来时已损耗过大。 +这类亏损的根源是时间管理，而不是方向判断。 + +**反例情境：到点即入场。** +把时间窗口当成入场按钮，忽略结构是否已就绪，通常会在高波动噪音中被动止损。 + +### 二、交易中的真实表现 + +实盘分水岭往往不在“能否看懂走势”，而在“是否能在合适时段保持耐心、在合适窗口果断执行”。 +Time Theory 的价值，正是在这一步建立纪律。 + +--- + +## 31.7　执行意义 + +本章可落地为“周内-日内-会话”三层时间执行卡。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：先写周内主任务与当日角色。 +2. 触发：限定 True Day 核心时段与关键会话窗口。 +3. 确认：窗口内必须出现结构证据，窗口外提高门槛。 +4. 执行：时间与结构共振时按标准风险执行。 +5. 退出：时间条件退化且结构未延续时主动降级。 + +### 二、时间评分建议（0—3） + +1. 是否处于周内关键阶段。 +2. 是否处于 True Day 核心时段。 +3. 是否处于高质量会话窗口。 + +评分高可标准执行，评分低应降频或旁观。 + +### 三、执行前六问 + +1. 今天在周内叙事里属于什么角色。 +2. 当前是否处于 True Day 核心时段。 +3. 当前阶段是平衡、清理还是扩张。 +4. 时间窗口与结构证据是否同向。 +5. 若窗口过后仍无证据，是否准备放弃。 +6. 本次执行是否可在盘后按时间链复现。 + +--- + +## 31.8　常见误区 + +### 误区一：把 Time Theory 当固定剧本 + +**识别信号：** 认为某个时段“必涨”或“必跌”。 +**纠偏动作：** 把时间当概率约束，不当方向承诺。 + +### 误区二：只看方向，不看 Day of Week + +**识别信号：** 每天都用同一执行强度。 +**纠偏动作：** 周内先分角色，再定执行强度。 + +### 误区三：忽略 True Day 边界 + +**识别信号：** 全天高频交易、无时段分层。 +**纠偏动作：** 把主要风险表达集中到核心时段。 + +### 误区四：到点即做，不等结构 + +**识别信号：** 时间到就进场，结构未确认。 +**纠偏动作：** 时间是门槛，不是按钮。 + +### 误区五：把 Daily Range 简化成“今天涨跌” + +**识别信号：** 只看结果，不看阶段。 +**纠偏动作：** 用阶段语言记录日内路径。 + +### 误区六：低质量时段不降级 + +**识别信号：** 明知窗口差仍维持高仓位。 +**纠偏动作：** 建立时间触发的自动降级规则。 + +--- + +## 31.9　高阶深化 + +### 一、高阶执行看的是“三层时间共振” + +成熟执行不是记住几个时间点，而是让三层同时对齐： + +1. 周内层（Day of Week）； +2. 日内层（True Day）； +3. 会话层（Kill Zone）。 + +三层同向，执行容错显著提高；三层冲突，最优动作通常是降级。 + +### 二、把时间一致性做成复盘指标 + +建议把“时间评分”写入每笔交易日志，并与盈亏结果联动统计。 +长期看，这会比主观回忆更快暴露你的时段弱点。 + +### 三、时间理论真正提升的是筛选质量 + +正确使用后，交易次数通常减少，但质量上升。 +若学习时间理论后反而交易更频繁，说明你把“时间过滤”误用成了“时间追单”。 + +### 四、统一工作公式 + +> Time Quality = Week Role Clarity × True Day Alignment × Session Window Readiness × Structure Confirmation + +--- + +## 31.10　本章总结 + +1. Time Theory 是 Price Delivery 的时间骨架，不是附加项。 +2. 交易周区间先看 Day of Week，交易日内先看 True Day 与会话窗口。 +3. Daily Range 应按阶段读取，不应简化为结果二元。 +4. 时间窗口提高概率，但不能替代结构确认。 +5. 本章为第32章会话执行模型提供上游框架。 + +--- + +## 31.11　训练清单 + +1. 观察任务：连续20个交易日记录“周内角色 + 时段评分 + 主要位移时间”。 +2. 标注任务：每笔交易补充时间评分，并与盈亏分布对照。 +3. 执行任务：低评分时段禁止主动重仓。 +4. 复盘任务：比较“同结构不同时间”的绩效差异。 +5. 达标标准：将“低质量时段冲动交易”比例压到30%以下并持续四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Day of Week、IPDA True Day、Daily Range 阶段分解与时间窗口约束的核心内容整理。 +[2] 文中时间评分与执行分级用于训练记录，不替代结构确认规则。 +[3] 延伸表达仅用于把时间理论转写为可执行模板，不改变原有语义边界。 + + + +# 第32章　Asian Range、London、New York 与 Kill Zones + +## 32.1　本章核心问题 + +第31章建立了 Time Theory 的上游框架。 +但进入日内执行后，交易者仍会遇到一个现实问题： + +**同一天里，不同会话到底谁负责清理，谁负责扩张，谁负责管理。** + +若这个问题不清楚，实盘会出现三类高频损耗： + +1. 在亚洲低波动阶段追价，频繁被噪音往返； +2. 在伦敦清理阶段误把第一段动作当主方向； +3. 在纽约主要波段接近尾声时才重仓追随。 + +因此，本章主问题是： + +**如何把 Asian Range、London、New York 与 Kill Zones 组织成一套“会话分工模型”，并接入执行流程。** + +围绕主问题，本章回答四个子问题： + +1. 三大会话在日内递送中分别承担什么任务。 +2. Kill Zone 的正确定位是什么。 +3. 会话切换时应如何重评叙事。 +4. 如何把会话模型写入仓位与退出管理。 + +--- + +## 32.2　一句话结论 + +会话不是简单时钟切片，而是日内递送分工：Asian Range 更常承担平衡与库存构建，London 更常完成清理与首段位移，New York 负责延续或重构；Kill Zone 的价值是提升触发质量，不是要求到点必做。 + +--- + +## 32.3　基础定义 + +### 一、Asian Range + +Asian Range 在日内结构中常扮演“平衡段”角色。 +它更像库存与边界构建区，而不是主趋势发动区。 +这也是为什么亚洲高低点在后续会话常成为流动性目标。 + +### 二、London Session + +London 会话常是当日第一段高质量位移窗口。 +在很多路径里，伦敦先完成一侧清理，再给出首段方向性扩张。 +因此，伦敦时段更适合观察“清理是否完成、位移是否成立”。 + +### 三、New York Session + +纽约会话不是单一“延续段”，而是“延续或重构段”。 +也就是说，纽约既可能接力伦敦方向，也可能对日内区间做完整重排。 +这要求交易者在会话切换时重新评估，而不是机械延续旧叙事。 + +### 四、Kill Zone + +Kill Zone 的本质是“高信息密度窗口”，不是“强制交易窗口”。 +在这个窗口里，结构变化与流动性事件更容易集中出现； +但是否执行，仍由结构证据决定。 + +### 五、Session High/Low + +亚洲、伦敦、纽约各自的高低点，本身就是流动性地图的一部分。 +它们既可作为当日目标，也可作为清理后观察接管的关键锚点。 + +### 六、会话切换区 + +伦敦尾段到纽约开盘前后，常是叙事重估高发区。 +此时最需要做的不是加快交易，而是提高确认门槛。 + +### 七、品种适配边界 + +会话模型的“分工思想”具有通用性，但参数细节需要按品种微结构调整。 +例如某些工具在外汇中表现更典型，在指数期货中需要结合对应市场节奏做适配。 + +--- + +## 32.4　底层逻辑 + +### 一、会话分工对应 Daily Range 阶段 + +把会话放入日区间阶段后，路径更清楚： + +1. Asian：平衡与边界； +2. London：清理与首段位移； +3. 纽约前后：回补或再组织； +4. New York：延续或重构； +5. 尾盘：收束与管理。 + +这样读盘，能显著减少“看到波动就追”的冲动。 + +### 二、Kill Zone 是执行放大器，不是独立信号 + +高质量交易并非“在 Kill Zone 发生”就成立，而是“在 Kill Zone 且结构成立”才成立。 +这就是时间与结构必须共振的根本原因。 + +### 三、会话切换是接力点，也是误判点 + +会话切换前后常伴随新闻窗口与流动性再分配。 +若仍用上一会话逻辑机械执行，最容易把过渡波动误判成趋势确认。 + +### 四、Bellwether 可以降低会话噪音 + +在指数日内执行中，用15分钟图先“框日内”，再下钻触发，能显著降低会话内噪音交易。 +这是一种先框架、后触发的执行秩序。 + +### 五、会话模型的核心作用是“风险分配” + +成熟交易者不会把每个会话当同等机会，而是根据会话质量分配风险： +高质量会话负责表达风险，低质量会话负责管理风险。 + +### 六、午盘与收束段的常见陷阱 + +当主要推进阶段结束后，市场常进入低效率整理。 +若此时仍按开盘阶段强度高频追单，长期回撤会明显上升。 + +### 七、会话模型的成功标准 + +会话模型并不追求“每个窗口都交易”，而追求两件事： + +1. 高质量窗口不缺席； +2. 低质量窗口少犯错。 + +--- + +## 32.5　结构关系 + +### 一、承接第31章 + +第31章回答“时间为什么重要”，第32章回答“时间如何分工”。 +本章是 Time Theory 的执行化章节。 + +### 二、通向第33章 + +第33章将在会话分工基础上继续量化日内空间，展开 CBDR、ADR、标准差与轮廓投影。 + +### 三、通向第34章 + +第34章将把事件窗口（经济日历、新闻解禁、开盘波动）并入会话模型，形成事件日执行框架。 + +### 四、与第30章关系 + +第30章给跨市场过滤，本章给会话内节奏过滤；二者共同约束“什么时候值得出手”。 + +### 五、与后续模型章节关系 + +后续日内模型都应明确：当前信号属于哪个会话阶段、会话质量评分是多少、执行强度该如何调整。 + +--- + +## 32.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：伦敦清理后纽约延续。** +亚洲先形成范围，伦敦先处理一侧流动性并形成首段位移，纽约接力完成当日主目标。 + +**标准情境B：伦敦先走、纽约重构。** +伦敦方向先扩张，纽约并不延续，而是完成对日区间的反向重排。 +这说明纽约会话必须重新评估，不应机械跟随伦敦。 + +**标准情境C：Kill Zone + 结构共振。** +当关键数组、结构证据与 Kill Zone 同时满足时，执行质量通常显著提升。 + +**反例情境：到点即做。** +只因进入窗口就开仓，忽略结构状态，常在会话噪音段连续试错。 + +### 二、交易中的真实表现 + +会话模型最直接的提升，不是让你做更多交易，而是让你在正确时段“更敢做”，在低效时段“更敢等”。 +这会直接改善交易节奏与心态稳定性。 + +--- + +## 32.7　执行意义 + +本章可落地为“会话执行模板”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：盘前写主叙事与当日主次目标。 +2. 触发：先标亚洲范围与三大会话高低。 +3. 确认：在关键会话窗口等待清理与位移证据。 +4. 执行：会话与结构共振时按标准风险执行。 +5. 退出：进入低效率会话段后优先管理仓位，不盲目新增风险。 + +### 二、会话评分建议（0—4） + +1. 是否处于关键会话窗口。 +2. 是否完成会话级流动性清理。 +3. 是否出现结构接管或有效位移。 +4. 是否与当日叙事同向。 + +评分高可标准执行，评分低应降级。 + +### 三、执行前六问 + +1. 当前属于哪一会话阶段。 +2. 当前会话任务是清理、扩张还是管理。 +3. 是否已完成一侧流动性处理。 +4. 会话切换是否触发叙事重估。 +5. 当前仓位强度是否与会话质量匹配。 +6. 若会话进入低效率段，是否有降频计划。 + +--- + +## 32.8　常见误区 + +### 误区一：把 Kill Zone 当“必须做单时间” + +**识别信号：** 到点即开仓。 +**纠偏动作：** Kill Zone 只提高可能性，不替代结构确认。 + +### 误区二：把亚洲波动当主趋势 + +**识别信号：** 亚洲段频繁追单。 +**纠偏动作：** 亚洲优先做范围与库存观察，不急于方向押注。 + +### 误区三：忽略会话高低点流动性 + +**识别信号：** 盘中不记录会话高低。 +**纠偏动作：** 将三大会话高低写入固定观察清单。 + +### 误区四：会话切换不重估 + +**识别信号：** 伦敦逻辑机械沿用到纽约。 +**纠偏动作：** 会话切换时强制重评叙事与路径。 + +### 误区五：午盘继续高频冲动 + +**识别信号：** 主波段结束后仍维持开盘强度。 +**纠偏动作：** 午盘转入管理模式，非必要不新增风险。 + +### 误区六：模板机械套用 + +**识别信号：** 不分品种、不分市场微结构。 +**纠偏动作：** 保留分工原则，参数按品种适配。 + +--- + +## 32.9　高阶深化 + +### 一、会话“角色化”是高阶分水岭 + +高阶交易者不会把会话当简单时间段，而是当任务段： + +1. Asian：建边界； +2. London：做清理； +3. New York：做确认或重构。 + +这种角色化思维能显著减少情绪型追单。 + +### 二、把会话质量写成仓位语言 + +成熟执行的关键不是“看懂会话”，而是“让仓位服从会话质量”。 +高质量会话承担有效风险，低质量会话承担风险管理。 + +### 三、会话模型与账户曲线稳定性 + +当会话模型真正落地后，最明显变化通常是： + +1. 低质量时段亏损减少； +2. 高质量时段收益集中； +3. 回撤峰值下降。 + +### 四、统一工作公式 + +> Session Edge = Session Role Clarity × Liquidity Event Quality × Structure Confirmation × Risk Allocation Discipline + +--- + +## 32.10　本章总结 + +1. Asian、London、New York 在日内递送中有稳定分工。 +2. Kill Zone 的价值在于提高质量，不在于到点必做。 +3. 会话高低点是流动性地图的重要组成。 +4. 会话切换必须重评叙事，不能机械延续。 +5. 本章为第33章空间投影与第34章事件窗口管理打下基础。 + +--- + +## 32.11　训练清单 + +1. 观察任务：连续20个交易日标注三大会话高低与主要位移会话。 +2. 标注任务：每笔交易记录会话评分与结构证据。 +3. 执行任务：会话评分≤1 时禁止新增重仓。 +4. 复盘任务：比较“会话共振交易”与“非共振交易”绩效。 +5. 达标标准：将“低评分会话强做”比例降到25%以下并持续四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Asian Range、London/NY 会话分工、Kill Zone 与会话高低点流动性的核心内容整理。 +[2] 文中会话评分、风险分配与降频规则用于执行流程化训练，不构成固定收益承诺。 +[3] 延伸表达仅用于把会话语义转写为可复盘模板，不改变原始语义边界。 + + + +# 第33章　CBDR、ADR Projections、Flout、Standard Deviations、Intraday Profiles + +## 33.1　本章核心问题 + +第31章解决了时间骨架，第32章解决了会话分工。 +但实盘里仍有一个高频难题： + +**知道方向，也知道时段，却不知道当天空间该如何量化。** + +这会直接导致两种常见损耗： + +1. 目标设得太近，趋势尚未完成就过早离场； +2. 目标设得太远，本可兑现的利润被全部回吐。 + +因此，本章主问题是： + +**如何把 CBDR、Flout、Standard Deviations、ADR Projections 与 Intraday Profiles 组织成同一套日内空间投影系统。** + +围绕这一主问题，本章回答四个子问题： + +1. 这五个模块各自的角色是什么。 +2. 它们如何串成一个统一流程。 +3. 如何把“空间判断”变成“分层兑现”。 +4. 当日内结构变化时，投影应如何动态重估。 + +--- + +## 33.2　一句话结论 + +CBDR、Flout、Asian Range 提供日内参考几何，Standard Deviations 提供推进阶梯，ADR Projections 提供当日外层边界，Intraday Profiles 提供路径节奏；五者联动后，目标管理才能从“感觉止盈”升级为“结构化兑现”。 + +--- + +## 33.3　基础定义 + +### 一、CBDR + +CBDR 位于时间理论链条中的执行层参考位。 +它不是独立策略，而是用来定义日内相对位置与投影起点的工作坐标。 + +### 二、Flout + +Flout 与 CBDR、Asian Range 同属日内参考尺度。 +它的价值不在单独预测，而在与其他尺度共同形成“重叠共振区”。 + +### 三、ADR Projections + +ADR 是当日平均波动范围的投影工具。 +它给交易者提供“当日外层边界”的概率参考，用于约束目标与风险，不用于机械反向。 + +### 四、Standard Deviations + +标准差在本章中的角色是“路径阶梯”。 +入场前看重叠，持仓后看推进： + +1. 入场前：观察多尺度标准差是否共振； +2. 持仓中：沿标准差阶梯评估目标是否可持续推进。 + +### 五、Intraday Profiles + +Intraday Profiles 用来描述日内轮廓节奏。 +它告诉你“路径可能如何展开”，而不仅是“目标在哪里”。 + +### 六、五模块的链式关系 + +这五者不是并列孤岛，而是一条链： + +1. 时间与会话先给执行窗口； +2. CBDR/Flout/Asian 给参考几何； +3. 标准差给推进层级； +4. ADR 给外层边界； +5. Intraday Profile 决定路径节奏。 + +### 七、边界条件 + +任何投影都必须服从结构状态。 +当日内出现明显重构或收束，原投影应降级重算，而不是机械坚持旧目标。 + +--- + +## 33.4　底层逻辑 + +### 一、这套系统解决的是“空间纪律” + +多数执行失败并非方向错误，而是目标管理失序。 +本章的核心作用，就是把“做到哪里、分几步做”写成规则，而不是情绪决定。 + +### 二、入场共振比单点触碰更重要 + +单一参考位触碰很常见，真正有执行价值的是多参考尺度重叠。 +当 Asian Range、CBDR、Flout 的标准差带在同一价格区附近形成重叠，入场质量通常更高。 + +### 三、标准差让“持有”从主观变成结构化 + +没有标准差阶梯时，持仓管理通常只有两种极端： + +1. 太早走； +2. 死扛不走。 + +有了标准差阶梯，持仓可按“阶段兑现—保留扩展”进行，更容易稳定收益曲线。 + +### 四、ADR 是边界参考，不是反转按钮 + +ADR 的正确用法是“约束预期”。 +当价格接近 ADR 边界，应先评估： + +1. 是否与对侧数组共振； +2. 是否仍有结构推进证据； +3. 是否进入低效率会话段。 + +而不是机械反手。 + +### 五、Intraday Profiles 决定“到达方式” + +同样目标位，可能早盘直达，也可能午盘回补后再达。 +因此目标管理必须与日内轮廓同步更新，而不是只盯终点。 + +### 六、动态重估是系统生存条件 + +若纽约时段出现日内重构，或市场进入明显收束，原本的标准差投影与 ADR 预期应立即降级。 +坚持静态目标通常会放大利润回吐。 + +### 七、空间系统的核心收益 + +这套系统真正带来的不是“更精准预测”，而是： + +1. 提前知道哪里该减仓； +2. 知道何时保留扩展仓位； +3. 知道何时放弃过度期待。 + +--- + +## 33.5　结构关系 + +### 一、承接第32章 + +第32章给会话分工，本章给会话内空间投影。 +两章合在一起，形成“时段+空间”的日内执行底盘。 + +### 二、通向第34章 + +第34章会加入经济日历与新闻窗口，处理事件日对投影系统的冲击与重估。 + +### 三、通向第35章 + +第35章 Daily Range Model 将把本章空间投影并入完整日内阶段模型。 + +### 四、与第6章关系 + +本章的分层兑现思路与“先内部后外部”的目标管理逻辑一致，只是把其细化到日内空间尺度。 + +### 五、与后续风控章节关系 + +本章提供的是目标管理语言，后续风控章节将把这套语言进一步量化到仓位与回撤控制。 + +--- + +## 33.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：多尺度共振入场。** +价格回到关键数组后，Asian/CBDR/Flout 标准差带在同一区域重叠，随后出现顺叙事位移。 +这类样本通常优于单线触发。 + +**标准情境B：阶梯推进到外层边界。** +入场后沿标准差阶梯推进，最终与 ADR 边界及对侧数组形成共振，作为主兑现区。 + +**标准情境C：轮廓变化导致中途重估。** +原本顺畅推进在会话转换后转入收束，交易者主动下调扩展目标，先锁定已实现收益。 + +**反例情境：只画一条线就下单。** +忽略多尺度共振与会话轮廓，常导致“看似有位置，实则噪音区”反复止损。 + +### 二、交易中的真实表现 + +实盘里，真正难的不是找一个目标，而是管理“目标之间的顺序和概率”。 +本章体系的意义，就是让你从单点止盈升级到分层兑现。 + +--- + +## 33.7　执行意义 + +本章可落地为“日内空间投影五步法”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：先有上游叙事与最低风险收益空间。 +2. 触发：价格进入关键数组并靠近多尺度参考区。 +3. 确认：标准差共振与会话结构同步成立。 +4. 执行：按阶梯目标分批管理，不设单点幻想终点。 +5. 退出：若轮廓重构或收束确认，立即降级扩展目标。 + +### 二、三层目标建议 + +1. T1：最近结构性兑现位（先锁仓）。 +2. T2：ADR 与对侧数组共振区（主目标）。 +3. T3：若结构延续，再按新标准差阶梯外推。 + +### 三、执行前六问 + +1. 当前是否处于高质量会话窗口。 +2. 是否出现多尺度共振。 +3. 当前推进是否仍符合日内轮廓。 +4. 目标是否有 ADR 与数组共振支持。 +5. 若路径转入收束，如何降级。 +6. 本次止盈是否分层，而非单点。 + +--- + +## 33.8　常见误区 + +### 误区一：把 ADR 当必到硬边界 + +**识别信号：** 一靠近 ADR 就机械反手。 +**纠偏动作：** ADR 先做边界约束，再看结构与数组共振。 + +### 误区二：只用单一参考线触发 + +**识别信号：** 不看重叠共振，只看单点触碰。 +**纠偏动作：** 恢复多尺度共振确认流程。 + +### 误区三：忽略 Intraday Profiles + +**识别信号：** 午盘与收束段仍按开盘节奏重仓追单。 +**纠偏动作：** 把轮廓阶段写入仓位强度规则。 + +### 误区四：目标只设一个点 + +**识别信号：** 过早平仓或利润全吐。 +**纠偏动作：** 使用 T1/T2/T3 分层兑现。 + +### 误区五：空间不足仍强做 + +**识别信号：** 长期低风险收益比样本占比过高。 +**纠偏动作：** 达不到最低空间阈值时旁观。 + +### 误区六：日内结构重构后不重算投影 + +**识别信号：** 市场已变，目标不变。 +**纠偏动作：** 会话重构触发动态重估机制。 + +--- + +## 33.9　高阶深化 + +### 一、高阶用法是“动态地图” + +成熟交易者不会把投影当静态终点，而会在会话推进中持续更新： + +1. 共振带是否迁移； +2. 阶梯推进是否完整； +3. ADR 剩余空间是否仍支持持有。 + +### 二、把空间系统写成仓位系统 + +本章最强的落地点不是“画得更准”，而是“仓位更稳”： + +1. 共振高时允许标准风险； +2. 共振弱时自动降级； +3. 轮廓收束时优先保收益。 + +### 三、从“找点”升级为“管曲线” + +这套系统最终服务的是账户曲线稳定性。 +它通过分层兑现与动态降级，减少“大幅回吐”的情绪破坏。 + +### 四、统一工作公式 + +> Intraday Projection Quality = Multi-Scale Confluence × Profile Alignment × Deviation Ladder Integrity × ADR Boundary Discipline + +--- + +## 33.10　本章总结 + +1. CBDR、Flout、标准差、ADR、Intraday Profiles 属于同一投影系统。 +2. 多尺度共振优于单点触发。 +3. 标准差阶梯与 ADR 共振可把目标管理结构化。 +4. 会话轮廓决定到达方式，必须动态重估。 +5. 本章完成“时间会话”到“空间兑现”的执行桥接。 + +--- + +## 33.11　训练清单 + +1. 观察任务：连续20个交易日记录 CBDR/Flout/Asian 三尺度共振带。 +2. 标注任务：每笔交易写 T1/T2/T3 达成情况与会话阶段。 +3. 执行任务：未出现多尺度共振时禁止重仓。 +4. 复盘任务：比较“单线触发”与“共振触发”绩效差异。 +5. 达标标准：将“无共振强做”比例降至20%以下并持续四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 CBDR、Asian Range、Flout、Intraday Profiles、ADR Projections 与标准差路径的核心模块整理。 +[2] 文中共振评分、目标分层与降级规则用于执行流程化训练，不替代结构与时段确认。 +[3] 延伸表达仅用于把空间投影方法转写为可复盘流程，不引入框架外定义。 + + + +# 第34章　Economic Calendar、News Embargo 与 Opening Volatility + +## 34.1　本章核心问题 + +前一章我们完成了常态日内的空间投影。 +但一到数据日，许多交易者会立刻失去节奏： + +1. 新闻前提前押方向，被第一段假动作清理； +2. 新闻后追第一段冲动，随后被回补吞没； +3. 明明知道事件会放大波动，却没有把事件条件写进执行规则。 + +因此，本章主问题是： + +**如何把 Economic Calendar、News Embargo 与 Opening Volatility 纳入同一套事件日执行框架，使“事件窗口”成为风险控制条件，而不是方向赌博入口。** + +围绕主问题，本章回答四个子问题： + +1. 经济日历在 ICT 执行里应该扮演什么角色。 +2. News Embargo 为什么常成为日内阶段切换点。 +3. 00:00 与 8:30 开盘锚点该如何使用。 +4. 如何把“事件—会话—结构”整合成可复盘流程。 + +--- + +## 34.2　一句话结论 + +经济日历负责“提前标注风险时段”，News Embargo 负责“提示波动注入窗口”，Opening Volatility 负责“识别假动作高发区”；三者都属于执行过滤层，不属于方向预测层。 + +--- + +## 34.3　基础定义 + +### 一、Economic Calendar（经济日历） + +经济日历在本书中的定位是“事件时间地图”。 +它的作用是提前标注哪些时段可能出现波动注入与叙事重估，而不是告诉你数据后一定涨或跌。 + +### 二、News Embargo（新闻解禁窗口） + +News Embargo 是指关键数据窗口前后，市场从等待状态转入信息释放状态的阶段。 +这类窗口常伴随位移突然放大，也常伴随方向假动作。 + +### 三、Opening Volatility（开盘波动锚） + +在日内事件框架中，00:00 与 8:30 是两个重要观察开盘锚。 +围绕这些锚点的反向穿越、收回、再位移，常为当日“诱导段与确认段”的区分提供线索。 + +### 四、Judas 与事件窗口 + +Judas 的核心不是“阴谋叙事”，而是“先错位再递送”。 +在事件窗口附近，这类先反向清理再走主路径的行为更常见，因此更需要先等确认、后做执行。 + +### 五、会话联动 + +事件窗口从来不是孤立事件，它总嵌在会话切换中。 +因此，任何新闻交易都应同时回答：当前属于哪个会话阶段，会话任务是清理、扩张还是管理。 + +### 六、No-Trade 或降频窗口 + +高波动不等于高质量机会。 +在低效率时段（如部分午盘阶段）继续维持开盘强度执行，长期往往放大回撤。 + +### 七、事件日与常态日的边界 + +事件日并不意味着“策略重写”，而意味着“确认门槛提高”。 +常态日模型仍可使用，但必须增加事件条件与降级规则。 + +--- + +## 34.4　底层逻辑 + +### 一、事件不会替代结构，但会重排节奏 + +新闻本身不提供稳定方向，真正有价值的是它对“节奏”的影响： + +1. 何时从整理转入位移； +2. 何时从延续转入回补； +3. 何时必须重估原叙事。 + +### 二、窗口前后通常是“先清理、后选择” + +事件前后最常见的并不是直线单边，而是先清理近侧流动性，再决定是否真正接管方向。 +因此，第一段动作通常不应直接视为最终方向。 + +### 三、开盘锚点是识别假动作的工作坐标 + +当价格围绕 00:00 或 8:30 发生反向穿越后迅速回收，常提示“诱导段仍在进行”。 +只有在后续位移与结构证据出现后，才进入执行权限提升阶段。 + +### 四、事件窗口必须与会话分工合并读取 + +同样一次数据波动，若发生在会话启动段与发生在会话尾段，执行意义完全不同。 +不做会话合并，新闻交易容易退化为追第一根大K线。 + +### 五、边界条件：高波动不等于高赔率 + +事件日最常见误区是“波动大=机会大”。 +事实上，高波动也可能意味着高噪音。 +若结构证据不足，最优动作常常是降低频率而非提高频率。 + +### 六、事件日的核心目标是“先活下来，再放大” + +稳定账户首先依赖风险纪律。 +在事件窗口内，保留“等待确认”的能力，比抢第一段波动更重要。 + +### 七、事件框架的最终价值 + +它让你从“新闻反应型交易”转向“条件触发型交易”： + +1. 先写事件条件； +2. 再等结构确认； +3. 最后才执行风险表达。 + +--- + +## 34.5　结构关系 + +### 一、承接第33章 + +第33章给出常态日内投影，本章补上事件日重估机制。 +两章合并后，日内系统才具备“常态+事件”双模式能力。 + +### 二、通向第35章 + +第35章 Daily Range Model 将把平衡—操纵—扩张与事件窗口正式整合到同一模型里。 + +### 三、通向第36章 + +第36章 Intra-day Order Flow 将进一步处理事件后多分支路径的执行分配。 + +### 四、与第31—32章关系 + +第31章给时间骨架，第32章给会话分工，本章给事件注入条件。 +三章共同构成时间执行体系。 + +### 五、与风控章节关系 + +事件窗口的降级规则将直接影响仓位、回撤与账户生存，这一点会在后续风险章节系统化展开。 + +--- + +## 34.6　图表中的真实表现 / 交易中的真实表现 + +### 一、图表中的真实表现 + +**标准情境A：窗口前整理、窗口后注入。** +价格在数据前进入压缩，数据后释放波动并给出位移或重构。 +这类路径中，“窗口后确认”显著优于“窗口前押注”。 + +**标准情境B：先诱导再递送。** +围绕开盘锚点先出现反向清理，随后才出现与主叙事一致的扩张。 +若只做第一段，通常容易被反向洗出。 + +**标准情境C：事件后进入低效率段。** +主要波段完成后市场转入收束，继续高频追单常导致利润回吐。 + +**反例情境：把新闻当方向按钮。** +数据一出即追第一段波动，忽略结构确认与会话位置，长期执行质量通常不稳定。 + +### 二、交易中的真实表现 + +实盘里，事件日的核心挑战从来不是“看新闻”，而是“守纪律”。 +谁能把事件窗口写成规则，谁就更容易在高波动环境下保持稳定。 + +--- + +## 34.7　执行意义 + +本章可落地为“事件日执行五步法”。 + +### 一、五步流程（条件—触发—确认—执行—退出） + +1. 条件：盘前标注当日关键事件时间与会话位置。 +2. 触发：观察事件前后是否出现流动性清理与开盘锚点偏离。 +3. 确认：等待位移与结构接管证据，不追第一段冲动。 +4. 执行：时间、结构、会话三者共振时才按标准风险执行。 +5. 退出：事件后若转入低效率阶段，优先管理仓位并降频。 + +### 二、事件日最小计划模板 + +1. 今日关键事件与时间。 +2. 事件前允许动作与禁止动作。 +3. 事件后确认条件。 +4. 失败后降级动作。 +5. 午盘/尾盘风险管理规则。 + +### 三、执行前六问 + +1. 我是在预测新闻，还是在执行条件。 +2. 当前会话任务是什么。 +3. 开盘锚点是否出现异常穿越与回收。 +4. 是否已有结构接管证据。 +5. 当前仓位是否与事件风险匹配。 +6. 若无确认，是否愿意主动放弃交易。 + +--- + +## 34.8　常见误区 + +### 误区一：把经济日历当方向预测工具 + +**识别信号：** 数据前固定押单边。 +**纠偏动作：** 把日历用于风险前置，不用于方向拍板。 + +### 误区二：忽略 News Embargo 窗口 + +**识别信号：** 事件前后仍按常态时段规则执行。 +**纠偏动作：** 事件窗口前降频，窗口后重估。 + +### 误区三：只看新闻，不看开盘锚点 + +**识别信号：** 对 00:00 与 8:30 的相对位置没有记录。 +**纠偏动作：** 将双开盘锚写入日内固定观察项。 + +### 误区四：事件后追第一段大K线 + +**识别信号：** 频繁追高追低后被回补打掉。 +**纠偏动作：** 必须等待位移延续或结构接管确认。 + +### 误区五：事件日全天高频 + +**识别信号：** 午盘和尾盘仍维持开盘执行强度。 +**纠偏动作：** 进入低效率阶段后转入管理模式。 + +### 误区六：事件窗口与会话分工脱节 + +**识别信号：** 只看新闻时间，不看会话阶段。 +**纠偏动作：** 任何事件决策都要标注会话位置与会话任务。 + +--- + +## 34.9　高阶深化 + +### 一、高阶处理是“事件条件化”，不是“新闻投机化” + +成熟交易者会提前写好 if-then 分支： + +1. 若先清理后回收，则等待反向接管； +2. 若直接位移并守住关键区，则按延续处理； +3. 若反复穿越锚点无接管，则降频旁观。 + +### 二、建立事件-时段-结构三维矩阵 + +每笔事件交易建议记录三类标签： + +1. 事件强度； +2. 会话阶段； +3. 结构状态。 + +三维同向才提升强度，冲突则主动降级。 + +### 三、把事件纪律纳入账户生存系统 + +事件日最常见的大回撤，不来自“看错方向”，而来自“在无确认的高波动里放大风险”。 +把确认门槛前置，是事件日保护账户的核心动作。 + +### 四、统一工作公式 + +> Event-Day Execution Quality = Calendar Preparedness × Session Context × Post-Embargo Structure Confirmation × Risk Downgrade Discipline + +--- + +## 34.10　本章总结 + +1. 经济日历用于风险前置，不用于方向拍板。 +2. News Embargo 是波动注入与叙事重估高发窗口。 +3. 00:00 与 8:30 开盘锚点有助于识别诱导段与确认段。 +4. 事件日执行必须遵守“窗口后确认、会话联动、低效降频”。 +5. 本章完成常态日内模型向事件日模型的升级。 + +--- + +## 34.11　训练清单 + +1. 观察任务：连续20个事件日记录“事件时间—开盘锚点—会话位置—结构变化”。 +2. 标注任务：每笔事件交易记录是否等待窗口后确认。 +3. 执行任务：窗口前禁止重仓，窗口后无确认禁止追单。 +4. 复盘任务：比较“预测式新闻交易”与“条件式事件交易”绩效差异。 +5. 达标标准：将“窗口前冲动入场”比例降至15%以下并持续四周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于经济日历、新闻解禁窗口、00:00/8:30 开盘锚点与 Judas 假动作的核心内容整理。 +[2] 文中窗口纪律、会话降级与执行模板用于风险管理训练，不构成事件预测承诺。 +[3] 延伸表达仅用于把事件日规则转写为可复盘流程，不改变原始框架边界。 + +# 第七部分　模型层：从日内到波段 + +前六部分提供了完整语言系统。 +第七部分开始把语言系统压缩成可执行模型： + +**同一套框架，如何在不同周期、不同任务下稳定复用。** + +--- + +## 本部分定位 + +本部分核心目标是“模型化”而不是“再堆术语”： + +1. 日内模型如何按阶段执行； +2. 会话模型如何与目标管理联动； +3. 波段模型如何与周内节奏结合； +4. 模型间如何切换而不冲突。 + +--- + +## 六章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第35章 | Daily Range Model：平衡-诱导-扩张如何落地 | +| 第36章 | Intra-day Order Flow 与 OSOK 执行模块 | +| 第37章 | Internal/External Range Liquidity 模型与目标管理 | +| 第38章 | Power of 3 的日内路径与执行边界 | +| 第39章 | Market Profile 与纽约 AM/PM 机会分工 | +| 第40章 | Swing Trading Model：从日内过渡到周内 | + +--- + +## 学习边界 + +第七部分最容易误学成“模板背诵”。 +请固定原则： + +**模型是条件系统，不是固定剧本。** + +任何模型都必须写清启动条件、失效条件与降级动作。 + +--- + +## 学完应具备 + +完成第七部分后，你应能： + +1. 在日内和波段之间做模型级切换。 +2. 把目标与退出写成分层动作。 +3. 在会话变化中保持执行一致性。 +4. 用模型日志替代情绪化复盘。 + +--- + +## 与后续章节的连接 + +第八部分将进入精密执行与市场应用， +把模型能力升级为跨市场可迁移的执行能力。 + +--- + +## 章末注释 + +[1] 本导读用于连接第六部分的过滤体系与第七部分的模型落地。 +[2] 建议进入第八部分前，先复核第35章与第37章的执行五步流程。 + + + +# 第35章　Daily Range Model：Equilibrium、Manipulation、Expansion + +## 35.1　本章核心问题 + +前面的章节已经把时间窗口、会话节奏、日内空间投影和新闻过滤建立起来了，但在真实执行中，交易者仍然会反复遇到同一个问题： + +**同样是一天的行情，为什么有人能把“当天主段”抓出来，有人却在同一天里反复被洗？** + +问题的根源通常不是“缺少信号”，而是缺少对**日内阶段顺序**的稳定识别。若不先识别当日阶段，后续任何入场触发都可能被放错语境。 + +本章只解决一个主问题： + +**如何把 Daily Range 写成一个可识别、可执行、可失效的阶段模型。** + +围绕该主问题，本章回答四个子问题： + +1. Daily Range 为什么不能只用“看涨/看跌”二分法理解。 +2. `Equilibrium -> Manipulation -> Expansion` 为什么是日内执行主骨架。 +3. 为什么扩张之后会分化为延续、回撤或反向接管。 +4. 如何把该模型转化为“条件—触发—确认—执行—退出”的流程。 + +## 35.2　一句话结论 + +Daily Range 的核心不是预测收盘，而是识别“平衡—诱导—扩张—收束”的阶段切换；只有在阶段证据成立时才表达风险，阶段退化后应立即转入防守管理。 + +## 35.3　基础定义 + +### 一、Daily Range Model（当日区间形成模型） + +在两份课程内容中，日内结构被反复描述为一个有顺序的形成过程，而不是一段随机波动。可执行上，可将其写成： + +`Price Equilibrium -> Manipulation -> Expansion -> (Retracement / Reversal) -> Consolidation` + +这条顺序的意义是：先建立当天价格交换框架，再完成流动性清理，随后才出现真正值得交易的方向表达。 + +### 二、Price Equilibrium（平衡段） + +平衡段是当日模型的起点。日内常见表现是亚洲时段先形成一段可观察的窄幅区间，价格在其中完成库存准备与边界锚定。 + +平衡段的核心功能不是给方向，而是给后续阶段提供三个参考： + +1. 当天的初始高低边界； +2. 后续诱导动作可能发生的近侧流动性； +3. 扩张是否真实的对照基线。 + +没有平衡段，后面“诱导是否成立、扩张是否有效”都容易失去参照。 + +### 三、Manipulation（诱导段） + +诱导段常出现在关键时段附近，尤其是新闻禁运解除和开盘前后。课程内容反复强调：8:30 附近的波动注入与 9:30 开盘流动性激活，常使价格先走一段反向动作。 + +这段反向动作常被称为 Judas Swing，本质是： + +- 先处理近侧流动性； +- 再为真正方向递送腾出路径。 + +因此诱导段不是“模型噪音”，而是模型本身。 + +### 四、Expansion（扩张段） + +扩张段指价格快速离开均衡区并显示再定价意愿。其可执行意义在于： + +1. 它把“猜方向”升级为“有证据的方向表达”； +2. 它决定后续可否进入趋势跟随或分层兑现。 + +没有有效扩张，交易通常仍处在区间内部博弈。 + +### 五、Retracement / Reversal（扩张后的分支） + +扩张发生后并不意味着“全天单边已锁定”。当日路径通常会分化为两条主分支： + +1. **Retracement：** 同方向内部回补与再平衡； +2. **Reversal：** 原扩张被反向结构接管。 + +这意味着日内执行不是单线剧本，而是分支管理。 + +### 六、Consolidation / Holding Pattern（收束段） + +当当日主要区间逐步建立后，价格常进入收束阶段。课程内容明确指出，IPDA close 附近常见回到整理状态。 + +收束段的交易重点应从“扩大收益”切换为“保护收益”： + +- 降频； +- 降杠杆； +- 避免在低效率波动中回吐。 + +### 七、时间锚与日模型边界 + +在日模型语境中，有两个时间边界尤其关键： + +1. `00:00`（纽约时间）作为当日开盘语义锚； +2. `8:30`与`9:30`对应的波动注入窗口。 + +这些时间锚不是入场信号本身，而是“阶段切换更易发生”的条件带。 + +### 八、前日边界与当日阶段联动 + +在日模型实战中，前一日高低点常承担“阶段校验”功能： + +1. 当日若在关键窗口先处理前日一侧边界，再出现反向位移，通常更接近“先清理后递送”； +2. 当日若直接接受在前日边界外并持续推进，通常说明扩张强度高于回补需求； +3. 当前日边界处理行为与当日主叙事冲突时，应优先降级执行强度而不是强行解释。 + +这一步的作用是把“日模型阶段”与“跨日结构记忆”接起来，减少同一天里叙事频繁翻转的问题。 + +## 35.4　底层逻辑 + +### 一、日内交易本质是“阶段识别”，不是“方向竞猜” + +若只问“今天涨还是跌”，你会在全天任意位置寻找同一类信号；若先问“现在处在哪个阶段”，你会自然缩小执行窗口。 + +从执行结果看，阶段识别能力通常比单次方向判断更决定长期稳定性。 + +### 二、平衡段决定了当日语法 + +平衡段给出的是“语法起点”： + +- 哪些位置是近侧可清理流动性； +- 哪些位置是扩张后可能回补的区域； +- 何处算真正脱离均衡。 + +若跳过平衡段，后续往往把普通波动误判为结构事件。 + +### 三、诱导段是必要成本，不是失败信号 + +很多交易者在诱导段最容易犯错： + +1. 看到第一波反向动作就追； +2. 或看到反向动作就否定当天叙事。 + +更成熟的处理是：把诱导段视为“先清理再递送”的必要步骤，等待其完成后的结构确认。 + +### 四、扩张段才定义“可表达风险” + +扩张的价值不在于“K线更大”，而在于它提供了方向愿意被市场接受的证据。只有在这一步出现后，才有必要把风险从观察模式切换到执行模式。 + +### 五、扩张之后是管理问题，不是信仰问题 + +扩张后最常见错误是把初始方向神化为全天唯一方向。实际更常见的是： + +- 一段扩张； +- 一段回补； +- 再决定延续或切换。 + +因此执行者需要管理分支，而不是坚持单一叙事。 + +### 六、收束段决定账户曲线稳定度 + +很多账户回撤并非发生在“看错方向”，而发生在“方向看对后不愿收手”。当模型进入收束阶段却仍按开盘强度追单，常见结果是利润回吐。 + +### 七、首段失败不等于模型失效 + +日内经常出现“第一段扩张失败、第二段才形成主段”的情况。 +若把首段失败直接等同于全天叙事失效，常会导致两种错误： + +1. 在真正主段出现前提前放弃； +2. 因情绪补偿在次段过度追价。 + +更稳健的做法是把首段失败当作“阶段重置信号”：回到平衡与流动性状态再评估，而不是立刻改成反向信仰。 + +## 35.5　结构关系 + +1. 承接第31–34章： +第31–34章给出时间理论、会话结构、投影与事件过滤；本章把这些前置条件组织为单日阶段模型。 + +2. 通向第36章： +本章回答“今天处于哪一段”，第36章回答“在这一段里如何执行一次高质量风险表达（OSOK）”。 + +3. 通向第37–40章： +本章给出“形成路径”，第37–40章给出“目标兑现、PO3与会话模板、周内扩展”的执行深化。 + +## 35.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：看涨日的标准阶段链 + +1. 亚洲段先构建平衡； +2. 关键窗口先向下清理近侧流动性； +3. 伦敦至纽约前段出现向上扩张； +4. 纽约段完成回补后再推进； +5. 当日目标接近完成后进入收束。 + +这一链条常见于“先诱导后顺主叙事”的行情。 + +### 场景B：看空日的镜像链 + +1. 平衡段先形成； +2. 关键窗口先向上做假动作； +3. 随后向下扩张并服务下方目标； +4. 中后段进入回补与再推进； +5. 收束段降速。 + +### 场景C：扩张后反向接管 + +有些交易日会在扩张后出现反向夺回，这时日模型并未失效，而是进入分支切换。可执行关键不在“有没有反向K线”，而在“是否出现结构接管”。 + +### 反例场景：全天只用一种交易强度 + +最常见失败是：开盘段有效，午后仍用同样强度追击。结果通常不是错在方向，而是错在阶段。 + +## 35.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 盘前先写当日主叙事、主Draw、关键时段。 +2. **触发：** 观察是否出现平衡->诱导->扩张的切换证据。 +3. **确认：** 扩张后确认是回补延续还是反向接管。 +4. **执行：** 仅在阶段证据完整时入场，不在平衡中轴硬做方向。 +5. **退出：** 进入收束或关键结构退化时，主动降级风险。 + +### 阶段许可原则 + +- 未见扩张：以观察为主； +- 扩张成立：允许执行； +- 扩张退化：优先保护利润。 + +## 35.8　常见误区 + +误区1：把 Daily Range 学成固定剧本。 +识别信号：每天都期待同一顺序与同一幅度。 +纠偏动作：固定“阶段语法”，不固定“波动外观”。 + +误区2：把诱导段当失败。 +识别信号：第一段反向动作出现就推翻叙事。 +纠偏动作：先判断是否为近侧流动性清理，再判断失效。 + +误区3：没有扩张证据就重仓。 +识别信号：区间中段频繁试错。 +纠偏动作：把“有效扩张”设为执行许可门槛。 + +误区4：把新闻第一波当真方向。 +识别信号：8:30 第一根波动就追单。 +纠偏动作：窗口后看结构承接，不追第一波冲动。 + +误区5：忽略收束阶段。 +识别信号：当日目标已接近仍高频加仓。 +纠偏动作：收束段切换为利润保护模式。 + +## 35.9　高阶深化 + +### 一、阶段评分法 + +可把每笔交易先做三项评分： + +1. 是否处于有效阶段切换点； +2. 是否出现可验证扩张； +3. 是否与关键时间窗口共振。 + +评分低时降级风险，评分高时才允许标准执行。 + +### 二、“预测收盘”降级为“管理路径” + +高阶执行者不需要精确预测当日最低/最高与收盘位置，也能稳定盈利。关键在于： + +- 抓住扩张主段； +- 管理回补分支； +- 收束时保护利润。 + +### 三、阶段切换的失效边界 + +若扩张后无法保持关键结构、价格快速回到均衡中轴并失去继续推进能力，应把原叙事从“执行级”降为“观察级”。 + +## 35.10　本章总结 + +1. Daily Range 是阶段模型，不是涨跌标签。 +2. 平衡—诱导—扩张是日内执行主骨架。 +3. 扩张后必须管理分支，不可线性思维。 +4. 收束阶段的核心是保护已得收益。 +5. 本章为第36章 OSOK 模块提供上游框架。 + +## 35.11　训练清单 + +1. 观察任务：连续20个交易日标注平衡、诱导、扩张、回补/切换、收束五阶段。 +2. 标注任务：每笔交易记录“入场对应阶段”与“阶段许可证据”。 +3. 标注任务：统计8:30与9:30窗口内，第一波与第二波信号的质量差异。 +4. 执行任务：未出现扩张证据前，禁止标准仓位开仓。 +5. 执行任务：收束阶段只允许减仓与保护性管理。 +6. 复盘任务：比较“阶段共振交易”与“阶段错配交易”的R分布。 +7. 达标标准：将“无扩张先入场”比例降至20%以下，并稳定4周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF关于 Daily Range、IPDA、Judas Swing、会话时段与阶段顺序的共同语义整理。 +[2] 文中评分阈值、执行比例为训练用流程参数，需按交易品种与账户约束校准。 +[3] 建议与第31–34章、第36章联读，以保持时间—结构—执行语法一致。 + + + +# 第36章　Intra-day Order Flow 与 One Shot One Kill 执行模块 + +## 36.1　本章核心问题 + +第35章已经把“日模型阶段”讲清楚，但很多交易者的执行断层仍然发生在同一个位置： + +**知道今天大致怎么走，却不知道该在何时、何地、用什么强度去下这笔单。** + +这就是 Intra-day Order Flow 与 One Shot One Kill（OSOK）要解决的实务问题。若没有这层执行模块，常见后果是： + +1. 叙事正确，但入场点位持续劣化； +2. 会话方向看对，却被高频试错拉低收益质量； +3. 明明有主段，却在假动作阶段被反复清扫。 + +本章只解决一个主问题： + +**如何把“日内叙事”压缩成“可复制的一次高质量风险表达模块”。** + +围绕该主问题，本章回答四个子问题： + +1. Intra-day Order Flow 在执行中到底扮演什么角色； +2. OSOK 为什么是流程模块，而不是某个图形； +3. Bellwether、开盘锚点、Judas 与 3B Daily Bias 如何协同； +4. 如何在错过首笔后保持节奏，而不是情绪追单。 + +## 36.2　一句话结论 + +OSOK 的本质是“执行压缩”：先用 Intra-day Order Flow 定义当天主叙事，再用 Bellwether、会话窗口、开盘锚点与结构确认，把风险集中表达在少数高质量节点，而非全天随机表达。 + +## 36.3　基础定义 + +### 一、Intra-day Order Flow（日内订单流框架） + +在课程框架中，日内执行被明确组织为三件事： + +1. 设置 Daily Range； +2. 设置 Intra-day Layout； +3. 读取 Daily Profiles。 + +这三件事共同回答一个问题：**今天价格更可能向哪侧递送，以及通过哪条日内路径完成。** + +### 二、One Shot One Kill（OSOK） + +OSOK 的关键不是“只下一单”，而是“把当天主要风险预算集中到最完整的一次结构表达”。 + +在执行层，OSOK 反对两种行为： + +1. 无叙事高频点射； +2. 错过首笔后的情绪追价。 + +### 三、Bellwether（15分钟框架锚） + +课程中明确把 15 分钟图定义为 Bellwether，用来“frame your day”。 + +其职责是： + +1. 先给会话级上下文； +2. 再允许 1–5 分钟去做触发精细化； +3. 午盘阶段主动降频。 + +Bellwether 不是入场按钮，而是执行权限管理器。 + +### 四、3B Daily Bias（当日偏向三步） + +日内执行前的上游顺序保持不变： + +- B1：当前 Framework 是什么； +- B2：当前 Draw on Liquidity 是哪一侧； +- B3：当前 Dealing Range 处在 Premium 还是 Discount。 + +这三步决定“今天是否值得执行、该偏向哪边执行、应在哪类位置执行”。 + +### 五、开盘锚点（00:00 与 8:30） + +在日内模块里，`00:00`与`8:30`是两个高频使用的时间价格锚： + +1. 00:00 提供当日开盘语义； +2. 8:30 对应新闻禁运解除后的波动注入。 + +围绕这两个锚，假动作与主动作的分界往往更清晰。 + +### 六、Judas / Smokescreen（诱导段） + +课程明确指出，8:30 后的第一段波动常被用作 smokescreen。其可执行含义是： + +- 第一波不等于主方向； +- 先处理流动性，再观察结构接管。 + +### 七、CPE（Close Proximity Entries） + +当主叙事已成立但错过首笔时，CPE 用于“近距再参与”或“受控金字塔”。 + +CPE 的边界是： + +1. 只在 Objective 未达成时使用； +2. 只在结构前提未破坏时使用； +3. 只在风险递减时使用。 + +### 八、No-Trade 判定（执行权限的反面清单） + +OSOK 不仅定义“什么时候做”，也定义“什么时候不做”。 +当出现以下任一情形时，应主动进入 No-Trade 模式： + +1. 3B 未完成，主Draw不清； +2. 关键窗口后仍无有效接管证据； +3. 会话已进入低效率段且没有仓位管理需求。 + +把“不做”写进流程，是 OSOK 能长期稳定的必要条件。 + +## 36.4　底层逻辑 + +### 一、OSOK 的价值在于“减少错误表达次数” + +大多数交易损耗并非来自单笔大错，而来自大量中低质量试错。OSOK 通过流程筛选，把“可能做”压缩为“值得做”。 + +### 二、先有叙事，才有执行权限 + +日内执行的正确顺序是：Narrative -> Draw -> Bias -> Entry。 + +若顺序倒置，常见结果是： + +1. 先见信号再找理由； +2. 同一会话内方向反复切换； +3. 风险暴露远大于叙事确定度。 + +### 三、Bellwether 的功能是“组织噪音” + +若直接在低周期做决策，任何波动都像机会；若先由 15 分钟框架过滤，低周期才会退回“触发工具”角色。 + +### 四、Judas 让“真假动作”可区分 + +关键时段里最容易出错的，不是看不见机会，而是把诱导段当成主段。OSOK 的核心纪律是： + +- 不追第一波； +- 等处理后结构确认； +- 再做风险表达。 + +### 五、午盘规则是收益保护器，不是保守主义 + +课程明确把纽约午盘标为 no-trade 或低效率时段。其本质是降低无效交易频率，把风险预算保留给更清晰的会话段。 + +### 六、OSOK 是“当天管理系统”，不是“单次入场技巧” + +成熟执行不是做对一笔，而是管理一整天： + +1. 何时观察； +2. 何时执行； +3. 何时降频； +4. 何时停止。 + +### 七、错过首笔后的纪律比首笔本身更重要 + +实盘里最常见的破坏点不是首笔亏损，而是“错过后的补偿式交易”。 +因此 OSOK 必须额外规定：若首笔未参与，后续只能通过 CPE 或下一次完整确认链再入场，禁止在无确认尾段追价。 +这条规则直接决定了模型能否从“偶尔有效”变成“可持续有效”。 + +## 36.5　结构关系 + +1. 承接第35章： +第35章解决阶段识别，本章把阶段识别下沉为日内执行流程。 + +2. 通向第37章： +本章解决“怎么进”，第37章解决“怎么分层兑现（IRL/ERL）”。 + +3. 通向第41–42章： +后续 Precision 章节会把本章流程进一步升级为“结构同步 + 会话内多次再同步”。 + +## 36.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：Bearish OSOK 标准链 + +1. 盘前偏空，3B 支持下行； +2. 8:30 前后先向上清理近侧买方流动性； +3. 15分钟框架出现反向承压； +4. 低周期触发成立后入场； +5. 目标指向日内下方流动性或失衡带。 + +### 场景B：Bullish OSOK 镜像链 + +1. 盘前偏多，主Draw在上侧； +2. 开盘附近先向下做 Judas； +3. 收回关键位并形成向上接管； +4. 在有利时段完成入场与分层管理。 + +### 场景C：错过首笔后的 CPE 再同步 + +当主叙事未变且目标未达成时，可等待价格回到开盘范围附近的可执行区域，再做风险递减参与，而不是追单补错。 + +### 反例场景：把“会话波动”当“会话机会” + +最常见失败是：看到会话活跃就连续开仓。OSOK 的核心恰好相反——只在会话与结构同时共振时才执行。 + +## 36.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 盘前完成 3B，写清主叙事与主Draw。 +2. **触发：** 围绕 00:00 与 8:30 锚点观察是否出现流动性处理事件。 +3. **确认：** 15分钟先定框架，低周期只确认接管，不追第一波。 +4. **执行：** 仅在会话窗口 + 位置条件 + 结构条件同时成立时入场。 +5. **退出：** 午盘降频，目标达成或结构失效即执行既定退出。 + +### 风险分配原则 + +- 首笔未成立：不加大风险补错； +- 再参与：只允许风险递减； +- 会话退化：主动停止新增仓位。 + +## 36.8　常见误区 + +误区1：把 OSOK 当图形。 +识别信号：只看某个形态，不写叙事与时段。 +纠偏动作：恢复“叙事—时间—结构—执行”顺序。 + +误区2：没有 Daily Bias 就找入场。 +识别信号：盘中方向反复跳变。 +纠偏动作：先完成 3B，再下沉执行。 + +误区3：新闻第一波即追单。 +识别信号：8:30 后频繁被反抽。 +纠偏动作：先判定是否 Judas，再看接管证据。 + +误区4：忽略 Bellwether。 +识别信号：低周期交易频次高、质量低。 +纠偏动作：15分钟先框架，1–5分钟后触发。 + +误区5：错过首笔后情绪追价。 +识别信号：平均入场价持续恶化。 +纠偏动作：要么 CPE 再同步，要么放弃当次机会。 + +误区6：午盘继续进攻。 +识别信号：早盘利润在午盘回吐。 +纠偏动作：午盘改为管理仓位与等待。 + +## 36.9　高阶深化 + +### 一、OSOK 执行评分卡 + +每笔交易可做五项评分： + +1. Bias 清晰度； +2. 会话匹配度； +3. 流动性事件完整度； +4. 结构接管清晰度； +5. 失效边界清晰度。 + +低分机会降级观察，高分机会才允许标准风险。 + +### 二、同会话多机会排序 + +当会话内出现两到三次候选机会时，优先级不按“谁先出现”，而按： + +1. 与主Draw一致性； +2. 与关键数组重合度； +3. 失效边界可定义性。 + +### 三、从“做对一笔”到“管好一天” + +OSOK 的成熟标志不是单笔高R，而是： + +- 该做时果断； +- 不该做时旁观； +- 错过后不失序。 + +## 36.10　本章总结 + +1. Intra-day Order Flow 决定当天执行语境。 +2. OSOK 是流程模块，不是单一形态。 +3. 15分钟 Bellwether、3B 与开盘锚点共同构成执行上游。 +4. 诱导段只观察，确认段才执行。 +5. 本章为第37章目标分层与兑现管理提供入口。 + +## 36.11　训练清单 + +1. 观察任务：连续20个交易日完成 3B、Bellwether 与开盘锚点标注。 +2. 标注任务：每笔OSOK记录“会话时段、触发证据、失效点、评分”。 +3. 标注任务：分开统计“第一波追单”与“确认后入场”的绩效差异。 +4. 执行任务：评分低于3分的机会禁止标准仓位。 +5. 执行任务：午盘阶段仅允许管理动作，不允许新增高风险开仓。 +6. 复盘任务：比较“模块化执行”与“随机执行”的净值波动。 +7. 达标标准：将“无确认追单”比例压至20%以下并稳定4周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Bellwether、3B、8:30窗口、Judas、午盘规则与OSOK入口的共同语义整理。 +[2] 文中评分与阈值用于流程化训练，不构成收益承诺。 +[3] 建议与第35章、第37章联读，形成“阶段识别—执行压缩—目标兑现”完整链路。 + + + +# 第37章　Internal/External Range Liquidity 模型与 Profit Objective + +## 37.1　本章核心问题 + +第36章解决了日内高质量入场，但账户曲线的稳定性往往并不由入场决定，而由退出决定。现实中最常见的两类问题是： + +1. 方向看对却过早全平，主段收益拿不到； +2. 方向看对却执着终极目标，已得利润大幅回吐。 + +这两类问题都指向同一缺口： + +**没有把“目标”写成分层执行架构。** + +本章只解决一个主问题： + +**如何把 IRL/ERL 与 Profit Objective 组织成可执行、可管理、可复盘的目标系统。** + +本章回答四个子问题： + +1. IRL 与 ERL 在退出中的不同角色是什么； +2. 为什么“先内部、后外部”是更稳健的兑现结构； +3. Profit Objective 如何从主观预期升级为结构目标； +4. 目标未达成前如何管理仓位、止损与再参与。 + +## 37.2　一句话结论 + +Profit Objective 必须由上游 Draw on Liquidity 反推；执行上先在 IRL 完成部分兑现，再在 ERL 完成完整退出，并在目标未达成前保持叙事一致与风险递减管理。 + +## 37.3　基础定义 + +### 一、Draw on Liquidity 与目标来源 + +课程内容明确给出：高时间框架上的 Draw，主要落在两类对象上： + +1. Liquidity Pool； +2. Imbalance。 + +这意味着目标不是拍脑袋设定，而是从高周期叙事中“被派生”出来。 + +### 二、Internal Range Liquidity Exit（IRL Exit） + +IRL Exit 指在当前范围内部完成阶段性兑现。典型语境是： + +- 在折价区入场做多； +- 先把范围内部的溢价区失衡位或关键内部目标作为第一兑现层。 + +IRL 的目的不是结束交易，而是先把“确定性收益”锁进账户。 + +### 三、External Range Liquidity Exit（ERL Exit） + +ERL Exit 指在范围外部流动性完成最终兑现。典型语境是： + +- 已完成 IRL 部分兑现； +- 市场仍有能力去处理范围外部目标； +- 以 ERL 作为剩余仓位的完整退出层。 + +### 四、Profit Objective（目标架构） + +目标应被理解为“路径层级”，而不是“一个点”： + +1. O1：内部目标（保护收益）； +2. O2：外部目标（完成主兑现）； +3. O3：若 O2 被突破，按更高级 Draw 扩展。 + +### 五、目标一致性纪律（No Flip-Flop） + +课程内容反复强调：在目标被处理前，不应在目标方向上来回翻转。其本质是避免“噪音驱动下的频繁反手”。 + +### 六、目标未达成前的动态管理 + +当主结构仍有效时，价格回到 OB / Imbalance 一带，通常属于管理节点： + +- 可上移保护； +- 可做低风险再参与； +- 不应轻易把回补误判为叙事失效。 + +### 七、回测四问（目标管理数据化） + +课程在 IRL/ERL 模块给出四个高价值复盘问题： + +1. 入场回撤耗时多久； +2. 整笔交易耗时多久； +3. 触发发生在什么时间； +4. 最大回撤有多大。 + +### 八、保护位迁移（从生存到锁盈） + +分层目标如果没有保护位迁移，常会退化为“纸面分层”。 +实务上可把保护位分为三段： + +1. 入场后：以结构无效位为主； +2. IRL 触达后：保护位上移至成本附近或更优位置； +3. ERL 追踪中：按中期结构继续抬升，避免深度回吐。 + +这样可把“目标层级”与“风险层级”同步。 + +这四问直接决定你能否把目标管理从“感觉”升级为“统计规则”。 + +## 37.4　底层逻辑 + +### 一、先有目标，才有退出 + +没有目标层级，退出往往退化为情绪行为： + +- 见盈利就跑； +- 见回撤就怕； +- 见反弹就翻向。 + +目标层级的作用是让退出先于情绪发生。 + +### 二、IRL/ERL 是“概率—收益”平衡器 + +IRL 的可达性通常更高，ERL 的收益空间通常更大。把两者分开处理，可以同时解决： + +1. 过早全平导致的收益不足； +2. 过晚全平导致的回吐扩大。 + +### 三、目标一致性是执行稳定器 + +“目标未达成前不翻向”的纪律，不是固执，而是防止在噪音里丢失主叙事。只有当结构性失效出现时，才允许系统性重排目标。 + +### 四、目标管理必须容纳回补 + +即使价格仍朝主Draw推进，中途也可能出现犹豫K线或回撤。高质量管理不是要求“零回撤”，而是提前定义： + +- 哪类回补属于正常； +- 哪类回补属于失效。 + +### 五、再参与必须服从风险递减 + +课程给出典型递减序列（如 1% -> 0.5% -> 0.25%）的核心逻辑是： + +- 目标未达成前可加权； +- 每次新增暴露都要更谨慎。 + +这让再参与成为“提高效率”，而不是“加倍冒险”。 + +### 六、中期结构是持仓边界 + +只要中期关键结构仍在，主目标仍可持续跟踪；中期结构一旦失守，应立即降级目标并执行退出，不用主观希望替代客观边界。 + +### 七、ERL 未达时的提前退出条件 + +不是所有交易都会完整走到 ERL。 +当出现以下迹象时，应允许“未达ERL先退出”： + +1. 到达 IRL 后连续失去推进效率； +2. 中期结构出现反向接管证据； +3. 会话或周内节奏进入明显不利阶段。 + +这不是“放弃目标”，而是把“守纪律”放在“追终点”之前。 + +## 37.5　结构关系 + +1. 承接第36章： +第36章定义“怎么进”，本章定义“怎么拿、怎么退”。 + +2. 通向第38章： +第38章的 PO3 会解释“为什么价格常先诱导再递送”，为本章目标推进提供路径动力。 + +3. 通向第44–45章： +后续风险章节将把本章目标分层与 R 倍数、回撤管理、分批止盈合并到账户生存系统。 + +## 37.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：Long 的 IRL -> ERL 标准兑现 + +1. 高周期主Draw在上侧； +2. 入场后先到达内部目标（IRL）并部分落袋； +3. 结构保持时，剩余仓位继续指向外部目标（ERL）； +4. 到达 ERL 完成全平。 + +### 场景B：IRL 达成后趋势延续 + +很多交易者在 IRL 全平后看着行情继续走主段。该场景说明：IRL 与 ERL 不是二选一，而是顺序关系。 + +### 场景C：目标未达成时的回补管理 + +价格回到 OB/FVG 一带但中期结构未坏，这常是“管理节点”而非“翻向信号”。 + +### 反例场景：目标反复切换 + +典型表现是同一时段多空反复，最终每次都“看对一半、拿不到一段”。根因通常是目标纪律缺失。 + +## 37.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 盘前写明 HTF 主Draw与主Objective。 +2. **触发：** 入场后立即定义 IRL 第一兑现层。 +3. **确认：** IRL 触达后，评估结构是否支持继续指向 ERL。 +4. **执行：** 目标未达前，按结构上移保护并执行递减再参与。 +5. **退出：** 到达 ERL 或触发结构失效时执行完整退出。 + +### 目标管理三原则 + +- 目标先定义，仓位后分配； +- IRL 先锁定，ERL 再扩展； +- 失效先执行，叙事后更新。 + +## 37.8　常见误区 + +误区1：把 IRL 当全平位。 +识别信号：第一目标一到就清仓。 +纠偏动作：IRL 以部分兑现为主，ERL 为主退出层。 + +误区2：没有 Draw 就定目标。 +识别信号：目标只写“差不多到这儿”。 +纠偏动作：目标必须由 HTF 流动性或失衡对象反推。 + +误区3：Objective 未达就频繁翻向。 +识别信号：盘中多空切换过快。 +纠偏动作：失效未触发前，坚持主目标纪律。 + +误区4：只会拿仓，不会管仓。 +识别信号：盈利仓位回吐过深。 +纠偏动作：沿结构抬升保护位，分层兑现。 + +误区5：目标已完成仍加码。 +识别信号：ERL 已触达后继续追单。 +纠偏动作：目标完成后停止新增风险。 + +## 37.9　高阶深化 + +### 一、IRL/ERL 是收益曲线设计器 + +高阶执行并非“同手数拿到终点”，而是通过分层兑现把收益波动压缩在可承受区间。 + +### 二、把四问写进日志模板 + +将“耗时、时段、回撤、完成度”固定记录后，你会逐步得到： + +- 哪些时段更适合执行主目标； +- 哪些回撤幅度属于可接受； +- 哪类交易应早退、哪类交易可延持。 + +### 三、目标重排触发器 + +建议只在以下情况重排目标： + +1. 中期关键结构被夺回； +2. 目标路径出现反向接管证据； +3. 上游叙事前提被显著破坏。 + +## 37.10　本章总结 + +1. IRL/ERL 是分层兑现架构，不是两个孤立术语。 +2. Profit Objective 必须由 Draw 反推，而非主观设定。 +3. IRL 负责锁定收益，ERL 负责完成主段。 +4. 目标未达前应保持叙事一致与风险递减管理。 +5. 本章把“会进场”升级为“会兑现”。 + +## 37.11　训练清单 + +1. 观察任务：连续20笔交易标注 IRL、ERL 与实际退出层。 +2. 标注任务：每笔交易固定记录四项回测数据（耗时、时段、回撤、完成度）。 +3. 标注任务：区分“正常回补”与“结构失效”并记录触发证据。 +4. 执行任务：未定义 IRL/ERL 的交易禁止开仓。 +5. 执行任务：再参与必须按风险递减序列执行。 +6. 复盘任务：比较“单点止盈”与“分层兑现”对净值波动的影响。 +7. 达标标准：将“盈利回吐超过50%后才退出”的样本比例降至25%以下并稳定4周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Draw、IRL/ERL 退出、目标一致性、回测四问与递减风险金字塔的共同语义整理。 +[2] 文中比例与阈值用于流程化训练，不构成收益承诺。 +[3] 建议与第36章、第38章联读，形成“执行触发—目标兑现—路径动因”闭环。 + + + +# 第38章　Power of 3：Accumulation、Manipulation、Distribution + +## 38.1　本章核心问题 + +Power of 3（PO3）是全书里被提及最频繁的模型之一，但也是最容易被误学的模型之一。常见误区有两种： + +1. 把 PO3 当成固定图形，到图上机械套模版； +2. 把 PO3 当成事后解释，盘中却无法落地执行。 + +本章要解决的核心不是“再定义一次术语”，而是： + +**如何把 PO3 从记忆模型升级为执行模型。** + +围绕这个主问题，本章回答四个子问题： + +1. PO3 三阶段的严格工作定义是什么； +2. PO3 如何与 Daily Bias、开盘锚点、Judas 联动； +3. 为什么 PO3 必须镜像理解（多头与空头）； +4. 何时属于阶段内回补，何时属于模型失效。 + +## 38.2　一句话结论 + +PO3 不是预测收盘的形态游戏，而是“先蓄单、再诱导、后分发”的递送顺序模型；只有当它与上游 Bias、Draw、时间窗口同向共振时，才具备稳定执行价值。 + +## 38.3　基础定义 + +### 一、Power of 3（三阶段顺序） + +课程内容对 PO3 的核心定义非常清楚： + +1. Accumulation +2. Manipulation +3. Distribution + +可执行重点不在“出现三个阶段”，而在“三个阶段是否按顺序成立”。 + +### 二、Accumulation（蓄单段） + +Accumulation 指主段启动前的库存准备。它常表现为： + +- 价格围绕开盘价或关键区间窄幅整理； +- 单边意图尚未公开释放； +- 双侧流动性逐步堆积。 + +在空头示例中，价格位于开盘价上方时，常对应空方库存积累语境；多头镜像同理。 + +### 三、Manipulation（诱导段） + +Manipulation 指在主段前出现的反向假动作，常在开盘或新闻前后触发。其目的通常是： + +- 把市场参与者诱导到错误一侧； +- 先处理近侧流动性； +- 为主方向分发段让出路径。 + +这一步与 Judas 机制直接相连。 + +### 四、Distribution（分发段） + +Distribution 是 PO3 的主递送段：价格开始沿真实方向推进，并逐步完成当日主要目标处理。对执行者而言，这一段才是主要风险表达区。 + +### 五、开盘锚点（00:00 / 8:30） + +PO3 在日内实战里高度依赖两类开盘锚： + +1. `00:00` 的日内开盘语义； +2. `8:30` 的新闻波动注入语义。 + +围绕这两个锚，Manipulation 的可识别度通常更高。 + +### 六、PO3 与 Daily Bias + +PO3 不能独立产生方向。它的上游依然是： + +Narrative -> Draw on Liquidity -> Daily Bias。 + +PO3 的作用是把“已知方向偏向”拆成“可执行的三阶段路径”。 + +### 七、CPE 与错过首笔后的再参与 + +课程中给出 CPE（Close Proximity Entries）用于处理常见执行难题： + +- 错过了 Judas 首笔； +- 仍想在主叙事有效时参与分发段。 + +CPE 的边界是：只在 Objective 未达成、结构未失效时使用。 + +### 八、PO3 的非预测边界 + +课程明确强调：不需要精确预测日内最低点或收盘点，也能保持盈利。PO3 的任务是提高阶段判断质量，而非制造“极值预测幻觉”。 + +### 九、PO3 与会话错位 + +同样是三阶段路径，发生在不同会话中的执行意义并不相同。 +例如诱导若出现在低效率尾段，其后分发的可靠性通常弱于关键窗口内形成的诱导。 +因此 PO3 必须与会话质量联动，而不能仅凭阶段外观判断。 + +## 38.4　底层逻辑 + +### 一、PO3 的本质是顺序，不是外观 + +同样三段外观，可能对应完全不同的语境。真正有效的 PO3 必须满足： + +1. 上游偏向先成立； +2. 中段诱导可被解释为流动性处理； +3. 后段分发有结构承接。 + +缺少任一条件，通常只是“像PO3”的波动。 + +### 二、Manipulation 阶段是最容易错的阶段 + +大多数错误单都发生在此阶段： + +- 追第一波； +- 或过早逆第一波； +- 或把第一波当全天终局。 + +更稳健的处理是“先识别诱导，后等待接管”。 + +### 三、PO3 需要位置过滤 + +同样三阶段路径，在 Premium / Discount 不同位置意义差异很大。若忽略位置，PO3 常会退化成“阶段名称正确、交易位置错误”。 + +### 四、PO3 与 IRL/ERL 的联动 + +把第37章引入后，PO3 可形成完整链条： + +- Manipulation 完成后进入试探参与； +- Distribution 首段对应 IRL 部分兑现； +- Distribution 延伸阶段争取 ERL 完整兑现。 + +这让 PO3 从“入场故事”升级为“全流程管理模型”。 + +### 五、PO3 是分形模型，不是单周期模型 + +课程强调价格分形：高周期与低周期都可能出现同类阶段结构。高阶做法不是“每个周期都交易”，而是： + +- 上层周期给叙事； +- 下层周期给触发。 + +### 六、模型失效与阶段回补必须分开 + +分发段出现回补不等于模型失效。失效需要更强证据： + +- 关键结构被反向接管； +- 主目标逻辑被破坏； +- 开盘锚语义被持续否定。 + +### 七、分发尾段不等于继续加速 + +很多执行回吐发生在分发后段：价格仍沿主方向，但效率已明显下降。 +此时若继续按“启动段强度”追击，通常会把已得利润重新暴露于回撤。 +更稳健的处理是：分发后段优先做目标管理与保护位管理，而不是继续放大方向押注。 + +## 38.5　结构关系 + +1. 承接第37章： +第37章解决目标分层，本章解释“目标为什么常以先诱导后递送的节奏出现”。 + +2. 通向第39章： +第39章将把 PO3 放入 AM/PM 会话模板，解决“同一天哪个时段更值得做”。 + +3. 通向第40章： +第40章将把 PO3 语义向周内 Swing 扩展，处理多日递送路径。 + +## 38.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：Bullish PO3 标准链 + +1. 开盘附近先形成蓄单区； +2. 关键窗口先向下做假动作（Judas）； +3. 价格收回关键位后进入上行分发； +4. 主段完成内部目标，再评估外部扩展。 + +### 场景B：Bearish PO3 标准链 + +1. 开盘上方先形成库存准备； +2. 先向上诱导并处理上侧流动性； +3. 随后向下分发并服务下方目标。 + +### 场景C：错过首笔后的 CPE 再同步 + +当主叙事有效、目标未达时，可在开盘附近的近距区域等待二次参与，而不是在分发尾段追价。 + +### 反例场景：任何三段都当 PO3 + +若没有上游 Bias、没有流动性语义、没有结构承接，只靠“看起来像三段”入场，结果通常是震荡段反复止损。 + +## 38.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 先完成 3B，确认当天 Bias 与主Draw。 +2. **触发：** 围绕 00:00 与 8:30 观察是否出现诱导动作。 +3. **确认：** 等待诱导后的结构接管，不在诱导段重仓。 +4. **执行：** 在 Distribution 启动段参与，并按 IRL/ERL 管理。 +5. **退出：** 目标达成或结构失效时退出，不做尾段追击。 + +### 执行强度分配 + +- Accumulation：观察优先； +- Manipulation：确认优先； +- Distribution：执行优先。 + +## 38.8　常见误区 + +误区1：把 PO3 当固定图案。 +识别信号：看见三段就直接下单。 +纠偏动作：先验证 Bias/Draw，再验证阶段顺序。 + +误区2：在 Manipulation 段重仓。 +识别信号：经常买在假上冲、卖在假下破。 +纠偏动作：诱导段只观察，确认后再执行。 + +误区3：忽略开盘锚点。 +识别信号：对 00:00 / 8:30 相对位置没有记录。 +纠偏动作：把开盘锚点纳入盘前模板。 + +误区4：只看阶段，不看位置。 +识别信号：回补深度与预期经常错位。 +纠偏动作：用 Premium/Discount 约束阶段预期。 + +误区5：把 PO3 当收盘预测工具。 +识别信号：未命中极值就否定系统。 +纠偏动作：把目标从“猜极值”改成“抓主段”。 + +## 38.9　高阶深化 + +### 一、PO3 与收益管理一体化 + +高阶用法不是“识别到 PO3 就进场”，而是把 PO3 变成收益管理框架： + +- 诱导完成后参与； +- 主分发段分层兑现； +- 末段减速时主动降风险。 + +### 二、三句预案法 + +每笔交易前固定写三句： + +1. 当前处于 PO3 哪一段； +2. 进入下一段需要哪些证据； +3. 哪些证据会否定当前判断。 + +它能显著降低事后解释式交易。 + +### 三、阶段转换速率 + +同样是从 Manipulation 到 Distribution，有的切换快、有的切换慢。切换速率不同，仓位与持有策略也应不同。快切换可更积极，慢切换宜减仓或等待。 + +## 38.10　本章总结 + +1. PO3 是阶段顺序模型，不是固定形态模型。 +2. 三阶段分别是 Accumulation、Manipulation、Distribution。 +3. PO3 必须与 Bias、Draw、开盘锚点协同使用。 +4. Manipulation 的第一波不是执行信号，确认后才执行。 +5. 本章把第37章目标系统与日内路径动因打通。 + +## 38.11　训练清单 + +1. 观察任务：连续20个交易日标注 00:00、8:30 锚点与 PO3 三阶段切换。 +2. 标注任务：每笔交易记录“阶段判定、确认证据、失效证据”。 +3. 标注任务：统计“诱导段入场”与“分发段入场”的胜率和R值差异。 +4. 执行任务：未完成 Bias+Draw 判定时禁止用 PO3 入场。 +5. 执行任务：错过首笔后只允许 CPE 再同步，不允许追价补错。 +6. 复盘任务：复核每次 PO3 失效是否因结构失效，还是仅属正常回补。 +7. 达标标准：将“诱导段冲动入场”比例降至20%以下并稳定4周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 PO3、Judas、开盘锚点、Daily Bias 与 CPE 的共同语义整理。 +[2] 文中执行强度分配与阈值用于流程训练，不构成收益承诺。 +[3] 建议与第37章、第39章联读，形成“目标分层—路径阶段—会话模板”一致语法。 + + + +# 第39章　Market Profile 与 New York AM/PM Session Opportunities + +## 39.1　本章核心问题 + +到第38章为止，我们已经能读懂 PO3 的阶段路径，但执行里仍有一个高频难题： + +**同样是纽约交易日，为什么有的日子 AM 是主机会，有的日子 PM 才是主机会？** + +若不解决这个问题，交易者常在两种错误中切换： + +1. 该做 AM 的日子，下午才追； +2. 该等 PM 的日子，早盘就高频试错。 + +本章只解决一个主问题： + +**如何用 Market Profile 先判“日型”，再判“时段执行重心”。** + +本章回答四个子问题： + +1. 三种模板的工作含义是什么； +2. AM、Lunch、PM 的职责如何分层； +3. 大隔夜波动日为什么要避免 AM 追单； +4. 如何把模板与 Bellwether、Daily Bias、Draw 合成流程。 + +## 39.2　一句话结论 + +Market Profile 的价值不在于预测，而在于筛选：先识别当天属于哪类会话模板，再决定 AM 或 PM 的执行权重，把交易集中在“时段与结构共振”的窗口。 + +## 39.3　基础定义 + +### 一、Market Profile（本章语境） + +本章的 Market Profile 指“会话行为模板”，不是单一指标。其作用是把当日机会按时间段拆分，而不是把所有机会放在同一时段强行执行。 + +### 二、三类核心模板 + +课程内容给出三种高频模板： + +1. **Template 1：Morning Trend, Afternoon Reversal** +2. **Template 2：Morning Trend, Afternoon Continuation（1:1 measured move）** +3. **Template 3：Morning Consolidation, Afternoon Trend** + +三模板并非互斥标签，而是日内路径的主要组织方式。 + +### 三、模板前置问题 + +在判模板前，课程要求先问两件事： + +1. 日线语境当前指向什么； +2. 近三日回看显示什么路径偏向。 + +这一步用于防止“只看当天局部波动”而忽略高层背景。 + +### 四、会话分段职责 + +纽约日内执行可分为： + +1. Morning Session（结构启动与首段验证）； +2. New York Lunch（低效率或管理时段）； +3. PM Session（延续或反向重构时段）。 + +### 五、Bellwether（15分钟框架） + +15分钟仍是会话框架锚。它负责告诉你： + +- 当前是趋势段还是整理段； +- 当前更适合跟随还是等待； +- 当前是否进入低效率时段。 + +### 六、Large Overnight Price Run（大隔夜波动日） + +课程把这类日型单独拎出，核心规则是： + +1. 隔夜已大幅扩张时，AM 追单风险显著提升； +2. AM 往往更容易出现“追随者被清理”； +3. PM 在流动性再处理后，机会质量更高。 + +### 七、Intra-day Draw 与 AM/PM 接力 + +课程结构语义是： + +- MSS 常先导向 AM 的 intra-day draw； +- 当 AM draw 完成后，PM 再决定延续或反向。 + +这意味着 AM 与 PM 不是对立关系，而是接力关系。 + +### 八、模板切换触发器 + +模板初判只是一版假设，盘中仍需证据校正。 +常用的切换触发器可固定为三类： + +1. AM 主Draw提前完成且出现反向接管； +2. 关键会话窗口后仍无延续证据； +3. 结构从“推进”退化为“回到均衡中轴”。 + +有了触发器，模板修正才不会沦为情绪翻向。 + +## 39.4　底层逻辑 + +### 一、先判“是什么日”，再判“何时做” + +很多执行问题并非方向错，而是时段错。模板先行可以显著降低“在错误时段做正确方向”的损耗。 + +### 二、AM 与 PM 信息密度不对称 + +AM 常负责： + +1. 当日首段结构验证； +2. 关键流动性清理； +3. 首次位移表达。 + +PM 常负责： + +1. AM 路径的延续完成； +2. 或在特定模板下进行反向接管。 + +因此同一策略不应全天同强度执行。 + +### 三、Lunch 规则是风险效率规则 + +午盘并非“永远无机会”，而是“平均风险收益比不优”。把 Lunch 设为 no-trade / 降频管理，能显著减少噪音损耗。 + +### 四、大隔夜日的核心是“不和FOMO站在同一侧” + +隔夜大波动后，AM 最容易出现追单拥挤。成熟做法是先等会话内再平衡与流动性处理，PM 再找结构化机会。 + +### 五、模板不是方向发动机，而是执行过滤器 + +模板不能替代 Narrative 和 Draw。其功能是： + +- 给时段分配执行权重； +- 给仓位分配进攻顺序； +- 给“该等还是该做”提供客观依据。 + +### 六、模板判断要允许盘中修正 + +模板不是早盘一次定终身。若盘中出现结构接管证据，模板应动态修正；但修正必须由证据触发，而非情绪触发。 + +### 七、模板误判的正确代价控制 + +模板误判在实盘中不可避免，关键不是“零误判”，而是“误判后低成本退出”。 +当模板与价格行为出现持续背离时，应先降风险、再重评，而不是用加仓去对抗证据。 +这条纪律能显著降低“时段错配导致的连续亏损”。 + +## 39.5　结构关系 + +1. 承接第38章： +第38章解释单日阶段路径，本章把该路径映射到 AM/PM 的时段执行。 + +2. 通向第40章： +本章处理“单日会话模板”，第40章上卷到“周内 Swing 模型”。 + +3. 通向第42章： +本章的会话权重逻辑，是第42章“会话内多次再同步”的前提。 + +## 39.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：Template 1（AM 趋势，PM 反向） + +1. AM 先走出明确趋势； +2. 关键流动性被处理后，PM 出现反向接管； +3. 执行重点从“早段跟随”切换到“午后确认反向”。 + +### 场景B：Template 2（AM 趋势，PM 延续） + +1. AM 已建立方向优势； +2. PM 继续沿同方向推进，常见 measured move 结构； +3. 管理上不宜在 AM 末端过早全平。 + +### 场景C：Template 3（AM 整理，PM 趋势） + +1. AM 主要是区间博弈； +2. PM 才给主段扩张； +3. 执行重心应从“早盘试错”转为“午后确认”。 + +### 场景D：Large Overnight Price Run + +1. 隔夜已出现大幅单边； +2. AM 易出现追随者被反向清理； +3. PM 在流动性池被再处理后再找 setup，效率更高。 + +### 反例场景：全天同强度交易 + +不区分 AM/Lunch/PM，一整天同频率下单，最常见结果是： + +- AM 赚到的，Lunch 吐回去； +- PM 真机会来时风险预算已消耗。 + +## 39.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 盘前先判断日线语境与三日回看，给出模板初判。 +2. **触发：** 用 15分钟 Bellwether 标注会话关键位与时段切换点。 +3. **确认：** AM 先看 intra-day draw 是否达成，再判断 PM 延续或反向。 +4. **执行：** 按模板给 AM/PM 分配不同仓位权重。 +5. **退出：** Lunch 降频；模板失效时重评，不在失效模板中硬做。 + +### 会话权重建议 + +- 模板清晰时：主时段标准风险，次时段半风险； +- 模板冲突时：降级风险，等待结构再明确。 + +## 39.8　常见误区 + +误区1：不判模板直接找信号。 +识别信号：每天都用同一时段打法。 +纠偏动作：先判日型，再判时段。 + +误区2：忽视 Lunch 降频。 +识别信号：午间交易拉低全天绩效。 +纠偏动作：午盘只做管理或观察。 + +误区3：大隔夜后 AM 追单。 +识别信号：开盘后反复被反抽。 +纠偏动作：大隔夜日优先 PM 执行。 + +误区4：AM draw 完成后反复逆向硬做。 +识别信号：在主叙事明确时频繁反手。 +纠偏动作：主模板失效前保持一致性。 + +误区5：把 Bellwether 当入场信号本身。 +识别信号：15分钟一动就下单。 +纠偏动作：Bellwether 只定框架，入场仍需结构确认。 + +## 39.9　高阶深化 + +### 一、模板—时段—仓位三维管理 + +可把三模板映射为仓位策略： + +1. AM 主仓 / PM 观察； +2. AM 主仓 / PM 延续仓； +3. AM 轻仓 / PM 主仓。 + +这样仓位由“日型概率”驱动，而不是由情绪驱动。 + +### 二、大隔夜日的黑白名单 + +建议设两条纪律： + +1. AM 黑名单：禁止追随型入场； +2. PM 白名单：仅在流动性再处理后参与。 + +长期执行能显著降低被开盘噪音切割的概率。 + +### 三、模板复盘指标 + +每个交易日固定记录： + +1. 模板初判是否正确； +2. 主盈利段落在 AM 还是 PM； +3. 是否遵守 Lunch 规则； +4. 模板修正是否有证据支撑。 + +## 39.10　本章总结 + +1. Market Profile 是会话模板系统，不是单点信号。 +2. AM/Lunch/PM 信息密度不对称，执行强度应分层。 +3. 大隔夜波动日优先等待 PM，避免 AM 追随。 +4. Bellwether 定框架，模板定时段，结构定入场。 +5. 本章完成“日内路径”到“会话机会管理”的升级。 + +## 39.11　训练清单 + +1. 观察任务：连续20个交易日为每一天标注 Template 1/2/3。 +2. 标注任务：记录主盈利时段（AM/PM）与 Lunch 违规次数。 +3. 标注任务：单独统计大隔夜日 AM 与 PM 的信号质量差异。 +4. 执行任务：大隔夜日 AM 禁止追单，PM 仅做确认后参与。 +5. 执行任务：模板冲突时风险降级，不做满仓表达。 +6. 复盘任务：比较“模板先行”与“信号先行”的净值波动。 +7. 达标标准：将“时段错配交易”比例降至25%以下并稳定4周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于三模板、Bellwether、Lunch规则、AM/PM接力与大隔夜日处理语义整理。 +[2] 文中时段权重与风险分配用于流程训练，不构成收益承诺。 +[3] 建议与第38章、第40章联读，形成“单日阶段—会话模板—周内路径”连续框架。 + + + +# 第40章　Swing Trading Model：从日内到周内 + +## 40.1　本章核心问题 + +很多交易者在日内执行上已经具备能力，但一旦持仓周期延长到 1–3 周，常出现两类失衡： + +1. 用低周期噪音管理高周期仓位，导致提前离场； +2. 用高周期观点硬扛低周期失效，导致回撤失控。 + +这说明问题不在“会不会看方向”，而在“有没有多周期分工”。 + +本章只解决一个主问题： + +**如何把 Swing Trading 写成“上层定方向、中层管路径、下层给触发”的分工系统。** + +本章回答四个子问题： + +1. Swing 交易应如何固定核心研究周期； +2. 周内节奏（MTW 与 TGIF）如何进入持仓管理； +3. 为什么不能用短周期先定义结构； +4. 如何把日内模型与周内模型连成同一套执行语法。 + +## 40.2　一句话结论 + +Swing 模型的核心不是“持有更久”，而是“分工更清晰”：高周期给偏向，中周期给框架，低周期给触发；周内节奏决定进攻与兑现的时间分配。 + +## 40.3　基础定义 + +### 一、Swing Trader 的周期定位 + +课程中对 Swing 模型给出清晰分工： + +- 持有周期：约 1–3 周； +- 长周期：Daily； +- 中周期：4H； +- 短周期：1H。 + +这组分工并非固定宗教，而是用于把“方向、管理、触发”拆开。 + +### 二、三层职责 + +三层角色可写为： + +1. **Long-term（Daily）：** 决定方向偏向与主目标； +2. **Intermediate-term（4H）：** 决定路径框架与仓位管理； +3. **Short-term（1H及以下）：** 决定入场与风险效率。 + +关键纪律是：短周期用于入场，不用于推翻主结构。 + +### 三、Weekly Range 与 PD Array 递送 + +课程明确强调：每周市场常在 PD Array 之间递送，从一个象限向另一个象限推进。对 Swing 执行而言，这意味着周内目标不应只看点位，而应看“从哪类数组递送到哪类数组”。 + +### 四、MTW 节奏（Monday to Wednesday） + +框架中的统计线索显示：周区间的核心推进，常在周一到周三完成 30%–50%。 + +该线索的用途不是预测，而是管理： + +- 周前半更容易出现方向验证与推进； +- 周后半更应关注回撤、兑现与防守。 + +### 五、MTW 高低点被处理后的加速 + +课程也强调：当 MTW 高/低被穿透后，价格常出现加速段，向更高层级数组推进。这给 Swing 的“持仓延续”提供了客观条件。 + +### 六、TGIF 现象（周末回撤与清理） + +在周蜡烛临近收束时，常见回撤回到周区间内部，寻找 FVG 或流动性池。其背后机制通常与周末追价资金被清理有关。 + +TGIF 的实务含义是： + +- 周五后段不宜无条件追单； +- 更应优先保护周内已得利润。 + +### 七、模型重叠（Overlap） + +课程提示 Swing 模型可能重叠，意味着同一周内可能出现“延续路径”和“回撤路径”并存。成熟处理不是二选一押注，而是分配权重并等待结构证据升级。 + +### 八、周内任务拆分（建仓—持仓—兑现） + +Swing 模型可进一步拆成三段任务： + +1. 建仓段：以低周期优化进入高周期方向； +2. 持仓段：以中周期结构管理回撤与保护； +3. 兑现段：结合周内节奏与目标完成度分层退出。 + +把任务拆开后，执行动作会明显减少互相冲突。 + +## 40.4　底层逻辑 + +### 一、Swing 不是“大止损日内单” + +Swing 的核心变化不在止损距离，而在信息层级： + +- 日内交易主要受会话驱动； +- Swing 交易主要受周内递送与高周期目标驱动。 + +若以日内噪音替代周内框架，持仓会失去稳定性。 + +### 二、自上而下是硬约束 + +课程反复强调：中周期给框架，短周期给入场。它直接解决 Swing 最大误区——不再让 1H 噪音去推翻 Daily 主叙事。 + +### 三、周内节奏决定风险节拍 + +把 MTW 与 TGIF 纳入后，风险分配会自然分层： + +1. 周前半：允许更积极验证主叙事； +2. 周后半：提高保护性管理权重； +3. 周末：防止追价与利润回吐。 + +### 四、日内与Swing是嵌套关系 + +Swing 不排斥日内执行，恰恰需要日内去优化入场。其正确关系是： + +- 高周期决定做哪边； +- 低周期决定如何低风险进入。 + +### 五、模型重叠时要做“仓位表达”，不是“观点摇摆” + +当周内路径出现重叠可能时，最差做法是频繁改观点；更优做法是降低风险、分批验证、等待结构确认哪个路径成为主线。 + +### 六、周内执行的核心边界 + +一旦周内主目标已接近完成且进入周末收束阶段，继续按前半周强度进攻，往往得不偿失。此时“保住周收益”通常优先于“再搏最后一段”。 + +### 七、跨周续持的边界管理 + +并非所有仓位都应跨周。 +若续持需要成立，至少要满足： + +1. 高周期主Draw尚未完成； +2. 周末收束未破坏中期结构； +3. 下周开盘前有明确的风险重置计划。 + +否则，周末前完成结构化减仓，通常优于无计划续持。 + +## 40.5　结构关系 + +1. 承接第39章： +第39章处理单日会话模板，本章上卷到周内路径管理。 + +2. 通向第41章： +第41章将把 Swing 框架下的结构读取进一步精密化（MSB/MSS与流动性接管）。 + +3. 通向第44–45章： +本章的分层持仓与周内节奏，将在后续风险章节转化为账户层规则。 + +## 40.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：标准多头周 + +1. 周初由 Daily 给出多头偏向； +2. 4H 框架确认路径； +3. 1H 提供低风险入场； +4. 周前半完成主要推进； +5. 周后半以保护和分层兑现为主。 + +### 场景B：前半周不动，后半周扩张 + +有些周前半推进不足，后半才启动。此时执行关键是“耐心等待框架成熟”，而不是前半周反复试错耗损。 + +### 场景C：主框架不变，低周期多次优化 + +当 4H 主结构仍完整时，1H 可多次提供优化入口。这类多次参与应服从同一叙事，不应演化为频繁反手。 + +### 场景D：跨周续持失败的典型路径 + +有些仓位周末前看似仍有空间，但下周开盘直接出现反向跳动或结构缺口。 +若周末前没有完成分层减仓与风险重置，原本盈利仓位会在开盘阶段被动承受不必要波动。 +这类样本提示：跨周续持不是“多拿一点”的自然延伸，而是需要单独审批的风险动作。 + +### 反例场景：短周期先判主结构 + +最常见错误是：1H 一次回调就宣布周趋势切换。结果通常是高频翻向、低质量执行。 + +## 40.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 周初先定义 Daily 主偏向与主Draw。 +2. **触发：** 用 4H 标定关键区间、关键数组与中期失效边界。 +3. **确认：** 用 1H/更低周期寻找与 4H 同向的触发。 +4. **执行：** 周前半优先推进，周后半优先管理与保护。 +5. **退出：** 目标达成、结构失效或周末收束阶段触发时分层退出。 + +### 周内风险配速 + +- 框架清晰：标准风险； +- 路径重叠：风险降级； +- 周末收束：防守优先。 + +### 仓位节拍建议（任务驱动） + +可按周内任务分配仓位节拍： + +1. 建仓段：仓位由小到中，先验证后放大； +2. 持仓段：以保护位迁移为核心，不因噪音频繁重置； +3. 兑现段：按目标完成度递减风险，不把盈利段硬拖成猜顶猜底。 + +## 40.8　常见误区 + +误区1：把 Swing 当长持日内。 +识别信号：完全依赖低周期决策。 +纠偏动作：恢复 Daily/4H/1H 三层分工。 + +误区2：短周期定义主结构。 +识别信号：同一周多空反复。 +纠偏动作：短周期只做入口，不做主框架判定。 + +误区3：忽视周内节奏。 +识别信号：周后半仍按周前半强度开仓。 +纠偏动作：把 MTW/TGIF 写入仓位管理规则。 + +误区4：周末追价。 +识别信号：周五后段追单后被清理。 +纠偏动作：周末优先保护盈利。 + +误区5：只设方向，不设管理节拍。 +识别信号：知道多空，不知道加减仓时机。 +纠偏动作：用中周期框架定义持仓节奏。 + +## 40.9　高阶深化 + +### 一、双账本管理法（周模型 + 日模型） + +建议每笔 Swing 交易同步记录： + +1. 周模型：偏向、目标、周节奏、失效边界； +2. 日模型：会话触发、加减仓动作、保护动作。 + +它能清楚区分“方向正确但执行欠佳”与“方向本身错误”。 + +### 二、重叠模型的权重表达 + +模型重叠时，不应观点反复，而应： + +1. 保留主叙事； +2. 降低仓位权重； +3. 等结构证据升级后再加权。 + +### 三、从“猜周走势”到“管周路径” + +高阶 Swing 不是一次性猜完整周，而是周初定向、周中验证、周末保护。这个过程化管理，比重仓押单一剧本更可持续。 + +## 40.10　本章总结 + +1. Swing 模型核心是多周期分工，而非持仓时长本身。 +2. Daily 定偏向，4H 定框架，1H 定触发。 +3. MTW/TGIF 应进入仓位与退出规则。 +4. 高周期决定做哪边，低周期决定怎么做。 +5. 本章完成从日内执行到周内执行的体系衔接。 + +## 40.11　训练清单 + +1. 观察任务：连续8周记录 MTW 推进强度、周后半回撤特征与 TGIF 影响。 +2. 标注任务：每笔 Swing 交易记录三层角色（偏向/框架/触发）。 +3. 标注任务：区分“周前半推进失败”与“周后半反向接管”。 +4. 执行任务：主结构未失效前，禁止因短周期噪音反手。 +5. 执行任务：周末阶段新增仓位必须降级风险。 +6. 复盘任务：比较“单周期决策”与“三周期分工决策”的绩效差异。 +7. 达标标准：将“短周期噪音导致的提前平仓/反手”比例降至25%以下并稳定8周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 Swing 持仓分工、周内递送、MTW/TGIF与Bellwether分层语义整理。 +[2] 文中节奏与仓位规则用于流程训练，不构成收益承诺。 +[3] 建议与第39章、第41章联读，形成“会话—周内—结构接管”的连续框架。 + +# 第八部分　精密执行与市场应用 + +第七部分完成了模型层。 +第八部分要解决的是： + +**如何把模型执行升级为跨市场、跨会话、跨层级的精密操作能力。** + +--- + +## 本部分定位 + +本部分强调三件事： + +1. 结构阅读如何提升到 Precision Technician 标准； +2. 同一会话内如何处理多次可执行同步机会； +3. 外汇与指数期货如何在同一框架下做参数适配。 + +--- + +## 三章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第41章 | 精密结构阅读与真假结构变化识别 | +| 第42章 | Session 内多次同步机会的执行分配 | +| 第43章 | Institutional Order Flow 在 Forex 与 Index Futures 的应用边界 | + +--- + +## 学习边界 + +第八部分最容易误学成“激进交易”。 +请固定原则： + +**精密执行不是更频繁执行，而是更严格过滤后执行。** + +--- + +## 学完应具备 + +完成第八部分后，你应能： + +1. 识别高质量结构变化与低质量假变化。 +2. 在同一会话内管理多次机会而不自我冲突。 +3. 在不同市场中保持框架一致、参数适配。 + +--- + +## 与后续章节的连接 + +第九部分将把执行能力与账户生存能力连接， +解决“会做交易”与“能活下来”之间的缺口。 + +--- + +## 章末注释 + +[1] 本导读用于连接第七部分模型执行与第八部分精密应用。 +[2] 建议进入第九部分前，先复核第42章的多机会分配规则与第43章市场适配边界。 + + + +# 第41章　Market Structure for Precision Technicians + +## 41.1　本章核心问题 + +很多交易者“会看结构”，却始终达不到 precision（精密执行）。根因通常不是不会画高低点，而是结构阅读顺序错了： + +1. 先看局部破位，再补叙事； +2. 先看图形模式，再找流动性语义； +3. 低周期频繁推翻高周期框架。 + +课程在 Precision 模块里给出核心分歧： + +- 零售视角偏“形态先行”； +- 机构视角偏“流动性与失衡先行”。 + +本章只解决一个主问题： + +**如何把结构分析从“图形识别”升级为“叙事—目标—结构接管”三段式框架。** + +本章回答四个子问题： + +1. MSB 与 MSS 的层级区别是什么； +2. 为什么结构必须服务于 Draw，而不能替代 Draw； +3. 为什么中周期定框架、短周期定触发是硬约束； +4. 如何把结构事件写成可执行确认链。 + +## 41.2　一句话结论 + +Precision 结构分析的正确顺序是：先叙事，再目标，再结构；先高周期给框架，再低周期给触发。离开这一顺序，MSB/MSS 容易被误读为噪音事件。 + +## 41.3　基础定义 + +### 一、MSB 与 MSS 的层级差异 + +课程中对两者的定位非常清晰： + +1. **MSB（Market Structure Break）：** 更偏多日趋势推进层面的结构破坏与延续； +2. **MSS（Market Structure Shift）：** 更偏日内路径接管层面的结构切换。 + +二者不是同义词，也不应在同一层级互换使用。 + +### 二、Interbank 结构视角 + +课程强调，机构并不因为“图形可见”而交易图形，也不依赖指标信号本身。其结构阅读第一优先级是： + +1. 流动性在哪里； +2. 失衡在哪里； +3. 价格下一步更可能服务哪一侧。 + +### 三、结构前置链（Narrative -> Draw -> Bias） + +在 Precision 语境中，结构分析之前必须先回答： + +- 当前叙事是什么； +- 当前 Draw 是哪一侧； +- 当前 Bias 是否支持该侧。 + +结构事件（MSB/MSS）的价值，是验证这条链是否仍成立。 + +### 四、MSS 显著性的前提 + +课程明确提醒： + +- 不要强行找 MSS； +- 近期高点被破并不自动显著； +- 只有在流动性被处理后，MSS 才更具交易意义。 + +并且 MSS 成立后，价格常会 seek opposing liquidity。 + +### 五、MSB 的“显著”边界 + +在多周期语境下，只有当中期关键高低点被破坏并与上游叙事一致，MSB 才应升级为“结构级事件”；否则往往只是局部扰动。 + +### 六、中短周期职责边界 + +课程反复强调： + +- Intermediate-term 给框架； +- Short-term 是 Bellwether，用于入场优化。 + +若反过来使用，就会在低周期噪音中持续误判。 + +### 七、Parent / Subordinate Order Block 联动 + +Precision 执行里常用“父级区定义方向，子级区定义入口”。其意义是： + +- 高周期负责“做哪边”； +- 低周期负责“怎么低风险做”。 + +### 八、显著结构事件与普通破位的区分 + +为了避免“见破就做”，可把结构事件分成两类： + +1. **普通破位：** 仅发生在低周期、缺少流动性前置、后续没有位移承接； +2. **显著结构事件：** 发生在关键层级，且前后具备“流动性处理 -> 结构接管 -> 数组承接”完整链。 + +只有第二类才应进入标准执行序列。 + +## 41.4　底层逻辑 + +### 一、结构必须“服务目标” + +结构不是独立信号系统。若一个结构事件不能回答“它服务哪一侧目标”，它通常只具解释价值，不具执行价值。 + +### 二、假结构陷阱来自顺序倒置 + +课程直接指出：若无法用机构视角理解结构，容易成为 false MSB 的受害者。最常见原因是： + +1. 只看局部破位，不看流动性前置； +2. 只看低周期变化，不看高周期框架； +3. 把结构标签当成交权限。 + +### 三、MSS 的交易价值来自“流动性后接管” + +MSS 单独出现并不稀缺，真正稀缺的是： + +- 先有流动性事件； +- 再有反向接管； +- 再有可执行数组承接。 + +三者闭合后，MSS 才有高执行价值。 + +### 四、MSB 的交易价值来自“层级一致” + +MSB 若只发生在低周期，通常只影响短段路径；MSB 若发生在中周期关键位并与长周期同向，才具备改变持仓策略的资格。 + +### 五、结构确认链应固定化 + +课程可归纳为三步确认链： + +1. 先清理流动性； +2. 再出现结构切换； +3. 最后在 FVG/OB 处完成执行确认。 + +这条链让结构从“主观解释”变为“客观流程”。 + +### 六、持仓稳定取决于结构边界纪律 + +只要中期关键结构仍完整，回撤不应自动触发恐慌离场；结构边界被破坏时，也不应被主观信念拖延执行。 + +### 七、结构确认与仓位强度必须同步 + +结构显著性不是“有或没有”二元，而是“强、中、弱”分级。 +更稳健的做法是把仓位与结构等级绑定： + +1. 弱确认：观察或轻仓； +2. 中确认：半风险表达； +3. 强确认：标准风险表达。 + +这样可以把“结构判断误差”转化为“可控风险误差”。 + +## 41.5　结构关系 + +1. 承接第40章： +第40章给出 Swing 分工，本章把“如何判结构”做成精密规则。 + +2. 通向第42章： +第42章会把本章结构框架落到“同会话多次再同步执行”。 + +3. 通向第22章与执行层： +本章提供 MSS/MSB 的精密过滤逻辑，与前文结构章节形成上下游闭环。 + +## 41.6　图表中的真实表现 / 交易中的真实表现 + +### 场景A：标准 Precision 结构链 + +1. 先定义 Narrative 与 Draw； +2. 价格处理一侧流动性； +3. 出现 MSS 或显著 MSB； +4. 回到 FVG/OB 完成低风险执行。 + +### 场景B：中期框架不变、短期多次触发 + +当中期结构仍支持主方向，短期反复回撤更可能是入场优化机会，而不是方向切换证据。 + +### 场景C：显著中期破坏触发重排 + +若中期关键位被破坏且叙事前提被否定，应把原持仓从“延续管理”切换为“失效处置”。 + +### 场景D：同向重测与反向夺回的分界 + +很多误判发生在“看起来都像回测”的阶段。 +实务可用一个简单分界：若回测后快速恢复主方向并继续服务原Draw，多数属于同向重测；若回测后持续失去主方向结构并反向夺回关键位，则应按接管处理。 +这一步能显著减少“把正常回测当反转”与“把反向接管当普通回测”两类错误。 + +### 反例场景：局部破位即反手 + +只因短周期一处高低点穿越就反手，通常会在同一区间内被反复清理。 + +## 41.7　执行意义 + +### 五步流程（本章版） + +1. **条件：** 先写 Narrative、Draw、Bias，不先贴结构标签。 +2. **触发：** 观察是否先出现流动性处理，再看 MSS/MSB。 +3. **确认：** 中周期确认结构权限，短周期只做入场优化。 +4. **执行：** 在 Parent/Subordinate 数组共振区执行。 +5. **退出：** 中期关键结构失效或主目标完成时退出。 + +### 结构事件评分建议 + +可按五项评分结构显著性： + +1. 叙事一致性； +2. Draw 一致性； +3. 流动性前置完整度； +4. 时间窗口有效性； +5. 周期层级一致性。 + +### 最小确认链（执行门槛） + +为避免“标签先于证据”，可把结构执行门槛固定为三项至少两项成立： + +1. 流动性事件已发生； +2. 结构接管已被中周期确认； +3. 数组承接位给出可定义失效边界。 + +门槛不足时降级为观察，有助于把“结构理解”转化为“结构纪律”。 + +## 41.8　常见误区 + +误区1：先结构、后叙事。 +识别信号：图上到处都能解释。 +纠偏动作：恢复 Narrative -> Draw -> Bias 顺序。 + +误区2：强行找 MSS。 +识别信号：任何小级别转折都当 shift。 +纠偏动作：仅在流动性事件后评估 MSS 显著性。 + +误区3：短周期定义主结构。 +识别信号：1–5分钟变化频繁推翻4H/日线框架。 +纠偏动作：中周期定框架，短周期定入口。 + +误区4：把假突破当显著MSB。 +识别信号：局部破位即重仓换边。 +纠偏动作：必须叠加中期关键位与叙事一致性。 + +误区5：回撤即恐慌离场。 +识别信号：持仓总在主段前被洗掉。 +纠偏动作：结构未失效前按规则管理，不按情绪管理。 + +## 41.9　高阶深化 + +### 一、从“结构点”到“结构链” + +高阶读取不再问“这里是不是MSB”，而是问： + +1. 之前清理了谁； +2. 现在谁在接管； +3. 接下来要去哪里。 + +这会把执行从点状反应升级为链式反应。 + +### 二、结构与数组一体化 + +结构只回答“是否接管”，数组回答“在哪里表达风险”。两者分开会失真，合并才可执行。 + +### 三、复盘三问 + +每笔交易后固定复盘： + +1. 我的结构判断服务哪一侧Draw； +2. 哪个中期位是失效边界； +3. 我是否被短周期噪音诱导偏离。 + +## 41.10　本章总结 + +1. Precision 结构分析先叙事后结构，先高后低。 +2. MSB 与 MSS 分属不同层级，不可混用。 +3. 流动性处理是结构显著性的关键前提。 +4. 中周期定框架，短周期定执行。 +5. 本章为第42章“会话内多次同步”建立结构准则。 + +## 41.11　训练清单 + +1. 观察任务：连续20天记录每次 MSS/MSB 前是否出现流动性处理。 +2. 标注任务：每笔交易写清 Narrative、Draw、中期失效位三项。 +3. 标注任务：区分“局部破位”与“显著结构事件”样本。 +4. 执行任务：结构评分低于3分时，禁止标准仓位。 +5. 执行任务：中期结构未变时，禁止因短周期噪音反手。 +6. 复盘任务：比较“先叙事后结构”与“先结构后叙事”的绩效差异。 +7. 达标标准：将“假结构突破导致的反手交易”比例降至20%以下并稳定4周。 + +--- + +## 章末注释 + +[1] 本章内容依据根目录两份PDF中关于 MSB/MSS、Interbank 结构视角、三步确认链与多周期分工语义整理。 +[2] 文中评分阈值用于流程训练，不构成收益承诺。 +[3] 建议与第40章、第42章联读，形成“周框架—结构确认—会话执行”闭环。 + + + +# 第42章　Precision 执行与 Session 内多次同步（含 Multiple Setups Within Trading Sessions） + +## 42.1　本章核心问题 + +进入 Precision 执行阶段后，交易者最常遇到的，不再是“看不懂方向”，而是“节奏一乱就整天失控”。 + +最典型的场景是： + +1. 第一笔机会错过后，立刻追价，结果在最差位置成交； +2. 第一笔止损后，急于翻本，连续开仓把当日风险打满； +3. 早盘没抓到，就直接放弃全天，不再评估午后是否出现新的高质量结构； +4. 明明主叙事没变，却因为短周期两三根反向K线就推翻计划。 + +这类问题的共同根源不是技术缺陷，而是缺少一套“会话内再同步”规则。 + +因此，本章只解决一个主问题： + +**在同一交易会话内，如何进行“多次同步”，而不是“多次试错”。** + +围绕该主问题，本章回答四个子问题： + +1. 什么叫会话内 Multiple Setups，边界在哪里； +2. 为什么“错过第一笔”不等于“当天结束”； +3. 什么条件下可以二次参与，什么条件下必须停止； +4. 如何把会话内重入写成可执行、可复盘的流程。 + +--- + +## 42.2　一句话结论 + +**会话内多次 Setup 的本质不是增加交易次数，而是在同一 Narrative、同一 Draw、同一结构前提下进行再同步；每次再参与都必须重新过“框架—时段—结构—风险”四道闸门，并采用递减风险管理。** + +--- + +## 42.3　基础定义 + +### 一、Multiple Setups Within Trading Sessions（会话内多次设定） + +该概念的核心含义是： + +1. 错过一笔交易，不等于当天没有机会； +2. 但也不是每天都存在稳定的第二、第三次高质量触发； +3. 多次机会成立的前提，是上游框架仍然有效。 + +它强调的是“再同步能力”，而不是“高频交易冲动”。 + +### 二、Bellwether Timeframe（钟摆周期） + +在 Precision 执行中，短周期图并不负责定义方向，而负责组织当日节奏。15分钟图常被用作 Bellwether： + +1. 标记当日关键高低点与失衡； +2. 组织早盘、午盘、午后的会话节奏； +3. 给低周期触发提供框架边界。 + +**Bellwether 的职责是“框架化噪音”，不是“直接发出买卖按钮”。** + +### 三、Session 分段与机会密度 + +会话内执行需要承认时段差异： + +1. 早盘通常信息密度高、触发多； +2. 午盘常进入效率下降区，属于降频或观望时段； +3. 午后可能出现延续段或新的结构确认段。 + +因此，“多次 Setup”从来不是全时段等权重，而是按会话质量分配注意力与风险。 + +### 四、Parent / Subordinate 执行结构 + +Precision 体系要求： + +1. Intermediate-Term 提供框架与方向权限； +2. Short-Term 提供入场精度与风险优化。 + +落地上常表现为： + +- 父级结构定义“做哪边”； +- 子级数组（如低周期 OB / FVG）定义“在哪做、怎么做”。 + +### 五、Objective 未完成前的再参与 + +会话内重入不是随意加仓，而是建立在一个前提上： + +**中期结构仍有效，且主 Objective 尚未完成。** + +在这个前提下，价格回到低周期可执行区域时，才有“第二次表达风险”的意义。 + +### 六、递减风险（Declining Risk Ladder） + +多次参与的风险分配应遵循“边际递减”而非“边际放大”。 + +常见实践是： + +1. 第一笔标准风险； +2. 第二笔降档风险； +3. 第三笔继续降档或不再参与。 + +这样做的目的，是防止“重入”退化为“补亏行为”。 + +--- + +## 42.4　底层逻辑 + +### 一、会话内多次机会，本质是同一叙事的多次表达 + +只要上游 Narrative 与 Draw 未变，价格在会话内出现多段可执行波动是正常现象。问题不在“有没有第二次机会”，而在“第二次机会是否仍服务同一目标”。 + +如果目标已达、结构已失效，却仍以“会话内多次机会”为理由继续开仓，本质是在用正确术语掩盖错误行为。 + +### 二、错过交易本身不可怕，节奏崩坏才可怕 + +多数账户回撤并非来自第一笔亏损，而来自第一笔之后的情绪连锁：追价、重仓、缩短确认、连续试错。会话内再同步规则的价值，正是把“情绪反应”改写成“流程反应”。 + +### 三、早盘多触发不代表全天都高质量 + +会话内结构密度本来就不均匀。早盘常出现清晰波动，午盘常出现流动性不足、震荡拉扯。把“早盘的执行标准”照搬到午盘，通常会显著降低胜率与盈亏比。 + +### 四、PM Setup 的价值在于“新验证”，不是“补偿交易” + +午后机会成立的前提不是“早上没赚到”，而是“午后出现了新的结构确认”。 + +这一区分非常关键： + +- 补偿交易来自情绪； +- PM Setup 来自证据。 + +### 五、重入是否成立，必须回到中期结构 + +会话内执行最常见误区是：短周期一有波动就当新机会。更稳健的做法是先回到中期检查： + +1. 中期低点/高点是否仍保持； +2. 主 Draw 是否仍未完成； +3. 当前回撤是修复还是接管。 + +只有这三项仍支持原叙事，低周期重入才有意义。 + +### 六、递减风险是把“可做”变成“可持续”的关键 + +会话内多次参与会自然放大交易次数。如果不做风险递减，单日暴露容易失控，最终把“高质量再同步”做成“高频试错”。 + +递减风险规则的核心不是保守，而是把概率优势与账户生存统一起来。 + +### 七、会话内执行必须有终止条件 + +以下任一出现，应停止当日再同步： + +1. 主目标完成，剩余空间不足； +2. 中期结构失效，原叙事被否定； +3. 进入低效率时段且没有新证据； +4. 当日风险预算已达上限。 + +没有终止条件的“多次机会”，最终通常会演变成“多次消耗”。 + +--- + +## 42.5　结构关系 + +### 一、承接第41章 + +第41章给出 Precision 结构判读顺序（先叙事后结构、先中期后短期），本章把这一顺序落地到会话内执行管理： + +- 第41章解决“怎么看结构”； +- 第42章解决“同一天怎么按结构做多次决策”。 + +### 二、通向第43章 + +本章给出“会话内再同步”的执行语法；第43章会把这套语法迁移到不同资产（外汇与指数期货）的场景中，处理参数差异与执行约束。 + +### 三、通向风险章节 + +本章的递减风险、目标完成后停止新增仓位、单日终止条件，会直接进入后续账户管理章节，成为回撤控制的关键前置规则。 + +--- + +## 42.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：早盘错过首笔，二次回踩再同步 + +常见路径： + +1. 早盘先出现第一段位移； +2. 第一触发错过，不追； +3. 价格回到子级执行区； +4. 在同一 Draw 未完成前提下完成二次参与。 + +这类交易的关键不是“我做了第二笔”，而是“第二笔与第一笔服务同一目标”。 + +### 二、标准情境B：早盘无清晰触发，午后出现高质量结构 + +常见路径： + +1. 早盘主要完成流动性处理或方向试探； +2. 午后才给出更清晰的位移与承接； +3. 交易者在午后按确认链执行，而不是因为“早盘没做成”而强做。 + +### 三、标准情境C：主目标未达前的分段推进 + +常见路径： + +1. 第一段推进后出现回补； +2. 回补未破中期结构； +3. 第二段再推进继续服务主目标。 + +此时第二次参与本质是“路径中继”，不是“方向重猜”。 + +### 四、反例情境：missed trade 后追单连锁 + +典型错误链： + +1. 首笔错过； +2. 第二笔追价； +3. 回撤止损后情绪化加码； +4. 午盘继续低质量交易。 + +最终结果往往是：方向本来没错，但执行节奏全面失控。 + +### 五、实盘中的真实难点 + +会话内执行最难的不是“看信号”，而是“守顺序”： + +- 先框架，后触发； +- 先中期，后短期； +- 先风险，后收益。 + +能在错过后继续守顺序，才是 Precision 执行真正的分水岭。 + +--- + +## 42.7　执行意义 + +### 一、会话内再同步五步框架 + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 上游框架是否仍有效 | 先复核 Narrative、Draw、中期结构 | +| 触发 | 当前是否处在有效会话窗口 | 仅在高信息时段评估新机会 | +| 确认 | 是否出现同向结构承接证据 | 回补后看接管与数组反应 | +| 执行 | 本次参与是否具备风险优势 | 子级区域执行，采用递减风险 | +| 退出 | 是否触发终止条件 | 目标达成、结构失效或时段失效即停止 | + +### 二、会话内执行的四条硬规则 + +1. **无框架，不重入。** +2. **无确认，不重入。** +3. **不递减风险，不重入。** +4. **目标已达或结构失效，禁止继续新增风险。** + +### 三、重入前必答清单 + +每次二次参与前，必须回答： + +1. 本次交易服务哪个目标？ +2. 与上一笔相比，结构条件是否更好而不是更差？ +3. 本次风险是否低于前一笔？ +4. 若失败，失效条件在哪里？ + +任一问题答不清，宁可等待。 + +### 四、仓位管理建议 + +1. 第一笔用标准风险； +2. 第二笔仅在条件更优时参与，且风险降档； +3. 第三笔只在中期结构仍强且目标仍远时考虑； +4. 当日累计风险达到预设阈值后，停止新单。 + +--- + +## 42.8　常见误区 + +### 误区一：把“多次机会”理解成“多次尝试” + +**识别信号：** 同一会话连续开仓，但没有同一目标与同一框架。 +**纠偏动作：** 任何再参与都要明确“它与上一笔是否同一叙事链”。 + +### 误区二：错过后立刻追价 + +**识别信号：** 入场越来越晚、止损越来越近、情绪越来越急。 +**纠偏动作：** 错过后先回到 Bellwether 重画结构，再决定是否存在下一次窗口。 + +### 误区三：重入时放大风险 + +**识别信号：** 第二笔风险高于第一笔。 +**纠偏动作：** 强制执行递减风险阶梯，防止补亏行为。 + +### 误区四：午盘继续用早盘强度交易 + +**识别信号：** 午盘频繁开仓但质量显著下降。 +**纠偏动作：** 时段降权，午盘优先观察与等待。 + +### 误区五：目标完成后仍加仓 + +**识别信号：** 已触及主目标仍持续新增头寸。 +**纠偏动作：** 目标完成后只做管理，不做扩张。 + +### 误区六：短周期波动推翻中期结构 + +**识别信号：** 1-5分钟来回波动导致频繁改判。 +**纠偏动作：** 保持“中期定框架、短期定入口”分工。 + +--- + +## 42.9　高阶深化 + +### 一、再同步不是“补单”，而是“重获权限” + +高阶执行里，每次重入都需要重新获得交易权限： + +1. 方向权限：叙事未变； +2. 结构权限：关键位未失； +3. 时间权限：窗口仍在； +4. 风险权限：预算仍有。 + +四项任一缺失，都不应继续参与。 + +### 二、会话内机会分级 + +建议将会话内机会划分为 A/B/C 三级： + +1. **A级：** 叙事、结构、时段、位置四项同向； +2. **B级：** 三项同向，一项一般； +3. **C级：** 仅局部信号，不具备完整闭环。 + +实务上，A级可常规执行，B级降仓，C级观察。 + +### 三、从“怕错过”到“等二次结构” + +多数不必要亏损来自“怕错过第一笔”。 + +成熟执行者更关注： + +- 第一笔错过后，是否会有更低风险的第二次结构； +- 若没有，就接受“今天不做这一段”。 + +这种心智会显著降低追价交易占比。 + +### 四、统一工作公式 + +> **Session Re-Sync Quality = Framework Integrity × Timing Validity × Structure Continuity × Risk Decay Discipline × Objective Distance** + +该公式用于判断“当前是否值得二次参与”。 + +--- + +## 42.10　本章总结 + +1. 会话内 Multiple Setups 的核心是再同步，不是增加次数。 +2. 再同步必须建立在同一 Narrative、同一 Draw、同一中期结构前提下。 +3. 早盘、午盘、午后机会密度不同，执行强度必须随时段调整。 +4. 递减风险与终止条件，是会话内执行可持续的底线。 +5. 本章把 Precision 结构能力转化为“同日连续决策能力”。 + +--- + +## 42.11　训练清单 + +### 一、观察任务 + +连续 20 个交易日记录： + +1. 首次机会是否错过； +2. 是否出现第二次可执行窗口； +3. 第二次窗口是否与首次同一叙事链。 + +### 二、标注任务 + +对每次再参与填写四栏： + +1. 框架是否未变； +2. 会话窗口是否有效； +3. 结构是否承接； +4. 风险是否递减。 + +### 三、执行任务 + +下一轮交易只允许执行满足以下条件的重入： + +1. 叙事未变； +2. 中期结构未失； +3. 风险降档； +4. 目标仍有空间。 + +### 四、复盘任务 + +对比两类样本： + +1. 情绪重入； +2. 规则重入。 + +统计胜率、盈亏比、单日最大回撤差异。 + +### 五、达标标准 + +在连续四周内，将“missed trade 后追价入场”比例降至 15% 以下，并保持稳定。 + +--- + +## 章末注释 + +[1] 本章围绕 Precision 执行、Bellwether、会话分段、PM 机会、Subordinate 执行与递减风险等语义，依据两份PDF的相关章节整理。 +[2] 文中的风险阶梯、评分与阈值用于流程化训练，不构成收益承诺；实际参数应根据品种波动与账户约束校准。 +[3] 本章与第41章共同构成“结构判读—会话执行”闭环，并为第43章跨市场应用提供统一执行语法。 + + + +# 第43章　Applying Institutional Order Flow：Forex Markets 与 Index Futures + +## 43.1　本章核心问题 + +走到本章，交易者通常会出现一个新的断层： + +- 在某一市场（如外汇）执行还算稳定； +- 一旦切到另一市场（如指数期货），原来的流程就开始失真。 + +最常见的两种极端是： + +1. 认为所有市场完全一样，机械照搬同一参数； +2. 认为所有市场完全不同，每换一个品种就重建一套体系。 + +这两种做法都会带来稳定性问题。前者会忽略市场微结构差异，后者会丢掉方法论的一致性。 + +因此，本章只解决一个主问题： + +**如何把 Institutional Order Flow 的核心流程跨市场迁移，同时保留必要的品种化参数。** + +围绕该主问题，本章回答四个子问题： + +1. 什么是跨市场“可迁移层”，什么是“需本地化层”； +2. 外汇与指数期货在执行上有哪些关键差异； +3. 跨市场确认如何降低误判与冲突交易； +4. 如何把跨市场分析写成一套统一且可复盘的流程。 + +--- + +## 43.2　一句话结论 + +**Institutional Order Flow 的骨架是跨资产通用的：先大局、再框架、后触发；但执行参数必须市场化：会话节奏、工具适配、合约机制与相关性过滤要按品种重设。** + +--- + +## 43.3　基础定义 + +### 一、Applying Institutional Order Flow（跨市场应用） + +本章所说的“应用”，不是把同一张模板直接贴到所有品种，而是分两层处理： + +1. **流程层（通用）：** Narrative -> Draw -> Bias -> Execution； +2. **参数层（品种化）：** 会话特征、波动结构、合约规则、相关性过滤。 + +流程层不变，参数层可变。 + +### 二、三层视角框架（Big Picture / Intermediate / Short-Term） + +跨市场应用的上游顺序固定为三层： + +1. **Big Picture：** 宏观、利率、跨市场、季节因素； +2. **Intermediate：** Top-Down 结构、持仓与情绪信息； +3. **Short-Term：** 相关性、时间理论、日内递送节奏。 + +这三层的作用不是增加复杂度，而是给不同信息分配不同权重，避免低周期噪音覆盖上游结论。 + +### 三、跨资产的一致起点 + +跨市场分析的统一起点是： + +1. 从高周期开始定义当前交易范围与订单流状态； +2. 将高周期关键数组逐级下传到中低周期； +3. 在低周期只做执行精度优化，不再重建方向。 + +这一定义说明“跨资产可迁移”的核心不是某个单独工具，而是 Top-Down 的决策顺序。 + +### 四、外汇与指数期货的工具边界 + +跨市场应用必须尊重工具边界： + +1. 指数期货可围绕 Daily Range、Intra-day Layout、Daily Profiles 建模； +2. 某些工具在外汇语境下更强（如亚洲时段区间），不应机械照搬到指数期货。 + +**同一术语在不同市场的有效性并不等权。** + +### 五、指数期货的合约机制约束 + +指数期货执行还需要加入合约层变量： + +1. 交割月切换； +2. 到期日临近时的流动性与行为变化； +3. 历史样本的换月处理。 + +若忽略这些约束，回测与实盘会出现系统偏差。 + +### 六、跨品种相关性与过滤 + +跨市场应用不是“多看几个图”，而是用相关结构做质量过滤： + +1. 外汇可用跨货币关系区分“爆发型”与“震荡型”对； +2. 利率与跨市场结构可用于验证或降级当下叙事； +3. 当外部关系明显冲突时，应先降风险，再谈执行。 + +### 七、跨市场应用的风控底线 + +不论哪个市场，模式都可能失败。跨市场迁移的第一原则不是“找到更多机会”，而是“先保证同一套风控纪律不变”。 + +--- + +## 43.4　底层逻辑 + +### 一、流程可迁移，参数必须本地化 + +这是本章最核心的逻辑。 + +很多“跨市场失效”并不是方法错，而是层级错：把参数层误当流程层。比如流程上应先做 Top-Down，这在所有市场都成立；但具体会话划分、波动窗口、工具权重，必须按市场重设。 + +### 二、先统一决策顺序，再谈市场差异 + +跨市场执行最忌讳“先看局部波动，再临时拼叙事”。 + +正确顺序应始终是： + +1. 先确认高周期叙事和方向权限； +2. 再确认中周期结构是否支持； +3. 最后在短周期寻找执行触发。 + +顺序稳定，迁移才稳定。 + +### 三、跨市场差异并不否定同一语言系统 + +外汇和指数期货在微结构上确实不同，但它们都可以使用同一语言系统： + +- 目标由 Draw 决定； +- 位置由 Range 与数组决定； +- 执行由会话与结构确认决定。 + +真正需要调整的是“参数”，不是“语法”。 + +### 四、相关性过滤的价值在于减少冲突交易 + +当单市场信号看起来成立，但跨市场或利率层面不支持时，最成熟的动作通常不是“硬做”，而是： + +1. 降仓； +2. 降频； +3. 等待一致性恢复。 + +这一步对降低回撤尤其关键。 + +### 五、跨市场应用的本质是“统一方法 + 差异配置” + +把一套方法迁移到多个市场，真正的收益不是“交易更多品种”，而是： + +1. 判断语法一致； +2. 错误更容易定位； +3. 复盘更容易比较与迭代。 + +### 六、风险收益约束在跨市场中更重要 + +跨市场执行容易产生“机会变多”的错觉，从而放松风险门槛。成熟做法应保持统一的最低风险收益要求，防止因为品种切换而稀释交易质量。 + +### 七、跨市场迁移失败常见于三种断点 + +1. 只迁移工具，不迁移顺序； +2. 只迁移信号，不迁移风控； +3. 只迁移结论，不迁移验证链。 + +修复这三类断点，跨市场稳定性会明显提升。 + +--- + +## 43.5　结构关系 + +### 一、承接第41–42章 + +第41章建立 Precision 结构语言，第42章建立会话内再同步规则。本章把这两者从“单市场内稳定”，推进到“跨市场可复制”。 + +### 二、通向第44–45章 + +跨市场应用最终要落到账户层： + +1. 统一的风险预算； +2. 一致的回撤控制； +3. 标准化的分批与退出纪律。 + +如果本章不稳，后续风控会因为市场切换而失去一致性。 + +### 三、与全书链路的接口 + +本章把前三大链路合并： + +- 叙事链（Narrative -> Draw -> Bias）； +- 结构链（HTF 框架 -> LTF 触发）； +- 执行链（会话窗口 -> 风险管理）。 + +跨市场应用，本质上就是这三条链在不同资产上的一致复现。 + +--- + +## 43.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：外汇中的跨品种过滤 + +常见流程： + +1. 先在高周期定义主叙事与主目标； +2. 再看相关货币对是否呈现同向支持或对冲冲突； +3. 若一致，执行升权；若冲突，执行降权。 + +这样做可以显著减少“单图表看起来不错，但整体环境不支持”的交易。 + +### 二、标准情境B：指数期货中的日内建模 + +常见流程： + +1. 用日区间与会话布局组织当日路径； +2. 用 Bellwether 周期标记关键高低与失衡； +3. 在早盘与午后分别评估结构机会； +4. 午盘时段降低交易强度。 + +该流程的重点是“会话化执行”，而不是“全天等权执行”。 + +### 三、标准情境C：交割合约临近时的执行降档 + +当到期与换月临近，部分行为特征会变化。成熟处理是： + +1. 对样本做合约标注； +2. 对异常波动阶段降仓； +3. 避免用常态参数硬套非常态阶段。 + +### 四、反例情境A：外汇工具硬迁移到指数期货 + +只复制工具，不重设会话与结构参数，常出现“术语正确、结果失真”。 + +### 五、反例情境B：忽视外部确认 + +单市场信号成立就重仓推进，忽视跨市场冲突，往往会放大回撤并降低策略一致性。 + +### 六、实盘中的真实难点 + +跨市场执行最难的不是“学新工具”，而是“守同一顺序”。 + +顺序一乱，任何市场都不稳定；顺序稳定，参数调整才有意义。 + +--- + +## 43.7　执行意义 + +### 一、跨市场统一执行模板（五步） + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 高周期叙事是否清晰 | 先做 Top-Down，确认主方向与主目标 | +| 触发 | 当前市场参数是否适配 | 设定会话、工具、合约与波动过滤 | +| 确认 | 外部关系是否支持 | 相关性、利率、跨市场一致性过滤 | +| 执行 | 入场是否服务同一 Draw | 低周期只做精度优化，不重建方向 | +| 退出 | 风险边界是否触发 | 失效立即退出，目标达成分层兑现 | + +### 二、“共通层—参数层”双清单 + +每个市场开盘前都应完成两张清单： + +1. **共通层：** Narrative、Draw、Bias、结构边界； +2. **参数层：** 会话窗口、工具权重、合约状态、过滤规则。 + +双清单齐全后，跨市场执行会显著稳定。 + +### 三、冲突处理规则 + +当市场内信号与外部确认冲突时，优先采用： + +1. 降仓； +2. 缩短持仓； +3. 等待下一次一致性窗口。 + +不要用“我更熟这个品种”来覆盖冲突证据。 + +### 四、跨市场执行的最小风控约束 + +1. 风险收益不达标不做； +2. 样本不干净（如换月影响未处理）不做； +3. 叙事未形成闭环不做。 + +这些约束比“多一个品种机会”更重要。 + +--- + +## 43.8　常见误区 + +### 误区一：把跨市场迁移理解成参数复制 + +**识别信号：** 不同市场使用同一会话模板、同一工具权重。 +**纠偏动作：** 保留流程一致，重设参数差异。 + +### 误区二：忽略合约机制 + +**识别信号：** 指数期货回测与实盘不处理换月与到期。 +**纠偏动作：** 把合约状态纳入样本与执行前检查。 + +### 误区三：只看单市场，不看外部确认 + +**识别信号：** 外部冲突明显仍重仓执行。 +**纠偏动作：** 建立跨市场过滤闸门，冲突时优先降风险。 + +### 误区四：先找图形，后补叙事 + +**识别信号：** 分析总在事后成立，事前不稳定。 +**纠偏动作：** 恢复“先大局后触发”的固定顺序。 + +### 误区五：把失败归因于“品种问题” + +**识别信号：** 规则违规后仍用市场差异做借口。 +**纠偏动作：** 先审计流程一致性，再讨论品种特性。 + +### 误区六：跨市场后放松风险约束 + +**识别信号：** 因机会变多而提高总暴露。 +**纠偏动作：** 保持统一风险预算，不因品种增加而放宽纪律。 + +--- + +## 43.9　高阶深化 + +### 一、跨市场应用的核心竞争力是“同语法复盘” + +高阶交易者的优势，不是会更多品种，而是能用同一套语言复盘不同资产： + +1. 同样记录叙事； +2. 同样记录目标与结构； +3. 同样记录失效与修正。 + +这样可以显著提升策略迭代效率。 + +### 二、构建“市场适配矩阵” + +建议为每个市场建立三类参数： + +1. **必用参数：** 会话窗口、关键周期、风险门槛； +2. **可选参数：** 相关性过滤、附加确认； +3. **禁用参数：** 在该市场稳定性不足的工具。 + +有了适配矩阵，迁移就不再依赖临场感觉。 + +### 三、跨市场冲突的优先级管理 + +当出现冲突时，先问三件事： + +1. 高周期叙事是否一致； +2. 中周期结构是否一致； +3. 短周期触发是否一致。 + +一致项越少，执行强度越低。 + +### 四、统一工作公式 + +> **Cross-Market Execution Quality = Universal Process Integrity × Market Parameter Fit × External Confirmation Consistency × Risk Discipline** + +该公式用于评估“本次跨市场执行是否具备可持续性”。 + +--- + +## 43.10　本章总结 + +1. Institutional Order Flow 可跨市场迁移，但只能迁移流程，不能机械复制参数。 +2. 外汇与指数期货的差异主要在会话、工具适配与合约机制，不在核心决策顺序。 +3. 跨市场确认的意义是过滤冲突交易，而不是制造信息负担。 +4. 稳定的跨市场执行来自“同一语法 + 差异配置 + 一致风控”。 +5. 本章完成了从“单市场可执行”到“多市场可复制”的方法升级。 + +--- + +## 43.11　训练清单 + +### 一、观察任务 + +选择外汇与指数期货各一个标的，连续四周记录： + +1. 高周期叙事； +2. 主 Draw； +3. 会话参数； +4. 外部确认结果。 + +### 二、标注任务 + +为每个市场建立“共通层—参数层”双清单，并在每周复盘时更新。 + +### 三、执行任务 + +任何跨市场交易前必须完成： + +1. Top-Down 框架确认； +2. 参数适配确认； +3. 风险预算确认。 + +缺一项，不开仓。 + +### 四、复盘任务 + +统计两类交易的绩效差异： + +1. 完整执行双清单的交易； +2. 未完成双清单的交易。 + +重点观察胜率、盈亏比与回撤。 + +### 五、达标标准 + +在连续四周内，将“跨市场参数误配导致的错误交易”比例降至 20% 以下，并保持稳定。 + +--- + +## 章末注释 + +[1] 本章围绕跨资产的一致 Top-Down 起点、三层视角、跨市场相关性、指数期货会话建模与合约机制约束，依据两份PDF相关内容整理。 +[2] 本章“共通层—参数层”框架属于方法组织工具，不构成收益承诺；不同市场需结合流动性、交易时段与样本质量进行本地化校准。 +[3] 本章是“结构执行”向“跨市场可复制执行”的桥接章节，后续风险与仓位管理章节应以本章的流程一致性为前提。 + +# 第九部分　风险、目标与账户生存 + +前八部分已经回答“如何识别与执行”。 +第九部分回答另一个决定长期结果的问题： + +**如何在不确定市场中活得足够久，直到优势兑现。** + +--- + +## 本部分定位 + +本部分把风险管理从“口号”变成“动作”： + +1. 用 Reward-to-Risk 约束样本质量； +2. 用 Drawdown 管理系统波动； +3. 用分层止盈和仓位控制减少回吐； +4. 用复利规则避免风险失控。 + +--- + +## 两章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第44章 | R 倍数、回撤与复利如何协同 | +| 第45章 | 无效点、止损、仓位、分批止盈如何标准化 | + +--- + +## 学习边界 + +第九部分最容易被误学成“保守就安全”。 +请固定原则： + +**风险管理不是减少收益，而是提高收益的可持续性。** + +--- + +## 学完应具备 + +完成第九部分后，你应能： + +1. 在入场前写出风险收益结构。 +2. 在持仓中按规则减仓与保护利润。 +3. 在连续失利时自动降级风险。 +4. 用账户曲线而非单笔盈亏评估系统质量。 + +--- + +## 与后续章节的连接 + +第十部分将把风险控制与研究复盘结合， +完成从“会执行”到“会迭代”的最后闭环。 + +--- + +## 章末注释 + +[1] 本导读用于连接第八部分执行能力与第九部分账户管理能力。 +[2] 建议进入第十部分前，先复核第44章回撤规则与第45章分批兑现标准。 + + + +# 第44章　Reward-to-Risk、Drawdown 与 Compounding + +## 44.1　本章核心问题 + +很多交易者在技术层面学得很快，但账户曲线始终不稳定。最常见的根源不是“看不懂图”，而是把交易目标设成了“短期暴利”，而不是“长期存活与复利”。 + +这会带来几个典型后果： + +1. 为了快，放大单笔风险； +2. 为了回本，连续重仓； +3. 只盯胜率，不看盈亏结构； +4. 忽视回撤约束，导致账户无法持续执行同一模型。 + +本章只解决一个主问题： + +**如何把 Reward-to-Risk、Drawdown 与 Compounding 组织成同一套账户生存框架。** + +围绕该主问题，本章回答四个子问题： + +1. 为什么“低回撤”比“高爆发”更重要； +2. 为什么胜率不高也能稳定盈利； +3. 单笔风险应如何与 R 倍数匹配； +4. 小账户如何在不过度冒险的前提下实现复利。 + +--- + +## 44.2　一句话结论 + +**可持续盈利来自“风险先行”的结构：先控制单笔风险与总回撤，再用 3:1 起步、5:1 优先的盈亏结构放大正期望，最后通过小幅稳定复利而非大幅冒险增长账户。** + +--- + +## 44.3　基础定义 + +### 一、Reward-to-Risk（盈亏比） + +Reward-to-Risk 用于描述“平均盈利单位”与“平均亏损单位”的关系。它回答的不是“这一单会不会赢”，而是“长期下来每次冒1份风险能换回多少份收益”。 + +本书执行语境下，3:1 可作为基础门槛，5:1 属于更优结构。 + +### 二、Drawdown（回撤） + +Drawdown 是账户从阶段高点回落到低点的跌幅。它是系统可持续性的核心约束。回撤过高时，即使模型方向正确，执行纪律也会被心理压力破坏。 + +**低回撤不是保守，而是寿命。** + +### 三、Compounding（复利增长） + +复利不是靠单笔暴利实现，而是靠“可重复的小幅正增长”累积。即使每周只完成有限收益，只要风险受控、周期稳定，长期曲线仍可显著上升。 + +### 四、单笔风险（Risk Per Trade） + +单笔风险是每次交易允许亏损的账户比例。实践上常见 1% 或更低风险作为基准。核心不是固定某个数字，而是： + +1. 风险要可承受； +2. 连续亏损后仍能继续执行； +3. 不因情绪放大。 + +### 五、正期望（Expectancy） + +正期望由三项共同决定： + +1. 胜率； +2. 盈亏比； +3. 执行纪律。 + +高胜率不等于正期望，低胜率也不必然亏损。若盈亏比足够高，较低胜率仍可保持净盈利。 + +### 六、过程导向（Process-Oriented Thinking） + +账户增长的底层能力不是“反应速度”，而是“过程一致性”：先定义环境、再定义参数、再定义可执行条件，最后复盘修正。冲动式交易的反义词不是“慢”，而是“有流程”。 + +--- + +## 44.4　底层逻辑 + +### 一、账户增长先解决“活着”，再解决“长大” + +任何复利模型的前提都是可持续执行。若回撤过大，交易者会在心理与资金层同时失去执行能力。于是“理论上的高收益”无法变成“现实中的可重复收益”。 + +### 二、胜率不是第一优先级，盈亏结构才是 + +很多交易者过度追求“每十笔赢七八笔”。但在风险管理模型里，更关键的是： + +1. 亏损时能否小亏； +2. 盈利时能否放大利润段； +3. 总体 R 倍数是否为正。 + +当盈亏结构合理时，即使胜率只有三到五成，账户仍可能稳定增长。 + +### 三、低风险并不等于增长慢 + +“只要风险小，账户就长不大”是常见误解。现实是：风险小 + 结构优 + 执行稳，通常优于风险大 + 情绪化 + 回撤失控。尤其在复利框架中，小幅稳定收益会随着基数扩大而逐步放大。 + +### 四、3:1 与 5:1 的意义是“覆盖亏损能力” + +盈亏比门槛的本质，不是追求漂亮数字，而是提高系统对亏损序列的耐受度： + +1. 3:1 让系统在较低胜率下仍有正期望空间； +2. 5:1 进一步增强“少数大赚覆盖多数小亏”的能力。 + +### 五、回撤控制是复利的闸门 + +很多账户在“技术上会做”但“资金上做不下去”，根本原因就是回撤曲线过陡。回撤控制做得好，交易者才能在同一策略上持续积累样本，从而真正进入复利区间。 + +### 六、过程纪律优先于结果情绪 + +在风险章节里，最重要的思维是： + +1. 亏损是业务成本，不是身份否定； +2. 每笔交易先看是否符合模型，再看是否盈利； +3. 账户曲线取决于长期流程，不取决于单笔胜负。 + +### 七、成长目标必须阶段化 + +不切实际的收益目标会反向破坏执行。更有效的路径是： + +1. 先达成可持续小目标； +2. 再扩展到更高收益阶段； +3. 最后在风险可控前提下放大规模。 + +--- + +## 44.5　结构关系 + +### 一、承接第35–43章 + +前面章节建立了“什么时候做、做哪边、在哪里做、如何会话内同步”的技术链条。本章把这些技术能力收束到账户层，回答“做对之后如何长期活下来”。 + +### 二、通向第45章 + +本章给出风险框架（R:R、回撤、复利），第45章会进一步落到执行颗粒度：无效点、止损摆放、仓位计算、分批止盈。 + +### 三、与研究复盘章节的关系 + +后续第46–48章会把本章的资金原则转成可训练系统：通过回测与日志验证“模型收益结构是否真的支撑复利”。 + +--- + +## 44.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：中等胜率 + 高盈亏比 + +常见样本是： + +1. 胜率并不高； +2. 但亏损可控； +3. 盈利段能做到 3R 以上。 + +这类系统在连续样本中往往比“高胜率小止盈大止损”更稳定。 + +### 二、标准情境B：分段止盈提升曲线稳定 + +当交易先达到 3R 附近，先兑现部分仓位，再让剩余仓位追更远流动性，常能同时兼顾“锁定收益”和“保留扩展”。 + +### 三、标准情境C：小账户稳步复利 + +即使初始资金不大，只要风险固定、回撤受控、执行一致，账户仍可通过复利逐步扩大。关键在于“稳定重复”，而不是“单次爆发”。 + +### 四、反例情境A：高风险换高增长幻想 + +单笔风险过大时，连续几笔亏损就会显著削弱账户恢复能力，最终逼迫交易者改变策略或情绪化加仓。 + +### 五、反例情境B：只追胜率不看盈亏结构 + +看起来“经常对”，但一两次亏损就吞掉前面多笔盈利，长期曲线仍难以向上。 + +--- + +## 44.7　执行意义 + +### 一、账户层五步执行框架 + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 这笔交易是否满足最小盈亏结构 | 不满足最低 R:R 直接放弃 | +| 触发 | 单笔风险是否在预算内 | 先定风险金额，再定手数 | +| 确认 | 失效与止损是否客观 | 无效点不清不交易 | +| 执行 | 是否遵守部分兑现与延伸规则 | 到达阶段目标先锁定部分利润 | +| 退出 | 是否触发回撤与日内风控阈值 | 达阈值停止新增风险 | + +### 二、账户管理三条硬规则 + +1. **先定风险，再谈收益。** +2. **先守回撤，再谈复利。** +3. **先保流程一致，再谈提高频率。** + +### 三、最低可执行标准 + +建议建立最低门槛： + +1. 无法形成 3:1 结构，不做； +2. 单笔风险超预算，不做； +3. 失效位置不清，不做； +4. 当日已触回撤上限，停止交易。 + +### 四、收益目标的阶段化管理 + +1. 第一阶段：先稳定“月度小幅正收益”； +2. 第二阶段：在不放大回撤的前提下提升 R 倍数； +3. 第三阶段：仅在长期稳定后才考虑放大规模。 + +--- + +## 44.8　常见误区 + +### 误区一：急于短期暴利 + +**识别信号：** 放大单笔风险、频繁加仓、忽视回撤。 +**纠偏动作：** 把增长目标拆成阶段目标，先守资金曲线稳定。 + +### 误区二：把低风险误解为低成长 + +**识别信号：** 因为“赚得慢”而提高风险。 +**纠偏动作：** 以复利视角评估收益，不以单周结果评估系统。 + +### 误区三：只看胜率不看盈亏比 + +**识别信号：** 高频小赚 + 偶发大亏。 +**纠偏动作：** 强制记录平均盈利R与平均亏损R，优先优化结构。 + +### 误区四：止损预算随情绪变化 + +**识别信号：** 连亏后加大赌注，连赢后放松纪律。 +**纠偏动作：** 固定单笔风险预算，禁止情绪性改动。 + +### 误区五：忽视回撤阈值 + +**识别信号：** 已触账户回撤上限仍持续交易。 +**纠偏动作：** 预设日内/周内停止规则，触发即停。 + +### 误区六：把亏损当异常，把盈利当常态 + +**识别信号：** 对亏损极度抗拒，导致执行变形。 +**纠偏动作：** 将亏损视为业务成本，用样本统计管理预期。 + +--- + +## 44.9　高阶深化 + +### 一、账户增长的本质是“正期望 × 执行一致性” + +高阶交易不是“会更多模型”，而是“让同一正期望模型在长样本中稳定落地”。 + +### 二、回撤管理是策略寿命管理 + +策略并不是因为“方向错误”才死亡，更多时候死于回撤过大导致的执行断裂。把回撤当作第一指标，策略寿命会显著延长。 + +### 三、分层兑现与复利的耦合 + +部分止盈并不是减少收益，而是通过降低收益回吐来平滑曲线。曲线更平滑，复利效率往往更高。 + +### 四、统一工作公式 + +> **Account Growth Quality = Positive Expectancy × Drawdown Control × Risk Consistency × Compounding Discipline** + +该公式用于评估账户是否处于“可持续增长”状态。 + +--- + +## 44.10　本章总结 + +1. 账户生存优先级高于单笔收益；低回撤是长期盈利前提。 +2. 胜率并非唯一核心，盈亏比与执行纪律共同决定正期望。 +3. 3:1 是基础门槛，5:1 是结构优化方向。 +4. 复利依赖小幅稳定增长，不依赖高风险爆发。 +5. 本章为第45章的止损、仓位与分批执行提供资金框架底座。 + +--- + +## 44.11　训练清单 + +### 一、观察任务 + +回看最近 50 笔交易，统计： + +1. 平均盈利R； +2. 平均亏损R； +3. 胜率； +4. 最大连续亏损数； +5. 最大回撤。 + +### 二、标注任务 + +对每笔交易补充两项： + +1. 这笔是否满足最低 3:1 结构； +2. 单笔风险是否在预算内。 + +### 三、执行任务 + +下一轮交易强制执行： + +1. 不满足最小R:R不做； +2. 达到日内回撤阈值即停。 + +### 四、复盘任务 + +比较两类样本绩效： + +1. 严格风险预算样本； +2. 情绪化放大风险样本。 + +重点观察收益曲线波动与恢复速度。 + +### 五、达标标准 + +连续四周将“超预算风险交易”比例压至 10% 以下，并把最大单周回撤控制在预设阈值内。 + +--- + +## 章末注释 + +[1] 本章围绕盈亏比、低回撤、小风险复利与过程导向执行，依据两份PDF在资金管理与执行纪律相关内容整理。 +[2] 文中阈值与比例用于流程训练，不构成收益承诺；实际参数应依据品种波动和账户承受能力校准。 +[3] 本章与第45章共同构成本书账户生存模块：第44章管框架，第45章管落地动作。 + + + +# 第45章　无效点、止损摆放、仓位控制与分批止盈 + +## 45.1　本章核心问题 + +第44章解决了账户层框架：要以风险先行、低回撤、正期望和复利为核心。接下来必须回答一个更具体的问题： + +**每一笔交易，风险到底如何落地。** + +实盘里最常见的失控，不在“看错方向”，而在“风险动作没有标准”： + +1. 止损按情绪放，不按失效放； +2. 手数按欲望定，不按风险定； +3. 目标只设一个极值点，不做分层兑现； +4. 盈利后不会移动保护，回吐把好单做成平单或亏单。 + +本章只解决一个主问题： + +**如何把无效点、保护性止损、仓位规模与分批止盈，写成可执行的一体化规则。** + +围绕该主问题，本章回答四个子问题： + +1. 无效点应如何客观定义； +2. 止损应该放在什么结构位置； +3. 仓位大小如何从“风险金额”反推； +4. 为什么要“先拿一部分，再让剩余仓位跑目标”。 + +--- + +## 45.2　一句话结论 + +**风险管理的核心不是“少亏”，而是“亏在该亏的位置”：先用结构无效点定义保护性止损，再按固定风险反推仓位，最后用 3R 分段兑现与目标跟踪把收益与回撤同时可控化。** + +--- + +## 45.3　基础定义 + +### 一、Invalidation（无效点） + +无效点是“当前交易假设不再成立”的客观边界。它不是心理止痛点，而是结构被否定的价格条件。 + +无效点的作用有三项： + +1. 决定止损位置； +2. 决定仓位大小； +3. 决定这笔交易是否值得做。 + +### 二、Protective Stop Loss（保护性止损） + +保护性止损应放在“下一层会使前提失效的数组之外”，而不是放在“我不舒服的地方”。 + +在顺多语境下，常见逻辑是止损置于下一层折价参考下方；顺空语境镜像处理，置于下一层溢价参考上方。 + +### 三、Close Proximity Entries（CPE） + +CPE 强调“在开盘区附近寻找更紧凑风险结构”，其核心目的不是提高频率，而是： + +1. 在同样方向判断下，减少无效点距离； +2. 提升可实现的盈亏比； +3. 为错过首笔后的再参与提供更合理风险入口。 + +### 四、Position Sizing（仓位规模） + +仓位不是先定手数再看风险，而是： + +1. 先定单笔可亏损金额； +2. 再根据止损距离反推手数。 + +只有这样，账户风险才会在不同交易中保持一致。 + +### 五、Partial Take Profit（分批止盈） + +分批止盈的核心是“收益分层”： + +1. 第一层先锁定已实现利润； +2. 第二层让剩余仓位服务更远流动性目标。 + +典型做法是先在 3R 附近处理一部分，再把剩余仓位交给更高层目标。 + +### 六、Trail by Respected Arrays（跟随数组移动保护） + +当价格沿目标方向推进时，可将止损逐步移动到“已被市场尊重的数组”之外，作用是： + +1. 保护已实现收益； +2. 降低大幅回吐概率； +3. 在不提前平仓的前提下提升盈亏质量。 + +### 七、Pyramiding with Risk Decay（递减风险加仓） + +在主目标未达且中期结构未失效时，回撤到 OB / Imbalance 可能构成再参与机会。该类加仓必须满足“风险递减”原则：后续加仓风险应低于首笔风险。 + +--- + +## 45.4　底层逻辑 + +### 一、止损位置决定交易质量，而非交易舒适度 + +止损若不放在结构无效点之外，交易会出现两种问题： + +1. 太近：被正常波动扫掉； +2. 太远：仓位被迫缩小或单笔风险超标。 + +因此止损不是“越小越好”，而是“刚好放在前提失效之外最好”。 + +### 二、仓位控制是风险预算的执行器 + +同样的方向判断，因止损距离不同，仓位应不同。若仓位不随止损距离调整，风险会在交易之间失真，最终破坏第44章的资金框架。 + +### 三、分批止盈是把“对”变成“拿到” + +很多交易者最大的痛点不是看错，而是拿不住或回吐。分批止盈的意义在于： + +1. 先把正确判断转成确定收益； +2. 再让剩余仓位争取扩展收益。 + +这样可以同时降低“过早全平”和“过度死扛”的双重风险。 + +### 四、目标未完成前，保护应随结构推进而更新 + +价格推进过程中，新的结构与数组会不断形成。若仍死守初始止损，不仅风险效率低，也容易把已盈利交易重新暴露在过大回撤里。 + +“移动保护”不是主观收紧，而是跟随“被市场确认的结构层级”更新无效边界。 + +### 五、再参与必须服从目标状态 + +若主目标已达，再加仓通常属于收益后段追逐；若目标未达且结构仍完整，再参与才有统计优势。区别不在“有没有回踩”，而在“回踩是否仍服务同一 Objective”。 + +### 六、风险动作必须先写后做 + +本章所有动作（止损、仓位、分批、移动保护）都应在入场前写入计划。临场才决定，等于把规则交给情绪。 + +### 七、风险一致性比单笔漂亮更重要 + +交易系统的长期优势来自“每笔都按规则执行”，而不是“偶尔一笔做得很完美”。风险动作的一致性，决定账户曲线的可复制性。 + +--- + +## 45.5　结构关系 + +### 一、承接第44章 + +第44章给出风险框架，本章给出执行动作。两章关系是： + +- 第44章：为什么必须风险先行； +- 第45章：风险先行如何具体落实。 + +### 二、通向第46–48章 + +后续研究与成长章节会把本章规则转成可量化复盘指标： + +1. 止损是否按无效点放置； +2. 仓位是否按风险反推； +3. 分批与移动保护是否按计划执行。 + +### 三、与模型章节的接口 + +本章不替代模型信号，而是给所有模型提供统一风险底盘。任何模型若不能映射到本章四件事（无效点、止损、仓位、兑现），都不具备实盘稳定性。 + +--- + +## 45.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：3R 先兑现，剩余追外部目标 + +常见路径： + +1. 交易入场后先达到阶段目标； +2. 执行部分止盈； +3. 剩余仓位继续服务更高层流动性； +4. 若后续回撤，也已锁定第一段收益。 + +### 二、标准情境B：结构推进中动态移动保护 + +常见路径： + +1. 价格持续推进； +2. 新的有效数组形成并被尊重； +3. 保护性止损逐步跟进到更有利位置。 + +这类管理常显著降低“盈利大回吐”。 + +### 三、标准情境C：递减风险再参与 + +在目标未达且结构完整时： + +1. 首笔建立方向敞口； +2. 回撤到可执行区域出现第二笔； +3. 第二笔风险低于首笔； +4. 总体风险仍受控。 + +### 四、反例情境A：无效点不清就入场 + +表现为： + +1. 止损随意； +2. 仓位失真； +3. 亏损后无法归因。 + +### 五、反例情境B：不分批只等终极目标 + +表现为： + +1. 中途盈利显著但未锁定； +2. 回撤后情绪化出场； +3. 结果“看对却没拿到”。 + +--- + +## 45.7　执行意义 + +### 一、风险落地五步框架 + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 无效点是否清晰 | 不清晰不交易 | +| 触发 | 止损位置是否客观 | 放在前提失效之外 | +| 确认 | 仓位是否按风险反推 | 固定风险预算下计算手数 | +| 执行 | 分批计划是否预先写好 | 先阶段兑现，再追扩展 | +| 退出 | 是否触发保护更新或失效 | 按数组推进移动保护，失效即退 | + +### 二、入场前四条硬规则 + +1. **先写无效点，再算仓位。** +2. **先确定第一兑现层，再谈扩展层。** +3. **主目标已达，不再新增风险。** +4. **再参与只在风险递减条件下进行。** + +### 三、仓位计算的统一顺序 + +1. 确定单笔可亏损金额； +2. 确定无效点与止损距离； +3. 反推手数； +4. 检查是否满足最低盈亏比； +5. 不满足则放弃交易。 + +### 四、执行记录建议 + +每笔交易至少记录六项： + +1. 无效点； +2. 初始止损； +3. 仓位风险； +4. 第一兑现点； +5. 扩展目标； +6. 移动保护规则。 + +--- + +## 45.8　常见误区 + +### 误区一：止损按情绪放置 + +**识别信号：** 亏损后经常说“本来就不该放这么近/远”。 +**纠偏动作：** 止损必须绑定结构失效，不绑定情绪舒适度。 + +### 误区二：仓位不随止损距离变化 + +**识别信号：** 每次固定手数，不管止损远近。 +**纠偏动作：** 固定风险金额，动态调整手数。 + +### 误区三：只设终极止盈，不做分批 + +**识别信号：** 盈利回吐后情绪波动大。 +**纠偏动作：** 先锁定阶段收益，再保留扩展仓位。 + +### 误区四：盈利后不更新保护 + +**识别信号：** 从大幅浮盈回到小幅盈利甚至亏损。 +**纠偏动作：** 按被尊重数组逐级移动保护。 + +### 误区五：目标已达仍继续加仓 + +**识别信号：** 收益后段风险暴露持续升高。 +**纠偏动作：** 目标完成后停止新增头寸。 + +### 误区六：连亏后提高单笔风险 + +**识别信号：** “想一单赚回来”。 +**纠偏动作：** 连亏阶段只允许降风险，不允许升风险。 + +--- + +## 45.9　高阶深化 + +### 一、风险管理不是防守，而是收益放大器 + +多数人把风险管理理解为“减少亏损”。更高阶的理解是：它让你在正确行情中更有能力持有，在错误行情中更快止损，从而放大净收益质量。 + +### 二、分层兑现与递减风险可以协同 + +常见高阶组合是： + +1. 首笔建立主方向； +2. 3R 附近先兑现一部分； +3. 回撤后以更小风险做再参与； +4. 最终到达外部目标时全平。 + +这样既控制回撤，也保留扩展利润。 + +### 三、把“无效点”升级为“流程锚点” + +高阶执行者会把无效点用作全流程锚点： + +- 入场前：决定是否可做； +- 持仓中：决定何时退出； +- 复盘后：决定模型是否需修正。 + +### 四、统一工作公式 + +> **Risk Execution Quality = Invalidation Clarity × Position Sizing Accuracy × Partial Exit Discipline × Dynamic Protection Consistency** + +该公式用于衡量风险动作是否真正可复制。 + +--- + +## 45.10　本章总结 + +1. 无效点是风险管理起点，止损必须放在前提失效之外。 +2. 仓位应由固定风险金额反推，而不是主观手数决定。 +3. 分批止盈能显著降低“看对却拿不到”的执行损耗。 +4. 目标未达时可考虑递减风险再参与，目标达成后停止新增风险。 +5. 本章把第44章的资金框架落地为可执行的单笔风险动作。 + +--- + +## 45.11　训练清单 + +### 一、观察任务 + +回看最近 40 笔交易，逐笔检查： + +1. 是否先写无效点； +2. 止损是否放在结构失效外； +3. 仓位是否按风险反推。 + +### 二、标注任务 + +每笔交易补写“第一兑现层 + 扩展层 + 保护更新规则”，并记录执行偏差。 + +### 三、执行任务 + +下一轮交易强制执行： + +1. 无效点不清不交易； +2. 不设分批不交易； +3. 不做风险递减不加仓。 + +### 四、复盘任务 + +比较两类样本： + +1. 严格执行风险动作样本； +2. 临场随意决策样本。 + +重点观察：最大回吐、平均R、回撤恢复时间。 + +### 五、达标标准 + +连续四周将“无效点不清即入场”比例降至 10% 以下，并将“盈利回吐到亏损”的样本比例下降 50%。 + +--- + +## 章末注释 + +[1] 本章围绕 Protective Stop、分层兑现、递减风险与仓位控制，依据两份PDF中风险执行相关语义整理。 +[2] 文中比例与阈值用于流程训练，不构成收益承诺；实际参数需结合交易品种和账户约束校准。 +[3] 本章与第44章共同构成“账户生存与风险执行”双章模块。 + +# 第十部分　研究、复盘与专家化成长 + +前九部分解决了框架、执行与风险。 +第十部分解决的是长期成长： + +**如何把一次次交易结果沉淀为可复用能力，而不是重复犯错。** + +--- + +## 本部分定位 + +本部分的核心是建立“研究型交易者”工作流： + +1. 回测不是找历史安慰，而是检验规则边界； +2. 笔记不是流水账，而是模型迭代证据； +3. 日志不是记录输赢，而是记录执行偏差。 + +--- + +## 三章职责 + +| 章节 | 核心问题 | +| --- | --- | +| 第46章 | Backtesting、Study Notes、Journal 的标准字段 | +| 第47章 | 如何把研究结果转成个人执行框架 | +| 第48章 | 从术语学习者到 Precision Technician 的成长路径 | + +--- + +## 学习边界 + +第十部分最容易误学成“形式化记录”。 +请固定原则： + +**研究体系的目标是提高下一笔交易质量，不是增加记录数量。** + +--- + +## 学完应具备 + +完成第十部分后，你应能： + +1. 建立可持续的回测与复盘循环。 +2. 把错误分类为可修复规则。 +3. 让个人框架随证据升级，而非随情绪摇摆。 +4. 形成从学习到执行到迭代的闭环。 + +--- + +## 全书收束 + +十个部分最终汇成同一条执行链： + +`语言与框架 -> 流动性与位置 -> 结构与时间 -> 模型与执行 -> 风险与研究` + +这条链的目标不是“每次都对”，而是“长期稳定地做对更多高质量样本”。 + +--- + +## 章末注释 + +[1] 本导读用于连接第九部分风险管理与第十部分成长体系。 +[2] 建议全书完成后，按第46—48章模板做一次全系统回测与执行审计。 + + + +# 第46章　Backtesting、Study Notes 与 Trading Journal + +## 46.1　本章核心问题 + +很多交易者的问题不在“没学知识”，而在“学了却无法沉淀成稳定能力”。最常见表现是： + +1. 盘中觉得懂，盘后复盘却没有可比样本； +2. 一次做对就自信暴涨，一次做错就全盘否定； +3. 只记结论，不记过程，导致错误反复发生； +4. 研究时间很长，但没有形成可检验数据。 + +本章只解决一个主问题： + +**如何把 Backtesting、Study Notes 与 Trading Journal 建成同一套研究闭环，让“感觉”变成“证据”。** + +围绕该主问题，本章回答四个子问题： + +1. 回测到底该采集哪些数据； +2. Study Notes 与交易日志如何分工； +3. 为什么“过程记录”比“结果截图”更重要； +4. 如何通过样本库持续提升执行稳定性。 + +--- + +## 46.2　一句话结论 + +**高质量成长来自可重复研究闭环：用 Backtesting 采集结构数据，用 Study Notes 提炼模式语言，用 Trading Journal 记录执行偏差，再把三者回灌到下一轮交易计划。** + +--- + +## 46.3　基础定义 + +### 一、Backtesting（回测） + +本书语境下，回测不是“翻图找感觉”，而是对同一模型进行样本化验证。其核心任务是回答： + +1. 这个模型在什么环境下有效； +2. 触发后通常需要多久到达目标； +3. 过程中的回撤与噪音有多大。 + +### 二、Study Notes（学习笔记） + +Study Notes 记录的是“模型认知层”： + +1. 术语定义； +2. 条件边界； +3. 触发链路； +4. 失效标准。 + +它解决“我怎么理解模型”。 + +### 三、Trading Journal（交易日志） + +Trading Journal 记录的是“执行行为层”： + +1. 当时做了什么； +2. 为什么这么做； +3. 是否按规则做； +4. 偏差出现在哪里。 + +它解决“我有没有按模型做”。 + +### 四、回测四个核心问题 + +在实务中，至少要记录四类高价值数据： + +1. 入场回撤等待了多久； +2. 整笔交易从入场到退出用了多久； +3. 入场发生在什么时段； +4. 过程中出现了多少最大不利波动（Drawdown）。 + +这四项能直接连接模型设计与风控设计。 + +### 五、样本库（Example Library） + +样本库不是“收藏截图”，而是按主题分组的可检索案例库。常见分组包括： + +1. 早盘/午后止损清理； +2. 日区间与扩张样本； +3. 趋势延续与趋势转弱样本； +4. 两次入场与会话框架样本。 + +### 六、交易风格定位 + +研究体系必须服务于你的交易风格。常见风格包括： + +1. Position； +2. Swing； +3. Short-Term； +4. Day Trade / Scalping。 + +若风格不明确，回测与日志会出现“样本和执行不匹配”的问题。 + +### 七、过程导向记录 + +研究日志应优先记录“过程是否合规”，而非“单笔盈亏大小”。过程导向是把执行从冲动反应转成标准动作的基础。 + +--- + +## 46.4　底层逻辑 + +### 一、没有数据，改进就会停留在主观层 + +多数交易者复盘失败，是因为“只记结果，不记变量”。没有变量，就无法比较；没有比较，就无法优化。 + +回测与日志的本质，是把“我以为”变成“我验证过”。 + +### 二、Study Notes 与 Journal 的关系是“定义—执行” + +Study Notes 负责定义模型，Journal 负责验证执行。如果只有前者，没有后者，模型会停在理论层；只有后者，没有前者，执行会失去标准。 + +### 三、回测的价值不在预测，而在边界识别 + +回测不是为了证明“这套模型永远正确”，而是为了识别： + +1. 适用环境； +2. 常见失败路径； +3. 风险波动范围； +4. 退出管理节奏。 + +边界清楚，实盘才会稳定。 + +### 四、时段统计能显著提升执行效率 + +同一个 Setup 在不同时间段质量差异很大。记录“入场发生时间”和“完成时间”，可以帮助你识别最有优势的执行窗口，减少低效率时段交易。 + +### 五、样本分层是防止“以偏概全”的关键 + +如果把所有交易混在一起统计，会掩盖真实规律。更有效的做法是按模型类型、会话时段、结构状态做分层统计，找出“哪类样本真正贡献了收益”。 + +### 六、新手最先应追求“反馈速度” + +训练早期，短周期与日内样本反馈更快，更有利于建立执行闭环。长周期样本数量少、反馈慢，不适合用来做最初阶段的行为矫正。 + +### 七、研究闭环必须包含“下一步动作” + +每周复盘若只写“这周好/不好”，价值很低。高质量复盘应落到可执行动作： + +1. 下周保留什么； +2. 下周删除什么； +3. 下周新增什么。 + +--- + +## 46.5　结构关系 + +### 一、承接第44–45章 + +第44–45章给出资金与风险动作标准，本章提供“如何验证这些标准是否真的被执行”的研究方法。 + +### 二、通向第47章 + +第47章会在本章基础上完成升级：从“记录与验证”走向“形成个人执行框架”。 + +### 三、通向第48章 + +第48章的“从术语学习者到 Precision Technician”并不靠听懂更多概念，而靠本章这种持续样本化训练。 + +--- + +## 46.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：同模型多样本回测后发现真实节奏 + +常见结果： + +1. 某模型在特定会话明显更优； +2. 某模型平均回撤超出预期； +3. 某模型到达目标时间显著长于主观想象。 + +这些发现会直接改进入场、止损和持仓时间管理。 + +### 二、标准情境B：日志暴露“执行偏差”而非“模型问题” + +很多亏损并非模型失效，而是执行违规：提前进、延迟出、无确认重入。日志可把“模型问题”和“行为问题”拆开，避免错误归因。 + +### 三、标准情境C：样本库帮助识别高价值环境 + +当样本库累积后，你会更快识别：哪些日型、哪些结构、哪些时段最值得交易，从而减少低质量出手。 + +### 四、反例情境A：只截图，不记录变量 + +表现为： + +1. 看起来复盘很多； +2. 实际无法提炼规则； +3. 下一周重复同样错误。 + +### 五、反例情境B：只记录盈亏，不记录过程 + +表现为： + +1. 账面上有数据； +2. 但无法判断是模型优势还是偶然波动； +3. 无法持续优化。 + +--- + +## 46.7　执行意义 + +### 一、研究闭环五步法 + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 本周重点研究哪一个模型 | 每周只设 1–2 个核心主题 | +| 触发 | 采集哪些统一字段 | 固定记录时段、回撤、耗时、退出类型 | +| 确认 | 样本量是否足够 | 低样本不下结论 | +| 执行 | 下周如何应用结论 | 把结论写入交易前检查项 | +| 复核 | 改动是否有效 | 下周复盘验证改动结果 | + +### 二、最低记录模板（每笔） + +1. 交易类型与模型标签； +2. 叙事与目标； +3. 入场时段； +4. 无效点与风险； +5. 最大不利波动； +6. 退出方式； +7. 是否违规。 + +### 三、周度复盘模板 + +1. 本周总样本数； +2. 合规率； +3. 高质量样本来源（按时段/模型）； +4. 主要亏损来源（模型失效 or 执行违规）； +5. 下周三条调整动作。 + +### 四、研究边界 + +1. 单周小样本不做大结论； +2. 不在情绪高波动时重写模型； +3. 任何模型调整都要保留前后对照样本。 + +--- + +## 46.8　常见误区 + +### 误区一：回测只看“能不能赚钱” + +**识别信号：** 不记录回撤、时段、持仓时间。 +**纠偏动作：** 至少记录四核心字段（入场时段、回撤、耗时、结果）。 + +### 误区二：Study Notes 与 Journal 混写 + +**识别信号：** 定义、情绪、执行混在一起，无法检索。 +**纠偏动作：** 分开维护“模型定义本”与“执行日志本”。 + +### 误区三：样本不足就下结论 + +**识别信号：** 几笔连赢就放大仓位，几笔连亏就推翻模型。 +**纠偏动作：** 建立最小样本门槛，未达门槛只观察不改模。 + +### 误区四：只记盈利案例 + +**识别信号：** 复盘全是好单，坏单缺失。 +**纠偏动作：** 亏损样本必须同等记录，尤其记录违规原因。 + +### 误区五：复盘没有行动项 + +**识别信号：** 每周复盘停在“感觉总结”。 +**纠偏动作：** 每周输出三条可执行改动并在下周验证。 + +### 误区六：风格未定就广撒网 + +**识别信号：** 同时回测多个周期、多个策略，全部浅尝辄止。 +**纠偏动作：** 先明确主风格，再围绕主风格构建样本库。 + +--- + +## 46.9　高阶深化 + +### 一、把研究系统做成“可迭代工程” + +高阶研究的重点不是记录更多，而是让记录可比较、可复用、可升级。统一字段和统一命名能显著提升迭代效率。 + +### 二、建立“违规数据库” + +除了模型样本库，还应建立违规样本库： + +1. 提前入场； +2. 无确认重入； +3. 止损外移； +4. 计划外加仓。 + +违规数据库是执行进步速度最快的抓手。 + +### 三、从“交易日志”升级到“决策日志” + +成熟阶段应记录“当时为什么不做某笔看起来很诱人的交易”。这种“放弃决策”记录对提升稳定性价值极高。 + +### 四、统一工作公式 + +> **Research Quality = Data Consistency × Sample Sufficiency × Process Discipline × Iterative Feedback Speed** + +该公式用于评估你的研究体系是否真正支持成长。 + +--- + +## 46.10　本章总结 + +1. Backtesting、Study Notes、Trading Journal 是同一闭环的三环，不可分离。 +2. 回测重点是识别边界与节奏，不是追求预测确定性。 +3. 日志价值在于暴露执行偏差，而不只是记录盈亏。 +4. 样本分层与统一字段，是从“复盘很多”到“复盘有效”的关键。 +5. 本章为第47章“形成个人执行框架”提供数据基础。 + +--- + +## 46.11　训练清单 + +### 一、观察任务 + +连续四周只跟踪 1–2 个核心模型，累计至少 40 个标准化样本。 + +### 二、标注任务 + +每笔样本强制记录四核心字段： + +1. 入场时段； +2. 入场等待耗时； +3. 最大不利波动； +4. 完整持仓耗时。 + +### 三、执行任务 + +每周输出三条“下周执行改动”，并在下周逐条复核。 + +### 四、复盘任务 + +分别统计： + +1. 模型失效样本； +2. 执行违规样本。 + +计算两者占比，避免错误归因。 + +### 五、达标标准 + +连续四周将“无标准字段记录的交易”比例降至 10% 以下，并将“重复性执行错误”下降 50%。 + +--- + +## 章末注释 + +[1] 本章围绕回测字段、样本分层、研究日志与过程导向训练，依据两份PDF相关内容整理。 +[2] 文中的样本门槛与比例用于研究流程管理，不构成收益承诺；应结合实际交易频率与市场波动校准。 +[3] 本章与第47章构成“数据沉淀—框架形成”连续模块。 + + + +# 第47章　从 Study Notes 与 Backtesting 到个人执行框架 + +## 47.1　本章核心问题 + +第46章解决了“如何记录与研究”，但很多交易者仍会卡在一个关键节点： + +**有了很多笔记和样本，为什么实盘依然不稳定。** + +原因通常是： + +1. 学习材料很多，但没有形成“单一执行语法”； +2. 回测样本很多，但没有沉淀成“固定决策顺序”； +3. 知识点很多，但没有形成“个人模型边界”。 + +本章只解决一个主问题： + +**如何把 Study Notes 与 Backtesting 结果，收束为一套“个人执行框架”。** + +围绕该主问题，本章回答四个子问题： + +1. 执行框架最小组成是什么； +2. 如何把不同周期和不同工具放进同一流程； +3. 如何给框架设置适用边界与失效边界； +4. 如何避免“每周换系统”的研究陷阱。 + +--- + +## 47.2　一句话结论 + +**个人执行框架不是“工具清单”，而是“固定顺序”：先大局叙事，再中局框架，再短局触发；先定义可做环境，再定义风险参数，再定义执行与退出规则，最后用样本持续校准。** + +--- + +## 47.3　基础定义 + +### 一、个人执行框架（Personal Execution Framework） + +本书语境下，个人执行框架由五块组成： + +1. 交易环境定义； +2. 参数定义（风险、目标、时段）； +3. 可执行触发标准； +4. 失效与退出规则； +5. 复盘与迭代规则。 + +这五块缺任何一块，系统就会在实盘中失真。 + +### 二、环境优先（Define Trade Environments） + +执行框架的第一步不是找信号，而是先定义“今天属于哪种环境、我该做哪类机会”。环境不明时，执行应降频或等待。 + +### 三、参数优先（Determine Trade Parameters） + +参数包括： + +1. 单笔风险； +2. 最低盈亏比； +3. 时段窗口； +4. 持仓风格（日内/短波段等）。 + +参数先写，执行才有一致性。 + +### 四、可执行标准（Executable Criteria） + +可执行标准是把“看起来不错”变成“可以下单”的闸门，例如： + +1. 叙事是否成立； +2. 结构是否支持； +3. 位置是否有优势； +4. 时间是否匹配。 + +### 五、三层视角在框架中的分工 + +个人框架应固定三层职责： + +1. **Long-Term：** 给 Narrative 与 Bias； +2. **Intermediate-Term：** 给路径框架与关键结构； +3. **Short-Term：** 给入场触发与风险优化。 + +这三层分工是避免“低周期推翻高周期”的关键。 + +### 六、风格匹配（Trader Type Fit） + +框架必须匹配交易者风格： + +1. Position； +2. Swing； +3. Short-Term； +4. Day Trader/Scalper。 + +若风格与框架不匹配，执行会长期内耗。 + +### 七、框架边界（Scope & Limits） + +每个个人框架都应明确： + +1. 做什么； +2. 不做什么； +3. 在什么条件下暂停。 + +边界越清楚，稳定性越高。 + +--- + +## 47.4　底层逻辑 + +### 一、框架的价值在“减少临场决策量” + +实盘失误往往发生在临场决策过多时。个人框架的作用，是把大量临场判断前置到盘前，让盘中只做“是否满足条件”的检查。 + +### 二、从“知识积累”到“决策顺序”才算升级 + +很多人长期停留在“知道很多概念”。真正升级发生在： + +1. 把概念按先后顺序排好； +2. 每次都按同一顺序执行； +3. 用样本检验顺序是否有效。 + +### 三、框架必须可证伪 + +若框架没有失效条件，它就不是框架，只是信念。可证伪框架至少要回答： + +1. 什么条件出现我就不做； +2. 什么条件出现我就承认错； +3. 什么条件出现我才恢复执行。 + +### 四、中期框架决定执行稳定度 + +很多执行漂移来自“短周期独立定义方向”。当中期框架被固定后，短周期只负责优化入场，系统噪音会显著下降。 + +### 五、框架不是一次性定稿，而是迭代产物 + +个人框架应通过样本持续迭代： + +1. 保留高贡献模块； +2. 删除低贡献模块； +3. 调整冲突模块。 + +但迭代必须有节奏，不能因短期盈亏频繁改模。 + +### 六、框架一致性高于策略复杂度 + +复杂系统不一定更优。多数账户稳定提升来自“少而稳”的执行语法： + +1. 明确环境； +2. 明确触发； +3. 明确风险； +4. 明确退出。 + +### 七、框架形成后，情绪波动会显著下降 + +当交易者知道“何时该做、何时不做、错了怎么退”，焦虑会下降，执行更容易保持一致。这是从学习者向执行者过渡的关键心理收益。 + +--- + +## 47.5　结构关系 + +### 一、承接第46章 + +第46章给出数据沉淀方法，本章把数据沉淀转成“可执行框架”。 + +### 二、通向第48章 + +第48章将进一步讨论“从术语学习者到 Precision Technician”的身份转变，本章是该转变的方法基础。 + +### 三、与全书模型章节的关系 + +本章并不新增工具，而是把前面所有工具（流动性、数组、结构、会话）统一到一个固定决策流程中。 + +--- + +## 47.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：同一顺序反复执行，波动下降 + +交易者按固定顺序执行数周后，通常会看到： + +1. 低质量交易显著减少； +2. 入场更集中在高信息窗口； +3. 账户回撤波动趋于收敛。 + +### 二、标准情境B：框架边界过滤掉“看起来像机会”的噪音 + +在无框架时期，许多局部波动都会被误判为机会；有框架后，这些机会会在“环境闸门”阶段被过滤。 + +### 三、标准情境C：中期框架稳定，短期触发更清晰 + +当中期方向与目标已定，短期图只负责找执行点，交易者不再频繁换边，持仓管理质量明显提高。 + +### 四、反例情境A：每周换系统 + +表现为： + +1. 样本无法累积； +2. 规则不断变化； +3. 盈亏难以归因。 + +### 五、反例情境B：框架写得完整，执行时完全跳过 + +表现为： + +1. 计划很漂亮； +2. 盘中按情绪做； +3. 复盘无法闭环。 + +--- + +## 47.7　执行意义 + +### 一、个人框架五步落地法 + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 今天是什么环境 | 先定 Narrative 与 Bias | +| 触发 | 哪类机会可做 | 只允许模型内 Setup | +| 确认 | 结构与时段是否支持 | 中期框架 + 短期触发双确认 | +| 执行 | 风险参数是否合规 | 固定风险、固定最小R:R | +| 退出 | 何时结束本次交易 | 目标达成或失效触发即退出 | + +### 二、个人框架最小文档（建议） + +每位交易者都应维护一页“框架总纲”，至少包含： + +1. 我的交易风格； +2. 我的可做环境； +3. 我的触发模型； +4. 我的风险规则； +5. 我的停止规则。 + +### 三、周度迭代规则 + +每周只允许三类改动： + +1. 删除一项低贡献规则； +2. 强化一项高贡献规则； +3. 修正一项高频违规点。 + +禁止“大改重写”式迭代。 + +### 四、执行一致性检查 + +每笔交易后只问三件事： + +1. 我是否按框架做； +2. 我是否在框架外做了不该做的事； +3. 若再来一次，我是否会做同样动作。 + +--- + +## 47.8　常见误区 + +### 误区一：把框架当成术语合集 + +**识别信号：** 名词很多，顺序没有。 +**纠偏动作：** 固定“先环境后触发”的执行顺序。 + +### 误区二：参数经常改，样本无法累积 + +**识别信号：** 每周都改时段、改风险、改模型。 +**纠偏动作：** 设定最短验证周期，未达样本量不改核心参数。 + +### 误区三：短周期持续覆盖中期框架 + +**识别信号：** 盘中频繁换边。 +**纠偏动作：** 中期定框架，短期只做入场优化。 + +### 误区四：不写框架边界 + +**识别信号：** 什么都想做。 +**纠偏动作：** 明确“不做清单”，比“做清单”更重要。 + +### 误区五：复盘只看盈亏，不看合规率 + +**识别信号：** 盈亏波动大，找不到原因。 +**纠偏动作：** 先统计“按框架执行率”，再评估盈亏。 + +### 误区六：追求完美框架，不愿先执行 + +**识别信号：** 长期写计划，几乎不做样本。 +**纠偏动作：** 先用最小可执行框架跑样本，再迭代优化。 + +--- + +## 47.9　高阶深化 + +### 一、从“模型”升级到“系统” + +模型解决“什么时候做”，系统解决“如何长期做”。个人框架是把多个模型连接成系统的接口层。 + +### 二、框架的真正护城河是“可复现” + +高阶交易者的优势不在于偶尔抓到大波动，而在于能在不同周、不同市场状态下，重复执行同一套决策语法。 + +### 三、建立“框架健康度”指标 + +建议固定追踪： + +1. 合规执行率； +2. 框架外交易占比； +3. 高频违规类型； +4. 违规后修正速度。 + +这些指标常比单周收益更能反映长期能力。 + +### 四、统一工作公式 + +> **Framework Maturity = Decision Order Stability × Rule Clarity × Boundary Discipline × Iteration Quality** + +该公式用于评估个人执行框架是否进入稳定阶段。 + +--- + +## 47.10　本章总结 + +1. 个人执行框架是“固定顺序”，不是“工具堆叠”。 +2. 先环境、后参数、再触发，是框架稳定的核心。 +3. 中期定框架、短期定触发，是执行抗噪的关键分工。 +4. 框架必须可证伪、可迭代、可复现。 +5. 本章把“研究成果”转化为“可长期执行的个人系统”。 + +--- + +## 47.11　训练清单 + +### 一、观察任务 + +用最近 30 笔交易，回填“是否按框架顺序执行”，统计合规率。 + +### 二、标注任务 + +建立一页“个人框架总纲”，写清： + +1. 可做环境； +2. 触发模型； +3. 风险规则； +4. 停止规则。 + +### 三、执行任务 + +下一轮交易只允许“框架内交易”，框架外交易一律标记为违规样本。 + +### 四、复盘任务 + +每周输出： + +1. 三条保留规则； +2. 三条删除规则； +3. 三条修正规则。 + +### 五、达标标准 + +连续四周将“框架外交易”比例降至 15% 以下，并保持合规执行率稳定上升。 + +--- + +## 章末注释 + +[1] 本章围绕过程导向、三层视角分工、风格匹配与可执行标准，依据两份PDF中相关方法论语义整理。 +[2] 文中的比例与阈值用于框架化训练，不构成收益承诺；应结合个人交易频率与样本规模调整。 +[3] 本章是第46章研究闭环与第48章专业化转变之间的桥接章节。 + + + +# 第48章　从术语学习者到 Precision Technician + +## 48.1　本章核心问题 + +走到全书最后，交易者通常已经掌握大量术语：流动性、失衡、结构、会话、模型、风控、复盘。但真正的分水岭并不在“会不会说术语”，而在： + +**这些术语是否已经被组织成可稳定执行的职业能力。** + +现实中最常见的断层是： + +1. 概念很多，决策顺序混乱； +2. 复盘很多，实盘执行率低； +3. 方向常对，收益兑现差； +4. 计划很完整，盘中被情绪接管。 + +本章只解决一个主问题： + +**如何完成从“术语学习者”到“Precision Technician”的转变。** + +围绕该主问题，本章回答四个子问题： + +1. Precision Technician 的核心能力到底是什么； +2. 专业执行者与反应式交易者的根本差别在哪里； +3. 如何把前47章知识收束成一套长期可持续流程； +4. 如何在现实压力下保持执行一致性并持续成长。 + +--- + +## 48.2　一句话结论 + +**Precision Technician 的本质不是知道更多术语，而是始终按同一流程工作：先叙事、后目标、再结构、再执行、最后复盘；用过程导向替代情绪导向，用可验证规则替代临场冲动。** + +--- + +## 48.3　基础定义 + +### 一、术语学习者（Term Learner） + +术语学习者的典型特征： + +1. 概念记忆多，流程稳定性弱； +2. 看到图形就想解释，难以统一优先级； +3. 交易行为容易被短周期噪音牵引。 + +### 二、Precision Technician（精密执行者） + +Precision Technician 的核心不是“预测更准”，而是“流程更稳”。其工作顺序固定： + +1. 先从高周期确定叙事； +2. 再定义 Draw 与 Bias； +3. 再由中期结构提供框架； +4. 最后用短周期优化入场与风险。 + +### 三、Interbank 结构视角 + +专业执行者的阅读优先级是： + +1. 先看流动性与失衡； +2. 再判断市场叙事； +3. 再确认结构是否支持执行。 + +这与零售常见的“先看图形、后补解释”完全不同。 + +### 四、Narrative -> Draw -> Bias 链路 + +这是全书最核心的执行链： + +1. 叙事决定市场当前要讲什么故事； +2. 目标决定价格更可能先处理哪里； +3. 偏向决定执行应偏向哪一侧。 + +若这条链不完整，后续所有技术触发都应降级。 + +### 五、中短周期职责边界 + +专业执行的硬规则是： + +1. Intermediate-Term 给框架； +2. Short-Term 仅用于入场。 + +短周期不应独立定义大方向，否则会持续落入假结构与噪音交易。 + +### 六、过程导向（Process Orientation） + +过程导向强调： + +1. 先定义环境与参数； +2. 再执行可验证标准； +3. 最后按日志迭代。 + +它与“冲动反应式交易”是两套完全不同的职业路径。 + +### 七、阶段性目标（Small Achievable Goals） + +专业成长应采用递进目标： + +1. 先达成小而稳定的阶段目标； +2. 再扩展到更高收益目标； +3. 始终保持风险可承受与流程可执行。 + +--- + +## 48.4　底层逻辑 + +### 一、职业化转变的核心是“同一流程重复执行” + +交易能力的成熟，不来自某一笔神单，而来自同一套流程在大量样本中的稳定复现。流程一旦经常被情绪打断，任何技术优势都会被抵消。 + +### 二、知识不等于能力，能力来自行为一致性 + +许多交易者停留在“知道”。Precision 阶段要求的是“做到”： + +1. 盘前能写清楚； +2. 盘中能执行； +3. 盘后能复盘。 + +三者一致，才算能力。 + +### 三、结构误判的根源常在顺序错误 + +如果不先建立叙事与目标，结构信号会被过度解读。专业执行者之所以更稳定，不是因为看得更神秘，而是因为顺序更严格。 + +### 四、现实压力下更需要流程护栏 + +现实生活压力最容易诱发三类行为： + +1. 过度杠杆； +2. 模型外交易； +3. 无目标冲动开仓。 + +流程护栏的作用就是在压力状态下仍保持最低纪律，避免账户进入失控区。 + +### 五、成长速度取决于反馈回路质量 + +成长不是时间函数，而是反馈函数。反馈回路越清晰（记录完整、复盘有效、改动可验证），能力提升越快。 + +### 六、专业执行者不追求“永不犯错” + +成熟执行并不否认亏损，而是把亏损限制在规则内，把错误转化为下一轮优化输入。真正危险的不是亏损，而是无规则亏损。 + +### 七、最终目标是“可持续”，不是“短期传奇” + +短期爆发可能来自运气，长期稳定必须来自流程。Precision Technician 的职业价值，体现在长期可持续性，而不是短期戏剧性收益。 + +--- + +## 48.5　结构关系 + +### 一、承接全书前三条主线 + +本章把全书三条主线收束为统一职业框架： + +1. 目标与空间主线（Range、Draw、位置）； +2. 流动性主线（清理、诱导、路径）； +3. 结构与执行主线（位移、接管、确认、会话）。 + +### 二、承接第46–47章 + +第46章给出研究闭环，第47章给出个人框架，本章给出“如何把框架变成长期职业习惯”的最后一步。 + +### 三、与账户管理的关系 + +本章不替代风险章节，而是把风险章节变成日常执行习惯： + +- 风险预算前置； +- 过程纪律优先； +- 回撤控制常态化。 + +--- + +## 48.6　图表中的真实表现 / 交易中的真实表现 + +### 一、标准情境A：同一顺序带来稳定执行 + +表现为： + +1. 盘前先定叙事和目标； +2. 盘中只等待模型内机会； +3. 盘后按统一模板复盘。 + +长期看，交易次数可能减少，但质量显著提升。 + +### 二、标准情境B：错过交易后仍能保持同步 + +专业执行者不会因 missed trade 情绪失衡，而会判断： + +1. 是否仍有会话内再同步机会； +2. 若没有，是否应接受空仓。 + +这种“接受错过”的能力，是职业化成熟的重要标志。 + +### 三、标准情境C：现实压力下仍守规则 + +当外部压力增加时，执行者依然坚持： + +1. 不超预算风险； +2. 不做模型外交易； +3. 不因短期波动改写核心框架。 + +这类稳定性直接决定账户寿命。 + +### 四、反例情境A：术语熟练但行为失序 + +表现为： + +1. 盘前说得清； +2. 盘中做不到； +3. 盘后归因混乱。 + +本质是“知识多于纪律”。 + +### 五、反例情境B：阶段目标缺失导致冲动 + +没有阶段性目标时，交易者更容易追求不现实收益，进而触发过度杠杆与冲动交易。 + +--- + +## 48.7　执行意义 + +### 一、Precision Technician 日常流程（五步） + +| 步骤 | 核心问题 | 执行动作 | +| --- | --- | --- | +| 条件 | 今天叙事与目标是什么 | 先写 Narrative、Draw、Bias | +| 触发 | 哪类机会属于模型内 | 仅保留框架内 Setup | +| 确认 | 结构与时段是否授权执行 | 中期框架 + 短期触发双确认 | +| 执行 | 风险与仓位是否合规 | 固定风险预算，按规则入场与管理 | +| 复盘 | 今天的偏差在哪里 | 记录违规并输出下轮修正动作 | + +### 二、职业化三条底线 + +1. **不因情绪改变风险规则。** +2. **不因短期结果改变核心流程。** +3. **不因外部压力放弃执行边界。** + +### 三、成长节奏建议 + +1. 先追求“连续合规执行”； +2. 再追求“稳定正期望”； +3. 最后才追求“规模扩张”。 + +顺序不能倒置。 + +### 四、执行检查清单（每日） + +1. 今日叙事是否清楚； +2. 今日目标是否清楚； +3. 今日风险上限是否写明； +4. 今日停止条件是否写明； +5. 复盘动作是否已安排。 + +--- + +## 48.8　常见误区 + +### 误区一：把专业化理解为“会更多术语” + +**识别信号：** 学习输入很多，执行输出不稳定。 +**纠偏动作：** 以流程一致性作为核心评价指标。 + +### 误区二：短期亏损后频繁改系统 + +**识别信号：** 连亏几笔就重写框架。 +**纠偏动作：** 用样本门槛约束改模节奏。 + +### 误区三：把短周期当方向引擎 + +**识别信号：** 频繁被噪音带节奏。 +**纠偏动作：** 坚持中期定框架、短期定入口。 + +### 误区四：现实压力下放弃纪律 + +**识别信号：** 过杠杆、冲动交易、目标漂移。 +**纠偏动作：** 使用阶段目标与风险上限约束行为。 + +### 误区五：复盘只看盈亏，不看行为 + +**识别信号：** 每周总结只有利润数字。 +**纠偏动作：** 把“合规率、违规类型、修正动作”列为必填项。 + +### 误区六：把空仓等同于失败 + +**识别信号：** 没机会也强做。 +**纠偏动作：** 把“高质量不交易”视为专业行为的一部分。 + +--- + +## 48.9　高阶深化 + +### 一、从交易者到执行工程师 + +高阶阶段的转变，是把交易当成“执行工程”： + +1. 有输入标准； +2. 有执行规范； +3. 有输出评估； +4. 有迭代机制。 + +这会显著降低偶然性对结果的影响。 + +### 二、建立“职业化指标面板” + +建议长期追踪四个指标： + +1. 框架内交易占比； +2. 风险违规次数； +3. 模型外交易占比； +4. 复盘修正完成率。 + +这些指标比单月收益更能反映专业程度。 + +### 三、把“错过”纳入系统，而不是纳入情绪 + +成熟执行者会把 missed trade 作为系统事件处理： + +1. 记录原因； +2. 判断是否仍可再同步； +3. 若不可再同步，接受空仓并结束该机会。 + +这是从情绪交易向专业执行过渡的关键行为。 + +### 四、统一工作公式 + +> **Precision Maturity = Process Consistency × Structural Discipline × Risk Integrity × Feedback Iteration** + +该公式用于评估你是否真正完成职业化转变。 + +--- + +## 48.10　本章总结 + +1. Precision Technician 的核心是流程稳定，不是术语堆叠。 +2. 先叙事后执行、先框架后触发，是专业化底层顺序。 +3. 现实压力下保持纪律，决定账户长期生存。 +4. 阶段目标与反馈闭环，是持续成长的真正引擎。 +5. 本章完成了全书从认知到职业化执行的最终闭环。 + +--- + +## 48.11　训练清单 + +### 一、观察任务 + +连续八周记录“框架内执行率、模型外交易率、风险违规次数”。 + +### 二、标注任务 + +每周输出三类日志： + +1. 本周最优执行样本； +2. 本周最大偏差样本； +3. 下周三条修正动作。 + +### 三、执行任务 + +下一阶段只以“合规率提升”为第一目标，不以“单周收益创新高”为第一目标。 + +### 四、复盘任务 + +每周复盘时分开统计： + +1. 模型本身失效； +2. 执行纪律失效。 + +避免把纪律问题误归因于模型。 + +### 五、达标标准 + +连续八周将“模型外交易”比例压至 10% 以下，并保持“框架内执行率”稳定提升。 + +--- + +## 章末注释 + +[1] 本章围绕流程导向、叙事链、三层分工、会话纪律与职业化成长路径，依据两份PDF相关方法语义整理。 +[2] 文中比例与阈值用于训练管理，不构成收益承诺；应结合交易频率、风险承受能力与阶段目标校准。 +[3] 本章作为全书终章，建议与第44–47章联读，形成“账户生存—风险动作—研究闭环—职业化执行”完整链路。 + + + + +# 术语索引 + +> 说明：以下索引按“术语—对应章节”编排，页码在终排阶段统一回填。 + +## A–C + +- `Accumulation`：见第38章。 +- `ADR Projections`：见第33章。 +- `Anticipation`：见第23章。 +- `Backtesting`：见第46章。 +- `Balanced Price Range (BPR)`：见第15章。 +- `Bellwether`：见第30章、第36章。 +- `Break of Structure / Market Structure Break (MSB)`：见第22章。 +- `Breaker Block`：见第17章。 +- `Buy-Side Liquidity (BSL)`：见第7章。 +- `CBDR`：见第33章。 +- `Clean High / Clean Low`：见第8章。 +- `Compounding`：见第44章。 +- `Consolidation`：见第18章。 +- `Consolidation Hurdles`：见第25章。 +- `Context / Framework`：见第3章。 +- `Correlation`：见第30章。 +- `COT`：见第29章。 + +## D–F + +- `Daily Bias`：见第25章。 +- `Daily Range Model`：见第35章。 +- `Dealing Range`：见第2章。 +- `Displacement`：见第21章。 +- `Distribution`：见第38章。 +- `Draw on Liquidity`：见第4章。 +- `Drawdown`：见第44章。 +- `Economic Calendar`：见第34章。 +- `Elements of a Trade Setup`：见第3章。 +- `Equilibrium`：见第2章、第5章。 +- `Expansion`：见第18章。 +- `External Range Liquidity (ERL)`：见第6章。 +- `Fair Valuation`：见第14章。 +- `Fair Value Gap (FVG)`：见第14章。 +- `Flout`：见第33章。 + +## I–L + +- `Imbalance`：见第14章。 +- `Institutional Order Flow`：见第43章。 +- `Interest Rates`：见第29章。 +- `Intermarket`：见第29章。 +- `Internal Range Liquidity (IRL)`：见第6章。 +- `Intra-day Order Flow`：见第36章。 +- `Intraday Profiles`：见第33章。 +- `IPDA (Interbank Price Delivery Algorithm)`：见第1章。 +- `Judas Swing`：见第11章。 +- `Kill Zones`：见第32章。 +- `Liquidity Pool`：见第8章。 +- `Liquidity Sweep`：见第10章。 +- `Liquidity Void`：见第9章。 +- `Long-Term / Intermediate-Term / Short-Term Perspective`：见第27章。 + +## M–O + +- `Macro`：见第29章。 +- `Manipulation`：见第11章。 +- `Market Conditioning`：见第11章。 +- `Market Efficiency Paradigm`：见第26章。 +- `Market Profile`：见第39章。 +- `Market Sentiment`：见第29章。 +- `Market Structure Shift (MSS)`：见第22章。 +- `Mitigation Block`：见第17章。 +- `Multiple Setups Within Trading Sessions`：见第42章。 +- `Narrative`：见第24章。 +- `News Embargo`：见第34章。 +- `One Shot One Kill (OSOK)`：见第36章。 +- `Open Interest`：见第29章。 +- `Opening Volatility`：见第34章。 +- `Order Block`：见第16章。 +- `OTE (Optimal Trade Entry)`：见第5章。 + +## P–R + +- `PD Array`：见第13章。 +- `Power of 3 (PO3)`：见第38章。 +- `Premium / Discount`：见第5章。 +- `Price Delivery`：见第1章。 +- `Precision Technician`：见第41章、第48章。 +- `Profit Objective`：见第37章。 +- `Raid`：见第10章。 +- `Reference Point`：见第3章。 +- `Relative Strength`：见第30章。 +- `Retracement`：见第18章。 +- `Rebalancing`：见第15章。 +- `Reversal`：见第18章。 +- `Reward-to-Risk`：见第44章。 + +## S–T + +- `Seasonality`：见第29章。 +- `Sell-Side Liquidity (SSL)`：见第7章。 +- `Session High / Session Low`：见第32章。 +- `SMT Divergence`：见第30章。 +- `Standard Deviations`：见第33章。 +- `Stop Hunt`：见第10章。 +- `Stop Run`：见第10章。 +- `Study Notes`：见第46章、第47章。 +- `Swing High / Swing Low`：见第19章。 +- `Swing Trading Model`：见第40章。 +- `Time Theory`：见第31章。 +- `Top-Down Analysis`：见第28章。 +- `Trading Journal`：见第46章。 +- `True Day`：见第31章。 diff --git a/docs/archive/README.md b/docs/archive/README.md deleted file mode 100644 index bba85f3..0000000 --- a/docs/archive/README.md +++ /dev/null @@ -1,15 +0,0 @@ -# Documentation Archive - -This directory keeps files that are no longer part of the active project reading path. - -Archive groups: - -- `history/`: dated snapshots, temporary reports, and one-off continuity notes. -- `obsolete_plans/`: planning documents that no longer match the current code and product stage. - -Archive rules: - -- Archived files are kept for traceability and historical reference. -- Pure duplicate documents are deleted instead of archived once their canonical replacements are recorded in `docs/AI_ICT_文档索引与命名规范_v2.md`. -- New project work should not cite archived files as canonical requirements. -- Active project reading should start from `docs/AI_ICT_文档索引与命名规范_v2.md`. diff --git a/docs/archive/history/AI_ICT_主线开发检查点_v1.md b/docs/archive/history/AI_ICT_主线开发检查点_v1.md deleted file mode 100644 index f8c6c34..0000000 --- a/docs/archive/history/AI_ICT_主线开发检查点_v1.md +++ /dev/null @@ -1,455 +0,0 @@ -# AI ICT 主线开发检查点 v1 - -## 1. 文档目标 - -本文档用于在本次会话结束时保存当前主线开发进度，确保下次登录后可以直接从主线继续推进，而不需要重新梳理上下文。 - ---- - -## 2. 当前主线状态 - -当前主线已经从“纯方案/文档阶段”推进到“真实工程骨架 + 数据链 + 结构识别链 + 候选信号链 + 回测链”的阶段。 - -可以把当前状态概括为： - -> 文档层已基本闭环，工程骨架已落地，数据库与模型层已落地，基础数据链、MVP 主模型识别链以及第一版回测链都已经开始成型并写入真实数据库。 - ---- - -## 3. 已完成的主线阶段 - -### 3.1 文档与方案层 - -以下文档已经落地到 `docs/`，并已本地检查： - -- 总体设计文档 -- PostgreSQL Schema 文档 -- MVP 规则规格书 -- 开发路线图 -- 执行检查清单 -- 项目启动清单 -- Migration 拆分计划 -- 第一批正式 Migration 文件草案 -- 第二批正式 Migration 文件草案 -- OKX 数据接入规格书 -- Session 生成器规格书 -- Swing 识别规格书 -- Dealing Range 规格书 -- Liquidity Pool 规格书 -- Sweep 识别规格书 -- Displacement 规格书 -- MSS 判定规格书 -- FVG 规格书 -- 文档索引与命名规范 -- 重复文档清理计划 -- 项目代码骨架规范 -- 自动化协作工作规程 -- 标准 CLAUDE.md 模板 -- 自动化协作迁移清单 -- 主线进度摘要 - -结论： -- 文档层已经足够支撑继续写代码 -- 当前后续不应再以扩写文档为主线 - ---- - -### 3.2 工程骨架层 - -已落地： - -#### 根目录 -- `.env.example` -- `pyproject.toml` -- `README.md` - -#### 目录骨架 -- `src/` -- `migrations/` -- `seeds/` -- `scripts/` -- `tests/unit` -- `tests/integration` -- `tests/fixtures` - -#### 配置与 DB 基础 -- `src/config/settings.py` -- `src/config/sessions.py` -- `src/db/engine.py` -- `src/db/base.py` -- `src/db/session.py` -- `src/main.py` - -结论： -- 工程骨架已可继续扩展 - ---- - -### 3.3 数据库与模型层 - -#### 第一批模型已落地 -- `venue.py` -- `instrument.py` -- `candle.py` -- `market_session.py` -- `swing.py` -- `dealing_range.py` -- `liquidity_pool.py` - -#### 第二批模型已落地 -- `displacement_event.py` -- `structure_event.py` -- `fvg_zone.py` -- `bias_snapshot.py` -- `trade_signal.py` -- `trade_execution.py` -- `backtest_run.py` -- `backtest_result.py` -- `sweep_event.py` - -#### 模型聚合导出 -- `src/models/__init__.py` - -#### 第一批 migration 已落地 -- `001_create_venues.sql` -- `002_create_instruments.sql` -- `003_create_candles.sql` -- `004_create_candles_partitions_and_indexes.sql` -- `005_create_market_sessions.sql` -- `006_create_swings.sql` -- `007_create_dealing_ranges.sql` -- `008_create_liquidity_pools.sql` -- `009_seed_venues.sql` -- `010_seed_instruments.sql` - -#### 第二批 migration 已落地 -- `011_create_displacement_events.sql` -- `012_create_structure_events.sql` -- `013_create_fvg_zones.sql` -- `014_create_bias_snapshots.sql` -- `015_create_trade_signals.sql` -- `016_create_trade_executions.sql` -- `017_create_backtest_runs.sql` -- `018_create_backtest_results.sql` -- `019_create_sweep_events.sql` - -#### 远程数据库状态 -- 远程 PostgreSQL 专用库：`ai_ict` -- 库已创建并成功执行 migrations -- 当前用户 `yuqei` 已有业务库使用权限 - -结论： -- 数据库结构设计和第一版 migration 文件已基本闭环 -- 真实远程库已经落地，不再只是本地文档状态 - ---- - -### 3.4 基础设施状态 - -#### 远程主机 `192.168.3.90` -- PostgreSQL: 已可用 -- MinIO: 已安装并 active -- Docker: 已确认可用，`docker --version` 正常，`systemctl is-active docker` = active -- Podman: 也可用，但不再是主路径阻塞 - -结论： -- 远程基础设施当前不再是主线阻塞点 - ---- - -## 4. 当前已经真实跑通到“代码链”的主线模块 - -### 4.1 OKX 数据入口 - -已落地： -- `src/services/market_data/okx_client.py` -- `src/services/market_data/normalizer.py` -- `src/services/market_data/__init__.py` -- `scripts/run_okx_backfill.py` - -能力： -- 从 OKX 拉取原始 candles -- 标准化为内部 candle 对象 -- 支持当前代理环境下可用的请求路径 - ---- - -### 4.2 Candles 写入链 - -已落地： -- `src/repositories/candle_repository.py` -- `src/repositories/__init__.py` - -能力： -- 把 normalized candles upsert 进 `candles` -- 具备幂等写入路径 - ---- - -### 4.3 Session 生成链 - -已落地： -- `src/repositories/market_session_repository.py` -- `src/services/sessions/session_generator.py` -- `src/services/sessions/__init__.py` -- `scripts/run_session_generator.py` - -能力： -- 从 `candles` 读取指定时间窗口 -- 生成 session 窗口 -- 聚合 `high / low / midpoint` -- upsert 写入 `market_sessions` - ---- - -### 4.4 Swing 识别链 - -已落地： -- `src/repositories/swing_repository.py` -- `src/services/swings/swing_service.py` -- `src/services/swings/__init__.py` -- `scripts/run_swings.py` - -能力： -- 从 `candles` 读取 -- 检测 ST swings -- 写入 `swings` - -当前限制： -- 只做了 ST 第一版 -- 尚未做 IT / LT - ---- - -### 4.5 Dealing Range 链 - -已落地： -- `src/repositories/dealing_range_repository.py` -- `src/services/ranges/dealing_range_service.py` -- `src/services/ranges/__init__.py` -- `scripts/run_ranges.py` - -能力： -- 从 `swings` 读取 -- 生成 active range -- 计算 equilibrium -- 写入 `dealing_ranges` - ---- - -### 4.6 Liquidity Pool 链 - -已落地： -- `src/repositories/liquidity_pool_repository.py` -- `src/services/liquidity/liquidity_pool_service.py` -- `src/services/liquidity/__init__.py` -- `scripts/run_liquidity.py` - -能力： -- 从 `swings` 读取 prior high / low -- 从 `market_sessions` 读取 session high / low -- 写入 `liquidity_pools` - -当前限制： -- `equal highs / lows` 增强仍未真正落地成功 -- 当前该点仍是待继续推进的结构质量改进项 - ---- - -### 4.7 Sweep 链 - -已落地： -- `src/repositories/sweep_repository.py` -- `src/services/sweeps/sweep_service.py` -- `src/services/sweeps/__init__.py` -- `scripts/run_sweeps.py` - -能力： -- 从 `liquidity_pools` + `candles` 读取 -- 检测 sweep -- 写入 `sweep_events` -- 更新 liquidity pool 状态 - ---- - -### 4.8 Displacement 链 - -已落地： -- `src/repositories/displacement_repository.py` -- `src/services/displacement/displacement_service.py` -- `src/services/displacement/__init__.py` -- `scripts/run_displacement.py` - -能力： -- 从 `candles` 读取 -- 计算 body_ratio -- 检测方向性 displacement -- 写入 `displacement_events` - ---- - -### 4.9 MSS 链 - -已落地： -- `src/repositories/structure_repository.py` -- `src/services/structure/mss_service.py` -- `src/services/structure/__init__.py` -- `scripts/run_mss.py` - -能力： -- 从 `swings` + `displacement_events` 读取 -- 生成 MSS 候选 -- 写入 `structure_events` - ---- - -### 4.10 FVG 链 - -已落地： -- `src/repositories/fvg_repository.py` -- `src/services/fvg/fvg_service.py` -- `src/services/fvg/__init__.py` -- `scripts/run_fvg.py` - -能力： -- 从 `candles` 识别 bullish / bearish FVG -- 关联 displacement -- 写入 `fvg_zones` -- 已新增：`fill_pct / status` 动态更新能力 -- 已验证：数据库中已有 `open / touched / mitigated` 状态分布 - ---- - -### 4.11 Bias + Signal 组合层 - -已落地： -- `src/repositories/bias_repository.py` -- `src/repositories/signal_repository.py` -- `src/services/bias/bias_service.py` -- `src/services/bias/__init__.py` -- `src/services/signals/signal_service.py` -- `src/services/signals/__init__.py` -- `scripts/run_signals.py` - -能力： -- 从 `dealing_ranges` + `structure_events` 读取生成 bias snapshot -- 从 `bias + FVG + MSS` 组合生成 signal 候选 -- 写入 `bias_snapshots` 与 `trade_signals` - -当前限制： -- session filter 已进入 backtest，但 signal 本身仍可继续增强 - ---- - -### 4.12 Backtest 链 - -已落地： -- `src/repositories/backtest_repository.py` -- `src/services/backtest/backtest_service.py` -- `src/services/backtest/__init__.py` -- `scripts/run_backtest.py` - -能力： -- 从 `trade_signals` 读取候选信号 -- 从后续 `candles` 读取未来样本 -- 先判断 entry 是否触发 -- 再判断 stop / TP 结果 -- 已引入：同根 K 线 `stop_first` 规则 -- 已引入：session 覆盖检查 -- 写入 `backtest_runs` 与 `backtest_results` - -结论： -- 回测已从“静态 RR 打标签”升级到“基于真实后续 candles 的更真实结果评估” - ---- - -## 5. 当前数据库中的真实结果概况 - -当前核心结果量级： - -- candles: 400 -- market_sessions: 5 -- swings: 78 -- dealing_ranges: 2 -- liquidity_pools: 47 -- sweep_events: 53 -- displacement_events: 113 -- structure_events: 3 -- fvg_zones: 149 -- bias_snapshots: 3 -- trade_signals: 3 -- backtest_runs: 10 -- backtest_results: 25 - -说明： -- 真实样本、结构、信号、回测结果都已开始累积 - ---- - -## 6. 当前主线已经形成的真实链路 - -到本次检查点为止，已经形成如下主线： - -`OKX -> candles -> market_sessions -> swings -> dealing_ranges -> liquidity_pools -> sweep_events -> displacement_events -> MSS -> FVG -> bias_snapshots -> trade_signals -> backtest_runs -> backtest_results` - -这意味着： -- 基础数据层已启动 -- 基础结构层已启动 -- 事件识别链已启动 -- 候选信号层已启动 -- 回测层已启动 - -项目已经不再停留在“方案和文档”阶段。 - ---- - -## 7. 当前仍未完成但建议继续走主线的模块 - -### 第一优先级：继续提升回测真实性 -建议继续增强： -1. 更精细的 entry 触发判定 -2. stop / TP 命中顺序更严格的时间语义 -3. 更细化 invalidation 逻辑 -4. session filter 与 signal 层进一步联动 - -### 第二优先级：继续提升结构质量 -建议继续增强： -1. equal highs / lows -2. 更精细 liquidity merge / 去重 -3. MSS acceptance -4. FVG mitigation 更完整联动到 signal - -### 第三优先级：扩大样本 -建议继续： -1. 进一步扩大 OKX 历史样本 -2. 继续多 timeframe 累积 -3. 提高 signal / backtest 的统计意义 - ---- - -## 8. 下次继续时建议的第一句话 - -下次进入项目时，可以直接这样说： - -```text -继续按主线开发，从 docs/AI_ICT_主线开发检查点_v1.md 继续，不要重做已完成模块。优先继续提升回测真实性，并补齐 equal highs / lows 这一结构质量增强点。 -``` - ---- - -## 9. 当前结论 - -本次主线已经从： -- 文档阶段 -- 工程骨架阶段 -- 数据库准备阶段 - -推进到： -- 基础数据链已落地 -- 基础结构识别链已落地 -- 候选信号链已落地 -- 回测链已落地并持续增强 - -下次会话最合理的继续方向不是重搭骨架，也不是再扩文档，而是： - -> 继续增强回测真实性 + 继续补结构质量中的 equal highs / lows 等待落地点。 diff --git a/docs/archive/history/AI_ICT_当前工作断点_2026-04-24.md b/docs/archive/history/AI_ICT_当前工作断点_2026-04-24.md deleted file mode 100644 index d4b23f6..0000000 --- a/docs/archive/history/AI_ICT_当前工作断点_2026-04-24.md +++ /dev/null @@ -1,71 +0,0 @@ -# AI ICT 当前工作断点（2026-04-24） - -## 已完成 -- 代码侧 idempotency 主线补丁已落地并通过本地回归。 -- API 服务端异常兜底已补齐：`src/api/server.py` - - 业务查询异常不再直接断连接 - - 会返回 JSON 500（`internal_server_error`）便于排查 - - 已新增 `/executions` 聚合接口，供 dashboard 展示 execution timeline / blotter -- `/signals` 路由回归测试已补：`tests/unit/test_api_and_main.py` -- 执行层已进一步对齐需求：`src/services/execution/execution_service.py` - - `semi_auto` 必须显式确认后才会真正创建执行记录 - - 风控拒绝原因继续保留在 `meta.risk_checks` - - 已新增 `execution_audit`、lifecycle 分类、settlement 持久化回写 - - 已新增 `settle_execution_by_id()`，可按 execution_id 回查并回写 settlement - - 已新增 `settle_execution_by_id_from_latest_backtest()`，可自动抓取最新 backtest result 后完成 settlement - - 已新增 `settle_latest_execution_for_signal()`，可按 signal 自动找到最新 execution 并完成 settlement -- 主运行链路已接入 execution settlement：`src/main.py` - - 已从 `signal -> latest execution -> latest backtest -> settlement` 打通到主闭环 - - 闭环摘要新增 `writes.execution_status` - - 闭环摘要新增 `writes.execution_lifecycle_state` -- 报告层已接入 execution audit：`src/services/reports/post_trade_review_service.py` -- 最小前端 dashboard 已落地：`src/web/` - - 当前可视化 overview / health / candles / signals / sessions / executions / backtests - - 已新增 auto refresh、last updated、状态彩色标签 - - 已新增 overview 指标卡 - - 已新增 details 面板，可点击行/卡片查看结构化明细 - - 已新增 execution status filter、文本搜索、选中高亮 -- 运行脚本已补数据库不可用时的优雅降级： - - `scripts/run_execution.py` - - `scripts/run_pipeline.py` - - `scripts/run_execution_settlement.py` -- `scripts/run_execution.py` 已升级为：创建 execution 后自动执行该 signal 的 latest execution settlement -- `scripts/run_execution_settlement.py` 已升级为：按 `signal_id` 自动找到 latest execution 后执行 settlement -- 报告样本、错误样本、脚本 fallback 样本已落盘：`docs/AI_ICT_报告样本_2026-04-24.md` -- 本地验证已通过： - - `test_api_and_main.py` -> 7 tests OK - - `test_api_server.py` -> 8 tests OK - - `test_execution_service.py` -> 22 tests OK - - `test_report_services.py` -> 3 tests OK -- 远端 PostgreSQL 已修复 `pg_hba.conf` 网段放行问题： - - 新增 `172.22.0.0/16` - - 新增 `172.23.0.0/16` -- 远端服务已重部署并完成 smoke： - - `GET /health` -> `200 OK` - - `GET /signals?instrument_id=1&limit=3` -> `200 OK` - - `GET /backtests?instrument_id=1&limit=3` -> `200 OK` - - `GET /sessions?instrument_id=1&limit=3` -> `200 OK` - - `GET /candles?instrument_id=1&timeframe=1m&limit=3` -> `200 OK` -- 部署脚本已修正：`scripts/deploy_server.exp` - - 不再依赖外部遗留的 `/tmp/ai-ict-deploy.tgz` - - 脚本会从项目根目录自动打包再上传部署 - -## 本次根因 -- HTTP 层此前只捕获 `ValueError`，业务异常会导致连接直接断开，表现为 `curl: (52) Empty reply from server` -- 远端数据库同时拒绝了 Docker bridge 网段 `172.23.0.0/16` 的容器连接，导致 `/signals` 查询实际触发 `psycopg.OperationalError` - -## 当前未闭环点 -- 部署链路已用新版脚本完成一次完整验证：打包、上传、解包、重启、smoke 均已通过。 -- 需求对齐后续主线待推进： - - 执行层：继续把 settlement 从当前回测/规则结算链推进到真实成交/持仓回写链 - - 运行链路：下一步可考虑把 settlement 再推进到真实成交/持仓更新与 execution audit 联动 - - 检查清单：继续把已完成项从文档状态同步到真实验证状态 - -## 建议下次直接续跑步骤 -1. 继续补执行层最小闭环，优先做 execution audit 与持仓生命周期管理。 -2. 为 pre-market / intraday / post-trade 报告补样本落盘与错误样本。 -3. 完成后再更新检查清单与主线检查点文档。 - -## 本次保留说明 -- 按你的要求：**不写入持久记忆系统**。 -- 本断点仅保存于项目文档，避免增加 memory 负担。 diff --git a/docs/archive/history/AI_ICT_报告样本_2026-04-24.md b/docs/archive/history/AI_ICT_报告样本_2026-04-24.md deleted file mode 100644 index 0f88e83..0000000 --- a/docs/archive/history/AI_ICT_报告样本_2026-04-24.md +++ /dev/null @@ -1,151 +0,0 @@ -# AI ICT 报告样本（2026-04-24） - -## 1. pre-market sample - -```json -{ - "report_type": "pre_market_plan", - "daily_bias": "bullish", - "draw_side": "buy_side", - "execution_intensity": "high", - "reason_codes": ["latest_mss", "active_range_available"], - "session_code": "LONDON", - "execution_permission": true, - "working_range": { - "range_id": 1, - "high": 110.0, - "low": 90.0, - "equilibrium": 100.0, - "location": "discount" - } -} -``` - -## 2. intraday sample - -```json -{ - "report_type": "intraday_explanation", - "sweep": { - "present": true, - "side_swept": "buy_side", - "close_back_inside": true - }, - "structure": { - "event_type": "MSS", - "direction": "bullish", - "accepted": true - }, - "fvg": { - "direction": "bullish", - "status": "open", - "fill_pct": 0.0 - }, - "signal": { - "present": true, - "status": "awaiting_confirmation", - "side": "buy", - "session_code": "LONDON", - "is_valid": true - }, - "invalidations": [] -} -``` - -## 3. post-trade review sample - -```json -{ - "report_type": "post_trade_review", - "rule_aligned": false, - "execution_status": "rejected", - "signal_status": "awaiting_context", - "backtest_outcome": "loss", - "execution_audit": { - "audit_status": "review", - "is_actionable": false, - "error_tags": ["execution_rejected", "session_not_allowed"], - "lifecycle_state": "rejected", - "risk_checks": ["session_not_allowed"], - "tp_hits": {"tp1": false, "tp2": false}, - "stop_loss_hit": true - }, - "error_types": ["execution_rejected", "session_not_allowed"], - "improvement_notes": ["inspect_stop_and_structure_context", "prefer_confirmed_execution_window", "review_same_candle_ambiguity_cases", "review_signal_invalidations"] -} -``` - -## 4. error sample - -```json -{ - "report_type": "post_trade_review", - "rule_aligned": false, - "execution_status": "closed", - "signal_status": "awaiting_confirmation", - "backtest_outcome": "loss", - "execution_audit": { - "audit_status": "review", - "is_actionable": false, - "error_tags": ["signal_invalidated_before_entry"], - "lifecycle_state": "expired", - "risk_checks": [], - "tp_hits": {"tp1": false, "tp2": false}, - "stop_loss_hit": false - }, - "error_types": ["signal_invalidated_before_entry"], - "improvement_notes": ["avoid_expired_or_invalidated_signals", "review_signal_invalidations"] -} -``` - -## 5. current note - -- 以上样本已对应当前代码输出结构。 -- post-trade review 已包含 `execution_audit`，可用于 execution audit 样本留档。 -- 当前 lifecycle 已接入主运行链路摘要，并可持久化回写 execution 状态。 -- 当前已支持按 execution_id 回查 execution 后执行 settlement 回写。 -- 当前主闭环也已直接接入 `signal_id -> latest execution -> latest backtest -> settlement` 路径。 -- `scripts/run_execution.py` 与 `scripts/run_pipeline.py` 在数据库不可用时都已改为优雅输出错误，而不是抛长异常。 -- 当前 dashboard 已增强为带 overview 指标卡、auto refresh、last updated、状态彩色标签的最小可视化页面。 -- 当前仍未完成真实撮合/成交回执驱动的持仓管理，因此样本中的 lifecycle 仍主要来自回测/规则结算链。 - -## 6. script fallback sample - -```text -Database unavailable for execution sample: OperationalError -Database unavailable for pipeline sample: OperationalError -Database unavailable for execution settlement sample: OperationalError -``` - -当前 `run_execution.py` 已升级为：创建 execution 后自动结算该 signal 的 latest execution。 -当前 `run_execution_settlement.py` 已升级为：按 `signal_id` 自动找到 latest execution 并完成 settlement。 - -该样本用于记录当前运行脚本的无库环境行为。 - -## 7. execution settlement sample - -脚本入口：`scripts/run_execution_settlement.py` - -用途： -- 按 `signal_id` 自动找到 latest execution -- 自动抓取该 signal 最新 backtest result -- 根据最新 backtest 结果执行 settlement -- 回写 lifecycle / status / meta - -当前无数据库环境下的样本输出： - -```text -Database unavailable for execution settlement sample: OperationalError -``` - -有数据库且 execution 存在时，预期输出结构： - -```text -Execution settlement updated: id=; status=closed; lifecycle_state=tp2_closed -``` - -该入口用于后续继续收口“真实 execution 回写链”。 - -另外，当前运行脚本的优雅降级行为已由 `tests/unit/test_api_server.py` 覆盖。 - -该样本用于记录当前运行脚本的无库环境行为。 diff --git a/docs/archive/history/AI_ICT_离线自动化推进记录_2026-04-29.md b/docs/archive/history/AI_ICT_离线自动化推进记录_2026-04-29.md deleted file mode 100644 index 0f6e0a0..0000000 --- a/docs/archive/history/AI_ICT_离线自动化推进记录_2026-04-29.md +++ /dev/null @@ -1,431 +0,0 @@ -# AI ICT 离线自动化推进记录（2026-04-29） - -## 背景 - -服务器 PostgreSQL 暂时不可用，本轮只推进不依赖数据库的代码、纯函数、单元测试与文档记录。 - -目标不是扩展概念，而是提高系统后续验证交易有效性的可信度。 - -## 已完成离线能力 - -### 1. Signal RR 硬过滤 - -- 新增 `MIN_TP1_RR = 1.0` -- 新增 `MIN_TP2_RR = 2.0` -- `SignalService.build_signal()` 现在会拒绝 RR 不达标的候选信号 -- 信号 meta 写入 `rr_filter` - -### 2. 回测 R 倍数与成本模型 - -- 新增 `BacktestCostConfig` -- 支持 `fee_rate` -- 支持 `slippage_rate` -- 支持 `fixed_cost_r` -- 每笔结果写入： - - `cost_r` - - `r_multiple` - - `cost_model` -- 汇总新增： - - `total_r` - - `expectancy_r` - - `profit_factor_r` - - `total_cost_r` - - `avg_cost_r` - -### 3. 回测风险统计 - -- 新增 R 曲线： - - `cumulative_r_curve` -- 新增最大回撤： - - `max_drawdown_r` -- 新增最大连续亏损： - - `max_consecutive_losses` -- 新增 MFE / MAE 的 R 倍数： - - `avg_mfe_r` - - `avg_mae_r` - -### 4. 回测质量门槛 - -- 新增 `BacktestQualityGate` -- 新增 `evaluate_backtest_quality()` -- 默认检查： - - 最小样本量 - - 最小实际触发交易样本量 - - 最低期望 R - - 最低 profit factor - - 最大回撤 - - 最大连续亏损 -- `BacktestReportService.build_summary()` 现在输出 `quality_gate` -- `BacktestService.run_backtest()` 写入 backtest run summary 时同步固化 `quality_gate` -- backtest run config 同步记录当次使用的 `quality_gate` 阈值，便于追溯自动化门禁标准 -- `run_backtest.py` 与 `run_pipeline.py` 支持通过环境变量注入成本模型： - - `BACKTEST_FEE_RATE` - - `BACKTEST_SLIPPAGE_RATE` - - `BACKTEST_FIXED_COST_R` -- `run_backtest.py` 与 `run_pipeline.py` 支持无人流程质量门禁： - - `BACKTEST_REQUIRE_QUALITY_GATE=1` - - 门禁失败时返回 exit code `2` -- `run_backtest.py` 支持 `BACKTEST_OUTPUT_JSON=1`： - - 输出脚本级 `passed` - - 输出 `backtest_run_id` - - 输出 `result_count` - - 输出 `summary` - - 输出 `quality_gate` - - 数据库不可用时输出结构化 `error_type` -- 质量门禁阈值可通过环境变量调整： - - `BACKTEST_MIN_TOTAL_SIGNALS` - - `BACKTEST_MIN_EXECUTED_SIGNALS` - - `BACKTEST_MIN_EXPECTANCY_R` - - `BACKTEST_MIN_PROFIT_FACTOR_R` - - `BACKTEST_MAX_DRAWDOWN_R` - - `BACKTEST_MAX_CONSECUTIVE_LOSSES` -- 回测 summary 新增： - - `executed_signals` - - `executed_rate` - - `executed_expectancy_r` - - `executed_profit_factor_r` -- `run_closed_loop()` 返回 `backtest_quality_gate`，便于自动编排系统直接判断是否继续推进 - -### 5. 历史 replay 骨架 - -- 新增纯内存历史回放模块：`src/services/backtest/replay.py` -- `iter_historical_replay()` 逐根 candle 推进 -- 每个 frame 只暴露当时已知 candles -- `detect_confirmed_swings_for_replay()` 只在右侧确认窗口完成后释放 confirmed swing -- 这是后续无未来函数回测的基础 - -### 6. Replay 输入数据校验 - -- 新增 `validate_replay_candles()` -- 回放前检查： - - 必要字段缺失 - - `ts_open` 重复 - - `ts_open` 非递增 - - `high < low` - - `open` 不在 high/low 内 - - `close` 不在 high/low 内 - - OHLC 非数字、非有限值与非正价格 -- 新增 `load_replay_candles()`，支持： - - JSON - - JSONL / NDJSON - - CSV -- 新增纯离线 replay 文件脚本： - - `python3 scripts/run_replay_file.py ` - - `REPLAY_LEFT_BARS` - - `REPLAY_RIGHT_BARS` - - `REPLAY_MIN_CANDLES` - - `REPLAY_MIN_SWINGS` - - `REPLAY_OUTPUT_JSON` -- Replay 样本门禁失败时返回 exit code `2` -- Replay JSON 输出包含： - - candle/frame/swing 统计 - - 样本窗口：起止 `ts_open`、首尾 close、最高/最低价、区间 close return - - `max_gap_minutes`，用于发现历史 K 线断档 - - 最新 confirmed swing - - quality gate 状态与原因 -- Replay 文件门禁新增： - - `REPLAY_MAX_GAP_MINUTES` - - 超过门槛时返回 `candle_gap_too_large` -- 新增仓库内 replay 样本： - - `tests/fixtures/offline_replay_sample.jsonl` - -### 7. 账户级风控纯函数 - -- 新增 `AccountRiskState` -- 新增 `evaluate_account_risk_limits()` -- 执行决策已支持账户状态输入 -- `run_execution.py` 与 `run_pipeline.py` 支持通过环境变量注入账户状态 -- 当前可拒绝： - - 全局执行熔断开启 - - 日亏损达到上限 - - 连续亏损达到上限 - - 最大持仓数达到上限 - - 同方向暴露达到上限 -- 当前执行风控环境变量： - - `EXECUTION_KILL_SWITCH` - - `EXECUTION_DAILY_PNL_PCT` - - `EXECUTION_CONSECUTIVE_LOSSES` - - `EXECUTION_OPEN_POSITIONS` - - `EXECUTION_SAME_SIDE_OPEN_POSITIONS` - - `EXECUTION_MAX_DAILY_LOSS_PCT` - - `EXECUTION_MAX_CONSECUTIVE_LOSSES` - - `EXECUTION_MAX_OPEN_POSITIONS` - - `EXECUTION_MAX_SAME_SIDE_POSITIONS` - -### 8. Signal evidence 校验 - -- 新增 `validate_signal_evidence()` -- 当前最小证据链： - - `bias_snapshot_id` - - `fvg_id` - - `mss_id` -- 预留严格证据链： - - `bias_snapshot_id` - - `sweep_id` - - `displacement_id` - - `mss_id` - - `fvg_id` - - `liquidity_target_id` -- `SignalService.build_signal()` meta 写入 `evidence_quality` -- `SignalService` 支持注入 required evidence keys，不完整时直接拒绝候选信号 -- `run_signals.py` 与 `run_pipeline.py` 支持： - - `SIGNAL_EVIDENCE_MODE=minimal` - - `SIGNAL_EVIDENCE_MODE=strict` - -### 9. Dashboard 回测质量展示与静态资源检查 - -- Dashboard 回测卡片展示： - - `expectancy_r` - - `executed_expectancy_r` - - `max_drawdown_r` - - `executed_signals / executed_rate` - - `quality_gate` -- Overview 展示最新回测的 quality gate 状态与实际触发交易样本量 -- 清理 `src/web/app.js` 中重复定义导致的脚本语法错误 -- 静态资源测试新增： - - `index.html` 引用资源存在性检查 - - `node --check src/web/app.js` 语法检查 -- 新增离线总闸脚本： - - `python3 scripts/run_offline_checks.py` - - 当前串联单元测试、migration 静态检查与 dashboard JS 语法检查 - - 设置 `OFFLINE_REPLAY_FILE` 时自动追加 replay 文件检查 - - 设置 `OFFLINE_CHECKS_OUTPUT_JSON` 时输出机器可读 JSON summary -- 新增 migration 静态检查脚本： - - `python3 scripts/run_migration_static_checks.py` - - 检查 migration 编号连续 - - 检查核心表与关键列是否由 migration 创建 - - 检查 readiness 依赖的 seed 值： - - `venues.code=OKX` - - `instruments.symbol=BTC-USDT` -- 新增 script 静态检查脚本： - - `python3 scripts/run_script_static_checks.py` - - 检查无人脚本中会让空 env 误回退到真实环境变量的写法 - - AST 解析 automation 脚本，提前拦截 Python 语法错误 - - 检查关键自动化入口必须 `raise SystemExit(main())`，避免返回码被吞 - - 检查脚本中 Python 3.9 不兼容的 PEP604 Optional 注解 - - 已接入 `run_offline_checks.py` -- `run_migrations.py` 改为按 SQL statement 分拆执行 migration 文件，避免多语句整文件 execute 的驱动兼容风险 -- `run_migrations.py` 数据库异常时返回 exit code `2`，并纳入脚本入口返回码静态检查 -- `run_migrations.py` 支持 `MIGRATIONS_OUTPUT_JSON=1` 输出机器可读迁移摘要 -- 新增无人流程循环入口： - - `python3 scripts/run_autonomous_cycle.py` - - 顺序执行离线总闸、数据库探测、数据库可用后的 guarded pipeline - - 数据库不可用时进入 `waiting_for_database` - - human 输出与 JSON 输出都包含 `next_actions`，便于下一轮无人流程直接接续 - - 输出 `action_plan`，包含建议命令、动作说明与 `requires_database` 标记 - - `AUTONOMOUS_OUTPUT_JSON` - - `AUTONOMOUS_REQUIRE_DB` - - `AUTONOMOUS_RUN_PIPELINE` - - `AUTONOMOUS_MAX_DB_PROBES` - - `AUTONOMOUS_PROBE_INTERVAL_SECONDS` - - `AUTONOMOUS_REQUIRE_SCHEMA` - - `AUTONOMOUS_APPLY_MIGRATIONS` - - DB 可用但 schema 不完整时，默认执行 `run_migrations.py`，复查 schema，通过后继续 readiness/pipeline；migration 失败时进入 `migration_failed` - - 数据库可连通后先检查核心表与关键列；缺表或缺列时进入 `database_schema_not_ready` 并返回 exit code `2` - - `AUTONOMOUS_REQUIRE_DATA_READINESS` - - `AUTONOMOUS_BACKFILL_CANDLES` - - readiness 仅因 candles 数量不足失败时，默认执行 `run_okx_backfill.py`，复查 readiness，通过后继续 guarded pipeline；backfill 失败时进入 `backfill_failed` - - 调用 `run_pipeline.py` 时默认设置 `BACKTEST_REQUIRE_QUALITY_GATE=1` 与 `PIPELINE_OUTPUT_JSON=1`，确保无人流程不会把质量门槛失败误判为成功，并能解析 pipeline 失败原因 -- `run_okx_backfill.py` 拆出可测试核心函数，自动化异常返回 exit code `2` -- 修复 OKX backfill 同批次重复 `ts_open` confirmed candle 去重问题 -- OKX backfill 支持使用上一页最旧 `ts` 作为 `after` 游标继续拉更早历史，减少重复拉取最新页 -- OKX backfill 支持无人流程环境变量： - - `OKX_BACKFILL_SYMBOL` - - `OKX_BACKFILL_INST_ID` - - `OKX_BACKFILL_PAGES` - - `OKX_BACKFILL_LIMIT` - - `OKX_BACKFILL_TIMEFRAMES` - - `OKX_BACKFILL_OUTPUT_JSON` -- autonomous cycle 自动 backfill 时强制 `OKX_BACKFILL_OUTPUT_JSON=1` -- `run_pipeline.py`、`run_execution.py`、`run_execution_settlement.py` 在数据库异常时返回 exit code `2`，避免无人流程把数据库中途掉线误判为成功 -- `run_pipeline.py` 支持 `PIPELINE_OUTPUT_JSON=1`，数据库中途异常时输出结构化 `passed:false` 与 `error_type` -- `run_execution.py` 支持 `EXECUTION_OUTPUT_JSON=1`，输出 `execution_mode:paper`、`passed` 与数据库错误类型 -- `run_execution_settlement.py` 支持 `EXECUTION_SETTLEMENT_OUTPUT_JSON=1`，输出 `execution_mode:paper`、`passed` 与数据库错误类型 -- `run_reports.py` 支持 `REPORTS_OUTPUT_JSON=1`，输出 pre-market、intraday、post-trade 与 backtest summary 的机器可读报告样本 -- `run_signals.py` 支持 `SIGNALS_OUTPUT_JSON=1`，数据库异常时返回 exit code `2` 并输出结构化错误；入口改为 `raise SystemExit(main())` -- 以下结构处理入口已支持 JSON 输出、数据库异常 exit code `2`，并纳入入口返回码静态检查： - - `run_session_generator.py` - - `run_swings.py` - - `run_ranges.py` - - `run_liquidity.py` - - `run_sweeps.py` - - `run_displacement.py` - - `run_mss.py` - - `run_fvg.py` -- `check_db.py` 与 `check_db_connection.py` 支持 JSON 输出与数据库异常 exit code `2` -- `apply_migrations.py` 已委托给 `run_migrations.py` 的安全迁移入口，避免旧脚本绕过 SQL 拆分和结构化错误输出 -- `show_models.py` 支持 `SHOW_MODELS_OUTPUT_JSON=1`，并纳入入口返回码静态检查 -- README 已补齐 `MIGRATION_CHECKS_OUTPUT_JSON` 与 `SCRIPT_CHECKS_OUTPUT_JSON`，确保公开环境变量清单覆盖当前脚本能力 -- `run_dev.py` 与 `run_api_server.py` 也改为 `raise SystemExit(main())`，保留原行为同时让入口返回码静态检查覆盖全部 Python 脚本 -- `run_script_static_checks.py` 现在对 `scripts/` 中任意定义了 `main()` 的脚本强制检查 `raise SystemExit(main())`，不再依赖手工维护白名单 -- `run_offline_checks.run_checks(env=...)` 现在会把传入 env 与当前系统环境合并后传给子检查进程，保证函数调用模式与命令行模式一致 -- `src/db/engine.py` 默认对 PostgreSQL 设置 `connect_timeout=5`，可用 `DATABASE_CONNECT_TIMEOUT` 覆盖，避免数据库不可用时无人脚本长时间挂起 -- 新增只读数据库 readiness 脚本： - - `python3 scripts/run_database_readiness.py` - - 检查数据库连通 - - 检查 schema readiness - - 检查必要 seed data - - 检查可选最小 candles 数量 - - 检查可选 candles 时间跨度与最新 candle 新鲜度 - - `READINESS_OUTPUT_JSON` - - `READINESS_REQUIRED_VENUES` - - `READINESS_REQUIRED_INSTRUMENTS` - - `READINESS_CANDLE_INSTRUMENT_ID` - - `READINESS_CANDLE_TIMEFRAME` - - `READINESS_MIN_CANDLES`，默认 `50` - - `READINESS_MIN_CANDLE_SPAN_MINUTES`，默认 `60` - - `READINESS_MAX_CANDLE_AGE_MINUTES`，默认 `240` - - 输出 `next_actions` 与结构化 `action_plan`： - - `wait_for_database_recovery` - - `run_migrations_before_pipeline` - - `verify_seed_migrations_or_seed_data` - - `run_okx_backfill_or_load_replay_sample` - - `run_guarded_pipeline` - -## 当前验证 - -本轮离线推进后的本地单元测试： - -```text -python3 -m unittest discover -s tests/unit -p "test_*.py" -Ran 216 tests -OK -``` - -前端脚本语法检查： - -```text -node --check src/web/app.js -exit code 0 -``` - -离线总闸： - -```text -python3 scripts/run_offline_checks.py -Ran 216 tests -OK -Migration static checks passed: True -Script static checks passed: True -dashboard_js_syntax passed -``` - -回测脚本 JSON 输出（数据库不可用时）： - -```text -BACKTEST_OUTPUT_JSON=1 python3 scripts/run_backtest.py -{"backtest_run_id": null, "error_type": "OperationalError", "passed": false, "quality_gate": null, "result_count": 0, "summary": null} -``` - -Pipeline JSON 输出（数据库不可用时）： - -```text -PIPELINE_OUTPUT_JSON=1 python3 scripts/run_pipeline.py -{"error_type": "OperationalError", "passed": false} -``` - -执行脚本 JSON 输出（数据库不可用时，仍保持 paper 模式）： - -```text -EXECUTION_OUTPUT_JSON=1 python3 scripts/run_execution.py -{"error_type": "OperationalError", "execution_mode": "paper", "passed": false, "signal_id": 1} - -EXECUTION_SETTLEMENT_OUTPUT_JSON=1 python3 scripts/run_execution_settlement.py -{"error_type": "OperationalError", "execution_mode": "paper", "passed": false, "signal_id": 1} -``` - -报告脚本 JSON 输出： - -```text -REPORTS_OUTPUT_JSON=1 python3 scripts/run_reports.py -{"passed": true, "backtest_summary": {"quality_gate": {"passed": false}}} -``` - -信号脚本 JSON 输出（数据库不可用时）： - -```text -SIGNALS_OUTPUT_JSON=1 python3 scripts/run_signals.py -{"error_type": "OperationalError", "instrument_id": 1, "passed": false, "timeframe": "1m"} -``` - -工具脚本 JSON 输出： - -```text -SHOW_MODELS_OUTPUT_JSON=1 python3 scripts/show_models.py -{"model_count": 16, "passed": true} - -CHECK_DB_OUTPUT_JSON=1 python3 scripts/check_db.py -{"available": false, "error_type": "OperationalError", "passed": false} -``` - -无人流程循环入口当前状态： - -```text -python3 scripts/run_autonomous_cycle.py -Autonomous mode: waiting_for_database -Next actions: wait_for_database_recovery -Action plan [no-db]: wait_for_database_recovery -> /Library/Developer/CommandLineTools/usr/bin/python3 scripts/run_autonomous_cycle.py -Step offline_checks: passed exit_code=0 -Database available: False -Database probe error: OperationalError -``` - -无人流程 JSON 入口当前状态： - -```text -AUTONOMOUS_OUTPUT_JSON=1 python3 scripts/run_autonomous_cycle.py -{"mode": "waiting_for_database", "next_actions": ["wait_for_database_recovery"], "passed": true} -``` - -数据库 readiness 当前状态： - -```text -python3 scripts/run_database_readiness.py -Database readiness passed: False -Database available: False -Database readiness reasons: database_unavailable -Database readiness next actions: wait_for_database_recovery -Database readiness action plan [no-db]: wait_for_database_recovery -> /Library/Developer/CommandLineTools/usr/bin/python3 scripts/run_autonomous_cycle.py -``` - -带 replay 样本门禁的离线总闸： - -```text -OFFLINE_REPLAY_FILE=tests/fixtures/offline_replay_sample.jsonl REPLAY_LEFT_BARS=1 REPLAY_RIGHT_BARS=1 REPLAY_MIN_CANDLES=5 REPLAY_MIN_SWINGS=2 python3 scripts/run_offline_checks.py -Replay sample: first_ts=1 last_ts=5 close_return_pct=0.02040816326530612 -Replay confirmed swings: 2 -Replay quality gate passed: True -``` - -## 数据库恢复后的优先接续点 - -1. 用真实 candles 跑 replay 校验，确认历史数据顺序与 OHLC 合法。 -2. 将 replay confirmed swings 与当前 `SwingService.detect_swings()` 结果抽样比对。 -3. 补齐严格 evidence 链路中的： - - `sweep_id` - - `displacement_id` - - `liquidity_target_id` -4. 在真实回测结果上观察： - - `expectancy_r` - - `profit_factor_r` - - `max_drawdown_r` - - `max_consecutive_losses` - - `avg_mfe_r` - - `avg_mae_r` - -## 当前原则 - -数据库恢复前继续只推进： - -- 纯函数 -- 单元测试 -- 离线 replay -- 风控与质量门槛 -- 文档同步 - -不推进： - -- migration -- 远程部署 -- 真实数据库写入 -- 真实下单 diff --git a/docs/archive/obsolete_plans/AI_ICT_开发路线图_v1.md b/docs/archive/obsolete_plans/AI_ICT_开发路线图_v1.md deleted file mode 100644 index cd0be5f..0000000 --- a/docs/archive/obsolete_plans/AI_ICT_开发路线图_v1.md +++ /dev/null @@ -1,592 +0,0 @@ -# AI ICT 开发路线图 v1 - -## 1. 文档目标 - -本文档把已有三份设计文档落地成可执行开发路线，明确模块顺序、阶段目标、交付物、验证点和推进节奏。 - -关联文档： - -1. `AI_ICT_总体设计文档_v1.md` -2. `AI_ICT_PostgreSQL_Schema_v1.md` -3. `AI_ICT_MVP_规则规格书_v1.md` - -本路线图遵循一个原则： - -> 先打牢基础数据和规则底座，再做信号、回测、执行和 AI 报告。 - ---- - -## 2. 总体阶段划分 - -项目按 7 个阶段推进： - -1. 项目基础设施初始化 -2. 基础数据层 -3. 基础规则层 -4. 核心信号层 -5. 回测与验证层 -6. 半自动执行层 -7. AI 报告与复盘层 - -每一阶段都必须满足“可验证完成”后再进入下一阶段。 - ---- - -## 3. 阶段 0：项目基础设施初始化 - -## 3.1 目标 - -建立后续开发所需的项目骨架、目录结构和工程规范。 - -## 3.2 交付物 - -- 项目目录结构 -- 环境变量模板 -- PostgreSQL 连接配置 -- 基础日志模块 -- 基础配置模块 -- 枚举与常量定义 -- 时间框架与 session 配置表 - -## 3.3 建议目录 - -```text -src/ - config/ - db/ - models/ - services/ - market-data/ - rule-engine/ - signal/ - execution/ - report/ - rules/ - swings/ - ranges/ - liquidity/ - structure/ - fvg/ - backtest/ - risk/ - utils/ - api/ - -docs/ -``` - -## 3.4 完成标准 - -- 本地项目可启动 -- 配置可加载 -- PostgreSQL 可连接 -- 基础日志可输出 - -## 3.5 验证点 - -- 配置加载测试通过 -- 数据库连接测试通过 -- 项目空服务可正常启动 - ---- - -## 4. 阶段 1：基础数据层 - -这是全项目最优先阶段。 - -## 4.1 目标 - -建立统一、稳定、可回放的市场数据底座。 - -## 4.2 模块 - -### M1.1 instruments / venues 基础字典 - -实现： - -- venues 表初始化 -- instruments 表初始化 -- BTC / ETH / XAU 基础配置 -- tick_size / lot_size / price_scale 配置 - -完成标准： - -- 交易品种元信息可查询 -- 不同交易所品种映射清晰 - -### M1.2 candles 入库 - -实现： - -- OKX 行情接入 -- LMAX 行情接入预留接口 -- K 线标准化 -- candles 表写入 -- 去重与唯一约束 - -完成标准： - -- 能按 symbol/timeframe 持续入库 -- 数据不重复 -- 时间戳一致 - -### M1.3 market_sessions 生成器 - -实现： - -- ASIA / LONDON / NY_AM / NY_LUNCH / NY_PM 会话切分 -- 计算 session high / low / midpoint -- 会话状态更新 - -完成标准： - -- 每个交易日可生成完整 session 数据 -- 会话 pivot 可查询 - -## 4.3 阶段交付物 - -- `venues` -- `instruments` -- `candles` -- `market_sessions` -- 数据采集任务 - -## 4.4 验证点 - -- 能查询最近 N 天指定品种 K 线 -- 能查询某天各 session high/low -- candles 唯一键无冲突 -- session 结果与参考图人工抽查一致 - ---- - -## 5. 阶段 2：基础规则层 - -## 5.1 目标 - -实现后续全部信号依赖的基础结构规则。 - -## 5.2 模块 - -### M2.1 swings - -实现： - -- swing high / swing low 识别 -- ST / IT / LT 强度分层 -- provisional / confirmed 区分 - -完成标准： - -- 能按 timeframe 产出稳定 swing 列表 -- 与图表人工抽样比对合理 - -### M2.2 dealing_ranges - -实现： - -- 主工作区间识别 -- equilibrium 计算 -- premium / discount / equilibrium 位置判定 - -完成标准： - -- 当前主 range 可查询 -- 可输出当前价格所处分区 - -### M2.3 liquidity_pools - -实现： - -- prior high / prior low -- equal highs / equal lows -- session highs / lows - -完成标准： - -- pool 可结构化落库 -- 状态可更新：untouched / swept / consumed - -## 5.3 阶段交付物 - -- `swings` -- `dealing_ranges` -- `liquidity_pools` -- 基础规则重算接口 - -## 5.4 验证点 - -- 随机抽取样本图表进行人工比对 -- 同一 timeframe 规则结果可重复生成 -- 当前价格位置判断稳定 - ---- - -## 6. 阶段 3：核心信号层 - -## 6.1 目标 - -实现 MVP 主模型所需的核心触发规则。 - -## 6.2 模块 - -### M3.1 sweep_events - -实现： - -- 流动性刺穿 -- close back inside -- 弱 sweep / 有效 sweep 区分 - -### M3.2 displacement_events - -实现： - -- 大实体 / 推进性 / 脱离平衡 / FVG 联动判定 -- displacement 强度打分 - -### M3.3 structure_events - -实现： - -- MSB -- MSS -- accepted / rejected 状态 - -### M3.4 fvg_zones - -实现： - -- bullish / bearish FVG -- fill_pct -- touched / mitigated / invalidated 状态 - -### M3.5 bias_snapshots - -实现： - -- higher timeframe bias 生成 -- confidence -- execution_intensity -- reason_codes - -### M3.6 trade_signals - -实现： - -- `SWEEP_MSS_FVG` 信号组装 -- invalidations -- RR 校验 -- 状态机流转 - -## 6.3 阶段交付物 - -- `sweep_events` -- `displacement_events` -- `structure_events` -- `fvg_zones` -- `bias_snapshots` -- `trade_signals` - -## 6.4 验证点 - -- 能自动生成候选信号 -- 候选信号有明确 evidence -- 无效信号会被 RR / session / bias 过滤 -- 随机抽取样本图核对规则链路完整性 - ---- - -## 7. 阶段 4：回测与验证层 - -## 7.1 目标 - -验证规则是否具备统计价值，并识别失真来源。 - -## 7.2 模块 - -### M4.1 backtest_runs - -实现： - -- 指定模型、品种、周期范围启动回测 -- 固定配置快照 - -### M4.2 backtest_results - -实现： - -- 单信号 outcome -- mfe / mae -- tp1_hit / tp2_hit -- invalidated_before_entry -- error_tags - -### M4.3 统计分析 - -实现： - -- 按 symbol/session/weekday/timeframe 分组 -- 统计 win rate / RR / drawdown / expectancy - -## 7.3 阶段交付物 - -- `backtest_runs` -- `backtest_results` -- 回测汇总报告 - -## 7.4 验证点 - -- 回测可重复执行 -- 同配置回测结果一致 -- 可明确识别高质量/低质量场景 - ---- - -## 8. 阶段 5：半自动执行层 - -## 8.1 目标 - -在风控前提下，把信号转为可确认执行的订单流程。 - -## 8.2 模块 - -### M5.1 risk engine - -实现： - -- 单笔风险检查 -- 日亏损阈值 -- 连亏停机 -- session 限制 -- 新闻时间窗限制 -- 同方向暴露控制 - -### M5.2 paper trading - -实现： - -- 模拟下单 -- 模拟止损止盈 -- 模拟部分止盈 - -### M5.3 semi-auto execution - -实现： - -- 用户确认后下单 -- 订单状态跟踪 -- TP1 / TP2 管理 -- 强制失效平仓 - -## 8.3 阶段交付物 - -- `trade_executions` -- 风控决策模块 -- 模拟盘执行模块 -- 半自动执行接口 - -## 8.4 验证点 - -- 无 stop 的信号无法进入执行 -- 非允许会话不能开新仓 -- 风控拒绝结果可审计 -- 模拟盘结果可复盘 - ---- - -## 9. 阶段 6：AI 报告与复盘层 - -## 9.1 目标 - -让 AI 站在规则之后做解释、总结和复盘。 - -## 9.2 模块 - -### M6.1 pre-market plan - -输出： - -- 当日 bias -- 主 Draw -- 当前 working range -- 执行许可 - -### M6.2 intraday explanation - -输出： - -- 当前 sweep / MSS / FVG 结构说明 -- 当前信号是否有效 -- 当前关键 invalidation - -### M6.3 post-trade review - -输出： - -- 本笔交易是否符合规则 -- 错误类型 -- 改进建议 - -## 9.3 验证点 - -- AI 输出只解释已有结构对象 -- 不产生脱离规则的裸信号 -- 同一结构输入下输出稳定 - ---- - -## 10. 推荐实施节奏 - -## 10.1 第一优先序 - -1. 阶段 0 -2. 阶段 1 -3. 阶段 2 - -说明： - -- 阶段 1 和阶段 2 是所有后续模块共享前提 -- 若基础数据和基础规则不稳，后面的回测、信号、执行都会失真 - -## 10.2 第二优先序 - -4. 阶段 3 -5. 阶段 4 - -说明： - -- 先有信号，再做系统性回测 -- 不建议跳过回测直接做真实执行 - -## 10.3 第三优先序 - -6. 阶段 5 -7. 阶段 6 - -说明： - -- 先保证执行正确，再让 AI 做说明层增强 - ---- - -## 11. 每阶段建议产出物 - -每阶段结束至少产出以下内容： - -1. 模块代码 -2. 最小验证脚本 -3. 数据样本截图或导出 -4. 阶段测试记录 -5. 已知限制说明 - ---- - -## 12. 开发中必须持续维护的清单 - -## 12.1 配置清单 - -- 品种配置 -- timeframe 配置 -- session 配置 -- 风险阈值配置 -- equal highs/lows 阈值配置 - -## 12.2 验证清单 - -- 数据唯一性 -- 时间戳一致性 -- session 切分准确性 -- rule engine 重跑一致性 -- 回测口径与实盘口径一致性 - -## 12.3 风险清单 - -- 交易所数据缺口 -- session 时区错配 -- swing 参数对不同品种不适配 -- sweep 与真实突破混淆 -- bias 过度主观化 - ---- - -## 13. 下一步落地建议 - -截至当前代码状态，项目已经不再处于起步阶段。已形成的工程主线为： - -`OKX -> candles -> market_sessions -> swings -> dealing_ranges -> liquidity_pools -> sweep_events -> displacement_events -> MSS -> FVG -> bias_snapshots -> trade_signals -> backtest_runs -> backtest_results` - -因此后续开发不应再回到“建立骨架 / 初始化表”的任务，而应进入阶段 4 的质量加固，并为阶段 5 做受控准备。 - -### Step 1：回测真实性加固 - -优先完成： - -- 同根 K 线同时触发 entry / stop / TP 时，记录 `same_candle_ambiguous` 元数据 -- 修正 `invalidated_before_entry` 语义，只表示入场前已经失效，不混用为普通止损 -- 将 session 覆盖结果写入 backtest result meta，支持后续按 session 统计 -- 为回测核心判定补单元测试，避免后续规则增强时回归 - -完成标准： - -- 回测结果能区分 `missed / loss / breakeven / win` -- stop-first 保守假设可被配置快照追溯 -- 同一组 candles + signal 多次运行结果一致 -- 无未来 candles、未触发 entry、同根歧义均可通过 error_tags/meta 审计 - -### Step 2：Signal 层 session 联动 - -优先完成： - -- signal 生成时写入 `session_code` -- 非允许 session 的候选信号不进入 `awaiting_confirmation` -- 将 session filter 的拒绝原因写入 `invalidations` 或 `meta` - -完成标准： - -- `trade_signals.session_code` 不再长期为空 -- OFF_HOURS / NY_LUNCH 的新开仓信号会被降级或拒绝 -- backtest 与 signal 层使用一致的 session 口径 - -### Step 3：结构质量增强 - -优先完成： - -- equal highs / equal lows 阈值配置化 -- liquidity pool merge / 去重 -- MSS acceptance 规则细化 -- FVG mitigation 状态与 signal 有效性联动 - -完成标准： - -- liquidity pools 中明显重复区域减少 -- MSS 不再仅依赖“破位 + displacement”的最简判定 -- 已 mitigated / invalidated FVG 不再生成新的候选信号 - -### Step 4：样本扩大与统计报告 - -优先完成： - -- 扩大 OKX backfill 时间范围 -- 增加多 timeframe 回测入口 -- 输出按 symbol / session / weekday / side 的汇总统计 - -完成标准： - -- 单次回测样本数量具备统计意义 -- 能识别表现较好与较差的 session/方向/品种组合 -- 报告层只解释结构化结果，不直接创造交易建议 - ---- - -## 14. 当前结论 - -本路线图的核心不是把任务列得更多，而是把推进顺序固定下来，并在代码已经越过起步阶段后及时切换重心： - -`基础设施 -> 数据 -> 基础规则 -> 核心信号 -> 回测 -> 执行 -> AI 报告` - -当前合理重心是： - -`回测真实性 -> signal/session 一致性 -> 结构质量 -> 样本统计 -> 受控执行` - -后续开发中，只要发现任务偏离这个顺序，应优先回到基础共享模块和可验证回测结果，避免过早进入复杂策略或真实自动化执行。 diff --git a/docs/archive/obsolete_plans/AI_ICT_执行检查清单_v1.md b/docs/archive/obsolete_plans/AI_ICT_执行检查清单_v1.md deleted file mode 100644 index 5533a38..0000000 --- a/docs/archive/obsolete_plans/AI_ICT_执行检查清单_v1.md +++ /dev/null @@ -1,339 +0,0 @@ -# AI ICT 执行检查清单 v1 - -## 1. 文档目标 - -本文档用于把 AI ICT 项目的每一阶段交付都转成可执行、可验证、可关闭的检查清单，避免任务处于“已启动但未推进”的悬挂状态。 - -适用范围： - -- 总体设计落地 -- 数据库实现 -- 规则引擎实现 -- 信号生成 -- 回测验证 -- 半自动执行 -- AI 报告与复盘 - -核心原则： - -1. 任务必须拆到可执行 -2. 启动后必须立即产出文件、代码或验证结果 -3. 只有“已写入 + 已检查”才算完成 -4. 不允许长期停留在 in_progress 而没有产物 - ---- - -## 2. 通用执行规则 - -每个模块都必须经过以下 5 步： - -1. 明确输入 -2. 明确输出 -3. 完成最小实现 -4. 本地验证 -5. 记录结果并关闭任务 - -若任一步无法继续，必须立即把阻塞点明确写成： - -- 缺少外部资源 -- 缺少配置 -- 需要产品决策 -- 需要真实账户/API 权限 - -除了以上阻塞，不允许任务只挂起不推进。 - ---- - -## 3. 任务关闭标准 - -一个任务只有满足以下条件才允许标记完成： - -### 3.1 文档类任务 - -必须同时满足： - -- 文档已写入本地 `.md` -- 路径已确认存在 -- 已读取前部内容检查格式正常 -- 文档标题、章节结构、核心内容完整 - -### 3.2 代码类任务 - -必须同时满足： - -- 代码已落地到目标文件 -- 相关模块能被导入或启动 -- 至少有一条本地验证结果 -- 修改内容与任务目标直接相关 - -### 3.3 数据库类任务 - -必须同时满足： - -- schema / migration 已落地 -- 字段、约束、索引已核查 -- 至少完成一次本地建表或 dry-run 验证 -- 与设计文档一致 - -### 3.4 规则类任务 - -必须同时满足： - -- 输入输出结构已实现 -- 至少有样本数据跑通 -- 至少人工抽查一个正例/反例 -- 可复用到回测流程 - ---- - -## 4. 阶段执行检查清单 - -## 4.1 阶段 0：项目基础设施初始化 - -### 检查项 - -- [ ] 项目目录结构已建立 -- [ ] 配置模块已建立 -- [ ] 环境变量模板已建立 -- [ ] 日志模块已建立 -- [ ] PostgreSQL 连接模块已建立 -- [ ] 本地启动入口已建立 - -### 完成标准 - -- [ ] 本地服务可启动 -- [ ] 配置可加载 -- [ ] 数据库连接可验证 - -### 验证记录 - -- [ ] 启动命令已记录 -- [ ] 验证结果已记录 - ---- - -## 4.2 阶段 1：基础数据层 - -### 检查项 - -- [ ] `venues` 表已建立 -- [ ] `instruments` 表已建立 -- [ ] `candles` 表已建立 -- [ ] `market_sessions` 表已建立 -- [ ] OKX 数据采集已接通 -- [ ] BTC/ETH K 线可入库 -- [ ] session 生成器已跑通 - -### 完成标准 - -- [ ] 指定 symbol / timeframe 能查到最近数据 -- [ ] candles 唯一键无重复 -- [ ] session high / low / midpoint 可查询 - -### 验证记录 - -- [ ] K 线查询样本已记录 -- [ ] session 查询样本已记录 -- [ ] 一致性问题已清零或列出 - ---- - -## 4.3 阶段 2：基础规则层 - -### 检查项 - -- [ ] swings 识别已实现 -- [ ] dealing range 识别已实现 -- [ ] premium / discount / equilibrium 判定已实现 -- [ ] liquidity pools 识别已实现 -- [x] equal highs / lows 阈值可配置 - -### 完成标准 - -- [ ] 至少一个品种多周期规则跑通 -- [ ] 可查询当前主 range -- [ ] 可查询当前 price location -- [ ] 可查询当前 liquidity pools - -### 验证记录 - -- [ ] 随机样本图人工抽查已完成 -- [ ] 正例样本已记录 -- [ ] 反例样本已记录 - ---- - -## 4.4 阶段 3：核心信号层 - -### 检查项 - -- [ ] sweep 识别已实现 -- [ ] displacement 识别已实现 -- [ ] MSB 已实现 -- [ ] MSS 已实现 -- [ ] FVG 识别已实现 -- [ ] bias snapshot 已实现 -- [ ] `SWEEP_MSS_FVG` 信号组装已实现 - -### 完成标准 - -- [ ] 可生成候选信号 -- [ ] 每个信号都能追溯 evidence -- [ ] RR 过滤生效 -- [ ] session 过滤生效 -- [ ] invalidation 已可生成 - -### 验证记录 - -- [ ] 至少一条有效样本已记录 -- [ ] 至少一条无效样本已记录 -- [ ] 规则链路截图或导出已保留 - ---- - -## 4.5 阶段 4：回测与验证层 - -### 检查项 - -- [x] backtest run 启动逻辑已实现 -- [x] backtest result 存储已实现 -- [x] mfe / mae 已计算 -- [x] tp1 / tp2 命中统计已实现 -- [x] error tags 已实现 -- [ ] 按 session / symbol / weekday 分组统计已实现 - -### 完成标准 - -- [x] 同配置回测可重复 -- [x] 可输出基础绩效指标 -- [ ] 可识别高质量 / 低质量场景 - -### 验证记录 - -- [x] 至少一次完整回测已记录 -- [x] 输出样本已保留 -- [x] 已知偏差已记录 - -### 当前补强项 - -- [x] 同根 K 线 entry / stop / TP 歧义已写入 meta -- [x] `invalidated_before_entry` 与入场后止损语义已拆开 -- [x] 回测核心判定已有单元测试 -- [x] session 过滤与 signal 生成层联动 - ---- - -## 4.6 阶段 5：半自动执行层 - -### 检查项 - -- [x] risk engine 已实现 -- [x] paper trading 已实现 -- [x] semi-auto order confirm 流程已实现 -- [ ] stop / tp1 / tp2 管理已实现 -- [x] execution audit 已实现 - -### 完成标准 - -- [x] 无 stop 信号无法执行 -- [x] 风控拒绝可追溯 -- [ ] 模拟订单可完整开平 -- [x] 半自动流程需要显式确认 - -### 验证记录 - -- [x] 拒单样本已记录 -- [x] 正常成交样本已记录 -- [x] 失效平仓样本已记录 - -### 当前说明 - -- `ExecutionService.evaluate_execution_decision()` 已实现风险判定与拒绝原因收集。 -- `ExecutionService.create_execution()` 已支持 `paper` / `semi_auto` 两种模式。 -- `semi_auto` 现在必须显式传入确认参数后才会真正创建执行记录。 -- 当前仍未覆盖真实撮合/成交回执驱动的持仓管理，因此 `stop / tp1 / tp2 管理` 仍保持未完成。 -- `ExecutionService.audit_execution()`、`classify_execution_lifecycle()`、`persist_execution_settlement()`、`settle_execution_by_id()`、`settle_execution_by_id_from_latest_backtest()`、`settle_latest_execution_for_signal()` 已落地，post-trade review、主运行链路、按 execution_id / signal_id 的回写入口都已接入 execution settlement 输出。 -- 主闭环 `run_closed_loop()` 现已直接使用 `signal_id -> latest execution -> latest backtest -> settlement` 路径。 -- `scripts/run_execution.py`、`scripts/run_pipeline.py`、`scripts/run_execution_settlement.py` 已补数据库不可用时的优雅降级输出，减少样本脚本在无本地 PG 环境下的阻塞。 -- `scripts/run_execution.py` 与 `scripts/run_execution_settlement.py` 都已升级到更完整的自动 settlement 样本链路。 -- 本地验证：`test_execution_service.py` -> 22 tests OK；`test_report_services.py` -> 3 tests OK；`test_api_and_main.py` -> 7 tests OK；`test_api_server.py` -> 8 tests OK - ---- - -## 4.7 阶段 6：AI 报告与复盘层 - -### 检查项 - -- [x] pre-market 模板已实现 -- [x] intraday explanation 模板已实现 -- [x] post-trade review 模板已实现 -- [x] AI 输入只依赖结构化数据 -- [x] AI 输出不绕过规则层 - -### 完成标准 - -- [x] 同一输入得到稳定报告 -- [x] 报告能解释关键 evidence -- [x] 报告含 invalidation / risk note - -### 验证记录 - -- [x] 报告样本已保存 -- [x] 错误示例已记录 - ---- - -## 5. 每日推进检查规则 - -每天推进时，至少要保证完成以下动作中的一项： - -1. 落一个新文件 -2. 改一组代码并验证 -3. 完成一次数据库建表/迁移验证 -4. 完成一轮回测并输出结果 -5. 完成一份本地文档并校验 - -如果没有任何上述产物，就不应把任务继续挂在进行中。 - ---- - -## 6. 防止“任务悬挂”的执行规则 - -发现以下情况，必须立即重拆任务： - -1. 任务启动后长时间无文件产物 -2. 任务启动后无代码变更 -3. 连续两次只报状态，没有验证结果 -4. 任务范围太大，无法在一个工作单元内关闭 - -重拆方法： - -- 把一个大任务拆成 2~5 个更小任务 -- 每个小任务都必须有明确产物 -- 优先先完成能落地的那个最小任务 - ---- - -## 7. 当前建议使用方式 - -后续开发建议始终按以下模式推进： - -1. 从路线图挑一个阶段 -2. 从该阶段挑一个最小可执行模块 -3. 完成实现 -4. 本地验证 -5. 更新本清单 -6. 关闭任务 -7. 再进入下一个最小模块 - ---- - -## 8. 当前结论 - -本清单的目的不是增加流程负担，而是防止项目推进中出现“任务看似启动、实际没有推进”的假忙碌状态。 - -从现在开始，每个任务都应以： - -> 已落地文件 / 已落地代码 / 已验证结果 - -作为完成依据，而不是以“已开始”作为依据。 diff --git a/docs/archive/obsolete_plans/AI_ICT_文档索引与命名规范_v1.md b/docs/archive/obsolete_plans/AI_ICT_文档索引与命名规范_v1.md deleted file mode 100644 index cc9cb85..0000000 --- a/docs/archive/obsolete_plans/AI_ICT_文档索引与命名规范_v1.md +++ /dev/null @@ -1,291 +0,0 @@ -# AI ICT 文档索引与命名规范 v1 - -## 1. 文档目标 - -本文档用于统一当前 AI ICT 项目的文档体系，解决以下问题： - -1. 明确哪些文档是当前主参考文档 -2. 明确文档的用途和阅读顺序 -3. 避免后续出现重复命名、重复主题、主从版本不清的问题 -4. 为后续继续新增文档提供统一命名规范 - ---- - -## 2. 当前文档主索引 - -以下文件为当前 `docs/` 目录下的有效参考文档。 - -### A. 顶层设计文档 - -#### 1. `AI_ICT_总体设计文档_v1.md` -用途： -- 项目总目标 -- 架构总览 -- 服务拆分 -- 数据库选型 -- 模块职责 -- 总体推进方向 - -推荐角色： -- 总纲文档 - ---- - -#### 2. `AI_ICT_PostgreSQL_Schema_v1.md` -用途： -- PostgreSQL 表结构设计 -- 字段、约束、索引、分区建议 -- JSONB 边界 - -推荐角色： -- 数据库主参考文档 - ---- - -#### 3. `AI_ICT_MVP_规则规格书_v1.md` -用途： -- MVP 规则定义 -- 核心对象 -- 主模型 -- Signal 状态机 -- 回测标签 - -推荐角色： -- 规则引擎主参考文档 - ---- - -### B. 推进与交付文档 - -#### 4. `AI_ICT_开发路线图_v1.md` -用途： -- 项目阶段划分 -- 模块顺序 -- 交付物 -- 验证点 - -推荐角色： -- 项目推进主计划文档 - ---- - -#### 5. `AI_ICT_执行检查清单_v1.md` -用途： -- 任务关闭标准 -- 模块完成标准 -- 防止任务悬挂 - -推荐角色： -- 执行与验收参考文档 - ---- - -#### 6. `AI_ICT_项目启动清单_v1.md` -用途： -- 第一轮真实开发启动顺序 -- 基础模块优先顺序 -- 项目起步检查点 - -推荐角色： -- 第一波开发启动清单 - ---- - -### C. 数据与基础模块文档 - -#### 7. `AI_ICT_OKX_数据接入规格书_v1.md` -用途： -- OKX 行情接入 -- 历史补数 -- 增量同步 -- 幂等入库 -- 错误处理 - -推荐角色： -- 市场数据层接入主参考文档 - ---- - -#### 8. `AI_ICT_Session_生成器规格书_v1.md` -用途： -- 会话切分 -- 时区处理 -- 跨午夜归属规则 -- session high/low/midpoint -- `market_sessions` 写入 - -推荐角色： -- Session 模块主参考文档 - ---- - -### D. Migration 文档 - -#### 9. `AI_ICT_Migration_拆分计划_v1.md` -用途： -- schema migration 拆批 -- 执行顺序 -- 依赖关系 -- 验证点 -- 回滚顺序 - -推荐角色： -- 当前 migration 主参考文档 - -状态： -- **当前主版本（canonical）** - ---- - -#### 10. `AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` -用途： -- 与 migration 拆分主题相近的旧/重复命名版本 - -状态： -- **非主版本** -- 当前不建议继续引用 - -处理建议： -- 后续可合并或归档 -- 若确认内容重复，应统一保留 `AI_ICT_Migration_拆分计划_v1.md` - ---- - -## 3. 推荐阅读顺序 - -如果是第一次进入项目，建议按以下顺序阅读： - -### 第 1 层：总纲 -1. `AI_ICT_总体设计文档_v1.md` -2. `AI_ICT_开发路线图_v1.md` - -### 第 2 层：基础实现标准 -3. `AI_ICT_PostgreSQL_Schema_v1.md` -4. `AI_ICT_MVP_规则规格书_v1.md` - -### 第 3 层：启动与执行 -5. `AI_ICT_项目启动清单_v1.md` -6. `AI_ICT_执行检查清单_v1.md` - -### 第 4 层：首批模块落地 -7. `AI_ICT_OKX_数据接入规格书_v1.md` -8. `AI_ICT_Session_生成器规格书_v1.md` -9. `AI_ICT_Migration_拆分计划_v1.md` - ---- - -## 4. 文档分层规范 - -后续新增文档建议按以下四类分层： - -### 4.1 顶层设计类 -命名模板： - -`AI_ICT_<主题>文档_vN.md` - -示例： -- `AI_ICT_总体设计文档_v1.md` -- `AI_ICT_风控设计文档_v1.md` - ---- - -### 4.2 规格书类 -命名模板： - -`AI_ICT_<模块>规格书_vN.md` - -示例： -- `AI_ICT_OKX_数据接入规格书_v1.md` -- `AI_ICT_Session_生成器规格书_v1.md` -- `AI_ICT_Swing_识别规格书_v1.md` - ---- - -### 4.3 计划/清单类 -命名模板： - -`AI_ICT_<主题>清单_vN.md` -或 -`AI_ICT_<主题>路线图_vN.md` - -示例： -- `AI_ICT_项目启动清单_v1.md` -- `AI_ICT_执行检查清单_v1.md` -- `AI_ICT_开发路线图_v1.md` - ---- - -### 4.4 数据库 / migration 类 -命名模板： - -`AI_ICT_<数据库或模块>_<主题>_vN.md` - -示例： -- `AI_ICT_PostgreSQL_Schema_v1.md` -- `AI_ICT_Migration_拆分计划_v1.md` - -说明： -- 这类文档尽量固定中文或英文一种主命名风格 -- 不要同一主题同时出现中英混合双版本标题 - ---- - -## 5. 命名统一规则 - -后续新增文档时，必须遵守： - -1. 同一主题只保留一个 canonical 名称 -2. 若重写版本，递增 `v2`，不要新起另一个不同名字 -3. 不要同时保留： - - 中文主题名版本 - - 英文同义主题名版本 -4. 若发生主题重复，必须在索引文档中明确： - - 哪个是主版本 - - 哪个已废弃或待归档 - ---- - -## 6. 文档生命周期规则 - -每份文档应有如下状态之一： - -- canonical：当前主参考文档 -- active：仍在使用，但不是最高优先级引用 -- draft：临时草稿 -- archived：已归档 -- deprecated：已弃用，不再引用 - -当前建议： - -- `AI_ICT_Migration_拆分计划_v1.md` -> canonical -- `AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` -> deprecated 或待归档 - ---- - -## 7. 后续建议新增文档列表 - -按优先级建议后续继续补： - -1. `AI_ICT_Swing_识别规格书_v1.md` -2. `AI_ICT_Dealing_Range_规格书_v1.md` -3. `AI_ICT_Liquidity_Pool_规格书_v1.md` -4. `AI_ICT_Sweep_识别规格书_v1.md` -5. `AI_ICT_MSS_判定规格书_v1.md` -6. `AI_ICT_FVG_规格书_v1.md` -7. `AI_ICT_Backtest_规格书_v1.md` -8. `AI_ICT_风控规格书_v1.md` - ---- - -## 8. 当前结论 - -当前 `docs/` 已经具备从方案到启动的第一轮完整文档骨架。 - -从现在开始，新增文档时应统一遵守： - -- 单主题单主版本 -- 先写入再汇报 -- 用索引文档固定引用关系 -- 避免中英文重复命名并存 - -本文件应作为当前 `docs/` 目录的导航入口与命名规范参考。 \ No newline at end of file diff --git a/docs/archive/obsolete_plans/AI_ICT_重复文档清理计划_v1.md b/docs/archive/obsolete_plans/AI_ICT_重复文档清理计划_v1.md deleted file mode 100644 index 60c2610..0000000 --- a/docs/archive/obsolete_plans/AI_ICT_重复文档清理计划_v1.md +++ /dev/null @@ -1,217 +0,0 @@ -# AI ICT 重复文档清理计划 v1 - -## 1. 文档目标 - -本文档用于解决当前 `docs/` 目录中出现的重复文档、重复命名和主版本不清的问题，防止后续继续引用混乱。 - -目标： - -1. 列出当前重复/冲突文档 -2. 明确每组文档的 canonical 主版本 -3. 明确待归档/待废弃文件 -4. 给出实际清理顺序 -5. 固定未来不再重复的规则 - ---- - -## 2. 当前发现的重复/冲突文档 - -根据当前 `docs/` 目录，已发现以下重复组： - -### 2.1 Migration 主题重复组 - -#### 文件 A -`AI_ICT_Migration_拆分计划_v1.md` - -#### 文件 B -`AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` - -问题： -- 主题高度重合 -- 一个中文命名，一个英文命名 -- 容易导致后续引用时不确定主版本 - -当前建议： -- **canonical**：`AI_ICT_Migration_拆分计划_v1.md` -- **待废弃 / 待归档**：`AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` - -原因： -- 中文命名已被文档索引明确标记为主版本 -- 该版本更符合当前目录整体命名风格 - ---- - -### 2.2 Session 主题重复组 - -#### 文件 A -`AI_ICT_Session_生成器规格书_v1.md` - -#### 文件 B -`AI_ICT_Session_Generator_Spec_v1.md` - -问题： -- 属于同一主题的中英文双命名版本 -- 当前主参考文档已明确为中文规格书版本 -- 若继续并存，会导致下游引用混乱 - -当前建议： -- **canonical**：`AI_ICT_Session_生成器规格书_v1.md` -- **待废弃 / 待归档**：`AI_ICT_Session_Generator_Spec_v1.md` - -原因： -- 中文命名已纳入索引体系 -- 与其他模块规格书风格一致 - ---- - -## 3. 当前 canonical 文档清单 - -以下文档应视为当前主引用版本： - -- `AI_ICT_总体设计文档_v1.md` -- `AI_ICT_PostgreSQL_Schema_v1.md` -- `AI_ICT_MVP_规则规格书_v1.md` -- `AI_ICT_开发路线图_v1.md` -- `AI_ICT_执行检查清单_v1.md` -- `AI_ICT_项目启动清单_v1.md` -- `AI_ICT_OKX_数据接入规格书_v1.md` -- `AI_ICT_Session_生成器规格书_v1.md` -- `AI_ICT_Swing_识别规格书_v1.md` -- `AI_ICT_Migration_拆分计划_v1.md` -- `AI_ICT_文档索引与命名规范_v1.md` - -这些文件才是后续继续扩展时的主参考对象。 - ---- - -## 4. 建议的清理动作 - -## 4.1 第一阶段：先标记，不立即删除 - -当前建议先不要直接删除重复文件，而是先完成以下动作： - -1. 在索引文档中明确 canonical -2. 在清理计划中明确 deprecated 文档 -3. 后续新增引用只允许引用 canonical 文档 - -原因： -- 当前重复文件可能还承载一部分历史内容 -- 直接删除前，最好先人工确认内容是否真的完全重复 - ---- - -## 4.2 第二阶段：移动到 archive 或 deprecated 区 - -建议后续建立： - -```text -docs/ - archive/ -``` - -然后把以下文件移入 archive： - -- `AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` -- `AI_ICT_Session_Generator_Spec_v1.md` - -或改名为： - -- `DEPRECATED_AI_ICT_PostgreSQL_Migration_Split_Plan_v1.md` -- `DEPRECATED_AI_ICT_Session_Generator_Spec_v1.md` - -说明： -- 使用 archive 子目录比直接删除更稳妥 -- 当前阶段更推荐 archive，而不是物理删除 - ---- - -## 4.3 第三阶段：统一索引引用 - -完成 archive 后，应同步更新： - -- `AI_ICT_文档索引与命名规范_v1.md` - -使其明确： - -- active docs -- archived docs -- deprecated docs - ---- - -## 5. 建议的清理执行顺序 - -建议按以下顺序进行： - -### Step 1 -保留所有文件不删，只明确 canonical - -### Step 2 -建立 `docs/archive/` - -### Step 3 -将重复英文版本移入 `archive/` - -### Step 4 -更新索引文档中的路径与状态 - -### Step 5 -后续所有新增文档只允许一个 canonical 名称 - ---- - -## 6. 未来避免重复的规则 - -从现在开始，新增文档必须遵守以下规则： - -### 规则 1：单主题只允许一个主文件名 -同一主题只保留一个 canonical 名称，不允许再额外起一个英文同义名或中文同义名。 - -### 规则 2：更新版本用 v2，不重起新文件名 -如果某主题要升级： - -- 正确做法：`..._v2.md` -- 错误做法：再新建一个不同命名的同义文件 - -### 规则 3：先查索引，再写文档 -新增文档前，必须先检查： - -- `AI_ICT_文档索引与命名规范_v1.md` - -确认没有现成同主题主文件。 - -### 规则 4：英文文件名只在必要时统一采用全英文体系 -若未来要切全英文命名，必须统一迁移整个体系，不能中英混杂逐个漂移。 - ---- - -## 7. 当前不建议直接删除的原因 - -当前阶段不建议直接删除重复文件，原因是： - -1. 可能仍有历史内容差异 -2. 当前更需要先稳定文档主线 -3. 立即删除属于可逆性较低操作，应该在确认后做 - -所以当前最合理策略是： - -- 先标记 -- 再归档 -- 最后如有必要再删除 - ---- - -## 8. 当前结论 - -当前 `docs/` 目录已经形成主干体系，但出现了两组明显重复文档： - -1. Migration 主题重复 -2. Session 主题重复 - -当前统一策略如下： - -- 主版本继续保留中文 canonical 文档 -- 英文重复命名版本后续进入 archive -- 今后新增文档只允许单主题单主名称 - -本文件应作为后续文档清理与去重的直接执行依据。 \ No newline at end of file diff --git a/docs/archive/obsolete_plans/AI_ICT_项目启动清单_v1.md b/docs/archive/obsolete_plans/AI_ICT_项目启动清单_v1.md deleted file mode 100644 index 61414b4..0000000 --- a/docs/archive/obsolete_plans/AI_ICT_项目启动清单_v1.md +++ /dev/null @@ -1,250 +0,0 @@ -# AI ICT 项目启动清单 v1 - -## 1. 文档目标 - -本文档用于指导 AI ICT 项目从方案阶段正式进入第一轮真实开发，确保启动工作按顺序落地，不出现“准备了很多文档，但没有真正开始实现”的情况。 - -本清单聚焦第一波基础共享模块： - -1. 项目骨架 -2. PostgreSQL 初始化 -3. OKX 数据接入 -4. Session 生成器 -5. Swing / Range 第一版 - ---- - -## 2. 启动阶段总原则 - -### 原则 1：先做基础共享模块 -优先实现会被后续全部规则复用的模块： - -- config -- db -- candles -- sessions -- swings -- ranges - -### 原则 2：每一步都必须可验证 -每完成一个模块，至少产出以下之一： - -- 本地文件 -- 数据库对象 -- 可运行命令 -- 测试结果 -- 样本输出 - -### 原则 3：先 OKX，后 LMAX -第一轮只优先打通 BTC / ETH，XAU 的 LMAX 接入放在第二顺位。 - ---- - -## 3. 启动顺序 - -## Step 1：创建项目代码骨架 - -### 目标 -建立可持续开发的项目基础结构。 - -### 检查项 -- [ ] 初始化项目目录结构 -- [ ] 创建 `config/` -- [ ] 创建 `db/` -- [ ] 创建 `services/market-data/` -- [ ] 创建 `services/rule-engine/` -- [ ] 创建 `services/signal/` -- [ ] 创建 `risk/` -- [ ] 创建 `backtest/` -- [ ] 创建 `api/` -- [ ] 创建基础 `utils/` - -### 完成标准 -- [ ] 项目可以本地启动一个空入口 -- [ ] 配置文件可以加载 -- [ ] 日志可以输出 - ---- - -## Step 2：初始化 PostgreSQL - -### 目标 -建立基础数据库对象。 - -### 优先建表顺序 -1. `venues` -2. `instruments` -3. `candles` -4. `market_sessions` -5. `swings` -6. `dealing_ranges` -7. `liquidity_pools` - -### 检查项 -- [ ] PostgreSQL 连接配置已建立 -- [ ] migration 目录已建立 -- [ ] 第一版 schema 已拆分成 migration -- [ ] 建表顺序已固定 -- [ ] 主键和唯一键已定义 -- [ ] candles 分区策略已确定 - -### 完成标准 -- [ ] 本地数据库可完成初始化 -- [ ] 所有基础表存在 -- [ ] candles 唯一键可生效 - ---- - -## Step 3：初始化品种元数据 - -### 目标 -建立首批交易对象配置。 - -### 首批对象 -- [ ] OKX BTC -- [ ] OKX ETH -- [ ] LMAX XAU（先可预留，后接真实数据） - -### 检查项 -- [ ] venue 元数据已插入 -- [ ] instrument 元数据已插入 -- [ ] tick_size 已定义 -- [ ] lot_size 已定义 -- [ ] price_scale 已定义 - -### 完成标准 -- [ ] 所有首批 instrument 可被程序查询 - ---- - -## Step 4：接入 OKX 行情 - -### 目标 -打通第一条真实数据链路。 - -### 检查项 -- [ ] 明确 OKX K 线接口 -- [ ] 实现历史 K 线抓取 -- [ ] 实现增量 K 线抓取 -- [ ] 做字段标准化映射 -- [ ] 入库 `candles` -- [ ] 增加去重逻辑 - -### 第一轮时间框架 -- [ ] 1m -- [ ] 5m -- [ ] 15m -- [ ] 1h -- [ ] 4h - -### 完成标准 -- [ ] BTC 可写入多周期 candles -- [ ] ETH 可写入多周期 candles -- [ ] 指定时间范围可查到连续数据 - ---- - -## Step 5：实现 Session 生成器 - -### 目标 -从 candles 自动生成会话边界和 pivot。 - -### 默认时区 -- `America/New_York` - -### 默认会话 -- [ ] ASIA -- [ ] LONDON -- [ ] NY_AM -- [ ] NY_LUNCH -- [ ] NY_PM - -### 检查项 -- [ ] session 切分逻辑已实现 -- [ ] high / low 计算已实现 -- [ ] midpoint 计算已实现 -- [ ] session 数据写入 `market_sessions` - -### 完成标准 -- [ ] 指定日期能生成完整 session 数据 -- [ ] session high/low 与图表人工抽查一致 - ---- - -## Step 6：实现 Swing 第一版 - -### 目标 -建立结构高低点基础识别。 - -### 检查项 -- [ ] swing high 识别 -- [ ] swing low 识别 -- [ ] confirmed / provisional 区分 -- [ ] M5 参数已配置 -- [ ] M15 参数已配置 -- [ ] H1 参数已配置 - -### 完成标准 -- [ ] 至少一个品种多周期 swing 可生成 -- [ ] 样本人工抽查合理 - ---- - -## Step 7：实现 Dealing Range 第一版 - -### 目标 -生成 working range 与位置标签。 - -### 检查项 -- [ ] range high / low 生成 -- [ ] equilibrium 计算 -- [ ] premium / discount / equilibrium 判定 -- [ ] 当前主 range 可查询 - -### 完成标准 -- [ ] 给定价格可判断位置 -- [ ] range 与 swing 关联可追溯 - ---- - -## 4. 第一轮验证里程碑 - -完成以下条件后，才算真正进入“规则开发期”： - -- [ ] BTC / ETH candles 已持续入库 -- [ ] session 已可稳定生成 -- [ ] swings 已可查询 -- [ ] range 已可查询 -- [ ] 当前 price location 已可查询 - -只有这五项成立，后面再进入： - -- liquidity pools -- sweep -- displacement -- MSS -- FVG - ---- - -## 5. 启动阶段推荐输出物 - -启动阶段至少应新增这些真实产物： - -1. 项目目录骨架 -2. migration 文件 -3. PostgreSQL 连接模块 -4. OKX candles 抓取模块 -5. session 生成器 -6. swings 识别模块 -7. dealing range 识别模块 - ---- - -## 6. 当前结论 - -AI ICT 项目从现在开始，真正的“第一锹土”不是写更多概念，而是完成下面这条真实链路： - -`PostgreSQL -> OKX Candles -> Sessions -> Swings -> Dealing Range` - -只要这条链路打通，后续 liquidity / sweep / MSS / FVG / signal 才有稳定基础。 \ No newline at end of file diff --git a/docs/examples/training_case_package_smoke_m6.md b/docs/examples/training_case_package_smoke_m6.md deleted file mode 100644 index ac19d10..0000000 --- a/docs/examples/training_case_package_smoke_m6.md +++ /dev/null @@ -1,27 +0,0 @@ -# Training Case Package Smoke - -Run the offline package smoke as a local import/export smoke: - -```bash -.venv/bin/python scripts/run_training_case_package.py \ - --input tests/fixtures/training_case_package_m6.json \ - --output /tmp/training_case_public_export.json -``` - -The command uses local files only. The written export is public output in the public package shape and omits internal solution details. - -Discover the same public package import/export smoke and public error contract from CLI help: - -```bash -.venv/bin/python scripts/run_training_case_package.py --help -``` - -The broader offline check suite includes this same Training Case smoke as `training_case_package`: - -```bash -.venv/bin/python scripts/run_offline_checks.py -``` - -On success, stdout is one JSON object with `passed`, `input`, `output`, `imported`, and `exported`. `--output` writes only the public export JSON shown by `output`; it does not include internal solution details. - -On public errors for invalid input paths or invalid output targets, stdout is one-line JSON with `passed`, `input`, `output`, and `error`. Stable public error codes include `input_file_not_found`, `input_path_is_directory`, `output_path_is_directory`, and `output_path_unwritable`; the message masks raw internals. diff --git a/docs/training_case_engine_m1_m6_product_readme.md b/docs/training_case_engine_m1_m6_product_readme.md deleted file mode 100644 index 9fe0bfc..0000000 --- a/docs/training_case_engine_m1_m6_product_readme.md +++ /dev/null @@ -1,199 +0,0 @@ -# Training Case Engine M1-M40 Product README - -Training Case Engine is the product-facing training module in AI Exchange. M1-M40 is the current public milestone range, with current product maturity through M40 across public API, package, dashboard, validation, and local deployment guard surfaces. - -## Training Case Engine acceptance index - -Accepted milestone range: M1-M40, with current product maturity through M40. - -Offline validation commands: - -- `.venv/bin/python -m unittest discover -s tests/unit -p "test_*.py"` -- `.venv/bin/python scripts/run_offline_checks.py` - -Accepted user-facing surfaces: - -- Dashboard Training panel -- public API routes -- offline public package import/export -- public error catalog -- public privacy contract coverage - -## Milestone Release Index - -- M1-M28 established persisted training cases, a lightweight HTTP API, a dashboard entry, validation hardening, public package import/export, offline package smoke coverage, product documentation checks, public response plus package smoke privacy hardening, and dashboard/public docs privacy alignment. The M1-M28 product maturity through M28 included API contract coverage, error contract coverage, the fixture/schema contract, the offline checks registry smoke, recursive public payload sanitization, public response privacy contract coverage, package smoke docs/fixture public privacy guards, and dashboard and public docs privacy smoke coverage. -- M29-M34 kept package smoke docs, fixture/public output, offline registry references, dashboard privacy, and public route documentation audited for public package, public export, and public output workflows. -- M35 acceptance posture added public validation through the Training Case acceptance manifest, focused milestone test suites, and offline checks. -- M36-M40 locks API contract coverage, error contract coverage, privacy contract coverage, package smoke and offline registry coverage, dashboard and public docs privacy smoke coverage, and single-set local Docker deployment plus Docker smoke guard coverage. - -## Dashboard Entry - -Run the local API server with the project script and open the root dashboard. The dashboard includes a Training panel with: - -- available cases -- user progress -- attempt start -- annotation note save -- attempt submit - -The dashboard calls the same Training endpoints listed below and displays public case fields only. - -## Local Docker Deployment - -Use the single-set local Docker deployment policy for the local Training dashboard: - -- Deploy from the deploy directory `/root/deploy/ai-ict`. -- Keep the compose project `ai-ict`, container `ai-ict`, and exactly one active deployment set. -- Keep one active `ai-ict` container; do not create a second local stack or a second `ai-ict` container. -- Before every local rebuild, stop stale services first, then start the same set: - -```bash -cd /root/deploy/ai-ict -docker compose -p ai-ict -f /root/deploy/ai-ict/docker-compose.yml down --remove-orphans -docker compose -p ai-ict -f /root/deploy/ai-ict/docker-compose.yml up -d --build -``` - -- After the rebuild, verify the same one active set, one active `ai-ict` container, and Docker `healthy` status: - -```bash -docker compose -p ai-ict -f /root/deploy/ai-ict/docker-compose.yml ps -test "$(docker ps --filter label=com.docker.compose.project=ai-ict --format '{{.Names}}' | wc -l | tr -d ' ')" = "1" -test "$(docker ps --filter name=^/ai-ict$ --format '{{.Names}}' | wc -l | tr -d ' ')" = "1" -test "$(docker inspect -f '{{.State.Health.Status}}' ai-ict)" = "healthy" -``` - -- Check the documented local demo readiness without starting containers; this offline check does not invoke Docker: - -```bash -.venv/bin/python scripts/check_local_demo_readiness.py -``` - -## API Surface - -All endpoints use JSON responses. List endpoints accept `limit` with an upper bound of `100`. - -| Method | Path | Capability | -| --- | --- | --- | -| GET | `/training/cases` | List cases by optional status, skill tag, instrument, and limit filters. | -| GET | `/training/cases/{case_id}` | Read one public case. | -| GET | `/training/cases/export` | Export a public package with the same case filters as the case list. | -| POST | `/training/cases/import` | Import a versioned public package and create cases plus tasks. | -| POST | `/training/attempts` | Start an attempt for a case. | -| POST | `/training/attempts/{attempt_id}/annotations` | Save an annotation payload for an attempt. | -| POST | `/training/attempts/{attempt_id}/submit` | Submit an attempt with an optional score. | -| GET | `/training/progress` | List progress rows by optional user, skill tag, and limit filters. | - -Public API responses for case list/detail, package export/import, progress, submit, create-attempt, and annotation lifecycle routes are covered by privacy contract tests. Those responses scrub private solution material, including nested internal solution details, before returning JSON. - -## Package Smoke - -Use the offline package smoke to check import plus public export and public output without external services: - -```bash -.venv/bin/python scripts/run_training_case_package.py \ - --input tests/fixtures/training_case_package_m6.json \ - --output /tmp/training_case_public_export.json -``` - -Discover the same public package import/export behavior and public error contract from CLI help: - -```bash -.venv/bin/python scripts/run_training_case_package.py --help -``` - -The broader offline check suite also includes this package smoke as `training_case_package` and dashboard JavaScript syntax validation as `dashboard_js_syntax`: - -```bash -.venv/bin/python scripts/run_offline_checks.py -``` - -## Acceptance And Offline Validation - -The M35 acceptance posture uses the Training Case acceptance manifest to keep focused milestone test suites discoverable and aligned with the offline checks. The broader offline checks include the public package smoke, dashboard syntax validation, and dashboard and public docs privacy smoke coverage without external services. - -## Validation And Errors - -Training public error catalog: - -- Malformed or non-object request bodies are deterministic public validation errors and return `400` with `invalid_json_body`. -- Missing required JSON fields are deterministic public validation errors and return `400` with `missing_required_json_field:`. -- Invalid JSON field values are deterministic public validation errors and return `400` with `invalid_json_field:`. -- Invalid path identifiers are deterministic public validation errors and return `400` with `invalid_path_param:`. -- Invalid list limits are deterministic public validation errors and return `400` with `invalid_limit_query_param:limit`; valid limits are `1` through `100`. -- Missing cases return `404` with `not_found`. -- Masked unexpected failures return `500` with `internal_server_error`; the public response masks raw internals, and responses do not echo raw internals. -- Package CLI public errors for invalid input paths and invalid output targets emit one-line JSON with `passed`, `input`, `output`, and `error`; stable public error codes include `input_file_not_found`, `input_path_is_directory`, `output_path_is_directory`, and `output_path_unwritable`. - -Public API response examples: - -- Malformed or non-object JSON body: `POST /training/attempts` -> HTTP `400` - -```json -{"error": "invalid_json_body"} -``` - -- Missing required JSON field: `POST /training/attempts` with `{}` -> HTTP `400` - -```json -{"error": "missing_required_json_field:case_id"} -``` - -- Invalid JSON field value: `POST /training/attempts` with text `case_id` -> HTTP `400` - -```json -{"error": "invalid_json_field:case_id"} -``` - -- Invalid path identifier: `GET /training/cases/not-an-id` -> HTTP `400` - -```json -{"error": "invalid_path_param:case_id"} -``` - -- Invalid list limit: `GET /training/cases?limit=not-a-number` -> HTTP `400` - -```json -{"error": "invalid_limit_query_param:limit"} -``` - -- Missing case: `GET /training/cases/404` -> HTTP `404` - -```json -{"error": "not_found"} -``` - -- Masked internal server error: any Training route -> HTTP `500` - -```json -{"error": "internal_server_error"} -``` - -Package CLI public error examples: - -- Missing input file: - -```json -{"passed": false, "input": "missing_training_case_package.json", "output": "training_case_public_export.json", "error": "input_file_not_found"} -``` - -- Directory input path: - -```json -{"passed": false, "input": "training_case_package_dir", "output": "training_case_public_export.json", "error": "input_path_is_directory"} -``` - -- Directory output target: - -```json -{"passed": false, "input": "tests/fixtures/training_case_package_m6.json", "output": "training_case_public_export_dir", "error": "output_path_is_directory"} -``` - -Package import rejects private internal solution fields. Package export is stable public output JSON and omits private solution material. - -## Data Isolation Guarantees - -- Training records are scoped to the training domain: cases, tasks, attempts, annotations, scores, and progress. -- Training may reference upstream market or rule events as read-only context. -- Training APIs and package tooling do not write to signals, executions, backtest results, or live-trading records. -- Public package import/export keeps operator-only notes, rubric internals, and private solution material out of exported payloads. -- The offline package smoke uses local files and an in-memory training repository; it writes only the requested public output file. diff --git a/docs/workflow/AI_协作自动化工作规程_v1.md b/docs/workflow/AI_协作自动化工作规程_v1.md deleted file mode 100644 index 5666dd9..0000000 --- a/docs/workflow/AI_协作自动化工作规程_v1.md +++ /dev/null @@ -1,338 +0,0 @@ -# AI 协作自动化工作规程 v1 - -## 1. 文档目标 - -本文档用于总结本次 AI ICT 项目协作中被验证有效的自动化协作规则，形成一套可复用的“AI 自动执行工作规程”。 - -目标： - -1. 固化本次有效的自动化执行经验 -2. 让后续项目能够直接复用这些规则 -3. 避免再次出现“口头上自动、实际却经常停下”的情况 -4. 让 AI 在复杂工程任务中稳定进入产物驱动模式 - ---- - -## 2. 核心结论 - -本次协作中最有效的转折，不是“要求 AI 自动一点”，而是把自动化要求从模糊偏好，变成了可执行规则。 - -也就是说，真正有效的不是： - -- 更积极 -- 更自动 -- 少停一点 - -而是以下这类明确规则： - -- 不要只说开始，要真正推进 -- 只有文件写入并检查后才算完成 -- 大任务必须拆成小任务 -- 做完一个直接做下一个 -- 同一个阻塞不要重复卡住 -- 除非不可逆操作或缺外部资源，否则不要停 - ---- - -## 3. 从“状态驱动”切到“产物驱动” - -这是最关键的一条。 - -### 3.1 低效模式：状态驱动 - -典型表现： - -- 任务显示 in_progress -- 口头说已开始 -- 频繁汇报计划 -- 但没有真实文件、代码或验证结果产出 - -这种模式会让人感觉： - -> 看起来在忙，但实际上没有推进 - ---- - -### 3.2 高效模式：产物驱动 - -正确模式应当是： - -- 文档任务 -> 写出真实 `.md` -- 代码任务 -> 写出真实 `.py` / `.sql` -- 校验任务 -> 给出真实检查结果 -- 每完成一步都必须有可见产物 - -原则： - -> 没有产物，就不算推进。 - ---- - -## 4. 自动化执行的 8 条核心规则 - -## 规则 1：任务必须拆小 - -不要保留大而空的任务，例如： - -- 设计整个系统 -- 搭建所有功能 -- 处理后续工作 - -应该拆成： - -- 写总体设计文档 -- 写 schema 文档 -- 写 OKX 接入规格书 -- 写 session generator -- 写 swing service - -原则： - -- 每个任务都必须短、具体、可执行 -- 每个任务都要能在一个工作单元中拿出产物 - ---- - -## 规则 2：只在“写完并检查后”汇报完成 - -错误方式： - -- 我开始写了 -- 我正在做 -- 我已经启动下一步 - -正确方式： - -- 文件已经写入本地 -- 已经检查文件存在 -- 已经抽样读取内容 -- 然后再汇报 - -原则： - -> 汇报完成的前提必须是“产物已存在”。 - ---- - -## 规则 3：除了必要阻塞，不要停下等待指示 - -默认执行规则应为： - -- 做完当前任务 -- 自动进入下一任务 -- 直到遇到真正需要用户决策的事情才停 - -真正允许停下的情况： - -1. 不可逆操作 -2. 缺少外部资源 -3. 缺少权限 -4. 需要明确产品决策 - -除此以外，不应把调度权频繁交回用户。 - ---- - -## 规则 4：同一个阻塞不要重复两次 - -如果同一种阻塞连续出现两次，且没有新产物、新验证、新任务推进，就不能继续停留在原地。 - -应立即： - -- 重拆任务 -- 换一种推进路径 -- 先做旁边可落地的子任务 - -例如： - -- 某个文件目录不存在 -> 立刻改成先让用户建目录或改到已有目录 -- 某个 `__init__.py` 更新被写入保护拦住 -> 先读再改，不继续卡住 - -原则： - -> 同一阻塞重复两次后，必须换打法。 - ---- - -## 规则 5：里程碑更新要短，但不能替代执行 - -更新是必要的，但不能变成“只有汇报，没有推进”。 - -好的更新格式： - -- 已写入哪些文件 -- 已检查哪些文件 -- 下一步会继续推进什么 - -不好的更新格式： - -- 我正在进行中 -- 我马上开始 -- 我会继续做 - -原则： - -> 更新只能说明进展，不能替代进展本身。 - ---- - -## 规则 6：优先从基础共享模块开始 - -对复杂系统，最容易出问题的是太早冲到上层功能。 - -正确顺序应该是： - -1. 配置 -2. DB -3. 基础模型 -4. migration -5. 数据接入 -6. session -7. swing -8. range -9. liquidity -10. events -11. signal -12. execution - -原则： - -> 先把所有后续模块共享依赖打牢，再往上走。 - ---- - -## 规则 7：并行只用于真正独立的任务 - -适合并行的： - -- 两份互不依赖的文档 -- 两个互不影响的检查任务 -- 目录创建 + 配置文件写入 - -不适合并行的： - -- 同一文件链上的连续写入 -- 依赖前一步结果的任务 -- 需要共享上下文的顺序实现 - -原则： - -> 并行是为了提速，不是为了制造混乱。 - ---- - -## 规则 8：当进入实现阶段后，优先写真实文件而不是继续扩文档 - -文档足够以后，必须切换到： - -- 真实目录 -- 真实配置 -- 真实模型 -- 真实 migration -- 真实脚本 -- 真实服务 - -否则会停留在“文档很全，但工程没启动”的假进展状态。 - -原则： - -> 文档只服务于实现，不能替代实现。 - ---- - -## 5. 本次实践中验证有效的工作模式 - -本次实践中，下面这种模式被证明最有效： - -### Step 1 -创建任务 - -### Step 2 -立即进入实际写文件/写代码 - -### Step 3 -写完后立刻本地检查： -- 是否存在 -- 是否可读 -- 是否抽样正常 - -### Step 4 -更新任务完成状态 - -### Step 5 -直接进入下一任务 - -这个闭环一旦形成，自动化就会很稳。 - ---- - -## 6. 文档类任务的标准流程 - -1. 明确主题 -2. 直接写 `.md` -3. 读回前几十行检查 -4. 再汇报完成 -5. 继续下一份文档 - -关键原则： - -- 不先说“开始写” -- 只在“写完+检查完”后说完成 - ---- - -## 7. 代码类任务的标准流程 - -1. 明确模块边界 -2. 直接落文件 -3. 若更新已有文件，先读后改 -4. 检查文件存在 -5. 抽样读代码 -6. 再汇报完成 -7. 进入下一个模块 - -关键原则： - -- 以代码文件为产物 -- 以检查结果为结束条件 - ---- - -## 8. 为什么这套方式后来明显变好了 - -因为后期已经形成了稳定闭环： - -- 小任务 -- 真产物 -- 本地检查 -- 简短汇报 -- 立即继续 - -所以后面看起来就像“真正开始自动运转了”。 - -不是因为 AI 自己突然变了，而是因为协作规则被固定成了可执行工作规程。 - ---- - -## 9. 后续项目推荐直接复用的默认规程 - -以后如要快速进入这种高自动化协作模式，建议默认使用下面这组规则： - -1. 默认 autonomy-first -2. 任务必须拆小 -3. 只在写完并检查后汇报 -4. 不允许任务空挂 -5. 同一阻塞不要重复两次 -6. 先做共享基础模块 -7. 文档够了就切到真实代码 -8. 做完一个自动进入下一个 - ---- - -## 10. 当前结论 - -本文件沉淀的最重要经验是： - -> 自动化协作真正有效，不靠“更积极一点”，而靠“把推进规则具体化、产物化、可验证化”。 - -以后只要沿用这份规程，AI 在复杂工程任务中的自动执行稳定性会明显更高。 \ No newline at end of file diff --git a/docs/workflow/AI_自动化协作迁移清单_v1.md b/docs/workflow/AI_自动化协作迁移清单_v1.md deleted file mode 100644 index 682d717..0000000 --- a/docs/workflow/AI_自动化协作迁移清单_v1.md +++ /dev/null @@ -1,239 +0,0 @@ -# AI 自动化协作迁移清单 v1 - -## 1. 文档目标 - -本文档用于把本次已经验证有效的 Claude Code 自动化协作方式迁移到另一台电脑或另一个项目里，尽量做到开箱即用。 - -目标： - -1. 明确哪些文件必须复制 -2. 明确这些文件要放到哪里 -3. 明确新项目第一次如何初始化 -4. 明确 memory 文件是否需要一起迁移 -5. 让跨电脑迁移成本最小化 - ---- - -## 2. 迁移的核心原则 - -这套自动化模式想稳定复现，不能只靠“口头告诉 AI 自动一点”。 - -必须至少把以下三层一起迁移： - -1. **项目规则层**：`CLAUDE.md` -2. **协作说明层**：自动化工作规程文档 -3. **偏好层**：关键 memory 文件 - -三层作用不同： - -- `CLAUDE.md`：负责在项目内直接生效 -- 工作规程文档：负责解释为什么这样做、怎么做 -- memory 文件：负责把偏好延续到后续会话 - ---- - -## 3. 必须复制的文件 - -## 3.1 首要文件：CLAUDE.md - -在目标项目根目录放置： - -- `CLAUDE.md` - -来源建议： - -- 直接使用 `标准_CLAUDE_md_模板_v1.md` 的内容 -- 复制后改名为 `CLAUDE.md` - -目标位置： - -```text -<目标项目根目录>/CLAUDE.md -``` - -这是最关键的一步。 - -如果只做一件事，就做这件事。 - ---- - -## 3.2 协作规程文档 - -建议一并复制： - -- `AI_协作自动化工作规程_v1.md` - -目标位置建议： - -```text -<目标项目根目录>/docs/AI_协作自动化工作规程_v1.md -``` - -作用： - -- 供你和 AI 随时参考 -- 当协作节奏漂移时，可以快速拉回到统一规程 - ---- - -## 3.3 迁移清单文档本身 - -建议也复制： - -- `AI_自动化协作迁移清单_v1.md` - -目标位置建议： - -```text -<目标项目根目录>/docs/AI_自动化协作迁移清单_v1.md -``` - -作用： - -- 以后再次迁移时直接复用 - ---- - -## 4. 建议复制的 memory 文件 - -不建议无脑复制整个 memory 文件夹。 - -建议只复制与“协作方式”强相关的文件。 - -### 推荐复制 - -- `feedback_autonomy_first_execution.md` -- `feedback_local_docs_preference.md` - -如果对方电脑也使用 Claude Code memory 机制，可以放到对方项目对应的 memory 目录。 - -如果你不清楚对方机器的 memory 路径，至少先保留这两份文件原文，后续再落到对应目录。 - ---- - -## 5. 不建议整包复制的内容 - -以下内容一般不建议整包搬运： - -1. 整个 memory 文件夹 -2. 当前项目专用业务文档 -3. 与当前项目强绑定的数据库/规则实现细节 -4. 临时任务状态文件 - -原因： - -- 可能把别的项目上下文污染过去 -- 会把不适合新项目的历史偏好一起带过去 - -原则： - -> 迁移协作方式，不等于迁移整个历史上下文。 - ---- - -## 6. 新电脑/新项目最小落地步骤 - -如果你要在另一台电脑上快速复现这套模式，最少做这 4 步： - -### Step 1 -在目标项目根目录创建： - -- `CLAUDE.md` - -内容使用： -- `标准_CLAUDE_md_模板_v1.md` - -### Step 2 -在目标项目下创建 `docs/` 目录，并放入： - -- `AI_协作自动化工作规程_v1.md` -- `AI_自动化协作迁移清单_v1.md` - -### Step 3 -如果支持 memory，补上： - -- `feedback_autonomy_first_execution.md` -- `feedback_local_docs_preference.md` - -### Step 4 -在第一次对话时明确一句： - -> 按 CLAUDE.md 和自动化工作规程执行，采用 autonomy-first、产物驱动、只在写完并检查后汇报的模式。 - -这句会帮助新会话快速收敛到正确模式。 - ---- - -## 7. 最稳妥的迁移方式 - -推荐你以后统一使用以下结构： - -```text -<目标项目>/ - CLAUDE.md - docs/ - AI_协作自动化工作规程_v1.md - AI_自动化协作迁移清单_v1.md -``` - -如果还要加 memory，则额外在 Claude Code 的项目 memory 目录里放： - -- `feedback_autonomy_first_execution.md` -- `feedback_local_docs_preference.md` - -这样就形成： - -- 项目内规则 -- 项目内说明 -- 会话级偏好 - -三层闭环。 - ---- - -## 8. 新项目第一次启动时推荐说法 - -你在新电脑的新项目里，第一次可以直接对 Claude Code 说： - -```text -请严格按项目里的 CLAUDE.md 和 docs/AI_协作自动化工作规程执行。 -默认采用 autonomy-first、产物驱动模式： -- 不要只汇报开始 -- 只有写完并本地检查后才汇报完成 -- 大任务拆小 -- 除非不可逆操作/缺资源/需要产品决策，否则不要停下等我分配 -- 做完一个直接接下一个 -``` - -这句话非常有效。 - ---- - -## 9. 如果只想迁移最核心的一样东西 - -如果你懒得搬太多，优先级如下： - -### 第一优先级 -- `CLAUDE.md` - -### 第二优先级 -- `AI_协作自动化工作规程_v1.md` - -### 第三优先级 -- 两个关键 memory 文件 - -也就是说： - -> 只传一份文档，不如先把 `CLAUDE.md` 真正放到项目根目录。 - ---- - -## 10. 当前结论 - -跨电脑复用这套自动化协作方式，最佳做法不是只传一份说明文档，而是： - -1. 把标准模板落成目标项目的 `CLAUDE.md` -2. 把自动化工作规程文档放进目标项目 `docs/` -3. 按需补关键 memory 偏好文件 - -这样你在新电脑上最容易复现本次这种“真正不空转、能持续产生产物”的自动化协作效果。 diff --git a/docs/workflow/CLAUDE_template_autonomy_first.md b/docs/workflow/CLAUDE_template_autonomy_first.md deleted file mode 100644 index 00e2205..0000000 --- a/docs/workflow/CLAUDE_template_autonomy_first.md +++ /dev/null @@ -1,225 +0,0 @@ -# CLAUDE.md Template - -Use this file as a starting `CLAUDE.md` for other repositories. Replace the placeholders and keep the execution rules unless the project needs stricter constraints. - ---- - -# CLAUDE.md - -This file provides guidance to Claude Code when working in this repository. - -## Project Overview - -- Project: `` -- Goal: `` -- Primary stack: `` -- Main quality gate: `` - -## Commands - -```bash -# Install dependencies - - -# Start dev mode - - -# Run tests - - -# Run typecheck - - -# Run lint / format - - -``` - -## Collaboration Mode - -Default to autonomy-first execution. - -After the task is clear: -- proactively plan -- implement directly -- test and verify -- continue to the next concrete task without routine confirmation - -Only stop and ask the user when you hit one of these: -1. an irreversible or high-blast-radius action -2. missing external credentials, services, or permissions -3. a real product decision with multiple valid directions -4. a blocker that cannot be resolved by reading code, running checks, or changing local files - -## Core Working Rules - -### 1. Prefer product over status -Do not treat `in_progress` as progress. -A task counts as progress only when there is a real artifact such as: -- edited code -- written docs -- created config -- migration file -- test result -- verification result - -Rule: -- no artifact, no completion report - -### 2. Break work into small executable tasks -For any non-trivial request, split the work into small tasks that each produce an inspectable result. - -Good task examples: -- add repository method for loading candles -- create migration for sweep events -- wire runner script for session generation -- verify new script imports cleanly - -Bad task examples: -- build the whole system -- finish the backend -- handle remaining work - -### 3. Finish one concrete step, then immediately start the next -After completing a task: -- mark it complete -- summarize the concrete result briefly -- start the next highest-value unblocked task - -Do not wait for permission between normal reversible steps. - -### 4. Do not repeat the same blocker twice -If the same blocker appears twice without any new artifact or validation progress, stop looping. -Immediately do one of: -- change the approach -- split the task smaller -- work on an adjacent unblocked dependency -- surface the true blocker clearly - -Rule: -- never stay in a stale loop - -### 5. Keep milestone updates short and factual -Progress updates should say: -- what was written or changed -- what was verified -- what is next - -Avoid empty updates like: -- "working on it" -- "starting now" -- "continuing" - -### 6. Parallelize only truly independent work -Use parallel work only when tasks do not share the same dependency chain. - -Good parallel cases: -- two unrelated docs -- independent read-only inspections -- separate file checks - -Bad parallel cases: -- multiple edits in the same file chain -- steps that depend on previous output -- intertwined refactors sharing context - -### 7. Prefer shared foundations before upper layers -When building systems, usually work in this order unless the user says otherwise: -1. config -2. database / schema -3. core models -4. repositories -5. services -6. entry scripts / APIs -7. downstream features - -This reduces rework. - -### 8. Switch from docs to implementation as soon as the design is sufficient -Once the spec is clear enough, stop expanding docs and write the real files. -Docs support implementation; they do not replace it. - -## Verification Rules - -Before reporting a task complete: -- confirm the target file exists -- read back the important file sections you changed -- run the narrowest relevant check first -- prefer direct runnable validation over purely descriptive claims - -Examples: -- compile the changed Python files -- run the changed script -- run a focused test file -- read the migration or config back after writing it - -If verification is blocked by environment issues, say so explicitly and separate: -- code is ready -- environment is not ready - -## Risk Rules - -Proceed without confirmation for local, reversible actions such as: -- reading files -- editing code -- creating normal source files -- running tests -- running local checks - -Pause for confirmation before: -- deleting files or branches -- force push / history rewrite -- destructive database operations -- modifying shared infrastructure -- posting to external services -- actions visible to other people - -If a safer reversible path exists, prefer it. - -## Communication Style - -- be concise -- lead with the result -- reference files with `path:line` when useful -- do not over-explain routine steps -- report at milestone boundaries, not after every tiny action - -## Task Workflow - -For substantial work: -1. create small tasks up front -2. set the current task to `in_progress` before starting -3. complete tasks immediately after finishing them -4. if a task grows too large, replace it with smaller tasks -5. keep progress moving; do not leave stale broad tasks hanging - -## Implementation Guardrails - -- do not add features beyond the request -- do not refactor unrelated code while fixing a local issue -- do not add abstractions for one-off use -- do not add speculative compatibility layers -- validate user input and external boundaries, but do not over-defend impossible internal states - -## Recommended Repository-Specific Section - -Add project-local facts below this line. - -### Architecture Notes -- `` -- `
` -- `` - -### Quality Gates -- `` -- `` - -### Project-Specific Constraints -- `` - ---- - -## Maintainer Notes - -This template is intentionally opinionated toward autonomy-first execution. -If you want stricter supervision, replace the Collaboration Mode and Core Working Rules sections with project-specific alternatives. diff --git a/docs/workflow/README.md b/docs/workflow/README.md deleted file mode 100644 index e33fdd9..0000000 --- a/docs/workflow/README.md +++ /dev/null @@ -1,7 +0,0 @@ -# Workflow Docs - -This directory contains generic Codex / Claude workflow helpers rather than AI ICT product requirements. - -Contents here are still useful for team workflow migration and prompt/template reuse, but they are not part of the current project development reading path. - -For project requirements and engineering plans, start from `docs/AI_ICT_文档索引与命名规范_v2.md`. diff --git a/docs/workflow/automation_workflow_migration_checklist.md b/docs/workflow/automation_workflow_migration_checklist.md deleted file mode 100644 index 6ae9c6d..0000000 --- a/docs/workflow/automation_workflow_migration_checklist.md +++ /dev/null @@ -1,182 +0,0 @@ -# Automation Workflow Migration Checklist - -Use this checklist to move the proven autonomy-first Claude workflow from one computer to another and bootstrap a fresh project quickly. - -## 1. Source files to copy - -Copy these files from the source machine or source repository: - -- `docs/CLAUDE_template_autonomy_first.md` - - reusable base template for project `CLAUDE.md` -- `docs/AI_协作自动化工作规程_v1.md` - - explanation of the working rules and why they were chosen -- `docs/标准_CLAUDE_md_模板_v1.md` - - optional extra local reference if you want a second comparison template - -If you already have a project-specific `CLAUDE.md` that worked well, copy that too. - -## 2. Target placement on the new computer - -### Required placement - -For each target project, place one active file at the project root: - -- `/CLAUDE.md` - -Recommended source for that file: -- start from `docs/CLAUDE_template_autonomy_first.md` -- customize it for the new repository -- save the final version as `/CLAUDE.md` - -### Optional reference placement - -Keep the reusable references in a local docs area, for example: - -- `/docs/CLAUDE_template_autonomy_first.md` -- `/docs/AI_协作自动化工作规程_v1.md` - -This is useful when you want both: -- one active root `CLAUDE.md` -- one reusable reference copy for later edits - -## 3. New machine prerequisite checklist - -Before using the workflow on the target machine, confirm: - -- [ ] Claude Code is installed and working -- [ ] the target repository can be opened locally -- [ ] the main language/runtime toolchain is installed -- [ ] the project package manager is installed -- [ ] the project test/typecheck/lint commands are known -- [ ] any required local services are available -- [ ] any needed credentials are already configured outside the repo - -Examples of local services: -- database -- Redis -- Docker services -- cloud CLI auth - -## 4. Initialize a new project with this workflow - -### Step 1. Create or copy the root file - -- [ ] copy `docs/CLAUDE_template_autonomy_first.md` -- [ ] create `/CLAUDE.md` -- [ ] paste the template into it - -### Step 2. Replace the placeholders - -In the new root `CLAUDE.md`, fill in: - -- [ ] project name -- [ ] one-paragraph project goal -- [ ] primary stack -- [ ] install command -- [ ] dev command -- [ ] test command -- [ ] typecheck command -- [ ] lint / format commands -- [ ] key architecture notes -- [ ] quality gates that must pass -- [ ] project-specific constraints - -### Step 3. Add project-local rules - -Add any rules that are specific to the new repository, for example: - -- [ ] strict typecheck must pass with zero errors -- [ ] database migrations must be additive only -- [ ] no mock database tests -- [ ] feature flags must gate new functionality -- [ ] do not change CI files without confirmation - -### Step 4. Keep the proven execution rules - -Unless the new project truly needs different behavior, keep these intact: - -- [ ] autonomy-first collaboration mode -- [ ] artifact over status -- [ ] small executable task breakdown -- [ ] continue after each completed task -- [ ] do not repeat the same blocker twice -- [ ] short factual milestone updates -- [ ] verify before reporting complete -- [ ] ask only for irreversible actions, missing resources, or product decisions - -## 5. First-run project bootstrap checklist - -After adding the new root `CLAUDE.md`, do this in the project: - -- [ ] open the repository in Claude Code -- [ ] ask Claude to read the root `CLAUDE.md` -- [ ] ask Claude to inspect the repository structure -- [ ] ask Claude to identify the real quality gates -- [ ] ask Claude to create small executable tasks for the first milestone -- [ ] verify the first change is small and reversible -- [ ] confirm Claude reports artifacts, not just status - -## 6. Quick validation checklist - -Use this to confirm the workflow migrated correctly: - -- [ ] Claude reads the root `CLAUDE.md` automatically -- [ ] Claude breaks non-trivial work into small tasks -- [ ] Claude edits files directly instead of lingering in planning -- [ ] Claude gives short milestone updates instead of repetitive status chatter -- [ ] Claude keeps moving without repeated confirmation on reversible steps -- [ ] Claude pauses only for real decision points or risky actions -- [ ] Claude verifies file existence or checks before claiming completion - -## 7. Minimal file set for a lightweight migration - -If you want the smallest useful transfer, only move these: - -- `docs/CLAUDE_template_autonomy_first.md` -- create `/CLAUDE.md` from it - -That is enough to reproduce the main behavior. - -## 8. Recommended file set for a full migration - -For a more complete transfer, move these: - -- `docs/CLAUDE_template_autonomy_first.md` -- `docs/AI_协作自动化工作规程_v1.md` -- current project’s final `CLAUDE.md` if it has proven repo-specific rules - -This gives you: -- the reusable template -- the rationale document -- one real working example - -## 9. Common migration mistakes - -Avoid these mistakes: - -- [ ] copying only the idea, but not the actual `CLAUDE.md` file -- [ ] placing the template in `docs/` but forgetting to create root `CLAUDE.md` -- [ ] leaving placeholder commands unfilled -- [ ] keeping broad vague tasks instead of small executable tasks -- [ ] accepting status reports without artifact checks -- [ ] letting the workflow stop after each small reversible step -- [ ] forgetting to document real project quality gates - -## 10. Recommended startup prompt for a new repo - -After placing the new root `CLAUDE.md`, a good initialization prompt is: - -```text -Read the root CLAUDE.md, inspect this repository, identify the real quality gates, then create a small autonomy-first task breakdown for the first milestone and start executing the first concrete reversible step. -``` - -## 11. Completion criteria - -The migration is complete when: - -- [ ] the new machine has Claude Code working -- [ ] the target project has a root `CLAUDE.md` -- [ ] the root file contains real project commands and constraints -- [ ] Claude follows artifact-driven execution in practice -- [ ] the first milestone is decomposed into small tasks -- [ ] the first real change is written and verified successfully diff --git a/docs/workflow/标准_CLAUDE_md_模板_v1.md b/docs/workflow/标准_CLAUDE_md_模板_v1.md deleted file mode 100644 index ccce9de..0000000 --- a/docs/workflow/标准_CLAUDE_md_模板_v1.md +++ /dev/null @@ -1,166 +0,0 @@ -# 可跨电脑复用的标准 CLAUDE.md 模板 - -> 用法：把下面内容复制为目标项目根目录下的 `CLAUDE.md`。 -> 作用：让 Claude Code 在新电脑/新项目里尽快进入高自动化、产物驱动、少打断的协作模式。 - ---- - -# CLAUDE.md - -This file defines the default collaboration protocol for Claude Code in this project. - -## Collaboration Mode - -Default to **autonomy-first execution**. - -Once requirements are clear: - -- do not stop after each small step to ask what to do next -- continue to the next highest-value concrete task automatically -- only stop for: - 1. irreversible/destructive actions - 2. missing external resources or credentials - 3. product decisions that genuinely require user input - 4. explicit user request to pause or stop - -## Core Execution Rules - -### 1. Artifact-driven progress - -Do not treat “started” as progress. -Progress only counts when there is a real artifact, such as: - -- a written file -- a code change -- a migration file -- a test result -- a verification result - -If no artifact was produced, do not present the task as meaningfully progressed. - -### 2. Report only after write + local check - -For document work, report completion only after: - -1. the file is actually written locally -2. the file is checked for existence -3. the file is read back locally to confirm it looks correct - -Avoid status updates like: - -- “I started it” -- “I’m working on it” -- “next I will…” - -unless the user specifically asked for live status. - -### 3. Break work into small executable tasks - -Do not keep large vague tasks open. -Break work into small tasks that each produce a concrete artifact. -Examples: - -- write schema doc -- create migration file -- add repository module -- add service module -- add runner script -- run a focused verification - -### 4. Do not let tasks hang - -If a task is marked in progress but no file/code/test/verification result is produced for a while, consider it hanging. -Immediately rescope it into smaller executable tasks and continue. - -### 5. Do not repeat the same blocker twice - -If the same blocker appears twice without new code, new verification, or new task progress: - -- stop repeating the blocker -- change tactics -- pick a neighboring concrete task -- or narrow the scope and keep moving - -### 6. Finish one concrete task, then immediately start the next - -When a task completes, do not wait for redispatch. -Continue automatically to the next highest-value concrete task unless a real blocker exists. - -### 7. Prefer foundation-first implementation order - -When building systems, prioritize: - -1. config -2. db -3. migrations -4. base models -5. ingestion/data pipelines -6. foundational domain logic -7. higher-level orchestration -8. execution/UI/reporting - -Do not jump too early to upper-layer features if foundational modules are still missing. - -### 8. Parallelize only truly independent work - -Use parallel work only when tasks are genuinely independent. -If tasks share the same files, same chain of dependencies, or same narrow context, do them sequentially. - -## Preferred Update Style - -Keep milestone updates short and concrete. -Good update format: - -- what was written -- what was checked -- what is the next concrete task already being executed - -Avoid long narrative explanations during active execution. - -## Document Handling Rules - -When the user asks for persistent references, save substantial outputs as local Markdown files in the project. -This includes: - -- architecture docs -- schema docs -- implementation plans -- rule specifications -- operational playbooks - -Do not leave important long-lived outputs only in chat if they should be reusable later. - -## Code Work Rules - -For implementation tasks: - -- prefer creating real files over only describing code -- when updating an existing file, read it first -- after writing code, do a local check before claiming completion -- when useful, add a minimal runnable script or entrypoint to make the work executable - -## Default Working Pattern - -Use this loop by default: - -1. identify the next concrete task -2. create/write the artifact -3. locally verify it -4. mark the task complete -5. immediately continue to the next concrete task - -## If the User Asks to Save Progress and Stop - -Before stopping: - -1. ensure current files are written -2. ensure any in-progress task is either completed or clearly reset -3. leave a resumable checkpoint in local files if appropriate -4. stop cleanly without leaving stale hanging task claims - ---- - -## Optional Project-Specific Section - -Below this line, project maintainers can add domain-specific rules, architecture notes, commands, or constraints. - diff --git a/migrations/020_create_training_case_engine_tables.sql b/migrations/020_create_training_case_engine_tables.sql index 812bc22..a9489d1 100644 --- a/migrations/020_create_training_case_engine_tables.sql +++ b/migrations/020_create_training_case_engine_tables.sql @@ -21,6 +21,24 @@ create table if not exists training_cases ( check (decision_ts <= end_ts) ); +alter table if exists training_cases add column if not exists instrument_id bigint; +alter table if exists training_cases add column if not exists timeframe text not null default '1m'; +alter table if exists training_cases add column if not exists case_type text not null default 'unknown'; +alter table if exists training_cases add column if not exists skill_tag text not null default 'general'; +alter table if exists training_cases add column if not exists chapter_ref text; +alter table if exists training_cases add column if not exists source_event_type text; +alter table if exists training_cases add column if not exists source_event_id bigint; +alter table if exists training_cases add column if not exists source_event_refs jsonb not null default '[]'::jsonb; +alter table if exists training_cases add column if not exists start_ts timestamptz not null default now(); +alter table if exists training_cases add column if not exists decision_ts timestamptz not null default now(); +alter table if exists training_cases add column if not exists end_ts timestamptz not null default now(); +alter table if exists training_cases add column if not exists difficulty text not null default 'medium'; +alter table if exists training_cases add column if not exists answer_key jsonb not null default '{}'::jsonb; +alter table if exists training_cases add column if not exists status text not null default 'draft'; +alter table if exists training_cases add column if not exists meta jsonb not null default '{}'::jsonb; +alter table if exists training_cases add column if not exists created_at timestamptz not null default now(); +alter table if exists training_cases add column if not exists updated_at timestamptz not null default now(); + create index if not exists idx_training_cases_instr_tf_decision_desc on training_cases (instrument_id, timeframe, decision_ts desc); @@ -45,6 +63,18 @@ create table if not exists training_case_tasks ( updated_at timestamptz not null default now() ); +alter table if exists training_case_tasks add column if not exists case_id bigint; +alter table if exists training_case_tasks add column if not exists task_type text not null default 'annotation'; +alter table if exists training_case_tasks add column if not exists skill_tag text not null default 'general'; +alter table if exists training_case_tasks add column if not exists prompt text not null default ''; +alter table if exists training_case_tasks add column if not exists required_annotation_types jsonb not null default '[]'::jsonb; +alter table if exists training_case_tasks add column if not exists max_score numeric(8,2) not null default 0; +alter table if exists training_case_tasks add column if not exists sort_order integer not null default 0; +alter table if exists training_case_tasks add column if not exists status text not null default 'active'; +alter table if exists training_case_tasks add column if not exists meta jsonb not null default '{}'::jsonb; +alter table if exists training_case_tasks add column if not exists created_at timestamptz not null default now(); +alter table if exists training_case_tasks add column if not exists updated_at timestamptz not null default now(); + create index if not exists idx_training_case_tasks_case_sort on training_case_tasks (case_id, sort_order, id); @@ -65,6 +95,17 @@ create table if not exists training_attempts ( updated_at timestamptz not null default now() ); +alter table if exists training_attempts add column if not exists case_id bigint; +alter table if exists training_attempts add column if not exists user_id text not null default 'local'; +alter table if exists training_attempts add column if not exists status text not null default 'started'; +alter table if exists training_attempts add column if not exists current_frame_index integer not null default 0; +alter table if exists training_attempts add column if not exists started_at timestamptz not null default now(); +alter table if exists training_attempts add column if not exists submitted_at timestamptz; +alter table if exists training_attempts add column if not exists total_score numeric(8,2); +alter table if exists training_attempts add column if not exists meta jsonb not null default '{}'::jsonb; +alter table if exists training_attempts add column if not exists created_at timestamptz not null default now(); +alter table if exists training_attempts add column if not exists updated_at timestamptz not null default now(); + create index if not exists idx_training_attempts_user_status_created_desc on training_attempts (user_id, status, created_at desc); @@ -82,6 +123,14 @@ create table if not exists training_annotations ( updated_at timestamptz not null default now() ); +alter table if exists training_annotations add column if not exists attempt_id bigint; +alter table if exists training_annotations add column if not exists task_id bigint; +alter table if exists training_annotations add column if not exists user_id text not null default 'local'; +alter table if exists training_annotations add column if not exists annotation_type text not null default 'note'; +alter table if exists training_annotations add column if not exists payload jsonb not null default '{}'::jsonb; +alter table if exists training_annotations add column if not exists created_at timestamptz not null default now(); +alter table if exists training_annotations add column if not exists updated_at timestamptz not null default now(); + create index if not exists idx_training_annotations_attempt_type_created on training_annotations (attempt_id, annotation_type, created_at); @@ -98,6 +147,16 @@ create table if not exists training_scores ( updated_at timestamptz not null default now() ); +alter table if exists training_scores add column if not exists attempt_id bigint; +alter table if exists training_scores add column if not exists task_id bigint; +alter table if exists training_scores add column if not exists user_id text not null default 'local'; +alter table if exists training_scores add column if not exists category text not null default 'general'; +alter table if exists training_scores add column if not exists score numeric(8,2) not null default 0; +alter table if exists training_scores add column if not exists max_score numeric(8,2) not null default 0; +alter table if exists training_scores add column if not exists feedback jsonb not null default '{}'::jsonb; +alter table if exists training_scores add column if not exists created_at timestamptz not null default now(); +alter table if exists training_scores add column if not exists updated_at timestamptz not null default now(); + create index if not exists idx_training_scores_attempt_category on training_scores (attempt_id, category); @@ -115,5 +174,15 @@ create table if not exists training_progress ( unique (user_id, skill_tag) ); +alter table if exists training_progress add column if not exists user_id text not null default 'local'; +alter table if exists training_progress add column if not exists skill_tag text not null default 'general'; +alter table if exists training_progress add column if not exists attempt_count integer not null default 0; +alter table if exists training_progress add column if not exists avg_score numeric(8,4); +alter table if exists training_progress add column if not exists last_attempt_at timestamptz; +alter table if exists training_progress add column if not exists weakness_tags jsonb not null default '[]'::jsonb; +alter table if exists training_progress add column if not exists meta jsonb not null default '{}'::jsonb; +alter table if exists training_progress add column if not exists created_at timestamptz not null default now(); +alter table if exists training_progress add column if not exists updated_at timestamptz not null default now(); + create index if not exists idx_training_progress_user_skill on training_progress (user_id, skill_tag); diff --git a/migrations/021_create_trading_plans.sql b/migrations/021_create_trading_plans.sql new file mode 100644 index 0000000..a1a1103 --- /dev/null +++ b/migrations/021_create_trading_plans.sql @@ -0,0 +1,27 @@ +create table if not exists trading_plans ( + id bigserial primary key, + instrument_id bigint not null references instruments(id), + plan_date date not null, + status text not null, + narrative text not null, + primary_draw jsonb not null default '{}'::jsonb, + secondary_draw jsonb not null default '{}'::jsonb, + bias text not null, + allowed_sessions jsonb not null default '[]'::jsonb, + invalidations jsonb not null default '[]'::jsonb, + no_trade_conditions jsonb not null default '[]'::jsonb, + inputs jsonb not null default '{}'::jsonb, + quality jsonb not null default '{}'::jsonb, + timeframe_set jsonb not null default '{}'::jsonb, + created_ts timestamptz not null, + activated_ts timestamptz, + created_at timestamptz not null default now(), + updated_at timestamptz not null default now(), + unique (instrument_id, plan_date) +); + +create index if not exists idx_trading_plans_instr_date_desc +on trading_plans (instrument_id, plan_date desc); + +create index if not exists idx_trading_plans_instr_status_date_desc +on trading_plans (instrument_id, status, plan_date desc); diff --git a/package.json b/package.json new file mode 100644 index 0000000..204305b --- /dev/null +++ b/package.json @@ -0,0 +1,10 @@ +{ + "name": "ai-ict", + "version": "0.1.0", + "private": true, + "scripts": { + "lint": ".\\.venv\\Scripts\\python.exe scripts/run_script_static_checks.py && .\\.venv\\Scripts\\python.exe scripts/run_migration_static_checks.py && .\\.venv\\Scripts\\python.exe -m unittest tests.unit.test_trading_plan_service", + "build": ".\\.venv\\Scripts\\python.exe -m compileall -q src scripts tests", + "visual:snapshots": "node --check src/web/app.js" + } +} diff --git a/scripts/run_autonomous_cycle.py b/scripts/run_autonomous_cycle.py index 458d8d2..2885a91 100644 --- a/scripts/run_autonomous_cycle.py +++ b/scripts/run_autonomous_cycle.py @@ -44,6 +44,7 @@ REQUIRED_PIPELINE_SCHEMA = { "structure_events": ("id", "instrument_id", "timeframe", "event_type", "direction", "broken_level", "reference_swing_id", "displacement_event_id", "accepted", "signal_relevant", "ts", "meta"), "fvg_zones": ("id", "instrument_id", "timeframe", "direction", "lower", "upper", "start_ts", "end_ts", "status", "fill_pct", "related_displacement_id", "meta"), "bias_snapshots": ("id", "instrument_id", "bias_tf", "setup_tf", "trigger_tf", "snapshot_ts", "daily_bias", "execution_intensity", "draw_side", "reason_codes", "meta"), + "trading_plans": ("id", "instrument_id", "plan_date", "status", "narrative", "primary_draw", "secondary_draw", "bias", "allowed_sessions", "invalidations", "no_trade_conditions", "inputs", "quality", "timeframe_set", "created_ts", "activated_ts"), "trade_signals": ("id", "instrument_id", "model_code", "side", "status", "bias_snapshot_id", "entry_type", "entry_low", "entry_high", "stop_loss", "tp1", "tp2", "rr_tp1", "rr_tp2", "created_ts", "expires_ts", "invalidations", "evidence", "meta"), "trade_executions": ("id", "signal_id", "execution_mode", "side", "entry_price", "stop_loss", "take_profit_1", "take_profit_2", "size", "risk_pct", "status", "opened_ts", "meta"), "backtest_runs": ("id", "model_code", "instrument_id", "timeframe_set", "started_ts", "config", "summary"), diff --git a/scripts/run_trading_plans.py b/scripts/run_trading_plans.py new file mode 100644 index 0000000..ffb8de6 --- /dev/null +++ b/scripts/run_trading_plans.py @@ -0,0 +1,114 @@ +from pathlib import Path +import json +import os +import sys + +from sqlalchemy.exc import SQLAlchemyError + +ROOT = Path(__file__).resolve().parents[1] +os.environ.setdefault("DATABASE_URL", "postgresql+psycopg://user:pass@localhost:5432/ai_ict_test") +if str(ROOT) not in sys.path: + sys.path.insert(0, str(ROOT)) + +from src.services.trading_plans import TradingPlanService + + +DEFAULT_TRADING_PLAN_SYMBOLS = ("BTC-USDT", "ETH-USDT") + + +def build_trading_plan_symbols_from_env(env=None) -> tuple[str, ...]: + env = os.environ if env is None else env + raw_value = str(env.get("TRADING_PLAN_SYMBOLS") or ",".join(DEFAULT_TRADING_PLAN_SYMBOLS)) + symbols = tuple(item.strip() for item in raw_value.split(",") if item.strip()) + return symbols or DEFAULT_TRADING_PLAN_SYMBOLS + + +def build_trading_plan_timeframe_set_from_env(env=None) -> dict: + env = os.environ if env is None else env + bias_tf = str(env.get("AI_ICT_BIAS_TIMEFRAME") or env.get("TRADING_PLAN_BIAS_TIMEFRAME") or "1m") + setup_tf = str(env.get("AI_ICT_SETUP_TIMEFRAME") or env.get("TRADING_PLAN_SETUP_TIMEFRAME") or bias_tf) + trigger_tf = str(env.get("AI_ICT_TRIGGER_TIMEFRAME") or env.get("TRADING_PLAN_TRIGGER_TIMEFRAME") or setup_tf) + return { + "bias_tf": bias_tf, + "setup_tf": setup_tf, + "trigger_tf": trigger_tf, + } + + +def main(env=None) -> int: + env = os.environ if env is None else env + output_json = _get_bool(env, "TRADING_PLANS_OUTPUT_JSON", False) + symbols = build_trading_plan_symbols_from_env(env=env) + timeframe_set = build_trading_plan_timeframe_set_from_env(env=env) + service = TradingPlanService() + plans = [] + + try: + for symbol in symbols: + instrument = service.repository.fetch_instrument_by_symbol(symbol) + if not instrument: + plans.append( + { + "symbol": symbol, + "passed": False, + "error": "instrument_not_found", + } + ) + continue + candidate = service.build_plan( + instrument_id=int(instrument["id"]), + bias_tf=timeframe_set["bias_tf"], + setup_tf=timeframe_set["setup_tf"], + trigger_tf=timeframe_set["trigger_tf"], + ) + plan_id = service.persist_plan(candidate) + plans.append( + { + "symbol": symbol, + "instrument_id": int(instrument["id"]), + "passed": True, + "plan_id": plan_id, + "status": candidate.status, + "bias": candidate.bias, + "has_draw": bool(candidate.primary_draw), + "has_invalidation": bool(candidate.invalidations), + "no_trade_conditions": candidate.no_trade_conditions, + } + ) + except SQLAlchemyError as exc: + payload = { + "passed": False, + "symbols": list(symbols), + "timeframe_set": timeframe_set, + "error_type": exc.__class__.__name__, + "error": str(exc), + } + if output_json: + print(json.dumps(payload, default=str, ensure_ascii=False, sort_keys=True)) + else: + print(f"Database unavailable for trading plan sample: {exc.__class__.__name__}") + return 2 + + payload = { + "passed": all(plan.get("passed") for plan in plans), + "symbols": list(symbols), + "timeframe_set": timeframe_set, + "plans": plans, + } + if output_json: + print(json.dumps(payload, default=str, ensure_ascii=False, sort_keys=True)) + else: + for plan in plans: + print(json.dumps(plan, default=str, ensure_ascii=False, sort_keys=True)) + return 0 if payload["passed"] else 2 + + +def _get_bool(env, key: str, default: bool) -> bool: + value = env.get(key) + if value is None or value == "": + return default + return str(value).strip().lower() in {"1", "true", "yes", "on"} + + +if __name__ == "__main__": + raise SystemExit(main()) diff --git a/src/api/__init__.py b/src/api/__init__.py index bd02423..f32d708 100644 --- a/src/api/__init__.py +++ b/src/api/__init__.py @@ -6,12 +6,14 @@ from src.api.health import get_health from src.api.server import route_request, serve_api from src.api.sessions import get_recent_sessions from src.api.signals import get_recent_signals +from src.api.trading_plans import get_recent_trading_plans __all__ = [ "get_health", "get_recent_candles", "get_recent_sessions", "get_recent_signals", + "get_recent_trading_plans", "get_recent_backtest_summaries", "route_request", "serve_api", diff --git a/src/api/server.py b/src/api/server.py index cb1cf79..fa9a29e 100644 --- a/src/api/server.py +++ b/src/api/server.py @@ -10,6 +10,7 @@ from src.api.candles import get_recent_candles from src.api.health import get_health from src.api.sessions import get_recent_sessions from src.api.signals import get_recent_signals +from src.api.trading_plans import get_recent_trading_plans from src.api.training import ( add_training_annotation, create_training_attempt, @@ -33,6 +34,7 @@ def build_api_dependencies() -> dict: "candles": get_recent_candles, "sessions": get_recent_sessions, "signals": get_recent_signals, + "trading_plans": get_recent_trading_plans, "backtests": get_recent_backtest_summaries, "executions": execution_service.build_execution_dashboard_items, "training_cases": get_training_cases, @@ -85,6 +87,10 @@ def route_request( instrument_id = _require_int(query, "instrument_id") limit = _get_int(query, "limit", 20) return 200, {"items": deps["signals"](instrument_id=instrument_id, limit=limit)} + if method == "GET" and path == "/trading-plans": + instrument_id = _require_int(query, "instrument_id") + limit = _get_int(query, "limit", 20) + return 200, {"items": deps["trading_plans"](instrument_id=instrument_id, limit=limit)} if method == "GET" and path == "/backtests": instrument_id = _get_optional_int(query, "instrument_id") limit = _get_int(query, "limit", 10) diff --git a/src/api/trading_plans.py b/src/api/trading_plans.py new file mode 100644 index 0000000..dd3f86d --- /dev/null +++ b/src/api/trading_plans.py @@ -0,0 +1,29 @@ +from sqlalchemy import text + +from src.db.session import SessionLocal + + +def get_recent_trading_plans(instrument_id: int, limit: int = 20) -> list[dict]: + sql = text( + """ + select id, instrument_id, plan_date, status, narrative, primary_draw, secondary_draw, + bias, allowed_sessions, invalidations, no_trade_conditions, inputs, quality, + timeframe_set, created_ts, activated_ts + from trading_plans + where instrument_id = :instrument_id + order by plan_date desc, created_ts desc + limit :limit + """ + ) + with SessionLocal() as session: + rows = session.execute(sql, {"instrument_id": instrument_id, "limit": limit}).mappings().all() + return [normalize_trading_plan_row(dict(row)) for row in rows] + + +def normalize_trading_plan_row(row: dict) -> dict: + payload = dict(row) + payload["draw"] = payload.get("primary_draw") or {} + payload["has_draw"] = bool(payload.get("primary_draw")) + payload["has_invalidation"] = bool(payload.get("invalidations")) + payload["active_eligible"] = payload.get("status") == "active" + return payload diff --git a/src/models/__init__.py b/src/models/__init__.py index f719871..fd48b6d 100644 --- a/src/models/__init__.py +++ b/src/models/__init__.py @@ -15,6 +15,7 @@ from src.models.sweep_event import SweepEvent from src.models.swing import Swing from src.models.trade_execution import TradeExecution from src.models.trade_signal import TradeSignal +from src.models.trading_plan import TradingPlan from src.models.training import ( TrainingAnnotation, TrainingAttempt, @@ -41,6 +42,7 @@ __all__ = [ "Swing", "TradeExecution", "TradeSignal", + "TradingPlan", "TrainingAnnotation", "TrainingAttempt", "TrainingCase", diff --git a/src/models/trading_plan.py b/src/models/trading_plan.py new file mode 100644 index 0000000..6f1b0ec --- /dev/null +++ b/src/models/trading_plan.py @@ -0,0 +1,27 @@ +from typing import Optional +from sqlalchemy import Date, ForeignKey, Text +from sqlalchemy.dialects.postgresql import JSONB +from sqlalchemy.orm import Mapped, mapped_column + +from src.db.base import Base + + +class TradingPlan(Base): + __tablename__ = "trading_plans" + + id: Mapped[int] = mapped_column(primary_key=True) + instrument_id: Mapped[int] = mapped_column(ForeignKey("instruments.id"), nullable=False) + plan_date: Mapped[object] = mapped_column(Date, nullable=False) + status: Mapped[str] = mapped_column(Text, nullable=False) + narrative: Mapped[str] = mapped_column(Text, nullable=False) + primary_draw: Mapped[dict] = mapped_column(JSONB, nullable=False, default=dict) + secondary_draw: Mapped[dict] = mapped_column(JSONB, nullable=False, default=dict) + bias: Mapped[str] = mapped_column(Text, nullable=False) + allowed_sessions: Mapped[list] = mapped_column(JSONB, nullable=False, default=list) + invalidations: Mapped[list] = mapped_column(JSONB, nullable=False, default=list) + no_trade_conditions: Mapped[list] = mapped_column(JSONB, nullable=False, default=list) + inputs: Mapped[dict] = mapped_column(JSONB, nullable=False, default=dict) + quality: Mapped[dict] = mapped_column(JSONB, nullable=False, default=dict) + timeframe_set: Mapped[dict] = mapped_column(JSONB, nullable=False, default=dict) + created_ts: Mapped[object] = mapped_column(nullable=False) + activated_ts: Mapped[Optional[object]] = mapped_column() diff --git a/src/repositories/__init__.py b/src/repositories/__init__.py index 3e1152f..d62c170 100644 --- a/src/repositories/__init__.py +++ b/src/repositories/__init__.py @@ -13,6 +13,7 @@ from src.repositories.signal_repository import SignalRepository from src.repositories.structure_repository import StructureRepository from src.repositories.swing_repository import SwingRepository from src.repositories.sweep_repository import SweepRepository +from src.repositories.trading_plan_repository import TradingPlanRepository from src.repositories.training_case_repository import TrainingCaseRepository __all__ = [ @@ -29,5 +30,6 @@ __all__ = [ "StructureRepository", "SwingRepository", "SweepRepository", + "TradingPlanRepository", "TrainingCaseRepository", ] diff --git a/src/repositories/trading_plan_repository.py b/src/repositories/trading_plan_repository.py new file mode 100644 index 0000000..6de5485 --- /dev/null +++ b/src/repositories/trading_plan_repository.py @@ -0,0 +1,222 @@ +import json +from typing import Optional + +from sqlalchemy import text + +from src.db.session import SessionLocal + + +class TradingPlanRepository: + def fetch_instrument_by_symbol(self, symbol: str) -> Optional[dict]: + sql = text( + """ + select id, symbol, active + from instruments + where symbol = :symbol + and active = true + limit 1 + """ + ) + with SessionLocal() as session: + row = session.execute(sql, {"symbol": symbol}).mappings().first() + return dict(row) if row else None + + def fetch_latest_range(self, instrument_id: int, timeframe: str) -> Optional[dict]: + sql = text( + """ + select id, high, low, equilibrium, state, ts_start, ts_end, meta + from dealing_ranges + where instrument_id = :instrument_id + and timeframe = :timeframe + and state = 'valid' + order by ts_start desc, id desc + limit 1 + """ + ) + with SessionLocal() as session: + row = session.execute(sql, {"instrument_id": instrument_id, "timeframe": timeframe}).mappings().first() + return dict(row) if row else None + + def fetch_recent_liquidity_pools(self, instrument_id: int, timeframe: str, limit: int = 20) -> list[dict]: + sql = text( + """ + select id, side, pool_type, price_low, price_high, status, created_ts, updated_ts, meta + from liquidity_pools + where instrument_id = :instrument_id + and timeframe = :timeframe + order by + case when status in ('untouched', 'active', 'open') then 0 else 1 end, + created_ts desc, + id desc + limit :limit + """ + ) + with SessionLocal() as session: + rows = session.execute( + sql, + {"instrument_id": instrument_id, "timeframe": timeframe, "limit": limit}, + ).mappings().all() + return [dict(row) for row in rows] + + def fetch_latest_mss(self, instrument_id: int, timeframe: str) -> Optional[dict]: + sql = text( + """ + select id, direction, broken_level, accepted, ts, displacement_event_id, meta + from structure_events + where instrument_id = :instrument_id + and timeframe = :timeframe + and event_type = 'MSS' + order by ts desc, id desc + limit 1 + """ + ) + with SessionLocal() as session: + row = session.execute(sql, {"instrument_id": instrument_id, "timeframe": timeframe}).mappings().first() + return dict(row) if row else None + + def fetch_recent_fvgs(self, instrument_id: int, timeframe: str, limit: int = 20) -> list[dict]: + sql = text( + """ + select id, direction, upper, lower, status, fill_pct, related_displacement_id, start_ts, end_ts, meta + from fvg_zones + where instrument_id = :instrument_id + and timeframe = :timeframe + order by end_ts desc, id desc + limit :limit + """ + ) + with SessionLocal() as session: + rows = session.execute( + sql, + {"instrument_id": instrument_id, "timeframe": timeframe, "limit": limit}, + ).mappings().all() + return [dict(row) for row in rows] + + def fetch_sessions_for_date(self, instrument_id: int, plan_date) -> list[dict]: + sql = text( + """ + select id, session_code, status, start_ts, end_ts, high, low, midpoint, meta + from market_sessions + where instrument_id = :instrument_id + and session_date = :plan_date + order by start_ts asc, id asc + """ + ) + with SessionLocal() as session: + rows = session.execute( + sql, + {"instrument_id": instrument_id, "plan_date": plan_date}, + ).mappings().all() + return [dict(row) for row in rows] + + def upsert_trading_plan( + self, + *, + instrument_id: int, + plan_date, + status: str, + narrative: str, + primary_draw: dict, + secondary_draw: dict, + bias: str, + allowed_sessions: list, + invalidations: list, + no_trade_conditions: list, + inputs: dict, + quality: dict, + timeframe_set: dict, + created_ts, + activated_ts, + ) -> int: + sql = text( + """ + insert into trading_plans ( + instrument_id, + plan_date, + status, + narrative, + primary_draw, + secondary_draw, + bias, + allowed_sessions, + invalidations, + no_trade_conditions, + inputs, + quality, + timeframe_set, + created_ts, + activated_ts + ) values ( + :instrument_id, + :plan_date, + :status, + :narrative, + cast(:primary_draw as jsonb), + cast(:secondary_draw as jsonb), + :bias, + cast(:allowed_sessions as jsonb), + cast(:invalidations as jsonb), + cast(:no_trade_conditions as jsonb), + cast(:inputs as jsonb), + cast(:quality as jsonb), + cast(:timeframe_set as jsonb), + :created_ts, + :activated_ts + ) + on conflict (instrument_id, plan_date) + do update set + status = excluded.status, + narrative = excluded.narrative, + primary_draw = excluded.primary_draw, + secondary_draw = excluded.secondary_draw, + bias = excluded.bias, + allowed_sessions = excluded.allowed_sessions, + invalidations = excluded.invalidations, + no_trade_conditions = excluded.no_trade_conditions, + inputs = excluded.inputs, + quality = excluded.quality, + timeframe_set = excluded.timeframe_set, + created_ts = excluded.created_ts, + activated_ts = excluded.activated_ts, + updated_at = now() + returning id + """ + ) + with SessionLocal.begin() as session: + result = session.execute( + sql, + { + "instrument_id": instrument_id, + "plan_date": plan_date, + "status": status, + "narrative": narrative, + "primary_draw": json.dumps(primary_draw), + "secondary_draw": json.dumps(secondary_draw), + "bias": bias, + "allowed_sessions": json.dumps(allowed_sessions), + "invalidations": json.dumps(invalidations), + "no_trade_conditions": json.dumps(no_trade_conditions), + "inputs": json.dumps(inputs), + "quality": json.dumps(quality), + "timeframe_set": json.dumps(timeframe_set), + "created_ts": created_ts, + "activated_ts": activated_ts, + }, + ) + return int(result.scalar_one()) + + def fetch_recent_trading_plans(self, instrument_id: int, limit: int = 20) -> list[dict]: + sql = text( + """ + select id, instrument_id, plan_date, status, narrative, primary_draw, secondary_draw, + bias, allowed_sessions, invalidations, no_trade_conditions, inputs, quality, + timeframe_set, created_ts, activated_ts + from trading_plans + where instrument_id = :instrument_id + order by plan_date desc, created_ts desc + limit :limit + """ + ) + with SessionLocal() as session: + rows = session.execute(sql, {"instrument_id": instrument_id, "limit": limit}).mappings().all() + return [dict(row) for row in rows] diff --git a/src/services/trading_plans/__init__.py b/src/services/trading_plans/__init__.py new file mode 100644 index 0000000..b684d48 --- /dev/null +++ b/src/services/trading_plans/__init__.py @@ -0,0 +1,19 @@ +"""Trading plan service package.""" + +from src.services.trading_plans.trading_plan_service import ( + ACTIVE_PLAN_STATUS, + DEFAULT_ALLOWED_EXECUTION_SESSIONS, + DRAFT_PLAN_STATUS, + TradingPlanCandidate, + TradingPlanService, + build_trading_plan_from_inputs, +) + +__all__ = [ + "ACTIVE_PLAN_STATUS", + "DEFAULT_ALLOWED_EXECUTION_SESSIONS", + "DRAFT_PLAN_STATUS", + "TradingPlanCandidate", + "TradingPlanService", + "build_trading_plan_from_inputs", +] diff --git a/src/services/trading_plans/trading_plan_service.py b/src/services/trading_plans/trading_plan_service.py new file mode 100644 index 0000000..3928049 --- /dev/null +++ b/src/services/trading_plans/trading_plan_service.py @@ -0,0 +1,391 @@ +from dataclasses import dataclass +from datetime import datetime, timezone +from typing import Optional + +from src.repositories.trading_plan_repository import TradingPlanRepository + + +ACTIVE_PLAN_STATUS = "active" +DRAFT_PLAN_STATUS = "draft" +DEFAULT_ALLOWED_EXECUTION_SESSIONS = ("LONDON", "NY_AM", "NY_PM") +ACTIVE_LIQUIDITY_STATUSES = {"untouched", "active", "open"} +ACTIVE_PLAN_BLOCKERS = { + "missing_primary_draw", + "missing_invalidation", + "missing_directional_bias", + "mss_not_accepted", +} + + +@dataclass(frozen=True) +class TradingPlanCandidate: + instrument_id: int + plan_date: object + status: str + narrative: str + primary_draw: dict + secondary_draw: dict + bias: str + allowed_sessions: list[str] + invalidations: list[dict] + no_trade_conditions: list[str] + inputs: dict + quality: dict + timeframe_set: dict + created_ts: object + activated_ts: Optional[object] + + def to_dict(self) -> dict: + return { + "instrument_id": self.instrument_id, + "plan_date": self.plan_date, + "status": self.status, + "narrative": self.narrative, + "primary_draw": self.primary_draw, + "secondary_draw": self.secondary_draw, + "bias": self.bias, + "allowed_sessions": self.allowed_sessions, + "invalidations": self.invalidations, + "no_trade_conditions": self.no_trade_conditions, + "inputs": self.inputs, + "quality": self.quality, + "timeframe_set": self.timeframe_set, + "created_ts": self.created_ts, + "activated_ts": self.activated_ts, + } + + +class TradingPlanService: + def __init__(self, repository: Optional[TradingPlanRepository] = None) -> None: + self.repository = repository or TradingPlanRepository() + + def build_plan( + self, + instrument_id: int, + bias_tf: str = "1m", + setup_tf: str = "1m", + trigger_tf: str = "1m", + plan_date=None, + ) -> TradingPlanCandidate: + created_ts = datetime.now(timezone.utc) + plan_date = plan_date or created_ts.date() + range_row = self.repository.fetch_latest_range(instrument_id=instrument_id, timeframe=bias_tf) + liquidity_pools = self.repository.fetch_recent_liquidity_pools( + instrument_id=instrument_id, + timeframe=setup_tf, + limit=20, + ) + mss = self.repository.fetch_latest_mss(instrument_id=instrument_id, timeframe=setup_tf) + fvgs = self.repository.fetch_recent_fvgs(instrument_id=instrument_id, timeframe=trigger_tf, limit=20) + sessions = self.repository.fetch_sessions_for_date(instrument_id=instrument_id, plan_date=plan_date) + + return build_trading_plan_from_inputs( + instrument_id=instrument_id, + plan_date=plan_date, + timeframe_set={"bias_tf": bias_tf, "setup_tf": setup_tf, "trigger_tf": trigger_tf}, + range_row=range_row, + liquidity_pools=liquidity_pools, + mss=mss, + fvgs=fvgs, + sessions=sessions, + created_ts=created_ts, + ) + + def persist_plan(self, candidate: TradingPlanCandidate) -> int: + return self.repository.upsert_trading_plan(**candidate.to_dict()) + + +def build_trading_plan_from_inputs( + *, + instrument_id: int, + plan_date, + timeframe_set: dict, + range_row: Optional[dict], + liquidity_pools: list[dict], + mss: Optional[dict], + fvgs: list[dict], + sessions: list[dict], + created_ts=None, +) -> TradingPlanCandidate: + created_ts = created_ts or datetime.now(timezone.utc) + bias = resolve_plan_bias(mss) + primary_side = resolve_primary_draw_side(bias=bias, liquidity_pools=liquidity_pools) + secondary_side = opposite_draw_side(primary_side) + primary_draw = build_draw_candidate(primary_side, range_row=range_row, liquidity_pools=liquidity_pools) + secondary_draw = build_draw_candidate(secondary_side, range_row=range_row, liquidity_pools=liquidity_pools) + invalidations = build_plan_invalidations(bias=bias, range_row=range_row, mss=mss, fvgs=fvgs) + allowed_sessions = resolve_allowed_sessions(sessions) + no_trade_conditions = build_no_trade_conditions( + bias=bias, + primary_draw=primary_draw, + invalidations=invalidations, + allowed_sessions=allowed_sessions, + mss=mss, + ) + status = ACTIVE_PLAN_STATUS if is_active_plan_eligible(no_trade_conditions) else DRAFT_PLAN_STATUS + activated_ts = created_ts if status == ACTIVE_PLAN_STATUS else None + inputs = build_plan_inputs( + range_row=range_row, + liquidity_pools=liquidity_pools, + mss=mss, + fvgs=fvgs, + sessions=sessions, + ) + quality = build_plan_quality( + status=status, + primary_draw=primary_draw, + invalidations=invalidations, + no_trade_conditions=no_trade_conditions, + inputs=inputs, + ) + narrative = build_plan_narrative( + bias=bias, + primary_draw=primary_draw, + secondary_draw=secondary_draw, + mss=mss, + range_row=range_row, + status=status, + ) + + return TradingPlanCandidate( + instrument_id=instrument_id, + plan_date=plan_date, + status=status, + narrative=narrative, + primary_draw=primary_draw, + secondary_draw=secondary_draw, + bias=bias, + allowed_sessions=allowed_sessions, + invalidations=invalidations, + no_trade_conditions=no_trade_conditions, + inputs=inputs, + quality=quality, + timeframe_set=dict(timeframe_set), + created_ts=created_ts, + activated_ts=activated_ts, + ) + + +def resolve_plan_bias(mss: Optional[dict]) -> str: + if not mss: + return "neutral" + direction = str(mss.get("direction") or "").strip().lower() + if direction == "bullish": + return "bullish" + if direction == "bearish": + return "bearish" + return "neutral" + + +def resolve_primary_draw_side(bias: str, liquidity_pools: list[dict]) -> Optional[str]: + if bias == "bullish": + return "buy_side" + if bias == "bearish": + return "sell_side" + for pool in liquidity_pools: + side = pool.get("side") + if side in {"buy_side", "sell_side"}: + return str(side) + return None + + +def opposite_draw_side(side: Optional[str]) -> Optional[str]: + if side == "buy_side": + return "sell_side" + if side == "sell_side": + return "buy_side" + return None + + +def build_draw_candidate(side: Optional[str], *, range_row: Optional[dict], liquidity_pools: list[dict]) -> dict: + if side not in {"buy_side", "sell_side"}: + return {} + for pool in liquidity_pools: + if pool.get("side") == side and str(pool.get("status") or "") in ACTIVE_LIQUIDITY_STATUSES: + return { + "side": side, + "source": "liquidity_pool", + "pool_id": pool.get("id"), + "pool_type": pool.get("pool_type"), + "price_low": _float_or_none(pool.get("price_low")), + "price_high": _float_or_none(pool.get("price_high")), + "status": pool.get("status"), + } + if not range_row: + return {} + if side == "buy_side": + price = _float_or_none(range_row.get("high")) + boundary = "range_high" + else: + price = _float_or_none(range_row.get("low")) + boundary = "range_low" + return { + "side": side, + "source": "dealing_range_boundary", + "range_id": range_row.get("id"), + "boundary": boundary, + "price_low": price, + "price_high": price, + } + + +def build_plan_invalidations(bias: str, range_row: Optional[dict], mss: Optional[dict], fvgs: list[dict]) -> list[dict]: + invalidations: list[dict] = [] + if mss: + invalidations.append( + { + "code": "mss_broken_level_reclaimed", + "source": "structure_event", + "mss_id": mss.get("id"), + "direction": mss.get("direction"), + "level": _float_or_none(mss.get("broken_level")), + } + ) + if range_row and bias in {"bullish", "bearish"}: + if bias == "bullish": + invalidations.append( + { + "code": "range_low_lost", + "source": "dealing_range", + "range_id": range_row.get("id"), + "level": _float_or_none(range_row.get("low")), + } + ) + else: + invalidations.append( + { + "code": "range_high_reclaimed", + "source": "dealing_range", + "range_id": range_row.get("id"), + "level": _float_or_none(range_row.get("high")), + } + ) + latest_fvg = fvgs[0] if fvgs else None + if latest_fvg: + invalidations.append( + { + "code": "fvg_invalidated_or_fully_mitigated", + "source": "fvg_zone", + "fvg_id": latest_fvg.get("id"), + "status": latest_fvg.get("status"), + } + ) + return dedupe_invalidations(invalidations) + + +def resolve_allowed_sessions(sessions: list[dict]) -> list[str]: + allowed = [] + for session in sessions: + code = str(session.get("session_code") or "") + if code in DEFAULT_ALLOWED_EXECUTION_SESSIONS and code not in allowed: + allowed.append(code) + return allowed or list(DEFAULT_ALLOWED_EXECUTION_SESSIONS) + + +def build_no_trade_conditions( + *, + bias: str, + primary_draw: dict, + invalidations: list[dict], + allowed_sessions: list[str], + mss: Optional[dict], +) -> list[str]: + conditions: list[str] = [] + if not primary_draw: + conditions.append("missing_primary_draw") + if not invalidations: + conditions.append("missing_invalidation") + if bias not in {"bullish", "bearish"}: + conditions.append("missing_directional_bias") + if not allowed_sessions: + conditions.append("missing_allowed_session") + if mss and mss.get("accepted") is not True: + conditions.append("mss_not_accepted") + return conditions + + +def is_active_plan_eligible(no_trade_conditions: list[str]) -> bool: + return not any(condition in ACTIVE_PLAN_BLOCKERS for condition in no_trade_conditions) + + +def build_plan_inputs( + *, + range_row: Optional[dict], + liquidity_pools: list[dict], + mss: Optional[dict], + fvgs: list[dict], + sessions: list[dict], +) -> dict: + return { + "range_id": range_row.get("id") if range_row else None, + "mss_id": mss.get("id") if mss else None, + "fvg_ids": [row.get("id") for row in fvgs], + "liquidity_pool_ids": [row.get("id") for row in liquidity_pools], + "session_ids": [row.get("id") for row in sessions], + "counts": { + "ranges": 1 if range_row else 0, + "liquidity_pools": len(liquidity_pools), + "fvgs": len(fvgs), + "sessions": len(sessions), + }, + } + + +def build_plan_quality( + *, + status: str, + primary_draw: dict, + invalidations: list[dict], + no_trade_conditions: list[str], + inputs: dict, +) -> dict: + reason_codes = [] + if primary_draw: + reason_codes.append("primary_draw_available") + if invalidations: + reason_codes.append("invalidation_available") + if inputs.get("mss_id"): + reason_codes.append("mss_available") + if inputs.get("range_id"): + reason_codes.append("active_range_available") + return { + "has_draw": bool(primary_draw), + "has_invalidation": bool(invalidations), + "active_eligible": status == ACTIVE_PLAN_STATUS, + "blockers": list(no_trade_conditions), + "reason_codes": reason_codes, + } + + +def build_plan_narrative( + *, + bias: str, + primary_draw: dict, + secondary_draw: dict, + mss: Optional[dict], + range_row: Optional[dict], + status: str, +) -> str: + draw_side = primary_draw.get("side") or "no_draw" + draw_source = primary_draw.get("source") or "missing" + mss_state = "accepted_mss" if mss and mss.get("accepted") is True else "no_accepted_mss" + range_state = "range_available" if range_row else "range_missing" + return f"{status}:{bias}:{draw_side}:{draw_source}:{mss_state}:{range_state}" + + +def dedupe_invalidations(invalidations: list[dict]) -> list[dict]: + seen = set() + result = [] + for item in invalidations: + key = (item.get("code"), item.get("source"), item.get("mss_id"), item.get("range_id"), item.get("fvg_id")) + if key in seen: + continue + seen.add(key) + result.append(item) + return result + + +def _float_or_none(value) -> Optional[float]: + if value is None: + return None + return float(value) diff --git a/tests/unit/test_trading_plan_service.py b/tests/unit/test_trading_plan_service.py new file mode 100644 index 0000000..31788ee --- /dev/null +++ b/tests/unit/test_trading_plan_service.py @@ -0,0 +1,250 @@ +from datetime import date, datetime, timezone +import os +import unittest + +os.environ.setdefault("DATABASE_URL", "postgresql+psycopg://user:pass@localhost:5432/ai_ict_test") + +from scripts import run_trading_plans +from src.services.trading_plans import ACTIVE_PLAN_STATUS, DRAFT_PLAN_STATUS, TradingPlanService +from src.services.trading_plans.trading_plan_service import build_trading_plan_from_inputs + + +class TradingPlanServiceTests(unittest.TestCase): + def test_builds_active_plan_when_draw_and_invalidation_exist(self) -> None: + plan = build_trading_plan_from_inputs( + instrument_id=1, + plan_date=date(2026, 5, 6), + timeframe_set={"bias_tf": "1h", "setup_tf": "15m", "trigger_tf": "5m"}, + range_row=_range_row(), + liquidity_pools=[ + _liquidity_pool(pool_id=21, side="buy_side"), + _liquidity_pool(pool_id=22, side="sell_side"), + ], + mss=_mss_row(direction="bullish", accepted=True), + fvgs=[_fvg_row()], + sessions=[_session_row("LONDON"), _session_row("NY_AM"), _session_row("ASIA")], + created_ts=_created_ts(), + ) + + self.assertEqual(plan.status, ACTIVE_PLAN_STATUS) + self.assertEqual(plan.bias, "bullish") + self.assertEqual(plan.primary_draw["side"], "buy_side") + self.assertEqual(plan.primary_draw["source"], "liquidity_pool") + self.assertEqual(plan.primary_draw["pool_id"], 21) + self.assertEqual(plan.allowed_sessions, ["LONDON", "NY_AM"]) + self.assertTrue(plan.invalidations) + self.assertEqual(plan.no_trade_conditions, []) + self.assertTrue(plan.quality["has_draw"]) + self.assertTrue(plan.quality["has_invalidation"]) + self.assertTrue(plan.quality["active_eligible"]) + self.assertIsNotNone(plan.activated_ts) + + def test_plan_without_draw_cannot_be_active_even_when_invalidation_exists(self) -> None: + plan = build_trading_plan_from_inputs( + instrument_id=1, + plan_date=date(2026, 5, 6), + timeframe_set={"bias_tf": "1h", "setup_tf": "15m", "trigger_tf": "5m"}, + range_row=None, + liquidity_pools=[], + mss=_mss_row(direction="bullish", accepted=True), + fvgs=[], + sessions=[], + created_ts=_created_ts(), + ) + + self.assertEqual(plan.status, DRAFT_PLAN_STATUS) + self.assertEqual(plan.primary_draw, {}) + self.assertTrue(plan.invalidations) + self.assertIn("missing_primary_draw", plan.no_trade_conditions) + self.assertFalse(plan.quality["active_eligible"]) + self.assertIsNone(plan.activated_ts) + + def test_plan_without_invalidation_cannot_be_active_even_when_draw_exists(self) -> None: + plan = build_trading_plan_from_inputs( + instrument_id=1, + plan_date=date(2026, 5, 6), + timeframe_set={"bias_tf": "1h", "setup_tf": "15m", "trigger_tf": "5m"}, + range_row=None, + liquidity_pools=[_liquidity_pool(pool_id=41, side="buy_side")], + mss=None, + fvgs=[], + sessions=[], + created_ts=_created_ts(), + ) + + self.assertEqual(plan.status, DRAFT_PLAN_STATUS) + self.assertEqual(plan.primary_draw["side"], "buy_side") + self.assertEqual(plan.invalidations, []) + self.assertIn("missing_invalidation", plan.no_trade_conditions) + self.assertIn("missing_directional_bias", plan.no_trade_conditions) + self.assertFalse(plan.quality["active_eligible"]) + + def test_mss_must_be_accepted_for_active_plan(self) -> None: + plan = build_trading_plan_from_inputs( + instrument_id=1, + plan_date=date(2026, 5, 6), + timeframe_set={"bias_tf": "1h", "setup_tf": "15m", "trigger_tf": "5m"}, + range_row=_range_row(), + liquidity_pools=[_liquidity_pool(pool_id=51, side="sell_side")], + mss=_mss_row(direction="bearish", accepted=False), + fvgs=[_fvg_row(direction="bearish")], + sessions=[], + created_ts=_created_ts(), + ) + + self.assertEqual(plan.status, DRAFT_PLAN_STATUS) + self.assertEqual(plan.bias, "bearish") + self.assertIn("mss_not_accepted", plan.no_trade_conditions) + + def test_default_btc_eth_symbols_can_generate_structured_daily_plans(self) -> None: + repository = _TradingPlanStubRepository() + service = TradingPlanService(repository=repository) + plans = [] + + for symbol in run_trading_plans.build_trading_plan_symbols_from_env({}): + instrument = repository.fetch_instrument_by_symbol(symbol) + self.assertIsNotNone(instrument) + assert instrument is not None + plans.append( + service.build_plan( + instrument_id=instrument["id"], + bias_tf="1h", + setup_tf="15m", + trigger_tf="5m", + plan_date=date(2026, 5, 6), + ) + ) + + self.assertEqual([plan.instrument_id for plan in plans], [1, 2]) + self.assertEqual([plan.status for plan in plans], [ACTIVE_PLAN_STATUS, ACTIVE_PLAN_STATUS]) + for plan in plans: + with self.subTest(instrument_id=plan.instrument_id): + self.assertTrue(plan.primary_draw) + self.assertTrue(plan.invalidations) + self.assertIn(plan.bias, {"bullish", "bearish"}) + + +class TradingPlanScriptConfigTests(unittest.TestCase): + def test_symbol_env_defaults_to_btc_eth(self) -> None: + self.assertEqual(run_trading_plans.build_trading_plan_symbols_from_env({}), ("BTC-USDT", "ETH-USDT")) + + def test_symbol_env_accepts_comma_separated_override(self) -> None: + self.assertEqual( + run_trading_plans.build_trading_plan_symbols_from_env({"TRADING_PLAN_SYMBOLS": " BTC-USDT , ETH-USDT "}), + ("BTC-USDT", "ETH-USDT"), + ) + + def test_timeframe_env_reads_overrides(self) -> None: + self.assertEqual( + run_trading_plans.build_trading_plan_timeframe_set_from_env( + { + "AI_ICT_BIAS_TIMEFRAME": "4h", + "AI_ICT_SETUP_TIMEFRAME": "1h", + "AI_ICT_TRIGGER_TIMEFRAME": "15m", + } + ), + {"bias_tf": "4h", "setup_tf": "1h", "trigger_tf": "15m"}, + ) + + +class _TradingPlanStubRepository: + def __init__(self) -> None: + self.instruments = { + "BTC-USDT": {"id": 1, "symbol": "BTC-USDT", "active": True}, + "ETH-USDT": {"id": 2, "symbol": "ETH-USDT", "active": True}, + } + + def fetch_instrument_by_symbol(self, symbol: str): + return self.instruments.get(symbol) + + def fetch_latest_range(self, instrument_id: int, timeframe: str): + if instrument_id == 1: + return _range_row(range_id=101, high=72000.0, low=70000.0) + return _range_row(range_id=201, high=3800.0, low=3600.0) + + def fetch_recent_liquidity_pools(self, instrument_id: int, timeframe: str, limit: int = 20): + if instrument_id == 1: + return [_liquidity_pool(pool_id=111, side="buy_side", price_low=71980.0, price_high=72020.0)] + return [_liquidity_pool(pool_id=211, side="sell_side", price_low=3590.0, price_high=3610.0)] + + def fetch_latest_mss(self, instrument_id: int, timeframe: str): + if instrument_id == 1: + return _mss_row(mss_id=121, direction="bullish", accepted=True, broken_level=71000.0) + return _mss_row(mss_id=221, direction="bearish", accepted=True, broken_level=3700.0) + + def fetch_recent_fvgs(self, instrument_id: int, timeframe: str, limit: int = 20): + if instrument_id == 1: + return [_fvg_row(fvg_id=131, direction="bullish")] + return [_fvg_row(fvg_id=231, direction="bearish")] + + def fetch_sessions_for_date(self, instrument_id: int, plan_date): + return [_session_row("LONDON"), _session_row("NY_AM")] + + def upsert_trading_plan(self, **kwargs): + return int(kwargs["instrument_id"]) + + +def _created_ts() -> datetime: + return datetime(2026, 5, 6, 0, 0, tzinfo=timezone.utc) + + +def _range_row(range_id: int = 10, high: float = 101.0, low: float = 99.0) -> dict: + return {"id": range_id, "high": high, "low": low, "equilibrium": (high + low) / 2, "state": "valid"} + + +def _liquidity_pool( + *, + pool_id: int, + side: str, + price_low: float = 100.8, + price_high: float = 101.2, + status: str = "untouched", +) -> dict: + return { + "id": pool_id, + "side": side, + "pool_type": "equal_highs" if side == "buy_side" else "equal_lows", + "price_low": price_low, + "price_high": price_high, + "status": status, + } + + +def _mss_row( + *, + mss_id: int = 30, + direction: str = "bullish", + accepted: bool = True, + broken_level: float = 100.0, +) -> dict: + return { + "id": mss_id, + "direction": direction, + "accepted": accepted, + "broken_level": broken_level, + "displacement_event_id": 7, + "meta": {"state": "accepted" if accepted else "rejected"}, + } + + +def _fvg_row(fvg_id: int = 40, direction: str = "bullish") -> dict: + return { + "id": fvg_id, + "direction": direction, + "lower": 100.0, + "upper": 100.2, + "status": "open", + "fill_pct": 0.0, + } + + +def _session_row(code: str) -> dict: + return { + "id": len(code), + "session_code": code, + "status": "planned", + } + + +if __name__ == "__main__": + unittest.main()