一个人的发行部：我是如何把 AI Skill 铺到 10+ 个渠道的

我的工作处境

我是一名 AI 产品经理，负责公司 Skill 产品面向 C 端的产品和运营。翻译一下这句话的实际含义：

  • 产品迭代是我的：功能规划、版本管理、需求文档；
  • 渠道分发是我的：上架、更新、跟平台方对接；
  • 数据运营是我的：下载量监控、增长归因、周报；
  • 商务推进还是我的：推荐位提报、生态合作。

四个职能，一个人。没有运营同学帮我盯数据，没有商务同学帮我跑渠道。

但我有一个别人没有的东西：一支随叫随到的 AI Agent 编队。这篇文章讲的就是我怎么用这套体系，把公司的 Skill 产品铺到了 10+ 个渠道，并让整条数据链路实现无人值守。

产品矩阵：从 2 个到 7 个

上半年，我负责的 Skill 产品线从 2 个扩展到了 7 个：

Skill定位
深知公文写作公文写作助手，下载量主力
深知晓政务政策可信问答
DKnownAI Guard大模型安全检测
深知可信搜索可信搜索入口
深知可信咨询咨询师式多轮深挖
深知可信 PPT政务汇报材料生成
深知可信投研投研场景可信检索

每个 Skill 都有完整的产品生命周期：需求定义、版本迭代、渠道包构建、上架、数据回收。

渠道矩阵：一个产品 × 十个货架

真正让这件事变难的，是渠道的碎片化。同一个 Skill，要面对形态完全不同的分发阵地：

  • SkillHub（腾讯云生态）：核心渠道，有企业版专区，我们的公文写作在这里拿过”公文写作竞技场”同轮测试第一；
  • ClawHub（OpenClaw 生态）：要同时维护个人版和公司组织版两套账号；
  • ModelScope 魔搭：模型平台，有自己的渠道码和上架规范；
  • 科大讯飞 Astron、虾评、Qoder、火山引擎 AgentMesh、skills.sh：每家都有自己的审核流程、目录结构、元数据要求；
  • WorkBuddy：要走人工提报的生态合作，需要准备成套的 Playbook 案例材料；
  • GitHub：自有仓库作为兜底分发和信任背书。

粗略算一下：7 个产品 × 10+ 个渠道，任何一个功能的版本更新，理论上都要触发几十次渠道包构建和上架操作。

我拒绝手工维护台账

一开始，我和大多数人一样，用一个 HTML 台账手工记录：什么渠道、什么版本、什么时候发的、下载量多少。

三周之后我放弃了。我对 Agent 说的话后来成了这个项目的初心：

“我就是不想手动输入数据，想尽量做到自动监控和 agent 上传。”

这句话逼出来的，是后来整个体系的架构决策：

  1. 放弃飞书/Airtable 这类”记录工具”——它们的本质还是人工录入；
  2. 选择 GitHub 作为工作中枢——Actions 可以跑采集脚本，仓库本身就是数据库和看板；
  3. 配置驱动——新增一个 Skill 或渠道，只需要改一行配置，不改代码。

流水线：从一次提交到十个货架

现在，一次完整的分发流程长这样：

主干版本迭代（full 版，含完整能力）
    ↓ 以 SkillHub 版为功能基线
复制出 public/<渠道>/<slug> 渠道目录
    ↓ 只替换渠道标识 / slug / 渠道码 / 文案
check_release.py 发布安全检查
    ↓ 杜绝真实配置、API Key、缓存文件外泄
每渠道只保留一个最新包 → 人工上传（截图逐字段核对）
    ↓
新渠道写入 skills.json 监控配置
    ↓
次日起进入每日 08:30 自动采集

两个细节值得展开。

发布安全检查是红线。 full 版目录里有真实的 config.ini 和 API Key，永远不上传。check_release.py 会扫描每个待发布包：真实配置、密钥、__pycache__、.pyc，任何一项出现就终止发布。多渠道分发最怕的不是麻烦，是一次泄漏。

一渠道一包。 “一个渠道只保留一个最新版本的包，生成新包之后旧包就删掉。“这条规则让版本管理成本从 O(历史版本数) 降到 O(1)。

数据中枢：skill-market-work-hub

体系的核心是一个我搭起来的自动化运营中枢（内部仓库 skill-market-work-hub），结构如下：

skill-market-work-hub/
├── 00-dashboard/        # README 首页看板：SVG 趋势图 + 指标表
├── 01-config/           # skills.json：所有 skill × 渠道的监控配置
├── 02-data-monitoring/  # 每日采集的 CSV 数据
├── 03-channel-management/ # 渠道状态、待上架渠道管理
├── 04-version-release/  # 版本发布记录
├── 05-ops-reports/      # 运营周报素材
└── 99-archive/          # 归档的旧数据仓库

每天早上 08:30，定时服务触发 GitHub 的 repository_dispatch，Actions 拉起采集任务：逐渠道抓取下载量、安装量、收藏等指标 → 写入 CSV → 生成 SUMMARY → 渲染 SVG 趋势曲线 → 自动提交回 README。我打开仓库首页，昨天的全渠道数据就摆在那里。

采集脚本要对付各种”不配合”的渠道：SkillHub 换了 slug 规则就 404，ModelScope 要从页面内嵌的 window.__detail_data__ 里解析数据，虾评迁了团队空间。每攻克一个渠道，就沉淀一个适配器——这是典型的苦活，但也是壁垒。

指标口径也是产品设计

跑数据的人都知道，口径不清的看板比没有看板更危险。我们踩过的坑：

  • 渠道版本切换会导致下载计数”重置”，曲线会回落——所以口径定义为”各渠道截至当日已观察到的最高下载量汇总”；
  • “增长量”和什么时候比？定义为”相对前一采集日的首次采集值”——因为偶尔手动补采，幂等的定义才不会被重复采集污染。

这两个口径都是我在看到异常数据的当下定义出来的。指标定义能力，是数据运营的基本功。

成绩单

到 8 月初，这套体系交出的数据：

  • 深知公文写作：全渠道累计下载从 7 月下旬的 5,393 增长到 8 月初的 13,000+，最好的一周七天涨了 5,700+，其中 SkillHub 单渠道单日最高贡献 +2,229；
  • 深知晓：全渠道累计 483，ModelScope 上线首日即进入监控；
  • 新增渠道：ModelScope、skills.sh、WorkBuddy（生态合作材料已备齐）；
  • 监控覆盖：12 个已启用监控点，每日自动采集失败记录为空；
  • TODO 体系：产品、运营、商务三类待办统一编号管理，累计 24 项，完成自动从看板移除。

数字不算惊人。但要知道，这背后没有一个专职运营——采集、看板、周报数据、趋势图，全部无人值守。

写在最后：一个人的产能从哪来

经常有人问我，一个人怎么同时扛产品、渠道、数据、商务四条线。

我的答案分两层。

显性的一层是工具：自动采集流水线、GitHub 看板、渠道包构建脚本、发布安全检查。这些让重复劳动归零。

隐性的一层是判断：什么口径是对的、哪个渠道值得攻坚（老板点名 WorkBuddy，但数据告诉我 SkillHub 是增长主引擎）、版本漂移什么时候必须修（主干 3.1.2 / 渠道 3.1.1 / 平台显示 3.1.0 的落差是第一优先级）。这些是产品经理不可替代的部分。

工具负责产能，判断负责方向。AI Agent 时代，一个人的上限不再是他能做多少事，而是他能设计出多大的系统，以及他对系统的每一次判断有多准。

这大概就是”一个人的发行部”真正的样子。