从「抄作业」到 AI 自动生成视频的完整方法论

很多创作者在做视频号时都会遇到同一个问题：
为什么看起来很努力，却始终没有稳定的高播放？

原因往往不在执行力，而在起点就错了——
从“原创灵感”开始，而不是从“成功案例”开始。

事实证明，当前阶段最容易跑通的方式不是凭空创作，而是：

先抄作业，再用 AI 把成功经验规模化复制。

下面是一套已经被反复验证、且非常适合短视频平台的完整方法。

一、核心思路：不是抄内容，而是抄「爆款结构」

这里的“抄作业”并不是搬运视频，而是反向工程爆款：

• 不关心某条视频讲了什么
• 只关心它为什么能火
• 把“感觉”拆成可复用的结构

整个流程可以拆成四个关键词：

采样 → 归纳 → 再创作 → 自动生成

二、为什么这个方法能跑通？

1️⃣ 爆款不是偶然，而是可重复的结构结果

绝大多数高播放视频，并不是随机出现的，而是满足了以下条件：

• 前几秒有强烈视觉或行为异常
• 中段存在明确冲突或失控
• 结尾有情绪释放或反转
• 风格高度统一，利于算法识别

单个视频看不出规律，但同一 channel 的 Top 视频几乎一定有共性。

2️⃣ 从 YouTube 入手，是最稳妥的起点

YouTube 的优势在于：

• 样本量大
• 数据透明
• 爆款生命周期长

选择一个已经跑通的 YouTube channel，本质是在复用：

• 已验证的受众偏好
• 已适配的平台算法
• 已成熟的内容节奏

3️⃣ NotebookLM 的价值：把隐性经验变成显性规则

NotebookLM 的核心作用并不是“写文案”，而是：

从多个成功样本中，提炼共性模式。

例如：

• 开头平均在第几秒出现刺激点
• 冲突是否围绕“规则 / 强迫 / 对抗”
• 情绪是逐步升级还是瞬间爆发
• 是否存在固定角色关系（支配 / 反抗）

这一步完成后，爆款不再是“感觉”，而是结构模板。

4️⃣ 文本转视频，是 AI 当前最成熟的短视频应用场景

当前 AI 在短视频领域的优势集中在：

• 夸张动作
• 强对比画面
• 明确情绪
• 简单故事线

当“创意结构”已经由 NotebookLM 给出，
AI 更适合承担的是从创意到画面的执行过程。

三、完整可执行流程（SOP）

Step 1：查找 YouTube 火爆 Channel

筛选标准：

• 同一类型内容
• 至少 3–5 条百万播放
• 风格高度统一

Step 2：选取 Top 10 爆款视频

重点关注：

• 播放量
• 明显被算法推荐的迹象
• 评论区情绪密度

Step 3：将视频链接输入 NotebookLM 分析

分析重点放在结构层面：

• 前 3 秒发生了什么
• 冲突第一次出现的时间点
• 情绪如何被放大
• 是否存在“规则被打破”的瞬间

最终得到的是一个可复用的爆款结构模型。

Step 4：让 NotebookLM 生成“类似结构”的新创意

在结构不变的前提下，替换：

• 场景
• 道具
• 主题设定

NotebookLM 在这一阶段输出的，是已经符合爆款结构的新视频创意。

四、演示案例：厨房灾难——机器“闹鬼”事件

根据前述步骤，选择一个由 NotebookLM 生成的视频创意，用于展示从创意到视频生成的全过程。

创意名称

厨房灾难：机器“闹鬼”事件（The Haunted Mixer Prank）

创意概念

在制作节日甜点的过程中，人为制造厨房设备故障，形成短暂混乱，再用反转完成喜剧闭环。

核心情节点

• 设备失控
• 人物恐慌
• 荒诞解释
• 快速反转恢复秩序

五、让 AI 根据该创意生成文本转视频 Prompt

在演示中，并不直接人工编写提示词，而是：

将该创意输入给视频生成模型或多模态 AI，要求其根据创意自动生成文本转视频 Prompt。

并对 AI 提出明确约束：

• 视频总时长：20 秒
• 镜头数量：4 个
• 每个镜头 1 个核心事件
• 强调视觉、动作和情绪变化

🎬 AI 生成的 Text-to-Video Prompt（20 秒）

A 20-second comedic kitchen prank video.

Scene 1 (0–4s):
Bright home kitchen.
A cheerful female character is happily making holiday desserts.
She overloads a stand mixer with too many ingredients.
The mixer begins shaking violently.

Scene 2 (4–9s):
The mixer malfunctions.
Smoke rises dramatically.
Ingredients splatter everywhere.
The character panics, shouting:
“Unplug it! Unplug it now!”

Scene 3 (9–14s):
The mixer stops.
Close-up of the burnt mixer head.
She stares at it and asks nervously:
“Did I summon a ghost?”

Scene 4 (14–20s):
Comedic reversal.
She pulls out a brand-new mixer.
Smiles calmly and continues cooking as if nothing happened.
Bright, cheerful ending.

Style:
Fast-paced, exaggerated comedy.
Strong facial expressions.
Short-form video style.
No subtitles, no text overlays, no watermarks.

然后选一个文本转视频的模型将提示词输入。

六、为什么这个演示案例具有代表性？

• 创意来源于结构分析，而非灵感碰运气
• Prompt 由 AI 基于创意自动生成
• 冲突、节奏、反转完整可复用
• 非常适合短视频平台算法偏好

这说明：
当结构正确时，AI 的执行能力已经足够支撑内容生产。

七、结语：内容创作正在进入「工程化时代」

当内容生产开始遵循：

• 用数据筛选方向
• 用模型总结结构
• 用 AI 生成与执行
• 用批量测试验证结果

创作就不再是玄学，而是一套可以被复用和放大的系统。

在这个体系中，“抄作业”不是捷径，而是最低成本、最高成功率的起点。
当结构被掌握，所谓的“原创”，自然会不断出现。

本文由mdnice多平台发布

基于 YOLOv8 的电网绝缘子破损与闪络缺陷智能检测系统识别项目 [目标检测完整源码]

一、研究背景与工程问题分析

随着电力系统规模的不断扩大，输电线路和变电设备的运行安全已成为电网运维中的核心问题之一。在众多电力设备中，绝缘子承担着电气隔离与机械支撑的双重任务，其运行状态直接影响电网的稳定性与可靠性。

在长期运行过程中，绝缘子通常会受到以下不利因素影响：

• 长期高压电场作用导致材料老化
• 风沙、盐雾、工业污染物附着
• 高湿环境下易发生表面放电
• 外力冲击造成瓷裙破损或脱落

