---
title: 商派AI进化之路-完整叙事与页面构建说明
description: 文本抽取：AI研讨会/商派AI进化之路-完整叙事与页面构建说明
updated: 2026-11-04
tags: [原始文档, 抽取, AI研讨会]
source: AI研讨会/商派AI进化之路-完整叙事与页面构建说明
source_type: txt
source_hash: da437df4ffe5
extracted_at: 2026-11-04
quality: ok
---

---
source: AI研讨会/商派AI进化之路-完整叙事与页面构建说明.md
type: md
size_kb: 21
category: AI研讨会
quality: ok
---

# 商派 AI 进化之路：完整叙事与页面构建说明

> 本文用于还原这组页面从最初构想到当前版本的完整思路：为什么重写主题、为什么这样安排章节、每一种页面与链接承担什么作用，以及后续如何继续补充客户案例。

## 1. 这组页面要回答的根本问题

最初的页面主题偏向 `Agentic Commerce Seminar`，重点在“智能体如何进入商城与零售业务”。它可以呈现单个技术方向，却不足以说明商派正在经历的更大变化。

这次重构要说明的不是“商派做了若干 AI 功能”，而是商派从成熟的通用业务系统软件出发，如何逐步完成三次能力扩展：

1. **让长期沉淀的业务系统继续服务企业增长。** 商派已经形成覆盖全渠道零售、经销、商品、订单、库存、财务及相关治理的产品体系，业务规则、流程和行业经验长期运行在系统中，并持续按年、月、周更新。
2. **让原有产品逐步适应 AI 时代。** 从产品功能中的 AI 延展，到商城和 OMS 内置助手，再到系统能够被通用工作台智能体理解、调用和操控。
3. **把视角从商派系统扩展到客户整体业务。** 商派系统只是企业 IT 环境中的一部分。企业仍有大量跨平台、跨部门、系统内外的人工工作，需要结合 AI、行业理解和客户现场共同寻找解法。

因此，页面的主命题是：

> **商派的 AI 之路，始于让成熟业务系统更智能，进而让业务能力能够被智能体调用，最后把这些能力和行业理解带到客户更广泛的真实工作中。**

这也是为什么新总览不再把“商城”作为唯一叙事中心，而把“商派业务系统—AI 能力—客户整体业务”作为连续演进关系。

## 2. 形成这个判断的客户现场认知

页面第三篇的出发点来自近期与客户沟通、与 WorkBuddy 的共创实践，以及回访老客户时得到的共同信号。

商派自身系统中的存量问题已经相对有限；但客户企业中仍同时存在 ERP、PLM、WMS/TMS、SCM、OA、BI、财务、采购、协作工具与各类外部平台。系统本身并不等于工作已经完成：数据仍要搬运，差异仍要核对，规则仍要解释，异常仍要追踪，材料仍要整理，很多跨系统流程还要依靠人来衔接。

随着商派与 WorkBuddy 的更多共创、实践与传播，越来越多客户主动带着这类长期痛点来讨论。回访老客户时，也反复看见同一个现象：客户已经习惯了这些**苦活、累活、脏活和杂活**，却并不意味着它们没有改善空间。

因此第三篇前设置了一段单独的“关键认知”转场。它不是普通导语，而是从“商派产品 AI 化”进入“客户整体业务服务”的逻辑支点：

> 商派不仅要持续做好自身产品，也可以结合 AI 和对行业、业务的理解，为客户那些早已被习惯的难题提供新的解法。

这意味着商派面对的是一次新的挑战：在守住自身产品积累的同时，从客户的业务、数据、规则和岗位结果出发，开展更多 AI 共创项目。

## 3. 总览页面的三篇叙事

