AI 没让打工人轻松，只让老板更会派活

晚上 10 点 47 分，群里弹出一条消息。

“这个方案明早 9 点前给我，AI 跑一下很快。”

你盯着手机看了三秒。

这活以前至少排两天：要翻客户资料、拆竞品、补数据口径、写 PPT、对齐销售口径，再找产品确认两处边界。现在老板看你白天用 AI 十分钟生成了一版初稿，就自动完成了一次单位换算：

以前：2 天
用了 AI：10 分钟出初稿
所以：今晚必须交终稿

更要命的是，他不是只压缩这一件事。

周一让你“用 AI 出 5 个方向”，周二让你“每个方向都细化一下”，周三说“既然 AI 能做，那就顺便把竞品、预算、落地排期、风险预案也补上”。最后你发现，AI 确实帮你省掉了一部分打字时间，但省出来的时间没有回到你身上。

它被老板自动吞掉了，换成更多任务、更短 deadline、更多临时返工。

参考文章里那个场景很典型：以前人不在电脑前，老板多少还知道“这事得明天到公司再处理”；现在微信小程序、远程电脑、Agent 工作台一出来，老板终于找到了新的话术：

“你用 AI 搞一下，很快的。”

问题不在 AI。

真正的问题是：管理层把 AI 当成产能外挂，却没有重构需求、验收、排期和责任边界。

这篇不聊“AI 会不会取代人”这种大词。就拆一个具体问题：

为什么 AI 明明能提效，最后一线反而更累？

一句人话判断

AI 不是天然让人更累。

让人更累的是一种很粗暴的管理公式：

AI 提效 = 个人空闲时间增加 = 可以继续塞活

这个公式错在三层。

第一，AI 省掉的是局部执行时间，不是完整交付时间。

第二，AI 生成的是候选结果，不是可直接负责的业务结果。

第三，AI 把很多隐性工作显性化了：提示词、资料清洗、事实核验、格式修正、风险判断、对外口径，这些都要人来兜底。

所以你会看到一种非常诡异的现象：

工具越来越强，交付节奏越来越急，人的责任却一点没少。

第一层：老板看到的是“出稿很快”，没看到的是“交付很慢”

很多老板迷信 AI，不是因为他真的理解 Agent、RAG、上下文窗口、工具调用。

他只看到了一个画面：你输入一句话，屏幕上哗哗出字。

这就很危险。

因为在真实工作里，“出字”只占交付链路里很小一段。

拿一个普通市场方案举例：

需求澄清 -> 资料收集 -> 初稿生成 -> 事实核验 -> 业务口径对齐
        -> 数据补充 -> 风险判断 -> 设计排版 -> 审批修改 -> 对外发送

AI 很擅长帮你加速“初稿生成”和部分“资料整理”。

但它不替你承担这些问题：

• 这个数据来源能不能对外用？
• 竞品分析有没有过期？
• 这个承诺销售能不能兑现？
• 法务、财务、交付团队是否认这个口径？
• 客户看到后会不会误解成正式报价？

老板如果只把“初稿生成”当成交付时间，就会把排期压得离谱。

可以用一个更工程化的方式看：

task: 客户方案
ai_saved:
draft_minutes:80
human_still_owns:
context_alignment:true
factual_check:true
business_commitment:true
final_accountability:true
delivery_risk:
if_schedule_by_draft_time:high

这段配置的意思很简单：AI 省的是 draft_minutes，不是 human_still_owns 下面那一串责任。

NBER 有一篇关于客服场景的研究，发现生成式 AI 工具让客服平均生产率提升约 14%，新手和低技能员工提升更明显，但对高技能员工影响很小。这说明 AI 的收益不是均匀撒在所有人、所有任务上的，它有明显的任务边界和人群差异。

把这个结论搬到公司排期里，就是一句话：

不能因为某类任务提效 14%，就把所有知识工作统一砍掉 50% 排期。

第二层：AI 省下来的不是“人的时间”，而是“系统吞吐”

很多人第一次用 AI，会有一种错觉：

