AI 最先进入财务工作的哪里？

OpenAI Strategic Finance 并没有先展示“让 AI 替 CFO 做决定”，而是先把判断之前的工作拆开：收集信号、整理数据、生成候选方案、构建分析页面、完成勾稽、准备材料，再把结果交给人复核和批准。

导读

2026 年 6 月，OpenAI Strategic Finance 团队以 #12daysofChatCodexStratfin 为标签，连续分享 ChatGPT、Codex 和 Codex Sites 在财务工作中的使用方式。初看这组分享，读者很容易把它理解为“OpenAI 财务团队做了一堆酷炫的 dashboard”，或只是 OpenAI 在 6 月秘密提交 S-1 后的一系列传播活动中的一环。但仔细读完这十几天的分享后，AI4FIN 认为，这是离 AI 最近的财务团队所做的一次无保留的实操分享。接下来先看 Day 1–6。这六天围绕第一个问题展开：AI 最先进入了哪些工作单元？答案不是 CFO 的最终判断，也不是 Controller 的签字责任。AI 先进入的是判断之前那一段长期由 Excel、邮件、人工搬运和个人经验支撑的工作：

• 从大量业务记录中收集信号；
• 把不同来源的数据整理成同一个分析对象；
• 生成可供讨论的候选方案；
• 把一次性分析做成可以刷新和复用的页面；
• 完成计划、实际、PO、accrual 和 transaction 的勾稽；
• 准备月结材料、检查异常并组织复核。

这组六天可以按工作重心分为两组：

• Day 1–3 在扩展 Finance 的 sensing layer。营销预算的边际回报、客户沟通中的销售领先信号、人员计划与招聘状态，原本分散在代理商数据、会议记录、邮件、CRM、HCM、ATS 和组织层级中。AI 的作用是让财务更早看见业务正在发生什么，而不是等月末或季度结果出来再解释。

• Day 4–6 则开始改变财务产物本身。Opex 分析不再只是一个人维护的 Excel；BvA 不再只是总差异和 commentary；月结 deck 不再只是文件夹里不断改名的 PowerPoint。页面、勾稽包和 deck 开始拥有输入、刷新、异常、复核和发布等状态。AI 不只是生成内容，也开始编排工作流。

下面逐日拆解六个案例。每个案例只回答六个问题：原来的业务瓶颈是什么，输入是什么，AI 做什么，人保留什么责任，最终沉淀什么资产，以及建议从什么范围起步。

为什么 AI 会先进入这些工作单元

财务工作中有很多内容可以由 AI 生成，但并不是所有任务都适合优先交给 AI。Day 1–6 选择的场景有几个共同特征。

第一，它们都有大量已经数字化、却没有被组织好的输入。营销 spend、Gong transcript、HCM、ATS、GL、PO、accrual 和 slide template 原本就在公司系统中。团队的问题不是没有数据，而是每次都需要有人寻找、复制、映射和解释。AI 最容易切入的地方，正是这种“信息已经存在，工作仍靠人工搬运”的断层。

第二，它们都有可以观察的中间产物。Response curve、account stage、position bridge、Opex page、reconciliation queue 和 slide draft 都可以被人检查。AI 不必直接给出不可逆的最终决定，而是先交付一个候选方案、工作区或首稿。Reviewer 能看到过程，也能修改结果。

第三，它们都有明确的重复周期。Marketing allocation 按周更新，sales signals 按周回看，HC view 按日或周刷新，Opex、BvA 和 close deck 按月运行。重复频率越高，越值得把一次性的个人操作变成可复用工作单元。团队每次修正规则、mapping 或模板，下一周期都能继续使用。

第四，它们都有天然的人类责任节点。预算需要 owner 批准，销售阶段需要业务人员判断，HC 口径需要 Finance 与 HR 确认，Opex 页面需要 FP&A 负责指标，accrual 需要会计判断，close deck 需要 owner review。AI 可以进入准备工作，不需要一开始就重新分配最终责任。

财务团队可以用一张简单的筛选表寻找自己的第一批场景：

如果一个场景需要 AI 同时寻找未知数据、定义新口径、做重大判断并执行不可逆动作，它通常不是好的第一站。相反，那些输入相对清楚、人工准备时间很长、结果本来就需要复核的任务，往往能更快形成可用方法。

第一组：Day 1–3，扩展 Finance 的 sensing layer

Day 1｜Marketing spend：从绩效报表到预算候选方案

业务问题

营销财务通常拥有很多历史报表，却很难在预算仍可调整时回答一个更有价值的问题：下一美元应该投到哪里？

传统 reporting 可以告诉团队某个渠道过去花了多少、平均 ROAS 如何、目标完成了多少。但平均表现掩盖了边际变化。同一个渠道可能整体回报不错，新增预算却已经进入 saturation；另一个市场目前规模较小，却仍有更高的边际回报。真正的经营动作不是重新排序渠道，而是在预算、合同、品牌和市场容量约束下，提出可以执行的 donor→receiver 调整方案。

