企业官网建设流程全解析

要判断一个 AI 模型有没有变笨，不能只靠逛开发者社区时刷到的零星吐槽。项目标题里的“AI model experience from user's opinion”这种做法，正好戳中了很多 AI 应用团队的真实痛点：用户每天产生大量主观意见，但缺少一个把意见转成可比指标的方法。“Is AI Dumber Today? An index of AI model experience from user's opinion” 想做的事情，本质上不是替某个模型翻案，而是建立一套从用户观点出发的体验指数，让“变笨了”“变聪明了”这种模糊感觉变成可观测、可统计、可回归验证的数据。这篇文章就沿着这条思路展开：先分析用户为什么会产生这种观感，再讲体验指数的口径和采集层，然后给出一套最小 Python 实现，最后讨论如何用回归探测、置信区间和分层分析来区分“真实能力回退”和“观感波动”。

1. 为什么用户会产生“模型变笨了”的观感

1.1 用户嘴里的“变笨”至少对应五种不同变化

当一个用户说某个 AI 助手“变笨了”，他可能只是在表达“这次回答不可用”，但背后的成因可能完全不同。如果产品团队、AI Infra 团队只凭几条截图和一段聊天记录就下判断，很容易把不同类型的问题混在一起处理。

常见的五种真实变化包括：

• 能力分布漂移：模型从版本 A 升级到版本 B 后，代码补全变强了，但长文本归纳变弱了。用户只使用长文本归纳场景，就会觉得变笨。
• 策略与安全取向改变：升级后拒绝率上升，或者回答变得非常保守。能力没有下降，但用户可用性降低了。
• 上下文窗口变大后的注意力分散：支持更长上下文之后，模型在超长对话里更容易遗忘早期指令，用户体验像是“记忆退化”。
• 生成风格改变：模型从简洁回答变成话多但信息密度低。用户不关心它是不是更有礼貌，只认为它变啰嗦了。
• 服务端路由和参数不稳定：同一个“模型版本号”背后实际路由到多个上游模型，或者采样温度被调整过，用户在不同时间提问，效果差异巨大。

这些现象并不互相排斥。一次完整的“模型变笨”反馈里，可能既包含能力回退，也包含产品策略调整，还包含用户主观预期的变化。工程上要做的是先把这些因素拆开。

1.2 观感不等于回退：体验是预期与结果的差

用户对 AI 模型的评价，从来不是对“正确答案概率”的直接映射，而是对“预期体验”的差值判断。同一个回答，放在去年可能让用户惊喜，放在今天却会被认为是明显退步。这种参照系差异会影响体验指数，但不会影响自动评测任务集的分数。

假如只用一个 Bench 分数来衡量模型，很可能会忽略用户在真实场景里的挫败感。反过来，只看用户评分，又会把版本升级带来的能力提升掩盖掉。因此，“从用户观点建立的 AI 模型体验指数”应该被理解成一个产品指标，而不是学术评测指标。

它是产品经理、客服、应用开发者、模型运营者都能使用的中间层：把主观意见变成相对固定的口径，再把口径落到具体的时间、版本、任务和能力维度上。后续讨论模型是否真的变笨时，至少有一个双方都能接受的讨论框架。

1.3 缺少统一指数和缺少归因信息是同一件事的两面

很多团队做不好用户意见分析，不是因为不会写文本分类，而是日志里没有版本信息、提示词版本、请求时间、用户行为。一个用户反馈“你这模型最近不会写 SQL”，如果日志里只记录了用户名和反馈内容，根本没法确认他使用的是哪个上游模型、哪个推理参数、哪一版提示词。

“指数”的价值不在于给出一个精确到小数点后两位的数字，而在于强迫团队把口径、数据源、样本量、时间窗口、版本信息都统一起来。没有这些前提，指数只会变成又一张没人看得懂的大屏。

2. 体验指数口径设计：先讲清楚统计的是什么

2.1 不要用单一评分掩盖样本结构差异

设计指数之前，先看常见误区：直接计算“好评率”。假设版本 A 上线后新增了大量代码生成用户，代码任务本身更难，负面率天然偏高。此时好评率下降，并不是模型变笨了，而是用户任务分布变了。

为了减少任务分布的影响，指数至少要从两个维度做分层：

• 任务类别：代码生成、数学推理、知识问答、文案写作、工具调用、Agent 规划等。
• 用户来源或渠道：应用内反馈、客服工单、公开社区文本、产品埋点。

每一条用户意见需要能落到“版本 + 任务 + 时间”这三个坐标里。如果日志里没有任务类别，可以用关键词规则、提示词模板 ID 或模型应用名称去映射，但不要等到统计分析时才手动补。