“我 2 小时的活，半小时做完了，那我是不是多出来 1.5 小时？”

理论上是。

但在公司里，如果没有明确规则，这 1.5 小时通常不会变成你的休息，而会变成组织吞吐量。

也就是：

以前一天交 1 个方案
现在一天交 3 个方案
以前一周写 1 篇报告
现在一周写 5 篇报告
以前一个版本做 3 个备选
现在每个需求都要 10 个备选

这时候 AI 不再是减负工具，而变成了任务放大器。

Microsoft 和 LinkedIn 的 2024 Work Trend Index 里有一组很扎眼的数据：75% 的全球知识工作者已经在工作中使用 AI；同时，68% 的人说自己难以跟上工作节奏和工作量，46% 感到倦怠。

这两个数字放在一起看，味道就不一样了。

不是“大家用了 AI，所以不累了”。

更像是“大家太累了，所以自己偷偷找 AI 扛一部分；但组织层面的节奏和规则并没有变好”。

Slack 2024 年 Workforce Index 也提到一个很现实的担心：员工害怕 AI 省下来的时间会让领导期待他们做更多、更快的工作。

这就是打工人的痛点。

你用 AI，不一定换来轻松。

你可能换来的是“你既然会用 AI，那这批活都给你”。

第三层：AI 把需求入口变宽了，却没有把验收口变窄

以前老板提需求，多少会被成本挡一下。

“这个要不要做？”背后有一个隐性约束：

做一次要 2 天
所以别乱提

AI 出现后，这个约束没了。

“让 AI 试试”听起来几乎没有成本。

于是需求入口变成这样：

这就是为什么很多团队用了 AI 之后，事情没有减少，反而越来越碎。

因为以前被成本拦住的低质量需求，现在都能进来了。

“帮我做 3 个版本。”
“再换个风格。”
“把这个截图也分析一下。”
“顺便写个老板视角。”
“再补一个竞品视角。”
“不急，今晚给就行。”

如果团队没有需求准入规则，AI 会把所有“随口一提”都变成待办。

更麻烦的是，验收口没有变窄。

AI 可以给 10 个方案，老板就会从 10 个方案里挑刺。你不是少做了，而是从“写一个方案”变成“生成 10 个方案、解释 10 个方案、合并 10 个方案、背锅最终那个方案”。

这在工程里很像没有限流的入口。

def accept_task(task):
    if task.can_be_done_by_ai:
        return True
    return has_clear_owner(task) and has_business_value(task)

这段伪代码的问题很明显。

can_be_done_by_ai 被放在了第一优先级。只要 AI 能试，就进入队列。

正确的写法应该先问业务价值和责任边界：

def accept_task(task):
    if not task.business_goal:
        return Reject("没有明确目标")
    if not task.owner:
        return Reject("没有验收负责人")
    if task.deadline < estimate_delivery_time(task):
        return Negotiate("排期不成立")
    return Accept("进入 AI 辅助交付")

AI 应该出现在 Accept 之后。

它是执行方式，不是需求准入理由。

第四层：最累的不是生成，而是核验和兜底

老板嘴里的“AI 跑一下”，常常省略了后半句：

“但结果你负责。”

这句话才是关键。

AI 生成一个方案，错了不会去开复盘会。

AI 编一段数据，客户追问不会自己解释。

AI 把内部资料贴到不该贴的地方，最后也不是模型背安全事故。

真实链路是这样的：

很多 AI 工作的体感变累，就累在这条链路：

• 你要判断输入资料能不能喂给模型；
• 你要判断模型输出有没有事实错误；
• 你要判断哪些内容能对外发；
• 你要判断结果是否符合公司口径；
• 你还要在出问题时解释“为什么当时这么交付”。

如果这些动作不被承认为工作量，AI 只会让人的责任密度变高。

OpenAI 的 evals 文档里有一个很工程化的观点：要通过评估测试模型输出是否满足指定的风格和内容标准，理解应用表现是否符合预期，尤其是在升级或切换模型时。

