惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hacker News: Ask HN
Hacker News: Ask HN
WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
The GitHub Blog
The GitHub Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 聂微东
A
About on SuperTechFans
Stack Overflow Blog
Stack Overflow Blog
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
腾讯CDC
爱范儿
爱范儿
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 【当耐特】
V
Visual Studio Blog
有赞技术团队
有赞技术团队
U
Unit 42
D
Docker
小众软件
小众软件
F
Full Disclosure
I
Intezer
Scott Helme
Scott Helme
P
Privacy International News Feed
P
Proofpoint News Feed
Engineering at Meta
Engineering at Meta
Google DeepMind News
Google DeepMind News
B
Blog
Martin Fowler
Martin Fowler
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Vercel News
Vercel News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Spread Privacy
Spread Privacy
宝玉的分享
宝玉的分享
S
Security Affairs
www.infosecurity-magazine.com
www.infosecurity-magazine.com
月光博客
月光博客
C
Cisco Blogs
云风的 BLOG
云风的 BLOG
Schneier on Security
Schneier on Security
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Threat Research - Cisco Blogs
量子位
Hacker News - Newest:
Hacker News - Newest: "LLM"
H
Heimdal Security Blog
N
Netflix TechBlog - Medium
H
Hacker News: Front Page
P
Proofpoint News Feed
G
GRAHAM CLULEY
V
Vulnerabilities – Threatpost
S
Schneier on Security

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
做了一年客服型外呼 Agent,我发现旧的效果评估体系正在失效 – 人人都是产品经理
洋洋 · 2026-05-22 · via 人人都是产品经理

当外呼机器人从机械的'念话术'进化为具备大模型能力的Agent,传统的评估体系正在面临崩溃。本文通过真实案例揭示了AI客服为何会在看似完美的流程中突然失控,深度剖析了三类失效的关键指标,并提出全新的三层评估框架,帮助产品经理重建适合AI时代的质检标准。

先说一个让我当场卡住的评测案例。

那是去年我们接的一个客服型外呼项目,做完一轮迭代后我自己抽查通话记录,翻到一通电话——接通了,对话轮次很高,用户问得很细,机器人也一直在答,从头到尾”流程”看起来是走完的。按我们当时那套评估口径,这通电话所有指标都是绿的。

但我把录音听完,后背发凉。

这通电话拖了很久,用户一个问题接一个问题地追问,对话上下文越堆越长。到后半段,AI 开始有点”飘”了:先是答非所问,后来干脆开始胡言乱语,最后竟然把我们配置在系统里的内部 SOP 流程,一条一条地念给了用户听——那本来是给机器人自己看的作业指导,不是给用户的话术。

我盯着那条记录看了很久。问题不在于”这通电话出了事故”,事故谁都会有。真正让我卡住的是另一件事:我们那套评估体系,根本没有任何一个指标会因为这通电话而报警。 接通率正常、对话轮次甚至偏高(在旧口径里这是好事)、流程完成率正常、没有转人工。从数据看,这是一通”健康”的电话。

那一刻我意识到,我们一直在用一套为”上一代外呼”设计的尺子,去量一个已经变了形的东西。

这篇文章想聊的就是这件事:当外呼机器人从”念话术”进化成”大模型 Agent”,为什么旧的效果评估体系会失效,哪些指标已经测不准了,又该补进来什么。我做的是客服解答型外呼,下面的讨论也主要基于这个场景。

一、旧评估体系的底层假设,已经不成立了

要讲清楚”为什么失效”,得先讲清楚旧体系是为什么设计的。

传统的话术流外呼,本质是一个确定性系统。它的核心是一张流程图——AI 训练师把业务场景拆成一个个节点,每个节点预设好话术,节点之间靠意图判断来分流。用户说了什么,机器人就跳到对应节点,念对应的那段话。它能说出来的每一句话,都是事先写死在话术库里的。

正因为系统是确定性的,旧的评估体系才能那样设计。你回头看传统外呼那套核心指标——接通率、节点命中率、流程完成率、转人工率——会发现它们有一个共同点:全是”流程合规类”指标。它们测的不是机器人”说得好不好”,而是机器人”有没有按图走”。

这套体系能成立,是因为它背后压着一个谁都没明说、但所有人都默认的假设:

机器人不会说出话术库里没有的话。

只要这个假设成立,评估就可以很省心。机器人最坏的情况无非是”走错节点”或者”流程没走完”,这些用流程类指标都能抓到。它不可能”乱说”,因为它根本没有”乱说”的能力——它的嘴是被话术库焊死的。

大模型外呼,把这个假设直接打破了。

大模型外呼是一个概率性系统。它不再从话术库里取一句固定的话,而是基于上下文实时生成一句话。这带来的好处很明显:对话自然了,能处理预设之外的问题了,不用再为每一种说法穷举相似问了。但代价是——它能说出的话,不再有边界。它可能说得很好,也可能说出话术库里从来没有、你也从来没想到它会说的东西。我开头那个 SOP 泄露的案例,就是这个代价的具象化。

