当 AI 开始串起一整段财务工作

Day 1–6 把财务工作拆成可执行单元。Day 7–12 继续追问：当这些单元开始持续运行，怎样让数字、叙事、输出和组织记忆在不同工具之间保持一致？

导读

OpenAI Strategic Finance 团队在 #12daysofChatCodexStratfin 的前六天，展示了 AI 如何进入一段段具体财务工作：收集经营信号、整理跨系统数据、生成候选方案、构建分析页面、完成勾稽、准备月结材料。AI 并没有直接取代预算批准、会计判断或管理层签字，而是先把长期依赖 Excel、邮件、人工搬运和个人经验的步骤，改造成可以重复执行的工作单元。

Day 7–12 的重心发生了变化。

问题不再只是“AI 能不能完成某个任务”，而是：P&L 刷新后，Sheets、dashboard 和 slides 是否使用同一版本；月度 forecast 被拆到日度后，是否仍能回到原计划；模型建议加入账户信号时，是否重复计算了已经进入 baseline 的信息；一份材料被改写成音频时，数字与限定条件是否仍然保留；一个 multi-tab 长期规划模型由 AI 生成后，公式、场景和跨 tab 逻辑是否真正闭合；一份已经批准的 investor response，能否在未来被正确、合规地复用。

这六天可以分成两组：

• Day 7–9 处理 运行中的一致性。流程需要在多个输出、多个时间粒度和多种业务信号之间维护同一份经营事实。
• Day 10–12 处理 可复用的组织资产。输出不再停留在一次报告，而是变成可以转换、刷新、检索和积累的内容、模型与知识。

如果 Day 1–6 的关键词是“工作单元”，Day 7–12 展示的就是这些工作单元如何开始向上下游延伸，并具备连接成工作链的条件。单点工具可以提高一个人的速度；只有相邻环节逐步拥有共同输入、版本、证据和复核状态，Finance 才不会从六套人工文件迁移成六套彼此冲突的 AI 工具。

下面仍按同一组问题逐日拆解：业务瓶颈是什么，输入与背景是什么，AI 做什么，人保留什么责任，最终沉淀什么资产，以及建议从什么范围开始。

第一组：Day 7–9，让数字、时间与判断保持一致

Day 7｜P&L refresh：让多个财务输出共享同一次刷新

业务问题

在 close 和 forecast update 中，Finance 很少只维护一张表。Anaplan 中的计划发生变化后，团队还要更新 Sheets、CFO dashboard、variance chart、commentary 和 executive slides。同一批数字被复制到多个输出中，而每个输出又有自己的刷新顺序、公式和负责人。

传统流程的风险不只是慢，而是“看起来都更新了，实际上不是同一版本”。新的 Databricks actuals 可能搭配旧的 Anaplan forecast；Sheets 已刷新，slides 仍引用上个版本；数字一致，period、scenario、currency 或 narrative 却不一致。最终人工检查往往只能看到输出，无法确认每个页面到底用了哪次 source snapshot。

Day 7 将这个问题描述为 Source → Refresh → Analyze → Explain → Audit。它试图把多个输出的更新和检查组织成一次受控运行，而不是让分析师分别维护每个文件。

输入与背景

这个工作单元至少需要 approved Anaplan snapshot、Databricks extract、共同的 period/scenario/as-of、受控的 P&L/metric view、输出 mapping，以及一套可版本化的复核规则。

作者在一条已保存的评论回复中明确表示使用 Skills。这一点很重要：复核步骤不再只存在于某位分析师的习惯，而有机会被编码为可复用 playbook。但 Skill 只有在拥有版本、owner、测试、容差和执行记录时，才是控制资产；如果它只是一段不透明指令，就仍然可能稳定地产生错误结果。

AI 的角色

按照作者描述，Codex 负责 refresh、analyze、explain 与 audit handoff。若将其复原为生产工作流，更稳妥的实现是：系统先检查来源、schema 和 control totals，并生成受控的 P&L/metric view；Sheets、dashboard 和 slides 都从这份视图刷新，而不是彼此复制。

AI 再比较 variance、识别主要 drivers，并结合经过批准的 business context 或 meeting notes 起草 commentary。最后，由版本化规则检查 number、period 和 narrative，将未通过项目放入 exception queue。

公开 GIF 显示了 Ready for review、P&L AUDIT CHECK 和 AUDIT READY。这些状态的价值在于，它们把自动预检与人工复核交接区分开。这里的 AUDIT READY 应理解为“复核准备完成”或“材料已经具备人工复核条件”，不是“AI 已完成审计”，更不是“可以直接发布”。