2.2 一个可以用代码复现的最小口径公式

先定义原始事件。假设一个事件对应一次完整对话或一次明确反馈，例如点赞、点踩、复制回答、继续追问、提交工单。体验指数的常见计算方式是：

体验指数 = (正面加权评分 - 负面加权评分) / 事件总数 × 100

这里把评分限定在[-1, 1]区间。负分表示不满意，正分表示满意，0 表示中性或没有明确反馈。如果事件总数太小，就不能直接比较，需要用置信区间控制波动。更严格的做法是先按事件分层，再计算加权平均值。

实际项目中不要在一个公式里塞太多加权因子。最低可用的口径是：

每日净正面率 = (当日正面事件数 - 当日负面事件数) / 当日有效反馈样本数

这个数值可以很方便地按日画趋势。正式对外展示时再扩展到“净正面率 + 样本量 + 波动区间”的复合指标。

2.3 意见强度、成本感知和严重度是否应该进公式

用户反馈并不是非黑即白。一个用户说“回答不太满意，但还能用”，另一个用户说“这个代码在生产环境造成数据回滚了”，两者都算负面，但对最终体验的破坏程度完全不同。

因此指数公式可以包含严重度权重。生产环境建议在事件表里增加severity字段，至少区分三级：

此外，成本也会强烈影响主观体验。按 Credits 计费的场景里，用户消耗了比较多的积分却得到低质量回答，更容易产生“价值下降”的判断。这里不讨论 Credits 到底如何换算，只需要知道：成本越敏感的场景，用户对失败的回答越不宽容。如果想让指数对产品有指导意义，必须把计费消耗或用户付费状态作为分层变量。

2.4 样本量与置信区间是口径的一部分

口径设计时最容易忽略“样本数量不够”。如果一天只有十几条用户反馈，净正面率从 20% 跌到 0% 可能只是随机波动。

建议每个版本对比周期内都同时输出样本量和置信区间。小规模团队可以先使用 Wilson 区间估计样本可靠性：

import math def wilson_interval(positive, total, z=1.96): if total == 0: return (0.0, 0.0) p = positive / total denominator = 1 + z * z / total center = p + z * z / (2 * total) margin = z * math.sqrt((p * (1 - p) + z * z / (4 * total)) / total) lower = (center - margin) / denominator upper = (center + margin) / denominator return max(0.0, lower), min(1.0, upper)

这个函数会出现在后面完整管道里。先把它当作统计判断的辅助工具：当两条时间区间的置信区间重叠范围很大时，不要急着下“变笨了”的结论。

3. 数据采集层：先让意见变成结构化事件

3.1 首选第一方埋点，社区公开内容只做补充

常见的数据源有四类，优先级各不相同：

采集公开社区文本时要注意平台条款和个人信息保护。技术博客里不展开讨论合规细节，但生产团队必须让法务提前介入。宁可把指数建立在自家产品埋点上，也不要为了样本量去采集不可控的公开数据。

3.2 事件结构要同时支持“用户怎么看”和“实例怎么跑”

收集事件时，字段越完整，后面排查越简单。一个比较合理的最小事件结构如下：

{ "event_id": "evt_20260710_0001", "request_id": "req_8f3a1", "request_at": "2026-07-10T08:31:00Z", "model_version": "assistant-v2-20260701", "prompt_version": "prompt_v3", "task_category": "code_generation", "model_provider": "llm-gateway-prod", "latency_ms": 1872, "completion_tokens": 682, "credits_used": 3, "feedback_action": "down", "feedback_text": "生成的排序逻辑忽略了空数组", "severity": "medium", "ab_group": "experiment" }

这里要注意model_version和用户感知到的“模型名称”不一定一致。前端可能展示的是某个模型别名，但实际后端网关可能已经灰度到新小版本。记录model_version时必须写网关解析后的最终版本，而不是页面上的展示名。

3.3 日志写入位置与聚合策略

事件采集不应直接写在业务主流程里并同步阻塞响应。比较好的做法是把事件放进消息队列，或者使用异步日志。

中小型项目可以用 PostgreSQL 保存明细表，再按小时或按天跑聚合任务。数据量增大后再迁移到 ClickHouse、BigQuery 等分析型存储。这里不推荐一开始就引入复杂组件，因为指数的第一步是口径稳定，而不是吞吐量。

明细表可以简化成：

CREATE TABLE ai_user_feedback_events ( event_date Date, event_ts DateTime, request_id String, model_version String, prompt_version String, task_category String, feedback_action String, feedback_text String, severity String, ab_group String ) ENGINE = MergeTree ORDER BY (event_date, model_version, task_category);

