在众多APP盲目跟风嵌入通用ChatBot时，潮新闻APP却选择了一条反常识的路径——构建垂类子助手矩阵。本文深度剖析了通用AI助手在垂类场景中的三大陷阱，并分享了如何通过场景化设计、专业能力差异化等策略，让AI真正解决用户需求而非沦为摆设。如果你是正在传统行业推动AI落地的产品人，这些实战经验将帮你避开90%的坑。

最近一年我看下来，几乎每个 APP 都在塞 AI 助手。打开看一眼，长得都一样：一个对话框，”你好，请问需要什么帮助？”，下面三个推荐问题。然后用户就把它关了。

我做的事情有点反过来。在潮新闻APP里，我没做那种大而全的 ChatBot，而是搭了一个通用助手加五个垂类子助手的矩阵。跑了一段时间，得到一个挺反常识的结论——通用 ChatBot 在垂类 APP里基本是个伪需求，垂类子助手才是用户真会用的东西。

这篇我把决策过程拆给你看。如果你也在传统行业、垂类APP里负责 AI 落地，应该能省不少弯路。

垂类APP抄“ChatGPT”的三个典型坑

先泼盆冷水。我见过的 AI 助手项目，十个有八个掉进同一个坑：把 ChatGPT 缩小一份塞进自己 APP。

这种思路背后的逻辑听起来都没毛病。”ChatGPT 能干的事，我们让用户在 APP 里也能干”——可问题是，用户打开你的 APP，本来就不是为了通用问答。他来潮新闻是为了看新闻、看本地资讯、办点跟政务相关的事。他真要问”光合作用是什么”，他直接打开豆包、DeepSeek 不就完了，谁会绕一圈到一个新闻APP里来问？

你的APP入口承载的是用户的具体场景，不是一个万能问答的容器。一旦把通用 ChatBot 当主入口，等于你在用自己短的腿，去追别人最长的腿。

第二个常见的坑，是觉得入口越统一越好。很多 PM 的本能反应是先收口，一个入口一个对话框，看起来很优雅。但用户的场景天然就是碎的。

举个例子。一个潮新闻用户，可能上午要查份公文，中午想给家里老人挂个号问诊，下午刷到张好照片想配段文字发朋友圈，晚上看到楼下出事了想报料。这四件事，你让他在同一个对话框里完成？他第一反应是不知道怎么开口。统一入口看着干净，但用户根本搞不清这玩意儿到底能干啥，干脆就不用了。

还有一个最坑的，叫”先做通用，再慢慢做垂类”。这个最迷惑人，因为听起来特别像渐进式 MVP。

实际跑下来你会发现，用户根本不会自己从通用 ChatBot 跳到你后做的垂类助手。为啥？因为他第一次用通用 ChatBot 就被劝退了——回答太泛、不够准、答不到他想要的。这个负面印象一旦留下，你后面做的再准的垂类助手，他也不会再点开第二次。通用 ChatBot 不是垂类助手的踏脚石，它是垂类助手的拦路虎。

我们也有一些自己的观察数据。通用 ChatBot 在豆包、Kimi 这种大模型 APP 里，用户的会话轮次是挺高的；但同样的入口塞到垂类 APP 里，会话轮次会大幅下滑，基本上聊一两轮就走。这个落差不是产品体验差异，是用户预期差异。在大模型 APP 里用户来就是为了问 AI；在垂类 APP 里用户压根不是冲这个来的。

所以结论挺简单：通用 ChatBot 在大模型 APP 里成立，在垂类 APP 里就是个用户教育成本巨大的负担。

动手做矩阵之前，先问自己三个问题

但话说回来，矩阵化也不是免费午餐，不是所有产品都该这么搞。动手之前，我一般会先问自己三件事。

第一件，你的 APP 是单一场景还是多元场景？判断标准很糙——你能不能在一分钟内列出用户进 APP 的五种以上具体目的。能就是多元，不能就是单一。纯工具、纯电商这种单一场景，做一个垂类助手就够了，别折腾矩阵；媒体、政务、生活服务这种多元的，才适合切。潮新闻就是典型多元，看新闻、查公文、问政、报料、健康咨询，每个场景的用户画像都不一样。

第二件，你的用户是带着具体任务来，还是随便逛逛来？带任务的好办，子助手直接对应任务，他点哪个图标就告诉了你他要干啥；只是闲逛刷信息流的，用通用助手做点摘要、追问就行，别强行切矩阵，没必要。

第三件，也是最容易被忽略的——你的 AI 能力能不能形成专业差异？说人话就是：你的子助手做出来，跟通用 ChatGPT 答得差不多吗？如果差不多，那就别做了，用户为啥要在你这用？子助手能立得住，必须至少占一条：要么你有别人没有的数据，比如政务文件、医院数据、本地内容；要么你做的不是问答，是带步骤的任务，比如报料、挂号、办事；要么你有特殊的合规要求，必须用专门的提示词控住口径。三条都不沾的，砍掉。

潮新闻的矩阵架构与踩过的坑

下面说说我们最后落的架构。一个通用助手，加上五个垂类子助手——公文智搜、AI 报料、AI 摄友、AI 问诊、政策智答。

