拆解小红书「点点」：产品经理看到护城河，开发者看到一堆脏数据

去年底点点独立上线时，很多分析叫它"小红书版 AI 搜索"。这个说法放到现在就不准了。

2026 年 9 月，“问一问"和"点点"合并，对外统一叫"点点”，主打"搜索即对话"。也就是说它现在不是一个需要你去下载的 App，而是搜索框本身。形态变了，判断也得跟着变——搜索要的是入口效率，助手要的是能力陪伴，这两套产品逻辑差得很远。

这篇我拆两遍。一遍按产品经理的路子问，一遍按开发的路子问，最后把两个答案对起来看。之所以要这么干，是因为写的时候我发现，同一个设计决策，两个视角给出的理由经常不一样，而真正的原因往往藏在两个理由的缝里。

先把基线摆正。

• 2024 年 8 月 iOS 独立版上线，12 月正式发布，初期基于自研"珠玑大模型"。
• 2025 年 2 月接入 DeepSeek 深度思考，7 月推 2.0 加了语音和图像，11 月嵌进主站（侧边栏、划词、分享）。
• 2026 年 4 月，Hi Lab 升级成 AI 一级部门 Dots，下设模型研发、基础设施、工程、产品四块。
• 2026 年 5 月上线 PC 端，9 月与"问一问"合并。
• 自研线没停，是转向了：2025.06 开源 dots.llm1（1420 亿总参、140 亿激活），2026.04 开源 REDSearcher 等，2026.08 开源 280B 的 dots3-note preview。

一句话：今天的点点是 AI 搜索，不是 AI 助手。下面所有分析都建在这个前提上。

▲ 同一块晶体，一条橙带一条绿带。产品和工程看的是同一件事，从不同的面切进去，颜色就不一样了。两个都不算错，只是谁也没看全。

一、产品视角：谁在用，他们到底要什么

谁在用

官方口径是"面向生活场景的普通用户"。这话在 PR 稿里没毛病，做决策时没法用——"普通用户"不指导任何设计。

实际用的人至少三种，而且前两种的诉求是打架的。

核心层是出行探店前做功课的人，25 到 35 岁女性占比高，要一份能直接照抄的方案，愿意为它等五分钟。延伸层是刷笔记时顺手问一句的人，出现在划词、侧边栏、评论区 @ 这些地方，要求一秒内有反应，慢两秒就走了。

一个产品同时伺候这两种节奏，只能做两套路径——攻略模式和划词速答就是这两套。代价是两套都做不到极致。这不是能力问题，是定位自带的。

第三种人最容易被忽略：创作者和商家。小红书广告收入占总营收大概 76%，最需要 AI 提效的其实是商家侧，但点点到现在没有品牌知识库、没有商品库接入、没有客服工作流。这块是空的。后面讲价值主张时还会绕回来。

▲ 延伸层用户就是这么进来的：在主站看到笔记，转给点点，它给四个动作——帮我种草推荐、整理总结、行程规划。全程不用打开另一个 App。所谓"嵌在内容流里"，说的就是这个。

他们到底要什么

把点点当搜索看，需求是"找到信息"。但真去拆用户做决策时的心理过程，信息只是第一层。

「我想去西安玩」
→ 知道有哪些景点 （信息）
→ 但不知道哪个值得去 （判断）
→ 更怕去了被坑 （风险）
→ 最后要定下行程 （执行）
→ 全程想要一点"有人跟我一样"的踏实感（情绪）

这五层里，传统搜索只解决第一层。剩下四层本质上是一回事：需要有别人的经验做背书。

用户问"回民街值不值得去"，他不缺景点介绍，百度一搜一大把。他缺的是"去过的人后不后悔"。这类东西只存在于真实表达里，而且最真实的往往不在正文——正文是作者整理过的叙事，评论区是读者没加工的反馈。

所以评论区在这个产品里不是"互动数据"，是需求源。产品经理要是只把它当元数据看，这个产品根本设计不出来。

顺带说一句，绝大多数 RAG 产品把评论丢掉，工程上是有道理的，我在第七节会讲那堆数据有多难处理。但顺序得摆对：产品判断在前，工程代价在后。反过来的话，这个产品第一次技术评审就会被毙掉。