人的角色

Finance owner 仍然选择正式 source version，确认 metric definition，调查异常，并判断 narrative 是否符合业务事实。Reviewer 需要查看 Skill 输出的证据与 exceptions，而不是只看一排绿色勾选项。

人的另一个责任是测试这套复核 Skill 本身。团队应在测试 workbook 中注入错误：错 period、旧 scenario、正负号错误、被值覆盖的公式、跨输出不一致和缺失 footnote。如果 Skill 无法发现已知错误，它就不能作为 AUDIT READY 的门禁。

可复用资产

Day 7 最值得沉淀的是一个 cross-surface reporting pipeline：

• 共同的 source snapshot 和受控 metric layer；
• Sheets、dashboard 与 slides 的输出 mapping；
• 版本化复核 Skill；
• number、period、unit、scenario 与 narrative 的一致性检查；
• exception queue、reviewer decision 和 publish version；
• 每次运行的 source、output 与 Skill hash。

这使 Finance 不再逐个更新文件，而是运行一次有输入、有状态、有证据的 reporting refresh。

建议起步范围

不要先覆盖完整 CFO pack。选择 Revenue、Gross Margin、R&D 和 Operating Profit 四项，连接一个 Anaplan snapshot、一个 Databricks extract、一个 Google Sheets 工作簿、一页 dashboard 和两张 slides。

第一版必须证明三件事：所有输出来自同一 snapshot；注入的已知错误能被 Skill 检出；任何数字或 commentary 变化都会撤销原 review status。做到这三点后，再扩展指标和页面。

公开证据范围： 两个 GIF 直接展示 refresh、CFO reporting pack、P&L audit checklist 和 audit handoff；真实 connector、Skill 内容、control totals、cross-output tie-out 和批准记录没有公开。

图注：Day 7 的关键不是自动刷新更多页面，而是让所有页面共享同一次刷新，并把 UI 中的 AUDIT READY 理解为人工复核的起点。

Day 8｜Ads forecast：把月度计划拆成日度 operating model

业务问题

很多财务模型按月规划，经营动作却按日发生。Ads revenue 会受到 weekday、holiday、seasonality、地区和用户趋势影响。月度 forecast 可以支持管理层计划，却很难回答某一天的流量、impressions 和 revenue 应该如何变化。

团队过去同时维护 monthly 与 weekly forecast；一旦 assumption 或业务逻辑改变，就要重新拆分、汇总和 reconcile。真正困难的不是把月度数字除以天数，而是在 month boundary、partial week、holiday 和 rounding 下，确保 daily、weekly 与 monthly view 使用同一组假设并能双向勾稽。

输入与背景

工作流需要 approved monthly plan、actuals snapshot、model/scenario/as-of、weekday profile、holiday calendar、country/product mapping 和明确的 rounding policy。

其中 calendar 不应被视为普通参数。Holiday uplift 是否覆盖 weekday effect，跨月的一周如何分配，不完整的 actuals 如何显示，都会改变结果。所有权重和优先级都需要版本化，否则同一个月可能因刷新日期不同而得到不同日度计划。

AI 的角色

系统依据已批准的 weekday、holiday 和 seasonality 规则，将 monthly forecast 分解为 weekly 和 daily operating plan，并生成 daily、weekly、monthly 三种视图和 budget-vs-actual comparison。分解公式、双向勾稽和 rounding residual 的处理必须是确定性的，不能让模型在每次运行时自由推理。

公开 GIF 展示了 Daily Ads Model、Ad-Eligible DAU、Billable Impressions、Ad Revenue & ARR、多个 case、时间粒度切换和 actuals 对比。这说明案例不只是输出一张拆分表，而是在构建一个可以比较版本、情景与时间粒度的 forecasting app。AI 可以辅助构建应用、比较情景、识别 drivers 并解释异常。

生产版本还应由确定性检查层完成每次分解后的双向 tie-out：daily 汇总到 weekly，weekly 汇总到 monthly，同时按 country、product 和 plan type 检查 subtotal。rounding residual 不能被静默丢弃，应被明确分配并记录。

人的角色

Finance 与业务 owner 定义 weekday、holiday 和 seasonality 逻辑，决定哪些 case 可以进入正式 forecast，并解释 actual deviation。系统可以计算多个 scenario，但正式版本仍由人批准。

