wix-base44-connector

基于 Base44 构建 Wix 应用

Wix 连接器已连接；以下是如何在其上构建应用——收集网站上下文，查找 API 并从文档中了解其契约，然后编写代码。全面发现：端点、路径、文档 URL、请求和响应字段都来自下面的调用，绝不能凭记忆或模式推断。遇到 404 或空结果 ⇒ 继续发现，不要穷举变体。示例用于说明机制，可能会过时——依赖示例前务必核实。

每项 Wix 任务都要先获取网站上下文（见下文的 wx.context）。它会报告网站实际拥有的内容及各部分的配置方式，确保每次调用都以实际情况为目标，而不是根据名称猜测。这是任务的第一步，不是一次性设置：后续轮次不会继承先前轮次的上下文，因此在基于先前工作继续构建或调用 Wix API 前，必须重新读取上下文。

管理或管理员任务要从操作指南开始：调用 wx.mgmtRecipes（Learn Wix），并遵循适用的指南。操作指南会明确说明 API 不支持什么、批量调用实际会写入哪些字段，以及两次调用必须按什么顺序执行——仅凭 schema 推断这些内容，通常要经过好几次错误才搞得清楚。wx.search 也会为匹配的操作指南排序（hits 中的操作指南条目），因此从方法开始的搜索也能找到它们。

在此技能中：

• 要构建什么？——面向访客、面向所有者，还是代为执行管理任务——根据用户意图按每个请求分别决定，并遵循各自的流程
• 辅助工具——每次执行都会首先打开的 wx.* 加载器
• 收集上下文——wx.context，报告网站实际拥有的内容
• 了解 Wix——查找 API，了解其契约
  • 管理操作指南——管理员任务的第一站（wx.mgmtRecipes）
  • 搜索和浏览——使用 wx.search 搜索方法、操作指南和文章
  • 阅读文档页面——使用 wx.page 查看已定位的文档 URL
  • 规范索引——使用 wx.spec 查看已定位方法的精确 schema
• 编写代码
  • 构建过程中的管理操作——由你在 exec_tool 中执行
  • 后端函数——由应用以所有者身份执行
  • 访客身份验证和 Wix 托管流程——通过访客客户端、重定向会话、无头 OAuth 应用实现——也可以使用 wix-vibe-headless 引导构建完整的垂直领域应用

你要构建什么？

Wix 有两种身份：访客和管理员，每种身份都有各自的流程。执行每项请求之前，先根据用户想做什么（而不是所用技术）判断请求属于哪种身份：

• 访客 — 使用网站的人：浏览、预约、购买、以会员身份登录。使用访客令牌，通过一个共享访客客户端从浏览器调用。
• 管理员，自行构建 — 所有者自己的管理界面：自定义视图、批量操作、内部工具。使用管理员连接器令牌，在前端调用的后端函数中从服务器端操作。
• 管理员，代为操作 — 用户想要现在就管理业务，而不是开发应用：创建产品、更改设置、导入联系人。使用管理员令牌，在 exec_tool 中按需操作；不会将任何内容发布到应用中。

所有者已经拥有完整的 Wix 控制面板来运营业务，其中包括订单、产品、预约、设置等，因此是否构建管理员功能应由用户决定，而不是默认需要填补的空缺。如果请求同时涉及访客和管理员部分，两者各自遵循自己的流程。

如果请求没有说明属于哪种身份，就用用户的说法询问（这个功能是给谁用的），不要使用技术术语（身份、令牌、流程）。如果你不询问就自行判断，请用同样的方式告知用户你的选择。

以下规则由这一区分得出：

• 结账必须使用访客令牌，绝不能使用管理员令牌 — 包括此应用为访客创建的结账。管理员令牌确实会返回一个结账 URL，而这正是陷阱：该 URL 属于网站，而非买家（购物车不会持久保存，无法恢复未完成的结账，也无法归因），并且重定向会话会直接拒绝该 URL（403）。只有来自 OAuth 应用重定向列表中 URL 的请求才能返回此应用（见下文的访客身份验证和 Wix 托管流程）。
• 尚无 OAuth 应用并不是改用管理员令牌的理由。 wx.ensureOAuthApp 会返回 clientId，如果网站尚无应用，还会创建该应用——这是访客流程的第一步。任何人都可以通过这个公开的 clientId 创建匿名访客令牌；无需访客登录。
• 无需登录也仍然是访客。 asServiceRole 管理的是此应用自身的数据访问权限，并不决定 Wix 看到的是哪种身份：公开页面上的 Wix 调用使用访客令牌。只有当功能属于所有者端时才使用管理员令牌，绝不能因为没有人登录就使用它。
• 页面之外的所有者端工作 — webhook、计划任务、明确授权的高权限操作 — 也属于管理员流程，应在后端函数中执行。