排序键的设计关键是“按日期、模型版本、任务类别查询”，这样版本对比脚本运行时不需要全表扫描。

4. 用 Python 实现一个最小体验指数管道

4.1 项目结构与数据模型

为了方便复现，这里提供一个最小实现，项目结构如下：

ai_experience_index/ ├── labeler.py ├── index.py ├── compare.py └── events.json

先定义一个事件数据类和意见标签枚举。使用 Python 3.10 之后的类型语法可以写得更简洁。

# labeler.py from __future__ import annotations from dataclasses import dataclass from enum import Enum from typing import Optional class Opinion(Enum): POSITIVE = 1 NEUTRAL = 0 NEGATIVE = -1 @dataclass class UserEvent: event_id: str model_version: str task_category: str feedback_action: Optional[str] feedback_text: str severity: Optional[str] = None credits_used: float = 0.0 @dataclass class LabeledEvent: event: UserEvent opinion: Opinion strength: float

这样就把原始日志和分类结果分开。后续无论是改分类模型还是改指数公式，都不会影响原始事件结构。

4.2 意见标签器：先跑通规则版本，再替换成模型分类

真实的用户体验分析中，文本判断很难完全用关键词解决。但最小管道不需要一开始就接大型模型。先用规则版本验证整个流程，再考虑用 LLM 分类或微调模型都是合理的路径。

下面是一个简易的标签器：

# labeler.py 追加 NEGATIVE_WORDS = [ "错", "失败", "不能用", "变笨", "退步", "垃圾", "误导", "崩", "不回", "乱写", "漏掉", "无效", "坏了" ] POSITIVE_WORDS = [ "好用", "很准", "满意", "牛逼", "厉害", "能跑", "清晰", "有帮助", "比之前好", "解决" ] class RuleBasedLabeler: def label(self, event: UserEvent) -> LabeledEvent: text = f"{event.feedback_text} {event.feedback_action or ''}".lower() negative_score = sum(1 for w in NEGATIVE_WORDS if w in text) positive_score = sum(1 for w in POSITIVE_WORDS if w in text) if event.feedback_action == "up": positive_score += 2 elif event.feedback_action == "down": negative_score += 2 if positive_score > negative_score: opinion = Opinion.POSITIVE elif negative_score > positive_score: opinion = Opinion.NEGATIVE else: opinion = Opinion.NEUTRAL strength = abs(positive_score - negative_score) strength = min(strength, 3.0) / 3.0 return LabeledEvent(event=event, opinion=opinion, strength=strength)

这个规则版本的问题很明显：关键词列表会漏掉同义表达，也会误判反讽。所以进入生产前必须用人工标注集评估。建议准备几百条带标签样本，用来验证分类准确率；如果低于 80%，就考虑接一个专业 LLM 分类器。

4.3 指数计算模块：分层输出趋势

计算指数时不直接输出一个总分，而是输出一个分版本、分任务的结果：

# index.py from collections import defaultdict from dataclasses import dataclass, field from typing import List from labeler import Opinion, LabeledEvent @dataclass class IndexResult: model_version: str task_category: str total: int positive: int negative: int neutral: int score: float @dataclass class ExperienceIndex: events: List[LabeledEvent] def compute(self) -> List[IndexResult]: groups: dict[tuple[str, str], List[LabeledEvent]] = defaultdict(list) for le in self.events: key = (le.event.model_version, le.event.task_category) groups[key].append(le) results = [] for (model_version, task_category), event_list in groups.items(): total = len(event_list) positive = sum(1 for e in event_list if e.opinion == Opinion.POSITIVE) negative = sum(1 for e in event_list if e.opinion == Opinion.NEGATIVE) neutral = total - positive - negative score = (positive - negative) / total * 100 if total else 0.0 results.append(IndexResult( model_version=model_version, task_category=task_category, total=total, positive=positive, negative=negative, neutral=neutral, score=score )) return results

上面的score表示“净正面率 × 100”，取值区间在[-100, 100]。把它画在时间轴上，正分代表净正面，负分代表净负面。

4.4 版本对比模块：带上时间窗口和显著性判断

版本对比是体验指数最常见的场景。运行下面这段脚本，可以看到模型版本 A 和 B 在各任务类别上的差异：

# compare.py from datetime import datetime, timedelta from typing import List from labeler import UserEvent, RuleBasedLabeler from index import ExperienceIndex from labeler import Opinion def filter_by_window( events: List[UserEvent], start: datetime, end: datetime ) -> List[UserEvent]: return [ e for e in events if start <= datetime.fromisoformat(e.request_at.replace("Z", "+00:00")) <= end ] def compare_models(events: List[UserEvent], labeler=RuleBasedLabeler()): labeled = [labeler.label(e) for e in events] index = ExperienceIndex(labeled) results = index.compute() return results

