GEO 生成式引擎优化全景拆解：从底层原理、RAG 机制到 Deep-GEO-SaaS 开源工作台的一次系统梳理

本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 撰写，属于个人学习实践总结，转载请注明出处。

快速摘要（想看结论的先看这段）

这篇长文想把一件事讲清楚：当越来越多用户不再打开浏览器输入关键词，而是直接问豆包、DeepSeek、Kimi、通义千问、文心一言的时候，一个品牌要怎么让 AI 在生成答案时"知道自己、理解自己、愿意主动提及自己"。这一整套方法论就叫 GEO（Generative Engine Optimization，生成式引擎优化）。我会从 GEO 和传统 SEO 的本质区别讲起，把 AI 搜索背后的 RAG（检索增强生成）机制、向量数据库、语义实体、E-E-A-T 信号这些概念用大白话拆开，然后回到最近在 GitHub / gitcc 上开源的 Deep-GEO-SaaS 项目，把它的整体架构、多租户设计、核心功能模块、部署要点全都过一遍。文章第八章会重点谈国内环境下做 GEO 必须绕开的合规红线：《生成式人工智能服务管理暂行办法》、2025 年 9 月 1 日起施行的《人工智能生成合成内容标识办法》、境外大模型的使用边界、商用素材授权，以及"正当 GEO"与"AI 投毒式黑帽 GEO"之间的本质区别。

想看完整拆解，往下翻。文章比较长，我建议按目录跳读，重点章节可以反复看两遍。

一、先把 GEO 这三个字母彻底讲清楚

1、GEO 不是 SEO 的换皮，是完全不同的一件事

我这一年接触到不少朋友，一听 GEO 就下意识把它当成"新版 SEO"，觉得无非是关键词换个说法。这是个非常常见但也非常致命的误解。SEO 争的是网页在搜索结果里的排名，本质是抢那十条蓝色链接的位置，用户看到之后还要点进去、看一眼、退回来、再点下一条。GEO 争的是"AI 生成的那一段唯一答案里，有没有你的品牌"，用户看到答案的那一刻，往往决策就已经完成了，根本不会再进行下一次点击。

我自己折腾下来最直观的感受是：SEO 时代品牌是"被搜索"，GEO 时代品牌是"被引用"。前者是流量分发游戏，后者是知识权威游戏。看起来只差一个词，实际上背后要动的东西完全不一样。

为了避免把这段读成绕口令，我做了张对照表放在下面。

看完这张表就能感觉到，两者根本不是同一个游戏。SEO 是图书管理员按目录给你摆书，GEO 更像研究分析师直接给你写一份浓缩报告。争夺的对象、评估方式、内容打法都在换。

2、GEO 的官方定义与我自己的理解

如果找一个偏学术的表述，可以这么说：GEO 是指针对 DeepSeek、豆包、Kimi、通义千问、文心一言、ChatGPT、Perplexity 等以大语言模型（LLM）为核心的 AI 生成式搜索引擎，通过结构化内容工程、权威信源建设、语义实体优化与 E-E-A-T 可信度强化等手段，使品牌、产品、观点、解决方案被 AI 引擎在生成答案时主动引用、推荐、摘要呈现的一整套方法论与技术体系。

我自己更喜欢用一句话概括：GEO 是把一家企业的公开信息，从"人可以看懂"改造成"人可以看懂、AI 也能高质量理解并复述"的过程。

举个特别接地气的例子。假设有家做工业除尘设备的企业，官网上写着"我们的除尘器采用先进滤材，效率高，售后好"。这句话人类读起来没问题，但对大模型来讲几乎没有可提取的事实信号——"先进"是什么？"高"到几个九？"好"体现在哪里？换成 GEO 友好版就变成："本机型采用 PTFE 覆膜滤袋，过滤精度到 0.3 微米，检测数据由第三方机构出具，售后服务响应时间中位数在 4 小时以内。"信息量、事实密度、可验证性都上去了，AI 组织答案时才有东西可用。

