17 KiB
交接：主观量化系统 09-03 到 09-07 这一段
写给下一个接手的人。读完这份就能接着干，不用回翻对话。
范围是 2026-09-03 方案批准之后到 09-07 上午。方案正本在同目录的 《主观量化系统方案_2026-09-03.md》，逐条决定在《复盘决定台账.md》，现记到第 32 条。 这份文件只讲这一段做了什么、现在是什么状态、下一步该干什么。
零、一句话现状
四层链路（数据基座、选股系统、PMS、择时决策系统）已经端到端接通， 研究结论第一次真正走到了人眼前。但有三处正在退步或没验完，接手第一件事是处理它们， 见第五节。
一、这一段做完的六件事
1.1 候选卡加了论断质量标注
解决什么问题。 同一张卡上有个双标：吸筹评分超过三十个交易日就判陈旧， 而研报论断此前只有"披露日不晚于数据日"这一个上界，永不过期。 技术侧的证据会过期、研究侧的不会，两类证据在卡上看着一样新。
做了什么。 四项提示：论断过了多少天、是不是全部出自同一份研报、
有几条被标为疑似误抽、有几条处于未结的方向分歧。四项都只提示，不参与三门槛判决。
陈旧线定为 90 个自然日（配置项 LOGIC_STALE_DAYS），一次定死，不按复盘收益读数回调。
一处实现纪律。 质量画像必须在按票截断之前算。截断后每票只剩最近三条， "这票一共有几份不同来源"就统计不出来了。单测里专门有一条钉住这件事。
实测（09-04 全市场，3,767 只票）。 701 只带论断；陈旧度中位 147 天， 超过 90 天的 478 只（68%），超过一年的 39 只；372 只带多条论断， 其中 82 只（22%）全部出自同一份研报；96 只带疑似误抽标记共 264 条。
1.2 逻辑状态四态写完并接进计划
它回答什么。 不判断"这条产业逻辑对不对"——那是研究员的活。 只判断支撑它的证据还在不在：预测在不在下修、覆盖在不在收缩、有没有出现方向相反的论断。
四路证据。 甲路研报论断（方向受控必填，两个窗口：新材料窗口决定向好、 陈旧线决定还算不算数）、乙路产业研判（判采信倾向这个受控四值的迁移，不判自由文本）、 丙路券商行动（等长窗口的每股收益预测中位数与覆盖机构数）、丁路公司事件（无数据源， 恒出缺失，但照样记名——缺失要让人看得见系统缺的是什么）。
一条设计取舍。 向好判的是"变好了"，不是"现在是好的"。所以甲路要求最近三十天里 有新的利好论断，乙路要求采信倾向发生迁移，一直偏多的主题归平稳。 不这样的话逻辑强化会变得到处都是，也就不再说明任何事。
与候选卡三态是正交两维，不合并。 候选卡回答"今天要不要买"，是当日无状态重算； 四态回答"支撑它的研究证据还在不在"，是跨日跟踪。收敛规则单调：逻辑强化只能提前卡内序、 永远不升判决；逻辑存疑只能改分流通道、不能把仅展示变成可执行。
测试守的是这一条。 四个状态乘三个判决十二种组合逐个扫过，判决一次都没被四态动过。
实测改了一处设计。 首跑六只判为逻辑存疑的票里有五只，触发是覆盖机构从三家减到两家—— 一家机构那两周没发报告就构成 33% 的收缩。加基数门槛（前窗口至少五家）后只剩一只。
1.3 环节评析：从没跑过到每工作日自动跑
背景。 传导扫描每早指向的是环节，而已有的产业级评析只覆盖八个人工注册的主题， 两套名字不在一个命名空间，交集为零。
一个此前没人知道的事实。 这个任务在 09-04 之前一次都没跑过—— 它被路由到一条独立队列，而消费这条队列的容器 09-04 才在配置里定义、从未创建。
材料口径是关键。 不是按环节名去命中论断（那样十六个环节里只有四个够料）， 而是照产业级那套：先拿成员公司的代码与公司名，再回头去论断里捞。按这个口径十六个全部够料。
代价如实写在提示词与函数说明里。 九个环节的材料一条都没直接命中环节名， 结论本质是成员公司论断的加总。提示词要求模型只对环节整体下判断、不外推到个股。
踩过的坑。 首跑五个失败四个。原因是这个档挂的是推理型模型， 推理和答案共用同一个输出额度；实测推理长度 3,647 到 25,535 个字符， 而额度只有 8192，推理还没写完就见底。额度提到 32768 后零失败。 同一个坑在主题页旁批、热点扫描、传导旁批三处也存在（都写着 4096）， 日志里查到近三天有 5 次额度耗尽，一并修了。
定时。 基座机 crontab，北京时间 20:30（那台机器走世界时，表里写的是 12:30）。 装完在最简环境下实跑验证过，不是只看写法。
1.4 给人看的文字全面重写（四批）
起因是页面上出现"选股系统判为仅展示，不出提议：门槛未过：started"。
started 是门槛在代码里的变量名，SELL 是枚举值，两者都只该在系统之间传递。
| 批次 | 范围 | 内容 |
|---|---|---|
| 一 | 选股系统候选卡 | 预期空间、传导那句、论断出处的 36 位编号、ST 门槛没文案掉进兜底 |
| 二 | PMS 后端 | 规则闸六句、仓位约束六句、资金四句、计划取数两句 |
| 三 | PMS 页面 | 操作日志印函数名、冻结原因漏网、账本打整个字典等九处 |
| 四 | 计划文本与周报 | 环境标签、表头全译、导读重写 |
一条必须守住的纪律。 那些大写判据码是承重的：账本靠它取去重键、 命令进度靠它做原因聚类。2026-07-29 账本被同一条指令按分钟灌满，病根就是去重键失效。 所以码留在句首，只能在显示层剥。后端与前端各一份实现，注释互相指认。
页面此前完全没有测试，所以第三批先写守卫再改。它比人工照清单改可靠—— 多抓出四处清单里没有的。守卫现在盯着 11 个枚举字段，已登记进测试入口与哨兵清单。
改正一处事实错误。 周报导读写着"样本纪律三档"，代码里只有两档。
1.5 关闭启动涨幅线
做成整条开关（CARD_REQUIRE_STARTED），不是把阈值调成负数那种绕法——
调阈值的话没有当日行情的票仍会被拦下。
实测对照（数据日 09-03）： 关之前 83 只强传导票全部落到仅展示、候选 0 只； 关之后候选 33 只、关注 1 只、仅展示 102 只，PMS 有 11 只进入建仓流程 （新建仓是只提议，不会自动下单）。
九条用例钉住"关掉这一条不许顺带放松别的"：传导、覆盖、吸筹确认线、硬风险四道仍照拦。
1.6 让旁批说得出产业理由
根因两条。 一是喂给模型的六项全是行情口径，一项产业逻辑都没有； 二是提示词无条件要求"说主要不确定性是什么"，所以后半句必定是风险。
改法。 把环节研判与成员论断方向计数喂进去；风险那句改成条件式。 材料缺席时明确写"这个环节还没有做过研判"，而不是省略—— 省略的话模型会拿行情数字硬凑一句产业判断。
实跑对比（AI算力主题，环节"服务器"）：
- 改之前的样子："锂离子电池涨幅负 6.4%，目标价空间 74%，市盈率 15 低于链均值， 电池龙头具备配置价值；竞争加剧与原材料波动是风险。"
- 改之后："超节点占比提升与 GB200 良率改善推动毛利率上行，token 用量增加及下游采购 加大驱动需求，预期上修至盈利改善；但环节整体供需数据不足，匹配存疑。"
二、费用的实际口径（09-07 更正）
单个环节实测： 固定 3 次云端调用，输入 12,730、输出 16,763，合计约 2.9 万 token。 输出比输入多，因为推理过程也计进输出。
09-04 我给的估算是错的。 当时说"事件天天刷新，多数环节要重评，每天约 59 万 token"。
09-07 实测：周五那次定时投了 24 个，全部指纹跳过，一个都没重跑，耗时都在 0.2 秒以内。
原因是环节评析那个任务把封顶挪到了指纹之前（与产业级评析相反）。指纹只覆盖真正进 模型的那 32 条论断加 12 条事件，而每天新落库的上千条事件多数落在这 12 条之外，指纹不变。
所以稳态花费远低于估算。新的口径是：只有新出现的环节、或近期材料真的进了前 44 条的 环节才会重评。 近 31 个交易日的读数是每天新出现 4 到 5 个环节， 按此估约每天 12 万到 15 万 token。这个数还需要连着看几天确认。
注意：钱是多少我不知道。 仓库、配置、文档里一个单价数字都没有。要算钱得查供应商 当期价目或看控制台账单。
三、上线状态
| 系统 | 机器 | 状态 |
|---|---|---|
| 数据基座 astock-kg | 178 | 代码到 d0d3a2a，环节评析容器 worker-review 已建并在跑，定时已装 |
| 选股系统 akg-factor-bridge | 155 | 代码到 655cef7，容器已重建，启动涨幅线已关 |
| PMS tradingSystem | 155 | 代码到 9a45df3，镜像已重建，全套 655 例通过 |
| 择时决策系统 bionic_trader | 188 | 09-03 上线后本段未动 |
PMS 的三项确认（每次上线前照做，不许照抄上一次的读数）： 下发模式是直连（不是影子模式，台账 022 记的已过期）、 目标地址 192.168.18.182 是模拟侧、账本表前缀为空。
四、这一段踩过的坑（都值得记住）
一，docker compose exec 会打到孤儿容器。 155 上有个 2026-08-03 由 docker compose run
留下的容器跑了四周，exec 会优先打到它，导致核验落在四周前的代码上。已清除。
识别办法：docker compose ps -q pms-web 与 docker compose exec -T pms-web hostname 不一致。
二，推理型模型的推理占输出额度。 四处都踩了这个坑，全部提到 32768。
判断办法：日志里出现 finish=length 就是又不够了。
三，"代码写了"不等于"跑通了"。 两个现成例子：候选卡的缺失项一路带到前端却 从没被渲染过；环节评析的任务与路由都配好了，消费容器却从未创建。
四，我自己出过两次误判。 一次是按猜的键名取值、据此报"环节图建不出来"， 实际是我查错了地方；一次是把"自我校验没通过的研判"一律过滤掉， 实测二十个里十个没通过，等于扔掉一半。结构不确定时先把顶层键打出来， 不要按猜的键名取值然后据此下结论。
五，选股系统的计划接口每次实时重算，实测 24 秒。 PMS 的取数超时原为 10 秒，
容器重建后立刻暴露。已把 PMS_PLAN_TIMEOUT 调到 60。容器重建后第一次拉计划必然慢。
五、接手第一件事：三处正在退步或没验完的
5.1 行业观点快照断了（最要紧）
现象。 09-07 的计划里产业研判这一路可用数是 0，而 09-04 是 6。 三十行全部写着"这个环节对不上任何产业研判主题"。
查到的原因。 快照表里只有 09-03 与 09-04 两天，周末与今天都没有新增。 计划取不到当日快照，于是这一路整个缺席。
要查什么。 调度中心那条快照任务 09-04 手动触发验证过是通的 （来源 192.168.16.165，写入时刻从 05:01 走到 05:05）。所以要查的是它有没有按日自动执行、 还是只在手动触发时跑。
验证命令（在 Mac 上跑）：
ssh -p 2280 factor@192.168.16.155 "docker exec akg_factor_bridge python3 -c \"import db, config; print(db.read_mysql('factor', 'SELECT plan_date, COUNT(*) n, MAX(snapshot_at) FROM ' + config.JUDGEMENT_SNAPSHOT_TABLE + ' GROUP BY 1 ORDER BY 1 DESC LIMIT 5').to_string())\""
预期读数：每个交易日一行。现在只有两行，就是断了。
5.2 一致性检查表十三行只核完五行
这是用户定的判收标准——系统逻辑、实现、设计目标三者高度一致。没核完就不能说这个阶段做完了。
已核完的五行：
| 行 | 结论 | 证据 |
|---|---|---|
| 一 分析结论到选股 | 一致 | 当日计划 30 行全部带逻辑状态，22 行带因果论断（运行时） |
| 三 无法判断的出口 | 部分一致 | 代码逻辑对，但当日判决分布里一只"关注"都没有，这条路没被真正走过 |
| 八 环境判断 | 一致 | 计划顶层市场段四项齐全（运行时） |
| 九 择时定位 | 一致 | 送研判的白名单十六个键里没有论断、依据、四态，产业逻辑没有越界 |
| 十三 同源与凭据 | 部分一致 | 坏信号集合三处值一致且注释互指，但只有选股系统一处有单测钉住 |
剩下八行要连库或调接口才能验：第四行裁决留痕、第五行复盘对照、第六行时点纪律、 第七行研究深度、第十行信号来源、第十一行持仓跟踪、第十二行人机分工，以及第二行选股到建仓方案。
核对时守住一条： "代码里写了"不算数，判"一致"必须看到运行时证据。 已因此降级过一行（第三行）。
不要派并行代理做这件事。 09-04 与 09-05 各试过一次，两次都是全部代理跑满几十分钟、 零条结果、卡在返回那一步。自己逐行做反而快。
5.3 采信倾向全是偏多，这一路暂时没有区分度
二十个环节的采信倾向清一色偏多，一个偏空、一个中性都没有。 原因是研报材料本身几乎全是看多的，券商极少明说不看好。
这是设计预料到的，不是缺陷。 四态里写死了稳定偏多归"平稳"，只有发生迁移才算向好或转弱。 所以这一路在攒够版本史之前，最多只能贡献"平稳"这个非负面证据。
但前提是快照要每天落。 见 5.1——现在断了，连版本史都攒不起来。
另外二十个环节里十个自我校验未通过。校验挑的是"某条论据撑不住某个推断"， 不是整份结论作废，所以现在是照给但带上校验意见。
六、还没做的（按建议顺序）
一，把 5.1 那条修好。 不修的话产业研判这一路等于没接。
二，核完一致性检查表剩下八行。 这是判收标准本身。
三，给另外两处坏信号集合加单测。 现在三处值一致靠人记，只有一处有机器守着。
四，触发密钥进访问日志。 密钥跟在网址后面，会明文写进接口的访问日志。 不紧急（内网、日志只有本机能读），改法是放到请求头里，但调度中心那条任务要跟着改。
五，方案里搁置的两条不要重开，除非前置条件满足：上下游业绩传导 （需要供应关系恢复更新、方向准确率有实测、清洗后配对数够用）、 产业级驱动跟踪（需要先给驱动方建同义与冻结词表）。
七、验证命令汇总
选股系统（Mac 上跑）：
ssh -p 2280 factor@192.168.16.155 "docker exec akg_factor_bridge python3 logic_state_coverage.py 2026-09-03 2026-09-04"
预期读数：四态分布是无法判断约九成、逻辑成立约一成、逻辑存疑个位数； 各路可用次数里产业研判不为零。若产业研判为零，就是 5.1 那条断了。
环节评析的定时（Mac 上跑）：
ssh -p 2280 tlai@192.168.16.178 "tail -c 600 ~/akg_logs/review_segment.log"
预期读数：每个工作日一段 JSON，dispatched 是当晚投出去的环节名单。
PMS 全套测试（Mac 上跑）：
ssh -p 2280 factor@192.168.16.155 "cd /home/factor/project/tradingSystem && make test"
预期读数：最后一行 ALL SUITES PASS，共 655 例。
若报缺依赖，是镜像没重建，先跑 make deploy-local。
选股系统全套测试（Mac 上跑）：
ssh -p 2280 factor@192.168.16.155 "cd ~/project/akg-factor-bridge && for f in test_*.py; do printf '%-28s ' $f; docker exec akg_factor_bridge python3 $f 2>&1 | tail -1 | cut -c1-40; done"
预期读数：九个文件全部以 ALL OK 或 ALL PASS 开头。
八、红线（不许碰）
- 禁止关机、重启这类高危命令。
- 容器的重启、重建、新建必须先经用户同意。
- PMS 正式实例（连 192.168.16.98 那侧 QMT）测试期间一律不部署。
- 每次 PMS 上线前逐项确认三项：下发模式、通道开关、账本表前缀。不许照抄上一次的读数。
- 不做回测、因子合成、IC 与单调性评价；评价只用候选单复盘。
- 不用内部代号与不严肃的措辞；需要决定的事项在对话里选项式提问。