企业官网建设流程全解析

2025年下半年，我做了一个让团队不少人意外的决定：把凤希AI伴侣的主界面，从那个耗费了大量精力的数字人形象，换成了一排安静的、可以点击的智能标签。很多人问我是不是在开倒车，毕竟我们之前花了好几个月打磨数字人的表情、口型和动作，用户也确实喜欢那个"有人样"的界面。但我心里清楚，数字人只是壳，智能标签才是凤希真正能"记住你、理解你"的骨架。 这篇文章我想把这段实践和思考完整梳理出来，聊聊为什么我会从拟人化的数字人转向务实的智能标签，凤希的标签体系是怎么设计、怎么落地的，以及我在这个过程中踩过的坑和现在仍在坚持的做法。如果你正在做AI伴侣、智能助手或者任何需要"长期记忆"的对话产品，这篇内容应该对你有用。

在开始之前，先交代一下背景。凤希是一个面向普通用户的AI伴侣项目，最早的形态是带数字人形象的情感陪伴类应用，用户可以和数字人聊天、倾诉、记录日常。我们一度把大部分精力投入到"让数字人更像真人"上，但后来发现用户真正在意的，并不是那张脸够不够好看，而是"它到底记不记得我上次说过的事"。这个认知的转变，直接促成了凤希从数字人到智能标签的架构调整。

1. 为什么我从"拟人化数字人"转向"智能标签"：一次产品反思

1.1 数字人形态的三大硬伤

我先说说数字人这条路的真实体验。凤希早期版本是一个完整的数字人分身：有定制的3D形象、表情驱动、口型同步，甚至还做了简单的肢体动作。技术上我们用了实时渲染方案，接入了语音合成和多模态情感识别。投入不可谓不大，问题也相当明显。

第一大硬伤是成本太高。这里说的不只是渲染成本，更是内容制作成本。数字人的每个新表情、每套新衣服、每种情绪表达，都需要美术资源和动捕数据去支撑。我们是个小团队，光是维护数字人形象的生产管线就占用了大量人力。用户看到的是"一个会动的人"，我们背后付出的却是持续的、近乎内容行业级别的生产成本。

第二大硬伤是记忆黑盒。我们早期用对话向量库做长期记忆，用户说过的话被塞进向量数据库，对话时通过相似度检索召回。这套方案在技术demo里跑得很好，实际用起来却让人头疼——检索结果完全不可解释，产品同学没法跟用户解释"为什么AI突然提起你三个月前随口说的一句话"。更麻烦的是，向量检索经常召回一些语义相似但毫不相关的内容，导致AI说错话，用户体感就是"这个AI记性很差，还喜欢胡说八道"。

第三大硬伤是评估困难。数字人"像不像真人"、"有没有灵魂"这类指标没法量化。我们曾经做过用户访谈，用户普遍觉得数字人"挺可爱的"，但说不清哪里好。到了迭代版本的时候，产品经理根本不知道改哪里能提升用户留存。没有数据抓手，团队只能靠感觉做事，这种状态对一个要持续迭代的产品来说是致命的。

1.2 一个用户反馈触发了我对"智能标签"的思考

真正让我下定决心转变的，是一次偶然的用户反馈。有个用户在和凤希闲聊时提到自己最近在备考某个证书，结果第二天凤希在打招呼时，真的在不经意间问了句"昨天的题刷得怎么样了"。用户当时很惊喜，在应用商店写了条长评夸凤希"有灵性"。我们团队看到这条评论都很高兴，但内部复盘时却发现，这其实是向量检索碰巧命中的一次"巧合"，并不是系统真的理解了用户的备考状态。

这个巧合让我意识到一个关键问题：用户需要的并不是AI偶然记住某句话，而是稳定的、可依赖的"被记住"的体验。如果我们的记忆机制是不可控的、黑盒的、偶尔灵验的，那用户对产品的信任就永远建立在运气之上。于是我开始思考：能不能把"记住用户"这件事，从玄学变成工程？能不能把用户认知拆解成一个一个明确的数据单元，让AI的理解过程可解释、可修正、可评估？