由此产生的典型缺陷主要包括 绝缘子破损 与 绝缘子闪络。这类缺陷具有隐蔽性强、分布范围广、人工巡检成本高等特点，一旦未能及时发现，极易引发线路跳闸、设备损毁，甚至区域性停电事故。

传统的人工巡检方式已逐渐暴露出明显不足：

• 巡检效率难以覆盖大规模线路
• 高空、野外作业存在安全风险
• 检测结果依赖个人经验，缺乏一致性

在此背景下，结合无人机巡检、固定摄像头采集手段，引入基于深度学习的视觉检测技术，构建自动化缺陷识别系统，已成为智能电网发展的重要方向。

源码下载与效果演示

哔哩哔哩视频下方观看：
https://www.bilibili.com/video/BV1Qk8uz6E9f/

包含：

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址（含标注脚本

二、系统总体设计思路

本项目以 YOLOv8 目标检测模型 为核心算法，面向电力巡检场景进行专项训练，并通过 PyQt5 图形界面 实现完整的工程化封装，最终形成一套可直接投入使用的 电网绝缘子缺陷智能检测系统。

系统设计目标包括：

1. 高检测准确率：能够稳定识别破损与闪络缺陷
2. 实时推理能力：满足视频流与在线巡检需求
3. 良好可用性：非算法人员也可直接操作
4. 可扩展性强：便于后期模型升级与功能拓展

三、整体系统架构

系统采用典型的分层架构设计，各模块职责清晰、相互解耦：

┌───────────────┐
│ 数据采集层    │  图像 / 视频 / 摄像头 / 无人机
└───────┬───────┘
        │
┌───────▼───────┐
│ YOLOv8 推理层 │  缺陷检测与分类
└───────┬───────┘
        │
┌───────▼───────┐
│ 结果解析层    │  类别 / 置信度 / 坐标
└───────┬───────┘
        │
┌───────▼───────┐
│ PyQt5 界面层  │  可视化展示与交互
└───────────────┘

该架构的优势在于：

• 算法模块可独立替换或升级
• UI 与模型完全解耦，降低维护成本
• 支持本地部署或后续服务化改造
  

四、检测目标定义与业务建模

4.1 缺陷类别建模

结合电力运维业务需求，本项目共定义三类检测目标：

这种分类方式不仅能够识别缺陷类型，还可为后续缺陷定位、统计分析与风险分级提供基础数据支持。

4.2 数据集构建原则

为了保证模型在实际场景中的泛化能力，数据集构建阶段重点考虑：

• 不同拍摄高度（模拟无人机巡检）
• 不同光照条件（逆光、阴影、强反射）
• 复杂背景（山地、树林、建筑）
• 正常与缺陷样本的合理比例

数据统一采用 YOLO 标准格式，便于训练、推理与工程复用。

五、YOLOv8 模型选型与训练流程

5.1 YOLOv8 在工业场景中的优势

YOLOv8 作为 Ultralytics 推出的新一代检测模型，在工程实践中具备以下优势：

• Anchor-Free 设计，减少人工调参
• 更合理的损失函数设计，提高收敛稳定性
• 推理接口高度封装，工程接入成本低
• 兼容 ONNX、TensorRT 等多种部署形式

对于绝缘子这类尺度变化大、形态细长、背景复杂的目标，YOLOv8 在精度与速度之间取得了良好平衡。

5.2 模型训练流程

训练流程主要包括：

1. 数据清洗与标注校验
2. 训练 / 验证集划分
3. 模型初始化与参数配置
4. 多轮迭代训练与性能评估

训练过程中重点关注以下指标：

• mAP@0.5：整体检测能力
• 混淆矩阵：破损与闪络的区分效果
• Loss 曲线：模型是否稳定收敛

当模型在验证集上表现稳定后，即可用于推理部署。

六、推理流程与缺陷结果解析

YOLOv8 提供了简洁高效的推理接口，推理阶段主要完成以下工作：

• 加载训练完成的权重文件
• 对输入图像或视频帧进行检测
• 输出目标类别、置信度与边界框

在视频与摄像头模式下，系统采用逐帧检测方式，并通过合理的帧率控制，确保检测效果与实时性之间的平衡。

七、PyQt5 图形化系统设计

为了提升系统的可用性，本项目引入 PyQt5 构建桌面级可视化应用，核心功能包括：

• 多种检测模式切换（图片 / 视频 / 摄像头）
• 实时显示检测结果与缺陷标签
• 一键保存检测结果图片或视频
• 自动管理输出目录，便于后期复核

该界面设计使系统能够直接服务于运维人员与巡检人员，而不仅仅局限于算法研究。

八、典型应用场景与扩展方向

8.1 实际应用场景

• 输电线路无人机巡检
• 变电站设备日常检查
• 电网缺陷快速筛查与统计
• 智能运维示范项目

8.2 可扩展方向

• 缺陷严重程度自动分级
• 与巡检工单系统对接
• 缺陷时序变化分析
• 多模型协同检测（如分割 + 检测）

九、总结与思考

本文围绕电网绝缘子破损与闪络缺陷检测这一典型工业视觉问题，系统性地介绍了一套 基于 YOLOv8 的智能检测系统 的完整实现过程。从问题背景、系统架构、模型训练，到可视化应用与工程部署，展示了深度学习技术在电力运维场景中的实际价值。

实践表明，只有将算法能力与工程需求深度结合，AI 技术才能真正落地并产生长期价值。本项目不仅适合作为电力巡检智能化的参考方案，也为其他工业缺陷检测场景提供了可复用的技术范式。

ERROR: Could not install packages due to an OSError: Missing dependencies for SOCKS support.

最后排查了一下，发现是 vpn 的问题，我把 vpn 关了。然后把终端关了，新开一个终端再运行 pip 就行了

​

GraphicsGale是一款像素画制作软件，很多画像素图、做 GIF 动画的人都在用，体积小、功能全，还支持逐帧编辑。

它的安装包通常就是一个 .exe文件，双击就能装，下面一步步教你。

一、准备工作

安装包下载：https://pan.quark.cn/s/007523c13df9

二、安装步骤

1. 双击 GraphicsGale.exe运行。
2. 如果是 Windows 10/11，会弹出“用户账户控制”提示 → 点  “是” （需要管理员权限）。
3. 进入安装界面，选语言（默认 English，想换日语或中文可以看有没有选项，有的版本没有就默认英文）。
4. 点  “Next” ​ 继续。

5. 选安装位置：

   • 默认是 C:\Program Files\GraphicsGale，想改就点“Browse”选 D 盘或其他盘。

6. 选附加任务：

   • 建议勾“Create a desktop shortcut”（创建桌面快捷方式），点“Next”。
7. 点  “Install” ​ 开始安装，等进度条走完（很快，几秒钟）。
8. 最后点  “Finish” ​ 完成安装，桌面上会有 GraphicsGale 图标。

