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> |
||
|---|---|---|
| .. | ||
| assets | ||
| core | ||
| db | ||
| repo | ||
| services | ||
| web | ||
| ws | ||
| __init__.py | ||
| scheduler.py | ||