ToolJet + Claude Code/Codex：AI驱动内部工具构建的No Codegen实践-平芜编程栈

先问一个很现实的问题：当你让 Claude Code 或 Codex 写了一个内部工具，接下来会发生什么？

如果是传统思路，AI 会帮你生成一堆前端代码、后端接口、数据库建表脚本，然后你需要把它们跑起来、接上数据、处理登录权限、部署到服务器，最后告诉团队“这个工具好了，大家来用吧”。听起来没什么问题，但做过的人都懂，内部工具的真正成本从来不是“生成”，而是后续的修改和维护。

每次业务方提一个新需求，你都要重新打开代码仓库，找到对应组件，改逻辑，重新部署。AI 生成代码的速度越快，你需要维护的代码量就越大，这套模式对于一次性内部工具来说，其实是一笔隐性的负资产。

本文要聊的 ToolJet 提供了一条完全不同的路径：让 Claude Code 和 Codex 直接在 ToolJet 平台上搭建内部工具，AI 操作的是可视化组件和数据源配置，而不是生成一堆需要长期维护的代码。这也是项目标题中 “no codegen” 的核心含义——不生成代码，不等于不能构建工具，而是让 AI 直接在运行环境中完成构建。

无论你是在选型内部工具平台，还是想把手上的 Claude Code / Codex 从“代码生成器”升级成“工具构建器”，这篇文章都值得读完。

1. 背景与核心概念

1.1 ToolJet 是什么

ToolJet 是一个开源的低代码平台，专门用于快速构建内部工具。它提供可视化的画布、预置的组件库（表格、表单、图表、按钮等），以及丰富的数据源连接器（PostgreSQL、MySQL、REST API、GraphQL、Google Sheets、Redis 等）。你可以通过拖拽组件、配置数据查询、编写少量 JS 逻辑，在较短时间内搭建出一个可用的内部运营后台。

ToolJet 最本质的定位是：缩短从“业务需求”到“可用工具”的距离。它并不想取代正规的前端开发流程，而是把内部工具这类“脏活累活”从开发任务中剥离出来。

1.2 Claude Code 和 Codex 是什么

Claude Code 是 Anthropic 推出的命令行 AI 编程助手，能够在终端中理解你的自然语言指令，读取项目文件、修改代码、执行命令，完成一系列复杂开发任务。它最大的特点是 Agent 能力很强，可以自主规划执行步骤，而不是简单给出代码建议。

Codex 是 OpenAI 旗下的 AI 编程助手，同样以 Agent 方式工作。它能够接管开发环境中的实际任务，比如创建文件、运行测试、修复报错，通过自然语言驱动整个开发流程。

这两款工具当前的热度都很高，围绕 Claude Code 安装、Codex 安装、接入 DeepSeek 等话题在开发者社区讨论非常活跃。但我发现一个问题：大多数人在使用它们时，第一反应都是“帮我写代码”。这当然没错，但对于内部工具这个场景，生成代码往往不是最优解。

1.3 “No Codegen” 到底是什么意思

Codegen 指代的是“代码生成”，即让 AI 输出源代码文件，再由开发者把这些代码纳入版本管理、编译、部署。而 ToolJet 所提倡的 “no codegen”，指的是让 AI 直接在 ToolJet 环境中操作应用配置、修改组件属性、建立数据源连接，整个过程不产生需要维护的代码库。

两者最大的区别在于维护模型：

模式	AI 产出物	后续维护方式	适用场景
Codegen 模式	源代码文件	修改代码、走 Git 流程、重新部署	正式产品、复杂业务系统
No Codegen 模式	ToolJet 应用配置	在可视化界面修改、随时生效	内部工具、管理后台、临时需求

