今年 2 月 9 日，北京时间深夜，全球数以千万计的开发者打开 GitHub，看到了同一个页面。

不是 404，比 404 更让人焦虑——是那个让所有工程师后背发凉的黄色警告条，加上状态页上一排排从绿色变成红色的指示灯。

github.com 挂了。

API 挂了。

GitHub Actions 挂了。

Git 操作挂了——就连 Copilot 也没能幸免。

那一晚，有人的 CI/CD 流水线在最关键的节点停摆，有人的自动化部署卡在了半空中，还有人在等待一个迟迟无法合并的 PR——背后是一个等待上线的功能，等待的是真实用户。

事后 GitHub 发布了事故报告。根本原因，用技术语言说，是「一个负责认证和用户管理的，核心数据库集群过载」。但这几个字背后藏着一条触目惊心的触发链——

两天前，工程团队为了尽快给用户推送一个新模型，把一个「用户设置缓存」的刷新时间从 12 小时改成了 2 小时。就是这一个配置数字的改动。

结果，本来分散在 12 小时内完成的缓存重写，被压缩进了 2 小时，形成了一次密集的「缓存重写风暴」，异步任务队列被瞬间打爆，共享基础设施组件崩溃，连锁反应蔓延到了负责代理 HTTPS Git 操作的服务，最终导致整个平台的连接耗尽。

一个数字，从 12 改到 2。

GitHub，是被自己改的一个配置打穿的。

但如果你只看到这一个配置改动，那你大概错过了这个故事最重要的部分。

01 不是一次意外，是十次意外

2 月 9 日的事故，不是一个孤立事件。

事实上，2026 年的前三个月，GitHub 经历了至少 8 次重大事故。2 月份单月就有 37 次大大小小的故障记录。GitHub 的 CTO Vlad Fedorov 后来在博客里承认，这两个月 GitHub 没能维持它向企业客户承诺的「三个九」——99.9% 可用性。

翻开这两个月的故障档案，你会发现一个奇特的规律：每一次事故，看起来都是不同的原因。

2 月 2 日：Azure 计算提供商出问题，GitHub Actions 停摆近 4 小时，Copilot 编码代理、CodeQL、Dependabot 全部受牵连。

2 月 9 日：缓存重写风暴，认证数据库过载。

3 月 5 日：Redis 集群故障，GitHub Actions 95% 的工作流无法在 5 分钟内启动，平均延迟 30 分钟。

3 月 18 日：Webhook 延迟飙升到正常水平的 32 倍。

每一次看起来都是「意外」，每一次的直接原因都不一样。但 Fedorov 的解释把它们串成了同一个故事。他说，这些事故背后有三个共同的结构性原因：「快速的负载增长、服务之间的紧耦合导致局部故障扩散，以及系统缺乏对异常客户端的流量保护能力。」

用工程师的话说，GitHub 的地基，已经开始在新负载的重压下出现裂缝。

而这个「新负载」，有一个具体的名字。

02 每周 2.75 亿次提交

关键数据

2025 年全年 commit 总量：约 10 亿次

2026 年单周 commit 量：2.75 亿次

按此速度，2026 年全年预计：140 亿次（同比增长 14 倍）

GitHub Actions 计算量：2023 年每周 5 亿分钟 → 2025 年 10 亿 → 2026 年初某周 21 亿分钟

如果你是 GitHub 的基础设施工程师，2025 年和 2026 年的监控仪表盘对比，大概会让你目瞪口呆。

2025 年全年，GitHub 处理了大约 10 亿次代码提交。这个数字本身已经很大了，是 GitHub 平台多年积累的结果。但到了 2026 年，单周的提交量就达到了 2.75 亿次。换算一下——如果按这个速度走完全年，2026 年的总提交量将接近 140 亿次，是 2025 年全年的整整 14 倍。

这不是一条平滑增长的曲线，而是一道陡坡。GitHub 的 Actions 计算量变化更能说明问题：2023 年每周消耗 5 亿分钟，2025 年翻倍到 10 亿，然后在 2026 年初的某一周，直接飙到了 21 亿分钟。

