warm-path-workspace

热路径交易工作区

将“这是一家公司，这是我们的 LinkedIn 联系人”转化为一个独立、可分享的 HTML 工作区，回答客户团队真正关心的两个问题：谁做决策，以及我们已经认识谁可以帮我们联系上他们。

大多数利益相关方图谱只回答第一个问题。交易能否成交，关键在第二个问题；但人们往往会弄虚作假——把每个联系人都直接连到买家，这就让实习生看起来和副总裁一样有价值。此技能会为每条路径评分，让负责人把最稀缺的资源（队友愿意帮忙引荐）用在真正能奏效的路径上。

构建内容

一个通过 Artifact 工具发布的 HTML 文件；每个客户对应一组标签页，客户多于一个时，顶部会显示客户切换器：

标签页	内容
概览	客户简介、员工人数与融资概览卡片、招聘信号图表、近期动态
利益相关方	按交易角色分组的买方群体；每张卡片都可打开侧边抽屉，查看活动详情、优先事项、谈话要点、异议、可直接复制的开场白、值得关注的帖子、职业时间线——每项说法都附有证据下拉项
关系图	你 → 热络联系人 → 具名中间人 → 决策者；根据路径强度设置颜色和线条粗细，并列出排名后的关系链
信号	按时间从近到远排列的招聘激增、工作变动、意向帖子、融资动态
行动方案	3-6 条优先行动，每条都注明背后的信号或路径

输入

只询问缺失的信息。

输入	必填	默认值
目标客户	是	-
LinkedIn 联系人导出文件	否，但这是此技能的核心用途	跳过热络路径，并说明原因
卖方公司 + 一句话产品介绍	否	根据上下文推断
交易阶段	否	“Prospecting”
深度	否	每个客户 6-8 位利益相关方

导出文件可以是纯 Connections.csv、已解压的 Basic_LinkedInDataExport_* 文件夹，或原始 .zip 文件，三种格式都可以。如果导出文件中包含 Profile.csv，系统会自动读取所有者姓名——文件里已有信息时，不要询问用户每个文件属于谁。请向用户确认检测到的姓名，因为把联系人归到错误的队友名下，会将引荐请求发给错误的人。

阶段 0 - 预检和隔离工作目录

创建一个按运行区分的工作目录，并将所有内容都放在其中：

WORK="$(mktemp -d -t wpw)"   # or <somewhere>/wpw-<account>-<timestamp>
mkdir -p "$WORK"

这件事的重要性超乎想象。两个运行共用临时路径时，会互相覆盖对方的 connections.json，而且不会显露任何错误：测试中，有一次运行短暂报告某位所有者在某客户处一个联系人都没有，但实际上他们有一万个联系人。跨所有者数据污染是此工具可能造成的最严重的数据损坏，因为负责人最终会向错误的队友请求引荐，而这个队友根本不认识对方。每次运行使用一个目录，始终如此。

接着检查 Crustdata 是否可访问，并用一行显示余额。此技能中的所有 Crustdata 调用都通过 Code Mode MCP（install.crustdata.com/mcp）运行：使用纯 JavaScript 的 execute({ code }) 脚本调用 await callTool(name, params)——每个脚本都以 // user query: ... 或 // model query: ... 注释开头，根据 r.ok 分支，并且只返回所需的精简投影（fields 是响应白名单：结果只包含你列出的分组）。预检调用为免费的 account_credits：

// model query: preflight - Crustdata reachable + credit balance
const r = await callTool("account_credits", {});
return r.ok ? r.data : { error: r.message };

阶段 1 - 账户简报（每个账户）

使用 company_identify（免费）解析公司——这是模糊匹配，一个标识符可能匹配多家公司，因此选择 confidence_score 最高的匹配项——然后使用 crustdata_company_ids 执行一次 company_enrich，并设置 exact_match: true 和 fields: ["basic_info", "headcount", "funding", "competitors", "people", "news", "hiring", "followers", "taxonomy"]（people 组包含决策者和 CXO 概览；列出你读取的每个分组）。然后执行两次 job_search：第一次设置 limit: 0，按 job_details.category 聚合分组以获取汇总数据；第二次设置 limit: 15，按 metadata.date_added 降序排序，获取重要职位。然后对公司执行 social_post_list_live（使用 company_domain；每条帖子消耗 1 个额度，因此请谨慎设置 limit——简报中约 10 条就足够）。

