AI 在职场中的价值，已经不只是在原有岗位上更快完成几项任务。新的 OpenAI 经济研究关注了一个更值得企业观察的变化：员工正在把 AI 用于传统职责之外的活动，而其中一些原本临时、零散的尝试，正在变成反复出现的工作环节。
这意味着，AI 采用的重点不应只是“哪些岗位会使用模型”，还要继续追问：员工正在创造哪些新活动？哪些活动已经形成稳定节奏？组织应该如何让这些做法变得可复用、可审查，并且不会带来新的风险？
从“工具使用”转向“工作活动设计”
传统的岗位描述通常围绕职位名称展开：工程师写代码，销售跟进客户，运营制作内容，财务整理报表。但 AI 的介入方式往往横跨这些边界。
一个工程师可能让 AI 帮忙准备客户演示；一名销售可能用它分析产品反馈；运营人员可能让它把会议记录整理成行动清单；管理者则可能利用 AI 对多个团队的状态进行归纳。这些事情未必属于某个岗位的核心职责，却可能逐渐成为稳定的工作活动。
因此，评估 AI 影响时，可以把观察单位从“职位”下沉到“活动”：
- 这项活动是否重复发生？
- 它是否已经有固定输入和输出？
- 员工是否在多个项目中复用同一套方法？
- AI 生成的结果是否需要人工审核？
- 这项活动是节省了时间，还是创造了新的协作方式？
这种视角能避免一个常见误区：把 AI 只看成原有流程中的自动化按钮。更准确的做法，是记录哪些工作正在被重新组合。
“新活动”为什么会变成日常工作
一项 AI 用法从试验变成常规，通常会经历几个阶段。
1. 从临时解决问题开始
员工先在具体场景中使用 AI，例如把一份长文压缩成摘要、为客户邮件生成初稿，或从会议记录中提取待办事项。这个阶段的目标通常是解决眼前问题，而不是建立完整流程。
2. 输入和输出逐渐固定
当类似任务反复出现，员工会开始固定输入格式、提示词、检查清单和输出模板。此时，AI 不再只是聊天窗口里的临时助手，而是工作流中的一个步骤。
3. 形成可交接的操作方式
如果另一名同事能够根据同一套说明复现结果，这项活动就具备了组织化的可能。团队可以把提示词、示例、审批规则和异常处理方式放在项目文档或内部知识库中。
4. 进入节奏和治理范围
当活动影响客户沟通、业务决策或敏感数据时，就需要补充权限、日志、人工复核和数据保护要求。反复使用不等于可以完全自动化；恰恰相反，稳定使用之后更需要明确边界。
一个可落地的做法：建立“AI 活动日志”
企业不必一开始就做复杂的生产力测量。可以先让团队记录 AI 帮助完成了哪些活动，并区分“偶发尝试”和“已经重复使用”的流程。
下面是一个可以直接改造的 Python 示例。它使用 OpenAI Responses API，把一段工作记录整理成活动清单。示例假设你已经设置了 OPENAI_API_KEY，并且需要根据实际模型、合规要求和 SDK 版本调整配置。
import json
import os
import urllib.request
API_KEY = os.environ["OPENAI_API_KEY"]
API_URL = "https://api.openai.com/v1/responses"
work_log = """
周一：把客户访谈记录整理成三个产品需求，发送给产品经理。
周二：根据销售会议纪要生成跟进邮件初稿，人工修改后发送。
周三：让模型比较两版技术方案，并列出需要架构师确认的差异。
周四：再次整理客户访谈记录，使用了和周一相同的提示词模板。
"""
prompt = f"""
你是一名工作流程分析助手。请根据下面的工作记录，提取员工使用 AI 完成的活动。
只输出 JSON 数组，每个元素包含：
- activity: 活动名称
- frequency_signal: 是否显示出重复发生的迹象
- human_review: 需要人工确认的环节
- next_step: 建议如何把它变成可复用流程
不要推断记录中没有出现的事实。
工作记录：
{work_log}
"""
payload = {
"model": "gpt-4.1-mini",
"input": prompt
}
request = urllib.request.Request(
API_URL,
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
method="POST",
)
with urllib.request.urlopen(request, timeout=60) as response:
result = json.loads(response.read().decode("utf-8"))
print(result.get("output_text", result))
这个例子的重点不是让模型替管理者做结论，而是把分散的工作记录转化为可讨论的对象。团队可以进一步增加以下字段：
- 每次活动耗时，以及使用 AI 前后的大致变化；
- 输入是否包含客户资料、源代码或个人信息；
- 输出由谁审核、审核依据是什么；
- 活动是否适合共享给其他团队；
- 如果模型结果错误，错误会影响谁。
如果不希望把原始记录发送到外部服务，也可以先在本地脱敏，再调用模型；或者使用组织批准的内部部署方案。代码中的工作记录只是示例，实际使用时应替换为经过授权的数据。
管理者应该关注什么
不要只统计调用次数
调用次数很容易统计，却不能说明 AI 是否真正改变了工作。更有价值的指标包括：重复活动数量、人工返工比例、交接效率、错误类型以及新产生的协作环节。
把提示词升级为流程资产
一个员工反复使用的提示词，可能是团队流程的早期版本。与其把它留在个人聊天记录里，不如配上输入示例、输出格式、审核步骤和失败案例，形成可以维护的工作资产。
为跨岗位活动设定责任人
新活动往往没有天然的部门归属。比如“把客户反馈转成产品机会”可能同时涉及客服、销售、产品和数据团队。应明确谁维护模板，谁负责事实核验，谁批准将结果用于决策。
留出不自动化的部分
涉及招聘、绩效、合规、医疗、财务决策或客户承诺的活动，不能因为重复发生就直接交给模型执行。重复性只说明它值得设计流程，不代表它可以取消人工判断。
采用前的检查清单
在把一个新活动纳入团队日常之前，可以回答以下问题：
- [ ] 活动的目的、输入和输出是否清楚？
- [ ] 是否明确哪些内容不能发送给模型？
- [ ] 是否有人工审核人和可追溯记录？
- [ ] 是否保存了代表性输入、输出和失败案例？
- [ ] 是否能由另一名同事复现，而不是依赖个人经验？
- [ ] 是否定义了错误升级和停止使用的条件？
- [ ] 是否定期检查这项活动是否仍然有价值？
AI 带来的变化，未必表现为一个岗位突然消失，也可能表现为许多岗位都多出了一组过去不存在的固定活动。对企业而言，真正重要的是识别这些活动、验证它们的价值，并为它们建立适度的治理方式。
当团队能够把“我偶尔让 AI 帮我做这件事”转化为“我们有一套可复用、可审核、边界清晰的工作流程”，AI 才真正从个人工具变成了组织能力。