是什么在疯狂提交代码？

不是人类开发者。

GitHub 的数据显示，AI Agent 正在成为这个平台上最活跃的「用户」。Claude Code 单独一个工具，现在贡献了 GitHub 所有公开仓库提交量的 4.5%。每周 260 万次提交，而在 2025 年 9 月底，这个数字还只有 10 万——三个月内增长了 25 倍。

AI Agent 开启的 PR 数量同样在爆炸。2025 年 9 月，AI 生成的 PR 大约是每月 400 万个，到 2026 年 3 月，这个数字跳到了 1700 万——四倍多，半年内。

有一个画面可以帮你理解这意味着什么。

以前，GitHub 的「用户」主要是人类程序员。他们白天工作，晚上睡觉，周末休息，每次提交会思考，会犹豫，手速有上限。系统的负载跟着人类的作息走，有峰谷，可以预测。

现在，越来越多的「用户」是 AI Agent。它们不睡觉，不休息，不犹豫，一个任务可以同时开多个并行的 Agent，每个 Agent 每小时的提交量，轻松超过一个真实工程师一周的工作量。更重要的是，它们不只是在提交代码，还在不断创建新仓库——把仓库当成工作流的「输出产物」，而不是人类的「工作空间」。

GitHub 的基础设施工程师们，面对的已经不是一个流量更大的同类问题，而是一个性质完全不同的问题。

03 Copilot 的钱不够烧了

故障频发只是问题的一面，GitHub 还有另一个更让人头疼的麻烦——算账的时候发现亏了。

Copilot 最初的定价逻辑，建立在一个合理的假设上：用户主要是「辅助补全」式的使用，每次交互是短暂的，计算量可预测。个人版每月 10 美元，商业版每月 19 美元，按座位收费，这个模型在过去几年里运转良好。

然后，Agentic AI 来了。

Agentic 工作流和传统补全是两个物种。标准的代码补全，请求是线性的、可预测的，计算周期短暂。而一个 Agentic 编码 session，可能运行几个小时，同时启动多个并行线程，进行多步推理、自我纠错、跨仓库重构——一个 session 消耗的 token 量，轻松超过一个普通用户一整月的订阅费用。

GitHub 面对的局面是，少数重度 Agentic 用户，正在用几美元的月费消耗相当于几百美元的计算资源。

面对这个局面，GitHub 的反应很直接——先控流，再改价。

今年年初开始，GitHub 对 Copilot 启动了两套并行限流机制：session 时长上限和每周使用量上限，两个维度都按照 token 消耗量乘以模型计算权重来算。与此同时，部分个人 Copilot 套餐暂停了新用户注册。

6 月 1 日，GitHub 完成了更根本的定价改革：Copilot 全面切换按用量计费，用「AI Credits」取代原来的套餐费用，1 个 AI Credit 等于 1 美分，使用量按 token 消耗实时计算。

按座位收费的时代，在 Agentic AI 面前，走到了终点。

这个转变不只是 GitHub 的烦恼。这是整个 AI 工具行业在 2026 年正在经历的一次集体定价危机——当 AI 开始替代人类执行完整的工作流，而不只是「辅助」人类工作时，所有基于「每人每月」的订阅逻辑都会失效。

04 30 倍，不是 10 倍

回到基础设施问题。GitHub 到底准备怎么应对这个「14 倍增长」？

这里有一个细节，能说明问题的严峻程度：

2025 年 12 月下旬，Agentic 工作流突然开始加速。GitHub 的工程师们意识到，10 倍不够。到 2026 年 2 月，也就是那次严重停机之后，GitHub 宣布需要按照今天规模的 30 倍重新设计架构。

不是扩容，是重新设计。

这两个词的区别很大。扩容是把现有的机器变多、把现有的数据库加内存——方向不变，只是规模变大。重新设计意味着，现有的架构假设在 30 倍规模下会系统性失效，必须从底层重新思考服务拆分、数据流、故障隔离的方式。

