2026年构建内部工具：Retool与Appsmith对比直接编码

每个工程团队最终都会面临内部工具的问题。有人需要一个仪表板来管理客户账户。其他人需要一种无需直接在生产环境运行 SQL 来处理退款的方法。运维团队想要一个能触发部署流程的表单。不知不觉间，你就面临着一个购买还是自建的决定，这将决定你团队未来几年的生产力。

2026年，内部工具市场已经相当成熟。Retool（现已达到v3.x版本）和Appsmith（v1.40+）是主导的低代码平台，但它们已经迎来了一系列替代品的不断增长生态系统——Tooljet、Budibase、Airplane（在2025年底被Airtable收购）等。与此同时，”直接写代码”阵营也有自己的武器库：带有服务端组件的Next.js 15、shadcn/ui、Tailwind CSS v4，以及Refine和AdminJS等介于低代码和自定义开发之间的框架。

无论是通过哪种方式构建内部工具——在200人的金融科技公司交付Retool应用，还是在初创公司手动编写管理面板——我都想提供一个诚实的比较。不是供应商营销版本，也不是”真正的工程师自己写工具”的版本。而是那些真正重要的权衡、成本和决策点。

低代码平台的案例

Retool和Appsmith真正擅长的地方

低代码平台能非常出色地解决特定问题：它们消除了将UI连接到数据源和渲染CRUD操作的样板代码。如果你的内部工具本质上是”查询数据库，在表格中显示结果，让用户编辑行，并触发某些操作”，这些平台可以在几小时内而不是几天内让你从零开始实现功能。

Retool的核心优势在于其查询层。你可以连接PostgreSQL数据库（或MySQL、MongoDB、REST API、GraphQL端点，或其他大约50种集成），并在构建器中直接编写查询。这些查询可以引用UI组件——搜索输入、日期选择器、下拉菜单——平台会自动处理数据绑定。

-- 一个典型的引用UI组件的Retool SQL查询
SELECT 
  u.id, u.email, u.name, u.plan, u.created_at,
  COUNT(o.id) as order_count,
  SUM(o.total) as lifetime_value
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.email ILIKE {{'%' + searchInput.value + '%'}}
  AND u.created_at >= {{dateRangePicker.value.start}}
  AND u.created_at <= {{dateRangePicker.value.end}}
  AND ({{planFilter.value}} = 'all' OR u.plan = {{planFilter.value}})
GROUP BY u.id
ORDER BY {{sortColumn.value}} {{sortDirection.value}}
LIMIT 50 OFFSET {{(table1.pageNumber - 1) * 50}}

这确实很有用。在自定义应用中编写等效功能意味着需要构建查询构建器、参数化输入、处理分页、管理加载状态，并将所有这些连接到UI组件。在Retool中，这大约需要15分钟。

Appsmith（开源、可自托管）提供了类似的功能，但采用了一种更对开发者友好的方法。其以 JavaScript 为核心的设计意味着你需要在各处编写 JavaScript 表达式，而不是使用 Retool 使用的模板语法。自 Appsmith v1.30 起，其 Git 集成已显著改进——你可以对应用进行版本控制、创建分支和合并，这在早期版本中是一个主要痛点。

低代码平台的不足之处

当你的需求超出平台的预设范围时，问题就开始了。每个低代码平台都对内部工具的外观做出假设，当你的工具不符合这些假设时，你就是在与平台对抗，而不是在它之上构建。

复杂的 UI 交互： 拖放式构建器在处理表单和表格时表现很好。但对于自定义可视化、带条件分支的多步骤向导，或任何需要对布局和交互进行精确控制的功能，它们就力不从心了。Retool 的自定义组件 API（v2，2025 年中期发布）有所帮助，但构建自定义 React 组件、打包、上传到 Retool，并将其连接到查询层，通常比直接在 React 中构建整个页面更费事。

规模化性能： Retool 和 Appsmith 在处理大型数据集时都存在困难。显示 10,000 行数据并带有客户端过滤的表格会明显卡顿。这两个平台都在浏览器中渲染，因此你受限于浏览器内存限制和 JavaScript 执行性能。对于自定义应用，你会从一开始就实现服务器端分页和过滤。