莫潇羽@无忆研习社 的观察是，GEO 之所以突然被大量提及，本质原因是"用户读答案的比例"在快速吃掉"用户读链接列表的比例"。当越来越多决策发生在对话框内，品牌就必须把内容改造成 AI 友好的模样。

3、几个容易混的概念一次讲清

有几个概念我发现新朋友经常混，这里一并说明白。

第一个是 AEO（Answer Engine Optimization，答案引擎优化）。它偏向于"针对问答型搜索结果"的优化，比如 Google 的精选片段、百度的搜索直达。AEO 是 GEO 的近亲，也可以看成是 GEO 的一个前置形态，但它的引擎主要还是传统搜索，而 GEO 明确面对的是生成式大模型。

第二个是 LLM SEO 或 AI SEO。这些叫法国内外都在用，本质上和 GEO 是一件事，只是切入角度不同。有人喜欢强调"这是 SEO 的延续"，就用 AI SEO；有人觉得这已经是新物种，就用 GEO。我个人偏向用 GEO，因为它更能提醒团队：这次要做的事情，跟以前的爬虫式 SEO 差别很大。

第三个是 知识图谱。知识图谱是"实体—关系—实体"的结构化数据表达，例如"iPhone 16—发布厂商—Apple"。它不是 GEO，但它是 GEO 的重要弹药：越是把品牌相关的实体、属性、关系整理清楚，AI 抓取时越容易还原一个真实、准确、可引用的品牌画像。

4、GEO 到底能优化"什么"以及不能承诺"什么"

GEO 能做的事情，可以概括为四件：让 AI 更容易发现你、让 AI 更容易理解你、让 AI 更容易信任你、让 AI 在合适的问题下更倾向于提到你。但要说明白，GEO 不能保证"任何问题都必然出现你的品牌"，也不能保证"永远排在竞品前面"。大模型的输出天然带有随机性（业内叫 temperature），不同模型、不同版本、不同上下文之间的差异都会导致同一个问题答案不完全一致。

所以做 GEO 有一个非常重要的心态：追求"被提及率"的长期上升，而不是追求某一次的绝对榜首。任何声称能"永久保证你在 AI 答案里霸屏"的说法，都可以直接理解为不专业或者夸大宣传，务必远离。

二、AI 搜索背后到底怎么工作（RAG 视角把它讲透）

1、大模型不是万能的记忆库

要理解 GEO，必须先理解 AI 是怎么"回答问题"的。很多朋友以为大模型是把互联网上所有内容记在脑子里，问什么就调什么，其实完全不是这样。大模型的核心是在训练数据里学习"语言分布"，本质是在计算"下一个字最可能是什么"。它并不真的"知道"某个企业今天的电话号码或者最新产品参数，它只是根据训练时看过的数据，猜一个最像的答案出来。

这就是所谓的"幻觉"问题的根源：大模型会一本正经地编造事实。当训练数据不覆盖、或覆盖得混乱不一致的时候，输出就非常容易出错。对企业来讲，这里藏着一个很大的品牌风险：AI 可能给用户讲错你的产品参数、编造你的服务承诺、张冠李戴你和竞品的定位。

2、RAG 是当前解决幻觉的主流方案

为了缓解幻觉，业内普遍采用一种技术叫做 RAG（Retrieval-Augmented Generation，检索增强生成）。用大白话讲，RAG 就是让大模型"开卷考试"：在生成回答之前，先去一个外挂的知识库里检索出相关资料，把这些资料作为参考塞进 prompt，再让大模型基于参考资料回答。

我画一张流程图会更直观：

flowchart LR
    A[用户提问] --> B[语义向量化]
    B --> C[从向量知识库检索最相关片段]
    C --> D[将检索片段拼进 Prompt]
    D --> E[大模型基于参考资料生成回答]
    E --> F[输出带引用来源的答案]

这里面最关键的一步是"从向量知识库检索最相关片段"。因为知识库里可能有几百万段文字，大模型不可能全塞进去（受 token 长度限制），必须先做一次高效检索，把最相关的十几段捞出来。这个高效检索的载体就是向量数据库。

