icp-persona-builder

ICP 画像构建器

研究公司的买家群体，并构建详细的合成画像，以模拟其理想客户。这些画像会成为可重复使用的客户资产——构建完成后，任何技能都可以加载它们，从买家的角度评估内容、消息、网站或营销活动。

快速开始

Build ICP personas for [company]. Their site is [url].

已知 ICP 时：

Build personas for [company]. Their ICPs are: [ICP 1], [ICP 2], [ICP 3].

输入

输入	必需	来源
公司名称	是	用户提供
公司 URL	建议提供	有助于调研
已知 ICP	否	用户提供，或通过调研发现
客户背景文件	否	如有，则使用 clients/<client>/context.md

流程

阶段 1：公司调研

了解公司所做的业务以及服务对象：

1. 使用 WebFetch 获取其网站内容——首页、产品／解决方案页面、定价页面、“适用对象”页面
2. 使用 WebSearch 搜索：
   • “[company] customers”／“[company] case studies”
   • “[company] reviews”（G2、Capterra、TrustRadius）
   • “[company] vs”（对比搜索可揭示买家群体）
   • “[company] jobs”（公司正在招聘哪些岗位来销售产品／提供支持）
3. 提取信号：
   • 他们解决什么问题？
   • 定价／套餐如何？（可反映 ACV 和买家类型）
   • 他们服务哪些行业／垂直领域？
   • 目标公司规模是什么？
   • 案例研究和客户评价中出现了哪些职位／头衔？
   • 他们采用什么市场进入方式？（自助式、销售主导式、混合式）

阶段 2：识别 ICP 群体

根据调研结果，识别 4-6 个不同的买家群体。每个群体都应代表一种有实质差异的买家类型——角色、公司概况或购买动机各不相同。

为每个群体定义：

属性	说明
群体名称	简短标签（例如，“企业 IT 负责人”“初创公司创始人”“代理机构运营者”）
角色／职位	该群体的典型职位
公司概况	规模、阶段、行业、技术栈
核心痛点	驱使他们寻找解决方案的首要问题
购买触发因素	什么事件会促使他们现在开始搜索
决策标准	评估时最看重什么（按重要性排序）
成熟度	他们对问题领域和解决方案格局的了解程度
替代方案	他们还会考虑什么（竞争对手、自行开发、维持现状）
群体规模估计	粗略估计该群体对公司的重要程度（主要、次要、新兴）

群体多样性规则：

• 至少包含一位 技术型 买家（评估功能、架构、集成）
• 至少包含一位 业务型 买家（评估 ROI、成果、竞争优势）
• 至少包含一位 持怀疑态度 的人（曾有过不愉快经历，难以说服）
• 至少包含一位 初级人员／研究者（为决策者进行初步调研）
• 如果公司服务多个层级，尽量覆盖不同规模的公司

阶段 3：构建合成画像

为每个群体创建详细的合成画像。画像应让人觉得是一个真实、具体的人，而不是抽象的营销概念。

画像结构：

{
  "id": "persona-slug",
  "name": "Jordan Chen",
  "segment": "Enterprise IT Leader",
  "title": "VP of Engineering",
  "company": {
    "type": "Mid-market SaaS company",
    "size": "200-500 employees",
    "stage": "Series B, scaling fast",
    "industry": "Financial services technology"
  },
  "demographics": {
    "experience_years": 12,
    "reports_to": "CTO",
    "team_size": 35,
    "budget_authority": "$50K-200K without board approval"
  },
  "situation": "Jordan's team is growing faster than their tooling can support. They've been using a patchwork of internal scripts and are losing engineering hours to maintenance. The CTO has asked Jordan to evaluate modern solutions before next quarter's planning cycle.",
  "pain_points": [
    "Team productivity is dropping as they scale",
    "Current tools don't integrate well",
    "Onboarding new engineers takes too long"
  ],
  "buying_trigger": "CTO mandate to evaluate solutions before Q3 planning",
  "decision_criteria_ranked": [
    "Enterprise security and compliance (SOC2, SSO)",
    "Integration with existing stack (GitHub, Jira, Datadog)",
    "Scalability — will this work at 2x team size?",
    "Total cost of ownership, not just sticker price",
    "Implementation timeline — needs to be live in 6 weeks"
  ],
  "skepticism_profile": {
    "trust_level": "Low — has been burned by vendor promises before",
    "research_style": "Deep dive. Reads docs, checks GitHub issues, asks peers in Slack communities",
    "key_objections": [
      "Will this actually scale or will we outgrow it in a year?",
      "What's the real implementation cost beyond the license?",
      "How good is the support when things break at 2am?"
    ]
  },
  "technical_sophistication": "High — understands the technical landscape well, can evaluate architecture decisions, wants to see under the hood",
  "language": {
    "describes_problem_as": "We need to consolidate our toolchain and reduce operational overhead",
    "searches_for": ["engineering productivity platform", "developer tools consolidation", "[competitor] alternative enterprise"],
    "red_flag_words": ["revolutionary", "AI-powered", "seamless" — overpromising triggers skepticism],
    "trust_signals": ["SOC2 badge", "customer logos in their industry", "transparent pricing", "public changelog"]
  },
  "evaluation_behavior": {
    "first_visit": "Scans headline, checks if it's for their company size, looks for enterprise/security page",
    "deep_evaluation": "Reads docs, checks integrations list, looks for case studies from similar companies",
    "social_proof_needs": "Wants to see companies their size in their industry, not just FAANG logos",
    "deal_breakers": ["No SSO/SAML", "No self-hosted option", "Pricing only available via sales call"]
  }
}

阶段 4：保存画像资产

将以下可重复使用的资产保存到客户目录：

clients/<client>/personas/personas.json——机器可读文件，所有画像以数组形式存储：

{
  "company": "Acme Corp",
  "url": "https://acme.com",
  "created": "2026-02-26",
  "segment_count": 5,
  "personas": [ ... ]
}

clients/<client>/personas/personas.md——易于审阅和分享的 Markdown 文件，以文字形式详细描述所有画像。

clients/<client>/personas/segments.md——包含所有群体及其关键属性的汇总表，便于快速查阅。

输出摘要

完成后，请提供：

1. 细分群体概览表 — 一览所有细分群体及其关键属性
2. 用户画像摘要 — 用 2–3 句话概述每个用户画像
3. 覆盖范围检查 — 确认已满足多样性规则（技术、业务、持怀疑态度、研究人员）
4. 后续步骤 — 建议运行 icp-website-review 或其他可使用这些用户画像的技能

提示

• 研究深度很重要。 在第 1 阶段投入足够的时间。越了解公司的实际客户，用户画像就越真实。不要只看主页，还要深入查看评价、案例研究和招聘信息。
• 让用户画像具体明确。 “市场经理”太宽泛。“Sarah 是一家拥有 50 人的 B2B SaaS 初创公司的高级需求开发经理，刚因预算削减失去了她的 SDR 团队”能让你清楚地了解她会如何评估工具。
• 纳入语言维度。 用户描述问题的方式往往与供应商描述解决方案的方式截然不同。这个差距正是信息传达失效之处。
• 怀疑态度是最重要的特征。 每个用户画像都需要明确的怀疑点。什么会让他们不买？他们对供应商的默认看法是什么？
• 此技能没有代码脚本。 它由 Agent 使用 WebSearch 和 WebFetch 执行。上述结构化流程将指导研究和用户画像创建。

依赖项

• 网页搜索能力（用于公司和 ICP 研究）
• 网页抓取能力（用于读取网站页面）
• 无需 API 密钥或付费工具