GitHub 披露的具体方向包括，解耦关键服务以防止级联失败、引入背压机制和流量降级能力、为热点服务部署独立主机、消除单点故障，以及更完善的变更管理——避免「把缓存 TTL 从 12 小时改到 2 小时」这种操作在没有充分压测的情况下直接上线。

值得注意的是，GitHub 并不孤单。

Stripe 已经遇到了 AI Agent 批量创建账户的问题，AWS 正在构建 Agent 专用的身份系统、日志系统和生产控制机制。这些动作不是未雨绸缪，而是监控仪表盘上已经出现了它们不得不解决的信号。

GitHub 只是第一个被打穿的——因为它在 AI 工具链的最核心。

05 代码仓库，正在变成 AI 的排气管

停下来想一想这整件事的性质。

GitHub 是什么？最直观的回答是，它是程序员存代码的地方。但更深一层，它是人类软件协作的基础设施——提交记录是协作的轨迹，PR 是讨论的容器，Issues 是意图的留存，Action 是执行的管道。整套系统，是为人类的工作节奏、思维方式和协作模式设计的。

AI Agent 改变了这一切。

当一个 AI Agent 一天可以提交几百次代码，每一次「提交」背后没有人类的思考和权衡，只有一个任务循环的进度步骤——代码仓库还是「协作的容器」吗？

当 AI 工具自动生成仓库、自动开 PR、自动跑 CI、自动 merge——开发者还是这个流程的主体，还是说他们已经退化成了「审核者」甚至「旁观者」？

GitHub CTO 在描述这次危机时，用了「负载快速增长」这个词。但这个词很可能低估了问题的本质——这不只是量的增长，是使用方式的质变。在旧模型里，GitHub 是「开发者的工具」；在新模型里，GitHub 正在变成「AI 的排气管」，一个自动化工作流的输出管道。

这对 GitHub 意味着什么，其实还没有答案。30 倍扩容能解决流量问题，但解决不了商业模式的再定义，也解决不了「谁是我的真正用户」这个身份问题。

最近有一个颇为意味深长的现象：GitHub 在停机之后开了大量工程博客，非常详细地描述了每一次事故的根本原因，几乎达到了令人意外的透明程度。有人认为这是 GitHub 在主动建立信任，也有人认为这是在以透明度换取开发者社区的耐心——因为接下来的重构期，还会有更多不稳定。

一个平台，在被自己的成功打穿之后，需要把自己拆开重建——而这个过程本身，也是一次能不能撑住的考验。

2 月 9 日那晚，那个等待 PR 合并的工程师，大概最终还是等来了绿灯。但他可能没有意识到，让他等待的那次宕机，不是 GitHub 的一次意外，而是整个软件开发行业进入新时代的一声响动。

作者：宇航猿

来源：极客公园

这两年，AI 修图已经不是什么新鲜事了，调色、背景模糊，到皮肤细节的打磨，几乎都有专门的工具能处理。但说到抠图，还真就是 AI 修图工具里最难搞的一部分。

但抠图这件事，说小也小，说烦也是真烦，虽然它看起来只是把背景擦掉，实际却特别挑场景，比如人像头发、衣服边缘、产品反光、透明材质、复杂光线，这些地方一个没处理好，抠出来的图就是几乎不可用的状态。

实际上，很多用户并不是想做什么高级设计，只是单纯想换个头像、抠个商品主图、做个封面素材，但是一大堆专业工具难搞又复杂，学习成本还高。不过，近期 AI 抠图开源工具已经在 GitHub 上如雨后春笋般涌出来，有专门制作头像的、万物皆可抠的，还有主打 5 秒内出图的。

（图源：magicpfp）

但这些 AI 抠图，真如开发者们说的那样好用吗？是骡子是马，我们还是得拉出来遛一遛才知道。

让 AI 抠图？很快、但质量不高

这次我们试的三个工具都是在 GitHub 上讨论度挺高的，分别是 magicpfp、RMBG 和 remove-bg。这三个工具虽然都是把图片背景抠掉，但背后的思路其实不太一样。比如magicpfp 更像一个为头像场景做的小网页，重点不是“万物皆可抠”，而是让用户上传一张人像，顺手把去背景、换背景、头像美化这一套流程做完；RMBG 更像一个通用型的本地抠图工具，主打免费、隐私和本地处理；remove-bg 则是一个更全面的工具，它直接把 WebGPU、Transformers.js 和 RMBG V1.4 这套东西塞进浏览器里，让本地前端去处理。