这也改变了 Finance 在营销决策中的位置。过去，Marketing Finance 往往在周期结束后解释 variance；如果能够持续观察 response curve，Finance 就可以更早参与资源配置讨论。

输入与背景

这个工作单元的输入不是一张汇总渠道表，而是按日期、市场、渠道和 campaign 或 keyword 展开的 spend 与 outcome 数据。OpenAI 官方演讲提到，团队从营销代理商处取得 geography、channel、keyword 等维度的数据，再用 Codex 构建 ROI dashboard。

要让分析真正支持决策，还需要补上几类业务背景：当前批准预算、不可移动预算、渠道上下限、合同承诺、市场容量，以及 outcome 的正式定义。如果企业已经有实验或 MMM 结果，response curve 应与增量估计结合，而不是单独依赖相关性拟合。

AI 的角色

AI 在这里承担三层工作。

第一层是分析。它比较不同 market-channel 组合中的 spend 与 outcome，拟合 response curve，识别边际回报下降和 saturation 区间。

第二层是构建。它把筛选条件、散点图、拟合曲线和预算建议表做成交互页面，使 Finance 和 Marketing 可以切换市场、渠道、时间区间和 spend cap，而不需要每次重新写分析脚本。

第三层是提出候选方案。系统不只显示历史表现，还生成 donor market-channel、receiver market-channel、proposed shift 和 estimated uplift，帮助团队把分析推进到预算讨论。

这一步的组织意义在于，分析师不再把大部分时间花在重跑图表和拼接 recommendation deck。AI 先生成一组受约束的候选方案，Finance 把精力放在模型假设、可执行性和资金取舍上。

人的角色

人仍然决定什么叫“更好”。

模型可以拟合或估计边际回报，但基于观察数据的 response curve 并不天然等于真实的增量回报。模型也不能独立判断品牌曝光、渠道战略价值、合同限制和市场团队的执行能力。Marketing Finance 需要挑战数据的归因逻辑，增长负责人需要确认渠道是否能吸收新增预算，预算 owner 决定是否批准调整。

人的另一个职责是区分 estimated uplift 和 realized uplift。候选方案执行后，团队要把实际 spend、实际 outcome 和偏差原因回写到下一轮分析。否则 AI 每周都可以生成新的建议，却没有任何机制判断建议是否真的有效。

可复用资产

Day 1 最值得沉淀的不是一张静态 ROI dashboard，而是一个可重复运行的 marketing allocation model：

• 固定的数据输入与指标定义；
• 可刷新 response curves；
• 带约束的预算候选方案；
• proposed、approved、executed、measured 的决策记录；
• 预测 uplift 与实际结果的回看。

这个资产可以服务周度预算会，也可以成为季度预算规划和场景分析的输入。页面只是入口，真正被复用的是模型、约束和决策历史。

建议起步范围

不要从全球、全渠道优化开始。选择一个市场、两个可以相互调整预算的渠道和一个定义清楚的 outcome，再选择一段具有足够 spend variation 的历史窗口。试点可以从八到十二周开始，但窗口是否足够仍取决于数据颗粒度、spend variation、季节性和样本数量，模型也不得据此自动外推到训练区间之外。

第一版只要求系统回答四件事：当前 spend 位于曲线什么位置，新增预算的边际回报大致如何，哪些约束阻止预算移动，建议执行后如何回看。它不自动修改预算，也不需要做复杂的全局优化。只要能让一次预算评审从“看平均 ROAS”进步到“讨论边际回报、约束和实际结果”，就已经形成可用的工作变化。

公开证据范围： 主贴图和官方演讲直接展示 response curve、saturation 与 donor→receiver 建议表；具体模型选择、预算审批和实际 uplift 主要来自团队描述，未公开完整实现。

图注：Day 1 把 marketing reporting 推进到候选预算配置。页面不是最终决策者，而是让团队围绕边际回报和约束展开讨论。

Day 2｜Sales field signals：把客户沟通转成销售领先信号

业务问题

新产品上市后，季度收入是一个太晚的指标。CFO 和 CRO 更早想知道的是：销售有没有真正把产品带进客户对话，客户处于 introduction、technical evaluation、pilot 还是 rollout，哪些 segment 和 geography 正在加速，哪些账户需要额外支持。

传统做法是在 CRM 新增字段，再要求销售每天填写。问题不是字段建不出来，而是高频填报很难持续，原始对话中的细节也会被压缩成一个粗糙标签。大量更真实的信号已经存在于 Gong transcript、客户邮件、Slack、pipeline 和 product usage 中，只是没有被组织成 Finance 可以使用的经营视图。

输入与背景

Day 2 使用的背景信息包括客户与销售的沟通记录、account context、CRM pipeline 和产品使用情况。官方演讲明确提到 Gong transcripts 和客户邮件；原帖还提到 Slack、pipeline 与 product usage。

这些输入不能被简单拼成一个统一分数。每条记录需要先映射到正式 account ID，再按 account、product 和 period 去重与聚合。企业还要先定义阶段 taxonomy：什么算 introduction，什么证据才能进入 technical evaluation，pilot 与 rollout 的边界是什么，以及 blocked 和 no evidence 如何区分。