visitor pages ──(visitor token)────────────────────────► wixapis.com
admin pages   ──► base44/functions/… ──(admin token)────► wixapis.com
exec_tool     ──(admin token, ad hoc management)────────► wixapis.com

付款由连接的网站负责。 访客购买的任何商品，都会在此应用将其引导至的 Wix 托管页面上付款，并使用网站已有的支付服务提供商。Base44 的 <available_payment_providers> 说明针对的是由 Base44 托管的结账，不适用于这些流程；无论其中列出或排除哪些支付服务提供商，这些流程都不受影响。

辅助工具

研究和探查在 exec_tool 中运行，所有 exec 都由同一个加载器打开（exec 之间不共享状态 — 每轮都要重新加载；模块位于此文件旁边的磁盘上，仅在首次访问时以网络作为回退）：

const fs = require("fs"), P = ".agents/skills/wix-base44-connector/utils.cjs";
if (!fs.existsSync(P)) { fs.mkdirSync(".agents/skills/wix-base44-connector", { recursive: true });
  fs.writeFileSync(P, await (await fetch("https://www.wix.com/skills/wix-base44-connector/scripts/utils.cjs")).text()); }
const wx = require(require("path").resolve(P));

wx 导出以下辅助工具：

• wx.post/get/patch/put/del(url, [body], token?) — JSON 传输，每种动词对应一个（get/del 不接受 body）：使用 token 作为 Bearer；非 2xx 响应会 抛出 API 自身的错误
• wx.clip(value) — 限制返回值的大小：超出上限时返回 { truncated, total, head }；将 undefined 显示为 null，让缺失状态清晰可见
• wx.context(token) — 网站的完整动态上下文报告；内容较少时内联返回，否则保存为带标题大纲的 Markdown 文件
• wx.browse(menuUrl, { include, filter, depth }) — 确定性地遍历文档门户菜单
• wx.search(term, { type, max, lines }) — 在一个 hits 列表中返回排序后的 REST 文档、Headless 文章和管理配方；响应类型请参见 Search and browse。只有方法命中项带有端点。
• wx.page(docsUrl) — 读取文档页面；其中的示例会以标题和行号的形式返回
• wx.bash(cmd) — 对已保存文件运行 shell 命令（GNU grep/sed；awk 为 mawk；不支持 rg）
• wx.spec(docsUrl | code) — 获取方法的精确架构，以及文档自带的请求示例标题（保存在 examplesPath）；传入命中项的 docsUrl 可直接加载，也可传入原始 code 自行查询索引
• wx.mgmtRecipes(q?) — 管理配方索引；不带参数时返回类别，输入一个词则返回匹配的配方
• wx.ensureOAuthApp(token, { name, redirectUris, redirectDomains }) — 查找或创建无头 OAuth 应用，按名称查找，或以 origin: "base44-app" 创建，并将重定向列表合并到现有允许列表中；返回 { clientId, created }。浏览器会使用 clientId 生成访客令牌。当 context 报告中没有 OAuth 应用时，或在使用会返回此应用的 Wix 托管流程之前运行此方法 — 请参见 Visitor authentication and Wix-hosted flows
• wx.installApp(appDefId, siteId, token) — 在网站上安装 Wix 应用（Apps Installer）。如果发现某个 API 所属的应用尚未安装在网站上，请先安装 — 这是一次调用即可满足的前置条件，不是改用手动构建替代方案的理由。appDefId 来自 search 或 Apps-Created-by-Wix 表；siteId 来自 context（网站报告）

默认情况下，Search 会跨 REST、管理配方和 Headless 发起一个合并请求。 服务会将它们统一排序并交错返回方法和文章；辅助工具会保留该顺序。max 限制合并结果的数量（默认为 15）。

