前两天在翻 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 面板里然后点击左下角的“{}”格式化按钮等代码重新排版。第四步格式化之后再用关键词搜一遍这次就能看到完整的配置对象了。如果文件太大搜索卡顿可以在格式化后的代码里用 CtrlF 输入 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 里执行一行代码列出当前页面加载过的所有脚本 URLwindow.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 配置不算什么高深的东西但沿着它往深处走你看到的不只是四个套餐而是一整套关于用户分层、额度控制和商业转化的思考方式。保持好奇可以但记得守住合规边界——看配置、学思路、别伸手。前端代码是产品向你敞开的一扇展示窗但也仅此而已。