AI 的角色

AI 首先是一个信息抽取与分类层。它从通话和邮件中识别与产品相关的片段，保留说话人、时间和原文，再把信号归到定义好的阶段。

随后，它将 account-level signals 汇总成 segment、geography 和 weekly trend，使 Finance 能在收入结果出现之前观察 launch momentum。AI 还可以把 CRM stage、沟通信号和 product usage 并排展示，标出相互支持或相互冲突的账户。

这个角色与“预测成交概率”不同。它不需要一开始就给每个账户一个黑箱分数。更实用的第一步，是把原本散落在数百次沟通中的证据整理成一张 review queue，让 Finance、RevOps 和销售管理者知道哪些账户值得看、为什么值得看。

人的角色

人负责定义信号，也负责解释信号。

销售团队和 RevOps 需要共同制定阶段规则，审查低置信分类，并纠正身份映射和语境错误。Finance 使用这些信号支持资源配置，但不能把“没有可见沟通”直接解释为客户失速，因为相关讨论可能发生在线下或系统权限之外。

人还要决定这些数据可以用于什么。将客户沟通用于 launch review 和 specialist resource planning，与将它直接用于销售人员绩效评分，是完全不同的组织政策。后者会改变员工行为，也会带来隐私与信任问题，不能由模型默认决定。

可复用资产

Day 2 最终可以沉淀三类资产：

• 一套销售阶段 taxonomy 和人工标注样本；
• 一个将 Gong、email、CRM 与 usage 映射到 account 的 signal model；
• 一张带原文证据、置信度和 reviewer decision 的 launch review workspace。

随着人工修正累积，这套资产会逐渐形成公司自己的 launch knowledge：什么样的客户语言通常意味着 evaluation，哪些技术问题经常阻塞 pilot，哪些 segment 需要 specialist 支持。它不只是一次性 dashboard，而是一套可以持续学习的分类与复核机制。

建议起步范围

只选一个产品、一个 segment 和两类批准来源，例如 Gong transcript 与 CRM account context。先以二十到五十个账户为样本，建立 taxonomy 和初始标注集，再保留独立样本评估误报、漏报和 reviewer disagreement。

第一版按周输出 account、stage、evidence span、confidence、conflict 和 reviewer decision。不要自动改 pipeline，不要接入所有员工邮件，也不要做个人绩效评分。先验证 Finance 是否能通过这张队列更早发现 launch 问题，以及 reviewer 的纠正能否稳定改善下一轮分类。

公开证据范围： 主贴画面直接展示 synthetic/anonymized weekly dashboard；Gong、邮件、Slack、account 下钻及阶段分类流程主要来自帖子和官方演讲描述。

图注：Day 2 的方法不是增加 CRM 填报，而是把已经存在的客户沟通整理成可复核的领先信号。

Day 3｜Headcount visibility：把人员状态转成经营产能视图

业务问题

Headcount 报告最难的地方，不是统计员工人数，而是同时理解“已经在岗、已经接受 offer、正在招聘、已经批准但尚未释放”的完整 capacity pipeline。

这些状态分散在 position plan、HCM、ATS 和组织层级中。计划系统知道岗位是否获批，ATS 知道招聘进度，HCM 知道员工是否入职，manager hierarchy 决定这些岗位应该归到哪个 leader、region 或 segment。任何一个系统都只能看到局部。

对于支持 GTM 的 Finance 团队，经营问题不是“公司有多少人”，而是 sales 和 technical success capacity 正在哪些地区增加，哪些已批准岗位迟迟没有释放，哪些 accepted hires 尚未转为 filled，以及当前 HC 投资是否仍与战略优先级一致。

输入与背景

Day 3 的输入包括 HCM、planning、ATS 和 manager hierarchy。要把这些来源拼成一个经营视图，关键对象不是员工姓名，而是岗位本身。应优先以统一 position ID 作为连接主键；如果各系统不存在共同 ID，则必须建立稳定、可版本化的 position crosswalk，而不是依赖姓名和职位名称模糊匹配。Position plan、requisition 和 employee record 最终都需要落到同一个岗位对象上。

时间也必须成为输入的一部分。组织层级和员工状态都随 effective date 变化。周度报告需要固定 as-of timestamp，记录各系统的 extract time，否则同一份 dashboard 可能混用不同时间点的数据。

AI 的角色

AI 在这里先完成跨系统整理：检查岗位与 requisition 的对应关系，按 leader、region、segment 和 job family 汇总，并将岗位分为 Filled、Accepted、Open 和 Approved 等状态。

随后，它生成 dashboard、可编辑表格和 executive summary。Finance 不再每周手工复制不同系统的数字、重建 pivot、检查组织层级，再把结果写成领导层更新。系统可以比较本周与上周快照，标出新增、取消、延迟入职、manager 变化和 approved-but-unreleased roles。

