什么是无代码自定义扫描器构建器？
自定义扫描器构建器是一种无需写代码的工具，可以把检测引擎、指标和环境筛选器组合成一个逻辑条件。你选择需要的组件，用 AND 或 OR 连接起来，平台就会扫描所有符合条件的市场，只有完全匹配你这条规则时才发出提醒。
它和固定扫描器的差别，在于控制权。普通扫描器直接塞给你某个作者对交易模型的定义；构建器则把基础组件交给你，让你自己拼出真正交易的那套条件。在 LiquidityScan 里，这个功能位于 Scanner Studio，而共享的 Confluence 目录，本质上就是一批面向所有用户发布的 Studio 扫描器。
为什么每个交易优势都需要它
能长期稳定交易的人，扫描的东西不会完全一样。有人等 1H 出现 Change of Character（CHoCH），再等价格在 London kill zone 内回测一个强 order block。另一个人要的是更高周期的 liquidity sweep 和收复，但只看真正有成交量的品种。这不是指标不同，而是对同一批组件做了不同的组合。
固定扫描器做不到这一点。它只会按照自己的单一模式触发，然后逼着你在几百张图上手动检查其余 confluence。从“某个模式出现了”到“我的完整交易模型成立”，中间正是自定义扫描器构建器能发挥作用的地方：它编码的是整张检查清单，而不是其中一行。
你不在电脑前时，这一点尤其重要。一个“1H CHoCH”的固定提醒，可能让手机响上几十次，但其中几乎没有一个是你的交易，因为你的交易还需要回测、时段和成交量。
把这些条件全部编码进去后，你最终收到的提醒已经经过预筛选。你为提醒付出的边际成本，会更接近这套交易模型本身的价值，而不是又一张必须从头检查的图表。
- 具体性：你的优势通常是 3—5 个条件叠加，不是单独一个条件。
- 覆盖面：一条规则可以同时扫描整个市场，人眼做不到。
- 纪律：写死的规则每次都以同样方式触发，减少主观扫描中最容易毁掉结果的愿望式找形态。
- 与回测对齐：只要规则写出来，你就能认真推敲和迭代，而不是停留在“我看到就知道”的模糊判断上。
一条规则里可以组合什么
无代码构建器的力量，来自它能把多少组件交给你使用。在 Scanner Studio 里，一条规则可以从 3 类组件中取条件，再用布尔逻辑把它们接起来。
检测引擎负责提供模式条件：Super Engulfing、OB+／OB++ 强 order block、市场结构（BOS／CHoCH）、Liquidity Sweep 反转、Pulse 的 RSI confluence 筛选器、Core Layer 对齐，以及扫描器中的其他引擎。每个引擎都是一个勾选条件，不需要写脚本。
指标负责添加经典技术门槛：RSI、EMA、SMA、成交量、ATR 和涨跌幅。你可以用它们来筛选某个引擎条件，例如只有当看涨模式触发且 RSI 低于指定阈值时，规则才算通过。
环境筛选器限制规则在哪里、什么时候可以触发：ICT kill zone、交易时段、资产类别（加密资产还是传统金融资产）、24 小时成交量下限，以及星期几。这些筛选器本身不负责检测模式；它们决定哪些候选结果能够留下来。
3 类组件的分工清楚，规则才容易读懂。引擎回答“发生了什么”，指标回答“在什么技术条件下发生”，环境筛选器回答“在哪里、什么时候才算数”。一条同时借用 3 类条件的规则，更接近真实交易模型；只靠引擎堆出来的规则，往往只是描述一个到处都会出现的形态。
| 构建组件 | 在规则中的作用 | 示例 |
|---|---|---|
| 检测引擎 | 必须出现的模式条件 | OB+、CHoCH、Liquidity Sweep、Super Engulfing |
| 指标 | 筛选或限制某个条件 | RSI、EMA、SMA、成交量、ATR、涨跌幅 |
| 环境筛选器 | 限制触发的地点和时间 | kill zone、交易时段、资产类别、成交量下限、星期几 |
如何一步步构建自定义扫描规则
在自定义扫描器构建器里写规则，就是连续做出几次选择，每一步都会缩小符合条件的范围。下面这个顺序，能让扫描逻辑保持清楚。
1．选择引擎条件和连接方式
先从定义交易模型的模式开始。假设你的模型是：结构翻转后，价格回测 order block 才有意义。那就选择 OB+ 和市场结构 CHoCH，并用 AND 连接。这样一个品种必须同时满足两者，才会匹配。只有当多个模式中的任意一个都可以作为候选条件时，才用 OR。
2．添加环境筛选器
先把扫描范围收紧。加入 kill zone 筛选器，让规则只在 London 时段触发；再设置 24 小时成交量下限，比如只保留成交量超过 2000 万美元的品种，把流动性不足的交易对挡在外面。交易时段、资产类别和星期几的设置也是同样的逻辑。
3．为每个引擎选择事件模式或当前成立模式
每个引擎条件都有两种读取方式。事件模式表示该模式必须刚刚在最新一根已收盘 K 线上触发，是一个新鲜信号。当前成立模式表示条件现在仍然成立，不管它是什么时候出现，是一个持续状态。CHoCH 通常适合事件模式；当前有效的方向偏置或尚未被 mitigation 的区域，通常适合当前成立模式。
3a．添加更高周期包装器
你可以把任意一个条件包装起来，让它在比规则其他部分更高的周期上进行判断。这样就能把自上而下的逻辑放进一条扫描规则：用 4H 方向偏置包装 1H 入场条件，意味着只有高周期方向一致，规则才会在入场模式上触发。
4．强制方向一致
打开方向一致性约束，让每个条件都必须指向同一方向。否则，看涨 CHoCH 可能和看跌 order block 同时匹配，最后只会制造噪音。开启之后，只有整组条件都看涨或整组条件都看跌时，规则才会触发，这才是实际交易里有意义的 confluence。
Sequence 规则：按顺序执行的交易剧本
大多数扫描器，不管是不是自定义的，只会检查多个条件是否同时出现。真正拉开差距的，是严肃构建器里的sequence规则：每个条件必须按指定顺序触发，而且前一步必须先收盘。
拿经典反转逻辑来说：CHoCH先提示结构翻转，然后你才等待新方向上的 order block 形成并被回测。单纯的同时出现逻辑表达不了“然后”。但 sequence 规则可以：第 1 个条件是 CHoCH，第 2 个条件是 OB+ 回测，只有当回测发生在 CHoCH 之后，这个品种才算匹配。
这才贴近 ICT 交易剧本的真实写法。先扫流动性，再发生结构转移，最后等待入场。先有方向偏置，再出现 displacement，最后回撤。按顺序排列的规则，可以把多步骤交易剧本变成一条可扫描的条件，而一堆互相独立的提醒做不到，因为它们根本没有顺序记忆。
顺序还会砍掉同时出现逻辑悄悄放过的假阳性。在一段震荡区间里，某个品种可能在同一根 K 线上几乎同时打印看涨 order block 和看跌结构读数，而同时出现规则仍然可能把它判为匹配。
要求结构翻转先发生、回测后发生的 sequence 规则，则会直接拒绝这种混乱，因为两个条件没有按照交易剧本要求的顺序排列。结果是匹配集合更小、更干净，也更能反映价格的真实推进过程，而不是一次巧合重叠。
一个完整示例，以及扫描器不会做什么
假设你交易流动性较高的加密资产，专做 London 时段反转。你可以在构建器里写出这样的规则：
- 条件 1（sequence，第 1 步）：1H 市场结构 CHoCH，事件模式，看涨。
- 条件 2（sequence，第 2 步）：1H OB+ 回测，当前成立模式，必须在条件 1 之后触发。
- 高周期包装器：要求 4H 方向偏置看涨，让结构翻转与高周期方向一致。
- 环境条件：仅限 London kill zone；24 小时成交量高于 2000 万美元；资产类别为加密资产。
- 方向一致：开启，所有条件都必须看涨。
保存之后，这条扫描规则会每小时基于已收盘 K 线扫描整个市场。当某个品种满足完整的有序规则时，平台会立即推送匹配结果，提醒可以通过网页或原生推送发送，也会显示在应用内。你从提醒里判断候选结果，不需要打开 300 张图去找。
但要分清楚它是什么，也要分清楚它不是什么。构建器只负责找出符合你自己规则的候选结果。它不会预测这笔交易能否成功，不会公布胜率，也不会替你下单。匹配结果只说明“我的条件出现了”，没有更多含义。
结果质量完全受你写下的规则质量限制。模糊规则只会筛出模糊候选，任何引擎都修不好一个定义不清的交易优势。
Scanner Studio 目前也仍然是面向管理员的功能界面，而它发布的结果会通过共享 Confluence 目录提供给所有人。说白了，DIY 构建器本身还没有对每个账户开放，但它生成的交易模型已经在运行。
每一条 Confluence 条目，包括按顺序执行的交易剧本，都是一条面向全局发布的 Studio 扫描器。所以现在最准确的说法是：你可以通过目录使用构建器产出的结果，而自助版本会是这个功能自然的下一步。
会毁掉自定义扫描规则的错误
大多数无效扫描都来自 2 种错误，而且根源都是把构建器给你的自由用错了。
筛选过度，最后什么都没有。你每增加一个 AND 条件，匹配集合就会缩小一截。堆上 6 个引擎、3 个指标、一个 kill zone，再加星期几筛选器，完全可能写出一条今年都没有触发过的规则。如果扫描连续几天返回 0 个结果，就删掉最不重要的条件，再放宽一个阈值。一条从不触发的规则，什么也教不了你。
伪 confluence。所有条件都在测同一件事，那不叫 confluence，只是把重复包装成严谨。一个看涨动量引擎已经要求强势收盘，你又加一个 RSI 超卖门槛，本质上只是把同一个信号算了 2 次。真正的 confluence 叠加的是相互独立的读数：结构、区域、时间窗口。方向一致和高周期包装器能带来真正的独立性；3 个动量条件不能。
- 引擎条件先收窄，阈值先放宽；看到匹配率之后，再逐步收紧。
- 与其堆 5 个弱环境筛选器，不如优先使用一个强筛选器，比如 kill zone 或成交量下限。
- 用 sequence 顺序增加严谨度，不要不断堆叠同时出现的条件。
常见问题
构建自定义扫描器需要会写代码吗？
不需要。无代码构建器会把引擎、指标和筛选器做成勾选框和下拉选项，再用 AND 或 OR 逻辑连接起来。你通过可视化界面组合规则并保存，不需要学习任何脚本语言；这正是自定义扫描器构建器和自己编写检测代码的区别。
自定义扫描规则多久运行一次？
在 LiquidityScan 中，Scanner Studio 每小时对保存的规则进行全市场扫描，而且始终基于已确认收盘的 K 线，因此结果不会重绘。当某个品种满足你的规则时，你会收到网页或原生推送，以及应用内通知，不需要自己盯着信息流。
事件模式和当前成立模式有什么区别？
事件模式要求模式刚刚在最新一根已收盘 K 线上触发，是一个新鲜信号。当前成立模式要求条件此刻仍然成立，不管它是什么时候出现，是一个持续状态。结构突破通常属于事件；当前有效的方向偏置或尚未被 mitigation 的区域，通常属于当前成立条件。
自定义扫描器能告诉我什么时候买入或卖出吗？
不能。它只会找出符合你定义条件的候选结果，不会发布交易指令，不保证结果，也不会计算胜率。大多数引擎输出的是模式或区域，而不是入场、止损和目标位。把每个匹配结果当作你进一步分析的筛选起点，不要把它当成可以直接执行的信号。
相关内容路径
你可以从构建器继续往外看：了解它调用的引擎，以及它适合放进什么样的交易流程。
- LiquidityScan 扫描器如何工作——了解你的规则所运行的原始 K 线到交易模型检测流程。
- order block 扫描器：实时检测 OB 和 FVG——解释可以放进自定义规则的引擎条件。
- ICT 自上而下分析：多周期对齐——了解你为每个条件添加高周期包装器时所用的逻辑。
- 如何找到你的 ICT 交易优势：专业化框架——在开始构建之前，先定义值得编码的条件集合。
- 一步步构建完整的 ICT 交易模型——把可扫描规则变成完整的入场、止损和管理计划。
- 最佳 ICT 扫描器：如何选择——了解自定义构建器与固定扫描器之间的定位差异。
- Scanner、Pulse 和 Core Layer：LiquidityScan 的 3 个功能界面——从另一个角度了解扫描器、Pulse 和 Core Layer。
- ICT 交易提醒：设置形成即刻收到通知 — 构建扫描器后，设置提醒即可在形态形成时及时获知