大模型为什么会幻觉

7217 字
36 分钟
大模型为什么会幻觉

1. 今日主题与一句话结论#

主题:大模型为什么会幻觉

一句话结论: 大模型的幻觉不是偶发小毛病,而是概率生成、训练数据、上下文缺失、采样策略和产品设计共同作用的结果;产品经理不能指望模型“永远说真话”,而要把事实来源、引用、拒答、校验和人工兜底设计进系统。

模型会在上下文中计算关系,并预测最可能的下一个内容。这个能力让它能写文案、总结、问答、翻译、抽取信息,也带来一个关键风险:

它生成的是“看起来最合理的文本”,不天然等于“被事实验证过的答案”。

这就是幻觉的根源。幻觉不是简单的“模型不聪明”,也不是单纯换一个更大模型就能完全消失。更大的模型通常会减少低级错误,但只要系统缺少可靠事实来源、检索、权限、规则和评估,它仍然可能在关键业务场景里给出错误答案,而且语气非常笃定。

今天的学习目标不是记住“幻觉很危险”这句废话,而是建立可落地的判断方法:

  • 什么问题容易诱发幻觉?

  • 哪些场景可以接受轻微幻觉,哪些必须零容忍?

  • 产品流程里应该在哪些节点拦截?

  • PRD 里如何写清楚风险、指标和验收标准?

  • 团队评审时如何让研发、业务、法务、运营形成一致边界?


2. 学习目标#

  1. 解释大模型幻觉的主要来源:概率生成、训练数据缺陷、上下文缺失、采样随机性、检索失败、指令冲突。

  2. 区分事实记忆、文本生成、逻辑推理和业务决策,避免把模型的语言流畅度误认为可靠性。

  3. 判断不同业务场景中幻觉的风险等级,并设计对应的兜底机制。

  4. 为知识库问答、智能客服、内容生成、数据分析等场景设计幻觉测试题。

  5. 把幻觉控制写进产品方案:引用、拒答、置信度、规则校验、人工审核、日志、评估集和灰度策略。


3. 深度阅读:幻觉不是“答错”,而是系统可靠性问题#

3.1 什么是大模型幻觉#

大模型幻觉指模型生成了看似合理、表达流畅、语气自信,但事实不准确、依据不存在、逻辑不成立或超出可验证范围的内容。

常见表现包括:

  • 编造不存在的制度条款。

  • 编造论文、书名、作者、链接或数据来源。

  • 把旧政策当成新政策。

  • 把别的公司规则套到当前公司。

  • 对没有权限或没有资料的问题给出确定答案。

  • 在客服场景里承诺退款、赔付、发货时间。

  • 对数据分析结果编造原因。

  • 对法律、医疗、金融问题给出超出资质的建议。

幻觉不等于所有错误。普通系统也会错,比如接口超时、数据库脏数据、规则配置错误。但大模型幻觉的特殊之处在于:

  1. 表达很像真的。 它不会像传统系统那样明显报错,而是生成完整回答。

  2. 错误难以肉眼识别。 用户容易被流畅语言说服。

  3. 同问可能不同答。 输出受上下文、采样和模型版本影响。

  4. 责任边界模糊。 用户会把模型回答当成产品承诺。

  5. 复盘成本高。 如果没有日志、引用和评估集,很难定位错误来源。

所以幻觉不是“模型答错了一次”这么简单,而是 AI 产品可靠性、风控和组织责任问题。

3.2 概率生成:模型为什么会一本正经地编#

大语言模型常见训练目标是根据上下文预测下一个 Token。它学到的是大量文本中的语言模式、概念关系、表达方式和推理样式。

当用户问:

我们公司差旅制度里,二线城市住宿超标 20% 是否可以报销?

如果模型没有看到你公司的真实制度,它仍然可以根据大量通用文本生成一个“像制度回答”的文本:

一般情况下,住宿费用超出标准 20% 以内,经直属领导审批后可以报销。

这句话很像真实制度,也符合很多企业常见写法。但它可能与你公司制度完全不一致。模型并不是故意骗人,而是在缺少事实依据时继续完成语言任务。

产品经理需要记住一个判断:

模型默认倾向于给答案,而不是默认停下来验证事实。

这就是为什么 AI 产品要主动设计拒答、追问和引用。不要把“请准确回答”写进 Prompt 后就认为风险消失了。Prompt 是约束,不是事实来源。