如果连接到协作工具，AI 还可以起草适合管理层阅读的更新。但这里最重要的变化不是“自动发 Slack”，而是 dashboard、表格和摘要都由同一份 position-level view 生成。分析页面和管理层叙事不再各自维护一套数字。

人的角色

人负责定义岗位状态并处理例外。

Accepted candidate 何时转为 filled，冻结岗位是否仍计入 capacity，取消 requisition 如何处理，组织调整按哪个 effective date 生效，都需要 Finance、HR 和 Recruiting 共同确认。模型不能为了让总数闭合而静默合并重复岗位或猜测 manager mapping。

Finance 还要决定什么信息可以进入领导层页面和协作频道。多数经营讨论不需要 candidate name、薪酬或面试反馈。人不仅批准摘要，也负责限定输出字段、频道范围和刷新 cadence。

可复用资产

Day 3 最值得复用的是一个 position-level operating model：

• Position plan、HCM 与 ATS 的统一岗位对象；
• Filled、Accepted、Open、Approved 的互斥定义；
• effective-dated hierarchy；
• Plan → Approved → Open → Accepted → Filled 的 bridge；
• 周度变化与 exception queue；
• 从同一数据视图生成的 dashboard、Google Sheet 和 management summary。

这套资产以后可以进入 HC forecast、capacity planning、招聘优先级和 Opex 分析。它的价值不止是把月度更新变成周度更新，而是把 HC 从静态人数表变成可解释的经营产能管道。

建议起步范围

选择一个 leader 下的组织分支，冻结同一天的 position plan、HCM 和 ATS 快照。第一版优先完成基于统一 position ID 的对账；如果没有共同 ID，则先建立可版本化的 position crosswalk，再生成 Approved → Open → Accepted → Filled bridge，并单独列出缺失 position、重复 requisition、冻结岗位与 manager mapping 失败。

先让 Finance、HR 和 Recruiting 对同一份 exception queue 达成一致，再生成 leadership summary。暂时不要自动发送到 Slack。只要每周不再依赖一个人手工解释三套系统为什么对不上，这个工作单元就已经具备复用价值。

公开证据范围： 主贴图片直接展示 HC 状态、leader/subteam rollup 和 summary 入口；HCM/ATS 接入、层级检查、Google Sheets 与 Slack 发布来自作者描述。

图注：Day 3 把岗位计划、招聘进度和在职状态组织成同一个 capacity pipeline。

第二组：Day 4–6，让财务产物变成有状态的工作流

Day 4｜Monthly Opex web dashboard：财务开始自己构建分析产品

业务问题

很多 Finance 团队并不缺 Opex 分析，而是缺少一个能持续使用的交付形式。分析师每月从 planning model 和 ledger 拉数，更新 Excel、截图、复制到 PowerPoint，再把同样的问题解释给不同业务负责人。想做交互页面，又要等待 BI 或工程排期。

按照作者描述，Day 4 所主张的变化是：财务用户可以直接描述 audience、decision、metrics、tables、commentary 和 visuals，再由 Codex 构建 web dashboard。Vibe coding 在这里不是为了让 Finance 成为前端工程团队，而是缩短“业务问题—分析原型—使用反馈”之间的距离。

输入与背景

一个 Monthly Opex 页面需要 period、scenario、entity、cost center、account、currency、Actual、Forecast 或 Budget、HC snapshot、variance threshold、commentary owner，以及正式的 metric definitions。

这些输入中最重要的不是字段数量，而是已有财务模型与页面之间的分工。P&L、A/F variance、FX 和 HC 计算应来自受控数据或 metric layer；web 页面负责呈现和交互。否则 Finance 虽然摆脱了 BI 排期，却可能得到第二套散落在 JavaScript 里的财务逻辑。

AI 的角色

AI 在 Day 4 中首先扮演 builder 的角色。它先追问页面给谁用、要支持什么决定，再生成 HTML、CSS 和 JavaScript，快速构建包含 P&L highlights、A/F、variance callouts、trend、headcount 和 data notes 的页面。

更有价值的是，它可以把一次性页面变成可重复刷新的分析产品。AI 可以读取新的 approved dataset，更新页面，运行基本检查，生成 staging version，并根据用户反馈调整布局和交互。

这会改变 Finance 与技术团队的分工。Finance 可以自行完成业务原型、字段定义和使用者迭代；Data/IT 团队则把精力放在权威数据层、身份权限、部署环境和共享组件，而不是替每一个成本中心修改图表。

人的角色

Finance 仍然拥有指标口径和解释权。业务 partner 决定页面要支持什么决策，FP&A 确认 Actual、Forecast、variance 和 HC 的定义，页面 owner 审核数字与 commentary。

Data/IT 的角色也没有消失，而是从“替 Finance 做每张页面”转向提供稳定的底座：受控 dataset、访问权限、部署模板、测试和监控。一个成熟的协作方式是，Finance 可以自己迭代 presentation layer，但不能在正式页面里随意创建新的财务口径。

可复用资产

Day 4 最终沉淀的是一套 Finance-owned analytical app template：

