1. 为什么我要把逻辑和个股拆成两层来做先把结论摆在前面市面上大多数所谓AI选股的做法是把行情数据、财务数据、新闻情绪一股脑塞给大模型然后让它直接吐出一个股票代码。我试过这条路结论是——能跑通但不可用。原因不复杂大模型本质是一个概率性的语言模型它擅长的是归纳、推理、结构化表达而不是在噪声极高的金融时间序列上做精确的数值外推。你让它直接预测明天涨跌等于让一个文科状元去做高频量化方向就错了。所以我这套框架的核心思路是分层解耦把逻辑和个股拆成两个独立的智能体环节中间用结构化的中间产物连接。第一层叫逻辑层智能体负责回答当前市场在交易什么主线、哪些行业逻辑正在被资金认可、驱动因素是什么第二层叫个股层智能体负责回答在这条逻辑下哪些标的的基本面、资金面、技术面能对得上。两层之间不直接传递买什么而是传递一份结构化的逻辑卡片个股层拿到卡片后再去做匹配。这么拆的好处有三个。第一可解释。当最终选出的票表现不好时你能回溯到底是逻辑判断错了还是个股匹配错了而不是面对一个黑盒干瞪眼。第二可复用。同一条逻辑比如算力约束下的国产替代可以喂给不同的个股筛选策略逻辑层不用重跑。第三抗幻觉。大模型在总结一条产业逻辑这件事上的幻觉率远低于预测一个具体价格把任务限制在它擅长的区间里输出质量会稳定很多。这套框架适合谁我认为适合三类人一是有点编程基础、想把自己的投资经验系统化的个人投资者二是做AI应用开发、想找一个真实落地场景练手的工程师三是做投研、想用工具提升信息处理效率的从业者。它不需要你有GPU集群一台带独显的机器或者一个能调用大模型API的环境就能起步。下面我把整个框架从架构到落地拆开讲。2. 逻辑层智能体把市场在炒什么变成结构化卡片2.1 逻辑层到底要产出什么逻辑层的输出不是一段散文而是一张逻辑卡片。我定义的卡片字段包括主线名称、驱动事件、受益环节、持续时间预期、验证指标、证伪信号、置信度。举个例子当市场在交易算力约束这条线时卡片大概长这样字段内容示例主线名称算力约束下的推理侧降本驱动事件大模型推理需求爆发单位算力成本成为瓶颈受益环节推理优化、量化压缩、边缘部署、国产算力适配持续时间预期中期1-2个季度验证指标相关公司订单增速、推理芯片出货量、云厂商资本开支结构变化证伪信号推理成本大幅下降导致降本逻辑不再稀缺置信度0.7为什么要做成表格而不是一段话因为下游的个股层智能体需要可编程地读取这些字段。如果逻辑层输出的是最近算力很火相关公司可能受益这种话个股层根本没法用。结构化之后个股层可以拿受益环节去匹配行业标签拿验证指标去匹配财务数据拿证伪信号去做风险过滤。2.2 逻辑层的数据源与提示词设计逻辑层吃进去的数据我建议分三类新闻与公告、研报摘要、市场表现数据板块涨跌幅、成交额占比、涨停家数。注意这里不要喂原始K线K线是给个股层用的。逻辑层关心的是叙事不是价格。提示词设计上我踩过一个坑早期我让模型分析当前市场热点结果它每次都给我一堆正确的废话。后来我改成角色约束输出格式三段式你是一名专注产业趋势的投研分析师。 基于以下材料识别当前市场正在交易的核心逻辑最多输出3条。 每条逻辑必须包含主线名称、驱动事件、受益环节、持续时间预期、验证指标、证伪信号、置信度(0-1)。 要求 1. 受益环节必须是具体的产业环节不能是相关概念股这种模糊表述。 2. 验证指标必须是可观测的数据不能是市场情绪这种主观描述。 3. 如果材料不足以支撑某条逻辑置信度必须低于0.5。 材料如下 {news_and_reports}这个提示词的关键在于约束输出粒度。你会发现一旦要求验证指标必须可观测模型就会被迫从空泛叙事转向具体数据幻觉空间被大幅压缩。这是我实测下来最有效的一招。2.3 逻辑层的去重与置信度校准逻辑层跑一段时间后你会遇到一个问题每天输出的逻辑卡片高度重复。这时候需要做语义去重。我的做法是用一个轻量的嵌入模型把主线名称驱动事件编码成向量计算余弦相似度超过0.85的合并保留置信度更高的那条并把两条的验证指标取并集。置信度校准是另一个容易被忽略的点。模型自己给的置信度往往偏高需要做历史回测校准。具体做法是把过去N期逻辑卡片存档等验证窗口过去后回看哪些逻辑真的兑现了统计每个置信度区间的实际兑现率然后做一次映射修正。比如模型给0.7的实际兑现率只有0.5那就把0.7映射到0.5。这一步做完置信度才真正有参考价值。提示逻辑层不需要每天全量重跑。我的经验是主线逻辑的切换频率远低于股价波动频率一周跑2-3次足够盘中异动时再手动触发一次即可。3. 个股层智能体让逻辑卡片去钓标的3.1 从逻辑卡片到选股条件的翻译个股层的核心任务是把逻辑卡片里的受益环节翻译成可执行的筛选条件。这一步我建议用规则模型混合的方式纯模型容易飘。具体分三步第一步行业映射。把受益环节映射到具体的行业分类和概念标签。比如推理优化映射到AI应用软件服务国产算力适配映射到半导体信创。这一步可以用一个维护好的映射表也可以用模型辅助生成后人工确认。第二步财务与基本面过滤。根据验证指标生成筛选条件。比如验证指标是订单增速那就筛最近两个季度营收增速20%且合同负债环比增长的标的。这一步是硬规则不交给模型。第三步技术面与资金面排序。对通过前两步的标的用技术指标均线多头排列、量能温和放大和资金指标主力净流入、北向持仓变化做排序打分。3.2 个股层的提示词与工具调用个股层我强烈建议用**工具调用Function Calling**的方式而不是让模型直接读原始数据。原因很简单财务数据、行情数据都是结构化的让模型去读表格再算指标既慢又容易错。正确做法是把筛选、计算封装成函数模型只负责决定调用哪个函数、传什么参数。一个典型的工具集包括screen_by_industry(industry_tags, top_n)按行业标签筛选filter_by_financial(metrics, thresholds)按财务指标过滤rank_by_technical(indicators, weights)按技术指标排序get_capital_flow(codes, days)获取资金流向模型的工作流是读逻辑卡片 → 决定调用哪些工具 → 拿到结果 → 生成最终推荐列表和理由。这样既保证了数值计算的准确性又保留了模型的推理能力。3.3 个股层最容易翻车的地方我踩过最大的坑是幸存者偏差。早期我用历史数据回测发现策略收益很漂亮实盘却差很多。排查后发现回测时我用的股票池是当前还在交易的股票那些退市的、被ST的早就被剔除了等于开了上帝视角。修正方法是回测时必须用当时的股票池快照包括后来退市的标的。第二个坑是逻辑与个股的错配。有时候逻辑层判断对了主线但个股层选出来的票跟这条主线其实关系不大只是财务数据好看。解决办法是在个股层的提示词里加一条硬约束推荐理由必须显式引用逻辑卡片中的受益环节如果引用不上就不推荐。这一条加上后错配率明显下降。4. 两层之间的衔接中间产物的设计与版本管理4.1 为什么中间产物要版本化逻辑卡片是会变的。今天判断算力约束是主线下周可能就切换成应用落地了。如果不做版本管理你根本不知道某只票是基于哪一版逻辑选出来的也就无法归因。我的做法是给每张逻辑卡片打上logic_id和version个股层的每次推荐都记录对应的logic_id。这样回看时能清楚看到这条逻辑存活了多久、选出的票表现如何。4.2 衔接层的字段对齐两层之间最容易出问题的是字段语义不一致。逻辑层说的受益环节是个偏产业的描述个股层需要的是偏分类的标签。中间需要一个对齐层把产业语言翻译成数据语言。我维护了一张对照表比如逻辑层表述个股层标签推理侧降本AI应用、软件服务国产算力适配半导体、信创边缘部署物联网、消费电子数据要素数据服务、传媒这张表不用一次做全跑起来之后遇到映射不上的再补慢慢就覆盖全了。4.3 反馈闭环让框架自己进化框架跑起来之后最重要的是反馈闭环。我的做法是每周做一次复盘把本周推荐的标的按逻辑分组统计每组的表现然后回看逻辑卡片的验证指标和证伪信号是否触发。如果某条逻辑连续两周证伪信号都没触发但标的也不涨说明这条逻辑可能只是叙事而非交易逻辑下次同类逻辑的置信度就要下调。这个闭环不需要多复杂一张表格加每周半小时的复盘就够。但坚持做和不做半年后框架的质量差距会非常大。5. 算力与部署个人开发者怎么把这套跑起来5.1 算力需求的真实评估很多人一听AI智能体就以为要买卡。实际上这套框架的算力需求分两块推理和微调。推理这块逻辑层和个股层的调用频率都不高逻辑层一周几次个股层一天几次用API完全够成本可控。真正吃算力的是如果你想做本地部署或者微调。本地部署的话7B到14B参数的模型用int8量化后一张消费级显卡比如24G显存级别就能跑。如果要做微调LoRA方式下同样的卡也能勉强跑7B模型的小规模微调。我的建议是先用API把框架跑通验证逻辑有效之后再考虑本地化。不要一上来就折腾部署那是本末倒置。5.2 精度选择int8、fp16到底怎么选这里补充一个实操细节。模型推理时的数值精度直接影响显存占用和速度精度显存占用速度适用场景fp32最高最慢训练推理基本不用fp16中等较快推理首选精度损失小int8较低快显存紧张时的推理int4最低最快极限压缩精度损失明显我的实测经验是推理用fp16显存不够再降到int8。int4虽然省显存但在需要精确推理的任务上比如财务数据理解精度损失比较明显不建议用在个股层。逻辑层对精度要求低一些int8可以接受。5.3 成本控制的实际做法API调用是有成本的尤其是逻辑层要喂大量新闻和研报。我的控制方法有三个一是缓存同一批材料不重复调用二是分级先用小模型做粗筛把无关材料过滤掉再用大模型做精读三是批处理把多条逻辑的识别合并成一次调用而不是一条一条问。这三招下来成本能压到原来的三分之一左右。6. 实盘验证中暴露的问题与修正6.1 逻辑层滞后于市场实盘跑了两周后我发现一个明显问题逻辑层识别出主线时往往已经涨了一波了。原因是逻辑层依赖新闻和研报而这些材料本身就有滞后性。修正方法是引入前瞻性信号把产业政策征求意见稿、龙头公司业绩预告、产业链调研纪要这类早于新闻的材料单独加权。另外把持续时间预期这个字段用起来如果判断是短期就只做快进快出不恋战。6.2 个股层的过度拟合个股层的筛选条件如果设得太细会选出很少的票而且这些票往往是历史表现好的实盘容易失效。我的修正原则是筛选条件不超过4个且必须包含至少1个非价格类指标。纯技术面的筛选最容易过拟合加入财务或资金面指标能有效缓解。6.3 模型的一致性漂移同一个逻辑卡片今天问和明天问模型可能给出不同的推荐。这是因为大模型有随机性。解决办法是固定随机种子如果API支持并且在提示词里要求基于给定条件做确定性筛选不要引入额外主观判断。另外个股层的工具调用结果本身是确定的只要模型不乱改参数输出就稳定。7. 几个我认为值得单独说的经验第一不要把框架当成预测机器。它的价值在于把分散的信息结构化、把重复的筛选自动化而不是告诉你明天买什么。把它当成一个信息处理助手心态会好很多用起来也更理性。第二逻辑层的质量决定上限。个股层再精细如果逻辑层判断错了主线结果也不会好。所以时间分配上我建议逻辑层和个股层投入比例大概是6:4而不是反过来。第三小步快跑别追求一步到位。我见过太多人想做一个全自动AI投研系统结果卡在数据接入就放弃了。正确的做法是先手动喂几条逻辑跑通个股层再慢慢把逻辑层自动化。每一步都能用起来才有动力继续。第四保留人工否决权。框架给出的推荐最终下单前我一定会人工过一遍尤其是那些逻辑卡片置信度低于0.6的。AI负责广度人负责深度和风控这个分工目前来看是最稳的。这套框架我前后迭代了大概三个月从最初的一团乱麻到现在能稳定输出中间踩的坑基本都写在上面了。如果你也在做类似的事情建议从逻辑卡片这个中间产物开始设计把两层的接口定清楚后面的路会顺很多。