从找场景到做 Skill:AI 赋能落地的一套拆解方法

0 评论 813 浏览 1 收藏 18 分钟

直播里被问最多的两个问题:找不到能上 AI 的场景,场景塞过来又不知道怎么拆。这篇把方法捋成文字版,先判断环节适不适合 AI,再拆成 IPO 原子化节点,最后决定哪些做成 Skill。

昨晚直播讲了两个多小时 AI 赋能怎么落地,这篇是整理后的文字版。

全文由 MiMo 基于录音妙记撰写整理,可能有未修正的转录错别字,我通读了一遍问题不大。

直播里被问得最多的就两个问题:找不到可以引入 AI 的场景;场景被塞过来,不知道怎么拆。

下面按直播的顺序把方法捋成文字。

给业务加 AI,不用先做一个 AI 产品

2025 年还常见的做法,是拿一个场景做成应用:搭个 Dify 工作流,包一层界面,交给业务用。今天没必要这么做了。

更好的策略是给员工配通用 Agent,产品经理去做 Skill 和插件。发票审核、行政流程、运营杂活,都吃这一套。

有个例外。公司想集中管理 AI 的使用,或者不想让内部资料流到外部产品的 API 里,可以用 Dify 的 Agents 功能搭内部 Agent,链接发给员工就能用。

卖 SaaS 的公司分两种看。产品高频使用、带看板或操作交互的,在原有产品里叠加 AI 功能是成立的。工具属性的 SaaS 走这条路会很难受:用户进来就是单点解决一个问题。工具型 SaaS 更可靠的做法是把能力 API 化,封装成 MCP 或 CLI 交给 Agent 调用。

工具一多就得配套 Skill。一个 SaaS 随便几十个功能点,MCP 的 description 里塞不下用法组合,得靠 Skill 告诉 Agent 什么任务调什么接口。WorkBuddy 的连接器就是这两种形态:飞书走 CLI,腾讯文档走 MCP 加一套官方 Skill。MCP 会常驻 Agent 上下文,工具多了还要靠连接器开关和 router 管理。WorkBuddy 的 router 只给 Agent 写工具名和描述,需要细节时再按需拉取 schema。

找场景:卡住大家的三个点

第一类,不知道这个环节能被 AI 干,找不到切入点。注意别硬造场景。帮行政写通知、做贺卡,人家自己两句话就搞定,轮不到你赋能。要找的是想干干不成的:不知道能干的,能力不足干不了的,试过一次没干好就说 AI 不行的。

第二类,知道能干,不知道 AI 该在哪个环节介入、介入多深。最常见的失败是整段活一股脑丢给 AI。让 AI 写调研报告,不给方向不给需求,AI 自己扩写搜索整理,交上来方向不对;加需求再改,改完又把前面改坏了。

这类活通常有三段,第一段本来就该人干:理思路、定方向、给大纲、给会议纪要。AI 不知道你开过这个会。产品经理要做的是把分工写进产品:哪些信息必须人给,没给够就让 AI 反过来问用户,问不到就明确说干不了。也可以在入口上要求填完必填项才允许提交,体验硬一些,但比跑偏强。

第三类,知道该在哪个环节用,不知道上下文要给到什么程度。这分两块。

一块是必备输入。炒菜的例子最直观:人找不着酱油,会关小火先去找;AI 找不着酱油,会拿生抽或者醋糊弄过去。必备的材料不给全,活一定干不好。

另一块是规则规范和判断条件。什么叫断生,少许是多少,怎么算合格。不给,AI 就按它认为最好的规则干。这些属于行业基本认知,也正是赋能要补的东西。

用不好 AI 的人,多数是本身不会干这个活。人教不明白,可以教明白 AI。把那部分认知交给 AI,让这个人只干最基础的操作。

四个维度,判断一个环节适不适合 AI

维度 适合引入 AI 不适合
输入弹性 大段文本、非结构化、边界模糊 输入规范、字段固定、可遍历
规则属性 说得清楚,但没法计算 能写成是非判断,程序可算
是否重复 反复出现的同类型任务 一次性任务,不值得产品化
容错空间 输出有弹性,最后有人兜底审阅 零容错,比如财务计算

规则那条展开说。判断一条评论是不是负面情绪,给三五条样例就能说明白,但情绪没法用程序算出来,以前的 NLP 只能抽关键词。说得清、算不了,交给 AI 合适。能写成计算规则的,给程序。

