关于 AI 与工作的讨论，常被压缩成一个问题：它会替代哪些岗位？新的 OpenAI 研究提供了另一个观察角度：ChatGPT 用户正在跨越原有角色分工，承担过去较少接触的任务。变化的重点不只是把现有工作做快，而是扩大一个人能够完成的任务范围，并由此重新塑造岗位边界。
来源摘要没有给出行业占比、效率增幅或因果关系，因此不能据此断言 AI 已经普遍提升生产率。不过，它揭示了一个值得企业验证的趋势：衡量 AI 价值时，除了节省时间，还应观察员工是否获得了新的任务能力。
岗位没有消失，任务组合先发生了变化
岗位名称通常稳定，实际工作内容却可以快速变化。产品经理可能借助 AI 编写数据查询草稿，工程师可以整理用户访谈，运营人员也能生成简单的自动化脚本。这些任务原本可能需要等待其他团队支持，现在可以由任务发起者先完成初稿，再交给专业人员审查。
这种扩展不等于专业边界失去意义。AI 更像是降低了相邻任务的进入成本：
- 员工能更快理解陌生领域的术语、流程和交付格式。
- 初稿成本下降，让过去“不值得排期”的小任务变得可执行。
- 跨团队协作从“请对方从头完成”转向“提交可审查的草案”。
- 专业人员的工作重心可能转向验证、纠错和处理复杂例外。
因此，真正需要观察的单位不是岗位，而是任务。一个岗位可以同时包含适合 AI 辅助的任务、必须由专家判断的任务，以及不应交给外部模型处理的敏感任务。
扩展能力与提高效率不是同一件事
如果 AI 把一份周报的制作时间从两小时降到一小时，这是效率提升。如果原本不会分析日志的客服人员，借助 AI 写出查询语句并定位问题类别，再由工程师确认，那么这更接近能力扩展。
两者需要不同的指标：
| 观察目标 | 可记录指标 |
|---|---|
| 效率提升 | 用时变化、返工次数、单位成本 |
| 能力扩展 | 新任务类型数量、独立完成比例、求助链路变化 |
| 质量控制 | 审查退回率、事实错误、安全事件 |
| 组织变化 | 跨团队等待时间、交接次数、职责调整 |
只统计生成次数或活跃用户，很难判断岗位边界是否真的改变。更有用的问题是：员工完成了哪些过去不会做、不能做或没有资源做的任务？这些成果经过审查后是否可用？
可以这样实践：运行一个四周任务边界实验
下面是一个不依赖第三方包的最小记录工具。它不会调用模型，而是把每次 AI 辅助任务写入 CSV，并按“是否属于新任务”汇总结果。将代码保存为 task_boundary.py，使用 Python 3 运行即可。
import argparse
import csv
from collections import Counter
from pathlib import Path
FILE = Path("ai_task_trials.csv")
FIELDS = ["role", "task", "new_task", "reviewed", "accepted", "minutes_saved"]
def add(args):
exists = FILE.exists()
with FILE.open("a", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=FIELDS)
if not exists:
writer.writeheader()
writer.writerow({
"role": args.role,
"task": args.task,
"new_task": args.new_task,
"reviewed": args.reviewed,
"accepted": args.accepted,
"minutes_saved": args.minutes_saved,
})
def report():
if not FILE.exists():
print("No trials recorded.")
return
with FILE.open(newline="", encoding="utf-8") as f:
rows = list(csv.DictReader(f))
new_tasks = [r for r in rows if r["new_task"] == "yes"]
accepted = [r for r in rows if r["accepted"] == "yes"]
saved = sum(int(r["minutes_saved"]) for r in rows)
print(f"Trials: {len(rows)}")
print(f"New-task trials: {len(new_tasks)}")
print(f"Accepted after use: {len(accepted)}")
print(f"Estimated minutes saved: {saved}")
print("Trials by role:", dict(Counter(r["role"] for r in rows)))
parser = argparse.ArgumentParser()
sub = parser.add_subparsers(dest="command", required=True)
add_parser = sub.add_parser("add")
add_parser.add_argument("--role", required=True)
add_parser.add_argument("--task", required=True)
add_parser.add_argument("--new-task", choices=["yes", "no"], required=True)
add_parser.add_argument("--reviewed", choices=["yes", "no"], required=True)
add_parser.add_argument("--accepted", choices=["yes", "no"], required=True)
add_parser.add_argument("--minutes-saved", type=int, default=0)
add_parser.set_defaults(func=add)
report_parser = sub.add_parser("report")
report_parser.set_defaults(func=lambda _: report())
args = parser.parse_args()
args.func(args)
例如，记录一次由运营人员完成、并经过工程师审查的 SQL 草稿任务：
python task_boundary.py add \
--role operations \
--task "drafted a weekly retention SQL query" \
--new-task yes \
--reviewed yes \
--accepted yes \
--minutes-saved 35
python task_boundary.py report
配合 ChatGPT 使用时，可以采用下面的提示词框架。把数据表结构、允许访问的字段和验收标准替换为团队自己的内容；不要粘贴客户隐私、密钥或未经批准的内部数据。
你是任务草稿助手，不是最终审批者。
我的角色：运营分析
我过去较少完成的任务：编写每周留存率 SQL 查询
可用表结构：<粘贴脱敏后的 schema>
业务定义：第 0 周注册，并在第 N 周至少活跃一次
请输出：
1. 一段带注释的 SQL 草稿；
2. 你对字段和口径所做的假设；
3. 三个需要数据工程师确认的问题；
4. 两个用于发现重复计数或时区错误的测试查询。
不要虚构不存在的表或字段。信息不足时明确标注。
这个流程的关键不是让非专家绕过专家，而是让他们带着结构化草稿、假设和测试进入审查环节。
采用时守住三条边界
团队可以从低风险、可验证、容易回滚的相邻任务开始，例如文档草稿、查询草稿、会议材料重组和测试用例生成。涉及招聘、绩效、法律判断、生产环境变更或敏感数据时，应设置更严格的审批和访问控制。
落地前至少确认三件事：任务成果由谁负责，哪些数据禁止输入模型，以及什么条件下必须升级给专业人员。四周后不要只看节省了多少分钟，还要检查新增任务是否通过审查、是否增加返工，以及员工是否因此承担了未经授权的责任。
AI 对工作的深层影响，可能并不是简单压缩现有岗位，而是持续改变每个岗位内部的任务组合。组织越早建立任务级记录、审查机制和责任边界，就越能分辨真正的能力扩展与表面上的内容生成。