brainstorm-ideas-existing

brainstorm-ideas-existing 概览

brainstorm-ideas-existing 是一个面向产品发现的技能，用于围绕已有产品生成新想法，而不是从零发明。它帮助一个 product trio 分别从 PM、Designer 和 Engineer 的视角思考某个机会点，再把输出收敛到最有希望的方向。适合你已经有了一个产品、一个目标人群和一个待解决问题，希望获得比通用提示词更结构化的创意发散时使用。

这个 skill 最适合什么场景

当你需要新的功能点、已知机会的替代方案，或者更好的产品发现假设起点时，brainstorm-ideas-existing 的效果最好。它尤其适合 Product Management 场景：目标是在确定 roadmap 方向之前，先把客户痛点、业务价值和落地现实连起来。

它有什么不同

和松散的头脑风暴提示词不同，这个 skill 明确引入了多个视角和优先级排序。这一点很重要，因为它能减少单一维度的点子，帮助你找到真正值得验证的选项。它也会鼓励你进入 discovery 的迭代回路，这在第一次产出不够好，或者证据还不完整时尤其有用。

什么时候适合用

如果你能回答三个问题，就适合用 brainstorm-ideas-existing：你在做什么产品、你在探索什么机会或问题、这些想法要服务谁。若你只是想要泛泛的创意灵感，这个 skill 可能流程感过重；但如果你需要更贴近产品策略和执行约束的想法，它会更合适。

如何使用 brainstorm-ideas-existing skill

安装并定位这个 skill

使用 npx skills add phuryn/pm-skills --skill brainstorm-ideas-existing 安装。就 brainstorm-ideas-existing 的安装决策来说，关键点是这个 repo 很精简：没有可供检查的辅助脚本或支持目录，因此 SKILL.md 是主要的信息来源。建议先从这里开始，再确认 frontmatter，并在把它接入你的工作流之前通读 skill 正文。

给 skill 正确的输入

brainstorm-ideas-existing 的使用方式在你提供产品名称、具体机会点、目标受众和期望结果时最有效。好的输入会像这样：“为我们现有的 fitness app 头脑风暴一些想法，帮助改善新用户首周流失问题。” 不好的输入则像：“给我的产品一些想法。” 前者给了 skill 足够上下文来产出有用点子；后者只能让它猜。

用 trio 风格来提问

这个 skill 的设计思路是从 PM、Designer 和 Engineer 的角度思考，所以提问时要围绕决策，而不只是发散创意。一个实用的 brainstorm-ideas-existing 用法，是先按视角要点子，再加一个简短的优先级筛选步骤。例如：“分别从 PM、Design、Engineering 三个视角各生成 5 个想法，然后按影响力、可行性和信心度排序出前 5 个。” 这种结构符合 skill 的工作流，也更便于在 workshop 或规划会议中直接使用输出结果。

先阅读源文件

对于这个 repository，SKILL.md 是最先要看的主文件，因为没有 README.md、rules/、resources/ 或脚本来扩展工作流。如果你要把 brainstorm-ideas-existing 改造成适合自己组织的版本，最重要的不是照搬措辞，而是保留顺序：先确认上下文，再从多个视角发散，然后做优先级排序。这个顺序才是把输出牢牢锚定在真实产品问题上的关键。

brainstorm-ideas-existing skill 常见问题

brainstorm-ideas-existing 只适合 Product Management 吗？

不是。brainstorm-ideas-existing 对 Product Management 很有用，但它的设计本身就是跨职能的。只要决策同时涉及 PM、Design 和 Engineering，它就会更好用，尤其是在你既想要有吸引力、又想要能落地的想法时。

它和普通提示词有什么不同？

普通提示词也许能给出一些想法，但 brainstorm-ideas-existing 会增加结构：它要求上下文、区分不同视角，并推动你做优先级排序。这样通常能得到更可用的输出和更少的空泛建议，尤其是在机会点复杂，或者团队需要一个共同起点时。

这个 skill 适合新手吗？

适合，前提是你已经知道产品和问题是什么。使用这个 skill 不需要你具备完整的 discovery 经验，但你需要给它足够的上下文。新手如果能在提问前用一小段话说明产品、用户分群和业务目标，通常会得到更好的结果。

什么时候不该用它？

当问题还没定义清楚、产品本身还不明确，或者你只是想快速列一堆随机概念时，不要用 brainstorm-ideas-existing。如果你需要的是深入的研究综合、UX 文案，或者实施规格说明，它也不是最佳选择。它的价值在这些任务之前：把一个已知机会转化为更好的产品选项。

如何改进 brainstorm-ideas-existing skill

先把约束说得更清楚

brainstorm-ideas-existing 的最佳结果来自明确边界：目标人群、产品阶段、指标和已知痛点。比如你说“提升 self-serve SMB admins 在前 7 天的 activation”，得到的点子会比“改进 onboarding”更好。约束会帮助 skill 用相关性换取广度。

要求输出可评估

不要只停留在生成想法。你应该要求 skill 说明每个想法为什么重要、由哪个视角提出，以及应该如何判断它。比如：“对每个想法，注明预期用户价值、业务影响和主要实施风险。” 这样能让 brainstorm-ideas-existing 的输出更接近决策材料，也更方便和 product trio 一起讨论。

在第一轮之后继续迭代

第一轮输出通常只是起点，不是最终答案。如果想法太泛，就收窄受众或结果；如果太保守，就要求更大胆的选项或相邻机会；如果觉得成本太高，就让它给出更低投入的变体。这样不断迭代，brainstorm-ideas-existing 才能真正用于产品发现，而不是停留在 workshop 练习层面。

用证据来增强提示词

如果有研究笔记、用户原话、漏斗数据，或者当前产品限制，就把它们加进去。这个 skill 本来就是围绕机会背景来工作的，所以证据能帮助它避免泛泛的头脑风暴。更强的输入，是提升 brainstorm-ideas-existing 使用效果、并把想法推进到实验而不只是讨论的最快方式。