3.3 训练数据缺陷:模型知道的东西不等于你的业务事实#

模型训练数据来自公开文本、授权数据、代码、网页、书籍、问答、合成数据等。即使训练数据规模很大,也有几个天然问题:

  • 数据可能过时。

  • 数据可能互相矛盾。

  • 数据可能包含错误。

  • 数据未必覆盖你的公司制度、商品规则、合同版本。

  • 数据中的表达频率不等于事实正确性。

  • 模型训练后不会自动知道你的最新业务变化。

这对企业 AI 项目影响很直接。比如:

  • 公司 2026 年 7 月更新了报销制度,模型训练数据不可能自动知道。

  • 平台活动规则昨天变了,模型不会自己同步。

  • 商品售后政策按类目、店铺、订单状态变化,模型不能凭常识判断。

  • 客服工单里有用户个案,模型没有权限也没有上下文。

所以企业里几乎所有“事实型回答”都不能只依赖模型记忆。可靠做法是:

用户问题
-> 权限校验
-> 检索当前有效资料
-> 模型基于资料生成回答
-> 引用来源
-> 不足则拒答或转人工

这就是 RAG 的基本价值。它不是让模型更会聊天,而是把回答锚定到可追溯资料。

3.4 上下文缺失:资料没给够,模型会补#

很多幻觉不是模型本身不知道,而是产品设计没有给足上下文。

例如客服系统里用户问:

我这单可以退款吗?

模型要可靠回答,至少需要:

  • 用户身份。

  • 订单状态。

  • 商品类目。

  • 是否发货、签收、使用。

  • 是否参与活动。

  • 退款政策。

  • 优惠券和积分规则。

  • 是否存在异常风控。

如果系统只把用户这句话发给模型,模型只能按通用退款话术生成,很容易出现错误承诺。

这类问题在 PRD 中必须拆清楚:

问题需要的上下文缺失时应做什么
能否退款订单状态、售后政策、风控结果查询系统,查不到则转人工
能否报销制度版本、金额、城市、审批记录要求补充信息或引用制度
数据为什么下降指标口径、维度拆解、实验记录给出假设,不给确定归因
合同风险是什么合同原文、标准条款、法务规则标注风险点,不做法律结论

上下文缺失时,好的 AI 产品不应该“硬答”。它应该追问、拒答、转人工或给出不确定提示。

3.5 采样与随机性:为什么同一个问题会答得不一样#

大模型生成时通常不是永远选择概率最高的下一个 Token,而是会根据温度、top-p 等采样参数在多个候选中选择。这样做可以让输出更自然、更有创造性,但也会带来不稳定。

不同任务对随机性的容忍度不同:

场景随机性容忍度建议
广告文案创意可以生成多版本
标题改写允许变化,但要规则校验
用户访谈摘要要忠实原文,不应自由发挥
制度问答很低必须基于引用
退款判断零容忍走规则系统,不由模型判断

产品经理要把采样策略纳入功能设计。创意任务可以鼓励多样性;事实任务要降低随机性,并把模型输出限制在资料范围内。

3.6 检索失败:有 RAG 也会幻觉#

很多团队以为接了 RAG 就不会幻觉,这是错误判断。RAG 只是降低幻觉的关键手段,不是自动保证正确。

RAG 失败常见原因:

  1. 文档质量差。 扫描件、图片、表格、旧版 PDF 混在一起。

  2. 分块不合理。 一个条款被切断,模型拿不到完整条件。

  3. 召回不准。 用户问法和文档措辞差异大,检索不到。

  4. 重排失败。 找到了相关文档,但最关键片段排在后面。

  5. 版本冲突。 新旧制度都被检索出来。

  6. 权限过滤缺失。 用户看到了不该看的资料。

  7. 引用不支持结论。 模型引用了段落,但结论是自己补出来的。

所以 RAG 产品要评估两件事:

检索是否找到了正确资料?
回答是否忠实于资料?

前者是检索质量,后者是答案忠实度。只看“回答看起来不错”是不够的。

3.7 指令冲突:Prompt 写得越多不一定越安全#

很多团队遇到幻觉后,会不断在 Prompt 里加规则:

请不要编造。
请基于资料回答。
如果不知道就说不知道。
请务必准确。
请严格遵守制度。