三、首次运行设置

1. 双击桌面图标打开软件。
2. 第一次打开可能会提示“是否注册” → 选“试用”或“Cancel”（免费版够用了）。
3. 进入主界面，就能开始画像素图了。

四、基本使用（简单说两句）

• 新建画布：点“File”→“New”，选尺寸（比如 32x32、64x64 像素）。
• 画图工具：左边工具栏有铅笔、橡皮、油漆桶、吸色器等，选了就能画。
• 保存文件：点“File”→“Save As”，支持 .gal（工程文件）、.png、.gif等格式。
• 做 GIF 动画：新建多帧画布，每帧画不同的画面，然后导出为 GIF 就行。

​

在 AI 驱动的数据分析时代，传统宽表模式因敏捷性不足、数据冗余和难以支持即席查询而力不从心。相比之下，NoETL 数据语义层（Semantic Layer）作为位于数据存储与应用间的抽象层，通过将物理数据映射为统一业务语义，实现了逻辑与物理解耦。对于需要快速响应变化、支持 AI 交互的场景，语义层架构是更具适应性的选择，能提供零等待的指标交付和 100% 一致的业务口径。

AI 时代下，传统宽表模式为何力不从心？

数据分析正从“预制品加工”转向“自助式厨房”。过去支撑报表的宽表模式，在 AI 驱动、即席查询的需求下暴露三大瓶颈：

1. 敏捷性坍塌：业务变更需回溯修改 ETL、重跑宽表，响应周期长达数周。
2. 数据一致性失控：多张口径各异的宽表导致“指标打架”，AI 模型基于此将产生不可靠洞察。
3. 无法支持即席查询：宽表只能回答预设问题，无法响应跨域、临时的分析需求。

例如，周五下午，市场部需要新指标评估促销活动。数据团队告知需新建宽表，排期至下周三。决策时机已然错过。这种“响应迟滞”在 AI 时代是致命的。

什么是 NoETL 数据语义层（Semantic Layer）？

NoETL 数据语义层（Semantic Layer）是数据存储与数据应用间的关键抽象层，其核心功能是将复杂的技术数据结构映射为统一的业务术语和指标，充当数据的“业务翻译官”。其颠覆性源于三大技术理念：

1. 解耦逻辑与物理：业务逻辑（如“销售额=价格×数量-折扣”）不再硬编码于 ETL，而是作为可复用定义存储于语义层。
2. 统一业务语义：动态编织明细数据为统一的业务语义，确保全公司对“销售额”只有一个定义，实现“单一事实来源”。
3. 实时查询下推：将“查看华东区销售额”的查询实时翻译、优化并下推至数据源执行，无需移动和预计算数据。

为什么它是 AI 时代的关键？

AI Agent 需要无歧义的上下文来准确生成 SQL。语义层提供了这份“业务词典”，为 AI 提供了稳定、可靠的数据接口，从根本上避免了因口径混乱导致的“AI 幻觉”。

Aloudata 如何基于语义层赋能 AI 驱动的分析？

作为国内数据语义编织（Semantic Fabric）领导者，Aloudata 方案的核心是：用 Aloudata CAN 自动化指标平台构建语义层，用 Aloudata Agent 分析决策智能体作为交互入口。

企业可以通过 Aloudata CAN 中连接数仓明细层，在可视化界面通过配置化的方式定义业务实体、维度和指标，构建语义模型，形成 NoETL 数据语义层，实现业务语义的标准化开发和管理，保障 100% 指标口径的一致性，避免 AI 问数的“幻觉”出现。

以 NoETL 数据语义层为底座，用户可以部署 Aloudata Agent，通过自然语言交互的方式直接提问：“上周新用户首单平均客单价？”Agent 基于语义层理解意图，通过 NL2MQL2SQL 的技术路径，先输出 MQL，再通过指标语义引擎生成 100% 准确的 SQL 语句并返回结果。

在这个过程中，用户零等待指标交付，逻辑变更分钟级生效，无需 ETL；100%一致口径，所有人与 AI 通过同一语义层访问数据；无缝对接 AI，语义层为 AI 提供标准化查询 API。

常见疑问回答（FAQ）

Q: 语义层架构的性能是否比宽表差？

不会。语义层采用智能查询下推与缓存，其优势在于在保证核心性能的同时，极大扩展了可即时响应的问题范围。

Q: 已建的宽表和数据仓库，是否要推倒重来？

不需要。语义层是增强层。Aloudata CAN 可直接连接现有数据资产，在其之上构建统一语义，保护投资的同时解锁新能力。

Q: 语义层如何保证数据安全与权限控制？

企业级产品（如 Aloudata CAN）提供行列级权限管控，并将规则与语义模型绑定。任何查询都会自动注入权限过滤，确保安全合规。

很多企业的指标越做越多，决策却越来越慢：会上报数热闹，真正的“下一步做什么”说不清。根因往往不是数据不够，而是缺少一套能对齐战略、解释因果、嵌入节奏的产品指标体系。本文用一套“5步法”把北极星、指标树、漏斗、治理与看板串成可执行路径，让指标从“汇报材料”变成“决策语言”。

关键词聚合：产品指标体系｜北极星指标（North Star Metric）｜指标树（Driver Tree/KPI Tree）｜AARRR 漏斗（Pirate Metrics）｜HEART 体验指标｜OKR｜指标口径｜数据治理｜数据质量｜数据看板/仪表盘（Dashboard）

为什么你的指标越做越多，决策却越来越慢？

我在不同规模的组织里反复见到一个现象：指标体系做得很“全”，管理却做得很“虚”。 每个部门都能拿出一组“看起来不错”的数字，但一旦追问“这些数字如何改变用户价值、如何影响长期收入”，讨论就会迅速滑向口径争执、责任推诿，最后以“下次再看”收场。

更棘手的是，一些“可展示但不可驱动”的指标会天然占据汇报舞台：曝光、下载、浏览量、粉丝数……它们往往能让人产生“我们在变好”的错觉，却很难直接导向下一步行动。组织越依赖这类指标，越容易陷入“报数化”，决策反而越来越慢。

所以问题不在于缺指标，而在于缺一套能把“指标—行动—结果—复盘”真正连起来的产品指标体系。当指标只用来展示，它会越来越像装饰；当指标用来决策，它才会成为组织能力。

方法论：一套好的产品指标体系，至少解决三件事

关键定义：什么是“产品指标体系”？

产品指标体系不是一张报表，也不是 KPI 清单，而是：

一套围绕“用户价值与业务价值”建立的指标结构（指标分层+指标口径+数据治理+看板节奏），用于支持决策、资源配置与持续改进。

它至少要同时解决三个问题：方向是否一致、原因是否可解释、行动是否能闭环。

1）对齐：让“用户价值”和“业务价值”说同一种话

