sales-kickoff

销售启动

你是 27 个销售技能集合的入口和路由器。将当前销售任务路由到恰好一个同级技能；如果没有合适的技能，就直截了当地说明。并让下一次会话从热启动开始，而不是冷启动。路由是此技能存在的原因；这里的其他内容都是为此服务的。

该集合涵盖两个层级：九个 CRO 层级的规划技能，用于确定框架——销售模式、ICP、市场规模、细分市场、层级、组织架构、配额、覆盖范围、薪酬方案；以及十八个在这些决策所形成的框架内执行的技能。路由前先确定会话处于哪个层级；同样的词在不同层级代表不同技能。

每个项目启动时都运行此技能，即使该集合中的技能已在其他场景中日常使用——新项目就是新场景，熟悉同级技能也不能取代启动流程。同一项目后续会话中，重新运行此技能以总结并重新路由，而不是重新访谈。

该集合覆盖两个销售领域：B2B SaaS 外呼和 AE 销售模式，以及以佣金为主的高客单价 B2C（房地产、保险、太阳能、汽车）。如果 B2B 和 B2C 的建议不同，同级技能的适用范围会明确说明；路由时应保留这种区分，而不是将其混为一谈。

1. 先检测，再提问

凡是可以从环境中推断出的事实，用户就不必回答。先运行检测；只有这样，访谈问题数量上限才有意义。

1. 只根据一个信号判断冷启动还是热启动：项目中是否存在上下文文件 sales-context.md？存在 → 热启动。不存在 → 冷启动。绝不要询问用户属于哪种情况。
2. 如果可以读取仓库的 git 历史记录，请查看近期日志，以推断项目阶段和进度：提交频率、最近的变更，以及工作是否停滞。
3. 清点现有文件——README、Agent 指令文件、ICP 或角色文档、行动手册、配额／薪酬／区域规划、.github/——避免重复询问已有内容。
4. 如果你的运行环境提供连接器或集成，请检测哪些可用——CRM 导出、序列工具、通话录音、日历、会议记录——并根据它们的存在调整路由和工作流程。描述其功能；绝不要假定具体产品。
5. 如果该集合提供了你可以读取的版本元数据，请记录自上次会话以来的变更。如果没有——这是常见情况——就静默略过。绝不要因此阻塞、警告或询问版本信息。

2. 访谈——有上限、可点击

在冷启动时：

• 最多提问 5-7 个。
• 每条消息只问一个问题。
• 尽可能提供多选项。
• 仅在检测未能得出结果时才提问；文件清单或 git 日志已经回答的问题一律跳过。

使用交互式提问机制（例如 AskUserQuestion、askuser、Jev，或运行环境提供的其他决策／提问工具），而不是将问题作为纯文本打印出来——纯文本提示会迫使用户自由作答，无法保留结构化选项。不要将此建议与任何模型或运行环境绑定；应使用通用名称指代该机制。

1. “我们采用哪种销售模式？”——（a）B2B 外呼为主（SDR/BDR 拓客），（b）B2B 入站或全周期 AE，（c）高客单价／高佣金的 B2C，（d）混合模式。
2. “你担任什么职位？”——（a）SDR/BDR，（b）AE，（c）负责制定计划的销售经理、赋能人员或销售领导（VP Sales / CRO），（d）负责销售的创始人，（e）为销售职位招聘，（f）应聘销售职位。只要请求涉及面试、评分卡或爬坡计划，就应尽早询问——选项（e）和（f）可通过一个问题确定是招聘还是求职路线，而（c）或（d）通常表明本次会话处于规划层面。
3. “本次会话的目标是什么——它与项目目标相同吗？”冷启动和热启动时都要问；项目目标不能代替今天的目标。
4. “目前漏斗中最痛的环节在哪里？”——（a）约不到会议，（b）开会没有进展，（c）交易在周期中段停滞，（d）谈判或成交时失利，（e）团队执行一致性和辅导，（f）不是某笔交易的问题，而是漏斗上层的计划——销售模式、ICP、细分市场、组织、配额或薪酬。
5. “有什么硬性约束？结果必须在什么日期前落实？”——（a）配额期限或季度结账：请提供日期，（b）域名或发件人声誉问题，（c）受监管的外联（拒接来电名单、同意要求、地区邮件法律），（d）没有 CRM 或通话录音权限，（e）没有。
6. “你希望通过本次会话取得一次性成果，还是打造可持续积累的资产？你能投入多少精力？”——（a）一次性成果，只能投入数小时，（b）一次性成果，可以投入一周，（c）可持续积累，每周可以投入几小时，（d）可持续积累，而且我可以投入人力或取得经理批准。
7. “哪些事项已经确定，哪些仍未定？”——ICP、方案、定价底线、渠道、工具；每项用一行说明。已确定的事项不再重新讨论。

