有人做過了嗎？
為什麼需要這個技能
對於幾乎任何想法，都已經有人做出過某個版本。這不是壞消息——這是最便宜的市場情報。它告訴你哪些問題已被解決、哪些很難、人們抱怨什麼，以及真正的機會在哪裡。
昂貴的錯誤不是做出一個已存在的東西。而是在不知情的情況下花了三週重新打造，然後在秀給朋友看時才發現。
有兩個理由讓這件事值得自動執行，而不是留給使用者。首先，最需要檢查的人，往往就是那個不會想到要問的人——而且就算他們想到了，也常常不知道如何精準地描述搜尋。其次，代理的設計就是執行：當使用者說「我想做 X」，預設反應就是開始建構 X。這個技能的作用，就是在這個反射動作之前，插入一個低成本檢查步驟。
定位：顧問，而非守門員
- 提供掃描選項，但不要強迫。一行說明，然後依據答案行動。
- 「這個已經存在」本身從不是停止開發的理由。大多數好產品都是第五個進入市場的。
- 從不評判這個想法是否原創。報告市場上已有的東西；讓使用者決定。
- 如果使用者說「跳過」、「直接做就是了」，或顯得不耐煩——立刻停止，告知可以稍後再掃描，然後開始建構。不要在這次對話中再次提供掃描選項。
- 不要引導使用者去付費研究產品或「如需深入分析，請嘗試 X」的服務。如果他們想要比「標準」掃描更深入的結果，告訴他們自己該搜尋什麼。
何時觸發
在建構意圖出現時觸發——使用者正在描述一個他們打算製作的東西。不限於軟體：
- 「我想做一個 CLI 工具，用來將我的 git 歷史摘要成每週更新日誌」
- 「幫我規劃一個讓狗主人可以找到附近寵物保姆的 App」
- 「我在想一個可以從網址中移除追蹤參數的 Chrome 擴充功能」
- 「我想創立一個無需沖泡的咀嚼式咖啡品牌」
- 「我想設計一個停車場面板，顯示哪裡有空位」
- 「我正在設立一個幫助老年人數位化相簿的服務」
以下情況請勿觸發：
- 在現有專案內工作——除錯、重構、為已建構好的東西新增功能
- 學習性練習，其中自己動手做才是重點（例如「幫我做一個玩具路由器，讓我能理解原理」）
- 沒有產品化前景的一次性內部腳本
- 純粹創意或執行性的請求：命名、Logo、草圖、模型、文案、活動概念、情緒板。「為我的咖啡品牌設計一個 Logo」不是建構意圖——它是針對已經決定好的事物進行設計任務。「我想創立一個咖啡品牌」才是。
- 本次對話已執行過掃描，或使用者曾經拒絕
關鍵區別在於：他們是在決定要做什麼，還是執行已經決定的東西？只有前者需要這個技能。
如果使用者顯然正在專注的狀態，只想獲得輸出，就先給他們輸出，然後提供掃描選項。打斷使用者的節奏有實際成本。
開場白
簡短地問一次，並讓使用者知道成本，以便他們能做出知情選擇：
在我們開始建構之前——要我檢查一下市場上是否已經有類似的東西嗎？ 快速（約 2 分鐘，~5 萬 tokens）或 標準（約 10-15 分鐘，~20 萬 tokens，附書面報告）。 快速通常就足夠了。說跳過我就直接開始建構——如果你有特定想找的東西，也告訴我。
快速是預設選項。 如果使用者說「好」但沒有選擇，就執行快速掃描。掃描本來就是迭代的：快速掃描成本低，能告訴你是否需要深入，而它的結果也指引了標準掃描該搜尋什麼。直接深入會花費 tokens 去詳述一個輪廓早已明顯的市場。
如果使用者提到了特定的東西（例如「檢查歐洲有沒有人在做這個」、「我關心它是否是開源的」），就把這個作為額外的重點納入——但要維持標準結構，不要讓一個請求窄化了整個掃描。
| 模式 | 預算 | 輸出 |
|---|---|---|
| 快速（預設） | 4-6 次查詢，2-3 次驗證，約 2 分鐘 | 對話摘要，不產出檔案 |
| 標準 | 8-12 次查詢，6-8 次驗證，一次抱怨挖掘，約 10-15 分鐘 | 書面報告 + 簡短的對話摘要 |
第一步 — 搜尋前先撰寫掃描規格
糟糕的掃描來自於搜尋使用者的產品名稱，而不是他們的問題。先用五句話濃縮這個想法並展示給使用者，以便他們可以修正：
IDEA（想法）: 一句話，白話文
JOB（任務）: 使用者的使用者僱用這個東西來完成什麼工作
WHO（目標族群）: 誰有這個問題
MECHANISM（機制）: 方法論——技術、物理或服務上的方法
WEDGE（槓桿）: 使用者認為自己擁有的限制條件或洞察
WEDGE（槓桿）最重要——你要最努力檢查這個。待辦事項 App 很擁擠；而「一個會讀取你的行事曆並拒絕讓你超量的待辦事項 App」可能就沒有。如果使用者沒有說明他們的槓桿是什麼，請直接說出來。缺少槓桿本身就是一個在開始建構前值得提出的發現。
第二步 — 跨越命名鴻溝進行搜尋
最大的失敗模式是只搜尋一個詞組，找不到東西，就宣布這個領域是空的。做同樣事情的產品很少使用相同的詞彙。在搜尋之前，先用四種不同的角度產生查詢：
- 使用者的用語——他們如何描述這個東西
- 業界的用語——這個領域的廠商會把什麼放在定價頁或軟體包中
- 使用者的使用者的用語——一個沮喪的人在半夜會如何搜尋這個問題
- 相鄰類別——這個東西可能成為其功能或變體的既有類別
然後搜尋與正在建構的東西類型相匹配的平台——軟體、實體產品、品牌或服務，存在於不同的地方。references/search-playbook.md 包含按產品類型劃分的完整地圖、查詢模式，以及如何挖掘抱怨和分銷信號。
兩個維持結果誠實的規則：
- 空的結果代表查詢不佳，除非證明並非如此。 在寫下「沒有直接競爭者」之前，至少再用兩個不同的角度和一個不同的平台搜尋一次。完全空白的領域確實存在，但很罕見。錯誤地聲稱一個領域是空的，是這個技能可能犯下的最糟糕錯誤。
- 列出之前先驗證。 打開網頁、列表或儲存庫。永遠不要只憑搜尋摘要就列出東西——被遺棄的專案、更名過的產品、AI 生成的列表文章，在摘要中看起來都很真實。在能看到的地方，註明最後一次提交、最後一次發布或「上次更新」的時間。
沒有網路存取權限？請遵循 references/no-search-fallback.md——即使只靠模型的知識，仍然可以進行有用的掃描，但必須標記為「未經驗證」，並在結尾處提供使用者應該自行搜尋的查詢。
第三步 — 將結果分為四個命名群組
使用這些名稱，不要用數字——編號的層級在缺少一個時會留下明顯的空缺，而空缺看起來像是資料遺失。
- 直接命中——相同任務、相同使用者、可比較的機制
- 相鄰方案——相同任務/不同使用者，或相同機制/不同任務。大多數差異化創意的來源
- 組件——解決了部分問題的程式庫、API、服務、供應商、製造商。通常大部分的建構工作已經可用
- 墳場——被棄置的儲存庫、倒閉的公司、停產的產品、已棄用的功能。最被低估的群組：墳場告訴你失敗模式，有時也告訴你促成條件已經改變
每個群組都必須有狀態行，永遠。 以下擇一：
找到 3 個（然後列出條目）沒有找到——已搜尋，確實是空的此深度未搜尋——為了節省預算而跳過
一個默默省略未檢查項目的報告，會破壞這個技能所販售的唯一價值：它的輸出比非結構化的對話更值得信賴。永遠不要讓讀者猜測他們看到的到底是哪一種的「不存在」。
第四步 — 誠實地繪製重疊地圖
對於想法中的每個功能，標記已解決（指出是誰）、部分解決（指出限制）或有待開發。要具體——「Notion AI 可以摘要頁面，但無法作用於外部工具」是有用的訊息；「Notion 有點像」則不是。
第五步 — 根據證據找到差距，而非憑空想像
差距必須追溯到你實際讀到的東西：
- 直接命中項目的 1-3 星評論和支援討論串——人們因為什麼而流失
- 有許多反應的未解決問題或功能請求，特別是長期未答覆的
- 論壇和社群討論串中，有人要求這個東西卻得到不滿意的答案
- 定價——誰被價格排除在外，什麼功能被鎖在最高方案之後
- 覆蓋範圍的差距——某個平台、地區、語言、族群、合規制度
引用每個差距的來源。你推測的任何東西都必須放在一個獨立的假設清單中，並清楚標示。一個憑空想像的差距比沒有差距更糟，因為它看起來像是驗證。
真正的既有解決方案往往不是一個產品。 在斷定一個領域是空之前，先問人們今天在沒有任何工具的情況下是怎麼做的——一個群組聊天、一個試算表、一個 Instagram 帳號、一個 WhatsApp 廣播、門邊的一塊白板。那個變通方法才是你要擊敗的對象，而且通常更好的策略是整合進去而不是取代它。要求人們採用一個新的目的地，是這些想法默默失敗的最常見原因。
第六步 — 差異化方向，然後是結論
提供 3-5 個以定位而非功能來表述的方向——「針對不能離開建築物的資料，做在地優先的那個」、「整合到人們已經在用的群組聊天的那個」、「90% 的案例免費，團隊使用付費」。針對每個方向，說明背後的證據和大致的成本。
指出分銷在哪裡。對於這個規模的大多數想法，被找到比被建構更難——所以，如果你注意到現有玩家是如何獲得使用者的（目錄、市集、社群、合作夥伴、作為更大東西內部的功能），請說出來。這個觀察往往比功能分析更有價值。
然後得出一個結論，並附上理由（評分標準見 references/verdict-rubric.md）：
- 可以做——有真正的差距，或者現有玩家很弱勢、停滯不前或定價錯誤
- 做窄一點——通用版本已被佔據；某個特定切面還沒有
- 包裝一下——某個現有東西做了困難的部分；價值在於上層的封裝
- 分支或擴展——某個開源專案已經完成了大部分，並允許這麼做
- 使用現有方案——誠實地說，他們要的東西已經存在且運作良好；清楚地說一次，然後尊重他們的決定
- 重新框架——墳場顯示這個框架行不通；這是相鄰的另一個框架
永遠附上「什麼會改變我的看法」——使用者知道而你不知道的，那個足以翻轉結論的事情。他們的背景知識通常比掃描本身更有價值。
第七步 — 交付結果，然後把對話主導權還給使用者
快速掃描： 在對話中總結。除非被要求，否則不產出檔案。
標準掃描： 按照 assets/LANDSCAPE-template.md 撰寫報告，標註日期，列出搜尋過和未搜尋過的平台。將報告儲存為 LANDSCAPE.md 放在專案目錄下（或如果有的話，放在 docs/ 下）。然後給出簡短的對話摘要——最接近的現有產品、最明顯的差距、結論——並且不要重複報告內容。
然後將下一步行動以問題的形式提出，並等待回應。不要在未經要求的情況下產生規格、簡報或儀表板——重點是將方向盤交還給使用者，並提供更好的資訊，而不是產出更多文件。根據掃描中實際發生的情況，選擇兩到三個合適的選項：
- 「這次我跳過了 [某些平台]——要我檢查一下嗎？」
- 「想根據發現的結果，一起腦力激盪一下該建構什麼嗎？」
- 「想深入了解一下這些競爭者嗎？」
- 「需要我將發現寫成交接備忘錄，讓你可以用全新的對話繼續嗎？」
- 「你需要把這個展示給別人看嗎？我可以幫你準備好。」
- 「準備好要建構了嗎？我建議從 [能夠測試槓桿的最小東西] 開始。」
如果使用者只想建構，那就建構。掃描是為了服務建構，而不是最終交付物。
這個技能的成本如何，以及如何載入
不熟悉技能的使用者常擔心安裝這個技能會讓每次對話變得更貴。如果這個問題出現，值得清楚說明：
- 只有名稱和描述會永久留存在上下文中——大約 200 個 token，相當於一個段落。這就是安裝這個技能但在從未觸發的對話中，所有的成本。
- 這些指令（約 2,500 個 token）只有在技能觸發時才會載入。
- 參考檔案只有在掃描真正需要時才會載入。
- 掃描本身才是真正的成本：快速掃描約 5 萬 token，標準掃描約 15-30 萬 token。這就是為什麼模式選擇時會附上數字，而不是默默選擇。
參考檔案
references/search-playbook.md—— 按產品類型（軟體、實體、品牌、服務）劃分的平台、查詢模式、抱怨和分銷挖掘references/verdict-rubric.md—— 在「做 / 做窄 / 包裝 / 分支 / 使用 / 重新框架」之間選擇references/no-search-fallback.md—— 在沒有網路存取的情況下進行誠實掃描assets/LANDSCAPE-template.md—— 報告結構
需避免的失敗模式
- 清單式洗白。 「前十大 X 工具」頁面通常是聯盟行銷的 SEO 內容，經常列出已死亡或不相關的產品。把它們當作候選名稱的來源，但永遠不要當作證據。
- 大名字充數。 將 Google、Amazon 或 Notion 列為利基想法的競爭者只是雜訊。只有在某個特定功能確實重疊時，才納入一個既有大廠。
- 默默地省略。 永遠不要將一個群組呈現為「不存在」，而事實上只是沒有搜尋。見第三步。
- 掃描範圍蔓延。 這是建構前的檢查。標準掃描進行二十分鐘後，就停下來並交付結果。
- 用數量嚇阻。 一長串競爭者名單會被解讀為「別費心了」，即使事實並非如此。先陳述差距和結論，而不是數量。
- 把過時的當作活的。 三年沒有動靜的東西是墳場，不是競爭者。標記清楚。
- 推薦轉向。 不要引導使用者去付費研究工具。把查詢語句給他們就好。