大家好，我是超级峰。

前段时间我受邀参加了联想 天禧AI Skills 苍穹共创计划，并在开源中国的直播里分享了一个从我真实工作流里沉淀出来的 Skill：离职交接 Skill（offboarding-handover）。

本篇文章将介绍我近期参加 天禧AI Skills 苍穹共创计划的经历，以及提交的【离职交接 Skill】具体解决什么问题、内部框架是怎么设计的、Demo 跑出来是什么效果，以及把一个 Skill 提交到天禧AI技能广场的完整流程和这次活动的激励。如果你也想把手里的经验变成一个能上架的 Skill，这篇可以直接当操作手册用！

话不多说，正片开始。

一、我是怎么参与进苍穹共创计划的

先说说这次参与的经历。

天禧AI Skills 苍穹共创计划是联想面向开发者发起的 Skill 共创活动：大家可以把自己沉淀的 Skill 提交到联想开放平台，通过审核后上架到天禧AI技能广场，让更多 天禧AI 的用户直接调用。

我平时的工作离不开 AI 编程和 Agent 工作流，手里也攒了不少自己写的 Skill。收到共创计划的邀请后，我挑一个最真实的遇到的场景，并且最好是那种每个职场人都躲不开、但每次做起来都很痛苦的场景。

想来想去，我选了——离职交接。

这个场景几乎人人都经历过：要么你交接给别人，要么别人交接给你。而且它有一个非常典型的特征——交接资料极度混乱，但交付要求极度清晰。面对这种「输入混乱、输出规范」的场景，恰恰是 Skill 最能发挥价值的地方。

于是就有了这次直播分享的主角：offboarding-handover，一个把零散工作资料整理成可交付交接包的 Skill 。从打磨 Skill、上传到联想开放平台、通过审核，到最后在开源中国的直播里做完整分享，整个流程走下来，我对「个人 Skills 如何商业变现」这件事有了更具象的体感。下面挨个展开。

二、offboarding-handover 解决什么问题

适用场景

想象一个很常见的画面：一位产品经理要离职了，他的工作文件夹里躺着 270 个文件、23 个顶层目录。里面有「临时_移动端APP_需求梳理_84.md」这种随手笔记，有 PRD 从 v1.0 到 v3.9 十几个版本并存，有四个空的「产品线」目录和四个重名的「XX产品线」目录混在一起，还有一个躺了 27 个文件的「归档」黑洞。

交接方觉得「我都给你了」，接手人打开文件夹一脸茫然：从哪看起？哪个是最新版？哪些事还没做完？哪些账号下周就要到期？

传统做法是交接人花一两天手动整理，再拉着接手人开几轮会。而这个 Skill 的目标是：执行一次，直接生成一份接手人能看懂、HR 能签字的交接包。

它不只适用于离职交接。岗位调动、项目移交、长假前的工作备份、甚至外包项目的资料交付，本质都是同一类问题：把混乱的资料变成有结构的交付物。

核心功能

offboarding-handover 做四件事：

1. 全量清点与智能分类：先扫描整个文件夹建立清单基线（多少文件、多少目录、每个分支多少内容），再按预设的岗位模板分类归档。产品经理有产品经理的交接结构，运营有运营的，不用每次重新解释「这些资料该怎么归类」。

2. 规范命名与版本收敛：把「最终版」「新最终版」这类文件名统一成「序号-项目-主题-材料类型-状态-版本」的规范格式；十几个版本的 PRD 只保留定稿和最新草稿，其余旧版本收敛掉，但每一个被收敛的版本都记录在案，可追溯。

3. 生成离线 HTML 交接门户：交接包里自带一个网页入口，接手人打开就能看到交接速览、马上要接的事、风险与待确认项、可打印的交接确认单，以及全部文件的索引。

4. 保护原始文件：整理过程全部基于复制，原始资料一个字节都不动。就算整理结果不满意，推倒重来也没有任何损失。

内部框架：一个可控的流程

很多人以为 Skill 就是一段写得比较好的 prompt，其实差别很大。这个 Skill 内部是一个可控流程，Agent 必须按阶段推进，每个阶段有明确的准入和退出条件，不允许跳步：

1. 清单基线先行：先全量扫描，拿到总文件数、目录数、顶层分支分布、扩展名分布，没有完整基线之前禁止深度分类，也禁止向用户提问。

2. 触发检查：如果命中硬触发条件——文件数超过 3000、有意义的顶层分支超过 8 个、或者角色置信度不高——强制进入并行子代理模式。

