万字精讲Skill设计：把认知产品化是AI时代产品经理的基本功

本来想简单写写，一不小心写了 1.2 万字。既是 skill 设计开发的教程，更是对“认知产品化”这个 AI 时代的核心命题的展开论述。

推荐产品经理阅读，如果你只想学习如何使用 skill，可以退出了。

TL;DR：

1. 1. AI 技术给产品设计带来的革命性改变到底是什么？

2. 2. Skill 的概念定义，看完能上手设计那种

3. 3. Skill 的类型，如何封装认知？

4. 4. 使用 IPO 思维拆解和设计 skill

5. 5. 极简的 skill 设计流程：8 步

当我们聊“产品sense”时，具体在聊什么？

同样一份需求，落到不同产品经理手里，最后很可能长成两个东西。

新人读完需求，开始画流程。

资深产品经理会多停一会儿：用户为什么要做这件事？现有方案卡在哪里？成功口径是谁定的？数据从哪里来？出了问题谁兜底？

老板/用户只说了一句话，他脑子里已经拉出一串待确认的问题。

这串问题很少完整地写在岗位说明里。

它来自跑过的项目，是在一次次评审被追问之后慢慢积累起来的，我们管它叫“产品 sense”。

过去，我们转移这类经验的手段很有限。

你可以写文档“教学”，但读者看懂以后，还得自己判断何时使用。

你可以做培训“分享”，课上听得明白，换个项目又要重新消化。

核心是，如果学习的那个人没有足够的积累，摘到果子也没法消化。

于是，认知长期依附在人身上。一个人带着它开会、做判断、改方案；这个人换岗，能力也跟着离开。公司留下几十页复盘，下一拨人继续踩相似的坑。

AI 改变了这件事。

我们开始有机会把一套判断方式交给机器：收到任务先收集哪些信息，遇到冲突按什么原则取舍，走到哪一步该找人确认，交付前用什么标准检查。

Agent 可以读取这些“判断方式”，调用工具，操作文件，在过程中继续向用户提问。

它承接的已经不只是一条命令，还包括一个人完成任务时用到的经验、流程与边界。

简单来说，认知和经验可以被产品化了。

此刻，一套认知可以有清楚的适用场景，可以被安装、调用和更新；能接受输入，完成处理，产出结果；过去躺在某个人脑子里的方法，现在可以成为一份能运行的能力。

这是今天产品经理最应该关注的事情。

过去我们靠规则和流程把最佳实践标准化成产品，但必须是可遍历、有边界、可以最终转化成是否判断的规则，因为程序直接收结构化的输入。

今天，我们可以让 AI 写“鲁迅风格”的文章、可以让 Agent“看看还缺少哪些信息跟用户澄清”、可以指定一个“爆款方法论”让 AI 无限连复制流量、可以把专家对边界的判断写成SKILL.md让 Agent 一步一步验证。

某Agent里内置的专家团 把方法论一点点搬进 AI

从大模型出现以来我们其实一直把“认知”塞给 AI，从提示词到 Workflow 到 skills。

1. Prompt：先搬过去一段方法

最早大家到处收集的提示词，最常见是带有创作者思考框架的那种：

“你是一名资深产品经理。请从用户价值、商业价值、实现成本、数据指标几个维度分析以下需求……”

它轻、快、便宜，复制到对话框就能用。一个写得好的 Prompt，确实能把方法论迁移一部分。

麻烦也很快出现。提示词散落在聊天记录、收藏夹和团队文档里；同事拿到后会删几句、添几句，版本渐渐分叉；用户还得知道什么时候贴哪一段，以及要补充哪些背景。

任务一长，模型会漏掉前面的要求。换个场景，原来的提示词还得手工改。

某提示词社区

Prompt 像一张写给 AI 的操作便签。它适合单次、边界清晰的任务，却很难独自承载一套持续维护的能力。

确切讲，它没法被产品化。