内部工具有一个典型特征：变更频率高、单次逻辑不复杂、使用者是内部员工。这种场景下，为每一次小需求都引入完整的代码工程流程，成本和收益不成正比。ToolJet + AI Agent 的思路，就是把 AI 从“代码生成器”变成“操作员”，它帮你在 ToolJet 里搭好页面、配好数据源、写好交互逻辑，你只需要审核和微调。

1.4 什么人需要关注这个组合

经常被业务方拉着做各种内部管理后台的开发人员。
团队已经引入 Claude Code 或 Codex，但希望拓宽 AI 应用场景的开发者。
正在评估低代码平台，担心平台不够灵活、难以让 AI 介入的架构师。
希望减少内部工具维护成本的技术管理者。

如果你符合以上任意一条，下面这套实操方案会很有参考价值。

2. 环境准备与版本说明

在开始之前，我们需要把环境准备到位。由于 ToolJet、Claude Code、Codex 都在快速迭代，本文不写死具体版本号，重点演示整体配置思路，你按照自己的实际环境调整即可。

2.1 部署 ToolJet

ToolJet 支持多种部署方式：

云端 SaaS 版：可以直接在官网注册使用，适合快速验证。
Docker 自托管：通过 docker-compose 在服务器或本机启动，适合需要私有化部署的团队。
源码部署：从 GitHub 拉取仓库自行构建，适合深度二次开发。

对于想深入体验结合 AI 的开发者，推荐使用 Docker 方式部署。下面是一个最基础的 docker-compose 片段，用于了解 ToolJet 的启动方式：

# docker-compose.yml（示例，需按官方文档调整） version: "3.8" services: tooljet: image: tooljet/tooljet:latest ports: - "8080:80" environment: SECRET_KEY_BASE: 请修改为随机字符串 LOCKBOX_MASTER_KEY: 请修改为随机字符串 volumes: - tooljet_data:/var/lib/postgresql restart: unless-stopped volumes: tooljet_data:

注意：上面只是一个极简示例，真实的 ToolJet 部署还会涉及 PostgreSQL、Redis 等依赖。建议以官方仓库中的 docker-compose 文件为准。

2.2 安装 Claude Code

Claude Code 以命令行工具形式运行，安装方式比较简单。官方推荐使用 npm 全局安装：

npm install -g @anthropic-ai/claude-code

安装完成后，在终端中运行claude进入交互模式。如果是首次使用，需要完成登录认证：

claude

首次启动时会引导你登录 Anthropic 账号并授权。这个过程需要你的网络环境能够正常访问 Anthropic 服务。

补充一点：社区中也有人通过 cc-switch 之类的工具来切换 Claude Code 的 API 提供商，或者将 Claude Code 接入其它模型网关。这类做法需要你自己判断合规性和稳定性，本文不展开介绍。

2.3 安装 Codex

Codex CLI 是 OpenAI 提供的 Agent 型编程工具。安装方式通常也是通过 npm：

npm install -g @openai/codex

安装完成后运行：

codex

首次运行时需要配置 API Key 或完成登录授权。如果你使用的是第三方兼容网关或本地代理，还需要额外配置 base URL。社区中有人将 Codex 接入 DeepSeek 等模型服务，核心原理就是修改模型名称和 API 地址，这一块本文同样不深入讨论。

2.4 版本与兼容性建议

由于这三款工具迭代速度非常快，界面、命令参数、API 都可能随时变化。在动手操作前，建议先确认以下信息：

ToolJet 是云端版还是自托管版，版本号是多少。
Claude Code 版本（运行claude --version查看）。
Codex 版本（运行codex --version查看）。
Claude Code 或 Codex 是否有权限访问本地 HTTP 服务（例如 ToolJet 运行在 localhost，需要确认 Agent 能否调用 localhost 地址）。

如果组件版本升级后出现兼容问题，优先回退版本或等待官方文档更新，不要盲目修改配置。

3. 核心原理：为什么 AI Agent 能驱动 ToolJet

3.1 ToolJet 的应用本质是“配置”而非“代码”

