无代码应用开发：适合小团队的4个平台

做无代码应用开发时，团队工作流程可以考虑 AppSheet，网页和移动端产品可以考虑 Bubble，连接现有数据的应用可以考虑 Softr，而重视代码导出的话，可以考虑 WeWeb。你的选择取决于谁需要访问、应用的运行成本，以及离开平台时哪些内容可以迁移。

无代码应用开发基础

你可以通过可视化工具构建应用，无需编写底层代码。Microsoft（在新标签页中打开） 将无代码应用构建工具定义为一种开发软件，让不懂编程的人也能创建应用。工作的重心转向决定应用该如何运作。

先从业务需求出发。员工工作流程和面向客户的产品，对访问、支持和发布的要求各不相同。这些建议基于资料研究，而非实际测试结果。

这些推荐按业务需求排序，从团队运营到面向客户的产品，再到使用现有数据的应用和代码所有权。这个顺序很重要，因为一款工具可能很适合某项工作，用于另一项工作时却会带来高昂的维护成本。没有哪个平台能在所有场景下胜出。

上文对 AppSheet（在新标签页中打开） 的区分依据其定价页面，该页面将免费测试与 Publisher Pro 区分开来，并说明了后者的访问限制。Bubble（在新标签页中打开） 的定价页面介绍了按用量计费的方式，以及对网页、iOS 和 Android 应用的支持。只有当 Softr 和 WeWeb 的现行条款符合你的要求时，它们才是合适的选择。

在选择应用开发平台之前，你需要清楚了解它将处理哪些信息。数据是指应用读取或修改的记录和文件。将这些记录保存在你的企业控制的账户中，会让所有权更容易管理，但这并不能决定谁可以在应用内查看这些记录。

• 你的数据计划要明确记录存放在哪里、源账户归谁所有，以及如何备份。
• 你的工作流程计划要说明什么会触发操作、操作会改变什么，以及失败时会发生什么。
• 你的访问计划要说明每个人可以读取或修改哪些记录。
• 你的退出计划要明确哪些内容可以导出，以及哪些内容需要重新构建。

访问权限值得特别留意。隐藏按钮只是改变了界面，并不能证明底层信息受到保护。私密记录需要在数据被读取或修改时落实权限控制。登录用于确认身份，权限则决定这个人能做什么。

一个能正常使用的界面，也无法解答所有运营问题。操作失败、账号恢复以及所连接服务的变更，都必须有人负责。对小团队来说，这份责任可能比首个界面成形的速度更重要。

如果平台适合你的工作流程，而且你能承担持续使用的费用，无代码应用开发就是一个合理的起点。代价是你必须依赖平台的规则和服务。在考虑界面是否精美之前，必要功能、访问控制或退出方案就应该决定哪些平台能入围。

用于团队工作流程的 AppSheet

如果你要打造面向员工的工具，AppSheet 值得试点，因为你可以先让一小群人测试，再决定是否部署。根据 AppSheet 的定价页面，你可以免费探索平台，并让最多 10 名用户测试应用。这有助于检验工作流程，但并不能确定正式发布的费用。

公开应用的价格需要仔细看。AppSheet 列出的 Publisher Pro 价格为每个应用每月 $50，用户人数不限。同一页面说明，这些应用包含 Core 功能，但不包含用户登录和安全过滤器。

安全过滤器控制应用向用户提供哪些记录。由于不具备登录功能和这些过滤器，Publisher Pro 不适合处理必须仅对特定客户或员工开放的私密记录。用户人数不限，并不能解决这个访问权限问题。

对于需要登录的应用，AppSheet 列出的身份验证方式包括通过 Google 和 Microsoft 等服务商进行验证。身份验证就是核实用户的身份。要确定该用户可以访问哪些记录，仍需单独检查权限。

实际区别在于谁可以使用应用。公开资源可以服务于那些你不需要知道其身份的人。私密客户门户则需要将已登录的用户与其获准访问的记录可靠地关联起来。如果为了避免按用户收费而选择公开发布，这项要求仍然无法得到满足。

先投入测试才是合适的做法。在 AppSheet 规定的测试额度内，你的试点可以纳入职责和访问需求各不相同的人。真正有用的结果，是证实每种角色都能完成自己的工作，同时不会看到受限信息。

• 获授权的用户可以读取和更新工作所需的记录。
• 受限用户无法通过搜索或直接链接获取私密记录。
• 被移除的用户会按预期失去访问权限。
• 更新失败后会留下明确的状态，让员工知道是否需要重试。

运行成本需要单独核查。需登录使用的方案、许可规则，以及任何已连接服务的费用，共同决定了持续支出。注明日期的报价应列明币种和计费条款，尤其是当你的企业以加元付款时。仅凭列出的 Publisher Pro 金额，无法确定私有应用的费用。