容错那条同理。必须可丁可卯输出具体金额的场景给不了 AI;四五个字的弹性、错了有人审的场景可以。一次性任务没必要做成产品,用户直接用通用 Agent 就行。

想批量找场景,把公司里的日历、日报周报、各部门周例会纪要丢给 AI,让它按这几个维度筛一遍,看哪些环节值得引入 AI。

IPO 原子化拆解

场景确认能做之后就该拆了。我一直讲的 IPO,是 Input、Process、Output 的缩写。

整个流程是一个 IPO,先套上面的维度判断一遍,然后每个 P 再拆成 IPO,I 接着上一步的 O,一层层往下拆,拆到不能再拆为止。

IPO 原子化拆解:每个原子节点单独判断执行者

拆完逐个节点判断执行者:程序、AI,还是人。

能用程序干的,尽量别用 AI。我分享过的写 PRD、画原型那几个 Skill,里面都有一步是运行脚本生成模板。模板内容固定,写进 Python 脚本里,Agent 一运行就生成,每次一模一样零错误。让 AI 现场生成五份几百字的模板,没个二三十秒写不完,誊抄的过程中还特别容易抄错。

还有一种分工是 AI 先生成程序,再由程序算出结果。上游输出不稳定、不规范的时候,AI 当中间的解析缓冲。这其实是两个节点:AI 节点接程序节点。

拆完的结构本身就是工作流或者 Skill。直播里我拿销售线索分层演示了一遍,AI 两分钟拆出 12 个节点:读 Excel、字段校验、缺失字段丢给人补全、抽取线索信息、权重打分、SLA 分级、映射到销售、输出跟进建议、组装回写 CRM、人工兜底。每个节点对应产品里的一个功能,也对应工作流里的一个节点。

这套拆解是产品经理的基本功。点一个交互,能反推背后每一步怎么实现的,算过了合格线;能拆到原子节点,就有机会复现别人的产品;能看出哪一步做得烂、提示词里大概写了什么、该怎么约束它,才算能做优化。

举个例子。我让 WorkBuddy 写一个调用真实大模型 API 的 ChatBI,它为了调试,直接去读了我存 API 密钥的 models.json。DeepSeek Harness、Codex 这些工具遇到密钥会提醒你删掉、记得重置,提交代码时还会把密钥段加进 .gitignore。WorkBuddy 这个行为背后必然有一段提示词在驱动。遇到这种设计,要能反推出它写了什么,以及怎么反制。

认知劳动产品化:什么该做成 Skill

有清晰方法论的内容,都可以做成 Skill。我把这叫认知劳动产品化:脑子里的经验复刻成产品,直接垫给用的人。

要赋能的对象,是短期教不会、也不愿意学的那批员工。一教就会的人不用赋能,他自己会去找工具。教不会的那些,过去得靠三年五个项目练出来的东西,现在把方法论固化成 Skill,让他照着干。

AI 会做 PPT,但默认不会按你的偏好做。你喜欢三栏布局,有自己习惯的配色和版式,这些才是 Skill 要固化的东西:你的流程、你的规则、你的审美。

通用的做法会被模型内化。GitHub 上一万 star 以上的 AI 做 PPT 项目,火过一个版本,这套审美就被训进模型了。现在通用模型做 HTML PPT 默认就是那种文字压英文的排版,看多了觉得廉价,这种默认视觉现在叫 AI Slop。个性化的偏好难被复刻,垂直流程里的玩法也一样。

Skill 本质上是提示词加脚本加工具。工具一般外挂在 MCP 或者 CLI 上,全塞进 Skill 会臃肿,开发维护成本都高。

Skill 装进通用 Agent:通用 Agent 加一套 Skill 就是垂直 Agent

好多公司纠结要不要开发垂直场景的 Agent,我觉得大部分没必要。通用 Agent 加一套 Skill 就是垂直 Agent,真正需要单独做一个 Agent 的理由,剩下权限、规范、边界这几类。

用户 90% 的活都在通用 Agent 里干完,单独一个垂直 Agent 会很难受。你懂的场景不只有你懂,竞对做出 Skill 的那天,用户立刻就迁过去。吃一年半年的信息差可以,长期还是 Agent 加 Skill。

写好 Skill 要懂 Agent 和模型的底层原理。不懂的人写出来的 Skill,干一个轻松活要二三十分钟,各种规则反复读,时灵时不灵。

两个可以上手试的东西

