buyer-persona-generator

ICP Persona Builder

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

快速开始

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	否	用户提供，或通过研究发现
客户背景文件	否	如有，使用任何现有的公司背景文件

流程

阶段 1：公司研究

了解公司做什么，以及服务哪些客户：

1. 使用 WebFetch 获取其网站内容 — 首页、产品/解决方案页面、定价页面、“适用对象”页面
2. 使用 WebSearch 搜索：
   • “[公司] 客户” / “[公司] 案例研究”
   • “[公司] 评价”（G2、Capterra、TrustRadius）
   • “[公司] 对比”（对比搜索可揭示买家细分群体）
   • “[公司] 职位”（他们在招聘哪些岗位来销售产品或提供支持）
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：保存角色画像资产

将其保存到客户目录，作为可重复使用的资产：

personas.json — 机器可读文件，以数组形式包含所有角色画像。保存到当前工作目录，或用户指定的位置：

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

personas.md — 面向阅读者的 Markdown 文件，以文字形式写出所有角色画像，便于审阅和分享。

segments.md — 汇总所有细分群体及其关键属性的表格，可用作快速参考。

输出摘要

构建完成后，呈现：

1. 细分群体概览表 — 一目了然地列出所有细分群体及其关键属性
2. 角色画像摘要 — 每个角色画像用 2-3 句话概括
3. 覆盖情况检查 — 确认已满足多样性规则（技术型、业务型、持怀疑态度者、研究者）
4. 后续步骤 — 建议运行 icp-website-audit 或其他可使用这些角色画像的技能

提示

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

依赖项

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