企业官网建设流程全解析

在无代码低代码平台持续洗牌的背景下，Airtable 被 Bending Spoons 以约 22 亿美元收购的消息，在技术社区引发了不少讨论。有人把它看作一次普通的资本交易，也有人担心产品会像 Evernote 那样经历涨价、裁员和体验收缩。无论最终走向如何，对于正在使用 Airtable 支撑业务系统的团队和个人开发者来说，理解这次收购背后的逻辑，提前做好数据备份、成本评估和技术选型预案，才是更有价值的动作。下面从收购背景、Airtable 的核心技术能力、开发者的实际应对方案三个维度展开。

1. 背景：Bending Spoons 收购 Airtable 始末

1.1 收购案概况

根据多家科技媒体的报道，Bending Spoons 正在收购 Airtable，交易价格大约为 22 亿美元。需要注意，不同报道对价格的表述略有出入，有的说是 20 亿美元，有的则提到 25 亿美元。整体来看，这笔交易对 Airtable 的估值大致在 20 亿到 25 亿美元区间。

Airtable 上一轮融资要追溯到 2022 年初的 F 轮，当时估值一度达到 110 亿美元。从巅峰估值 110 亿降到如今 20 多亿成交，落差确实明显。这种下跌背后的原因是多方面的：无代码赛道竞争加剧、SaaS 市场整体估值回调、Airtable 自身增速放缓，以及长期亏损带来的融资压力。

对 Bending Spoons 而言，这笔收购延续了它一贯的“收购成熟产品 + 集中化运营 + 重新商业化”的策略。它不是打算在 Airtable 原有赛道上正面竞争，而是看中了 Airtable 的客户基础、品牌认知和产品体系，希望以更低成本获得一个有现金流潜力的企业级产品。

1.2 Bending Spoons 的商业模式

Bending Spoons 成立于 2013 年，总部在意大利米兰，是一家以移动应用和 SaaS 产品为重心、极度重视内部集中资源的公司。它的名字经常出现在收购新闻里，因为过去几年它陆续收编了多个知名产品：

• Evernote：曾经印象笔记的母公司产品，被收购后用户价格结构发生了明显调整。
• Meetup：线下活动组织平台，被收购后开始强化订阅模式。
• WeTransfer：文件传输工具，在 2024 年被 Bending Spoons 收购。

Bending Spoons 的典型操作路径可以概括为三步。第一步，收购那些产品有一定用户量、但增长乏力或盈利能力不足的公司。第二步，大幅精简被收购公司的团队，把核心研发、增长、商业化工作收归内部统一处理，被收购团队的成员往往只保留很小一部分。第三步，通过数据分析、AI 能力和集中投放提升用户变现效率，例如调整订阅价格、增加付费墙、优化广告转化。

这套模式在 Evernote 上表现得很激进。收购后，Evernote 的价格体系调整明显，免费用户受到更多限制，付费用户的年费也随之上涨。数据迁移、产品支持、公司员工规模都发生了不小的变化。这种“压成本、抓变现”的思路，和传统 SaaS 公司“先做大用户规模、再追求利润”的打法明显不同。

1.3 为什么是 Airtable

Airtable 对 Bending Spoons 的吸引力主要来自三块：客户资产、数据壁垒和产品扩展空间。

从客户资产角度看，Airtable 过去十年积累了相当多的企业客户，很多团队把业务流程、库存管理、内容排期、需求跟踪都搬到了 Airtable 上。这些工作流一旦形成，替换成本并不低，因此客户留存具有天然粘性。

从数据壁垒角度看，Airtable 上沉淀的是用户真实的业务数据。虽然 Airtable 本身不是传统意义上的数据库，但对很多中小团队而言，它已经承担了业务数据库的角色。这种真实业务数据意味着用户可以持续付费，也让产品有了向上销售的空间。

