ChatGPT管理后台新增用量、任务与Codex成果分析

原文要点

OpenAI在ChatGPT Admin Console上线三组分析：Usage视图汇总ChatGPT Work与Codex的活跃用户、credits与token，可按群组或成员过滤；Insights用任务分类器把抽样消息归入软件工程、销售调研等用途，Overview看credits分布、Use cases表按任务列出credits/消息数/活跃用户，任务详情含Models、Reasoning、Speed的credits占比及插件排行榜和Skills视图；Outcomes跟踪Codex在合并提交与代码行数中的占比。Admin插件可把发现生成汇报材料，Admin API可接入自有看板。文中ROI示例（20名销售、245%）为客户假设数字，截图均为演示数据。

这次做成什么

管理员用Admin Console做一次“用量→业务价值”月度复盘练习：定位一个高频任务，检查模型与推理档位是否匹配，和业务负责人共建基线，算一版示意ROI并生成汇报初稿。

准备什么

• ChatGPT Enterprise或Business工作区的管理员账号，能进入Admin Console
• 工作区已有一段真实使用数据，Insights任务分类基于抽样消息，数据太少时分类意义有限
• 一名愿意配合提供基线数据的业务负责人（如销售或工程主管）
• （可选）要用Admin API接入自有看板时需具备API调用权限

具体怎么做

1. 在Usage视图找采用洼地

   进入Admin Console的Usage，把ChatGPT Work与Codex的活跃用户和credits趋势按群组过滤，找出活跃明显偏低的团队，记下群组名和趋势区间，作为与团队负责人谈培训需求的依据。

2. 在Insights锁定一个高频任务

   打开Insights的Overview看credits在任务间的分布，再切到Use cases表，按credits排序选出与业务优先级相关的第一大任务（例如销售团队的account research），记下该任务的credits、消息数和活跃用户数。

3. 检查任务配置是否匹配

   进入该任务详情，看Models、Reasoning、Speed三段各自的credits占比：若常规简报类任务大量使用高推理档位，记下占比，列为“可测试更快更便宜配置”的候选项；同时看Plugin leaderboard和Skills视图，插件使用率过低记为可能的权限或培训缺口。

4. 工程团队加看Outcomes

   若团队用Codex，打开Outcomes视图，按群组或仓库过滤，看Codex贡献的合并提交与代码行数占比趋势，并计划与评审时长、缺陷和返工数据对照，不单独用占比下结论。

5. 用Admin插件生成汇报初稿

   在ChatGPT Work里启用Admin插件，粘贴下方提示词，让它把前面记录的数字整理成一页管理层摘要；生成后逐条核对数字与你在控制台看到的实际值是否一致。

6. 与业务负责人共建基线算ROI

   用下方ROI计算模板，把团队人数、任务频率、每次节省时长、人力成本与AI总成本填入，算出示意年化收益与ROI，与负责人约定一个复盘日期再对照实际值。

可直接复制的材料

你是工作区管理员的数据分析助手。请基于Admin Console中ChatGPT Work与Codex的使用数据，帮我准备一份月度管理层汇报，包含：
1. 采用情况：各群组活跃用户与credits趋势，指出采用率最低的一个群组并简述可能原因；
2. 任务结构：credits占比最高的三个任务类别，分别列出credits、消息数和活跃用户数；
3. 配置检查：针对第一大任务，说明Models、Reasoning、Speed的credits分布，指出是否存在为常规任务使用高成本配置的迹象；
4. 工程产出：Codex在合并提交与代码行数中的占比趋势，按仓库列出差异；
5. 建议：给出三条下月可执行动作（培训、插件权限、流程模板），每条注明依据的数据。
输出为一页中文摘要加一张要点表格，所有数字标注来源视图名称。

{
  "team": "示例：销售客户调研小组",
  "inputs": {
    "headcount": 12,
    "briefs_per_person_per_week": 2,
    "hours_saved_per_brief": 2.5,
    "working_weeks_per_year": 46,
    "productive_reinvest_rate": 0.5,
    "fully_loaded_cost_per_hour_cny": 260,
    "first_year_total_cost_cny": 220000
  },
  "formulas": {
    "annual_hours_saved": "headcount × briefs_per_person_per_week × hours_saved_per_brief × working_weeks_per_year",
    "capacity_value": "annual_hours_saved × productive_reinvest_rate × fully_loaded_cost_per_hour_cny",
    "roi_percent": "(capacity_value − first_year_total_cost_cny) ÷ first_year_total_cost_cny × 100"
  }
}

输入与输出示例

本站虚构演示，非OpenAI客户数据；输入参数与计算结果一一对应，仅作方法示意。

输入

12人销售小组，每人每周做2份客户简报，使用AI后每份节省2.5小时，年工作46周，节省时间按50%转化为有效产出，全负担人力成本每小时260元，首年AI总投入220000元。

对应输出

annual_hours_saved = 12×2×2.5×46 = 2760小时；capacity_value = 2760×0.5×260 = 358800元；示意ROI = (358800−220000)÷220000 ≈ 63%。汇报中应注明：此为容量价值的示意估算，未计入胜率提升或成交周期缩短等潜在收益，复盘日以实际准备时长与简报质量基线校准。

做完检查这些

• 能在Usage视图按群组过滤并指出至少一个活跃偏低的团队，截图记录趋势区间
• 能说出第一大任务的credits、消息数、活跃用户数及其Models/Reasoning/Speed分布
• 汇报初稿中的每个数字都能在控制台对应视图找到，没有插件臆造的值
• ROI测算包含人力成本、AI总投入和节省时长三要素，且明确标注为示意估算

容易卡住的地方

• 控制台截图与文中数字均为演示数据，不能当作自己租户的实际基线引用
• 任务分类器基于抽样消息归类，样本小的团队分类结果波动大，不宜据此做罚款式考核
• Codex合并代码占比上升不等于质量提升，必须与评审时长、缺陷和返工一起对照
• ROI公式只算容量价值，作者原文的245%同样是假设数字，向管理层汇报时避免说成承诺收益
• Admin API自动化需要额外开发投入，别把插件一键汇报和API接入混为一谈