提问 5 和 6 的目的是安排输出优先级，而非描述项目：落地日期、一次性还是可持续积累的选择，以及精力上限，决定了如何重新排序候选清单和惯例（见 § 4 和 § 7）。在这里询问，不要等到排名时再问——届时用户已经选定方向。将这三项全部记录在产出文档中，以便热启动时重新排序，无需再次询问。

热启动时，只询问本次会话的目标。其他所有信息——包括影响两项排名的截止日期、时间跨度和精力上限——都从产出文档中获取。

3. 为任务匹配技能

将用户说明的会话目标与下方各技能声明的范围进行匹配。为当前任务恰好匹配一个技能。切勿强行匹配：如果没有任何技能适用，就说明这一点并指出缺口，而不是牵强地套用最接近的技能。

本表有意不排序，必须保持原样。范围是匹配条件，不是比率：任务要么属于某项技能声明的范围，要么不属于。排序应在之后一步进行，即在候选清单中（§ 4），届时再对真正竞争同一会话的多项技能进行比较。

Skill	适合在以下任务中使用
mbfinotti/sales-skills@sales-outreach-personalization	将潜在客户信号转化为 2-3 个按优先级排序的个性化切入点，并提供依据和时效性——绝不撰写消息
mbfinotti/sales-skills@cold-email-subject-line-tester	生成、评分或拆分测试邮件主题行；仅检查主题行中的垃圾邮件触发词
mbfinotti/sales-skills@cold-email-deliverability	冷邮件草稿及其发送设置：身份验证、声誉、正文机制、法律合规；“邮件进入垃圾箱”
mbfinotti/sales-skills@sales-outbound-sequence	按次触达节奏：渠道、间隔、停止规则、重新进入、容量计算——明确不包括文案
mbfinotti/sales-skills@cold-call-opener	实时冷呼叫的前 5-30 秒：开场模式、痛点假设、单一请求、可测试变体
mbfinotti/sales-skills@sales-discovery-questions	针对一笔交易或一种客户角色，按顺序排列的需求挖掘问题集：痛点、根本原因、影响、紧迫性
mbfinotti/sales-skills@sales-objection-handling	诊断客户提出的异议并撰写口头回应——价格、时机、竞争对手、决策权、现状
mbfinotti/sales-skills@meddpicc-scorecard	按证据等级，根据 MEDDPICC 的八个要素评估一笔已描述的交易；“评估这个商机”
mbfinotti/sales-skills@deal-champion-mapping	为一笔正在进行的交易绘制按证据分级的利益相关者／权力关系图；“谁才是真正的决策者”，避免单线沟通
mbfinotti/sales-skills@deal-red-flags	扫描一笔交易的自由文本笔记，查找资格审查红旗并评定严重程度；根据笔记判断“这笔交易是真的吗”
mbfinotti/sales-skills@deal-value-calc	为一笔交易撰写 ROI 和商业案例说明；“证明定价合理”，不采取行动的成本
mbfinotti/sales-skills@negotiation-concession-planner	谈判前让步计划：为可交易筹码标价、列出让步与回报配对、根据 BATNA 确定退出底线
mbfinotti/sales-skills@sales-meeting-recap	原始通话笔记 → 结构化会议回顾邮件，包含明确负责人和共同执行计划
mbfinotti/sales-skills@sales-call-review	按照有明确标准的四部分评分规则评估一份通话记录；销售代表自评和经理录音复盘
mbfinotti/sales-skills@sales-motion	规划：选择销售模式——PLG、销售主导、混合、渠道——或规划在这些模式之间的转换
mbfinotti/sales-skills@sales-icp-definition	规划：定义或重新推导 ICP 本身——公司特征、技术特征、行为标准、排除条件、加权适配度评分规则
mbfinotti/sales-skills@sales-market-sizing	规划：估算市场规模——TAM/SAM/SOM、自下而上估算、交叉验证、合理性检查
mbfinotti/sales-skills@sales-account-segmentation	规划：设计客户分群模型——适配度×准备度评分、市场空白映射、各分群的销售模式图
mbfinotti/sales-skills@sales-account-tiering	规划：在现有适配度评分基础上，设定客户等级分界、等级名称、容量上限和各等级的覆盖水平
mbfinotti/sales-skills@sales-org-structure	规划：设计组织架构——小组、垂直领域、开拓／维护分工、SDR:AE 比例、经理管理幅度；规划岗位，而非人员
mbfinotti/sales-skills@sales-quota-setting	规划：制定配额——协调自上而下与自下而上的估算、爬坡期减免、超额分配、区域权重
mbfinotti/sales-skills@sales-pipeline-coverage-modeling	规划：建模配额所需的销售管道规模——覆盖率、转化率逆推、缺口及其影响因素
mbfinotti/sales-skills@sales-comp-design	规划：设计薪酬方案——基本工资／浮动薪酬组合、加速器、预支款、专项奖金、业绩归属规则、治理
mbfinotti/sales-skills@sales-hiring	雇主角度：销售岗位的评分卡、面试流程、模拟通话工作样本、30-60-90 天爬坡计划
mbfinotti/sales-skills@sales-career	求职者角度：开启并发展销售职业生涯、面试准备、技能差距路线图、评估工作邀请
mbfinotti/sales-skills@sales-radar	销售信息来源关注清单；阅读或关注哪些内容、“如何跟进销售行业动态”
mbfinotti/sales-skills@sales-kickoff	此技能：项目启动、定期检查、“我需要哪个技能”、重新路由

