社区分享来的策略，增加了部分功能，判断牛熊市场对默认持仓日期和每日开仓数进行调整。策略中有每个指标调整值回测率的记录，方便调试。 在2024年2月6日至2025年1月31日之间，回测收益率超过100%，最大到过120左右。 目前存在问题：1、 24年2月起大盘大跌，目前还没有增加对大盘暴跌不开仓并清仓的处理能力，后期会逐步完善。 2、只进行回测和模拟，没有进入实盘，具体实盘收益不清楚。 从社区取得收获分享给社区。策略提供参考，有错误或优化建议请提出，在此表示感谢。 融资融券杠杆资金3个月走势分析（2026/7/31 – 2026/10/29） 说明：最新交易日 10/30 的两融数据尚未收全（当日仅统计到 1.22 万亿，明显低于正常水平），图中以 10/29 为最新完整数据点。该篇报告由StockApi智能体自动化分析总结而来。 一、核心数据总表（两融余额单位：亿元） 日期 两融余额 融资余额 融资买入占成交额 阶段特征 7/31 26,113 — 9.54% 加杠杆初期 8/18 26,979★峰值 ~26,700 9.49% 杠杆冲顶（情绪最热） 8/20 26,664 26,395 9.02% 高位松动 8/31 26,647 26,355 — 横盘 9/18 26,382 26,087 8.02% 温和回落 9/30 25,699 25,405 — 单日融资净流出392 亿 10/16 24,889 24,597 6.30% 去杠杆加速 10/23 24,318 24,027 6.29% 31 个行业全线净流出 10/29 23,850 23,567 6.11% 仍在流出 关键变化：峰值→最新，两融余额减少 3,130 亿元（-11.6%），融资余额减少约 11%，融资买入占成交额从 9.80% 高点降至 6.11%（-38%）。 二、图形化：三个阶段一目了然 图1｜两融余额阶梯式下降（每格 ≈100 亿，基数为 23,500 亿） 7/31 26,113 ██████████████████████████ 加杠杆 8/07 26,475 ██████████████████████████████ 8/14 26,739 ████████████████████████████████ 8/18 26,979 ███████████████████████████████████ ★峰值 8/28 26,647 ███████████████████████████████ 9/04 26,378 █████████████████████████████ 9/11 26,316 ████████████████████████████ 高位横盘 9/18 26,382 █████████████████████████████ 9/24 26,373 █████████████████████████████ 9/30 25,699 ██████████████████████ 拐点 10/09 25,597 █████████████████████ 10/16 24,889 ██████████████ 加速去杠杆 10/23 24,318 ████████ 10/29 23,850 ████ ← 仍在下行 图2｜杠杆资金参与度（融资买入额/成交额，越靠右越冷） 8月 ▅██▇█▇▇██▇██▆▇ 均值 9.2% 过热区 9月 ▄▃▄▃▅▄▄▃▃▃▃▅▄▅ 均值 7.5% 降温 10月 ▂▂▂▂▂▁▁▂▂▂▁▁▂▁▃▁ 均值 6.4% 冷区 ↑8月17日峰值9.80% ↑10月22日低点5.97% ↑10/29 6.11% 图3｜杠杆与指数同向下行，但创业板跌幅远大于杠杆收缩幅度 指标 8月高点 10/30 最新 区间涨跌 两融余额 26,979（8/18） 23,850（10/29） -11.6% 上证指数 3,990（8/18） 3,599.02 -9.8% 深证成指 14,704（8/17） 10,833.78 -26.3% 创业板指 3,740（8/17） 2,413.63 -35.5% 沪深300ETF — 4.065 元 -11.7% 成交同步萎缩：上证日成交额从 8/19 的 1.22 万亿降至 10/30 的 7,642 亿（-37%）；创业板成交额从 7,348 亿降至 4,542 亿。量价与杠杆三者同步走弱，是典型的去杠杆下跌结构。 三、结构拆解：这不是空头行情，是多头去杠杆 融券端几乎没动：融券余额 9/30 为 293.96 亿，占两融余额仅 1.14%，全月基本持平（8/31 为 292.71 亿）。做空力量不是主导，纯多头撤退。 融资端连续大额净流出：9/30 单日 -392 亿、10/15 -314 亿、10/29 -263 亿、10/23 -243 亿、10/22 -234 亿。10 月 16 个交易日累计 -1,849 亿（-7.2%），去杠杆速度约为 9 月（-949 亿）的 2 倍。 行业上系统性撤出：10/12–10/16 当周 31 个申万一级行业仅 1 个获融资净买入，电子 -263.58 亿、通信 -121.55 亿、电力设备 -59.17 亿；10/19–10/23 当周 31 个行业全部净流出（电子 -134.34 亿、电力设备 -88.46 亿、通信 -86.16 亿）。→ 流出集中在科技成长，与创业板 -35% 完全对应。 杠杆水位仍偏高：两融余额占 A 股流通市值 10/16 为 2.70%、10/23 为 2.66%，仍高于历史常见的中枢水平（约 2.3%–2.5%）。这意味着去杠杆还有空间，尚未到“出清”状态。 四、结论 杠杆资金已明确转熊，且尚未见底：8/18 见顶后连续 2 个多月单边回落，累计 -3,130 亿；10 月流出速度还在加快，10/29 单日仍净流出 263 亿，没有任何企稳信号。 下跌由多头被动减仓和市值缩水造成，并非空头主动进攻：融券余额几乎零变化，说明这不是“做空砸盘”，而是杠杆多头在亏损中出现被动平仓与主动降杠杆的循环。 杠杆交易的市场弹性已大幅下降：融资买入占比 6.1%，意味着“杠杆资金推涨”的引擎熄火，市场进入缩量阴跌、反弹缺乏持续性的状态。 创业板的风险释放远未完成：创业板指跌 35.5%，而两融仅收缩 11.6%，且 2.66% 的杠杆水位仍偏高，成长股仍有被动平仓的潜在抛压。 从时间节奏看，10 月是主力去杠杆阶段，尚未结束；后续要确认底部，至少需要：单日融资净流出收窄至 50 亿以内、连续 3 日转为净买入，同时融资买入占比回到 7% 以上。目前两者均未出现。 操作建议 方向：观望（防御为主，不抄底）。杠杆去化未完成、指数处 3 个月新低，任何反弹都先按反抽处理。 标的： 防御底仓：沪深300ETF华泰柏瑞（510300），规模 1,578 亿元、流动性最好，近 3 个月 -11.7%，适合分批定投而非一次性买入； 抗跌替代：红利低波类策略（中证红利低波 100 近 3 个月仅 -1.2%，远强于沪深300 的 -11.7%），注意 159228 规模仅 1.07 亿、流动性一般，宜选同类规模更大的品种； 回避：电子、通信、电力设备（融资净流出前三的行业）及创业板高贝塔成长股。 板块概念：高股息红利、大盘价值、公用事业类防御；回避 AI 算力、半导体设备、锂电等融资盘密集的成长赛道。 仓位：权益总仓位降至 40%–50%，其中红利与宽基占七成以上；融资杠杆仓位清零，不要在下跌趋势中使用两融。 参考价位： 上证指数 3,600 已失守，下方观察 3,550 / 3,450；反弹压力区 3,700–3,750（10/19–10/21 密集成交区）、3,800–3,850； 创业板指 2,400 为心理关口，2,500–2,550（10/29 前成交密集区）为反弹压力。 风控： 若两融单日净流出再超 300 亿，权益仓位进一步降至 30% 以下； 创业板指有效跌破 2,400，成长类持仓无条件减半； 加仓的唯一触发条件——两融余额连续 3 个交易日净买入 + 融资买入占比回升至 7% 以上 + 指数站上 5 日均线并伴随成交额回升，三者同时满足才可加仓至 60%。 风险提示：以上内容基于StockApi智能体公开两融与行情数据的技术与资金面分析，不构成投资建议；杠杆资金数据存在统计口径差异，10/30 数据尚未收全，请以交易所官方披露为准。 游资活跃股共振：别人画像，你直接看聚合结果 本文由 StockApi 智能体基于最近游资活跃股、月游资排行榜与龙虎榜接口整理撰写，代码可直接运行复现。 引言 跟游资的难点从来不是"找不到游资"，而是画像成本太高：拉三个月交割单、按席位统计胜率、再盯当日龙虎榜交叉验证——这套流程认真做完要一天，等你做完，行情走完了。 但有一类"懒人友好"的数据：平台已经替你完成聚合的游资信号。比如「最近五日各大游资买入金额大于 8000 万且关注度比较高的票」这种现成股池——它已经把"哪些票正在被多个大资金营业部反复光顾"这件事算好了。你要做的不是从零画像，而是把聚合股池、月度席位排行、当日龙虎榜三层共振起来用：股池给"最近谁热"，月榜给"哪路游资在主导"，龙虎榜给"今天有没有真金白银确认"。 策略原理 本篇用到StockApi的四个接口 接口（中文名） 路径 在策略里做什么 最近游资活跃股 /v1/activeYouziStocks 近 5 日游资大额买入 + 高关注度的聚合股池（10 次/天，必须落库，交易日 18:00 更新） 月游资排行榜单 /v1/youziRank 当月席位买入排行，识别主导资金风格 龙虎榜查询 /v1/base/dragonTiger 当日上榜明细与净买额，做最后确认 股票日/周/月 K 线行情 /v1/base/day 近 5 日涨幅，过滤已处高位的热度股（涨幅 > 60% 只看不买） 字段中文对照 字段 中文含义 备注 total_count 总上榜次数 近 5 日该票被游资关注的总次数 big_count 大额营业部次数 单笔 > 8000 万的营业部上榜次数 yyb_count 营业部个数 涉及的营业部数量，越分散越健康 diff_total_count 较昨日总次数变化 增量信号：今天又多了一批游资进来 diff_yyb_count 较昨日营业部个数变化 新营业部加入 = 关注度扩散 total_je_formatted 总净额（格式化字符串） 已格式化，数值比较需清洗 bk_info 所属板块 用于板块聚集度判断 close（日 K 口径） 个股收盘价 5 日涨幅 = 收盘 / 5 日前收盘 − 1，过滤高位票 buyAmountRatio 买入额占成交额比（龙虎榜口径） ≥ 5% 说明上榜买入是真仓位 三层共振流程（18:00 数据更新后） 热度层（游资活跃股接口）：取 total_count ≥ 3 且 big_count ≥ 2 的票；重点看增量：diff_total_count > 0 或 diff_yyb_count > 0 的票——游资是做加法的票才有接力价值，次数开始环比下降的票是热度尾声。 主导层（月游资排行接口）：确认当月排行前列的席位属于"接力型"还是"一日游型"——接力型席位主导的活跃股，次日参与胜率显著更高；这个判断不需要精算，看月榜前十的名字性质即可。 确认层（龙虎榜接口）：候选票当日若上龙虎榜，要求买入额占成交额比 ≥ 5% 且净买额为正——把"热度高但今日实际在出货"的票剔除。 位置过滤（日 K 接口）：近 5 日涨幅 > 60% 的票只观察不参与——游资活跃股里最危险的就是这些高位票，热度还在但赔率已经反转。 执行：通过全部过滤的票，次日开盘涨幅 ≤ 3% 参与，持有 3 个交易日，跌破买入价 5% 离场。 与"游资席位跟随"篇（前作）的分工：那一篇是从交割单自下而上画像（适合深研少数席位）；这一篇是自上而下用聚合结果（适合每天批量过一遍全市场）。前者精度高、成本高；后者成本低、覆盖广。两条路都通，按精力分配。 为什么"增量字段"比"存量字段"值钱 活跃股池里 total_count 大的票，可能已经热了四天——你看到的时候就是接盘的时候。真正有预测力的是 diff_* 系列变化量： 状态 total_count diff_total_count 含义 动作 热度启动 3—5 +1 或更多 新游资刚进场 最佳介入窗口 热度维持 6—10 ≈ 0 老面孔原地踏步 观察，等增量 热度衰竭 ≥ 8 负数 游资开始撤 回避 聚合接口最容易被用成"买热度最高的票"——正好用反。存量表筛选，增量表决策，这是所有聚合类数据的通用法则。 Python 完整实现 import os import re import time import requests import pandas as pd TOKEN = os.getenv("STOCKAPI_TOKEN", "你的Token") BASE = "https://www.stockapi.com.cn/v1" def call(path, **params): params["token"] = TOKEN r = requests.get(f"{BASE}{path}", params=params, timeout=15) r.raise_for_status() d = r.json() if d.get("code") == 20000: return d["data"] raise RuntimeError(f"{path} 调用失败: {d.get('msg')}") def to_num(s): """清洗 'total_je_formatted' 这类格式化字符串（如 '1.2亿'、'3456万'）""" if isinstance(s, (int, float)): return float(s) m = re.match(r"([\d.]+)(亿|万)?", str(s)) if not m: return None v = float(m.group(1)) return v * 1e8 if m.group(2) == "亿" else v * 1e4 if m.group(2) == "万" else v # ---------- 1. 热度层：活跃股池（每天最多 10 次调用，落库复用） ---------- def active_pool(trade_date): df = pd.DataFrame(call("/activeYouziStocks", tradeDate=trade_date) or []) if df.empty: return df for c in ["total_count", "big_count", "yyb_count", "diff_total_count", "diff_yyb_count"]: if c in df.columns: df[c] = pd.to_numeric(df[c], errors="coerce") if "total_je_formatted" in df.columns: df["total_je"] = df["total_je_formatted"].map(to_num) df["code"] = df["code"].astype(str).str.zfill(6) return df # ---------- 2. 日 K：5 日涨幅过滤高位票 ---------- def zf5(code): d = call("/base/day", code=code, startDate="2026-09-01", endDate="2026-10-29", calculationCycle=100) k = pd.DataFrame({c: v for c, v in d.items() if isinstance(v, list)}) k["time"] = pd.to_datetime(k["time"]) k = k.sort_values("time") k["close"] = pd.to_numeric(k["close"], errors="coerce") if len(k) < 6: return None return k["close"].iloc[-1] / k["close"].iloc[-6] - 1 # ---------- 3. 确认层：龙虎榜净买 ---------- def dragon_ok(code, trade_date): df = pd.DataFrame(call("/base/dragonTiger", tradeDate=trade_date) or []) if df.empty: return False for c in df.columns: try: df[c] = pd.to_numeric(df[c], errors="ignore") except (TypeError, ValueError): pass row = df[df["code"].astype(str).str.zfill(6) == code] if row.empty: return True # 未上榜不否决，交给热度层判断 return row["buyAmountRatio"].iloc[0] >= 5 # ---------- 4. 主流程：增量共振 ---------- def resonance(date): pool = active_pool(date) if pool.empty: return pd.DataFrame() hot = pool[(pool["total_count"] >= 3) & (pool["big_count"] >= 2) & ((pool["diff_total_count"] > 0) | (pool["diff_yyb_count"] > 0))] picks = [] for c in hot["code"]: z = zf5(c) # 高位票过滤：5 日涨幅 > 60% 只观察 if z is not None and z > 0.60: continue if dragon_ok(c, date): picks.append(c) out = hot[hot["code"].isin(picks)].copy() return out.sort_values("diff_total_count", ascending=False) res = resonance("2026-10-28") print(res[["code", "name", "total_count", "diff_total_count", "big_count"]].head(10).to_string(index=False)) 回测指标怎么读 指标 典型量级（示意） 说明 每日共振票数 1—6 只 增量条件过滤后并不多 3 日持有胜率 55%—65% 龙虎榜净买确认贡献主要 平均持有收益 2%—6% 3 日短持有，快进快出 最大风险 高位票断板补跌 用开盘 ≤ 3% 与 5% 止损控制 活跃股池每天只有 10 次调用，回测需逐日落库积累；先用龙虎榜 + 涨停池近似回放，落库两周后再用真实聚合数据校准。 参数与风控 参数 默认 调整方向 总上榜次数下限 3 提高到 5 更聚焦头部 增量条件 diff 任一 > 0 收紧为 diff_total_count ≥ 2 次日参与上限 开盘 ≤ 3% 高开太多的票次日溢价已被吃掉 持有期 3 交易日 游资接力周期通常不超过一周 风控三条： 接口 10 次/天的调用限额是硬约束：每天收盘后调用一次并落库，绝不在盘中浪费调用次数。 候选票若位于 5 日涨幅 > 60% 的位置，只观察不参与——游资活跃股里高危的正是这些高位票。 月榜席位的风格会漂移（接力型游资也会改打一日游），每月重新评估一次主导席位性质，不要用上个月的印象。 常见问题（FAQ） Q：活跃股池和交割单画像（游资席位跟随篇）数据有什么区别？ A：活跃股池是平台预聚合的股票维度数据（哪些票热、增量如何），交割单是原始的席位维度数据（谁在买、买多少）。前者开箱即用但无法细拆席位；后者自由度最高但要自己写画像逻辑。按"批量筛选用池、深度研究用单"的原则分配。 Q：total_je_formatted 为什么是字符串？ A：该字段是给人看的格式化文本（"1.2亿"）。做数值比较必须先清洗：正则提取数字与单位（亿/万），换算回元。代码里的 to_num 就是干这个的——直接 pd.to_numeric 会全部变 NaN。 Q：为什么候选票没上龙虎榜也算通过？ A：龙虎榜有上榜门槛，游资小仓位试错的票不一定上榜。未上榜不否决，上榜才做净买校验——龙虎榜在这一层是"证伪工具"（发现上榜但净卖出的票），不是"证实工具"。 跌停池 × 炸板池：情绪冰点日的「错杀股」反抽 本文由 StockApi 智能体基于跌停股池、炸板股池、情绪周期与日 K 接口整理撰写，代码可直接运行复现。 引言 情绪冰点日是短线客最难熬、也是赔率最好的一天：跌停几十家、涨停寥寥无几，恐慌到连强势股都被砸出跌停。这种日子的第二天，市场经常出现技术性反抽——不是所有跌停都是该跌的，相当一部分是情绪错杀。 但抄跌停是所有抄底里最危险的姿势：真利空跌停后面还有十个跌停。这个策略的核心是区分「错杀」和「该杀」，靠三个结构证据：封单撤了多少（封不死说明有资金在接）、开板开了几次（反复开板 = 多空在交换筹码，不是单边出逃）、它昨天是不是涨停/炸板（从涨停被砸下来的才叫错杀，阴跌了半个月的跌停叫补跌）。跌停股池、炸板股池、情绪周期三个接口正好把这三件事全部量化。 策略原理 本篇用到的StockApi四个接口 接口（中文名） 路径 在策略里做什么 跌停股池 /v1/base/DTPool 当日跌停股结构：连续跌停天数、开板次数、封单（交易日 15:30 更新） 炸板股池 /v1/base/ZBPool 当日曾涨停但收盘未封住的票，识别"从涨停被砸下来"的错杀路径 情绪周期 /v1/base/emotionalCycle 判定冰点日与恐慌收敛 股票日/周/月 K 线行情 /v1/base/day 次日开盘价与当日均价，确定低吸执行价 字段中文对照 字段 中文含义 备注 days 连续跌停天数 = 1 才是首板跌停（错杀候选），≥ 2 的连续跌停不碰 oc 开板次数 跌停板打开的次数，≥ 3 说明有资金反复接 ceilingAmount 封单资金 跌停口径下是封住跌停的卖单金额，越小越好 fba 板上成交额 跌停价位上成交的金额，有成交说明有人接飞刀 bombNum 炸板次数 炸板池口径，昨日涨停被砸的次数 ztjs / dtjs 涨停家数 / 跌停家数 冰点判定：dtjs ≥ 前5日均值 × 2 且 ztjs < 30 close / open 收盘价 / 开盘价 次日低吸的执行参照 冰点判定 + 错杀识别（收盘后） 冰点日判定（情绪周期接口）：当日跌停家数 ≥ 前 5 日均值的 2 倍，且涨停家数 < 30。冰点日是整个策略的触发器，不是冰点日不启动。 错杀筛选（跌停股池接口）：在当日跌停池里筛 days = 1（首日跌停，不是连续阴跌的补跌） oc ≥ 3（跌停反复被打开，有承接） ceilingAmount / 流通市值 < 0.5%（跌停封单薄，封不死） 错杀路径确认（炸板股池接口）：候选票昨日出现在涨停池或今日出现在炸板池——从涨停/炸板跌到跌停的票才是情绪错杀；一路阴跌型跌停剔除。 次日执行（日 K 接口）：次日开盘低开 2%—4% 时买入（低开太深说明有利空未出尽，高开说明反抽已抢跑）；当日反抽 ≥ 5% 兑现一半，尾盘留一半；次日收盘前无条件清仓。冰点反抽是 T+1 游戏，不恋战。 为什么"开板次数"是错杀最强的证据 跌停板上的开板，每一场都是多空的一次正面交锋： 跌停形态 开板次数 封单变化 本质 次日倾向 一字跌停 0 封单巨大且增加 单边出逃/重大利空 继续跌 尾盘封死 0—1 收盘才封上 恐慌宣泄不充分 隔日继续宣泄 反复开板 ≥ 3 封单被反复打穿 有资金在跌停位持续承接 反抽概率最高 开板次数多意味着跌停价位上实际发生了大量成交——恐慌盘的卖压被吃掉了。配合「封单占比 < 0.5%」，筛出来的就是"想砸的砸完了、想接的接到了"的票。 Python 完整实现 import os import requests import pandas as pd TOKEN = os.getenv("STOCKAPI_TOKEN", "你的Token") BASE = "https://www.stockapi.com.cn/v1" def call(path, **params): params["token"] = TOKEN r = requests.get(f"{BASE}{path}", params=params, timeout=15) r.raise_for_status() d = r.json() if d.get("code") == 20000: return d["data"] raise RuntimeError(f"{path} 调用失败: {d.get('msg')}") # ---------- 1. 冰点判定（情绪周期） ---------- def ice_day(date): d = call("/base/emotionalCycle") df = pd.DataFrame(d["contentList"], columns=d["colNameList"]) df["dt"] = pd.to_datetime(df["date1"].astype(str), format="%Y%m%d") df = df[df["dt"] < pd.Timestamp(date)].sort_values("dt") dt_cnt = pd.to_numeric(df["dtjs"], errors="coerce") zt_cnt = pd.to_numeric(df["ztjs"], errors="coerce") today_dt = dt_cnt.iloc[-1] return today_dt >= dt_cnt.tail(6).head(5).mean() * 2 and zt_cnt.iloc[-1] < 30 # ---------- 2. 跌停池错杀筛选 ---------- def dt_candidates(date): df = pd.DataFrame(call("/base/DTPool", date=date) or []) if df.empty: return df for c in ["days", "oc", "ceilingAmount", "flowCapital", "fba"]: if c in df.columns: df[c] = pd.to_numeric(df[c], errors="coerce") df["code"] = df["code"].astype(str).str.zfill(6) cond = (df["days"] == 1) & (df["oc"] >= 3) & \ (df["ceilingAmount"] / df["flowCapital"].replace(0, pd.NA) < 0.005) return df[cond] # ---------- 3. 炸板路径确认 ---------- def path_ok(code, date): zb = pd.DataFrame(call("/base/ZBPool", date=date) or []) if zb.empty: return False return code in zb["code"].astype(str).str.zfill(6).values # ---------- 4. 主流程 ---------- def ice_rebound_watchlist(date): if not ice_day(date): return "非冰点日，不启动" cands = dt_candidates(date) picks = [c for c in cands["code"] if path_ok(c, date)] return cands[cands["code"].isin(picks)][ ["code", "name", "oc", "ceilingAmount", "fba"]] watch = ice_rebound_watchlist("2026-10-28") print(watch) 回测指标怎么读 指标 典型量级（示意） 说明 冰点日频率 每季度 1—3 次 策略天然低频，等待是主要成本 每次入选票数 2—8 只 冰点日规模越大候选越多 次日反抽 ≥ 5% 概率 50%—60% 三重结构过滤后的水平 失败情形 次日继续大跌 由"低开 2%—4% 才买"与 T+1 清仓兜底 回测方式：遍历历史，对每个冰点日执行同一筛选，统计次日开盘买入后的 T+1 收盘收益。三个池子接口都支持按历史日期查询，可完整回放。 参数与风控 参数 默认 调整方向 冰点倍数 2×前5日均值 收紧到 3× 更极端、更少 开板次数下限 3 放宽到 2 信号更多、质量下降 次日低吸区间 低开 2%—4% 超出区间放弃，宁缺毋滥 持仓期 次日收盘清仓 冰点反抽不过夜到第三天 风控三条： 连续跌停（days ≥ 2）的票无论结构多好都不碰——首日跌停是情绪，连续跌停大概率是基本面。 候选票若当晚出现利空公告（业绩雷、监管问询），次日无论开在哪个位置都放弃。 单次冰点反抽总仓位 ≤ 2 成，这是情绪博弈不是价值投资，错了就走。 常见问题（FAQ） Q：跌停池的 ceilingAmount 在跌停语境下是什么？ A：是封住跌停的卖单金额，方向与涨停池相反。所以这里它是"封死下跌的力量"——越小越封不死、越有承接机会，筛选条件是 < 而不是 >。字段同名方向相反，是这两个池子最容易混淆的地方。 Q：为什么一定要叠加炸板池确认？ A：跌停池只说明"今天跌停了"，炸板池说明"它今天曾经涨到过涨停"。有这个路径的票才是从抢筹到踩踏的情绪反转，波动最大、反抽动力最强；而平稳阴跌到跌停的票没有情绪记忆，反抽动力弱。 Q：这个策略和涨停池系的龙头策略什么关系？ A：正好是硬币的两面：13—16 篇做的是情绪进攻端的"强上强"，本篇做的是情绪崩溃端的"错杀修复"。两者的环境判定都来自情绪周期接口——涨停家数高做前者，跌停家数极端做后者，刚好填满情绪光谱的两端。 免责声明：本文为策略研究与技术分享，不构成任何投资建议。市场有风险，入市需谨慎。 请大家不要客气，任何意见建议可以在这里评论提出。 被采纳后我们将奖励1G研究环境内存 3个月。 股票和外汇的数据接口，拉回来就能用。期货不一样——同样是"行情"，期货多了一层合约的概念：同一品种有主力合约、连续合约，还分不同到期月份；交易所有好几家，还有夜盘。第一次做期货监控的时候，我以为就是多调几个接口的事，结果被合约体系和换月问题折腾得不轻。这篇把我搭的一套多品种期货数据管道完整记录下来：合约代码怎么认、批量快照怎么拿、实时推送怎么接、主力换月怎么处理。数据源用的 iTick，token 去它官网 itick.org 申请，REST 和 WebSocket 共用一套。 期货合约体系：先认识代码，再谈接入 期货跟股票最大的区别就是"品种"和"合约"是两个概念。股票一个代码就是一个公司，期货一个品种下面有多个合约，接口里用"品种代码"来标识： 品种 代码 市场 region 说明 股指期货（沪深300） IF 中国 CN 中金所 黄金 GC 美国 US COMEX 白银 SI 美国 US COMEX 原油 CL 美国 US NYMEX 大豆 ZS 美国 US CBOT 纳指期货 NQ 美国 US CME 标普期货 ES 美国 US CME 接口统一用 region + code 定位一个品种。认准这几个主流代码，后面调接口就不会发懵。 REST批量快照：一个请求拿全品种 监控面板启动时要初始化所有品种的状态，用批量报价接口一次拉全，别一个个循环调： import requests API_BASE = "https://api.itick.org" headers = {"accept": "application/json", "token": "your_token_here"} def fetch_futures_snapshots(codes="GC,SI,CL,ZS,NQ,ES,IF"): # /future/quotes 批量报价，codes 用英文逗号分隔 # 返回 dict，key 是品种代码 resp = requests.get( f"{API_BASE}/future/quotes", headers=headers, params={"region": "US", "codes": codes}, ) return resp.json()["data"] snap = fetch_futures_snapshots() for symbol, q in snap.items(): print(symbol, q["ld"], q["chp"], q["ts"]) 返回的每个品种都是一个报价对象，字段 s/ld/o/p/h/l/t/v/tu/ts/ch/chp：ld 最新价、p 前日收盘价、ts 交易状态、ch/chp 涨跌。有几个点值得注意： 返回是 dict 不是数组，key 是品种代码，遍历时用 for symbol, q in snap.items() p 前收字段是期货报价特有的，算涨跌额直接用 ld - p 批量接口的参数是 codes（复数），写 code 会报参数错误 ts 交易状态：期货有夜盘，判断行情是否有效前先看这个字段 历史K线：kType 一个编码走所有周期 回测和画图需要历史数据，期货K线接口的参数跟股票一样：region + code + kType + limit。周期用数字编码，1分钟到月线都有： def fetch_future_klines(code, region="US", ktype=8, limit=200): resp = requests.get( f"{API_BASE}/future/kline", headers=headers, params={ "region": region, "code": code, "kType": ktype, # 1=1分钟 2=5分钟 5=1小时 8=日K 9=周K 10=月K "limit": limit, # 单次最大500 }, ) rows = resp.json()["data"] # 返回数组，每条 t/o/h/l/c/v/tu，时间戳毫秒 return rows gold_daily = fetch_future_klines("GC", ktype=8, limit=300) print(gold_daily[-1]["c"]) # 黄金最新一根日K收盘 这里有个期货特有的坑：连续合约和具体月份合约的K线不一样。接口返回的一般是主力/连续合约的标准化数据，做回测时如果自己拼接具体月份合约的数据，换月那天会出现跳空，别把它当成真实的行情波动。 WebSocket实时推送：一条连接盯多个品种 盘中实时监控用 WebSocket，流程还是那四步：连上 → 等鉴权成功 → 订阅 → 心跳。一条连接最多订500个标的，主流品种一条连接全搞定： import json import threading import time import websocket WS_URL = "wss://api.itick.org/future" TOKEN = "your_token_here" authenticated = False heartbeat_alive = True def on_message(ws, message): global authenticated payload = json.loads(message) if payload.get("resAc") == "auth" and payload.get("code") == 1 and not authenticated: authenticated = True ws.send(json.dumps({ "ac": "subscribe", "params": "GC$US,SI$US,CL$US,NQ$US,ES$US,IF$CN", "types": "quote" })) threading.Thread(target=heartbeat, args=(ws,), daemon=True).start() return if payload.get("resAc") == "pong": return data = payload.get("data") or {} if data.get("type") == "quote": # 推送字段与REST一致，s/ld/o/h/l/v/tu print(data["s"], data["ld"], data["t"]) def heartbeat(ws): while heartbeat_alive: time.sleep(30) ws.send(json.dumps({"ac": "ping", "params": str(int(time.time() * 1000))})) ws = websocket.WebSocketApp(WS_URL, header=[f"token: {TOKEN}"], on_message=on_message) ws.run_forever() 订阅格式 GC$US 是"品种代码$市场代码"，多品种逗号分隔。这里有个容易忽略的点：IF 是中金所品种，region 是 CN，不是 US——写订阅参数时别想当然全填 US。 主力合约换月：期货监控绕不开的坑 股票没有"换月"概念，期货有。随着临近交割，主力合约会切换到下一个月份，这时候连续合约的K线和报价会出现一个跳变。做多品种监控要注意： 换月跳空不是行情波动：策略判断涨跌时要排除换月带来的价格跳变，不然会误触发信号 别在代码里写死合约月份：用连续合约代码，让数据源帮你处理主力切换 持仓量变化是换月的信号：成交量、持仓量明显转移时，多半是在换月，关注 ts 交易状态和价格是否异常 组合示例：多品种期货监控面板 把快照和实时拼起来，就是一个可用的监控面板骨架： import json, threading, time, requests, websocket API_BASE = "https://api.itick.org" WS_URL = "wss://api.itick.org/future" TOKEN = "your_token_here" headers = {"accept": "application/json", "token": TOKEN} WATCHLIST = "GC,SI,CL,ZS,NQ,ES" # 启动快照 print("=== 期货快照 ===") snap = requests.get(f"{API_BASE}/future/quotes", headers=headers, params={"region": "US", "codes": WATCHLIST}).json()["data"] for symbol, q in snap.items(): sign = "+" if q["chp"] >= 0 else "" print(f" {symbol}: {q['ld']} ({sign}{q['chp']}%)") # 实时推送 authenticated = False def on_message(ws, message): global authenticated payload = json.loads(message) if payload.get("resAc") == "auth" and payload.get("code") == 1 and not authenticated: authenticated = True params = ",".join(f"{c}$US" for c in WATCHLIST.split(",")) ws.send(json.dumps({"ac": "subscribe", "params": params, "types": "quote"})) threading.Thread(target=heartbeat, args=(ws,), daemon=True).start() return if payload.get("resAc") == "pong": return data = payload.get("data") or {} if data.get("type") == "quote": print(f"[实时] {data['s']}: {data['ld']} ({data['chp']}%)") def heartbeat(ws): while True: time.sleep(30) ws.send(json.dumps({"ac": "ping", "params": str(int(time.time() * 1000))})) ws = websocket.WebSocketApp(WS_URL, header=[f"token: {TOKEN}"], on_message=on_message) ws.run_forever() 这个脚本启动时拉一次全品种快照，盘中WebSocket实时更新，做监控或者告警的底座足够用了。 踩坑清单速查 品种代码 ≠ 合约代码：接口用品种代码（GC/CL/IF），别拿具体月份合约号来调 IF 是 CN 市场：中金所品种 region 填 CN，别全填 US 批量接口参数是 codes（复数），返回 dict 以品种代码为 key 期货报价有 p 前收字段，涨跌额 = 最新价 − 前收 连续合约换月有跳空：回测和信号判断时要排除换月跳变 时间戳毫秒，判断夜盘时段先统一时区 WS 先等鉴权成功再订阅，心跳 30 秒一次不能省 小结 多品种期货数据管道，核心就三件事：认识合约体系、快照走批量、实时走推送。合约代码认准 region + code，快照用 /future/quotes 一次拿全，实时用 WebSocket 一条连接盯多个品种，换月的坑提前心里有数，这套管道就能稳定跑起来。接口参数和返回字段的完整说明，写代码时对照官方文档最稳妥。 GitHub：https://github.com/itick-org/ 摘要：用Codex分析A股，怎样把行情、财报数据和估值放在一起看？本文以寒武纪为例，实测通过TickDB MCP获取历史行情、单季财务与PE估值，结合公司公告核对期间和口径，再用Python生成事实卡、整理个股研究笔记。附可复制的任务指令、真实输入和可运行代码，适合个人研究者与AI投研产品团队，减少重复查数和整理。 三季报披露期间，看到一只关注的股票利润增长超过一倍，你最想弄清楚的，往往是增长从哪里来、现金回来了多少，以及市场原先已经期待了多少。把新闻标题交给AI，它很快就能写出一段点评；可一旦把“同比增长”顺手写成“超预期”，后面的判断就可能偏了。 先把数字查全，再把问题问准。让Codex通过TickDB取得同一只股票的行情、财报数据和估值，完成必要计算，最后留下一页写清依据与下一步的研究笔记。TickDB提供AI可调用的结构化数据入口，个人研究者可以少重复查数，投研产品团队也能据此设计研究卡片。 这次选寒武纪688256.SH。2026年10月29日，我们通过已连接的TickDB MCP查询股票信息、历史日线、利润表、现金流和估值，再结合公司季度报告核对。下面按一次个股研究的顺序展开：先看拿到了什么，再看这些数字该怎样读，最后把方法交给你。 图1：AI生成概念示意，展示资料整理的关系；卡片上的曲线和图形不表示寒武纪的实际走势。 一、先看实测结果：数字到手后，研究从哪里继续 这次查询得到的几项信息，足够组成一页研究底稿： 观察项目 本次结果 接下来要弄清楚什么 历史行情 9月22日至10月27日取得20根前复权日线，首末收盘价1121.00元、912.98元，变化−18.56% 这段窗口内发生过哪些信息变化 单季营业收入 2026年第三季度约35.31亿元，同比增长104.47% 增长来自哪些业务或客户变化 单季归母净利润 约14.04亿元，同比增长147.74% 这是相对去年增长，还是也高于此前预期 单季经营现金流 约−0.84亿元；上年同季约−9.40亿元 净流出收窄以后，回款与支出各有什么变化 PE估值 10月29日查询返回146.01，返回未附明确的估值业务时点 盈利分母采用什么口径，比较基准是否一致 财务金额按亿元保留两位。接口整数金额与公告原文有元级差异；接口报告期日期标签为9月29日，公告报告期末为9月30日。本例保留两边原值，季度归属按公告核对。 把这些数字放在一起，最有用的收获是：下一问有了落点。利润增长去查预期和利润构成，现金流去查收付明细，估值去查分母。研究不必停在“公司增长很快”这句话上。 二、利润增长这么快，为什么还要继续查 同比增长，比较的是去年；超预期，要找此前的预期 10月23日晚，IT之家报道了寒武纪第三季度业绩。报道列出的营收、利润数字，可以回到公司报告核对；其“AI解读”还使用了“大幅超出市场预期”的表述。 这正好给我们一个实际的阅读问题：预期基准在哪里？ 同比增长147.74%，比较的是本年第三季度和去年第三季度的利润。判断是否超预期，则要找财报披露前、针对同一季度的预测：谁预测的，何时发布，预测的是归母净利润还是其他指标。若采用多家机构的预测，还要交代纳入了哪些机构。 同比增长：本期实际值，与上年同季实际值比较。 是否超预期：本期实际值，与披露前对本期的预测比较。 本篇取回了实际财务数据，没有另行建立机构预测样本，因此笔记保留“同比增长”，把“核查此前预期”列为下一步。读新闻、看AI点评时，也可以用这一问检验它有没有跳过依据。 利润与现金流放在一起看，能问得更具体 本例第三季度单季归母净利润约14.04亿元，经营现金流约−0.84亿元。两者为什么不同？先从账上确认收入与实际收到现金的时间差开始想：有些收入已经确认，款项可能稍后才收；有些经营支出发生在当期，也未必与当期利润一一对应。 江苏证监局的投资者教育资料也解释过，利润表与现金流量表的项目没有简单的一一对应关系，可以借助现金流量补充资料，逐步将净利润调节为经营活动现金流量净额。 因此，查下去的顺序可以很具体： 继续查什么 想回答的问题 需要补哪份资料 销售回款与应收变化 收入增长之后，收款情况怎样 现金流量表、资产负债表及相关说明 采购付款与存货变化 是否有经营支出先于后续销售发生 现金流量表、存货及采购相关说明 其他经营收付与调整项目 利润和现金的差异还有哪些来源 报告说明；有补充资料时再核对调节项 这些是核查方向，本例还没有把差异归因到某个项目。单季现金流为负，也不能直接推导公司经营恶化：它较上年同季的净流出已经明显收窄，仍要结合累计期间、实际明细和业务节奏读。 一个PE数字，离贵或便宜还差几个条件 估值查询返回PE值146.01，同时带有关于“便宜”和区间位置的自动描述。研究笔记先留下数值，继续核查计算条件。 市盈率把股价与盈利联系起来。用哪个时点的股价，盈利采用上年度、滚动期间还是预测值，都会影响比较。换一家公司的PE来对照，也要先把这些条件对齐。 本次返回没有明确的估值业务时间字段，我们只知道10月29日取回了这条结果。因此不能把它与10月27日的收盘价当作同一天的一组数，进一步推导所谓便宜程度。 三、看股价与财报，先把时间放对 本例最容易混淆的地方，是把一份第三季度报告与一个横跨9月、10月的行情窗口，当成了同一段时间。 图2：左侧是数字覆盖的期间，右侧是本次使用的资料记录日期。公告存档页日期为10月24日，10月23日晚已有公开报道；首次披露时点应核对交易所记录。 财报里的单季经营情况属于7月至9月。本文的20根日线覆盖9月22日至10月27日，首末收盘变化为： （912.98 ÷ 1121.00 − 1）× 100% ≈ −18.56% 这段价格窗口包含报告公开报道之前和之后的记录。因此，把−18.56%直接写成“财报公布后的市场反应”，时间上就对不上。若要研究财报发布后的价格表现，应先核对公告首次公开的具体时间，再单独划定观察窗口，并查看同期其他信息。 同样，今天查到一份财报，也不能默认过去某个交易日已经能看到它。做历史研究时，这一步尤其重要。 数字旁边留下日期和期间，读者就能自己判断哪些可以直接比，哪些还缺条件。原本笼统的“股价为什么不跟业绩走”，也就能拆成更容易查证的问题。 四、TickDB在这项研究里，提供了什么价值 如果只研究一只股票，手工翻行情和报告也能完成。但观察名单需要反复更新，或者要把这套过程放进投研产品时，每次重新找入口、抄数字、整理格式，就会成为持续的工作量。 本例通过TickDB MCP，围绕同一个证券对象取得历史行情、财务和估值输入，再交给Codex整理、交给代码计算。几类数据能接着用，是这条路径的主要价值：行情提出价格问题，财务把问题落到经营指标，估值提供进一步比较的线索。TickDB产品入口 这里也可以分清分工：TickDB提供本篇实际取得的数据，代码计算首末变化和同比，研究者核对公告、寻找预期与经营明细。最后生成的研究笔记由这一整条过程完成。 对行情应用和AI投研产品，值得借鉴的是卡片的设计：在每项数字旁保留期间与来源，在观点后面留出“还要查什么”。用户点开现金流观察，应该知道接下来查哪张表；点开估值，应该能看到计算条件，而不只有一句“偏低”。 本文跑的是MCP按需查询。持续盘中更新属于另一项产品任务，要另行验证相应的行情订阅方式。换证券、换市场时，也要核对可用字段、报告期和账户权限。本例发现的日期标签与元级金额差异，都保留在核对记录中。 五、把这套研究方法带走 先在Codex中接好TickDB MCP，并确认当前账户可以调用所需工具。然后把下面的任务交给它： 为寒武纪688256.SH整理一页研究笔记，数据通过TickDB MCP实际查询。 1. 查询股票身份，确认代码、名称和币种。 2. 查询截至2026-10-27的20根日线，interval=1d，adjust=forward。 end_time按Asia/Shanghai当日23:59:59.999转换为Unix毫秒。 按日期升序排列，保留原始返回。 3. 分别查询利润表IS和现金流CF，period_type=q3，n=2。 保留营业收入、净利润、经营现金流的字段名、年份、期间及原值。 对照公司季度报告，核对单季/累计、归母归属、单位； 披露时间查公告记录，不用第三方存档页日期代替。 4. 查询估值；保留数值及可用时间信息，不直接采用自动描述作结论。 5. 将行情首尾记录与两年同季财务整理为下方JSON格式， 保存research_input.json，运行本页make_note.py生成事实卡。 6. 根据事实卡写一页笔记：价格观察、经营观察、估值待查、下一步。 关键事实注明数据或公告来源；缺项就保留问题，不补造数字。 不把价格与业绩同时出现写成已经找到涨跌原因。 这对应了本篇实际执行的数据查询与整理步骤。你可以先保留同一标的和日期，把整条过程跑一遍，再替换自己的研究对象与窗口。 给技术同事的最小实现 下面的输入取自本次真实返回。价格部分只列计算所需的首尾两条；完整查询取得20条。财务保留接口原值，净利润字段在本例结合公告核对归属。 保存为research_input.json： { "symbol": "688256.SH", "currency": "CNY", "queried_at": "2026-10-29", "adjust": "forward", "prices": [["2026-09-22", "1121.00"], ["2026-10-27", "912.98"]], "fiscal_year": 2026, "period": "q3", "financials": [ {"year": 2026, "period": "q3", "metric": "OperatingRevenue", "value": "3530828295"}, {"year": 2025, "period": "q3", "metric": "OperatingRevenue", "value": "1726780893"}, {"year": 2026, "period": "q3", "metric": "NetProfit", "value": "1403610673"}, {"year": 2025, "period": "q3", "metric": "NetProfit", "value": "566563170"}, {"year": 2026, "period": "q3", "metric": "NetOperateCashFlow", "value": "-83677875"}, {"year": 2025, "period": "q3", "metric": "NetOperateCashFlow", "value": "-940455129"} ] } 再保存下面的make_note.py。使用Python 3标准库，无需安装第三方依赖： import json import sys from datetime import date from decimal import Decimal from pathlib import Path def number(value): result = Decimal(str(value)) if not result.is_finite(): raise ValueError("金额或价格必须是有限数值") return result def make_note(data): if data["currency"] != "CNY" or data["adjust"] != "forward": raise ValueError("本例要求人民币、前复权价格") prices = sorted(data["prices"], key=lambda row: date.fromisoformat(row[0])) if len(prices) < 2 or len({row[0] for row in prices}) != len(prices): raise ValueError("至少需要两个不同日期，且不能重复") if any(number(row[1]) <= 0 for row in prices): raise ValueError("价格必须为正数") fields = {} for row in data["financials"]: key = (int(row["year"]), row["period"], row["metric"]) if key in fields: raise ValueError("财务字段重复，请先核对口径") fields[key] = number(row["value"]) year, period = int(data["fiscal_year"]), data["period"] lines = [f'# {data["symbol"]} 研究事实卡', f'取数日期：{data["queried_at"]}；币种：CNY；价格：前复权。'] first, last = prices[0], prices[-1] change = (number(last[1]) / number(first[1]) - 1) * 100 lines.append(f'价格：{first[0]} {number(first[1]):.2f}元 → ' f'{last[0]} {number(last[1]):.2f}元；首末收盘变化 {change:+.2f}%。') for metric, label in [("OperatingRevenue", "营业收入"), ("NetProfit", "净利润"), ("NetOperateCashFlow", "经营现金流")]: current = fields[(year, period, metric)] previous = fields[(year - 1, period, metric)] text = f'{label}（{year}/{year-1}，{period}）：' text += f'{current / 100000000:.2f} / {previous / 100000000:.2f}亿元。' if previous > 0: text += f' 同比 {(current / previous - 1) * 100:+.2f}%。' else: text += ' 上期为零或负数，保留金额对照，不计算同比百分比。' lines.append(text) lines.append('待查问题：请结合公告、现金流明细和估值口径补充。') return '\n\n'.join(lines) + '\n' if __name__ == "__main__": source = Path(sys.argv[1] if len(sys.argv) > 1 else "research_input.json") try: data = json.loads(source.read_text(encoding="utf-8")) Path("research_note.md").write_text(make_note(data), encoding="utf-8") print("已生成 research_note.md") except (OSError, ValueError, KeyError, TypeError, ArithmeticError) as error: raise SystemExit(f"输入需核对：{error}") 在这两个文件所在目录运行： python3 make_note.py research_input.json 程序生成research_note.md。本次实际输出中的关键结果为： 首末收盘变化：-18.56% 营业收入：35.31 / 17.27亿元；同比 +104.47% 净利润：14.04 / 5.67亿元；同比 +147.74% 经营现金流：-0.84 / -9.40亿元 上期为零或负数，保留金额对照，不计算同比百分比。 这段代码完成本地计算和事实卡生成；新的数据由前面的MCP查询取得。以后替换输入时，币种、价格口径、财务期间与字段含义也要一起核对。事实卡里保留“净利润”字段名称，是否能在笔记中称为归母净利润，要继续核对对应公告。 不写代码，也可以直接使用这个笔记格式 研究对象与取数日期： 价格观察：选定哪个区间，发生了什么变化？ 经营观察：对应哪份报告、哪种期间，有哪些实际变化？ 估值待查：拿到了什么数值，还缺哪项比较条件？ 下一步：最值得回到公告或明细里查的具体问题是什么？ 留下一两个能继续核查的问题，通常比把公司所有信息都塞进一页更有用。 六、留下一页，下次能接着研究 一页有用的笔记，应该让你下次打开时知道接着查什么。本例留下的就很明确：查披露前的利润预期，查经营收付明细，查PE的计算条件。发现新资料以后，再回来更新判断。 英国金融行为监管局FCA在2026年7月更新的AI投资研究指引中，也肯定了AI在整理复杂资料方面的用途，并建议用可信来源复核结果，把AI提供的信息作为继续研究的起点。实际做起来，就是让数字能回查、计算能重跑，问题能继续往下问。 第一次用Codex做股票分析，从哪里开始？ 选一只自己熟悉的股票、一个已经结束的行情窗口和一份明确的季度报告。先用上面的任务指令取得数据，做出一页笔记，再逐项补上你真正关心的问题。 查询缺数据，或者笔记里的数字对不上怎么办？ 保留错误和缺项，先核对证券代码、权限、单位、报告期间与复权口径。财务回到公告查，计算用保存的输入重跑；缺失值不填零。本例的报告期标签与元级金额差异，也按这个办法分别保留和核对。 TickDB还能支持下一步研究什么？ 沿着已验证的行情、财务和估值输入，组织自己的固定观察名单，反复生成研究底稿。新增同业或其他市场前，先确认对应数据是否可用；需要现金流逐项明细时，继续补读公司报告。 从TickDB AI工具入口开始，用自己熟悉的一只股票试一次。值得留下来的，是查数之后，你终于知道该把下一步研究放在哪里。 参考资料 TickDB AI工具页及本篇MCP真实返回：股票信息、历史日线、财务与估值；查询日期2026年10月29日。 中科寒武纪科技股份有限公司《2026年第三季度报告》：主要财务数据、期间说明；新浪财经存档PDF，存档页日期2026年10月24日。 IT之家《寒武纪2026年第三季度归母净利润14.04亿元，同比增长147.74%》：2026年10月23日18时42分；用于对照新闻数据与“AI解读”的判断基准。 江苏证监局《读懂上市公司报告之资产负债表、利润表和现金流量表之间的关系如何？》：2023年10月31日，关于净利润与经营现金流的关系。 FCA《Using AI for investment research》：2025年12月18日首次发布，2026年7月30日更新，关于AI辅助研究与可信来源复核。 OpenAI官方《Model Context Protocol》说明：外部工具与信息的连接方式；查阅于2026年10月29日。 本文展示数据整理与研究方法，寒武纪用于接口与笔记演示，不构成买卖建议。行情、财务与估值按文中所列时间使用。 摘要：用Codex分析A股，怎样把行情、财报数据和估值放在一起看？本文以寒武纪为例，实测通过TickDB MCP获取历史行情、单季财务与PE估值，结合公司公告核对期间和口径，再用Python生成事实卡、整理个股研究笔记。附可复制的任务指令、真实输入和可运行代码，适合个人研究者与AI投研产品团队，减少重复查数和整理。 三季报披露期间，看到一只关注的股票利润增长超过一倍，你最想弄清楚的，往往是增长从哪里来、现金回来了多少，以及市场原先已经期待了多少。把新闻标题交给AI，它很快就能写出一段点评；可一旦把“同比增长”顺手写成“超预期”，后面的判断就可能偏了。 先把数字查全，再把问题问准。让Codex通过TickDB取得同一只股票的行情、财报数据和估值，完成必要计算，最后留下一页写清依据与下一步的研究笔记。TickDB提供AI可调用的结构化数据入口，个人研究者可以少重复查数，投研产品团队也能据此设计研究卡片。 这次选寒武纪688256.SH。2026年10月29日，我们通过已连接的TickDB MCP查询股票信息、历史日线、利润表、现金流和估值，再结合公司季度报告核对。下面按一次个股研究的顺序展开：先看拿到了什么，再看这些数字该怎样读，最后把方法交给你。 图1：AI生成概念示意，展示资料整理的关系；卡片上的曲线和图形不表示寒武纪的实际走势。 一、先看实测结果：数字到手后，研究从哪里继续 这次查询得到的几项信息，足够组成一页研究底稿： 观察项目 本次结果 接下来要弄清楚什么 历史行情 9月22日至10月27日取得20根前复权日线，首末收盘价1121.00元、912.98元，变化−18.56% 这段窗口内发生过哪些信息变化 单季营业收入 2026年第三季度约35.31亿元，同比增长104.47% 增长来自哪些业务或客户变化 单季归母净利润 约14.04亿元，同比增长147.74% 这是相对去年增长，还是也高于此前预期 单季经营现金流 约−0.84亿元；上年同季约−9.40亿元 净流出收窄以后，回款与支出各有什么变化 PE估值 10月29日查询返回146.01，返回未附明确的估值业务时点 盈利分母采用什么口径，比较基准是否一致 财务金额按亿元保留两位。接口整数金额与公告原文有元级差异；接口报告期日期标签为9月29日，公告报告期末为9月30日。本例保留两边原值，季度归属按公告核对。 把这些数字放在一起，最有用的收获是：下一问有了落点。利润增长去查预期和利润构成，现金流去查收付明细，估值去查分母。研究不必停在“公司增长很快”这句话上。 二、利润增长这么快，为什么还要继续查 同比增长，比较的是去年；超预期，要找此前的预期 10月23日晚，IT之家报道了寒武纪第三季度业绩。报道列出的营收、利润数字，可以回到公司报告核对；其“AI解读”还使用了“大幅超出市场预期”的表述。 这正好给我们一个实际的阅读问题：预期基准在哪里？ 同比增长147.74%，比较的是本年第三季度和去年第三季度的利润。判断是否超预期，则要找财报披露前、针对同一季度的预测：谁预测的，何时发布，预测的是归母净利润还是其他指标。若采用多家机构的预测，还要交代纳入了哪些机构。 同比增长：本期实际值，与上年同季实际值比较。 是否超预期：本期实际值，与披露前对本期的预测比较。 本篇取回了实际财务数据，没有另行建立机构预测样本，因此笔记保留“同比增长”，把“核查此前预期”列为下一步。读新闻、看AI点评时，也可以用这一问检验它有没有跳过依据。 利润与现金流放在一起看，能问得更具体 本例第三季度单季归母净利润约14.04亿元，经营现金流约−0.84亿元。两者为什么不同？先从账上确认收入与实际收到现金的时间差开始想：有些收入已经确认，款项可能稍后才收；有些经营支出发生在当期，也未必与当期利润一一对应。 江苏证监局的投资者教育资料也解释过，利润表与现金流量表的项目没有简单的一一对应关系，可以借助现金流量补充资料，逐步将净利润调节为经营活动现金流量净额。 因此，查下去的顺序可以很具体： 继续查什么 想回答的问题 需要补哪份资料 销售回款与应收变化 收入增长之后，收款情况怎样 现金流量表、资产负债表及相关说明 采购付款与存货变化 是否有经营支出先于后续销售发生 现金流量表、存货及采购相关说明 其他经营收付与调整项目 利润和现金的差异还有哪些来源 报告说明；有补充资料时再核对调节项 这些是核查方向，本例还没有把差异归因到某个项目。单季现金流为负，也不能直接推导公司经营恶化：它较上年同季的净流出已经明显收窄，仍要结合累计期间、实际明细和业务节奏读。 一个PE数字，离贵或便宜还差几个条件 估值查询返回PE值146.01，同时带有关于“便宜”和区间位置的自动描述。研究笔记先留下数值，继续核查计算条件。 市盈率把股价与盈利联系起来。用哪个时点的股价，盈利采用上年度、滚动期间还是预测值，都会影响比较。换一家公司的PE来对照，也要先把这些条件对齐。 本次返回没有明确的估值业务时间字段，我们只知道10月29日取回了这条结果。因此不能把它与10月27日的收盘价当作同一天的一组数，进一步推导所谓便宜程度。 三、看股价与财报，先把时间放对 本例最容易混淆的地方，是把一份第三季度报告与一个横跨9月、10月的行情窗口，当成了同一段时间。 图2：左侧是数字覆盖的期间，右侧是本次使用的资料记录日期。公告存档页日期为10月24日，10月23日晚已有公开报道；首次披露时点应核对交易所记录。 财报里的单季经营情况属于7月至9月。本文的20根日线覆盖9月22日至10月27日，首末收盘变化为： （912.98 ÷ 1121.00 − 1）× 100% ≈ −18.56% 这段价格窗口包含报告公开报道之前和之后的记录。因此，把−18.56%直接写成“财报公布后的市场反应”，时间上就对不上。若要研究财报发布后的价格表现，应先核对公告首次公开的具体时间，再单独划定观察窗口，并查看同期其他信息。 同样，今天查到一份财报，也不能默认过去某个交易日已经能看到它。做历史研究时，这一步尤其重要。 数字旁边留下日期和期间，读者就能自己判断哪些可以直接比，哪些还缺条件。原本笼统的“股价为什么不跟业绩走”，也就能拆成更容易查证的问题。 四、TickDB在这项研究里，提供了什么价值 如果只研究一只股票，手工翻行情和报告也能完成。但观察名单需要反复更新，或者要把这套过程放进投研产品时，每次重新找入口、抄数字、整理格式，就会成为持续的工作量。 本例通过TickDB MCP，围绕同一个证券对象取得历史行情、财务和估值输入，再交给Codex整理、交给代码计算。几类数据能接着用，是这条路径的主要价值：行情提出价格问题，财务把问题落到经营指标，估值提供进一步比较的线索。TickDB产品入口 这里也可以分清分工：TickDB提供本篇实际取得的数据，代码计算首末变化和同比，研究者核对公告、寻找预期与经营明细。最后生成的研究笔记由这一整条过程完成。 对行情应用和AI投研产品，值得借鉴的是卡片的设计：在每项数字旁保留期间与来源，在观点后面留出“还要查什么”。用户点开现金流观察，应该知道接下来查哪张表；点开估值，应该能看到计算条件，而不只有一句“偏低”。 本文跑的是MCP按需查询。持续盘中更新属于另一项产品任务，要另行验证相应的行情订阅方式。换证券、换市场时，也要核对可用字段、报告期和账户权限。本例发现的日期标签与元级金额差异，都保留在核对记录中。 五、把这套研究方法带走 先在Codex中接好TickDB MCP，并确认当前账户可以调用所需工具。然后把下面的任务交给它： 为寒武纪688256.SH整理一页研究笔记，数据通过TickDB MCP实际查询。 1. 查询股票身份，确认代码、名称和币种。 2. 查询截至2026-10-27的20根日线，interval=1d，adjust=forward。 end_time按Asia/Shanghai当日23:59:59.999转换为Unix毫秒。 按日期升序排列，保留原始返回。 3. 分别查询利润表IS和现金流CF，period_type=q3，n=2。 保留营业收入、净利润、经营现金流的字段名、年份、期间及原值。 对照公司季度报告，核对单季/累计、归母归属、单位； 披露时间查公告记录，不用第三方存档页日期代替。 4. 查询估值；保留数值及可用时间信息，不直接采用自动描述作结论。 5. 将行情首尾记录与两年同季财务整理为下方JSON格式， 保存research_input.json，运行本页make_note.py生成事实卡。 6. 根据事实卡写一页笔记：价格观察、经营观察、估值待查、下一步。 关键事实注明数据或公告来源；缺项就保留问题，不补造数字。 不把价格与业绩同时出现写成已经找到涨跌原因。 这对应了本篇实际执行的数据查询与整理步骤。你可以先保留同一标的和日期，把整条过程跑一遍，再替换自己的研究对象与窗口。 给技术同事的最小实现 下面的输入取自本次真实返回。价格部分只列计算所需的首尾两条；完整查询取得20条。财务保留接口原值，净利润字段在本例结合公告核对归属。 保存为research_input.json： { "symbol": "688256.SH", "currency": "CNY", "queried_at": "2026-10-29", "adjust": "forward", "prices": [["2026-09-22", "1121.00"], ["2026-10-27", "912.98"]], "fiscal_year": 2026, "period": "q3", "financials": [ {"year": 2026, "period": "q3", "metric": "OperatingRevenue", "value": "3530828295"}, {"year": 2025, "period": "q3", "metric": "OperatingRevenue", "value": "1726780893"}, {"year": 2026, "period": "q3", "metric": "NetProfit", "value": "1403610673"}, {"year": 2025, "period": "q3", "metric": "NetProfit", "value": "566563170"}, {"year": 2026, "period": "q3", "metric": "NetOperateCashFlow", "value": "-83677875"}, {"year": 2025, "period": "q3", "metric": "NetOperateCashFlow", "value": "-940455129"} ] } 再保存下面的make_note.py。使用Python 3标准库，无需安装第三方依赖： import json import sys from datetime import date from decimal import Decimal from pathlib import Path def number(value): result = Decimal(str(value)) if not result.is_finite(): raise ValueError("金额或价格必须是有限数值") return result def make_note(data): if data["currency"] != "CNY" or data["adjust"] != "forward": raise ValueError("本例要求人民币、前复权价格") prices = sorted(data["prices"], key=lambda row: date.fromisoformat(row[0])) if len(prices) < 2 or len({row[0] for row in prices}) != len(prices): raise ValueError("至少需要两个不同日期，且不能重复") if any(number(row[1]) <= 0 for row in prices): raise ValueError("价格必须为正数") fields = {} for row in data["financials"]: key = (int(row["year"]), row["period"], row["metric"]) if key in fields: raise ValueError("财务字段重复，请先核对口径") fields[key] = number(row["value"]) year, period = int(data["fiscal_year"]), data["period"] lines = [f'# {data["symbol"]} 研究事实卡', f'取数日期：{data["queried_at"]}；币种：CNY；价格：前复权。'] first, last = prices[0], prices[-1] change = (number(last[1]) / number(first[1]) - 1) * 100 lines.append(f'价格：{first[0]} {number(first[1]):.2f}元 → ' f'{last[0]} {number(last[1]):.2f}元；首末收盘变化 {change:+.2f}%。') for metric, label in [("OperatingRevenue", "营业收入"), ("NetProfit", "净利润"), ("NetOperateCashFlow", "经营现金流")]: current = fields[(year, period, metric)] previous = fields[(year - 1, period, metric)] text = f'{label}（{year}/{year-1}，{period}）：' text += f'{current / 100000000:.2f} / {previous / 100000000:.2f}亿元。' if previous > 0: text += f' 同比 {(current / previous - 1) * 100:+.2f}%。' else: text += ' 上期为零或负数，保留金额对照，不计算同比百分比。' lines.append(text) lines.append('待查问题：请结合公告、现金流明细和估值口径补充。') return '\n\n'.join(lines) + '\n' if __name__ == "__main__": source = Path(sys.argv[1] if len(sys.argv) > 1 else "research_input.json") try: data = json.loads(source.read_text(encoding="utf-8")) Path("research_note.md").write_text(make_note(data), encoding="utf-8") print("已生成 research_note.md") except (OSError, ValueError, KeyError, TypeError, ArithmeticError) as error: raise SystemExit(f"输入需核对：{error}") 在这两个文件所在目录运行： python3 make_note.py research_input.json 程序生成research_note.md。本次实际输出中的关键结果为： 首末收盘变化：-18.56% 营业收入：35.31 / 17.27亿元；同比 +104.47% 净利润：14.04 / 5.67亿元；同比 +147.74% 经营现金流：-0.84 / -9.40亿元 上期为零或负数，保留金额对照，不计算同比百分比。 这段代码完成本地计算和事实卡生成；新的数据由前面的MCP查询取得。以后替换输入时，币种、价格口径、财务期间与字段含义也要一起核对。事实卡里保留“净利润”字段名称，是否能在笔记中称为归母净利润，要继续核对对应公告。 不写代码，也可以直接使用这个笔记格式 研究对象与取数日期： 价格观察：选定哪个区间，发生了什么变化？ 经营观察：对应哪份报告、哪种期间，有哪些实际变化？ 估值待查：拿到了什么数值，还缺哪项比较条件？ 下一步：最值得回到公告或明细里查的具体问题是什么？ 留下一两个能继续核查的问题，通常比把公司所有信息都塞进一页更有用。 六、留下一页，下次能接着研究 一页有用的笔记，应该让你下次打开时知道接着查什么。本例留下的就很明确：查披露前的利润预期，查经营收付明细，查PE的计算条件。发现新资料以后，再回来更新判断。 英国金融行为监管局FCA在2026年7月更新的AI投资研究指引中，也肯定了AI在整理复杂资料方面的用途，并建议用可信来源复核结果，把AI提供的信息作为继续研究的起点。实际做起来，就是让数字能回查、计算能重跑，问题能继续往下问。 第一次用Codex做股票分析，从哪里开始？ 选一只自己熟悉的股票、一个已经结束的行情窗口和一份明确的季度报告。先用上面的任务指令取得数据，做出一页笔记，再逐项补上你真正关心的问题。 查询缺数据，或者笔记里的数字对不上怎么办？ 保留错误和缺项，先核对证券代码、权限、单位、报告期间与复权口径。财务回到公告查，计算用保存的输入重跑；缺失值不填零。本例的报告期标签与元级金额差异，也按这个办法分别保留和核对。 TickDB还能支持下一步研究什么？ 沿着已验证的行情、财务和估值输入，组织自己的固定观察名单，反复生成研究底稿。新增同业或其他市场前，先确认对应数据是否可用；需要现金流逐项明细时，继续补读公司报告。 从TickDB AI工具入口开始，用自己熟悉的一只股票试一次。值得留下来的，是查数之后，你终于知道该把下一步研究放在哪里。 参考资料 TickDB AI工具页及本篇MCP真实返回：股票信息、历史日线、财务与估值；查询日期2026年10月29日。 中科寒武纪科技股份有限公司《2026年第三季度报告》：主要财务数据、期间说明；新浪财经存档PDF，存档页日期2026年10月24日。 IT之家《寒武纪2026年第三季度归母净利润14.04亿元，同比增长147.74%》：2026年10月23日18时42分；用于对照新闻数据与“AI解读”的判断基准。 江苏证监局《读懂上市公司报告之资产负债表、利润表和现金流量表之间的关系如何？》：2023年10月31日，关于净利润与经营现金流的关系。 FCA《Using AI for investment research》：2025年12月18日首次发布，2026年7月30日更新，关于AI辅助研究与可信来源复核。 OpenAI官方《Model Context Protocol》说明：外部工具与信息的连接方式；查阅于2026年10月29日。 本文展示数据整理与研究方法，寒武纪用于接口与笔记演示，不构成买卖建议。行情、财务与估值按文中所列时间使用。 什么是量化交易 在我看来，由固定的行为准则作为依据，机械式的进行交易的过程，都可成为量化 交易。我朋友当学生的时候用的就是excel，做商品跨期对冲套利，每天收盘后用excel手动更新数据，收益也很可观。一个完整的量化交易策略研究过程应该时这么几个步骤： 在市场的毒打中，发现某种市场规律（金融异象） 在有效市场假说那些人看来，市场的资产应当已经被充分定价了， 比如比较常见的“阻力位”、“支撑位”。比如MACD金叉死叉，比如均线金叉死叉。 当发现这种规律之后，我们可能需要通过准确数学的语言描述出来，比如阻力位就是一个非常抽象的概念，每个人定义的都不同，但是金叉死叉就是一个很容易通过数学准确描述的东西，自然金叉死叉就更好验证。 实证研究 这种异象到底能不能赚钱，不能靠拍脑袋决定，我们需要编写一个策略去验证想法是否正确。这一部分会在接下来的策略开发部分详细介绍。 当获取了策略的收益之后，我们还需要对策略进行绩效分析，以此判断我们的策略到底赚的什么钱，年化多少，最大回撤多少等等，由此才能够在策略产生回测的时候心里有数。这部分会在策略绩效评估部分介绍。 模拟盘 策略开发以及回测都完成后，我们需要按照真实的行情模拟一段时间，以便知道我们的策略是在历史数据上玩数据挖掘游戏还是真的印钞机。 评估策略容量、小资金实盘 模拟盘最大的问题是你的买入行为不会对市场造成冲击，往往我们还需要实盘一段时间才知道是否可行，这部分距离我们比较遥远，以后再说。 可见均线的金叉死叉确实能够筛选出部分行情，进行趋势性的做多或者做空，可以带来不菲的收益。但是我们都知道，市场不是一直处于趋势中的，可能一年中绝大多数时间都是振荡行情，这段时间还是使用金叉死叉做多做空会不会对策略收益造成毁灭性打击呢？商品市场中趋势往往更顺畅，一次就持续好几个月，但是股票市场中，一步三回头，趋势性更弱，以后我们讲因子部分，有很多因子能够定量描述这种趋势，更有助于我们挑选标的。 策略 事件驱动的回测策略中，我们需要通过“回调”的方式，执行买入、卖出操作，我们需要自己计算当前账户中所剩金额，手动指定下单的价格（市价限价）和数量。 一般一个策略，可以分为这几个大的模块 信号产生 负责产生买入和卖出信号，在这个案例中就是MA5>MA20时发出做多信号，相反情况发出做空信号。往往这一部分决定了策略的上限。 交易执行 负责对将信号转化为实际的买入卖出操作，由于信号产生不一定会照顾到实际的市场情况，比如当某个标的涨停时，很可能带着5日线迅速超过20日线，发出买入指令，但是此时已经涨停了，无法买入，这时候交易执行模块需要对这种情况进行过滤，还有一些比如在期货市场中，需要定时调换主力合约，这些都需要在交易执行模块操作。再比一些拆单，买一卖一超价等，这块以后有机会可以分享，但是太细节了不符合今天的主题。 风险控制 负责对交易所合规、策略整体风险控制等。比如交易所不允许自成交，比如报单速度限额等，这里我们基本涉及不到，所以重点分享的是策略的止盈止损等。往往通过简单地多空信号还不能实现及时的退出，有时可能已经跌了非常多了五日线才下穿20日线，这时候开空有可能又会因为跌多了反弹来回打脸，所以我们策略还需要依据价格的波动及时的进行止损或止盈，这一块可以在后续的策略优化部分分享。 策略优化 策略还有几个可以优化的地方 交易多个资产 在市场呆的久了就会发现，趋势性行情可能每年才有一两次，甚至一些商品，可能10年会有那么几个特别大的趋势性行情，但是换到每年，都有那么几个商品在大行情中，比如这几年的原油。我们是否可以找到一批趋势性很强的资产然后合理的分配资金，并捕获这种行情呢？当然可以，所以才有ATR这种用法，推荐一本书《海龟交易法则》，也算量化鼻祖了。 止盈止损 拿到策略的回测图，我们会发现一些比较有意思的时期，比如这段时期，沪深300已经开始连续下跌了5%，才发出死叉信号，那我们是否可以在账户开始发生回撤达到一定幅度时就提前退出？特别是在期货、期权这种杠杆交易中。 优化交易下单 我们策略中经常为了快速成交，直接使用市价单，但是快速的买入卖出很可能导致交易成本过高，有没有可能通过限定在超一档，通过快速挂撤单来降低成本呢？ 优化结果 这段时间趋势跟踪策略收益都非常可观。 
