product-lens

product-lens 概覽

product-lens 是一個決策支援型技能，專門用來在功能開發真正進入實作前先放慢腳步。product-lens skill 能幫你先驗證「為什麼要做」、壓力測試產品想法，並在工程規劃開始前，把模糊需求整理成更清楚的產品簡報。

當你需要的是產品診斷，而不是完整規格書時，就該用 product-lens。它很適合創辦人、PM 和 builder，用來判斷一個想法值不值得做、真正解決的是什麼問題，以及最小但可信的版本應該長什麼樣子。

product-lens 最適合的情境

product-lens for Decision Support 的核心工作，是去問團隊在直接執行時常常略過的問題：這是給誰用的、痛點是什麼、為什麼是現在、以及成功要怎麼衡量。它最適合在功能承諾之前、每週產品 review 期間，或在概念聽起來很令人興奮但還沒有被驗證時使用。

product-lens 和一般 prompt 有什麼不同

一般的 prompt 可以拿來發想功能；product-lens 的範圍更窄，它會引導一場診斷式對話，並產出包含風險、是否繼續做的建議，以及更清楚下一步的 PRODUCT-BRIEF.md。當你需要的是可重複的 review 工作流程，而不是一次性的建議時，它就特別有價值。

什麼情況下不適合用 product-lens

如果你已經想要的是可長期沿用的 PRD-to-SRS 成品，或是 capability contract，這個技能會刻意把你導向 product-capability。product-lens 應該先用來測試想法，不是拿來定稿交付細節。

如何使用 product-lens skill

安裝 product-lens

直接使用 skill 檔案中的儲存庫安裝指令：npx skills add affaan-m/everything-claude-code --skill product-lens。這就是 product-lens install 這一步；安裝完成後，要把它當成工作流程技能，而不是獨立應用程式。

先丟出一個真實的產品問題

最好的 product-lens usage 是從一個具體決策開始。把粗略目標、服務的使用者、目前的行為或替代作法，以及你卡住的選擇一起提供出來。例如：「我們想降低首次賣家的 onboarding 流失率，但還不確定問題到底是定價、設定太複雜，還是信任感不足。」這會比「改善 onboarding」有用得多。

先讀這些檔案

先從 SKILL.md 開始理解工作流程，再視情況查看 README.md、AGENTS.md、metadata.json，以及任何存在的 rules/、resources/、references/ 或 scripts/ 資料夾。在這個 repo 裡，主要來源就是 skill 檔案本身，所以最快的 product-lens guide 是先讀診斷問題和兩種模式，再拿去套真實專案。

把 skill 當成產品簡報引擎使用

實際流程是：先描述機會，讓 skill 追問前提假設，補齊缺少的事實，然後檢視產出的 PRODUCT-BRIEF.md，看是否能得到 go/no-go 答案。若輸出還是太抽象，就把輸入收斂到單一使用者族群和單一痛苦流程，再帶著這些限制重跑一次 skill。

product-lens skill 常見問答

product-lens 適合初學者嗎？

可以，只要你的目標是在動手做之前先想清楚。這個 skill 上手不難，但最適合的情境，是你能提供具體問題、目標使用者，以及對目前工作流程的基本理解。

product-lens 和一般 AI prompt 有什麼差別？

一般 prompt 可能只會給你寬泛的產品建議。product-lens 的設計目標，是逼出能做決策的輸入與輸出：它會追問痛點、時機、排除目標，以及成功指標，因此在產品 review 和 product-lens for Decision Support 上，比隨手發想更有用。

什麼時候應該避免使用它？

當團隊已經有驗證過的簡報，現在需要的是交付物、實作細節或 API-level contract 時，就不要用它。這種情況下，repo 本身也說應該交給 product-capability。

什麼樣的輸入最能發揮 product-lens 的效果？

最好的輸入會包含明確的使用者名稱、具體痛點、使用者現在怎麼做、為什麼時機重要，以及什麼結果算成功。如果你能清楚描述你要做的決定，這個 skill 通常就能把它壓力測試得很好。

如何改進 product-lens skill

給更明確的限制條件

品質提升最大的一步，就是收斂範圍。與其說「提升留存」，不如改成「降低使用免費方案的獨立創作者第一週流失」。限制條件可以幫 product-lens 揭露正確的取捨，避免流於泛泛而談。

提供證據，不要只給想法

如果手上有，請放入使用者引言、客服工單、漏斗流失數據、業務異議，或發佈後回饋。product-lens 最有效的時候，是能判斷真實訊號，而不是抽象直覺；這也會直接提升建議品質。

要求的是決策，不是腦力激盪

當你想要的是 go/no-go 建議、風險審查，或更聚焦的 MVP 論述時，這個 skill 最強。如果你只是問功能點子，得到的價值會比你問「我們應該先驗證什麼、又該避免建哪些東西？」來得低。

第一次跑完後再迭代

先用第一次 product-lens usage 的結果來修正簡報，再把它暴露出來的缺漏資訊補上後重新執行。最好的結果通常來自一次短而精準的診斷迴圈，而不是一個完美到不必改的 prompt。