从产品扩展空间看，Airtable 在 2023 年和 2024 年陆续强化了 AI 相关能力，包括自动生成公式、自动总结记录、内容分类等。Bending Spoons 对 AI 技术一直非常看重，收购后大概率会把 Airtable 的 AI 能力进一步产品化，同时把价格体系重新梳理。对开发者来说，最直接的感受可能是：套餐价格调整、免费额度收紧、API 调用限制变化、新增功能集中在更高付费档位。

2. Airtable 的技术能力与核心概念

2.1 Base：电子表格与数据库的结合

Airtable 最核心的单位是 Base。一个 Base 可以理解为一个独立数据库，里面可以包含多张 Table。每张 Table 又由 Field 和 Record 组成。这里的概念和传统数据库有对应关系，但不完全一致：

• Base 相当于 MySQL 里的一个 schema 或一个独立 database。
• Table 相当于数据表。
• Field 相当于列字段。
• Record 相当于一行数据。
• View 则类似数据库里的视图，但 Airtable 的 View 更强调可视化呈现。

举个例子，如果你要做一个项目管理系统，可以创建一个名为“项目管理”的 Base，里面包含“需求列表”“任务列表”“成员信息”三张 Table。需求列表和任务列表之间可以通过“查找引用”字段建立关联，任务分配时可以关联到成员信息表里的某个成员记录。

Airtable 与传统电子表格的最大差异在于字段类型。Airtable 的字段不只是文本和数字，还包括单选、多选、附件、日期、链接记录、公式、查找引用等。公式字段可以直接基于其他字段计算值，查找引用字段则可以跨表读取关联记录的信息。这种设计让用户可以用可视化的方式完成很多原本需要编写 SQL JOIN 才能实现的数据关联操作。

2.2 Field 与 View 的设计逻辑

Airtable 的 View 是整个产品最吸引人的部分之一。同一张表，可以通过不同视图从不同角度查看。例如，一张“任务表”既可以切到网格视图像电子表格一样编辑，也可以切到看板视图按照状态拖拽卡片，还可以切到日历视图按日期查看排期，或者用表单视图对外收集数据。

视图本质上是过滤、排序、分组条件的一种组合。视图不会改变数据本身，只改变数据呈现方式。这种“数据与视图分离”的设计，让非技术人员也能灵活组织信息，同时不会破坏底层数据结构。

对开发者来说，理解 Field 和 View 的另一个意义在于 API 操作。Airtable 的 API 以 Base 和 Table 为操作对象，一条记录的字段值就是 API 返回的 JSON 对象中的字段映射。字段类型、字段名称、字段选项会直接影响 API 请求参数，例如单选字段的选项值、日期字段的时区格式、附件字段的 URL 列表，都需要在实际开发中单独处理。

2.3 Automation 与 API

Airtable 的自动化能力（Automation）可以理解为内置的轻量级工作流引擎。它支持触发器、条件和操作三个层次。常见触发器包括“记录创建时”“记录字段更新时”“定时执行”，操作则包括“发送邮件”“创建记录”“调用 Webhook”“发送 Slack 消息”等。

Automation 的意义在于减少重复操作，但它的能力边界也比较清楚。复杂业务逻辑、长事务处理、大量并发写入，都不适合放在 Airtable Automation 里。更合理的做法是把 Airtable 作为业务数据管理界面，把复杂的后台逻辑放到自建服务中，通过 Airtable Web API 与数据进行对接。

Airtable API 是一个标准的 REST API。官方推荐使用 Personal Access Token 或 OAuth 2.0 进行鉴权。每次请求需要在请求头中携带Authorization: Bearer <token>。API 请求路径一般是：

GET https://api.airtable.com/v0/{baseId}/{tableName}

Airtable API 默认单页最多返回 100 条记录，超出部分需要通过offset字段进行翻页。这个设计很像很多云数据库的分页机制，实际开发时需要使用循环不断拉取，直到没有 offset 返回为止。

3. 收购对开发者的影响

3.1 定价与商业模式变化

对现有 Airtable 用户来说，最现实的影响是价格和套餐结构。虽然目前没有公开消息确认 Airtable 会立刻执行类似 Evernote 那么大幅度涨价，但参考 Bending Spoons 的历史操作，对价格体系做调整几乎是必然的。