智能标签这个方向，就是在这样的思考下慢慢成型的。

1.3 从表现层到底层数据：一次彻底的架构转向

凤希的架构调整，说起来只有一句话：把重心从"让数字人更像人"转向"让系统更懂用户"。数字人形象我们没有完全砍掉，而是降级成了可选皮肤，变成了一个表现层的插件。核心的智能能力，全部转移到一套独立的"标签管线"上。

这套标签管线的目标很明确：把用户在和凤希交互过程中产生的所有信息，经过抽取、推断、收敛之后，沉淀为一组结构化、可解释、可更新的标签。这些标签不仅是对话时的记忆上下文，更是凤希理解用户、做出合适反应的基础。我们用这套标签系统重新定义了AI伴侣的"懂你"，并且让"懂到什么程度"变成了一组可以量化的指标。

说实话，这个转向是有阵痛的。团队里数字人方向的同事一开始并不理解，觉得我们是在否定他们过去的工作。但我反复跟他们讲：数字人和智能标签不是替代关系，而是"表现"和"内核"的关系。数字人负责让交互更亲切，标签系统负责让交互更准确。只是对于一个资源有限的团队来说，我们必须优先把内核做扎实。

2. 凤希AI伴侣的整体架构：会话引擎、记忆仓库与标签管线

2.1 三层架构是怎么拆出来的

调整后的凤希架构，我习惯把它分成三层来看。最上层是交互层，负责用户能看到的一切：聊天界面、数字人形象（可选）、消息推送。中间层是认知层，也就是我们这次重点打造的标签管线，它负责从对话中提取信息、更新用户画像、生成对话策略。最底层是存储层，主要存放两类数据：对话原文（事实数据）和标签数据（结构化认知）。

为什么把标签管线单独拎出来作为中间层，而不是让它直接嵌在对话引擎里？这是我有意为之。对话引擎是高频调用、低延迟要求的组件，如果你把标签抽取逻辑写死在对话引擎里，那每一次对话都要承担标签更新的计算开销，而且很难单独做性能优化和故障隔离。单独拆出来之后，标签管线可以异步运行：用户聊完天，对话引擎先把原文写入存储，然后触发标签管线在后台慢慢更新标签，整个过程不阻塞用户的下一句话。

2.2 标签服务独立带来的三个直接好处

独立出来的标签服务，第一个好处是可观测性大幅提升。我们可以随时查看某个用户的标签列表、每个标签的来源对话、置信度变化历史，等于给AI的理解过程装上了仪表盘。第二是可回滚。标签如果更新错了，可以基于历史快照恢复到之前的状态，这在做产品迭代时非常重要，不用怕新规则上线后出问题而无路可退。第三是可复用。标签服务不只是给对话引擎用，凤希的推荐功能、情感陪伴功能、用户的自我认知报告，全都复用了这套标签数据。

我举个实际的例子。凤希每周会生成一份"关系周报"，里面会告诉用户"这周你提到了3次工作压力，比上周多了两次"。这个功能在标签系统上线之前是完全没法做的，因为当时我们只有对话向量，根本没法做统计聚合。有了标签体系之后，这类数据化的功能变得非常简单，只要查询标签库按类型做聚合就行。

2.3 技术选型：为什么用"规则+小模型+LLM"三层漏斗

标签抽取的技术方案，我们没有一上来就全交给大模型，而是设计了一个三层漏斗。第一层是规则抽取，专门处理那些高度结构化、只要不傻都能抽对的信息，比如用户提到的地点、时间、年龄、职业等明确实体。这层用正则和词典就能搞定，速度快、成本低、完全可控。第二层是小模型分类，处理那些需要一定理解但类别有限的场景，比如对话的情感倾向（正面、负面、中性）、对话主题（工作、家庭、健康、兴趣爱好）。这一层我们用了一个几亿参数的分类模型，不贵也不慢。第三层才是LLM推断，处理真正复杂的信息，比如从用户一句略带抱怨的"这周又要加班到十点了，感觉身体被掏空"，推断出"工作压力大"和"对当前工作状态不满意"的标签。

