你是不是也有过这样的时刻昨天还觉得自己的编码助手很聪明今天喂同一个需求它却开始一本正经地编造接口名。刚想吐槽“模型是不是被降智了”又看到群里有人附和再往下翻还会看到有人在 Hacker News 上贴出一个项目名字直接就叫“Show HN: Is AI Dumber Today? An index of AI model experience from users opinion”。这个问题问得直白也能刺痛很多正在把 AI 集成到生产流程里的工程师。因为“变笨”的体感确实存在但我们很难用“跑分下降了”来解释它。模型版本没变、Prompt 没变、任务复杂度没变可结果就是不如昨天稳定。真正的问题或许不在于模型参数被偷偷改小而在于我们缺少一条观测“实时体验”的工程化管道。用户在各种社区、评论区、工单里生产了大量零散观点如果有一种办法把这些观点收拢、清洗、量化并形成类似指数的指标至少我们能知道这种“变笨”到底是主观错觉还是可观测的系统性波动。这篇文章会拆解这类项目的两个层面。第一是判断层用户口碑型模型体验指数到底衡量什么它和传统 benchmark 评测差别在哪里。第二是工程层我会给出一个可复现的最小实现骨架包括 JSONL 数据格式、情绪分类、SQLite 存储、滑动窗口指数计算和查询 API。你不需要一开始就做大平台先跑通一条评论到一张趋势表的闭环比什么都重要。1. 为什么用户总是觉得“AI 变笨了”“AI 变笨了”不是一个严谨的技术命题但它是一个真实的用户信号。如果你去翻看各种开发者反馈会发现绝大部分抱怨都指向几个非常具体的现象对话刚开始不久模型就报“context length 超限”看起来像智能不足实际是长会话管理问题。API 返回 selected model is at capacity 或 model is unavailable模型本身没问题但容量调度导致体验断裂。客户端与模型网关版本不一致出现“该模型不存在”或“模型名不识别”的报错。开启思维链推理的模型多轮对话没有把 reasoning_content 回传给 API导致后续一轮直接失败。服务端临时降级到小模型用户在无感知的情况下被切换到更低能力版本。上面这些现象搜索材料里都能看到大量真实报错原文。它们有一个共同点用户往往不会去区分“模型能力下降”和“模型服务状态异常”只会得到一个结论——今天这个 AI 好笨。用一张表格可以看得很清楚用户看到的提示工程层面常见原因用户实际感知selected model is at capacity服务端容量调度或流量过高半天不响应误以为模型傻了model is unavailableProvider 网关异常或路由失败功能不可用体验中断400 context length 超限上下文窗口被打满模型“忘记”了之前的内容reasoning_content 未回传思维链模型多轮协议处理不当推理能力突然失效model not supported客户端版本与模型名不匹配认为模型被悄悄下架这类体验问题恰恰是 benchmark 很难覆盖的。因为评测环境是干净的固定测试集、固定超参数、固定上下文服务端也处于稳定状态。而真实用户面对的是复杂网络、长上下文、并发调度、模型版本灰度切换甚至还有客户端配置差异。所以我的判断是用户觉得“AI 变笨”本质上是用户在观察一个动态系统。模型能力是其中一个变量但不是全部变量。如果想要回答“AI 是不是变笨了”就非常需要有另一个数据入口——直接从用户意见出发去度量一段时期内真实交互中的体验变化。这就是“模型体验指数”类项目存在的价值。2. 从意见文本到“模型体验指数”要解决什么问题先把这个概念拆开。“指数”在金融领域是用来反映一组标的综合变化的统计量比如股票指数。放到大模型场景里我们要建模的对象不是股价而是某个模型在一段时间内收到的用户意见变化。一条意见可以来自一条帖子、一条评论、一个工单、一条反馈消息。把大量意见按照模型、平台、时间、情绪倾向聚合起来就形成了“模型体验指数”。这个指数想回答的问题非常聚焦“在这段时间里用过这个模型的用户整体感受是变好了还是变坏了”要达成这个目标需要先处理三个现实挑战。第一个挑战是模型名归一化。同一个模型在不同语境下叫法完全不同。有人写 Claude Sonnet有人写 claude-sonnet有人直接写“克劳德”有人写 GPT-4o有人写 gpt4o。如果不做归一化统计口径会立刻失真。第二个挑战是情绪判断。一条评论说“This model is not buggy”规则系统如果只看 buggy 关键词很可能把正面评价误判成负面。这说明简单的关键词匹配一定有误差需要在工程链路里设计兜底机制。第三个挑战是时间粒度。模型体验不是一成不变的服务端可能在一周内完成数次灰度更新。如果按月度聚合很多短期波动会被平均掉。合理的做法是先把意见按天沉淀再通过滑动窗口计算连续指数让短期异常能及时暴露出来。为了让你快速建立感知这里给出一个最小意见条目应该包含的字段字段含义示例model_name原始模型名gpt-4oplatform来源平台hacker_news / reddit / feedbackcontent评论或反馈正文今天好慢一直报错sentiment情绪倾向1 正面 / 0 中性 / -1 负面category问题类型slow / buggy / refusesource_url来源链接可选created_at发生时间ISO8601 时间有了这个结构采集、清洗、入库、聚合就都能标准化了。后续章节我会沿着这条链路逐步实现一个最小可用的模型。3. 口碑型指数与 Benchmark 评测的本质区别很多读者会问市面上已经有很多大模型评测基准像 MMLU、HumanEval、MT-Bench、LMArena还需要再做一套用户口碑指数吗我的观点是两者观测的完全不是同一个东西。Benchmark 适合回答“模型在预设任务上达到什么水平”用户口碑指数适合回答“模型在实际使用中体验如何波动”。前者是能力快照后者是体验温度计。两者的差异可以从多个维度看对比维度Benchmark 评测用户口碑体验指数数据来源固定测试集真实用户文本意见时效性按版本或发布周期更新可按天或周滚动更新主观偏差通过评测协议尽量控制天然存在需要归一化处理能力维度准确率、推理、编码等可用性、速度、拒绝率、幻觉等受服务影响较小很大容量与路由异常会直接体现典型用途模型选型、论文对比线上质量监测、客服体验看板Benchmark 的“失效”并不是说它没价值而是它覆盖不到生产环境中的高频扰动。比如某个模型在 HumanEval 上得分很高但它在高并发时频繁触发容量拒绝某个模型推理能力很强但它会在多轮对话中因为上下文管理问题频繁断开。这些体验问题用户不会写成“今天 Negative Log Likelihood 上升了”只会说“这模型真笨”。指数型项目本质上是在给 benchmark 补一个“用户在真实环境里实际感受到什么”的观测维度。它不做能力绝对值的排名而是做体验相对变化的追踪。理解了这一点你就不会问“这个指数能不能替代 Chatbot Arena”这类问题了它俩本就不该是替代关系。4. 数据源与合规边界不能见到什么就爬什么做用户口碑指数最容易被忽略但又最重要的问题是数据从哪里来。常见来源大致有这么几类公开社区Hacker News、Reddit、相关开发者论坛适合观察大众舆论。开发者平台GitHub Issues、产品 Feedback 区适合追踪特定编程工具的问题。自有产品反馈你所在团队收到的用户反馈、工单、问卷这是最可信、权益最清晰的数据。社交平台内容密度高但 API 限制严格数据获取和合规成本都很高。如果你只是个人追踪几个主流模型的表现我更推荐从 Hacker News、Reddit 这类有公开接口或历史数据集的平台开始。最小闭环不需要实时流可以先用导出的历史评论跑通流程再逐步增加定时采集。这里必须强调几条合规底线第一采集行为要遵守平台服务条款和 robots 协议。不要写一个无限并发的爬虫去抓取全站数据这对源站是负担也容易给自己带来法律风险。第二涉及个人信息的评论要脱敏。展示聚合结果时不要展示能够直接定位到具体用户的 ID、邮箱、联系方式。第三用户原文可以用于内部统计但如果要公开转发或引用需要谨慎评估版权和平台规则。最小原型阶段建议只做聚合展示不做原文墙。第四生产级系统要设置合理的采集频率和重试退避。对公开 API 要控制 QPS尽量使用官方提供的分页参数不做暴力翻页。一句话总结做体验指数的第一步不是写爬虫而是先想清楚数据的权利边界。数据来源不稳定后面所有工程都是白做。5. 系统整体设计与 SQLite 数据结构在动手写代码之前先把系统分清楚层级。一个最小可用的模型体验指数系统通常包含五层接入层接收 JSONL、CSV或API 返回的半结构化评论。清洗层做模型名归一化、正文去重、无效评论过滤。分类层根据关键词或调用模型判断情绪和问题类别。存储层把标准化的意见条目写入数据库。服务层提供指数查询 API 和可视化数据。原型阶段我建议直接用 SQLite 而不是 MySQL 或 PostgreSQL。原因很简单单文件、零部署、事务支持够用适合先把闭环跑通。等数据量到百万级、需要多人并发写入时再迁移到 PostgreSQL 也不迟。建表语句如下-- 文件路径schema.sql CREATE TABLE IF NOT EXISTS model_opinions ( id INTEGER PRIMARY KEY AUTOINCREMENT, model_name TEXT NOT NULL, platform TEXT NOT NULL DEFAULT , content TEXT NOT NULL, category TEXT NOT NULL DEFAULT , sentiment INTEGER NOT NULL DEFAULT 0, source_url TEXT NOT NULL DEFAULT , created_at TEXT NOT NULL ); CREATE INDEX IF NOT EXISTS idx_model_time ON model_opinions (model_name, created_at); CREATE INDEX IF NOT EXISTS idx_platform ON model_opinions (platform);这里有三个设计细节值得说明。第一created_at 直接使用 TEXT 类型保存 ISO8601 时间。SQLite 的 date 函数可以直接处理这种格式减少转换成本。但要注意统一使用 UTC 时间避免不同地区服务器写入的时间口径不一致。第二模型名虽然要保留原始名称用于追溯但统计时应该使用归一化后的标准名。为了简单我直接把归一化结果写回 model_name 字段原始名称可以在采集层单独保存原型阶段可以不建额外表。第三创建复合索引 idx_model_time是为了支撑最常见查询根据模型名查询一段时间内的意见分布。如果后续要按平台过滤再继续加索引。6. 环境准备与项目目录本文的代码需要 Python 3.8 以上环境推荐使用 3.10 或更高版本。SQLite 本身是 Python 标准库内置模块不需要单独安装。如果希望把指数通过 HTTP 接口暴露出来还需要安装 Flask。建议先创建项目目录mkdir model-experience-index cd model-experience-index python3 -m venv venv source venv/bin/activateWindows 环境下激活虚拟环境的命令为venv\Scripts\activate然后安装依赖pip install flask requestsrequirements.txt 可以这样写requests2.31.0 flask3.0.0版本号可以根据你本地的实际环境微调不需要严格锁定。这里的 requests 主要用于从公开接口拉取数据如果你已经有现成的 JSONL 文件甚至可以只保留 Flask。最终的目录结构如下model-experience-index/ ├── schema.sql ├── model_index_pipeline.py ├── index_query.py ├── app.py ├── data/ │ ├── raw.jsonl │ └── opinions.db └── requirements.txtdata 目录需要手动创建mkdir data7. 清洗与分类把一段评论变成带标签的数据这一阶段的输入是 data/raw.jsonl一行一条 JSON格式如下{model_name: gpt-4o, platform: dev_blog, content: The model refused to answer a simple coding question today, very disappointed., created_at: 2025-06-01T10:00:00Z, source_url: https://example.com/post/1} {model_name: Claude Sonnet, platform: hacker_news, content: Claude is so helpful. It solved my refactoring task accurately., created_at: 2025-06-01T11:00:00Z, source_url: https://example.com/post/2} {model_name: gpt-4o, platform: dev_blog, content: timeout again, the model is at capacity, I cannot continue my work., created_at: 2025-06-02T09:00:00Z, source_url: https://example.com/post/3}实际采集时created_at 请使用真实的采集时间或评论发布时间。下面这段代码会完成三个任务读取 JSONL、归一化模型名、基于关键词规则完成情绪分类。# 文件路径model_index_pipeline.py # -*- coding: utf-8 -*- import argparse import json import re import sqlite3 from datetime import datetime, timezone from pathlib import Path # 模型名归一化映射表 MODEL_ALIASES { gpt-4o: gpt-4o, gpt4o: gpt-4o, gpt-4o-mini: gpt-4o-mini, gpt4o-mini: gpt-4o-mini, claude: claude, claude-sonnet: claude-sonnet, claude sonnet: claude-sonnet, deepseek-r1: deepseek-r1, deepseek r1: deepseek-r1, } # 问题类别与关键词注意这里不做复杂 NLP POSITIVE_WORDS { helpful: [helpful, impressive, amazing, accurate, great answer, works perfectly, 好用, 准确, 惊艳], fast: [fast, snappy, instant, no latency, 非常快, 流畅], } NEGATIVE_WORDS { refuse: [refuse, cannot answer, cant answer, not allowed, 拒绝回答, 无法回答, sorry], buggy: [bug, wrong, incorrect, false, hallucination, 编造, 胡说, 错误, 幻觉, 不对, 有问题], slow: [slow, timeout, lag, at capacity, unavailable, 卡顿, 超时, 无法连接, 断连], } def normalize_model(raw_name: str) - str: 把不同写法归一化成标准模型名。 if not raw_name: return unknown key raw_name.strip().lower() return MODEL_ALIASES.get(key, key) def classify_and_score(text: str): 基于关键词做粗分类返回 (category, sentiment)。 sentiment: 1 表示正面-1 表示负面0 表示中性或混合。 category: 多个类别使用逗号拼接。 lowered (text or ).lower() pos_hits, neg_hits [], [] for cat, words in NEGATIVE_WORDS.items(): for word in words: if word in lowered: neg_hits.append(cat) break for cat, words in POSITIVE_WORDS.items(): for word in words: if word in lowered: pos_hits.append(cat) break if pos_hits and neg_hits: return mixed, 0 if neg_hits: return ,.join(neg_hits), -1 if pos_hits: return ,.join(pos_hits), 1 return uncategorized, 0 def process_raw_file(raw_file: str, db_file: str) - int: 读取 JSONL 文件并写入 SQLite。 db sqlite3.connect(db_file) db.execute( CREATE TABLE IF NOT EXISTS model_opinions ( id INTEGER PRIMARY KEY AUTOINCREMENT, model_name TEXT NOT NULL, platform TEXT NOT NULL DEFAULT , content TEXT NOT NULL, category TEXT NOT NULL DEFAULT , sentiment INTEGER NOT NULL DEFAULT 0, source_url TEXT NOT NULL DEFAULT , created_at TEXT NOT NULL ) ) inserted 0 with open(raw_file, r, encodingutf-8) as fh: for line in fh: line line.strip() if not line: continue item json.loads(line) content (item.get(content) or ).strip() if len(content) 3: continue raw_model item.get(model_name, ) model_name normalize_model(raw_model) platform (item.get(platform) or unknown).strip() source_url (item.get(source_url) or ).strip() created_at item.get(created_at) if not created_at: created_at datetime.now(timezone.utc).isoformat(timespecseconds) category, sentiment classify_and_score(content) db.execute( INSERT INTO model_opinions (model_name, platform, content, category, sentiment, source_url, created_at) VALUES (?, ?, ?, ?, ?, ?, ?) , (model_name, platform, content, category, sentiment, source_url, created_at), ) inserted 1 db.commit() db.close() return inserted if __name__ __main__: parser argparse.ArgumentParser(description模型体验指数 - 数据清洗入库) parser.add_argument(--input, defaultdata/raw.jsonl, help输入 JSONL 文件) parser.add_argument(--db, defaultdata/opinions.db, helpSQLite 数据库文件) args parser.parse_args() total process_raw_file(args.input, args.db) print(f清洗入库完成共插入 {total} 条意见)代码里需要解释几个关键点。MODEL_ALIASES 映射表用于统一大小写和常见缩写实际生产环境中这份映射表应当做成独立配置文件方便在不改代码的前提下扩充。classify_and_score 函数基于关键词做粗分类它只能作为基线不能期待它达到 GPT-4 级别的语义理解。但它的好处是确定性强、可解释、无额外成本原型阶段完全够用。情绪判定时的正负同时命中会被归为 mixed这比简单把正负相加更稳妥。试想一条评论写“It is fast but often wrong”它既包含“fast”又包含“wrong”如果只统计关键词数量可能被算成正样本这是失真。归为混合中性至少不会污染情绪汇总。代码里的一处易错点是在写 SQL 时不能使用普通字符串格式化拼接评论内容而是必须使用问号占位符。因为真实评论里经常出现百分号、单引号等特殊字符如果用 % 格式化去拼 SQL就会出现类似 unsupported format character 的异常。参数化查询可以彻底规避这个问题。执行命令如下python model_index_pipeline.py --input data/raw.jsonl --db data/opinions.db如果一切正常会看到输出清洗入库完成共插入 3 条意见此时可以用 SQLite 命令验证sqlite3 data/opinions.db SELECT model_name, category, sentiment, created_at FROM model_opinions;你会看到类似于下面的结果gpt-4o|refuse|-1|2025-06-01T10:00:00Z claude-sonnet|helpful|1|2025-06-01T11:00:00Z gpt-4o|slow|-1|2025-06-02T09:00:00Z8. 指数计算用滑动窗口观察趋势清洗入库只是第一步。真正有价值的是把离散的意见聚合成可观察的曲线。这里定义一种简单的指数在某个时间窗口内负面意见数量占该窗口总意见数的比例乘以 100。数值越高代表用户负面体验占比越高。为了避免单日样本过少带来的剧烈抖动代码里加入了滑动窗口和最小样本量门槛。# 文件路径index_query.py # -*- coding: utf-8 -*- import argparse import sqlite3 from collections import defaultdict from datetime import date, datetime, timedelta def compute_index(db_file: str, model_name: str, window: int 14, min_samples: int 3): 计算模型在滑动窗口内的负面体验指数。 index 越高表示该时间段内用户负面评价占比越高。 conn sqlite3.connect(db_file) conn.row_factory sqlite3.Row rows conn.execute( SELECT date(created_at) AS day, sentiment, COUNT(*) AS cnt FROM model_opinions WHERE model_name ? GROUP BY date(created_at), sentiment ORDER BY day , (model_name,), ).fetchall() conn.close() daily_agg defaultdict(lambda: {pos: 0, neg: 0, neu: 0}) for row in rows: day row[day] if row[sentiment] 1: daily_agg[day][pos] row[cnt] elif row[sentiment] -1: daily_agg[day][neg] row[cnt] else: daily_agg[day][neu] row[cnt] if not daily_agg: return [] start_day datetime.strptime(min(daily_agg.keys()), %Y-%m-%d).date() end_day datetime.strptime(max(daily_agg.keys()), %Y-%m-%d).date() series [] # buffer 中只保留当前滑动窗口内的日聚合数据 buffer defaultdict(lambda: {pos: 0, neg: 0, neu: 0}) def clean_buffer(current_day: date): expired [d for d in buffer if (current_day - d).days window] for d in expired: del buffer[d] current start_day while current end_day: key current.isoformat() clean_buffer(current) if key in daily_agg: buffer[current] daily_agg[key] else: buffer[current] {pos: 0, neg: 0, neu: 0} total sum(buffer[d][pos] buffer[d][neg] buffer[d][neu] for d in buffer) neg sum(buffer[d][neg] for d in buffer) if total min_samples: index_value round(neg * 100.0 / total, 2) series.append({ date: key, index: index_value, samples: total, }) current timedelta(days1) return series if __name__ __main__: parser argparse.ArgumentParser(description模型体验指数 - 查询与计算) parser.add_argument(--db, defaultdata/opinions.db) parser.add_argument(--model, defaultgpt-4o) parser.add_argument(--window, typeint, default14) parser.add_argument(--min-samples, typeint, default3) args parser.parse_args() result compute_index(args.db, args.model, args.window, args.min_samples) if not result: print(没有找到该模型的数据请检查模型名是否拼写正确) raise SystemExit(1) print(f{date:12}{index:10}{samples}) for item in result: print(f{item[date]:12}{item[index]:10}{item[samples]})这段代码在理解上有三个重点。第一SQL 使用 date(created_at) 把 ISO8601 时间字符串截断到天方便按天聚合。GROUP BY 中的 sentiment 能统计每日正负中三条数量这样可以减少 Python 层的计算量。第二buffer 保存的是滑动窗口内的数据。每进入一个新日期先淘汰超过窗口天数的旧数据再加入当天数据再计算当前窗口的负面比例。这和移动平均的思想是一致的能有效平滑单日波动。第三min_samples 参数的用意是防止样本太少时指数失真。如果某一天只有一条负面评论负面率就是 100%这显然不能说明模型突然变差了。只有当窗口内总样本数达到门槛时才输出指数。执行查询命令python index_query.py --db data/opinions.db --model gpt-4o --window 14示意输出如下date index samples 2025-06-01 50.0 2 2025-06-02 66.67 3这里 2025-06-01 有两条例样本一条负面一条正面所以指数是 502025-06-02 有三条例样本其中两条负面所以指数约 66.67。如果你的数据量更大曲线会平滑很多。9. 提供一个轻量的 HTTP 查询接口聚合计算完成后下一步自然是通过接口暴露给前端或监控系统。这里用 Flask 写一个最小 API。# 文件路径app.py # -*- coding: utf-8 -*- from flask import Flask, jsonify, request from index_query import compute_index app Flask(__name__) app.route(/api/index, methods[GET]) def api_index(): model_name request.args.get(model, gpt-4o) window request.args.get(window, 14, typeint) min_samples request.args.get(min_samples, 3, typeint) series compute_index( data/opinions.db, model_namemodel_name, windowwindow, min_samplesmin_samples, ) if not series: return jsonify({model: model_name, error: no enough data or unknown model}), 404 return jsonify({model: model_name, series: series}) if __name__ __main__: app.run(host0.0.0.0, port8000, debugFalse)启动服务python app.py然后在另一个终端执行curl http://127.0.0.1:8000/api/index?modelgpt-4owindow14预期返回一段 JSON核心结构如下{ model: gpt-4o, series: [ {date: 2025-06-01, index: 50.0, samples: 2}, {date: 2025-06-02, index: 66.67,