作为 AI 产品中心，

我们为什么要把 

AI 用法沉淀成团队 Skill？

-----------------------------

品胜 AI 产品中心，

本身就是一支高频用 AI 的团队。

市场分析、竞品分析、商品详情图、

周报、项目进度……

我们每天都让 AI 参与工作。

起初，就是打开对话窗口、

输入需求、等着出结果。

但是，“临时调用”久了，

问题也来了：

1、每次做分析都得——

重新解释背景和偏好；

2、某次效果很好，

经验却只留在那次对话里，

很难稳定复现。

于是，

我们开始做一件事——把这些高频、重复、

已经形成固定方法的工作，

封装成团队自己的 Skill。

市场分析和竞品分析，

是我们最早沉淀成 Skill 的一类工作。

多次迭代后，

它逐渐带上了明显的团队偏好：

更关注我们所在的产品方向，

优先识别长期跟踪的重点竞品，

按我们习惯的维度拆解，比如：

产品定位、人群、价格策略、

功能卖点、可借鉴点和风险点等。

结论，也更强调

“对我们当前产品有什么启发”，

而不只是信息罗列。

又比如，竞品分析文档信息：

这是竞品分析的信息来源的例子：

通用 Skill 也能出详情图，

但卖点不贴产品、层级不懂转化、

风格不稳定，大多需要人工重调。

我们把详情图封

装成团队版 Skill 并反复调试，

让它清楚：

核心卖点必须前置、关键参数先行、

场景表达放大、文案版式符合电商转化逻辑。

团队特供版 Skill，不再是“能生成一张图”，

而是

“按我们的业务标准稳定生成一套可用方案”。

AI 的价值在于，

能否稳定地用我们的方式做。

通用skill生成商品详情图效果

沉淀后团队skill生成商品详情图效果

沉淀后团队skill生成商品详情图一览

过去写周报，信息散在钉钉聊天、

文件更新和会议纪要里，

靠人回忆、汇总、确认。

我们把周报和

项目进度追踪做成了 Skill，

悟空可以从钉钉聊天、

文件更新和项目资料中

主动提取各项目进展，

自动生成结构化周报。

它呈现了：

每个项目推进到哪里、本周关键事项、

进行中任务、风险和阻塞、下一步责任人。

更重要的是，每一条信息都可追溯。

老板问：

“这个数据谁提的，依据是什么？”，

悟空能回到对应聊天或文档里找到来源。

周报，从主观汇报变成了可追溯的项目回放，

形成真正的业务闭环。

我们做了一个 Skill 数据看板，

不是简单的统计页，

而是把 Skill、文档和团队贡献串起来。

过去知识和技能分开沉淀。

现在，可以看清楚：

1、哪个 Skill 被调用了多少次？

2、生成了哪些文档？

3、这些重要文档源自哪个 Skill？

4、它的版本、评分和维护记录如何？

5、谁创建？

6、谁使用？

7、谁在持续优化？

这让：文档的结果和背后的方法连在了一起，

团队贡献也变得可见。

维护 Skill ，不再是无形的劳动，

而是一种有反馈、有激励的可持续行为——

这正是正向激励。

这些能力背后，

是一套工作流：

悟空：

是中枢 Agent，负责理解需求、调度 Skill、生成结果并回流。

钉钉知识库：

承载真实业务文档、聊天和项目资料，很多 Skill 基于这些信息加工输出。

自研 Skill Hub ：

把市场分析、详情图、周报等方法，

封装成可复用的 Skill，版本化管理，

保留 Change Log 和案例。

三者形成“业务知识在钉钉，

团队方法在 Skill Hub，

任务由悟空调度执行”的链路。

未来，

悟空企业技能中心正式上线后，

这一切会更深地嵌入钉钉生态，

让 AI 像生产力系统一样自然运转。

在我们看来，

一个 Skill 就像一个小产品。

v1.0 出来，

用几次会发现输入不清晰、输出不稳定，

遇到新场景还得补规则。

所以我们

会为每个 Skill 保留版本和 Change Log：

记下为什么改、改了什么、解决什么问题、

新版本适合什么场景、效果变化。

这样，

团队能看见 Skill 是怎么一步步变好的，

新成员能理解规则，

改坏了也能回溯。

我们不是在维护静态模板，

而是在维护持续进化的团队能力——

毕竟，持续迭代，本身就是经验再组织。