2. Workflow：塞一条流程给 AI

后来，大家把模型接进工作流：第一步分类，第二步检索资料，第三步生成内容，第四步写入系统。

节点、条件和数据流都画在画布上，模型在指定位置完成指定动作。

Dify工作流

Workflow 解决了不少稳定性问题。业务人员不用反复复制提示词，团队也能看见任务走到了哪里。报表生成、客服分流、内容审核这类步骤清楚的任务，很适合用它。

但是，真实工作经常临时拐弯：资料缺失时要先找人，发现数据口径冲突时要回到上一步，用户改了目标后还要重新规划。

为了覆盖这些变化，流程图会不断长出分支。

搭建者得提前想到许多情况，还要维护节点之间的数据格式。

在 Workflow 里，被产品化的“认知”是由“流程编排”和“LLM节点提示词”组成的，需要调来调去的“编排”那部分，明明也可以让 LLM 来决策。

3. Skill：把一整套认知交给 Agent

Agent 出现后，模型可以在一个循环里观察环境、制定下一步、调用工具，再根据结果继续行动。我们也有了新的封装方式：

• • 把专家经验写成参考资料；

• • 把可靠步骤写成执行指引；

• • 把必须稳定的操作固化成脚本；

• • 把交付格式做成模板；

• • 把质量要求做成检查清单；

• • 再告诉 Agent，什么场景该启用这套能力。

这组文件就是 Skill。

Agent 保留了处理开放问题的空间，Skill 为它提供任务所需的专业知识和行动边界。

流程清楚的部分可以继续使用 Workflow 或脚本，临场判断交给模型，需要拍板的地方留给人。

Prompt 和 Workflow 会继续留在 Skill 里。Prompt 成为指令的一部分，Workflow 成为标准流程或脚本；Skill 把它们连同资料、模板、工具和验收标准一起收拢，变成一套可发现、可复用、可迭代的能力。

自此，一套认知可以完整复制给 AI，实现真正意义上的产品化了。

从 Prompt、Workflow 到 Skill 的能力封装演进 有效定义 skill

很多介绍会把 Skill 说成“标准化封装的能力”。

这种概念没啥用处，听完只知道是个啥，但很难动手做一个出来。

进到 Agent 的运行过程里看 Skill，会清晰很多。

它从一个文件夹开始。

以 Codex、Claude Code、WorkBuddy 这类 Agent 产品为例，应用会约定一个存放 Skill 的位置。

你把文件夹复制进去，安装就完成了。

放在电脑根目录里，多个项目都能发现它；放在某个项目的目录里，它只服务这个项目。

一个最小 Skill，甚至可以只有一份SKILL.md：

my-skill/
└── SKILL.md

复杂一点的 Skill 会多出几类材料：

my-skill/
├── SKILL.md          # 入口：何时使用、怎样执行
├── references/       # 领域知识、规则、案例
├── templates/        # 交付模板、示例结构
├── scripts/          # 需要稳定执行的程序
└── assets/           # 图片、字体等素材

文件放进去之后，Agent 怎样知道它存在？

SKILL.md开头通常有一小段元数据，其中最关键的是name和description。Agent 启动会话时，会扫描安装 Skill 的那个skills文件夹，把里面所有文件夹里的SKILL.md的名称和描述提取出来，加上这个文档所在的路径放进上下文。

模型先看到一张“能力目录”，知道每个 Skill 大概负责什么。

用户发来任务后，模型根据描述判断是否需要某个 Skill。需要时，它会去指定路径读取对应的SKILL.md，获得完整指引。

执行到具体步骤，它再去读某份参考资料、套用模板，或运行脚本。

Agent 发现并调用 Skill 的运行过程

这套机制常被称为渐进式披露。

你去一家大图书馆，不会进门就把所有书摊开。目录先告诉你有哪些书，选中一本再看章节，需要证据时继续翻参考资料。