在员工开始依赖这个工具之前，检查退出安排很重要。数据导出是指以可用的形式取出你的记录；这并不代表界面和工作流程规则也能随之迁移。你的企业应掌控源账户，并记录应用的运行方式。

• 数据所有者无需依赖某一位员工的个人账户，就能取回记录和附件。
• 导出后，相关记录之间的关联仍然保留。
• 团队已记录权限和自动化规则，以便日后重建应用。
• 已连接服务的账户可以转移或替换，而不会丢失业务信息。

如果员工的工作流程适合用 AppSheet 的工具来处理，而且需登录使用的部署成本也适合你的团队，AppSheet 就值得列入候选名单。Publisher Pro 则属于另一种选择，适用于可以接受公开访问的情况。

用于网页和移动产品的 Bubble

对于面向客户的产品，如果你的发布计划涵盖网页或移动应用，Bubble 就值得评估。Bubble 的定价页面表示，该平台支持为网页、iOS 和 Android 构建应用。它是否适合你，取决于方案能否覆盖你所需的发布范围，以及你对应用资源消耗的测量结果。

留意用量。Bubble 表示其定价以用量为基础，因此应用消耗的资源会影响账单。仅凭用户数量，无法了解全部成本。

Bubble 在定价页面上区分了工作负载单位（WU）和 AI 点数。工作负载单位衡量托管和运行应用所需的一般服务器处理量，而 AI 点数衡量 AI 驱动功能的使用量。这是两种独立的计量方式，因此 AI 额度并不能说明方案包含多少常规应用处理量。

触发通知的用量门槛很重要。根据 Bubble 的定价页面，当应用用量达到 100% 并开始产生超额费用时，你会收到一封电子邮件。这封邮件是预算警示，并不代表费用已停止增加。

你的团队需要清楚由谁接收用量提醒，以及谁能作出处理。计费通知如果发到无人查看的邮箱，就起不了多少保护作用。上线前，需要检查有哪些支出控制措施可用，以及这些措施会如何影响应用的可用性。

要公平地比较价格，发布条款也必须一致。仅支持网页发布的方案，与涵盖移动应用发布的方案，满足的是不同需求。按月计费和承诺订阅一年，带来的付款义务并不相同，即使两者的价格都以每月金额显示。

在这些项目一致之前，较低的标示价格并不代表较低的运行成本。可靠的估算应以相关方案和实测的应用活动量为依据。估算也要为应用构建平台之外另行收费的服务预留空间。

有用的试点测试会衡量客户实际要完成的操作。服务器处理是指在屏幕后方执行的工作，包括读取或更新信息。看似简单的页面，仍可能触发大量处理工作。因此，与功能清单相比，你自己的工作流程更适合用来测试成本。

1. 使用不含私人信息的示例数据，搭建一套完整的客户工作流程。
2. 测量成功操作和失败尝试所消耗的工作负载。
3. 使用你预计上线时会有的记录数量，重复测试。
4. 根据实测需求和当前套餐条款，估算常规月份和高用量月份的费用。

可迁移性需要单独评估。数据导出涉及记录和文件。应用逻辑的可迁移性则涉及控制权限、操作和计算的规则。证明其中一项可以迁移，并不代表另一项也可以。

• 导出内容包括你需要的业务记录、文件及其关联关系。
• 平台当前的条款说明了你离开平台后，应用逻辑会如何处理。
• 你的企业掌控自己的域名和所连接服务的账号。
• 替换方案明确列出哪些页面、权限和工作流程需要重建。

如果 Bubble 的发布选项适合你的产品，而且实测用量符合你的预算，它就是一个合理的候选平台。如果你要求运营费用固定，或整个应用都能迁移，就需要先解决这些要求，再决定是否采用。

Softr：适合使用现有数据的应用

如果你要围绕现有记录搭建门户应用，Softr 值得列入候选名单。据 Zapier（在新标签页中打开） 报道，它支持超过 50 种集成，包括 Google Sheets 和 Airtable。因此，它是否适合你还取决于具体条件，关键在于访问控制，以及为你的用户提供服务的成本。

从你现有的记录入手。连接数据源可以让你不必将信息搬到另一个系统，但也会把现有的数据问题带进应用。即使页面看起来已经完成，重复条目和不一致的账号名称仍可能让门户应用变得不可靠。

Google Sheets 是检查数据的一个实用起点。每条记录都需要一个稳定的标识符，也就是一个即使记录位置改变也保持不变的值。当行被移动或删除时，单靠行号就无法达到这个目的。记录还需要通过可靠的方式，确定谁可以访问它们。

