文章头图

整理自 2026 年 5 月 13 日团队 AI 例行学习会。本文只保留与学习方法、Skill、产品使用和业务场景有关的内容。

今天,我们团队例行学习 AI

今晚的学习会,我最大的感受是:大家已经不再满足于“知道一个 AI 工具”。

我们真正关心的是另一件事。

AI 到底怎么进入每天的工作?

怎么帮我们写方案、做课件、整理纪要、沉淀方法论?

怎么从一次次零散尝试,变成团队可以复用的能力?

中间我们谈到了很多产品,也谈到了很多 Skill。

但讨论到最后,我越来越确认两件事。

第一,工具只是入口,Skill 只是载体,真正的核心还是场景。

第二,团队学习 AI 的第一要务,是建立 Demo 文化。

任何方法论,都不能只停留在概念上。

它必须尽快被 AI 具像化成一个可看的交付物。

核心金句

我们先确认了一件事:Demo 文化是第一要务

这次会里,其实一直有一个隐含共识。

方法论讲得再好,如果没有 Demo,就很难形成真正的团队能力。

因为 Demo 会倒逼我们把抽象观点落到真实交付上。

一个流程方法论,不能只停留在几句话里。

它应该被做成一页诊断图、一份报告、一个案例,或者一套课件。

一个 AI 学习心得,也不能只停留在会议纪要里。

它应该被转成公众号、操作清单、网页课件,或者可复用的 Skill。

这就是 Demo 文化的价值。

它不是为了炫技。

它是为了验证:这个想法能不能被别人看懂,能不能被客户感知,能不能被团队复用。

所以我认为,接下来我们团队用 AI 的第一动作,不是继续解释方法论。

而是让 AI 帮我们把方法论做出来。

能看,能讲,能改,能交付。

我们先讨论了一个问题:AI 到底要不要先学路线图

学习会一开始,大家提出了一个很真实的困惑。

如果我们想快速提升 AI 能力,是不是应该有一张路线图?

先学提示词,再学智能体,再学 Skill,再学各种工具?

这个问题很合理。

但我们讨论下来,得到的结论不是“不要学习”。

而是不要把 AI 学成一套脱离工作的知识体系。

对我们这种咨询团队来说,更有效的路径,是先回到工作。

我每天开什么会?

我每周写什么材料?

我经常卡在哪类课件、报告、方案、案例上?

这些场景才是 AI 学习的入口。

OpenAI 的提示词指南也强调,请求 AI 时要讲清任务、上下文和目标输出。这个原则放到团队学习里,就是先给 AI 一个真实任务,而不是先背工具说明书。

然后,我们讨论了岗位智能体

第二个重要话题,是岗位智能体。

我们不是在讨论一个抽象概念。

大家真正想要的是一个“能干活的助理”。

比如开完会以后,它能整理纪要。

拿到访谈材料以后,它能提炼案例。

看到课程资料以后,它能生成课件框架。

我们把一段想法讲给它,它能先写出公众号初稿。

这类智能体的价值,不在于它像不像人。

而在于它能不能活在我们的工作环境里,理解已有材料,并把材料转成下一步交付物。

所以我们形成了一个很朴素的判断:先不要把岗位智能体想得太大。

先让它稳定完成三件事。

1整理资料:会议纪要、访谈记录、群聊讨论、课件内容。

2生成初稿:文章、方案、课件、案例、SOP。

3协同分发:把内容发给相关人,并推动后续反馈。

AI学习闭环图

图 1:我们这次讨论形成的基本闭环。

接着,我们谈到了 Skill

Skill 是今晚反复出现的词。

我们讨论 PPT Skill、报告 Skill、公众号 Skill、网页课件 Skill,也讨论怎么把一个好输出沉淀成可复用能力。

我对 Skill 的理解也更清楚了。

Skill 不是一段漂亮提示词。

它更像一份可执行的工作规程。

它要说清楚:什么场景用它,输入什么材料,按什么步骤处理,输出成什么格式,最后怎么判断好坏。

这也是为什么大家做 Skill 会卡住。

因为写一个能用的 Skill,本质上不是写一句指令。

而是在拆解一类工作。

比如“做 PPT”这件事,表面是排版问题。

其实背后还有内容结构、页面风格、案例颗粒度、讲课场景、修改便利性。

再比如“写方法论”这件事,表面是观点表达。

但如果没有交付物,它就很难被验证。

所以一个好 Skill,最好不只是帮我们总结观点。

它还要帮我们把观点变成 Demo。

所以我们的共识是:Skill 不要贪多。

先围绕一个真实场景打磨。