Skill 用相似的方式管理上下文：先给模型少量索引，任务命中后再加载细节。

它解决了一个很现实的问题。系统提示词的空间和模型的注意力都有限。把公司全部制度、几十套模板、所有操作步骤一次塞进去，费用会上升，干扰也会变多。Agent 还可能在错误场景调用一段正确规则。

渐进式披露让信息在需要时出现，也让每份资料的用途更清楚。

这里有一个容易被忽略的前提：Agent 得拥有文件系统或类似的沙盒环境，也得能读取文件、执行脚本。一个只支持对话、无法访问任何工作空间的 Chatbot，即使收到一份SKILL.md，也很难跑出完整的 Skill 机制。

理解这一点，你就能分辨市面上的很多“Skill”。有些只是把 Prompt 换了个名字；有些已经具备文件、工具与按需读取能力；还有些做成了平台自己的插件系统。

名称可以相同，运行基础差别很大。

产品经理做方案时，要先问清 Agent 能访问什么、能执行什么、怎样发现能力。

Skill 的类型

文件夹只是外壳，里面的内容决定 Agent 会获得什么能力。

从产品设计的角度看，常见 Skill 可以沿着三个方向来做。这三个方向会互相组合，很少泾渭分明。

1. 复制经验，让 Agent 更懂行

大模型学过许多知识，调用哪一套知识却带着概率。

它可能知道需求评审，也可能给你一份放在哪个项目都成立的通用建议。公司内部的术语、业务规则、历史决策，它更无从得知。

经验复制类 Skill 会把可靠材料放到模型手边。例如：

• • 一位增长产品经理总结的实验设计方法；

• • 一套小红书选题与文案经验；

• • 一家公司对活跃、留存、转化的指标口径；

• • 某个行业的合规检查规则。

这些内容帮助 Agent 在任务中调用指定认知，也方便团队更新。业务口径调整后，你改参考资料、重新测试，下一次执行就能使用新版本。无需等待模型厂商重新训练。

2. 封装流程，让 Agent 做得稳

Agent 可以自己规划步骤，这给了它处理开放任务的能力，也带来顺序漂移、漏步骤和工具误用。

流程封装类 Skill 会明确任务怎样推进：

1. 1. 先查哪些材料，再做哪项分析；

2. 2. 哪些工具有前置条件；

3. 3. 缺信息时向用户问什么；

4. 4. 哪一步完成后必须保存中间结果；

5. 5. ……

模型能判断的部分，可以用文字指引。

格式严格、计算明确、批量重复的部分，更适合写进脚本。

脚本执行同一份代码会得到可预期的过程，模型负责准备输入、调用程序和解释结果。

人机协作节点很考验产品设计。

有些 Skill 可以一路跑完，比如把一批图片统一改名。有些任务需要 Agent 干一段就停下来：

• • 需求边界尚未确认，用户得做选择；

• • 生产环境即将发生变更，负责人得批准；

• • 文章提纲已经形成，作者想先调整方向。

• • ……

Skill 可以把这些暂停点写进流程，让 Agent 学会在合适的时候找人。

3. 场景定制化，让 Agent 进入具体业务

公司数据库的表结构、内部系统的接口、部门审批规则、固定报告格式，通常同时包含专有知识和固定流程。

例如，一个经营分析 Skill 可能要求 Agent：

1. 1. 只使用经过批准的数据表和字段；

2. 2. 按公司口径计算收入与留存；

3. 3. 遇到缺失数据时标记问题，禁止补造数字；

4. 4. 把结果填入管理层一直使用的 Excel 模板；

5. 5. 输出前运行检查脚本，核对公式与汇总值。

知识、流程、环境和交付格式在这里合成了一套专属能力。通用 Agent 借助它，才能在某家公司的具体场景里可靠工作。

总结下来，我们得到了一个本该放在上一版块的 Skill 的定义：

Skill 是把 Agent 在一个场景中需要的知识经验、执行流程、环境约束和验收标准，封装成可复用的文件化能力单元。