人还要决定结果如何进入下游系统。评论区有人直接追问：调整是在 console 中实时写入 ERP/FP&A cube，还是先 staged for review？作者没有公开回答。对大多数企业，第一版应只生成 staged export；向正式 planning model 或 FP&A cube 写回，必须等到审批、最小权限、重复写入保护、写回勾稽和回滚能力全部建立。

可复用资产

Day 8 沉淀的是一个 time-grain forecast engine：

• 月度计划与实际快照；
• weekday/holiday calendar 与分解规则；
• daily、weekly、monthly 双向 tie-out；
• 版本化 scenario store；
• BvA、override、exception 与 approval history；
• staged export 和 rollback pointer。

它让月度财务计划真正进入日常经营，而不是另外维护一套与正式 forecast 脱节的 operational sheet。

建议起步范围

选择一个 metric、一个 country、两个 case 和三个月计划。显式写出 weekday 与 holiday weights，并注入 month-boundary、missing-holiday、stale-actual 和 rounding errors。

第一版只要能稳定生成 daily/weekly tables、完整汇总回 monthly total，并将所有异常留在 review queue，就已经足够。批准后保存 immutable version，输出到 staging table，不直接改写正式 cube。

公开证据范围： 13 帧 GIF 直接展示 synthetic forecasting app、case comparison、Daily/Monthly 切换和 BvA；weekly 画面、分解算法、tie-out、代码、测试和 writeback 均未公开。

图注：把月度 forecast 做成日度 operating model，核心不是颗粒度更细，而是不同时间粒度仍能回到同一个批准版本。

Day 9｜Account-level forecast adjustment：把模型与 Finance judgment 放进同一条审阅链

业务问题

Data Science 模型可以给出 account-level baseline，但最新业务变化往往先体现在 Gong、Slack、RevOps 记录、spend signals 或 product launch 信息中。Finance 如果忽略这些信号，forecast 会反应迟缓；如果直接把所有信号叠加到 baseline，又可能把已经进入模型的信息重复计算。

因此，Day 9 的真正问题不是“让 AI 替 Finance 改 forecast”，而是让模型 baseline、prior forecast、业务证据和人工 judgment 在同一个界面中可比较、可解释、可保存。

输入与背景

输入包括 DS model/version、prior forecast、point-in-time account signals、account master、event time 与 ingestion time、source entitlement，以及每类信号是否已经进入 baseline 的判断规则。

这里有两个基础控制。第一是 point-in-time：forecast cut-off 之后的信息不能回填到当时的建议中。第二是 cross-source dedup：同一客户事件可能同时出现在 Gong、Slack 和 RevOps，不能被算作三次独立增量。

AI 的角色

系统先完成 point-in-time filtering、entity matching、cross-source dedup 和 baseline-inclusion 检查，避免 future information leakage 与 double counting。AI 再从非结构化通话、消息和账户事件中识别 drivers，将 DS baseline、prior forecast、recent trend 和多源业务信号组织成 account-level review，并生成带 source evidence 的 recommendation、confidence 和 proposed impact。

公开 GIF 显示 Human review required、Apply recommendation、版本保存和 XLSX/Sheets export。更成熟的工作流中，Apply 不应直接改写正式 forecast，而是把建议送入 accept、modify 或 reject 队列。每个 reviewer decision 都要记录理由，由版本系统生成新版本，并通过确定性计算更新 quarter、FY 和 prior-forecast bridge。

AI 最有价值的角色，是减少 Finance 寻找账户背景、解释非结构化信号和起草调整建议的时间；它不能同时担任信号提取者、forecast owner 和最终批准人。

人的角色

Finance reviewer 判断某个信号是否真正改变 forecast，确认模型是否已经吸收类似信息，并为 override 写明理由。RevOps 或 account owner 负责纠正账户映射和业务上下文。

人还需要挑战 Confidence 86% 这类数字。没有 calibration set 和历史表现时，confidence 只是模型内部表达，不能直接成为批准阈值。对高金额调整，即使 confidence 很高，也应要求更强证据和更高审批层级。

可复用资产

Day 9 沉淀的是一个 forecast recommendation and override system：

• 版本化 DS baseline 与 prior forecast；
• 按类型记录、带时间截面的账户事件；
• baseline-inclusion 与 cross-source dedup 记录；
• 带 citation 的 recommendation；
• accept/modify/reject 和 override reason；
• immutable forecast version、export hash 与 downstream reconciliation。

