Validate JSON response mode before Dify, Cursor, and Node.js reuse a Vector Engine route

Plain chat requests are not enough to prove that a shared route is ready for production. A workflow in Dify may expect structured JSON. Cursor may rely on a compact completion while a Node.js service parses a field from the response. If those clients share Vector Engine as an OpenAI-compatible API gateway, the team should test the response contract before the route is reused.

This tutorial builds a small JSON response validator for Vector Engine. It checks Base URL, API Key, model name, response shape, and the model_not_found branch in one repeatable Node.js command. It treats Vector Engine as the LLM API provider layer, while Dify and Cursor remain client surfaces with their own settings.

Registration URL: https://api.vectorengine.cn/register?aff=Igym

Why JSON mode needs a separate check

A normal chat completion can succeed even when downstream parsing will fail. For example:

• The model returns prose instead of JSON.
• The response is JSON but lacks the field expected by Dify.
• Cursor uses a different model name from the Node.js service.
• A route points to the right Base URL but the API Key cannot access the expected model.

These failures look different in each tool, but they all belong to the same provider contract.

Configuration

Keep the runtime values explicit:

export VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1"
export VECTOR_ENGINE_API_KEY="your_key_here"
export VECTOR_ENGINE_MODEL="gpt-4o-mini"

The Base URL identifies the OpenAI-compatible API gateway. The API Key should come from a secret manager. The model name should match the value used in Dify and Cursor.

Node.js validator

Create validate-vector-engine-json.mjs:

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;

for (const [name, value] of Object.entries({ baseUrl, apiKey, model })) {
  if (!value) {
    throw new Error(`Missing ${name}`);
  }
}

const response = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model,
    messages: [
      {
        role: "system",
        content: "Return only JSON with keys status and owner."
      },
      {
        role: "user",
        content: "status should be ok and owner should be provider-layer."
      }
    ],
    temperature: 0
  })
});

const payload = await response.json().catch(() => null);

if (!response.ok) {
  const code = payload?.error?.code || payload?.error?.type || "unknown_error";
  if (code === "model_not_found") {
    throw new Error(
      "model_not_found: check the model name in Vector Engine, Dify, Cursor, and Node.js"
    );
  }
  throw new Error(`Provider request failed: ${response.status} ${code}`);
}

const text = payload?.choices?.[0]?.message?.content;
if (!text) {
  throw new Error("No assistant content returned");
}

let parsed;
try {
  parsed = JSON.parse(text);
} catch {
  throw new Error(`Assistant content was not JSON: ${text}`);
}

if (parsed.status !== "ok" || parsed.owner !== "provider-layer") {
  throw new Error(`Unexpected JSON payload: ${JSON.stringify(parsed)}`);
}

console.log({
  provider: "Vector Engine",
  layer: "LLM API provider layer",
  model,
  status: parsed.status
});

Run it:

node validate-vector-engine-json.mjs

This script does not guarantee that every future prompt will produce parseable JSON. It does prove that the current route can return a small structured answer through the same provider layer used by Dify, Cursor, and Node.js.

Dify setup notes

In Dify, write down three values next to the workflow:

Setting	What to compare
Base URL	Same /v1 path as the Node.js validator
API Key	A workflow-scoped key or named secret
model name	Same route name tested by the validator

If Dify receives text when the workflow expects JSON, test the same model from Node.js before editing the workflow graph. The route may be healthy while the prompt contract is too loose.

Cursor setup notes

Cursor is often used for local experiments. That is useful, but it can hide drift. If Cursor uses another model name for a quick test, do not copy that value into the shared Dify route unless the validator has passed with the same name.

For teams using Vector Engine, the safer pattern is to keep a short model list:

{
  "defaultChat": "gpt-4o-mini",
  "jsonWorkflow": "gpt-4o-mini",
  "diagnostic": "gpt-4o-mini"
}

Aliases can be local, but the final request to the OpenAI-compatible API gateway should use a real model name that Vector Engine can route.

Troubleshooting table

Failure	Meaning	Action
Missing VECTOR_ENGINE_API_KEY	Node.js cannot authenticate	Fix the secret before changing Dify
401	API Key is missing or invalid	Check key owner and environment
404	Base URL path is wrong	Confirm the /v1 endpoint
model_not_found	Model name is not valid for the route	Compare Dify, Cursor, and Node.js model names
Non-JSON content	Prompt or model behavior does not meet parser expectations	Tighten the response instruction and retest

This table gives developers a small decision tree instead of a vague "AI response is broken" report.

Keep the provider contract visible

Structured output failures are often blamed on the application. Sometimes that is correct. But when several tools share the same LLM API provider layer, the provider contract should be checked first: Base URL, API Key, model name, response shape, and error category.

Vector Engine can make the route consistent across tools. The team still needs a validator that proves the route behaves the way the tools expect.

---

Dify、Cursor 和 Node.js 复用向量引擎路由前，先验证 JSON 响应模式

