Skip to content

Repository files navigation

让每家街边小店,都拥有自己的 AI 接口

merchant-skill-generator 是一个帮助本地商家生成 AI 接口的开源工具。

瑞幸、麦当劳这样的品牌,可以让 AI 认识自己的门店、商品、活动和服务。

那么,为什么路边的沙县小吃、主理人咖啡店、酒吧、烧烤店、理发店和维修店不能拥有自己的 AI 接口?

在 AI 时代,和 AI 连接的权利,不应该只属于大公司。

这个项目希望把这件事变得足够简单:商家把已有的文字、链接、图片、PDF 或菜单资料交给 AI,经过商家确认后,就能生成一个可维护、可部署、可被 AI 调用的 Merchant Skill / MCP 仓库。

为什么做这件事

AI 正在成为新的消费入口。

以后,顾客不一定先打开 App、搜索小程序、翻菜单页。他们可能直接问 AI:

附近有什么适合坐一会儿的咖啡店?

我第一次去这家店,应该怎么选?

两个人预算 100 元,有什么合适的方案?

这家理发店需要预约吗?

大品牌已经拥有 App、会员系统、支付系统、技术团队和专门的数据接口,所以它们更容易进入 AI 世界。

但一家普通小店没有 App、没有会员系统、没有技术团队,并不代表它不值得被 AI 认识。

如果未来只有大公司能够被 AI 找到、理解和调用,数字化的差距只会换一种方式继续存在。

merchant-skill-generator 想先解决最基础的一步:

让普通商家也拥有一个 AI 能读懂、AI 能调用、商家自己能维护的接口。

这个项目是什么

它不是一个新的点单 App,也不是一个替所有商家托管交易的平台。

它做的是把一家商家的公开资料和经营规则,整理成一套 AI 可以使用的能力:

商家已有资料
      ↓
AI 整理事实、来源和不确定项
      ↓
商家确认关键内容
      ↓
生成 Merchant Skill + MCP 服务
      ↓
部署、发布、持续更新

商家不需要先开发 App、会员系统或完整交易系统,才能开始被 AI 正确理解。

AI 可以帮顾客做什么

顾客可以用自然语言询问一家店:

  • 这家店在哪里,什么时候营业?
  • 有哪些商品、菜单、服务或体验项目?
  • 我第一次来,应该怎么选?
  • 按预算、人数、偏好或限制,怎么推荐?
  • 什么时候去更合适?需要预约吗?
  • 最近有什么活动或最新动态?
  • 帮我整理一个购买、预约、购票或咨询草稿。
  • 真正购买或预约,应该去哪个官方渠道?

生成的 Skill 主要覆盖四类能力:

  1. 认识商家:地点、营业时间、服务方式和官方渠道。
  2. 理解项目:商品、菜单、服务、票务、体验项目及其说明。
  3. 帮助决策:预算、人数、偏好、限制和到店或服务计划。
  4. 连接行动:生成行动草稿,并把真实交易引导到官方渠道。

当前的基础模式有明确边界:

  • 不静默下单。
  • 不处理支付。
  • 不保存用户账号。
  • 不承诺实时库存、实时排队或预约成功。
  • 不把未知价格、供应状态或活动有效期补写成事实。
  • 真实购买、预约、购票、退款和履约,以商家官方渠道为准。

参考案例

主理人咖啡店

顾客可能会问:

第一次来推荐喝什么?

这里适合办公吗?有 Wi-Fi 和插座吗?

周末下午适合坐一会儿吗?

AI 可以理解咖啡项目、豆单、门店环境、座位规则、营业时间和活动资料,给出有依据的推荐和到店提醒。

老板得到的不是一张静态菜单,而是一套能被 AI 正确介绍和调用的咖啡店接口。

沙县小吃 / 小餐馆

顾客可能会问:

两个人 50 元怎么选?

有什么招牌?

晚上去需要排队吗?

AI 可以根据预算、人数和项目标签生成选择建议,说明价格和排队信息的时效边界,再把真实购买或外卖动作引导到官方渠道。

酒吧

顾客可能会问:

今晚适合去吗?

需要预约吗?

有什么招牌酒或活动?

AI 可以回答营业时段、低消或入场规则、活动安排、订位方式和官方联系方式,但不会替用户承诺有座,也不会替用户完成支付。

理发店、维修店和其他本地商户

顾客可能会问:

你们提供哪些服务?

这个预算可以做什么?

需要提前预约吗?

出现问题应该怎么联系?

这类商家不需要被强行套进“菜单”和“点单”逻辑。生成器会使用通用本地商户预设,把商品、服务、项目、预约和官方渠道组合成适合自己的 AI 接口。

示例资料位于 examples/specs/,可以用同一套流程生成:

示例 商户类型 生成后的 MCP 路径
daybreak-cafe.json 咖啡店 /daybreak-cafe-mcp
jinguyuan-restaurant.json 餐厅 /jinguyuan-dumpling-mcp
haze-bar.json 酒吧 /haze-bar-mcp
alley-hair-salon.json 理发店 /alley-hair-salon-mcp
bloom-florist.json 花店 /bloom-florist-mcp
echo-livehouse.json Live House /echo-livehouse-mcp
night-owl-tabletop.json 桌游、剧本杀或密室体验 /night-owl-tabletop-mcp

一个普通商家怎么获得自己的 Skill

