用 ToolJet MCP 把一个复杂的召回响应控制台搭出来后我发现它不是在写代码

很多人用 AI 搭建内部工具的误区是让它写一套 React 代码然后部署，但这样一来，后续只要业务逻辑变了，你得重新 prompt 或者手动改代码。我最近试了 ToolJet MCP，它的逻辑是让 AI 直接调用 ToolJet 的 API 来创建页面、组件和查询。这意味着 Codex 跑完之后，产出的是一个标准的 ToolJet 应用，你依然可以在可视化编辑器里像拖拽一样去修改它，而不是面对一堆冷冰冰的源代码。

这次实操的任务量其实挺大，我给 Codex 喂了一个 1400 字的详细需求文档，要求它构建一个服务于南澳某制造企业的召回响应控制台（Recall Response Console），涉及质量、运营、合规、供应链和客户响应五个部门。

最终生成的这个应用规模相当客观：包含了 3 个页面，里面塞了 10 个数据表、109 行种子数据、28 个查询以及 109 个组件。

在具体的构建过程中，我给 Codex 的核心指令非常简单：

Build this application in ToolJet. Follow the attached brief, keep the data consistent across every page, and verify each phase before moving on.

这个控制台的分页逻辑很清晰。第一个页面是 Recall Command Centre（召回指挥中心），这里需要展示组合级别的 KPI，比如当前活跃的召回数、风险单位数、已回收单位数、财务风险敞口以及完成率。页面下方有一个高优先级召回的重点区域，标注了严重程度、召回原因、受影响批次、单位数量和监管状态，甚至要把受影响库存从生产到回收的全链路进度给可视化出来。

在这个页面里，有一个覆盖所有召回记录的组合表格，支持通过状态、严重程度、类别、负责人、日期和地区进行过滤，还能搜索产品、SKU、批次和召回 ID。页面底部的视图则集中在回收进度、风险敞口、地理分布和召回活动这几块。

当你点击某个具体的召回记录时，会跳转到第二个页面：Recall Case & Response Workspace（召回案例与响应工作区）。这个页面是给具体经办团队用的，而不是给管理层看概览的。

以我看到的实测案例为例，页面会详细显示该案件的影响情况：受影响单位 18,420 个，已定位 16,210 个，已隔离 13,840 个，已回收 11,920 个。整个流程从问题检测（Issue Detected）开始，依次经过调查（Investigation）、启动召回（Recall Initiated）、遏制（Containment）、回收（Recovery）、验证（Verification）直到关闭（Closure）。

这种构建方式最让我觉得舒服的一点是，它把 AI 的能力变成了“配置员”而非“程序员”。如果以后财务部门说要加一个审批步骤，或者合规部门要改一个字段，我不需要重新跑一遍生成流程，直接在 ToolJet 的画布上改就行了。

如果你想尝试这种链路，可以参考这个仓库：

https://github.com/ToolJet/tooljet-mcp