普通 Web 应用的核心是代码：前端代码、后端代码、数据库脚本。开发者修改功能，本质上是修改代码，然后重新构建和部署。

ToolJet 的应用本质是一份“配置数据”。你在画布上拖入一个表格组件，它会在内部记录组件的类型、位置、绑定的数据源、属性配置。你设置一个按钮的点击事件，它会记录事件类型和对应的动作。整个应用的表现完全由这份配置驱动，ToolJet 平台负责把配置渲染成可交互的 Web 界面。

这种架构带来的直接好处是：修改配置比修改代码轻量得多，而且不需要重新部署。

3.2 AI Agent 驱动 ToolJet 的两种途径

Claude Code 和 Codex 要操作 ToolJet，有两条技术路径：

路径一：通过 ToolJet REST API

ToolJet 提供了 REST API，可以创建应用、修改组件、运行查询、管理数据源。Claude Code 或 Codex 可以通过 curl 或写脚本调用这些 API，实现“代码生成式”的操作——只不过生成的代码是 Shell 脚本或 Python 脚本，而脚本的作用是改变 ToolJet 里的配置。

这种方式适合以下场景：

需要批量创建多个相似应用。
需要在 CI/CD 流程中自动更新 ToolJet 应用。
需要把 AI 的构建过程固化成可重复执行的脚本。

路径二：通过 ToolJet 提供的 AI 能力

ToolJet 平台本身正在融入 AI Agent 能力。官方在推动一个方向：让自然语言直接驱动 ToolJet 的构建过程，用户描述需求，Agent 在 ToolJet 内部完成组件编排、数据源连接和逻辑配置。这意味着 AI 不再是外部工具，而是平台的内生能力。

Claude Code 和 Codex 在这个体系中的角色，更像是“AI 构建引擎”。它们接受自然语言指令，分析 ToolJet 应用的结构和可用的 API/组件，然后执行一系列操作完成工具搭建。

3.3 人工审核仍是必要环节

无论是外部脚本调用 API，还是平台内置 AI Agent，都需要注意一个问题：AI 操作 ToolJet 时产生的变更必须可审查、可回滚。

ToolJet 的应用是运行中的配置，AI 一旦修改了配置，影响是即时性的。因此在实际落地中，强烈建议：

在非生产环境让 AI 完成初步构建。
人工审核配置后，再同步到生产环境。
使用 ToolJet 自身的版本管理功能，保留变更历史。

3.4 与传统 AI 开发工作流的对比

维度	传统 AI 开发（Codegen）	AI + ToolJet
AI 输出	源代码	应用配置
运行载体	独立的 Web 服务	ToolJet 平台
修改流程	改代码 → 部署 → 验证	改配置 → 刷新页面 → 验证
维护成本	需要管理代码仓库、依赖、环境	平台统一管理
适合场景	正式产品、复杂业务	内部工具、管理后台
灵活性上限	高，但成本也高	中高，日常内部工具足够用

一句话总结：如果你需要的是“能用的内部工具”，AI + ToolJet 是性价比很高的选择；如果你需要的是“完全可控的产品级应用”，传统代码开发依然是更可靠的方式。

4. 完整实战：让 Claude Code / Codex 构建一个内部工具

接下来进入实操环节。我们通过一个完整示例，演示如何利用 Claude Code 和 Codex 驱动 ToolJet 构建内部工具。

4.1 实战目标

假设团队需要一个“客户反馈管理后台”，需求如下：

展示客户反馈列表。
支持按状态筛选（待处理 / 处理中 / 已完成）。
支持标记反馈状态。
展示简单统计（今日新增、总数、已完成数）。

这个需求非常典型：逻辑不复杂、需要数据库支持、涉及增删改查。传统开发至少需要写后端接口、前端页面、数据库表，一套流程下来几个小时起步。现在用 ToolJet + AI Agent，我们希望把时间压缩到分钟级。

4.2 创建基础数据表

