Lead Signal Scout
將產品 URL 轉化為一個短名單，其中每一筆記錄都對應到代理實際開啟、閱讀並標註日期的頁面，並且屬於真正可能購買的人。未經驗證、過時或不夠格的受眾永遠不會進入短名單。
六道閘門是強制性的。跳過任何一道即視為本次執行無效；請直接說明，而不是送出有缺陷的輸出。
- 需求收集（步驟 1）- 在簡報能排除弱匹配之前，不要進行研究。
- 驗證（步驟 4）- 對於尚未擷取頁面的受眾，不要撰寫其記錄。
- 篩選（步驟 4）- 不要直接放棄一個有結果的查詢，至少應開啟其中一個結果並記錄原因。
- 時效性（步驟 5）- 不要將未標註日期或超過截止日期的訊號加入短名單。
- 資格評估（步驟 6）- 對於沒有自身已證明的問題、無購買能力、無可用聯絡方式，或在公司主導模式中無法識別公司的受眾，不要加入短名單。
- 審計（步驟 8）- 在
validate_run.py回傳 PASS 之前，不應呈現任何結果。
所有散文欄位皆需參照 references/writing-rules.md 撰寫。一封看起來像是自動生成的報告，無論背後的研究有多深入，都會被忽略。
工作流程
1. 需求收集
閱讀 references/intake.md。建立產品簡報，然後以單一封裝訊息一次性詢問使用者四個登陸頁面無法提供的資訊：地理位置、價格區間與購買動機、排除條件，以及任何現有客戶或過往成交資料。若使用者未回答，則帶入標記的假設繼續進行。
記錄 icp.price_band_source 為 user 或 assumed。這很重要：**你自己發明的價格區間不應排除任何人。**若為 assumed，不要因價格因素將 commercial_fit 評分低於 3。一個未經確認的數字沒有資格決定哪些真實公司應被排除。
在此設定 max_age_days。預設為 120。當訊號來自招聘貼文或供應商搜尋時，請使用 60，因為四個月前的需求通常已經被滿足。
2. 設定模式與深度
模式決定優化目標。深度決定短名單數量。兩者彼此獨立。
| 模式 | 優化目標 | 權重（痛點 / 契合度 / 商業 / 時機 / 觸及 / 證據） |
|---|---|---|
discovery (預設) | 未滿足的痛點，產品市場契合前 | 28 / 22 / 10 / 14 / 13 / 13 |
pipeline | 銷售型企業可重複的線索流 | 22 / 20 / 20 / 14 / 12 / 12 |
design-partners | 可能測試並提供回饋的人 | 24 / 18 / 6 / 10 / 24 / 18 |
b2b | 具有當前業務觸發點的企業 | 14 / 20 / 26 / 18 / 11 / 11 |
community | 明確的公開請求與討論 | 28 / 18 / 8 / 14 / 22 / 10 |
b2b 和 pipeline 模式也會拒絕將無法識別其公司的受眾列入短名單。
| 深度 | 短名單上限 | 最少查詢數 | 最少開啟頁面數 | 最少儲藏桶 x 系列覆蓋數 |
|---|---|---|---|---|
quick | 5 | 10 | 12 | 4 儲藏桶 x 3 系列 |
standard (預設) | 10 | 18 | 20 | 5 儲藏桶 x 4 系列 |
deep | 20 | 35 | 35 | 7 儲藏桶 x 6 系列 |
查詢衡量的是打字量，頁面衡量的是閱讀量，而其中只有後者能真正找到客戶。請記錄 coverage.pages_opened 的數量，包括那些最終未能成為候選人的頁面。
將所選模式的設定檔完整複製到執行 JSON 中。審計器會根據該設定檔重新計算所有分數，並在宣告的權重偏離模式設定檔時判定為失敗。
3. 規劃並執行搜尋
閱讀 references/search-playbook.md。在搜尋前先撰寫查詢計劃：使用哪些儲藏桶、哪些來源系列、以受眾自身用語撰寫哪些片語。記錄每一個查詢及其結果數量，包括零結果的查詢。收集候選 URL；但此時還不要撰寫受眾記錄。
4. 先驗證，再撰寫
閱讀 references/verification.md。擷取每個候選 URL，然後決定：
signal_confirmed- 頁面已擷取，訊號存在於該頁面，且可歸因於指定的受眾。只有此類可被列入短名單。url_ok- 已擷取，但訊號有所保留、歸因是推測的，或缺少日期。屬於審查層級。unverified- 未擷取、連結失效或需要權限。加入dropped並附上原因，然後停止。不要對此撰寫記錄。
先編寫完整的受眾記錄再因為頁面 404 而捨棄它，會浪費大部分執行時間。先擷取，再撰寫。
**開啟你將要放棄的頁面。**任何查詢若出現三個或以上結果卻沒有任何一個被保留，需要在該覆蓋條目上附加 note，並在開啟其中一個結果後撰寫。審計器會對大多數被放棄的查詢沒有附註的執行判定為失敗。
這一步驟決定了誰會進入短名單，而且除非你寫下來，否則它是看不見的。一次記錄了 16 個查詢並滿足所有覆蓋門檻的執行，可能實際上浮現了 75 個結果、開啟了 10 個，並將其整個短名單來自三個類似公告的查詢，而一篇競爭者評論和三個已發布的 RFP 頁面卻未被閱讀。審計行會稱這種情況為完整覆蓋。驗證聯絡方式以及來源；verification.md 涵蓋了需要記錄的內容。
研究限制：僅限於公開的專業和商業資訊；不得繞過登入、付費牆、存取控制、速率限制或機器人限制；不得使用資料經紀商、洩漏的資料集、私人群組、個人電子郵件發現或電話增強服務；絕不能推斷或針對受保護特徵、健康狀況、財務困難、政治立場、宗教或性取向。
5. 為每個訊號標註日期
時機分數是根據年齡計算的，因此未標註日期的訊號不能被列入短名單。依序檢查此清單，並在找到答案時停止：可見的發布日期、頁面上轉換為 signal_age_days 的相對時間戳記，或 URL 中編碼的時間戳記。記錄你使用的是哪一種於 date_basis 中。verification.md 提供了每種方式的方法。
絕不要估計年齡。部分日期如 2026-08 會被拒絕，未來日期也是如此。一個基於猜測日期的短名單條目正是此技能旨在預防的確切失敗。
為每個確認的受眾記錄 fetched_at 和 final_url。審計器無法親眼看到你擷取頁面；這些欄位使得一個未經支持的聲明需要花費更多工夫才能立論。
6. 評分、門檻檢查與去重
閱讀 references/scoring.md。依據撰寫的錨點，對六個維度進行 0-5 的評分。時機分數來自年齡，按區間設定上限；若有命名的當前觸發點，則上限提高一分。
pain_strength 評分的是受眾自身的問題，並且是在該產品所執行的任務中，以他們自己的話語表述的。他們客戶的問題、他們銷售解決方案的問題，或他們評論的市場趨勢，這些都評為 0 分。每個消費品牌都會發起行銷活動；那不是一個訊號。
commercial_fit 問的是這個賣家是否能透過其擁有的銷售動機來成交這個買家。而不是這家公司規模有多大。數十億美元營收、遍佈一百個國家並擁有公開的供應商入口網站是存在採購流程的證據，對於一個自助服務或創始人主導的賣家來說，這只能評為 2 分，而不是 4 分。
任何低於 50 分的項目直接丟棄。以下情況則歸入審查層級：未標註日期、超過 max_age_days 且缺少三個 still_open 欄位、pain_strength 為 0 或 1 且無命名的 trigger、commercial_fit 為 0 或 1 且與使用者提供的區間不符、唯一的聯絡方式是 inappropriate，或在 b2b 或 pipeline 模式下公司未識別。沒有任何記錄會被刪除；審查層級會顯示每個項目及其原因。
記錄 signal_type 和 purchase_readiness，而不是單一的意圖標籤。正在招聘設計師的人有真實的意圖，但沒有購買軟體的意圖。這兩個標籤有其上限，與其下的維度相關聯：hiring 不能超過 adjacent，基於痛點的訊號需要 pain_strength 為 3 才能達到 strong，strong 需要 commercial_fit 為 3，而 direct 則需要 4。審計器會強制執行所有這些，因為自由文字欄位一起向上漂移正是產品發布公告變成高意圖買家的方式。
一個為自由工作者、承包商或員工刊登的廣告頁面是 hiring，無論該工作與產品有多麼匹配。他們是在選擇一個人，而不是一項服務，而 hiring 會將購買準備度上限限制在 adjacent。將一則工作廣告歸類為 direct_request 就會繞過這個上限，這正是為何一個十五美元時薪的自由接案簡報曾經登上短名單頂端的原因。關鍵在於該路線要求的內容：作品集、履歷、簡歷或報價單意味著招聘；而範圍、價格、週轉時間或試用則意味著購買。
根據 dedupe_key 進行去重。從同一輸出目錄中先前執行的 ledger.json 載入資料，排除已出現過的項目，以及使用者排除清單上的所有項目。
保持短名單的來源多樣性：來自同一來源系列或同一網域的比例不得超過一半。否則，那個最可靠能擷取到頁面的網站將會主導整個執行，而單一來源的短名單也會繼承該網站的偏見。
如果短名單中有超過 60% 的項目得分為 80+，則表示評分錨點應用過於寬鬆。請重新評分。
7. 記錄身份、位置與聯絡方式
分別記錄 company、person 和 handle。公司是潛在的購買者；個人是發文者；handle 是他們在平台上的使用者名稱。當無法識別公司時，將 company 設為 not identified，並將 handle 放入 handle 欄位，按照平台的書寫方式撰寫（例如 u/name）。在這種情況下，輸出會以 handle 為首。首先尋找公司資訊：發文者經常在討論串、個人資料或連結中提及公司名稱。
為每位受眾提供一個 channel_url：使用者實際開啟以進行聯絡的頁面。通常是來源討論串，有時是聯絡表單或個人資料。開啟它，並記錄 channel_evidence：一個簡短的引用或頁面上的標題，顯示該路線是為誰設計的。一個聲稱 channel_fit: valid 但沒有 channel_evidence 的短名單受眾將無法通過審計。
供應商和廠商註冊入口網站最多只能算是 questionable，它們是一個排隊流程，而不是一場對話。應徵者、媒體和客戶支援路線是 inappropriate。當你找到的第一條路線形狀不對時，再多花一次擷取來尋找正確的路線，然後再放棄該受眾；大型網站通常會將商業洽詢頁面隱藏起來，而將職涯頁面排在前面。
審計器讀取的是 channel_evidence，而不僅僅是 URL。Reddit 或 LinkedIn 上的一則工作廣告擁有完全正常的 URL，但只有在文字中才會暴露自己：「分享您的作品集和最新履歷」無論託管在哪裡，都是一條求職申請路線。
除非另一個頁面顯示了相同的訊號，否則請將 additional_source_urls 留空。它呈現為「Also seen at」，因此將聯絡頁面放在那裡會聲稱存在實際上不存在的佐證。
為每個入選的受眾草擬一封開場白，少於 90 個字，且僅以已擷取的頁面為依據。除非使用者在後續指令中另行授權，否則不要發送、提交、建立連線、追蹤、留言或寫入 CRM。
8. 建立輸出並進行審計
閱讀 references/output-schema.md，撰寫 run.json，然後執行：
python3 <skill-dir>/scripts/validate_run.py run.json
python3 <skill-dir>/scripts/build_outputs.py run.json outputs/
<skill-dir> 是此技能本身的目錄，也就是載入此 SKILL.md 的那個目錄。請根據該目錄建立絕對路徑。不要使用相對於工作目錄的路徑：工作目錄是使用者的專案，而不是此技能。如果宿主環境會替代 ${CLAUDE_SKILL_DIR}，那麼該變數即為此目錄。
修正每個 ERROR 並重新執行，直到程式輸出 PASS。在最終回覆中逐字報告審計行。build_outputs.py 會寫出 leads.csv（操作清單）、leads-full.csv（所有欄位）、report.html、brief.md 和一個更新後的 ledger.json。請將 run.json 與它們放在一起，作為資料的來源。
如果沒有 Python：請根據結構描述手動撰寫 brief.md 和 leads.csv，並手動執行審計器的檢查。
9. 報告
在回覆和 brief.md 中逐字回報審計行。如果執行通過，它不會出現在 report.html 中，因為一個綠色的「OK」橫幅並不是人們開啟受眾報告時想看到的東西。
接著是結論、最佳潛在客戶，以及產出檔案的絕對路徑。以已驗證且已標註日期的資訊為重點。讓缺口顯而易見。
品質標準
- 沒有已擷取來源的受眾不是受眾。沒有日期的受眾不是線索。無法購買的受眾是一場研究訪談。沒有陳述自身問題的受眾只是一個市場區隔。
- 已浮現但從未被打開的結果，才是本次執行真正的產出。請計算它們，並打開那些你正打算跳過的結果。
- 一次檢視了三十個候選人但最終沒有選入任何一個的執行，是一個有效的結果。請直接報告，而不是填塞內容。
- 十個經過驗證、具有時效性的匹配，勝過五十個泛泛的結果。
- 報告那些已被搜尋但一無所獲的項目，而不僅僅是那些找到的項目。
- 從來源進行個人化，而不是來自虛構。
- 將所有內容標記為假設。一個公開的訊號不代表同意、興趣或購買意圖。