翻译到公司场景，就是：

不要把“看起来能用”当成“可以上线”。

不要把“生成速度快”当成“验收成本低”。

如果一个团队大量使用 AI 做对外材料、代码、客服、数据分析，却没有最低限度的评估集、抽检机制、引用来源、权限控制和回滚方案，那不是提效，是把风险塞给一线。

第五层：移动 Agent 会让“随时工作”变得更顺滑

参考文章里提到的 WorkBuddy 这类产品，有一个很有意思的方向：手机上说一句话，就能调电脑、跑任务、生成报告、处理 PPT。

从产品角度看，这当然是进步。

以前 AI 工具还像“桌面软件 + API Key + 插件配置 + 本地环境”。现在越来越像微信里的移动工作台。对普通人来说，门槛会大幅下降。

但从打工人角度看，它也会放大另一个问题：

以前：人不在电脑前，需求会自然延后
现在：人在地铁上，也能被要求“顺手处理一下”

工具把物理边界打穿了。

如果公司没有协作规则，移动 Agent 会把“能做”误解成“应该现在做”。

这也是为什么我不反对 AI 工具，但非常反对“AI 很快，所以你随时都该响应”的管理逻辑。

技术上，Agent 可以 7x24 小时运行。

人不行。

工程上怎么落地：别先买工具，先改规则

如果你在团队里推动 AI，不要只发一句：

“大家以后多用 AI 提效。”

这句话基本等于没说。

更靠谱的是把 AI 工作流拆成 5 个闸门。

1. 需求闸门：AI 不能替业务目标背书

每个 AI 任务至少写清三件事：

goal: 这次交付要影响什么业务结果
owner: 谁验收，谁负责最终口径
deadline_reason: 为什么是这个时间点

如果这三件事说不清，就不要因为“AI 能做”而进入队列。

2. 排期闸门：只压缩可自动化部分

估时不要写成：

用了 AI，整体时间打 5 折

更合理的是拆分：

AI 提效只应该作用在可被自动化的环节，不能粗暴作用在整个交付周期。

3. 验收闸门：输出必须带证据

AI 交付物最好统一要求带来源、假设和不确定项。

例如：

## 结论
建议优先做 A 方向。

## 依据
- 客户历史反馈：来自 CRM 2026-06-20 记录
- 竞品价格：来自官网公开报价，抓取时间 2026-06-23
- 成本估算：基于当前云资源单价，未包含人工支持成本

## 不确定项
- 客户预算未确认
- 法务条款未审
- 数据样本不足 30 条

这不是形式主义。

这是把“AI 看起来很有道理”变成“人可以验收和追责”的最低结构。

4. 责任闸门：谁让 AI 做，谁定义验收

很多团队最扯的地方是：老板随口派活，员工用 AI 生成，最后员工为所有模糊需求背锅。

要避免这个问题，责任要前置。

需求方负责目标和验收口径
执行方负责过程和交付质量
管理者负责排期和资源取舍
AI 只负责辅助生成，不承担最终责任

NIST AI Risk Management Framework 的思路也类似：AI 风险管理要进入设计、开发、使用和评估过程，而不是出事后才补救。它强调的是组织能力，不是个人自觉。

5. 节奏闸门：省下来的时间要有归属

这是最容易被忽略的一条。

AI 省下来的时间，到底归谁？

如果默认全部归组织，那员工一定会把 AI 当成新型压榨工具。

更健康的规则可以很朴素：

• 一部分归业务，用来提升吞吐；
• 一部分归质量，用来做核验、复盘、沉淀模板；
• 一部分归个人，用来学习、休息和减少加班。

不把这件事说清楚，AI 提效只会变成隐形加班。

给打工人的自保清单

如果你现在已经处在“老板什么都让你用 AI 搞一下”的环境里，别只硬扛。

你可以把沟通方式改成工程化表达。

1. 不要只说“做不了”，要拆交付链路

可以这样回：

AI 可以先帮我出初稿，预计 30 分钟。
但最终版还需要补三件事：
1. 核验客户数据来源；
2. 和产品确认承诺边界；
3. 排版并过一遍对外口径。