这些规则有价值,但不能无限堆。Prompt 过长会带来维护困难,也可能产生指令冲突。

例如同一个 Prompt 里同时写:

  • 必须回答用户问题。

  • 不确定时不得回答。

  • 要用亲切语气安抚用户。

  • 不得承诺退款。

  • 遇到投诉要积极解决。

当用户情绪激烈地要求退款时,模型可能优先执行“安抚”和“积极解决”,输出模糊承诺。

更稳的设计不是把所有安全责任压到 Prompt,而是分层控制:

规则系统:确定性判断
权限系统:决定能看什么
检索系统:提供事实资料
模型:理解和生成
后处理:校验格式、禁词、引用
人工:处理高风险和不确定场景

Prompt 是系统的一部分,不是系统本身。

3.8 幻觉风险分级:不是所有错误都同等严重#

AI 产品不能只写“降低幻觉”。必须区分风险等级。

风险等级示例后果产品策略
文案措辞不够准确人工修改即可可生成多版本,保留编辑
摘要遗漏部分观点影响判断效率显示来源,支持回看原文
制度问答编造条款员工按错规则办事强制引用,资料不足拒答
很高客服承诺退款赔付客诉、损失、合规风险不允许模型最终决策
极高医疗、法律、金融建议
重大责任风险专业审核,严格免责声明和转人工

这张表应进入 AI 功能 PRD。没有风险等级,研发无法设计兜底,测试无法验收,业务上线后也不知道什么问题必须回滚。

3.9 幻觉控制的产品设计原则#

幻觉控制不是单点功能,而是一组产品原则。

第一,回答必须有事实边界。 系统要定义哪些问题可答、哪些问题不可答、哪些问题只能给参考信息。

第二,关键结论要有来源。 知识问答、制度问答、合同摘要、客服政策解释都应显示引用或原文片段。

第三,资料不足时允许“不回答”。 不回答不是失败,错误回答才是失败。产品指标不能只追求回答率,还要看正确率、拒答率和转人工质量。

第四,高风险动作必须工具或人工确认。 退款、赔付、改价、发券、发邮件、删除数据、提交审批,不应由模型直接执行。

第五,输出要可追溯。 保留用户问题、检索片段、模型版本、Prompt 版本、输出、用户反馈和人工处理结果。

第六,评估集要持续更新。 幻觉控制不是上线前测一次,而是用真实问题不断扩充测试集。

3.10 幻觉指标怎么设计#

AI 功能不能只看满意度。对幻觉风险较高的功能,至少要监控:

  • 答案准确率。

  • 引用准确率。

  • 引用支持率:引用内容是否支撑结论。

  • 无依据回答率。

  • 错误承诺率。

  • 拒答正确率。

  • 转人工准确率。

  • 高风险问题拦截率。

  • 用户负反馈率。

  • 人工复核通过率。

其中最容易被忽略的是“引用支持率”。很多系统会给出引用,但引用只是相关,不一定支持结论。

例如引用原文说:

超标准住宿需提前审批。

模型回答:

只要直属领导口头同意即可报销。

这就是引用不支持结论。测试时必须专门抓。

3.11 PRD 里如何写幻觉控制#

一个合格的 AI 功能 PRD,不应该只写“模型基于知识库回答”。至少要写清:

  1. 可回答范围:哪些问题属于当前功能。

  2. 不可回答范围:哪些问题必须拒答或转人工。

  3. 输入依赖:需要哪些业务数据和知识资料。

  4. 资料优先级:制度、FAQ、订单系统、人工记录谁更权威。

  5. 引用要求:哪些答案必须给来源。

  6. 拒答规则:何时说不知道、何时追问。

  7. 高风险动作:哪些动作必须人工确认。

  8. 评估指标:准确率、引用支持率、幻觉率、转人工率。

  9. 日志与复盘:记录哪些信息。

  10. 灰度与回滚:什么错误触发暂停或降级。

这会让 AI 项目从“接模型试试”变成可验收、可上线、可复盘的产品工程。


4. 案例一:制度问答中编造报销规则#

业务背景#

一家国内互联网公司希望用 AI 做内部制度助手,覆盖差旅报销、采购申请、请假、合同审批等问题。员工可以在企业 IM 里直接问:

我去深圳出差,酒店超了标准 80 元,经理微信同意了,可以报销吗?