它将过去散落在模型、聊天记录和 analyst judgment 中的 forecast adjustment，变成可以复盘的决策历史。

建议起步范围

使用十个 synthetic accounts 和一个季度，固定 DS baseline 与 prior forecast，制作带重复项和 future-dated records 的 Gong、Slack 与 RevOps events。

第一版必须通过 point-in-time filtering、entity matching、baseline-inclusion 和 cross-source dedup。只有带原始 citation 的建议才进入人工 review；版本写入受控版本库后，才允许导出 staging workbook。

公开证据范围： 公开 GIF 展示 adjustment、evidence、recommendation、human review、version 和 export；source records、schema、去重、point-in-time 测试、持久化和下游写回未公开。

图注：Day 9 不是用业务信号取代统计模型，而是让 baseline、证据、人工调整和版本历史出现在同一条审阅链中。

第二组：Day 10–12，把输出、模型与答复变成组织资产

Day 10｜Document/deck → podcast：把分析转成更易吸收的管理层简报

业务问题

Finance 和 Data Science 团队可能花数周完成分析，最后把一份 deck 发到 Slack。管理者没有时间逐页阅读，重要结论、限定条件和行动项也很容易淹没在附件中。

Day 10 处理的是 insight delivery。它不产生新的 forecast，而是把已经批准的 document 或 presentation 转成 podcast-style briefing，让管理者在通勤或会议间隙获取核心信息。

Day 10 延伸的是同一事实在不同交付形式之间的一致性。同一份批准材料可以产生新的交付形式，但不能产生第二套事实：source deck 是事实来源，script 和 audio 都是派生版本，不能在转换过程中丢失数字、期间和限定条件。

输入与背景

输入首先应是 approved source file，而不是任意 working draft。系统还需要 audience、长度、tone、voice、pacing、获准使用的 TTS project，以及必须保留的数字、日期、单位、排名口径、scope exclusion 和 footnote。

一份 executive script 不只是摘要。它需要知道哪些 caveat 在压缩时不可删除，哪些 chart title 不能脱离 denominator，哪些 speaker notes 与表格冲突时必须升级给人。

AI 的角色

原帖说明 Skill 会识别核心叙事和关键结论，并转成 podcast-style audio。若用于正式管理层材料，建议将流程进一步拆开：AI 提取 narrative、numbers 和 caveats，并起草带 slide/page citation 的 script；确定性检查核对数字、单位、日期和范围限定；内容 owner 批准最终脚本；TTS 只负责生成音频。生成后，系统再用 transcript 与批准 script 做差异检查，并将 pronunciation 或遗漏问题送入 review。

公开视频直接展示了一段约 111 秒的 podcast 成品，其内容与 OpenAI Q1 2026 Signals 的核心事实和限定条件基本一致。但画面没有展示 source deck、Prompt、Skill、script、TTS 参数或人工批准。因此，成品存在且事实大体一致，并不等于生成过程已经可审计。

人的角色

内容 owner 批准 script，确认关键数字和 caveat 没有因追求流畅而被弱化。Reviewer 还要检查人名、缩写、币种、百分比和专业术语的发音。

对 confidential deck，Security/IT 需要确认文件进入哪个 API project、是否允许留存，以及输出 audience 是否与 source ACL 一致。音频的传播范围不能因为“只是摘要”而宽于原文件。

可复用资产

Day 10 沉淀的是一个 governed executive briefing pipeline：

• approved source 与版本 hash；
• claim/number/caveat inventory；
• 带 citation 的 script；
• script approval 与 change log；
• 固定 TTS model、voice、instructions 和 speed；
• audio transcript diff、pronunciation review 和 distribution ACL。

真正可复用的不是某一种声音，而是从来源到 script、再到 audio 的完整 lineage。

建议起步范围

使用五页 synthetic Finance deck，放入十个数字、一个排名表、两个 footnotes、一个 scope exclusion、一条与正文冲突的 speaker note 和几个难读名称，生成 90 秒 briefing。

只有数字、单位、期间和限定全部保留，冲突被升级，script 经人批准，音频 transcript 与 script 一致，并带 AI-generated disclosure 时才通过。

公开证据范围： 原帖直接说明团队构建了可复用 Codex Skill，将 document 或 presentation 转成 podcast，并可调整 voice、tone、pacing 和 audience；视频、音轨、字幕和 transcript 证明最终 podcast 存在，且核心事实可与 OpenAI Q1 2026 Signals 官方页面交叉核验。带页码引用的 script、数字检查、人工批准、transcript diff 和发音复核属于本文提出的生产化复原，公开材料未展示这些环节。