使用 IPO 设计 Skill

看懂文件结构以后，具体设计就很简单了。

翻来覆去说过几百遍的 IPO —— 输入、处理、输出 —— 仍然是一把好用的拆解刀。

Input：先让任务有一个靠谱的起点

许多 Agent 任务失败，在第一步就埋下了种子。

用户说“帮我分析一下这个需求”，没给业务目标、用户反馈和数据口径，Agent 只好从常识出发。后面写得越多，离真实项目可能越远。

设计 skill 时，除了场景认知的产品化，其实还包含了使用 LLM 的常识。

是的，这些常识，99%的普通用户不知道。

在为 skill 设计输入时，可以分三层问：

• •用户必须提供什么？比如目标、原始材料、交付时间、使用对象。缺少这些信息，任务无法开始。

• •Agent 可以自己获得什么？比如读取当前项目的 PRD、查询数据库结构、搜索指定资料库。用户不用重复搬运 Agent 已经能访问的信息。

• •产品经理要替用户补什么？用户未必知道该提供竞品范围、历史决策或审批人。Skill 可以通过一组问题引导他，也可以在工作空间里主动查找。

输入设计的成果，未必是一张长表单。它也可以是一段渐进对话：先确认目标，再根据答案追问；信息够用时开始执行，关键项缺失时暂停。

好的 Skill 会降低用户描述任务的门槛，同时守住启动条件。

Process：在模型判断、明确流程和脚本之间分工

处理层决定 Agent 怎样干活。你可以把步骤分成三种：

• •需要理解和判断的步骤，交给模型。比如从访谈里归纳需求、比较多个方案、根据上下文选择评审维度。

• •需要顺序和协作的步骤，写成流程。比如先读背景，再检查信息缺口；形成提纲后请用户确认；收到反馈再进入成稿。

• •需要确定性的步骤，交给脚本。比如解析固定格式文件、批量改名、计算指标、校验 JSON、检查文档是否缺少指定章节。

全部交给模型，过程容易漂。全部写成脚本，开放任务又装不进去。

Skill 设计的手艺，就体现在这条分界线上。

你还要标出中间状态放在哪里。

长任务可以把阶段产物保存成文件：资料摘要、待确认问题、当前提纲、检查报告。

Agent 下一轮能接着做，用户也能查看过程。任务中断后，这些文件还能帮它恢复。

Output：交付物要能被下一步直接使用

“输出一份高质量报告”给不了 Agent 足够的信息。

高质量要落到看得见的标准：结构有哪些章节，数字附什么来源，结论对应哪些证据，文件用什么格式，谁会拿它做下一步。

用户对交付物有两种常见状态：

一种是用户只知道目标。比如他想写一篇能带来报名的课程文章，却说不清文章该有哪些部分。Skill 需要提供一套经过验证的内容结构和写作标准。

另一种是用户已经拿着固定载体。老板给了一张 Excel 模板，团队沿用一份评审表，系统只接受指定 Schema。Skill 要读取这个载体，反推加工方式，并把结果准确填回去。

交付结束前，还要安排自检。检查可以来自清单、脚本、样例对照或二次核验。

Agent 应该知道“生成完了”和“可以交付”之间还有一道门。

Harness：让 Agent 知道哪里该停

万事皆可 Harness，skill 同样。（这里其实多少有点滥用这个词了，Guardrails 似乎更合适一些）

skill 不能只有对 Agent 的“鼓动”，还要有“劝解” —— 哪些事不能做、别乱做 —— 一个合格的 Skill 还应该包括：

• • 哪些操作可以直接做，哪些只能预览；

• • 哪些动作必须获得用户确认；

• • 数据不足时如何报告，禁止用什么内容补空白；

• • 工具失败后重试几次，失败到什么程度要停；

• • 修改前怎样备份，出错后怎样恢复；