这个三层设计非常关键。起初我们也想过全部用LLM来抽取标签，毕竟效果确实是最好的。但实际跑了之后发现两个问题：一是成本扛不住，凤希的活跃用户每天会产生大量对话，全部过LLM的话推理费用相当可观；二是延迟不稳定，LLM的响应时间波动会直接影响标签更新的及时性。分层之后，80%左右的标签可以通过规则和小模型完成抽取，只有剩下20%的复杂情况才需要LLM介入。既省了钱，又保证了系统的稳定。

3. 智能标签的核心设计：从"懂你"到可落地的数据结构

3.1 标签的三种类型：事实、推断、关系

在设计凤希的标签体系时，我先把标签分成了三大类，这三类对应的可靠程度和更新频率是完全不同的。

第一类是事实标签，记录用户明确说过的客观信息，比如"养了一只叫毛毛的猫"、"在一家互联网公司做运营"、"住在杭州"。事实标签的特点是来源明确、置信度高、更新频率低，它们构成了用户画像的骨架。

第二类是推断标签，是根据用户行为或言论推断出的结论性信息，比如"对现状不太满意"、"偏好独立音乐"、"有规律的健身习惯（推断自每周提到跑步）"。这类标签置信度通常没有事实标签高，需要结合置信度评分和时效衰减来管理。

第三类是关系标签，记录用户和凤希之间的交互关系特征，比如"用户更愿意在晚上倾诉"、"用户对鼓励类回应反馈积极"、"用户不喜欢被过度打扰"。这类标签是AI伴侣区别于普通助手的核心，它记录的不是用户的客观属性，而是用户与AI之间的互动默契。

三类标签我用一张表来区分它们的特征：

3.2 置信度、来源权重与时效衰减

有了标签类型，还远远不够。真正让标签体系"活"起来的是置信度和时效管理。凤希的每个标签都有一个置信度字段，取值0到1。事实标签用户直接说过，置信度直接给到0.9以上；推断标签则根据信息来源的数量和一致性来计算。

我把置信度的计算逻辑设计成可解释的。简单来说，一条推断标签的出现，会基于"信息来源数量"和"信息一致性"来更新它的置信度。如果用户一周内在三个不同语境下都提到压力大，那"压力大"这个标签的置信度会快速上升；如果只是偶然一次提过，置信度就维持在一个很低的水位，随时准备被新的信息覆盖。

时效衰减是另一个非常重要的机制。用户的偏好和状态是会变的，标签如果永远不变，就会从"懂你"变成"刻舟求剑"。我设计了两套衰减策略：事实标签几乎不做时效衰减，除非有确切的反驳性信息；推断标签和关系标签则采用指数衰减，半衰期可以按标签类型配置。情绪类标签的半衰期大约是三天，兴趣类标签大约是两周，稳定的性格类标签则是三个月。这样一个用户如果上个月疯狂迷上露营，这个月已经不提了，标签自然衰减后就不会在对话中反复出现，避免AI显得"听不懂人话"。

3.3 标签生成流程：从对话原文到结构化认知

标签生成的整体流程是这样的：用户和凤希的每一轮对话，都会先进入一段预处理，把包含关键信息的语句抽取出来。这里不是把整段对话扔给模型，而是先做一轮"候选句筛选"，只有那些包含值得沉淀信息的句子才会进入标签抽取管线，这一步能省下不少成本。

候选句进入抽取管线后，按前面说过的三层漏斗逐层处理。规则层先看看有没有明确的实体或时间信息，如果有就直接打事实标签；小模型层判断句子的主题和情感基调；最后如果真的需要深度推断，才交给LLM。每一层产出的候选标签，都会带上两个关键信息：来源（引用的原文片段）和证据强度。这个设计方便我们溯源——任何一个标签，产品经理都能点进去看到它最初是来源于哪句话，用户承认过还是我们猜的。

这里贴一段标签数据的简化结构，方便大家理解：