图注：Day 10 展示了管理层接收信息的新形式。生产价值取决于来源、脚本、音频之间是否保留完整证据链。

Day 11｜AI-native 长期规划模型（LRP）：让 AI 生成模型，也让模型接受财务控制

业务问题

长期规划模型至少需要让产品、情景、期间、revenue、COGS、OPEX、working capital 和 P&L 保持联动。若模型进一步用于完整预算、融资或董事会规划，通常还需要扩展到 cash flow 和 balance sheet，并完成三表勾稽。

AI 可以在短时间内生成 multi-tab workbook，这比逐格搭建快得多。但“表已经填满”不是模型完成的标准。broken link、hardcode、sign error、unit mismatch、scenario 未传播和跨 tab 逻辑断裂，都会藏在看似完整的 workbook 中。

输入与背景

Day 11 从 detailed Prompt 和 blank workbook 开始。生产版本还需要 versioned requirements、data dictionary、product/scenario config、source snapshot、model architecture、formula policy、color convention、named range convention 和验收测试。

AI 在动手修改已有模型前，应先提出 change plan：哪些 sheet 新建，哪些 range 会覆盖，哪些现有公式需要保留。否则一次大范围生成很容易破坏已有模型，却无法说明改了什么。

AI 的角色

AI 构建 workbook 结构、helper columns、named ranges、hidden support tabs、公式、flattened Model Dataset 和 Outputs Pivot。公开视频展示了从 blank Google Sheet 到 P&L Modeling 和 Outputs Pivot 的过程，说明它已经能够生成复杂模型形态。

随后必须由独立检查层运行 formula、link、sign、unit、period、scenario propagation、Source Key uniqueness、dataset-source reconciliation 和 pivot-dataset reconciliation。若企业将模型扩展到 cash flow 和 balance sheet，再增加 three-statement tie-out。生成模型的 agent 不应仅凭自己的总结宣告模型通过。

对 live data，AI 只能读取受控 staging/import tab，并保存 source system、query/version、extracted-at、as-of、row count 和 control total。refresh 失败时必须阻断发布，不能静默沿用旧 actuals。

人的角色

FP&A owner 定义 driver、scenario 和业务关系，审查关键公式，并比较 AI 生成版本与独立 baseline。Accounting 或 Finance reviewer 检查 working capital 与跨 tab 逻辑；若模型被扩展为三表，再负责相应勾稽。Data owner 管理 source refresh 和 lineage。

人还需要决定模型何时可以从 prototype 进入正式使用。一个 sanitized example 在数小时内生成，不代表它已经适合预算或 board planning。只有模型结构、公式、测试、版本和 review 都可以重放，速度才有意义。

可复用资产

Day 11 沉淀的是一个 model factory with controls：

• versioned requirements 与 detailed build Prompt；
• workbook architecture 和 formula convention；
• source import contract 与 lineage；
• 公式、勾稽和 scenario 的自动化测试；
• source tabs → Model Dataset → Outputs Pivot 的 traceability；
• reviewer sign-off、workbook/source hashes 和 controlled export。

这会把 AI 从一次性的 spreadsheet writer，变成受测试约束的模型构建工具。

建议起步范围

使用一个包含三个产品、三种情景和八个季度的 synthetic 模型，主动加入 broken link、hardcode、duplicate Source Key、stale actuals 和 unit mismatch。若试点明确扩展到完整三表，再加入“无法平衡的资产负债表”等错误。

只有当自动测试发现全部已注入错误、dataset 与 pivot 完成勾稽、关键结果与独立 baseline 一致，并保存 reviewer、workbook 和 source hashes 时，试点才算通过；完整三表闭合只适用于已明确纳入 cash flow 和 balance sheet 的扩展版本。

公开证据范围： 31 秒视频直接展示 detailed Prompt 上半部分、blank start、multi-tab 模型、P&L Modeling 和 Outputs Pivot；完整 Prompt、workbook、公式、测试、three-statement tie-out、live refresh 和人工 review 未公开。

图注：Day 11 显示 AI 能快速生成复杂 workbook 形态；财务团队仍要用独立测试证明它是一个模型，而不只是一组看起来完整的表。

Day 12｜IR Agent：把批准过的答复变成组织记忆

业务问题