在让 AI 动手之前，我们先把数据库准备好。这里以 PostgreSQL 为例，执行以下建表语句：

-- 创建客户反馈表 CREATE TABLE customer_feedback ( id SERIAL PRIMARY KEY, customer_name VARCHAR(100) NOT NULL, content TEXT NOT NULL, status VARCHAR(20) NOT NULL DEFAULT 'pending', created_at TIMESTAMP DEFAULT NOW() ); -- 插入几条测试数据 INSERT INTO customer_feedback (customer_name, content, status) VALUES ('张三', '希望增加导出功能', 'pending'), ('李四', '页面加载速度有点慢', 'processing'), ('王五', '整体体验不错，但移动端需要优化', 'completed');

这个表有三个核心字段：客户名称、反馈内容、处理状态。后续我们在 ToolJet 中做的所有操作，都是围绕这张表展开。

4.3 在 ToolJet 中创建应用并连接数据源

手动操作的步骤是：

登录 ToolJet，点击“创建新应用”。
在左侧数据源面板中，添加 PostgreSQL 数据源。
填写数据库连接信息：主机、端口、数据库名、用户名、密码。
创建查询，写入上面的 SQL 语句。

这个流程如果是人来做，熟悉的话两三分钟就能完成。但要交给 AI Agent 来做，就需要让 Agent 能够访问 ToolJet 的 API。以下是思路示例：

# 思路示例：通过 ToolJet API 创建数据源 curl -X POST "${TOOLJET_URL}/api/data_sources" \ -H "Authorization: Bearer ${TOOLJET_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "name": "customer_feedback_db", "type": "postgres", "options": { "host": "localhost", "port": "5432", "database": "inner_tools", "username": "postgres", "password": "your_password" } }'

这个脚本展示了 AI 或人工如何通过 API 将数据源注册到 ToolJet。实际运行时，需要在 ToolJet 管理后台获取 API Key，并确保 API 地址正确。

4.4 利用 Claude Code 编写 ToolJet 操作脚本

Claude Code 在这里的价值，是帮你生成并执行上面的 API 脚本。

在终端中启动 Claude Code：

claude

然后输入以下提示词：

请帮我编写一个 Python 脚本，通过 ToolJet API 完成以下任务： 1. 在 ToolJet 中创建名为 customer_feedback_db 的 PostgreSQL 数据源。 2. 创建一个查询，查询语句为：SELECT * FROM customer_feedback ORDER BY created_at DESC。 3. 输出执行结果。 ToolJet 的 API 地址是 http://localhost:8080/api，Token 环境变量为 TOOLJET_API_KEY。

Claude Code 会分析 ToolJet 的 API 文档（前提是你的提示词中提供了足够的 API 信息，或者它能访问 ToolJet 的 OpenAPI 文档），生成类似下面的脚本：

# 文件路径：create_tooljet_datasource.py（示例） import os import requests TOOLJET_URL = os.getenv("TOOLJET_URL", "http://localhost:8080") API_KEY = os.getenv("TOOLJET_API_KEY") HEADERS = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } def create_datasource(): """在 ToolJet 中创建 PostgreSQL 数据源""" url = f"{TOOLJET_URL}/api/data_sources" payload = { "name": "customer_feedback_db", "type": "postgres", "options": { "host": "localhost", "port": "5432", "database": "inner_tools", "username": "postgres", "password": "your_password" } } resp = requests.post(url, headers=HEADERS, json=payload) resp.raise_for_status() print("数据源创建成功:", resp.json()) return resp.json()["id"] def create_query(datasource_id: int): """在 ToolJet 中创建查询""" url = f"{TOOLJET_URL}/api/queries" payload = { "name": "get_all_feedback", "data_source_id": datasource_id, "query": "SELECT * FROM customer_feedback ORDER BY created_at DESC" } resp = requests.post(url, headers=HEADERS, json=payload) resp.raise_for_status() print("查询创建成功:", resp.json()) if __name__ == "__main__": ds_id = create_datasource() create_query(ds_id)