从技术上看，这些工具的原理几乎都是一致的，像 magicpfp 和 remove-bg 都明确标注使用了 BRIA 的 RMBG-1.4，remove-bg 还用了 Transformers.js 来调模型，尽量在浏览器本地完成推理。

简单来说，这类工具不是在“拿橡皮擦图片”，而是在让模型判断，图片里哪些像素属于主体，哪些属于背景，再生成一张带透明通道的结果图。当然，之所以大家都盯上这套工具，本质上还是因为WebGPU、WASM 和前端模型调用这套能力比前几年成熟得多了，浏览器性能也强多了，可以在前端干活了。

从实际体验看，magicpfp 虽然功能有限，但是自由度是最高的一个。magicpfp 只能制作头像，也就是它 AI 识别的对象必须是人物，其实头像本来就是最标准化的一类图片任务，主体通常清楚，构图也相对固定，没必要上来就挑战复杂商品图。

（图源：the verge）

（图源：雷科技制图/magicpfp）

我们拿了马斯克的一张新闻图给 magicpfp，人物主体抓得还算稳，头、手、上半身这些主要结构都保住了，没有出现手指缺一块、衣服被啃掉一截这种低级错误，拿去做社交头像是够用的。问题在于它的边缘并不算干净，头发顶部有明显溢边，肩膀和手臂外轮廓也有一点彩边，左下角甚至还顺手把椅子给捎上了一点。

不过呢，好在它支持调整，背景颜色、边缘、尺寸，这些都能重新做，小小的失误是可以接受的。但很可惜，magicpfp 毕竟只是一个非常小的个人项目，所以它整体的生成速度是比较慢的，远不及直接拿 AI 去生成一张。

（图源：雷科技制图/magicpfp）

RMBG 的感觉就完全不一样了，它更像一个“我不管你好不好看，我先把活干完”的工具。首先，RMBG 是一个本地 AI 工具，不用注册，不用把图传到服务器，也不会担心这个工具要收费。

上手来看，RMBG 也是很典型的「能做，但效果一般」的角色，奥特曼那张新闻图，主体轮廓是完整的，脸、脖子、肩膀都没出大问题，但头发和肩部边缘还是有比较明显的绿色残留，像是背景剥掉了，脏边却没擦干净。让 RMBG 抠广告图里的手机，它确实知道前景是谁，把手和手机主体都保住了，没有傻到把整个场景都留下来，可手机右侧、手指周围的红黄杂边相当明显，边缘还有一点虚，暖色环境光和背景高光像是一起粘在了主体外轮廓上。

（图源：雷科技制图/RMBG）

只能说，这样的效果用拿来商用可能是差一点，最多只能是视频里的贴图素材，再放大一点就要露馅。当然，RMBG 自己也说，目前仅仅能提供个人需求用途，还不到商业用途的水平。

来到 remove-bg ，熟悉 AI 抠图工具的朋友对这个项目应该不陌生，它以高质量和超快速著称。实际体验下来也的确是这样，比如那张手机广告图，它对主体的判断比 RMBG 更干净，手机轮廓、手指边缘、顶部弧线这些容易翻车的位置都处理得更稳，刺眼的彩边少了一截，直接商用可能都不太会被发现。

（图源：华为）

（图源：雷科技制图/remove-bg）

马斯克那张图也是这样，像是头发、肩膀、双手交叠这些区域虽然还是有轻微瑕疵，但整体脏边感明显更轻，左下角乱入的内容也更少。

（图源：雷科技制图/remove-bg）

整体看下来，这三款工具的差距倒也不是那么明显，只是它们各自的特色太鲜明。比如magicpfp 更像头像场景的小成品、RMBG 最高支持 20 张图一起生成、remove-bg 的抠图效率高，成品也很接近直接可用的程度。但如果要拿来和 PhotoShop 上用钢笔工具一点一点抠出来的精品图，那这三个工具几乎没有合格的。