每个辅助工具都会在结果大小合适时内联返回（≤ 4,000 个字符 — exec 结果会在约 5,000 个字符处截断）。 较大的结果会保存到 .agents/skills/wix-base44-connector/tmp/，并返回 { path, bytes, lines, outline } — outline 是你定位文件内容的索引。处理已保存文件分两步：用 wx.bash("grep -n 'term' <path> | head -40") 查找（或跨所有保存文件查找： grep -rn 'term' .agents/skills/wix-base44-connector/tmp/），然后用 read_file 引用内容 — 使用 grep 指定行号的 offset/limit 窗口；若整个文件不超过 45K 上限，也可读取全文。

收集上下文 — 动态上下文报告

const { accessToken } = await base44.asServiceRole.connectors.getConnection("wix");
return await wx.context(accessToken);

一份报告包含：已安装应用 及其 ID（包括 Stores 的目录版本 — V1 还是 V3 决定其端点）、OAuth 应用 ID（也是访客 clientId）、区域设置、货币、CMS 集合。 报告为空 = 令牌无效，绝不表示网站为空。

报告中没有 OAuth 应用，表示该网站尚未创建 OAuth 应用。对于访客操作的任何功能，都应使用 wx.ensureOAuthApp 创建应用 — 一次调用即可返回前端用于生成访客令牌的 clientId — 并基于访客流程构建功能。

超过 4,000 个字符的报告会完整保存到临时 Markdown 文件中。结果包含其路径、字节数和行数，以及标题大纲。读取该文件以检查网站上下文。

了解 Wix — 查找 API 并熟悉其契约

管理操作指南 — 管理任务的首选入口

按类别整理的管理流程 — ecommerce、bookings、stores、cms、google-ads、sites、contacts、 get-paid、marketing、pricing-plans、events、blog、forms、restaurants、domains、media 等：

await wx.mgmtRecipes();           // categories with counts
await wx.mgmtRecipes("stores");   // a category's list — or any task word: wx.mgmtRecipes("coupon")
// each row points at its recipe: `file` when the wix-manage skill is installed — read_file it
// straight off disk — else `url`: wx.page(url), whole when small, saved + outline when big

操作指南包含方法页面中没有的前提条件、执行顺序和注意事项。wx.search 也会在其 hits 列表中为这些操作指南排序，因此无论从哪种方式搜索，都能找到它们。

搜索和浏览

wx.search 会返回已保存文件的引用和排序后的命中结果。每个命中结果都是一个方法、文章或操作指南，通过其 title 字段标识；只有方法才有端点。

type Section = { title: string; line: number }; // 1-based line in the saved file
type SearchResult = {
  path: string; bytes: number; lines: number; note?: string;
  hits: ({ docsUrl: string } & (
    | { method: string; endpoint: string | null; gist?: string; examples?: Section[] }
    | { article: string | null; line: number; outline?: Section[] }
    | { recipe: string | null; line: number; lines: number;
        file?: string; steps?: string[]; calls?: string[] }
  ))[];
};

path 指向的文件保留了完整的返回 Markdown，而可选详情和超出数量限制的命中结果可能会从内联响应中省略。无法解析的标题或端点会显示为 null。如果没有结果块可供解析，head 和 note 会替代 hits；达到最终大小限制时，返回的内容会变为 { truncated: true, total: number, head: string }，而不是上述对象。

// name the method? search finds it in one call:
const result = await wx.search("stores v3 update product"); // SearchResult above
// Keep all hit kinds; only a method hit has an endpoint to call and a schema for wx.spec.
// exploring an unfamiliar product? browse is deterministic — menuUrl alone orients (children + counts);
// filter before listing methods. browse works for both portals this skill uses — REST
// (api-reference) and WIX_HEADLESS (go-headless) — just pass that portal's menu URL.
await wx.browse("https://dev.wix.com/docs/api-reference/business-solutions/bookings/bookings",
                { include: ["METHOD"], filter: "resched", depth: 4 });
// non-REST portal — same call, that portal's menu URL:
await wx.browse("https://dev.wix.com/docs/go-headless/authentication", { depth: 2 });

// don't know where it lives? search ranks, never says "no match" — drop wrong-product hits
await wx.search("pause a pricing plan subscription and resume it");
// Same SearchResult: methods, articles, and recipes remain in ranked order.

产品及其功能 — 常见产品及部分功能列表：

