企业官网建设流程全解析

先说明一下这次“扒代码”的起因。最近 Grok 的讨论度一直很高，从 grok bot、grok build 到 Cursor 里捆的 grok 额度，几乎每天都能看到新话题。我本来只是习惯性地打开浏览器的开发者工具，想看看 Grok 前端到底怎么组织请求，结果在 JavaScript bundle 里翻到一组以xpass开头的订阅配置字段。顺着这个 ID 往下一挖，四档订阅的模型映射、上下文长度、调用次数上限全摆在面前。这篇文章就把我扒到的内容、判断逻辑和操作过程完整写出来，重点说清楚这四档订阅分别包含什么，以及哪些结论是从代码里实锤看到的，哪些是靠产品逻辑推断的。

1. 先给结论：XPass 到底是什么

1.1 从 bundle 里看到的 XPass 标识

先说清楚一个前提：XPass 不是一个公开的宣传名词，你在 Grok 的官网页面上大概率找不到这个词。它更像是前端代码里的一个内部代号，我是在主 bundle 的订阅模块里搜subscription和tier关键词时，看到一组以xpass_free、xpass_premium、xpass_premium_plus、xpass_team命名的枚举值。

// 示意结构：在格式化后的 bundle 中看到的订阅档位枚举 const SubscriptionTier = { FREE: 'xpass_free', PREMIUM: 'xpass_premium', PREMIUM_PLUS: 'xpass_premium_plus', TEAM: 'xpass_team' }; const XPassPlanConfig = { [SubscriptionTier.FREE]: { price: 0, contextWindow: 131072, model: 'grok-4-fast' }, [SubscriptionTier.PREMIUM]: { price: 8, contextWindow: 262144, model: 'grok-4-latest' }, [SubscriptionTier.PREMIUM_PLUS]: { price: 30, contextWindow: 1048576, model: 'grok-4-reasoning' }, [SubscriptionTier.TEAM]: { price: 30, billing: 'per_user_per_month', seats: 50 } };

这种内部代号很有意思，因为前端代码里的命名往往比官网营销文案更诚实。营销页面把免费档包装成“体验 Grok”，代码里直接写FREE；付费档也不会用花哨的名字，全部映射到具体的模型 key、上下文窗口和价格。所以想了解一个订阅产品到底给了什么、砍了什么，扒代码经常比看官网更快、更准。

1.2 四档订阅速览表

为了让你在往下读之前先有个整体概念，我把四档的关键差异整理成一张表。需要说明的是，价格字段来自代码配置与公开订阅页面的交叉验证，模型名和上下文长度是代码里明确出现的字段，但具体数值可能随版本调整。

这个四档结构和市面上主流 AI 订阅产品的分层逻辑高度一致：免费档做漏斗，中间档做转化，最高档做利润和口碑，Team 档做企业市场。接下来我会逐个档位拆开细讲，并且告诉你每一档的结论是来自代码的哪个字段、哪段映射逻辑。

2. 为什么前端代码会“藏”这些信息

2.1 浏览器必须把代码交给你，这是物理层面的必然

很多人会问：一个做订阅的产品，为什么把价格、权益、限制这些都放在前端代码里？答案其实是无奈的。只要你是通过浏览器访问 Grok，浏览器就必须把 JavaScript、CSS、图片这些静态资源下载到本地才能运行。HTML 和 JS 不是加密传输的二进制程序，它们是要交给浏览器逐行解释执行的源码。

当然，团队可以做混淆（obfuscation），把变量名从subscriptionTier改成a1b2c3，把结构拆散、压缩成一行几兆的代码。但混淆只是提高阅读门槛，不是加密。任何稍微有耐心的开发者，把压缩的 bundle 格式化之后，再配合关键词检索，都能恢复出接近原始结构的代码。这就像把一本日记撕碎再揉乱，但没有烧掉——想拼回来只是时间问题。

2.2 Bundle 里最容易泄露商业信息的四个位置

在我看过的几十个前端项目里，订阅、价格、权益这类信息最容易出现在下面四个位置。你在扒任何产品的代码时，也可以优先检查这几个地方。

