惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - Franky
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
Google DeepMind News
Google DeepMind News
腾讯CDC
G
Google Developers Blog
Martin Fowler
Martin Fowler
Microsoft Security Blog
Microsoft Security Blog
Recent Announcements
Recent Announcements
爱范儿
爱范儿
Engineering at Meta
Engineering at Meta
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans
aimingoo的专栏
aimingoo的专栏
有赞技术团队
有赞技术团队
Jina AI
Jina AI
人人都是产品经理
人人都是产品经理
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
M
MIT News - Artificial intelligence
罗磊的独立博客
博客园 - 三生石上(FineUI控件)
美团技术团队
WordPress大学
WordPress大学
阮一峰的网络日志
阮一峰的网络日志

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
用Skill做产品规划?聊聊我踩过的3个坑 – 人人都是产品经理,
产品方法论集散地 · 2026-05-08 · via 人人都是产品经理

AI技能的落地并非一帆风顺,从万能许愿池到精准工具的认知转变,背后是无数踩坑经验的积累。本文首次披露作者在10个Skill实战中遇到的三大典型陷阱:违背单一职责原则、高估私有数据抓取能力、盲目信任业务理解深度。每一段血泪史都指向同一个真相——AI不是魔法,而是需要精心设计输入与拆解任务的超级外脑。

原本今天这篇文章,我是想继续分享如何把产品方法论封装到 AI Skill(智能技能)里的实操案例。

但随着这段时间我在业务里疯狂落地了近10个Skill,逐渐发现了一个更值得聊的话题——AI 的局限性

我发现,把 AI 当工具用和把它当“万能许愿池”用,完全是两码事。在这个把大模型吹得神乎其神的风口上,我也没能免俗地踩了不少坑。

今天不聊高大上的成功案例,就聊聊我在写了近10个产品辅助 Skill 之后,实打实踩过的三个坑。希望能给正在尝试把 AI 融入日常工作的你,一点真实的启发。

第一个坑:总是忽略 AI 的“单一职责原则”

在上一篇分享《如何用 Skill 评估工作量》时,我就踩过这个坑。

当时我期望一个 Skill 既能帮我输出完整的产品方案,又能顺手把对应的研发工作量给评估了。结果呢?它哪件事都没干好,方案写得很水,评估也很离谱。

昨天在写“产品规划 Skill”的时候,我又犯了同样的错。

我想用一个 Skill 一步到位:让它先去分析关键竞品最近两年的迭代情况;然后再去分析我积压的近千条需求清单;最后再结合我们公司的战略方向,直接给我吐出一份完美的“年度产品规划”。

结果可想而知,一团糟。

最后的解决方案是什么?分拆。我老老实实地把它拆成了三个独立的 Skill:

  1. 竞品分析 Skill:只负责分析我投喂的竞品日志,输出路线图和差异化策略。
  2. 需求优先级判断 Skill:只负责拿着我那上千条需求,严格按照我的方法论(P0-P4)打分,输出优先级清单。
  3. 产品规划 Skill:最后拿着前两个 Skill 的结果,结合企业战略,输出最终的产品规划思路和路线图。

小结一下:这是最常见、也最容易踩的坑。本质上,是我们对 AI 抱有不切实际的幻想。我们总以为它已经强大到能通过一句简单的指令,理解所有复杂的诉求。

这就像你对刚招进来的应届高材生说:“你去把竞品和咱们的需求池看一看,下午给我一份明年的产品规划。”——除了得到一份根本没法落地的 PPT,你什么也得不到。

第二个坑:过度迷信 AI 对“私有化数据”的抓取能力

在做竞品分析的时候,我一开始的想法很丰满:我只要输入竞品名称(比如北森、薪人薪事、飞书等),AI 就能自动去网上抓取他们最近 1-2 年的升级日志和财务报表,自动给我分析出一份产品路线图和战略变化。

它确实给我输出了一篇洋洋洒洒的内容。但仔细一看,基本全是基于网上公开的营销软文、发版通稿、甚至发布会公关稿拼凑出来的。对于产品底层究竟是怎么迭代的,几乎没有任何参考价值。

其实,但凡多想一步,我都不会有这种不切实际的幻想。

原因很简单:对于 SaaS 企业来说,真正的“用户手册”、“升级日志”这些核心的更新记录,都是需要登录鉴权才能看到的,这属于企业的私有化资产。AI 再厉害,也突破不了这层物理隔离。

最后的解决方案:回归“外脑”定位。我换了个思路,把之前人工辛苦整理下来的“竞品升级日志”作为原材料投喂给 AI。告诉它:“基于这些真实的迭代日志,帮我分析他们演进的路线图和对我们的启示。”

这一次,它给出的结果完全符合预期。

小结一下:这个坑的本质是“上下文环境(Context)”缺失。你可以把大模型想象成一位享誉世界的大厨。但如果你不把你们家祖传的秘方和特定的原材料交给他,他也绝对做不出一道符合你口味的家乡菜。

不要对 AI 有超出常理的预期,以为只要给个简单提示词,你就能坐享其成。

第三个坑:过度信赖 AI 对自身业务的“推理与理解”能力

我负责的两个子系统,最近一年半积压了 1000 多条需求。以前,我每周都要花半个小时去人肉标识这些需求属于哪个模块(比如:排班-循环排班-大小周)。

我一开始的如意算盘是:建一个 Skill,把这 1000 条需求丢给它。让它不仅帮我把同类场景的需求合并(比如把5条循环排班的需求合并成1条),还能结合我的优先级方法论(产品价值 = 客户价值 + 商业价值 – 情绪成本x2),直接给我输出一份精简后的高优需求表。

结果呢?我又一次被现实打脸。我高估了 AI 对我们特定业务的理解能力,也高估了业务端提需求时描述的清晰度。AI 根本无法像我预期那样准确地“合并同类项”,它给出的合并结果,几乎全是凭空臆想的,逻辑漏洞百出。

最终的妥协与务实:调试了好几次后,我放弃了让它去“深度理解并合并”的幻想。我退而求其次,选择了更务实的路径:不要求它合并需求,只要求它判断优先级。

我输入 1000 条需求的 Excel 表,它原封不动地输出 1000 条需求,只是在后面严格按照我的方法论加上了优先级的判断(P0-P4)。这样,我只需要重点去捞那些被判定为 P0 和 P1 的需求自己看就行了。

小结一下:这第三个坑,其实是前两个坑的综合体。我既犯了“让它同时干多件事(合并需求+判断优先级)”的错,又犯了“在没有给足业务 Context 的情况下,指望它能像我一样拥有业务直觉”的错。

写在最后

踩完这三个大坑,我对 AI 的使用姿势有了全新的认知:

Skill 在创建的时候,必须严格遵循“单一职能”原则。同时,需要提供足够Context(即上下文)

但这并不意味着我们的工作流只能是零碎的。在实际使用时,我们可以把多个单一职能的 Skill 组合起来,把Context当做输入素材利用起来

比如,我现在要做2026年半年度规划,我的工作流变成了:

  1. 提供内部收集的竞品升级日志文件,调用【竞品分析 Skill】
  2. 导出 1000 条需求清单文件,调用【需求优先级判断 Skill】
  3. 自动结合前两者的输出,加上我们公司的战略和投入资源,调用【产品规划 Skill】

AI 终究只是那个拿着锅铲的大厨,而你,才是那个决定要做什么菜、并且负责准备顶级食材买得好不好的饭。

本文由人人都是产品经理作者【产品方法论集散地】,微信公众号:【产品方法论集散地】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。