这段代码的作用是通过 ToolJet API 注册数据源和查询，而不是生成前端代码。Claude Code 帮你完成了“与 API 交互”的编码工作，你只需要审核脚本、配置好环境变量，再运行：

export TOOLJET_URL=http://localhost:8080 export TOOLJET_API_KEY=你的_API_Key python create_tooljet_datasource.py

4.5 利用 Codex 构建前端界面配置

数据源和查询准备好了，接下来是界面。在 ToolJet 中，“界面”同样由配置构成。Codex 可以通过 API 来更新应用的组件配置。

假设置前已经在 ToolJet 中创建了一个空白应用，并知道应用 ID。下面是用 Codex 编写脚本、通过 ToolJet API 添加表格组件和按钮组件的思路：

# 文件路径：configure_ui.py（示例） import requests import os import json TOOLJET_URL = os.getenv("TOOLJET_URL", "http://localhost:8080") API_KEY = os.getenv("TOOLJET_API_KEY") APP_ID = os.getenv("APP_ID") # ToolJet 应用 ID HEADERS = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } def add_table_component(): """添加表格组件，绑定数据查询""" url = f"{TOOLJET_URL}/api/apps/{APP_ID}/components" payload = { "component": "TableV2", "props": { "data": "{{queries.get_all_feedback.data}}", "columns": [ {"name": "customer_name", "label": "客户名称"}, {"name": "content", "label": "反馈内容"}, {"name": "status", "label": "状态"}, {"name": "created_at", "label": "提交时间"} ] } } resp = requests.post(url, headers=HEADERS, json=payload) resp.raise_for_status() print("表格组件添加成功") if __name__ == "__main__": add_table_component()

这里的关键点在于{{queries.get_all_feedback.data}}，这是 ToolJet 中常见的模板语法，表示将查询结果绑定到表格组件的数据源上。Codex 需要理解这种数据绑定的写法，才能生成正确的配置脚本。

启动 Codex：

codex

在交互窗口中输入：

请根据 ToolJet 的 API 文档，帮助编写一个配置脚本，在指定应用中添加一个表格组件： - 组件类型：TableV2 - 数据绑定：queries.get_all_feedback.data - 需要显示字段：customer_name, content, status, created_at - API 基础地址：http://localhost:8080/api - 认证方式：Bearer Token（环境变量 TOOLJET_API_KEY）

Codex 会参考你的描述生成脚本，你审核后运行即可。

4.6 运行与验证

完成上述步骤后，在浏览器中打开 ToolJet 应用，你应该能看到：

表格组件显示了customer_feedback表中的数据。
查询在后台正确执行。
如果添加了筛选组件，可以按状态筛选数据。

这里要特别注意：AI 生成的脚本未必一次就能完全正确。第一轮运行后，可能会出现 API 路径不对、参数缺失、组件类型名错误等问题。这是正常的，你需要把报错信息反馈给 Claude Code 或 Codex，让它们自己修复脚本，而不是手动改代码。这也是 Agent 模式最有价值的地方——它能基于报错反馈进行自我迭代。

4.7 实战总结

通过上面的示例可以看出，AI + ToolJet 的工作方式和传统 AI 编程有显著差异：

步骤	传统 AI 编程	AI + ToolJet
1	让 AI 生成前端页面代码	让 AI 生成 ToolJet 配置脚本
2	让 AI 生成后端接口代码	让 AI 调用 ToolJet API 注册数据源
3	本地联调前后端	不涉及前后端联调
4	部署前端、后端、数据库迁移	在 ToolJet 中直接查看效果
5	需求变更时重新生成代码	修改配置或重新调用 API

核心变化是：AI 的工作产物从“代码”变成了“配置变更”，维护成本呈指数下降。

5. 常见问题与排查思路