一旦”机器人不会乱说”这个地基塌了,建在它上面的整套流程合规类评估体系,就跟着晃了。这不是某个指标不准的问题,是整套尺子的刻度对不上了。

二、三类旧指标,是怎么失效的

具体说,旧体系里有三类指标,在大模型外呼下出了问题。它们不是”略有偏差”,而是有的失去了计算对象,有的甚至正负号反了。

1. 意图识别准确率:失去了计算对象

传统外呼里,”意图识别准确率”是个硬指标。它的算法很清晰:用户这句话,机器人有没有正确判断该跳到哪个节点。命中率是多少,一目了然。这个指标之所以能算,是因为有”节点”这个明确的、离散的对象作为标尺——意图就是节点的入口,识别对不对,看跳没跳对节点就行。

但大模型外呼里,”节点”这个东西在很多实现里已经被弱化甚至取消了。对话不再是节点间的跳转,而是模型基于整段上下文的连续生成。这时候你再问”意图识别准确率是多少”,会发现这个指标失去了它原本的计算对象——没有节点了,你拿什么去比对”跳对没跳对”?

这个指标不是变得不重要了,是它的旧定义失效了。”机器人有没有理解用户”这件事还需要评估,但它得被重新定义。比如,从”节点命中”改成”应答相关性”——不再看它跳到哪,而是看它生成的这句回答,和用户真实诉求之间的语义匹配程度。评估的对象,要从”流程动作”换成”应答内容本身”。

2. 流程完成率:从成功标志变成了欺骗性指标

传统外呼里,”流程走完了”基本等于”这通电话成功了”。流程完成率因此是个很受重视的结果指标。

但在大模型外呼里,这个指标开始骗人。

因为”流程走完”和”过程没出问题”,已经被解耦了。机器人完全可能走完了整个流程,但中间胡说了一大通。我开头那个案例就是活的反例——那通电话的流程是”完整”的,可中间它把 SOP 念出去了。流程完成率告诉你这通电话成功了,事实是它是一次严重事故。

旧时代流程完成率可信,是因为确定性系统里”走完流程”必然意味着”每一步都念了正确的话”。大模型把这个绑定关系拆开了:走完流程,不再保证过程合规。于是流程完成率从一个结果指标,悄悄变成了一个具有欺骗性的指标——它依然是绿的,但绿色背后的含义已经变了。继续盯着它,你会对大量出过问题的电话视而不见。

3. 对话轮次与通话时长:正负号反了

这是我觉得最值得讲的一个。

传统外呼里,对话轮次和通话时长,通常被当作正向信号。用户愿意跟机器人多聊几轮、聊得久一点,一般说明用户是投入的、有意向的、问题在被认真处理。轮次太低反而要警惕——可能是用户没耐心,几句话就挂了。所以旧口径里,轮次和时长偏高,往往算好事。

大模型外呼里,这个信号的方向,在客服场景下很可能是反的。

回到我开头那个案例:那通电话出事,恰恰是因为它轮次太高、时长太长。用户一个问题接一个问题地追问,对话上下文不断累积,越堆越长。而上下文越长,大模型”飘”的概率就越高——它要在越来越长的历史里保持一致性,注意力被稀释,幻觉的风险随之上升。那通电话不是”聊得越多越投入”,而是”聊得越多越危险”。

也就是说,同一个指标——对话轮次——在传统外呼里偏高是健康信号,在大模型外呼里偏高却可能是幻觉的高危预警。它的正负号反了。 如果你把旧口径直接搬过来,会把最该被预警的那批电话,当成表现最好的那批。

这三个指标的遭遇其实是同一个故事的三个侧面:旧指标都是为”机器人不会乱说”那个假设服务的,假设没了,有的指标失去了标尺,有的失去了可信度,有的甚至意义反转。光是修修补补不够,得往体系里补新的东西。

三、需要补进来的三个新维度

如果说上一节是”拆”,这一节就是”补”。大模型外呼带来了旧体系完全没覆盖的几类问题,对应地需要三个新维度。

1. 知识库召回质量:不只看”召回了没有”

客服型外呼基本都是 RAG 架构——机器人要回答用户问题,得先从知识库里把相关内容检索出来,再交给大模型组织成话。所以知识库召回质量,是第一个必须进体系的新维度。

但这里要拆细。我见过不少团队只看一个”召回率”,这不够,至少要拆成两层:

一是召回成功率——用户问的这个问题,知识库里到底有没有把对应的条目检索出来。二是召回相关性——检索出来的条目,是不是真的和用户问题对口,有没有召回一堆看着沾边、实则答非所问的内容。

为什么必须拆开?因为真正危险的情况,藏在两者的夹缝里:召回失败了,但模型没有承认”我不知道”,而是硬着头皮答了。 确定性系统里召回失败,机器人顶多沉默或者转人工;概率性系统里召回失败,模型会用它的语言能力把空白”填”上——这就是幻觉最高发的场景之一。所以评估召回质量,光看”召回了多少”没用,得盯住”召回失败时模型有没有兜住”。