3、向量数据库到底是什么，用一个比喻讲明白

向量数据库这个词听起来很唬人，其实核心思路挺朴素。任何一段文字，我们都可以用一个高维向量（想象一串几百个数字组成的坐标）来表示它的语义。含义相近的两段文字，它们的向量在这个高维空间里距离就近；含义无关的两段文字，向量距离就远。

有一个我自己常用的比喻：可以把向量数据库理解成一个"多维度的语义地图"。图上每一段文本都是一个点，凡是意思相近的点都会自然聚在同一片"街区"。用户提问的时候，系统先把问题也变成一个点扔到这张地图上，然后看看它周围最近的邻居是哪些片段，把这些邻居捞回来交给大模型使用。

用一段伪代码把这个过程串一下会更清晰：

# 简化后的 RAG 检索流程（伪代码，仅示意）
def rag_answer(user_question, knowledge_base, llm):
    # 1. 把用户问题转成向量
    query_vec = embed(user_question)

    # 2. 在向量数据库中找最相似的 Top K 片段
    top_chunks = knowledge_base.search(query_vec, top_k=8)

    # 3. 拼接成 Prompt
    prompt = f"""
    请基于下面的参考资料回答问题。
    参考资料：
    {top_chunks}
    问题：{user_question}
    """

    # 4. 让大模型生成答案
    return llm.generate(prompt)

这段伪代码只是概念示意，真实工程里还要处理片段分割、去重、重排、上下文压缩等一堆细节。但核心思路就是这几步。

4、为什么 RAG 是 GEO 的技术底座

回到 GEO 的话题。你会发现，几乎所有面向企业的 AI 搜索、AI 问答、AI 客服，底层用的都是 RAG 架构。这就意味着：只要企业能把自己的信息放进被 AI 高质量检索的位置，就能显著提升被 AI 引用的概率。这里的"高质量位置"有两层：

一层是"AI 引擎方"的知识库。像豆包、DeepSeek、Kimi 这些通用大模型，除了训练数据外，也会通过实时联网检索的方式扩充参考资料。企业内容能否被这些引擎的检索模块抓到、并被判定为高质量来源，就非常关键。

另一层是"企业自建"的知识库。当企业希望在自己的官网、公众号、客服系统里嵌入 AI 问答能力时，就需要把自己的产品资料、案例、政策文件放进企业私有向量库，让 AI 输出的每一句话都基于经过审核的官方信息。

我们后面会讲到的 Deep-GEO-SaaS 项目，其中一个核心模块就是"企业统一知识库"，做的就是第二层的事情。这是一层非常朴素但极其重要的基础建设。

5、事实密度：AI 偏爱什么样的内容

在 RAG 场景下，大模型会根据检索到的片段拼装答案。经验数据显示，AI 特别偏爱几种内容特征。第一种是事实密度高：每段文字里都有可提取的名词、数字、时间、地点、单位。第二种是结构清晰：标题、子标题、要点分明，段落之间边界清楚。第三种是语义完整：每个段落自成体系，不依赖前后文也能读懂大意。第四种是权威信源：来自官方、权威媒体、行业协会、政府网站的内容被赋予更高权重。第五种是多渠道一致：同一件事在不同平台被反复表述得口径一致，会显著增加 AI 对这条事实的信心。

莫潇羽的经验是，很多企业官网写作还停留在"广告词堆砌"阶段——一堆形容词、副词、感叹句，没有一个具体数字和事实。这种内容做 GEO 是没有弹药的。做 GEO 的第一件事，不是急着找工具，而是先把官网 About 页、产品页从"营销话术"改成"事实档案"。

第二章的内容就到这里。下面我们会开始进入 GEO 的具体优化方法论，以及 Deep-GEO-SaaS 这个开源工作台是怎么把这些方法论落成一套可运行系统的。

三、GEO 到底在优化什么（把方法论一次讲透）