确认该账户是否仍是一家独立公司。 收购会改变预算归属，以及员工在个人资料中列出的品牌。近期交易应写入简报和别名列表。测试时发现 Confluent 在流程中途已成为 IBM 旗下公司，这改变了整个采购流程。

撰写一份 3-4 句的 brief：说明他们的业务、规模、正在发生的变化，以及为什么是现在。所有数字都要以刚刚获取的载荷为依据。

趁现在获取徽标。 basic_info.logo_permalink 会通过免费的 company_identify 调用（以及上面的 enrich）返回，不额外消耗额度。下载徽标，将其转换为 base64，并将其写入 account.logo_url，格式为 data:image/jpeg;base64,... URI——媒体 CDN 会以 binary/octet-stream 的形式提供这些文件，因此远程 <img src> 会显示空白。工作区会在标题栏和账户切换器中显示徽标；如果没有徽标，则会显示字母图标。

阶段 2 - 采购团队

以用户指定的联系人和阶段 1 的 people 组为起点，然后使用 person_search 进行发现，并按 experience.employment_details.current.company_id 和较高的 experience.employment_details.current.seniority_level 筛选，优先考虑你所销售产品对应的职能。先用 person_autocomplete 确认枚举值——枚举值错误会悄无声息地返回零行（资历级别词汇表是封闭集合：CXO、Vice President、Director、Experienced Manager、Strategic 等）。

然后进行第二轮搜索，关注技术栈所有权，而非职位头衔。 资历是权限的替代指标；真正重要的是谁掌管预算和工具。搜索职位或个人简介中提到自己负责相关系统（运营、平台、系统、赋能、工具、“GTM 系统”、“人才运营”等）的人。测试时，某个账户中最合适的买家是一位拥有 18 种工具和 500 万美元预算的高级经理，而仅搜索总监及以上级别的人完全漏掉了他。

筛选出 6-8 人。为他们分配初步的 deal_role 和 influence（1-5）。如果某人属于被收购的子品牌而非母公司，则设置 entity——这样，与该子品牌的联系就能直接匹配到此人。

收购相关信息往往藏着暖路径。 被收购公司的员工往往仍会列出原品牌，因此搜索“IBM”时，无法匹配到与“Red Hat”有关的联系人。通过网络搜索收购历史，并将完整别名列表写入 aliases.json：

{"IBM": ["ibm", "red hat", "hashicorp", "apptio", "nordcloud"]}

多词别名按短语匹配，单词别名按完整词元匹配，因此像“edge”这样的片段不会误匹配无关公司。留意真实的名称冲突——“Observe.AI”不是 Snowflake 收购的“Observe, Inc.”，两者都会出现。

阶段 3 - 深入了解利益相关者

每位利益相关者启动一个子 Agent，并在同一条消息中批量启动，使用 references/stakeholder-agent.md。不要将原始帖子转储到主上下文中。按照 references/dossier-schema.md 组装到 $WORK/<slug>/dossier.json。

每个人的照片（basic_profile.profile_picture_permalink）已包含在子 Agent 请求的 basic_profile 组中，无需额外付费。将其编码为 Base64，存入利益相关者的 photo_url， 与徽标遵循相同的 binary/octet-stream 规则。卡片和抽屉展示出来的会是真实的购买 小组，而不是一面姓名首字母墙。

阶段 4 - 人脉、候选名单和验证

python3 scripts/parse_connections.py --out "$WORK/connections.json" \
  --input "/path/Connections.csv" \
  --input "/path/Basic_LinkedInDataExport_2026.zip"     # append ':Name' to override the owner

向用户报告各负责人的总数。然后，**在将候选名单作为有效联系人路径呈现之前，先验证名单。**导出数据包含导出当天的雇主信息，之后会悄然过时——测试时有一位候选人已经离开了目标公司。使用 person_enrich（fields: ["basic_profile", "experience"]）抽查匹配行，并删除或标记已离职的人。

有两个盲点是结构性的，说明起来很简单，而且值得说明；不要只交付一张看似完整的图：

• 公司字段为空的人脉无法匹配任何别名，因此不可见
• 前员工不可见——导出数据只包含当前雇主，因此即使某人在目标公司工作了十年后刚刚离职，也不会出现，尽管他是理想的牵线人选