命令行入口可以这样写：

python compare.py --start 2026-07-01 --end 2026-07-10 --model assistant-v2-20260701

实际生产实现还要补两个参数：版本过滤和时间窗口。运行后预期的输出格式如下：

model=assistant-v2-20260701 task=code_generation total=1280 score=-12.5 model=assistant-v2-20260701 task=math_reasoning total=412 score=6.2 model=assistant-v2-20260710 task=code_generation total=1107 score=-8.1

不要只比较 score，还要比较每一行的 total。样本量相差太大时，优先看置信区间。

5. 如何验证“变笨”是真回退还是观感波动

5.1 先看同一版本长期趋势，再谈版本切换

如果用户反馈“最近变笨了”，但版本并没有升级过，最可能的原因是任务分布变化、提示词调整或上游路由变化。排查时先过滤出同一个model_version的 30 天趋势，按周聚合净正面率。

判定逻辑是：

1. 长期趋势没有明显突变，只是短期波动：先怀疑随机噪声或社区热帖。
2. 趋势在某一天之后持续走低：检查那天是否发布过新版本、策略、提示词或路由规则。
3. 版本没变但分数持续走低：大概率是入口流量或任务结构变了。

5.2 用固定回归任务集做能力探测

用户观点指数能反映“体验质量”，但无法准确指出“是哪个能力下降了”。因此需要一组固定回归任务，每次版本更新前跑一遍。

回归任务集不需要覆盖所有真实用户问题，它更像体温计。建议选择四到六类典型任务，每类准备 20 到 100 个输入输出对：

• 代码生成：给定需求文本，检查代码是否含正确边界处理。
• 数学计算：给定算式，检查结果是否准确。
• 长文本归纳：给定长文档，检查关键实体和信息是否被保留。
• 工具调用：给定自然语言请求，检查是否生成正确 JSON 参数。
• 安全拒绝：给定不合规请求，检查是否拒绝且没有提供替代危害建议。

把每次回归结果存成同一格式，和用户意见指数交叉验证。如果回归集分数下降，同时用户负面率上升，真实回退的可能性就很高。如果回归集没变，只有用户负面率上升，则重点查产品策略、UI、计费或运营活动。

5.3 用分层对比排除任务分布干扰

直接比较总体负面率没有意义。正确做法是按task_category做分层对比。每个任务类别单独计算分数和置信区间。

如果所有任务类别的负面率都上升，可以怀疑模型整体变弱或策略整体收缩。如果只有创意写作上来了，代码生成没变化，那不能得出整体“变笨”的结论。

5.4 给结论加一个“疑似根因”标签

每次模型团队讨论用户反馈时，最怕信息缺位。建议最终报告输出一个统一结论块：

这种结论表比“用户说变笨了”更有讨论价值。

6. 能力维度拆分：把体验指数从总分变成雷达

6.1 任务类别不等于能力维度

前文多次使用task_category，但它更适合日志分类。真正分析模型能力时，还需要从任务里抽出能力维度。例如“代码生成”任务既可能测长代码规划能力，也可能测第三方库知识。仅凭任务类别定义指数，粒度太粗。

一个可行的标签思路是在事件里额外增加capability字段。最小能力维度可以包括：

6.2 不要把“用户觉得差”直接写成“能力差”

在体验指数看板上可以展示“用户侧体验下降”和“能力回归集变化”两类数据。产品页面上的文案应当保留区分，例如：“用户负面率上升了 12%，但固定回归集分数没有显著变化，怀疑是版本提示词风格导致的感知差异”。

这样写的好处是避免把产品问题全部推给模型能力，也避免把模型性能问题伪装成用户主观情绪。

6.3 输出一张可分享的模型体验卡片

把线下计算结果集合成一张卡片，方便产品、算法、测试协作。JSON 示例：

{ "model_version": "assistant-v2-20260710", "compare_to": "assistant-v2-20260601", "user_feedback_index": { "score_before": 5.2, "score_after": -8.4, "sample_size_after": 4802 }, "capability_breakdown": { "instruction_following": { "regression_score_before": 0.92, "regression_score_after": 0.91, "state": "stable" }, "long_context_dependency": { "regression_score_before": 0.85, "regression_score_after": 0.71, "state": "degraded" } }, "suspected_cause": "长上下文检索头在超长输入下表现劣化", "next_step": "运行长上下文归因实验，准备异常长样本集" }

这种结构化输出可以直接接入监控告警。