测试： 这是房间里的大象。Retool 和 Appsmith 都没有有意义的测试方案。你无法为 Retool 查询编写单元测试。你无法为 Appsmith 工作流编写集成测试。如果查询更改破坏了下游组件，你只能通过手动点击应用来发现。对于认真对待软件质量的团队来说，这是一个严重的缺陷。

供应商锁定： 你的 Retool 应用是不可移植的。如果你决定离开这个平台——无论是由于价格变化、功能差距还是收购——你都需要从头开始重写。Appsmith 通过开源（可自托管）在一定程度上缓解了这个问题，但你的应用仍然与 Appsmith 运行时紧密耦合。

编写代码的理由

现代自定义内部工具栈

在2026年从头开始构建内部工具比五年前要快得多。一个现代的内部管理面板技术栈看起来大概是这样的：

// 一个典型的2026年内部工具技术栈
{
  "framework": "Next.js 15.2 (App Router + Server Components)",
  "ui": "shadcn/ui (基于Radix primitives构建) + Tailwind CSS v4",
  "data-table": "@tanstack/react-table v8.x",
  "forms": "react-hook-form v7.x + zod验证",
  "auth": "Auth.js v5 (前身为NextAuth) 配合企业SSO",
  "database": "Prisma v6 ORM 或 Drizzle ORM v0.36",
  "deployment": "Vercel / Docker / Kubernetes"
}

使用这个技术栈，有经验的开发者可以在大约两到三天内构建一个功能完整的CRUD管理面板——包括身份验证、表格视图、搜索、过滤、分页和编辑表单。这比Retool慢，但差距没有人们想象的那么大。

shadcn/ui组件库值得一提。与作为npm包分发的传统UI库不同，shadcn/ui直接将组件源代码复制到你的项目中。这意味着你拥有代码，可以修改任何内容，并且对第三方没有依赖。结合Tailwind v4改进的性能和新的CSS优先配置方法，构建美观的内部UI确实非常快速。

// 示例：使用shadcn/ui和TanStack Table的用户管理表格
// 这大约80行实际代码 — 与Retool的工作量相当

"use client";

import { columns } from "./columns";
import { DataTable } from "@/components/ui/data-table";
import { useQuery } from "@tanstack/react-query";
import { Input } from "@/components/ui/input";
import { useState } from "react";
import { useDebounce } from "@/hooks/use-debounce";

export default function UsersPage() {
  const [search, setSearch] = useState("");
  const debouncedSearch = useDebounce(search, 300);
  const [page, setPage] = useState(0);

  const { data, isLoading } = useQuery({
    queryKey: ["users", debouncedSearch, page],
    queryFn: () =>
      fetch(`/api/users?search=${debouncedSearch}&page=${page}&limit=50`)
        .then((r) => r.json()),
  });

  return (
    <div className="space-y-4">
      <Input
        placeholder="按邮箱搜索用户..."
        value={search}
        onChange={(e) => setSearch(e.target.value)}
      />
      <DataTable
        columns={columns}
        data={data?.users ?? []}
        pageCount={data?.pageCount ?? 0}
        page={page}
        onPageChange={setPage}
        isLoading={isLoading}
      />
    </div>
  );
}

Refine框架：中间地带

Refine (v4.x) 占据了一个有趣的中立位置。它是一个开源的 React 框架，专门为数据密集型应用而设计——管理面板、仪表盘和内部工具。它开箱即用地提供了数据获取层、路由、身份验证和访问控制，但你需要编写实际的 React 组件来构建 UI。

// Refine 资源定义 — 类似于低代码的开发体验，
// 但你拥有所有代码
import { Refine } from "@refinedev/core";
import { dataProvider } from "@refinedev/supabase";

function App() {
  return (
    <Refine
      dataProvider={dataProvider(supabaseClient)}
      resources={[
        {
          name: "users",
          list: "/users",
          show: "/users/:id",
          edit: "/users/:id/edit",
          create: "/users/new",
        },
        {
          name: "orders",
          list: "/orders",
          show: "/orders/:id",
        },
      ]}
    />
  );
}

