zlt
|
bccc2e5970
|
计划接口按请求实时补个股深度评析：评析什么时候跑完都算数
用户问：今天要计划的股票理论上应该优先做买方评析，为什么没有。查下来是三层
原因叠在一起，前一层今天已经解掉，这里解掉后两层。
第一层（今天已解）。评析原先每天凌晨 00:45 跑一批二十家，而当天的计划要
07:10 才出，所以它读到的永远是前一天的名单。今天改成全天每小时一批之后，
07:10 之后的批次能读到当天名单了。
第二层。计划一天只装配一次。07:10 出计划时读一次评析库，之后新产出的报告
再也进不了那份快照。
第三层。计划接口带十二小时缓存（今天早上为修页面超时从十分钟改上去的），
于是连「重新装配一次」这条路也堵上了 —— 原先十分钟过期重算，新报告十分钟内
能进；现在要等十二小时。这一层是今天早上那笔改动的副作用。
实测证据。今天早上七点十分那份计划里 154 行只有 7 只带评析。中午十二点二十三
到三十五分之间新跑出五份报告，而这五只（688556.SH 名单第 2、605598.SH 第 7、
300118.SZ 第 8、688698.SH 第 11、300638.SZ 第 13）正是持仓管理系统当天出提议的
票 —— 它当天一份都看不到，卡片上写的全是「数据基座还没出这家的报告」。
为什么不靠排期解决。查过两天名单的重合度：09-08 与 09-09 只重合 66 只 = 55%，
前 40 名里只有 46% 重合，每天有 54 只是新进名单的。也就是说「凌晨提前跑前一天
的名单」最多覆盖一半，剩下一半当天无论如何都赶不上 —— 名单本身就是计划的产物，
不出计划就不知道要跑谁。
修法。在 /plan 返回时实时补一次，与 regime、market 两个键同一个路子：按请求补、
不进缓存。这样评析什么时候跑完都行，跑完下一次请求就带上；计划缓存多久、走快照
还是现算，都不再影响它。代价是每次请求多一条批量数据库查询。
最要小心的是浅拷贝：get_plan 里的 dict(data) 只拷了顶层，main / observe 里的行
对象与缓存里那一份是同一批，不先拷贝就改等于把当次请求的结果写进缓存、污染全天。
新增的 test_plan_reviews_live.py 六组用例里，第二组专门钉这一条。
访问日志加了「评析补 N 只」，事后能核对。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-10 13:17:22 +08:00 |
|
zlt
|
abd7fec110
|
计划接口改读当日全量快照，不再每次现场装配（台账 057）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-10 09:23:41 +08:00 |
|
zlt
|
47369d3e58
|
选股计划缓存：存活时间盖住整个交易日，同键只算一次（09-10 页面超时修复）
09-10 开盘前页面报「上游的选股计划读不到 · timeout of 60000ms exceeded」。根因两半：
一、缓存只活 10 分钟。PMS 在 08:40 预热了一次（那次花 39 秒），08:50 就过期；用户
09:02 打开页面正好撞上冷启动。改成 12 小时——缓存键里带的是真实数据日，上游换日
后旧那份立刻失效，本来就不靠时间保新鲜；12 小时是为了让 08:40 那次预热管到收盘。
二、装配在锁外面，几路并发各跑一遍。页面一次加载拉多路，全部判未命中、各自跑一趟
三十多秒的装配、还互相抢同一批库连接，实际耗时远超单跑一次——这才是破 60 秒的
那一半。改成同键单飞：第一个去算，后到的等它算完直接吃缓存；不同参数组合互不阻塞。
新增 test_plan_cache.py 钉住四件事：换日立刻失效、同键只算一次、不同参数不互相阻塞、
存活时间盖得住交易日。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-10 09:09:40 +08:00 |
|
zlt
|
12a2ab159d
|
实时计划接口加当日缓存：装配要三四十秒，PMS 页面一次加载拉几路就超时；键带真实数据日，默认十分钟，nocache=1 强制重算，重新生成计划时清空
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-09 13:43:22 +08:00 |
|
zlt
|
296fc96909
|
公司质地接入：公司深度取数、逻辑状态第五路、判决收敛只降不升、卡与计划两键、候选单表列、复盘分组、逐票接口回两键、单测（台账 053）
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
2026-09-09 12:05:03 +08:00 |
|
zlt
|
ab09154594
|
接口 /logic_state 随状态回安全边际三情景（持仓页参考目标价用；算失败不拖垮状态查询）
|
2026-09-07 16:35:29 +08:00 |
|
zlt
|
faede9ab68
|
第三件桥侧前置：逐票日频逻辑状态表（抗抖动）与按代码查询接口
新模块 logic_state_daily.py：每个数据日为档位表里的每只票记一行原始态与落定态，
落定走 logic_state.settle（进入存疑即刻成立、退出要连续三天、其余迁移要连续两天），
只在 plan.generate 里写、/plan 实时重算只读；同日重跑幂等。
plan.py：四路取数抽成 _logic_inputs（计划装配与接口现算共用一处）；卡上的 state 改为
落定态，另发 raw_state、settle_note、prev_state；新增 logic_states_for 给接口现算。
api.py：GET /logic_state?codes=…，优先回当日表行（source=daily），不在表里的按此刻
现算并按历史落定（source=computed）。config 加表名与三个天数。
单测：新建 test_logic_state_daily.py（落定口径、读不到不断产、幂等落库、往返形状），
test_plan_logic_state.py 加落定态发出两例；十个测试文件在 155 容器隔离副本全绿。
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
2026-09-07 14:21:42 +08:00 |
|
zlt
|
8978b9dfe5
|
选股系统接通分析结论：候选卡读因果论断作证据线、关注判决细化为系统无法判断、计划环境段加市场四项、入池上下文补证据字段、复盘加四份名单与三套对照台账对表两节
判决定义按台账 013：关注只保留三门槛全过无硬风险但确认线缺失或陈旧；只差覆盖与潜在吸筹归仅展示。人工裁决说明同步修订。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-03 11:44:16 +08:00 |
|
zlt
|
f09b087228
|
候选卡上线第一批：计划装配联入判决与证据线、当日 JSON 快照带版本戳、候选单与关注环节两节；接口顶层加 generated_at/plan_version/regime/snapshot 与访问日志（主榜观察档装配排序裁剪不动）；取数层 sources.py；环境标签 regime.py 只展示分组；调度加 regime-append 步骤；入池加来源标记、切片与候选优先开关（默认关）；方案文档同步
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
2026-09-02 16:39:52 +08:00 |
|
zlt
|
386f28e8e5
|
判决接口：单票数据异常不崩整批，与代码形态错误的兜错对称
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2026-09-02 11:48:26 +08:00 |
|
zlt
|
baaf5dfc01
|
处理pms系统对接
|
2026-08-18 16:01:40 +08:00 |
|
zlt
|
de7c340342
|
通过调度系统接入
|
2026-08-03 16:33:23 +08:00 |
|
zlt
|
37f7ace34b
|
计划 API：桥容器常驻改 uvicorn(:8300)，GET /plan 取每日选股计划；
plan.py 拆装配/渲染两层供 API 与 cron 共用；requirements 加 fastapi/uvicorn
|
2026-07-30 14:09:02 +08:00 |