营销、销售、客服如何用上 AI？从岗位插件到完整工作流程

“你们能不能把每周报表自动发给门店？”

营销觉得这句话适合写进活动页，销售想据此安排演示，客服担心客户把“导出报表”理解成了“自动发送”。大家都在认真做事，但只要其中一人把尚未支持的功能写成承诺，后面的人就得补救。

岗位插件适合处理这种重复工作：把资料、判断步骤和交付格式放在一起，让下一次任务有章可循。这篇用一家虚构的报表软件公司“青禾”串起营销、销售和客服。你可以直接复制资料练习；文中的示例产物是教学参考，不是客户实绩，也不代表模型每次都会给出相同答案。

社区里的三个岗位精选包，源自 Anthropic 的 Knowledge Work Plugins，由 Onevium 独立整理适配。它们保留原作者、Apache-2.0 许可、固定来源版本和修改说明；不是原仓库的全量镜像。

这些包不附带业务系统连接器。先用手边的文件就能练习，模型连接仍需单独准备。插件许可不包含模型用量、CRM 或其他服务的费用。

青禾想用一周时间邀请门店负责人预约演示。交给 AI 的资料可以很短：

品牌：青禾，面向 5–20 家门店的小团队。
已支持：手动导出 CSV；按门店查看每周销售额。
未支持：定时发邮件；自动给门店经理发消息。
活动：一周内邀请现有订阅邮件的读者预约演示。
预算：只用已有网站与邮件草稿，不投放广告。
目标：让有每周汇总需求的负责人预约，目标数由团队确认。
语气：具体、平实，不写“彻底解放”“提升十倍”。

调用 campaign-plan，要求给出一周安排、每份内容的目的和需要谁补充的信息。接着把拟发布文案交给 brand-review。例如，“从此报表自动到达每位店长邮箱”应该被指出与产品事实冲突，并改成“按门店整理每周销售额，导出 CSV 后与同事分享”。

检查活动计划时，先看它有没有替你捏造目标和历史成绩。没有过去的打开率，就保留待填；团队尚未批准的预约数量，也不能写成保证。具体的营销方法来自上游营销插件，这里的产品与活动资料由我们设计。

活动收到一条咨询，销售拿到这些信息：

线索 L-17，松林门店，8 家门店。
来源：客户主动提交的咨询表。
客户原话：“每周五都要合并 8 张表，希望少做一点重复工作。”
尚不知道：表格字段是否一致、谁负责合并、最终给谁看。
会议：明天 20 分钟产品演示。

用 call-prep 准备会谈，附上营销那份产品事实。期望得到的是一张能带进会议的简报：已知需求、三个待问问题、适合演示的功能和不应承诺的能力。

好问题会接着客户的话往下问：“8 张表的列名和统计周期一致吗？”“汇总之后谁做决定？”“你最想减少的是收集、合并，还是发送？”它们比“贵公司的数字化战略是什么”更接近这次会谈。

account-research 可用于补充公司背景，但没有可靠来源时就停在已提供资料。客户有 8 家门店，不代表已经知道采购预算，更不代表负责人已经同意购买。本文的重点是准备会谈；会后如何形成可审核的记录，可以接着看客户跟进实践。

试用第二天，客户发来工单 T-104：今天 09:20 起，CSV 导出显示空白；两位同事在 Chrome 复现；查看已有报表仍正常；未报告数据丢失；希望中午前恢复。团队还没有确认原因，也没有承诺修复时间。

给 ticket-triage 的请求可以直接写：

根据上述 T-104 整理分流草稿。
分开写已知事实、未知信息、优先级理由、建议接手团队和首次回复。
没有提供历史工单库，不要声称已经查过重复问题。
客户希望中午恢复，不等于我们承诺中午修好。
只生成草稿，不发送回复或创建工单。

你应该能从结果里找到“导出受影响，已有报表仍可查看”；根因栏应保持未确认；首次回复可以说明已经收到反馈、下一步需要收集什么，不应擅自答应修复时间。优先级要附理由，并与团队自己的标准核对。

问题真正解决后，再把经确认的处理步骤交给 kb-article。如果只有猜测，知识库草稿也应停在待确认状态。AI 写得再流畅，都不能替一次没有发生过的验证签字。

实际试跑中，我们还抓到一个问题。插件正确读到了工单，也没有承诺中午修好，但首次回复写了“我们已将这个问题标为高优先级，正在排查原因”。练习只要求生成草稿，并没有发生分派或排查。发送前应该改成“我们已收到您的反馈；还需要确认影响范围和复现步骤，随后由团队安排排查”。它还把“未报告数据丢失”改写成了“目前没有发现数据丢失”；这两句话证据强度不同，也应恢复成前者。

这次试跑说明了为什么最后一遍要由人读：除了查错字，还要把每一个“已经”对照真实发生过的动作。

三个岗位不必共享所有聊天记录。这个案例里，值得传递的是：

插件能帮你整理这些材料；把不同包自动接成一套系统，还需要另外设计触发、传递和授权。这篇的练习由你逐步调用、检查，再把必要结果交给下一步。

第一次只选最常卡住的一环。比如每次开会都要重新翻客户背景，就先做会前简报。等你能指出“这次少了哪条关键信息”，再把它补进流程。

在 Onevium 里打开左侧插件。这次用的是 Onevium 精选中的社区岗位包，名称是：营销岗位精选、销售岗位精选、客服岗位精选。上游原作者和许可仍保留在包内，Onevium 负责这份精选适配。

先在页面上方的作用范围选择练习项目，再找到需要的岗位包，点击卡片旁的添加。安装窗口中核对包名、版本、发布者、包含的 Skill 和启用范围，阅读内容后点安装并启用。回到目录，确认该包在当前项目显示为已启用，再开始新一轮会话。

如果目录还没显示新包，打开来源 → 检查更新，等目录读取成功后再找。这里不需要下载 ZIP、导入 JSON 或运行准备脚本。

打开已安装包的详情，查看在对话中使用，取用界面列出的完整名称。例如本篇可以用 /onevium-customer-support-essentials:ticket-triage，再附上前面的任务和资料。也可以直接让 AI 使用这个已安装的 Skill。第一次运行时检查过程里是否加载了正确 Skill、读取了指定资料，然后按本文的核对点审阅结果。

文章里的公司和数字都是虚构练习。客服案例包含一次实际调用的观察；其他案例给出的是可复算的参考答案，不代表所有 Skill 都经过业务实测。更多入口说明见插件教程和Skills 教程。社区的开源仓库用于查阅源码、许可和适配记录。

青禾和松林都是虚构公司。换成自己的工作时，重新核对产品事实、对象、日期和允许操作的范围，不把练习中的承诺带进真实业务。

这套方法的价值，会体现在下一份简报和下一张工单里：同事能看懂依据，知道哪些已经确认，也知道该接着问什么。需要处理经营数字与合同的团队，可以继续读数据、财务与法务的岗位实践。