普通人或许不需要最完美的抠图

实测做完之后，一个很直接的感受就是，这几个开源工具当然还远没有到把成熟商业产品干翻的程度，但它们明明还有一堆毛病，却已经把一件过去默认得交给云端平台去做的事，搬回了浏览器和本地，而这才是这项工具的趋势。

前面我们就提到，之所以 AI 抠图工具不断升级，都是因为 WebGPU 的不断进化。过去浏览器当然也能跑很多东西，但真碰到 AI 推理这种活，网页环境一直有点力不从心，原因不复杂，老一代 WebGL 更偏图形渲染，做通用 GPU 计算并不顺手，而机器学习这类任务恰恰又很吃并行计算能力，所以很多 AI 功能以前只能放在服务器上跑，浏览器更多只是个上传下载的壳。

WebGPU 不一样的地方就在于，它一开始就把现代 GPU 的图形能力和通用计算能力都更完整地暴露给网页，Google Chrome 这些年也一直拿机器学习推理做典型案例，强调 WebGPU 能让浏览器更高效地调用本地 GPU 去做高性能计算，这才让网页开始有点像一个真正能跑 AI 的轻量运行环境。

（图源：RMBG）

也就是说，在 AI 抠图这件事上，以前用户点一下抠图按钮，真正干活的是远端服务器，浏览器只是负责把图片传过去，再把结果拿回来，所以 SaaS 工具的优势非常明显，效果统一、速度稳定，不需要担心自己的设备能否跟得上。可 WebGPU 出来之后，浏览器开始能直接借本机的 GPU 干活，很多轻量模型就有机会在本地完成推理，图片不用先上传，等待路径也更短，尤其在背景移除这种相对标准化、目标又比较明确的任务上，这种变化会显得特别明显。

现在的模型量级越来越轻，浏览器越来越能算，调用方式也越来越现成，于是像背景移除这种能力，就不再非得做成一个上传到云端再返回结果的闭环，而是可以被拆成网页、小组件、插件，甚至设计工具里的一个内置模块。

所以说，即便从实测来看，这些 AI 抠图工具的表现都挺一般，没有真正能和专业工具媲美的，但就是架不住大家的喜爱，这就是因为多数普通人并不需要非常完美的图，只需要一个快速、基本能用的图。

抠图只是前奏，更多 AI 工具正在本地化

实际上，AI 抠图之所以得到大量关注，真正值得被看见的还是关于「AI 小工具正在大量本地化」，很多原本必须交给云端去做的轻量 AI 任务，已经开始具备在本地完成的条件了。

抠图只是这波变化里最明显的，因为它高频、标准化、结果又很直观，用户一眼就能看出好不好用，所以特别适合率先本地化。后面很可能跟上的就不只是图片处理了，像图片放大、简单修边、证件照处理、商品图白底化这种任务，本来就和抠图一样，规则清楚、交互短、模型也相对可控，很容易继续依附浏览器本地推理这套能力发展下去。

不仅仅是针对图片的处理，像是音频转写、字幕生成、网页摘要、翻译、分类、轻量 OCR、页面内容提取，这些同样高频、轻量、结果容易验证的工具，也都很有机会沿着类似路线走，因为它们本质上都符合一个条件，就是没有复杂到非得把任务扔去云端才能完成。

（图源：remove-bg）

所以从这个小小的 AI 抠图工具来看，未来很多 AI 功能未必还会以独立网站/App的形式存在，它们更可能变成浏览器里的一个按钮、设计软件里的一个模块甚至是某个插件里默认开启的能力。对用户来说，这当然是好事，操作更短，隐私顾虑更少，很多小需求也不必再专门跑去一个 SaaS 平台解决；但对行业来说，很多原本独立存在的应用或网页，都没有必要存在，尤其是一些小功能，都可能在这套逻辑下，慢慢被取代。

来源：雷科技

最近在GitHub上刷到一个项目：coreyhaines31发布的marketingskills。