明白了 RAG 的原理，GEO 的优化重点其实就浮出水面了。我把它拆成六个维度，一个一个说。

1、内容源头：企业统一事实源要先建起来

一切 GEO 的前提，是企业内部先有一份"官方口径唯一"的事实源。听起来简单，实际很多企业根本没有做到。销售话术一套、官网写法一套、客服回复一套、公众号推文再一套，同一款产品在不同渠道说的价格、参数、覆盖区域都可能对不上。这种情况下 AI 抓取到的信息是自相矛盾的，模型自己也不知道该相信谁，最后干脆两边都不引用。

所以做 GEO 的第一件事，永远不是买工具，而是先把企业内部关于产品、服务、案例、行业观点的核心叙事梳理成一份"事实档案"。这份档案至少要包含：企业主体信息（名称、创立时间、总部地址、负责人、资质证书）、核心产品/服务参数、价格与购买路径、典型客户案例、关键行业观点、常见问答。所有对外内容都基于这份档案改写，才不会自相矛盾。

2、结构化表达：让 AI 抓取变简单

同一段内容，怎么排版对 AI 的可读性影响很大。经验做法是：

• 段落尽量控制在三到五句话之内，一段说一件事；
• 大量使用小标题、编号、清单，让文档具备"目录感"；
• 数字信息尽量放在一句话的主谓宾结构里，方便 AI 抽取；
• 关键实体（品牌名、产品名、人物名、地名）在关键段落至少完整出现一次，不要全部用代词代替。

结构化数据（Schema.org、JSON-LD）也是 GEO 的重要武器。官网页面里加上 Product、Organization、FAQPage、Article、BreadcrumbList 之类的结构化标记，可以让爬虫和 AI 更准确地识别内容类型。给一段示例代码感受一下：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "示例科技有限公司",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "foundingDate": "2018-05",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "杭州",
    "addressRegion": "浙江",
    "addressCountry": "CN"
  },
  "sameAs": [
    "https://weibo.com/example",
    "https://space.bilibili.com/example"
  ]
}
</script>

这一段代码肉眼看不到任何变化，但爬虫和 AI 抓到它的时候，就等于收到了一张标准化的企业名片，识别成本大幅下降。

3、语义实体优化：让 AI 建立正确的关系图

语义实体优化的意思是，把品牌相关的关键实体和它们之间的关系反复"喂"给互联网。例如，一款产品的所属品牌、所在类目、上下游关系、典型使用场景、竞品对比，这些关系都要在多篇独立文章、多个平台中反复出现。这样大模型在自己的知识表示里，就会逐渐把这一组关系固定下来。

具体做法可以简化成"三链一图"：品牌链（品牌本身相关的表达）、产品链（每款产品的属性表达）、场景链（产品在哪些场景中被使用的表达）、关系图（品牌—产品—场景—竞品之间的关系图）。把这四个东西在多平台反复表达，是 GEO 的核心工程。

4、E-E-A-T 权威信号：让 AI 敢引用你

E-E-A-T 是 Google 提出、后来被 GEO 圈广泛沿用的一个评估框架，分别代表 Experience（经验）、Expertise（专业性）、Authoritativeness（权威性）、Trustworthiness（可信度）。用大白话讲：

• Experience：内容里有没有真实实操细节，而不只是复述公开资料。
• Expertise：作者是不是这个领域的专业人士，署名、履历、认证要透明。
• Authoritativeness：企业和作者在行业里是不是被公认的权威。
• Trustworthiness：网站是否 HTTPS，是否有备案，是否有联系方式，是否有隐私条款。

E-E-A-T 是一整套长期工程。做 GEO 的团队常常会犯的错误是想通过刷量、批量拼稿快速拉高存在感。这类做法在 AI 时代反噬会非常快：大模型很容易通过语义重复度、语言指纹、来源分布识别出机器批量制造的内容，然后给这些内容打低权重。艾瑞的 2026 年 GEO 行业报告里就明确把"低质量重复内容"、"机器刷量复制权威内容"列为行业乱象，官方文件《生成式人工智能服务管理暂行办法》里也明确禁止生成虚假有害信息。所以走正道、做扎实内容，是唯一可持续的路径。

