基础篇:免费版到底包含什么

我花了五天时间，以真实用户的方式使用免费套餐，而不是按照定价页面描述的方式，并随手记录了过程中发生的一切。截个图就走人是找不出隐藏细节的——只有实际用上一整周、真正撞到限制墙才能。以下是这份记录。

周一，上午9:40——注册，无需信用卡

在写第一行代码之前我先检查的第一件事：是否要求绑定信用卡。没有。这种细节我平时通常会忽略，但一个在你还没构建任何东西之前就要索要付款信息的免费套餐，其实已经在告诉你它是怎么看待用户的，所以我记了一笔，然后开始正式动手构建。

我选了一个小型企业网站作为测试项目——没什么特别的，一个落地页、一个联系表单、一个博客板块。到10:15时，第一版就已经在免费子域名上线了。“构建”和“发布”之间没有付费墙拦着，而这恰恰是很多免费套餐悄悄变成演示版的地方。

周一，下午2:00——迭代循环，我预期会撞墙的地方

这是我最怀疑的部分。对任何智能体来说，第一次构建都很“便宜”——需求清晰、没有既有代码需要协调——所以平台很容易让第一次构建显得很大方，然后在第二次构建上悄悄让你付出代价。我特意针对这个循环下手：“把标题栏改成吸顶固定”“修复移动端导航”“做一次内容调整”，之后又追加了两次小修改。这几次改动实际触及的文件数，都比要求本身听起来要多——真实的修改往来向来如此。那天我没有撞到额度上限，但能感觉到它就在不远处——这个额度显然是按照这样一整个周期的用量来设计的，不是按五天设计的。

下午稍晚，我还检查了免费账户是否会为了省算力而跳过审查环节。没有——同样的代码检查、同样的安全检查、同样的功能验证，任何东西标记为完成前都一样要过。我特意去找这个捷径，因为如果我自己经营这家公司、面临利润压力，这正是我第一个会砍掉的东西——但它没被砍掉。

周二，上午11:00——推送第二个项目，看看后端限制在哪

我又启动了第二个想法，这次需要真正的后端——数据库、一个 API 接口，一整套。这正是我预期会遇到真正限制的地方，果然找到了：每个免费账户只能有一个带后端的线上服务应用。我试图在第一个之外再同时上线第二个带后端的应用，结果两个无法同时运行。

令我意外的是什么不会占用那个名额。那周晚些时候我构建了一个小型可下载工具——没有服务器，只是一个打包好的应用——发布时完全没问题，不会和已上线的后端抢名额。想清楚成本结构就明白了：一个托管后端无论有没有人访问都在持续运行、持续耗费成本；而一个静态或可安装的构建只是静静躺着的文件。只有持续运行的那种才会被限额。

周二下午4:30——尝试打破并发限制

启动了一个构建任务，结果中途让助手去做一件不相关的事。它进入了排队，而不是并行执行。大约90秒内挺烦人，之后就无所谓了——反正我当时也在看第一个构建的预览，所以"等第一个完成再开始下一个"本来就是我会做的选择。我能想象对于同时跑两条智能体流水线的团队来说这会更麻烦——比如一个页面在生成内容的同时，另一个构建智能体在重构另一个页面——但那是和我不同的使用模式。

周三——关于资料库，以及它为什么不是一个"试用功能"

周三花了一整天测试那些"积累型"的东西——知识库、参考图片、模板——在免费版上是否真的可用，还是只是为付费版设的噱头。结果没有被锁。到第三天，平台已经在复用我的品牌语调和参考截图，不需要我再重新解释，这正是知识层存在的意义：如果把它锁起来，免费用户就永远看不到产品的复利效应，那他们又怎么会为了继续使用一个从未给过他们价值的东西而付费呢。

我也测试了租户数据隔离是否在免费版上"打折"——比如隔离不完整、隔离检查排队更慢之类。结果没有，而且坦白说这在结构上根本做不到"打折"：隔离是二元的。后台任务和查询要么按租户完全隔开，要么没隔开，不存在打折八折卖的版本。在这一点上免费版和付费版得到的保证是一样的，我本来就这么假设，但想亲自验证而不是单凭信任。

周四——应用商店发布，我差点没试的那件事

我差点跳过这项测试，因为我本能地以为发布到应用商店一定是付费专享——大多数人都会这么想，而这是错的。我把周二那个小工具打包成可安装应用，平台端的发布流程和我预期付费账户应有的表现完全一致。唯一的阻力来自谷歌自己的开发者注册费，这和我使用的套餐毫无关系。这点值得明确说出来，因为我见过有人仅凭假设就给自己设下了根本不存在的限制。

周五——下次我会跳过什么

如果再做一次这项测试，我会跳过周二下午的并发探测——它不到两分钟就回答了问题，而我又多花了四十分钟试各种变体，结果全都证实了同一个结论。我还会把租户隔离检查提前到第一天而不是第三天，因为这是人们在把任何真实数据放到平台上之前就该知道的事实，而不是事后才知道。

我不会跳过的：周一的迭代循环测试。那是免费版最容易暴露出"这其实是个诱导付费的漏斗"真面目的地方，如果你正在判断这到底是个真实产品还是营销包装得更好的试用版，这项测试值得你自己花时间重新跑一遍。

所以：基于我实际遇到的阻碍，而不是我原本以为会遇到的阻碍，升级的理由其实就三个——站得住脚的理由。你的迭代额度已经被用尽不止一次，而不是每个人第一个月都会遇到的那一次——参见额度用尽时实际会发生什么，不会有任何损失，但反复出现的模式就是信号。你需要同时运行两个已上线的托管后端，这是免费版在结构上无法承载的需求，不是靠预算调整就能绕过的问题。或者你做的东西已经不再是测试，而是开始真正赚钱了，这时候一直贴着上限运行带来的是焦虑成本，不只是技术成本。

这周我一个都没碰到。我做了一个真实的网站和一个真实的可下载工具，都进行了迭代、都发布了，唯一碰到的墙正好就是条款里写明会存在的那道墙。