三个设计，各自在赌什么

功能不按入口分，按能力分大概是五条线：多模态提问、UGC 检索与溯源、多轮追问、个性化上下文、攻略模式。前四条已经全量，攻略模式只在 App 上有，还带额度。

重点说三个设计。不是列优点，是说它们在赌什么。

把"提问"改成"选择"。

答案里的关键词能点，点了不弹输入框，直接甩三个候选问题出来。

这么做是因为生活决策里用户经常不知道自己该问什么。他知道要去西安，但不知道要问"回民街几点人少"“地铁能不能直达兵马俑”。让 AI 把"你接下来可能想知道的"摆出来，比让他自己组织 query 更贴近决策的真实节奏。

三个不是五个。三个刚好盖住"是什么／多少钱／适不适合我"这一圈，五个就开始犹豫了。这个数字应该是调过的。

▲ 首屏根本没有输入框，先给四个气泡：附近 citywalk 路线、近期艺术展览推荐、超人气零食盘点、小红书热门携宠旅行地。把"问什么"变成"选什么"，和答案里那三个候选追问是同一套思路，只是在更前面的位置又用了一次。

先反问，再回答。

攻略模式生成前会问细节：孩子多大、几天、骑车还是走路。

效率上是倒退，白多一轮交互。但信息不足时的硬答，恰恰是"不靠谱"的主要来源。愿意多问一句的产品，用户会觉得更可信。它把"靠谱"这个说不清的感觉，拆成了具体动作。

攻略模式为什么只在 App 上还限额。

官方没解释。我的判断不是战略克制，是钱。

攻略模式是多阶段、多源、长时间的任务，一次跑几分钟，单次成本大概是普通问答的几十倍——多轮检索、长上下文、深度推理，还得调地图 API。额度限制是成本闸门。

真实含义是"这个能力很好，但我们还没找到让它跑得起的办法"，不是"我们故意只放一点出来"。这两个判断差得挺远：如果是后者，下一步该扩大开放；如果是前者，下一步该优化成本。搞错了就会做错决策。

品味在"怎么不做"

一个产品做什么，多半是被资源和技术推着走的；不做什么才是主动选的。

点点不做开放域问答，不做长文本处理，不做通用 Agent，文本输入上限也有限。这些看着像能力不足，其实是拿通用换垂直。只有放弃"什么都能答"，才可能在吃喝玩乐行上比通用助手深一层。

什么时候做也很讲究。PC 端拖到 2026 年 5 月才补，攻略模式到现在没进主站。能力成熟度优先于功能齐整。

最值得看的是怎么不做：对还不稳定的能力，点点选的是限制入口加额度，不是全量上线边跑边优化。前一种用产品结构控风险，后一种用口碑付学费。大部分团队会选后者，因为前者看起来不够进取。

价值主张，和它自带的裂缝

压成一句话，不是"AI 搜索助手"，是"让你在生活决策上少踩一次坑"。

这句话里三个词都有用。生活决策划了场景边界；少踩坑承诺的是避错不是最优，最优定义不了，避错可以；一次暗示低频高价值，不追日活，追关键时刻的不可替代。

价值能分三层，一层比一层难守。省时间最容易被感知，也最容易被替代，竞品爬点内容也能做。可溯源是转化的关键，每条结论能点回原帖、看得到真人互动数据。敢下手最难替代，它把用户从"看了很多"推到"定了"。

用户是被第一层吸引来的，被第三层留下的。中间这段转化是这个产品的生死线。

再往上看还有一道更大的裂缝。小红书给"问一问"定过一句 slogan：“有事就问小红书，活人答案靠得住”。这句话里没有"智能"，只有"活人"。

问题是 AI 干的事就是"替你总结活人的话"，而平台的核心资产是"活人亲自说的话"。前者越成功，后者被读到的越少。答案越完整，点原生笔记越少，广告曝光越少，而广告占小红书营收约 76%。

百度已经把这个结局演示过一遍：AI 生成结果占比超 20%，2025 年三季度在线营销收入同比下滑 18%。

有个细节能看出内部其实是清醒的——商业化团队曾经要求 AI 搜索不要主动生成购物推荐列表。虽然最后功能留下了，但商业部门会去干预产品设计，说明这个矛盾是真的，而且高层认了。