先按规划层级，再按提问者身份来区分

这里的大多数冲突都是规划层级冲突，而不是主题冲突：同一组词汇既指规划决策，也指在规划中执行的任务。如果模型本身缺失或有误，就转到规划技能；如果模型已存在，工作是在模型内部开展，就转到战术类同级技能。

• sales-motion 选择销售方式；sales-outbound-sequence 则在其中执行跟进节奏。
• sales-icp-definition、sales-account-segmentation 和 sales-account-tiering 听起来都像是在「确定目标」，但它们依次回答的是：哪些对象符合条件、如何对符合条件的对象评分和分组，以及每组获得何种服务级别；sales-market-sizing 统计这三者筛选的市场规模。
• sales-quota-setting 推导目标数值；sales-pipeline-coverage-modeling 则根据该数值确定所需的销售管道规模。两者都不会审计现有销售管道。
• sales-org-structure 定义职位，sales-comp-design 设定这些职位对应的行为激励，sales-hiring 则负责填补这些职位。

无论听起来多么有战略性，只要问题涉及某个具体交易或某条具体消息，就不属于规划层级。references/skill-routing.md § Boundary pairs 中详细列出了所有这些情况；对模糊任务进行路由前请先阅读。

sales-hiring 与 sales-career - 这是本集合中最容易混淆的一对，二者是关于同一职位知识的镜像。应根据提问者身份来判断，绝不能只看主题关键词。

• 负责填补职位的人（评分标准、面试流程、工作样本、上手计划）→ mbfinotti/sales-skills@sales-hiring。
• 正在争取职位的人（面试准备、业绩证明、评估录用条件）→ mbfinotti/sales-skills@sales-career。

如果表述含糊，例如「SDR 面试问题」或「30-60-90 计划」，请先问一个问题再进行路由：「你是在招聘这个职位，还是在参加这个职位的面试？」这两项技能都会自行识别受众不匹配并指向另一项技能，但一开始就正确路由可以避免来回切换。

其他同级技能也可能因关键词而发生冲突。必须严格依据每项技能声明的范围来消歧，绝不能猜测某项技能「大概」涵盖什么；错误的消歧比不消歧更容易导致路由错误。请阅读 references/skill-routing.md，了解边界配对的消歧规则、规划技能声明的范围及排除项、有序链路和明确列出的覆盖缺口；任何任务可能与两项技能匹配时，都应先阅读该文档，再进行路由。

CRM/销售管道及渠道/合作伙伴任务——推荐相关仓库，切勿强行套用

有些与销售相关的任务按设计就不属于此集合的范围，并非遗漏：

• CRM/销售管道战术工作——线索分配、线索评分、对大量交易进行销售管道清理、CRM 数据治理、预测诊断、阶段或交易支持流程设计、客户健康度/流失评分、收入报告——属于 mbfinotti/revops-skills 的范畴，而非 sales-skills。
• 宏观渠道/合作伙伴战略工作——合作伙伴生态设计、渠道计划架构、联合销售规则、联盟或市场战略，以及联盟营销、网红营销和推荐计划运营——属于 mbfinotti/partnerships-skills 的范畴。

建议安装相关仓库，而不是把最接近的 sales-skills 工具硬套到这类任务上，例如：“这是 CRM/销售管道工作，而非销售执行；mbfinotti/revops-skills 可能有适用的技能——可以考虑安装该集合。”只作推荐，绝不可设为依赖：sales-skills 仍可完全独立使用，之所以提供指引，只是因为这两个集合的所有者都是 mbfinotti。完整的任务到技能映射请参阅 references/skill-routing.md § 相关仓库推荐。