潜在的变化方向包括：免费版可用的 Base 数量减少、单条记录数或字段数进一步受限、自动化运行次数耗尽后必须升档、AI 功能改为独立付费、API 调用频率纳入计费维度等。

对个人开发者而言，原来“免费版 + 低规模 API 调用”够用的模式可能会受影响。如果免费额度持续压缩，开发者的使用成本会迅速上升。团队用户需要重点评估年度预算，尤其当业务已经深度依赖 Airtable 的自动化、界面扩展和大量 API 集成时，迁移成本早已不是一个小数字。

建议现在就开始做一件事：梳理当前账号绑定了哪些 Base、哪些自动化在运行、每个月 API 调用量大约是多少。没有这份数据，后续做成本评估时只能凭感觉，很容易低估风险。

3.2 API 与生态的潜在变化

Bending Spoons 对待产品的整体思路是“集中化、统一化、商业化”，这可能导致 Airtable 的开放平台策略在未来发生调整。

Airtable 目前有比较成熟的 API、Extension（扩展）、Marketplace（应用市场）和第三方集成体系。开发者可以基于 Airtable API 构建外部应用，也可以通过扩展机制在 Airtable 内部增加自定义能力。收购之后，这些生态设施可能面临三种情况：

一是生态开放程度收紧。新团队更关注核心付费功能，可能会减少对第三方扩展市场的投入，或者提高上架门槛。

二是 API 策略调整。例如调用配额调整、部分接口从免费移到付费档、对高用量客户提出企业签约要求。

三是功能更新节奏变化。新的产品决策会更直接地服务于收入目标，一些面向长期创新、短期难变现的功能可能被搁置。

开发者在技术选型时，不能把产品策略的稳定性视为理所当然。如果业务核心链路依赖 Airtable API，必须提前制定降级方案，例如在 API 调用失败时记录重试消息、在本地缓存关键数据、在迁移时保证数据可直接导出。

3.3 数据安全与长期风险

数据安全是所有 SaaS 用户绕不开的话题。收购完成后，被收购产品的数据安全策略、数据处理协议、服务器区域、访问权限体系都可能发生变化。如果团队所在行业对数据合规有严格要求，例如金融、医疗、政务或者大型企业内控，那么使用海外 SaaS 存储业务数据本身就需要做合规评估，收购带来的不确定性会让评估更加复杂。

即使不看法律合规，只看工程层面也存在风险。产品价格上调、功能权限调整、API 策略变化，任何一个环节出问题，都可能让线上业务短时间内失去依赖。对个人项目影响可能不大，但对企业客户而言，这种“平台级单点依赖”是实实在在的技术债务。

更稳妥的做法是遵循“数据可迁移、备份常态化、架构不绑定”三个原则。也就是说，任何写入 Airtable 的关键数据，都应该有自动备份机制；任何基于 Airtable 的业务逻辑，都不应该让数据无法导出；任何时候都要知道，如果 Airtable 明天不可用，你的团队应该怎么继续运转。

4. 开发者应对：数据备份与迁移准备

4.1 Airtable API 的基本用法

在讨论备份和迁移之前，先掌握 Airtable API 的基础用法。这里以 Python 为例，使用标准库requests请求 Airtable API。

在 Airtable 中，每个 Base 都有一个唯一的 Base ID，格式类似appXXXXXXX。每个表名对应 API 路径中的一个位置参数。请求列表数据时，默认会返回records、offset等字段。

一个最小读取示例：

import requests base_id = "appXXXXXXX" table_name = "Tasks" token = "你的 personal access token" url = f"https://api.airtable.com/v0/{base_id}/{table_name}" headers = {"Authorization": f"Bearer {token}"} response = requests.get(url, headers=headers) print(response.status_code) print(response.json())

这里的token需要在 Airtable 账号的设置页面里创建 Personal Access Token。创建时可以选择权限范围，例如读取数据、写入数据、创建 Base 等。同时还可以指定允许访问的 Base，避免 token 有过大的权限。

