icp

说明

设置状态。 根据网站／案例研究证据，于 2026 年 6 月 8 日完成配置（路径 B — 未连接 CRM）。3 个细分市场：云原生 B2B SaaS 工程团队（100–1,000 名员工，B2B SaaS，以 AWS 为先，完成 B 轮融资后）、金融科技与支付基础设施（50–500 名员工，金融科技／支付，云原生，以合规为驱动）、数字媒体、流媒体与游戏（200–2,000 名员工，高流量消费级平台）。4 类角色：SRE／平台工程师（支持者）、工程副总裁／总监（经济决策者）、DevOps 负责人／基础设施主管（支持者／评估者）、工程 COO／CTO（经济决策者，金融科技细分市场）。下一步优化：连接 CRM，根据真实的赢单／输单数据进行验证。

此技能的用途

日常工作有两项：

1. 优化 — 提取实际赢单情况，找出当前 ICP 遗漏或夸大的模式，并提出优化建议，待用户批准后再保存。
2. 添加细分市场 — 当一种独立的销售模式已经形成时，在现有细分市场之外定义一个新的 ICP 细分市场。

首次发现流程位于 Setup — 如果状态检查提示需要，请加载该流程。

---

优化流程

第 1 步 — 加载并展示已定义的内容

提取当前细分市场、角色、目标市场和价值主张。每项用一到两行展示给用户，帮助他们回忆要优化的内容。询问：“有没有哪些具体内容感觉不太对？还是要我全面扫描近期交易？”

第 2 步 — 提取近期已结束的交易

从最近 6 个月的已赢单和已输单开始。检查是否已连接 CRM；如果已连接，提取交易阶段历史、关联公司、成交日期，以及已填写的赢／输原因。每页 20 条。

如果此期间已结束的交易超过 60 笔，则改用 swan-execute-code：将交易查询结果导出到文件并在那里汇总。不要将 200 条交易记录全部加载到上下文中。

如果未连接 CRM，请用户列出最近 5–10 笔已赢单和已输单；根据该列表开展工作。如果用户无法提供，则暂时无法进行优化；建议他们连接 CRM，或等有更多交易结束后再回来。

第 3 步 — 提取各交易关联公司的企业特征

先搜索 Swan 的公司记录。如果超过 20% 的记录缺少规模、行业或阶段信息，标记这一数据缺口 — 不要为了填补缺失信息而对所有记录进行数据补充。缺少这些数据会导致分析不完整；请明确说明。

第 4 步 — 找出模式

使用 swan-execute-code（或在交易数 ≤ 20 时手动分析），按以下维度对比赢单和输单：

• 行业 — 哪些行业的赢单比例较高？
• 员工人数区间（1-50、51-200、201-1000、1000+）— 哪个区间的赢单率最高？
• 融资阶段／公司阶段 — 同样的问题。
• 地区 — 同样的问题。
• 如果已填写赢／输原因，分别列出双方最常见的 5 个原因。

每个维度都打印一张简短的表格。不要粘贴原始交易数据。

第 5 步 — 提出优化建议

将上述模式与当前 ICP 进行比较，留意以下情况：

• 范围过宽 — 赢单集中在比细分市场所述范围更窄的区间。
• 范围过窄 — 赢单覆盖了所述区间之外的范围。
• 缺少排除条件 — 输单集中但赢单没有的维度（“我们总是在医疗保健行业输单 — 是否应该将其排除在目标范围外？”）。
• 新细分市场 — 一组赢单不符合任何现有细分市场。
• 角色偏移 — 赢单中的实际签署者／支持者与已保存的角色不符。

对每项建议的更改，用一行描述：“将规模区间收紧为 50-300（当前：50-1000）。赢单集中在 50-300，超过 500 的输单明显增加。”

提出 3–5 项更改建议。超过这个数量，说明 ICP 需要完整的发现流程 — 转到 Setup。

步骤 6 — 确认并保存

询问用户要应用哪些更改。对于每项确认的更改：

• 区隔边界更改 → 对现有区隔使用 swan-update-knowledge-segment。
• 新区隔 → 使用 swan-create-icp-segment。
• 新建或细化角色画像 → 使用 swan-create-knowledge-persona 或 swan-update-knowledge-persona。
• 用户在完善过程中提出的细化后价值主张 → 使用 swan-update-knowledge-value-prop。

确认已保存的内容。建议在下一批尚未评分的客户账户上运行评分，以验证此次完善。

---

优秀成果的标准

出色的完善过程：

• 首先发现矛盾。 最重要的输出，是实际赢单与既定 ICP 不一致之处。优先指出这一点。
• 指出被忽视的因素。 输单集中在当前 ICP 根本未提及的某个维度上——要揭示这个维度，而不只是报出数量。
• 以真实交易为依据。 每项拟议更改都要引用具体模式（“12 笔赢单中有 8 笔的规模低于 200，7 笔输单中有 5 笔的规模超过 500”）。没有证据支撑的观点不能纳入提案。
• 知道何时该停止。 如果数据表明当前 ICP 是正确的，恰当的结论就是“没有明显偏移，ICP 仍然成立”。为了显得有成果而凭空编造更改，是头号失败模式。
• 将角色画像视为 ICP 的一部分，而非独立工作。 赢单的签约人会在同一轮完善中影响角色画像；绝不要把角色画像推给其他技能处理。

应避免的失败模式：

• 因为数据噪声太大而提出 8 项更改。用户无法落实 8 项；挑出最重要的 3 项。
• 仅凭一个背离预期的季度就建议全面重写。偏移应在多个细分数据中呈现规律。
• 保存前跳过回顾确认步骤。用户必须逐项批准每项更改。
• 把“用户说我们有新的 ICP”当作删除旧 ICP 的许可。销毁现有状态前先询问。

---

规则

• 必须以交易数据而非观点为每项拟议更改提供依据。引用具体模式。
• 拟议更改必须控制在 3–5 项。更大规模的调整应通过 Setup 进行。
• 保存前必须征得用户确认。
• 至少要有 10 笔已结束的交易可供查看，否则绝不进行完善。少于此数量时，信号都是噪声。
• 绝不自动保存。每项更改都须经用户批准。
• 绝不把角色画像视为独立技能——它们属于 /icp。

---

此技能将逐步扩展的细化子页面

随着组织的 GTM 方式不断成熟，逐步添加：

• SegmentDeepDive.md — 当组织有 2 个或更多采用明显不同运作方式的区隔时，记录各区隔的完善手册（该区隔最重要的维度、哪些输单属于噪声）。
• PersonaSharpening.md — 当角色画像工作从职位和职责扩展到职业阶段信号、行为信号和排除条件时（原先 ideal-buyer-profile 涵盖的范围）。
• Drift.md — 组织积累 4 个或更多季度的历史数据后，加入偏移报告流程（在适当时从 icp-evolution 合并而来）。
• SegmentBirth.md — 当一组赢单与其他赢单存在明显差异时，创建新区隔的流程。