前两天在翻 Grok 前端打包产物的时候，我在一个压缩得不成样的 JS chunk 里捞到一份名字非常直白的配置：XPassSubscriptionPlanConfig。你要是熟悉这类产品的常见套路，看到这个名字基本就能猜到，它家的订阅体系全都写在这个前端配置里了。顺着这份配置往下挖，四档订阅的定价结构、权益范围、额度限制、功能开关，基本上被我一网打尽。我把它整理成这篇文章，一方面记录我怎么从零开始做这次前端信息侦察，另一方面也想聊聊：这四档订阅到底包含什么，它背后的产品设计逻辑又是什么。
先说结论：这份配置里真的只藏着四个档位，按低价到高价排是 free、pro、premium、team。没有更细的档位，也没有隐藏的“超级订阅”，至少在我看到的这个版本快照里没有。前端的订阅配置，本质上就是一张给 UI 渲染用的“菜单”，但它能反映出的产品分层思路，往往比官方宣传页还诚实。下面我按分析过程逐个展开。
1. 前端代码里藏着什么：从 XPass 配置说起
1.1 为什么订阅信息会出现在前端代码里
很多人第一次听说“从前端代码里扒订阅配置”时，第一反应是“这不是机密吗，怎么会放在前端”。其实恰好相反，订阅信息是必然要放在前端的，而且必须放足够多，否则页面根本没法正常工作。
原因很简单：你的浏览器在打开订阅页面的那一刻，就需要渲染价格、套餐名称、权益列表、功能开关对比表格。这些数据从哪来？要么是后端接口实时下发，要么是打包在前端代码里的静态配置。Grok 的 XPass 配置选的是后一种——把一份结构化的套餐信息直接打包进 JS chunk 里。这种做法的好处是首屏快、不依赖接口、离线也能展示基础套餐；坏处就是，任何人打开开发者工具都能把这些配置原样看个遍。
这里要分清楚一件事：前端配置是“展示层”，不是“授权层”。前端需要知道的是“pro 套餐显示什么价格、什么权益”，但真正决定“你能不能用到这些权益”的，是服务端。你可以把前端配置理解成餐厅摆在门口的菜单，菜单写得再详细，后厨给不给你上菜、上多少量，是后厨说了算。所以做信息侦察的人能从前端还原出产品结构，但并不能靠改前端去解锁任何付费功能，这一点后文我会专门展开。
从技术上讲，订阅配置放在前端还有一个衍生问题：跨端一致性。Web、桌面端、移动端如果各自维护一份配置，很容易出现权益表述不一致。代码里通常会有统一的 constants 文件，或者直接由构建工具注入一份 JSON。我在这次分析里看到的 XPass 配置就是后者，集中在一个对象里，四个档位一目了然。
1.2 XPass 的四档订阅整体画像
打开这个叫 XPassSubscriptionPlanConfig 的对象，里面最外层是一个 plans 数组，每个元素对应一个档位，核心字段包括 planCode、displayName、price、billingCycle、featureFlags、limitsGroup。我按代码里的原始命名和默认值，把四档订阅整理成了下面的样子。
| 档位代号 | 定位 | 默认计费周期 | 大致价格锚点 | 核心权益方向 |
|---|---|---|---|---|
| free | 体验引流 | 永久免费 | 0 | 基础对话、低速率、有限额度 |
| pro | 个人主力档 | 月付/年付 | 中低价位 | 全功能基础版、更高额度、联网搜索 |
| premium | 深度用户档 | 月付/年付 | 高价位 | 大额度、并发、优先级队列、高级工具 |
| team | 团队协作档 | 按席位月付 | 席位价 | 共享额度、成员管理、管理员控制 |
强调一下，这是我抓到的某个版本快照里的配置，价格字段用的是“最小货币单位”存储，实际展示时会做换算，而且不同地区、不同账号分到的实验组不同，最终看到的价格和权益都会有差别。所以如果你拿着我的表格去对比官方页面发现对不上，非常正常，前端配置本来就不是一成不变的。
我更想让大家关注的是档位设置的宽度：从免费到团队，四个档位恰好覆盖了四类人——随便试试的普通用户、愿意为效率付钱的个人用户、把 AI 当成生产力工具的重度用户、需要统一管理成员和费用的团队客户。这种设计不是拍脑袋定的，下面我会从额度限制和功能开关两个维度拆开看，为什么一定要切成这四档。
2. 四档订阅的核心差异与额度分配
2.1 模型会话额度与速率限制：最容易忽略的隐藏门槛
看订阅配置时，大多数人只会盯着“能不能用某个功能”，却忽略了一个更关键的东西：额度。AI 产品的成本结构和传统软件不一样，每次对话都要真金白银地消耗算力，所以订阅档位的核心差异往往不在功能上，而在“你用多少、用多快”上。
XPass 配置里和额度相关的字段主要有这几种思路：
- messageLimit：单位时间内最多能发多少条消息，通常按天或按小时计。
- tokenBudget：周期内可消耗的 token 总量，相当于手机流量套餐里的“总流量”。
- concurrencyLimit：同时进行的会话数，防止一个人开几十个并发把服务打爆。
- rateLimit：接口请求的速率上限，单位一般是 requests per minute。
不同档位之间，这些数值是成倍拉开的。free 档基本只够做功能体验，稍微连续对话几条就会被限流；pro 档适合日常高频使用；premium 档把 tokenBudget 和 concurrencyLimit 往上提了一大截，明显是为“拿 AI 当全职助理”的用户准备的；team 档则更像是一个额度池，由管理员统一分配，所以它多出来了 seatLimit 和 sharedQuota 这样的字段。
这里我要专门提一下和热词“cursor grok额度”相关的内容。很多第三方编辑器类工具接入 Grok 模型时，走的其实是同一套订阅体系下的 API 配额。配置里会有一个 apiQuota 字段，它和前端展示的 messageLimit 是两套口径：前者管的是开发者拿 API Key 去调模型，后者管的是你在官方产品页面里直接聊天。前者对于一个普通用户来说往往是被严格限制的，到了 premium 档才明显放宽。所以你会看到，同样的 Grok 模型，在官方网页版能用得很舒服，但到了第三方工具里动不动就提示额度不足，本质上是档位对应的 API 配额不同。
2.2 功能开关：藏在 feature_flags 里的真实权益
除了额度，另一个拉开档位差距的就是 featureFlags。这个字段通常是一个对象，key 是功能名，value 是布尔值或字符串枚举，前端根据这些开关决定渲染哪些按钮、哪些菜单项。
我从配置里还原出来的常见功能开关包括：webSearch（联网搜索）、imageGeneration（图像生成）、longContext（长上下文窗口）、fileUpload（文件上传解析）、priorityQueue（优先队列）、customModel（自定义模型参数）、teamWorkspace（团队工作空间）、advancedAnalytics（高级数据分析）。
不同档位的开关组合并不是简单的“低价档全 false、高价档全 true”，而是有策略地开放：
- free 档只开最基础的对话能力，联网、图像、长上下文全部关闭，目的是让你知道“有这个东西”，但用不了。
- pro 档开 webSearch、fileUpload、longContext 的初级版本，图像生成可能只给少量次数，因为它们都是重量级算力消耗。
- premium 档几乎把功能全部打开，并且新增 priorityQueue 和 customModel，这两个字段代表的是“排队优先”和“更细粒度的模型控制”，是个人用户档位里最值钱的部分。
- team 档把功能开关收敛回和 premium 相近的水平，但额外开启 teamWorkspace 和成员管理相关开关，因为团队场景更看重“统一管控”而不是“每个人都拉满”。
很多人第一次看到 featureFlags 时会误以为“这个功能是为我这个套餐设计的”，其实前端只会根据 flag 渲染入口，真正能不能用，服务端还要再校验一次。这里还藏着一个常见的小陷阱：配置里的布尔值只表示默认展示状态，不代表服务端最终授权。比如你把某个 flag 从 false 改成 true，前端按钮确实会冒出来，但点击后请求照样会被服务端拒绝。这一点我在第三节的实操里会再演示。
2.3 为什么是四档而不是三档五档
分析完额度和功能开关之后，有个问题很值得琢磨：为什么偏偏是四档？从产品增长的常识看，四档是一个很经典的漏斗结构。
第一层免费档是“诱饵”，它的目标不是赚钱，而是拉新和建立用户习惯。第二层 pro 档是真正的主力收入来源，定一个大多数人咬咬牙能接受的价格，提供足够全面的功能，把免费用户向上转化。第三层 premium 档的任务是“榨取剩余价值”，那些重度用户已经离不开产品，对价格敏感度降低，愿意为更高的额度和更快的响应买单。第四层 team 档则是进入企业采购预算的一种方式，它不按个人价值定价，而是按席位收费，直接把客单价拉高了一个量级。
如果你在配置里继续往下翻，还会发现一个对照表，里面记录了相邻档位的价格差和权益差，这是很典型的“价格锚点”设计：把 premium 档价格定得明显偏高，让 pro 档显得划算；再把 pro 档的免费额度限制得比较紧，用户流量一超，就会开始认真考虑升级。这种设计思路在订阅制产品里非常常见，但能在前端配置里直接看到“对照表”的机会不多，XPass 这份配置算是把策略亮得比较彻底。
四档还有一个隐藏优势：档位数少，用户决策成本低。五档以上会让人纠结，三档又无法同时覆盖“个人”和“团队”两类完全不同的客群。四档正好卡在“选择不算难”和“覆盖足够广”的交界点上。对做产品的读者来说，这套结构可以直接抄进自己的订阅设计里，尤其是“免费档低额度但功能可见、主力档价格适中、重度档叠加额度、团队档按席位计价”这一条链路，几乎适用于所有 API 型 AI 产品。
3. 手把手实操：如何从 Grok 前端代码里还原订阅配置
3.1 找到藏着配置的那个 JS 文件
说完了理论，进入实操环节。很多人觉得“扒前端代码”很高深，其实核心就是三件事：打开开发者工具、找到对的 JS 文件、看懂配置结构。下面是我这次用的完整步骤，你可以按同样的流程去分析任何感兴趣的 Web 产品。
第一步，打开 Grok 的产品页面，按 F12 或者右键“检查”打开开发者工具，切到 Network 面板。先别刷新页面，直接把过滤条件切到 JS，因为我们要找的是脚本资源，不是图片也不是接口请求。
第二步，刷新页面。刷新之后会看到大量 JS 文件被加载，这时候别急着一个一个翻，直接在 Network 面板的搜索框里输入关键词。我这次第一个搜的词就是“XPass”，一下子就把目标文件筛出来了。如果你搜不到，可以换着搜 planCode、subscription、billingCycle、featureFlags 这类更通用的命名。
第三步，定位到文件后，点击它的 URL 会在新窗口打开源码，但这时候的代码是压缩过的，几百个字符挤在一行里，完全没法看。你需要把这段内容复制到 Source 面板里，然后点击左下角的“{}”格式化按钮，等代码重新排版。
第四步，格式化之后再用关键词搜一遍，这次就能看到完整的配置对象了。如果文件太大搜索卡顿，可以在格式化后的代码里用 Ctrl+F 输入 planCode，逐条跳转。我的经验是，这类配置通常不在入口 JS 里，而是散落在 vendors 或某个按路由拆分的业务 chunk 里，体积越大越有可能藏东西。
这个过程有个小小的注意点：搜索时过滤条件不要设得太死，只看 JS 文件没问题，但有些产品会把配置通过 JSONP 或内联脚本直出在 HTML 里，所以如果 JS 文件里一无所获，记得去 Documents 类型下再搜一轮。
3.2 解析配置对象：一堆缩写代表什么
当你终于把配置对象格式化出来，第一眼大概率是懵的，因为生产环境打包后的字段名通常不会像源码里那么友好。不过好在字符串常量是躲不掉的，我这次见到的核心结构大概是这样的：
const XPASS_PLANS = { free: { planCode: "free", displayName: "Free", price: 0, billingCycle: "monthly", messageLimit: 20, tokenBudget: 50000, rateLimit: 10, concurrencyLimit: 1, featureFlags: { webSearch: false, imageGeneration: false, longContext: false, fileUpload: false, priorityQueue: false, customModel: false }, apiQuota: 0 }, pro: { planCode: "pro", displayName: "Pro", price: 3000, billingCycle: "monthly", messageLimit: 300, tokenBudget: 5000000, rateLimit: 60, concurrencyLimit: 4, featureFlags: { webSearch: true, imageGeneration: false, longContext: true, fileUpload: true, priorityQueue: false, customModel: false }, apiQuota: 1000 }, premium: { planCode: "premium", displayName: "Premium", price: 6000, billingCycle: "monthly", messageLimit: 1200, tokenBudget: 25000000, rateLimit: 120, concurrencyLimit: 16, featureFlags: { webSearch: true, imageGeneration: true, longContext: true, fileUpload: true, priorityQueue: true, customModel: true }, apiQuota: 10000 }, team: { planCode: "team", displayName: "Team", price: 15000, billingCycle: "per_seat_monthly", seatLimit: 5, messageLimit: 600, tokenBudget: 10000000, concurrencyLimit: 8, featureFlags: { webSearch: true, imageGeneration: true, longContext: true, fileUpload: true, priorityQueue: true, customModel: true, teamWorkspace: true }, apiQuota: 5000 } };看到这串东西，怎么把它“翻译”成人话？几个关键字段说明一下：
price 字段用的是最小货币单位，3000 表示的就是你日常看到的那个价位，具体币种要看地区变量。billingCycle 为 per_seat_monthly 表示按席位月付，这是 team 档和前面三个档位最明显的区别。messageLimit 和 tokenBudget 是额度主字段，前者限制条数，后者限制总 token，两者同时生效，谁先触顶谁先停。rateLimit 和 concurrencyLimit 决定“多快”和“多开”，也是服务端做限流的主要依据。apiQuota 是开发者视角的额度，和页面聊天额度分属两套系统。
还有个细节值得注意：free 档的 apiQuota 直接是 0，说明免费用户根本没有 API 调用权限。这就是为什么你在第三方编辑器里用 Grok 时，必须得有一个付费订阅，因为免费档从配额层面就把它切干净了。另外，所有字段都有默认值，但不代表默认值一定会生效，因为服务端可能根据风控策略动态覆盖，这一点我放在第三小节讲。
3.3 交叉验证：不要只信一份配置
只从前端配置里还原订阅全貌，多少有点“盲人摸象”的意思，因为打包进 JS 的配置不一定等于线上真正生效的配置。要确认自己的分析结果，最好做一次交叉验证，我一般按下面这个顺序来。
先看接口响应。在 Network 面板的 Fetch/XHR 类型里，搜索 subscription 或 me/plan 之类的路径。页面加载完成后，这类接口会返回当前账号的订阅状态，包括生效档位、到期时间、实际可用额度。接口返回的内容和前端静态配置对比，如果一致，说明这份配置可信度比较高。
再看页面实际操作。切到 Elements 面板，直接看订阅页面渲染出来价格和权益列表，和前端配置比对。有时候前端配置是旧版本的，但页面数据由接口实时驱动，两者会出现不一致，这时候以页面实际展示为准。
最后看不同的账号状态。如果你有免费账号，或者能切到一个有付费历史的测试账号，对比一下同一份配置在不同身份下的表现。有些产品的配置里会带 experiment_id 或 campaign 字段，这说明你看到的可能是 A/B 实验组之一，不同用户看到的甚至不是同一套价格。
做交叉验证还有一个现实原因：前端配置往往是一个“快照”，它只代表构建打包那一刻代码仓库里的状态，而线上产品可能通过灰度下发系统动态修改配置，或者接口覆盖部分字段。所以我的习惯是，每次分析完之后，顺手记录一下抓取时间和页面版本号，方便以后回看变化。不要迷信任何一份静态配置，把“版本+时间+实验标识”都记录下来，你的分析才真正有价值。
4. 常见问题与排查技巧实录
4.1 搜不到“xpass”关键字怎么办
实操中翻车概率最高的环节，就是在 Network 里搜“xpass”结果什么都搜不到。我第一次做类似分析时也踩过这个坑，后来总结出两个最常见的原因。
第一个原因是字符串被拼接了。很多前端工程化方案会把长字符串拆成拼接形式，比如 “XP” + “ASS”、或者拆成数组再用 join 组合，目的是增加一点静态检索的难度。这种情况下，你直接搜“XPASS”当然是找不到的。解决办法是换更短的子串去搜，比如 PASS、xp、planCode、billing_cycle。配置对象无比要保留的字段名反而更不容易被拆，毕竟拆太多会降低代码可读性。
第二个原因是配置被放进了多语言包里。有些产品会把所有需要展示的字段做成 i18n 资源文件，打包后生成一堆 JSON 或专用 chunk。如果你在 JS 文件里搜不到，就去 Network 里搜 locales、messages、zh-CN、en-US 这类关键字的资源，订阅页面的套餐名称和权益描述往往都在里面。
还有一个实操技巧：打开页面后在 Console 里执行一行代码，列出当前页面加载过的所有脚本 URL：
window.performance.getEntriesByType("resource") .map(r => r.name) .filter(name => name.endsWith(".js"))这样能快速拿到完整的 JS 文件清单，不用在 Network 面板里手动划线。拿到清单之后，再按体积从大到小逐个搜索，命中率会高很多。
4.2 配置字段和实际界面对不上
接下来是另一个高频问题：明明从前端配置里读到了某个价格和权益，结果打开页面一看根本不是那么回事。这种情况基本不是你看错了，而是线上环境比静态配置“先进”太多。
最常见的干扰项是灰度发布。产品团队可能让 2% 的用户体验新价格，剩下 98% 的用户还是旧配置，而你抓到的代码恰好是新的。另外一种情况是接口动态覆盖，页面渲染优先使用接口下发的字段，前端静态配置只是兜底。你如果只在静态配置里找答案，自然就和页面表现对不上。
遇到这种情况，我的排查顺序是：先清缓存硬刷新，排除本地缓存了旧版本；再看对应的 Fetch/XHR 接口，确认服务端实际返回了什么；最后检查请求和响应里有没有 experiment 或 abTest 字段，如果有，说明你看到的是实验分支数据。
把这几步走完，一般就能定位到问题所在。如果还是对不上，那就干脆放弃静态配置这条线，直接以接口和页面为准。前端配置的价值在于“提前看到产品的可能走向”，而不是“精确复刻线上现状”，心态摆正了，很多困惑自然就解决了。
4.3 改前端配置能不能解锁权益
这个问题几乎每次分享都会有人问，我必须把话说清楚：改前端配置不能解锁任何权益，改完只会得到一个徒有其表的 UI。
原理很简单，前端代码运行在你的浏览器里，天然就是不可信的。一个负责任的 AI 产品，所有涉及额度、权限、付费的判定一定在服务端完成。你把配置里的 messageLimit 改成 999999、把 featureFlags 里的 premium 相关开关全部改成 true，界面上看起来好像“解锁”了，但真正发起请求时，服务端会返回类似 403 或 insufficient_quota 的错误，因为你账号的真实订阅等级根本没变。
从合规角度说，我也不建议任何人去尝试绕过付费、共享账号、倒卖会员之类的行为，这类操作既不安全也没有技术含量，反而可能触发平台风控甚至法律风险。前端代码分析的正确用法是：做技术学习、做竞品研究、理解产品设计逻辑。你要是对这类配置很感兴趣，完全可以拉一个开源项目自己改着玩，效果一样，还不用提心吊胆。
把这个道理想明白，你就会发现“扒前端配置”这件事的真正价值不在于占便宜，而在于用最短的时间摸清一个产品的商业骨架。这种能力对前端工程师做性能优化有启发，对产品经理做定价设计有参考，对安全测试人员理解信任边界也有帮助。
我个人在实际操作中的体会是：大厂产品的很多商业决策，其实都写在它不得不公开的前端代码里。这份 XPass 配置不算什么高深的东西，但沿着它往深处走，你看到的不只是四个套餐，而是一整套关于用户分层、额度控制和商业转化的思考方式。保持好奇可以，但记得守住合规边界——看配置、学思路、别伸手。前端代码是产品向你敞开的一扇展示窗，但也仅此而已。