• • 哪些信息可以进入外部服务，哪些只能留在本地。

这部分很像产品中的权限、异常流和风控设计。

过去画业务流程时容易把它们塞进角落，Agent 会把这些角落放大，因为它会自己规划下一步，也可能连续执行很久。

用 IPO 与 Guardrails 设计一个 Skill 另一个思路：skill 是来填坑的

IPO 帮你正向设计一套 Skill。还有一条反向路径也很实用：观察模型会在哪里出错，再给对应位置加约束。

这项工作很像做产品复盘。模型每次把活干砸，都在告诉你能力单元里少了什么。

大模型的核心缺陷其实就两个：

1. 1. 知识非常多，多到了我们不知道它具体有哪些知识，也因此不知道它会使用什么知识帮我解决问题

2. 2. 生成 Token 很随意， 每一次不确定性都在长程任务中被持续叠加

由此，可以展开非常多会搞砸任务的问题：

LLM的部分缺陷vs补救skill策略

比如其中的“信息不够时自行假设”：

在长任务里，一处假设会一路传下去。Agent 先编了一个市场数据，后面的策略、预算和目标都建立在它上面。

就 LLM 的这个“臭毛病”，Skill 可以规定：外部事实必须给出来源；无法核实时标为未知；关键输入缺失就向用户提问。

这个约束短短几行，能救下后面几十步。

Skill 的第一版通常来自经验，后续版本则来自失败。每次大崩溃，可能正好就是一个可以独立封装的 skill。

开发一个 Skill 的极简流程

Skill 开发很像做一款小产品：先找场景，理解熟手的工作方式，做出最小闭环，再用真实任务把问题跑出来，然后迭代、迭代、迭代……

不着急非得上 scripts，代码会扩大 skill 的范围、提升流程的稳定性，但最好先把场景和流程捋出来。

SKill 的核心之核心，是把隐性的判断还原成清楚的输入、步骤、边界和标准。

第一步：选一个值得封装的任务

适合做成第一只 Skill 的任务，通常有几个特征：

• • 团队反复在做，频率足以支撑维护成本；

• • 熟手和新手的结果差异明显，经验有迁移价值；

• • 任务需要多步完成，单段 Prompt 已经显得吃力；

• • 输入和交付物大致可描述，能判断是否完成；

• • Agent 能访问任务需要的材料和工具。

需求评审、用户访谈整理、周报生成、运营文案检查、数据口径核对，都适合作为起点。

“帮公司做好所有产品工作”这个范围太大。第一版最好切成一个清楚的任务，比如“评审进入研发前的功能 PRD，并输出待澄清问题与风险清单”。

场景越具体，Skill 越容易获得清晰边界。

第二步：先找 cases，再写 md

找三到五个过去做过的案例，至少覆盖一次顺利完成、一次信息不足、一次中途出错。

把当时的输入、过程、最终交付和反馈放在一起看一遍，边界先界定出来。

接着访谈“熟手”，也就是最佳实践萃取。

少问“你有什么方法论”，多追具体动作：

• • 你拿到材料先看哪里？

• • 哪种信号会让你停下来追问？

• • 哪些错误新人经常犯？

• • 你怎么判断结果可以交出去？

• • 遇到例外时，你会改走哪条路？

• • ……

人很难一次说清自己的全部经验，前面找的真实案例能把肌肉记忆拉回现场。

第三步：列出 IPO 和失败点

用一页纸列出：

输入：用户提供什么？Agent 主动读取什么？缺什么就不能开始？
处理：熟手按什么顺序做？哪里需要判断？哪里适合用脚本？
输出：交付给谁？用什么格式？怎样验收？
边界：哪些动作要确认？哪里容易出错？失败后怎么办？

再把 LLM 缺陷的问题表拿过来逐项看：模型会不会混淆术语？会不会漏检查？会不会在数据缺失时猜一个？

这些潜在的问题，决定需要准备什么资料、模板和校验规则。