• 面向特定 audience 和 decision 的页面结构；
• 连接受控 Opex dataset 的输入合同；
• P&L、A/F、trend、HC 和 notes 的可复用组件；
• refresh、validate、staging 和 publish 的操作流程；
• 业务用户反馈形成的页面设计规则。

这类模板可以复用到不同 cost center 或 business line。真正提高速度的，不是每次都重新进行 vibe coding，而是把公司已经确认的数据接口、组件和部署方式保留下来。

建议起步范围

选择一个 cost center、一个已关闭月份和一张 A/F bridge。先由现有财务模型生成只读 dataset，Codex 只负责页面，不在浏览器中重新计算财务指标。

第一版部署在 staging，显示 data version、as-of time、scenario 和 source。让一名 Finance business partner 实际使用，观察使用者是否能更快找到 variance、趋势和 commentary，而不是先追求全公司统一门户。这个范围足以验证 Finance 自助构建是否真的缩短迭代时间，也能明确 Data/IT 需要提供哪些共享能力。

公开证据范围： 主贴画面只直接展示项目名称与空白 Prompt；最终页面、refresh、validation 和 internal republish 的流程来自作者描述。

图注：Day 4 的重点不是一张已完成页面，而是 Finance 开始直接参与分析产品的构建过程。

Day 5｜Marketing BvA：把勾稽从后台动作变成工作区

业务问题

预算与实际分析常被简化成一张 variance 表，但财务团队真正花时间的地方通常在表之前：从 plan、GL、PO schedule、accrual register 和 transaction detail 拉数，更新 spreadsheet tabs、formulas 和 pivots，检查 mapping，处理 late posting，再确认每一层都能 tie out。

如果这些动作只存在于某位分析师的 Excel 和个人经验里，月底就很难知道一个差异究竟来自真实业务变化、期间错配、漏提 accrual，还是简单的数据处理错误。

Day 5 的方法是把 reconciliation 本身放进工作区。页面不只显示 Budget、Posted Actuals、Accruals 和 Variance，也显示 sources tied、unmatched、source status 和 largest drivers。勾稽不再是生成分析前看不见的准备工作，而是分析产品的一部分。

输入与背景

这个工作单元至少需要四类输入：Approved plan、GL actuals、PO schedule 和 accrual register。Transaction detail、mapping table、FX rate、materiality 和 control totals 构成必要背景。

公开页面将 Approved plan、posted actuals 与 PO-backed accruals 作为三类来源呈现；在 AI4FIN 的企业复原方案中，为了单独控制 invoice 与 accrual 双计风险，进一步将 PO schedule 和 accrual register 拆成两类输入，因此形成四源勾稽。

每一类来源都有自己的业务时间。PO commitment、goods receipt、service receipt、invoice、posting、payment 和 accrual period 不是同一个概念。系统只有正确识别这些状态，才能避免把已入账 invoice 与仍未冲回的 accrual 重复计算，也才能解释 committed-but-not-accrued 和 prior-period catch-up。

AI 的角色

AI 先摄入和标准化不同来源，检查字段、期间、币种和 mapping，再将各来源分别与 control totals 勾稽。无法映射的 account、缺失 PO、异常 accrual 和 late posting 进入 exception queue。

勾稽完成后，AI 才生成 cost center × category 的 Budget、Posted、Accrual、Total 和 Variance，并按影响大小排序主要 drivers。使用者可以从 category 下钻到 PO、transaction 或 accrual record，查看差异的组成。

AI 还可以起草 commentary，但它的起点不是一张总差异表，而是已经整理好的 driver 和来源记录。这样，“发生了什么”由数据结构支持，“为什么发生”则由 Finance 和业务 owner 补充业务背景。

这会改变月结中的任务分配。分析师不再先花数小时机械复制，再在截止前匆忙解释差异；系统持续准备勾稽和异常，人优先处理高影响项目与判断事项。

人的角色

Finance 决定正式 plan version、mapping、materiality 和 accrual treatment。模型可以标出异常，不能自行创建 journal、修改 accrual 或把 working forecast 当成 approved plan。

人还负责处理例外背后的业务含义。同一个未匹配 PO 可能是采购流程问题，也可能是供应商发票延迟；同一个 variance 可能来自 timing，也可能代表永久性 run-rate 变化。AI 可以把证据整理好，但不能替代会计判断和业务解释。

可复用资产

Day 5 沉淀的核心资产是一个 reconciliation workspace：

• Plan、GL、PO 与 accrual 的统一输入合同；
• 各来源 control totals；
• mapping 与 exception queue；
• accrual roll-forward；
• cost center/category 到 source record 的 lineage；
• variance drivers 与 reviewer commentary。

这套资产既服务月结，也可以进入 forecast refresh、vendor review 和 spend governance。过去只在月末使用一次的勾稽逻辑，可以成为持续更新的财务工作单元。

建议起步范围

在六个案例中，Day 5 是最适合作为财务团队起点的场景之一。