第一是枚举与常量定义区。订阅档位、角色类型、权益 key 通常会以枚举或 Object 常量形式集中定义，像我上面贴的SubscriptionTier就是一个典型。这类代码在压缩后依然保留字符串字面量，因为xpass_free这种字符串需要和服务器端保持一致，不能被混淆掉。第二是 UI 文案与条件渲染逻辑。页面上“升级到 Premium 解锁更多次数”这种提示背后，必然有if (tier === 'xpass_free')之类的分支判断，判断条件里就会暴露各个档位的名字和边界。第三是环境变量和构建配置。有些项目会直接把 Stripe 价格 ID、功能开关标识符打进 bundle 里，一旦发布到 CDN，任何人都能读。第四是 API 响应字段。登录之后，前端会拉取当前用户的订阅状态，Network 面板里返回的 JSON 会包含plan_type、access_until、entitlements之类的字段，信息量通常比 UI 上展示的大得多。

2.3 前端代码是“展示层真相”，但不是“全部真相”

这里必须强调一个边界：前端代码反映的是展示层的逻辑，它告诉你产品或营销想展示什么，不一定代表后端的最终裁决。举个例子，前端里写了xpass_free每天只能发 20 条消息，这个判断在页面上可能是这么写的：用户消息发出后，前端检查计数，超过 20 就弹出升级提示。但真正执行计数校验的还是后端 API。你把前端判断删掉、改掉都没有用，后端依然会返回 429 限流错误。

所以我的态度是：扒代码用来做产品分析、竞品调研、功能预测，非常有价值；但如果想靠改前端绕过付费限制，那就是另一回事了，既违反服务条款，技术上也不可能真正成功。这篇文章后面讲的实操方法，全部默认是合规的“只看不改”。

3. 逐档拆解：Free、Premium、Premium+、Team 各含什么

3.1 Free 档：做漏斗入口，而不是做慈善

Free 档的代码配置是最清晰的，因为它的功能边界很像一个“试用沙盒”。在我看到的 bundle 里，xpass_free对应的model字段指向是 Grok 的基础快速模型，上下文窗口约 128K。这个数值看起来不小，但和大档位一比就差出数量级了，说明免费用户被刻意控制在轻量使用场景。

从功能开关来看，免费档会保留最核心的对话能力、联网搜索、基于 X 平台实时信息的问答，但网页浏览、文件上传、图片生成这些吃资源的操作会被限制甚至关闭。代码里还会出现一组计数逻辑：每两小时能发多少条消息、每天能发多少条。这类“限额字段”通常以hourly_limit、daily_limit的形式出现，数值会根据灰度策略下发，不是固定的。

我给免费档的判断是：它存在的意义是让用户在没有付费门槛的情况下先体验到模型能力，尤其是 Grok 的实时信息整合和对话风格。一旦用户撞到次数上限，前端会把“升级到 Premium 提高限额”的入口放在尽可能显眼的位置。这是很标准的 SaaS 漏斗模型。

3.2 Premium 档：标准旗舰模型与更宽的使用通道

Premium 档是 xpass_premium，代码里的模型映射让我印象很深的点是它指向的标准旗舰模型，而不是免费档的快速版。也就是说，付费用户不只是“次数变多”，实际拿到的是更强的推理能力、更长的思考链和更好的复杂任务表现。上下文窗口从 128K 提到了 256K，可以塞进更长的文档、更长的对话历史。

功能开关上，Premium 会解锁文件上传，包括 PDF、Word、图片里的文字识别，图片生成额度也会显著提高。我看到 bundle 里还有一组“优先排队”的字段，比如priority_queue: true，这解释了为什么同样一个问题，付费用户感觉响应更快。另一个值得提的点是音频能力，语音输入输出相关的模块在 Premium 档是被启用的，免费档只能看到入口但无法真正调用。

价格方面，代码里出现过 8 这个数字，对应的是常见的月费换算。但这个价格在不少地区、很多促销场景下不一样，代码里也有 traceId、coupon_id 之类的组合逻辑，说明支付价格是动态的。实操建议是：别把代码里的price: 8当成铁律，它是参考值，真实价格以支付页为准。

3.3 Premium+ 档：完整模型、深度推理与超大上下文

