夜雨聆风我做B端产品这些年，最近半年最大的认知升级是：AI不只是对话工具，它还能变成你的"得力助手"——而且你不用写一行代码。
这个东西叫 Skill（技能），很多人听过但不知道怎么用。今天这篇文章，我用B端产品经理的实际场景，把 Skill 到底是什么、怎么用，一次性讲清楚。
什么是 Skill？
先说结论：Skill 就是把你每天重复的工作流程，封装成一套自动执行的"技能包"。说白了，可以把它理解为SOP的数字化。
打个比方：
• 你每天早上到公司，先打开竞品页面看看有没有更新 → 这是一个操作 • 若更新则把更新截图发到产品群里 → 这是另一个操作 • 根据竞品的更新情况，写一个prd来更新自己的产品 → 又是一个操作
这些操作如果每天重复做，很浪费时间。但如果把它们串成一个自动化流程，加上 AI 作为中间的智能判断节点，这就是一个 Skill。
用专业一点的话说： Skill 由多个"节点"组成——触发器、数据获取、AI 处理、结果输出，按顺序执行，全程不需要人工干预。或者可以理解为它是把专家经验沉淀为可复用的能力，用它可以完成特定的业务，什么时用调用它就行。最主要的是它能稳定的执行。
为什么 B 端 PM 尤其需要 Skill？
B 端产品经理的时间大量消耗在三件事上：
1. 信息整理（竞品动态、用户反馈、行业报告、需求收集等） 2. 文档撰写（PRD、会议纪要、汇报材料） 3. 跨部门同步（需求评审、进度跟进、问题排查）
这些事情不创造核心价值，但不得不做。Skill 能帮你把这些低创造性但不得不做的事情自动化，不用你自己做。让你专注于做业务价值更高的工作。
当你跑通了几个 Skill 后，你会发现它能帮你省不少时间。省下来的时间不是让你摸鱼，哈哈。而是让你有充足的时间做价值更高的事情——理解业务、设计系统、推动落地。
场景一：「从想法到原型」Skill（每次省下半天）
问题
拿到一个新需求后，以前的流程是这样的：
1. 先花 2-3 小时梳理业务逻辑 PRD初版（背景、目标、功能清单、字段定义……） 2. 再花 2-3 小时用 Axure/Figma 画原型 3. 然后找业务确认，业务说"能不能这样……"，改 4. 改完原型直到业务满意为止再更新 PRD
一轮下来一天就没了。而且 PRD 和原型很容易不一致——PRD 改了原型忘了改，或者反过来。
我的 Skill 怎么做
我写好初步业务需求（不用完整，核心逻辑说清楚就行） ↓AI 根据 PRD 模板，自动完善成完整 PRD（补充字段定义、异常流程、权限说明） ↓AI 根据完善后的 PRD，自动生成可交互的前端原型页面 ↓我审核 → 微调 → 直接拿给业务看具体操作：
我用 Claude Code（或 Trae），操作分两步：
第一步：完善 PRD
我有一个标准的 PRD 模板，包含这些章节：
## 背景与目标## 用户角色与权限## 业务流程## 功能清单（P0/P1/P2）## 页面结构## 数据字段定义（字段名/类型/是否必填/校验规则）## 异常处理## 验收标准拿到需求后，我先写一个初步想法：
我要做一个供应商结算模块。供应商每月对账后生成结算单，财务审核后打款。流程是：系统自动生成 → 供应商确认 → 财务审核 → 打款。然后让 AI 根据我的模板补全：
请按照以下 PRD 模板，帮我完善这个供应商结算模块的需求。模板：[粘贴我的PRD模板]初步需求：[粘贴我的初步想法]要求：1. 功能清单标注 P0/P1/P2 优先级2. 数据字段定义要包含字段类型、是否必填、校验规则3. 异常场景至少列出 5 个（比如供应商不确认怎么办、财务驳回怎么办）4. 用表格输出，不要写大段文字第二步：生成原型
PRD 完善后，直接让 AI 生成前端页面：
基于上面完善的 PRD，帮我生成一个供应商结算后台的前端页面。要求：1. 用 React + Tailwind CSS2. 包含供应商列表、结算单明细、确认按钮3. 数据先用 mock4. 页面要包含筛选条件（供应商名称、结算状态、时间范围）效果
• 以前：写 PRD 2-3 小时 + 画原型 2-3 小时 = 5-6 小时，甚至更多 • 现在：写初步想法 30 分钟 + AI 完善 PRD 5 分钟 + AI 生成原型 10 分钟 = 45 分钟
而且 PRD 和原型天然一致——都是从同一个需求生成的，不存在"改了原型忘了改 PRD"的问题。
踩坑提醒
• 不要一次性把完整需求丢给 AI，它会跑偏。先给它核心逻辑，让它生成框架，确认方向对了再补充细节。 • AI 生成的 PRD 是"骨架"，你需要填"血肉"。具体的业务规则、你们公司的特殊逻辑、和开发确认的技术约束，这些 AI 不知道，必须你补。 • PRD 模板要提前写好，不能临时凑。模板质量直接决定 AI 输出质量。如果你自己的模板都很模糊，AI 只会更模糊。建议先花 1 小时把 PRD 模板打磨好，后面每次用都是复用。
场景二：「PRD 同步更新」Skill（每次省下 2 小时）
问题
和业务进行需求评审/原型评审，经常会临时调整需求——加个字段、改个交互、调整个状态。
以前我的做法是：
1. 会上口头确认"好的，那就这样改" 2. 会后花 1-2 小时更新原型 3. 更新完再改prd
但经常出现的情况是：会上定了 5 个调整，会后只改了 3 个，另外 2 个忘了。或者改了功能描述，但没改数据字段定义，导致开发按旧 PRD 开发，上线后出 Bug。
我的 Skill 怎么做
我在原型页面上和 AI 对话，调整需求（改交互、加字段、调逻辑） ↓AI 更新原型页面 ↓AI 同步分析：这个调整是否影响 PRD？如果影响，自动更新 PRD 对应章节 ↓AI 输出变更清单（改了哪些、为什么改、影响范围）具体操作：
我直接在 Claude Code 里对话，调整原型：
帮我在供应商列表页加一个"批量导出"按钮，导出的字段包括：供应商名称、结算金额、结算状态、创建时间。AI 会更新页面，然后告诉我：
已完成。以下变更需要同步到 PRD：✅ 已更新 PRD：1. 【功能清单】新增 "批量导出" 功能（P1）2. 【页面结构】供应商列表页新增操作按钮区域我确认后，PRD 自动更新完成。
效果
• 以前：会上记录 + 会后整理 PRD = 2 小时 • 现在：对话调整 + AI 自动更新 PRD + 确认 = 15 分钟
更重要的是：不会再漏改PRD了。AI 会分析每次原型调整对 PRD 的影响，自动标注需要同步的地方，我只负责确认。
踩坑提醒
• 变更清单一定要留存档。每次更新后让 AI 输出的变更清单不要删，保存起来。后续开发问"这个字段怎么变了"，你直接甩清单，比翻聊天记录快 100 倍。 • AI 的判断不一定对，它可能把"不影响 PRD"的交互调整也标成需要更新。没关系，宁可多标，不能漏标。你只需要快速扫一眼确认就行。 • 每次更新后，让 AI 输出一份变更清单。这样你发给开发的时候，他们一眼就知道改了什么，不用重新看整份 PRD。 • PRD 模板要提前定义好章节结构。如果模板不规范，AI 不知道往哪里更新内容。 • 多留个心眼。有时候 AI 有时候也会遗漏 PRD 更新，所以每次更新了页面/原型后，一定要看下AI到底有没有更新prd。
怎么开始你的第一个 Skill？
不需要写代码，不需要懂技术。推荐从 Claude Code 或 Trae 开始：
1. 想场景：想一想平常你的工作中哪项工作是重复的，并且是低级的（价值低），不值得你去干 2. 定规则：这项工作是否能做成一个标准化的sop（规范化，如什么时候按什么规则执行，你需要什么样的结果）
如果这2点有了，那么你就可以搞skill了。
Skill怎么编写？
先放松，再放松。因为skill不需要你写代码，你用自然语言告诉它就行，所以不用紧张。
1. 定目标：告诉AI你的目标是什么，你想解决在什么场景下的什么问题 2. 讲流程：告诉AI这项工作的流程是什么，比如1,2，3…… 3. 约束：告诉AI你希望这个skill输出什么，输出格式是什么；不希望AI输出什么等
有了这些你AI就可以帮你写skill了。从现在开始就琢磨一下，你的哪个工作打算用skill实现吧。在工作中要多实践。跑几个skill后再去研究每个skill的文件结构，你会发现所有skill的文件目录都是一样的（这是规则）。作为产品，了解skill的文件结构即可，不必研究细节。
Skill 编写的 5 个注意事项
1. 场景越小越好不要一上来就想做一个"万能 Skill"。先选一个具体、高频、规则清晰的场景——比如"每周五整理用户反馈"。跑通后再扩展。小步快跑，比大而全强 100 倍。
2. 先跑通，再优化第一个版本一定不完美。没关系，先用最简单的方式跑通整个流程，看到效果了再调优。我自己编写的一个 Skill，最初的提示词只有 3 句话，后来迭代了 8 次才能跑的很顺畅。
3. 输出格式要提前约束AI 默认的输出格式往往不是你想要的。一定要明确告诉它：输出什么格式（表格/列表/JSON）、不要什么内容。比如"用表格输出，不要写大段文字"、"只输出差异点，相同内容不要提"。
4. 敏感数据不要丢给 AI客户信息、内部数据、未公开的业务指标——这些不要放到 Skill 的输入里。如果确实需要，先做脱敏处理（比如用"客户A"代替真实名称）。
5. 定期备份你的 SkillSkill 的配置文件、提示词模板——定期备份。平台可能更新、可能下线，但你的经验是你的。建议每个 Skill 建一个文件夹，里面放：配置文件、提示词、使用记录、迭代历史。
Skill 的迭代方法：怎么让它越来越好用？
Skill 不是一次写完就能一直用的，需要在工作过程中持续优化。我的迭代方法是：
第一步：每次使用后记录问题每次跑完 Skill，花 1 分钟记录：哪些地方结果不理想？AI 理解错了什么？缺了什么信息？
第二步：集中优化，不要每次改一点不要每次遇到小问题就去改 Skill。攒够 3-5 个问题后，集中调一次。这样效率更高，也能看出优化前后的对比。
第三步：保留旧版本每次大改前，把旧版 Skill 的文件复制一份，命名为"v1 备份"。这样新版跑崩了可以回退。
第四步：分享给同事测试你跑得很顺的 Skill，别人用可能处处卡壳。找同事跑一遍，你会发现很多你意识不到的问题。这也是验证 Skill 是否"通用化"的最好方式。
写在最后
Skill 不是替代产品经理，而是把你从重复劳动中解放出来，让你有时间做非常非常重要的事——理解业务、抽象问题、设计系统。
B 端产品经理的核心竞争力，不是你会用多少工具，而是你能不能把一个复杂的业务问题，抽象成一套清晰的规则。Skill 只是帮你把这套规则自动化执行而已。
但如果你连规则都理不清楚，Skill 也帮不了你。
所以，先把业务想清楚，再用 Skill 让它跑起来。
我是做 10年+ B 端产品的产品人，AI 是我最近在死磕的方向。
关注公众号「B端产品AI附身」，回复关键词领取资料：回复「AI工具」→ B端产品经理 AI 效率清单回复「简历模板」→ B端高级产品经理简历模板（3套）
本公众号持续分享 B 端产品实战经验和 AI 工具用法、B端产品方法论干货，拒绝假大空！欢迎大家一起交流、进步。
