这次我们来看一个很多人都在问的问题AI 到底是不是泡沫。如果只看新闻很难给出答案。融资一轮接一轮模型一个比一个贵应用却经常是“雷声大、雨点小”。与其被各方观点带着走不如用数据和技术手段自己测。这篇文章不聊空泛概念直接给出一套可落地的“AI 泡沫观测框架”。从资本、算力、产品、开源四个维度入手用公开 API 采集数据、用 Python 计算指标、再用定时任务做持续监控。文章会给出最小可运行的指标聚合脚本方便接入自己的监控面板或告警系统。这个框架不挑硬件普通开发机、一台云服务器都可以跑甚至本地笔记本也能支撑。代码量不大真正花时间的是数据源配额管理和指标口径设计。适合三类读者做 AI 产品决策的人、做行业研究的技术分析师以及关心自身技术栈风险边界的开发者。看完之后你可以照着搭一套属于自己的 AI 行业温度观测系统。1. 核心能力速览能力项说明分析对象AI 行业泡沫风险信号核心维度资本热度、算力供需、产品真实需求、开源活跃度主要工具Python 3、公开数据源 API、SQLite/CSV、Cron 定时任务硬件要求无需 GPU普通开发机即可启动方式命令行脚本 定时任务数据源 APIGitHub API、云厂商公开定价、公开融资数据库等批量采集支持多指标、多数据源并行采集输出形式CSV、SQLite、控制台报告、Grafana 等可视化面板适合场景行业监控、技术选型、投资研究辅助使用边界量化观测工具不构成投资建议需遵守数据授权要求这里的关键是这套框架本质上是一个量化观测系统不是魔法水晶球。它的作用是帮你把“AI 是不是要崩”这种模糊问题拆解成一组可跟踪、可比较、可告警的指标。2. 适用场景与使用边界2.1 适合谁用第一类是用 AI 能力做产品决策的人。你在选模型供应商时担心对方估值虚高、后续涨价或服务不稳定可以通过长期跟踪资本和算力数据提前感知风险。第二类是技术分析师和行业研究员。你可以把文章里的数据采集框架当作一个模板替换成自己关心的指标快速搭建行业监控脚本。第三类是运维和全栈工程师。你想把外部市场数据接入内部监控系统让 Grafana 大屏多一块“外部风险面板”这篇文章提供了现成的聚合思路。2.2 能解决什么问题传统上判断 AI 泡沫靠的是阅读大量新闻、跟踪融资事件、看财报电话会议。这种方式信息滞后且容易陷入单点消息的干扰。用数据采集和指标聚合的方式可以把散落的信号集中到一个面板上看到趋势变化。2.3 不适合什么场景这个框架不适合做短线交易决策。公开数据源存在延迟融资新闻披露时间也不固定指标无法做到实时。它更适合观察月级别、季度级别的趋势变化。也不适合用来做单一公司的精确估值。它提供的是宏观维度的相对温度不是精确的财务预测。2.4 数据合规与边界使用公开 API 必须遵守对应平台的服务条款。GitHub API 有配额限制云厂商公开定价页面的抓取需要遵循 robots 协议。涉及融资数据时优先选择已经获得授权的数据库或者只用媒体公开报道里的信息。不要采集未公开的、涉及隐私或商业秘密的数据。3. 环境准备与前置条件3.1 运行环境建议使用 Python 3.9 以上版本创建独立虚拟环境避免依赖冲突。整个项目不需要 GPU 环境CPU 就足够跑数据采集脚本。磁盘占用很小主要是 CSV 和 SQLite 文件。python -m venv ai_bubble_env source ai_bubble_env/bin/activate # Windows 下使用 ai_bubble_env\Scripts\activate pip install requests pandas matplotlib3.2 数据源准备核心数据源包括GitHub Search API采集 open source AI 项目的 star 数、issue 数、活跃度。云厂商公开定价页面手动维护价格表或定期抓取用于观察算力成本变化。公开融资数据库如 Crunchbase、PitchBook但这类平台通常需要付费 API。免费方案是用公开新闻聚合手动或半自动录入。行业报告其他机构发布的 AI 应用使用率报告定期把关键指标录入系统。还有一个更稳妥的思路不直接抓取复杂页面而是用“人工录入 脚本汇总”的方式。每周花十分钟更新几个关键数字效果远好于写一个很难维护的爬虫。3.3 目录结构建议按下面的结构组织代码和数据ai_bubble_monitor/ ├── config.yaml # 数据源配置、阈值配置 ├── collectors/ │ ├── github_collector.py │ ├── gpu_price_collector.py │ └── funding_collector.py ├── metrics/ │ ├── normalize.py │ └── aggregate.py ├── data/ │ ├── raw/ # 原始数据 CSV │ └── processed/ # 归一化和聚合后的数据 ├── scripts/ │ ├── run_all.py │ └── alert.py └── output/ └── report.json把数据、代码、输出分离后面做批量任务和定时采集时会省很多事情。4. 四维泡沫指标设计泡沫监测不需要追求指标数量多关键是口径稳定、数据源可靠。整理下来值得长期跟踪的是四个维度。4.1 资本热度指标资本热度反映一级市场和二级市场对 AI 的定价态度。重点跟踪这几个数据AI 领域单月融资事件数量。头部大模型公司的估值变化。云厂商资本开支撑续性。这些数据主要来自公开新闻、融资数据库和上市公司财报。由于部分数据不是结构化 API建议用一个简单的 CSV 维护历史记录。date,funding_events,top_valuation,cloud_cap_ex 2025-01,18,80,45 2025-02,22,85,52 2025-03,17,90,494.2 算力供需指标算力供需是 AI 泡沫最直接的观测窗口。训练和推理都需要 GPU如果算力供给持续过剩且价格下跌说明下游需求没有跟上模型供给。建议跟踪主流云 GPU 实例的按小时价格。新卡发布节奏和二手市场折价。云厂商的库存和排队周期。GPU 价格数据可以通过定期抓取云厂商公开计价页面获取也可以使用第三方价格监控服务。如果自己抓取建议设置合理的抓取频率避免对目标网站造成压力。4.3 产品真实需求指标产品需求是最难量化、也最重要的维度。很多泡沫讨论都集中在“AI 应用到底有没有人用”。可以跟踪这些公开信号AI 应用榜单中的 DAU / WAU 变化。面向开发者的 API 调用量增长。企业付费意愿通过财报电话会议和客户访谈内容判断。开发者社区中关于 AI 应用落地困难的讨论热度。需要注意的是产品数据往往分散在各个平台没有统一 API。一个可行的方案是每周固定时间人工记录关键数字然后由脚本统一汇总分析。4.4 开源社区活跃度指标开源社区数据是最容易获取、也最客观的指标。通过 GitHub API 可以稳定地跟踪 AI 项目的 star、fork、issue、commit 数据。这里主要看头部开源模型仓库的 star 增长曲线。推理框架和 Agent 框架的贡献者数量。相关仓库的 issue 关闭速度和新增 issue 数量。开源活跃度突然从高位回落可能意味着开发者热情在消退这是泡沫观察里的一个领先信号。5. 数据采集与指标计算5.1 开源社区活跃度采集GitHub Search API 是公开免费的适合采集仓库维度数据。下面是一个最小示例按关键词搜索仓库并按 star 排序import requests HEADERS { Accept: application/vnd.githubjson } def search_repos(keyword: str, sort: str stars, per_page: int 10): url https://api.github.com/search/repositories params { q: keyword, sort: sort, order: desc, per_page: per_page } resp requests.get(url, headersHEADERS, paramsparams, timeout30) resp.raise_for_status() data resp.json() return [ { name: item[full_name], stars: item[stargazers_count], forks: item[forks_count], open_issues: item[open_issues_count], created_at: item[created_at], pushed_at: item[pushed_at], } for item in data.get(items, []) ] if __name__ __main__: repos search_repos(large language model) for r in repos: print(r[name], r[stars], r[open_issues])运行这个脚本能得到 AI 相关热门仓库的 star 数量和 open issue 数量。把这些数据按周落库就能看到开源热度变化。5.2 算力价格采集GPU 价格没有统一的公开 API通常需要从云厂商的计价页面抓取或用第三方价格监控平台。为了保持稳定性更推荐维护一份手工录入的价格表再由脚本计算环比变化。import pandas as pd def load_gpu_prices(path: str): df pd.read_csv(path) df[change_pct] df[price].pct_change() * 100 return df # 示例用法 gpu_df load_gpu_prices(data/raw/gpu_prices.csv) latest gpu_df.iloc[-1] print(f最新 GPU 单价: {latest[price]}, 环比变化: {latest[change_pct]:.2f}%)这里的关键是记录价格变化趋势而不是绝对价格。不同代际的 GPU 性能差异很大直接比较绝对价格没有意义。5.3 指标归一化不同维度的指标量纲完全不同star 数可能是十万级融资事件可能是十级GPU 价格变化率是百分比。聚合之前必须先归一化。常用的方式是最小最大归一化把每个指标映射到 0 到 1 之间。为了让不同时间周期的数据可比建议用滚动窗口def normalize_series(series): min_val series.min() max_val series.max() if max_val min_val: return series * 0 0.5 return (series - min_val) / (max_val - min_val) print(normalize_series(pd.Series([10, 20, 30, 40])))归一化后的数值越高说明该维度越“热”。当多个维度同时达到高位时泡沫风险信号就会放大。5.4 聚合泡沫温度指数归一化后可以给四个维度分配权重计算出综合温度指数。权重可以根据自己的关注点调整比如你觉得产品真实需求最重要就提高它的权重。def compute_bubble_index(metrics: dict, weights: dict) - float: total 0.0 weight_sum 0.0 for key, value in metrics.items(): weight weights.get(key, 1.0) total value * weight weight_sum weight return total / weight_sum metrics { capital: 0.73, compute: 0.61, product: 0.88, open_source: 0.45, } weights { capital: 1.0, compute: 1.0, product: 1.5, open_source: 0.8, } index compute_bubble_index(metrics, weights) print(fAI 泡沫温度指数: {index:.2f})温度指数建议取 0 到 1 之间。超过 0.8 视为过热区间低于 0.3 视为冷淡区间。这里需要把你的时间窗口拉长到至少半年才有参考意义。6. 定时批量监控与告警6.1 批量采集脚本把所有采集逻辑汇总到一个入口脚本里方便定时任务调用。关键是要加异常处理避免单个数据源失败导致整个任务中断。import json import sys from collectors.github_collector import collect_github_metrics from collectors.gpu_price_collector import collect_gpu_prices from metrics.normalize import normalize_and_save from metrics.aggregate import aggregate_index def run_all(): results {} try: results[open_source] collect_github_metrics() except Exception as e: print(f[WARN] GitHub 采集失败: {e}, filesys.stderr) try: results[compute] collect_gpu_prices() except Exception as e: print(f[WARN] GPU 价格采集失败: {e}, filesys.stderr) # 资本和产品数据多数是半手工维护这里从 CSV 读取 results[capital] load_from_csv(data/raw/funding_data.csv) norm_data normalize_and_save(results) index aggregate_index(norm_data) with open(output/report.json, w) as f: json.dump({index: index, details: norm_data}, f, ensure_asciiFalse, indent2) print(f聚合完成温度指数: {index:.2f}) if __name__ __main__: run_all()6.2 Cron 定时任务在 Linux 服务器上可以用 Crontab 设置每周一次或每天一次的采集任务。# 每天凌晨 2 点执行一次采集 0 2 * * * cd /path/to/ai_bubble_monitor ./venv/bin/python scripts/run_all.py logs/cron.log 21如果使用 Windows可以用任务计划程序或者直接用 GitHub Actions 定时运行把结果输出到仓库。6.3 阈值告警当温度指数超过预设阈值或某个维度突然变化超过 20% 时触发告警。这里演示一个最简单的通知方式def send_alert(message: str): # 这里可以替换为钉钉、飞书、企业微信或邮件通知 Webhook print(f[ALERT] {message}) thresholds { index: 0.8, single_dimension_change: 20.0, } def check_alerts(index: float, changes: dict): if index thresholds[index]: send_alert(f泡沫温度指数过高: {index:.2f}) for dim, change in changes.items(): if change thresholds[single_dimension_change]: send_alert(f{dim} 指标单日变动过大: {change:.2f}%)告警不要设置得太灵敏否则容易被单次数据抖动干扰。建议用移动平均线做平滑比如取最近 4 周均值来判定。7. 数据可视化与结果解读7.1 汇总报表输出每次采集完成后输出一份 JSON 报告包含温度指数和各个维度的子分值。{ date: 2025-07-01, index: 0.72, dimensions: { capital: 0.73, compute: 0.61, product: 0.88, open_source: 0.45 }, top_signals: [ 头部云厂商资本开支持续增长, AI 应用 DAU 环比增长放缓, 开源模型贡献者数量回落 ] }7.2 可视化接入CSV 和 JSON 数据可以直接导入 Grafana或者用 Python 绘制趋势图。下面是一个最小示例import matplotlib.pyplot as plt import pandas as pd df pd.read_csv(data/processed/bubble_index.csv) plt.figure(figsize(10, 5)) plt.plot(df[date], df[index], markero) plt.axhline(y0.8, colorred, linestyle--, label过热阈值) plt.axhline(y0.3, colorgreen, linestyle--, label冷淡阈值) plt.title(AI 泡沫温度指数趋势) plt.xticks(rotation45) plt.legend() plt.tight_layout() plt.savefig(output/bubble_trend.png)如果不想自己搭 Grafana直接用 CSV 画趋势图也能满足大多数分析需求。7.3 结果解读方法看数据时不要只看单点要看“维度分化”。比如资本温度很高、开源活跃度却快速下降说明资金热度和开发者真实行动之间存在背离这种背离往往比单一指标的上涨更值得警惕。反过来如果产品需求持续上涨但资本和算力价格温和回落说明行业在出清早期的高预期属于相对健康的调整。8. 常见问题与排查方法问题现象可能原因排查方式解决方案GitHub API 返回 403请求频率达到配额限制查看响应头 X-RateLimit-Remaining降低采集频率或者配置 GITHUB_TOKEN采集脚本运行一半中断网络超时或某个依赖项目变更为不兼容查看日志中 WARN 标记在单数据源调用处加 try-except失败不中断主流程温度指数突然跳到 1.0归一化窗口太短检查窗口内是否有异常大值改用滚动窗口最小区间设为一个季度GPU 价格数据不更新手动维护的 CSV 忘记更新查看 data/raw 文件修改时间增加录入提醒通过定时任务检查文件新鲜度融资数据只有零星几条新闻源覆盖不全对比多家媒体公开报道初期可以只覆盖头部公司保持口径一致告警频繁触发阈值设置太紧单次抖动触发查看最近 4 周数据方差改用移动平均值判断降低瞬时数据权重Cron 任务执行失败路径写错或虚拟环境未激活手动执行一次脚本看报错在脚本开头打印 cwd使用绝对路径输出 JSON 为空所有数据源采集都失败检查 report.json 是否生成单独运行各 collector 模块验证数据源可用性9. 最佳实践与使用建议第一次搭建时建议先把“最小闭环”跑通。所谓最小闭环就是先只接 GitHub API 和手工维护的融资数据 CSV计算出温度指数画出一张趋势图。这个流程跑顺之后再慢慢增加算力价格、产品需求等数据源。指标口径一旦确定不要频繁改动。比如你决定跟踪“头部 10 个开源项目 star 总数”就固定收集这 10 个项目而不是每次换一批。口径变了历史数据和当前数据就没法比较。数据采集和输出要分目录管理。把所有原始数据放在 data/raw归一化中间结果放在 data/processed最终报告放 output。这样即使采集脚本写错了原始数据还在可以重新计算。定期检查数据源配额。GitHub 未认证的请求每小时只有 60 次认证后有 5000 次。如果你的项目列表比较多建议配置认证 Token。告警通道要合理设计。推荐把告警通知发到独立的群或频道不要和日常开发消息混在一起。否则很容易被淹没。最后坚持记录。泡沫观测是一个时间越长越有价值的事情。前三个月可能什么都看不出来但当数据积累到一年以上趋势信号就会清晰很多。10. 总结预测 AI 泡沫这件事最不重要的就是“猜测顶点”最重要的是建立一个持续观测的系统。这篇文章给出的四维框架和 Python 脚本可以帮你把模糊的市场情绪转化成可量化、可跟踪、可告警的指标。建议先跑通开源社区活跃度采集这是最容易自动化、数据最客观的维度。然后加上算力和资本维度最后再补产品真实需求。每一步都不难核心工作是坚持更新数据、保持口径稳定。最容易踩的坑有三个一是上来就想接一堆数据源结果全被 API 限流卡死二是指标口径频繁变动导致数据不可比三是只看综合指数不看维度分化。这篇思路里的框架本身也可以向外扩展。如果你关注的是 AI 视频生成可以把四个维度替换成视频模型开源热度、算力价格、应用榜单、企业案例数量如果你关注的是 AI Agent也可以做一套 Agent 专属的观测面板。指标换掉采集和聚合逻辑不变。