阶段 5 - 联系路径解析

阅读 references/chain-scoring.md 了解模型和诚信约束。联系路径分为三种，按优先级排列；构建器会自动检测前两种：

1. 零跳转 - 人脉本身就是购买小组成员。没有比这更好的路径，而且很容易漏掉，因为候选名单和购买小组由不同阶段构建。构建器先按 LinkedIn URL 匹配，再按姓名匹配；这一项无需额外操作。
2. 经日期验证的共同任职经历 - 人脉与某位利益相关者曾在同一家公司同期工作。这是证据最充分的桥接方式，但前提是任职日期确实重叠：测试中 13 条看似“我们都在 X 工作过”的关系，只有 3 条通过了日期检查——其余的人脉都是在目标离职后才加入。要启用此方式，请补充候选名单成员的工作经历，并写入 careers.json：

   {"https://www.linkedin.com/in/someone": [{"company": "Red Hat", "start": "2021-03", "end": "2023-08"}]}
   

   以 LinkedIn URL 或小写姓名为键。构建器会计算日期，并将时间不重叠的配对记录为已说明原因的死胡同，避免他人再次发现。
3. 组织层级桥接 - 其他所有情况。解析候选名单中各职能的高级负责人，每个（账户、职能）执行一次 person_search，而不是每位人脉执行一次，并写入 intermediaries.json：

   {"Acme": {"Engineering": [{"name": "...", "title": "VP, Platform Engineering",
                              "linkedin_url": "...",
                              "basis": "most senior Engineering leader at Acme (person_search, seniority=VP)"}]}}
   

   始终在 basis 中填写发现此人的方式和其符合条件的原因。数据中没有汇报关系，因此不要将 basis 表述为已确认的经理关系。

阶段 6 - 信号与行动方案

根据招聘激增、子 Agent 发现的购买信号、职位变动、融资和近期新闻组装 signals[]，按时间从新到旧排列并标明严重程度。然后编写 3-6 条 plays[]，指出人脉、中间人和决策者，并引用表明当下正是行动时机的信号。“联系团队”不算行动方案。

阶段 7 - 构建并发布

python3 scripts/build_workspace.py \
  --dossier "Acme=$WORK/acme/dossier.json" \
  --dossier "Globex=$WORK/globex/dossier.json" \
  --connections "$WORK/connections.json" \
  --aliases "$WORK/aliases.json" \
  --intermediaries "$WORK/intermediaries.json" \
  --careers "$WORK/careers.json" \
  --template assets/workspace-template.html \
  --title "Acme + Globex Deal Workspaces" \
  --out "$WORK/workspace.html"

构建器会完成所有确定性工作：将联系人与账户匹配、检测零跳转和共享历史路径、为每条链评分并排序、接入中间联系人、记录死胡同，并注入数据。发布前，请检查它打印的摘要——高意向联系人数量、强关系数量、零跳转、已验证的前同事、具名组织层级。

然后发布它。先加载 artifact-design 技能（首次调用 Artifact 前必须执行），然后调用 Artifact，并设置 file_path = $WORK/workspace.html、一个稳定的标题、一句描述和一个 favicon。Artifact 才是交付成果；把工作区留在磁盘上对任何人都没有帮助。使用相同文件路径重新发布会部署到同一个 URL，因此迭代成本很低。

报告关键数据：已映射的利益相关者数量、已分析的帖子数量、暖关系链数量及其中强关系链的数量、零跳转路径、信号、行动方案。

阶段 8 - 迭代

常见的后续操作：添加队友的导出数据并重新构建，添加或重新运行利益相关者，修改交易角色，扩大采购群体。每项操作都会编辑输入并重新运行阶段 7，发布到同一个 URL。

值得坚守的准则

绝不捏造，并让产出本身证明这一点。 每项陈述都必须附有证据，注明其来源载荷；没有证据支持的陈述应放入 gaps。证据下拉菜单是人们信任此页面的原因，一处言之凿凿的编造就足以让这一切付诸东流。

“没有强有力的人脉链”是成功，不是失败。 如果团队的人脉网络无法触达采购职能，就坦诚说明，并将该客户归为有温度的辅助式外向拓展对象。把四条薄弱的人脉链包装成突破口，只会浪费真实的社交资本。在测试中，无辅助运行和技能运行都独立地对同一客户得出了这一结论，这说明系统运作正常。

