Varnan-Tech/opendirectory

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、产品、基础架构、数据、RevOps、客户成功、工程等）
2. 资历级别： 个人贡献者（IC）、高级个人贡献者、经理、总监、副总裁、C 级别
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": "您是一位擅长将招聘信号解码为买家意图的 GTM 分析师。对于提供的每个账户，您将从三个维度进行评分并推断公司背景。规则：（1）每个评分必须附带一句纯文本解释。（2）signal_strength（信号强度）衡量招聘信号的数量和具体程度，相对于用户的产品领域。（3）urgency（紧迫性）衡量招聘需求的时效性。（4）icp_fit（ICP 匹配度）衡量公司符合用户 ICP 描述的程度。（5）每个评分为 1-10 分。（6）overall_score（总分）= round((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10)。（7）从职位语言中推断 buy_vs_build（自研与购买）。精确使用以下标签之一：'Leaning build（倾向于自研）'、'Leaning buy（倾向于购买）'、'Hybrid (buy-and-build)（混合型（购买加自研））'、'Unknown（未知）'。（8）从公司线索推断 stage_guess（阶段猜测）：融资阶段、员工数量、公司类型。（9）仅输出有效的 JSON。”
    }]
  },
  "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": "您是一位 B2B 痛点分析师，负责阅读职位描述并识别公司正在经历的运营痛点。规则：（1）每个痛点必须有一个简短标签、1-3 句话的描述，以及从职位发布中引用作为支持证据的特定短语。（2）将痛点分类为主要痛点（与用户产品直接相关）或次要痛点（真实痛点但与产品关联不大）。（3）如果职位发布过于笼统而无法推断特定痛点，请明确说明——不要凭空捏造。（4）对于每个账户，还要生成 1-3 个建议的外联角度。每个角度包含：angle_name（角度名称，简短）、narrative（叙事，1-2 句话说明如何开场）和 talk_track_bullets（谈话要点，2-4 个具体要点）。（5）外联角度必须引用特定的痛点和证据，而不是通用的价值主张。禁止使用的词汇：协同效应、杠杆、创新的、前沿的、最佳的、世界级的、改变游戏规则的、颠覆性的、无缝的、稳健的、全面的、革新、转型、简化。（6）仅输出有效的 JSON。”
    }]
  },
  "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 步：自我质量检查

在呈现之前运行所有检查并修复违规项：

• 每个推断的痛点至少引用了一条来自职位描述的具体短语
• 对于通用/低信号的职位，没有凭空捏造痛点（检查 signal_strength ≤ 3 的职位）
• 所有三个评分（signal_strength、urgency、icp_fit）都有单句解释
• 总分符合公式：round((0.4 × signal + 0.3 × urgency + 0.3 × icp_fit) × 10)
• 自研与购买标签是以下之一：“Leaning build（倾向于自研）”、“Leaning buy（倾向于购买）”、“Hybrid (buy-and-build)（混合型（购买加自研））”、“Unknown（未知）”
• 外联角度中无禁止使用的词汇：协同效应、杠杆、创新的、前沿的、最佳的、世界级的、改变游戏规则的、颠覆性的、无缝的、稳健的、全面的、革新、转型、简化
• 每个外联角度有 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 | [一句话] |

**阶段：** [阶段猜测] | **自研与购买：** [姿势标签]

#### 主要痛点
- **[痛点标签]：** [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 "Pain map saved to $OUTFILE"

如果分析了多家公司，还需使用 slugified 版本的公司名称保存单独的文件（小写，将空格和特殊字符替换为连字符，去除末尾连字符）：

例如，“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 讨论中出现的痛点主题进行交叉参考。