4.2 用 Python 批量备份数据

当表里记录超过 100 条时，接口会返回offset字段。下面这个脚本可以循环读取所有记录，最终保存为 JSON 文件。

import requests import json import os AIRTABLE_API_URL = "https://api.airtable.com/v0" BASE_ID = "appXXXXXXX" TABLE_NAME = "Tasks" TOKEN = os.environ.get("AIRTABLE_TOKEN") headers = {"Authorization": f"Bearer {TOKEN}"} def fetch_all_records(base_id: str, table_name: str) -> list: records = [] offset = None params = {"pageSize": 100} while True: if offset: params["offset"] = offset response = requests.get( f"{AIRTABLE_API_URL}/{base_id}/{table_name}", headers=headers, params=params, ) response.raise_for_status() data = response.json() records.extend(data.get("records", [])) offset = data.get("offset") if not offset: break return records if __name__ == "__main__": all_records = fetch_all_records(BASE_ID, TABLE_NAME) with open("airtable_backup.json", "w", encoding="utf-8") as f: json.dump(all_records, f, ensure_ascii=False, indent=2) print(f"备份完成，共 {len(all_records)} 条记录")

执行前需要设置环境变量AIRTABLE_TOKEN。如果你有多个表，可以在脚本外层再写一个循环，把每个表的记录都导出来。备份出来的 JSON 可以直接入本地数据库，也可以后续转换成 CSV。

在正式执行之前，建议先拷贝一个独立 Base 做测试，确认 token 权限和数据字段都能正确读取，再对生产数据执行。这一点在涉及真实业务数据时尤其重要。

4.3 导出流程与注意点

Airtable 官方提供了手动导出 CSV 的功能，但 CSV 对附件、引用字段、多选字段的还原能力有限。附件字段导出后可能只是 URL 列表，多选字段的值会被拼接成字符串，跨表引用则可能丢失关联信息。

因此，完整的迁移备份流程建议是：

1. 使用 API 导出所有 Base 的结构定义，包括字段名称、字段类型、字段选项。
2. 使用 API 导出每个表的全部记录，保留 JSON 原始格式。
3. 单独下载所有附件文件，不只保存 URL，避免链接失效后数据丢失。
4. 导出一份自动化配置的说明文档，记录触发器、条件和操作步骤。
5. 把备份文件上传到独立的存储空间，例如本地磁盘、对象存储或私有 Git 仓库。

关键点在于：附件必须单独保存。Airtable 返回的附件字段通常包含下载 URL，但这个 URL 可能带有时效性，也可能包含访问控制信息。如果只把 URL 存下来，后续可能无法访问，因此需要主动下载附件内容。

5. 开源替代方案对比

5.1 NocoDB

NocoDB 是一个开源的无代码数据库平台，它的定位是“Airtable 的开源替代品”。NocoDB 可以直接连接现有的关系型数据库，比如 MySQL、PostgreSQL、SQLite、SQL Server、ClickHouse 等，也可以自己创建表。这意味着如果团队已经在使用 PostgreSQL，可以很自然地在上面叠加一层类似 Airtable 的界面。

NocoDB 有网格、看板、日历、甘特图、画廊等多种视图，支持公式、关联记录、视图过滤、角色权限、Webhook、API 访问等功能。在团队内部署 NocoDB，可以保留 Airtable 的很多交互体验，同时数据掌握在自己手里。

需要注意，NocoDB 是开源项目，但它的迭代速度、稳定性和企业级能力与商业化 SaaS 产品尚有差距。用它承接简单的项目管理和内部工具非常合适，但如果你的场景需要极端复杂的权限体系、大规模并发访问或长期服务保障，部署和运维成本也要计算在内。

5.2 Baserow

Baserow 是另一款开源无代码数据库，支持自托管和云版本。Baserow 的界面更接近传统数据库管理工具与 Airtable 的折中方案，也提供 API、行级权限、公式字段、外部数据源连接等功能。