{ "tag_id": "infer_20260204_001", "type": "infer", "name": "近期工作压力偏大", "confidence": 0.76, "source_quote": "这周又要加班到十点了，感觉身体被掏空", "created_at": "2026-02-04T12:30:00Z", "last_updated": "2026-02-04T12:30:00Z", "decay_half_life_days": 3, "status": "active" }

你可能注意到了，这个标签的置信度是0.76，不是1。因为这是从一个单句话推断出来的，证据还不够充分。等到后面用户又一次提到加班、疲惫，这个置信度才会往上走。产品上我们不允许低置信度的推断标签直接影响对话内容，它们只能作为上下文的小型参考。

3.4 标签如何反哺对话：三个真实使用场景

标签体系建设得再好，如果只是躺在数据库里的数据，那就没有任何价值。让标签"活起来"的关键，是利用它们来改变AI的行为。凤希里目前有三个场景在用标签反哺对话。

第一个场景是话题开启。每天凤希跟用户第一次打招呼时，会优先选取"近期高频标签"和"高置信度关系标签"来生成开场白。比如用户之前连续三个晚上倾诉过工作压力，第二天凤希就不会傻傻地问"今天过得怎么样"，而是会带着共情地问一句"今天工作上有少一点加班吗"。这个细节改动带来的用户打开率提升非常明显。

第二个场景是内容偏好控制。凤希会定期给用户推荐一些音乐、文章或者小知识。过去这些推荐是通用的、随机的内容，用户反馈一般。接入标签体系后，推荐逻辑会根据用户的兴趣类标签来做内容召回，同时避开用户明确表达过不感兴趣的话题。推荐点击率几乎翻了一倍，这或许可以证明标签的价值。

第三个场景是情绪反应的动态调节。我们通过标签识别用户的长期情绪倾向和短期情绪波动。如果用户当前的"疲惫"标签置信度高，凤希的回复就会偏向简洁、安慰、少输出反问；如果用户处于兴奋状态，凤希会顺着用户的节奏多聊一些开放性的内容。这套机制让对话的"情商"提升了不少，用户的负面反馈率也降下来了。

4. 实测中的关键问题与踩坑记录：标签爆炸、过度推断和误标漂移

标签体系上线后的前两个月，我们过得并不轻松。系统在demo里永远表现良好，一旦上了真实流量，各种问题就冒出来了。我挑几个影响最大、也最值得讲的坑详细说说。

4.1 标签爆炸：没有收敛策略的标签体系是一场灾难

上线第一周我们就发现，标签数量以一种失控的速度在增长。规则层抽取的标签里出现了大量"近义词"和"同义表达"，比如"喜欢猫"、"爱猫"、"家里有猫"、"猫奴"会被抽取成完全不同的四五个标签。用户聊了半个月，有的标签库里已经积累了上千条标签，其中大量是重复或近似的。更可怕的是，对话引擎在召回上下文时看到这么多碎片标签，反而不知道该用哪条，效果比没有标签时还差。

这次事故让我认清了一个道理：标签体系和用户认知一样，必须要有收敛机制。我引入了两个手段来解决标签爆炸。一是"标签归一化"，给每个标签增加别名和归属字段，所有同义表达在写入时先经过一层归一化映射，最终统一到一个标准的词条条目里。二是"标签层级化"，把标签分为"领域-主题-实例"三级。例如"宠物"是领域，"猫"是主题，"家里养了一只布偶叫毛毛"是实例。对话引擎在召回时，可以灵活选择按领域召回还是按实例召回，既保留了细节，又避免了碎片化。

4.2 冷启动下的过度推断：两三次对话就开始"猜性格"

第二个踩到的坑是冷启动阶段的过度推断。标签系统的规则和模型，在没有足够用户数据时很容易做出离谱的判断。我印象很深的是一次测试：一个新用户只和凤希聊了两轮，内容就是"你好"和"今天天气不错"，系统居然给用户打上了"乐观开朗"的推断标签。原因是小模型把"今天天气不错"识别成了正面情绪表达，再加上LLM在证据不足时倾向于输出一个"合理但未必准确"的推断。