7. 常见观感偏差与工程化过程中的坑

7.1 热帖和社交传播会污染短期指数

一条十万播放的视频或帖子，短时间会带来大量差评。这些反馈往往来自没有完整使用过模型的用户，情绪强度高，文本噪声大。

处理方式有两种：

• 把公开社区内容单独存表，不混入产品内反馈主指数。
• 在主指数中增加渠道权重，或至少输出时不把“社区文本情绪”写成“产品内真实体验”。

最稳妥的策略是：第一方埋点负责指数趋势，公开社区负责舆情预警。两者可以交叉观察，但不合并打分。

7.2 同一条任务样例在不同形式下结果差异很大

做回归对比时，很容易把“同样的需求文本”当成“同样的测试样例”。实际上，用户需求文本一变，模型效果可能差很多。

建议把回归集的输入做结构化保存，记录需求文本、目标模型、推理参数、期望点。比较时只对比完全一致的任务文本，或者按任务意图分组后再做统计。手动把用户真实问题改成测试集时，要注意改写后可能丢失原始约束条件。

7.3 模型版本号不在日志里，任何定位都无从谈起

这个坑在真实项目里非常常见。日志只有model=assistant，但后面的真实版本已经灰度切换多次。发现问题时，找不到哪个上游模型、哪一版 prompt 产生的回答。

补救方式是补上请求链路追踪 ID，在日志中记录网关返回的model_version、prompt_version和sampling_params。如果使用类似 Spring AI 的框架，需要在调用前后使用拦截器记录上下文信息，而不是只写一通业务日志。

7.4 用户请求分布变化被误认为质量下降

假设某周产品引导用户测试更复杂的 Agent 工作流，用户失败率必然升高。看起来是指数下降，实际是任务难度上升。比较两个版本时，必须观察任务类别占比是否发生漂移。如果版本 B 期间代码生成占比更高，总体负面率不能直接对比。

7.5 只读取用户明确表达的反馈，会漏掉大量被动不满意事件

不是所有用户都会点“踩”或者写评论。只有明确差评率上升时，说明问题已经很严重。比较好的做法是同时记录“停止生成”“立即复制上个版本答案”“连续重试”等行为信号，把它们作为隐性负面事件。

7.6 问题排查速查表

8. 工程化落地清单与扩展方向

8.1 上线前检查清单

• 每一条反馈事件是否包含model_version、prompt_version、request_id？
• 是否在代码里为失败请求也写了日志？失败请求往往比成功请求更有价值。
• 是否明确区分了应用内反馈和社区舆情？
• 是否有同一个模型的回归集基线？
• 是否记录了任务类别？如果系统没有自动分类，是否给用户提供了标签入口？
• 是否用 UTC 时间做事件对齐？
• 是否对日志中的私密信息做脱敏？
• 指数输出是否同时带样本量和置信区间？

把这张清单写进发布流程，比事后折腾统计口径要省时得多。

8.2 体验指数产品化的最佳实践

不要把指标做成单一数字。建议一个真正的 AI 体验指数看板包含以下四块内容：

1. 总览层：净正面率、明确负面率、样本量。
2. 趋势层：按日或周展示分数的置信区间带。
3. 分层层：按版本、任务、能力维度、用户渠道进行交叉筛选。
4. 归因层：每个看板都链接到最近一次模型发版记录和回归集结果。

运营上还应该设置报警，但要避免使用瞬时值报警，因为用户反馈天然有滞后性。推荐使用 7 日滚动窗口，并且只有当指标低于基线且置信区间不与该基线重叠时才告警。

8.3 向用户观点之外扩展

体验指数不只是测试和运营工具，还可以反哺 AI 应用开发中的路由与调度。常见做法包括：

• 对低质量高严重度任务增加人工复审阈值。
• 根据用户对成本与质量偏好，把请求路由到不同模型。
• 在 Agent 场景中把任务拆成多个子步骤，每一步单独记录反馈，定位退化出现在哪个环节。

甚至可以在提示词版本管理里加入“用户反馈迟报”。当 prompt 改动上线后，持续观察对应任务类别的指数变化。如果两周内没有明显负面波动，再扩大灰度。

AI 模型到底有没有变笨，最终不应该只靠社区经验来判断。它需要产品侧的用户意见、工程侧的版本日志、评估侧的回归集三者共同回答。这篇内容的核心建议是：先定义口径，再沉淀日志，然后用分层统计和回归集交叉验证。照着这个顺序去处理“模型变笨”反馈，得到的结论会比单条聊天记录可靠得多，后续做模型升级、提示词调整和成本策略时，也更容易找到具体抓手。