智能盯盘工作流
智能盯盘可以拆成盘前准备、盘中检查和盘后复核三个步骤。本文提供观察清单、数据时间、未知项和交接记录模板,说明 Bastix TAP 与信息雷达可承担的研究边界,适合想把盯盘变成可复核流程的用户;相关行情覆盖为 Beta,不承诺全市场实时、盘中预警或自动交易。
智能盯盘不应被理解成模型全天预测涨跌。更稳妥的做法,是把一天拆成三个用户可管理的研究步骤:盘前定义问题,盘中按既定问题检查,盘后回到原始证据复核。
Bastix 已公开确认 TAP 可用于持续的研究、观察和整理,也确认只读信息雷达按计划运行并展示结果。1 但“盘前三段任务自动交接”“统一盘中频率”“修改后如何恢复”“专用移动通知”等行为没有获批口径。因此,以下内容是中立工作流模板,由用户自行建立和验收,不是 Bastix 当前自动化流程的说明。
三个时段各自只解决一个问题
| 时段 | 核心问题 | 用户准备的输入 | 应留下的交付物 |
|---|---|---|---|
| 盘前 | 今天准备观察什么 | 上一日复核、观察对象、公告与资讯 | 今日清单、检查问题、已知未知项 |
| 盘中 | 既定问题能否回答 | 盘前清单、当前可用数据 | 原始值、数据时间、来源、无法判断项 |
| 盘后 | 实际发生了什么,证据是否完整 | 盘前清单、盘中记录、收盘后材料 | 完成项、缺失项、规则变化与下一步 |
三段可以由不同工具或人工步骤完成。关键不是“全部自动化”,而是任何结论都能回到盘前问题和当时可用的数据。
盘前:建立观察清单,不给买卖方向
盘前清单至少要回答:
- 目标市场和日期是否明确;
- 观察对象能否唯一识别;
- 已知公告与资讯来自哪里,发布时间是什么;
- 盘中准备检查哪个具体字段;
- 哪些问题因为数据或权限不足仍然未知。
可以使用下面的用户自建模板:
session_date: "实际日期"
market: "实际市场"
objects:
- "完整标的代码"
checks:
- check_id: C-01
question: "检查指定字段是否可得"
field: "字段名"
rule: "允许的时间窗口或判断条件"
known_unknowns:
- "尚未确认的市场、数据或来源问题"
source_refs:
- "公告或资讯原文"
owner: "真实责任人"这里的 check_id、owner 等字段属于用户工作台账,不代表 Bastix 当前生成相同结构。如果交易日、对象或数据权限无法确认,盘前交付物应写“待确认”,而不是假定可以继续。
盘中:只检查盘前定义的问题
盘中最常见的错误,是看到新消息后不断改写规则,最后无法知道某次结论使用了哪个版本。更可复核的做法是:
- 一次检查只引用一个盘前问题版本;
- 保存原始值、来源和数据截止时间;
- 把“条件不成立”与“因缺数无法判断”分开;
- 新传闻先进入来源核验,不直接变成自动判断条件;
- 修改问题后另存新版本,并重新执行受控检查。
用户可以在自己的记录中使用三类结果:
| 结果 | 含义 |
|---|---|
| 满足 | 数据完整,既定条件成立 |
| 未满足 | 数据完整,既定条件不成立 |
| 无法判断 | 数据缺失、陈旧、来源不可用、对象不清或步骤未完成 |
这些只是工作流分类,不是 Bastix 当前产品状态名。
盘后:按盘前清单逐项复核
盘后不能只写一段“今天表现如何”。应逐项核对:
| 盘后问题 | 应保存的证据 |
|---|---|
| 盘前计划了哪些检查 | 原始盘前清单和版本 |
| 哪些检查实际完成 | 对应的盘中记录或人工操作记录 |
| 哪些结果无法判断 | 缺失字段、来源或未执行原因 |
| 规则是否临时改变 | 旧版本、新版本、修改时间和理由 |
| 使用了哪些盘后材料 | 收盘数据、公告原文及各自时间 |
| 明天怎样处理 | 继续、修改、关闭或人工调查 |
没有盘中记录时,不能根据收盘价倒推“某时刻一定满足条件”。缺失时段应如实留空。
跨时段交接要固定哪些内容
无论用表格、笔记还是持续任务,至少保持以下六项不变:
- 交易日期与市场;
- 观察对象及其完整代码;
- 检查问题与版本;
- 数据来源和截止时间;
- 无法判断的原因;
- 下一步责任人。
如果只把自然语言结论传给下一时段,盘后无法判断是市场变化、规则变化还是数据变化。
失败时间线:用户应怎样留证
下面是验收示例,不是 Bastix 已发生的产品案例,也不说明当前产品会自动完成恢复。
| 时点 | 观察到的事件 | 用户应记录 | 不应写成 |
|---|---|---|---|
| 盘前 | 清单完成 | 对象、问题版本、来源与未知项 | “系统已准备完毕” |
| 盘中第一次检查 | 数据字段为空 | 数据时间、来源、缺失字段 | “条件未满足” |
| 人工复核 | 找到来源中断 | 影响范围和临时处理 | 沿用旧值称为当前数据 |
| 修改问题 | 改用新的允许窗口 | 旧版、新版和修改理由 | 后台已自动生效 |
| 再次检查 | 新版本得到完整数据 | 新的测试记录和证据 | 补造缺失期间的结果 |
| 盘后 | 汇总成功与未知 | 同时保留两类记录 | 只保留成功项 |
如果要验证 Bastix 对任务修改、停止、重新启动和失败恢复的具体行为,必须在同一版本执行真实测试并保存原始运行记录。没有这些证据,本页只提供方法,不作产品承诺。
信息雷达是来源层,不是个股结论层
Bastix 信息雷达可以按计划进行只读信息整理并向用户展示结果。2 用户可以把相关条目加入盘前待核对清单,但仍要回到原始公告或资讯,确认发布时间、来源和对象归属。
产业主题不自动等于某只股票,模型对“利好/利空”的判断也可能出错。雷达条目不应直接变成个股交易结论,更不能证明盘中规则已经命中。
通知与研究判断是两条链路
研究步骤完成,不代表通知已经发送;没有收到通知,也不代表研究条件未满足。验收时应分开保存:
判断链路:问题 → 数据 → 规则 → 结果 → 证据
通知链路:待发送内容 → 渠道 → 发送状态 → 设备接收Bastix 当前没有获批的专用盯盘通知渠道、冷却去重规则或送达 SLA。因此,本页不承诺“第一时间提醒”“永不漏报”。需要此类能力时,应在实际设备和实际套餐下测试现有提醒产品。
哪些情况应该停止当天流程
- 市场日期或观察对象无法确认;
- 数据来源、许可或时间口径不清;
- 关键字段缺失,却仍被要求给出确定判断;
- 规则在盘中改变,但旧版和新版没有分开保存;
- 盘后材料被用来补写盘中结论;
- 用户实际需要券商账户监控、下单或资金托管。
最后一类需求超出 Bastix 的内置能力。持续任务只用于研究、观察和整理;真实资金决定与交易记录应回到用户及正规交易渠道。
配置一条持续研究任务时,阅读股票监控工具中的任务定义和验收方法;比较已有到价与技术提醒产品时,阅读股票监控软件选型。准备好观察清单后,可进入工作台把盯盘步骤配置成一条可复核的持续研究任务。