中高层最怕的不是指标不好看，而是组织努力方向不一致：产品追功能，运营追热度，销售追签约，最后用户体验与续费被牺牲。我通常建议用“北极星指标（North Star Metric）”做对齐：用一个最核心的指标把方向统一，避免资源在部门之间相互抵消。

2）可解释：从“指标清单”升级为“因果链条”

有数字不等于有洞察。你需要的不是几十个 KPI，而是一棵能解释“为什么上升/下降”的指标树（Driver Tree / KPI Tree）：把结果指标拆解为可影响的驱动因素，帮助团队定位杠杆、做资源配置。

3）可运营：把指标嵌入节奏，而不是只在月底出现

指标体系发挥作用，靠的是机制：看板怎么设计、例会怎么开、异常怎么处理、动作怎么验证。否则指标会退化成“月度PPT”。这里要特别警惕一个规律：当指标被当作硬目标与奖惩绑定时，人会“优化指标”而不是“优化系统”。

5步法：从“定方向”到“能落地”的产品指标体系搭建路径

一页速览（可直接做成内部共识页）
1）定北极星（方向） → 2）搭指标树（因果） → 3）串漏斗（旅程） → 4）建治理（可信） → 5）上看板（闭环）

第一步：定北极星——先把“我们到底要变好什么”说清楚

北极星指标怎么选？一句话答案：选“最能代表用户核心价值、且能牵引长期业务结果”的那一个。

北极星三条硬标准（评审时直接照此打分）

• 代表用户核心价值（不是内部产出）
• 与商业结果强相关（能解释留存、续费、复购、成本效率等）
• 不能被短期手段直接拉动：如果一个指标能被刷量、活动堆资源迅速抬高，它往往不适合作为北极星（会把组织带偏）。

常见误选（也是中国企业最常见的“走歪点”）

• 误把“营收/签约额”当北极星：这是结果，但难指导产品日常动作；
• 误把“DAU/访问量”当北极星：易被流量手段劫持，且未必代表价值达成；
• 误把“上线功能数/迭代次数”当北极星：这是输出不是结果，容易把组织带向“忙而无功”。

产出物（务必落在纸面）

• 北极星指标（1个主选+1个备选）
• 3~5个输入指标（能被日常工作影响）
• 关键假设清单（本季度必须验证的因果假设）

落地提示：北极星与关键假设最怕“只在会议上存在”。实践里我更建议把它们沉淀成可追溯、可讨论、可复用的“产品共识页”（例如 PRD/策略说明/指标定义页），并允许后续迭代版本化。像 ONES Wiki 这种知识库工具支持富文本/Markdown、评论讨论、版本记录与回滚，也支持把文档与项目任务关联起来，便于“战略—需求—迭代”同源追踪。

第二步：搭指标树——把结果拆到“可被影响”的驱动指标

指标树怎么画？一句话答案：把滞后结果拆成领先杠杆，让团队能“事前纠偏”而不是“事后复盘”。

我在项目里常用一句话提醒团队：

只看结果，你永远在解释过去；有领先指标，你才可能改变未来。

拆解三条纪律（避免“拆得很细但毫无行动价值”）

• 可控性：拆到团队能影响的层级，否则只是压力传导；
• 可解释性：每条分支必须讲得清“为什么会影响上层指标”；
• 可验证性：允许被数据检验，避免拍脑袋“伪因果”。

一个通用指标树骨架（可直接复用）

北极星（结果）：每周/每月“价值达成”的客户或用户规模

• 覆盖：进入价值路径的比例（从“进入”到“达成”）
• 深度：价值行为频次/协作深度（从“能用”到“用好”）
• 稳定：关键流程成功率/性能/缺陷（从“可用”到“可靠”）
• 留存：次周/次月留存、续费前置信号（从“发生”到“持续”）

指标卡片（Metric Card）：口径统一的最低成本做法

每个关键指标至少写清：

• 指标定义（口径）｜计算公式｜数据来源（埋点/表/系统）
• 更新频率｜Owner（业务Owner）｜使用场景（用于什么决策）

检查点：如果会开到最后仍在争“活跃到底怎么算”，说明你缺的不是分析能力，而是指标卡片与口径库。

落地提示：指标卡片不是“数据团队的文档”，而是产品团队的“决策字典”。我见过做得比较顺的团队，会把指标卡片放在知识库里，同时在需求/用户故事/实验任务上引用同一口径，避免“文档一套、执行一套”。ONES Wiki 支持文档关联项目任务、并能嵌入工作项列表；ONES Project 则覆盖需求管理、迭代管理等场景，能把“要改什么”直接落到工作项上。

第三步：串漏斗——把“增长与留存”讲成同一种语言

漏斗怎么定义？一句话答案：把用户从“进入—首次价值—持续使用—付费/续费”的关键路径，用事件+时间窗固化为可运营指标。

在B2B/复杂产品里，漏斗最容易失败的两件事

• 激活定义含糊：只写“完成注册”，没有“首次价值达成”；
• 没有时间窗口：不规定“7天内/14天内”，漏斗就无法比较、无法运营。

推荐做法：把“激活”定义为“首次价值达成（First Value）”。B2B 常见示例：

• T天内完成关键配置 / 跑通关键流程一次
• 首次协作达成（≥2角色、≥1流程闭环）
• 首次产出可交付结果（报表/审批/工单闭环等）

产出物

• 关键路径（用户旅程）图
• AARRR 各阶段的“决策级指标”（每段1~2个）
• 每个指标对应的“可运营动作库”（触达、引导、产品改造、质量改进）

落地提示：漏斗不是“画出来”，而是“跑起来”。所以建议你把每个漏斗节点的改进动作拆成可执行的产品工作项：比如“激活引导改版”“关键任务模板”“首个价值路径埋点补齐”“新手引导实验A/B”等，并按优先级进入需求池。比如 ONES Project 提到其支持建立需求池、规划迭代，并可通过看板、燃尽图等跟踪进度——这类能力更适合承载产品团队“从漏斗诊断到迭代交付”的连续动作。

第四步：建治理——口径统一、数据可信、权责闭环

治理怎么做？一句话答案：把指标当“管理资产”来管，像管需求一样管口径、质量与变更。

很多企业的产品指标体系失败，不是方法错，而是“治理缺席”：同名不同口径、数据延迟、指标无人负责，最后只能“用感觉决策”。

治理四件套（PMO 最适合牵头）

• 指标口径库：统一定义、统一版本、可追溯
• 数据质量红线：准确性、完整性、一致性、及时性（不达标必须标注风险）
• Owner机制：业务Owner 对指标解释与改进负责（数据同学负责“数的正确”）
• 变更控制：口径/埋点/报表变更必须评审、公告、可回溯