Refine 在让你保持自定义代码世界的同时，提供了大约 60-70% 的 Retool 速度优势。它支持多个 UI 框架（Ant Design、Material UI、Chakra、Mantine）和多个数据后端（REST、GraphQL、Supabase、Appwrite、Strapi）。权衡之处在于它有一定的学习曲线，而且其文档虽然在不断改进，但在高级用例方面仍有不足。

真实成本对比

供应商营销和博客文章经常错误地呈现双方的成本。以下是诚实的成本分析。

Retool 成本（2026 年定价）

对于 30 人的团队使用商业版，每年需要 $18,000。同一规模团队的企业版定价通常为每年 $30,000-45,000。这些数字增长很快，并且与人数呈线性增长。每个需要访问内部工具的新员工都会增加账单。

Appsmith 成本

Appsmith 的免费套餐确实是免费的，并且功能齐全。需要注意的是，自托管意味着你需要自己拥有基础设施——一台运行 Docker 的虚拟机（大多数云提供商上每月 20-50 美元），再加上保持其更新和备份的运营开销。对于小型团队来说，这是一笔不错的交易。对于大型团队，40 美元/用户/月的商业套餐比 Retool 的团队套餐更贵，但比 Retool 商业套餐更便宜。

定制构建成本

构建定制内部工具的成本几乎完全是开发人员的时间。以下是带有身份验证的 CRUD 管理面板的现实估算：

对于包含 5 个资源（用户、订单、产品、退款、报告）的工具，高级开发人员大约需要 8-10 个工作日。以高级工程师 800 美元/天的完全负担成本（包括工资、福利、间接费用）计算，前期成本为 6,400-8,000 美元。

但你还需要考虑持续维护：错误修复、新功能请求、依赖更新、安全补丁。为维护预留初始构建工作量的 10-20%/季度。这大约增加了每年 2,500-6,400 美元。

定制工具的第一年总成本：大约 9,000-14,500 美元。持续年度成本：2,500-6,400 美元。

与 30 个用户每年 18,000 美元的 Retool Business 相比，每年都是如此，并且随人数规模扩大。如果你有工程能力，数学上有利于定制构建工具——但前提是你确实维护它们。

决策框架

在多家公司通过两种方式构建内部工具后，这是我用来做决定的框架。

选择 Retool/Appsmith 的情况：

• 你的工具主要是 CRUD + 表格 + 表单。 这是低代码平台的最佳应用场景。如果你的工具 80% 的功能是”显示数据库数据并允许用户编辑”，那么低代码开发会更快更便宜。
• 你没有可用的工程资源。 如果你的工程师已经完全投入到产品工作中，而下周就需要一个内部工具，那么低代码是正确的选择。让工程师放下产品工作去做其他事情的机会成本是实实在在的。
• 工具的用户是非技术人员。 低代码平台对非工程师来说更容易修改。如果你的运维团队想要给表格添加一列或更改过滤器，他们可以在 Retool 中直接完成，而不需要提交工程工单。
• 你需要与多个数据源集成。 如果你的工具需要从 PostgreSQL、REST API、Google Sheet 和 Salesforce 中获取数据，Retool 的预构建连接器可以节省大量的集成工作。
• 你是小团队（少于 15 个工具用户）且可以使用团队套餐。 按 10 美元/用户/月的价格，对于小团队来说，Retool 在成本上很难被超越。

选择自定义代码的情况：

• 你的工具有复杂的 UI 需求。 自定义可视化、拖放界面、实时协作功能、具有复杂条件逻辑的多步骤工作流——这些都与低代码范式相悖。
• 你需要自动化测试。 如果这个工具至关重要（处理支付、管理库存、处理合规性），你需要自动化测试。低代码平台不支持这一点。
• 你的工具用户超过 30 人。 在这个规模下，低代码许可成本会超过自定义开发和维护的成本。而且用户数量只会继续增长。
• 你已经在维护一个组件库。 如果你的团队有一个包含 React 组件的内部设计系统，那么构建另一个内部工具就是增量工作，而不是从零开始的新项目。
• 数据敏感性阻止使用云托管工具。 自托管 Appsmith 在一定程度上解决了这个问题，但一些合规环境需要完全的代码所有权和审计追踪，这是低代码平台无法提供的。
• 工具的复杂性会随时间增长。 内部工具有一种功能累积的特性。从一个简单的用户查询开始，最终会变成一个完整的客户支持门户。如果你预计会有这种增长，从一开始就使用自定义代码可以避免日后痛苦的迁移。

