企业知识库定价模型：席位费 vs 站点费 vs 流量配额对照清单
企业知识库定价模型，是厂商按「谁付钱、按什么扩」来组织账单的方式，常见形态包括席位费（每个可登录协作者或客服代理）、站点或项目费（每个已发布文档站 / 知识库），以及按流量、文档数、AI 额度等资源配额计费。选型时真正决定总拥有成本的，往往不是首页单价，而是读者是否占席位、公开发布站点如何加价，以及 AI 用量是否另算。本文对照 Confluence、飞书、Zendesk 等席位型方案，GitBook、ReadMe、Mintlify 等站点或项目型 Docs，以及 Baklib 以组织订阅叠加文档、流量与成员配额的公开价目，给出一份可执行采购清单。
浏览 9
巴克励步
导语：先问「谁付钱」，再比「多少钱」
企业知识库定价模型，是厂商按「谁付钱、按什么扩」来组织账单的方式。常见的有三类：按可登录协作者或客服代理收取的席位费，按已发布文档站或知识库项目收取的站点 / 项目费，以及按流量、文档数、AI 额度等资源用量收取的配额费。很多团队在对比 Wiki、Docs 与帮助中心时，会先盯首页上的「每人每月多少钱」；真正拉开总拥有成本的，通常是另外三个问题——读者要不要付费、多站点会不会叠价、AI 是含在套餐里还是按次扣额度。
这和昨日讨论的协作 Wiki 与可发布企业 Wiki 选型不是同一件事。那篇文章回答「该不该用 Confluence / 语雀 / 飞书知识库同时承担正式发布」；本文只谈账单几何形状：同一份产品手册、内部 Wiki 或客户帮助中心，在不同计费方式下会怎样变贵。它也不重复 Wiki-first vs Search-first 里对权限可验与 Rovo credits 的讨论，只把「目录价」和「用量价」分开，避免把两套机制加总成一个含混的「AI 很贵」。更完整的产品定位见支柱文 Baklib Wiki 是什么。
为什么现在要谈：2026 年叠在一起的四条公开信号
第一，席位型协作 Wiki 的目录价本身在动。Atlassian 宣布自 2026 年 10 月 13 日 PT 起，更新包括 Confluence 在内的 Cloud Standard / Premium / Enterprise 等订阅目录价，影响新购、续费与升级；该日之前生成的报价在有效期内仍按旧价执行。官方同时写明：这次上调针对的是订阅目录价，与按用量计费（usage-based pricing，如 Rovo credits、Automation steps 等额度）是两套机制——套餐已含一定额度，超出部分需账单管理员显式开通才会计费。见 Future Cloud list pricing。Confluence Cloud 的月付采用累进式按用户计价（不同席位区间单价不同），年付则按固定用户档计价；官方还实行 Maximum Quantity Billing：月度账单按计费周期内分配过的最高席位数计算，周期中途减人不会降低当月账单。见 Confluence Licensing。
第二，发布型 Docs 把「站点」和「写作成员」拆开卖，并明确不按浏览量设上限。GitBook 公开定价把总价写成：每个已发布站点的套餐费，加上按用户收取的成员费；年付时 Essential 为每站点每月 65 美元、Ultimate 为每站点每月 249 美元，另加每用户每月 12 美元；月付则分别为 79 美元、299 美元和每用户 15 美元。对照表写明：所有套餐均不限制已发布文档的 page views。见 GitBook Pricing、GitBook Plans。
第三，帮助中心常常不再是独立 SKU，而是客服套件里的一项能力。Zendesk 公开定价页把定价结构概括为主要以座席（agent）按月计费，并可用量、附加组件叠加上去。Support Team 年付为每座席每月 19 美元，定位于核心工单；Suite Team 年付为每座席每月 55 美元，能力清单里写有 Knowledge Base；Suite Professional 年付为每座席每月 115 美元。FAQ 说明 Suite 是包含工单、消息、在线聊天、help center 与语音的一站式方案。功能对照表还列出：Suite Team 可支持 1 个帮助中心，Suite Professional 最多 5 个。见 Zendesk Pricing。
第四，一部分知识库厂商不再公布统一目录价。Document360 定价页改成问卷加报价，FAQ 写明不展示统一单价，以免小团队被高套餐误伤、大客户被低估；影响报价的六件事是：团队账号（编辑与审核者）、工作区、语言、SSO 与安全需求、知识库隐私模型（公开、私有或混合），以及 AI Premium Suite 用量。见 Document360 Pricing。
把这四条放在一起，采购问题就从「哪家首页更便宜」变成：你要为写的人付钱、为读的人付钱，还是为发布出去的站点与流量付钱。
三种主流模型，加一种「套件捆绑」
下表是定性对照，数字只在后文引用已核验的公开价目；具体账单仍以厂商计算器或商务报价为准。
| 模型 | 计费对象 | 扩张时账单怎么变 | 公开目录上的典型例子 |
|---|---|---|---|
| 席位费 | 可登录的协作者、组织成员或客服座席 | 全员进 Wiki，或客服座席增加时，费用近似线性上升 | Confluence Cloud；飞书商业版（知识库作为套件能力）；Zendesk Suite |
| 站点 / 项目费 | 已发布的文档站或知识库项目 | 多品牌、多手册站、多帮助中心时上升；匿名读者通常不占席位 | GitBook（站点 + 成员）；ReadMe（按 project） |
| 资源配额 | 文档数、流量、存储、AI Token、注册访客等 | 对外访问强度和内容规模上升时加购或升级 | Baklib 公开套餐（组织年费 + 配额） |
| 配置报价 | 工作区、语言、隐私模型、SSO、AI 附加 | 无统一目录价，需按配置询价 | Document360 |
还有一种容易被忽略的形态：编辑席位先封顶，再在付费档放开。Mintlify 的 Starter 对最多 5 个 editor seats 永久免费；Pro 年付为每月 450 美元（月付 540 美元），编辑席位不限，并含每月 10,000 credits，AI 能力按 credits 计费。见 Mintlify Pricing。它不是「每个公开站点单独标价」，但写作人数越过免费档后，账单形状会突然从「零」跳到「固定档 + 额度」。
飞书定价页 则把知识库与即时消息、云文档、视频会议等并列在同一套工作平台里，而不是单独 SKU：免费版支持 100 用户；商业标准版 50 元/人/月、商业专业版 80 元/人/月、商业旗舰版 120 元/人/月，并注明所有版本需按年付费。AI 能力另有分层，知识问答需租户整体开通后才可使用。已经为办公套件付过席位的团队，继续用飞书知识库做内部沉淀，边际成本往往最低；若拿「知识库模块单价」去和独立 Wiki 比，就会把整套办公席位误算进去。
席位费：适合全员共创，不适合「全员只是读者」
席位模型的优点很清楚：权限、审计和组织架构可以跟账号走，财务也容易按人头做预算。Confluence Cloud 把自己的用户定义成「能登录你的某个 Confluence 站点、并存在于用户管理中的人」；月付按精确用户数、年付按最接近的用户档收费。官方给采购侧的降费建议也很直白：停用不再使用产品的不活跃用户，让他们不再计入月度账单。见 Confluence Licensing、Future Cloud list pricing。
它的风险同样清楚。如果企业 Wiki 的真实读者是全员，而真正写制度、写手册的人只有内容团队，席位费会把「打开页面看一眼」也变成订阅成本。协作套件里这通常可以接受——因为同一个席位还覆盖文档、会议或工单。一旦你的目标是对外产品手册或客户自助站点，再按「所有可能读到的人」买席位，形状就错了。
客服套件把这个问题推得更远。Zendesk 的 Knowledge Base 出现在 Suite Team 的能力清单中，帮助中心是 Suite 的一部分，而不是公开定价页上的独立知识库商品。Suite Professional 还把多帮助中心数量写成套餐上限（最多 5 个）。与此同时，AI agents 按成功的 Automated Resolutions 计费，超出套餐额度后另有承诺用量与按需单价。见 Zendesk Pricing。结论不是「Zendesk 不适合做知识库」，而是：如果你已经为客服座席付费，帮助中心往往是套件附带能力；如果你并不需要工单与通话，只为了知识库去买一套按座席计费的 Suite，通常不是正确的支出形状。
Atlassian 侧还要再拆一层：Cloud 目录价上调之后，Rovo credits 一类用量并不会自动被「吃进」新的席位单价里。官方把订阅目录价与 usage-based pricing 写成并行关系。见 Future Cloud list pricing。关于权限是否可验、过期内容会不会让 AI 胡说，请读 Wiki-first vs Search-first；本文只提醒采购：席位账单和额度账单要分两行看。
站点费与项目费：匿名读者免费，站点数量成为主变量
发布型 Docs 的默认假设，是「少数人写作、多数人阅读」。GitBook 把用户写成：被邀请进组织、通过变更请求和内容评审来协作的人。它同时把两种「读者」分开——组织内的 Reader 角色是受邀成员，所有套餐的 Reader 席位都要付费；访客（Guest）同样计入组织成员数，权限高低不影响成员单价。相反，公开文档站的访问者不需要邀请，也不占用付费席位，只能看到已发布内容。见 GitBook Roles、Site and member costs。一个带有多个 variants（例如多语言或多版本）的站点，在账单上仍计为一个已发布站点。见 Site and member costs。
这意味着：如果你要做一份面向全网的产品手册，GitBook 的主变量通常是「发布了几个付费站点」加上「有多少人登录 GitBook 协作」，而不是「这个月有多少人点开了文档」。官方对照表把 page views 写成各套餐均不限。见 GitBook Pricing。需要注意的另一面是：一旦你为每个产品线、每个区域、每个帮助中心都单独发布一个付费站点，站点费会叠得很快；GitBook 把 site sections 与 groups（把产品文档、开发者门户、帮助中心等收进同一站点）放在 Ultimate，也就是较高的那档站点费里。见 GitBook Plans。认证访问（authenticated access）同样从 Ultimate 起提供——登录后可见的客户手册，并不会因为「读者很多」就自动变成席位费，但会把你推到更高的站点档。
ReadMe 的公开文档把同一逻辑写成按 project 计费：Starter 每月 0 美元、含 1 个项目；Pro 每月 250 美元、仍含 1 个项目；Enterprise 为定制价格，可组合多个项目，并写明不限席位。见 ReadMe Plans and Pricing。和 GitBook 相比，它更强调「一个项目一份账单」；多站点、多品牌时要提前问清「几个项目算几个账单」，不要默认企业档会自动合并。
站点模型适合对外 Docs 与帮助中心，也更贴近 产品手册站的 llms.txt / GEO 所讨论的发布面：匿名可达的手册站不应按潜在读者人头收费。它不适合的情况是：组织希望全员在同一套协作空间里共创，却只愿意为「发布站点」付钱——写作权限、评审流和成员管理仍然会回到席位或成员费上。
流量与资源配额：按交付成本，而不是按人头
第三种模型问的是：知识被发布出去之后，平台实际消耗了什么。Baklib 的公开价格方案把 SaaS 写成组织年费加一组配额，而不是「每个读者一个席位」。对照表列出的年费为：开源社区版免费，个人版 600 元/年，企业基础版 2,800 元/年，企业标准版 6,800 元/年，企业高级版 12,800 元/年，企业定制版从 8 万元/License 起。配额随版本变化，包括文档数上限、存储、按年发放的流量（GB / TB）、每月 AI Tokens、注册访客（私有）和组织成员（后台）。FAQ 专门解释了为什么流量按 GB/TB 而不是按访问次数：同样一次访问，纯文本可能只有几十 KB，富媒体可能是数 MB；按流量更接近真实成本，且年总量可跨月使用，适合发布高峰和季节波动。见 Baklib 价格方案。
这对「一源多站」很重要。FAQ 写明：创建的应用站点越多，折扣定价就会越多；若需求是官网 + 博客 + 帮助中心，通常建议选企业标准版，因为它对多站点和对外访问更友好。流量加购为每年 500 元增加 500 GB（仅 Standard 及以上），文档数加购为每年 500 元增加 1,000 篇。见 Baklib 价格方案。换一种说法：Baklib 公开价目把「后台有多少人维护知识」和「有多少注册访客能登录看私有内容」分开，而不是要求每一位公开读者都成为付费成员。这与 知识库对外发布 的产品逻辑一致——知识库只有绑定应用站点后才形成对外 URL，看的是文档在各站点的输出引用，而不是只开一个临时公开链接。
Document360 走的是另一条「按配置报价」的路。它把 project 定义成一套完整知识库（可以公开或私有），每个项目可有自己的用户、自定义域名、品牌和（私有项目中的）readers；同时把 reader account 写成「你授权登录后阅读私有项目的人」，且只适用于私有知识库。见 Document360 Pricing。报价驱动因素里出现了工作区、语言和隐私模型，却没有把 page views 写成计费项——至少在当前公开 FAQ 里，流量不是它对外宣称的价格旋钮。选型时仍应在询价单上单独确认：私有读者、语言站点和 AI 附加会怎样进入合同。
配额模型的优点是：对外成功（更多人来读公开手册）不会立刻变成席位焦虑；缺点是：富媒体、高峰流量或 AI 问答用量会逼近配额，需要加购或升级。Baklib 也写了公平使用原则：若连续 3 个月资源占用长期接近配额峰值（大于 80%），可能协商优化方案。见 Baklib 价格方案。采购时应把「公开流量」「私有注册访客」和「后台组织成员」三行分开测算，而不是只看年费数字。
采购对照清单：把账单形状画进立项书
在短名单上对每一家问下面这些问题。能在公开定价页或询价单上得到书面答案的，才进入商务环节。
- 写的人和读的人是不是同一类账号？ 若大多数人只是读者，优先看站点 / 项目费或「组织成员 + 注册访客」分列的配额模型；若全员共创，席位费往往更顺。
- 公开站点的匿名访问者要不要付费？ GitBook 把 public docs reader 写成无需邀请、不占付费席位；组织内 Reader / Guest 则计入成员账单。见 GitBook Roles。
- 已发布站点或项目如何计数？ 多语言 variants 算一个站点还是多个？帮助中心、产品手册、内部 Wiki 是三个站点还是一个站点里的三个栏目？GitBook 把多 variant 计为一个站点，并把多 section 的产品中枢放在 Ultimate。见 Site and member costs、GitBook Plans。Zendesk 则把多帮助中心写成套餐上限。见 Zendesk Pricing。
- 流量有没有上限，单位是浏览次数还是 GB？ GitBook 公开写明不限制 page views；Baklib 按年流量配额并以 FAQ 说明选择 GB 的理由。见 GitBook Pricing、Baklib 价格方案。
- AI 是套餐内权益，还是另一张用量账单？ Atlassian 把目录价与 Rovo credits 等额度分开；GitBook 按站点赠送 AI credits，并可另购额度包；Mintlify 把 Assistant 等能力按 credits 计价（例如一次回答 25 credits）。见 Future Cloud list pricing、GitBook Pricing、Mintlify Pricing。
- 知识库是不是必须搭配工单、IM 或整套办公席位才能买到？ 飞书知识库随套件提供；Zendesk 帮助中心写在 Suite 说明里。见 飞书定价、Zendesk Pricing。
- 私有 / 登录可见的读者怎么计费？ 把「公开匿名读者」「登录客户」「内部员工」拆成三行。Document360 为私有项目单独定义了 reader account；Baklib 把注册访客（私有）写成配额项。见 Document360 Pricing、Baklib 价格方案。
- 一源多站会不会被收两次内容费？ 同一份产品说明要同时出现在内部 Wiki、客户帮助中心和对外手册时，应确认是「一份内容、多处引用」，还是「每多一个站点就复制一份配额」。Baklib 的发布叙事是知识库绑定多个应用站点后查看输出引用。见 知识库对外发布。
- 有没有公开目录价？ 没有统一标价并不等于更贵，但财务模型会从「可自行测算」变成「依赖报价时效」。Document360 已明确改走定制报价。见 Document360 Pricing。
- 减人和中途变更会不会当月仍全额计费？ Confluence Cloud 的 Maximum Quantity Billing 是一个必须写进合同备忘的例子。见 Confluence Licensing。
怎么选：把交付面映射到账单形状
按主诉求走四条路径，而不是先比首页单价：
-
全员内部共创 \n 目标是制度、会议纪要、项目空间和跨部门评论。继续用已在付费的协作套件（飞书、Confluence 等）通常最省事。验收标准是席位覆盖真实写作者与必须登录的读者，并定期停用空闲账号。这不是「不要可发布 Wiki」，而是不要为纯内网共创再买一套按站点计费的 Docs。
-
对外产品手册 / 开发者 Docs \n 目标是品牌化站点、匿名可达、SEO 与 AI 可引用。站点 / 项目费或「不按公开读者收席位」的配额模型更合适。上线验收应包括：公开 URL、站点数量如何计费、page views 或流量是否设限，以及 AI 额度是否会在文档被助手高频查询时突然放大。与 Docs AI 可见性 的清单一起看：被引用成功不该变成惩罚性账单。
-
客服帮助中心，且工单已在同一套件里 \n 若团队已经购买 Zendesk Suite，帮助中心是套件能力，优先用起来；此时再买第二套知识库，应该是为了品牌化多站点、一源多站或与工单解耦的发布面，而不是为了「再有一个文章编辑器」。注意套餐对帮助中心数量的上限。见 Zendesk Pricing。
-
内部 Wiki + 对外手册 + 客户登录库同时存在 \n 这是多数成长型 B2B 的稳态，也是 Baklib Wiki 所强调的知识资产发布、权限交付与一源多站。选型时应验证：同一知识能否绑定多个应用站点；站点 / 栏目 / 页面能否分别设公开、仅登录可见或授权可见；账单是按公开读者膨胀，还是按组织成员、私有访客和流量配额膨胀。见 Baklib Wiki、知识库对外发布、价格方案。
PoC 两周可以只做三件事：列出写作者、内部读者、登录客户和匿名访客四类人数；画出你需要的站点矩阵（内部 Wiki / 帮助中心 / 产品手册 / 多语言）；用各家公开定价页或询价单把「席位 / 站点 / 流量 / AI」四行填成表格。数字对不上的那一行，就是真正的风险，而不是编辑器好不好看。
收束：选对账单形状，再谈编辑器
企业知识库的采购争议，经常被说成「要不要替代 Confluence」或「哪家 AI 更聪明」。2026 年更值得先写进立项书的，是账单形状：席位费奖励你控制登录人数，站点费奖励你控制发布面数量，流量与配额奖励你把公开成功和平台成本对齐，套件捆绑则奖励你复用已经在付的办公或客服座席。Atlassian 在上调 Cloud 目录价时仍把用量额度单列，GitBook 把公开读者和成员席位拆开，Zendesk 把帮助中心放进 Suite，Document360 改为按配置报价，Baklib 则公开了一套「组织年费 + 文档 / 流量 / 成员配额、多站点享折扣」的价目。见 Future Cloud list pricing、GitBook Pricing、Zendesk Pricing、Document360 Pricing、Baklib 价格方案。
如果痛点是把已治理知识发布为品牌化 Wiki、帮助中心或产品手册，按站点与栏目交付权限，并在已发布知识上做 AI 检索，可以从 Baklib Wiki 与 知识库发布 验证发布链路，再用价格方案核对自己的站点矩阵会落在哪一档配额——它补充的是交付面和账单形状，而不是取代团队每天写作的协作入口。功能对照仍见昨日的可发布企业 Wiki 选型。
下一步建议：不要先问「每人每月多少钱」。先数清四类人、三到四个交付面，再决定你该为席位、站点还是流量付费。
### 先核对账单形状，再验证发布链路
若你要的是品牌化 Wiki / 帮助中心 / 产品手册、站点级权限交付，以及同一知识资产的一源多站分发，可以从 Baklib Wiki 验证「知识库绑定应用站点」的发布链路，并用公开价格方案核对自己的文档量、流量与成员配额。
[了解 Baklib Wiki](/app/wiki) · [查看知识库发布能力](/features/kb-publish) · [查看价格方案](/s/pricing/)
常见问题
席位费、站点费和流量配额有什么区别？
席位费按可登录协作者、组织成员或客服座席计费，人数增加时账单上升。站点或项目费按已发布的文档站 / 知识库计数，匿名读者通常不占席位。流量配额按平台实际传输的数据量（或偶见的浏览次数）计费，对外访问变热时需要加购或升级。三者可以叠加：许多产品是「站点费 + 写作成员费」，或「组织年费 + 流量 / 文档配额」。
GitBook 会向公开文档的读者收费吗？会按浏览量收费吗？
按官方角色说明，公开文档站的访问者不需要邀请，也不占用付费席位，只能看到已发布内容；被邀请进组织的 Reader 或 Guest 则计入成员账单，权限高低不影响成员单价。定价页对照表写明各套餐均不限制已发布文档的 page views。总价是站点套餐费加上按成员收取的费用。
Atlassian 上调 Cloud 目录价，和 Rovo credits 是一回事吗？
不是。Atlassian 写明 2026 年 10 月 13 日 PT 起的更新针对订阅目录价，与 usage-based pricing（如 Rovo credits、Automation steps 等额度）是两套机制。套餐已含一定额度，超出部分需账单管理员显式开通才会产生额外费用。具体单价请以官方定价表和账号账单为准。
Zendesk 的知识库是单独卖的吗？
当前公开定价页把 Knowledge Base 写在 Suite Team 的能力清单里，并在 FAQ 中说明 Suite 包含 help center。Support Team 定位于核心工单能力。Suite Team 可支持 1 个帮助中心，Suite Professional 最多 5 个。采购时应把它理解成客服套件里的能力，而不是默认能买到一个与座席完全解耦的独立知识库 SKU。
Baklib 多站点会不会按读者人头收费？流量为什么按 GB 计算？
Baklib 公开价目是组织年费加文档、存储、流量、AI Tokens、注册访客（私有）和组织成员（后台）等配额，而不是按公开读者收席位。FAQ 说明应用站点越多折扣越多，并解释按 GB/TB 而不是按访问次数，是因为纯文本与富媒体的单次访问成本差异很大。多站点（例如官网 + 博客 + 帮助中心）通常建议企业标准版。具体以价格方案页的现行对照表为准。