相比 NocoDB，Baserow 在某些设计上更简洁，对于只需要基础表格、视图和权限的场景，配置起来更轻。但 Baserow 的生态规模和插件丰富度目前不如 NocoDB，如果项目需要大量集成，可能需要自己写脚本。

5.3 其他方案与技术选型框架

除了 NocoDB 和 Baserow，还可以根据业务场景选择其他方向：

选型时不要只比较功能列表，还要考虑团队已有的技术栈。如果团队熟悉 PostgreSQL，NocoDB 或 Supabase 是更自然的入口。如果团队主要是前端开发者，AppSmith 拖拽生成界面会更顺手。如果只是需要一个简单工具提升几个人日常效率，甚至继续付费使用 Airtable 也不是不可以。

之前有一个项目组的思路值得参考：把 Airtable 当作产品原型和无代码数据层，同时每周通过 API 自动把数据同步到 PostgreSQL 仓库。这样即使 Airtable 发生重大变化，核心数据仍然掌握在自己手里，替换界面层只是工作量问题，而不是数据安全问题。

6. 实战：用 NocoDB 自建类 Airtable 数据库

6.1 环境准备

这里以 NocoDB 自托管为例，演示如何快速在本地搭建一个类似 Airtable 的无代码数据库。部署方式选择 Docker Compose，因为这种方式环境一致、便于迁移，在一台 Linux 服务器或者本机有 Docker 环境就可以完成。

需要的环境如下：

• Docker 与 Docker Compose
• 至少 2GB 可用内存
• 完成一个目录，例如nocodb-demo
• 可以访问外网，以便拉取镜像

需要注意的是，NocoDB 版本迭代较快，配置项的细节可能随版本变化。本文示例的部署思路适用于大多数版本，实际使用时请以官方文档为准。

6.2 Docker Compose 部署

在项目目录下创建docker-compose.yml，内容如下：

version: "3.8" services: nocodb: image: nocodb/nocodb:latest container_name: nocodb ports: - "8080:8080" environment: NC_DB: "pg://postgres:5432?u=nocodb&p=nocodb&d=nocodb" volumes: - nocodb_data:/usr/app/data depends_on: - postgres restart: unless-stopped postgres: image: postgres:15 container_name: nocodb-postgres environment: POSTGRES_USER: nocodb POSTGRES_PASSWORD: nocodb POSTGRES_DB: nocodb volumes: - pg_data:/var/lib/postgresql/data restart: unless-stopped volumes: nocodb_data: pg_data:

这份配置做了三件事：启动了一个 PostgreSQL 数据库作为 NocoDB 的系统数据库；启动了一个 NocoDB 应用容器；把两个容器挂载了外部卷，保证数据不会因为容器重启而丢失。

执行启动命令：

docker-compose up -d

首次启动会拉取镜像，可能需要等待一段时间。启动完成后，浏览器访问http://localhost:8080，会进入 NocoDB 的初始化页面。设置管理员账号密码后，就可以开始使用了。

6.3 连接已有数据库

NocoDB 的强大之处在于可以连接已有数据库。左侧菜单通常有创建 Base 的入口，选择连接外部数据库后，可以在数据库类型中选择 MySQL、PostgreSQL、SQL Server 等协议。填入数据库地址、端口、用户名、密码和数据库名，NocoDB 会自动读取库里的表，并生成对应的表格。

这个功能在迁移场景中非常实用。例如你有一个订单表已经在 MySQL 里维护，可以通过 NocoDB 直接连接，再添加视图、公式字段和权限规则，不需要改变原有表结构。相比迁移到 Airtable，这种模式没有数据搬运过程，风险更小。

需要注意，连接外部数据库时，NocoDB 原则上不应该使用数据库的超管账号，而是单独创建一个只拥有所需库权限的最小权限账号。这样可以限制误操作范围，也便于审计。

6.4 创建表格与视图