这个项目上线不久就冲到了22k星。它不教你写文案，而是专门为AI Agent构建了一整套“营销大脑”。它把CRO、文案框架、SEO策略到增长工程，几乎所有高阶营销人的专业框架，全部封装成了AI可以直接调用的“技能包”。

看到它的第一反应是：Product marketing 员工也开始要被蒸馏了？

为了验证它是否真的能打，我拿手中一个“快消终端铺货指导”的B2B产品做了实战测试。结果还是不错的：原本需要团队耗时2周的GTM落地工作，我一个人调用技能库，半天就完成了高质量交付。当然也有不少要小休小改的地方。

一、 核心区别：为什么普通大模型做不好B2B营销？

在展示实战效果前，我们先聊聊痛点。很多营销人觉得AI不好用，是因为直接调用的 Claude 或 Gemini 虽然表现不错，但是和to B行业的knowledge及product markting /GTM体系化需求结合的不够。

1. 普通大模型的瓶颈：只会编文案，不懂营销框架

如果你对普通大模型说：“帮我写个销售话术和竞品分析”，它给你的通常是：

• 满屏套话：全是“提高效率、降低成本、赋能增长”这种放之四海而皆准的废话。
• 结构散乱：它不懂快消行业“终端执行→动销结果”的因果逻辑。
• 二次加工成本极高：你拿到的只是一堆文字素材，还需要花3天按营销框架重新拆解。

2. marketingskills 的降维打击：它是框架的自动化

当你加载了这个技能库，AI就从“文字搬运工”变成了“高级营销顾问”。它输出的不再是孤立的文字，而是基于专业营销框架生成的交付物。

它懂的就不再只是“怎么写”，而是“怎么赢”。

二、 底层逻辑：它到底在AI Agent里植入了什么？

很多人误以为这是一个新的AI模型，其实不然。它的本质是“给AI预装的35个专业工具箱”。

它的底层逻辑非常清晰：把营销人沉淀多年的工作流程（Workflows），通过代码化的方式变成了AI的原生技能（Skills）。每一个技能都对应一个真实的实战场景，比如：

• sales-enablement：不再从零开始写PPT，而是按销售赋能框架一键输出物料大纲。
• content-strategy：不再瞎猜选题，而是基于流量逻辑规划全年营销方向。
• pricing-strategy：直接调用B2B SaaS分层定价模型，而非拍脑袋定价。
• battlecard：精准拆解竞品短板，把攻防话术应对客户售前的挑战。

这就是核心区别：普通AI需要你一点点教它“什么是B2B逻辑”；而加载了该库的AI，默认就带着这些逻辑进场。

三、 实战复盘：To B新产品GTM计划

我以工作场景为例，对新产品Go-to-market 场景做了个测试：

1. 全年GTM计划：贴合B端业务场景理解

我通过调用 copywriting、pricing-strategy 和 analytics-tracking 等技能，生成了一份计划。

这里说明：智能体本身就有规划和自主调用不同需求对应skill的能力，所以侧重点也可以优先放在自身业务的描述，而非指导怎么调用。

可复制的提示词模板：

你现在是我的专属B2B营销顾问，并且你已经加载了本地安装的所有营销技能。

我正在推出一款面向快消零售客户的「终端铺货指导」产品，请你用这些技能，为我制定一份完整的全年GTM（Go-to-Market）计划，要求如下：

1）先调用 competitor-alternatives 和 content-strategy 技能：帮我分析市场竞品，提炼出这款产品的独特价值主张（USP），要明确它解决了快消客户的什么核心痛点，和市面上其他工具/服务的差异化在哪里。

2）调用 pricing-strategy 技能：基于B2B SaaS定价模型，为这款产品设计分层定价策略，包括入门版、标准版、企业版的定价、权益和适用客户。

3）调用 analytics-tracking 技能：把全年GTM拆分为「冷启动期、增长期、成熟期」三个阶段，每个阶段都要有：

-核心目标

-关键任务拆解

-可量化的KPI指标（线索量、转化率、付费率等）