Dify 1.17.1 之后的 Agents 功能值得玩一玩。可以选模型、预设提示词、装 Skill、传文件、配工具,工具既可以是连接器,也可以把工作流封装进来。它的 Skill 市场做集中管理,市场里更新版本,所有 Agent 实时同步,省掉了员工本地改乱版本的问题。知识库也能接进来。

它是沙箱机制。每个 Agent 一套 Docker 沙箱和独立 workspace,会话之间互相隔离,员工改不坏预设配置。代价是产出的文档跨会话不保留,运维成本高一些。适合流程管控类的 Skill,写 PRD 这类完全没问题;依赖后端服务、要拉起页面、环境依赖重的 Skill 会费劲。

另一个是开源项目 Pi。它新上的 Pi Durable 支持长时间运行,状态管理做得好,崩了数据能找回,适合部署在云端跑长周期任务。它有本地和云端两套 Agent,云端那套两核两 G 的服务器就够,手机上用快捷指令唤起,读剪贴板、读选中文件、语音输入都行。既能做中英互译这种单次请求,也能配 Skill 跑长程任务。

找工作,看三类公司

业务本位的公司,卖的是实体、咨询、代运营这类和趋势无关的东西。AI 加进来是给业务环节提效:内部协作、营销获客、数据分析、生产流程。卖的东西不因 AI 变。这类岗位最看重的就是 AI 赋能的能力。

行业门槛没有想象的高。金融、医疗这类要专业积累,通用业务大多能快速补上。广告投放看着专业,拆开就是素材、竞价、盯盘、出价优化,把巨量引擎的优化师手册看一遍,一天能入门。面试前还可以照着做个小 demo。

趋势本位的公司,是原来卖效率工具的 SaaS 和互联网产品。AI 本身成了效率来源,它们必须把自己 AI 化,不转就掉队。现在两条路都在试:把自身能力抽象成工具给 Agent 调用;在原有产品里改交互、叠 AI 功能。没有成熟的普适方案,还有一层风险是被模型和 Agent 的进展直接推平。

第三类是做 Agent 和大模型的公司。门槛高,对 harness、模型原理的要求高,薪资也高。这类团队的增长机会来自模型能力的突破:模型足够强,就能带着自己的入口涨用户。第三方小团队做的 Agent 产品,很难再出现爆发式增长。

前两类公司现在都在招 FDE 类岗位,考的核心能力就是分析场景和拆解场景。大部分通用行业的知识,AI 都能帮你快速消解,只要你问得出问题。

学习设计可控可用的 skill

我在《AI 产品经理转型实战营》线下课程中,有从 LLM 底层特性到 AI 赋能场景验证、落地实施方案、Agent 原理和 Agent Skill 开发的全流程内容。

课程授课时长共两天。不是单独教大家“写一个 Skill”,而是沿着一条完整的产品能力链往下走。

第一天先从产品经理最常见的工作开始,从实践中掌握 LLM 的底层特性。

我会带大家用 AI 做市场调研、写 PRD、画高保真原型几个产品经理最高频的工作,在实操中理解 LLM 的知识为什么不可靠、生成为什么不可靠,以及为什么产品经理必须学会质疑、约束和监控 AI。

下午会进入真实业务场景,用 IPO 模型把业务场景拆成 Input、Process、Output,再从规则结构化程度、信息充分度、数据量、容错率、人类决策和创造性等维度,判断一个环节究竟应该交给 AI、程序还是人。

然后把合适的流程做成 Workflow,并通过 RAG 给模型构建更可靠的上下文、构建一个基于内部知识的客服系统、AI 知识库。

第二天是 AI-Native 产品,会带你亲手开发一个 Agent,理解它“模型推理—工具调用—消息拼接—循环”的底层逻辑。

完成了以上内容学习,开发设计高质量、稳定的 skill 就如探囊取物了。

课程不是从“提示词技巧”开始,而是从 LLM 这个新用户的底层特性开始,一路走到场景拆解、上下文工程、Workflow、RAG、Agent、Skill 和最终交付。

如果你此刻正想从传统产品经理转向 AI 产品经理,或者想抓住 Work Agent 用户快速增长带来的这波机会,强烈推荐你来线下完整学一遍。

课程仍然在进行,接下来的安排如下:

城市 时间 状态
上海-9期 10月24日-25日 🟢 招募中(今年最后一场)

课程原价 3999 元,限时早鸟价 2999 元将在二期开营前结束。

本文由人人都是产品经理作者【张佳的AI实战笔记】,微信公众号:【喜新】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!