1. 先厘清主线LLM到底能在交易链路的哪个环节改变游戏规则做算法交易研究的人大概都经历过这么一层困惑LLM这个词听起来无所不能可真要把它塞进交易系统里第一个问题不是模型怎么调而是它究竟该干哪份活。我最初的项目设想很简单——让大模型帮我判断交易什么结果越做越发现选标的只是表象真正决定这套系统成败的是后面那句如何执行。把这句话拆开其实就是一整条算法交易流水线的重构过程。传统算法交易的流水线大概可以画成五段信号生成、组合构建、风险管理、执行算法、复盘归因。前两段负责交易什么后三段负责如何执行中间隔着的是仓位、约束、成本这些硬约束。过去我们做量化每一段都是数值计算因子打分、协方差矩阵、优化器、滑点模型整条链路是数字进、数字出。而LLM的强项恰恰不在数值而在语义——它能读财报、能听电话会、能理解新闻里管理层下调指引和行业迎来政策利好之间的微妙差别。这个能力在传统流水线里几乎是空白因为传统系统处理不了非结构化信息。所以我把LLM在交易链路里的定位归结为两个层次。第一层是交易什么也就是用语义理解能力把新闻、公告、研报这些文本转成带时间戳、带置信度的结构化交易事件。第二层是如何执行也就是在订单生成和算法选择这些环节让LLM当场景裁判根据当前市场状态输出执行策略。这两个层次听着分得很开实际上共用同一套架构底座上下文管理、结构化输出、校验防火墙、多Agent协作。写这篇研究笔记的初衷就是想把这条从交易什么到如何执行的完整路径以及我在每个环节踩过的坑、试过的方案原原本本梳理出来。适合的人有三类正在尝试把LLM引入交易系统的量化研究员想让策略从拍脑袋选股升级到有章法执行的个人投资者还有对LLM Agent工程感兴趣、想找个非聊天场景练手的技术开发者。1.1 传统交易流水线的语义断层传统量化有一个很尴尬的断层数据接入层拿到的都是结构化数值比如动量因子、波动率、市盈率但这些数值是人类交易员看了新闻、读了公告之后情绪的量化结果。这个转化过程原本由基金经理的盘感完成效率低且不可复制。LLM的出现等于把读材料、做判断这件事第一次变成了可编程的模块。但要注意语义理解和可编程之间还隔着工程化。我一开始天真地以为把新闻丢给GPT-4让它输出买或卖就行结果跑通后发现根本没法用没有时间维度没有置信度没有可校验的来源更重要的是模型今天对这个新闻的评价和明天可能完全不一致。研究做不下去才被迫回头重新设计信息提取的整个流程这一步的教训后面会详细展开。1.2 LLM切入的两个层次交易什么和如何执行在技术特性上是两种完全不同的活。前者对时效性极度敏感新闻出来之后模型必须在一两分钟内完成理解并输出事件后者对一致性极度敏感同一市场状态下执行策略的输出必须稳定不能这次说立刻市价买入下次说挂个低价慢慢等。这两个特性会影响很多设计决策最典型的是模型选型和缓存策略。交易什么环节模型响应越快越好实时性强可以选延迟较低的推理通道也可以考虑本地部署小参数模型做初筛再用云端大模型做精读。如何执行环节则应该引入缓存和模板机制——对高频出现的市场状态比如波动率升高但成交量平稳完全可以用历史输出做模式匹配没必要每次重新推理这样既能省钱又能提升行为一致性。这些具体内容我放在后面主体章节展开。2. 用LLM回答交易什么从信息噪音中提取可交易信号交易什么这个问题的标准解法在LLM出现之前是因子模型和事件驱动模型的混合体。因子模型是把涨跌幅、换手率、基本面指标做成数值特征事件驱动则是盯着财报、增持、回购、行业政策这些离散事件。传统事件驱动最大的痛点是事件要从公告和新闻里人工提取费时费力还漏得快。LLM直接抹平了这层障碍。我在项目里走的路线是LLM事件抽取置信度打分。全流程可以拆成五个环节每一步都有明确的输入输出方便单独调试。第一数据接入层。需要拿到至少两个来源的文本流一是交易所披露的公告原文二是经过清洗的财经新闻流。公告原文解决的是确凿事实问题财经新闻解决的是市场情绪倾向问题。这里强烈建议用专门的数据供应商API不要自己爬否则光做页面解析和反爬就能耗掉你两周时间。第二文本预处理。每条消息先做去重和切分把一篇几千字的研报拆成以段落为单位的小块因为上下文窗口有限整篇塞进去会让模型抓不住重点。切分时要注意把标题、发布时间、来源编号保留成元数据后续校验全靠这些字段。第三LLM结构化抽取。这是核心环节提示词里明确要求模型输出一个固定格式的JSON包含事件类型、情绪倾向、置信度、关联标的、影响时间窗口、摘要和引用来源。给模型规定输出契约是从玩具走向工具的关键一步否则模型会自由发挥下游代码没法处理。第四事件聚合。同一标的一小时内多条新闻需要按时间窗口聚合成一个复合事件比如某公司财报后被两家机构下调评级同时管理层发布回购计划这类复合信息比单条新闻更有交易价值。聚合这步我用的是规则代码而不是LLM因为逻辑简单明确规则更便宜更稳定。第五信号入库。最终产出写进一个事件表字段包括事件时间、标代码、事件类型、情绪分、置信度、过期时间。下游的组合构建模块每五分钟扫一次这张表按置信度过滤后生成候选交易列表。2.1 事件驱动信号的提炼流程用一个实际例子走一遍会更直观。假设某天下午两点半某上市公司发布财报电话会纪要里面管理层说下季度资本开支将显著增加全年毛利率承压。这条文本如果进关键词匹配系统只会匹配到资本开支毛利率这些词但无法判断这对股价是利空还是利多。放进LLM流程里模型的判断逻辑是资本开支增加意味着扩张但毛利率承压属于负面指引综合看短线偏空置信度0.65。这个输出会进入下游逻辑如果账户里没有该标的的多头持仓系统会生成一个观望信号如果恰好持有风控模块会提示关注财报指引利空。这种从字面关键词到语义判断的跃迁正是LLM在这个环节最大的价值。回测时能明显看到这类语义信号对股价的反应领先于纯数值因子因为新闻文本出现的时间点通常早于分析师们更新盈利预测的时间点。2.2 结构化输出契约一个可落地的JSON示例项目里实际使用的输出契约大概长这样我可以给一个简化的示例{ event_type: guidance_downgrade, sentiment: -0.35, confidence: 0.68, affected_symbols: [600519], impact_window: 2024-11-01T14:30:00Z/2024-11-01T20:00:00Z, summary: 管理层在电话会中下调下一季度收入指引主要原因为需求疲软与渠道库存偏高, cited_sources: [ref_0001, ref_0002] }注意里头有几个字段是我反复迭代后才加上的。impact_window字段用来告诉下游这个信号的有效期过了窗口自动失效避免拿隔夜旧闻做交易。cited_sources字段是防幻觉的关键要求模型必须引用输入文本的段落编号只要摘要里的信息在源文段里找不到对应依据这条信号直接丢弃。这个设计一定要做因为LLM在金融文本上的幻觉率比表面上看起来高得多尤其当输入文本本身就模棱两可的时候。2.3 时效性与幻觉LLM信号的两个命门这两点单独拿出来说因为它们是LLM信号能不能真正上生产的分水岭。时效性方面新闻事件的价值衰减极快。我用事件发生到信号入库的全链路耗时做过统计初期平均需要37秒因为部分文本要排队等模型推理。后来做了三处优化一是把公告原文切块后并发调用推理不同段落走不同worker二是对明星标的加了一个轻量预筛模型先用小参数模型判断是否有交易价值没价值就不进大模型三是加了缓存同一公告的重复文本直接命中缓存。优化后耗时降到9秒左右对大多数日频、小时频事件驱动策略已经够用。幻觉方面除了引用来源之外还有一招很管用给模型设定不知道就承认不知道的兜底出口。在提示词里明确写如果输入文本不包含足够信息判断情绪倾向必须输出sentiment: 0confidence: 0.1并注明insufficient_information。这个兜底很重要因为金融文本里大量内容是中性盘面描述模型硬要判断情绪反而是在创造噪音。实际运行下来大约有18%的事件被模型标记为信息不足这部分信号直接不进交易候选池。3. 如何执行不是下单那么简单LLM在订单生成与执行算法中的位置交易什么解决之后更大的坑出现了信号说关注某标的距离真正把一个订单送进市场中间还隔着一大段路。这段路就是执行层。我最初的想法是信号出来之后直接调用下单API但研究做深了才发现如果执行层处理不好信号做得再准也会被执行成本吃光。这里有一个行业里常被忽略的真相买卖价差、冲击成本、延迟成本三者叠加经常能占到策略毛收益的三到四成如何执行本身就是alpha的一部分。订单生成前有四层决策链每一层都不是LLM能够单独搞定的。第一层头寸大小。信号模型给出了方向和强度但具体下多少仓位需要参考风险预算、当前持仓集中度、历史波动率。这层我用优化器计算LLM不参与因为数值优化是它不擅长的。第二层订单类型。是下市价单追确定性还是下限价单控制成本这层LLM可以参与判断因为它需要理解当前市场急跌但流动性尚可这类语义场景。第三层执行算法。确定性订单里是走TWAP时间加权平均价格、VWAP成交量加权平均价格还是ISImplementation Shortfall实现缺口最小化这层是LLM最该发挥作用的地方。传统方案是根据参数公式选算法但公式不会读新闻不会知道此刻正有重大利好发酵、机构资金可能抢筹这种微妙语境而LLM能。第四层路由与监控。微秒级的盘口变化不适合LLM管这层交给高频执行引擎。LLM的角色是设定边界条件比如在成交量放大到正常水平两倍之前不要追单。3.1 订单生成前的四层决策链这四层决策链我跑通之后最大的感悟是LLM的价值不在取代任何一层而在连接它们。过去每一层之间靠人写规则协调规则写多了就僵化。比如传统系统会写死当信号强度大于0.7时使用市价单但这个阈值本身应该是动态的——流动性好、波动低时市价单的成本很低可以激进一点市场深度差时市价单瞬间打穿盘口必须换成限价单被动等待。这种看情形决定的逻辑正好由LLM来定夺。我给LLM输入的是一段聚合后的市场状态描述当前该标的的盘口买卖价差、最近五分钟成交量、波动率百分位、还有新闻流里与该标的相关的最新事件。模型的输出不是直接的市价单或限价单指令而是一组合法的场景标签和参数建议。{ regime: low_liquidity_high_vol, execution_tactic: passive_limit_only, participation_rate_ceiling: 0.04, urgency_score: -0.6, notes: 当前盘口深度不足建议以限价单挂在买一至买三区间被动成交避免市价冲击 }这个输出里participation_rate_ceiling的意思是最高参与率不超过4%下游执行引擎拿到这个参数后会自动计算每笔限价单的委托量。模型不给绝对价格、不给精确数量只给边界和策略方向数值由工程模块兜底这个分工在后面的校验环节会看到它的价值。3.2 LLM在策略选型中的真正用法执行算法选型的核心矛盾是冲击成本和时间风险之间的权衡。TWAP追求平均价格适合流动性充裕的大单VWAP让成交量分布跟随大盘适合资金量级较大但又不希望被盯上的场景IS激进地尽快成交适合信号时效性强的短线判断。传统选型用多因子打分但打分系数怎么设永远是个经验活。LLM的做法不一样。它读的是市场情境盘口突然变薄、新闻流里出现同行业公司被大单扫货的异动、期权隐含波动率在爬升——这些信号交织在一起形成一个现在应该在执行上激进还是保守的判断。实测下来LLM在两类场景里表现特别突出一是突发新闻后的抢跑场景它能识别出信息冲击强度大、需要加速执行二是财报真空期的低波动场景它能判断市场很稳、慢慢挂单就好直接降低了约12%的执行缺口。我总结的一套落地提示词思路是不要问模型应该下什么单要问它当前市场处于什么状态适合哪些执行约束。前者是开放题回答充满不确定性后者是选择题模型的分歧度明显下降输出稳定很多。3.3 为什么不让LLM直接定价项目早期我踩过一个很典型的坑让模型直接输出限单价比如以每股10.2元挂限价买单。模型确实会给出一个像模像样的价格但实际使用的问题很大。第一模型对盘口数据的精确感知能力差。喂给它买一价10.15卖一价10.20它基本能理解但它不理解距离最优买价几个tick这个概念对应到具体报价上意味着什么容易给出明显偏离合理范围的数字。第二数字输出不稳定同一盘口状态跑五次可能出三组不同的价格这对交易系统是致命的。第三也是最要命的一旦模型输出的价格直接进入订单就没有中间层来校验、约束和复核了出问题就是真金白银的损失。所以我在架构上做了一个彻底的切割LLM只做场景分类和策略描述所有涉及价格、数量、手数的数值全部由规则引擎和优化器生成。LLM输出里的urgency_score是-0.6规则引擎根据这个分数把限价单挂单深度设为买三档选价逻辑是程序化的。这个切割做完之后整个系统的安全等级才真正能看。4. 中间防火墙把LLM的自由文本输出锁死在可交易边界内任何把LLM接到实盘交易环境里的人第一件事都应该是建防火墙。这个防火墙不是网络安全意义的防火墙而是输出守门员——LLM是生成模型它输出什么都有可能哪怕你提示词写得再严格它也可能在某次异常输入下给出完全离谱的内容。防火墙的作用就是让离谱输出只停留在日志里永远到不了下单API。我项目里第一版防火墙只做JSON格式校验结果有一次模型输出了合法JSON但所有字段都是null因为那次上游数据源返回了一段空白公告。null事件被下游代码直接当成无信号恰好放过了那天的所有交易判断。后来我把防火墙迭代成三层结构每一层分别处理一类问题实测运行下来非法输出拦截率基本达到100%。4.1 三层校验第一层是结构校验。LLM输出必须是合法JSON必须包含全部必填字段字段类型必须匹配。这一层的实现朴素而扎实用Pydantic做schema解析不合格直接打回重试重试一次仍不合格就丢弃该信号并告警。第二层是业务校验。这是跟交易强相关的部分包含三块规则标的黑名单过滤ST股、停牌股、流动性极差的仙股直接拦截数值边界校验confidence必须在0到1之间participation_rate_ceiling必须在0到0.2之间超范围的数值一律按上限截断或者拒绝方向校验系统里不允许出现信号标明多头但执行参数却偏向空头的矛盾组合这类矛盾通常说明模型上下文被污染了。第三层是状态校验。这一层解决的是模型输出本身合理但跟账户当前状态冲突的问题。比如模型建议对某标的加仓30%但该标的已经是第一大重仓加仓后仓位会超过单票上限这种意图在进入执行引擎之前就要被拦截。再比如模型建议挂限价买单但账户现金根本不够覆盖候选成交数量这类也需要前置校验。状态校验的代码跟账户系统直接对接每次下单前读取最新持仓和资金不依赖缓存。三层校验顺序执行每一层都有独立的日志和告警。我格外看重状态校验因为它是唯一跟真实账户状态打交道的环节数据稍微一旧就可能出错所以账户数据的读取走了独立的低延迟通道。4.2 熔断与降级校验之外系统还需要一个全局熔断机制。我在项目里设置了三类熔断条件连续10次业务校验失败说明模型进入了某种异常模式触发熔断单日推理调用成本超过预设阈值触发熔断防止意外死循环策略组合单日亏损达到规定上限无条件进入只减仓不开仓的保护模式。熔断触发后系统不是简单停掉而是降级到经典算法兜底模式。也就是说LLM信号通道关闭但备用规则引擎还能按传统因子继续运行交易不中断只是从智能模式切到保守模式。这个设计非常关键。刚开始我做熔断时只做了停机处理结果有次策略空窗了三天白白错过了一段行情。后来改为降级而非停机整个系统的可用性上了个大台阶。4.3 合理但不可交易的边界问题最后这一小节是我个人认为最值得一读的部分。前面说的三层校验拦的都是明显错误的输出。但真正难缠的是另一种情况模型输出的内容逻辑上完全合理语义上也无懈可击但它对应的操作在当前市场规则下根本不可执行。举几个我在项目里真实遇到的例子模型建议做空一只刚上市且未纳入融券标的范围的股票它的判断依据是基本面但它不知道交易规则里该标的不允许融券模型建议在开盘集合竞价阶段挂市价单买入但当时开盘价尚未产生市价单会被拒单模型建议对某港股标的挂一个远低于现价的限价买单理论上没错但该标的有单日涨跌幅限制限价超出了跌停范围会被拒绝。这一类问题光靠LLM解决不了因为它没有实时交易规则的数据库。我的做法是引入一个独立的规则查询模块在状态校验阶段把候选标的的交易限制实时拉取出来比如是否可融券、涨跌幅范围、最小价格增量、最小交易单位然后跟LLM输出做交叉比对。这个规则查询模块不写在提示词里让模型自学而是作为工具调用让模型随时查询查回来的结果再进业务校验。这样处理之后此类合理但不可交易的拦截率从78%提升到97%剩下3%是极端冷门标的的规则更新延迟导致的。5. 多智能体协作研究Agent、风控Agent与执行Agent的分工项目做到第三个版本我得出一个很明确的结论一个Agent做不了所有事。我最初试过单Agent方案把市场数据、新闻、持仓、风控规则全部塞到一个上下文里让它输出交易决策。效果很分裂回答宏观问题像分析师回答执行问题像菜鸟而且上下文一长它会把前面读到的数据遗忘掉输出跑到偏到十万八千里。后来转向多智能体协作架构把完整交易链路拆成三个各司其职的Agent研究Agent、风控Agent、执行Agent。调度上我用的是一个轻量工作流框架每个Agent是独立节点通过消息队列传递结构化数据。如果你不想引入框架用Python的状态机加队列也能跑但要注意每个Agent的独立上下文和失败重试机制。5.1 单Agent的上下文困境上下文困境这个问题值得展开讲。LLM的注意力随着上下文变长会显著衰减这是个已经被反复验证的工程事实。当我把行情数据、新闻简报、持仓列表、历史交易记录、风控规则全部塞进一个上下文时它往往只能记住开头和结尾的内容中间部分的约束被直接忽略。最典型的表现是它读懂了新闻里的信号却忘了提示词里单票持仓不超过总资金10%的纪律给出一个明显超仓的建议。三个Agent拆开之后每个Agent的上下文窗口短了很多任务也聚焦了。研究Agent只需要关注这条新闻发生了什么风控Agent只需要关注这个候选交易是否符合约束执行Agent只需要关注给定策略约束当前市场用什么方式成交最划算。各管一段互相之间传输的是结构化JSON不是整段对话记录信息密度高得多遗忘问题大幅缓解。5.2 三类角色的任务编排任务编排我使用了一个简单的三段流水线。第一步研究Agent产出候选交易信号格式是第二章里那个事件JSON数组。第二步每个候选信号进入风控Agent它从账户系统读取实时持仓和资金、从规则引擎读取标的交易限制输出一个通过或拒绝的判断拒绝的理由必须结构化分类比如超限黑名单波动率过高。第三步通过风控的候选进入执行Agent它读取盘口快照和最近新闻流输出执行策略参数也就是第三章那个JSON。三个Agent之间没有互相调用的环是严格的前后依赖关系。这让中间结果的审计变得非常容易——某个环节出了问题直接看那段JSON就知道是谁的责任。项目后期我还加了一个复盘Agent它不参与实时交易只在收盘后把当天所有决策JSON拉出来做归因分析找出模型判断和实际行情之间的系统性偏差。比如连续一周研究Agent对回购公告类事件的情绪评分都过于乐观复盘Agent统计出这个偏差后会自动生成一条提示建议调整该类型事件的置信度校准。5.3 工具调用与权限隔离多Agent架构里最容易忽略的是权限隔离。谁有权限做什么必须在系统设计阶段就定死否则Agent之间互相调用工具会造成灾难。我的设计原则是工具权限按最小化原则分配研究Agent只能访问数据源和检索类工具完全不接触交易相关服务风控Agent只能读取账户状态和写入风控记录执行Agent是唯一可以输出交易意图的角色但它的输出还要经过第四章那套防火墙才能变成真实订单。每个Agent调用工具之前系统会校验它的token权限标签没有权限直接拒绝。这个机制在初期看着有点重但对于金融系统来说非常必要因为Agent一旦被prompt injection打进异常指令权限隔离是最后一道物理拦截。我在这个项目里还特别规定LLM永远拿不到下单API的直接调用权限只能写入一个待执行订单表由中间层托管进程扫描、校验、转发。这条做法我现在强烈推荐给任何做LLM交易系统的人。6. 回测与灰度上线如何证明这套系统不是花哨但没用系统架构全部跑通之后最严峻的问题来了怎么证明它真的有用。这一关过不了前面所有的架构设计都只是自我感动。LLM交易系统的回测跟传统量化回测有一个本质区别传统策略的规则不变回测结果可复现LLM策略的输出有随机性同一段历史行情回测两遍结果可能不一样。这给归因和验证带来了全新挑战。我实际使用的验证路径分三个阶段场景回测、纸面交易、小资金实盘。每一步都有明确的通过标准和数据指标整个验证周期花了大概三个月。这里分享其中值得注意的细节。6.1 回测时的四类失真源第一类失真LLM随机性。应对方法是多次采样。每个历史时间点的LLM决策重复跑三到五次取期望值作为回测路径同时记录方差。如果某个时点的决策方差过大说明模型对该特定场景没有稳定判断这类信号在实盘里应该降权。我的经验是confidence超过0.7的决策多次采样一致性通常也较好如果一致性差说明模型在强行作答这种信号宁可丢弃。第二类失真信息污染。这是LLM回测特有的陷阱。用2023年的历史新闻做回测时模型可能已经在预训练阶段读过这段新闻甚至知道后续股价走势。为了规避这个问题我在回测引擎里把所有待分析的新闻文本作为输入喂给模型而不是让模型凭记忆回答同时提示词里明确禁止使用你记忆中的任何历史信息只根据当前文本给判断。虽然不能根治预训练污染但能明显降低它造成的前视偏差。第三类失真成本忽略。LLM交易系统有真实的资金成本API调用费、推理延迟造成的滑点、中间层处理耗时。回测时我按每次决策平均12元推理成本、平均900毫秒延迟作为参数注入执行模型一整套回测跑下来资金成本大概吃掉毛收益的几个百分点这笔账不做的话实盘铁定被亏空。第四类失真事件顺序交叉。回测里两条新闻时间戳只差几毫秒处理顺序不同会导致模型接收到不同拼合文本。我的处理是按时间戳严格排序同一时刻的新闻按预先分配的消息ID顺序拼接保证回测过程可复现。6.2 场景回测与纸面交易传统回测跑K线序列LLM回测我建议按新闻流重放来做。把历史新闻按真实时间线一条一条喂进系统模型在每条新闻到来时输出事件信号和执行意图系统把这些信号映射成模拟订单按历史K线撮合计算成交滑点。这种回测方式更贴近真实运营状态能暴露很多批处理回测看不到的问题比如信号堆积、执行冲突和延迟错位。场景回测通过之后进入纸面交易阶段。我把系统接到实时的市场数据流所有信号和订单意图照常生成但不真实下单而是做模拟撮合持续观察六到八周。这个阶段最重要的产出是系统行为在实盘环境下的稳定性、延迟分布、以及异常概率。纸面交易中我发现过几个重要问题比如周末隔夜新闻导致周一开盘信号堆积所有候选都挤在开盘竞价阶段执行互相之间产生冲击预测偏差这个问题后来通过在执行Agent里增加开盘后十五分钟内禁止市价单的规则才解决。6.3 我的个人判断这类系统适合什么样的策略实验做到后期我对LLM交易系统的能力边界有了比较明确的感知。它最适合的是事件驱动型中低频策略因为这类策略的信息源天然是文本决策频率从几分钟到几天不等给LLM留了充足的推理时间也容得下API成本和延迟。相反它不适合高频做市或者毫秒级套利那需要的是专用硬件和C级执行路径LLM在里面不仅帮不上忙反而会成为延迟包袱。在资产类别上股票和商品期货的文本信息最丰富表现相对好加密货币市场虽然文本也多但噪音更大、置信度虚高的问题更明显需要更严格的阈值过滤。我个人不建议一上来就把LLM策略放到实盘大资金上跑用总资金的一小部分做灰度、跑一段时间再逐步放量是更稳妥的路径。另外我强烈建议把LLM系统的输出和传统因子策略的输出做对照归因。建一个简单的绩效归因表按日跟踪两类策略各自的胜率和盈亏比。实测下来LLM信号在财报季和突发事件期的超额收益最明显而常规交易日里它并不比基本的动量因子好多少。这个结论直接说明了LLM的定位——它是个特异功能模块不是全能交易大脑。写在最后的实操体会整个项目做下来我自己最大的转变是从让LLM做交易决策变成了让LLM做语义翻译、人做规则、代码做风控。别再想着模型输出一个买字就完事真正值钱的是它把一段复杂文本压缩成结构化事件的能力以及把市场状态翻译成执行约束的能力。模型不是全知全能的交易大脑用对了它是一个非常好用的现场翻译。最后分享一个我认为最值得复制的小技巧在每次LLM输出里强制要求带上数据时间戳和来源编号。这个字段在回测和归因时救过我无数次——某次信号异常我靠来源编号几分钟就定位到是上游某条公告的文本编码出了问题没有它排查时间至少翻三倍。所有想尝试LLM交易系统的人先从这一行字段开始做起你不会后悔的。