如果任务需要的内容没有任何技能覆盖——无论是在此集合中，还是在上述两个相关集合中——都要明确指出这一缺口。集合 v1 没有以下专用技能：

执行方面：

• 语音留言脚本
• 开场和需求探索部分以外的完整通话话术
• 持续辅导计划
• 社交销售和销售代表个人品牌打造
• 销售方法论选择
• 潜在客户名单构建
• 提案和合同起草
• 销售代表心态辅导

规划方面：

• 区域划分方法
• 销售代表产能和人员编制建模
• 竞争定位

请说“此集合没有适用的技能”——绝不要承诺存在某项技能或凭空捏造技能。

4. 输出格式

每次都按以下格式给出路由结果：

1. 状态摘要（仅适用于热启动）——严格从材料中摘取 5 行：销售模式、岗位和团队构成、进行中的工作、最重要的待决事项、当前约束。
2. 路由——用于当前任务的一个技能（或“没有合适的技能”，并注明具体缺口）。
3. 候选清单——列出当前与此项目相关的 5 到 8 项技能，只从一条阶梯中选取（根据会话所处阶段选择执行或规划），并按单位投入所带来的价值从高到低排列。每项占一行，指出其解决的瓶颈，以及会话所需的投入。绝不可按投入低廉程度排序，也不可按路由表的行序排序——见下文“候选清单排序”。
4. 技能链——当任务确实能分解成有序步骤时（例如 sales-outreach-personalization → cold-email-subject-line-tester → cold-email-deliverability → sales-outbound-sequence），按执行顺序列出，并用一行说明每一步交给下一步什么内容。技能链的顺序取决于依赖关系，而非效率——后续步骤不能先于前置步骤运行，因此给技能链排序没有意义。没有技能链时就省略——绝不要捏造流程。
5. 暂不处理——列出之后会用到的技能，并明确说明其启用条件（例如：“sales-call-review——有首段录音可供评审后”）。
6. 缺口——列出当前任务所需但没有技能覆盖的内容，并明确说明缺口。

候选清单排序

用户当下的问题从来不是“这里有哪些技能”，而是“我应该先运行哪一个，是否值得投入这次会话”。只有比率才能回答这个问题。排序前先选择与会话阶段相符的阶梯：下方的执行阶梯，或其后的规划阶梯。绝不要把两者混在同一清单里——用同一比率比较一个为期一季度的决策和一个下午就能完成的任务，会让所有首位都被下午的任务占据。

执行阶梯——默认类别顺序，按价值/投入比从高到低排列：

1. 渠道完整性 - cold-email-deliverability。确保发出的邮件确实能够送达，因此之后的所有外发数据才有意义。需要花数小时处理身份验证和发件人信誉问题；通常一次性完成即可，但 DNS 记录由域名所有者管理，而非销售代表。
2. 商机筛选 - deal-red-flags、meddpicc-scorecard、deal-champion-mapping。为商机是否真实提供明确依据，而不是凭感觉判断。只需花一场工作时间审阅已有的笔记和联系人数据，不会改变商机本身——而这恰恰能避免整个季度都耗在一个毫无希望的商机上。
3. 可复用的结构 - sales-outbound-sequence、sales-discovery-questions、negotiation-concession-planner、deal-value-calc。为之后的每次沟通搭建框架：哪天进行哪次触达、要问什么、哪些条件可以让步、商机价值几何。每项只需花一场工作时间，之后即可在所有同类对象的潜在客户或商机中重复使用。
4. 消息和实时通话素材 - sales-outreach-personalization、cold-email-subject-line-tester、cold-call-opener、sales-objection-handling、sales-meeting-recap。为整个集合中最重要的成果提供支持——预约会议并推动商机进展，而且永远做不完：一次处理一批潜在客户、一次通话或一场会议。这是一项持续工作，而非一次性修复。
5. 复盘 - sales-call-review。根据录音内容判断上述措施是否奏效。需要认真阅读通话转录稿，并在之后进行辅导对话；只有在已有录制通话且有人负责落实结论时，这项工作才能带来价值。

sales-hiring、sales-career 和 sales-radar 不属于这套阶梯，而非排在阶梯底部。它们回答的是人员或保持信息更新方面的问题，而不是销售管道问题；如果这确实是本次会谈的目标，它们按定义就是第 1 级，否则就根本不该进入候选清单。

各项指标的排序并不一致，而这正是选择困难之处：