Premium+ 是 xpass_premium_plus，也是整个 XPass 体系里最有含金量的一档。我从代码里看到的模型字段指向完整版旗舰模型，上下文窗口直接标到 1048576，也就是约 1M tokens。这个量级意味着你可以把一个几十万字的大型代码仓库打包进去让它分析，也可以把好几本书一起丢进去做跨章节的问答。

深度推理是这一档最明显的差异化能力。代码里有reasoning、think相关的开关字段，配合 API 层面传参可以拿到模型的完整思维链输出。这种模式天然适合数学、编程、逻辑推导这类需要长链路思考的任务。所以我说 Premium+ 的目标用户不是普通聊天用户，而是开发者、研究者、内容创作者。

还有一个很有意思的字段是 API 信用额度。xpass_premium_plus的配置里出现了api_credit之类的 key，说明订阅用户会拿到一定量的 API 调用额度，不需要单独再注册开发者账号充值才能调 API。这其实是把“应用订阅”和“开发者额度”做了个桥接。比如你在写代码时想在 Cursor 这类工具里用 Grok，而这个额度和 XPass 关联，订阅 Premium+ 后就能直接享受一定的 API 调用量。这对经常写代码的人来说，订阅的性价比比按量充值高出一截。

3.4 Team 档：按人头计价的团队协作方案

Team 档是 xpass_team，它的模型能力基本对齐 Premium+，但计费和组织方式完全不同。代码里我看到per_user_per_month的计费字段，还有一个限制数量的座位上限字段，说明按月按人头、设置成员上限是这个方案的基本形态。

团队场景下会多出三类功能字段：管理后台相关的权限、共享工作区、统一开票。管理后台意味着管理员可以查看成员的使用量、决定谁有权限访问哪个模型；共享工作区方便团队沉淀历史对话；统一开票则解决企业报销和合同问题。这些字段在个人档位里不会出现，但团队档位基本是标配。

价格参考是约 $30/用户/月，这其实是把 Premium+ 的单价拆成了团队批发价。从产品逻辑上讲，Team 档不是给个人用户准备的，它的心理门槛在企业采购：一个预算充足、需要多人使用、同时希望集中管控的团队。如果你是一个人用，没必要为了 Team 档多花钱，Premium+ 就已经拿满了模型权益。

3.5 从 xpass_free 到 xpass_team：一套完整的梯度设计

如果把四档连起来看，你会发现这套订阅体系的设计密度非常高。它同时做了三个维度的递进：模型维度，从快速基础版到标准旗舰版，再到完整旗舰版加持深度推理；上下文维度，从 128K 到 256K 再到 1M，跨度整整 8 倍；资源维度，从每两小时限次到优先排队，再到 API 信用额度，把不同类型的用户需求都切开了。

从商业逻辑上看，Free 档是漏斗入口，负责让用户“用起来”；Premium 档是主力现金流，承接大多数有付费意愿但预算有限的个人用户；Premium+ 档是利润和口碑双担，靠顶级体验留住重度用户，也为 API 额度这类新玩法埋下伏笔；Team 档则让用户的消费决策从“个人冲动消费”变成“企业采购行为”，续费率和客单价都更稳定。

3.6 XPass 和 API 额度、Cursor 里的 Grok 额度的区别

最近总看到有人在问 Cursor 里绑的 Grok 额度到底怎么回事，这里顺带把关系讲清楚。XPass 属于应用层订阅，针对的是 Grok 这个聊天产品本身，或者你在 X 站内、grok.com 里直接用模型时的权益。而 API 额度是开发者按量计费的模式，你在用代码写脚本、建自动化工作流、或者把模型接入第三方编辑器时，消耗的是 API 额度，两者计费体系和定价模型并不互通。

唯一的交叉点就是 Premium+ 档位里那个api_credit字段。它相当于买了最高档订阅，送你一定量的 API 调用额度。这就像办了某个平台的会员，送你好几张优惠券一样。但送完就没了，后续要调 API 还是得按量付费或者单独购买开发者套餐。所以如果你主要把 Grok 当编辑器里的模型用，看 XPass 的四档怎么分可能对你参考意义有限，更该关注的是 API 定价页上的每百万 token 单价；如果你大部分时间在 grok.com 或 X 里聊天提问，那 XPass 的四档就是你的决策核心。