Investor diligence 不是普通知识问答。同一个问题在不同融资阶段、不同投资者和不同时间点，可能允许使用不同材料。数字会更新，叙事会被替代，某些信息只允许向特定对象披露。

传统流程依赖少数人记住历史：上次如何回答，哪些数字已经批准，什么内容后来被替换，哪些材料可以给谁。随着 request 数量增加，团队容易重复劳动，也容易复用一份已经过期或不适用于当前对象的答复。

Day 12 的核心不是建立一个“会回答投资者问题的 chatbot”，而是把 request、source、draft、approval、delivery 和最终答复组织成可持续更新的 institutional memory，也就是组织记忆。

输入与背景

系统需要 authorized investor request、investor/deal/stage、recipient entitlement、point-in-time approved source set，以及 Legal、Comms 和 executive approval policy。信息治理应拆成两个维度：基础访问等级设为 Public、Internal、Confidential、Restricted；披露限制另设 MNPI、investor-specific、deal-stage-limited、legal-review-required 等标签。MNPI 不是与 Public 或 Confidential 平行的访问等级。

批准过的答复不能只是被追加到 vector store。每条记录都需要 effective-from/to、supersedes/superseded-by、适用对象、禁止复用条件、source passage、claim、number、period、as-of 和 approver。检索必须先按基础权限过滤，再按披露标签、投资者、融资阶段和有效日期做确定性过滤，最后才进行 semantic ranking。

AI 的角色

按照作者描述，IR GPT 会基于来源资料起草 investor diligence response，并将批准后的最终答复回写 curated knowledge base；后来还扩展到分析请求、制作投资人材料和支持其他 investor inquiries。要把这一方法用于正式 IR 流程，还需要先由确定性系统完成 entitlement、披露标签、投资者、融资阶段和有效日期过滤，再由 AI 在允许的 source set 中检索、生成带 passage-level citation 的 draft，并检查数字、日期、名称、as-of、冲突与 staleness。

最终答复经必要的 Legal、Comms 或 executive approval 后才能发送。只有实际批准并发送的 final response，才可以连同 approval record 回写 curated knowledge base。

公开截图显示 IR Agent、Google Drive、investor-reporting Skill、ChatGPT/Slack channel 和部分 role instructions。这至少证明存在相应的 agent configuration。原帖文字支持基于来源起草答复和将批准答复回写知识库，但 passage-level citation、entitlement filter、effective dating、delivery hash 和 supersession schema 属于本文提出的企业化设计；截图没有直接展示这些机制的运行证据。

人的角色

IR owner 对每份外部答复负责，检查 citation、数字、措辞和适用范围。Legal、Comms 和 Executive 按 policy 处理 MNPI、selective disclosure、重大承诺和融资表述。

人的另一项工作是维护知识有效期。一次批准并不意味着永久批准；新的财务期间、融资阶段或公司表述出现后，旧答案需要失效或被明确标记为已由新版本取代。否则 feedback loop 会把一份历史错误放大成“组织记忆”。

作者提到 2,000+ diligence requests、10,000+ estimated hours saved、over $180 billion of capital raised 和 no financial advisor engaged。公开材料没有 request log、时间底稿或归因方法。这些数字描述的是作者所称的三人团队在多个融资周期中的整体工作规模，不代表 IR Agent 对募资金额的独立增量贡献，也不能直接当成 agent ROI。

可复用资产

Day 12 沉淀的是一个 approved-response knowledge system：

• request、investor、stage 与 entitlement；
• point-in-time source set 与 passage citation；
• claim/number/date/as-of map；
• draft-final diff 和 approval chain；
• controlled delivery 与 artifact hash；
• effective-dated approved response；
• supersession、reuse scope 和 activity logs。

它让组织记忆不再只是“更容易搜到旧答案”，而是能回答旧答案在什么时间、对什么对象、基于什么来源、经过谁批准。

建议起步范围

不要直接复制融资场景。先建立 synthetic diligence room，包含 Public、Internal、Confidential 和 Restricted 四种访问等级，并为部分资料附加 MNPI、特定投资者适用和融资阶段限制等标签；再加入两个融资阶段、一个 superseded answer、两组冲突 as-of 数字，以及 50 个含重复和对抗性输入的请求。

验收要求包括零 MNPI 泄露、100% claim-level citation、过期答复全部排除、冲突全部升级、entitlement filter 可重复、review decision 全记录，并且只有 approved final response 能进入知识库。

