OC
英美烟草集团 用 AI 降本裁员九千人,传统行业的 AI 账单开始落到人头上
科技 · 2026-06-30 · 社会影响 · 阅读 26

英美烟草集团 用 AI 降本裁员九千人,传统行业的 AI 账单开始落到人头上

据 Fox Business 报道,British American Tobacco 计划裁掉约 5500 个岗位,并把约 3500 个岗位外包给第三方公司,总计影响约 9000 名员工。公司称,这轮重组与使用 AI 改造运营、降低成本和提升利润有关,预计到 2028 年实现约 7.93 亿美元年化节省。

Fox Business 报道,British American Tobacco 计划裁掉约 5500 个岗位,并把约 3500 个岗位外包给第三方公司,总计影响约 9000 名员工。公司称,这轮重组与使用 AI 改造运营、降低成本和提升利润有关,预计到 2028 年实现约 7.93 亿美元年化节省。

这条新闻的价值不在烟草行业本身,而在于它说明 AI 裁员已经不是科技公司内部的故事。很多传统行业不会发布华丽的模型,不会办开发者大会,也不会在 X 上晒 agent 截图,但它们会用 AI 改写后台流程、财务共享中心、客户服务、供应链计划和行政运营。最后,变化会落到岗位、外包和成本表上。

OC 原创解释图:AI 降本如何进入岗位和外包流程

当然,不能把 英美烟草集团 这轮裁员全部算到 AI 头上。报道里也提到,公司传统烟草业务长期下滑,消费者转向电子烟、尼古丁袋等替代产品,美国和其他市场监管更严,非法产品也冲击销售。AI 更像是重组工具和成本抓手,不是唯一原因。企业本来就在寻找降本路径,AI 让这条路看起来更快、更好向投资人解释。

这也是普通员工最需要看懂的地方。AI 不一定直接替代某一个岗位,它可能先改变组织设计:某些流程被自动化,某些岗位被标准化,某些工作转给外包商,留下来的员工需要监督系统、处理例外、维护数据和对接供应商。公司口中的“技术赋能”,在员工侧可能表现为“岗位消失、职责合并、工作密度上升”。

沈南乔的判断是,未来很多 AI 裁员不会写在标题里。企业会说自己在做敏捷化、数字化、共享服务、流程优化、外包调整。AI 只是其中一块拼图,但它让管理层更容易把“少人做更多事”写成可执行计划。真正需要追问的是:被自动化的工作是否真的消失了,还是被转移给剩下的人和外包员工?节省下来的钱有没有回到服务质量和员工培训里?

对 OC 读者来说,这不是一个离开发者很远的社会新闻。很多程序员正在写的内部工具、RPA、客服机器人、数据分析 Agent,最后都会进入企业成本模型。技术团队不能只问“能不能自动化”,也要知道这套工具会如何改变一线同事的工作。否则,AI 项目很容易从效率提升变成员工不信任的来源。

OC 不会把这件事写成“AI 抢走 9000 个工作”的简单故事。更准确的说法是:传统行业开始把 AI 放进降本重组方案里,人头、外包和利润目标被放到同一张表上。AI 不是裁员的唯一原因,但它正在成为裁员更容易被包装、推进和量化的工具。

参考来源

相关阅读

基于标题、摘要和正文内容自动匹配。

更多科技

评论

围绕这篇文章补充信息、提出问题或分享观察。

0
暂无评论。

发表评论

继续看看 OC 用户围绕这个话题说了什么、做了什么。

相关帖子

更多

重返OurCoders

<p>从2014年以来好久没逛过这个谈论了,不知道这个谈论的运营现在怎么样,开发人员是不是原来的人,前端UI做得不太好</p>

梁建溢 5 36

一个体会,Codex 这种现代 Agent,每天一个变,几天不用就有新惊喜

<p>当然我说的也包括 Claude Code,新功能日新月异,还有就是 AI 能力提升以后,可以做的东西日新月异。还有各种工作流方法日新月异。</p> <p>更好玩的是,我最近经历过很多次,你跟人介绍现在 Codex 可以做到什么样子,他们都觉得很厉害。但是你现场一演示,他们的震撼就更加完全不同了。所以,这种东西,需要大量的 Workshop 去沟通交流,光看文字很难讲清楚,直播、视频也越来越重要了。</p>

tinyfool 1 89

做 AI 语音产品时,授权、撤回和审计日志应该怎么落地?

<p>最近看到越来越多关于声音授权的讨论。对开发者来说,真正麻烦的往往不是“模型能不能模仿”,而是授权如何进入系统、生成结果如何追溯,以及授权撤回后该怎么办。</p> <p>我们在做 FlowSpeech 时也碰到过类似问题。我的体会是,不要把“用户勾选过同意”当成一个布尔字段,而应该把它做成一组可以审计的业务对象。</p> <h2>1. 把声音资产和授权分开</h2> <p>声音文件只描述技术属性,例如哈希、上传者、存储位置和创建时间。授权记录则至少要包含授权主体、用途范围、地域、有效期、来源证据和当前状态。这样同一份声音用于个人试听、商业广告、公开播客时,可以绑定不同的授权,而不是共用一个模糊的 consent=true。</p> <h2>2. 每次生成都保存授权快照</h2> <p>生成任务不要只引用当前授权 ID。授权内容以后可能变更,如果任务只查最新状态,历史结果就无法解释。更稳妥的做法是在任务创建时保存授权版本、文本哈希、声音版本、模型版本和操作者。生成出的音频再记录 artifact_id,并反向关联任务。</p> <p>我会把最小链路设计成:</p> <ol> <li>voice_asset:原始声音及版本;</li> <li>consent_grant:授权范围与证据;</li> <li>generation_job:请求参数和授权快照;</li> <li>audio_artifact:输出文件、校验值和公开状态;</li> <li>audit_event:谁在什么时候创建、下载、公开或撤回了内容。</li> </ol> <h2>3. 撤回不是简单删除一行</h2> <p>授权撤回后,系统至少要阻止新任务,并把相关公开音频进入下架队列。已经交付给客户的文件是否能删除,要按照合同和产品能力区分,不能在界面上承诺技术上做不到的“全球删除”。更现实的状态机是 active、suspended、revoked、expired,并明确每个状态允许哪些动作。</p> <h2>4. 对外展示也要可验证</h2> <p>除了后台日志,公开音频最好带上来源标记或可查询的生成记录。水印不是万能方案,但“可识别的音频 + 可验证的元数据 + 清晰的举报入口”组合起来,比一句“AI 生成”更有用。</p> <p>我们现在做的 <a href="https://flowspeech.io/zh">FlowSpeech</a> 主要解决上下文感知、情绪和停顿控制。越往产品化走,越觉得声音效果只是前半程,权限边界和可追溯性才决定这类工具能不能长期使用。</p> <p>大家在实际项目里会把授权证据放在业务数据库、对象存储,还是单独的审计系统?如果授权撤回,你们通常怎么处理已经生成并交付的音频?</p>

FlowSpeech 0 1