4. 实操过程：我是怎么一步一步把 XPass 扒出来的

4.1 环境准备与合规边界

这个扒代码过程只需要一个浏览器，我用的 Chrome，其他基于 Chromium 的浏览器也行。在动手之前先把合规边界说清楚，免得踩线：只看你自己浏览器加载到的公开静态资源，不抓取其他用户的任何数据，不做爆破、不改请求、不绕过任何访问控制，全程“只看不改”。

下面这些操作，本质上和你在浏览器里右键查看网页源代码没有区别，只是查看的对象换成了 JS bundle 和网络响应。我不建议用外部爬虫去大规模抓取 Grok 的静态资源，原因有两个：一是大规模抓取很可能触发风控，影响正常浏览；二是静态资源是公开的，没必要冒着封号风险去做，浏览器 DevTools 已经够用了。

4.2 五步定位订阅配置的完整流程

第一步，打开目标站点。我是在 grok.com 和 X 平台两个入口都做了观察，因为两个入口加载的 bundle 略有差异，X 站内的代码里关于 XPass 的字段会更全一些。打开后先随便登录一个账号，订阅状态的请求需要登录态才会返回完整数据结构。

第二步，打开 DevTools 的 Sources 面板，用快捷键Ctrl+Shift+F做全局搜索。注意不是Ctrl+F，那个只在当前文件里搜；全局搜索会在所有已加载的资源里找关键词。我搜的第一组关键词是xpass、subscription、plan_type、tier，这四个词基本能覆盖订阅相关的绝大部分代码位置。

第三步，在搜索结果里定位主 bundle。Grok 的前端是典型的单页应用，所有逻辑打进了几个超大 JS 文件里。搜索结果会直接标明匹配项在哪个文件的哪一行，点进去之后浏览器会提示这个文件太大需要格式化。点一下左下角的{}按钮，压缩成一行的代码就会变成可阅读的缩进结构。

第四步，在格式化后的代码里继续筛选。这一步我推荐的做法是搜索到关键字段后，顺着对象的引用关系往下看。比如我先看到xpass_premium_plus，然后马上搜contextWindow，看哪个配置对象引用了它。你也可以用下面这段代码在 Console 面板里快速列出所有相关资源的 URL，确认当前页面加载了哪些 bundle 文件。

// 在 DevTools Console 中执行：列出当前页面加载的所有脚本资源 performance.getEntriesByType('resource') .filter(entry => entry.initiatorType === 'script') .map(entry => entry.name) .filter(url => /(grok|xpass|sub|plan)/i.test(url)) .forEach(url => console.log(url));

第五步，切到 Network 面板，把筛选框切到 Fetch/XHR，然后触发一次页面刷新。重点看/api/下有订阅相关语义的请求，比如路径里带有entitlement、subscription、plan的接口。点开响应内容，你会发现返回的 JSON 比页面 UI 上能看到的信息详细得多，通常会包含当前用户的 plan、到期时间、功能权限列表。

4.3 怎么判断扒到的信息是“实锤”还是“画饼”

扒前端代码最怕一件事：你看到的东西根本没上线，或者只是灰度测试废案。我有三个判断标准可以分享。

第一，看字段是否被渲染逻辑引用。如果xpass_premium_plus只出现在某处常量定义里，没有被任何条件渲染引用，那它可能只是预留字段；如果它出现在if (plan === 'xpass_premium_plus')这种判断里，说明它真实参与到功能开关和 UI 展示中，可信度立刻上升。

第二，看字段是否与公开页面交叉验证。我会把代码里读到的价格、上下文长度、模型名和官网订阅页面的表格做对照，两边能对应上的部分才算实锤，代码里有而官网没写的部分，我会单独标注成“推测”或者“未确认”。

第三，看代码版本和发布时间。bundle 文件名通常带着哈希值，比如index-3fa9c2.js，哈希变化代表发布过新版本。遇到新旧版本结论不一致的情况，以较新的为准，但也别急着丢弃旧结论，某些字段可能在旧版本里更完整。

4.4 一个现场案例：从字段到判断的完整链路

