先问一个很现实的问题当你让 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 部署 ToolJetToolJet 支持多种部署方式云端 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 CodeClaude Code 以命令行工具形式运行安装方式比较简单。官方推荐使用 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后在终端中运行claude进入交互模式。如果是首次使用需要完成登录认证claude首次启动时会引导你登录 Anthropic 账号并授权。这个过程需要你的网络环境能够正常访问 Anthropic 服务。补充一点社区中也有人通过 cc-switch 之类的工具来切换 Claude Code 的 API 提供商或者将 Claude Code 接入其它模型网关。这类做法需要你自己判断合规性和稳定性本文不展开介绍。2.3 安装 CodexCodex CLI 是 OpenAI 提供的 Agent 型编程工具。安装方式通常也是通过 npmnpm 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 能驱动 ToolJet3.1 ToolJet 的应用本质是“配置”而非“代码”普通 Web 应用的核心是代码前端代码、后端代码、数据库脚本。开发者修改功能本质上是修改代码然后重新构建和部署。ToolJet 的应用本质是一份“配置数据”。你在画布上拖入一个表格组件它会在内部记录组件的类型、位置、绑定的数据源、属性配置。你设置一个按钮的点击事件它会记录事件类型和对应的动作。整个应用的表现完全由这份配置驱动ToolJet 平台负责把配置渲染成可交互的 Web 界面。这种架构带来的直接好处是修改配置比修改代码轻量得多而且不需要重新部署。3.2 AI Agent 驱动 ToolJet 的两种途径Claude Code 和 Codex 要操作 ToolJet有两条技术路径路径一通过 ToolJet REST APIToolJet 提供了 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 开发CodegenAI ToolJetAI 输出源代码应用配置运行载体独立的 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 Codeclaude然后输入以下提示词请帮我编写一个 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/apiToken 环境变量为 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: fBearer {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, headersHEADERS, jsonpayload) 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, headersHEADERS, jsonpayload) 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_URLhttp://localhost:8080 export TOOLJET_API_KEY你的_API_Key python create_tooljet_datasource.py4.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: fBearer {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, headersHEADERS, jsonpayload) resp.raise_for_status() print(表格组件添加成功) if __name__ __main__: add_table_component()这里的关键点在于{{queries.get_all_feedback.data}}这是 ToolJet 中常见的模板语法表示将查询结果绑定到表格组件的数据源上。Codex 需要理解这种数据绑定的写法才能生成正确的配置脚本。启动 Codexcodex在交互窗口中输入请根据 ToolJet 的 API 文档帮助编写一个配置脚本在指定应用中添加一个表格组件 - 组件类型TableV2 - 数据绑定queries.get_all_feedback.data - 需要显示字段customer_name, content, status, created_at - API 基础地址http://localhost:8080/api - 认证方式Bearer Token环境变量 TOOLJET_API_KEYCodex 会参考你的描述生成脚本你审核后运行即可。4.6 运行与验证完成上述步骤后在浏览器中打开 ToolJet 应用你应该能看到表格组件显示了customer_feedback表中的数据。查询在后台正确执行。如果添加了筛选组件可以按状态筛选数据。这里要特别注意AI 生成的脚本未必一次就能完全正确。第一轮运行后可能会出现 API 路径不对、参数缺失、组件类型名错误等问题。这是正常的你需要把报错信息反馈给 Claude Code 或 Codex让它们自己修复脚本而不是手动改代码。这也是 Agent 模式最有价值的地方——它能基于报错反馈进行自我迭代。4.7 实战总结通过上面的示例可以看出AI ToolJet 的工作方式和传统 AI 编程有显著差异步骤传统 AI 编程AI ToolJet1让 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 无法访问本地 ToolJetAgent 运行环境与 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_PASSWORDyour_strong_password export TOOLJET_API_KEYyour_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 帮你搭第一个后台。这段体验本身就比读这篇文章更有价值。