Merchant Skill Generator

让每家街边小店，都拥有自己的 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/](./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/-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.md](./references/capabilities.md) 和 [examples/specs/](./examples/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

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Hchen1218
• Source: Hchen1218/Merchant-skill-generator
• License: MIT

Install and usage instructions live in the source repository linked above.