总览页 [`index.html`index.html 采用三篇结构。三篇不是并列的产品目录，而是一条逐层外扩的叙事路径。

### 第一篇：商派的经典业务系统（第 01—02 章）

**回答的问题：商派原来有什么，为什么这些积累仍然重要？**

第一篇先建立业务底座。开篇导语是：

> 商派已经构建了面向品牌全渠道业务增长与管理的相对完整应用体系。

它不再使用“让企业的零售与经销业务在系统中运行”这一较为抽象、拗口的说法，改为强调“成熟的体系化全渠道业务框架已服务品牌多年，并仍以每年、每月、每周的节奏持续更新”。

第 01 章说明服务多年、持续更新的全渠道业务体系；第 02 章说明多年积累形成的产品体系与业务能力。它们共同确认一件事：AI 并不是替代已有系统，而是建立在长期运行的业务对象、流程、数据、权限与行业 Know-How 之上。

第 01 章独立页 [`01-business-framework.html`01-business-framework.html 后来整体替换为“全渠道业务场景数智化蓝图工程图”，用更工程化的方式呈现渠道、数据汇集、企业内部系统、业财一体和系统集成关系。图中“ERP、PLM、WMS/TMS、SCM、OA、BI、FIM、MES……”统一归入“企业内部系统”，避免把系统名堆成没有结构的清单。

### 第二篇：商派系统的 AI 进化（第 03—08 章）

**回答的问题：商派如何让自己的产品真正适应智能体时代？**

第二篇前设置第二段导语：

> 未来，软件可能不是人在用，而是智能体在用，人只需和它对话，由它来操控系统。

它不是对既有产品的否定，而是把讨论推进到新的使用方式：业务系统仍保存规则、权限、数据和正式执行责任，人的交互方式与任务组织方式开始发生变化。

第二篇的总标题经过调整，最终明确为：

> **从产品中的 AI 功能，到产品内置助手，再到完全适配智能体平台。**

这三个层次对应商派认知的逐步深入：

1. **产品中有 AI 功能。** 先在原有业务产品中做功能上的 AI 延展。
2. **产品中内置业务助手。** 让商城、OMS 等业务页面出现贴近身份、页面和上下文的助手，服务即时问答、推荐、查询、预填和确认等动作。
3. **产品完全适配智能体平台。** 单一页面里的助手能够改善局部操作，却不足以完成深度的系统级操作和跨系统协同。商品、订单、库存、规则、权限和操作能力必须通过 MCP 开放，使通用工作台智能体能够理解、调用、操控与回写。

第二篇各章节承担的具体作用如下。

| 章节 | 要说明的内容 | 在整体逻辑中的位置 |
| --- | --- | --- |
| 03 | 第一阶段：让业务系统拥有 AI 能力。包含商城内置智能导购、OMS AI 助手及智能体助手生成器。 | 从“产品里的 AI”开始。 |
| 04 | 第二阶段：从内嵌助手走向可被智能体接管的系统。系统通过 MCP 对外提供可理解、可调用、可操控、可回写的能力。 | 解释为什么局部助手还不够。 |
| 05 | 专项辨析：内嵌智能体与工作台智能体为什么都需要。 | 用对比澄清两类形态不是互相替代。 |
| 06 | 第三阶段：通用工作台智能体围绕任务实现更多业务场景。 | 展示工作台如何组织真实任务。 |
| 07 | Agentic Coding。 | 说明场景、开发、测试、交付与能力沉淀如何持续循环。 |
| 08 | 商派 AI 产品矩阵专题。 | 把业务系统、双智能体与 Agentic Coding 收束成完整结构。 |

#### 内嵌智能体与工作台智能体为何并存

第 05 章被刻意设计成一个“专项话题”，而非与前后章节同样的线性步骤。它承接第 03、04 章，回答客户最自然的追问：既然页面里已有 AI 助手，为什么还需要工作台？

- **内嵌智能体**服务于正在使用某个业务页面的人。它理解当前身份、页面和业务上下文，适合导购、问答、推荐、下单、订单操作与结果呈现。
- **工作台智能体**服务于坐在电脑前推进一项完整任务的人。它可以借助 MCP 和 Skill 跨页面、跨系统调用能力，在必要节点等待人工确认，再把结果回写。

两者共用业务能力底座，却服务不同的使用现场。页面通过专门的框架图与独立说明页 [`05-embedded-vs-workspace-agents.html`05-embedded-vs-workspace-agents.html 来表达这一关系，避免读者误以为“工作台”只是另一个聊天入口。

#### MCP、工作台选型与安全边界

第 04 章将“系统可被智能体接管”写成能力开放问题，而不绑定某一个智能体软件。商派开放的是业务系统能力，不限定工作台品牌；不同市场工作台形态都可以基于 MCP 接入。

这一章之下设置了三个与工作台选择相关的小话题：

1. 如何选择适合的智能体工作台；
2. 客户需要私有化部署智能体怎么办；
3. 商派提供 AI 大模型中转站服务。

这些话题分别链接到 [`04-agent-selection-guide.html`04-agent-selection-guide.html 的不同锚点，避免把“选哪个智能体”误解为唯一问题。

紧接着再链接到 [`04-mcp-service-security.html`04-mcp-service-security.html，回答“为什么商派系统可以被工作台接管、如何安全接管”。该独立页整合了架构、OMS MCP 安全访问和部署指南的内容，重点保留系统接入、身份权限、最小授权、人工确认、调用审计、异常回退和部署边界。安全不是附录，而是系统能力向智能体开放的前提。

#### 从演示到更多业务场景

第 06 章先链接已经存在的消费者购买、B2B 非标准 PO、B2B 对话式服务、OMS 日常作业、系统协同蓝图和并发任务流程。随后，在这些案例链接下加入“08 · Live Demo｜现在开始演示了”的紧凑演示区。

演示区保留原 `Live Demo` 的 11 个场景：

- 前四项标记为可现场演示：对话式商城下单、小程序智能导购、一句话经营分析、库存预警与智能补货；
- 后七项标记为可进一步交流：账号与权限开通、WMS 差异排查、主数据导入、采购订单创建、自然语言订单查询、异常监控、B2B 非标准 PO 智能接单。

它的作用不是把所有能力宣称为同一成熟度，而是区分“已可现场演示”与“可继续讨论的方向”。两张有具体入口的卡片还链接到已复制至当前目录的下单演示和品牌 Skill Hub 页面；其关联订单页和图片资源也一并复制，保证总览不依赖原目录。

#### 产品矩阵为何是第二篇的收束

第 08 章独立页 [`08-ai-product-matrix.html`08-ai-product-matrix.html 以“一个业务系统中心，三项商派 AI 能力围绕”为总框架。图示被还原为本地资源，并围绕它解释结构成因。

矩阵中的四个组成部分是：

1. **商派业务系统**：业务价值中心，沉淀业务流程、交易数据、行业模型、规则与正式执行能力；
2. **嵌入式 AI 智能体**：贴近页面与用户，即时服务单一业务系统中的操作；
3. **工作台 AI 智能体**：围绕完整任务，跨页面、跨系统调用和协作；
4. **Agentic Coding**：把客户场景持续转化为工具、功能和可复用能力。

页面还完整纳入原页面“构建 AI 时代的业务系统”板块，把 `Agent × Skill × MCP × ShopEx 业务系统 = 可执行的经营闭环` 作为解释公式。它同时明确人工确认点：AI 可以理解、拆解、调用和生成建议，但改价、退款、发券、补货等关键动作必须保留相应负责人的确认。

## 4. 第三篇：从商派产品出发，走向客户的整体业务

**回答的问题：商派是否只能解决自己的系统问题？**

第三篇的总标题是：

> **从商派产品出发，走向客户的整体业务。**

这里不是简单罗列“AI 能做什么”，而是把商派系统重新放回企业整体 IT 环境中。核心视角从“商派产品体系里，中心是商派业务系统”转换为“客户解决方案里，中心是客户的业务、数据与规则”。

在客户视角下，商派系统、第三方系统和办公协作工具都可以成为承载方式；AI 项目的起点不再只由某一个产品决定，而由客户真实的业务结果、数据来源、规则口径、权限边界和人员工作方式决定。

第 09 章以“站在企业全局看，商派系统只是其中一部分”说明这一视角转换。它解释：系统已经很多，人工工作仍然存在，是因为系统间、系统与人之间仍要有人负责搬运、核对、解释、追踪和整理。

此后第三篇采用“一个客户痛点，一条可验证路径，一组可引用材料”的方式持续追加案例。这样可以避免提前罗列抽象能力，而让每项 AI 服务都回到具体客户的问题、原有系统、已有材料、验证范围与交付结果。

### 已纳入总览的客户案例

| 章节 | 客户与问题 | 为什么具有代表性 | 当前引用材料 |
| --- | --- | --- | --- |
| 10 | **知名的大型商超供应链企业：让 AI 接过从标讯到标书交付的繁重工作。** 需求横跨标讯解析、逐条应答、资质检索、废标检查、语义查重、多轮评审、排版交付、签章上传与系统回写。 | 看似要建设“标书平台”，其中相当部分其实是内容生产和业务协同动作；可由本地工作台、内网 MCP 和企微文档分工，同时保留数据不训练和私有化边界。 | 方案页 `10-retail-supply-chain-tender-solution.html`；全流程模拟 `10-retail-supply-chain-tender-demo.html`。 |
| 11 | **知名卫浴品牌：八套老系统不换，先长出一层 AI 智能层，让老旧的订货系统具有 AI 能力。** | 体现不替换老系统，而是在原订货系统与订单中心、供应链等场景外加挂智能层；嵌入式与工作台智能体通过同一套 MCP、Skill、权限和确认门连接既有系统。 | `11-sanitaryware-ai-ordering-platform.html`。 |
| 12 | **知名食品品牌：让 AI 接过商超供货的对账与凭证工作。** | 体现 AI 进入业财协同和商超供货的高频、规则密集型岗位工作。 | 当前目录中引用的业财账务自动化方案页。 |
| 13 | **某国际咖啡品牌：两条 AI 需求线，一条管增长、一条管合规。** | 作为继续追加的客户共创案例，说明同一客户的 AI 起点可以来自不同业务目标。 | 后续按材料继续完善。 |

这些案例应持续区分四种状态：需求研判、方案设计、模拟演示、生产运行。页面不把所有探索写成已经规模化上线的事实，而是说明每个案例已经验证了什么、仍需要哪些数据、权限、业务确认和运行保障。

## 5. 页面形式与信息组织原则

### 总览页不是全文堆放页

一开始考虑过把全部内容放在一个超长页面中。最后采用的结构是：**总览页负责叙事、导航和判断；具体章节与案例页负责完整展开。**

这样处理的原因是：

- 总览页要让读者快速看懂商派认知如何一步步变化；
- 每个案例、架构、安全说明和产品演示往往需要较长篇幅、图片或交互，放在总览中会破坏主线；
- 新案例会不断增加，独立页面可以持续增补，不需要反复重构整篇总览；
- 总览章节下保留简洁说明与链接卡片，读者既能连续读，也能按兴趣进入细节。

因此，页面体系采用“一个总览 + 多个英文文件名的独立页”。从第 01 页开始，详情页使用英文文件名，便于链接稳定、后续维护和跨系统引用。

### 返回总览应保留阅读位置

详情页的“返回总览”不应只回到总览顶部。它需要尽量保留从哪个章节进入的信息，回到对应锚点，使读者不必重新翻到原位置。这条规则适用于以后新增的所有分页面。

### 详情页的页脚与正文边界

分页面不再增加“ShopEx 商派的 AI 进化之路 · 第 X 篇”这样的通用底部文字，也去掉与正文重复的图注或“本章定位”说明。详情页只保留真正帮助读者理解页面的标题、导语、图示、正文和返回入口。

## 6. 视觉与写作规则

本项目使用 ShopEx 风格，但只继承其**字体、颜色、空间感、蓝紫渐变、轻量边框和高级业务简报气质**，不照搬已有页面的内容板块。

具体规则包括：

- 中文页面统一使用中文优先字体；总览与分页面字体保持一致；
- 用大字号导语和留白建立篇章转换，例如第一篇前的业务体系导语、第二篇前的智能体使用方式导语、第三篇前的“关键认知”；
- 蓝紫渐变只用于重要结论、编号和有限的强调，不让所有卡片都变成渐变背景；
- 总览中的章节采用有缩进的编号—正文结构，使大篇章与小章节层级一致；
- 独立案例页可以使用长文、图解、流程、对比或演示，但总览中只保留必要的导读和入口；
- 引用原始页面的图片、演示与依赖资源时，将本地资源复制到 `202609` 目录，保证新页面可独立运行；
- 每次新增内容都检查桌面与移动端，确保没有横向溢出、长标题不截断、链接资源有效。

总览页面中最重要的转场不只靠文字，也通过视觉层级表达：

1. 第一篇是淡色业务积累导语；
2. 第二篇是“未来由智能体使用软件”的大字判断；
3. 第三篇是带引导线的“关键认知”引用区，突出客户真实反馈与“苦活、累活、脏活和杂活”。

## 7. 本项目已使用和正在使用的主要材料

### 原始叙事与产品材料

- `Seminar/shopex-agentic-commerce-seminar.html`：原始研讨会页面。其业务架构、AI Business System、Live Demo 等内容被拆分、重写或引用到新页面体系中。
- `main/ShopeXAgentic/`：商城内置助手、OMS 助手、系统初始化、工作台操控、智能体选型、MCP 安全、业务场景、产品矩阵等页面素材。
- `Reference/商派AI智能体平台_说明与介绍.html`：用于辨析内嵌智能体与工作台智能体的关系，保留其中相关框架图表达，不把无关材料混入专题。

### 客户材料

- `知识库资料2026/客户AI需求/知名的大型商超供应链企业/`：标书工作台方案与全流程模拟 Demo；
- `知识库资料2026/客户AI需求/知名卫浴品牌/需求分析/`：知名卫浴品牌 AI 订货平台与前插后插工程框架；
- `知识库资料2026/其他资料/100-客户文档/02-快消食品/知名食品品牌/`：业财账务自动化方案；
- 后续将继续从客户需求库中补充猛犸象、酒店用品、松下等场景，但每次均以具体问题和可验证结果为单位加入。

## 8. 迄今为止的重要取舍记录

1. **主题从“Agentic Commerce Seminar”提升为“商派的 AI 进化之路”。** 因为用户需要理解的是商派能力边界如何扩展，而不是只看商城场景。
2. **三篇并行而非三条替代路径。** 经典业务系统、系统 AI 化与客户整体业务服务会持续并行，能力和服务范围不断叠加。
3. **先说明已有业务底座，再谈 AI。** 若省略第一篇，AI 容易被理解成独立外挂，无法理解商派为何能提供业务语义、规则和执行能力。
4. **不把内嵌助手等同于系统 AI 化完成。** 内嵌助手改善单页面体验；MCP 和工作台接管才把系统能力带到完整任务中。
5. **工作台不绑定某一种智能体软件。** 平台选型、私有化部署和大模型中转是三个不同问题，必须分别说明。
6. **安全与权限不后置。** MCP 开放能力只有同时具备身份、权限、审计、确认与回退，才可进入真实业务环境。
7. **以客户痛点组织第三篇。** 不再先列“数据 AI”“流程 AI”等抽象栏目，而是逐个列出知名的大型商超供应链企业、知名卫浴品牌、智盟等实际需求，让服务拓展有证据、有边界。
8. **演示内容保留成熟度区分。** “TODAY”与“DISCUSS”代表可现场演示和可继续交流的差别，避免把探索性方向和已验证内容混为一谈。
9. **总览的文字要轻，关键认知要重。** 章节说明保持可扫描；只有篇章转折、产品矩阵和客户认知等真正改变叙事方向的内容，才使用大字、独立区域和图解。

## 9. 后续撰写与扩展方法

后续每增加一个客户需求，先用以下顺序判断，再决定是否进入总览：

1. **客户的原始问题是什么？** 不先从 AI 名词或功能清单开始。
2. **原有系统、数据、文件、规则和人员如何参与？** 确认 AI 需要连接什么，以及哪些环节必须保留人工确认。
3. **它属于哪一类工作？** 例如内容生产、单据理解、规则匹配、数据问答、跨系统操作、岗位流程或合规核对。
4. **当前验证到什么程度？** 明确是需求分析、方案、Demo、试点还是生产运行。
5. **能留下什么可复用能力？** 包括 Skill、MCP 服务、连接器、规则模板、验证样本、交互模式或交付方法。
6. **总览中如何用一句话说清？** 使用“客户：痛点与业务结果”的标题，下面只保留必要背景、验证范围和详情链接。

当案例累积到一定数量后，可以再从案例中总结可复用能力，但这一步应建立在已发生的客户项目之上，而不是提前用抽象分类替代客户现场。

## 10. 对外讲述时的一条完整话术

商派长期服务品牌的全渠道增长与管理，产品体系里已经沉淀了业务流程、交易数据、行业经验、规则与正式执行能力。AI 到来后，商派先让原有产品拥有 AI 功能，并在商城、OMS 等产品中内置业务助手。

但我们逐渐认识到，单一页面里的助手只能提升局部效率。要让业务系统真正适应智能体时代，系统本身必须能够被工作台智能体理解、调用、操控和回写。因此商派通过 MCP 与 Skill 开放业务能力，让不同形态的智能体平台都能在权限、安全和人工确认边界内使用这些能力。

当我们与 WorkBuddy 共创、并回访老客户时，又看见了更大的企业现场：商派系统内的存量问题并不多，但客户在大量其他系统、协作工具与岗位流程之间，仍长期依靠人工处理苦活、累活、脏活和杂活。商派因此从做好自身产品进一步走向客户的整体业务，结合 AI、行业理解和共创交付，为这些长期被习惯的问题寻找新的解法。

这就是这组页面的完整脉络：**从业务系统出发，让系统 AI 化，让系统被智能体使用，再把能力带到客户更广泛的真实工作中。**