三周前一个做 B2B 出海服务的读者在微信上问我能不能用 Claude Code 批量给 LinkedIn 上的潜在客户发消息他说他们团队的目标客户有 1000 多个但手动一个个查看资料、写个性化开场白、点发送一天最多只能完 成 50 个而且质量还不稳定。后来我们一起花了一周时间用 Claude Code 和 Codex 搭了一条基于 MCP 工具的外展流水线并不是为了“自动狂发消息”而是把找人、验证匹配度、生成个性化内容、人工审核、发送记录这五个环节串起来。第一周只发了 120 条但回复率比之前手动群发高了一倍多。这个结果让我重新理解了这类自动化的价值它真正改善的不是发送数量而是把高重复、高决策密度的销售工作流变得可控、可复用、可审计。很多人看到 “1000s of LinkedIn outreach” 的第一反应是这不就是群发脚本吗如果从纯技术角度出发用 Python 加 Selenium 就能模拟点击用 Claude/Codex 写文案撑死再加一个 MCP 工具读表格似乎没有必要引入 30 个 MCP 工具。但实际落地时你会发现真正能长期使用的系统不是一锤子买卖的“发送脚本”而是一个集线索管理、信息验证、内容生成、人工审核、发送执行、效果追踪于一体的增强工作流。下面我拆开讲讲这套方案怎么搭为什么这样搭以及哪些边界是你必须提前知道的。1. 先搞清楚这套自动化真正要解决的是什么1.1 外展的真正难点不是发消息而是“决策密度”LinkedIn 外展看似简单无非是找到目标客户、发一条消息。但把它拆开你会发现每一步都需要做大量决策这位候选人是不是我们的目标画像他现在所在的公司和我们产品有没有交集他最近发过什么动态、参加过什么活动适合用什么切入点第一句话是提对方公司的新融资还是提他分享的一篇文章这段消息读起来像流水线群发还是像一个真正了解他的人写的这些决策如果全部靠人工500 条消息可能就要消耗一个人两周时间。如果全部交给 AI又会面临错误信息、幻觉、以及内容同质化的问题。传统脚本只能帮你把“发送”这一步自动化但对前面的信息收集和内容决策没有帮助。这也是我坚持用 Claude Code / Codex 而不是普通脚本的核心原因它们可以作为“决策代理”在每一步工具调用之间进行判断和生成。1.2 为什么选择 Claude Code / Codex而不是普通自动化工具Claude Code、Codex CLI 这类工具本质上是一个“能跑在终端里的智能体”。它们不只是执行预定义脚本而是可以读取你本地的文件、CSV、数据库通过 MCP 协议调用浏览器、表格、搜索、CRM 等外部工具根据工具返回的结果生成下一步动作或内容以代码或文本的形式输出结果供你检查或继续执行。这就解决了传统自动化脚本最尴尬的问题脚本无法理解语义。比如当代理打开一个 LinkedIn 个人主页时它能从“最近动态”里判断出对方在关注什么话题从而自动生成一句高度相关的话。传统脚本只能按照模板替换变量效果完全不同。1.3 为什么需要“约 30 个 MCP 工具”而不是一个全能工具MCP 的全称是 Model Context Protocol它给 AI 模型提供了一个标准化的“工具插槽”。你可以理解为模型不再需要为每个外部服务写一套专门的集成代码而是通过统一的协议去调用 MCP Server。对于 LinkedIn 外展这条流水线我粗略统计了一下至少需要覆盖这些能力浏览器自动化打开页面、读取内容、点击按钮线索领取从 CSV、Airtable、Notion 或 CRM 读取候选名单公司背景查询通过搜索引擎或公司官网了解目标公司最近动态个人信息验证查看候选人最新职位、工作年限、近期动态内容生成模型本身负责写个性化消息发送执行浏览器自动填写消息框并预览最终由人点击发送状态记录将每条线索的处理状态写回表格或数据库日志和监控记录每次调用的输入、输出、耗时和错误。每一种能力背后可能有多个工具。比如浏览器自动化有 Playwright MCP也有其他 Browser MCP数据存储有 SQLite MCP、Google Sheets MCP、Notion MCP如果还要对接公司内部 CRM、邮件系统、Slack 通知工具数量很容易超过 30 个。但这里有一个容易被误解的事工具数量本身不是目标。真正重要的是你要在同一个代理环境里把“找线索、分析、生成、审核、发送、记录”这条链路串起来。30 个工具只是这类复杂工作流的自然结果。2. 把 Claude Code 和 Codex 跑起来安装、配置和常见报错2.1 环境准备与初始化先说明一下我这里并不打算贴一份“官方安装教程”因为版本变化很快。你动手之前最好去对应项目的 README 或 CLI 帮助文档里确认最新方式但无论哪个版本下面这几个环节是绕不开的安装 Node.js并确认版本满足要求一般要求 LTS 或更高。通过 npm 全局安装 Claude Code 或 Codex CLI。登录账号或配置模型服务的 API Key。在终端输入claude或codex确认命令可以被识别。配置 MCP Server添加你想用的工具。如果你是 Windows 用户最容易在第一步就卡住。热搜里经常出现claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这通常是 npm 全局安装目录没有写入系统 PATH 导致的。解决方法是先执行npm install -g anthropic-ai/claude-code之类命令随后找到 npm 全局 bin 目录一般可用npm prefix -g查看把它加入系统环境变量 PATH然后重启终端。还有一个常见问题是error: claude native binary not installed. either postinstall did not run这个大概率是 npm 安装过程中 postinstall 脚本没有正常执行。可以先尝试重新安装或者检查 npm 缓存、权限。如果重装仍然不行建议查看安装日志中的 error 栈不要盲目删除 node_modules。Codex 这边也有类似情况很多报错出现在网络或模型配置上。比如cc switch local proxy failed while handling codex endpoint /responses. provi...。这是一个比较典型的提示说明 CLI 在尝试通过某个本地代理端点发送请求但连接或协议处理失败了。如果你们公司有统一的开发者代理需要检查代理地址和认证信息是否正确如果没有就不要在配置里随便设 proxy。另外热搜里还有一条the gpt-5.6-sol model is not supported when using codex with a这提醒我们模型名称必须与你接入的服务商支持范围一致。不要因为看到某个模型名很新就乱填配置前先用codex --help或文档确认可用模型列表。2.2 配置 MCP Server把 30 个工具挂进来MCP Server 的配置方式每个 CLI 略有不同但核心结构差不多声明一个 server 名称、启动命令、环境变量和参数。例如在 Claude Code 中可以用配置文件或claude mcp add命令来添加。下面是一个简化示例展示如何添加一个本地运行的 Playwright 浏览器 MCP Serverclaude mcp add playwright -- npx playwright/mcplatest --headlessfalse有些工具需要配置 API Key比如搜索 MCP、外部 API 网关等可以在配置文件里声明环境变量{ mcpServers: { search: { command: npx, args: [-y, some/search-mcp], env: { API_KEY: your-api-key } } } }这里要特别说一句不要追求“把热门 MCP 都装一遍”。我曾经见过有人一次配置了 50 个 MCP结果模型经常不知道该调用哪个或者多个工具之间的职责重叠导致重复劳动。我更建议按工作流选工具。对于 LinkedIn 外展最核心的是这几类浏览器自动化Playwright MCP 是绕不开的基础设施用来打开 LinkedIn 页面、读取资料、填写消息框。注意--headlessfalse通常更合适因为浏览器自动化用于实际外展时你需要看到页面状态也便于人工介入验证码。搜索与网页抓取用于查公司新闻、行业动态、候选人最近动态。可以是 Search MCP 或通用 HTTP Request MCP。表格/数据库读线索 CSV、记录发送状态。可以用 SQLite MCP、Google Sheets MCP、Notion MCP或者自己写一个轻量文件读写工具。排程与通知当需要分批执行时用 Cron 或定时任务触发执行完成或失败时通过 Slack MCP 推送通知。如果你用 Dify 这类平台也可以添加本地 MCP 服务来统一管理。它们的原理相同都是把 MCP Server 注册给 Agent让模型在对话中调用。2.3 最小可运行的端到端场景先用一个最小场景验证流水线是否通候选名单只有 10 条不要求发送只要求生成“建议消息”并写回表格。这样做的好处是先隔离出最容易出错的环节。假设你的线索 CSV 长这样name,company,title,linkedin_url,last_post Alice,Acme Inc,VP Growth,https://www.linkedin.com/in/alice,We just launched a new API Bob,Beta Ltd,Head of Marketing,https://www.linkedin.com/in/bob,Looking for content ops tools你可以让 Claude Code 或 Codex 做这样一件事请读取 leads.csv 中的前 5 条记录。对于每条记录先用浏览器 MCP 打开 linkedin_url读取对方最近一条公开动态再结合公司名称和职位生成一条不超过 120 字的英文首回合消息。输出格式为 CSV包含 name, linkedin_url, generated_message 三列写入 output.csv。第一次跑通后再把“打开页面后输入消息、点击发送”加进来。但这一步开始就要认真考虑合规和质量控制了。3. 真正决定成败的批量外展的质量和合规控制3.1 自动化会放大风险也会放大错误LinkedIn 对自动化的态度非常谨慎。如果你的账号在短时间内发送大量重复消息很可能触发风控机制轻则限流重则封号。此外面向真实用户的商业消息在很多地区还要遵守反垃圾邮件法、数据保护法规。外展自动化能帮你提高效率但它同时也把风险放大了。最明显的问题有三个账号风险高频、无差别的自动发送会让平台判定你为机器人。信誉风险如果 AI 生成的消息带着错误事实比如张冠李戴的职位、虚构的共同好友对方会立刻对你的品牌失去信任。合规风险没有获取对方同意就发送营销信息在某些法律框架下可能违规。因此一个负责任的技术方案必须把“人”留在关键节点上。我强烈建议采用“半自动”模式而不是所谓的“全自动狂发”。3.2 把人的判断嵌入流程我们团队实际采用的流程是这样的代理批量读取线索在本地生成“候选触达消息”清单每一条消息都附上生成依据比如“候选人最近转发了某篇文章”“公司刚宣布融资”消息先写入表格的“草稿”列状态设为pending_review人工审核员逐条看觉得没问题就标记approved有问题可以修改后标记代理只处理approved状态的消息打开 LinkedIn 消息框填入内容但最后一下“发送”按钮由人工点击或至少预留一个确认确认再执行的开关。这样做的好处是即使某个决策点判断失误也不会直接造成不可逆的负面影响。每次发送前人都能拦截明显错误的内容。有人可能会问既然最后还要人点一下发送那自动化还有什么意义意义在于人工从“阅读资料、构思文案、填写表单”变成“审核一条已经写好的高质量消息”。审核一条消息只需要 5 到 10 秒而手工写一条可能要好几分钟。这样一天处理 100 条以上是现实的而且内容质量有了基本保障。3.3 频率控制与随机化不要设计“让代理一次性发完 1000 条”的任务。无论从平台策略还是实际效果看这种极端行为都不可取。更合理的批次策略是每天发送量从 10 条开始观察账号是否有异常比如无法访问 LinkedIn、出现安全验证如果没有异常第二天可以增加到 20 条再逐步增加两条消息之间加上随机延迟比如 90 到 180 秒同一时间段的会话数不要超过 5 个避免短时间内密集操作。如果你在运行长时间任务建议把任务拆成“每天一批”而不是“一次性跑完”。例如用系统自带的 cron 或 GitHub Actions每天定时执行一次发送任务。这样即使某天任务卡住也不会影响第二天的计划。3.4 个性化内容的质量检查AI 生成内容最怕的是“听起来很合理但实际上是编的”。候选人在上个月根本没发过那篇动态AI 却拿去当切入点这绝对会翻车。为了避免这种情况可以做两层校验信息来源校验凡是生成消息中引用的外部事实必须有一个可验证来源。比如“看到你分享了 XXX”要让代理记录来源链接并在输出中一并展示。人工复核事实审核员在放行前如果对某条事实存疑可以直接点击来源链接确认。无法确认的内容就不要发送。此外不要把所有个性化点都押在“对方最近动态”上。可以更多地使用公司公开信息、行业普遍话题、对方职位带来的共同利益点。这样即使个别动态抓取失败消息依然有一定相关性。4. 从单条到 1000 条批次任务、日志和异常排查4.1 跑通一条和跑通 1000 条是完全不同的工程一条消息跑通只能说明代码路径没问题跑 1000 条时你会遇到各种意想不到的情况某条 LinkedIn 链接失效某个人资料需要登录才能查看生成消息时模型突然输出空内容浏览器页面加载超时某条记录因为网络延迟导致重复发送表格写入时遇到非法字符。所以批量执行前一定要为数据加上“状态管理”。常见的状态至少包括pending // 还没处理 processing // 正在处理中 draft_review // 已生成草稿等待审核 approved // 人工审核通过 sent // 已发送 failed // 处理失败需要排查任务中断后代理可以根据状态字段自动跳过已经处理过的记录实现“断点续跑”。例如如果前 200 条中有 150 条已标记approved程序恢复后只处理状态为pending和failed的记录而不会把已发送的消息再发一遍。4.2 用日志和追踪定位问题日志不是只打印“成功”“失败”就完了。更实用的做法是对每次循环输出结构化日志至少包含当前处理的是哪条线索步骤编号读取资料、生成消息、写入表格、发送调用了哪个工具工具返回了什么样的结果摘要该步骤耗时错误类型和堆栈信息。例如可以记录成这样的 JSON 行{ts: 2025-02-14T10:00:00Z, record_id: 17, step: fetch_profile, tool: playwright, status: ok, profile_title: VP Growth, url: https://www.linkedin.com/in/alice}以后排查问题时你可以直接过滤某个 record_id看它卡在了哪一步。不要小看这个动作。它省下的不是一天两天的问题复盘时间而是整个系统的可维护性。4.3 常见问题排查链路结合近期安装和使用中高频出现的报错我列了一个常见问题排查表。它不是万能答案而是一个比较靠谱的排查顺序。现象可能原因推荐排查顺序CLI 命令无法识别npm 全局目录不在 PATH先执行npm prefix -g确认路径再检查环境变量 PATHMCP Server 连接失败端口冲突、启动命令错误、依赖缺失单独在终端启动 MCP Server 命令看有没有报错再检查配置文件中的 command 和 args浏览器自动化打开页面后一片空白需要登录、页面加载超时先手动打开 LinkedIn确认登录态考虑增加等待时间或设置--headlessfalse生成消息内容与资料无关上下文信息不足或模型幻觉检查输入的 profile_text 是否完整增加“必须基于资料原文生成”的系统约束发送速度过快循环中没有限速检查代码中是否配置了随机 sleep在循环里加并发限制任务中断后重复发送状态没有写入磁盘检查状态更新是否在发送成功之后才提交增加幂等锁Windows 下 Claude 安装后仍报错权限不足 / npm 缓存损坏重新安装全局包或使用 npx 的方式临时运行确认问题来自全局安装还是命令本身Codex 请求返回模型不支持endpoint 或模型名配置错误检查 config 中的 model 字段确认它是否与当前服务商兼容4.4 遇到验证码怎么办浏览器自动化一旦被平台检测到可能会弹出验证码。技术上有各种处理自动识别的方案但我不建议在 LinkedIn 外展场景中使用绕过验证码的技术。原因很简单验证码本身就是平台策略的一部分强行绕过会大幅增加账号风险也涉及不正当手段。更稳妥的做法是遇到验证码时代理立即停止自动操作通知人工处理人工手动解决验证码后再恢复任务如果频繁出现验证码说明操作频率太高或浏览器指纹异常需要降低频率并重新评估策略。把这套逻辑写进自动化代码里才算是一个有生产意识的方案。5. 这套工作流的真实边界和长期价值5.1 适合谁不适合谁先说结论这套方案最适合的是小规模的 B2B 团队、高客单价服务、需要深度个性化的客户开发。它不适合纯粹追求“海量触达”的 C 端营销也不适合没有任何内容差异化的群发场景。如果你服务的是大型企业客户哪怕一天只发 15 条高质量消息效果也会比发 200 条模板消息更好。因为决策链条长、客单价高、触达质量才是第一位的。反过来如果你的产品是面向大众消费者的低价商品这类外展策略本身就不匹配因为你很难通过人工审核每条消息去覆盖庞大的用户规模。5.2 和传统方案相比差异到底在哪里我用一个表格直观对比维度手动 SDR传统 RPA 脚本Claude Code/Codex MCP信息收集人工逐个查慢可批量抓取但无法理解语义代理可根据目标动态调用不同工具并理解内容个性化消息依赖个人经验质量不稳定模板变量填充容易群发感模型基于真实上下文生成可解释依据状态管理依赖 Excel/CRM 人工维护脚本可维护但调整逻辑成本高可让代理直接读写数据源风险控制人工发送相对安全容易触发风控且难控制节奏可以在流程中嵌入审核、限速、暂停规则长期迭代经验在人的脑子里脚本难适应新逻辑提示词和工具组合可以很快调整数据沉淀方便这个表格并不是说 AI 方案一定更好而是说它把“懂业务的人”和“重复操作”之间的耦合解开了。你能把精力放在策略设计上而不是每天复制粘贴消息。5.3 长期价值不在“外展”而在流程数字化我见过很多团队把自动化当成“省钱”手段目标定在“省掉一个人力”。但真正跑完一轮后会发现更大的价值是流程被数字化了哪些线索来源质量更高、哪些开场白更容易得到回复、哪些行业需要什么样的切入点、哪个时间段回复率更高。这些数据积累下来会形成一个可迭代的销售知识库。比如你可以在线索库里为每个目标客户打标签来源、行业、是否回复、是否有下一步动作。几轮之后就能分析出“某行业客户更容易被‘案例数据’打动”还是“创始人背景更容易被‘创始人对创始人’的叙事打动”。这种洞察是任何自动化脚本都替代不了的。5.4 一套可复用的外展闭环框架如果你要从零搭建类似系统我建议按照这个闭环来设计而不是急着写第一个自动化任务线索挖掘明确目标画像用人群搜索、推荐、旧客户补充名单匹配验证用工具批量补充公司信息、职位变更、最近动态判断真实匹配度内容生成基于真实上下文生成差异化消息并保存引用来源人工确认所有消息在发送前必须过一遍人眼发送与追踪低速、分批、随机化发送并记录发送时间和后续动作反馈回流把回复、打开、退订等结果写回数据表更新画像和模板库。这六个环节不需要一次性做得很重。你甚至可以先用 3 个 MCP 工具做其中三个环节等稳定后再逐步加工具。真正的难点不是“用 30 个工具”而是你能不能把每个环节的输入、输出、判定标准定义清楚。回到开头那个问题能不能用 Claude Code 批量发 1000 条 LinkedIn 消息技术上说可以。但从实际效果和长期信誉看我更建议把目标改成“用这套工具把 1000 条个性化消息准备好然后由人确认后以可控节奏发出”。第一次跑通时只选 10 个线索稳定后再逐步扩展到 50、100。你会发现真正让结果变好的不是海量发送而是每一次触达前系统都能帮你回答三个问题这个人值不值得联系我该说什么以及我凭什么让他相信。剩下的“发送”动作反而是整个流程里最不需要智能的一环。