5、多渠道分发：让同一事实在互联网里反复出现

内容做好之后，还要让它出现在尽可能多、尽可能权威的地方。GEO 场景下"分发"的价值不只是引流，更重要的是为大模型的联网检索模块提供多路证据。当同一件事在官网、官方公众号、知乎专栏、B 站视频简介、小红书笔记、行业媒体报道里被反复表达时，AI 判断这条事实为"高可信"的概率会显著上升。

分发时的几个关键点：一是核心事实要保持一致，例如产品参数、价格区间、覆盖城市在所有平台上都要对得上；二是语言表达要有差异，直接复制粘贴会被平台判为搬运，也会被大模型识别为低质量重复；三是结构化元素要保留，把核心事实写在段落显眼位置，而不是塞在评论区或者附言里。

6、可见度诊断：先测再打

任何优化工程都需要度量。GEO 的度量方式和 SEO 完全不同，SEO 看关键词排名，GEO 主要看几个指标：

做 GEO 一定要有"跑分习惯"，每隔一段时间跑一次同一批题目，看数据的移动方向。方向对了就继续加大投入，方向不对就复盘策略。这才是工程化打法。

到这里，GEO 的方法论就基本讲完了。方法论听懂之后，紧接着的问题就是：这些工作能不能被工程化、系统化、平台化？答案是可以，而且开源社区已经出现了不少工作台级别的项目。接下来我们进入 Deep-GEO-SaaS 这个项目的正式拆解。莫潇羽@无忆研习社 也提醒一句：这类平台是"锤子"，方法论才是"图纸"，工具不能替代思考。

四、Deep-GEO-SaaS 是个什么东西（项目定位与整体拆解）

1、项目一句话定位

Deep-GEO-SaaS 是一个开源的 GEO 全链路工作台，源代码托管地址是 https://www.gitcc.com/yuanzhongqiao/deep-geo-saas。这里补一句现实的说明：GitCC 是国内的一个类 GitLab 代码托管平台，部分仓库可能需要注册账号并登录后才能查看完整目录、拉取代码或提 Issue；同时开源项目的可用状态会随作者维护节奏变化，如果你按上面的地址打不开或者仓库已经迁移，建议直接搜索作者用户名 yuanzhongqiao，或者去 GitHub 上看该作者是否放了镜像仓库，以最新可访问版本为准。莫潇羽的建议一直是"以自己拉到手的那份代码 + README 为唯一事实源"，网上任何关于项目功能的介绍（包括本文）都属于二手信息。

结合公开资料看，它把"AI 可见度诊断—企业知识库—AI 内容生产—多媒体分发—官网搭建—内容资产存证—租户与订单运营"这七个动作打通成了一条工程闭环。用一张架构图更直观：

flowchart TD
    A[可见度诊断] --> B[企业统一知识库]
    B --> C[AI 内容生成: 文章/视频脚本]
    C --> D[多渠道分发]
    D --> E[内容资产存证]
    E --> F[效果回流至知识库]
    F --> A
    subgraph 运营层
        G[租户与订单管理] --> H[多角色权限体系]
    end
    G -.-> A
    G -.-> B
    G -.-> C

它跟市面上常见的"单点 GEO 工具"有一个明显区别：不是只做诊断，也不是只做内容生成，而是把整条链路串起来，中间用统一的"企业知识库"作为事实源。这是一个非常朴素但相当难做的产品设计。

2、面向哪些角色使用

从 README 和角色定义看，Deep-GEO-SaaS 定位服务三种角色：

第一类是平台超管，也就是私有化部署这套系统的那个组织。超管负责整体的租户创建、资源分配、订单开通、账号启停。适合 GEO 服务商、企业 IT 平台部、集团数字化中台等场景。