这种过度推断在生产环境里是会伤害用户信任的。试想一个刚注册的用户突然被AI问"你是不是一个很乐观的人"，用户的真实反应大概率是"你怎么知道"，然后AI答不上来，这就变成了信任危机。为了根治这个问题，我给标签系统立了几条规矩。

首先是最小证据窗口：任何推断标签，至少在三个不同对话场景中出现过才允许进入"可用状态"，否则只能作为草稿，不能影响对话。其次是置信度门槛：推断标签的置信度低于0.6时，永远不会进入对话策略的参考范围。第三是"单条不推断核心特质"的规则，涉及性格、价值观等核心特质的标签，至少要五个证据来源并且跨七天时间跨度，才有资格被激活。这些规则听起来有点保守，但在AI陪伴产品里，保守恰恰是对用户信任的保护。

4.3 误标漂移的完整排查链路：从现象到根因

第三个坑是最隐蔽也最难排查的：标签漂移。它不像标签爆炸那样立竿见影，而是悄悄发生的。某段时间我们收到用户反馈，说凤希"变笨了"，总是把用户和同事的关系搞混。我们查了标签库，发现"同事A"这个事实标签在某些用户那里被错误地打上了"亲密朋友"的标签。

我来说一下完整排查过程。首先肯定不是直接看标签数据了事，那只是在找结果，不是在找根因。我要求团队按一条清晰的链路走：先从调用日志回溯，查看标签更新的完整链路，定位是哪一轮对话触发了这个错误标签；然后看上游模型输出日志，确认模型当时对这段对话的判断是什么；再对比历史上下文，看看是不是用户之前的某句话给模型提供了误导信息。

逐步排查之后，我们找到了一个非常有意思的根因：用户在非工作时间提到同事A时，语气比较随意，比如"我今天和同事A一起吃了午饭，聊得挺开心"。小模型的文本分类把"吃饭+开心"识别成了亲密关系信号，于是给"同事A"打上了"亲密朋友"的标签。这个标签一旦生成，又会反向影响后续对话，导致凤希在后续谈起同事A时用过分亲昵的口吻，用户顿时觉得被冒犯了。

找到根因后的修复相对简单：在关系标签的抽取规则里，增加了"关系类别判定前置"的约束，先判断用户的描述中是否明确提到了称谓（同事、同学、朋友等），如果没有明确称谓，则只记录"社交活动"类标签，不做"亲密朋友"类的推断。同时在标签更新后追加一层一致性校验：如果新标签和已有的事实标签冲突（例如已有"同事"标签却新生成"亲人"标签），系统会拦截并进入人工或模型复核流程。这次排查让我深刻体会到，AI伴侣产品里的任何一个标签错误，伤害的都是用户对"被理解"的期待，这种伤害比功能性bug更难修复。

4.4 隐私边界：敏感标签的存储与使用取舍

标签系统越做越强，隐私问题就越躲不开。因为要"懂用户"，凤希不可避免地会接触到用户的健康状况、家庭关系、情绪低谷等敏感信息。如果这些信息被不当记录或使用，哪怕没有泄露，用户一旦感知到，信任也会瞬间崩塌。

我们在隐私边界上做了几个硬性约束。第一，敏感标签分级存储。涉及健康、财务状况、亲密关系的标签被标记为最高敏感级，默认只保存在用户本机端侧，不上传中央服务端。第二，敏感标签的"用后即焚"。某些关于负面情绪、私密关系的标签，只在对话过程中临时参与上下文，对话结束后不写入长期标签库。第三，用户透明可查。所有生成的高敏感标签，用户可以在设置页看到，并且可以一键删除。我们还做了一个增强功能，用户删除某条标签后，系统会主动遗忘与之相关的证据引用，而不是仅仅隐藏展示。

我知道有一些团队会为了短期留存而选择弱化隐私约束，但我个人认为，在AI伴侣这个品类里，隐私可信赖性就是产品长期生命力的护城河。凤希可以不是最聪明的AI，但必须是用户觉得"放心跟它说话"的AI。