3. 并行子代理扫描：角色探测、项目映射、风险检查、缺失事实探测四个专职子代理并行开工，各管一摊互不重叠，最后统一汇总并做覆盖率校验。

4. 角色确认门：向用户确认交接人、接手人、最后工作日、职责边界。这些关键事实没确认之前，输出只能是草稿，不允许生成「看起来很完整」的正式交接包。

5. 相关性过滤与版本收敛：每个文件先做 include / review / exclude 三态判定，别人的资料、公共模板、过期版本被排除或送入待复核区；同一文档的多个版本收敛成最终代表版。

6. 文件名规范化：入包文件统一改名为「序号-项目-主题-材料类型-状态-版本」，原始名称和路径全部记录在映射表里，可追溯。

7. 渲染输出：生成规范目录、Markdown 说明文档、离线 HTML 门户，最后按需导出 ZIP。

 

几个设计点值得展开说：

• 先盘点，后动手：避免 Agent「看了几个文件就自信开工」的通病。

• 大文件夹自动升级为多 Agent 并行：单线程「一个人慢慢看」在几百上千个文件的规模下既慢又容易漏，并行子代理各管一摊再汇总，速度和覆盖率同时有保障。

• 关键事实是硬门禁：宁可交付慢一点，不能交付错的。

• 每个决策可追溯：哪些文件被纳入、哪些被排除、哪些旧版本被收敛、每个文件改名前后的映射，全部写进清单报告。接手人对任何一个文件有疑问，都能查到来龙去脉。

这套结构写在 SKILL.md 和一组参考文档里，Agent 按需加载。这也是我理解的 Skill 和 prompt 的本质区别：prompt 是一次性的指令，Skill 是把判断标准、执行顺序、风险边界固化下来的可复用流程。

三、Demo 效果：270 个乱文件变成一份能签字的交接包

直播里我用一份模拟的产品经理工作文件夹做了完整演示。这个文件夹还原了真实工作场景的混乱程度：270 个文件、23 个顶层目录，临时笔记散落在根目录，PRD 十几个版本并存，还有空目录和重名目录互相打架。

在 Agent 对话框里引用这个 Skill 后，它先扫描建立清单，然后向我确认了交接人、接手人和最后工作日，接着就开始并行分析、过滤、改名、归档。跑完之后，原文件夹旁边多了一个「离职交接包」目录，整理前后的结构对比是这样的：

整理前的原始文件夹 vs Skill 生成的交接包结构

变化很直观：

• 23 个混乱的顶层目录收敛成 5 大模块：说明与导航、交接信息、交接总览、专项交接、未完事项与状态，外加一个网页门户。

• 270 个原始文件经过相关性过滤后，151 个纳入正式交接，30 个旧版本被收敛并记录在案，86 个模糊材料单独列入待复核清单——不是简单地「全部拷一遍」，是每个文件都有明确的去留理由。

• 所有入包文件统一改名，比如「电商管理系统 PRD 最终版.docx」变成「001-电商管理系统-PRD-需求文档-定稿-v2.2.docx」，排序即阅读顺序。

最能打动接手人的是那个离线 HTML 交接门户。双击打开 site/index.html，看到的是这样一个页面：

交接门户首屏：交接速览、紧急事项、风险提示一目了然

注意看首屏的信息密度：151 个纳入文件、5 项紧急事项、8 项高风险项、86 项待复核、18 项遗漏待确认，全部量化。「接手前必读」直接告诉接手人：有两个账号 12 天后到期需要立即转移、12 份客户合同涉及 3 个不同乙方主体需要法务确认、4 条产品线的路线图已经过期。这些信息以前要靠接手人自己踩坑才能发现，现在开箱即见。

 

往下滚动是「马上要接的事」，按 P0/P1 优先级排列，每一项都标注了当前状态、下一步动作，还能一键定位到对应文件。再往下是可打印的交接确认单，交接双方逐项确认后签字，HR 直接拿去归档。

 

文件列表也不是干巴巴的清单——每个文件都保留了「原始文件名 → 规范文件名」的映射，按产品线筛选，点击直接打开原文件：

交接材料列表：规范命名 + 原始文件名映射 + 状态标注

整个过程中我只回答了几个问题（交接人是谁、接手人是谁、最后工作日是哪天），剩下的分类、过滤、改名、渲染全部自动完成。最后把整个交接包压缩成 ZIP 发给接手人或 HR，对方拿到的就是一份不需要任何解释就能看懂的交接材料。