检查点：如果一个指标没有Owner，就没有人对“为什么变动、下一步怎么改”负责——它迟早变成“会议装饰”。

落地提示：很多产品团队在“指标治理”上忽略了一件事：指标体系不仅要管增长，也要管质量与体验。一个常见闭环是：需求→开发→测试→缺陷→复盘，如果链条断了，你会在“指标下降”时找不到可修复的抓手。ONES TestCase 支持测试用例与需求/任务关联、测试计划与迭代关联，并可由未通过用例快速创建缺陷任务；ONES Project 也与 TestCase 数据互通、可一键提 Bug 并跟踪缺陷。对产品团队而言，这意味着“漏斗问题”可以更快落到“版本质量与缺陷修复”的可执行闭环。

第五步：上看板——用“看板+例会+复盘”把指标变成组织习惯

看板怎么做？一句话答案：看板不是展示页，而是“决策清单”——每次例会都要产出动作与验证方式。

三层看板（与组织层级匹配）

• 经营层看板：北极星 + 关键结果（季度视角）
• 产品层看板：指标树主干 + 漏斗关键节点（双周/月度节奏）
• 专项看板：版本/实验/活动（短周期验证，明确假设与样本）

OKR 如何衔接指标体系？

• OKR 的 KR 要“可衡量、可复盘、能驱动对齐”。因此我建议的硬规则是：
• KR 优先来自“指标树主干 + 漏斗关键节点”；
• 每个KR必须对应：动作（做什么）+ 证据（怎么证明有效）；
• 复盘只讨论：事实—解释—动作，避免变成表态会。

落地提示：

产品经理常见痛点是：单个迭代看得清，多项目/多团队协同就看不清（依赖、资源、节奏容易失控）。在这种情况下，除了迭代看板，还需要“产品线/项目集”层面的汇总视角。ONES 的项目集管理解决方案强调为管理者提供全局视角、支持跨项目制定迭代计划；同时 ONES Project 也提供看板、燃尽图与多种报表来呈现项目表现。你不需要把看板做得花，关键是把它绑定到“例会—异常—动作—验证”的固定节奏上。

如果你还想把“指标体系”落实到更稳定的度量面（交付效率、交付质量、资源效率等），ONES Performance 提到其建立多维度效能度量实践体系，并提供仪表盘模板与多维分析能力，可用于跨团队的趋势复盘。

常见误区：产品指标体系最怕“越努力越错”

误区1：指标越多越安全
指标多往往意味着焦点分散。建议先把“决策级指标”控制在 10~20 个，其他作为诊断指标按需展开。

误区2：只盯增长，不看体验与质量
如果产品进入长期经营阶段，建议把体验纳入指标体系。HEART 框架提供五类 UX 指标：Happiness、Engagement、Adoption、Retention、Task Success，并强调不必每次都用全量指标，应按目标选择组合。

误区3：把指标当考核“唯一答案”
当指标直接绑定奖惩，人会优化指标而不是优化系统，这是典型的古德哈特风险。
更成熟的做法是：指标用于“方向与学习”，考核看“过程合规 + 结果趋势 + 关键里程碑”，避免单点指标绑架组织。

常见问题 FAQ：

Q：北极星指标可以有两个吗？
A：强烈建议“一条业务线一个北极星”，否则对齐会被稀释；若多业务线，可采用“业务线北极星 + 集团约束指标”。

Q：指标树拆到多细才算够？
A：拆到“团队可控、可行动、可验证”为止；再细会变成噪音。

Q：产品经理最容易把哪一步做成形式？
A：第三步与第五步——漏斗没变成需求池动作、看板没绑定复盘节奏，最后都会退化成“好看的图”。

一套真正有效的产品指标体系，最终在提升一种组织能力：

• 用北极星对齐方向，减少内耗；
• 用指标树解释因果，把结果变成可驱动的杠杆；
• 用漏斗运营旅程，把增长与留存放到同一条价值路径上；
• 用治理保证可信，让复盘基于同一套事实；
• 用看板与 OKR 固化节奏，把学习变成组织习惯。

当指标从“月底报表”走向“日常决策”，管理不会更冷，反而更诚实：因为每一次取舍，都能被解释、被验证、被复盘。对中高层与 PMO 来说，这才是指标体系真正的价值——把组织从“讲故事”带到“做学习”。

供应链、交付、现金流压力一上来，很多公司才发现：ERP不是“有没有”，而是“能不能在手机上把事办完”。
移动ERP选对了，核心是让审批、开单、库存、对账这些高频动作随时闭环。

一、主流移动ERP系统详细盘点

1、支道

支道是“一站式业务管理平台”，而不是那种固定菜单的传统ERP：你可以用它把采购、销售、项目、费用、审批、数据看板等流程按自己业务搭起来，然后在移动端跑起来。支道官方站点与App信息里都明确提到其以低代码/aPaaS等方式提供业务全流程数字化管理能力，背后主体为浙江支点数字科技有限公司。

如果你们的痛点是“流程散、表格多、跨部门全靠催”，支道通常比换一套重ERP更快见效。

推荐理由：

1、适合“业务变化快”的团队：流程、表单、权限经常要调整，不想每次都找开发改系统。

2、移动端上手快：App商店可查，适合把填报、审批、协同、数据汇总搬到手机上处理。

产品特色：

1、流程能“按你公司习惯走”：不是让你适应系统，而是系统更容易贴合你的流程。

2、数据能汇总到一处：减少“同一份数据多处填、多版本对不上”的情况。

3、适合先从一个部门/一条流程试起：跑通后再扩，不容易翻车。

适合场景/行业：

项目型/专业服务类公司、以及需要快速搭建内部流程的成长型企业。

2、金蝶

金蝶在小微与中小企业的移动端体验上做得比较成熟，尤其是“金蝶云星辰”这类产品，官方页面强调覆盖采购、销售、库存、资金等链路；同时其App商店信息也强调移动端经营看板、开单、审批等能力

1、推荐理由：想用手机把生意管住（开单/库存/资金），金蝶这条线比较稳。

2、产品特色：进销存与资金链路打通，移动端可做经营与待办处理。

3、适合场景：小微工贸、零售商家、轻量制造或商贸企业。

4、可能的局限：更偏“经营执行与老板看数”，复杂集团多业态要看更高阶产品与实施能力。

3、用友

用友体系里，“友空间”作为移动协同与门户入口，官方页面直接写到：一个App访问多系统、移动快捷审批、实时处理业务；App商店也强调可按组织/角色配置移动门户。

1、推荐理由：如果你们审批链条长、跨部门多，用友的“移动入口+审批”更容易打通。

2、产品特色：移动工作台、待办审批、业务单据一键访问。

3、适合场景：成长型企业、集团型组织的移动协同与业务处理。