通用助手只干一件事：兜底加分流。用户拿不准用哪个子助手时，进通用入口，由它判断意图后跳转过去。它本身不承担”啥都能答”的职责。这点很重要，不然又变回大而全了。

公文智搜，服务的是基层公务员和政务工作者，他们要找红头文件、政策原文、会议纪要。这事为什么必须独立做？因为数据源是封闭的，通用 ChatBot 根本搜不到这些东西。而且这群用户对准确性的要求高得吓人，错一个字都可能出事故。检索逻辑也跟普通问答完全不一样，得按发文机关、年份、文号这些维度去召回。

AI 报料，是给那些拍到突发新闻、楼下事故的用户用的。这事不是问答，是个带步骤的活儿——得引导用户描述清楚事件的时间地点人物经过，提示他补充图片视频，自动生成结构化稿件给编辑部，最后还要反馈”已收到”或”已采用”的状态。通用 ChatBot 你跟它聊半天，它也不知道下一步该让你干啥。专门的子助手用对话流加表单的混合形态，体验完全不一样。

AI 摄友这个，特意想说两句。一开始有人提议做 AI 修图，被我拒了。修图工具市面上一大把，再做一个有什么意思？媒体 APP 的差异化在哪？在内容生产能力。所以我们做的事是：用户上传照片，系统识别画面元素和场景，结合本地新闻语料库，生成一段有”新闻味”的文字——不是抖音文案、不是小红书文案，是带媒体腔调的。别的 AI 没有我们的本地内容库，调不出我们的语言风格，这就是壁垒。

AI 问诊是最让我紧张的一个。健康类问答的红线特别多——不能直接给诊断结论、不能推荐具体药品和剂量、必须引导线下就医、涉及紧急症状必须立刻提示打 120。这些约束要是放在通用 ChatBot 里，根本压不住。我们的做法是把所有约束写死在系统提示词里，再加一层敏感词后处理，宁可保守，不能越界。

政策智答，是面向普通市民的，比如”我家孩子上学怎么办””社保怎么交””营业执照在哪办”。为啥独立维护知识库？因为政策这玩意儿，特别讲地域和时效。北京的政策和杭州的不一样，去年的和今年的不一样。要是用通用模型，它会把全国各地各年份的政策搅在一起回答，错得离谱。我们必须按地市区县切片维护，政策一更新就强制走审核入库，答案还得标注信息来源、更新时间、适用地区。这是个长期内容运营的活儿，不是上线就完事了。

矩阵听起来很美，做起来一堆糟心事。我把踩过的几个坑也写出来，免得你再踩。

第一个坑，心智割裂。用户进 APP 看到六个 AI 入口，第一反应是”这都是啥？我该点哪个？”为了这事我们折腾了挺久，最后做了几件事：通用入口做路由分流，用户随便提问，系统识别意图后主动推荐”看起来你想找文件，要不要去公文智搜？”；子助手图标加一句话功能描述，别用花里胡哨的名字——”AI 摄友”听着就比”潮拍 AI”清楚得多；还有就是场景化触发，用户在新闻详情页看到本地突发事件，直接弹一个”想报料给我们吗？”，跳进 AI 报料，不要让用户自己去找入口。

第二个坑，能力重叠。用户问”杭州落户政策”，公文智搜能答，政策智答也能答，通用助手还能答，回答可能还不一致。我们的做法是给每个子助手定个边界协议，明确谁是”主答”、谁是”兜底”、谁是”拒答”。比如政策智答主答政策解读，公文智搜主答原文检索，两个交叉的领域由通用助手做仲裁。然后定期跑评测集，挑那些会触发多个子助手的问题，看答案一致性，不一致就调提示词或者调路由。

第三个坑，最让人头疼——业务方今天提”做 AI 体育”，明天提”做 AI 财经”，每加一个就要重写一套提示词、调一套 RAG、跑一套评测，受不了。我们后来做了个标准化接入模板，每个新子助手必须填齐几项才能上：角色定义、数据源、强约束、输出格式、评测集（至少 50 条问答对作为基线）、运营 SOP（谁负责更新、多久更新一次）。底层能力比如大模型调用、RAG、敏感词、日志，都做成共享层，所有子助手共用。这样新加一个子助手的边际成本就可控了，不会指数膨胀。

最后说点扎心的。矩阵化对团队是有门槛的。

至少得有两个 PM。一个看通用入口，管路由、管心智、管整体体验；一个看垂类，管单个子助手的深度。一个 PM 同时管这两件事，会精分。每个子助手都得有自己的评测集和打分流程，没评测就是瞎做。政策智答、公文智搜这种靠知识库吃饭的，不更新就废了，必须有人专门喂数据。

如果你团队只有一个 PM，那就老老实实做一个垂类助手，做精比做多重要。如果你的 AI 答得跟 ChatGPT 一样，没有专属数据和流程，那做矩阵就是徒增维护成本，没意义。最后，如果你的业务方主营业务都还没跑通，AI 是锦上添花，不是雪中送炭，别指望靠 AI 救命。

写到这儿其实就一句话——AI 助手是产品架构问题，不是接口调用问题。接 API 谁都会，难的是想清楚用户在你这个APP里到底要 AI 干什么。想清楚之后，该切就切，该砍就砍，别贪图大而全。