用 ToolJet MCP 与 Jev 构建评论风暴分析器

什么是评论风暴分析器？

产品发布当天，用户评论会瞬间涌来。一张只有一个人会用的共享表格，从那一刻起就彻底失去了扩展能力。ToolJet MCP 与 TypeSafe 的决策模型 Jev 组合，可以用一段提示词直接生成一个可运行、受权限管控的应用——这就是评论风暴分析器。

它的工作方式并不复杂：Jev 读取每条评论，返回情感、主题、紧急程度以及支撑判断的原文句子；人来做最终标签的决定。最终产物是一页式简报，包含标题、主题磁贴、可筛选的评论流，以及一份紧急跟进清单。

完整运行后的 Review Storm Analyzer：100 条评论全部由 Jev 打标，Jev 耗时 00:06.4，产品质量是最大主题，38 条被标记为需要跟进。

如何对评论洪流做分流？

评论洪流的分流逻辑可以拆成三步：给每条评论打标、把最响亮的主题聚出来、把紧急跟进项顶到最前面。ToolJet MCP 让编码智能体直接在 ToolJet 内部把这个流程构造成一个可用应用，页面、查询和数据模型全部自动接好。

• 加载：一条 RunJS 查询通过 12 个并行 worker 把批次发送给 Jev。
• 打标：Jev 返回情感、主题、紧急标记（紧急概率 50% 及以上）以及支撑该标签的句子。
• 复核：简报随结果到达实时更新。分析师可以带着理由修正标签，产品经理可以补充跟进备注。

配置 ToolJet MCP 与 TypeSafe 数据源

先把编码智能体连上 ToolJet MCP，具体步骤参考官方 MCP 概览文档与 GitHub 仓库。然后把 TypeSafe 数据源添加到工作区，并命名为 typesafe——构建提示词里用的就是这个名称。

构建阶段，智能体负责创建应用；运行阶段，应用通过这个数据源向 Jev 发出带类型的问题。这里的关键在于构建时与运行时分离：智能体只在构建时介入一次，之后应用独立运行，不依赖智能体在线。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底推出的开放协议，用于标准化 AI 模型与外部工具、数据源之间的连接方式。可以把它理解成"AI 的 USB-C 接口"：模型不再需要针对每个服务写专用适配器，而是通过统一的协议描述可用工具（tools）、可读资源（resources）和可复用提示（prompts），由客户端（如编码智能体）动态发现并调用。

ToolJet MCP 则是把 ToolJet 这个低代码平台的内部能力——工作区、数据源、查询、页面、权限组——暴露成一组 MCP 工具。编码智能体接入后，就能像调用普通函数一样创建表、接线查询、布置页面组件并设置 RBAC，而不必手写 ToolJet 的 JSON 配置文件。这正是文中"一段提示词生成整个应用"得以成立的技术前提。

提示词是怎么被收敛出来的？

这个构建经历了好几轮迭代，最终所有需求被收敛进一段提示词里。你完全可以从一开始就用这段提示词，一次性复现同一个评论简报应用。

构建一个名为 Review Storm Analyzer 的一页式 ToolJet 应用，面向产品发布后的产品团队。使用已有的 PostgreSQL 数据源（postgresql_fleet），表包括 rs_batches、rs_reviews、rs_synthetic_labels、rs_runs、rs_analysis、rs_corrections 和 rs_followups，预置 100 条虚构评论。使用已有的 typesafe 数据源（Jev）为每条评论返回情感、主题、紧急标记和支撑句。展示标题、三个主题磁贴、Analyze batch 及暂停/恢复按钮、已处理计数与 Jev 计时器、筛选器、评论流、按主题分组的评论、紧急跟进列表，以及用于修正和备注的详情面板。并行运行 12 个 Jev worker，用一次批量插入保存结果。创建 Review Storm - Analysts、Product Managers、Viewers 三个组：只有 Analysts 能运行 Jev 并保存修正，Product Managers 添加备注，Viewers 只能查看。

构建时与运行时的分离是这类 AI 生成应用的关键架构原则。构建时，编码智能体通过 MCP 一次性完成表结构创建、查询接线、页面布局和权限配置，产出一个静态的、自包含的 ToolJet 应用。运行时，应用只依赖它已配置好的数据源（这里是 PostgreSQL 和 typesafe 数据源）即可独立执行，不再需要智能体在线、不再消耗模型 token，也不受智能体会话生命周期影响。