如果明早 9 点要，只能交“内部讨论版”。
如果要客户可发版，需要到明天下午。

这段话的重点不是抱怨，而是把隐藏工作显性化。

2. 每次 AI 交付都标注版本等级

你可以给交付物分级：

L0 灵感草稿：只用于内部讨论
L1 可读初稿：结构完整，但未核验事实
L2 可评审版：关键事实已核验，有来源
L3 可发布版：业务、法务、品牌口径已确认

老板如果要快，就明确只能拿 L0/L1。

老板如果要稳，就要给 L2/L3 的时间。

3. 建一个自己的 Prompt 和验收模板库

别每次都从零开始跟 AI 斗智斗勇。

至少沉淀三类模板：

• 需求澄清模板；
• 事实核验模板；
• 对外交付检查模板。

例如：

请把下面材料整理成客户方案初稿。

要求：
1. 所有结论必须标注依据来源；
2. 没有依据的地方标记为【待确认】；
3. 不允许编造客户预算、竞品数据、承诺时间；
4. 输出分为：背景、问题、方案、风险、下一步。

这类 prompt 不神奇，但它能减少最烦人的返工。

4. 保留关键过程记录

用 AI 做重要任务时，建议保留：

• 原始需求；
• 输入材料；
• 关键 prompt；
• AI 输出版本；
• 人工修改点；
• 事实核验来源。

这不是不信任谁。

这是给自己留一条排查链路。

这题如果面试被问到，怎么答

如果面试官问：

“你怎么看公司里用 AI 提效以后，团队反而更累？”

不要只说“管理问题”。

可以这么答：

我会把它拆成技术工具、交付流程和组织激励三层。

技术工具层，AI 主要加速的是生成、总结、检索、格式转换，不等于端到端交付。

交付流程层，真正耗时的还有需求澄清、事实核验、业务确认、风险评估和审批。如果只按生成速度压缩排期，会把质量风险转嫁给执行者。

组织激励层，如果省下来的时间全部被换成更多任务，员工会把 AI 视为压榨工具，反而降低采用意愿。

所以我会建议先定义 AI 适用场景、验收标准、版本等级和责任边界，再谈提效指标。

如果面试官继续追问：

“那你怎么衡量 AI 真的提效了？”

你可以补一句：

我不会只看生成耗时。
我会同时看端到端交付周期、返工率、事实错误率、人工核验时间、员工加班时长、客户满意度和事故数。
只有这些指标一起改善，才叫真正提效。

这个回答的重点是：你没有把 AI 当玄学，也没有把 AI 当敌人。

你把它放回了工程系统里。

最后回到晚上 10 点 47 分那条消息

老板说：

“AI 跑一下很快。”

这句话只说对了一半。

AI 跑一下，确实可能很快。

但一个结果从“跑出来”到“能负责”，中间还有需求、事实、口径、审批、风险和责任。

这些东西不会因为模型变强就自动消失。

所以真正成熟的 AI 团队，不是人人都在深夜对着工具猛冲，也不是老板把所有排期都砍半。

真正成熟的团队会承认一件事：

AI 能放大产能，也能放大混乱。

如果规则没变，AI 越强，打工人越累。

如果规则跟上，AI 才可能真的把人从重复劳动里放出来。

否则那句“你用 AI 搞一下，很快的”，最后翻译成人话就是：

“工具替你省了 30 分钟，我再给你加 3 小时活。”

这才是老板迷信 AI 之后，打工人的命更苦的真正原因。

参考资料

• NBER: Generative AI at Work：https://www.nber.org/papers/w31161
• Microsoft & LinkedIn 2024 Work Trend Index：https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part
• Slack Workforce Index November 2024 PDF：https://d34u8crftukxnk.cloudfront.net/slackpress/prod/sites/6/The-Workforce-Index-from-Slack-November-2024.pdf
• NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
• OpenAI Evals Guide：https://platform.openai.com/docs/guides/evals