4、可能的局限：体系更大，落地往往更依赖实施与规划。

4、鼎捷

鼎捷“掌上易助”页面写得很直白：提供易助小程序，用于满足ERP用户移动化需求；同时易助ERP介绍中也强调其面向中小微制造企业，覆盖财务、进销存、生产等模块。

1、推荐理由：制造企业经常是“人不在电脑前”，小程序入口更容易推广。

2、产品特色：面向中小微制造的ERP体系 + 移动端应用入口。

3、适合场景：机械、五金、汽配、电子加工等中小制造。

4、可能的局限：如果你是多工厂、多语言、多币种的全球化集团，需要评估更高阶产品线。

5、浪潮

浪潮移动ERP在App商店描述中明确写到：提供移动首页、功能中心、移动审批、协同消息等，并可接入后台业务系统。

1、推荐理由：你要的是“统一移动入口+审批协同”，浪潮这类更对路。

2、产品特色：移动首页、功能中心、待办审批、协同消息等。

3、适合场景：高端集团企业移动化协同场景。

4、可能的局限：更偏“集团移动门户”，中小企业如果只要轻量进销存，可能会显得偏重。

6、网上管家婆

网上管家婆官网与App商店信息都提到：移动版为中小微打造，覆盖采购、销售、库存、财务等；并支持电脑、手机、平板、PDA多终端数据同步。

1、推荐理由：商贸批零电商最常见的诉求是“开单快、盘点快、对账清楚”。

2、产品特色：多终端同步、扫码操作、进销存+财务基础闭环。

3、适合场景：批发、零售、电商等。

4、可能的局限：更强在执行层，复杂制造/项目型的深度协同要另评估。

二、6款移动ERP对比表

三、选型建议与关键知识

移动ERP成不成功，不取决于“功能多不多”，取决于“用的人愿不愿意天天用”。

1、先定“移动端三大高频动作”

（1）审批：合同/付款/报销/采购申请

（2）业务动作：开单、查库存、对账、收发货

（3）现场回填：项目进度、巡检、异常上报

2、再看“供应商/协作方是否好用”

（1）入口轻不轻，有没有App、小程序、网页

（2）操作顺不顺，能不能3步以内完成常用动作

3、再看“你现有系统怎么接”

（1）已有财务/ERP/OA？优先选接口开放、能集成的。

（2）用友/金蝶生态用户，走原生或强集成路线通常更省心。

4、最后算总成本，不只看软件费

（1）实施、培训、对接、运维、人力配合成本都要算进去。

（2）最稳的做法：先做PoC，拿你们真实单据和流程跑一遍。

总结：如果你只想先把“移动闭环”跑起来，支道确实应该先看

很多企业的真实情况是：流程不标准、变化快、协同靠人盯。这个时候，支道这种更偏“可搭建、可迭代”的路线，往往更容易先拿到效果，再逐步扩到更完整的管理体系。

作者：齐海智

在 618 大促的技术战场上，每一行代码、每一个配置都影响着一线的实实在在的业务。一次看似平常的发版，却意外暴露了我们系统中的定时任务管理短板，这促使我们深入剖析分布式任务调度中异常重试机制的技术细节，并最终将其转化为守护系统稳定性的坚固防线。​

一、异常事件回溯：隐藏在发版背后的定时炸弹​

发版次日，业务部门反馈商家未收到门店收货明细邮件，导致门店收货业务收到影响。技术团队迅速启动应急流程，通过全链路日志追踪和系统状态分析，发现了问题的根源是：发版过程中，由于服务重启，中断了定时任务进程，正在执行的邮件发送任务被意外终止。而该任务在管理平台上并未配置任何重试策略，业务代码上也没有进行相关的检测和重试，这就导致任务失败后无法自动恢复执行，也未被及时感知到，进而引发业务阻断。​

为解决燃眉之急，研发人员立即登录任务管理平台，手工触发邮件发送任务，确保业务及时恢复。但这次事件给我们敲响了警钟：在分布式任务调度场景下，面对网络抖动、进程异常终止等场景，异常重试机制是保障业务可靠性的关键。​

二、重试策略设计：从理论到代码的深度解析​

2.1 验证EasyJob的重试策略

在复盘问题的过程中，我们发现了EasyJob分布式任务是具有重试策略的，只是默认不开启，而不是默认开启。





该策略以三个核心参数为基础：首次重试间隔时间 F、重试间隔乘数 M 和最大重试次数 C。

通过这三个参数的组合，我们可以灵活控制任务重试节奏，平衡系统负载与任务恢复效率。​

例如：配置t=10s, M=2, C=10，则间隔时间依次是：

验证日志：

21:45:29.990 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:45:40.204 [main-schedule-worker-pool-1-thread-2] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:46:00.674 [main-schedule-worker-pool-1-thread-3] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:46:41.749 [main-schedule-worker-pool-1-thread-4] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:48:02.398 [main-schedule-worker-pool-1-thread-5] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:50:43.008 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务

与上面计算的一致。

验证方案：

1、实现接口：com.wangyin.schedule.client.job.ScheduleFlowTask，并设置任务返回失败：





2、创建CRON触发器





3、设置自动重试参数





4、暂停任务并手工触发一次



2.2 实现一个简单的重试策略

根据上述策略，简单实现了一个灵活可配置的任务重试机制。

public class TaskRetryExecutor {
    @Getter
    private final ScheduledExecutorService executor = newScheduledThreadPool(10);
    private final long firstRetryInterval;
    private final int intervalMultiplier;
    private final int maxRetryCount;

    public TaskRetryExecutor(long firstRetryInterval, int intervalMultiplier, int maxRetryCount) {
        this.firstRetryInterval = firstRetryInterval;
        this.intervalMultiplier = intervalMultiplier;
        this.maxRetryCount = maxRetryCount;
    }

    public void submitRetryableTask(Runnable task) {
        executeWithRetry(task, 1);
    }

    private void executeWithRetry(Runnable task, int currentRetryCount) {
        executor.schedule(() -> {
            try {
                task.run();
                log.info("任务在第{}次尝试时成功执行", currentRetryCount);
            } catch (Exception e) {
                log.error("任务在第{}次尝试时执行失败", currentRetryCount, e);
                if (currentRetryCount <= maxRetryCount) {
                    long delay = calculateRetryDelay(currentRetryCount);
                    log.info("计划在{}毫秒后进行第{}次重试", delay, currentRetryCount);
                    executeWithRetry(task, currentRetryCount + 1);
                } else {
                    log.error("超过最大重试次数。任务执行最终失败。");
                }
            }
        }, currentRetryCount == 1 ? 0 : calculateRetryDelay(currentRetryCount), TimeUnit.MILLISECONDS);
    }