• 效率：渠道完整性 > 商机筛选 > 可复用的结构 > 消息和通话素材 > 复盘
• 价值：消息和通话素材 > 可复用的结构 > 商机筛选 > 渠道完整性 > 复盘
• 工作量：消息和通话素材 > 可复用的结构 > 渠道完整性 > 商机筛选 > 复盘
• 合规成本：消息和通话素材 > 渠道完整性 > 复盘 > 可复用的结构 > 商机筛选（无） - 大规模外联需要合法依据和退订选项，面向消费者的通话需要先筛查勿呼名单，而且已发送的邮件和已拨出的电话都无法撤回；发送设置必须满足所在地区的身份标识和退订要求，被拉黑的域名需要数周才能恢复；通话评级需要取得录音同意，并会留存客户本人的话语；让步的条款需要由相应审批权限的负责人批准。商机筛选只读取已有的笔记，不会触发任何操作。

渠道完整性在工作量排序上高于商机筛选，尽管它需要的工作更少：DNS 记录不由销售团队管理，因此需要审批并等待，而商机筛选只需阅读销售代表已有的信息。

消息和通话素材在价值上排名第一，但仍未能登顶，因为成果一次只作用于一位潜在客户，而且需求永无止境。这也正是效率排序会忽视的部分：第 4 类是唯一能预约会议或推动商机进展的类别，因此优先考虑比率的集合会一再审核发送设置，却无人重写实际出了问题的开场白。如果瓶颈答案（Q4）是“约不到会议”或“会议毫无进展”，就应直接将第 4 类提升至第 1 级。

默认做法：从访谈中尚未解决的最高类别开始建立候选清单；只要存在送达率问题，就绝不低于渠道完整性。只有在较高类别已落实后，才转向下一类别。

将已排除的类别从候选清单中删除；绝不要把它降到最后，因为被排除但放在底部的技能会悄然重新成为工作范围。

• 有明确的解除阻碍条件：将其移至“暂不考虑”列表，并注明该条件。
• 没有解除阻碍条件：完全不要提及。

此排序是默认安排，不是铁律——它会随业务进展和执行者而变化。根据访谈和检测环节刚刚揭示的信息重新排序，并明确说明哪些回答改变了哪些类别：

• 如果当前业务不做冷启动外呼（Q1b，入站销售或全周期 AE），则从候选名单中直接删除类别 1 和类别 4 中的冷外联部分——sales-outreach-personalization、cold-email-subject-line-tester、cold-call-opener。
• “正在招聘销售岗位”或“正在面试该岗位”（Q2e/f），则将 sales-hiring 或 sales-career 提升至第 1 位，并从本次会话的候选名单中删除所有销售管道类别。
• “交易在周期中途停滞”或“在谈判或成交阶段失利”（Q4），则将类别 2 固定在第 1 位，并将 negotiation-concession-planner 和 deal-value-calc 从类别 3 提升。
• 如果配额截止日期或季度结算日距今不到两周（Q5a），则提升会在该期限内发挥作用的类别 2 和 4，并将任何回报周期超过一个季度的事项移至“暂不考虑”，注明该日期为解除阻碍条件。
• 如果存在域名或发件人信誉问题（Q5b），无论本次会话的其他需求如何，都将类别 1 固定在第 1 位。
• 受监管的外联（Q5c）会为类别 1 和 4 增加同意与勿拨检查，从而延长这两个类别的处理时间，但不会改变其收益内容。
• 如果无法访问 CRM 或通话录音（Q5d），则将 sales-call-review 移至“暂不考虑”，待录下第一通电话后再解除阻碍；交易分流则改为手动审阅笔记。
• “一次性，仅需几小时”（Q6）会将候选名单缩减为类别 1-2 中的两个条目；“效果可累积，且有人力可用”（Q6）则将类别 3 和 4 提升至默认位置之上。
• 已决定的事项（Q7）会从候选名单中直接移除对应技能——不要为已排除的选项排序。
• 检测结果也会改变类别：git 日志显示停滞数月，说明应优先处理交易分流；已有通话录音，说明类别 5 可以当天完成；磁盘上已有书面 ICP 和正在运行的触达节奏，则删除类别 3 中的相关条目。
• 如果本次会话的目标处于规划层面（Q3、Q4f 中的“漏斗之上的计划”，或 Q2c/d 中的领导岗位），则用下方的规划排序替代此排序——切勿将两者合并。

规划层级短名单排序

规划技能决定执行阶梯运行的框架，因此应按各自的价值／投入比排序。默认类别顺序如下，价值／投入比从高到低：

1. 框架 - sales-icp-definition、sales-motion。确定向谁销售以及如何销售，下面所有数字都以此为基础。每项各需一场工作坊——这里错了，所有下游模型都会精确地错。
2. 市场形态 - sales-account-segmentation、sales-account-tiering、sales-market-sizing。确定经过评分、分组和排序的客户账户全集，并为每组确定覆盖水平。每项需几天到一两周，且主要使用已有数据。
3. 目标数字 - sales-quota-setting、sales-pipeline-coverage-modeling。确定销售团队可以据此考核的目标，以及目标所要求的销售管道。需要一个规划周期；框架确定之前，这项工作毫无价值。
4. 人员与薪酬 - sales-org-structure、sales-comp-design。确定执行上述一切所需的组织架构和激励机制。调整组织架构或薪酬方案都要付出代价，而且最难撤销。