选择一个 marketing cost center 和一个月，准备 Approved plan、GL actuals、PO schedule 与 accrual register。第一版只做四件事：四源 control total 表、unmatched queue、accrual roll-forward，以及从 category 下钻到 transaction 的 lineage。

暂时不追求复杂 dashboard，也不自动写完整 commentary。先验证每次刷新能否得到一致的勾稽结果，是否能抓出重复 invoice、未冲回 accrual、错误 mapping 和 plan version 切换。只要这张工作区能把“月底谁的表对不上”变成一组可明确分派的 exceptions，就已经改变了 close 的组织方式。

公开证据范围： 主贴页面直接展示 Approved plan、posted actuals、PO-backed accruals、sources tied、unmatched 和 variance drivers；完整四源处理、下钻与调整流程来自作者描述。

图注：Day 5 把 reconciliation 从分析前的隐藏准备动作，变成所有参与者都能看到和处理的工作区。

Day 6｜Governed monthly close deck：把文件交付变成复核流程

业务问题

月结 deck 的问题很少是“不会做 PowerPoint”，而是数字、页面和叙事在多个工具里不断漂移。Source checks 在 Excel 中，dashboard 在浏览器中，slide updates 在 PowerPoint 中，review comments 则散落在邮件或聊天工具里。数字已经刷新，图表可能仍是旧版；slide owner 修改 commentary 后，其他人未必知道原来的 review 是否仍有效。

Day 6 的方法是把 close deck 从一个最终文件改造成一条有状态的工作流。输入、refresh、QA、readiness gap、slide owner review、finalizer 和 export 不再只是团队习惯，而是页面可以识别和推进的状态。

输入与背景

这个工作单元需要 approved data inputs、review rules、slide template、business context、period/scenario 定义和 slide ownership。每张 slide 还需要知道自己引用哪些 source totals、图表、commentary 和 evidence。

期间状态尤其重要。Open period、forecast/outlook 和 closed actual 不能混用同一种叙事。系统不仅要刷新数字，还要知道哪些句子在当前 period state 下可以写，哪些内容必须保留为 outlook。

AI 的角色

AI 首先组织 approved inputs，运行 monthly refresh，更新受控表格与 slides，并根据数据和 approved business context 起草 first-pass narrative。

随后，它检查两类问题。一类是 data logic：control totals、公式、期间和 scenario 是否一致。另一类是 rendered output：slide 上的标签、单位、图例、标题和 commentary 是否与底层数据一致。AI 还可以标出 readiness gaps，把未完成事项分派给对应 slide owner。

在 review 阶段，系统保留每张 slide 的状态、owner 和修改记录。任何数字、图表、标题或 commentary 发生变化时，对应 slide 都应自动退回待复核状态；最终导出只能基于当前已批准版本。Q&A 也可以被限制在当前 dashboard evidence 内，使 reviewer 能追问成本变化、GPU mix 或是否 ready to finalize，而不是得到脱离来源的泛化回答。

这个案例最清楚地展示了 AI 从“生成内容”转向“编排交付”。生成第一版 slide 只是其中一步，真正被重新设计的是从 refresh 到 review、再到 export 的整条路径。

人的角色

Finance 检查数字、挑战叙事并决定材料是否可分享。Slide owner 对自己的页面负责，finalizer 决定是否允许导出。AI 可以提示、起草和组织，不能替人签核。

人的角色因此从手工搬运和追踪版本，转向处理 readiness gaps、修改业务解释和承担明确责任。过去 review 可能表现为聊天里一句“looks good”；在有状态工作流中，批准需要对应具体 slide 和具体版本。

这也带来组织层面的变化：月结材料不再由一个“最熟悉整套文件的人”集中维护。每张 slide 可以有清楚的 owner，系统负责汇总状态，finalizer 只处理已经完成前置复核的版本。知识不再完全依附于某个 PowerPoint owner。

可复用资产

Day 6 最终沉淀的是一个 close workflow，而不只是 deck template：

• Approved inputs 与 review rules；
• 可刷新 slide components；
• Data QA 与 rendered-slide QA；
• 每页 readiness status、owner 和 comment；
• 受来源约束的 narrative 与 Q&A；
• Review、finalize 和 export 的流程状态。

这套资产可以逐月复用，也能逐步覆盖 management reporting、board materials 和经营复盘。每个月积累的不只是最终 PDF，还包括问题、修改、解释和复核记录。

建议起步范围

Day 6 是另一个适合作为起点的场景，但第一版只做三张 slide。

选择三张数据来源稳定、每月重复出现的 close slides，固定 input dataset、模板、owner 和 review checklist。AI 负责刷新数字、生成首稿 commentary、运行数据与渲染检查，再把三张 slide 分别交给 owner 复核。三张 slide 均通过复核后，由另一位 finalizer 导出。

第一版的目标不是节省整套 deck 的制作时间，而是验证三件事：同一输入能否稳定生成同一结构，未解决异常能否阻止进入 final review，修改之后 reviewer 能否清楚知道需要重新检查什么。只要这三张 slide 不再依靠文件名和群聊追踪状态，工作流就已经开始改变。

