LinkedIn 職缺到買方痛點地圖
分析 LinkedIn 職缺，將其解碼為結構化的買方痛點地圖，包含分數、痛點與聯繫角度。
關鍵規則： 每一項推斷的痛點都必須引用職缺描述中支持該痛點的具體措辭。絕對不可憑空捏造未在文字中證實的痛點。如果職缺過於籠統而無法推斷痛點，請明確說明，並給予低訊號強度分數。
道德規則： 請勿推斷候選人的個人屬性或受保護特徵。嚴格專注於公司層級的營運痛點與組織需求。
步驟 1：設定檢查
確認必要的環境變數：
echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+set}"
若缺少 GEMINI_API_KEY： 停止。告知使用者：「需要設定 GEMINI_API_KEY。請前往 aistudio.google.com 取得，並將其加入您的 .env 檔案。」
步驟 2：收集輸入
此技能需要 3 個必要輸入。請在繼續之前收集它們。
2a：產品簡介
詢問：「請用 2-5 句話描述您的產品。您做什麼、您的核心價值主張是什麼、以及您鎖定哪些對象？」
如果使用者已在提示中提供此資訊： 將其提取出來。確認：「產品簡介已擷取：[摘要]。」
2b：理想客戶檔案 (ICP) 描述
詢問：「請用 2-6 個要點描述您的理想客戶檔案：產業、公司規模、您銷售的對象職位、技術堆疊線索。」
如果使用者已在提示中提供此資訊： 將其提取出來。確認：「ICP 已擷取：[摘要]。」
2c：招聘職缺
詢問：「請貼上您想分析的職缺描述。對於每個職缺，請包含公司名稱、職稱以及完整的描述文字。您可以貼上 1-15 個職缺。」
接受的格式：
- 原始貼上的文字，清楚標明公司名稱與職稱
- 結構化的 JSON 物件，包含欄位：
company_name、job_title、location（選填）、seniority（選填）、team_or_function（選填）、job_description_text、job_url（選填） - 使用明確分隔線（--- 或數字）分隔的多個職缺
若缺少任何欄位： 從描述文字中盡可能推斷。如果缺少 company_name 或 job_description_text，請在繼續之前要求提供。
2d：選用輸入
如果使用者提供以下任何項目，請將其擷取：
account_notes：每個公司的額外背景資訊（資金狀況、技術堆疊、已知工具、聯絡人）focus_dimension：「pipeline」（偏向計分與優先排序）、「positioning」（偏向訊息角度）或「both」（預設）
步驟 3：提取訊號
對於每個職缺，解析並提取：
- 團隊 / 功能： 此職位屬於哪個團隊？（GTM、產品、基礎架構、數據、RevOps、客戶成功、工程等）
- 資深程度： 個人貢獻者、資深個人貢獻者、經理、總監、副總裁、C 級
- 職責重點： 分類主要模式：
- 滅火："stabilize"、"fix"、"reduce downtime"、"unblock"
- 新建："build from scratch"、"0→1"、"greenfield"、"design and implement"
- 優化："scale"、"optimize"、"improve efficiency"、"automate"
- 取代："replace legacy"、"migrate from"、"modernize"
- 需求語言： 注意表示意圖的關鍵字："first X hire"、"critical role"、"immediate"、"must have"
- 工具 / 堆疊線索： 提及與使用者產品領域重疊的特定工具、平台或技術類別
按公司分組。 若同一公司有多個職缺，將其訊號分組在一起。
說明：「已從 X 家公司共 Y 個職缺中提取訊號。」
步驟 4：使用 LLM 評分
閱讀 references/scoring-rubric.md 以獲得完整的評分模型。
建立 LLM 請求：
cat > /tmp/pain-map-score-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "You are a GTM analyst who specializes in decoding hiring signals into buyer intent. For each account provided, you will score three dimensions and infer company context. Rules: (1) Every score must include a one-sentence plain-text explanation. (2) signal_strength measures how many and how specific the hiring signals are relative to the user's product area. (3) urgency measures how time-sensitive the hiring need appears. (4) icp_fit measures how closely the company matches the user's ICP description. (5) Each score is 1-10. (6) overall_score = round((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10). (7) Infer buy_vs_build from job language. Use EXACTLY one of these labels: 'Leaning build', 'Leaning buy', 'Hybrid (buy-and-build)', 'Unknown'. (8) Infer stage_guess from company clues: funding stage, employee count, company type. (9) Output valid JSON only."
}]
},
"contents": [{
"parts": [{
"text": "SCORING_CONTEXT_HERE"
}]
}],
"generationConfig": {
"temperature": 0.2,
"maxOutputTokens": 4096
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/pain-map-score-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
將 SCORING_CONTEXT_HERE 替換為：
- 步驟 2 中的產品簡介與 ICP 描述
- 步驟 3 中每家公司的提取訊號
references/scoring-rubric.md中的評分規則- 指示輸出 JSON，包含：
company_name、headline、overall_score、score_breakdown（signal_strength、urgency、icp_fit — 各含分數與說明）、stage_guess、buy_vs_build_guess
步驟 5：建立痛點地圖
對於每個帳戶，使用提取的訊號與 LLM 評分背景來建立買方痛點地圖。
cat > /tmp/pain-map-analysis-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "You are a B2B pain analyst who reads job descriptions and identifies the operational pains a company is experiencing. Rules: (1) Every pain must have a short label, a 1-3 sentence description, and specific phrases quoted from the job post as supporting evidence. (2) Classify pains as primary (directly relevant to the user's product) or secondary (real pain but tangential to the product). (3) If a post is too generic to infer specific pain, state that explicitly — do not hallucinate. (4) For each account, also generate 1-3 recommended outreach angles. Each angle has: angle_name (short), narrative (1-2 sentences on how to lead), and talk_track_bullets (2-4 concrete talking points). (5) Outreach angles must reference specific pains and evidence, not generic value props. No banned words: synergy, leverage, innovative, cutting-edge, best-in-class, world-class, game-changing, disruptive, seamless, robust, comprehensive, revolutionize, transform, streamline. (6) Output valid JSON only."
}]
},
"contents": [{
"parts": [{
"text": "ANALYSIS_CONTEXT_HERE"
}]
}],
"generationConfig": {
"temperature": 0.4,
"maxOutputTokens": 8192
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/pain-map-analysis-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
將 ANALYSIS_CONTEXT_HERE 替換為：
- 產品簡介與 ICP 描述
- 每家公司的職缺（完整文字）
- 步驟 4 中的分數與背景
- 提供的帳戶備註（若有）
- focus_dimension 偏好（pipeline / positioning / both）
- 指示輸出每個帳戶的：
buyer_pain_map（primary_pains、secondary_pains）和recommended_outreach_angles
閱讀 references/examples.md 以校準預期的輸出品質與深度。
步驟 6：建立交接物件
為每個帳戶產生一個結構化的交接區塊，讓 outreach-sequence-builder 可以直接使用：
handoff:
for_outreach_sequence_builder:
account_summary: 2-3 句關於公司狀況與招聘背景的摘要
key_pain: 一句話描述最可行的單一痛點
suggested_personas: 2-4 個最可能擁有此痛點的職位頭銜
tone: 一句話描述建議的聯繫語氣
交接內容必須具體到足以讓某人在不重新研究帳戶的情況下，將其貼入 outreach-sequence-builder 的提示中並獲得可用的序列。
步驟 7：自我品質檢查
在呈現之前，執行每一項檢查並修正違規：
- 每一項推斷的痛點至少引用一個來自職缺描述的具體詞句
- 對於過於籠統 / 低訊號的職缺（檢查訊號強度 ≤ 3 的職缺），未憑空捏造反痛點
- 所有三個分數（signal_strength、urgency、icp_fit）都有單句說明
- 總分符合公式：
round((0.4 × signal + 0.3 × urgency + 0.3 × icp_fit) × 10) - 自建 vs 購買標籤為以下之一：「Leaning build」、「Leaning buy」、「Hybrid (buy-and-build)」、「Unknown」
- 聯繫角度中沒有禁用詞：synergy、leverage、innovative、cutting-edge、best-in-class、world-class、game-changing、disruptive、seamless、robust、comprehensive、revolutionize、transform、streamline
- 每個聯繫角度有 2-4 個談話重點，而非通用的價值陳述
- 不符合 ICP 的帳戶已標記，並附有明確的降級建議
- 交接物件完整，包含所有 4 個欄位（account_summary、key_pain、suggested_personas、tone）
- 未推斷關於候選人的個人屬性或受保護特徵
- 當同一公司有多個職缺時，已按公司分組
在呈現之前修正任何違規。
步驟 8：輸出與儲存
人類可讀輸出
以此格式呈現完整分析：
## 買方痛點地圖 — [YYYY-MM-DD]
**產品：** [產品簡介中的產品名稱]
**分析的職缺：** Y 家公司的 X 個職缺
**重點：** [pipeline / positioning / both]
---
### [公司名稱] — 分數：[N]/100
**標題：** [招聘所揭示內容的一行摘要]
| 維度 | 分數 | 說明 |
|-----------|-------|-------------|
| 訊號強度 | N/10 | [一句話] |
| 急迫性 | N/10 | [一句話] |
| ICP 契合度 | N/10 | [一句話] |
**階段：** [推斷的階段] | **自建 vs 購買：** [姿態標籤]
#### 主要痛點
- **[痛點標籤]：** [1-3 句描述]
- 證據：「[從職缺引用詞句]」
#### 次要痛點
- **[痛點標籤]：** [1-3 句描述]
- 證據：「[從職缺引用詞句]」
#### 建議的聯繫角度
1. **[角度名稱]：** [敘述]
- [要點 1]
- [要點 2]
- [要點 3]
#### 交接 → outreach-sequence-builder
> **摘要：** [2-3 句]
> **關鍵痛點：** [一句話]
> **建議人物誌：** [列表]
> **語氣：** [一句話]
---
[根據 overall_score 降序排列，為每個公司重複]
儲存至檔案
mkdir -p docs/pain-maps
OUTFILE="docs/pain-maps/$(date +%Y-%m-%d).md"
cat > "$OUTFILE" << 'EOF'
REPORT_CONTENT_HERE
EOF
echo "痛點地圖已儲存至 $OUTFILE"
如果分析多個公司，也使用 slug 化的公司名稱儲存個別檔案（小寫，將空格和特殊字元替換為連字號，移除結尾連字號）：
例如：「ACME, Inc.」→ acme-inc.md，「CoolStartup Inc」→ coolstartup-inc.md
SLUG=$(echo "COMPANY_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/-$//')
cat > "docs/pain-maps/${SLUG}.md" << 'EOF'
INDIVIDUAL_ACCOUNT_CONTENT_HERE
EOF
何時使用
- 您有 1-15 個貼上的職缺描述，並想知道每家公司正在經歷哪些痛點
- 您正在規劃基於帳戶的客戶開發，並需要在撰寫序列之前進行結構化的痛點分析
- 您希望優先處理哪些產生招聘訊號的帳戶
- 產品行銷經理想要從職缺中取得真實世界的痛點語言，以優化產品定位
何時不使用
- 您需要尋找正在招聘的公司（請改用
linkedin-hiring-intent-scanner或yc-intent-radar-skill） - 您需要撰寫客戶開發訊息（請改用
outreach-sequence-builder— 將此技能的交接結果餵給它） - 您想要監控某個平台的隨時間變化的訊號（請改用
reddit-icp-monitor或twitter-GTM-find-skill） - 您需要聯絡資訊或郵件豐富化（此技能不提供此功能）
良好搭配
- outreach-sequence-builder：在建構序列時，直接將
handoff.for_outreach_sequence_builder區塊作為背景資訊傳入。 - noise-to-linkedin-carousel：將主要痛點與證據引用作為關於買方問題的輪播素材。
- reddit-icp-monitor：將職缺中的痛點主題與 Reddit 討論中出現的痛點主題進行交叉比對。