四、将 Skill 提交至天禧AI技能广场

Skill 做好了，怎么让更多人用上？这就是苍穹共创计划要解决的事。我把这次上传的完整流程记录下来，照着做基本不会卡壳。

第一步：完成开发者认证

入口在联想开放平台。如果你是个人开发者，认证时选择「个人开发者」类型即可，不需要公司资质。认证通过后进入管理中心。

第二步：创建应用，类型选 Skill

在「创建应用」页面有两个关键选项：创建类型选择智能体（平台推荐的新一代应用形式），应用类型选择Skill，然后点下一步：

创建类型选智能体，应用类型选 Skill

第三步：打包上传 ZIP

上传方式我选的是默认的对话式上传。把 Skill 打包成一个 ZIP 压缩包上传即可，有两个细节要注意：

• ZIP 包的根层必须直接是 SKILL.md 文件。Mac 用户注意：要打包 skill 文件夹里的内容，不能直接把文件夹整个压缩，否则会多出一层目录导致识别失败。

• 包体不要超过 10MB。

上传之后平台会自动从 Skill 内容里识别 Slug、名称和描述——这也是我反复强调 SKILL.md 要写清楚的原因：它不仅是给 Agent 看的执行手册，也是平台自动识别和用户理解的第一入口。之后再填几个使用示例（比如「帮我把这个文件夹整理成离职交接包」），版本号第一版直接写 1.0.0，确认无误后提交：

上传 ZIP 后平台自动识别 Slug、名称、描述，填写示例和版本号后提交

第四步：等待审核

提交后进入人工审核。官方公开信息里说审核周期大约 5 个工作日，我这次的实际体验快得多——几个小时就有结果了。审核通过后，Skill 就进入天禧AI技能广场，天禧AI的用户可以直接调用。

整个流程走下来，真正花时间的不是平台操作，而是把 SKILL.md 写清楚：它解决什么问题、适合什么场景、输入什么材料、输出什么结果、哪些环节需要用户确认、风险边界在哪。这些写得越清楚，平台识别越准，用户上手越快，审核也越顺。

五、活动激励：上架不是终点，而是起点

再说说这次活动的激励，我从开发者视角讲讲实际感受。

能量值支持。Skill 成功上架后，平台会给开发者能量值。能量值可以理解为在天禧AI平台内继续使用、测试和体验相关能力的资源。对开发者来说这很实际：Skill 上架不是一锤子买卖，后续的迭代、测试、体验优化都需要消耗资源，能量值正好覆盖了这部分成本（具体消耗和使用规则以平台页面为准）。

瓜分千万现金大奖。活动结束之后，官方还会根据大家提交的 Skills 做一个评选，评为优质 Skill 就可以参与瓜分千万现金奖池。小 Tips ：每一个认证开发者可以提交不止一个 Skill，Skills 提交得越多，最终获奖的机会越大！

曝光与推广资源。优质 Skill 会获得技能广场的流量推荐、活动曝光和联合推广的机会——个人开发者靠自己很难触达这么大的圈子。

商业化收入通道。这是我觉得最值得关注的一点：优质 Skill 后续会有商业化收入的机会。也就是说，你沉淀的工作流经验不只是「被更多人用到」，还有机会持续产生收益。具体的奖金、能量值数量和收益规则，以官方发布为准。

把这些激励串起来看，逻辑是完整的：能量值解决「持续迭代的成本」，推广资源解决「被看见的机会」，商业化通道解决「长期投入的动力」，丰厚的现金激励「瓜分千万现金」。对手里有真实工作流经验的开发者来说，这是一条把个人经验产品化的完整路径。

六、写在最后

参加这次苍穹共创计划，我最大的感受是：很多开发者手里其实都攒着值钱的东西，只是它们以 prompt、脚本或者个人习惯的形式散落在各处，用一次丢一次。

但 Skill 这个形态的价值，反而可以把这些一次性的经验变成标准化、可复用、可分发的能力。这次我做的是离职交接，但同样的思路完全可以套到周报整理、会议纪要、资料归档、简历优化、客服知识库、研发排障上——只要一个流程重复出现，并且有相对稳定的步骤，它就值得沉淀成一个 Skill。

如果大家也想参与天禧AI Skills 苍穹共创计划，我的建议是：不用一上来就憋大招，从自己真实遇到的、越具体越高频的问题开始。越真实的场景，越容易做出有价值的 Skill。

活动参与入口：https://open.lenovomm.com/developer/mgmt/appcreate?type=4

我是超级峰，我们下次再见。