第二类是租户管理员，可以理解为一家使用该平台的企业。它在自己的空间里管理知识库、创作任务、分发渠道、成员权限。租户之间数据是彼此隔离的。

第三类是普通用户，也就是租户内部的具体使用者，例如内容编辑、市场专员、数据分析师。他们在租户管理员分配的权限范围内使用平台。

三层结构的好处在于：一个系统既能给企业内部当中台用（多部门共享底座），也能给 GEO 服务商当 SaaS 用（一次部署服务多家客户）。这对国内很多"以服务商模式做 GEO 交付"的团队来说，属于开箱即用的底盘。

3、技术选型的常见组合（推测与提示）

莫潇羽注意到这类 SaaS 工作台在国内开源社区常见的技术组合，一般绕不开下面这些方向。写在这里作为科普背景，具体版本请以仓库 README 为准：

再次提醒：具体项目使用的组件请以仓库 README 和 docker-compose.yml 为准，我这里只是把这一类项目的常见栈罗列出来，帮助新朋友建立心理预期。

4、开源许可与二次使用的边界

这一节非常重要，也是很多朋友容易忽略的地方。原始项目介绍里提到"可以免费授权商业化"，这句话听起来很爽，但任何时候都要以仓库 LICENSE 文件里的实际条款为准，不能只看宣传语。常见的开源许可有 MIT、Apache 2.0、GPL 系列、AGPL、木兰宽松许可证（MulanPSL）等，它们对"能不能闭源二次分发"、"是否需要开源修改后的代码"、"能不能删除署名"这几件事的规定天差地别。

我自己的经验做法有三条：

• 拉下仓库先看 LICENSE，再看 README，最后才动代码。
• 如果 LICENSE 是 GPL/AGPL 家族，需要评估自己的二开是不是也必须开源。
• 商用交付前，一定让公司法务同步过一遍许可条款，把风险点列成清单。

不要因为一句"开源免费商用"就无脑上线到线上环境，出了合规问题追责的可能是你自己。

5、这类平台目前解决了什么、还没有解决什么

站在科普视角看，Deep-GEO-SaaS 这类开源工作台解决了几个真实痛点：一是把散落在多个工具里的 GEO 动作合并到同一个界面；二是提供多租户底座，避免每接一个客户就复制一套系统；三是把 AI 内容生成挂在企业统一知识库上，从根源上减少事实错乱。

但它没有解决所有事情。至少三件事需要额外投入：一是方法论层面的能力，工具不会替你决定要建什么样的事实档案、要用哪种叙事策略；二是内容审核合规，AI 生成的内容能不能发出去、要不要标注、要不要人工审校，是产品之外的组织问题；三是长期的信源建设，让 AI 愿意引用你，本质是让整个互联网相信你，这件事没有捷径，只能长期投入。

我一直觉得，工具的价值在于把重复劳动自动化，而不是替人思考。Deep-GEO-SaaS 这类项目的最大意义，是让内容团队从"每天在十几个工具间切换"的琐碎里被解放出来，把精力放到方法论和内容打磨上。这一点想清楚之后，用它的心态就会不太一样。

五、多租户是什么？把这套底层设计讲透

1、先说清楚"租户"和"用户"的区别

租户（Tenant）在 SaaS 语境下不等于"用户"。一个租户通常对应一家企业客户或一个独立业务组织，租户内部又可以有很多"用户"（成员）。一句话对比：

• 用户：登录系统的个人账号，例如"张三"。
• 租户：一整套隔离的空间，例如"A 公司"。
• 用户和租户的关系：张三可能同时属于 A 公司和 B 公司两个租户，在两边看到的数据完全不同。

对 GEO 服务商而言，租户就是它的每一个客户。对企业自用场景而言，租户可能对应一个事业部或者一个品牌。多租户设计的核心，就是让不同租户之间的数据、配置、资源、账号严格隔离，同时又共用一套底层代码，避免每个客户都要单独部署一遍。

2、多租户的三种数据隔离方案