进入 Base 后，点击创建表，可以手动添加字段。字段类型包括文本、长文本、数值、日期、单选、多选、附件、公式、关联等。创建完字段后，就可以在网格视图里录入数据。

创建视图时，可以选择看板视图、日历视图、画廊视图等。看板视图下可以按状态字段进行分组，拖拽卡片时直接改变记录的状态字段值。这个体验和 Airtable 很相似，团队内部基本可以无缝切换。

如果团队已经有迁移需求，可以先在 NocoDB 里创建一个空 Base，然后通过 CSV 或 API 导入 Airtable 导出的备份数据。导入完成后，再手动还原字段类型、视图配置和自动化逻辑。由于开源项目对字段类型支持不完全一致，迁移后要重点检查公式字段和附件字段。

6.5 数据安全问题提醒

自托管替代方案的核心优势是数据自主可控，但这不代表没有安全风险。自托管的平台需要你自己负责备份、升级、防火墙、访问控制和数据加密。一旦服务暴露在公网，必须开启 HTTPS、配置强密码、限制 IP 访问范围，并定期备份数据库卷。

在工程实践中，建议给所有自托管服务增加自动备份任务。PostgreSQL 可以用pg_dump定期导出，备份文件推送到私有对象存储。NocoDB 应用配置和数据卷也要纳入备份范围。安全不是一次配置就能完成的，需要持续维护。

7. 常见问题与决策清单

7.1 常见问题

在应对 SaaS 产品收购和潜在业务调整时，开发者遇到最多的问题大致如下：

这里额外提醒一点：在 Airtable 里执行删除、更新等批量操作时，要在不影响线上业务的时间窗口内进行，先备份后操作。无论使用哪个平台，凡是涉及真实数据的变更，都应该遵守最小权限和先备份原则。

7.2 决策清单

如果你正在评估是否继续使用 Airtable，可以按下面的清单逐项确认。

第一步，数据摸底。整理出当前正在使用的所有 Base、表数量和记录量，统计自动化运行次数和 API 调用量。

第二步，成本评估。根据当前套餐和未来可能的调价空间，计算年度支出。如果支出在预算内，且团队没有合规约束，可以继续使用。

第三步，关键业务判定。识别哪些业务核心链路依赖 Airtable，哪些只是辅助性协作工具。核心链路需要额外准备备用方案，辅助工具可以随大流。

第四步，备份实施。在官方功能与定价发生进一步变化之前，把重要数据备份到本地或对象存储。备份不是一次性动作，最好自动化。

第五步，替代方案验证。在 NocoDB、Baserow 或 Supabase 上搭建一套测试环境，导入样例数据，模拟真实流程，评估迁移工作量。

第六步，制定切换计划。如果决定迁移，优先迁移低频、非核心的数据，再逐步迁移核心业务。迁移期间保持双写，验证数据一致性后再关闭旧的 Airtable Base。

8. 总结与下一步建议

这次 Bending Spoons 收购 Airtable 的事件，给所有依赖第三方 SaaS 产品做业务系统的团队敲了一个警钟：产品的可用性、价格和运营策略，都会随着资本变化而改变，技术选型时必须保留退路。

对个人开发者，建议从今天开始启用 Airtable API 自动备份，并把关键数据同步到本地或私有仓库，避免平台变动时措手不及。对团队开发者，提前画出业务对 Airtable 的依赖关系图，确认哪些流程是强依赖，哪些可以快速替换，然后针对强依赖部分设计降级方案。

如果你想动手实践，下一步可以尝试三件事：第一，写一个 Python 脚本，把 Airtable 某个 Base 的表结构和记录完整导出；第二，在本地用 Docker Compose 部署一套 NocoDB 或 Baserow，把导出的数据导入进去，对比字段和视图的还原程度；第三，用 PostgreSQL 建一个备份表，定期通过 API 把关键数据同步过去，为长期演进做准备。

无代码数据库本身没有错，关键在于使用方式。借助它快速搭建业务界面是效率，但把数据安全、备份和退出机制一起考虑进去，才是工程上的成熟。