“
卡点不在模型而在可信的业务能力供给。商派把二十余年的零售、订单、履约经营 know-how，沉淀为一个可安装、可治理、可审计的 Skill 主仓——让智能体在真实的店铺、商品、库存与订单语境里，给出有据可依的答案。
—— 商派 ShopeX · Agent Skills 体系解读报告
AI Agent 开始走进品牌的生意现场，能力供给正在取代模型能力，成为落地的真正瓶颈。商派把二十余年的零售、订单与履约经营 know-how，按开放标准沉淀为一个可安装、可治理、可审计的 Skill 主仓，并以工程化方式加以约束。本报告基于对公开仓库的完整克隆与逐文件核验，解读这套体系的设计取舍、资产分布与信任机制。
观测与口径 ｜ 仓库 ShopeX/skills ｜ 标准 Agent Skills Specification ｜ 许可证 MIT
报告日期 2026-09-17 ｜ 观测快照 main @ 2026-09-04
46 个
公共 Skill 资产 · 覆盖消费者购物全链路
8 大
能力域划分 · 从发现到售后的完整闭环
7 类
产品线 scope 前缀 · 归属写进名称
100%
CI 强制校验 · 命名／结构／自包含全覆盖
📌 本文看点
01
46 个 Skill 的资产全景
02
一句话到扫码支付的闭环
03
把信任写成制度
SUMMARY
摘要
五点核心结论，概括商派 Agent Skills 体系的定位、方法与价值。
商派把「业务 know-how」做成了可安装的标准件。每一个 Skill 就是一个自包含目录，内含一份 SKILL.md 契约——它不描述产品卖点，而是写给 Agent 的可执行指令：什么情况下启用、必须调用哪些工具、绝不能编造什么、写操作前如何确认。
体系选择「小而专」，明确拒绝「万能 Skill」。商派未做一个巨型 shopex 助手，而是拆分为 46 个职责单一的能力单元。这带来三个工程收益：触发精准、按需装载、边界可归责。
规范先行，而非事后补救。仓库的命名注册表、description 三段式公式、自包含规则、PR 必备材料与双 Owner 制，在第一个 Skill 合入之前就已确立；CI 对每一项做机器校验。
最能体现工程深度的是「完整交易闭环」与「数据口径纪律」两端。前者把一句自然语言推进到可扫码支付，后者把「今天卖了多少」这类口语问题收敛到严格的统计口径，二者的共同点是：所有结论都必须来自工具真实返回。
信任被设计成制度，而不是提示词里的叮嘱。只读与写操作分界、dry-run 加显式确认、凭据红线、支付三态分离——这些约束写进了每一个 Skill 的正文，成为可审计的交付标准。
PROBLEM
命题：Agent 走进生意现场，卡点不在模型
通用大模型「懂电商」，但不「懂你的电商」。这中间隔着三道必须被工程化解决的鸿沟。
同一句「库存有多少」，在不同系统里是两个问题
在 ECX 消费者购物语境下，库存意味着某个 SKU 在会员所属店铺下的可售状态与规格可选项；而在 OMS 的经营分析语境下，「基础物料」与「销售物料」是两套独立的统计口径，选错口径得到的数字毫无意义。通用模型可以流畅地谈论库存，却无法自动分辨这些只在某个品牌、某套系统里才成立的约定。
这正是商派在真实项目中反复遇到的落差：Agent 落地失败的原因，通常不是它「不够聪明」，而是它不知道这个行业里什么算数、什么不算数、什么必须问过用户才能做。
！风险一 · 知识漂移
模型凭训练记忆补全价格、库存、物流单号、退款到账时间、活动门槛。这些数字在对话里看起来完全合理，却与真实系统无关。
！风险二 · 边界失控
把「帮我看看这个订单」理解成「帮我改这个订单」。只读咨询被误执行为写操作，加购、领券、下单、退款在用户未确认时被推进。
！风险三 · 不可治理
业务规则散落在提示词、客服手册、个人文档与聊天记录里。没有版本、没有 Owner、没有评审，改一处不知影响哪里。
商派对该命题的判断是：Agent 落地需要的是「可信的能力供给」，而不是更长的提示词。能力必须像软件一样被定义、评审、版本化与校验——这正是 Skill 主仓的出发点。
SOLUTION
解法：一个主仓，一套开放标准，三条硬规则
商派没有自创私有格式，而是站在开放标准之上，用最少的规则约束换取最大的可移植性。
开放标准：目录即能力
体系遵循 Agent Skills Specification：一个 Skill 就是至少包含 SKILL.md 的目录，由 YAML frontmatter 与 Markdown 正文组成，name 与 description 为必填字段。
这一选择带来直接收益：同一份 Skill 资产无需改写，即可被 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot、Windsurf 等不同 Agent 客户端发现与安装，商派不把自身绑定在任一厂商的私有机制上。
跨客户端可移植纯文本可审计技能内自包含
主仓模型：统一供给，按需装载
单仓库统一承载 ECX、OMS、DigiOS、B2B、POS 各产品线能力，以及跨产品共享能力与端到端组合流程。
对使用者，仓库是一个入口、一条安装命令、一次更新；对共建者，评审规则、命名规范、校验脚本与 Owner 分工只有一份。这正是「统一」带来的治理红利。
单一入口按需安装统一治理
三条强制规则
这三条规则写在仓库 README 首页，所有提交都必须满足，且由 CI 自动校验。
名称三层一致：目录名、SKILL.md 的 name 字段、安装时的 –skill
每个 Skill 必须自包含：禁止引用仓库根目录或兄弟 Skill 的文件，正文中也不允许出现 ../ 上级路径。原因很实际：不同安装器的扫描深度与依赖复制行为并不一致，只有自包含的目录在被单独复制后仍能完整工作。
产品归属写进全局唯一名称：以 scope 前缀声明归属：ecx-*、oms-*、digios-*、b2b-*、pos-*；跨产品共享用 common-*，端到端组合流程用 suite-*。前缀为已注册集合，禁止自造同义前缀。
| 类别 | 名称语法 | 用途 |
|---|---|---|
| 产品专属 | 单产品内的专业任务，如 ecx-order-diagnosis | |
| 跨产品共享 | common- |
至少两个产品共同使用，且输入输出与质量标准一致的能力 |
| 组合流程 | suite- |
编排多个能力，完成用户可感知的端到端流程 |
值得记录的是命名规范中的一个克制决定：禁止使用 helper、tool、utils、manager 这类意义空泛的词，也不新增 router-* 路由类 Skill。产品不明确时，应在各产品 Skill 的 description 里写清边界，而不是再造一层路由——这避免了「所有问题都进入同一个入口」的经典反模式。
ARCHITECTURE
体系架构：一层扁平目录，四层治理
仓库刻意保持结构简单——能力资产在最上层扁平铺开，治理设施收敛在独立目录。
ShopeX/skills
├── skills/
│ ├── ecx-shopping-assistant/
│ │ ├── SKILL.md
│ │ └── references/
│ ├── ecx-shopping-gift-guide/
│ │ └── SKILL.md
│ └── oms-mcp-sales-detail-statistics/
│ ├── SKILL.md
│ └── references/
├── docs/
│ ├── NAMING.md
│ ├── MAINTENANCE.md
│ └── RESEARCH.md
├── scripts/
│ └── validate_skills.py
├── .github/
├── CONTRIBUTING.md
├── LICENSE
└── README.md
skills/ · 46 个能力单元
一层扁平、名称全局唯一。每个目录至少含一份 SKILL.md 作为 Agent 可执行契约；需要细节时再挂 references/ 供按需读取。
docs/ · 三份治理文档
NAMING.md 定义命名、分类与产品前缀注册表；MAINTENANCE.md 规定角色分工、发布、废弃与安全基线；RESEARCH.md 沉淀标准仓调研结论与设计依据。
scripts/ · 一个校验器
validate_skills.py 在本地与 GitHub Actions 中执行同一套校验，PR 与主干推送均自动触发。
.github/ · 协作设施
CI 工作流、CODEOWNERS、PR 模板、Issue 模板与 Skill 模板。
四层治理：规范、执行、责任、协作
规范层
docs/NAMING.md 定义字符约束、scope 注册表、description 写法与目录自包含规则，并给出成对的推荐与反例。
执行层
scripts/validate_skills.py 在本地与 CI 中执行同一套校验，把规则从「评审人记得」变成「代码说了算」。
责任层
CODEOWNERS 按 scope 前缀绑定产品 Owner 与 Maintainer，要求至少一名适用 Owner 批准才能合并。
校验器实际检查什么
校验逻辑本身就是一份「规范的可执行版本」。它逐目录检查以下项目，任一不通过即让 CI 失败：
| 检查项 | 规则 |
|---|---|
| 目录命名格式 | 1–64 字符，仅小写字母、数字与单连字符，不得首尾连字符或连续连字符 |
| scope 注册 | 前缀必须属于已注册集合，否则报「未注册 scope」 |
| frontmatter 结构 | 必须以 — 开头并闭合；不允许重复字段 |
| 字段白名单 | 仅允许 name、description、license、compatibility、metadata、allowed-tools |
| 名称一致性 | frontmatter 的 name 必须等于目录名 |
| description 完备性 | 1–1024 字符，且必须包含触发语（use / when / 用于 / 适用 / 当） |
| 自包含约束 | 正文中不得出现上级或兄弟路径引用 ../ |
| 正文非空 | SKILL.md 正文不得为空 |
INVENTORY
资产盘点：46 个 Skill，覆盖消费者购物全链路
首批上线资产以 ECX / ECShopX 消费者电商场景为主干，并已延伸至 OMS 经营数据领域。
46
公共 Skill 总量
45
ECX 消费者电商 · 97.8%
1
OMS 经营分析 · 2.2%
DigiOS / B2B / POS 前缀已注册待启用
三类产品线前缀已在命名注册表中登记，对应的能力资产待后续批次补齐。
这一分布反映了一个清晰的产品策略：先在用户触点最密集、对话价值最高的消费者购物链路上把能力做厚，再向后端的订单、履约与经营分析延伸。ECX 作为 100% 开源、面向中小商家的商城产品线，承担了能力验证与规模化复制的双重角色。
八大能力域分布
45 个 ECX 能力单元按用户旅程聚类，形成八个职责清晰的能力域。
| 能力域 | 能力单元数 |
|---|---|
| 场景化导购 | 10 |
| 决策与选购 | 9 |
| 商品发现与认知 | 8 |
| 交易与履约 | 8 |
| 订单与售后 | 8 |
| 会员与权益 | 1 |
| 规则与政策 | 1 |
| 数据与分析（OMS） | 1 |
能力清单
以下按八大能力域列出全部 46 个能力单元及其职责说明。
①商品发现与认知
8 个能力单元
ecx-shopping-category-navigator
类目导航
帮助用户按类目、子类目、用途和关键词逐步缩小范围，再引导到商品推荐或详情页。
ecx-shopping-new-arrivals
上新与新款
围绕首页装修位、新品组件、热卖与搜索结果，处理上新、新款、New Arrivals 等场景。
ecx-shopping-bestseller-ranking-explainer
热卖榜解读
解读热卖榜、促销榜和首页推荐商品，帮助用户理解这些榜单为什么值得参考。
ecx-shopping-today-must-buy
今日必买
面向「今天买什么、有什么值得买」等泛发现意图，优先用热卖、促销、首页装修位和公开券生成真实推荐。
ecx-shopping-promotion-deals
促销好价
围绕促销商品、活动、公开优惠券和热卖商品，帮助用户找到当前可买的优惠商品。
ecx-shopping-brand-story-explainer
品牌与系列
围绕品牌、商品详情和店铺公开信息，解释品牌亮点、系列差异和选购注意事项。
ecx-shopping-authenticity-qualification-explainer
资质与正品
解释商品品牌、资质、认证、产地和详情页声明；只引用工具结果，不做无法验证的承诺。
ecx-personalized-fallback-recommend
泛发现兜底
当泛发现或清单类话术缺少明确检索词时启用：按登录态选择会员或公开召回工具，仅基于工具返回推荐。
②决策与选购
9 个能力单元
ecx-shopping-product-detail-explainer
商品详情解读
解释商品详情、规格、售后字段、价格和购买注意事项，帮助用户判断单个商品是否适合。
ecx-shopping-product-compare
多品对比
按价格、规格、库存、销量、适用场景和优惠信息对比多款商品，帮助用户做出购买决策。
ecx-shopping-size-spec-advisor
尺码与规格
围绕尺码、颜色、规格、容量、型号等选择问题，基于商品详情解释可选项和风险点。
ecx-shopping-stock-arrival-consultant
库存与到货
基于商品搜索和详情工具回答库存、规格可售、到货和缺货替代问题。
ecx-shopping-candidate-shortlist-filter
候选收敛
把用户已选或工具召回的候选商品，按预算、规格、场景、优惠和风险点筛到 1–3 个。
ecx-shopping-guided-questionnaire
引导式问询
用少量问题收集场景、预算、偏好和限制，再调用工具生成推荐，避免无效追问。
ecx-shopping-budget-guide
预算导购
按用户预算、价格带和性价比诉求推荐真实商品，并说明取舍点。
ecx-shopping-price-band-educator
价格带认知
解释不同价格带商品的常见差异，并基于真实商品帮助用户理解预算与品质的取舍。
ecx-product-consult
规格咨询
规格解读与选购建议；具体价格、库存与链接必须来自工具返回。
③场景化导购
10 个能力单元
ecx-shopping-scene-outfit-guide
场景穿搭
面向爬山、徒步、露营、运动、通勤、送礼等场景，把自然语言需求转成品类与商品清单。
ecx-shopping-bundle-guide
套装组合
为户外、运动、通勤、露营等场景组合多件商品，形成套装、清单和替代方案。
ecx-shopping-gift-guide
送礼推荐
按对象、预算、节日、关系和使用场景推荐礼物，并给出可购买商品和选择理由。
ecx-shopping-audience-segment-guide
人群细分
按儿童、老人、新手、专业玩家、通勤人群等细分用户推荐真实商品并说明适配理由。
ecx-shopping-festival-checklist-guide
节日清单
按节日、活动、出行、开学、年货等主题生成真实商品采购清单。
ecx-shopping-browse-history-recommend
浏览历史推荐
会员态读取浏览历史并补齐在售商品，生成「你最近看过 / 可能喜欢」的推荐。
ecx-shopping-repurchase-assistant
复购与囤货
结合会员订单、浏览历史、购物车和公开商品来源，处理复购、囤货、回购清单等会员态导购。
ecx-shopping-points-goods-guide
积分商品
查询积分商品和相关商品详情，回答积分兑换、积分商品推荐等场景。
ecx-product-recommend
商品推荐导购
推荐、搭配、热卖、送礼等导购场景按需启用；先调用商品类工具，只用返回数据组织答案。
ecx-retail-service
门店与电商导购
门店与电商导购及售后应答；涉及在售商品、价格、库存时须先调用商品工具。
④交易与履约
8 个能力单元
ecx-shopping-assistant
完整购物闭环
从自然语言意图直达可扫码支付：搜索、SKU 选择、地址、优惠券、购物车、结算、订单确认、微信支付二维码与支付状态查询。
ecx-shopping-cart-analyzer
购物车分析
读取会员购物车，结合券、活动和商品搜索给出保留、补充、凑单建议。
ecx-shopping-coupon-assistant
优惠券
处理领券、查券、优惠券使用说明；区分公开可领券、会员已领券和领券中心跳转。
ecx-shopping-gift-promotion-rule-explainer
满赠与叠加
解释满赠、赠品、活动门槛和优惠叠加规则；只引用活动、公开券和商品工具结果。
ecx-shopping-payment-method-consultant
支付方式
解释支付方式、结算价、优惠叠加和支付前注意事项；只做咨询，不发起支付。
ecx-shopping-delivery-address-consultant
收货地址
处理收货地址、配送范围、地址列表和配送规则咨询；默认只读查询，不修改地址。
ecx-shopping-recommendation-add-to-cart
推荐加购
把推荐商品或用户明确指定的商品加入购物车；必须确认商品、SKU 和数量后再调用写工具。
ecx-shopping-bulk-purchase-consultant
团购与集采
处理团购、企业采购、多件购买、备货清单等场景，基于商品和活动工具做只读建议。
⑤订单与售后
8 个能力单元
ecx-shopping-order-logistics-assistant
订单与物流
处理我的订单、订单详情、待支付、待收货、物流状态等会员态查询。
ecx-shopping-after-sales-consultant
售后退款换货
处理退款、退货、换货、售后进度和原因查询；默认咨询与查询，申请类写操作需确认。
ecx-shopping-return-exchange-policy-guide
退换货政策
解释退货、换货、退款、售后原因和寄回规则；只做政策说明，不提交售后。
ecx-shopping-invoice-consultant
发票咨询
基于会员订单只读信息解释发票申请、抬头、金额和订单关联问题，不提交发票申请。
ecx-shopping-human-service-handoff
转人工衔接
在会员态下只读整理订单、售后、购物车或商品问题摘要，方便用户转人工沟通。
ecx-general-support
通用售后与工单
通用售后与工单引导；先复述问题再处理，一次不追问过多项，并给出可执行的下一步。
ecx-shopping-post-purchase-usage-guide
购后使用指引
会员态结合订单和商品详情，为已购商品整理开箱、使用、保养和售后注意事项。
ecx-shopping-usage-care-guide
使用与保养
解释商品使用方法、保养注意事项、清洗存放和常见误区；只引用详情或通用安全建议。
⑥会员与权益
1 个能力单元
ecx-shopping-member-benefits
会员权益
解释会员价、优惠券、积分、订单统计和会员中心相关问题，优先使用会员工具与配置结果。
⑦规则与政策
1 个能力单元
ecx-shopping-policy-faq
规则问答
回答配送、退换货、优惠券、会员权益、发票、支付等规则类问题；不编造具体业务事实。
⑧数据与分析（OMS）
1 个能力单元
oms-mcp-sales-detail-statistics
销售明细统计
查询销售明细、汇总、排行与趋势。调用前必须由用户确认物料口径与时间范围，二者均不可推断；只读聚合，不做任何写操作。
ENGINEERING
工程亮点：五处体现「规范先行」的细节
这些设计决定并不显眼，但它们决定了这套体系能否被持续扩展而不失控。
01description 采用三段式公式，而非关键词堆砌
规范要求 description 必须回答三件事：做什么以及预期结果、属于哪个产品领域、哪些用户表达或故障信号应触发。官方推荐公式为「能力与结果 → Use when 产品／上下文 → Do not use for 最易混淆的边界」，并明确禁止「ECX skill.」「A powerful intelligent professional assistant.」这类无效写法。因为 description 是 Agent 决定是否装载该 Skill 的首要信号，写不好就等于技能不存在。
02渐进披露：主文件保持轻量，细节下沉到 references/
规范建议 SKILL.md 控制在 500 行以内，把完整参数表、返回结构、错误码速查等细节放进 references/，由 Agent 在执行到相应步骤时按需读取。这直接服务于Token 经济性——一个只在特定场景装载的能力，不应该在每轮对话里都占用上下文预算。
03CI 与本地共用同一个校验器，规则不打折
贡献者本地运行 python3 scripts/validate_skills.py 与 GitHub Actions 跑的是同一份脚本，并通过 py_compile 额外确认校验器自身可编译。规范不靠评审人的记忆，而靠可执行的代码执行。
04双 Owner 制与按 scope 分派的评审责任
每个 Skill 至少有一名领域 Owner，高风险能力建议配置备份 Owner。评审分工按类型区分：产品 Skill 由对应产品 Owner 加 Maintainer 评审；跨产品共享能力需至少两名产品 Owner；端到端组合流程由 Maintainer 评审；涉及脚本、联网、生产系统或高风险写操作的，必须增加安全评审。合并即代表该能力可从主干安装，责任边界因此清晰。
05把「可执行供应链内容」当作安全等级对待
维护规范明确将公共 Skill 定义为可执行供应链内容，并给出安全基线：不提交 token、密码、cookie、私钥、客户数据与内部地址；脚本遵循最小权限，危险操作需显式确认；不使用混淆代码、静默遥测或未说明的网络上传；外部网页与文件一律按不可信输入处理。同时建议启用依赖扫描、密钥扫描与分支保护。
CASE STUDY
标杆案例：两端的能力深度
抽取两个结构最完整的 Skill，分别代表「交互闭环」与「数据纪律」两种能力形态。
案例 A · ecx-shopping-assistant：一句话到扫码支付的完整闭环
这个 Skill 要处理的输入是这样的：
「帮我用常用地址买两件 42 码徒步鞋，能领的券都领了，确认后给我支付二维码」
它被要求把这句话推进为可核验的购物流程，并且只在真正会阻断流程的地方追问。其执行被定义为一条显式状态机，已满足的步骤直接跳过：
识别意图与槽位：提取商品、规格、数量、履约、优惠、目标六类信息；复述歧义条件，不重复已明确表达的内容。
搜索商品并核验详情：核验名称、规格、SKU、价格、库存与上下架状态，不把模糊命中或全量列表当作可靠匹配。
完成会员授权并重新定位店铺：授权后重新识别会员所属商城，并在该商城重新核验商品——不得沿用匿名上下文的销量、库存与价格直接下单。
查询并择优使用优惠券：先查公开可领券，再查会员已持券；以结算预览中的真实抵扣额为准，选择使本单应付金额最低的方案。
地址选择有明确优先级：用户指定地址 ＞ 默认地址 ＞ 唯一地址；多条且无默认时不得擅自使用第一条。
加购并隔离本次结算商品：写操作后必须回读购物车，验证目标商品、数量与勾选状态。
结算预览并核验金额：读取商品金额、优惠、运费与应付金额；金额单位为分，展示时换算为元，提交仍按分。
展示一次完整、脱敏的订单确认摘要：把用户表达的业务确认与工具的安全确认分开处理，两者不可互相替代。
获得明确确认后创建订单：先执行工具 dry-run，展示确认摘要，用户确认后以显式确认参数连同原参数提交；dry-run 令牌对 Agent 不可见，禁止复制。
由商城后端生成支付内容：从后端获取本次订单的微信 Native 支付链接，原样渲染为二维码。Agent 仅负责展示，禁止自行构造支付 URL、修改参数或拼接链接。
同一视图交付二维码与订单详情：包含订单号、状态、商品明细、优惠、运费、应付金额、脱敏收货信息、支付有效期提示，并说明二维码来源。
二维码生成 ≠ 支付发起 ≠ 支付成功——三个常被混为一谈的状态，必须严格分离。
Skill 明确要求：即使二维码生成返回「系统繁忙」，也不决定支付成败；只有在支付查询明确返回成功、且订单详情同步为已支付状态时，才可宣称支付成功。并且它明确写下一句边界——不存在「手动修改订单状态」的写工具，订单状态由支付回调自动更新，Agent 不得也无法手工改写。把「做不到的事」写清楚，和把「该做的事」写清楚同等重要。
显式状态机dry-run 安全确认写后回读验证支付三态分离失败恢复策略
该 Skill 主文件 164 行，配套 references/ 五份文档（工作流、工具契约、已知坑位、错误恢复、市场示例），合计约 663 行——主文件保持可读，细节按需加载，是渐进披露原则的完整落地示范。
案例 B · oms-mcp-sales-detail-statistics：数据类能力的口径纪律
「今天卖了多少？」在经营分析里是一句危险的话——它至少隐含两个必须由用户确认的口径选择。这个 Skill 的核心价值，是把口语问题严格收敛到可复现的统计口径上。
①口语 → 时间范围的默认映射
| 用户说法 | 默认行为 |
|---|---|
| 今日／今天销售 | 起止同为今天 |
| 昨天销售 | 起止同为昨天 |
| 最近 7 天销售 | 今天减 6 天 至 今天 |
| 本周销售 | 本周一 至 今天（周一至周日口径） |
| 本月销售 | 当月 1 号 至 今天（跨度不超 31 天） |
②绝不代用户默认的关键口径
物料口径（基础物料／销售物料／两者合计）没有默认值，无论用户是否说了时间，都必须反问确认——绝不能在用户没说的情况下自行推断。
同时规定每次调用只能选一种口径，需要多视角时多次调用后合并结果。这防止了「看起来是一个数字，实际是两种口径混算」这类最难排查的错误。
后端错误 ≠ 数据为空——列表为空时，必须先确认命中了哪个错误码。
当列表看起来是空的，必须先确认本次调用实际命中了哪个错误码；如果是上游服务异常，响应中会附带已脱敏的状态与提示，便于区分「真的没有销售」和「这次查询其实失败了」。它还明确禁止把分页结果当作全量统计口径，禁止把缺失维度推导成新的业务字段。这些约束单看琐碎，合起来才构成「数据可以拿去汇报」的信任基础。
口径必问错误码速查表只读聚合展示层默认规则
TRUST
信任设计：把安全约束写进每一份契约
在商派的 46 个 Skill 中，安全约束不是附注，而是与业务规则并列的正文段落。
四个逐层收紧的边界
数据来源：只认工具返回
商品、订单、价格、库存、优惠、物流与会员信息，只能来自本轮可用工具的返回或用户明确提供的信息。工具不可用、无权限或返回空结果时，如实说明限制，不用猜测补全结果。
操作类型：只读与写操作分离
默认只做咨询与查询；涉及写入、提交、领取、加购、下单或其他不可逆动作时，必须先展示影响范围并取得用户明确确认。
凭据边界：对话里不允许出现的东西
不在普通对话中索要、展示、记录或转发密码、短信验证码、JWT、token 或连接器凭据。会员授权优先走浏览器 OAuth 流程，由用户在可信授权页自行登录；部署不支持 OAuth 时，也只能使用连接器提供的安全凭据输入界面。
输出边界：脱敏与不越界承诺
最终输出仅展示脱敏手机号与脱敏地址摘要。政策类问题须说明「以店铺公示为准」，不编造物流单号、退款到账时间或工单内部审核状态；并在礼物推荐等场景中明确禁止输出可能冒犯用户或收礼人的刻板化判断。
其中最高频的一条约束是：只读咨询不得擅自执行写操作。
两个制度化的确认机制
机制一先预演，再执行
创建订单与生成支付二维码前均须执行工具 dry-run 并展示确认摘要。任何业务参数变化、金额变化或确认过期，都必须重新预演——不允许复用旧令牌。预演令牌对 Agent 不可见，禁止复制。
机制二用户意图不等于工具授权
「确认下单」「直接下单并给我二维码」可以作为业务意图确认，不再重复询问相同偏好；但工具层面的安全确认仍必须执行。两者分开处理、不可互相替代，是这套体系在安全与体验之间找到的平衡点。
每个 Skill 的末尾都有一段固定的「完成检查」清单，要求交付前逐项自检：是否已确认请求属于本技能适用范围、是否已区分工具事实与无法验证的内容、是否已遵守只读与写操作的边界并在需要时完成明确确认。把自检清单写进契约，意味着「合规」不再依赖执行者的经验水平。
GET STARTED
接入方式：一条命令，跨 Agent 可用
商派不为任一厂商单独封装，任何人可用标准命令发现、安装与更新这些能力。
Skills CLI
# 列出可安装项
npx skills add ShopeX/skills –list
# 安装指定 Skill
npx skills add ShopeX/skills –skill ecx-shopping-assistant
# 安装仓库全部 Skill
npx skills add ShopeX/skills –all
# 全局安装并跳过交互确认
npx skills add ShopeX/skills \
–skill ecx-shopping-assistant -g -y
# 检查和更新
npx skills check
npx skills update
CLI 支持 GitHub 简写与完整 URL 两种形式，可作为参数值传入，例如：
npx skills add https://github.com/ShopeX/skills \
–skill ecx-shopping-assistant
| 接入路径 | 说明 |
|---|---|
| 支持的 Agent 客户端 | Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot、Windsurf 等；实际安装目录由 CLI 按目标 Agent 决定 |
| 手动安装 | 复制完整的 skills/ |
| 命名兼容性设计 | 目录名、frontmatter name 与安装参数三者强制一致，避免「装上了却调不到」 |
| 发现与更新 | 安装后若客户端未发现新 Skill，重启对应 Agent 会话即可；后续用 CLI 的检查与更新命令统一升级 |
仓库对分发策略有一个明确表态：以开放 SKILL.md 标准为核心，厂商专属机制只作为可选的额外包装层，而非唯一分发方式。这一取舍保证了商派的能力资产不会因某个 Agent 平台的产品策略变化而失效。
THE END
价值与展望
这套体系对品牌客户、开发者生态与商派自身，分别是三种不同性质的价值。
对品牌客户
智能体在自家店铺语境里给出有据可依的答案：价格、库存、优惠、订单状态全部来自真实系统，不编造；加购、领券、下单等不可逆动作有明确的确认点；敏感凭据不进入对话。
这意味着品牌可以放心把「导购咨询 + 售前决策 + 售后查询」这一类高频、重复、易出错的对话场景交给 Agent。
对开发者生态
一份可复用的能力资产范本：单仓结构、命名注册表、description 写法公式、CI 校验脚本、PR 必备材料清单与废弃迁移流程，全部公开且可直接借用。
配合 ECX 的开源属性，开发者可以在自己的商城部署中直接安装、裁剪与扩展这些能力。
对商派自身
二十余年的零售与订单经营 know-how，第一次以「可评审、可版本化、可测试」的形态被沉淀下来，而非散落在项目交付与个人经验中。
同一份能力可以复用到不同品牌客户，交付从「每次重写提示词」变为「安装并配置」。
三个可观察的演进方向
产品线横向扩展
DigiOS、B2B、POS 三类前缀已在命名注册表中登记并分配 Owner，说明体系从设计之初就按多产品线规划，首批集中投入 ECX 与 OMS 是节奏选择而非能力上限。B2B 场景（经销、报价、批量化采购）与 POS 场景（门店收银、线下零售）是自然的下一站。
从单点能力走向组合流程
规范已为 suite-* 预留位置，并明确其职责是「编排多个能力完成用户可感知的端到端流程」，依赖方向单向为 suite 指向产品能力、禁止环状依赖。当单点能力足够丰富后，跨产品线的组合流程（如「从销售异常到库存补货」）将成为价值密度最高的形态。
治理机制的常态化运转
维护规范已定义季度质量审查清单：触发是否过宽或漏触发、是否依赖兄弟目录或绝对路径、主要 Agent 与 CLI 是否仍能发现该 Skill、Owner 是否有效、六个月内是否有真实使用与反馈。规范同时提示「不要以 star 或安装量作为唯一质量指标」——判断标准是触发正确、任务成功与风险可控。
真正的产出物不是 46 个文件，而是一套让业务经验可以像软件一样被交付的方法。
当品牌零售的每一个关键判断——什么该问、什么不能编、什么必须确认——都被写成可校验的契约时，AI Agent 才从演示走向生产。这正是商派把自己定位为「品牌数智科技伙伴」在 AI 时代的具体落法。
观测对象：GitHub ShopeX/skills 公共仓库（main 分支，最后推送 2026-09-04）
数据口径：经完整克隆后逐文件核验，共 46 个 Skill 目录、4 份治理文档、1 个校验脚本、6 份 references 资料
报告日期：2026-09-17 · 本报告所引事实均来自仓库公开内容
END
我是 {{作者名}}，{{一句话简介}}。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