留意名称冲突。 公司名称并非唯一，个人也会重名。确保匹配的是正确实体后，再将其纳入分析；寻找人才招募人员时，应排除采购部门的“战略采购”职位。

所有可直接发送内容的行文规范。 开场白和谈话要点会被粘贴到真实邮件中：不要使用 em dash 或 en dash，公司名称中不要带法律实体后缀。

根据内容调整布局，绝不要让布局隐藏任何内容。 下方的品牌系统是固定的，布局则不是。如果真实内容放不下，例如公司或个人姓名很长、标题有 12 个词、利益相关者有 40 位，或人脉链数量超过图表可绘制的范围，就调整布局，而不是内容：让卡片增高，改为换行而非截断，改为单列，拓宽列，调高上限，或将宽内容放入独立的滚动容器。绝不要通过裁切卡片、用省略号截断姓名或悄悄删掉行来解决空间问题。如果确实无法避免设置上限，就在 UI 中注明（“显示最强的 18 条路径，共 34 条”），让读者知道自己看不到哪些内容。查看渲染后的页面（第 7 阶段的自检），并在交付前修复所有被截断的内容。

渲染产物中的 Crustdata 品牌标识。 随附的工作区模板采用了真实的 Crustdata 品牌系统，编辑模板时请保留，绝不要移除：

• 字标：此技能的 assets/ 中提供了官方的一组字标文件：crustdata-logo-light.png（深色文字，适用于浅色背景）和 crustdata-logo-dark.png（白色文字，适用于深色背景），与 app.crustdata.com 页眉中显示的文件相同。将适合主题的版本以内嵌 Base64 的方式嵌入，字标高度约为 17px，并链接至 crustdata.com；模板会同时显示两个版本，并通过 CSS 切换。绝不要热链 Logo，渲染产物无法获取远程图片。
• 颜色：将品牌紫色 #5547E2（产品的主色）用作强调色；将 #8387FF（产品本身的浅紫色）用作深色主题的强调色。
• 字体：产品字体 Geist，通过数据 URI 形式的 @font-face 嵌入，并以系统字体栈作为后备。
• 图标：Lucide，即仪表板使用的图标集，以 currentColor 描边的 SVG 内嵌（模板的 licon() 辅助函数中包含路径数据）。产物 UI 中不得使用表情符号。

此技能渲染的任何其他页面或文档（一次性摘要页面、导出的报告）也必须采用相同的品牌系统：将 assets/ 中的成对字标以内嵌 Base64 的方式放在“Powered by”眉题旁，并从 assets/workspace-template.html 复制 @font-face、强调色变量和 licon() 图标辅助函数。此要求有条件：聊天输出和数据文件不使用品牌标识，也不要仅为放置标识而渲染产物。

工具依赖

• Crustdata MCP server（install.crustdata.com/mcp）：一个 单一 Code Mode MCP，提供 list_tools、get_schema 和 execute。所有 Crustdata 数据 工具都通过 execute({ code }) 中的纯 JavaScript 脚本调用 await callTool(name, params)。编写时依据 get_schema 提供的类型化接口，但 不要在代码主体中添加类型注解。此处使用的工具：company_identify、 company_enrich、person_search、person_autocomplete、person_enrich、 person_contact_enrich、job_search、social_post_list_live、web_search_live（别名 research）、account_credits
• scripts/parse_connections.py 和 scripts/build_workspace.py 使用 Python 3（纯本地 处理，不调用网络）
• Artifact 工具，用于发布工作区 HTML

附带资源

• scripts/parse_connections.py - 规范化 LinkedIn 导出数据，根据 Profile.csv 自动检测所有者
• scripts/build_workspace.py - 基准匹配、零跳和共同历史检测、关系链评分、HTML 注入
• assets/workspace-template.html - 自包含的多账号工作区渲染器
• references/dossier-schema.md - 每个账号的档案规范；编写档案前请先阅读
• references/stakeholder-agent.md - 深度调查子 Agent 提示词；Phase 3 前请先阅读
• references/chain-scoring.md - 路径的评分方式及如何如实解析；Phase 5 前请先阅读