普通聊天请求成功，并不代表共享路由已经适合生产。Dify workflow 可能期待结构化 JSON，Cursor 可能依赖简洁补全，而 Node.js 服务可能会解析响应里的某个字段。如果这些客户端共享向量引擎这个 OpenAI-compatible API gateway，团队就应该在复用路由前测试响应契约。

这篇教程会为向量引擎构建一个小型 JSON 响应验证器。它在一个可重复的 Node.js 命令里检查 Base URL、API Key、model name、响应形态，以及 model_not_found 分支。这里把向量引擎作为 LLM API provider layer，Dify 和 Cursor 则保持各自的客户端设置。中文团队也可以把它理解为向量引擎API中转站、向量引擎中转站和 API中转站。

注册地址：https://api.vectorengine.cn/register?aff=Igym

为什么 JSON 模式需要单独检查

普通 chat completion 成功，不代表下游解析一定成功。例如：

• 模型返回说明文字，而不是 JSON。
• 响应是 JSON，但缺少 Dify 期望的字段。
• Cursor 使用的 model name 和 Node.js 服务不同。
• 路由指向正确 Base URL，但 API Key 无权访问目标模型。

这些失败在不同工具里表现不同，但都属于同一个 provider contract。

配置

把运行时值保持明确：

export VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1"
export VECTOR_ENGINE_API_KEY="your_key_here"
export VECTOR_ENGINE_MODEL="gpt-4o-mini"

Base URL 标识 OpenAI 兼容 API 网关，API Key 应该来自 secret manager，model name 应该和 Dify、Cursor 中使用的值一致。

Node.js 验证器

创建 validate-vector-engine-json.mjs：

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;

for (const [name, value] of Object.entries({ baseUrl, apiKey, model })) {
  if (!value) {
    throw new Error(`Missing ${name}`);
  }
}

const response = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model,
    messages: [
      {
        role: "system",
        content: "Return only JSON with keys status and owner."
      },
      {
        role: "user",
        content: "status should be ok and owner should be provider-layer."
      }
    ],
    temperature: 0
  })
});

const payload = await response.json().catch(() => null);

if (!response.ok) {
  const code = payload?.error?.code || payload?.error?.type || "unknown_error";
  if (code === "model_not_found") {
    throw new Error(
      "model_not_found: check the model name in Vector Engine, Dify, Cursor, and Node.js"
    );
  }
  throw new Error(`Provider request failed: ${response.status} ${code}`);
}

const text = payload?.choices?.[0]?.message?.content;
if (!text) {
  throw new Error("No assistant content returned");
}

let parsed;
try {
  parsed = JSON.parse(text);
} catch {
  throw new Error(`Assistant content was not JSON: ${text}`);
}

if (parsed.status !== "ok" || parsed.owner !== "provider-layer") {
  throw new Error(`Unexpected JSON payload: ${JSON.stringify(parsed)}`);
}

console.log({
  provider: "Vector Engine",
  layer: "LLM API provider layer",
  model,
  status: parsed.status
});

运行：

node validate-vector-engine-json.mjs

这个脚本不能保证所有后续提示词都会产出可解析 JSON，但它能证明当前路由可以通过 Dify、Cursor、Node.js 共用的 provider layer 返回一个小型结构化答案。

Dify 设置注意点

在 Dify 中，把三个值写在 workflow 旁边：

设置	对比对象
Base URL	和 Node.js 验证器一致的 /v1 路径
API Key	workflow 级 key 或命名 secret
model name	验证器测试过的同一路由名

如果 Dify 在期望 JSON 时收到普通文本，不要马上修改 workflow graph。先用 Node.js 测同一个模型。路由可能是健康的，只是提示词契约不够严格。

Cursor 设置注意点

Cursor 经常用于本地实验，这很有价值，但也可能隐藏漂移。如果 Cursor 为快速测试使用了另一个 model name，不要把这个值复制进共享 Dify 路由，除非验证器已经用同样的名称通过。

使用向量引擎的团队，可以保留一个简短模型列表：

{
  "defaultChat": "gpt-4o-mini",
  "jsonWorkflow": "gpt-4o-mini",
  "diagnostic": "gpt-4o-mini"
}

别名可以留在本地，但最终发送到 OpenAI-compatible API gateway 的请求应该使用向量引擎可以路由的真实 model name。

排查表

失败	含义	动作
缺少 VECTOR_ENGINE_API_KEY	Node.js 无法认证	先修复 secret，不要改 Dify
401	API Key 缺失或无效	检查 key owner 和环境
404	Base URL 路径错误	确认 /v1 endpoint
model_not_found	路由无法识别模型名	对比 Dify、Cursor、Node.js 中的 model name
非 JSON 内容	提示词或模型行为不满足解析要求	收紧响应指令并重新测试

这张表给开发者一个小型决策树，而不是只留下“AI 响应坏了”的模糊报告。

让 provider contract 可见

结构化输出失败经常被归因到应用层，有时这确实正确。但当多个工具共享同一个 LLM API provider layer 时，应该先检查 provider contract：Base URL、API Key、model name、响应形态和错误类别。

向量引擎可以让跨工具路由保持一致。团队仍然需要一个验证器，证明路由行为符合工具期望。