返回资讯中心
外部精选
软件工程
#开发者实时流

OpenRun 谈 AI 时代内部工具:代码优先正取代低代码

来源标题:Code-First Internal Tools vs. Low-Code in the Age of AI

OpenRun 发文认为,在 AI 编程工具加持下,代码优先的内部工具对多数团队而言已优于低代码平台。OpenRun 是开源自托管的 GitOps 平台,可单节点 Docker/Podman 部署或部署到 Kubernetes,并内置团队所需的认证、授权与审计功能。

Hacker News 最新ajayvk2026/11/3 · 今天13 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

代码优先的内部工具与低代码在 AI 时代

代码优先的内部工具与低代码在 AI 时代

复制页面 复制为 Markdown 查看 Markdown 2026 年 10 月 28 日 📎 OpenRun 是一个开源的、自托管的 GitOps 平台,用于以声明式方式部署 Web 应用和内部工具。可以在单节点上用 Docker/Podman 部署,也可以将应用部署到 Kubernetes 集群上。OpenRun 提供了团队所需的身份认证、授权和审计功能。代码优先的内部工具由此获得了通常只在 Retool 这类企业级低代码工具中才有的平台能力。

背景

每家公司都有一长串的内部工具:管理面板、审批表单、数据库看板、重跑失败任务的页面。每一个都很小,只有少数几个人在用,谁也不想花一周时间去搭建它。低代码平台正是为了填补这个空缺而发展起来的。把一个表格拖到画布上,连上一条查询,加一个按钮,一个小时就能做完。本文讨论的是:在有了 AI 编程工具之后,为什么对大多数团队来说,代码优先的内部工具现在是更好的选择。

很长一段时间里,第一点正是使用低代码平台的主要理由。即便只是手写一个简单的 CRUD 应用,也意味着要选框架、接表单和查询、处理各种小细节。这样做更慢,而对于一个只有五个人使用的工具来说,慢就不值得了。

像 Claude Code、Cursor、Codex 和 GitHub Copilot 这样的 AI 编程工具,现在可以根据这样的提示词生成一个完整的小应用:

构建一个 Streamlit 应用,列出 Postgres 中 refunds 表的退款申请。为状态和日期添加筛选器,再加一个 Approve 按钮,点击后将状态设为 'approved' 并记录审批人。

结果就是几百行普通的 Python 代码,用的框架是 AI 模型见过很多次的。几分钟就能完成,而不是几天。FastAPI、Flask、Go、Node.js,或者团队已经在用的任何语言和框架,都是同样的道理。

这就消除了可视化编辑器相对于代码优先内部工具的大部分速度优势。在画布上拼装应用和让 AI 工具写出来,花的时间差不多。区别在于最终得到的东西。

低代码工具的缺点并没有改变:

在写代码还很慢的时候,这些是可以接受的取舍。当代码可以快速生成时,这些就变得难以自圆其说了。

低代码平台也在添加 AI 功能,可以在它们的编辑器内根据提示词生成应用。这些功能有用,但产出仍然是那个平台内部的一个应用。AI 工具是厂商选定的,结果也只能在那个平台上编辑和运行。

代码优先的应用在整个工具生命周期内都能更好地配合 AI,而不只是第一个版本:

内部工具的大部分成本,都花在建成之后多年里的小改动上。而这正是把普通代码放在 Git 里最能帮上忙的地方。

代码优先并不意味着一定要做成一个 React 前端、JSON API 加庞大 JavaScript 构建的单页应用。大多数内部工具就是表格、表单和按钮。对于这些,超媒体驱动的方式效果更好:服务器渲染 HTML,由一个像 HTMX 这样的小型库处理局部页面更新。FastHTML、Flask、FastAPI 或 Django 配合模板,以及 Go 的 html/template,用这种方式都很好用。

对于内部工具来说,这有一些明显的优势:

在需要的地方,仍然可以通过在某个页面上引入一个 JavaScript 库来实现丰富的客户端交互,但大多数内部工具并不需要。

OpenRun 直接支持这种方式。除了支持任何框架的容器化应用,OpenRun 还能运行用 Starlark(一种 Python 方言)编写、配合 Go HTML 模板和 HTMX 的超媒体应用,无需容器,也没有 npm 构建步骤。这些应用运行在沙箱中:调用 HTTP API、命令和其他插件所需的权限,会在应用安装时审批。对于最简单的工具,操作会根据函数的参数列表生成表单 UI,完全不需要 UI 代码。

生成应用是容易的部分。低代码平台提供的第二样东西——应用周边的平台——仍然是需要的。一个处理退款的内部工具需要:

没有这些,AI 生成的应用最终会跑在某人的笔记本电脑上,或者跑在一台没有身份认证的虚拟机上,这比它们所替代的低代码工具还要糟糕。为每个应用都构建这些,是实打实的工作。反向代理、OAuth 代理、CI 流水线和密钥配置可以拼凑起来,但这本身就会变成一个平台项目。

这正是 OpenRun 所要填补的空白。应用就是 Git 里的普通代码,以声明式方式部署,SSO、RBAC、审计日志和数据库绑定由平台为每个应用提供。应用代码不需要实现其中任何一项。与低代码平台的详细对比,见 OpenRun 与 Retool、Appsmith 和 Budibase 的对比。

在某些情况下,低代码工具仍然是合适的选择:

对于由开发者来构建内部工具的团队,或者人们借助 AI 编程工具来构建的团队,天平已经向代码优先的内部工具倾斜。现在把应用写成代码,和在编辑器里拼装它差不多快,而且结果更容易维护、测试和迁移。仍然需要解决方案的部分,是安全运行这些应用的平台。

想试用代码优先的内部工具,请参阅快速开始。

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →