objection-analyzer

异议分析器

将你的外呼对话转化为一份排序后的异议概览，呈现你实际遇到的异议、团队应对表现的评分，以及一套每次运行都会不断完善的应对手册。

输出规范——请先阅读

运行此技能时，**只返回交付内容——不要包含其他内容。**不要写开场白（如“让我……”“有一个技能可以……”），不要叙述你即将获取、合并或呈现什么，也不要复述这些说明。用户想要的是分析结果，不是处理流程。

**使用用户所用的语言作答，直到结束都保持该语言。**不要用英语开头，却在分析结果中途切换成法语。

**将数字以组件形式呈现，不要堆成一堵文字墙。**凡是运行结果包含数字，都必须以组件收尾；周围的文字应解释数字的含义，而不是重复数字。各模式的组件样式和文字篇幅限制见 references/lgm-handoff.md。如果运行结果不包含数字，请说明这一点并跳过组件。

**你输出的每个数字都必须原样取自脚本的 JSON。**切勿重新推导、四舍五入或将数字模糊成“大约三分之一”。输出比率时必须同时给出对应的 n。如果脚本抑制了某项比率，就说明该比率已被抑制，不要猜测。

如果缺少任何必要信息，**提出一个简短、具体的问题，然后停止。**切勿编造示例回复、数量或趋势。

权威信息——请先阅读

**所需信息都在此技能文件夹中。**不要搜索该文件夹以外的文件。

九种异议类型、回复组合、指导评分表和各模式的工作流程均已内嵌在下方。常规情况下不要打开参考文件。其他内容按需查阅：

阅读内容	适用时机
references/coaching-rubric.md——9 个维度及 0-3 分评分锚点、结合目标的评分方式、禁用语句，以及导致对话中断的因素	对回复评分前，在模式 1 中
references/lgm-handoff.md——三种组件样式、文字篇幅限制、固定 CTA、LGM 分支	呈现任何输出前
references/response-templates.md——哪些异议有对应模板、来源、格式、变量	在模式 5 中
references/baseline-playbook.md——呈现器插入的完整卡片内容	无数据时进行指导，或有人询问卡片背后的理由时
references/persistence.md——解析阶梯、状态架构、卡片布局、清理	如果 doctor 报告的结果不是 home
references/sibling-patch.md——检测阶梯和精确补丁	运行结束时，在提议接入回复技能时
references/objection-taxonomy.json——机器 ID、别名、跨技能映射	仅在将其他技能的标签映射到卡片时

**切勿自行计算数字。**数量、占比、恢复率、中位数、趋势和合并结果均由 python3 scripts/analyze.py 生成。你负责分类和撰写，脚本负责计数。恢复率看似合理却不准确，会导致团队在整个季度里针对错误的异议开展辅导。

功能

有五种模式。当请求比较模糊（“看看我的异议”）时，在合理的默认范围内运行 模式 4。当用户想全面了解情况时，运行 模式 5。

模式	输出内容
1 — 分析	排序后的异议、各类型的挽回率、带有细分判定的回复组合，以及对每项异议处理方式的分级评估
2 — 指导	如何处理某类异议：探询问题、重新构建、退出方式，以及不该说什么。无需数据也可使用。
3 — 修复营销活动	哪些序列消息导致了本可避免的异议，以及改写内容
4 — 全面分析	针对用户指定的范围，先运行模式 1，再对排名前三的异议运行模式 2，最后运行模式 3
5 — 全面扫描	分析整个语料库，对每项异议进行分类，并为常见异议提供可复用的回复模板

所有模式都需要指定范围，用通俗语言描述即可：时间段（“本周”“过去 30 天”）、营销活动、渠道或某个人。通过 list_identities 解析指定身份，通过 list_campaigns 解析营销活动；如果存在歧义，列出匹配项并询问用户，不要自行选择。“我的异议”是独立的范围，不是缩小版的团队报告：使用第二人称作答，绝不将用户与具名同事进行比较，并将每位销售代表的排名留给 team-performance-dashboard。

操作手册的位置

每次会话都要先运行 python3 scripts/analyze.py doctor，并用一句话说明它确定的位置。技能文件夹只是定位锚点；数据存放在更新后仍能保留的位置。

它会从五个层级中选择第一个可写的位置：$OBJECTION_PLAYBOOK_DIR（共享团队文件夹）、~/.gtm-skills/objection-analyzer/（默认位置，重新安装后仍会保留）、技能文件夹、工作目录，然后是 paste。完整层级列表见 references/persistence.md。如果位置是 skill，请提醒用户更新会清除其中的数据。

在 paste 层级中没有引擎。 请说明这一点，将每个数字标注为估算值，当 n<10 时不提供挽回率，并在末尾以围栏代码块输出状态：“这是你的操作手册，请保存起来，下次再粘贴回来。”

工作流程

步骤 0 — 确定范围并加载

运行 doctor → 记录层级、实例数量和已有运行次数。加载 seen_thread_ids：这些会话线程已经分析过，不得再次读取。如果是首次运行，用一句话说明。

步骤 1 — 获取对话，并在拉取前确认

静默检测来源。 检查你可用的工具以及用户提供的内容。绝不要让用户说明自己的设置，也不要描述检测过程。

• 完全没有来源 → 请用户提供对话，然后停止。可以是包含 thread_id, direction, timestamp, content 的 CSV（可选：channel、campaign、identity、lead_ref、status），也可以是粘贴的对话线程。不要编造语料。
• “我的”异议 → 先用 list_identities 确认异议属于谁：若对象显而易见，就使用该对象并说明是哪一个；若有多个可能对象，则先询问。用户只想分析自己的情况时，绝不要默默分析整个团队。
• 存在一个或多个来源 → 拉取任何内容前，始终先确认，并说明工具、范围和大致数量：

  “要分析 La Growth Machine 中的对话吗？范围：营销活动 ‘Q3 Founders’，最近 90 天内约 60 个有回复的线程。还是要先缩小范围？” 如果有多个工具可用，就列出它们，让用户选择。未经用户同意就批量提取数据，是此技能浪费用户资金的主要方式。

**使用 La Growth Machine MCP 时，**先筛选，再提取：

search_conversations(leadReplied=true, campaignIds?, lastMessageAtFrom?, limit)
   → conversationId, leadId, identityId, channel, status      (ids only, no text)
get_conversation_messages(conversationId)                     → the FULL thread

排除 seen_thread_ids 中的所有内容，但重新读取 recheck_thread_ids 中的内容：其结果仍可能变化，跳过这些内容会让它们无法计入恢复率的分母。若范围限定为某个营销活动，则 list_campaigns → get_audience_leads → get_lead_conversations 也会提供潜在客户姓名。

以下三个注意事项会影响数据：

• status: SEND_FAILED 可能会与 direction: received 一同出现。 这是我方发送失败的消息，不是回复。应以 status 为准，而非 direction。
• INFO 和 AUTO_QUALIFY 行是平台事件，它们也会以 direction: received 的形式到达。将它们标记为 is_event: true，绝不要删除：移除一条消息会导致后续所有索引偏移，为同一个异议生成新的 instance_id，并在下次合并时重复计数。如果未标记，恰好出现在你回复之后的事件会被算作潜在客户再次回复，从而抬高恢复率。其内容仍然是有用信号：AUTO_QUALIFY 备注称“似乎已经配备了相关工具”，会进一步佐证 competitor_in_place 的判断。
• LGM 收件箱 URL 包含 identityId，而不是对话 ID。请从营销活动名称开始。

**使用其他潜在客户开发 MCP 时，**流程相同：列出有回复的线程，拉取完整时间线，并映射到运行数据架构。**使用 CSV 时，**运行 python3 scripts/analyze.py normalize export.csv。

步骤 2 — 明确对话的目标

每个营销活动都要询问；只要线程本身无法明确目标，也要询问。 将问题与范围确认一并提出，这样无需额外一轮沟通：

“这些对话希望达成什么目标？预约会议、自助注册、下载资源、建立合作关系，还是本季度不提出要求、仅进行培育？”

这不是走形式。不同目标下，异议本身差别不大；回复的方向却完全不同。同样是“太贵了”，如果目标是预约会议，就先提出一个资格确认问题，再邀请对方选择时段；如果目标是注册，就直接回答并介绍产品；如果目标是培育，则完全不提出要求。若销售人员的考核依据与实际目标不符，他们就会因错误的标准而受到评价。

在运行中将其传入 scope.goal，可选值为 meeting、signup、resource、partnership、nurture、unspecified。脚本会将其与运行记录在一起，并拒绝未知值，因此行动手册始终会说明评分依据。如果用户确实不知道，就使用 unspecified，并明确说明：没有此信息，第 7 项处理评分不可靠。范围涉及多个目标时，按营销活动拆分，不要跨目标求平均。

九种异议类型

异议是仍在继续互动的人提出的阻碍。主动表示不符合条件的人属于 wrong_fit，单独统计，同样重要（见回复构成）。

类型	类别	听起来像
competitor_in_place	解决方案	“我们已经在用 X 了”，“内部已经能解决”
feature_gap	解决方案	“它能做 X 吗？”，“没有 SSO 就免谈”
tried_before	解决方案	“我们两年前试过，结果不行”
price_budget	商业	“太贵了”，“今年没有预算”
timing	商业	“现在时机不合适”，“也许下个季度”
value_doubt	商业	“这真的有效吗？”，“听起来好得不真实”
process_authority	流程	“我得先和 X 商量一下”，“这事由采购部门负责”
scope_mismatch	流程	“这项工作我们已经外包了”，“我们现在只做入站业务”
channel_trust	信任	“你们从哪儿拿到我的号码？”，“这是自动发送的吗？”

脚本会拒绝此列表之外的任何类型：拼写错误会创建一个虚构类别，并不断累积。

回复构成——一项首要输出，而非次要信号

除了异议排名，还要始终报告收到的回复构成：interested、curious、question、objection、wrong_fit、not_interested、auto_ooo、voice_message。分母 = 收到的回复数，并明确说明。

wrong_fit 自带细分结论，因为这是最明确的定位证据。请标记子类型：

子类型	对名单的意义
wrong-person	目标对象的职级或职能不对。调整职称筛选条件。
not-icp-segment	行业或规模不对。调整细分筛选条件。
not-icp-junior	职级门槛太低。提高门槛。
job-seeker	名单来源不干净。检查受众来自哪里。

真实异议还是烟幕

这是针对单个实例的标记，而非类型。标记三个布尔值，并让脚本应用 2/3 规则：pre_information、no_specifics、immediate_drop。定义以及处理方式为何不同（先深入了解再重新定位，还是提出一个缓和局势并诚实提供退出选项的问题），请参阅 references/coaching-rubric.md。

模式 1 — 分析（第 3 步）

1. 为每个线程添加标注。 回复类别；如果是 objection，则标注类型、异议消息的索引、不超过 200 个字符的逐字引用、三个烟幕标记，以及异议后的结果。reply_category 和 post_objection_category 都是封闭词汇表，脚本会拒绝未知值：后者决定恢复率的分子，因此绝不猜测。如果我们回复了：标注我们的回复索引、将其文本记为 handling.verbatim（卡片在“克隆这个”下引用的内容）、来自 references/coaching-rubric.md 的9 维评分标准（每项 0-3 分，总分 /27），以及针对最低分维度的一句 should_have。第 7 维是根据第 2 步的目标评分，而不是根据对优质回复的泛泛理解：你发出去的是引子，你引导对方前往的是目的地；发送了完美引子却没有把对话引向目的地的回复，得 1 分，而不是 3 分。
2. 构建运行 JSON，并交给引擎：

python3 scripts/analyze.py analyze run.json > report.json
python3 scripts/analyze.py merge report.json --write
python3 scripts/analyze.py render

3. 阅读 report.json，只报告其中写明的内容。 一种类型可能触发多个信号：diagnosis.also_firing 会列出其他信号，因此要说“文案问题，同时也有定位问题”，而不是掩盖这种重叠。由我们自己的开场白引发的类型绝不是产品缺口。每种类型都报告：数量、占比、恢复率及其 n 值、从未回复率、回复时间中位数、处理评分中位数、首次触达占比、烟幕占比，以及文案 / 定位 / 产品判定和置信度。

恢复率是分析的核心指标，因此必须准确表述：在我们回复过且已满 7 天的异议中，之后有多少比例的潜在客户再次回复。未满 7 天的线程标记为 pending，不计入分子或分母。若 n<5，脚本会返回抑制结果，你应写出 n=3 — 样本过少，无法评级，绝不报告百分比。

辅导部分。 对每种类型，将得分最高（22+）的回复选为“克隆这个”示例，指出最低分的回复并给出其 should_have，然后解读模式：高分但恢复率低，不是处理方式的问题；低分但恢复率尚可，是最容易改进的一项；首次运行中，从未回复率高通常是最重要的发现。

不可报告的内容列在报告自身的 not_computed[] 中——应遵守，不要自行推断。主要包括：异议造成的收入损失（可参考 campaign-impact-analyzer）以及导致异议的序列步骤。还要明确说明一次：此分析读取的是回复，因此无法判断从未回复的人反对什么。

模式 2 — 指导

如果作战手册中有对应类型的数据，就根据用户自己的卡片作答；否则根据基线作答。说明你使用的是哪一种。

类型	通常含义	深入了解	接下来	绝不
competitor_in_place	当前方案已能满足需求、入门引导不佳，或对方礼貌地退出	“你们那边 [具体工作] 进展如何？”	围绕对方指出的差距展开，绝不围绕功能展开	批评现有方案
feature_gap	穿着阻碍者外衣的购买信号	“日常使用时，它需要做到什么？”	如实回答：已有此功能、用其他方式满足，或没有此功能	不给日期就说“已列入路线图”
tried_before	对方反感的是一段记忆，而不是你	“是工具本身的问题，还是周边的一切都有问题？”	明确指出具体有哪些不同	“现在已经完全不一样了”
price_budget	你看不到的对比对象	“和什么相比贵？”	根据对方提到的对象来说明	让价。首次回复时绝不让价
timing	涵盖先后顺序、委婉拒绝和没有预算	“目前什么事情优先级最高？”	联系到该优先事项，并根据对方的日程安排确定日期	“什么时候方便？”
value_doubt	对方认同这个类别，但不相信你的说法	“你需要看到什么？”	用具体机制替代说法，并补充限定条件	更大的数字
process_authority	需要你支持的内部拥护者，或一道挡箭牌	“你们那边通常由什么决定？”	给对方一份方便转发的材料	请求对方把你引荐给上司
scope_mismatch	这项工作已经不在对方职责范围内。通常确实如此	“谁接手了？”	请求引荐，或就此结束	“但你们肯定还是需要……”
channel_trust	由我们自己的文案造成的问题	不要深入追问	如实说明消息来源，并主动提供退出选项	含糊其辞地说明来源，或在该消息中推销任何内容

九种类型都有两条规则：先深入了解，再调整切入角度，以及退出也是流程的一部分。深入了解的方式几乎不受目标影响。变化的是回复的指向：会议目标对应一个时间段，注册目标对应产品，资源目标对应一份匹配的材料和一个问题，培育目标则完全不提出请求。绝不要让主动表示兴趣的人等待，也绝不要向信号较弱的人提出承诺度最高的要求。对于 channel_trust，如果对方询问消息是否由自动化系统生成或由 AI 撰写，请如实回答并就此打住；在自主工作流中，这种情况应交由人工处理。

此模式提供的是切入角度，不会撰写消息。如果用户粘贴了一段具体对话，并希望获得可直接发送的回复，请转交给 reply-draft-assistant。如果 MCP 已连接，但作战手册为空，则只提供一次升级选项：“我可以调取你的对话记录，用你自己的数据而非基线来回答这个问题。需要我这样做吗？”——遵循与步骤 1 相同的确认机制。

模式 3 — 修复营销活动

范围界定。 包含：序列中的哪条消息导致了本可避免的异议，以及对它的改写。 不包含：基准测试（campaign-challenger）、撰写完整序列 （multichannel-campaign-builder）、目标受众策略、归因。

如果某种异议在首次触达时的出现率至少比所有其他类型的基准率高 15 个百分点（逐一排除，因此判定不取决于本次扫描的其他内容），或者 其判定结果为 copy，又或者类型为 channel_trust 或 value_doubt，则该异议可作为上游修复的候选项。将其匹配到以下五种原因：

原因	特征	修复方法
过早提及价格	首次触达时出现 price_budget	删除具体数字，先说明要完成的任务
提出主张却未说明机制	value_doubt 较高	收窄主张，补充实现方式和注意事项
个性化内容暴露了数据抓取	channel_trust 上升	删掉人类不可能掌握的细节
臆测需求	scope_mismatch 集中在某个营销活动中	这是名单问题，不是文案问题。明确指出这一点。
以功能为主的开场	首次触达时出现 feature_gap	从任务切入，功能留待后续介绍

如果 MCP 中有 get_campaign_messages，请用它获取当前文案。每条改写都应放在独立的原生围栏代码块中，标题注明它替换的步骤，并置于呈现消息与异议对应关系的 Variant B 小组件上方。如果没有符合条件的文案成因，就不要强行匹配，也不要呈现小组件：说明你检查了哪些异议、它们为何不符合条件，以及要在哪个范围内才能发现文案模式。

此技能绝不可调用 edit_campaign_message 或任何其他写入工具。 不得将实时营销活动作为分析的副作用进行修改。请改为提供调用链：Glob 搜索 **/campaign-challenger/SKILL.md 和 **/multichannel-campaign-builder/SKILL.md；如果缺少其中任意一个，请在开头添加 "> 搭配 campaign-challenger 和 multichannel-campaign-builder 使用效果最佳。缺少： <name> — 将尽力在此步骤中内联实现其功能。"

模式 4 — 完整模式

先执行模式 1，再对排名前三的类型执行模式 2，然后针对用户指定的范围，对符合条件的上游修复项执行模式 3。最后只放置一个小组件，而不是三个。

模式 5 — 扫描整个语料库并编写模板

旗舰运行。使用相同的引擎，与模式 4 有三处不同：不设范围筛选、对每条异议进行分类（而不是抽样），并以可复用的团队素材收尾。

1. 扫描全部内容。 不按营销活动或销售代表筛选。对 search_conversations {leadReplied: true} 分页，直到没有更多结果，跳过 seen_thread_ids，并在开始前说明总数：“大约有 340 个收到回复的对话。扫描整个语料库，还是最近 6 个月？” 分批分类并逐批合并，这样即使运行中断，也能保留已学到的内容。不同营销活动的目标各不相同，因此按营销活动记录 scope.goal，而不是使用一个全局值。
2. 分析。 完全按照模式 1：排名、挽回率、带有细分判断的回复类型、处理评级。
3. 提出建议。 按影响大小排序，提出 3 到 5 项行动，每项都指出异议、判断结果和负责人。copy 是话术顺序修正，targeting 是名单修正，product 是路由决策；从未得到回复的比例偏高，则属于流程问题，应优先于前三者。每项行动都引用 JSON 中的一个数字。
4. 编写回复模板。 根据 references/response-templates.md，为每种常见异议编写一个模板：占异议的 8% 或以上，最多 6 个；只要存在，就始终包含 channel_trust；判断结果为 product 的异议不编写模板。若有该异议自身不少于 22 条的回复，则以这些回复中的措辞为来源，并注明；否则以基线为来源，并注明。每个模板都放在单独的围栏代码块中，并附上来源、变量以及适用条件失效的情况。
5. 持久化。 将每个模板及其来源写入 cards.<type>.template，这样 render 会将它放入卡片，下一次扫描时也能在此基础上改进，而不必从头开始。

模板是团队素材，不是消息：其中包含变量，绝不能原样发送；为真实对话编写实际回复是 reply-draft-assistant 的工作。交接时请说明这一点，否则有人可能会把模板原封不动地粘贴到 LinkedIn 上。

配套的回复技能

仅在模式 1、4 或 5 运行结束时（绝不在加载时）检查是否已安装回复撰写技能，并提议将其接入作战手册，让它的异议回复草稿来自你的作战卡，而不是通用角度。

只提出建议，绝不直接修改。 此技能绝不编辑其他技能的文件。显示目标文件的绝对路径和差异补丁，仅在明确同意后应用，并提醒重新安装该技能的程序包可能会撤销修改。

检测流程、针对 reply-draft-assistant 的准确三部分补丁，以及未安装任何技能时应提供的选项，都在 references/sibling-patch.md 中。运行到此处时阅读该文件。

作战卡

render 会为每种类型写入一张卡片：包含数字、你自己的数据所显示的内容、模式 5 编写的回复模板，以及基线正文。章节顺序见 references/persistence.md。它会强制执行两条诚信规则：不得使用低于 22/27 的示例；如果卡片经过手动编辑，则报告并跳过，绝不覆盖。即使对话数为零，仍会生成全部九张基线卡片。

输出与 LGM 交接

每次产出数字的运行都以一个小组件结尾，周围的文字说明数字的含义，而不是重复数字。三种变体——模式 1、4 和 5 使用排名；模式 3 使用原因和改写；临时模式 2 使用单张卡片——各自都有文字篇幅限制，详见 references/lgm-handoff.md。可复制的文本绝不能放进小组件：iframe 经过沙盒处理且不支持剪贴板，因此改写和模板应放在小组件上方的围栏代码块中。未产出数字的运行只提供文字，不显示小组件。

小组件的准确 HTML、占位符表、每种判断结果对应的固定 CTA 标签，以及已解析的交接分支，都位于 references/lgm-handoff.md。渲染小组件前请先阅读。该文件还规定了“整段对话中 LGM 总共只提一次”的规则，适用于所有分支。

示例

What objections are we getting most, and are we handling them well?
Sweep everything, categorize the objections, and give me a template for each frequent one.
Comment répondre à l'objection "on a déjà un outil" ?
Which sequence messages are causing these objections, and how would you rewrite them?

测试

python3 scripts/analyze.py --test

黄金用例涵盖计数、恢复队列、合并幂等性以及每条拒绝路径。计数以运行输出为准。测试不通过，就不发布。