    public long calculateRetryDelay(int retryCount) {
        if (retryCount == 1) {
            return firstRetryInterval;
        } else if (retryCount > 1 && retryCount <= maxRetryCount) {
            long previousDelay = calculateRetryDelay(retryCount - 1);
            return previousDelay * intervalMultiplier;
        }
        return -1; // 超出最大重试次数，返回错误标识
    }
}

​在上述代码中：

1.TaskRetryExecutor类封装了任务重试的核心逻辑。构造函数接收三个关键参数：firstRetryInterval、intervalMultiplier和maxRetryCount，用于配置重试策略，对应于EasyJob的F、M、C参数。

2.submitRetryableTask方法接收一个可执行任务，并启动重试流程。它调用executeWithRetry方法，初始重试次数为1。

3.executeWithRetry方法是重试逻辑的核心。它使用ScheduledExecutorService来调度任务执行：

◦如果任务执行成功，记录成功日志。

◦•如果任务执行失败且未超过最大重试次数，计算下一次重试的延迟时间，并递归调用自身进行重试。

◦•如果超过最大重试次数，记录最终失败日志。

4.calculateRetryDelay方法实现了重试间隔的计算规则：

◦第一次重试使用firstRetryInterval。

◦之后的重试间隔是前一次间隔乘以intervalMultiplier。

◦如果超出最大重试次数，返回-1表示错误。

通过这种设计，我们实现了一个可复用、可配置的任务重试机制。它能够根据配置的参数自动调整重试间隔，在任务失败时进行有策略的重试，同时避免无限重试导致的资源浪费。

详细代码可在以下Git仓库中找到：mailto:git@coding.jd.com:newJavaEngineerOrientation/TaskRetryStrategies.git

2.3 重试策略的理论分析

2.3.1 EasyJob对乘数和最大重试次数的限制

在对EasyJob也进行了重试的验证中发现：

1.每次重做的乘数取值范围是[1,8]，可以是具有一位小数位的浮点数，比如3.5，

2.最多重做次数是[1,16]间的整数，第一次重试的间隔没有限制，单位是秒。



2.3.2 梯度分析

通过上面的验证和重试相关概念的定义，可以得到：第n次重试的间隔时间=第一次间隔时间*乘数^(n-1)，即：

其中：



对乘数M的梯度：

对重试次数n的梯度：



详细推导： http://xingyun.jd.com/codingRoot/newJavaEngineerOrientation/T...

从下图可以看出，重试次数n较大时（比如8），乘数 M 的细微变化都会导致，任务的间隔时间发生剧烈变化，因此n超过8之后，M基本不可调。



同样的，从下图可以看到，乘数M较大时（比如4），n的细微变化也会导致任务的间隔时间爆发式的增加。



1、乘数在1.5-4 的合理性

过小乘数 (<1.5) 的问题：

当乘数 = 1.2，重试 10 次的间隔时间是：1次:1, 2次:1.2, 3次:1.44, ..., 10次:5.16，

10 次重试总间隔仅 5 倍，接近固定间隔，可能导致 "惊群效应"（大量请求同时重试）。

过大乘数 (>4) 的问题

当乘数 = 8，重试 5 次的间隔时间：1次:1, 2次:8, 3次:64, 4次:512, 5次:4096

5 次重试后间隔已超 1 小时（假设初始间隔时间是最小的1s，4096s>1小时），可能导致请求长时间等待，用户体验差。

因此，乘数 = 1.5-4 在 "退避效率" 和 "资源消耗" 间取得平衡，一般取乘数= 2 （标准指数退避）。

行业实践：AWS SDK 默认乘数 = 2，Google gRPC 重试策略推荐乘数 = 1.5-3，多数 HTTP 客户端库 (如 requests) 默认乘数 = 2。

2、最大重试次数3-10的合理性

假设单次重试成功概率为P（比如网络/服务临时故障，重试成功概率通常较高），重试 n次至少成功 1 次的概率为：



当 p=0.5，（单次重试 50% 成功概率）：

n=3 时，成功概率 =1−(0.5)^3=87.5%

n=5 时，成功概率 =1−(0.5)^5=96.875%

n=10 时，成功概率 =1−(0.5)^10≈99.9%

实际场景中，临时故障的单次成功概率远高于 50% （比如网络抖动重试成功概率可能达 80%）

若 p=0.8，n=3时成功概率已达 1−0.2^3=99.2%几乎覆盖所有临时故障。

因此，3 - 10 次重试，能以极高概率（99%+）覆盖“临时故障”场景，再增加次数对成功概率提升极有限（边际效应递减）。

因为已知的任务延迟时间的公式是：

n从1到C进行累加得到总耗时:

，

根据等比数列求和公式可以得到：



令 M=2（常用乘数），F=1 秒（最小可能值）：

n=3时，T=（2^3-1）/（2-1）=7秒

n=5时，T=(2^5-1)/(2-1)=31秒

n=10时，T=2^10-1=1023秒≈17分钟

n=13时，T=2^13-1≈2.3小时

n=15时，T=2^15-1≈9.1小时

当n超过10后，每次增加都会导致总耗时急剧增长，很容易超过业务的容忍上限（具体业务具体分析），也可能因为重试过多，导致被调用的系统压力增加，甚至造成系统崩溃。

故：3 - 10 次重试可将总耗时控制在“业务可接受范围”（几秒到十几分钟），同时避免资源过载。

行业实践：Kafka 消费者重试：默认 10 次、Redis 客户端重试：默认 5 次、Hadoop 任务重试：默认 3-5 次、RFC 建议：RFC 6582（HTTP 重试）建议：3-5 次重试。

3、最佳实践速查表

三、经验沉淀：异常重试机制的设计原则​

通过这次实践和对行业方案的研究，我们总结出异常重试机制设计的四大核心原则：​

1.动态适应性原则：重试策略应支持参数化配置，根据业务场景和系统负载动态调整重试间隔和次数，避免 “一刀切” 的重试策略对系统造成冲击。​

2.幂等性保障原则：确保任务在多次重试过程中不会产生重复数据或副作用，通过唯一标识、状态机等技术手段，实现任务的幂等执行。​

3.故障隔离原则：将重试逻辑与业务逻辑分离，通过消息队列、异步调度等方式，降低重试操作对主线程的影响，避免因重试失败导致系统整体崩溃。​

4.可观测性原则：建立完善的监控和告警体系，实时追踪任务重试状态，在达到最大重试次数时及时发出告警，便于运维人员快速定位和解决问题。​

四、结语：以技术沉淀筑牢大促防线​

这次线上异常事件，犹如一面镜子，让我们清晰地看到了系统中的潜在风险，也为我们提供了一次宝贵的技术提升机会。通过对异常重试机制的深入研究和实践，我们不仅解决了当前问题，更将这些经验转化为团队的技术资产。在未来的 618 大促及其他关键业务场景中，我们将以更完善的技术方案、更严谨的设计原则，守护系统的稳定运行，为业务发展提供坚实的技术保障。