公开证据范围： 静态截图直接展示 agent、Google Drive、Skill、文件、channel 和部分 instructions；真实 request、检索、citation、批准、发送、知识回写、完整 Prompt/Skill 和 KPI 底稿均未公开。

图注：Day 12 最重要的不是“记住更多答案”，而是让每个答案都带着来源、权限、有效期和批准记录进入组织记忆。

第二阶段结论：Finance 需要为工作链建立共同条件

Day 7–12 看起来覆盖 reporting refresh、Ads forecast、account adjustment、podcast、LRP 和 investor relations。把应用名称拿掉后，它们共同处理四件事。

第一，所有输出必须回到同一份受控事实

Day 7 要求 Sheets、dashboard 和 slides 来自同一次 P&L refresh；Day 8 要求 daily、weekly 与 monthly forecast 双向勾稽；Day 9 要求 account recommendation 能回到 DS baseline、prior forecast 和原始业务证据；Day 10 要求 audio 回到批准 script 与 source deck；Day 11 要求 pivot 回到 dataset、formula 和 source row；Day 12 要求 investor answer 回到当前有效、允许披露的 source passage。

因此，财务 AI 的基础设施不只是 connector。它还需要 source snapshot、metric definition、version、hash、citation 和 lineage。没有这些，AI 可以让六种输出生成得更快，却无法证明它们说的是同一件事。

第二，状态比“完成”更重要

传统自动化经常只有 running、success 和 failed。财务工作需要更细的状态：source approved、refreshed、exception、review ready、reviewed、approved、staged、published、superseded。

AUDIT READY 不等于已审计，Apply recommendation 不等于已写回，音频已生成不等于 script 已批准，workbook 已填充不等于模型已通过，旧答复被检索到也不等于仍可使用。

一条成熟工作链必须明确：现在完成了哪一步，下一步由谁负责，什么变化会使原状态失效。

第三，人工判断需要留下结构化痕迹

Day 7 对 exceptions 的复核、Day 8 的 scenario approval、Day 9 的 accept/modify/reject、Day 10 的 script approval、Day 11 的 model sign-off 和 Day 12 的 external-response approval，都不应只留在聊天里一句“looks good”。

Finance 的人工判断至少要保存 decision、reason、reviewer、timestamp 和对应 artifact version。这样，组织才能区分 AI 自己的建议与人承担责任的决定，也能回看哪些建议被采用、被修改或被拒绝。

第四，真正的复用来自规则、测试与记忆

Day 7 将复核规则封装为 Skill；Day 8 将 calendar logic 做成分解引擎；Day 9 将 override 变成版本历史；Day 10 将内容转换做成 briefing pipeline；Day 11 将 detailed Prompt 与 tests 变成 model factory；Day 12 将 approved response 做成 effective-dated knowledge。

这些资产都可以跨周期运行。但可复用也会放大错误：错误 Skill 会反复放行，错误 holiday rule 会持续扭曲日度计划，错误答复会被知识库不断召回。复用资产必须同时拥有 owner、version、tests、known limitations 和 retirement/supersession 机制。

对 Finance Leadership 的实际含义

如果只看页面，Day 7–12 很容易被理解为“OpenAI 财务团队又做了六个 AI 应用”。更重要的变化是，Finance 的管理对象开始从文件和个人任务，转向一组具备持续运行条件的工作单元，以及它们之间可能形成的连接关系。

Finance Leadership 需要共同建立四类底座：

1. 受控数据与定义：共同 source snapshot、as-of、scenario、metric registry 和 mapping；
2. 工作流状态：exception、review、approval、staging、publish 和 supersession；
3. 证据与测试：control totals、formula checks、citation、lineage、known-error tests 和 output hash；
4. 责任与权限：owner、reviewer、approver、recipient entitlement 和 rollback。

这也改变了项目优先级。团队不应先追求“一个 agent 覆盖所有 FP&A”。更好的顺序是：选择一条高频工作链，固定输入与批准边界，建立异常队列和独立测试，让它连续运行几个周期，再把相邻环节连接进来。

例如，可以从 Day 7 的四项 P&L 指标开始，先连接 Sheets、dashboard 和两张 slides；稳定后，再加入 Day 10 的 executive audio briefing。也可以从 Day 9 的十个账户开始，先记录 recommendation 与人工 override；稳定后，再把 approved forecast version 送入 Day 8 的日度 operating model。连接顺序由业务依赖决定，而不是由哪个 demo 更吸引人决定。