• Stores — 产品 · 类别 · 产品选项和变体 · 库存 · 促销 · +7 项
• Bookings — 服务 · 预约 · 课程 · 员工 · 时段 · 候补名单 · +7 项
• eCommerce — 购物车 · 结账 · 订单 · 订单履行 · 折扣规则 · +7 项
• Events — 活动 · 票券定义 · RSVP · 签到 · +6 项
• Restaurants — 菜单 · 菜品 · 菜品附加选项 · 在线订单 · 预订 · +9 项
• Blog — 文章 · 草稿文章 · 类别 · 标签 · +3 项
• CMS — 数据项 · 数据集合 · 集合权限 · 外部数据库 · +4 项
• Pricing Plans — 计划 · 订单 · 定期订阅 · 免费试用期 · +4 项
• Members & Contacts — 联系人 · 标签 · 扩展字段 · 会员 · 徽章 · +7 项
• Forms — 表单架构 · 表单提交 · 交互式表单会话 · +3 项
• Loyalty — 忠诚度积分 · 积分获取规则 · 等级 · 奖励 · +5 项

完整列表 — 全部 36 种产品、其功能及文档路径：references/CAPABILITY_MAP.md。

如需深入了解字段、枚举值或确认某项是否不存在，请查阅规范索引——只有它能证明某项不存在。

阅读文档页面

方法页面大小超过 100 KB，包含 REST 和 SDK 两部分，重复列出字段名但类型不同 — 请在同一次 exec 中完成映射和截取；坐标供你的代码使用，无需再执行一次：

const pg = await wx.page(docsUrl);   // whole text when small; else { path, bytes, lines, outline }
// pg.examples lists the page's worked requests as { title, line } — a complete request (URL,
// headers, body) is usually all you need: read_file(pg.path, offset: <its line>)
// anything else, windowed to your term in the same round:
return wx.bash(`sed -n '/^## REST API/,/^## JavaScript SDK/p' ${pg.path} | grep -B5 -A40 -i 'examples\\|<term>' | head -c 3800`);
// a giant fenced example → its field vocabulary instead of paging it:
// wx.bash(`sed -n '<a>,<b>p' ${pg.path} | grep -oE '"[a-zA-Z]+":' | sort -u | head -60`)

search 也会将原始内容保存在内联命中结果旁边 — 如果命中的六行内容不够，请对其 path 执行 grep。

规范索引 — 已定位方法的精确架构

传入方法的 docsUrl（搜索或浏览命中结果中包含此字段）— spec 会在一次调用中加载该方法的架构（请求正文、响应、可筛选字段映射、示例），直接完成查询。请阅读字段的描述，而不只是名称 — 描述中包含规则（哪个字段是规范字段，以及何时字段为空）：

const sp = await wx.spec(hit.docsUrl);
// sp.examples — the method's worked requests as { title, line }, all saved at sp.examplesPath.
// The one that matches the task is rarely the first: read_file(sp.examplesPath, offset: <its line>)

想自行构造结果？传入针对索引的原始代码（lightIndex + getResourceSchemaByUrl）：

await wx.spec(`
  const url = "<docsUrl from search/browse>";           // API method page, not a skill/article page
  const s = await getResourceSchemaByUrl(url);
  // A method URL resolves to exactly that method — take methods[0]. Don't match on docsUrl:
  // the reader normalizes the url, so equality against the one you passed can miss.
  const m = s.methods[0];
  return {
    call: m.publicUrl,                                       // callable https://www.wixapis.com/… URL
    body: m.requestBody?.content["application/json"].schema.properties,
    responses: m.responses,
    filterable: m.queryMethodData?.queryFieldsCapabilitiesMap      // query methods
             || m.searchMethodData?.searchFieldsCapabilitiesMap,   // search methods
    example: m.legacyExamples?.[0]?.content,
  };
  // { $circular: "<name>" } types resolve via s.components.schemas["<name>"] — complete in this call
`);

filterable 会将每个字段映射到其允许的运算符和排序方式 — 仅在其列出的字段上进行服务端筛选，否则就在代码中筛选。

编写代码

使用 REST，而不是 JS SDK — 所有场景均如此：构建期间运行的管理操作、后端函数、前端页面。文档页面包含 REST 和 SDK 两部分；请阅读 REST 部分。

只发送页面中记录的内容 — 必填字段、嵌套结构和枚举值必须与文档中的拼写完全一致；只有当操作的 REST 部分列出了某个标头时，才发送该标头。切勿使用 wix-site-id：此处的每个令牌都已绑定到一个站点，而且在浏览器中，该标头会导致 CORS 预检直接失败。

