用ToolJet MCP构建召回响应控制台：AI应用开发实例
原文：https://dev.to/tooljet/building-a-recall-response-console-with-tooljet-mcp-and-examining-tooljets-approach-to-ai-app-126（作者 @karanrathod316）
构建内部应用的初版只是工作的一部分。而更困难的挑战在于，随着流程、数据以及相关人员持续变化，如何使其持续保持实用。
内部工具是不断演进的。运营团队要求增加一个筛选器。财务部门需要添加一个审批步骤。合规团队更新了流程。某个团队需要一个新的字段、不同的表格布局，或是另一种查询相同数据的方式。这些单个请求看起来都很小。但当它们遍布于数十或数百个内部应用时，就会演变成一个远超初始构建的维护难题。
在本教程中，我们希望展示这种方法在实践中的样子。我们向Codex提供了一份详细的制造召回系统需求说明，并使用ToolJet MCP来构建它。最终生成的应用程序规模足够大，能够带我们完整经历一次ToolJet MCP构建的全流程——从规划与验证，到查询、组件及后续迭代——并展示完成后的应用如何在ToolJet平台内保持可编辑状态。
最终应用程序包含10张数据表、109条种子数据、28个查询以及109个组件，分布在三个页面。
- ToolJet MCP 仓库： https://github.com/ToolJet/tooljet-mcp
ToolJet MCP 并未生成复杂的React代码库后直接交付。它利用ToolJet自身的API在平台内部创建了页面、组件、查询、事件、布局和数据。Codex完成操作后，结果仍然是一个标准的ToolJet应用程序。当后续维护该应用的人可能并非当初用提示词创建它的人时，这一点显得尤为重要。
我们让 Codex 构建的应用
原始需求简报约有 1,400 词。它描述了一个为南澳大利亚一家制造公司设计的召回响应控制台，供质量、运营、合规、供应链和客户响应团队使用。
主要指令很简单：
在 ToolJet 中构建此应用。按照附带的需求简报执行，保持所有页面的数据一致，并在进入下一阶段前验证每个阶段。
第一个页面是召回指挥中心。它需要展示活动召回的组合级关键绩效指标，包括风险单位、回收单位、财务敞口和完成率。在下方，优先级最高的召回拥有自己的专版，显示严重性、召回原因、受影响批次、单位数量和监管状态。我们还希望从生产到回收的全过程，受影响库存的进度都清晰可见。
该页面包含一个涵盖所有召回的组合表格。用户可以按状态、严重性、类别、负责人、日期和地区进行筛选，并能搜索产品、SKU、批次和召回ID。页面下半部分则添加了关于回收情况、风险敞口、地理分布和召回活动的视图。
点击某个召回，会打开第二个页面——召回案例与响应工作区。这个页面是为处理具体召回的团队设计的，而非用于监控整个召回组合。
选中的案例显示有 18,420 个受影响单位，已定位 16,210 个，隔离 13,840 个，回收 11,920 个。该页面贯穿了从发现问题、调查、启动召回、遏制、回收、验证到关闭的整个响应流程。它还包含了受影响的生产批次、分销追溯、利益相关方沟通、响应操作、根本原因调查以及审计追踪。
后来，我们给了 Codex 一个更简短的后续指令：
添加另一个与紧急操作相关的页面。
由于数据模型和应用结构已经存在，这次不需要另一份大型需求简报。Codex 复用了 recall_actions 表，并将这个请求转化为一个跨召回的响应台。在迭代评审中，它生成了一个专注于此功能的单一 HTML 产物，而不是另一组零散的文件。
响应台将所有召回中的紧急工作汇总到一个队列中，并按逾期、今日到期、已阻塞和关键操作进行分组。用户可以直接在队列中完成某个操作，也可以打开相关的召回案例以获取更多上下文。
这个应用本身很有用，但它也为我们提供了足够的分析层面，来研究 ToolJet 的 MCP 方式是如何进行生成的。
ToolJet MCP 不仅仅是生成更多前端代码
在 AI 应用构建中，一个常见方向是让编码智能体能够生成更大量的应用程序代码。在许多情况下，这意味着生成 React 组件、数据获取逻辑、状态管理以及将所有部分连接起来所需的粘合代码。
当目标产物本身就是代码库时，这种方法可以工作得很好。代价是，每个生成的应用也会成为另一个需要被理解和维护的代码库。
内部应用往往使这种权衡更加明显。一家公司可能拥有大量小型运营工具，每个工具都有不同的所有者和生命周期。其中许多维护者对业务流程的理解可能远超他们对 React 的理解。
ToolJet MCP 采取了不同的路径。它并不每次都要求模型生成应用程序框架，而是暴露更小的 API 来操作已存在的框架。
Codex（或任何其他编码智能体）可以创建页面、添加组件、配置查询、操作 ToolJet 数据库、连接事件、更改布局以及更新现有对象。模型仍然决定需要构建什么，但它不必将每个决策部分都表达为前端代码。
这使输出保持在 ToolJet 的应用模型之内。通过 MCP 创建的表格仍然是一个 ToolJet 表格组件。数据库操作仍然是一个 ToolJet 查询。由智能体创建的页面仍然出现在正常的页面结构中。
这也为智能体提供了一个更窄的操作面。它可以要求平台执行特定操作，而不是反复生成大段代码，然后再对结果进行推理。
构建在验证阶段中进行
MCP 并没有尝试通过一个庞大的操作来编写整个应用程序。
规划下一个阶段
↓
验证它
↓
修复验证错误
↓
应用该阶段
↓
验证结果
在一个阶段被应用之前，提议的应用规范会被检查（lint）。成功的检查会生成一个临时令牌（token），然后被写操作消耗。如果检查失败，该阶段就不会被写入。
这种验证在构建过程中捕获了几个实际问题。一个数据库列使用了 SQL 保留关键字。另一个绑定可能在组件挂载之前就引用它。一个操作针对的组件使用了错误的属性。这些问题在相应阶段被应用之前就被拒绝了。
这并不能让 AI 生成的应用神奇地变得没有错误。但它确实为智能体提供了一种更有结构化的失败方式。一个糟糕的更改可以被拒绝为一个无效的应用操作，而不是首先变成一大段需要事后调试的坏代码。
同样的理念也适用于组件。平台已经知道表格、容器、输入框或查询是什么。智能体可以基于这些既定契约进行工作，而不是每次都发明自己的版本。当试图控制令牌使用量，并且应用规模变得更大时，这是一种更有用的抽象。
为什么令牌使用量在整个构建过程中下降
在此构建期间，运行时暴露了一个近似的预算计数器。它不是一个精确的使用量表，不应被视为 API 账单，但其显示的模式很有用。
第一个主要回合，涵盖了规划、数据模型和页面 1，使用了大约 19 万令牌。页面 2 及其变更操作使用了大约 8.4 万。后来的“响应台”迭代使用了大约 5.1 万。
第一轮要完成的工作多得多。Codex 必须阅读平台参考文档、理解组件契约、建立数据模型，并创建初始应用程序结构。
后续工作可以重用这些决策。当我们添加“响应台”时，ToolJet MCP 不需要创建另一个数据模型。它重用了 recall_actions，添加了所需的行，并在现有应用程序之上构建了页面。组件类型已被知晓，更广泛的应用程序结构也已在上下文中。
实际好处不仅是更低的令牌使用量。它还意味着后续的更改可以融入相同的应用程序模型，而不是慢慢将项目变成一系列生成的代码路径。
之后你不必被迫继续使用 AI
当你的应用准备好后，下一个变更不一定需要通过 Codex 完成。
对于一个更大的功能，继续使用 ToolJet MCP 可能是合理的。智能体已经理解了应用结构，并且能够进行跨应用的协调变更。对于一个小型的 UI 变更，用户可以直接打开 ToolJet。
生成的表格仍然是一个正常的 ToolJet 组件，可通过可视化构建器进行编辑。
可视化构建器仍然可以正常识别这些组件。用户可以调整表格大小、移动它、修改样式、更改属性，或者添加另一个组件，而无需接触生成原始页面的那个流程。
在通过 MCP 构建之后，我们并没有花很多时间手动编辑这个应用。这并非展示可视化构建器的目的。其价值在于，生成的应用没有丢失平台的常规编辑模式。
同样的情况也适用于数据层。
在构建过程中创建的查询在 GUI 模式下仍然可读：更新 `recall_actions`，条件为行 ID 与所选操作匹配。
在 MCP 构建过程中创建的一个查询仍然可以在 ToolJet 的查询编辑器中打开。在 GUI 模式下，用户无需追溯生成的代码就能看到数据源、表、操作和过滤器。熟悉 SQL 的用户可以在 SQL 模式下工作。不熟悉的则可以使用 GUI。
这一点对于内部软件至关重要，因为维护工作通常最终由理解该工作流程的人承担，而非最初构建该应用的人。
这是 AI 应用构建的另一条路径
看待 AI 智能体构建软件有两种方式。
一种是持续提升智能体生成代码的能力。更好的模型能产出更整洁的组件、更庞大的应用和更少的错误。对于某些类型的软件，这正是你所需要的。
另一种选择是为智能体提供更好的抽象来工作。
ToolJet MCP 采用了第二种方式。模型仍然完成了大量困难的工作：它阅读需求说明、规划应用、决定页面的结构、创建数据模型并连接交互。平台则处理那些已有良好定义的部分。
表格不需要一个新的 React 实现。数据库更新不需要另一个自定义的数据访问层。页面也不需要成为另一个路由问题。
这也是为什么这种模式对于内部应用有意义。首次构建可以很快，而无需将每个应用都变成一个新的工程项目。
如果一家公司最终拥有数百个内部工具，生成它们的能力只是等式的一部分。这些工具还需要在创建者离职后，仍然能被理解和修改。
这次构建留下了什么
最终，我们得到了一个三页的“召回响应控制台”，拥有真实的数据模型、可用的查询、跨页导航、响应操作，以及足够的运营细节，使这个应用超越了演示阶段。
更重要的是，结果仍然表现得像一个 ToolJet 应用。
Codex、Claude Code 或任何其他智能体都可以通过 MCP 继续进行更改。开发者可以在需要时直接使用 SQL。业务用户可以通过 GUI 模式处理查询。有人可以打开可视化构建器调整组件，而无需先去了解 AI 智能体是如何生成它的。
这与生成另一个 React 代码库是不同的结果，即使两种方式最终可能产生非常相似的界面截图。
对于企业内部工具来说，随着应用数量的增长，这种区别变得越来越重要。生成软件正变得越来越便宜。而让所有这些软件保持可维护，将是更困难的问题。
ToolJet MCP 正是基于这个假设构建的。
原文：https://dev.to/tooljet/building-a-recall-response-console-with-tooljet-mcp-and-examining-tooljets-approach-to-ai-app-126（作者 @karanrathod316）