作者：蔡欣彤

项目说明

这是一个同时支持stdio，streamableHttpless和sse三种协议的MCP-Server的框架（ts语言）。

为什么我想做这个框架呢？因为随着AI发展，现在越来越多业务需要和AI相结合。而我在做AI应用中发现，MCP服务在AI方向的业务使用频率很高，但随着业务的加深，发现存在以下痛点：

1.针对不同业务，对于mcp-server需要的类型不同，有的就需要stdio，有的需要网络请求

2.不同平台对MCP服务协议要求不同，有支持streamableHttp，有仅支持sse的。

这两种情况，会出现相同功能重复开发，重复造轮子，浪费时间成本

3. 此外，有些研发人员目前并不了解MCP，在业务开发时候需要现学

而这会让研发周期加长，时间成本耗费过多

所以为了解决以上痛点，我从0-1搭建了这个框架。这个框架特点：

1.同时支持stdio，streamableHttpless和sse三种模式，实现一次开发支持三种模式

2.所有功能都拆分为独立模块。这样即使不懂的人，只要在指定的文件里面编写业务逻辑，就可以创造自己的mcp服务

3.支持环境变量，可通过环境变量配置域名，服务地址，端口和host，真正适用于生产使用

4.切换模式也很简单，只要在启动脚本根据需要，切换启动命令即可，改动成本近乎无

5.添加日志模块，方便查阅启动和服务调用情况

6.同时添加行云脚本，支持行云部署

github地址：https://github.com/XingtongCai/mcp-server-ts

coding地址： http://xingyun.jd.com/codingRoot/jdcloud-fe/mcp-server/tree/m...

内容介绍

整个框架的结构很简单，就如下这些：

## 目录结构
- build: 编译之后的文件
- src
 -- router: 配置streamableHttp和sse协议的路由
   -- index.ts: 注册streamableHttp路由入口
   -- mcp.ts: streamableHttp的配置路径，具体为`process.env.MCP_BASE_PATH`的路径请求,如果没有配置，默认/mcp。如果有需要添加二级路径，例如 /mcp/event，需要在这里面添加一下/event,如果一级不用动
   -- sse.ts: sse的配置路径，具体为`process.env.MCP_BASE_PATH`的路径请求,如果没有配置，默认/mcp。如果有需要添加二级路径，例如 /mcp/event，需要在这里面添加一下/event,如果一级不用动
 -- tools: mcp的工具 
   -- index.ts: 注册工具
   -- mockFunc.ts: 模拟一个工具写法 - 这部分需要根据业务开发
 -- cli.ts: 命令行解析工具
 -- index.ts: 总入口
 -- server.ts: 创建Mcp服务
 -- sse.ts: 运行sse模式
 -- stdio.ts: 运行stdio模式
 -- streamableHttp.ts: 运行streamableHttp模式
- xingyun/bin : 是根据我们业务使用的部署工具开发的部署脚本 - 这部分需要根据实际部署平台更改，我这个支持行云部署
- build_xingyun.sh: 是根据我们业务使用的部署工具开发的部署脚本 - 这部分需要根据实际部署平台更改，我这个支持行云部署

启动服务方式

a.本地启动

1.启动stdio: npm run start 是默认启动stdio

2.启动StreamableHttp: npm run start:http 是默认启动端口3001

3.更改端口启动StreamableHttp: npm run dev:http 或者 npm run start -- -t http -p 3001

-t httt: 代表启动StreamableHttp

-p 3001: 代表启动端口3001

4.启动sse: npm run start:sse 是默认启动端口3001



b.部署启动

我在 xingyun/bin/control.sh中写的启动脚本，这段代码是启动streamableHttpless的，如果需要启动sse，需要改为 npm run start:sse

start(){
    npm run start:http
    sleep 3
    status
}

生产环境配置

# 监听特定内网IP（例如：192.168.1.100）
export MCP_HOST=192.168.1.100
export MCP_PORT=3001

# 使用内网域名（可选）
export MCP_DOMAIN=mcp-server.internal.com

# 修改基础路径（可选，默认是 /mcp）
export MCP_BASE_PATH=/api/mcp

<!---->

### 端口配置优先级
1. 环境变量 `MCP_PORT`（最高优先级）
2. 命令行参数 `--port` 
3. 默认值：3001端口

### 访问地址优先级
1. 环境变量 `MCP_DOMAIN`（最高优先级）
2. 环境变量 `MCP_HOST`
3. 默认: localhost

<!---->

### 内网访问方式
假设你的内网服务器IP是 `192.168.1.100`，端口是 `3001`：

**基础访问：**
```
http://192.168.1.100:3001/sales
```

**带域名的访问：**
```
http://mcp-server.internal.com/sales
```

**自定义路径：**
```
http://192.168.1.100:3001/api/mcp



项目关键代码说明

这个是package.json文件，也是我们一开始要看的，cli.js这个文件是我们启动文件，也是解析命令行的工具，真实区分的地方在index.ts文件中

"scripts": {
    "build": "tsc && chmod 755 build/src/index.js  build/src/cli.js",
    "start": "node ./build/src/cli.js",
    "start:http": "node ./build/src/cli.js --transport http",
    "start:sse": "node ./build/src/cli.js --transport sse",
    "dev:http": "node ./build/src/cli.js  --transport http --port 3002",
    "stop": "pkill -f "demo" || true",
    "restart": "npm run stop && npm run start:http",
    "inspector": "npx @modelcontextprotocol/inspector"
  },

index.ts 的关键代码，在这区分不同模式，然后进入到各自的处理模块。各自模块就是调用sdk，配置域名等操作，代码过长，不展示了，但是这几个文件不用动。




StreamableHttp.ts我支持的是less，就是我不需要sessionId，如果有需要的，这块需要再自己改一下！！





server.ts 是创建mcp服务，同时注册tools工具，三个模式都需要使用的公共文件



tools/index.ts, 作为工具入口，一个工具一个注册



router文件夹下路由注册，是为了sse和streamableless的路由。



其中streamable的index.ts文件里面关键内容，其中basePath就是你的基础路径，通过定义指定访问路径。





sse的在sse.ts文件中，定义了get和post的方法





其实整个框架到这关键的代码就说完了。剩下xingyun的就是在行云平台部署和启动需要的脚本，这里就不介绍了



成果展示

1.stdio - 发布了依赖包，并用joycode成功联通

https://npm.m.jd.com/package/@jd/demo-mcp-server





2.streamableHttp - joycode成功联通并且可以运行





3.sse - autobots支持sse模式，用这个框架开发了在业务中使用的 权限拦截MCP,并成功在autobots引入