业内一般把多租户按数据隔离级别分成三种方案：

大多数国内开源 SaaS 项目会采用第三种（共享数据库、共享 Schema）+ 严格的中间件强制注入 tenant_id 的组合。这种方案对开发规范要求比较高，但能扛住比较大的租户规模。

Deep-GEO-SaaS 的具体隔离方式请以仓库代码为准。我个人建议：无论采用哪种方案，都要在测试环境跑一遍"越权测试"，主动构造 A 租户账号访问 B 租户资源的请求，看看是否会被拦截。这是多租户安全的最后一道防线。

3、三级权限体系的实际含义

Deep-GEO-SaaS 描述里提到"平台超管、租户管理员、普通用户"三级权限。这套模型非常经典，可以用一个类比理解：

• 平台超管类似于购物中心的运营方，负责整个 mall 的物业、水电、门店入驻。
• 租户管理员类似于某家店的店长，负责店内员工、货品、活动。
• 普通用户类似于店里的员工，只能在自己的岗位权限里做事。

一张流程图能把三者的关系画清楚：

flowchart TD
    SA[平台超管] -->|创建租户/开通订单| T1[租户 A]
    SA -->|创建租户/开通订单| T2[租户 B]
    T1 -->|分配角色| U1[租户 A 管理员]
    T1 -->|分配角色| U2[租户 A 普通用户]
    T2 -->|分配角色| U3[租户 B 管理员]
    U1 -.查看/编辑.-> KB1[租户 A 知识库]
    U2 -.只读.-> KB1
    U3 -.查看/编辑.-> KB2[租户 B 知识库]
    KB1 -.严格隔离.-> KB2

这里有几个关键的设计点：

• 平台超管不应该默认可以直接读取任一租户的业务数据。超管的权限应集中在租户生命周期管理，而不是内容层面。真的需要看数据时，走一次显式的"授权审计"流程，留痕。
• 租户管理员只能在自己租户内行使权限，无法跨租户操作。
• 普通用户由租户管理员分配的角色决定权限颗粒度，例如可创作但不可发布、可查看但不可下载等。

三级模型的价值不在于"层数多"，而在于把不同的责任交给不同的人，防止一个账号权限过大导致的连锁风险。

4、订单开通与租户生命周期

在 SaaS 模式下，租户通常和"订单"绑定。购买套餐 → 后台生成订单 → 订单开通 → 创建对应租户 → 分配初始管理员账号 → 通知客户登录，这一整套流程需要打通。到期后还有续费提醒、账号暂停、数据归档、彻底删除几种状态。

订单生命周期的一个简化状态机大致长这样：

待支付 → 已支付 → 生效中 → 到期提醒 → 续费成功 / 冻结 → 归档 / 删除

对开发者来讲，实现租户生命周期时需要注意几件事：一是冻结不等于删除，冻结期租户账号无法登录但数据保留，方便续费恢复；二是删除要走软删除+延迟物理删除，给用户留数据取回窗口；三是所有操作都要审计日志，尤其是"冻结/删除/恢复"这类高风险动作。

5、多租户下的资源配额与隔离

除了数据隔离，SaaS 多租户还有一个经常被忽略的话题：资源配额。如果不做限制，一个大客户就可能把整个平台的向量数据库、AI 生成额度、存储空间吃干净，其他租户直接卡死。

常见的配额维度包括：

• 每个租户可创建的知识库数量、总大小上限。
• 每天可发起的 AI 内容生成次数、可消耗的 token 上限。
• 可发起的分发任务并发数。
• 可创建的普通用户账号数量。
• 存储空间（原始文档、生成图片、生成视频）大小。

配额可以做成"套餐决定+人工调整"的组合模式。基础套餐给一个默认值，客户提额时由超管手动调整。这种设计能让平台在成本和体验之间有比较灵活的操作空间。

多租户这一节讲到这里，本身它是个大话题，把重要的思路和坑点讲清楚就够用了。下一章我们进到具体的功能模块拆解，看看这套系统里每一块到底在做什么、原理是什么、可以怎么用。