业务希望减少财务和行政重复咨询,同时提升员工查制度效率。

相关角色#

  • 员工:希望快速知道能不能报销。

  • 财务:负责制度解释和报销审核。

  • 行政:负责差旅标准维护。

  • HR 或制度管理员:负责制度版本发布。

  • 产品经理:负责问答范围、风险边界、验收指标。

  • 研发/AI 工程:负责文档接入、检索、模型调用、日志。

  • 法务/内控:关注制度合规和审计责任。

原始流程#

员工查制度文档
-> 找不到或看不懂
-> 问财务/行政
-> 财务询问城市、金额、审批情况
-> 人工判断是否符合制度
-> 员工提交报销
-> 财务审核

痛点:

  • 员工不知道该看哪份制度。

  • 制度正文、附件和城市标准表分散。

  • 新旧制度容易混淆。

  • 财务重复回答高频问题。

  • 员工会把“咨询答复”当成报销承诺。

幻觉发生方式#

如果系统只把员工问题交给模型,模型可能回答:

深圳出差住宿超标 80 元,若直属经理已审批,一般可以正常报销。建议在报销单中上传微信审批截图。

这个回答看起来合理,但可能完全错误。真实制度可能规定:

  • 超标必须在出差前走 OA 审批。

  • 微信同意不算有效审批。

  • 不同职级有不同住宿标准。

  • 深圳一类区域和二类区域标准不同。

  • 超标金额无论多少都需要部门负责人和财务负责人审批。

幻觉的根因不是模型不会写,而是系统没有拿到权威资料和审批记录。

AI 改造流程#

员工提问
-> 身份与权限校验
-> 问题结构化:城市、费用类型、超标金额、审批方式
-> 检索当前有效制度、城市标准表、审批要求
-> 检查是否存在必要字段缺失
-> 生成带引用的回答
-> 若缺少审批记录或条件不完整,则追问或转人工
-> 记录问答、引用、反馈和人工复核结果

数据与系统依赖#

  • 当前有效差旅制度。

  • 历史制度版本和生效日期。

  • 城市住宿标准表。

  • 组织架构和职级。

  • OA 审批记录。

  • 报销系统规则。

  • 财务人工答疑记录。

  • 员工权限和部门信息。

方案架构#

企业 IM
-> 问题解析
-> 场景识别:差旅报销
-> 字段抽取:城市/金额/审批/时间
-> 权限校验
-> RAG 检索
-> 制度正文
-> 附件标准表
-> 审批要求
-> 业务规则校验
-> 是否缺字段
-> 是否高风险
-> 模型生成
-> 结论
-> 引用
-> 需补充信息
-> 财务转人工
-> 日志与评估集沉淀

关键指标#

  • 自助解决率。

  • 财务人工咨询量下降。

  • 引用准确率。

  • 引用支持率。

  • 制度版本命中率。

  • 无依据回答率。

  • 高风险问题转人工率。

  • 员工满意度。

  • 报销审核驳回率变化。

主要风险#

  • 模型引用旧制度。

  • 模型把“可咨询”说成“可报销”。

  • 审批记录未查询到却给确定结论。

  • 用户无权限查看某些制度。

  • 员工截图或描述不完整。

  • 财务审核口径与知识库不同步。

复盘结论#

制度问答适合用 AI,但不能把模型回答等同于制度结论。产品设计上必须区分:

  • AI 可以解释制度。

  • AI 可以提示需要哪些材料。

  • AI 可以引用当前制度条款。

  • AI 不应替代报销审核系统做最终判断。

上线时不要只测“能不能回答”,要重点测“资料不足时能不能拒答”“引用是否支持结论”“高风险问题是否转人工”。


5. 案例二:智能客服错误承诺赔付#

业务背景#

一个电商平台在大促期间接入 AI 客服,目标是降低人工咨询量。高频问题包括物流延迟、退款、优惠券、发票、售后维修、活动价保。

用户问:

我的订单说昨天到,今天还没到,你们是不是要赔我?不赔我就投诉。

相关角色#

  • 消费者:希望获得明确解决方案。

  • AI 客服:负责初步接待和低风险问题回答。

  • 人工客服:处理投诉、赔付、异常订单。

  • 运营:负责活动规则和服务承诺。

  • 售后/物流团队:负责订单状态和异常处理。

  • 产品经理:负责客服流程、风险分级、指标。

  • 法务/合规:关注承诺、赔付和平台规则。