1. 把已有资料交给 AI

商家可以直接提供:

  • 一段店主介绍。
  • 官网、公众号、小红书或地图链接。
  • 菜单、价目表、服务列表或门店照片。
  • PDF、文档、表格或已有仓库。

不需要自己写 JSON,也不需要先理解 MCP。

2. AI 整理资料并提出关键问题

AI 会把资料整理成商家能看懂的摘要,并区分:

  • 已确认的信息。
  • 需要商家确认的信息。
  • 不影响生成的可选缺口。
  • 不补齐就不能生成的阻塞信息。

如果不同资料之间有冲突,AI 会先停下来确认,不会自行猜测。每次只追问一个最必要的问题。

3. 商家确认公开内容

生成前,商家需要确认:

  • 商家名称和介绍。
  • 地点、服务范围和营业方式。
  • 商品、菜单或服务项目。
  • 活动和官方渠道。
  • 哪些信息可以公开给 AI。

公开资料会保留来源和时效信息,并标注“资料由商家或授权运营者确认”。这不代表生成器平台完成了真实性认证。

4. 生成一个商家仓库和一个 MCP 服务

确认后,生成器会产出:

一店一仓库
一店一 MCP 后端
一套商家资料和来源记录
一套维护、部署和传播材料

5. 部署并发布

默认推荐 CloudBase。老板只需要完成三个云端动作:

  1. 创建 Node.js HTTP 服务。
  2. 上传生成的 zip 并部署,服务端口为 9000
  3. 复制公网根地址,交回给生成器完成最终验收。

最终会得到类似这样的 MCP 地址:

https://xxx.service.tcloudbase.com/<merchant-slug>-mcp

6. 把地址放到顾客看得到的地方

商家可以把 Skill 地址放在:

  • 小红书主页。
  • 微信公众号。
  • 门店桌牌。
  • 社群。
  • 大众点评简介。
  • GitHub 或 Gitee 仓库。

顾客可以直接把安装话术复制给支持 Skill 或 MCP 的 AI:

帮我安装这家店的 Skill,地址是:https://github.com/your-name/my-shop-skill

商家最终得到什么

每个商家最终得到一套可以继续维护的交付物:

  • 完整的商家 Skill 仓库。
  • 标准 MCP 服务。
  • CloudBase 上传 zip。
  • 最终可安装的 Skill zip。
  • 商家资料、来源和确认声明。
  • 数据维护和安全更新说明。
  • CloudBase 部署和验收说明。
  • 顾客安装话术。
  • 小红书、公众号、桌牌和社群传播文案。
  • 后续更新入口。

和瑞幸、麦当劳的差距

瑞幸、麦当劳这类大品牌已经拥有完整的实时业务系统,可以把商品 SKU、优惠券、库存、支付、订单、会员和履约接入 AI。

普通商家通常没有这些基础设施。

所以这个项目不假装第一天就复制大品牌的完整交易系统,而是先解决更基础的问题:

大品牌拥有完整的 AI 业务系统;
普通商家也应该先拥有自己的 AI 接口。

当前项目已经覆盖:

  • 地点和服务信息。
  • 商品、菜单、服务和体验项目。
  • 推荐和服务计划。
  • 活动和最新动态。
  • 购买、预约、购票或咨询草稿。
  • 官方渠道引导。

当前默认不覆盖:

  • 真实支付。
  • 真实下单或预约成功确认。
  • 订单查询和退款。
  • 实时库存和实时排队。
  • 会员券、积分和统一履约系统。

这不是项目的终点,而是基础模式的安全边界。只有真实连接器完成适配、测试并经过商家明确启用后,才适合进一步开放高风险写操作。

开发者入口

如果你是技术朋友、代理商或服务商,可以直接运行:

npm install

查看预设:

npm run generate -- --list-templates

从资料规格生成仓库:

npm run generate -- \
  --spec ./merchant-specs/my-shop.json \
  --out ./output

更新已有仓库:

npm run generate -- \
  --spec ./merchant-specs/my-shop.updated.json \
  --update ./output/my-shop-skill

如果生成文件被手工修改,更新会停止并生成冲突报告,不会静默覆盖商家内容。

验证整个项目:

npm run validate

单个生成仓库自带:

npm run smoke
npm run package:cloudbase
npm run finalize -- \
  --base-url https://xxx.service.tcloudbase.com \
  --repo-url https://github.com/your-name/my-shop-skill

内部数据模型使用 MerchantSpecV1。开发者可以参考 references/capabilities.mdexamples/specs/,但这不是普通商家的使用门槛。

11 个标准 MCP 工具

新生成的仓库默认公布以下通用工具:

  • list_locations
  • get_location_info
  • get_latest_updates
  • search_offerings
  • get_offering_detail
  • get_offering_categories
  • recommend_offerings
  • get_service_plan
  • get_promotion_options
  • build_action_draft
  • get_official_action_channels

旧工具名仍可作为兼容别名调用,但不会出现在新仓库的公开工具列表中。

项目不做什么

这个项目当前不负责:

  • 自动登录或调用商家的云账号。
  • 替商家创建 CloudBase 资源。
  • 代替商家维护实时业务系统。
  • 默认处理支付、真实订单或履约。
  • 把商家没有提供的信息补写成事实。

License

MIT

Releases

Packages

Contributors

Languages