在我看来这不是能"平衡"的矛盾，只能换路径。卖曝光这条路上，AI 和广告就是零和。唯一的解法是把变现从卖曝光挪到卖能力：把理解评论区这套能力反向卖给商家，做口碑监测、竞品分析、话术生成。这条路点点还没走，但它的数据禀赋是所有玩家里头最好的。

二、技术视角：怎么搭，难在哪

架构

▲ 四层都长在评论区上面。最下面那层的质量，决定了上面三层能发挥多少。

这套"一脑一目一手"的分层没什么新鲜的，任何 RAG 系统都长这样。有信息量的是每一层的取舍。

一脑用的是 SFT 垂类模型，不是通用大模型。生活场景的意图空间窄，垂类模型参数更小就能贴合得更好，推理也便宜。代价是复杂推理不够，后来接 DeepSeek 就是在补这个洞。

一目把评论区拉进了检索。这是真差异。

一手做 Just-in-Time：不预加载全部上下文，用户点的那一刻才去拉需要的证据。

架构上想强调一句：这个系统的复杂度重心不在模型，在数据。

卡点一：把评论区变成能检索的索引

这是我判断全系统最难的一件，也是别人抄不走的一件。

▲ 一篇笔记两百多条评论，最后进索引的只有几个块。这个压缩率是整套系统能跑起来的前提——不压，光是把它塞进上下文就能把延迟打穿。

单条评论有三个结构性毛病，导致它没法直接索引。太短（“+1”、“我也是”），语义密度不够，embedding 出来的向量基本没意义；指代缺得到处都是（“这家”“那个老板”“这个价”），脱离笔记就不知所指；语境强依赖（“周末去的，人巨多”），不知道哪家店、哪个周末。

能走的路只有先聚合再索引：

原始评论流（数百条）
→ 噪声过滤（表情 / 纯 @ / 广告导流 / 重复刷屏）
→ 话题聚类（住宿 / 交通 / 价格 / 服务 / 排队 / 推荐菜）
→ 每簇内抽取式归纳，产出结构化槽位
→ 生成「评论证据块」：{维度, 观点极性, 具体论据, 支撑评论ID, 条数}
→ 该块作为独立 chunk 入索引，parent 指向笔记 ID

索引粒度从 N 条短评论变成 M 个语义块，两个数差一个量级，检索效率和语义质量一起上去。

上面这套是我推的。但这张官方截图把结论露出来了：

▲ 用户问"八月去北京，5 天旅行攻略"，答案旁边挂出「参考来源 47」，下面四个 tab：全部 / 好评 34 / 吐槽 3 / 中立 10。评论是一堆文本直接塞进上下文吗？不是，先按评价倾向分好组再挂上去。所谓"评论证据块"，露在外面就是这个样子。

这个面板顺带回答了一个我原本只能猜的问题：正文和评论区打架时它站哪边。答案是都不站，分开摆。好评、吐槽、中立三个数字就在那里，用户自己看比例。

容易做反的一点：过滤时别用情感极性做权重，要用信息增益。直觉上会想滤掉负面评论，但避坑场景恰好反过来——负面又具体的评论才是最高价值证据。真正该滤掉的是"情绪很冲但没有任何事实"的那种（“垃圾店家气死我了”），它不提供任何可验证的东西。

打分维度大概是四个：具体性（有没有价格、时间、位置这些可验证实体）、独特性（是不是和别的评论重复）、可归因性（指向的实体明不明确）、可信度（有没有真实消费记录）。

卡点二：延迟的杠杆在检索侧，不在推理侧

这条在 RAG 系统里反直觉，但最值钱。

▲ 上下文一路收窄，最后只剩一根线往下走。收窄的动作有四个——限 top-k、限时效窗、压证据块长度、prefix cache 复用——但对首字延迟真正起作用的只有前两个。

响应延迟大致是这么构成的：

总延迟 ≈ prefill（正比于上下文长度） + decode（正比于输出长度）

输出长度由答案决定，不好砍。上下文长度完全由检索策略决定，这个旋钮是产品自己握着的。