私密内容的访问控制是决定性的测试。登录用于确认一个人的身份；权限则决定这个人可以读取或更改什么。隐藏按钮并不能证明其背后的记录受到保护。

在你选择付费套餐之前，需要从当前官方条款中确认以下事项：

• 套餐包含你的应用所需的数据连接，而且限额符合你预期的记录数量。
• 用户配额说明了员工和外部客户的人数如何计算。
• 访问控制能够将记录限制为仅供指定的人或组织访问。
• 发布条款涵盖你的正式上线应用和任何域名要求。

只看套餐名称还不够。你应该根据 Softr 当前官方定价页面和结账页面显示的价格与配额来决定是否购买，并记下日期、币种和计费周期。在这些细节确认之前，确定每月预算还为时过早。

数据连接本身也有成本。你的预算可能需要涵盖保留付费数据源账号的费用，额外的自动化功能也可能带来另一笔订阅费用。责任分工同样重要：当连接停止更新记录时，需要有人能及时发现。

将记录保留在现有数据源中，可以简化退出平台时的部分工作。但这并不能证明界面或权限规则也能随之迁移。数据所有权和应用可迁移性需要分别核查。

退出平台前的检查应涵盖以下事项：

• 你的企业掌控数据源账号，并能导出其中的记录和附件。
• 导出内容保留了重新关联相关记录所需的标识符。
• 平台条款说明了界面和工作流规则中的哪些内容可以一并迁出。
• 替代方案已考虑权限和已连接的自动化流程。

如果现有数据结构已经符合需求，就应先考虑 Softr，再考虑更复杂的开发方案。如果权限设置需要别扭的变通做法，或需要大量清理数据，现成连接带来的便利就没那么重要了。

用 WeWeb 导出代码

如果你的团队非常重视代码所有权，WeWeb（在新标签页中打开） 值得评估，因为它宣称支持代码导出和自行托管。自行托管是指在你掌控的基础设施上运行应用。这让你有更多选择，也需要承担更多责任。

WeWeb 的对比文章列出 Essential 的价格为每月 20，按年收费，并表示该套餐增加了代码导出、自行托管、GitHub 同步，以及 WeWeb 云端的无限会话。在将这一报价用于预算之前，你仍需确认币种和当前的结账条款。把它当作一条待核实的线索，而不是上线所需的全部费用。

收费周期很重要。年付套餐折算后的月费，并不意味着你可以每月按这个金额付款。报价需要同时说明折算后的周期性费用和购买时实际收取的金额。

导出只是开始。应用还依赖其中的记录，以及处理用户登录等任务的服务。迁移界面并不会自动迁移这些依赖项。

GitHub 是一项用于存储代码并追踪代码变更的服务，可以帮你保留导出代码的历史记录。仅有一个代码仓库，并不能证明另一位开发者能够运行这个应用。交接时，还需要提供操作说明，以及连接应用所用服务所需的配置。

有用的导出测试，应能在原编辑器之外完成可正常运行的部署。下载一个文件夹只能证明文件存在；实际运行它，才能看出你是否具备运行应用所需的各个部分。

1. 使用你打算购买的套餐导出一个测试版本。
2. 按照文档说明，在独立环境中部署它。
3. 连接测试数据，并验证登录功能和记录访问权限。
4. 修改一个界面，重新部署，并记录哪些工作仍需使用应用构建工具。

必须有人负责这些运维工作。自行托管可能意味着要安排更新、检查备份，并在部署失败时处理问题。对于没有技术支持的小团队，这些职责带来的负担可能超过立即迁移托管服务的价值。

对于使用量方面的说法，也要同样谨慎。根据 WeWeb 的说法，其所列的 Essential 方案包含在 WeWeb 云端不限次数的会话。这一表述并未明确连接到你的应用的服务有哪些限制或收费，因此，运营预算仍需单独列出这些服务。

这个选项排在最后，是因为可迁移性是一项特定的采购要求，其价值取决于你团队的需求。在无代码应用开发中，只有当你有人手能利用导出的内容时，导出功能才能发挥最大价值。如果你的团队希望采用全托管运营，眼前的好处可能只是保留未来退出平台的选择。

预算不能只看免费方案

你的上线预算需要涵盖一个能够正常运行且有支持服务的应用，以及它所依赖的服务。免费测试额度只能说明你在付费前可以试用哪些功能。它并不能确定正式发布或让客户私密访问应用的成本。

先确定范围。公平的比较应针对每个平台采用相同的受众和发布要求。员工工具和客户门户即使包含相似的界面，在访问权限和支持方面的需求也可能很不一样。

