linkedin-job-post-to-buyer-pain-map

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 步：提取信号

针对每条招聘信息，解析并提取：

1. 团队 / 职能： 该职位属于哪个团队？（GTM、Product、Infra、Data、RevOps、CS、Engineering 等）
2. 资历级别： IC、Senior IC、Manager、Director、VP、C-level
3. 职责重点： 对主要工作模式进行分类：
   • 救火： "稳定"、"修复"、"减少停机时间"、"解除阻碍"
   • 从头构建： "从头开始构建"、"0→1"、"全新领域"、"设计并实施"
   • 优化： "扩展"、"优化"、"提高效率"、"自动化"
   • 替换： "替换旧系统"、"从……迁移"、"现代化改造"
4. 需求措辞： 记录体现意向的关键词："首位 X 岗位招聘"、"关键职位"、"立即"、"必须具备"
5. 工具 / 技术栈线索： 任何与用户产品领域重叠的特定工具、平台或技术类别

按公司分组。 如果多条招聘信息来自同一家公司，请将其信号合并分组。

说明："已从 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 — 每项均包含 score 和 explanation）、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 sentence recap of the company's situation and hiring context
    key_pain: The single most actionable pain in one sentence
    suggested_personas: 2-4 job titles of the people most likely to own this pain
    tone: One sentence describing the recommended outreach tone

交接内容必须足够具体，让他人可以将其粘贴到 outreach-sequence-builder 的提示词中，无需重新研究该账户，就能生成可用的序列。

---

第 7 步：自检

运行所有检查，并在提交前修复违规项：

• 每个推断出的痛点都引用至少一处招聘描述中的具体措辞
• 对于信号较弱或通用的招聘信息，不得臆造痛点（检查 signal_strength ≤ 3 的招聘信息）
• 三项分数（signal_strength、urgency、icp_fit）都附有一句话说明
• 总分符合公式：round((0.4 × signal + 0.3 × urgency + 0.3 × icp_fit) × 10)
• Buy-vs-build 标签必须是以下之一："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 步：输出并保存

面向读者的输出

按以下格式呈现完整分析：

## Buyer Pain Map — [YYYY-MM-DD]

**Product:** [product name from brief]
**Posts analyzed:** X posts across Y companies
**Focus:** [pipeline / positioning / both]

---

### [Company Name] — Score: [N]/100

**Headline:** [one-line summary of what the hiring reveals]

| Dimension | Score | Explanation |
|-----------|-------|-------------|
| Signal Strength | N/10 | [one sentence] |
| Urgency | N/10 | [one sentence] |
| ICP Fit | N/10 | [one sentence] |

**Stage:** [stage guess] | **Buy-vs-Build:** [posture label]

#### Primary Pains
- **[Pain label]:** [1-3 sentence description]
  - Evidence: "[quoted phrase from job post]"

#### Secondary Pains
- **[Pain label]:** [1-3 sentence description]
  - Evidence: "[quoted phrase from job post]"

#### Recommended Outreach Angles
1. **[Angle name]:** [narrative]
   - [bullet 1]
   - [bullet 2]
   - [bullet 3]

#### Handoff → outreach-sequence-builder
> **Summary:** [2-3 sentences]
> **Key pain:** [one sentence]
> **Suggested personas:** [list]
> **Tone:** [one sentence]

---

[repeat for each company, ordered by overall_score descending]

保存到文件

mkdir -p docs/pain-maps
OUTFILE="docs/pain-maps/$(date +%Y-%m-%d).md"
cat > "$OUTFILE" << 'EOF'
REPORT_CONTENT_HERE
EOF
echo "Pain map saved to $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 份粘贴的职位描述，想了解各家公司面临的痛点
• 你正在规划基于账户的外联，需要在编写序列前进行结构化痛点分析
• 你想确定优先跟进哪些招聘信号账户
• PMM 想从招聘信息中提取真实的痛点措辞，以改进定位

不适用场景

• 你需要查找正在招聘的公司（请改用 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 讨论中出现的痛点主题进行交叉比对。