在实践过程中，你可能会遇到各种问题。下面列出几个高频场景及排查建议。

问题现象	常见原因	解决思路
ToolJet API 返回 401 未授权	API Key 错误、Token 过期	在 ToolJet 管理后台重新生成 API Key，确保环境变量正确
创建数据源成功但查询无数据	数据库连接串错误、SQL 语法问题	先在数据库中执行同样的 SQL 验证；检查 ToolJet 数据源配置
表格组件不显示数据	查询名称绑定错误、查询未运行	检查组件数据绑定字段是否为`queries.xxx.data`，在 ToolJet 中手动触发查询验证
Claude Code 无法访问本地 ToolJet	Agent 运行环境与 ToolJet 不在同一网络	确认 ToolJet 监听地址，或使用远端部署地址
Codex 生成的 API 脚本报错	ToolJet API 版本更新，接口路径变化	查阅官方 API 文档，以实际返回结果为准修正脚本
脚本删除组件导致配置异常	误操作删除了关键组件	使用 ToolJet 版本历史功能恢复；操作前导出应用配置备份

5.1 关于 Codex 报 not supported 的一个说明

社区中有用户反馈某些 Codex 配置会报“model is not supported”，例如使用某些内部或测试模型时出现：

the 'gpt-5.6-sol' model is not supported when using codex with a...

这类报错通常与 Codex 的模型配置有关。如果你没有使用官方默认模型，而是配置了自定义模型名，需要确认：

模型名是否被当前 Codex 版本支持。
是否填写了正确的模型供应商地址。
是否在 Codex 配置文件中指定了正确的模型权限。

最佳做法是回退到官方默认配置，或者使用文档明确支持的模型名称。

5.2 关于 Claude Code 环境报错

Claude Code 在 Windows PowerShell 下安装时，可能会遇到执行策略限制，报错信息类似：

claude : 无法加载文件 ... 因为在此系统上禁止运行脚本

解决方案是以管理员身份运行 PowerShell，执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

然后重新安装或运行 Claude Code。这个问题的根源是 PowerShell 的脚本执行策略，而不是 Claude Code 本身。

5.3 排查建议顺序

如果你在集成过程中遇到问题，可以按以下顺序排查：

确认网络连通性：ToolJet API 是否可以被 Claude Code / Codex 所在环境访问。
确认认证信息：API Key 是否正确，权限是否足够。
确认 API 文档版本：使用的接口路径和参数是否和当前 ToolJet 版本匹配。
检查返回日志：把完整的报错信息（HTTP 状态码、响应体）反馈给 AI Agent。
确认 ToolJet 内部状态：数据源是否测试通过、查询是否手动执行成功。

6. 最佳实践与工程建议

把 Claude Code / Codex 接入 ToolJet 这件事，技术门槛不算高，但要在团队中稳定落地，有一些工程层面的经验值得参考。

6.1 权限最小化

给 AI Agent 使用的 ToolJet API Key，应当遵循最小权限原则。只需要赋予它操作应用和数据源的权限，不要使用管理员账号的全量权限。原因很简单：AI Agent 在自动执行过程中，可能会因为误判执行一些不受控的操作。权限范围越小，出问题时的影响面就越可控。

同时，建议为 AI 配置独立的 API Key，并定期轮换。这样可以在某个 Key 泄露或行为异常时快速单独禁用，不影响其他开发者的正常使用。

6.2 应用配置备份与恢复

ToolJet 本身提供了应用版本管理功能，但在让 AI 大规模操作之前，还是建议手动导出一次应用配置。特别是在以下时机：

让 AI 添加复杂组件之前。
批量修改查询配置之前。
大规模调整数据源连接之前。

一个简单的备份策略是：每次 AI 操作前导出一份 JSON 配置，保存到版本管理仓库的tooljet-backup/目录下。一旦出现不可恢复的错误，可以从配置重新导入。

