tradingSystem/app/web
zlt d30440edb2 提议卡重排:要紧的放前面,证据收进展开,并标出「建议档位」与「实下股数」不一致
一、重排。原先一张卡一口气铺十六行,实测二十七八个可视行,大半是「暂无」
「近三天没点名」这类占位句,要人在一屏读不完的文字里自己找哪条要紧。
现在按「决定要不要点采纳所必需」分两层:

卡面留——这一笔买多少股多少钱占总规模几成、建议档位、选股系统判决、
决策系统结论(截到 60 字)、公司深度(真有报告才占一行)、为什么选它。
展开里收——研报、安全边际、催化事件、定价状态、相关快讯、行业催化、
判决收敛、建议方案整句、择时层两个期限、候选榜信息、决策系统原话。

「这一笔买多少」原先排在第十四行,而它才是采纳按钮真正会执行的东西,提到第一行。

二、删掉重复行。propBasis 与 propVerdictLine 在判决为「候选」或「仅展示」时
读的是同一个 hard_numbers.basis,逐字相同,模板里又挨着摆两行,于是卡上出现
两行一模一样的话。今天 77 只票里 38 只判候选,每一只出提议都重复一次。
删 propBasis,留 09-04 专门写的收口函数 propVerdictLine。

三、「为什么选它」第一次上卡。propReasons 这个函数写好之后模板里一直没引用过
(grep 只有定义与导出两处),而这恰恰是人做决定最先要看的。顺带不再只取前两条。

四、【要紧】新增一行红字,标出建议档位与实下股数不一致。

研判把握度低或不可用时,advice_service.apply_judge 把档位降成「试探仓」、
把 advice.target_pct 改成 1%,但它明确不改数量(函数说明原文「不改数量,
数量交人」),而页面上采纳按钮没有填数量的地方,这个「交人」无处兑现——
采纳时后端直接抄提议里的 qty 原样落单(web/main.py:485,只有卖出侧会重算)。

155 实测 8 张待确认提议,7 张写着「试探仓(目标 1.0%)」,而每一张实际都会
买 3.00%(标准仓 6% 的第一批),正好三倍:
  002812.SZ 1200股×48.55 实占 3.00%  建议 1%  算量用 6%
  300604.SZ  200股×264.81 实占 3.00%  建议 1%  算量用 6%
  300638.SZ 3300股×18.11 实占 3.05%  建议 1%  算量用 6%
  301525.SZ 1600股×37.37 实占 3.00%  建议 1%  算量用 6%
  688698.SH 1400股×41.49 实占 3.00%  建议 1%  算量用 6%
  605598.SH 2300股×25.24 实占 3.07%  建议 1%  算量用 6%
  688556.SH 7300股×8.11  实占 3.02%  建议 1%  算量用 6%
只有 300118.SZ(标准仓)是自洽的。

根子上的修法是让数量跟着档位重算,那会改变每一笔采纳真正发出去的钱,
还要一并处理「1% 在高价票上凑不满一手」与「pms_position.target_pct 从未写过、
试探仓建的仓日后会被按 6% 补满」两件事,所以单独拍板、本次不做。
在那之前先把矛盾摆到人眼前——让人看错数字下单,比让页面难看严重得多。

判定用的键一个都没动,只动 DOM 与显示函数。两道页面守卫通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 13:00:03 +08:00
..
static 提议卡重排:要紧的放前面,证据收进展开,并标出「建议档位」与「实下股数」不一致 2026-09-10 13:00:03 +08:00
__init__.py 第二批: 命令状态机/方案生成器/回放对账/管理页面/调度器骨架 2026-07-27 17:12:09 +08:00
auth.py 添加权限 2026-08-27 10:16:45 +08:00
main.py 点股票看它今天的全部信号:按代码回扫接口、抽屉、遮罩空白四处修复(台账 055 第一件) 2026-09-09 14:53:29 +08:00