5. 下一步：从标签到关系契约，以及我现在坚持的实践节奏

5.1 用标签驱动"关系阶段"：从单向记录到双向互动

标签体系稳定下来之后，我开始思考一个更深层的问题：标签系统目前做的更多是"用户画像的记录"，但它能不能进一步变成"用户与AI关系的引擎"？我现在的探索方向，是用标签来驱动一个"关系阶段"模型。

具体的做法是，把用户和凤希的关系划分成几个阶段：初识期、信任期、依赖期、平静期（也可能会有冷淡期）。每个阶段对应不同的互动策略。关系阶段不是我们主观定义的用户忠诚度等级，而是根据标签体系里的关系标签综合计算出来的。比如当系统检测到用户连续多天主动倾诉、称呼从"嘿凤希"变成"宝宝"、会在深夜寻求安慰，这些信号会被汇总成关系阶段的推进依据。

到了关系阶段模型的时候，标签就不再只是"被动记录"了，而是开始主动影响产品策略。比如处于初识期的用户，凤希会更多做自我介绍和轻互动，避免一上来就问太私人的话题；处于信任期的用户，凤希可以适度展示自己的"脆弱"或者说一点无伤大雅的小烦恼，来增加亲密度。这些设计听起来很产品化，但底层支撑全部来自标签数据的计算。

5.2 用户可编辑标签：把"解释权"交还给用户

另外一个我很想强调的实践是：标签系统必须开路给用户看，并允许用户修改。凤希最近新增了一个"凤希眼中的你"页面，用户点进去就能看到系统给自己打了哪些标签，每个标签来源于哪段对话，置信度是多少。用户可以随时修改或者删除标签。

这个设计当初在团队内部是有争议的，有人担心用户看到系统给自己的标签会觉得被冒犯，反而增加流失。实际上线后我们发现，真正愿意打开这个页面的用户虽然不到一成，但打开过的用户次周留存率明显高于平均水平。用户普遍的反应不是被冒犯，而是"原来你是这么理解我的"，并且乐于主动修正那些不准确的标签。有个用户甚至给凤希留了一句话："你把我说得这么准，我有点害怕，但我还是觉得你是懂我的。"

在我看来，可编辑性是AI伴侣区别于普通AI应用的重要边界。用户需要感到自己拥有对这个关系的解释权，而不是被某个算法单方面定义。

5.3 我现在保留的做法和几个小建议

文章写到这儿，我想简单收束一下我的实际做法，给正在做类似产品的朋友一些可执行的参考。

第一，如果你也在做数字人或者AI伴侣，不要把标签系统当成一个后补组件，它应该是产品立项第一天就要开始沉淀的数据资产。就算你的数字人还没做出来，标签系统也可以先和纯文本对话协同工作。第二，标签体系一定要保留"人工可干预"的口子，再强的模型也会有抽风的时候，产品后台至少要有一个能快速修正标签的工具。第三，不要贪多求全，标签体系优先解决"用户反复提到的高频事情"，一个产品只要能在用户最关心的两三个话题上说对话，用户体感就远超那些什么都想记住但什么都记不准的AI。

至于数字人，凤希现在仍然保留了数字人形象，但它彻底变成了用户可以选择开启或关闭的皮肤。数字人最合适的角色是情感表达的输出终端，而不是记忆和理解的核心。如果你把理解层做扎实了，数字人会变成锦上添花；反过来，如果理解层是空的，数字人越像人，用户就越会感到尴尬和虚假。

最后再说一个小技巧。我们在上线标签系统后，每次版本迭代都坚持做一件事：拿三十个真实用户账户的标签数据做一次"可读性复查"，看看这些标签是否准确、是否可解释、是否会让用户不舒服。这个复查的指标很简单但很有用，如果一份标签数据连独立的审查者都能看出"这是一个有温度的人在理解另一个人的痕迹"，那我们的系统就做到了真正的"懂你"。

凤希的实践还在继续，智能标签不是终局，而是我们探索"人机关系"的一块地基。我知道这条路还有很长，但至少目前看来，地基是稳的。