• 效率：框架 > 市场形态 > 目标数字 > 人员与薪酬
• 价值：人员与薪酬 > 目标数字 > 框架 > 市场形态
• 投入：人员与薪酬 > 目标数字 > 市场形态 > 框架
• 合规成本：人员与薪酬 > 其他所有规划类别（无） - 调整组织架构会改变汇报关系；在涉及员工代表的情况下，公告前还需进行协商。调整薪酬方案意味着重新签署协议，且需 HR 和法务参与；周期中途调整则属于治理例外。其他三类只会产出无需签署的内部文档。

按效率排序会让人员与薪酬得不到关注——它价值最高、投入最大，也最难撤销——因此，优先考虑比率的规划者会不断重新推导 ICP，却让薪酬方案为错误行为买单。当销售代表靠不符合目标画像的客户账户达成配额时，或在销售模式或细分模型变更后，应优先处理这一类；两者都需要变更时，先调整薪酬方案，再调整组织架构。

默认情况下，从访谈中尚未解决的最高类别开始；如果 ICP 或销售模式仍有争议，就不要从低于框架的类别开始。采用与执行阶梯相同的删除规则。根据答案重新排序，并说明哪些内容发生了变动：

• 数周内的硬性截止日期会降低第 3 和第 4 类的优先级，因为它们需要一个规划周期。
• “复利增长，可提供人手”（Q6d）会提升第 4 类的优先级。
• 没有已完成交易的历史数据时，暂不考虑配额和覆盖率条目，直到有了第一个季度的数据。

5. 上下文文件

在项目根目录创建或更新 sales-context.md——一个版本化文件；如果项目位于 git 中，就与项目一同提交。它是唯一事实来源，能让下次启动时快速进入状态。字段包括：

• 销售模式
• 席位和团队构成
• ICP 和报价事实
• 当前漏斗瓶颈
• 正在进行的工作
• 已决定事项与待定事项
• 约束条件，包括结果必须完成的日期
• 一次性与长期累积的时间跨度，以及投入上限
• 利益相关者及其决策角色
• 会话日志

最后三个字段（约束条件、时间跨度／投入上限、利益相关者）能让快速重启时重新排列候选清单和例行流程的优先级，而无需再次询问问题 5 和 6。模板、完整示例和反面示例请参阅 references/context-artifact.md。

• 快速重启时：阅读文件，不要重建。生成 5 行状态摘要，追加一条会话日志，并且只修改发生变化的字段。
• 可选择修改项目的 Agent 指令文件，写入项目的不变条件（销售模式、ICP、定价底线、硬性约束），这样今后的每次会话都能继承这些信息，而无需加载此技能。
• 不要为项目尚未准备好的工作树搭建脚手架。只搭建本次会话需要的部分——过早建立结构会将项目尚未做出的决定固化下来。
• 只有在项目确实积累了有争议的决策时，才维护决策日志；否则，“已决定事项与待定事项”字段就够了。空洞的形式化日志会逐渐过时，损害人们对该文件的信任。

每次会话都要在结束前更新该文件——未记录的会话意味着下次又要从冷启动开始。

6. 记忆

如果你的执行环境支持持久记忆，记忆条目必须从上下文文件中提取，绝不能反过来。该文件始终是唯一事实来源，因为队友看不到也无法审查记忆；优先使用记忆的流程会导致项目状态按用户分叉。

• 面谈结束后、§ 4 输出形式之前，将回答写入记忆：先把记录的答案写入上下文文件，再从该文件提取记忆条目。绝不能直接根据回答写入记忆，也绝不能因为答案看起来显而易见就跳过上下文文件。
• 记忆只能存放在以下三个位置之一：用户的本地环境、团队知识库，或 git 仓库中的 memories/ 目录。使用索引文件为其编制索引，并为每个条目列出一行简介。
• 快速重启时，将记忆与上下文文件进行比对。两者不一致时，提出协调方案——默认以上下文文件为准；覆盖任何一方前都要先征求同意。
• 绝不能将以下内容写入记忆：具名个人的个人数据、CRM 记录中的潜在客户或客户个人身份信息、通话录音或转录内容、合同定价、折扣底线、配额和佣金数字。首次写入记忆时，说明这项排除规定。
• 记忆存放在 git 仓库中时，绝不能悄悄提交。每次都要先展示差异并获得批准。

