product-lens

product-lens 概览

product-lens 是一个决策支持型 skill，专门用来在功能真正进入实现前先踩刹车、把问题想清楚。product-lens skill 可以帮助你验证“为什么要做”、压力测试产品想法，并在工程规划开始之前，把模糊需求转成更清晰的产品 brief。

当你需要的是产品诊断，而不是完整规格说明时，就该用 product-lens。它很适合创始人、PM 和 builder，用来判断一个想法值不值得做、它到底在解决什么问题，以及最小可行版本应该长什么样。

product-lens 最适合做什么

product-lens for Decision Support 的核心任务，是把团队在直接进入执行时常常跳过的问题问出来：这是给谁用的、真正的痛点是什么、为什么是现在、成功要怎么衡量。它最适合在功能承诺之前、每周产品评审时，或者当一个概念看起来很激动人心但还没有被验证时使用。

product-lens 和普通 prompt 有什么不同

通用 prompt 可以帮你发散功能点，而 product-lens 更聚焦：它推动的是一场诊断式对话，并输出一份包含风险、go/no-go 建议和更明确下一步的 PRODUCT-BRIEF.md。这让它在你需要的是可重复的评审流程，而不是一次性建议时，更有价值。

什么时候不适合用 product-lens

如果你已经想要的是一份稳定的 PRD-to-SRS 产物，或者 capability contract，这个 skill 会有意把你转交给 product-capability。product-lens 应该先用来测试想法，而不是最终定稿交付细节。

如何使用 product-lens skill

安装 product-lens

使用 skill 文件里的仓库安装命令：npx skills add affaan-m/everything-claude-code --skill product-lens。这就是 product-lens install 步骤；安装完成后，把它当作一个工作流 skill 使用，而不是独立应用。

输入一个真实的产品问题

最好的 product-lens usage 一定从一个具体决策开始。给它一个粗略目标、服务的用户、当前行为或替代方案，以及你卡住的选择点。比如：“我们想降低首次卖家的 onboarding 流失率，但不确定问题到底是定价、配置复杂，还是信任不足。”这要远比“改进 onboarding”有效得多。

先读这些文件

先看 SKILL.md 理解工作流，再查看 README.md、AGENTS.md、metadata.json，以及可能存在的 rules/、resources/、references/ 或 scripts/ 目录。在这个 repo 里，主要来源就是 skill 文件本身，所以最快的 product-lens guide 是先读诊断问题和两种模式，再把它用于真实项目。

把这个 skill 当作产品 brief 引擎来用

实际流程是：描述机会，让 skill 追问假设，补齐缺失事实，然后查看生成的 PRODUCT-BRIEF.md，拿到 go/no-go 判断。如果输出还是太抽象，就把输入收紧到一个用户细分和一个最痛的工作流，再带着这些约束重新跑一遍。

product-lens skill 常见问题

product-lens 适合新手吗？

适合，只要你的目标是在动手做之前先想清楚。这个 skill 上手不难，但最适合的前提是你能提供一个具体问题、目标用户，以及对当前工作流的基本认知。

product-lens 和通用 AI prompt 有什么区别？

通用 prompt 可能会给出宽泛的产品建议，而 product-lens 是为了逼出高质量决策输入和输出而设计的：它会追问痛点、时机、反目标和成功指标，因此它更适合产品评审和 product-lens for Decision Support，而不是随手头脑风暴。

什么时候应该避免使用它？

当团队已经有了经过验证的 brief，并且需要交付物、实现细节或 API 级别的 contract 时，就不要用它了。仓库本身也说明，这种情况下应该交给 product-capability。

什么样的输入最能发挥 product-lens 的效果？

最有力的输入包括：明确的用户、具体痛点、用户今天怎么做、为什么时机重要，以及什么才算成功。如果你能把需要做出的决策讲清楚，这个 skill 通常就能很好地帮你做压力测试。

如何改进 product-lens skill

给出更明确的约束

提升质量最大的办法就是缩小范围。不要只说“提高留存”，而是试试“降低使用免费计划的独立创作者在第一周的流失”。约束越清楚，product-lens 就越容易提炼出正确的取舍，而不是给出泛泛而谈的建议。

提供证据，而不只是想法

如果有的话，加入用户原话、支持工单、漏斗流失数据、销售异议或上线反馈。product-lens 最擅长的是基于真实信号做判断，而不是凭抽象直觉猜测；这些证据会直接提升建议质量。

要求它给决策，不要只要脑暴

这个 skill 在你想要 go/no-go 建议、风险评审，或者更清晰的 MVP 论证时最强。如果你只是要功能点想法，它给你的价值会明显低于你直接问：“我们应该先验证什么，又应该避免做什么？”

第一次跑完后继续迭代

先用第一次 product-lens usage 的结果来修正 brief，再把它暴露出的缺失信息补进去重新运行。最好的结果通常来自一次简短的诊断循环，而不是一条完美无缺的 prompt。