Day 1–12 走到了哪里

从 AI4FIN 的归纳视角看，Day 1–12 可以排列成一条逐步扩大的路径：

经营信号与财务输入
→ 可执行工作单元
→ 跨工具、跨时间粒度的一致性
→ 异常、复核与批准状态
→ 可复用模型、内容与知识

Day 1–3 扩展 sensing layer，让 Finance 更早看见营销、销售与人员变化。Day 4–6 将分析页面、勾稽和 close deck 变成有状态的工作单元。Day 7–9 让多个输出、多个时间粒度和多源信号保持一致。Day 10–12 则开始把管理层输出、长期规划模型和批准答复沉淀为组织资产。

走到这里，十二天完成的是一组财务能力的形成，还不是最终 operating model 的闭环。公开案例已经分别展示了 P&L refresh、日度 forecast、account adjustment、podcast、LRP 和 IR 知识库的目标形态与工作方式，但尚未回答几个更大的问题：这些能力如何被组合，如何在不同团队之间复用，谁负责 routing、handoff、schedule 和 exception，局部 agent 的输出又如何进入统一的 Finance 管理体系。

这组案例同样没有证明 AI 已经可以独立经营财务部门。公开材料大量使用 synthetic、sanitized 或 illustrative data，完整 Prompt、Skill、schema、测试、权限和 production logs 很少公开。它证明的是另一件更具体的事：

这组案例显示，AI 的应用边界已经不只是在 Excel 旁边回答问题。它开始与确定性系统配合，进入财务工作的输入、刷新、异常、复核、发布和记忆；财务计算、tie-out、权限过滤和状态转换仍由公式、代码与规则系统约束，人的职责则转向定义口径、挑战模型、处理例外、批准情景并承担最终责任。

但“多个可复用能力已经出现”，不等于“由 Finance 管理的工作链已经形成”。从单个 dashboard 的直接修改，到可重复回答新问题的分析引擎，再到 Treasury workflow 和跨组织 Agent Network，后续 Bonus Days 才会继续补上能力组合、专业 agent、orchestration 与治理这一层。

因此，Day 7–12 更适合作为第二阶段的落点，而不是整组分享的终点。Bonus Days 将继续回答最后一个问题：

当模型、内容、知识和工作单元都可以复用之后，Finance 如何把它们组织成一套能够跨团队运行、交接、复核和追责的工作体系？

主要原始来源

• Day 7｜Tanika Mehra：https://www.linkedin.com/posts/tanika-mehra_12daysofchatcodexstratfin-strategicfinance-activity-7474498251711225856-AHXK
• Day 8｜Stacy Young：https://www.linkedin.com/posts/stacylyoung_12daysofchatcodexstratfin-activity-7474854257913917442-Z9oR
• Day 9｜Jackson Wang：https://www.linkedin.com/posts/jacksonzwang_12daysofchatcodexstratfin-activity-7475201066985226241-aBMO
• Day 10｜Varghese George：https://www.linkedin.com/posts/varghese-george-975a3791_12daysofchatcodexstratfin-activity-7475667802196963328-MO8F
• OpenAI Q1 2026 Signals｜How ChatGPT adoption broadened in early 2026：https://openai.com/signals/research/2026q1-update
• Day 11｜Guilherme Souza：https://www.linkedin.com/posts/souzag_12daysofchatcodexstratfin-activity-7475945297286782977-zbmZ
• Day 12｜Chengpeng M.：https://www.linkedin.com/posts/cpmou_12daysofchatcodexstratfin-activity-7476340613483868174-eXdW
• OpenAI ChatGPT for Excel：https://openai.com/index/chatgpt-for-excel/
• OpenAI ChatGPT for Excel and Google Sheets Help：https://help.openai.com/en/articles/20001063-chatgpt-for-excel
• OpenAI Codex Sites：https://learn.chatgpt.com/docs/sites
• OpenAI Text-to-Speech guide：https://developers.openai.com/api/docs/guides/text-to-speech

资料范围

本文基于截至 2026 年 7 月 27 日已保存的 Day 7–12 LinkedIn 原帖、主贴图片/GIF/视频、公开评论样本与 OpenAI 官方材料。公开资料用于还原工作方法，不代表 OpenAI 对外提供了完整数据、代码、Prompt、Skill、测试或生产配置。作者披露的时间节省、使用规模和资本募集数据，在没有公开底稿时均保留为作者陈述，不写成经独立验证的成效。