Run Synthetic Prompt Fixtures Against Vector Engine Before Dify or Cursor Changes

A Vector Engine rollout often starts cleanly in one tool and then becomes noisy when more tools join. Dify may pass a workflow test, Cursor may autocomplete with another model name, and a Node.js service may fail later because its Base URL or API Key points to a different route. Synthetic prompt fixtures give the team a repeatable check before changing the LLM API provider layer.

This tutorial creates a small Node.js fixture runner for Vector Engine. It calls the same OpenAI-compatible API gateway with a controlled prompt set, records status and error codes, and separates model_not_found from authentication, Base URL, and payload issues.

Fixture design

Keep fixtures boring. They should not test product quality or creative output. They should test whether the route responds in a predictable shape.

[
  {
    "name": "short_answer",
    "model": "gpt-4.1-mini",
    "messages": [
      { "role": "user", "content": "Return the word ready." }
    ]
  },
  {
    "name": "json_shape",
    "model": "gpt-4.1-mini",
    "messages": [
      { "role": "user", "content": "Return JSON with keys status and reason." }
    ]
  }
]

Use the same model name that Dify, Cursor, and Node.js will use. If your team keeps different aliases per tool, add those aliases as separate fixtures so the mismatch is visible before release.

Environment variables

VECTOR_ENGINE_BASE_URL=https://your-vector-engine-base-url/v1
VECTOR_ENGINE_API_KEY=replace-with-your-key
VECTOR_ENGINE_MODEL=gpt-4.1-mini

The Base URL should be the Vector Engine route used by the tool being checked. The API Key should be scoped to the same environment. Do not paste production keys into shared test logs.

Node.js runner

import fs from "node:fs/promises";

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

const fixtures = JSON.parse(await fs.readFile("./fixtures.json", "utf8"));

async function runFixture(fixture) {
  const started = Date.now();
  const response = await fetch(`${baseUrl}/chat/completions`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "authorization": `Bearer ${apiKey}`
    },
    body: JSON.stringify({
      model: fixture.model || defaultModel,
      messages: fixture.messages,
      temperature: 0
    })
  });

  const payload = await response.json().catch(() => ({}));
  const errorCode = payload?.error?.code || payload?.code || null;

  return {
    name: fixture.name,
    model: fixture.model || defaultModel,
    status: response.status,
    errorCode,
    latencyMs: Date.now() - started,
    ok: response.ok
  };
}

for (const fixture of fixtures) {
  const result = await runFixture(fixture);
  console.log(JSON.stringify(result));
}

Interpreting results

Result	Likely cause	Next action
401 or 403	API Key missing, expired, or outside scope	Check key ownership before changing prompts
404 with model_not_found	Model name not routed in Vector Engine	Compare Dify, Cursor, and Node.js model names
Network error	Base URL is wrong or blocked	Verify the endpoint and environment
200 but unexpected shape	Caller assumption is too strict	Check response parsing before blaming the gateway

The runner is not a replacement for live monitoring. It is a pre-change check that makes the provider layer less mysterious.

Adding it to a release checklist

Before a Dify workflow change, run the fixtures with the Dify model name and Base URL. Before a Cursor provider update, run the same fixtures with the Cursor configuration. Before a Node.js deployment, run them in the deployment environment with the service API Key.

If all three produce the same status pattern, the Vector Engine route is probably aligned. If one tool differs, pause the rollout and inspect the configuration instead of changing the provider layer blindly.

Registration

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

Closing note

Synthetic fixtures are useful because they are small and repeatable. They let a team test Vector Engine as an OpenAI-compatible API gateway, keep Dify, Cursor, and Node.js aligned, and catch model_not_found before users see a broken workflow.

---

在 Dify 或 Cursor 变更前，用合成提示词样例检查向量引擎