混合方法

越来越多聪明的团队同时使用两种方法。他们使用 Retool 或 Appsmith 来构建快速、可抛弃的工具——一次性数据迁移界面、临时监控仪表板、临时报告工具——而对于那些将使用数年的核心内部工具，则使用自定义代码。

这种混合方法之所以有效，是因为它将工具的生命周期与投资相匹配。一个只会使用三个月的工具不需要自动化测试、CI/CD流水线和组件库。而一个会使用三年的工具则需要。

2026年实施建议

如果您选择低代码

1. 如果可以自行托管，请从 Appsmith Community Edition 开始。它是免费的、开源的，并且可以避免供应商锁定。Retool 更完善，但成本差异会累积。
2. 从第一天就开始使用版本控制。 Appsmith 原生支持 Git。Retool 在他们的商业版中添加了源代码控制功能。请使用它。没有版本控制低代码应用是维护的噩梦。
3. 为您的低代码应用设置一个暂存环境。 两个平台都支持多环境（暂存/生产）。使用它们来避免直接在生产数据上进行测试。
4. 记录您的查询和工作流程。 低代码应用很快就会变成黑盒。为每个查询添加注释，解释它的作用和原因。
5. 规划您的退出策略。 记录嵌入在低代码应用中的业务逻辑。如果您将来需要迁移，这些文档将为您节省数周时间。

如果您选择自定义开发

1. 使用带有 App Router 的 Next.js 15。 服务器组件消除了大部分 API 层——您可以直接在页面组件中查询数据库。与传统的 React + API 方法相比，这可以将开发时间减少约 30%。
2. 从 shadcn/ui 开始。 复制您需要的组件（表格、表单、对话框、下拉菜单、工作表），根据您的品牌进行定制，然后在此基础上构建。不要从头开始构建组件库。
3. 使用 Drizzle ORM 或 Prisma v6。 Drizzle 更轻量，并且有更好的 TypeScript 推断。Prisma 更成熟，文档更好。两者都可以。不要为 CRUD 操作编写原始 SQL。
4. 尽早实施基于角色的访问控制。 将 Auth.js v5 与您的企业 IdP（Okta、Google Workspace、Azure AD）一起使用。从一开始就添加基于角色的中间件——后期添加权限是很痛苦的。
5. 为业务逻辑编写测试，而不是 UI。 对于内部工具，您不需要 100% 的测试覆盖率。但要测试关键路径：退款流程是否真的退了正确的金额？用户停用流程是否撤销了所有活动会话？

AI 辅助开发呢？

2026 年改变方程式的一个因素是 AI 辅助编程。GitHub Copilot、Cursor 和 Claude Code 等工具可以在几分钟内生成 CRUD 样板代码、表单验证和数据表配置。这显著压缩了自定义工具的开发时间。

一位资深开发者使用 Cursor 或 Claude Code 可以在一天内 realistically 搭建一个完整的管理面板——包括数据库架构、API 路由、表格视图、表单组件和身份验证——这已经接近低代码平台的开发速度，却没有低代码平台的限制。

这并没有消除维护负担，但它确实改变了成本计算。如果初始构建从十天缩短到一天，与低代码许可成本的平衡点会来得更快。

结论

没有放之四海而皆准的正确答案，但针对你的具体情况，一定有合适的答案。决策矩阵很简单：

• 小型团队，简单的 CRUD 操作，没有工程带宽： 使用 Retool 或 Appsmith。本周内交付。
• 成长型团队，核心工作流工具，长期使用： 使用 Next.js + shadcn/ui 进行自定义代码开发。现在投入时间。
• 任何团队，临时性或实验性工具： 使用低代码平台。不要为可能在六个月后就不存在的东西过度工程化。
• 对合规性要求高的环境： 自定义代码，自托管部署。你需要审计追踪和代码所有权。

我看到团队犯的最大错误是将此视为一场宗教辩论——”我们是 Retool 团队”或”我们一切都自定义开发”。正确的方法是务实的：使用与工作需求、预期寿命和团队当前能力相匹配的工具。重要的东西自己构建，其他的购买现成的。