4）调用 lead-magnets 和 email-sequence 技能：为每个阶段设计配套的营销内容和获客渠道，包括：

-冷启动期：行业报告、白皮书、案例模板等引流钩子

-增长期：短视频内容、行业直播、客户案例拆解

-成熟期：老客户转介绍、客户成功故事、行业沙龙

同时生成一套对应的邮件序列，用于线索培育和转化。

5）调用 page-cro 和 copywriting 技能：为产品的官网落地页、销售话术、产品介绍文案做优化，重点突出USP和客户价值，提升转化效率。

6）最后，调用 analytics-tracking 技能：给我设计一套完整的效果追踪方案，包括每个渠道的追踪指标、数据看板建议，以及不同阶段的优化调整机制。

整个计划要贴合快消零售行业的特性，可直接落地执行，不要给我通用模板，所有内容都要围绕「终端铺货指导」这个产品来展开。

实战反馈：

它没有给我SaaS通用的模板，而是精准抓住了快消客户“执行看得见，结果说不清”的痛点。竞品分析部分，它直接将传统巡店SFA（打卡逻辑）与我的产品（结果验证逻辑）进行了深度切割，并提炼出了行业客户的场景痛点等问题。此外，GTM的计划框架还是非常完整，且符合行业特性的。

2. 销售赋能工具包：直接可交付的“核武器”

有了框架，我让它调用 sales-enablement 技能，一键生成全套物料。

可复制的提示词模板：

我现在需要为【快消零售行业·终端铺货指导/终端稽查产品】制作一整套专业销售赋能工具包（Sales Enablement Kit）。

请你自动调用你已安装的相关技能：sales-deck、battlecard、elevator-pitch、case-study、sales-email、sales-enablement 等技能，按照专业B2B销售物料标准输出全套内容。

产品核心：

-面向快消品牌方/区域经理/销售总监

-解决终端铺货率低、陈列不标准、稽查成本高、数据滞后、执行Gap看不到的问题

-模式：众包终端稽查 + 铺货Gap洞察 + 季度化落地交付

请严格输出以下5类销售工具，结构清晰、语言专业、可直接对外使用：

1）Sales Deck 核心结构（可直接做PPT）

2）Battle Card（竞品对比、攻防话术）

3）Elevator Pitch（30秒客户开口话术）

4）High-Level Email Letter（给销售总监/老板的初次触达邮件）

5）Case Study 框架（客户成功案例模板，可直接填空）

要求：

1.全部围绕快消铺货/陈列/稽查场景

2.语言商务、专业、可直接发给客户

3.不要泛内容，全部贴合我的产品

4.结构清晰，可直接复制进PPT/Word

实战反馈：

• 一套完全贴合快消场景的 12 页 Sales Deck 大纲，连每页的演讲要点都写好了，后面我要求给到md格式，放到NotebookLM生成的PPT还不错。
• 精准拆解了传统 SFA / 纯调研 / 纯众包三类竞品的 Battle Card，攻防话术直接能用。
• 从 30 秒高管话术、高层冷邮件，到客户案例模板，这里需要优化的空间还是挺大的。
• 本质是「用营销人的专业框架跑流程」，直接输出你要的交付物，不用二次拆解。

四、 深度复盘：它不是银弹，但它是“放大器”

在享受这种极致提效的同时，我也发现了它的边界：

1. 它能放大你的专业，也能放大你的平庸：AI提供的只是专业框架，如果你对自己产品的核心价值思考不透，生成的框架再漂亮也打不动客户。
2. 它是“效率工具”，而非“决策工具”：它负责提供大脑，搭骨架、写大纲、做模板，你负责填入真实的行业数据和最后的决策点。

写在最后，给B2B营销人的3个AI建议：

1. 拥抱“框架式AI”：停止无意义的聊天，开始用这种把专业知识“代码化”的工具。
2. 流程即资产：把你的GTM、销售赋能路径拆解成可复用的提示词，这才是你在AI时代的护城河。
3. 专注“行业认知”的厚度：把80%的可被提炼方法论的工作交给AI技能库，把剩下的时间用在洞察客户和产品决策上。