观察池怎么建立与维护,先要纠正一处混用:它不等于客户端里的自选列表。自选列表存的是名字与顺序,它回答不了「这条记录为什么在里面、哪天进来的、什么条件下移出去」。缺少这几项,观察池用久了就会变成一张只进不出的清单,每次复查都要从头看一遍。
下面按「与自选列表的分工、入池规则、出池规则、容量与复查周期、记录字段、落地方式」六步讲,最后给一份可以直接抄的字段表。文中不涉及任何方向判断,也不针对具体品种。
一、观察池与自选列表不是一回事
自选列表是展示位,作用是把要找的东西放在同一个地方,方便打开。观察池是带规则的台账,作用是把「需要持续跟踪的对象」与「随时可能查阅的对象」分开,让每一次跟踪都有明确的进入理由与退出条件。
{ 两者回答的问题不同 }
自选列表 —— 它在哪,叫什么名字
观察池 —— 它为什么在这里,什么时候进来的,什么条件下出去
{ 前者是位置,后者是规则加记录 }
观察池怎么建立与维护并不要求一次做完。两份清单并存的阶段是常态:开始时可以把自选列表整体当作观察池的候选来源,逐条补上入池规则与进池日期,符合规则的留下,其余的清出去。这个过程按复查周期分批处理即可。
分开的理由是复查成本。没有规则的清单会持续膨胀,每次复查的时间被摊薄到每一条上,结果是每一条都只看一眼,看不出状态变化。有规则的清单把复查动作固定下来,逐条过规则,不符合的当即移出,清单规模因此能被控制住。
二、入池规则怎么写
观察池怎么建立与维护里最开始要落笔的就是入池规则,它要写成可判定的条件,不写成形容词。「走势偏强」「形态不错」这类描述无法判定,写进规则等于没写。可判定的写法有两类:一类基于指标读数,例如某个读数落在某个区间;一类基于数据事实,例如收盘价与某条均线的相对关系。
| 规则类型 | 可判定的写法 | 为什么可判定 |
|---|---|---|
| 读数区间 | 写清指标名、参数、区间上下限 | 任意一天都能算出读数并判断是否落在区间内 |
| 相对关系 | 写清两个量的比较方向与周期 | 比较对象明确,结果只有成立与不成立 |
| 数据事实 | 写清字段名与取值范围 | 字段本身带数值,可直接核对 |
规则里要连同参数一起写。同一个指标用不同参数算出来的读数落在不同的区间里,只写指标名不写参数,两个月之后复查时无法复现当时的判断。做法是把参数值直接写进规则条目,与记录里的口径版本字段对应得上。
三、出池规则比入池规则更重要
出池规则要覆盖三种情形:规则不再成立、到期复查没有通过、以及被更合适的对象替代。三种情形可以各写一条,逐条对应到具体的判断动作。
{ 三类出池原因 }
① 条件不成立 —— 入池时的那条规则已经不再满足
② 到期未通过 —— 到了复查日期,按同一套规则复核没有通过
③ 被替代 —— 同一类观察对象里,这一条已由另一条覆盖
{ 三类各写一条,复查时逐条过,移出动作就有依据 }
三类出池原因里,第一类需要每次复查都逐条核对,第二类只在到期的条目上判断,第三类在同类观察对象之间做取舍。三类混在一起逐条过,工作量会明显上去,做法是把复查动作按原因分开:先筛到期,再核对规则,最后处理同类取舍。
四、容量与复查周期
观察池怎么建立与维护里的容量上限与复查周期要一起定,因为两者共同决定每次复查的工作量。容量定得大、周期定得短,单次复查要处理的条目数量就上去了,实际执行时会先跳过一部分,规则随之失效。
| 容量上限 | 复查周期 | 取舍 |
|---|---|---|
| 偏小 | 偏短 | 每条都能被仔细核对,代价是入池门槛要抬高 |
| 偏小 | 偏长 | 单次工作量轻,状态变化可能被漏过 |
| 偏大 | 偏短 | 单次工作量重,执行时容易打折 |
复查周期的起点按各自的进池日期计算,还是统一到一个固定日期,两种做法有差别。各自计算的好处是每一条都有完整的观察期;统一日期的好处是一次处理完全部到期条目,不会被漏掉。选哪一种与容量上限一起定,定下来之后写进字段说明,不要中途更换。
周期与规则的性质有关。规则里含变化较快的读数时,周期要短一些才能捕捉到状态变化;规则基于较长周期的数据事实时,周期放长不会漏过什么。把不同性质的规则混在同一个周期里复核,会让快的部分来不及、慢的部分过密。
五、记录字段
| 字段 | 写什么 | 作用 |
|---|---|---|
| 进池日期 | 满足入池规则的那一天 | 计算已经跟踪了多久 |
| 入池规则 | 规则原文,含参数值 | 复查时按同一条复核 |
| 触发读数 | 进池当天该指标的读数 | 与后续读数对照 |
| 复查日期 | 下一次要复核的日期 | 到期能被发现 |
| 状态 | 在池、观察中、待出池 | 区分不同处理阶段 |
| 出池原因 | 三类出池原因里的哪一类 | 统计规则的实际有效率 |
状态字段容易被省略,但它解决了实际问题:有些条目已经不再满足入池规则,却因为还没到复查日期而留在池中。把它们标成待出池,复查时先把这一类处理掉,不必等逐条走完。出池原因字段则在积累一段时间之后能回答一个具体问题:哪一类规则给出的条目留存得久,哪一类进池之后很快就出池。
触发读数这一列的价值在跨月之后才显现。同一套规则在不同时期给出的读数水平不同,把进池当天的读数与复查当天的读数并排看,能判断这条规则是长期有效,还是只在一段时期里有效。
六、落地到客户端与表格
落地方式是把客户端与一份表格对应起来。客户端里用自定义板块承载名字,表格承载规则与记录,两处靠一套统一的命名对上。命名方式建议在名称前加一个可以排序的前缀,让客户端里的显示顺序与表格里的记录顺序一致,核对时不用逐个找。
{ 每周固定动作 }
① 打开表格,按复查日期筛出到期的条目
② 逐条按入池规则复核,通过则更新复查日期,不通过则按出池原因移出
③ 把这一周新满足规则的条目补进表格,同时在客户端自定义板块里加上名字
④ 核对两处的条目数量是否一致
{ 四步走完,两处对应关系不会漂移 }
两处条目数量不一致,来源是其中一处改过而另一处没跟上。删掉表格里的条目却忘了在客户端里移除,或者反过来,都会让两边的数量出现偏差。把数量核对作为固定动作的第四步,这类漂移会在下一次复查时被发现。
把上面的内容收一下:观察池怎么建立与维护的落点是规则与记录两件事——规则决定谁能进来,记录决定谁该出去。两者都立起来之后,清单规模才稳得住。
复盘流程里与观察池配合的字段设计可以参考 复盘方法与数据工具 一栏,规则落地到条件筛选的写法见 通达信选股公式与预警 一栏,指标读数的基础口径见 通达信新手入门问答 一栏。
文中规则与字段设计为管理流程建议;通达信不同版本与券商定制版对自定义板块的数量上限、同步方式与公式分组的管理方式存在差异,具体请以你所用客户端的实际界面为准。本文只讨论清单与记录的组织方式,不构成任何投资建议。