向量引擎的接入常常在单个工具里看起来很顺利，但当更多工具加入后就会变得嘈杂。Dify 可能通过了工作流测试，Cursor 可能用另一个模型名称完成补全，而 Node.js 服务稍后失败，因为它的 Base URL 或 API Key 指向了不同路由。合成提示词样例可以让团队在修改 LLM API provider layer 之前拥有可重复检查。

这篇教程会创建一个小型 Node.js 样例运行器来检查 Vector Engine。它使用受控提示词调用同一个 OpenAI-compatible API gateway，记录状态码和错误码，并把 model_not_found 与鉴权、Base URL、请求体问题分开。

样例设计

样例要保持简单。它们不应该测试产品质量或创意输出，而应该测试路由是否按预期形态响应。

[
  {
    "name": "short_answer",
    "model": "gpt-4.1-mini",
    "messages": [
      { "role": "user", "content": "Return the word ready." }
    ]
  },
  {
    "name": "json_shape",
    "model": "gpt-4.1-mini",
    "messages": [
      { "role": "user", "content": "Return JSON with keys status and reason." }
    ]
  }
]

使用 Dify、Cursor 和 Node.js 都会使用的同一个模型名称。如果团队为不同工具保留不同别名，就把这些别名作为单独样例加入，让不一致在发布前暴露出来。

环境变量

VECTOR_ENGINE_BASE_URL=https://your-vector-engine-base-url/v1
VECTOR_ENGINE_API_KEY=replace-with-your-key
VECTOR_ENGINE_MODEL=gpt-4.1-mini

Base URL 应该是被检查工具实际使用的向量引擎路由。API Key 应该属于同一个环境范围。不要把生产密钥粘贴到共享测试日志里。

Node.js 运行器

import fs from "node:fs/promises";

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

const fixtures = JSON.parse(await fs.readFile("./fixtures.json", "utf8"));

async function runFixture(fixture) {
  const started = Date.now();
  const response = await fetch(`${baseUrl}/chat/completions`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "authorization": `Bearer ${apiKey}`
    },
    body: JSON.stringify({
      model: fixture.model || defaultModel,
      messages: fixture.messages,
      temperature: 0
    })
  });

  const payload = await response.json().catch(() => ({}));
  const errorCode = payload?.error?.code || payload?.code || null;

  return {
    name: fixture.name,
    model: fixture.model || defaultModel,
    status: response.status,
    errorCode,
    latencyMs: Date.now() - started,
    ok: response.ok
  };
}

for (const fixture of fixtures) {
  const result = await runFixture(fixture);
  console.log(JSON.stringify(result));
}

如何解读结果

结果	可能原因	下一步
401 或 403	API Key 缺失、过期或超出范围	先检查 Key 归属，不要急着改提示词
404 且包含 model_not_found	模型名称未在向量引擎中路由	比对 Dify、Cursor 和 Node.js 的模型名称
网络错误	Base URL 错误或被网络拦截	核对入口和环境
200 但形态不符合预期	调用方解析假设过强	先检查响应解析，不要直接归因到网关

运行器不能替代线上监控。它是变更前检查，让提供方层不再那么难判断。

放入发布检查清单

在 Dify 工作流变更前，使用 Dify 的模型名称和 Base URL 运行样例。在 Cursor 提供方配置更新前，使用 Cursor 配置运行同一批样例。在 Node.js 部署前，用服务所在环境和服务 API Key 运行。

如果三者产生相同的状态模式，说明 Vector Engine 路由大概率已对齐。如果某个工具不同，先暂停发布并检查配置，而不是盲目修改提供方层。

注册

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

结语

合成样例有价值，是因为它们足够小且可重复。它们可以帮助团队把向量引擎作为 OpenAI-compatible API gateway 来测试，让 Dify、Cursor 和 Node.js 保持一致，并在用户遇到故障之前发现 model_not_found。对向量引擎API中转站、向量引擎中转站和 API中转站 来说，这类检查能把接入过程从猜测变成可复核的工程流程。