公开证据范围： synthetic GIF 的五帧画面直接展示 Overview、GL Drill、GPU Splits、Close-Slide Handoff、来源受限 Q&A，以及 finalizer/export blocker；完整 refresh、QA、sign-off、lock 和 ship 流程来自作者描述。

图注：Day 6 不再把月结 deck 视为单一文件，而是把数据、叙事、页面状态和复核动作放进同一个工作区。

图注：Close-Slide Handoff 将期间状态、slide owner、finalizer 和导出条件放在页面上，使 review 成为工作流的一部分。

第一阶段结论：AI 开始把财务工作变成可执行单元

Day 1–6 看起来覆盖六个不同场景：marketing allocation、sales signals、headcount、Opex dashboard、BvA reconciliation 和 monthly close deck。把工具名称和页面样式拿掉后，它们其实在做同一件事：把一段依赖人工搬运与个人经验的财务工作，拆成可以描述、执行和复用的工作单元。

一个工作单元通常包含五个环节：

输入
→ 处理
→ 异常
→ 复核
→ 输出

Day 1 的输入是 spend 与 outcome，处理是 response curve，异常是数据不足或约束冲突，复核由 Marketing Finance 与增长团队完成，输出是预算候选方案。

Day 2 的输入是客户沟通和 account context，处理是 evidence extraction 与 stage classification，异常是低置信和多源冲突，复核由 RevOps、Sales 和 Finance 完成，输出是 launch signal view。

Day 3 的输入是 position plan、HCM、ATS 和 hierarchy，处理是 position reconciliation，异常是重复或缺失 mapping，复核由 Finance、HR 和 Recruiting 完成，输出是 capacity view 与 leadership summary。

Day 4 的输入是受控 Opex dataset，处理是页面构建与 refresh，异常是数据或组件检查失败，复核由 Finance owner 完成，输出是可供业务使用的 analytical app。

Day 5 的输入是 plan、GL、PO 和 accrual，处理是 mapping、tie-out 和 variance analysis，异常进入 reconciliation queue，复核由会计与业务 Finance 完成，输出是 BvA workspace 与 commentary。

Day 6 的输入是 close data、rules 和 slide template，处理是 refresh、QA 与 narrative draft，异常表现为 readiness gaps，复核由 slide owner 和 finalizer 完成，输出是批准后的 close deck。

这种拆解带来三类工作变化。

第一，Finance 从“制作结果”转向“设计工作单元”

过去，优秀分析师的价值往往体现在个人熟练度：知道去哪里找文件，知道哪张表要复制，知道哪个数字容易错，也知道管理层偏好怎样的叙事。这些知识存在于个人操作中，很难被团队复用。

要让 AI 执行工作，团队就必须把这些隐性知识说清楚：输入是什么，规则是什么，什么情况算异常，谁来判断，最终要交付什么。于是，Finance 的一部分工作从亲手制作每个结果，转向设计可重复执行的任务。

这不是简单的效率改进。一个能被清楚描述的工作单元，才可能被复用、交接、评估和持续优化。即使暂时不用 AI agent，完成这一步也会减少对单个“Excel hero”或“deck owner”的依赖。

第二，人的判断从流程末端被拉到明确节点

在传统流程里，人工判断无处不在，却很少被单独识别。分析师边复制数据边修正 mapping，边写 commentary 边判断差异原因，最后再由管理者整体看一遍。判断与机械操作混在一起，导致自动化很难切分。

Day 1–6 提供了另一种分工：AI 先完成高频、可重复的准备工作，人集中处理需要责任和业务语境的节点。

• 模型提出预算候选方案，人批准资本配置；
• 模型分类客户信号，人处理冲突和资源调整；
• 模型整理岗位状态，人定义组织口径；
• 模型构建页面，人拥有财务指标；
• 模型完成勾稽与初稿，人做会计和业务判断；
• 模型准备 close materials，人复核并批准发布。

因此，AI 进入财务并没有消灭判断。它迫使团队更清楚地回答：哪些是可执行规则，哪些是需要专业判断的例外，谁对最后的决定负责。

第三，财务产物开始从文件变成持续运行的资产

Excel、PowerPoint 和 dashboard 当然不会消失，但它们不再是唯一成果。

Day 1 留下 allocation model 和决策历史；Day 2 留下 taxonomy、标注样本和 account signal model；Day 3 留下 position-level operating model；Day 4 留下 analytical app template；Day 5 留下 reconciliation workspace；Day 6 留下 close workflow。

这些资产的共同点是，它们可以在下一周期继续运行。新的数据进入后，团队不必从空白文件开始，而是刷新已有的模型、规则、页面和复核任务。人的修改和判断也可以成为下一轮输入。

这正是从“用 AI 做一次任务”走向“用 AI 承担一个工作单元”的分界线。

组织变化：不是简单减人，而是重新定义接口

当工作被拆成可执行单元，Finance、业务团队和 Data/IT 之间的接口也会变化。