数据结构也需要通过查阅发现：从 spec() 读取方法的请求和响应架构 — 字段描述会说明哪个字段是规范字段，以及字段何时读取为空。不要根据单次实时探测推断数据结构：它只反映你发送的参数，因此探测时应使用与你的代码相同的请求。

构建期间的管理操作 — 在 exec_tool 中由你执行

const { accessToken } = await base44.asServiceRole.connectors.getConnection("wix");
const data = await wx.post("https://www.wixapis.com/contacts/v5/contacts/query",   // spec-index publicUrl
  { query: { cursorPaging: { limit: 10 } } }, accessToken);
// let it throw — the thrown message is your result; .catch hides the answer
return wx.clip({ error: null, count: data.contacts?.length, first: data.contacts[0] });
// `first` is one complete record — read the real field shapes off it; don't code from remembered key names

后端函数 — 由应用以所有者身份执行

同一个 API 调用，部署后运行。这里不会运行任何辅助函数——wx.* 是加载到 exec 中的构建工具，在 base44/functions/… 中不存在；请编写普通的 fetch。clip 也不可用，它会限制 exec 返回给你的内容：函数会将其数据返回给应用。

// inside base44/functions/… — plain fetch, no wx
const { accessToken } = await base44.asServiceRole.connectors.getConnection("wix");
const res = await fetch("https://www.wixapis.com/contacts/v5/contacts/query", {
  method: "POST",
  headers: { Authorization: `Bearer ${accessToken}`, "Content-Type": "application/json" },
  body: JSON.stringify({ query: { cursorPaging: { limit: 10 } } }),
});
if (!res.ok) throw new Error(`${res.status} ${await res.text()}`);   // the API's own error, not a generic one
return (await res.json()).contacts;

• 除非操作页面另有说明，否则这一流程的全部身份验证就是 Authorization: Bearer …。
• 每个业务领域一个文件，而非每次调用一个文件——每个文件都要单独部署，而部署需要时间。
• 调用你部署的每个函数，并修复出现的问题。部署不等于测试。

访客身份验证和 Wix 托管流程

“面向访客的网站”（你正在构建什么？）的形态，在代码中是这样的——页面导入一个文件。clientId（来自上下文报告）和签发的令牌都不是机密；两者结合代表“匿名访客”，放在已发布的代码中是安全的：

// src/lib/wixClient.js
let token;
const mint = async (body) => {
  const r = await (await fetch("https://www.wixapis.com/oauth2/token", { method: "POST",
    headers: { "Content-Type": "application/json" }, body: JSON.stringify(body) })).json();
  token = r.access_token; sessionStorage.setItem("wixRefresh", r.refresh_token);   // expires_in: 14400s = 4h
};
// first visit:  mint({ clientId: WIX_CLIENT_ID, grantType: "anonymous" });
// on expiry:    mint({ refreshToken: sessionStorage.getItem("wixRefresh"), grantType: "refresh_token" });
export const wix = (path, opts = {}) => fetch("https://www.wixapis.com" + path, { ...opts,
  headers: { Authorization: `Bearer ${token}`, "Content-Type": "application/json" } });

如果需要测试访客 API（包括重定向会话），可以在 exec_tool 中进行。签发访客令牌并将其传给 API 调用，这样测试使用的身份就与访客前端相同。 令牌约定：检索令牌。 例如，测试公开读取操作：

const { access_token: visitorToken } = await wx.post("https://www.wixapis.com/oauth2/token",
  { clientId: WIX_CLIENT_ID, grantType: "anonymous" });   // clientId: from the context report
return await wx.post("<a public read from Learn Wix>", { query: {} }, visitorToken);
// 200 ⇒ every visitor-facing page in the app is this same call, no server between
// a lean default response isn't the whole shape — contracts often define a fields param
// that opts INTO heavier parts (formatted prices, media); read the contract for it

**任何会将访客返回到你的应用的 Wix 托管流程，都需要设置无头 OAuth 应用的重定向配置。**这既包括重定向会话，也包括将买家送往 Wix 托管的结账页 checkoutUrl 并返回——也就是任何 Wix 会重定向到你应用中某个 URL 的流程。