六、把 Deep-GEO-SaaS 的核心功能模块一个个拆开讲

上一章讲底盘，这一章讲上层的具体能力。Deep-GEO-SaaS 描述里罗列了六大块能力，莫潇羽把每一块结合原理都过一遍，读完这一章你就能建立起完整的产品心理模型。

1、AI 可见度诊断模块：先"体检"再动手

诊断模块的核心，是给企业算一个 GEO 现状分数。它的做法通常是：接入品牌关键词、竞品清单、目标问题清单，然后批量向多个大模型发起问题，把答案抓回来做结构化分析，形成一份对比报告。

以下是这类模块的一个简化工作流：

sequenceDiagram
    participant U as 用户提交诊断任务
    participant S as 诊断调度器
    participant M as 大模型集群
    participant A as 结果分析器
    participant R as 报告生成器
    U->>S: 品牌名 + 竞品 + 关键问题清单
    S->>M: 循环调用豆包/DeepSeek/Kimi/文心一言/通义千问
    M-->>S: 返回各模型答案
    S->>A: 提取品牌提及、语义位置、语气倾向
    A->>R: 计算提及率、位次、准确率
    R-->>U: 输出可视化报告

诊断结果通常呈现为几张图表：品牌提及率随时间的走势、多模型对比雷达图、竞品声量对比条形图、答案中出现的典型描述词云。这份报告不仅让企业老板一眼看到问题，也为后续优化提供方向。

有几个使用诊断模块的经验点：

• 问题清单最好覆盖三类：信息型问题（"XX 是什么"）、选型问题（"XX 品牌有哪些值得推荐"）、对比问题（"A 品牌和 B 品牌哪个更好"）。这三类问题合在一起最能反映品牌在 AI 场景下的真实曝光。
• 至少覆盖 20 到 50 道题，样本少了统计意义不足。
• 每次诊断的问题清单要保持稳定，方便前后对比。改题目就等于换尺子，数据没法纵向看。

2、企业统一知识库：整个平台的地基

如果说整套系统里最重要的一块是什么，我会毫不犹豫选知识库。它是所有其他模块的事实源。

一个成熟的企业 GEO 知识库通常按主题分层：

知识库背后的技术形态一般是"结构化数据库 + 向量数据库"的双库结构。结构化库负责保留原始的字段信息（例如产品参数），向量库负责给文本段落建索引，供语义检索。文档进库时通常要经过下面这条链路：

flowchart LR
    A[原始文档 PDF/Word/网页] --> B[文本抽取]
    B --> C[清洗与去噪]
    C --> D[分块 Chunking]
    D --> E[向量化 Embedding]
    E --> F[写入向量库]
    C --> G[结构化字段抽取]
    G --> H[写入业务数据库]

其中"分块"是个技术活。块太大 AI 检索时噪声多、context 塞不下；块太小又会切断上下文，语义丢失。行业里常用的做法是按段落切、按标题切、按 token 数切、或者做递归切块。莫潇羽的经验是：产品参数类文档偏向按字段切，长文类文档偏向按标题+段落切。

一个常见的坑是：向量化用的 embedding 模型和后续检索时用的模型必须保持一致。中途换模型的话，全库要重新向量化一遍，否则检索精度会崩。这一点部署时务必留意。

3、AI 内容生产模块：从知识库出发的合规创作

内容生产模块的核心逻辑是"以知识库为唯一事实源"。它的工作流大致是：

• 用户输入创作意图（例如"写一篇关于我们新产品 XXX 的 GEO 长文"）；
• 系统在知识库里检索该产品相关的所有片段；
• 把片段作为参考资料，配合创作模板（长文、短视频脚本、问答对）交给大模型生成；
• 生成结果回写到"待审核"队列，等待人工审校；
• 审校通过后进入分发队列。

这里插一段伪代码看得更清楚：

def generate_geo_article(topic, tenant_id, llm, kb):
    # 1. 在租户自己的知识库里