Finance analyst 的角色会从结果制作人变成 workflow owner。过去，分析师通过熟练操作 Excel、记住文件位置和手工处理例外完成工作；新的职责是定义输入、指标、步骤、异常和输出，观察 AI 在哪里失败，再把修正沉淀为下一周期可以复用的规则。建模和业务判断仍然重要，但“能否把自己的工作设计成团队可运行的流程”会成为新的能力。

Finance manager 管理的也不再只是人员和 deadline。他需要管理一组工作单元：哪些可以自动运行，哪些等待 reviewer 复核，哪些因为数据问题被阻塞，哪些结果已经进入业务讨论。工作量不再只用“这周做了几份报告”来衡量；管理者还可以观察运行频率、异常数量、人工复核时间和被采用的建议。

业务 partner 的参与会更靠前。营销、销售、HR 和成本中心负责人不只在最后阅读结果，而要提前提供约束、taxonomy 和业务背景。Day 1 的渠道容量、Day 2 的销售阶段、Day 3 的岗位状态、Day 5 的 variance reason 都不是 Finance 或 AI 单方面能够定义。业务知识越早进入输入和规则，后面的 commentary 越不需要反复返工。

Data/IT 团队则从单个报表的交付者，转向共享底座的提供者。他们维护数据接口、身份权限、稳定运行环境和可复用组件；Finance 负责工作单元中的口径、判断和使用方式。这样既避免每个需求都进入工程排期，也避免每个 Finance 用户各自建立一套无法维护的连接和计算。

一个小型试点通常不需要成立新的 AI 部门。更实际的组合是：一名熟悉流程的 Finance owner，一名能够提供业务判断的业务 partner，以及一名帮助建立数据接口或运行环境的 Data/IT 同事。三方围绕一个周度或月度工作单元协作，先让它连续运行几个周期，再决定是否扩展。

组织变化也不等于立即减少岗位。早期更常见的结果是，团队把时间从搬运、格式调整和版本追踪，移到异常处理、业务讨论和流程设计。只有当多个周期稳定运行后，管理者才能看清哪些 capacity 被真正释放，又应该投向 forecast、decision support 还是更深入的业务合作。

这只是第一阶段

Day 1–6 说明，AI 已经可以进入财务判断之前的多个工作单元。它读取经营信号，整理跨系统数据，生成候选方案和页面，完成勾稽，准备 close materials，并把需要人处理的问题组织起来。

这组六天并不试图给出一套终局 operating model。它给出的阶段性变化更具体：

AI 正在把原本依赖 Excel、邮件、人工搬运和个人经验的财务工作，拆成输入、处理、异常、复核和输出等可执行环节。

一旦单个工作流可以持续执行，新的问题就会出现。

Marketing allocation 使用自己的数据与模型，sales signals 读取客户沟通，HC view 连接 HCM 与 ATS，Opex app、BvA workspace 和 close deck 又各自刷新。如果这些工具彼此独立，Finance 只是从六套人工文件变成六套 AI 工具，数据、口径和知识仍然会漂移。

所以下一个问题不是再做六个工具，而是：

当单个财务工作流可以被 AI 执行之后，如何让 P&L、Sheets、dashboard、forecast、management reporting 和知识库保持同步？

这将是 Day 7–12 要回答的问题。

主要原始来源

• Day 1｜Stacie Faggioli：https://www.linkedin.com/posts/stacie-faggioli-0820912_12daysofchatcodexstratfin-activity-7472321087754657792-I7zA
• Day 2｜Jake Stamell：https://www.linkedin.com/posts/jake-stamell_12daysofchatcodexstratfin-activity-7472677884411686912-r86v
• Day 3｜Kathir Sundarraj：https://www.linkedin.com/posts/katzsunn_12daysofchatcodexstratfin-activity-7473023143020769280-92zN
• Day 4｜Scott Dean：https://www.linkedin.com/posts/scott-dean-b8071a24_12daysofchatcodexstratfin-12daysofcodex4stratfin-activity-7473389078101524481-FUeg
• Day 5｜Amir Tavoli：https://www.linkedin.com/posts/amir-tavoli-840355177_12daysofchatcodexstratfin-activity-7473776537398546432-FQkW
• Day 6｜Kyle K.：https://www.linkedin.com/posts/kkober_12daysofchatcodexstratfin-activity-7474228889142050818-rmao
• OpenAI Finance 官方演讲（补充 Day 1–2）：https://www.youtube.com/watch?v=1NtS2KdnDok
• OpenAI Codex Sites 通用文档：https://developers.openai.com/codex/sites
• OpenAI 关于秘密提交 S-1 的官方说明：https://openai.com/index/openai-submits-confidential-s-1/

资料范围

本文基于截至 2026 年 7 月 27 日已保存的 Day 1–6 LinkedIn 原帖、主贴图片或 GIF、OpenAI 官方视频和公开评论样本。公开材料用于还原工作思路，不代表 OpenAI 对外提供了完整数据、代码或生产配置。文中在每个案例末尾简要说明直接画面与作者描述的边界，避免把资料限制写成正文主线。