这种分离带来三个直接好处：应用可以长期稳定运行、成本可预测（每次分析只付 Jev 调用的费用）、安全性更好（运行时不需要授予智能体工作区写权限）。它同时也意味着，一旦需求变更，要么重新生成应用，要么手动在 ToolJet 里调整，而不会"自动跟随"提示词变化。

ToolJet MCP 是如何把它建出来的？

智能体先检查工作区，创建七张 PostgreSQL 表，预置 100 条合成评论，然后接线查询、RunJS 分析逻辑、页面和权限。它先用占位标签跑通流程，再切换到通过 typesafe 数据源调用真实的 Jev。

性能数据值得单独拿出来看。首次完整运行耗时 22.9 秒，而 Jev 并不是瓶颈：12 个并行 Jev 调用约 1.1 秒就完成了，真正的拖累是每次约 700ms 且需要排队的 Postgres 查询。改成一次批量插入、并从内存渲染之后，运行时间降到 8.8 秒。录制版本最终跑出 00:06.4 的 Jev 时间。

这个对比说明一个常被忽略的事实：当 AI 调用被并行化之后，基础设施层的数据库往返往往才是真正的性能天花板。把 N 次查询压成一次批量操作，收益远大于优化模型本身。

1.5 倍速录制的 100 条评论运行：计数器爬到 100，Jev 计时器停在 00:06.4，一条评论在详情面板中打开。

并行 worker 与批量插入的取舍值得展开。传统做法是 12 个 worker 各自处理完一条评论就写一次库，形成 100 次独立事务，每次都要经历网络往返、事务提交、索引更新，文中测得每次约 700ms 且互相争抢连接池。批量插入把 100 条结果聚合成单条 INSERT ... VALUES (...), (...) 语句，一次往返、一次提交，把 N 次 700ms 压缩成一次几十毫秒级别的操作。

配合从内存渲染——即前端直接用已加载的结果数组绘制列表，而不是每渲染一行就查询一次数据库——整体运行时间从 22.9 秒降到 8.8 秒。这揭示一条常被忽视的性能规律：AI 应用的瓶颈往往是 I/O 编排而非模型推理。并行化只解决"同时等待多个慢调用"的问题，若下游是串行数据库往返，并行度越高反而会让排队越严重；只有先把 N 次往返压成 1 次，并行的收益才能真正释放。

谁在用评论分流，谁又能打开它？

消费硬件品牌的产品团队、平台卖家和软件团队在发版后，都可以用同一套布局处理任何一波文本反馈。角色分工很清晰：分析师运行 Jev 并保存修正，产品经理补充跟进备注，查看者只能看。

权限不是纸上声明。一个查看者调用写查询时会收到 401 拒绝——这说明服务端确实在执行规则，而不是仅仅在 UI 层隐藏按钮。

RBAC（Role-Based Access Control，基于角色的访问控制） 的核心思路是权限不直接绑在用户身上，而是绑在"角色"上，再把角色分配给用户或组。这样当有 200 名分析师时，只需维护一个 Analyst 角色，而不用为每个人单独配置。文中提到的 Analysts / Product Managers / Viewers 就是三个典型角色。

需要区分的是 RBAC 与 ACL：ACL 是逐资源的白名单（谁能读这张表），RBAC 是按职能分层的抽象（谁属于哪个角色）。ToolJet 的两层结构——平台权限管工作区资源、应用权限管页面/查询/组件——正好对应这种分层。关键判据是"服务端强制执行"：如果权限只在 UI 层隐藏按钮，前端拦截请求即可绕过；而查看者调用写查询返回 401，说明服务端在真正校验 token 里的角色声明，这才是有效的访问控制。

ToolJet 中的基于角色的访问控制

ToolJet 在两个层级上应用 RBAC。平台权限决定谁能触达某个工作区资源；应用权限决定每个组能打开和运行哪些页面、查询和组件。两层都由服务端强制执行。

ToolJet 的基于角色访问控制：角色与组、应用级页面/查询/组件权限，以及服务端规则。

对于评论数据这类客户反馈场景，ToolJet 还提供 SAML SSO、审计日志、Git Sync 和 Docker 自托管等企业级能力，供有需要的团队使用。

核心要点

评论风暴变成一页式简报的关键在于：Jev 负责建议，人负责决定。录制运行中，Jev 在 00:06.4 内为 100 条评论打标，其中 38 条被标记为需要跟进。需要说明的是，所有评论均为合成数据，应用也尚未用真实分析师账号测试过。如果你想把同样的布局指向自己的评论表，只需改动查询指向的 PostgreSQL 表即可。