所以优化顺序应该是这样的：流式输出排第一，因为用户感知的"响应"是第一个字出现，不是答案生成完；检索收敛排第二，限 top-k、限时效窗、压证据块长度，砍掉七成上下文，TTFT 能降一半以上，成本同步往下掉；然后才是 Prefix Cache（系统提示词和检索模板是固定前缀，可以跨请求复用）；量化或者投机解码放最后，它对生成速度有帮助，对 TTFT 影响有限，因为 TTFT 主要压在 prefill 的计算量上。

"优先引用 7 日内更新的笔记"这条规则值得说一句。它表面是个时效性需求，工程上同时办了三件事：信息更新鲜、检索空间更小、成本更低。一条规则同时优化三个指标，这种设计不多见。

但它也有代价。7 天窗会让长尾吃亏——小众景点、冷门店面，七天里可能一条新笔记都没有。更合理的做法是双窗：热门实体用 7 日窗，长尾自动放宽到 90 日，然后在答案里标一句"信息较旧，建议核实"。用一个统一窗口是省事，不是最优。

卡点三：可点的关键词必须在生成时打标记

"哪里不会点哪里"这个交互，落到工程上是一条很硬的约束。

为什么不能让检索阶段抽完实体直接标？因为可点击区域必须和最终渲染出来的文本严丝合缝。检索阶段抽出来的实体只是一个候选池，它保证不了最后一定出现在答案里——LLM 生成时会改写、合并、省略、换说法，把"XX 路 89 号"写成"那家店"就全废了。

如果标记来自检索层，两种坏法：标的字在答案里不存在，点不了；答案里的关键信息没被标，漏点。

所以标记只能发生在生成阶段，实现上大概率是结构化输出：

「值得去，但别<k id="e17" type="entity">周末</k>去。
<k id="e23" type="attr">招牌那道菜</k>确实好，
周末<k id="e31" type="metric">排队两小时</k>就不值了。」

→ 流式解析 → 渲染成可点击 span → span 绑定实体 ID

这跟 citation 标注是同一套机制，只是 citation 绑的是来源文档，这里绑的是实体和属性，用来生成追问。

道理讲完，看一眼实物会清楚很多：

▲ 正文里"小红书"“RED 新生代创作大赛”"2000 万粉丝博主的第一份工作是什么"这几处是青绿色的。边界落在句子中间，和前后文字严丝合缝——标记只能由生成侧给出，检索侧抽的实体做不到这种贴合。

追问那边则以模板加槽位填充为主，因为要秒出——点完 200 毫秒内得看见三个候选。走实时 LLM 生成最少 800 毫秒到 2 秒，中间这段空窗体验就断了。模板得按实体类型分：

restaurant → ["{name} 人均多少", "{name} 要排队吗", "{name} 适合带小孩吗"]
attraction → ["{name} 门票多少", "{name} 几点人少", "{name} 值得去吗"]

更可能的实现是双路：快路走模板，200 毫秒返回；慢路在后台用 LLM 生成个性化追问，1 秒后替换或追加。既保住秒出，又有深度。

开发者容易吃暗亏的一点：结构化标记会限制模型的输出自由度。模型不能自由换说法、不能随手省略，否则标记对不上文本。交互侧的创新，反过来给生成质量上了枷锁。产品经理看到的是体验提升，开发者看到的是生成约束，两边说的都对。

卡点四：长任务的状态管理

攻略模式能跑五分钟以上。公开实测里有人反馈"等的时间远超五分钟"，而且没有一键重新生成，得点好几次才能重来。

这暴露的不是模型问题，是长任务工程没做扎实。也是它为什么选了 WebSocket 而不是 HTTP 或 SSE。

很多人以为上 WS 是为了流式输出，其实 SSE 也流。真正卡住的是这几项：

后三项是决定性的。尤其断点续传——用户切后台、锁屏、地铁里换网络，SSE 全断，回来只能从头来。攻略模式恰恰是最需要"切出去再回来接着看"的场景。

所以 WS 的硬理由就三条：双向即时取消，省算力也省用户等待；状态化长任务，凭 session id 加序号续传，不用重放；一条连接跑多个会话。

难点分级：最难的都不在模型侧

把难点按性质摆开，会看到一个不太符合直觉的结论。

最难的两个是数据问题，还有一个是花钱买来的。