第四步：拆分文件，构建上下文结构

SKILL.md的大忌：洋洋洒洒几千字的流程、规则、代码。

切记：SKILL.md是INDEX，即放路由和行动指引：适用场景、执行顺序、协作节点、边界与验收。

要短到模型读完注意力完全不会有任何变化，但也要完整到模型知道下一步去哪找。

大段领域知识放进references/。

固定交付结构放进templates/。

需要精确执行或反复运行的动作放进scripts/。

样例可以单独保存，供模型理解标准，也供你做回归测试。

入口文件越长，模型越难抓住行动主线。把资料拆开，并在入口里写清读取条件，渐进式披露才会发挥作用。

整体结构捋完，可以开始着手写 skill 了。

第五步：Agent 友好的名称和描述

名称方便人识别，描述帮助模型决定是否选用。描述里要出现用户可能提出的任务、适用条件和能力边界。

下一步营销的必争之地：面向 Agent 的工程优化，Agent Engine Optimisation

例如：

---
name:prd-review
description:"评审进入研发前的功能 PRD。用于检查需求背景、用户价值、业务规则、数据指标、异常流程与上线风险，并输出待澄清问题和风险清单。当用户要做需求评审、PRD 评审或上线前产品检查时使用。"
---

“一个很好用的产品经理技能”很难触发，因为它没说要解决哪类任务。“写文档”又太宽，容易在不相关的写作任务里被误用。

第六步：写执行流程，把分叉点交代清楚

流程要使用动词，明确动作和产物：

1. 1. 读取 PRD 与项目背景材料。

2. 2. 检查启动条件；缺少业务目标、目标用户或核心流程时，列出问题并等待用户补充。

3. 3. 按用户、业务、数据、交互与风险几个视角评审。

4. 4. 对高影响且证据不足的判断标记“待确认”，禁止补造事实。

5. 5. 生成评审报告初稿，请用户确认优先级与争议项。

6. 6. 根据反馈整理终稿，并运行交付检查。

其中，第 2 步和第 5 步是人机协作节点。

你还可以写明不同分支：用户暂时拿不到数据怎么办，PRD 只有原型没有文字怎么办，评审对象只是一个轻量实验时要跳过哪些重型检查……

Skill 无需把每一次模型思考都规定死。稳定主干、关键分叉和危险边界写清楚，普通判断留给 Agent，流程才有弹性。

Skill 相比于 Workflow 的优势就是这里：把编排也交给 LLM，以换取更广泛的适用性。

第七步：写验收标准

大部分 Skill 的问题，是 SOP 跑完就完了，Agent 只参与了“生产”，但产出物质量如何又丢给用户了。

负责人的收尾是验收标准，能逐项回答的验收标准。

例如产出需求评审报告这种 Skill，可以检查：

• • 每个重大风险都引用了 PRD 原文或项目材料；

• • 待澄清问题说明了缺失信息会影响哪个决策；

• • 严重程度使用统一分级；

• • 没有把个人偏好写成用户事实；

• • 报告包含结论、问题、风险和建议动作；

• • 所有引用链接或文件路径可访问。

其中一部分由模型对照清单检查，格式、链接、字段完整性则可以交给脚本。也可以准备一份合格样例，让 Agent 在交付前比较结构和信息密度。

第八步：测试触发、执行和交付

Skill 测试要看三层：

• •触发测试检查 Agent 是否在合适的请求里启用它，也检查无关请求会不会误触发。

• •过程测试检查它有没有读对资料、按顺序调用工具、在缺信息时停下、在高风险动作前确认。

• •结果测试检查交付物是否满足标准，换一个案例后还能否保持质量。

测试部分，强烈推荐仔细阅读 A\ 发布的最新版的 skill-creator，里面包含了非常高质量的 skill 测评策略。

第一版 Skill 很难覆盖所有情况。上线后的维护方式和产品迭代相似：记录问题，判断问题来自知识、流程、工具还是验收，再修改对应文件。