一类工作跑通了,再复制到下一类工作。

产品讨论很多,但我们没有把产品当答案

今晚也聊了不少产品。

有办公环境里的智能助理。

有可以处理本地文件和代码的工具。

有能生成网页课件的产品。

也有适合写公众号、做报告、做课程材料的 Skill。

但讨论到后面,我们不再纠结“哪个产品最好”。

因为不同产品解决的问题不一样。

办公助理的优势,是它离群聊、会议、文档更近。

代码型工具的优势,是它能处理更复杂的文件、页面和自动化任务。

通用对话工具的优势,是快速讨论观点、生成初稿、解释概念。

所以工具选择不能从品牌开始。

要从任务开始。

如果我要整理一场会议,我需要的是上下文和协同。

如果我要做一个网页课件,我需要的是生成和部署能力。

如果我要打磨一个方法论,我需要的是样例、标准和反复修改。

产品只是完成场景的不同路径。

产品与场景关系图

图 2:产品不是答案,场景才是选择工具的起点。

我们还形成了一个重要动作:先模仿,再改造

今晚有一个观点很实用。

不要什么都从零开始。

看到好的课件、好的报告、好的网页、好的 Skill,可以先让 AI 学习它的结构。

然后再改成自己的业务语言、自己的案例和自己的风格。

这不是简单复制。

真正要学的是结构、节奏、版式和验收标准。

比如一个网页课件为什么看起来清楚?

一个报告为什么适合客户阅读?

一篇公众号为什么不像 AI 套话?

这些都可以被拆出来,变成 Skill 的组成部分。

但这里我们也做了一个校正。

公开资料和开源项目可以参考,但要看授权。

商业内容可以学习结构,不能照搬内容。

最后沉淀下来的,必须是我们自己的方法论和交付标准。

更重要的是,要沉淀成看得见的东西。

因为团队里真正能传播的,不是“我懂了”。

而是“你看,这就是它做出来的样子”。

这次学习会最后得到的结果

这次学习会不是停留在讨论层面。

我们至少得到了几个明确结果。

第一,Demo 文化要成为我们学习 AI 的第一要务。

以后讨论任何方法论,都要问一句:它能不能马上具像化成一个交付物?

第二,团队下一阶段的 AI 学习,不再从抽象知识开始,而是从工作场景开始。

第三,每个人都要尝试建立自己的 AI 助理,并持续喂给它角色信息、工作材料和输出样例。

第四,会议纪要、访谈材料、课程资料,都不应该只被保存,而应该被转化成案例、文章、课件或报告。

第五,Skill 是团队能力沉淀的关键,但要一项一项打磨,不能指望一次做成万能工具。

第六,网页课件、公众号、报告、直播课件这些交付物,会成为我们接下来优先打磨的 Demo 场景。

第七,产品选择要服从场景,不能因为某个工具热闹,就把它当成唯一答案。

行动清单图

图 3:下一步不是继续讨论 AI,而是把它嵌进日常工作。

我真正想记住的,是这句话

AI 学习不能只靠热情。

也不能只靠工具清单。

如果我们每次学习完,只是知道了几个新产品,过几天就会忘。

但如果我们把一个具体工作交给 AI,让它整理一次、生成一次、修改一次、复盘一次,这个能力就会留下来。

对我们团队来说,真正值得投入的,不是“今天又发现了一个工具”。

而是“今天又跑通了一个场景”。

比如把会议纪要变成文章。

把访谈材料变成案例。

把课程想法变成网页课件。

把个人经验变成团队 Skill。

这些事情看起来不炫。

但它们会一点点改变我们的工作方式。

更重要的是,它们会让团队形成一种新的习惯。

不只讨论,不只总结,不只写观点。

而是把任何一个值得沉淀的方法论,迅速变成一个 Demo。

让 AI 帮我们先做出来。

做出来之后,我们再判断、修改、升级。

我也更愿意用这个标准来衡量团队的 AI 学习:不是谁知道得更多,而是谁把 AI 放进了真实工作,并且真的产出了东西。

这就是今天这场例行学习会最重要的收获。

我们讨论了很多 Skill 和产品。

但最后落下来的,还是场景。

可以单独转发的 5 句话

1Demo 文化是团队学习 AI 的第一要务。

2工具只是入口,Skill 只是载体,真正的核心还是场景。

3任何方法论,都要尽快被 AI 具像化成一个交付物。

4我们不是为了学 AI 而学 AI,而是为了改造自己的工作流。

5团队 AI 能力的沉淀,不靠口号,靠一个个跑通的真实场景。

已复制,可粘贴到公众号编辑器