这就把"自研还是外部"的争论解释完了。珠玑不行就接 DeepSeek，因为通用推理本来就不是核心竞争力——买得到。自研线转向 REDSearcher、FireRed-Image-Edit 这些垂类，因为这些东西买不到，而且直接吃在核心体验上。

有分析说自研模型的意义未必在于做得多好，而在于保住参与下一轮竞争的资格，本质是张入场券。这个判断挺准。

选型：重点不在选了什么，在放弃了什么

先看模型分工。它不是一个模型干完所有事，是按工序切开的：

意图识别 / 查询改写 / 检索编排 → 轻量模型（自研小模型 / 珠玑）
证据重排 / 相关性判别 → 轻量模型 / 专用 reranker
复杂推理 / 答案生成 → 深推理模型（DeepSeek）
风格化改写 / 安全审核 → SFT 垂类模型

放弃的是端到端的单一模型一致性，还有"一个模型搞定一切"的简洁架构。软融合（ensemble）基本可以排除：两个不同家族的模型在同一段推理里交替干活，tokenizer 不一致，hidden state 对不齐，延迟翻倍成本翻倍。一个把响应速度当卖点的 C 端产品不会这么干。

这种切法的风险在于工序之间丢信息。检索编排模型理解的意图，和生成模型看到的意图如果不一致，就会出现"查对了但答偏了"。解法是在工序间传结构化的中间状态而不是原始文本，不难，但容易漏。

评论索引那边选的是先聚合再索引，放弃的是单条评论的可检索性——用户搜不到某一句原话。聚合还有个有损问题：聚类边界一旦切错，跨维度的信息就丢了；归纳式摘要本身也会丢细节。什么时候这个选择会出错？用户的问题特别具体的时候，比如"有没有人提过 302 房间"。补法是双层索引：聚合块负责召回，定位到块之后再去原始评论里捞原句。

WebSocket 那条前面说过了，补一个反向判断：如果产品形态退回一问一答、没有长任务，WS 就是纯负担。事实上主站划词速答那个场景要求一秒响应，用 SSE 反而更轻。所以"全站统一走 WS"有可能是架构上的过度统一。

最后说签名。第三方逆向报告说它用的是 XXTEA 加密加自定义 Base64，而不是常见的 HMAC 或 RSA。

从密码学角度看这是次优解。XXTEA 有已知的 related-key 攻击面，128 位密钥按现代标准偏弱，而且它压根不是标准签名算法。

但从工程角度这是最优解。XXTEA 的实现不到 1KB，零依赖，iOS、Android、Web、小程序四端能共用同一份逻辑——跨端签名一致是多端产品的大坑，算法越简单越不容易出错。而且小红书的客户端风控签名（x-sign 那一套）本来就是这个栈，换 HMAC 意味着客户端、网关、风控、日志、灰度全链路迁移，成本远超收益。

更重要的是，这类签名真正想抬的是逆向成本，不是密码学强度。目的是让"抓包、复现、批量刷量"这条链路的投入产出比变负。XXTEA 加上自定义字符表和参数排序拼接，足够让脚本止步，也不给正常用户增加任何成本。

把它当密码学失误来批评，是误读了设计目标。真要说它什么时候会出事——当需要"客户端持私钥、服务端只存公钥"的密钥隔离时，对称加密做不到，一旦某个客户端密钥泄露就是全局沦陷。真改的话方向是 Ed25519，同样是轻量实现，但语义是对的。

三、把两套说法对起来

前面两半各说各话，单独看都成立。这一节把它们摆到一起，找那些"只在单个视角下才成立"的合理化。

下面这张表是我写这篇最想留下的东西。同一个决策，产品经理和开发者给出的理由经常不一样，而真实驱动因素往往两边都不提。

这张表的用法：当两边说法不一致时，别急着判断谁对，先找真实驱动。找到了才知道这个决策在什么条件下会失效。

▲ 两条橙、两条绿，各自从两边汇进同一个点，再各自散开。产品经理和开发者很少直接吵，更多是各走各的路，谁也没在那一点上停下来看。

三个错位

产品经理容易把"能力接入"当成"能力获得"。