**任何访客流程的第一步：使用此应用自己的 URL 调用 wx.ensureOAuthApp。**它会返回前端用于签发访客令牌的 clientId（匿名访客无需登录）；如果站点没有 OAuth 应用，就会创建一个；如果已有，则会将你的 URL 添加到其列表中。只有列表中的 URL 才能完成返回流程，遗漏 URL 会导致流程静默中断——创建结账和匿名令牌仍会成功——直到真正的买家被重定向后滞留在 Wix。此操作按名称实现幂等：切勿为同一个 Base44 应用创建第二个 OAuth 应用，否则第一个 clientId 的返回流程将停止工作。创建应用时会设置 origin: "base44-app"，这是此流程在 OAuth 应用上的名称；origin 只能在创建时设置，因此手动创建的 OAuth 应用也要在创建调用中使用相同的值。

// Register BOTH of this app's own URLs — its preview URL and its published URL — so returns work
// before AND after publish. Both are built from the Base44 app id (NOT the Wix OAuth client_id /
// appId used above):
//   preview:   https://preview-sandbox--<base44-app-id>.base44.app
//   published: https://<app-name-slug>-<last 8 of the base44-app-id>.base44.app
//              where <app-name-slug> is the app's name (the brand name) slugified — e.g.
//              "Flash Sale Spark" -> flash-sale-spark-a4615088.base44.app.
// A custom domain the owner connects overrides the published one; the app name (hence the slug)
// can also change. So prefer the app's real current published URL when you have it, and update
// this same OAuth app whenever the name or domain changes — never create another.
const appOrigins = [previewUrl, publishedUrl]; // this app's actual preview + published URLs
const loginCallbacks = appOrigins.map(origin => new URL("/login-callback", origin).href);
const returnDomains = appOrigins.map(origin => new URL(origin).hostname);

// OAuth redirect configuration: exact login URLs versus domains for other returns.
// https://dev.wix.com/docs/go-headless/authentication/setup/allow-redirect-uris-and-domains.md
const { accessToken: adminToken } = await base44.asServiceRole.connectors.getConnection("wix");
const { clientId, created } = await wx.ensureOAuthApp(adminToken, {
  name: "My App",                     // this app's name; the lookup key on later runs
  redirectUris: loginCallbacks,       // login callbacks: matched exactly by the auth request
  redirectDomains: returnDomains,     // returns from Wix-hosted flows: hostnames only
});
// clientId is the public visitor client id the frontend client above mints from.
// When destinations change later — a custom domain, a renamed app — call this again with the
// new URLs: it updates the same OAuth app and preserves the entries already there.

获取访客令牌后，使用上面的访客客户端进行前端重定向的示例：

import { wix } from "@/lib/wixClient";

// Flow prerequisites and supported intents:
// https://dev.wix.com/docs/go-headless/business-solutions/wix-hosted-pages/redirect-using-the-rest-api.md
export async function redirectToWix(intent, returnPath = "/") {
  // wix sends the minted visitor token. Never use the admin token here.
  // Admin tokens are for ad hoc management calls or backend functions implementing admin logic.
  // Pass the intent required by the selected flow's schema.
  const response = await wix("/headless/v1/redirect-session", {
    method: "POST",
    body: JSON.stringify({
      ...intent,
      callbacks: {
        postFlowUrl: new URL(returnPath, window.location.origin).href,
      },
    }),
  });
  if (!response.ok) throw new Error(`${response.status} ${await response.text()}`);
  const { redirectSession } = await response.json();
  window.location.assign(redirectSession.fullUrl);
}

**要构建完整的垂直业务？使用 wix-vibe-headless 进行引导。**如果你要构建的是基于其支持的某个 Wix 垂直业务、面向访客的网站——例如店面、预约、定价方案、活动、餐厅、租赁、博客等——wix-vibe-headless 技能可以快速搭建该垂直业务：它完全基于此技能使用的同一套 Wix API 构建，但提供可运行的代码（REST 传输、脚手架、UI）以及管理 API 抽象（数据填充、配置），因此在 Base44 上引导垂直业务所需的调用次数大幅减少。 请阅读入口文档 www.wix.com/skills/wix-vibe-headless/platforms/base44.md。 其中的 STEP 1 包含安装流程本身——通过 exec_tool 运行的原样 npx skills add 调用、配套技能、垂直业务表格和脚手架部署——之后，指南位于 .agents/skills/wix-vibe-headless/platforms/base44.md。仅将其作为参考阅读也可以，但如果要安装，请完整遵循其流程——已发布的脚手架和数据填充路径是其大部分价值所在。