免费版上限真正要解决的，不是“免费给多少功能”，而是如何让用户完成一次真实工作，同时在持续使用中撞上可感知的资源边界。把核心流程锁掉，产品会退化成演示品，用户还没形成工作习惯就离开；把存储、协作人数、自动化配额设得过宽，轻度用户会长期停在免费层。更稳妥的切分，是完整保留核心工作流，再把限制放在随使用强度增长的资源上。这样用户会因为撞上上限而升级，而不是因为功能被锁而流失。

这条线必须对齐真实使用分层，而不是先定一个看起来克制的数字。个人轻量场景里，单个项目数据量往往很低，自动化也很少触发；一旦工具进入正式工作，存储和流程配额会迅速被吃掉。一款面向小型团队的协作工具在内测中观察到：多数个人用户单个项目很少超过 2GB，正式使用后则很快升到 10GB 以上；自动化也呈现同样分层，轻度用户一个月用不了几次，重度用户几乎每天都要配置新流程。把免费存储、成员数和自动化条数卡在这两类强度之间，付费理由才会变得具体——升级是因为空间不够、人数不够、流程不够用。

上限是否过宽，往往比价格数字更值得先验证。当 2GB 对免费用户过于宽裕、迟迟不产生升级动力时，下调到 1.5GB，比降价或继续堆免费功能更有效。免费版此时也不是用来养用户，而是用来筛选真正需要该工具的人。停在免费层的人，常常不是付不起钱，而是需求尚未越过那条边界。设计免费上限，盯住的应是使用深度何时变化，而不是把额度当成获客补贴。