2. 拟人化与情绪承接:把感性的词拆成能考核的项

我们做过滴滴的司机端外呼项目,这件事在那个项目里体会特别深。

司机端的客服外呼,跟普通的零售客服很不一样。司机是靠这个养家的,压力大、情绪很实。一个司机可能因为一直接不到单而烦躁,也可能因为接到一个要跑很远空程的单子而窝火。他打进来或者接起来的时候,往往是带着情绪的。这种时候,我们的 AI 第一件该做的事不是”解决问题”,而是先接住他的情绪——你得让他感觉到对面这个声音听懂了他的难处,而不是一个冷冰冰的应答机。情绪安抚之后,才是第二件事:很多司机其实是对功能设置不熟,需要 AI 一步步引导他,比如怎么看热力图去订单密集的区域、怎么提升出行分、怎么打开顺风车的顺路接单。

这里的关键是:如果 AI 上来不管司机什么情绪,张口就背”设置出行分请您打开第几个菜单”,这通电话的流程完成率可能很好看——引导步骤一步没落。但司机的体验是崩的,他要的安抚一点没给到。这又一次印证了前面那个判断:流程完成率会骗人。

“拟人化”本身是个很感性的词,没法直接拿去考核。要进评估体系,就得把它拆成可观察的子项。比如语音自然度——停顿、语气、节奏像不像真人,有没有明显的机械感。比如情绪承接率——在那些用户明显带情绪的对话里,机器人有没有先做安抚回应,而不是无视情绪直接推进流程。客服型外呼里,这个维度不是”锦上添花”,它直接影响用户挂不挂断电话,必须进体系。

3. 风险与边界:旧体系完全空白的一块

最后这个维度,是旧体系里完全没有、但大模型外呼必须补上的——风险与边界。

我开头那个 SOP 泄露的案例,最终就归到这里。这类问题在确定性系统里根本不存在,所以旧体系压根没有对应指标;但在概率性系统里它是真实且高频的风险。需要被纳入评估的至少有这么几项:幻觉率——机器人生成了与事实或知识库不符内容的比例;越界应答率——机器人回答了它本不该回答、超出业务范围的问题的比例;以及内部信息泄露——像 SOP、内部流程、配置话术这种本该机器人自己看的内容,有没有被说给用户。

这个维度和前面所有指标都不一样:前面那些指标是”打分”性质的,越高越好或越低越好;风险维度是”红线”性质的,一票否决。一通电话哪怕转化做得再漂亮、流程再完整,只要踩了信息泄露这条线,它就该被判定为事故,而不是用别的好指标去把它平均掉。

四、我主张的评估框架:过程、质量、风险三层

拆完也补完了,最后把它收成一个能用的框架。

我自己在用的,是把外呼 Agent 的评估指标分成三层。这三层不是并列罗列,而是有递进关系的:

第一层,过程层——对话维持得好不好。 包括对话轮次、通话时长、打断后的恢复成功率这类指标。它回答的是”这通对话作为一段交互,是否顺畅”。注意,这一层的指标(尤其是轮次和时长)要按前面说的,重新校准方向——在客服型外呼里,它们偏高更可能是预警而非好事。

第二层,质量层——答得对不对、像不像人。 包括知识库召回质量(召回成功率 + 召回相关性)、应答相关性、拟人化与情绪承接。它回答的是”机器人这通电话,专业能力和服务体验合不合格”。这一层是客服型外呼的核心战场。

第三层,风险层——有没有闯祸。 包括幻觉率、越界应答率、内部信息泄露。它回答的是”这通电话有没有突破底线”。这一层是一票否决的,任何一项触线,整通电话直接判定为不合格,不参与其他指标的平均。

为什么是这个顺序?因为它对应了大模型外呼里风险的优先级:一通电话首先不能闯祸(风险层兜底),其次要答得专业、有温度(质量层是主体),最后才是聊得顺不顺(过程层是基础体感)。旧体系的问题,恰恰是只有”过程层”和半个”质量层”,而完全缺失了”风险层”——它默认机器人不会闯祸,所以根本没设这道闸。

写到这里,其实可以把这一年的体会浓缩成一句话:

做传统外呼的评估,我们关心的是”机器人做到了什么”;做大模型外呼的评估,我们更要关心的是”机器人有没有失控”。

评估体系的重心,得跟着这个转变挪过去。这不是推翻重来——接通率、转化率这些结果指标依然有用——而是要清醒地知道,哪些旧指标已经测不准了,哪些新风险还裸奔着没人管。尺子变了形,得自己重新刻一把。

这是我目前的思考,肯定还不完整。如果你也在做大模型外呼,欢迎交流,尤其想听听不同业务场景下,大家是怎么给”风险层”定红线的。

本文由 @洋洋 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议