替换运营用的 Airtable. 把一条工作流迁出 Airtable，发生在这个 base 不再是团队使用的工具、而变成了团队要跟它较劲的数据库的时候。判断标准不是用了多久，而是那一天：有人为了跑出一份 base 做不出的报表而导出到表格，或者某个自动化悄悄失败、一整周没人发现。替换它，意味着保留 Airtable 还擅长的部分，只重建那部分已经长得超出它能力的工作流。
你有这个 base，它在真实运转你运营中的一部分。它同时也出现了一年前没有的三件事：加载变慢，你在为那些只打开一个视图的人按席位付费，每个月都有人把数据导出到表格里，因为你真正需要的报表在 Airtable 里根本做不出来。base 没有坏，它只是长得超出了这个工具的能力。
#我怎么判断该迁出 Airtable 了？
没有哪个记录数能一锤定音。我们看四个信号：数据为了完成真正的工作，多常要离开 base；付费席位里有多少是纯查看；过去一个季度有多少自动化悄悄失败过；新人要花多久才敢相信这些数字。这四个里有三个在往坏的方向走，base 就已经从工具变成了瓶颈。
我该替换 Airtable，还是它依然是对的工具？
当只有少数几个人在编辑结构化记录、报表在它的视图里就能搞定时，Airtable 是对的工具。当数据要经常离开它才能派上用场、只读查看者撑起了你的席位账单、或者自动化失败了没人发现时，它就成了错的工具。最诚实的判断标准是真正的工作发生在哪里。如果发生在导出文件和旁边的表格里，那这个 base 就是套着应用外壳的数据库，也就是该把它撑不住的那条工作流迁出去的时候了。
替换它具体是什么样子？
我们为一个 40 人的活动运营团队做过这件事，他们的供应商预订 base 已经长到 9 张关联表、30 个自动化，其中一半是坏的。我们没有把所有东西都重建一遍，只把正在往表格里泄漏的两条工作流——供应商审批和每周产能报表——迁到了一个带真正校验、能自己跑报表的小型内部应用里。其余部分留在 Airtable 里，它们照样能用。他们的席位账单降了下来，因为原来那 18 个纯查看的人，现在看的是仪表盘，而不是占着一个 base 席位。
这不就是把它重建成一套定制软件吗？
we are
我们界定出那一两条已经超出 base 能力的工作流，只把它们重建成一个小型内部应用，附带 Airtable 给不了你的校验和报表，其余部分原封不动留在 base 里。
we aren't
我们不是那种花两个季度、把一个能用的 base 换成一张白纸的定制软件重建，也不是又一个只是给已经到极限的同一套数据模型换个皮的无代码工具。
代价高昂的误判，是把“Airtable 撑不住了”读成“我们要把所有东西都重建一遍”。base 里大部分都没问题，出问题的只是一两条工作流：往表格里泄漏的那些，和自动化会失败的那些。只重建这些，其余保留，你花的是几周，而不是几个季度。AI 在这里改变了算法，因为过去需要一整个开发团队才能写出的、范围明确的内部工具，现在是一个小得多的项目。
我们迁走什么，留下什么
- 留下：由少数几个人手动编辑的结构化记录，Airtable 的视图本身就是报表。这正是 Airtable 该干的事。
- 迁走：任何需要经常导出到表格才能用起来的工作流。这个导出动作本身，就是 base 干不了这活的信号。
- 迁走：每周都要手动重建一遍的报表。一个小应用按计划自动跑出来，没人再需要重复搭同一个数据透视表。
- 迁走：按席位收费的纯查看权限。一个只读仪表盘比 base 席位便宜，而且只展示大家需要看的内容。
问题从来都不是要不要用 Airtable，而是哪两条工作流正悄悄吃掉你一周一天的时间，以及这两条是否值得动真格地重建。通常答案是值得，而 base 的其余部分都没问题。
这种界定正是我们咨询业务在做的事：找出那一两条值得迁出 Airtable 的工作流，用 base 撑不住的校验和报表重建它们，其余还能用的部分原封不动留着。如果你的 base 已经开始往表格里泄漏，预约一次 30 分钟摸底通话，把它带来。我们会告诉你哪些部分该留着，哪两条值得动真格地重建。