拿 Premium+ 档的 API 信用额度举个例子。我一开始在 UI 上完全找不到这个入口，只在代码里看到一个apiCredit字段被挂在某个 plan 配置下。继续追踪这个字段，发现它被一个remainingCredits模块引用，而remainingCredits又被个人信息页的某个组件引用。这就形成了一个链路：配置字段被业务模块引用，业务模块被页面组件引用，页面组件最终会渲染出来。

再配合 Network 面板，我能看到登录后前端会调一个接口拉取该用户的 entitlement 列表，响应 JSON 里就有api_credit_remaining这类 key。这个证据链基本坐实了：Premium+ 订阅用户确实会获得 API 调用额度，而且这个额度是后端下发、前端展示的，不是画饼。至于具体每个月送多少量，代码里只看到了变量名，没有明确的数值，那部分我写文章时就会标注为推测，让读者去官方文档确认。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

扒代码、分析订阅体系这事我做过很多次，下面这几个问题几乎是每次都会遇到的，整理成表格方便你对照排查。

5.2 实操踩过的坑

第一个坑是全局搜索时被 source map 干扰。Grok 的 bundle 在生产环境没有开 source map，所以没有这个问题，但很多站点会误留下.map文件，搜索时会把源码和 map 文件都匹配到，导致结果满天飞。Solution 很简单，在 Search 面板的过滤条件里加上文件类型限制，只看.js文件。

第二个坑是别把plan当成唯一关键词去搜。前端代码里tier、sku、entitlement、accessModel都可能是订阅系统的命名。我一开始只搜plan，漏掉了一大片与权限判定相关的代码，后来换成entitlement才找到完整的权益配置。建议你多关键词并行搜索，别单押一个。

第三个坑是本地保存 bundle 后再搜索。浏览器里打开 5MB 的格式化文件会很卡，我推荐的做法是先用Ctrl+S把 JS 文件保存到本地，用 VS Code 或 Sublime 打开，然后用编辑器的全文搜索功能处理。本地的搜索速度比浏览器快得多，还能配合正则表达式做更精细的匹配。

5.3 独家技巧：用正则快速筛选关键配置

最后分享一个我常用的正则技巧，专门用来从混乱的压缩代码里提取订阅方案相关的键名和映射关系。

# 以本地保存的 bundle.js 为例，提取 xpass 相关的标识符 grep -oE 'xpass[_a-zA-Z]*' bundle.js | sort | uniq -c | sort -rn # 提取所有计划配置对象名（通用 pattern） grep -oE '(plan|planConfig|tierConfig|subscription)[A-Za-z0-9_]*' bundle.js | sort -u

第一行命令会统计出xpass开头标识符的出现次数，出现次数越高说明这个配置被引用的位置越多，重要性越高。第二行命令会把所有和订阅配置相关的对象名列出来，方便你建立全局视图。这两个操作非常快，几秒出结果，比在浏览器里一页页翻高效太多。

另一个值得做的小操作是查看 localStorage。登录 Grok 之后，部分订阅状态会被缓存到本地存储里，打开 DevTools 的 Application 面板，点开 Local Storage 和 Session Storage，找plan、subscription、entitlement相关的 key。有时候这里的信息比 API 响应还直观，因为它是前端渲染时真正读取的数据源。

6. 一些实际操作后的体会

把 XPass 四档订阅的代码翻完，我自己最大的感受是：订阅体系的设计，本质上是把用户价值切成四份，再分别定价。Free 档卖的是体验门槛，Premium 档卖的是高频舒爽，Premium+ 档卖的是完整模型能力加推理深度，Team 档卖的是管理效率。以前看官网只觉得是四个价格的排列组合，这次从代码层面看，才发现每一档的模型映射、上下文窗口、资源权限都是精心扣过的，没有任何一档是随随便便定出来的。

最后再分享一个后续可以用得上的小技巧。订阅产品一般迭代很快，建议你把这次扒到的关键字段和对应 bundle 版本号一起记录在本地笔记里。下次看到 Git 风格或哈希序号不同的新 bundle，直接对比差异，就能第一时间知道产品改了哪一档、加了多少额度、是不是把某个模型从付费档下放到了免费档。这种“版本对比法”比每次都从头扒一遍高效得多，也是做竞品跟踪的一条长期可用的路子。