6.3 让 AI 先生成脚本，不要直接执行

在实际使用 Claude Code 或 Codex 时，我强烈建议一个工作习惯：先让 AI 生成脚本内容，人工审核后再执行。

例如：

第一步：让 AI 输出“你准备怎么操作 ToolJet，请列出具体步骤和脚本”。
第二步：人工检查脚本中涉及的数据源信息、SQL 语句、组件配置。
第三步：确认无误后，再让 AI 执行脚本或手动运行。

这样做有两个好处：一是避免 AI 误解需求导致的连锁错误；二是在审核过程中，你也能发现一些 AI 无法判断的问题，比如环境配置错误、数据源密码错误等。

6.4 合理设计查询，避免全表加载

内部工具常见的性能隐患是直接执行SELECT * FROM table，当数据量到达几十万行时，表格渲染会变得非常卡顿。在让 AI 生成查询时，建议约定以下最佳实践：

使用分页查询：LIMIT 20 OFFSET 0。
添加筛选条件：根据业务需要选择必要的字段。
避免在表格中加载大文本字段。

可以在提示词中直接要求 AI：“请为查询添加分页和筛选功能”。AI Agent 通常会遵循指令，生成更合理的查询。

6.5 使用环境变量管理敏感信息

脚本中难免涉及数据库用户名、密码、API Key 等敏感信息。不要把这些信息硬编码在脚本中，更不要直接写入 ToolJet 应用的公开配置中。建议的做法是：

在运行 CLI Agent 的环境中设置环境变量。
脚本中通过os.getenv()或process.env读取。
密钥管理使用专门的工具或平台能力。

例如：

export DB_PASSWORD='your_strong_password' export TOOLJET_API_KEY='your_tooljet_key'

脚本里这样读取：

import os db_password = os.getenv("DB_PASSWORD") api_key = os.getenv("TOOLJET_API_KEY")

6.6 渐进式落地，不要一步到位

如果你所在团队还没有任何 AI Agent 开发经验，不要一开始就追求“全自动让 AI 构建完整工具”。建议分三个阶段：

阶段一：让 AI 只负责创建数据源和简单查询，界面由人工拖拽完成。
阶段二：让 AI 负责创建查询 + 生成界面配置脚本，人工审核后执行。
阶段三：当团队对 ToolJet API 和组件配置足够熟悉后，再尝试让 AI 全流程构建。

渐进式落地的好处是，每阶段都能沉淀出团队自己的最佳实践和提示词模板，而不是一次性把风险拉满。

7. 总结

经过上面的完整拆解，我们可以看到 ToolJet 与 Claude Code、Codex 的组合，确实在内部工具开发这条路上提供了一种新的解题思路。

不再让 AI 生成一堆需要长期维护的前端代码，而是让它直接操作 ToolJet 运行时的配置，这符合内部工具“快速构建、频繁变更、低维护成本”的诉求。整个工作流的效率提升来自两个层面：Claude Code 和 Codex 帮你处理了与 API 交互的编码工作；ToolJet 帮你省去了传统前后端开发中部署、运维、迭代的天然成本。

当然，这套方案也有边界：它适合的是逻辑不复杂、生命周期短、以内部使用为主的工具。如果你需要的业务系统非常复杂，有特定的性能、安全和定制化要求，传统开发模式仍然是更稳健的选择。

下一步，你可以在实际项目中尝试以下方向：

在 ToolJet 中接入真实的业务数据库，用 Claude Code 生成数据查询。
让 Codex 通过 API 批量复制和修改应用配置，快速搭建同类型工具。
设计一套团队内部的提示词模板，把常见的工具类型（如审批后台、数据看板、运营报表）沉淀下来。

如果你正在被内部工具的需求反复打扰，不如找个下午，把 ToolJet 跑起来，让 Claude Code 或 Codex 帮你搭第一个后台。这段体验本身，就比读这篇文章更有价值。