别再让 AI 只帮你「写文档」:产品经理真正该装的 7 个 Skill

可以把 Skill 理解成一张交给 AI 的「标准作业卡」：什么时候触发、需要什么输入、按什么步骤工作、最终交付什么。

需求探索最常见的错误，是把自己想听的答案塞进问题里：「如果我们做一个自动提醒功能，你会用吗？」这种问题得到的往往是礼貌的「会」，而不是可靠证据。

PROMPT我要访谈最近 30 天放弃创建项目的团队管理员。访谈 30 分钟，目标是理解放弃发生在哪一步，以及他们用什么替代方案。先指出缺失信息，再输出提纲。

它的公开定义是生成结构化客户访谈脚本，使用 JTBD 探询，并遵循 The Mom Test 的原则：不推销、不诱导，聚焦过去真实发生的行为。它能提高问题质量，但不会替你解决样本偏差，也不能保证用户表达等于真实行为。

访谈结束后，真正耗时的是整理：谁在什么情境下做了什么？痛点是偶发抱怨还是重复行为？有没有替代方案？哪些只是我们自己的推测？

summarize-interview 可以把转写整理为 JTBD、满意度信号和行动项。更好的用法是要求它保留原话、说话人和时间戳，并把没有证据的内容标成「未证实」。

这样做的价值，不是节省十几分钟，而是为后续机会树和 PRD 建立可回溯的证据。

竞品分析很容易变成「谁有哪个按钮」的表格。真正有用的分析应该先回答：用户在这个场景里有哪些替代方案？除了直接竞品，还有没有 Excel、人工流程、外包服务或干脆不做？

它的公开用途包括识别直接竞品、分析优劣势和差异化机会。使用时应明确目标用户、场景、分析维度和允许检索的范围，并要求所有事实保留来源链接与访问日期。

团队开会时，最常见的画面是每个人都带着一个功能来：要不要加提醒？要不要做模板？要不要改首页？

机会方案树把讨论顺序倒过来：先明确期望结果，再列出有证据的用户机会，然后才讨论方案和验证实验。它基于 Teresa Torres 的持续发现方法，把 Outcome、Opportunity、Solution 和 Experiment 连成一棵树，最适合承接前面两步的访谈证据。

机会树不是最终答案。它的作用是让「为什么做」在「做什么」之前被说清楚。

「这个需求很重要」通常不是结论，而是一个没有说清权重的判断。

prioritize-features 会按影响、工作量、风险和战略对齐对功能列表排序，并给出 Top 5 建议。它最有价值的地方不是那个排名，而是敏感性：当战略对齐从 25% 调到 40%，排序会不会改变？某一项是不是因为缺数据才看起来很高？

在团队中使用时，要求 Skill 先列数据缺口，再给暂定排序。这样它是在帮助对齐，不是在制造伪客观。

公开的 create-prd Skill 使用八段式模板，覆盖问题、目标、用户、价值主张、方案与发布计划。但更重要的是输入顺序：它应该读取已经确认过的访谈证据、机会树和优先级决策，而不是从一句「做个协作功能」开始自由发挥。

建议在指令里写清四件事：

AI 可以把文档写完整，但技术可行性、资源承诺、法务、安全和上线窗口，仍需要对应负责人确认。

实验组转化率比对照组高，不代表一定应该上线。

ab-test-analysis 的公开定义包括统计显著性、样本量验证、置信区间，以及上线、延长或停止建议。输入至少要有样本量、转化数或均值方差、主要指标、实验时长和分流规则。

还应要求它区分两个概念：统计显著——这个差异不太像随机波动；业务显著——这个差异大到值得承担成本与风险。

如果存在样本比例异常、多重检验、指标中途变更或脏数据，结论必须交给数据分析师复核。

访谈提纲 → 访谈证据卡 → 竞品事实 → 机会树 → 排序与取舍 → PRD → 实验结论

第一，看来源和权限

第三方 Skill 可能读取文件、调用脚本或访问第三方服务。安装前应查看来源、权限和代码，敏感资料要遵守公司安全要求。

第二，AI 不补造事实

AI 适合做结构、归纳、计算和初稿，不适合补造事实。竞品、市场与实验数字必须有来源和口径。

第三，Skill 不代替决策

资源、风险、合规、技术债和上线时机，仍由团队负责。

先从最高频的一步开始。跑通，再连下一步。