接了 DeepSeek，很容易觉得"我们现在有强推理能力了"。实际拿到手的是推理能力的延迟、推理能力的成本，还有两个模型之间协同的复杂度。能力是借的，代价是自己的。这事在 AI 产品里太常见了——用了 GPT-4 就以为产品变聪明，其实只是账单变贵。

开发者容易把"指标"当成"目标"。

延迟从 5 秒优化到 2 秒，从工程看是体验变好了。但用户要的不是快，是敢决定。一个 2 秒给出的模糊答案，不如一个 5 秒给出的、带原帖链接和真实评价的确定答案。技术指标是体验的代理变量，不是体验本身。把代理变量优化到极致，可能离真实目标更远。

两边都不认领的那个问题最要命。

产品经理盯的是内容生态，站内有没有好内容、创作者活不活跃。开发者盯的是索引质量，召回率、相关性、无结果率。两边都默认"数据是给定的"。

但数据正在被污染。2026 年初，OpenClaw 这类 Agent 工具已经能全自动托管小红书账号，批量生产"伪体验"种草笔记，还出现了用户因 AI 笔记误导消费的纠纷。2026 年 8 月，小红书处置违规笔记 15 万余篇、违规账号 1400 余个。

这是一条闭合的路：AI 需要真实 UGC，AI 又降低了生产 UGC 的成本，UGC 被 AI 内容稀释，AI 的信源质量下降，产品价值归零。

产品经理会说这是内容治理的事，不是产品的事；开发者会说这是数据团队的事，不是检索的事。而这个问题最该待的地方，恰恰是检索链路——把 AI 生成检测做成召回排序的前置因子，给每篇笔记维护一个综合可信度分数（账号真人度、内容原创度、AI 生成概率、跨笔记一致性）。

谁都不认领的问题，最后会杀死产品。

▲ 从绿色开始，绕一圈走到暗红，最后没接回来。这个环上没有外力，每一步单独看都合理，合起来是自杀。

结尾

说三件我认为能带走的东西。

做垂直 AI 产品，胜负手在"数据获取权"加"数据处理意愿"，不在模型能力。点点用 DeepSeek 补推理、用自研做场景适配，这套分工零技术壁垒，任何公司都能干。但它能拿到评论区，别人拿不到，更关键的是它愿意为这堆脏数据付出工程代价。

所以做 AI 应用时该这么问自己：我有什么别人拿不到的数据？我愿意为这份数据做多脏的活？最后才是用什么模型。顺序一反，做出来的就是个套壳。

AI 搜索的商业悖论是结构性的，绕不过去，只能换路。卖曝光这条路上，答案越完整广告越少，百度已经用财报演示过一次。解法不是让答案不完整——那是产品自杀——而是把变现从卖曝光挪到卖能力。

还有一条容易被忽略：在 C 端产品里，省掉一次用户思考的价值，经常高于把准确率提升 10%。“点三个候选问题"技术上一点都不难，模板加槽位填充，但它把二次提问的成本从"想清楚再打字"压到"点一下”。这个体感差距，比模型从上一代升到下一代明显得多。AI 产品的竞争，正在从"谁更聪明"转向"谁更少让用户费劲"。

最后说一个我写这篇时才想清楚的事。

传统软件里产品经理定做什么、开发者定怎么做，界限清楚。在 AI 产品里这条线塌了，因为最关键的几个决策同时是产品决策和技术决策：索引评论区既是定位选择也是改检索架构，上 WebSocket 既是协议选型也是支撑五分钟长任务，攻略模式限额既是开放节奏也是成本控制。

所以点点最值得学的可能不是功能也不是架构，是那个"三一结构"本身——它其实是一次把产品判断编码进工程结构的尝试。一脑编的是"场景比能力重要"，一目编的是"评论区才是真话"，一手编的是"用户不知道该问什么"。

架构图就是产品策略的另一种写法。一个团队要是真把产品想清楚了，它的架构是能反推出产品逻辑的；反过来，架构乱通常意味着产品判断本身就模糊。

附：哪些是事实，哪些是我推的

点点没有技术博客，没有架构分享，也没有公开过模型分工的细节。文中所有涉及内部实现的描述，请按"合理推演"理解，不是事实。能带走的应该是推理方式，不是结论。

基于 2026 年 11 月前的公开信息写作。产品迭代快，细节以官方最新版本为准。