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

推荐订阅源

D
Docker
博客园 - 三生石上(FineUI控件)
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园_首页
Microsoft Azure Blog
Microsoft Azure Blog
GbyAI
GbyAI
腾讯CDC
酷 壳 – CoolShell
酷 壳 – CoolShell
M
MIT News - Artificial intelligence
Stack Overflow Blog
Stack Overflow Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Jina AI
Jina AI
爱范儿
爱范儿
博客园 - 【当耐特】
雷峰网
雷峰网
S
SegmentFault 最新的问题
美团技术团队
Blog — PlanetScale
Blog — PlanetScale
The GitHub Blog
The GitHub Blog
有赞技术团队
有赞技术团队
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
Google DeepMind News
Google DeepMind News
J
Java Code Geeks

人人都是产品经理

为什么你的产品找不到差异化?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 协议。