尧图网站建设 
简介在信息技术与金融投资深度结合的今天AI大模型正逐步改变传统投研的工作方式。面对海量行情数据与碎片化信息投资者如何高效完成数据采集、信号识别与决策辅助本文从AI大模型的技术原理出发探讨如何利用Python自动化框架结合定时任务与消息推送机制构建一套覆盖数据采集、智能分析、多渠道推送的轻量级投研工作流。通过大模型对技术指标、资金流向及公告事件的结构化解读实现从“人工盯盘”到“智能助理”的范式转移并深度解析企业微信、飞书等场景下的工程落地细节。文章既包含通用的数据分析方法论也提供可复现的工程实践路径适合对量化投研与自动化运维感兴趣的开发者参考。 每天早上开盘前你打开行情软件自选股列表里几十只股票红的绿的跳成一片。哪个该重点关注、哪个可能要出风险、哪些指标发生了突变全靠一双眼睛扫。等你把公告、资金流向、技术指标逐个过完半小时过去了盘中的最佳操作窗口往往也已经错过。这个问题我跟身边好几个做交易的朋友聊过大家的痛点高度一致不是不想复盘是真的没时间把每一只股票都看透。所以我花了两个周末做了一套基于 AI 大模型的 A 股自选股智能分析系统。它每天定时拉取行情和基本面数据调用大模型生成结构化解读最终把一份浓缩过的“决策仪表盘”通过企业微信、飞书或者邮件推到我手机上。起床看一眼推送今天重点盯哪几只、哪些信号在恶化心里基本就有数了。这篇文章把整套系统的设计思路、核心源码逻辑、部署步骤和我在实际运行中踩过的坑完整写出来给同样有自选股跟踪需求的朋友一条可以快速复现的路径。1. 从盯盘到自动推送先想清楚要解决什么问题动手写代码之前我先把需求拆了一遍。这个系统本质上做的是三件事定时采集数据、交给 AI 做分析、把结果推到常用聊天工具。听起来简单但每一环都有不少细节坑先讲清楚我为什么这么设计。1.1 手动复盘做久了你会发现痛点集中在三处第一是数据分散。行情软件里能看 K 线和资金流但要看公告、业绩快报、龙虎榜又得切换到另一个网站再查一下北向资金变化又得换工具。一个自选股池二三十只票信息源至少四五个每天重复打开再关闭时间全耗在切换上了。第二是信息过载。每一只股票单看技术面就有 MACD、KDJ、RSI、布林带一堆指标再加上量能变化、均线排列、换手率数据一多反而抓不住重点。更麻烦的是这些指标经常给出互相矛盾的信号日线 MACD 金叉了但量能又明显萎缩你说到底是买入信号还是诱多第三是缺乏持续性跟踪。一个人靠记忆去跟踪几十只股票的公告和财务数据变化几乎不可能。今天看到某家公司发了业绩预增公告过两周可能就忘了。等到股价异动再去翻原因往往已经慢了半拍。这三个痛点决定了系统的核心需求数据采集要全、分析结果要精、推送要定时。不是做一个能实时刷新的“大而全”交易终端而是做一个每天早上告诉你“今天该看什么”的助理。1.2 为什么选择“AI 大模型 定时推送”而不是本地实时看盘大多数行情软件本身就有预警功能比如价格突破、涨跌幅异动这部分能力其实很强。真正缺的是一个能把多维度数据综合起来、生成结论性意见的环节。传统条件预警做不到的恰恰是“综合判断”它只能告诉你某一条规则触发了不会告诉你“这只股票近期量价配合良好但即将面临前期套牢盘压力建议关注回调风险”。AI 大模型在这里的位置不是替代行情软件而是当一个能把数据翻译成人话的分析师助理。把技术指标数值、资金流向、公告摘要这些数据丢给它让它输出结构化的判断再用固定模板推送出来这正好补上从“数据”到“决策信息”之间那段距离。推送渠道我选了企业微信、飞书和邮件三端。企业微信和飞书本身是很多人日常工作离不开的工具推送消息很容易被看到邮件则是兜底方案稳定性高、不依赖第三方机器人接口。1.3 系统的能力边界它能做什么不能做什么这部分我觉得必须提前讲清楚因为涉及到大家对这套系统的预期管理。这套系统能做的是每天定时生成一份基于公开数据的自选股状态报告包括行情变化、技术面信号、资金流向、近期公告事件以及 AI 对这些信息综合判断后的关注建议。它不能做的是预测涨停、给出买卖点、保证收益。所有 AI 输出都应该被当作“参考信息”而不是“投资指令”。我在设计推送模板的时候有意把 AI 的结论写成“关注方向”而不是“操作建议”。比如输出“建议关注压力位突破情况”而不是“建议买入”。这样一个措辞差别既是合规考虑也是让使用者保持独立思考。2. 系统整体架构与模块划分整套系统的代码结构我按数据采集、AI 分析、消息推送、任务调度四个模块来组织。这样的拆分逻辑很直白每一个模块可以独立替换或升级比如今天用企业微信明天想换个渠道不会影响其他部分。2.1 核心模块与文件规划stock_analyzer/ ├── main.py # 主入口串联整个流程 ├── config.py # 配置文件自选股、API Key、渠道参数 ├── collectors/ │ ├── market_data.py # 行情与技术指标采集 │ ├── fundamental.py # 基本面数据与公告采集 │ └── money_flow.py # 资金流向采集 ├── ai/ │ ├── llm_client.py # 大模型 API 封装 │ └── prompt_builder.py # 提示词模板与结构化输出解析 ├── notifiers/ │ ├── wecom.py # 企业微信机器人 │ ├── feishu.py # 飞书机器人 │ └── email_sender.py # 邮件发送 ├── scheduler/ │ └── task_runner.py # 定时任务与重试逻辑 ├── utils/ │ ├── logger.py # 日志模块 │ └── retry.py # 重试装饰器 └── requirements.txt模块拆分的核心原则是“单向依赖”。采集层不关心数据推给谁AI 层只负责接收结构化数据并返回文本推送层只负责把文本变成不同渠道的消息格式。后面我要换数据源、换模型甚至换推送平台都只改对应的一个文件。2.2 数据源的选择与配置A 股数据源我用的是 akshare免费、无需 token接口覆盖行情、财务、公告、资金流对个人项目来说足够用。如果你有 tushare 的积分也可以换成 tushare接口差异只需要在 collectors 模块里做适配不影响上层逻辑。这里要提醒一个实际运行中必踩的坑akshare 的接口偶尔会变因为它的数据源来自公开网页网页结构一变接口输出就可能出错。所以我在 collectors 里统一加了一层异常捕获和结果校验拉不到数据或者字段缺失的时候宁可跳过这只股票也不能让整个任务崩溃。行情数据我拉了这些字段最新价、涨跌幅、成交量、成交额、换手率、量比、市盈率、市净率以及 MACD 的 DIF/DEA/柱状值与金叉死叉状态。资金流数据用“个股资金流排名”接口取主力净流入额和净流入占比。基本面数据里我最看重的是业绩预告和公告这两项直接影响市场预期比历史财务指标更能解释短期走势。2.3 数据采集频率与缓存策略A 股盘前、盘中、盘后的数据价值完全不同。盘后采集的数据最稳定适合做“每日复盘”盘中采集虽然及时但对接口稳定性要求高而且盘中数据波动大AI 分析的价值反而有限。所以我默认的策略是每个交易日收盘后 15-30 分钟跑一次也就是下午 15:15 左右既避开了数据未结算的窗口又能赶在盘后复盘前把报告推出来。如果遇到重试失败系统会自动间隔 5 分钟再尝试最多重试 3 次。数据拉取结果我会在本地存一份 JSON 缓存哪天接口挂了至少还能基于上一份数据生成报告不会出现当天什么都没有的情况。3. AI 大模型接入要点选型、提示词与防幻觉系统的核心“智商”来自 AI 大模型。这一章我重点讲模型选型、提示词设计和我在实际测试中踩过的坑——模型输出不稳定、数据被幻觉化这些都是真实发生过的问题。3.1 模型选型开源还是 API成本怎么算接入大模型有两种主流方式直接调用商用 API或者本地部署开源模型。我一开始在本地跑过 Qwen 系列的开源模型配置要求不算离谱但对一台普通云服务器来说推理速度确实感人跑完整份自选股报告要七八分钟而且稍大的模型还容易爆内存。后来换成调用 API速度和稳定性立刻上来了成本也不算高。以我现在的方案为例每日生成一份 30 只自选股的报告输入数据约 6000-8000 tokens输出约 1200 tokens一天的成本大约在几毛钱级别。这个成本对于个人使用来说完全可以接受。如果你自选股池更大可以通过分批调用的方式控制单次请求长度。选模型时我比较看重三点中文理解能力、结构化输出稳定性、API 价格。目前主流的国产大模型 API 基本都满足我最后选的是在成本和输出质量之间比较均衡的一个。接入逻辑上我建议封装一个llm_client把厂商 SDK 的具体调用细节隔离在接口后面以后换模型只改一个文件。3.2 提示词设计把数据变成结构化建议提示词是整个系统里最值得反复打磨的部分。我踩过最深的坑是第一版提示词写得太“开放”只把数据丢给模型让它自由分析。结果输出的内容五花八门有的长篇大论有的一句话带过完全没法统一展示。后来我换成了“角色 任务 数据输入 输出要求”的四段式模板并严格要求 JSON 输出。这样做的好处是既保留了模型的推理能力又让输出格式可控。核心提示词长这样PROMPT_TEMPLATE 你是我的A股投资研究助理。请根据以下自选股数据生成分析报告。 数据如下 {stock_data} 请逐只股票分析输出为JSON数组每个元素包含以下字段 - stock_code: 股票代码 - stock_name: 股票名称 - trend: 趋势判断只允许取值为强势/震荡/弱势 - signals: 信号列表数组元素为具体信号描述 - risk: 主要风险点描述 - focus: 明日关注重点 - summary: 一句话总结不超过30字 要求 1. 只基于给定数据分析不要臆测数据之外的信息 2. 信号要具体例如MACD金叉且量能放大不要使用技术面良好这类模糊描述 3. 不要输出投资建议只用关注观察警惕等中性动词 4. JSON必须合法不要输出任何解释文字 注意第 2 条和第 3 条要求这是我实际测试后加上去的。有了“信号要具体”的限制模型输出从空话变成了可操作的提示有了“只用中性动词”的限制既避免合规风险也让输出语气稳定。3.3 防幻觉与结果校验数值检查、温度参数、兜底逻辑大模型幻觉问题在金融场景里格外不能忍。我遇到过模型把“净利润同比增长 23.5%”写成“同比下降”也遇到过它给出一只根本不在自选股池里的股票代码。于是我在 ai 模块里做了三层防护。第一层是温度参数调低。大多数 API 支持 temperature 参数我设置成 0.2。这样模型输出更确定自由度太高容易出现编造内容。第二层是 JSON 解析后的字段校验。解析结果后我会检查 stock_code 是否都在我的自选股列表里signals 是否为数组trend 取值是否在允许范围内。任何一项不满足就重新请求一次最多重试 2 次。第三层是数字一致性检查。我会把原始数据里的关键数值比如涨跌幅、换手率单独摘出来让模型在分析时把这些值原样嵌入到 summary 或 signals 里然后我用正则把返回内容里的数字和原始数据做交叉核对。如果发现明显矛盾就丢弃该只股票的 AI 分析只保留数据卡片。三层防护都过不去的情况输出里会带上“AI 分析暂时不可用”的标记推送数据表和数据卡片仍然正常发送。这套兜底逻辑非常重要宁可少一段 AI 点评也不要推一段可能误导人的错误分析。4. 决策仪表盘的内容设计信息密度与阅读顺序推送内容不是数据越多越好恰恰相反推送内容的门槛是“在手机上三秒钟能扫完重点”。我把整个仪表盘设计成三层结构最上面是今日异动摘要中间是自选股信号汇总表下面是每只股票的明细卡片。4.1 摘要层设计今天的市场在发生什么摘要层是 AI 对整个自选股池的全局观察。我让模型从所有股票的分析结果里提取三条最重要的信息比如“自选股中 5 只股票出现放量突破信号”“3 只股票主力资金净流出金额超过 5000 万”“某公司发布业绩预增公告”。如果当天没有特别值得关注的信号就输出“今日无重大异动”。这一层是每天早上最优先看的内容它决定了今天要不要花额外时间去深挖某只股票。为了生成摘要我把每只股票的结构化分析结果汇总成一个 JSON 数组再让模型跑一次摘要生成。相当于一次批量明细分析加一次全局总结。4.2 信号汇总表一张表看完整池状态信号汇总表用文字列表呈现每只股票一行。格式固定为“代码 名称 | 趋势 | 信号数量”例如600519 贵州茅台 | 震荡 | 信号2 000858 五粮液 | 弱势 | 信号3 300750 宁德时代 | 强势 | 信号1这张表的价值在于快速定位“异常”。看到信号数量从昨天的 1 变成今天 3我就知道这只股票今天发生了什么需要关注的事情。信号数量本身没有绝对好坏它的意义在于变化。再往下才是单只股票的明细卡片。每张卡片包含当日行情速览、技术信号列表、资金流向、相关公告、AI 综合判断、风险点、关注建议。这部分内容最长但在手机上可以做到一屏一只股票信息密度刚刚好。4.3 推送文案怎么组织才能让人“愿意看”我从用户阅读习惯出发做了两个设计。第一是摘要和明细分开每天早上先推摘要如果你觉得某只股票有看头再通过命令触发完整明细推送而不是一股脑塞一篇 5000 字长文。第二是给每只股票加了一个“关注等级”高、中、低。等级由数据规则自动判断比如涨停、放量突破、业绩预增都算高关注。有高关注股票的当天摘要里会用单独一段列出确保不会漏看。另外一个容易被忽略的细节推送时间是固定的。我自己设定的 15:30 盘后推送养成习惯之后基本形成条件反射了。系统能坚持每天准点推比偶尔推一篇超长深度报告更能建立信任感。5. 企业微信、飞书、邮箱三端推送的落地细节消息推送这块是表面上最简单、实际上细节最多的部分。三个渠道我都接了一轮各自踩过一些坑分别展开说说。5.1 企业微信机器人Webhook 配置与图片发送企业微信自定义机器人是最快的接入方式。在群里添加一个自定义机器人拿到 Webhook 地址往这个地址 POST 一段 JSON 就能发文本消息。核心代码不到二十行import requests import json WECOM_WEBHOOK_URL 你的企业微信机器人webhook地址 def send_wecom_text(content: str) - bool: payload {msgtype: text, text: {content: content}} resp requests.post(WECOM_WEBHOOK_URL, jsonpayload, timeout10) data resp.json() if data.get(errcode) ! 0: logger.error(f企业微信发送失败: {data}) return False return True注意事项Webhook URL 中包含机器人的 key泄露后任何人都能往群里发消息所以不要提交到公开代码仓库建议放环境变量或配置文件中。另外企业微信机器人有频率限制每分钟最多 20 条我的报告推一次只有一条消息完全不会触发。如果你希望推送图文卡片而不是纯文本可以改用 markdown 类型企业微信机器人支持msgtypemarkdown语法和普通 Markdown 基本一致手机端和电脑端都能正常渲染。有个坑我必须提醒企业微信机器人的 Markdown 支持列表有限表格是不支持的。一开始我把信号汇总表用 Markdown 表格写进去结果推送出来一团乱。后来改成了列表式排版或者干脆转成图片推送。图片方案我会在下面展开。5.2 飞书机器人消息卡片与富文本飞书自定义机器人的接入方式类似也是 Webhook。飞书的优势是消息卡片功能很完善支持更丰富的排版包括表格、按钮、交互组件。如果你主力用飞书体验会比企业微信好不少。我实际用的飞书消息类型是interactive卡片用 JSON 定义卡片结构。下面是一个简化版本def send_feishu_card(webhook_url: str, title: str, elements: list) - bool: card_payload { msg_type: interactive, card: { header: { title: {tag: plain_text, content: title}, template: blue }, elements: elements } } resp requests.post(webhook_url, jsoncard_payload, timeout10) return resp.json().get(code) 0elements 部分可以是div、hr、img等组件的组合。我这里用div组织每只股票的摘要用hr做分隔线整张卡片相当于一份结构化报告。飞书这里也要注意两个坑第一是消息卡片有大小限制如果推送内容太长飞书会直接拒绝所以卡片内容必须要精简正文超过一定长度就拆成多条卡片。第二是飞书自定义机器人的 Webhook 在群里配置群名和关键词不需要严格匹配但有安全设置选项建议开启签名校验避免被恶意调用。5.3 邮件推送HTML 模板与附件邮件作为兜底渠道好处是几乎没有长度限制而且可以附带附件。我用的是smtplib加email库发送 HTML 格式的邮件。把报告渲染成表格样式在电脑上阅读体验很好适合做完整的复盘存档。import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart def send_email(subject: str, html_content: str): msg MIMEMultipart() msg[Subject] subject msg[From] SMTP_USER msg[To] TO_ADDRESS msg.attach(MIMEText(html_content, html, utf-8)) with smtplib.SMTP_SSL(SMTP_HOST, SMTP_PORT) as server: server.login(SMTP_USER, SMTP_PASS) server.send_message(msg)使用 QQ 邮箱或 163 邮箱的话需要去设置里开启 SMTP 服务并生成授权码而不是使用登录密码。我最初在这里卡了很久一直报认证失败后来才发现要用授权码。邮件的 HTML 模板我建议直接用 Python 的字符串格式化把表格行循环生成并填充进模板。如果报告里需要包含图表可以先用 matplotlib 生成图表保存为 PNG再作为附件发送。5.4 多端同时推还是择一推怎么选我实际跑的配置是企业微信为主、邮件兜底飞书作为备用。主渠道推摘要和信号汇总表邮件推完整版日报存档。这样既保证重要信息第一时间触达又有完整记录可以回溯。如果你只需要一个渠道建议优先选日常工作最常用的那个。三个渠道我都做了配置但没必要全部开启推送渠道越多维护成本越高而且消息重复反而让人懒得看。6. 部署到服务器定时任务、日志与故障恢复本地电脑跑通之后真正的考验是把系统部署到 7x24 小时运行的服务器上。这里面的坑大多是“程序能跑”和“程序天天稳定跑”之间的差距。6.1 环境准备与目录结构我建议用云服务器部署操作系统选 Ubuntu 22.04 LTS。Python 环境用venv创建避免污染系统 Python。部署的基本步骤如下# 安装系统依赖 sudo apt update sudo apt install -y python3-venv python3-pip git # 克隆项目并进入目录 git clone https://your-repo/stock_analyzer.git cd stock_analyzer # 创建虚拟环境并安装依赖 python3 -m venv venv source venv/bin/activate pip install -r requirements.txt # 复制配置模板并修改 cp config.example.py config.py依赖安装时有个小坑akshare的依赖项比较多如果遇到安装失败多半是缺少系统级编译环境比如build-essential。安装一个就解决sudo apt install -y build-essential配置文件config.py里我集中放了所有可变参数自选股列表、API key、Webhook 地址、SMTP 配置、推送开关。改配置不用动代码这一点长期维护很重要。6.2 Cron 定时任务时区、环境变量、日志轮转定时任务我用的是系统 cron每天 15:20 触发。命令长这样15 20 * * 1-5 cd /opt/stock_analyzer /opt/stock_analyzer/venv/bin/python main.py /var/log/stock_analyzer.log 21注意三点。第一是 cron 执行时的环境变量和手动执行不一样PATH是精简版所以命令里必须使用 Python 绝对路径不能依赖python命令。第二是时区问题服务器默认时区不一定是东八区需要先确认时间是否正确不对的话用timedatectl set-timezone Asia/Shanghai修改。第三是日志重定向表示追加21让错误信息也写进同一个日志文件。另外我加了个logrotate配置让日志文件每周轮转一次保留 4 周避免单机运行几个月后日志文件撑爆磁盘。配置路径在/etc/logrotate.d/stock_analyzer/var/log/stock_analyzer.log { weekly rotate 4 compress missingok notifempty }6.3 失败重试与告警机制系统需要防的不是“正常运行”而是“异常情况下的处理”。我为采集环节和 AI 分析环节都加了重试装饰器重试间隔递增比如第一次等待 1 分钟、第二次 5 分钟、第三次 15 分钟。import time from functools import wraps def retry(max_retries3, delay60): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: logger.warning(f{func.__name__} 第{attempt1}次失败: {e}) if attempt max_retries - 1: time.sleep(delay * (attempt 1)) else: raise return wrapper return decorator如果重试次数用完还是失败我要能第一时间知道。所以我在主流程里加了一个全局异常捕获任何重大异常都会调用企业微信机器人往自己的“告警专用群”里发一条错误消息而不是让任务静默失败。系统跑了一个多月告警消息一共收到过三次两次是 akshare 接口结构变化一次是服务器内存不足导致进程被杀。这些如果没做告警我可能过好多天才会发现报告停了。6.4 Docker 部署的补充思路项目跑稳定之后我也把它容器化了一份Docker 部署的主要收益是环境隔离和迁移方便。基础镜像用python:3.11-slim安装依赖后挂载配置文件和日志目录即可。如果你的服务器上同时跑着多个 Python 项目容器化能省掉很多依赖冲突的麻烦。需要注意的坑容器里跑 cron 不太方便我采用的是容器启动后跑一个 Python 版定时循环用schedule库而不是在宿主机上配 cron。如果你想用 Docker 但又想保留 cron 的直观性也可以让容器只跑任务、由宿主机的 cron 来触发docker exec两种思路都有人用看你的维护习惯。7. 运行几个月后的观察与优化方向系统上线之后我做了几个版本的优化迭代也总结了一些真实运行数据。这部分内容来自持续使用中的反馈希望能帮大家少走弯路。7.1 信号质量的真实反馈运行初期我的信号规则偏敏感稍微有点放量就标记为“高关注”。结果推送了几天之后我自己都麻木了看到高关注也没了感觉。后来我调整了关注等级规则至少满足两个条件才标“高关注”比如“涨幅超过 3% 且主力净流入为正”。假信号明显减少推送的可靠性提升了一个台阶。AI 分析的质量则和输入数据的质量强相关。开始的时候我直接把财务数据里的几十个字段一股脑丢给模型结果模型输出抓不住重点。后来我按照“行情表现、技术信号、资金信号、公告事件”四个维度整理输入模型给出的分析明显更有针对性。这给我一个重要启发大模型不是给的数据越多越聪明而是给结构化的、去噪之后的数据才能发挥真正的分析能力。7.2 结合现有工具链的更多玩法运行稳定之后我又自己做了一个基于 Dify 的自动化编排版本把数据采集和 LLM 分析变成了可编排的工作流。如果你本身就在用 Dify可以直接把采集结果通过 API 节点传入工作流再通过工作流的结束节点回调推送渠道。这种做法的好处是提示词和流程可以可视化修改不需要改代码就能迭代分析逻辑。至于热词里有人提到的“人狗大作战 python 代码”这类项目和本文不是一回事但如果你想练手练熟 Python 语法和事件循环那种小游戏项目确实是不错的基础练习。另外如果你的自选股池里有可转债也可以参考这篇文章的思路把可转债的数据源接进来分析逻辑稍微调整即可复用。7.3 后续值得做的三个扩展方向我目前列了三个扩展方向准备逐步做进去。第一是接入更多另类数据源。比如北向资金个股持仓变化、融资融券余额变化、龙虎榜机构席位数据。这些维度对判断市场情绪很有帮助目前我还没全部整合进来。第二是历史信号的自动跟踪回测。把系统每天推送的信号记录下来一周、一个月后回看这些信号对应的后续走势积累数据后能评估信号质量的真实水平。我现在有一套简单的信号打点机制但离完整回测还有距离。第三是多模型对比生成。同一个数据集让不同的大模型分别分析再把多份分析结果合并生成一份综合报告。不同模型的侧重点会有差异综合之后能减少单一模型的盲区。代价是成本和耗时都会增加更适合自选股池比较小的情况。8. 盘点我踩过的那些坑从接口失效到消息格式这一章把所有我在开发和运行过程中遇到的具体问题集中列出来每一个都是真实发生过并修复过的。如果你要复现这个系统提前知道这些坑能省不少时间。8.1 akshare 接口变化的应对与降级akshare 的接口变化频率比我预期高得多。有一次“个股资金流排名”接口的返回字段从net_inflow改成了main_net_inflow我的代码直接 KeyError 崩溃。从那之后我做了两件事第一是采集函数里用.get()而不是直接索引并加字段缺失默认值第二是每次运行结束生成一份数据字典的 schema 快照接口变动时对比快照就能快速发现差异。8.2 企业微信 markdown 表格渲染问题前面提到过企业微信的 markdown 并不支持表格。我自己踩了这个坑以后改成了图片推送方案。用 matplotlib 把信号汇总表渲染成一张长图然后调企业微信的素材接口先上传图片、拿到 media_id再用图片消息类型推送。效果比纯文本好很多手机上看图也更直观。唯一需要注意的是 matplotlib 默认中文字体显示会有问题需要配置中文字体具体代码如下import matplotlib.pyplot as plt from matplotlib import font_manager # 注册中文字体 font_path /usr/share/fonts/truetype/wqy/wqy-zenhei.ttc font_manager.fontManager.addfont(font_path) plt.rcParams[font.family] font_manager.FontProperties(fnamefont_path).get_name()8.3 AI 接口限流与成本控制商用大模型 API 一般都有 RPM每分钟请求数限制。我的报告生成流程里如果自选股池有 30 只我选择的是分批调用接口每批 5 只共 6 次请求。加上摘要生成 1 次总共 7 次请求基本不会触达限流。如果你自选股池超过 50 只建议考虑把数据压缩后一次性调用或改成本地小模型做简单排序、大模型只分析排序后的候选股。成本控制方面我加了一个预算上限检查每次生成报告前先估算本次请求的 token 用量如果超过预设阈值就自动减少输入字段并提示“本期报告为精简模式”。这个机制确保了即使自选股池扩大成本也不会失控。8.4 服务器重启后的自动恢复系统部署到服务器之后我担心的是服务器重启之后任务没有自动拉起。虽然 cron 服务在系统启动时会自动加载但如果日志文件目录、虚拟环境路径被改动任务也可能静默失败。所以我加了一个systemd服务单元用来跑一个健康检查脚本每 10 分钟检查一次今天的目标报告是否已经生成如果 18 点前还没生成就主动补跑一次任务。这样就解决了“报告忘记生成”的问题即使 cron 环境有问题也能及时发现。9. 源码获取、安装部署与环境配置全流程很多朋友关心源码怎么拿、拿到之后多长时间能跑通。我这里把整个部署流程串成一份从零开始的 checklist跟着走大概一小时内可以完成。9.1 环境依赖清单项目对系统环境的要求非常低主要依赖如下依赖库版本要求用途Python3.10运行环境akshare1.12A股数据采集pandas1.5数据处理openai1.x大模型 API 调用requests2.28HTTP 请求matplotlib3.7生成图片消息schedule1.2Docker 内定时调度以上依赖全部写进requirements.txtpip install -r requirements.txt一条命令搞定。9.2 配置项逐项说明config.py里每一项配置我都写了注释这里挑几个容易配错的说明# 自选股列表格式为 [(代码, 名称)] STOCK_POOL [ (600519, 贵州茅台), (000858, 五粮液), (300750, 宁德时代), ] # 大模型 API 配置 LLM_API_KEY sk-xxxx # API的密钥 LLM_BASE_URL https://api.openai.com/v1 # 兼容接口的地址 LLM_MODEL gpt-4o-mini # 模型名称 # 企业微信机器人 Webhook WECOM_WEBHOOK_URL https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx # 邮件 SMTP 配置 SMTP_HOST smtp.qq.com SMTP_PORT 465 SMTP_USER yourqq.com SMTP_PASS 你的授权码有几个隐藏细节值得强调。LLM_BASE_URL使用 OpenAI 兼容接口时不同厂商的地址不同需要按服务商文档填写。邮箱授权码不是 QQ 密码而是 QQ 邮箱设置里单独生成的“授权码”这个搞错的话会一直报认证失败。Webhook URL 不要带多余空格经常有人复制的时候把换行符也带进去导致签名验证失败。9.3 首次运行与验证配置完成后第一次建议手动运行cd /opt/stock_analyzer source venv/bin/activate python main.py --test加--test参数时程序只分析自选股池里第一只股票并推送到所有已开启的渠道。这样能快速验证数据采集、AI 调用、渠道推送是否全部正常。验证通过后再取消--test参数交给 cron 自动调度。这里有一个经验不要一上来就配置全套自选股。先放三五只测试等跑通 3 天稳定了再把完整的自选股池加进去。这看起来多了一步实际上能省去大量排查数据异常的时间。10. 这套系统给我的最大收获把时间从盯盘里抢回来最后回到个人使用感受上。系统跑起来之后改变最大的不是“收益”而是每天花在盯盘上的时间大幅减少。以前我早上开盘前要花四十分钟整理自选股信息现在十分钟就能完成同样甚至更全面的复盘。省下来的时间我拿来做更多的数据分析和系统迭代形成了正向反馈。我也要再次强调这套系统本质上是一个信息整理与提醒工具它的价值在于帮你快速定位值得关注的变化而不是替你作决策。真正的买卖判断仍然需要结合自己的交易体系、风险承受能力和市场的实时变化。如果你打算搭建一套类似系统我的建议是先从最小版本开始一只股票的数据采集加到企业微信群推送跑通后再逐步增加股票数量、增加 AI 分析、增加更多渠道。直接照抄完整系统的所有功能很容易半途而废但从小处着手每周迭代一个小功能两三周就能拥有一套真正属于你自己的智能分析助手。如果你对某个模块的实现细节有疑问欢迎在评论区交流。我后续会根据大家反馈补写更细分的教程比如 Dify 版本的工作流配置、量化信号回测体系或者企业微信图片消息的完整实现。关注不迷路实操过程中踩了什么新坑我也会继续回来更新。本文还有配套的精品资源点击获取 基于AI大模型的A股自选股智能分析系统设计与实践
简介在信息技术与金融投资深度结合的今天AI大模型正逐步改变传统投研的工作方式。面对海量行情数据与碎片化信息投资者如何高效完成数据采集、信号识别与决策辅助本文从AI大模型的技术原理出发探讨如何利用Python自动化框架结合定时任务与消息推送机制构建一套覆盖数据采集、智能分析、多渠道推送的轻量级投研工作流。通过大模型对技术指标、资金流向及公告事件的结构化解读实现从“人工盯盘”到“智能助理”的范式转移并深度解析企业微信、飞书等场景下的工程落地细节。文章既包含通用的数据分析方法论也提供可复现的工程实践路径适合对量化投研与自动化运维感兴趣的开发者参考。 每天早上开盘前你打开行情软件自选股列表里几十只股票红的绿的跳成一片。哪个该重点关注、哪个可能要出风险、哪些指标发生了突变全靠一双眼睛扫。等你把公告、资金流向、技术指标逐个过完半小时过去了盘中的最佳操作窗口往往也已经错过。这个问题我跟身边好几个做交易的朋友聊过大家的痛点高度一致不是不想复盘是真的没时间把每一只股票都看透。所以我花了两个周末做了一套基于 AI 大模型的 A 股自选股智能分析系统。它每天定时拉取行情和基本面数据调用大模型生成结构化解读最终把一份浓缩过的“决策仪表盘”通过企业微信、飞书或者邮件推到我手机上。起床看一眼推送今天重点盯哪几只、哪些信号在恶化心里基本就有数了。这篇文章把整套系统的设计思路、核心源码逻辑、部署步骤和我在实际运行中踩过的坑完整写出来给同样有自选股跟踪需求的朋友一条可以快速复现的路径。1. 从盯盘到自动推送先想清楚要解决什么问题动手写代码之前我先把需求拆了一遍。这个系统本质上做的是三件事定时采集数据、交给 AI 做分析、把结果推到常用聊天工具。听起来简单但每一环都有不少细节坑先讲清楚我为什么这么设计。1.1 手动复盘做久了你会发现痛点集中在三处第一是数据分散。行情软件里能看 K 线和资金流但要看公告、业绩快报、龙虎榜又得切换到另一个网站再查一下北向资金变化又得换工具。一个自选股池二三十只票信息源至少四五个每天重复打开再关闭时间全耗在切换上了。第二是信息过载。每一只股票单看技术面就有 MACD、KDJ、RSI、布林带一堆指标再加上量能变化、均线排列、换手率数据一多反而抓不住重点。更麻烦的是这些指标经常给出互相矛盾的信号日线 MACD 金叉了但量能又明显萎缩你说到底是买入信号还是诱多第三是缺乏持续性跟踪。一个人靠记忆去跟踪几十只股票的公告和财务数据变化几乎不可能。今天看到某家公司发了业绩预增公告过两周可能就忘了。等到股价异动再去翻原因往往已经慢了半拍。这三个痛点决定了系统的核心需求数据采集要全、分析结果要精、推送要定时。不是做一个能实时刷新的“大而全”交易终端而是做一个每天早上告诉你“今天该看什么”的助理。1.2 为什么选择“AI 大模型 定时推送”而不是本地实时看盘大多数行情软件本身就有预警功能比如价格突破、涨跌幅异动这部分能力其实很强。真正缺的是一个能把多维度数据综合起来、生成结论性意见的环节。传统条件预警做不到的恰恰是“综合判断”它只能告诉你某一条规则触发了不会告诉你“这只股票近期量价配合良好但即将面临前期套牢盘压力建议关注回调风险”。AI 大模型在这里的位置不是替代行情软件而是当一个能把数据翻译成人话的分析师助理。把技术指标数值、资金流向、公告摘要这些数据丢给它让它输出结构化的判断再用固定模板推送出来这正好补上从“数据”到“决策信息”之间那段距离。推送渠道我选了企业微信、飞书和邮件三端。企业微信和飞书本身是很多人日常工作离不开的工具推送消息很容易被看到邮件则是兜底方案稳定性高、不依赖第三方机器人接口。1.3 系统的能力边界它能做什么不能做什么这部分我觉得必须提前讲清楚因为涉及到大家对这套系统的预期管理。这套系统能做的是每天定时生成一份基于公开数据的自选股状态报告包括行情变化、技术面信号、资金流向、近期公告事件以及 AI 对这些信息综合判断后的关注建议。它不能做的是预测涨停、给出买卖点、保证收益。所有 AI 输出都应该被当作“参考信息”而不是“投资指令”。我在设计推送模板的时候有意把 AI 的结论写成“关注方向”而不是“操作建议”。比如输出“建议关注压力位突破情况”而不是“建议买入”。这样一个措辞差别既是合规考虑也是让使用者保持独立思考。2. 系统整体架构与模块划分整套系统的代码结构我按数据采集、AI 分析、消息推送、任务调度四个模块来组织。这样的拆分逻辑很直白每一个模块可以独立替换或升级比如今天用企业微信明天想换个渠道不会影响其他部分。2.1 核心模块与文件规划stock_analyzer/ ├── main.py # 主入口串联整个流程 ├── config.py # 配置文件自选股、API Key、渠道参数 ├── collectors/ │ ├── market_data.py # 行情与技术指标采集 │ ├── fundamental.py # 基本面数据与公告采集 │ └── money_flow.py # 资金流向采集 ├── ai/ │ ├── llm_client.py # 大模型 API 封装 │ └── prompt_builder.py # 提示词模板与结构化输出解析 ├── notifiers/ │ ├── wecom.py # 企业微信机器人 │ ├── feishu.py # 飞书机器人 │ └── email_sender.py # 邮件发送 ├── scheduler/ │ └── task_runner.py # 定时任务与重试逻辑 ├── utils/ │ ├── logger.py # 日志模块 │ └── retry.py # 重试装饰器 └── requirements.txt模块拆分的核心原则是“单向依赖”。采集层不关心数据推给谁AI 层只负责接收结构化数据并返回文本推送层只负责把文本变成不同渠道的消息格式。后面我要换数据源、换模型甚至换推送平台都只改对应的一个文件。2.2 数据源的选择与配置A 股数据源我用的是 akshare免费、无需 token接口覆盖行情、财务、公告、资金流对个人项目来说足够用。如果你有 tushare 的积分也可以换成 tushare接口差异只需要在 collectors 模块里做适配不影响上层逻辑。这里要提醒一个实际运行中必踩的坑akshare 的接口偶尔会变因为它的数据源来自公开网页网页结构一变接口输出就可能出错。所以我在 collectors 里统一加了一层异常捕获和结果校验拉不到数据或者字段缺失的时候宁可跳过这只股票也不能让整个任务崩溃。行情数据我拉了这些字段最新价、涨跌幅、成交量、成交额、换手率、量比、市盈率、市净率以及 MACD 的 DIF/DEA/柱状值与金叉死叉状态。资金流数据用“个股资金流排名”接口取主力净流入额和净流入占比。基本面数据里我最看重的是业绩预告和公告这两项直接影响市场预期比历史财务指标更能解释短期走势。2.3 数据采集频率与缓存策略A 股盘前、盘中、盘后的数据价值完全不同。盘后采集的数据最稳定适合做“每日复盘”盘中采集虽然及时但对接口稳定性要求高而且盘中数据波动大AI 分析的价值反而有限。所以我默认的策略是每个交易日收盘后 15-30 分钟跑一次也就是下午 15:15 左右既避开了数据未结算的窗口又能赶在盘后复盘前把报告推出来。如果遇到重试失败系统会自动间隔 5 分钟再尝试最多重试 3 次。数据拉取结果我会在本地存一份 JSON 缓存哪天接口挂了至少还能基于上一份数据生成报告不会出现当天什么都没有的情况。3. AI 大模型接入要点选型、提示词与防幻觉系统的核心“智商”来自 AI 大模型。这一章我重点讲模型选型、提示词设计和我在实际测试中踩过的坑——模型输出不稳定、数据被幻觉化这些都是真实发生过的问题。3.1 模型选型开源还是 API成本怎么算接入大模型有两种主流方式直接调用商用 API或者本地部署开源模型。我一开始在本地跑过 Qwen 系列的开源模型配置要求不算离谱但对一台普通云服务器来说推理速度确实感人跑完整份自选股报告要七八分钟而且稍大的模型还容易爆内存。后来换成调用 API速度和稳定性立刻上来了成本也不算高。以我现在的方案为例每日生成一份 30 只自选股的报告输入数据约 6000-8000 tokens输出约 1200 tokens一天的成本大约在几毛钱级别。这个成本对于个人使用来说完全可以接受。如果你自选股池更大可以通过分批调用的方式控制单次请求长度。选模型时我比较看重三点中文理解能力、结构化输出稳定性、API 价格。目前主流的国产大模型 API 基本都满足我最后选的是在成本和输出质量之间比较均衡的一个。接入逻辑上我建议封装一个llm_client把厂商 SDK 的具体调用细节隔离在接口后面以后换模型只改一个文件。3.2 提示词设计把数据变成结构化建议提示词是整个系统里最值得反复打磨的部分。我踩过最深的坑是第一版提示词写得太“开放”只把数据丢给模型让它自由分析。结果输出的内容五花八门有的长篇大论有的一句话带过完全没法统一展示。后来我换成了“角色 任务 数据输入 输出要求”的四段式模板并严格要求 JSON 输出。这样做的好处是既保留了模型的推理能力又让输出格式可控。核心提示词长这样PROMPT_TEMPLATE 你是我的A股投资研究助理。请根据以下自选股数据生成分析报告。 数据如下 {stock_data} 请逐只股票分析输出为JSON数组每个元素包含以下字段 - stock_code: 股票代码 - stock_name: 股票名称 - trend: 趋势判断只允许取值为强势/震荡/弱势 - signals: 信号列表数组元素为具体信号描述 - risk: 主要风险点描述 - focus: 明日关注重点 - summary: 一句话总结不超过30字 要求 1. 只基于给定数据分析不要臆测数据之外的信息 2. 信号要具体例如MACD金叉且量能放大不要使用技术面良好这类模糊描述 3. 不要输出投资建议只用关注观察警惕等中性动词 4. JSON必须合法不要输出任何解释文字 注意第 2 条和第 3 条要求这是我实际测试后加上去的。有了“信号要具体”的限制模型输出从空话变成了可操作的提示有了“只用中性动词”的限制既避免合规风险也让输出语气稳定。3.3 防幻觉与结果校验数值检查、温度参数、兜底逻辑大模型幻觉问题在金融场景里格外不能忍。我遇到过模型把“净利润同比增长 23.5%”写成“同比下降”也遇到过它给出一只根本不在自选股池里的股票代码。于是我在 ai 模块里做了三层防护。第一层是温度参数调低。大多数 API 支持 temperature 参数我设置成 0.2。这样模型输出更确定自由度太高容易出现编造内容。第二层是 JSON 解析后的字段校验。解析结果后我会检查 stock_code 是否都在我的自选股列表里signals 是否为数组trend 取值是否在允许范围内。任何一项不满足就重新请求一次最多重试 2 次。第三层是数字一致性检查。我会把原始数据里的关键数值比如涨跌幅、换手率单独摘出来让模型在分析时把这些值原样嵌入到 summary 或 signals 里然后我用正则把返回内容里的数字和原始数据做交叉核对。如果发现明显矛盾就丢弃该只股票的 AI 分析只保留数据卡片。三层防护都过不去的情况输出里会带上“AI 分析暂时不可用”的标记推送数据表和数据卡片仍然正常发送。这套兜底逻辑非常重要宁可少一段 AI 点评也不要推一段可能误导人的错误分析。4. 决策仪表盘的内容设计信息密度与阅读顺序推送内容不是数据越多越好恰恰相反推送内容的门槛是“在手机上三秒钟能扫完重点”。我把整个仪表盘设计成三层结构最上面是今日异动摘要中间是自选股信号汇总表下面是每只股票的明细卡片。4.1 摘要层设计今天的市场在发生什么摘要层是 AI 对整个自选股池的全局观察。我让模型从所有股票的分析结果里提取三条最重要的信息比如“自选股中 5 只股票出现放量突破信号”“3 只股票主力资金净流出金额超过 5000 万”“某公司发布业绩预增公告”。如果当天没有特别值得关注的信号就输出“今日无重大异动”。这一层是每天早上最优先看的内容它决定了今天要不要花额外时间去深挖某只股票。为了生成摘要我把每只股票的结构化分析结果汇总成一个 JSON 数组再让模型跑一次摘要生成。相当于一次批量明细分析加一次全局总结。4.2 信号汇总表一张表看完整池状态信号汇总表用文字列表呈现每只股票一行。格式固定为“代码 名称 | 趋势 | 信号数量”例如600519 贵州茅台 | 震荡 | 信号2 000858 五粮液 | 弱势 | 信号3 300750 宁德时代 | 强势 | 信号1这张表的价值在于快速定位“异常”。看到信号数量从昨天的 1 变成今天 3我就知道这只股票今天发生了什么需要关注的事情。信号数量本身没有绝对好坏它的意义在于变化。再往下才是单只股票的明细卡片。每张卡片包含当日行情速览、技术信号列表、资金流向、相关公告、AI 综合判断、风险点、关注建议。这部分内容最长但在手机上可以做到一屏一只股票信息密度刚刚好。4.3 推送文案怎么组织才能让人“愿意看”我从用户阅读习惯出发做了两个设计。第一是摘要和明细分开每天早上先推摘要如果你觉得某只股票有看头再通过命令触发完整明细推送而不是一股脑塞一篇 5000 字长文。第二是给每只股票加了一个“关注等级”高、中、低。等级由数据规则自动判断比如涨停、放量突破、业绩预增都算高关注。有高关注股票的当天摘要里会用单独一段列出确保不会漏看。另外一个容易被忽略的细节推送时间是固定的。我自己设定的 15:30 盘后推送养成习惯之后基本形成条件反射了。系统能坚持每天准点推比偶尔推一篇超长深度报告更能建立信任感。5. 企业微信、飞书、邮箱三端推送的落地细节消息推送这块是表面上最简单、实际上细节最多的部分。三个渠道我都接了一轮各自踩过一些坑分别展开说说。5.1 企业微信机器人Webhook 配置与图片发送企业微信自定义机器人是最快的接入方式。在群里添加一个自定义机器人拿到 Webhook 地址往这个地址 POST 一段 JSON 就能发文本消息。核心代码不到二十行import requests import json WECOM_WEBHOOK_URL 你的企业微信机器人webhook地址 def send_wecom_text(content: str) - bool: payload {msgtype: text, text: {content: content}} resp requests.post(WECOM_WEBHOOK_URL, jsonpayload, timeout10) data resp.json() if data.get(errcode) ! 0: logger.error(f企业微信发送失败: {data}) return False return True注意事项Webhook URL 中包含机器人的 key泄露后任何人都能往群里发消息所以不要提交到公开代码仓库建议放环境变量或配置文件中。另外企业微信机器人有频率限制每分钟最多 20 条我的报告推一次只有一条消息完全不会触发。如果你希望推送图文卡片而不是纯文本可以改用 markdown 类型企业微信机器人支持msgtypemarkdown语法和普通 Markdown 基本一致手机端和电脑端都能正常渲染。有个坑我必须提醒企业微信机器人的 Markdown 支持列表有限表格是不支持的。一开始我把信号汇总表用 Markdown 表格写进去结果推送出来一团乱。后来改成了列表式排版或者干脆转成图片推送。图片方案我会在下面展开。5.2 飞书机器人消息卡片与富文本飞书自定义机器人的接入方式类似也是 Webhook。飞书的优势是消息卡片功能很完善支持更丰富的排版包括表格、按钮、交互组件。如果你主力用飞书体验会比企业微信好不少。我实际用的飞书消息类型是interactive卡片用 JSON 定义卡片结构。下面是一个简化版本def send_feishu_card(webhook_url: str, title: str, elements: list) - bool: card_payload { msg_type: interactive, card: { header: { title: {tag: plain_text, content: title}, template: blue }, elements: elements } } resp requests.post(webhook_url, jsoncard_payload, timeout10) return resp.json().get(code) 0elements 部分可以是div、hr、img等组件的组合。我这里用div组织每只股票的摘要用hr做分隔线整张卡片相当于一份结构化报告。飞书这里也要注意两个坑第一是消息卡片有大小限制如果推送内容太长飞书会直接拒绝所以卡片内容必须要精简正文超过一定长度就拆成多条卡片。第二是飞书自定义机器人的 Webhook 在群里配置群名和关键词不需要严格匹配但有安全设置选项建议开启签名校验避免被恶意调用。5.3 邮件推送HTML 模板与附件邮件作为兜底渠道好处是几乎没有长度限制而且可以附带附件。我用的是smtplib加email库发送 HTML 格式的邮件。把报告渲染成表格样式在电脑上阅读体验很好适合做完整的复盘存档。import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart def send_email(subject: str, html_content: str): msg MIMEMultipart() msg[Subject] subject msg[From] SMTP_USER msg[To] TO_ADDRESS msg.attach(MIMEText(html_content, html, utf-8)) with smtplib.SMTP_SSL(SMTP_HOST, SMTP_PORT) as server: server.login(SMTP_USER, SMTP_PASS) server.send_message(msg)使用 QQ 邮箱或 163 邮箱的话需要去设置里开启 SMTP 服务并生成授权码而不是使用登录密码。我最初在这里卡了很久一直报认证失败后来才发现要用授权码。邮件的 HTML 模板我建议直接用 Python 的字符串格式化把表格行循环生成并填充进模板。如果报告里需要包含图表可以先用 matplotlib 生成图表保存为 PNG再作为附件发送。5.4 多端同时推还是择一推怎么选我实际跑的配置是企业微信为主、邮件兜底飞书作为备用。主渠道推摘要和信号汇总表邮件推完整版日报存档。这样既保证重要信息第一时间触达又有完整记录可以回溯。如果你只需要一个渠道建议优先选日常工作最常用的那个。三个渠道我都做了配置但没必要全部开启推送渠道越多维护成本越高而且消息重复反而让人懒得看。6. 部署到服务器定时任务、日志与故障恢复本地电脑跑通之后真正的考验是把系统部署到 7x24 小时运行的服务器上。这里面的坑大多是“程序能跑”和“程序天天稳定跑”之间的差距。6.1 环境准备与目录结构我建议用云服务器部署操作系统选 Ubuntu 22.04 LTS。Python 环境用venv创建避免污染系统 Python。部署的基本步骤如下# 安装系统依赖 sudo apt update sudo apt install -y python3-venv python3-pip git # 克隆项目并进入目录 git clone https://your-repo/stock_analyzer.git cd stock_analyzer # 创建虚拟环境并安装依赖 python3 -m venv venv source venv/bin/activate pip install -r requirements.txt # 复制配置模板并修改 cp config.example.py config.py依赖安装时有个小坑akshare的依赖项比较多如果遇到安装失败多半是缺少系统级编译环境比如build-essential。安装一个就解决sudo apt install -y build-essential配置文件config.py里我集中放了所有可变参数自选股列表、API key、Webhook 地址、SMTP 配置、推送开关。改配置不用动代码这一点长期维护很重要。6.2 Cron 定时任务时区、环境变量、日志轮转定时任务我用的是系统 cron每天 15:20 触发。命令长这样15 20 * * 1-5 cd /opt/stock_analyzer /opt/stock_analyzer/venv/bin/python main.py /var/log/stock_analyzer.log 21注意三点。第一是 cron 执行时的环境变量和手动执行不一样PATH是精简版所以命令里必须使用 Python 绝对路径不能依赖python命令。第二是时区问题服务器默认时区不一定是东八区需要先确认时间是否正确不对的话用timedatectl set-timezone Asia/Shanghai修改。第三是日志重定向表示追加21让错误信息也写进同一个日志文件。另外我加了个logrotate配置让日志文件每周轮转一次保留 4 周避免单机运行几个月后日志文件撑爆磁盘。配置路径在/etc/logrotate.d/stock_analyzer/var/log/stock_analyzer.log { weekly rotate 4 compress missingok notifempty }6.3 失败重试与告警机制系统需要防的不是“正常运行”而是“异常情况下的处理”。我为采集环节和 AI 分析环节都加了重试装饰器重试间隔递增比如第一次等待 1 分钟、第二次 5 分钟、第三次 15 分钟。import time from functools import wraps def retry(max_retries3, delay60): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: logger.warning(f{func.__name__} 第{attempt1}次失败: {e}) if attempt max_retries - 1: time.sleep(delay * (attempt 1)) else: raise return wrapper return decorator如果重试次数用完还是失败我要能第一时间知道。所以我在主流程里加了一个全局异常捕获任何重大异常都会调用企业微信机器人往自己的“告警专用群”里发一条错误消息而不是让任务静默失败。系统跑了一个多月告警消息一共收到过三次两次是 akshare 接口结构变化一次是服务器内存不足导致进程被杀。这些如果没做告警我可能过好多天才会发现报告停了。6.4 Docker 部署的补充思路项目跑稳定之后我也把它容器化了一份Docker 部署的主要收益是环境隔离和迁移方便。基础镜像用python:3.11-slim安装依赖后挂载配置文件和日志目录即可。如果你的服务器上同时跑着多个 Python 项目容器化能省掉很多依赖冲突的麻烦。需要注意的坑容器里跑 cron 不太方便我采用的是容器启动后跑一个 Python 版定时循环用schedule库而不是在宿主机上配 cron。如果你想用 Docker 但又想保留 cron 的直观性也可以让容器只跑任务、由宿主机的 cron 来触发docker exec两种思路都有人用看你的维护习惯。7. 运行几个月后的观察与优化方向系统上线之后我做了几个版本的优化迭代也总结了一些真实运行数据。这部分内容来自持续使用中的反馈希望能帮大家少走弯路。7.1 信号质量的真实反馈运行初期我的信号规则偏敏感稍微有点放量就标记为“高关注”。结果推送了几天之后我自己都麻木了看到高关注也没了感觉。后来我调整了关注等级规则至少满足两个条件才标“高关注”比如“涨幅超过 3% 且主力净流入为正”。假信号明显减少推送的可靠性提升了一个台阶。AI 分析的质量则和输入数据的质量强相关。开始的时候我直接把财务数据里的几十个字段一股脑丢给模型结果模型输出抓不住重点。后来我按照“行情表现、技术信号、资金信号、公告事件”四个维度整理输入模型给出的分析明显更有针对性。这给我一个重要启发大模型不是给的数据越多越聪明而是给结构化的、去噪之后的数据才能发挥真正的分析能力。7.2 结合现有工具链的更多玩法运行稳定之后我又自己做了一个基于 Dify 的自动化编排版本把数据采集和 LLM 分析变成了可编排的工作流。如果你本身就在用 Dify可以直接把采集结果通过 API 节点传入工作流再通过工作流的结束节点回调推送渠道。这种做法的好处是提示词和流程可以可视化修改不需要改代码就能迭代分析逻辑。至于热词里有人提到的“人狗大作战 python 代码”这类项目和本文不是一回事但如果你想练手练熟 Python 语法和事件循环那种小游戏项目确实是不错的基础练习。另外如果你的自选股池里有可转债也可以参考这篇文章的思路把可转债的数据源接进来分析逻辑稍微调整即可复用。7.3 后续值得做的三个扩展方向我目前列了三个扩展方向准备逐步做进去。第一是接入更多另类数据源。比如北向资金个股持仓变化、融资融券余额变化、龙虎榜机构席位数据。这些维度对判断市场情绪很有帮助目前我还没全部整合进来。第二是历史信号的自动跟踪回测。把系统每天推送的信号记录下来一周、一个月后回看这些信号对应的后续走势积累数据后能评估信号质量的真实水平。我现在有一套简单的信号打点机制但离完整回测还有距离。第三是多模型对比生成。同一个数据集让不同的大模型分别分析再把多份分析结果合并生成一份综合报告。不同模型的侧重点会有差异综合之后能减少单一模型的盲区。代价是成本和耗时都会增加更适合自选股池比较小的情况。8. 盘点我踩过的那些坑从接口失效到消息格式这一章把所有我在开发和运行过程中遇到的具体问题集中列出来每一个都是真实发生过并修复过的。如果你要复现这个系统提前知道这些坑能省不少时间。8.1 akshare 接口变化的应对与降级akshare 的接口变化频率比我预期高得多。有一次“个股资金流排名”接口的返回字段从net_inflow改成了main_net_inflow我的代码直接 KeyError 崩溃。从那之后我做了两件事第一是采集函数里用.get()而不是直接索引并加字段缺失默认值第二是每次运行结束生成一份数据字典的 schema 快照接口变动时对比快照就能快速发现差异。8.2 企业微信 markdown 表格渲染问题前面提到过企业微信的 markdown 并不支持表格。我自己踩了这个坑以后改成了图片推送方案。用 matplotlib 把信号汇总表渲染成一张长图然后调企业微信的素材接口先上传图片、拿到 media_id再用图片消息类型推送。效果比纯文本好很多手机上看图也更直观。唯一需要注意的是 matplotlib 默认中文字体显示会有问题需要配置中文字体具体代码如下import matplotlib.pyplot as plt from matplotlib import font_manager # 注册中文字体 font_path /usr/share/fonts/truetype/wqy/wqy-zenhei.ttc font_manager.fontManager.addfont(font_path) plt.rcParams[font.family] font_manager.FontProperties(fnamefont_path).get_name()8.3 AI 接口限流与成本控制商用大模型 API 一般都有 RPM每分钟请求数限制。我的报告生成流程里如果自选股池有 30 只我选择的是分批调用接口每批 5 只共 6 次请求。加上摘要生成 1 次总共 7 次请求基本不会触达限流。如果你自选股池超过 50 只建议考虑把数据压缩后一次性调用或改成本地小模型做简单排序、大模型只分析排序后的候选股。成本控制方面我加了一个预算上限检查每次生成报告前先估算本次请求的 token 用量如果超过预设阈值就自动减少输入字段并提示“本期报告为精简模式”。这个机制确保了即使自选股池扩大成本也不会失控。8.4 服务器重启后的自动恢复系统部署到服务器之后我担心的是服务器重启之后任务没有自动拉起。虽然 cron 服务在系统启动时会自动加载但如果日志文件目录、虚拟环境路径被改动任务也可能静默失败。所以我加了一个systemd服务单元用来跑一个健康检查脚本每 10 分钟检查一次今天的目标报告是否已经生成如果 18 点前还没生成就主动补跑一次任务。这样就解决了“报告忘记生成”的问题即使 cron 环境有问题也能及时发现。9. 源码获取、安装部署与环境配置全流程很多朋友关心源码怎么拿、拿到之后多长时间能跑通。我这里把整个部署流程串成一份从零开始的 checklist跟着走大概一小时内可以完成。9.1 环境依赖清单项目对系统环境的要求非常低主要依赖如下依赖库版本要求用途Python3.10运行环境akshare1.12A股数据采集pandas1.5数据处理openai1.x大模型 API 调用requests2.28HTTP 请求matplotlib3.7生成图片消息schedule1.2Docker 内定时调度以上依赖全部写进requirements.txtpip install -r requirements.txt一条命令搞定。9.2 配置项逐项说明config.py里每一项配置我都写了注释这里挑几个容易配错的说明# 自选股列表格式为 [(代码, 名称)] STOCK_POOL [ (600519, 贵州茅台), (000858, 五粮液), (300750, 宁德时代), ] # 大模型 API 配置 LLM_API_KEY sk-xxxx # API的密钥 LLM_BASE_URL https://api.openai.com/v1 # 兼容接口的地址 LLM_MODEL gpt-4o-mini # 模型名称 # 企业微信机器人 Webhook WECOM_WEBHOOK_URL https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx # 邮件 SMTP 配置 SMTP_HOST smtp.qq.com SMTP_PORT 465 SMTP_USER yourqq.com SMTP_PASS 你的授权码有几个隐藏细节值得强调。LLM_BASE_URL使用 OpenAI 兼容接口时不同厂商的地址不同需要按服务商文档填写。邮箱授权码不是 QQ 密码而是 QQ 邮箱设置里单独生成的“授权码”这个搞错的话会一直报认证失败。Webhook URL 不要带多余空格经常有人复制的时候把换行符也带进去导致签名验证失败。9.3 首次运行与验证配置完成后第一次建议手动运行cd /opt/stock_analyzer source venv/bin/activate python main.py --test加--test参数时程序只分析自选股池里第一只股票并推送到所有已开启的渠道。这样能快速验证数据采集、AI 调用、渠道推送是否全部正常。验证通过后再取消--test参数交给 cron 自动调度。这里有一个经验不要一上来就配置全套自选股。先放三五只测试等跑通 3 天稳定了再把完整的自选股池加进去。这看起来多了一步实际上能省去大量排查数据异常的时间。10. 这套系统给我的最大收获把时间从盯盘里抢回来最后回到个人使用感受上。系统跑起来之后改变最大的不是“收益”而是每天花在盯盘上的时间大幅减少。以前我早上开盘前要花四十分钟整理自选股信息现在十分钟就能完成同样甚至更全面的复盘。省下来的时间我拿来做更多的数据分析和系统迭代形成了正向反馈。我也要再次强调这套系统本质上是一个信息整理与提醒工具它的价值在于帮你快速定位值得关注的变化而不是替你作决策。真正的买卖判断仍然需要结合自己的交易体系、风险承受能力和市场的实时变化。如果你打算搭建一套类似系统我的建议是先从最小版本开始一只股票的数据采集加到企业微信群推送跑通后再逐步增加股票数量、增加 AI 分析、增加更多渠道。直接照抄完整系统的所有功能很容易半途而废但从小处着手每周迭代一个小功能两三周就能拥有一套真正属于你自己的智能分析助手。如果你对某个模块的实现细节有疑问欢迎在评论区交流。我后续会根据大家反馈补写更细分的教程比如 Dify 版本的工作流配置、量化信号回测体系或者企业微信图片消息的完整实现。关注不迷路实操过程中踩了什么新坑我也会继续回来更新。本文还有配套的精品资源点击获取