原始流程#

用户咨询
-> FAQ 机器人尝试命中
-> 命不中转人工
-> 人工查询订单和物流
-> 判断是否符合赔付或补偿
-> 回复用户并创建工单

大促期间人工压力大,平台希望 AI 先承担更多对话。

幻觉发生方式#

如果 AI 客服为了安抚用户,直接回答:

很抱歉给您带来不便,您的情况符合延迟配送赔付规则,我们会为您补偿 10 元优惠券。

这就是高风险幻觉。它可能违反实际规则:

  • 订单是否承诺时效不确定。

  • 物流延迟是否由平台责任导致不确定。

  • 商品类目是否支持赔付不确定。

  • 用户是否已享受其他补偿不确定。

  • 优惠券发放需要工单或人工审批。

这种错误不只是答错,会直接形成用户预期和平台责任。

AI 改造流程#

用户消息
-> 情绪与投诉风险识别
-> 订单状态查询
-> 物流状态查询
-> 服务承诺规则检索
-> 风险分级
-> 低风险:解释规则、查询进度
-> 中风险:创建工单、提示等待处理
-> 高风险:转人工,不承诺赔付
-> 回复生成
-> 日志记录与质检

数据与系统依赖#

  • 订单系统。

  • 物流轨迹。

  • 商品类目和店铺规则。

  • 平台服务承诺。

  • 赔付规则和优惠券发放规则。

  • 用户历史补偿记录。

  • 工单系统。

  • 客服质检系统。

方案架构#

用户会话
-> 意图识别
-> 催物流
-> 索赔
-> 投诉威胁
-> 风险分类
-> 工具调用
-> 查订单
-> 查物流
-> 查服务承诺
-> 查补偿记录
-> 回复策略
-> 解释规则
-> 引导工单
-> 转人工
-> 禁止项校验
-> 不承诺赔付
-> 不承诺到达时间
-> 不编造规则
-> 质检与复盘

关键指标#

  • 自助解决率。

  • 人工接管率。

  • 高风险问题识别率。

  • 错误承诺率。

  • 投诉升级率。

  • 用户满意度。

  • 单会话成本。

  • 平均响应时间。

  • 赔付工单人工复核通过率。

主要风险#

  • AI 为安抚用户而承诺赔付。

  • AI 编造物流到达时间。

  • 活动规则和赔付规则过期。

  • 订单系统查询失败但模型继续回答。

  • 用户通过诱导话术要求 AI 给承诺。

  • 高峰期为了降低人工接管率而放大自动处理范围。

复盘结论#

智能客服的目标不是“尽量不转人工”,而是把正确的问题交给正确的处理路径。对赔付、投诉、退款审批这类高风险事项,AI 可以做信息收集、规则解释和工单分流,但不应做最终承诺。

这里的产品指标要避免单一追求自助解决率。如果自助解决率上升,但错误承诺率、投诉升级率也上升,项目就是失败的。


6. 动手实操任务#

任务:设计 10 条容易诱发幻觉的问题#

请选择一个你熟悉的业务场景,例如:

  • 企业制度问答。

  • 智能客服。

  • 商品文案生成。

  • 合同摘要。

  • 运营数据分析。

  • 销售跟进助手。

设计 10 条容易诱发幻觉的问题,并标注风险。

建议覆盖以下类型:

  1. 资料缺失型:问题需要资料,但系统可能没有。

  2. 版本冲突型:新旧规则可能不同。

  3. 权限限制型:用户不应看到某些信息。

  4. 高风险承诺型:涉及退款、赔付、审批、价格。

  5. 诱导编造型:用户要求模型给不存在的依据。

  6. 数据归因型:模型可能编造原因。

  7. 边界模糊型:问题介于可答和不可答之间。

  8. 多条件判断型:需要多个字段共同决定。

  9. 引用错配型:资料相关但不支持结论。

  10. 情绪压力型:用户要求立即给确定答复。

按下面模板输出。

编号测试问题幻觉诱因正确处理方式风险等级验收标准
1我的超标住宿经理同意了,能报销吗?缺审批记录、制度条件复杂追问/检索制度/提示需财务审核不得直接承诺可报销

验收标准#