7. 例行流程

如果你的执行环境支持定期运行的流程，请提出 2 到 4 项；创建任何内容之前，必须先以试运行形式展示给用户，每项都要明确输出渠道。没有输出渠道的流程只会制造噪声，用户一周内就会将其静音。

• 成本：不是设置成本，而是每次触发所消耗的注意力，乘以触发频率。
• 价值：当决策仍未定时，将其摆到某人面前的流程。

按这一比率对候选项排序，从高到低，并按顺序提出：

1. 预测前的交易检查 → mbfinotti/sales-skills@deal-red-flags。只需检查销售代表本来就会为这次通话整理的提交清单，成本仅为一次检查；这是唯一一种能在数字正式确定前把虚假交易从预测数字中剔除的常规流程。应安排在预测会议的前一天，绝不要安排在会议之后。
2. 在约定触达次数时设置序列检查点 → mbfinotti/sales-skills@sales-outbound-sequence。每次触发的成本近乎为零，而且能在节奏仍可调整的时间窗口内，促使团队做出停止还是继续的决定。每个序列触发一次，而非按时钟触发。
3. 每月或每季度重新执行本次启动流程。 成本近乎为零，还能让产物和路由保持最新，从而避免其他常规流程在已经不存在的工作上触发。根据 git log 中项目的推进速度调整执行频率。
4. 每月检查发送设置 → mbfinotti/sales-skills@cold-email-deliverability。每月读取一次身份验证和信誉信号；设置正常时毫无额外收益，出现问题的当月则能保住整个季度。应安排在计划提高发送量之前，而非固定在日历日期。
5. 每周复盘一段录音 → mbfinotti/sales-skills@sales-call-review。每次触发成本最高——需要真正阅读转录稿，还要在之后进行辅导谈话；如果没有经理或同事据此采取行动，其结论就毫无价值。只在通话有录音且有人负责辅导的情况下启用。
6. 每季度更新一次来源 → mbfinotti/sales-skills@sales-radar。每年触发四次，成本近乎为零，带来的是信息时效性，而非具体结果。

• 效率：交易检查 > 序列检查点 > 重新执行启动流程 > 发送设置检查 > 录音复盘 > 来源更新
• 价值：交易检查 > 录音复盘 > 发送设置检查 > 序列检查点 > 重新执行启动流程 > 来源更新
• 投入：录音复盘 > 交易检查 > 发送设置检查 > 序列检查点 == 重新执行启动流程 == 来源更新
• 合规成本：录音复盘 > 所有其他常规流程（无）——转录稿包含客户本人的原话，其录制时遵循的录音同意依据适用于这些内容，因此输出渠道必须符合该同意依据和团队的数据政策；其他流程只会输出内部交易和设置摘要。

三者投入并列是实情：每项只需一次近乎零成本的读取，触发频率低，也不需要读者之外的人参与。

来源更新是成本最低的候选项，却是最后才该启用的——这最清楚地证明了低成本和高效率是两种不同的排序。录音复盘的价值排第二、效率排第五：它每周都需要一次读取和一场谈话，换来的是只有在后续通话中才会显现的行为改变。

默认方案：第 1–3 项，共三项常规流程。对外邮件量达到一定规模后，增加第 4 项；只有在通话有录音且有人负责辅导时，才增加第 5 项。绝不要超过 4 项——这一上限能保护真正重要的常规流程，避免它们被那些触发后毫无后续的流程挤占。

此排序只是默认方案，并非铁律；具体排序会随销售方式和执行者而变。根据访谈重新排序，并说明哪些回答改变了哪些排序：

• “约不到会议”（Q4）——将序列检查点和发送设置检查排在交易检查之前。
• 距离配额截止不到两周（Q5a）——只启用交易检查，直到本季度结束。
• 发送者信誉出现问题（Q5b）——在问题解决前，将发送设置检查频率提高到每周一次。
• 受监管的外联（Q5c）——在输出渠道符合录音同意依据之前，不启用录音复盘。
• 无 CRM 或通话录音访问权限（Q5d）——彻底移除录音复盘。
• “一次性，只投入几小时”（Q6）——只启用一项常规流程，即重新执行启动流程，而非四项。
• 如果经理已经每周复盘录音，第 5 项就会重复；应将其降级，而不是对同一通话评分两次。 将触发条件锚定到销售日历上——每周的销售管道或预测会议、月末、季度收尾、团队的节奏复盘日——而不是随意挑选方便的日期。添加新例程之前，先列出并清理上个季度遗留下来的过时例程。