模型读错资料，就改入口里的读取条件。

用户总在同一个问题上答不出来，就调整提问方式或提供示例。

脚本频繁遇到某类错误，就补异常处理。

交付看着完整却不能用，就收紧验收标准。

认知产品化的优势在这里显出来：团队不必依靠某个人下次记住，一次问题可以变成下一版能力的一部分。

一个 Skill 从经验到测试迭代的开发循环 认知离开人的脑袋之后

再回到开头的“产品 Sense”。

资深产品经理听完一句需求，脑子里浮现的那些问题，如今可以被整理、封装、测试，再交给整个团队使用。新人不会因此一夜之间拥有十年经验，但他可以借用熟手的提问顺序、检查维度和判断标准，完成一份更接近专业水位的工作。

对个人来说，Skill 是认知杠杆。你趟过的坑可以继续替你工作，同一套方法不必在每个对话里重新解释。

对团队来说，Skill 是能力基础设施。业务规则、工作流程和质量标准有了共同载体。规范更新时，团队维护一处；任务执行后，大家还能观察效果、继续迭代。

对产品经理来说，它也带来一块新的设计空间。你除了设计页面、流程和规则，还要设计 Agent 的上下文与行为：

• • 它先了解哪些信息；

• • 它可以自行决定什么；

• • 它在哪些节点找人；

• • 它怎样调用工具；

• • 它如何证明任务已经完成。

这些问题都很产品。区别只在于，你设计的用户旅程里多了一位会思考、会行动、偶尔也会犯迷糊的参与者。

Skill 也不会自动把一份普通方法变成专家能力。

文件化只能放大已有认知。

你对任务理解得越深，越能划清模型判断、脚本执行与人工决策的边界；你积累的案例越多，Skill 的分支和验收就越贴近现场。

学 Skill 的过程也会反过来训练产品经理。为了教会 Agent，你得把一句“凭经验判断”拆开，说明自己看了什么、比较了什么、在哪个信号出现时改变决定。那些原来靠感觉完成的动作，第一次变得可以检查、讨论和复用。

第一只 Skill 跑通以后，你会开始用另一种眼光看工作。重复流程里藏着可以封装的能力，评审意见里藏着验收标准，项目事故里藏着下一版的边界条件。

产品经理思维的全面重构

产品经理学习 AI，到底应该学什么？

提示词工程、上下文工程、Harness 工程固然都得学，但那些都是“技”，更底层的“道”是“认知产品化”这个大趋势。

把认知封装成产品，离不开 LLM。

过去设计产品要理解人性，现在设计产品要理解 LLM —— 它的缺陷、边界、一定会搞砸的问题。

我最近在做一门面向产品经理的 AI 转型线下课，用两天的时间，把这套新的思维方式和必须掌握的 LLM 特性帮你全面构建起来。

两天里，我会通过一系列实操项目，完成四次进阶：

1. 1. 把 AI 用进需求梳理、市场调研、PRD 和原型等日常工作，以理解大模型的底层原理；

2. 2. 把 AI 接进现有产品与流程，提升业务效率，以拿到利用AI 技术的门票；

3. 3. 构建模型本位的产品设计视角，真正理解 Agent 原理并动手开发 Agent 和 Skill；

4. 4. 通过三个项目练习 Vibe Coding，做出可以直接交互的 AI 产品。

课程采用小班制，两天都从任务入手，边做边讲。

Skill 会作为原生 AI 产品经理能力的一部分进入实操，你会从原理、场景设计一路做到开发与测试。

第一期已经在过去的 1 个月完成交付：

北京场的部分学员反馈

第二期开始招募，安排如下：

城市

时间

状态

北京-2期

8月1-2日

招募中

深圳-2期

8月15-16日

招募中

上海-2期

8月22-23日

招募中

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

扫码可以查看课程详细内容、上课方式与详细安排。