合格:

  1. 至少设计 10 条问题。

  2. 每条问题说明幻觉诱因。

  3. 每条问题写出正确处理方式。

  4. 至少覆盖 3 个不同风险等级。

优秀:

  1. 能把测试问题转成上线前评估集。

  2. 能定义“通过/失败”的验收标准。

  3. 能指出哪些问题必须转人工,哪些可以拒答,哪些可以基于引用回答。


7. 测试题与参考答案#

理解题#

1. 为什么大模型会产生幻觉? 参考答案:因为大模型主要按上下文预测最可能的后续文本,不天然验证事实。训练数据可能过时或错误,上下文可能缺失,采样会带来随机性,检索也可能失败,因此模型可能生成看似合理但不准确的内容。

2. 幻觉为什么比普通系统错误更难处理? 参考答案:因为幻觉通常表达流畅、语气自信,用户难以识别;同问可能不同答;如果没有引用和日志,很难追溯错误来源;在业务场景中还可能形成承诺和责任风险。

3. 为什么 RAG 不能彻底消除幻觉? 参考答案:RAG 依赖文档质量、分块、召回、重排、权限和版本管理。即使检索到相关资料,模型也可能引用不支持结论的内容。因此仍需评估检索准确率和答案忠实度。

4. 为什么不能用 Prompt 完全解决幻觉? 参考答案:Prompt 可以约束模型行为,但不能提供真实事实,也不能替代规则系统、权限系统、检索系统和人工审核。Prompt 过长还可能产生冲突和维护问题。

5. 幻觉控制中为什么“拒答”是必要能力? 参考答案:资料不足、高风险、无权限或超出范围时,拒答比错误回答更安全。AI 产品不能只追求回答率,还要衡量拒答正确率和转人工准确率。

应用题#

6. 一个企业制度问答助手如何降低幻觉? 参考答案:应接入当前有效制度,做权限校验、文档分块、检索与重排;回答必须带引用;资料不足时追问或拒答;高风险报销和审批问题转人工;记录日志并建立幻觉评估集。

7. 智能客服遇到用户要求赔付时应该如何设计? 参考答案:先识别高风险意图,查询订单、物流、服务承诺和补偿记录;AI 可以解释规则和创建工单,但不得直接承诺赔付。赔付、退款、投诉升级应转人工或由规则系统判断。


8. 当日产出模板#

8.1 幻觉测试题库 v1#

编号场景用户问题所需事实来源幻觉诱因期望处理失败表现风险等级
1制度问答制度文档/审批记录引用回答/追问/拒答/转人工编造条款/无依据承诺

8.2 AI 回答风险分级与兜底表#

风险等级问题类型允许模型直接回答吗必要机制触发兜底
文案风格建议可以可编辑、多版本用户不满意
摘要与信息抽取有条件可以原文引用、可回看低置信或用户质疑
制度政策解释仅可基于引用RAG、引用、拒答无资料或版本冲突
很高退款、赔付、审批不可以规则系统、人工确认涉及金额或承诺
极高医疗、法律、金融建议不可以专业人员审核任何具体决策建议

8.3 PRD 幻觉控制清单#

功能名称:
可回答范围:
不可回答范围:
必须引用的问题类型:
必须拒答的问题类型:
必须转人工的问题类型:
需要调用的业务系统:
资料版本优先级:
高风险动作列表:
评估指标:
灰度策略:
回滚条件:
日志字段:

9. 延伸阅读资料#

  1. Transformer 直觉。重点回看“概率生成”和“上下文关系”。

  2. Embedding 与语义检索。理解 RAG 为什么能降低幻觉,以及为什么检索质量会影响答案质量。

  3. NIST AI Risk Management Framework:用于建立 AI 风险识别、测量和治理思路。

  4. 业务内部资料:制度文档、客服质检记录、报销驳回案例、赔付投诉案例。这些比通用文章更适合做幻觉测试集。

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

大模型为什么会幻觉
https://www.shanfengpm.com/posts/2025-12-27-llm-hallucinations/
作者
山风
发布于
2025-12-27
许可协议
CC BY-NC-SA 4.0
本文首发于「山风blog」,作者:山风(余涛)。欢迎转发、分享本文链接, 但禁止任何形式的未授权转载、摘编、改写或商业使用
推荐文章大模型
Profile Image of the Author
山风
12年产品经验,持续记录产品思考、业务设计、数据分析和团队管理实践。
站点统计