每份报价旁都需要注明日期、币种和计费周期。对于支付美元账单的加拿大企业，实际从银行账户扣除的金额还可能取决于汇率和支付手续费。年度付费承诺需要在现金规划中单独列出。

下方的预算表将日常月度成本与上线前需支付的款项分开。空白项应填入报价金额或基于实测的估算；未知成本则应继续标为未知。

月度总额能帮助你判断是否负担得起。应付款项则让你知道是否有足够资金支持上线。在月度成本中，年度订阅应按年费除以其涵盖的月数来计算；在现金支出中，则应在付款到期时记录全额款项。

避免重复计算。应用搭建平台订阅中已包含的托管服务，不应再列为单独的托管费用。对于你的企业已经付费、且与应用连接的数据服务订阅，仍应加以注明，因为这个应用可能让该订阅更难取消。

预估增长时，应按各项服务的计费方式来计算。注册用户增加可能影响按席位（用户名额）计费的套餐，而反复更新记录可能影响用量或自动化费用。统一套用一个增长百分比，可能会漏掉收费档位的变化。

试点和你的运营计划可以提供以下有用信息：

• 需要访问权限的人数，以及服务商如何计算这些人数。
• 完成一个工作流程所消耗的操作量，包括失败的尝试。
• 你的记录所需的存储空间和附件容量。
• 你的团队能自行处理的支持工作，以及需要付费购买的支持服务。

即使没有人编写代码，也应该为维护预留预算。权限变更和连接失效可能导致可视化应用中断，就像它们会导致定制软件中断一样。支持协议应明确由谁排查故障，以及哪些变更需要额外付费。

价格最合适的应用开发平台，是整体运营成本与任务需求相匹配的平台。如果能省去反复进行的手动工作，较高的订阅费也可以是合理的。如果必要的访问控制或支持服务不在报价范围内，较低的入门价格就没有那么实用了。

选择你的应用开发平台

当试点证明你的团队能够安全地完成一个真实的工作流程时，你就能从候选名单中作出选择。合适的应用开发平台应能在你的运营预算内通过这项测试，并提供切实可行的记录恢复和服务退出途径。

从小规模开始。试点可以选用你的业务已经在处理的一项任务，并移除样本记录中的敏感信息。在开始搭建前，先写下预期结果，这样就不会把界面是否好看当作成功的衡量标准。

这些检查应按以下顺序进行，因为每一项都以前一项为基础。工作流程必须先产生正确的结果，你才能评估其权限设置；在放心用它处理客户记录之前，恢复能力也必须先得到验证。

1. 用样本数据搭建一个完整的工作流程。沿用一项现有任务，从最初的输入一直走到最终结果，包括你的团队所依赖的所有审批或通知环节。
2. 为每个预设角色使用独立账户来测试权限。除了可见的界面，还要检查直接链接和记录搜索，因为隐藏按钮并不能证明底层信息已受到保护。
3. 测试失败或重复执行的操作。连接中断或重复提交后，应留下明确的结果，而不是悄无声息地丢失更改或造成重复工作。
4. 从备份中恢复样本记录。备份成功的提示固然有用，但将记录恢复到安全的测试环境中，才能看出恢复流程是否真正有效。
5. 导出试点项目，并检查从平台导出了哪些内容。将记录和附件与应用代码分开检查，然后找出哪些连接或设置需要在其他地方重新建立。
6. 让负责日常运营的人在没有搭建者帮助的情况下运行工作流程。记录尚未解决的问题，并确认由谁处理失败的操作、账户变更和持续支持。

结果要具体。权限测试的截图、已恢复的样本记录和检查过的导出内容，都比笼统地记一句“应用可用”更有说服力。任何受阻的任务都需要在上线前明确负责人。

最终判断应以证据为依据，不同类型的失败应对应不同的处理结果。

如果基础能满足你的需求，而且剩余故障都有明确的修复方法，我们倾向于修复。如果某项必要要求超出了平台的能力范围，重建就更合理。已经花出去的钱，并不能成为接受访问控制缺失的理由。

我们的 AppDesign360 AI App Review & Launch 服务通过付费的产品和代码审查，为 AI 构建的应用提供书面审查结果，以及保留、修复或重建的建议。实施范围另行确定。对于无代码应用，我们首先需要确认是否支持你使用的构建工具，以及该工具的访问和导出选项允许我们检查哪些内容。

如果平台不提供源代码访问权限，审查也无法承诺获得这项权限。审查的实际价值在于，以书面形式说明哪些功能正常、哪些内容尚未验证，以及上线前必须做哪些改动。这样，你就能作出一个可以据此编制预算的决定。

你可以通过 https://appdesign360.com/contact 与我们讨论你的项目，确认审查是否适合你的应用和构建工具。

要点回顾

常见问题