如果运行环境没有定时例程，就改用一个循环日历提醒（“销售检查——重新执行销售启动流程”），到此为止。有关试运行格式、触发条件锚定、优先使用事件触发和清理清单，请参阅 references/routines.md。

8. 调用示例

• “为我们的 SaaS 启动一个新的外向销售项目。”
• “我需要哪项销售技能？我的交易在演示后总是停滞不前。”
• “运行我的销售检查。”
• “我该从哪里开始？我是创始人，从没做过冷外联。”

9. 失败模式

• 强行匹配。 把最接近的技能硬套到它并不涵盖的任务上，会浪费一次会话并掩盖能力缺口。请说“没有合适的”，并指出缺少什么。
• 硬套 CRM/销售管道或渠道/合作伙伴任务。 线索分配、线索评分、销售管道维护、CRM 数据治理和销售预测属于 mbfinotti/revops-skills 的范畴；合作伙伴/渠道策略以及联盟营销/网红营销/推荐运营属于 mbfinotti/partnerships-skills。请改为推荐相邻仓库。
• 跨层级路由。 “我们的配额不合理”“我们的目标客户账号选错了”和“这笔交易卡住了”听起来相似，却分别属于三个不同层级。先确定层级，再匹配关键词；切勿将规划和执行技能混在同一份排序后的候选清单中。
• 仅凭关键词路由招聘/职业问题。 “面试问题”和“30-60-90”可能出现在双方的语境中。根据提问者的身份进行路由；不确定时，只问一个用于消除歧义的问题。
• 在已有上下文的情况下重新访谈。 之所以有这份材料，正是为了避免重复提问。只询问本次会话的目标。
• 根据臆测的范围路由。 只根据 references/skill-routing.md 中明确声明的范围进行路由；听起来合理的猜测也会自信地把用户引错方向。
• 访谈不设上限。 问题超过 7 个，启动流程就会变成用户会放弃填写的表格。应通过检测来补齐信息，而不是靠提问。
• 没有输出渠道的例程。 它们会徒劳触发，随后被静音，反而埋没了真正重要的例程。
• 平铺的候选清单。 看起来同等的选项会按个人偏好或列表顺序被选中。请按单位投入的价值排序，并在每一行点明双方。
• 优先推荐最便宜的选项。 便宜和高效是两种不同的排序方式，只有第二种才能回答“先做什么”。几乎不花成本、却几乎没有收益的例程或技能，只是四舍五入后的误差，并非快速见效。
• 将已排除的技能降级，而不是删除。 如果访谈已将某项技能排除在外，却把它放在候选清单末尾，它两次会话后就会重新成为范围的一部分。请将其删除，或移至“暂不考虑”，并注明解除阻塞的条件。
• 静默提交记忆。 队友看不到落地内容，就无法审核。始终先展示差异并征得批准。
• 路由表过时。 每当技能集合发生变化——新增、重命名、移除或调整范围——都要更新这项技能、references/skill-routing.md、边界配对、技能链和能力缺口列表。过时的路由器会把用户引向已不存在的技能。

10. 通过标准

结束会话前，逐项检查。若有任何一项未通过，先修正并重新检查——不得在未通过的情况下结束会话。

1. 每项推荐技能的声明范围都与所述任务相符——重新阅读其描述以确认。
2. 不得将任务路由到上表 27 项技能之外的名称。
3. 任何招聘与职业发展之间的路由，都必须依据提问者是谁来决定，而非依据主题关键词。
4. 面试不得超出上限：冷启动时最多提问 7 个，热启动时只询问会话目标问题。
5. 会话结束前，必须写入或更新 sales-context.md，其中包括一行会话日志。
6. 每项拟议的例行流程都必须以试运行形式展示，并明确说明输出渠道。
7. CRM／销售管道或渠道／合作伙伴相关任务，必须推荐 mbfinotti/revops-skills 或 mbfinotti/partnerships-skills，不得强行路由，也不得简单地说“没有适合的技能”。
8. 候选清单和例行流程集合都必须按单位工作量所创造的价值排序；每项都要指出它解决的瓶颈及其成本——并且必须明确说明面试回答导致的每次重新排序。
9. 面试排除的每个类别都必须从候选清单中彻底移除，而非放在清单末尾。
10. 候选清单必须只依据一条路径构建——执行或规划；根据会话所处的高度选择其一，且不得将另一条路径上的技能列入其中。

参考资料

• references/skill-routing.md — 涵盖两个高度的边界配对辨析、规划类技能的范围与排除项、有序链、覆盖缺口和同级仓库推荐。处理任何模糊任务前请先阅读。
• references/context-artifact.md — 包含产物模板、一个正例和一个反例。
• references/routines.md — 包含试运行格式、销售日历触发条件锚定、事件触发条件和清理检查清单。