我最近在好几个团队里观察到同一个现象大家开始用 Claude Code、Codex 这类 AI 编程助手去“生成”内部工具。演示的时候很惊艳AI 噼里啪啦把前端页面写出来接口也调通了看起来万事大吉。但再往后问一句“这个工具下周需求变了谁来改”整个对话就会安静下来。这并不是说 AI 编程助手不行。恰恰相反它们非常擅长在一个明确的代码库里完成一次性的、边界清晰的开发任务。可内部工具不是这样的它业务对象多、审批流复杂、参与者非技术背景居多而且需求永远在变。把内部工具交付成一堆代码仓库本质上是放弃了低代码平台最核心的资产——可维护性。所以我看到 ToolJet 那个标题的时候一下就抓住了重点Claude Code 和 Codex 能直接在上面构建内部工具但不需要 codegen。“No codegen”听起来像技术洁癖实际上是一个完全不同的工作流选择。它意味着 AI 不负责生成一堆需要维护的代码而是以操作者的身份去创建表单、配置数据源、编排工作流。你审查的是结果和配置而不是去 review 一个 AI 写出来的前端项目。这恰好解决了内部工具真正的痛点不是造出来而是养得起。这篇文章想把这个思路展开讲清楚包括它和传统 codegen 路线的关键差异、如何用一个最小示例跑通全流程、在真实落地中会遇到哪些坑以及最容易被忽视的边界问题。1. AI 写代码很快但为什么内部工具还是“烂尾”最多内部工具不是一个新概念。从 Admin 后台、运营配置平台、审批面板到数据录入界面它们存在的意义是让团队内部的人能通过界面完成原本需要写 SQL、看日志、改代码才能做的事情。但这类工具恰恰是软件工程里最不讨喜的部分没有技术挑战性需求又极度善变上线后还得持续维护。过去几年低代码平台已经解决了“维护成本”的一部分。你在界面上拖出一个数据源绑定一张表加一个筛选条件整个工具就算完成了。下次需求变了改配置就行不涉及发版也不涉及代码回归。但低代码平台也有老问题上手有学习成本复杂的业务逻辑写起来很别扭而且很多平台是封闭的数据源和权限模型不一定符合你的现状。AI 编程助手的出现让很多人看到了另一条路。用自然语言描述一个后台AI 帮你把前后端代码全部写出来听起来确实很爽。但实际用下来问题不在于“能不能生成”而在于“能不能长期维护”。我把这种模式总结成三个结构性矛盾业务对象一直变但代码仓库是有历史包袱的。AI 生成一次很容易可每改一次需求AI 都要重新理解整个项目差异对比、回归测试、代码冲突这些传统研发流程的问题一个都不会少。内部工具的使用者往往不是开发者。你让运营、财务、客服去跑一个 git 仓库这本身就不现实。他们需要的是一个入口、一个界面、一套权限规则。生成代码不等于生成逻辑。AI 能写出看起来合理的代码但它不理解你的审批规则为什么是三级而不是两级不理解为什么某个字段必须人工核对。这些隐含业务规则一旦没进去代码生成得再快工具也不可用。所以这里要重新定义一下“AI 构建内部工具”这件事。如果 AI 只代替你敲键盘那它只是在加速一个本来就应该被结构化的过程。如果 AI 直接去操作工具对象的配置层它才真正改变了工作流。2. ToolJet 的关键设计让 AI 成为操作员而不是代码生成器ToolJet 是一个开源的低代码内部工具平台。你可以连接 PostgreSQL、MySQL、Redis、API 端点然后通过拖拽组件的方式快速搭建表单、表格、图表和管理界面。这类平台很多但 ToolJet 有个设计值得注意它把“工具本身”建模成了一组可操作的对象包括数据源、查询、组件、事件处理器和工作流。这意味着 Claude Code 或 Codex 不需要去写 React 组件和 Express 路由。它只需要学会一种 DSL领域特定语言——描述“我要创建一个 Data Source”“我要创建一个 Query”“我要设置一个 Table 组件的点击事件”。这类 DSL 结构化程度高、上下文窗口友好、验证成本低AI 调用时非常自然。我理解 ToolJet 这里所谓的“no codegen”核心就是AI 直接修改工具对象而不是生成一套独立的代码库。在这套工作流里有四个关键变化维度传统 AI codegenToolJet 式对象配置产物形态源码仓库、构建产物、部署脚本工具对象、资源配置、动态运行状态修改方式改代码、提 PR、回归测试、重新部署操作对象、配置字段、保存后即时生效审查要点阅读代码逻辑、检查依赖、验证边界验证配置结果、确认页面交互、核对数据映射长期维护需求驱动的代码变更需求驱动的对象配置变更从工程经验看这个取舍非常聪明。低代码平台早已证明内部工具最适合的产物形态就是“配置态”。但过去配置态的门槛很高你得熟悉这套平台自己的组件体系和数据绑定逻辑。AI 编程助手加入以后把“学会平台 DSL”这件事的成本几乎降到了零。人对平台的掌握程度不再是门槛AI 读取一段文档就能开始干活。不过这里要泼一盆冷水AI 能操作平台不等于 AI 能理解你的业务。你把“创建一个审批列表页”这种任务交给它是没问题的但如果你没有把审批流程、权限层级和状态流转规则喂给它它做出来的页面不会自动符合你的真实业务。也就是说no codegen 解决的是维护成本不是需求分析成本。后者永远需要人来把关。2.1 为什么 “No Codegen” 不是‘不用代码’“No codegen”最容易被人误解成“这个方案不能生成代码所以功能有限”。实际上不是。ToolJet 自己的工作流引擎、查询构造器和组件体系本身就是代码写出来的。这里拒绝的是“让 AI 生成应用代码然后跑成一个独立系统”的路线。AI 仍然在写东西但它写的不是业务代码而是操作指令和配置定义。从开发体验上说这是很聪明的降维。代码生成的隐忧集中在编译、运行、依赖、部署这些生命周期问题上。而对象配置的隐忧集中在权限、字段校验、流程编排这些业务问题上。内部工具的业务问题一定要有人想清楚的但生命周期问题能少一个就少一个。2.2 对开发者意味着什么从“救火队员”变成“流程设计者”过去开发者在内部工具上的角色很尴尬。你得帮运营做一张报表页面帮客服做一个人工审核功能帮财务做一个批量导入工具。需求无穷无尽而且永远在改。引入 ToolJet 加 AI 工作流之后开发者不用再为每个小需求写全套代码。你要做的是把数据源统一接入、把基础权限建好、把几个关键模板和流程固化下来然后剩下的需求让 AI 在配置层快速完成。从我的实际体感判断这个模式更适合“有低代码平台认知、愿意把数据模型梳理清楚的团队”。如果你连数据源都没有标准化公司内部的数据散落在 Excel、多个业务库和手工流程里那 AI 也帮不了你。工具再智能前提也得是地面上有一条清晰的数据通道。3. 一套完整的最小闭环让 AI 构建内部工具到底怎么操作理论说完了直接进入实操路径。以下示例基于 ToolJet 常见工作流我在描述时不会绑定某个具体插件版本但整体步骤在现行版本上都可以对齐。核心思路是先准备好环境再让 AI 连接数据源创建数据表和查询接着生成页面最后由人工审查和修正。整个过程尽量保持“一条任务线走到底”。3.1 环境准备要跑通这套流程你需要三样东西一个可用的 ToolJet 实例。本地可以用 Docker 跑团队使用可以部署在自有服务器或 Kubernetes 上。ToolJet 的部署文档里有明确的 compose 配置这里不再展开。一个数据源。可以是 PostgreSQL、MySQL、MariaDB、Redis、API 端点等。建议刚开始用一个测试库里面放一两条数据避免影响真实业务。一套可以调用的 Claude Code 或 Codex 环境。当前方案里AI 通过 ToolJet 的 API 或安全代理模式与平台通信。核心是让 ToolJet 提供可控的操作出口你给 AI 的权限范围只涉及工具配置而不是服务器所有文件。注意不要一上来就把 AI 接到生产环境。先用测试库 最小数据集把“创建数据源、查询、组件、页面”这条链路跑通再考虑权限放大。3.2 用自然语言完成数据源和查询配置环境准备好了第一步是让 AI 建连数据源。你可以在 ToolJet 的界面上把数据库连接信息填好也可以让 AI 通过 API 直接创建数据源配置。我更建议先手动建连数据源理由是数据库地址、账号、凭据这类信息涉及敏感权限不适合频繁暴露在对话上下文中。数据源建好之后后续操作都基于这个连接名AI 不需要再接触凭据。连接完成之后进入查询配置。查询是 ToolJet 里的核心对象它定义了你从数据源读什么、怎么写、怎么更新。给 AI 的指令可以像这样创建一个 PostgreSQL 查询名称是 list_pending_approvals从表 approvals 中读取 status pending 的记录按 created_at 降序排列最多返回 50 条。AI 理解这个任务后会直接创建 Query 对象并绑定到数据源上。你不用手写 SQL但建议你在 UI 里检查一遍 AI 生成的 SQL。低代码平台最忌讳的就是查询逻辑错误检查 SQL 比检查组件排版更重要。3.3 让 AI 生成页面和交互逻辑查询建好之后下一步是生成页面。ToolJet 的界面由组件构成比如 Table、Form、TextInput、Button 等。组件有属性和事件处理器AI 的职责是根据需求自动摆放这些组件并配置事件链路。假设我们正在做一个简单的审批面板需求是左侧显示待审批列表。点击某一行右侧显示该条记录的详情。下方有两个按钮通过、拒绝。点击按钮之后更新数据库里对应记录的 status并刷新列表。这个需求不需要任何代码生成AI 只需要完成三步创建一个 Table 组件数据源绑定到查询 list_pending_approvals。创建一个 Detail 组件内容绑定为当前选中行。创建两个按钮组件为按钮配置事件处理器更新记录然后重新运行查询。ToolJet 的事件处理器支持在配置界面里完成AI 操作起来和人工拖拽一样。完成后这个“页面”实际上已经可用了。因为所有状态都实时保存在平台对象里不需要单独构建和部署。3.4 人工审查和“微调”AI 自动生成的配置大概率不是完美的。常见问题包括组件布局不够合理信息层级不清晰。事件处理器绑定的字段不是数据库的真实主键。按钮的确认交互缺失用户可能误操作。页面对移动端预览的支持不好。这时候你要做的不是去改代码而是在 UI 上直接调整拖一下组件的位置改一下字段绑定加上一个确认弹窗。整个过程可能只需要十几分钟。这也是 no codegen 路线体验最好的地方——AI 把重复的排布和绑定工作做掉人把关键的业务正确性检查做完。这类配置有一个特点当你调整一个关联字段时平台会自动帮你把对应事件链路里的逻辑一起替换。这是传统代码仓库做不到的。3.5 发布和权限配置页面打磨好之后最后一步是发布并配置使用者权限。ToolJet 的身份与访问管理可以控制谁看得到哪个应用、谁的权限是只读、谁可以编辑。这一步是内部工具上线前必须检查的尤其是审批、退款、批量导入这类敏感动作。建议给最终用户分配“仅查看”或“按需操作”的权限给维护者分配“可编辑”权限。不要在权限配置上偷懒否则后面出了问题很难追溯责任。在 ToolJet 里这属于平台自带能力AI 也不应该被授权去修改权限边界。权限边界是少数我认为必须由人来配置的对象。4. 绕过代码生成后的隐秘代价这些坑会真实咬人任何方案都有代价只是“代价长在不同的地方”。以前你用 codegen 写内部工具代价在长期维护和发版流程。现在你用 ToolJet 加 AI 配置代价转移到下面这几个环节。4.1 AI 对业务规则的理解仍然不可靠AI 能完成“创建查询”“绑定组件”这类指令但它不会主动思考“这个列表应该过滤掉已删除数据”“这个按钮只有财务主管能看到”。这类业务规则如果没有出现在提示词里结果就是平台运行一切正常但不符合公司真实运作逻辑。我的建议是凡是包含状态流转、角色权限、数据隔离的规则都提前写成结构化文档在交给 AI 之前先过一遍。把规则写清楚了AI 构建出来的工具才真的能用而不是“看起来像能用”。简而言之这个流程把开发成本转移成了规则梳理成本。4.2 查询和组件数量上来之后策略还是要想清当工具规模变大页面里可能有几十个查询、几十个组件、十几条事件链。即使在低代码平台里这样的复杂度依然需要纪律性。AI 可以帮你处理单页面的工单式需求但当你需要在一个页面上串联查询 A 的结果传入查询 B 作为参数再由查询 B 触发另一个事件时还是会出现配置间的隐式依赖。这是低级平台最容易埋雷的区域。我从工程实践中总结出一个处理顺序梳理数据模型和关联关系把表结构画清楚。将可复用的查询抽成独立对象避免每个页面都写一遍同样的过滤逻辑。涉及多步骤业务时优先使用 ToolJet 内置的工作流引擎而不是在页面上堆事件链。每个查询都写清楚描述字段这不仅是给人看的也是给 AI 看的。4.3 太多的“一次任务”会演变成另一堆技术债低代码平台一个容易走偏的方向是因为改起来太简单所以团队会不断往上堆逻辑最后把平台变成一头无人能懂的庞然大物。AI 的加入会加速这种倾向。以前新需求要排队等开发现在 AI 几分钟就建好一个页面你很容易为了交付速度而牺牲设计一致性。所以在实际落地时要给团队定几条底线核心业务对象和数据源必须先统一接入不允许各页面随意连新表。AI 创建的查询和组件必须经过人工审查审查重点不是语法而是命名规范、字段映射和边界条件。定期清理过期页面和无效查询。平台维护成本低不代表不需要维护。如果你只是团队里的一个人自用以上几条可以放松一点。但如果是多部门协作的正式工具没有这些约束两个月后你就要开始处理一摊配置乱麻。4.4 两层日志与审计这是长期使用的安全底线当 AI 能直接操作平台对象时审计会变成一个重要问题。至少在理想情况下你需要能够回答几个问题哪个 AI 操作在什么时间创建了哪些查询这个查询当时的数据源是什么谁修改了这个应用的权限这些信息只有平台提供审计日志时你才能在事故发生后做回溯。ToolJet 这类头部低代码平台基本都有操作日志和应用版本历史但默认配置里日志保留策略不一定符合企业要求。建议在部署阶段就把日志接入中心日志系统至少保留 90 天。AI 越能干你越要把“谁做了什么”留下证据。5. 排查链路当 AI 构建的内部工具出问题先查哪里AI 帮你构建完工具之后流程并没有结束。真实世界中查询可能报错、页面可能空白、数据可能对比不上、权限可能出现偏差。这里我把排查链路总结成一个固定顺序遇到问题不要乱跳步骤。5.1 第一层看数据源连通性内部工具里相当一部分问题出在数据源本身。数据库 IP 变更、密码轮换、连接数打满、网络策略调整都会导致查询失败。排查时先看工具里的“Query 测试”是否通过。如果 Query 能正常执行但页面没数据说明问题在数据绑定不在数据源。如果 Query 本身就执行失败就去看数据库的错误码比如超时、拒绝连接、权限不足。这类问题在低代码平台里通常不会太隐蔽。5.2 第二层检查查询参数和数据映射页面空白或数据不对最常见的原因是参数绑定失效。比如你让表格按当前选中用户过滤但某个字段改名了AI 更新字段时没有同步事件链里的绑定结果就是页面明明配置了过滤却拿到全量数据。排查方法是逐个检查组件的绑定表达式从 React 组件向 Query 传参的链路是否完整。重点确认参数名、字段名、状态变量名是否一致以及加载顺序是否正确。5.3 第三层核对权限和角色权限问题最容易被误判成功能问题。用户反馈“看不到按钮”或“保存失败”很有可能是该角色没有被授予相关操作的权限而不是逻辑出问题。先检查当前用户的角色和应用的权限配置再进入事件逻辑排查。这也是我认为权限配置不应该完全交给 AI 的原因。人的权限边界和 AI 的能力边界必须分开。AI 可以帮你把按钮事件写上但谁点这个按钮、点击后能造成什么影响必须由业务负责人确认。5.4 第四层回看版本和发布状态在低代码平台里经常遇到一个诡异场景开发者明明在编辑器里改好了但使用者访问的页面还是旧的。这通常是因为修改没有发布或者当前应用发布到了测试环境而用户访问的是生产环境入口。进入发布页查看当前应用的版本状态、最近发布时间、当前发布环境是否和用户访问地址一致。如果版本和权限都没有问题再回头审视跨环境的数据源配置。5.5 第五层确认是不是平台本身的边界最后一层是平台边界问题。ToolJet 再灵活也不是所有逻辑都适合在配置层完成。比如高频的实时数据推送、复杂算法计算、超大数据量表格渲染无论 AI 怎么配置平台性能都可能不够理想。遇到这类情况正确做法不是硬调而是考虑把计算下沉为 API 服务或者替换为更适合场景的技术方案。这条判断很简单如果 AI 的配置看起来逻辑完全正确但实际性能始终过不了关那就说明这个需求不该由这个平台来完成。技术选型问题不是配置优化能解决的。6. 我判断这套组合真正适用的边界在哪里如果把“Claude Code / Codex ToolJet”当成一种新范式我倾向于把它的核心价值定义在“把内部工具的构建从代码生命周期转向对象操作生命周期”。工具不再是一个需要持续部署的软件项目而是一组可以被创建、修改、审查、发布和回收的配置对象。AI 在其中承担了“熟练操作员”的角色而人还是业务规则的最终责任人。适配这套组合的团队特征大致有这些已经有一定数量内部系统的需求但开发资源长期不足。团队具备基础的数据建模和权限设计能力能梳理清楚数据源。需求往往可归结为“填表、查询、审批、展示、导入导出、状态更新”。团队接受低代码平台作为正式生产力工具而不是临时拖拽工具。不太适合的场景也很明确高度复杂的业务规则比如涉及大量事务一致性、对账、强事务校验。对前端体验有极致要求的内部产品。需要和多个外部系统进行实时双向同步的场景。团队没有任何数据治理意识连主数据源都还没有统一。如果你已经决定往这个方向走别急着把所有流程一次性搬进平台。我建议先做三件事选一个真实的、低风险的内部小工具需求做试点比如周报汇总后台或测试数据管理面板。全流程用 AI 构建但每次修改都由人工在界面审查一遍。跑通一个季度之后再评估是否扩大范围。这套流程的价值不在于“AI 帮你写代码多快”而在于“AI 帮团队把一次性开发变成可持续维护的配置”。这个转变比任何生成代码的工具都更接近内部工具的本质。