当财务开始管理一组 AI 能力

Day 1–12 展示了财务工作如何被拆成可执行、可复用的工作单元。最后四个 Bonus Day 继续追问：这些单元如何被组合成分析产品、专业工作流和跨组织能力网络，并由 Finance 统一管理？

导读

在 Day 1–6 中，OpenAI Strategic Finance 团队展示了 AI 如何进入营销支出、销售线索、人员规划、Opex dashboard、BvA 和 close deck。Day 7–12 则把范围扩展到 P&L refresh、日度 forecast、账户级调整、管理层音频、长期规划模型和 IR 组织记忆。到这里，AI 已经不只是回答问题，而是在处理输入、刷新、分析、复核、交付和知识沉淀。

最后四个 Bonus Day 改变了设计单位。

Finance 不再只问“某一个任务能否自动完成”，而开始面对四个更接近 operating model 的问题：分析师能否在浏览器中直接表达修改意图，而不用反复翻译给工程团队；一个 dashboard 能否升级为可以持续回答新问题的分析引擎；专业 agent 能否在邮件、项目、KYC 和银行运营之间推进工作，同时不越过人的授权边界；当一个 Finance partner 同时支持十多个团队时，共享能力、局部背景和中央编排应如何分层。

从 AI4FIN 的归纳视角看，四个案例可以排列成一条扩展路径：

直接修改单个分析产品
→ 建立可重复回答新问题的分析引擎
→ 建立有审批边界的专业财务 agent
→ 用共享能力与中央编排管理多个组织场景

这条路径的价值不在于页面越来越复杂，也不在于 agent 数量越来越多。它显示 Finance 的管理对象开始从文件和单次任务，转向一组具有输入契约、状态、权限、证据、复核和生命周期的数字能力。

下面延续前两篇的同一组问题：业务瓶颈是什么，输入与背景是什么，AI 做什么，人保留什么责任，最终沉淀什么资产，以及建议从什么范围开始。

第一组：Bonus Day 13–14，让 Finance 直接构建并持续使用分析产品

Bonus Day 13｜Browser annotations：缩短财务意图到产品修改的距离

业务问题

Finance 要做一张管理层 dashboard，通常先在 Sheets 中画草图，再向 Data Science 或工程团队提交需求。双方需要确认数据表、指标定义、页面布局和格式；初版发布后，Finance 还会继续要求移动 KPI、修改坐标轴、增加 plan line 或重排图表。

这里最耗时的不是某一张图，而是翻译循环。Finance 用业务语言描述需求，数据团队将它翻译成查询和前端实现，Finance 再看页面指出偏差。小改动也要重新进入排期，数据口径与视觉修改混在同一轮沟通中。

Kevin Cong 展示的工作方式是：先让 Codex 使用经 Data Science 批准的数据表和既有 dashboard 模板生成 v1，再在 Codex 应用内浏览器中直接圈选页面区域并提出修改。公开 GIF 中，用户在 localhost dashboard 上标注 KPI、坐标轴、Payments cost bar 和 plan line，Codex 随后更新页面。

输入与背景

这类工作至少需要 approved table、受控 metric definition、已有模板、明确的 as-of、展示规范和发布边界。

“批准过的数据表”并不等于“批准过的指标”。表可能是可信的，生成的 SQL 仍可能重复 join、选择错误 grain，或使用过期 mapping。旧模板也可能保留过时标签和业务逻辑。因此，浏览器 annotation 适合表达视觉与交互意图，不能替代数据定义和勾稽。

公开素材明确标注 Synthetic demo data。它直接展示了浏览器标注与页面修改的交互方式，但没有公开 schema、SQL、公式、测试、source control、部署记录或真实耗时。

AI 的角色

AI 可以读取批准过的输入契约和页面模板，生成 dashboard 初版，并把 Finance 在浏览器中的局部标注转成代码修改。确定性测试层负责运行 query tests、control-total reconciliation 和 visual regression comparison；AI 则解释失败原因，并把不通过项目整理给 reviewer。

真正的新能力不是“AI 会画图”，而是 Finance 可以在成品界面上直接表达意图。业务语言、页面区域和代码变更被放进同一个 workspace，减少了多轮截图、文档和 ticket 之间的信息损失。

但 annotation 只应触发 preview branch。每次视觉修改都需要保留变更 diff，并重新运行 metric、query、responsive layout 和 accessibility 检查。直接在浏览器里改得更快，不应意味着绕过版本控制和发布门禁。

人的角色

Finance owner 决定使用哪些指标、如何解释结果、页面服务于哪类决策，并确认视觉修改没有改变业务含义。Data owner 仍然批准来源、grain、join 和 metric version。Reviewer 检查 query tests、control totals、截图差异和敏感信息暴露。

页面发布前，应区分 preview、review ready、approved 和 published。任何来源、公式或指标版本变化，都应撤销旧的批准状态。

可复用资产

Bonus Day 13 最值得沉淀的是一个 finance-owned dashboard development loop：

• allowlisted、read-only 的数据来源与 semantic layer；
• 版本化的 metric registry 和 dashboard template；
• 浏览器区域标注与代码变更记录；
• SQL/query tests、control totals 与 join-cardinality checks；
• visual regression、responsive 和 accessibility tests；
• preview、review 与 publish 状态；
• source、template、code 和 output 的完整 lineage。

它让 Finance 更直接地构建分析产品，但不把数据工程与发布控制变成隐形步骤。

建议起步范围

选择一张使用 synthetic data 的 contribution-margin dashboard，固定月度 schema 和三个核心指标。故意放入一个 duplicate join 和一个错误轴标签，再要求 Codex 完成三次浏览器标注修改。

只有在总额始终勾稽、两个已知缺陷被检出、source/as-of 一直可见、每次修改都有 code diff，并且发布必须经过批准时，才算通过第一轮验证。

公开证据范围： 原始 GIF 直接展示 Codex 对话、localhost browser、approved-finance-data table、synthetic contribution-margin dashboard、区域标注和页面更新；真实 SQL、数据血缘、指标定义的批准记录、测试、部署与时间日志未公开。

图注：浏览器 annotation 缩短的是“财务意图到代码修改”的距离；数据口径、勾稽和发布审批仍需独立控制。

Bonus Day 14｜API business analytics engine：从一次查询到可重复回答新问题

业务问题

API 业务的经营问题会同时跨越 model、customer、segment、usage、token monetization、latency 和 compute efficiency。每增加一个切法，分析师都可能重新写 SQL、寻找数据 owner、核对定义、拼接表格并制作一次性报告。

这种模式能回答已知问题，却很难形成累积能力。新问题不是在旧分析上继续，而是重新开始；同一客户、模型或收入指标可能在不同报告中使用不同 mapping；bridge、cohort、retention 和 top-account analysis 也很难保持共同 as-of。

Jacob Blau 展示的是一个交互式 API analytics application。60 秒视频中可以看到 API ARR by model group、L7D ARR bridge、Top 25 accounts、customer deep dive、cohort/retention heatmap，以及 date、lookback、segment 和 model-group controls。作者称 Codex 帮助构建了查询、组合数据、计算、刷新与报告视图的端到端流程。

输入与背景

这类引擎的核心不是更多图表，而是统一的数据与定义层：ARR、usage、tokens、latency 和 compute cost 必须拥有版本化口径；customer、contract、segment 与 model mapping 必须带 effective date；所有视图必须引用共同 snapshot。

如果这些条件没有固定，交互式切片只会更快地产生互相矛盾的答案。尤其是 cohort 与 bridge：合同日期选择、客户合并、模型重分类、late-arriving data 和 survivorship bias 都会改变结果，却不一定在页面上暴露。

公开视频展示了界面广度和交互性，但没有说明数据是真实、匿名还是 synthetic，也没有公开 SQL、schema、refresh job、计算逻辑或权限配置。

AI 的角色

AI 可以负责数据目录发现、生成受约束查询、组织分析步骤、组合已批准数据集和构建标准视图，并将新的业务问题映射到已有 metric registry。确定性组件负责指标计算、缓存刷新、bridge 闭合、权限过滤和 freshness 检查。对真正的新定义，系统应返回“unsupported definition”并请求 owner 决策，而不是自行发明口径。

分析引擎还应为每张图保存 query、source snapshot、metric version 和 control total。bridge 必须算术闭合，cohort 边界必须可重复，customer deep dive 必须经过 row-level access control。刷新若部分失败，页面应显示 stale 或 incomplete，不能把不同期间的数据拼成一个看似完整的 dashboard。

人的角色

Finance 与 Data 共同拥有指标、实体 mapping 和异常处理。业务 partner 决定哪些新问题值得沉淀为标准视图，哪些只是一次性探索。Reviewer 需要挑战 cohort bias、bridge logic 和客户分层，而不是只确认图表是否美观。

人的工作也包括控制分析能力的扩张。引擎可以快速增加切法，但每一个新 metric、mapping 和 reusable view 都会产生维护成本。未经批准的定义不应因为出现在 dashboard 中就自动成为事实标准。

可复用资产

Bonus Day 14 沉淀的是一个 governed business analytics engine：

• 统一 metric/semantic layer；
• customer、contract、segment 与 model 的 effective-dated mapping；
• read-only query 权限和 row-level access control；
• 共同 source snapshot 与 freshness state；
• SQL tests、join-cardinality checks 和 source-to-dashboard reconciliation；
• bridge、cohort 与 retention 的确定性计算组件；
• 新问题 eval set、unsupported-definition queue 和 reviewer decision；
• query、calculation 与输出的 lineage。

它与普通 dashboard 的区别是：新问题可以复用已有数据契约、计算组件和控制，而不是重新搭一份报告。

建议起步范围

用 synthetic SaaS/API dataset 建立五张标准视图：ARR trend、model bridge、Top Accounts、usage/TPM 和 contract cohort。固定 metric registry，并注入 duplicate join、late-arriving record、model remapping 和 cohort-boundary 四类测试。

验收标准不是“能生成五张图”，而是每张图都能追溯到 source row 和 metric version，所有总额闭合，权限过滤有效；面对一个新的切法时，引擎要么使用已批准定义完成回答，要么明确升级，不得静默创造新口径。

公开证据范围： 原始视频直接展示 API analytics application 的多种视图、筛选和 drill-down；作者关于一至两天构建、查询、刷新和计算自动化的描述未被独立验证，底层 SQL、数据、定义、测试与部署均未公开。

图注：分析引擎的门槛不是能否增加更多视图，而是新问题是否仍然回到同一套指标、mapping、snapshot 和控制。

第二组：Bonus Day 15 与 Final Bonus，把专业工作流组织成可治理的能力网络

Bonus Day 15｜Treasury Analyst：速度必须与授权边界一起设计

业务问题

Treasury banking operations 同时管理账户开立与关闭、signer 与 mandate、KYC request、支付和币种能力、银行 blocker、M&A integration 以及多个实体的项目进度。大量关键状态散落在邮件、tracker 和个人记忆中：这封邮件属于哪个实体和账户，缺什么材料，下一步由谁完成，什么时候 follow up，过去相似 KYC 请求如何处理。

这里的风险不只是延迟。邮件被关联到错误实体、过期 precedent 被当成当前要求、signer authority 被错误推断，或包含敏感信息的草稿发给错误银行，都会成为真实控制事故。

Jane Ro 展示了一个 Treasury Analyst plugin 与 Banking Operations application。公开 demo 中可以看到 projects、accounts、signers、legal entities、bank contacts、KYC/compliance、control exceptions、migration review 和 audit history。系统会给出 analyst summary、proposal 和 next action，并把动作放入 Analyst approval queue。

输入与背景

这类专业 agent 需要的不是一份宽泛 prompt，而是受控的公司知识、项目规则、实体与账户主数据、signer/mandate 权限、KYC evidence standard、bank-specific precedent、邮件 playbook 和 portfolio state。

每条建议都必须引用具体 email、project、entity、account、mandate 和 precedent。precedent 只能帮助准备材料，不能证明银行已经接受，也不能替代当前 KYC 要求。邮件内容本身是不可信输入，还要防止 prompt injection。

公开页面明确标注 DEMO DATA ONLY 和 Demo workspace。视频还反复显示 Approve, apply & stage draft、Demo action - stages Gmail draft only、Approved - not yet handed off 和 No email was sent。这些文案直接体现了刻意设计的人机边界。

AI 的角色

Treasury Analyst 可以读取已授权邮件和项目上下文，提出邮件—项目—实体关联，识别缺失证据和 blocker，建议 next action，并起草回复。它可以更新候选状态、准备 handoff package，把异常送入人工队列。

它不应成为 bank signatory、KYC approver、payment executor 或 corporate authority source。批准 agent 建议，不等于批准银行动作；staging draft 不等于发送邮件；KYC package complete 不等于银行接受。账户变更、signer 变更、支付和对外提交必须由独立授权系统与人员执行。

生产版本还应对每次读取、推荐、批准、修改、staging 和最终结果留下不可变记录，并保存 source、model、rule 和 configuration version。

人的角色

Treasury 人员验证实体、账户、owner、due date、mandate 和 KYC 要求，决定接受、修改还是拒绝建议。具备授权的 approver 决定是否将项目更新应用到正式 tracker，是否把草稿交给邮件系统，以及是否在银行系统中执行动作。

人还需要处理例外：名称冲突、跨实体请求、缺少 authority、过期 precedent、可疑邮件指令和隐私风险。系统不确定时，应停止并请求明确判断，而不是从历史样本中猜测。

可复用资产

Bonus Day 15 沉淀的是一个 governed Treasury operations workflow：

• entity、account、signer、mandate、bank contact 与 project 主数据；
• authorized mailbox scope 与 project-linking rules；
• KYC evidence standards 和 effective-dated precedent；
• blocker、owner、due date、next action 与 exception state；
• claim-level citation 和 draft provenance；
• analyst approval queue 与 accept/modify/reject reason；
• stage、handoff、send 和 bank action 的独立权限边界；
• 完整的 audit history、override 与 final outcome。

这类 agent 的价值不是替 Treasury 做决定，而是让证据、状态和下一步不再散落，同时把越权动作挡在明确边界之外。

建议起步范围

使用 synthetic entities、accounts、signers、mandates、projects、KYC packages 和 emails。测试集中故意加入冲突实体名称、过期 precedent、缺失证据、prompt-injection email，以及一个超出 delegated authority 的 signer request。

第一版只允许推荐和 staging draft。验收要求包括：记录关联正确、建议带引用、越权请求被阻止、注入内容被隔离、异常被升级、变更前后记录完整，并且系统不能自行发送邮件或执行任何银行动作。

公开证据范围： 原始视频直接展示 synthetic Treasury Demo、项目与银行运营记录、建议、审批队列、draft staging 和 No email was sent；真实 plugin/Skill、mailbox integration、数据模型、规则、evals、代码和 production deployment 未公开。

图注：专业 agent 的成熟度，不由它能自动做多少动作决定，而由它能否清楚说明证据来源、权限边界和人工批准停在哪一步。

Final Bonus Day｜Finance Orchestrator：从多个 agent 到一套跨组织运行体系

业务问题

一个 Strategic Finance partner 可能同时支持十多个团队。每个团队有不同的优先级、数据、指标、业务语言和节奏；budget refresh、BvA commentary、forecast、headcount reporting、ROI analysis 和管理层材料往往并行到达。

如果只为每个团队各建一个 agent，很快会出现新的碎片化：不同 agent 使用不同 KPI 定义和 snapshot，重复维护同一套 forecast 逻辑，handoff 丢失证据，局部背景跨团队泄露，失败任务被当成完整结果。agent 数量增加，并不会自动形成 operating model。

Marco Kim 展示的是一套概念性架构：十多个 org-specific StratFin agents，通过中央 Finance Orchestrator 协调，并共享 Headcount、Budget、Forecast、Variance 和 Insights 等能力。公开视频列出了 Government、Product Policy、Global Affairs、Legal、Communications 等 agent，以及 Legal dashboard 和 Global Affairs framework 两类 illustrative output。

输入与背景

按照作者描述，公开架构包含专业 agents、共享 Skills/Plugins 和中央 orchestrator。若将其复原为生产架构，至少需要把三层明确分开。

第一层是 shared capability layer：budget/actual ingestion、forecast refresh、BvA bridge、headcount reconciliation、narrative drafting、dashboard rendering、source citation 和 control-total checks。每项能力都需要 input contract、output schema、owner、version、tests、permitted tools 和 approval boundary。

第二层是 org-specific context layer：每个团队自己的授权来源、局部 KPI mapping、planning cadence、materiality、战略框架、业务词汇、输出受众和 reviewer。局部 agent 可以增加上下文，但不能静默 fork 共同指标。

第三层是 orchestration and governance layer：任务 routing、权限预检、dependency graph、handoff schema、timeout、retry、cancellation、partial failure、output checks、exception queue、human review 和 controlled publish。

AI 的角色

专业 agent 在各自授权范围内调用共享能力，处理本组织的分析任务。Orchestrator 负责确认任务属于哪个组织和实体，检查 source、permission 和 dependency，分派工作，维护 run state，收集 specialist output，并在进入最终复核前运行独立检查。

Orchestrator 应管理工作流状态，不应成为第二个自由发挥的 analyst。它不能为了完成一份综合材料而自行补写缺失结论，也不能在 worker timeout 或部分失败后把结果标记为 complete。每一次 handoff 都要保存 run ID、as-of、agent/Skill/Plugin version、source reference 和 output schema。

公开视频直接展示的是设计过的架构动画和 sanitized output form，不是实际运行记录。它没有展示 agent thread、route decision、tool call、handoff payload、check result、approval、failure recovery 或 deployment log。作者关于 scheduling、parallel work、quality checks 和视频由 orchestrator 创建的说法，应保留为作者陈述。

人的角色

Finance partner 从手工制作每项产物，转向组合问题、设定优先级、定义 acceptance criteria、挑战假设和批准输出。Shared Finance/Data 团队负责共同数据契约、metric registry、Skills/Plugins 和测试。Org Finance 负责本地背景、战略判断、例外和受众决策。

人的责任并没有因 central orchestrator 消失。相反，agent 网络扩大了变更影响面：一次共享 Skill 更新可能同时改变多个团队输出；一个 routing rule 错误可能造成跨组织数据暴露；一个共同指标冲突可能传播到整个 portfolio。Finance 需要像管理一组长期运行的服务一样管理 agent：上线、监控、评估、版本变更、降级和退役。

可复用资产

Final Bonus Day 最值得沉淀的是一套 Finance agent operating model：

• 共享 capability registry、input/output contract 与测试；
• org context registry、entitlement 与 local reviewer；
• deterministic routing、dependency graph 与 handoff schema；
• 共同 run ID、as-of snapshot 和 metric version；
• timeout、retry、cancellation 与 partial-failure policy；
• independent checks、exception queue 和 human approval；
• claim-level lineage 与 controlled publish；
• agent、Skill、Plugin 的 usage、quality、cost 与 retirement record。

agent count 不应成为成功指标。只有当不同场景确实拥有不同 context、access boundary、capability、reviewer 或 cadence 时，才值得拆成独立 agent；否则只是增加 routing 和维护成本。

建议起步范围

不要从十个 agent 开始。选择两个组织场景和一个 orchestrator：Org A 处理 cost-center BvA 与 forecast refresh，Org B 处理 headcount 和 program ROI；两者共享 source validation、budget/actual bridge、narrative schema 和 output QA。

测试中加入一个冲突指标定义、一个 access-restricted source、一个 stale snapshot、一个 worker timeout 和一条 unsupported claim。只有在 routing 可重复、没有跨组织泄露、指标冲突被升级、所有输出引用同一 approved snapshot、部分失败阻止 finalization、handoff 后仍保留 claim lineage，且每个 specialist output 都能由 reviewer 接受、修改或拒绝时，才进入扩展阶段。

公开证据范围： 原始视频直接展示 Finance Orchestrator、org-specific agent cards、shared capability layer，以及两个 masked/illustrative output；真实 agent definition、prompt、Skill、Plugin、source permission、route rule、execution、eval、approval 和 production status 未公开。

图注：中央编排的价值不是让一个 agent 决定一切，而是让多个专业能力共享标准、保持边界，并在失败和例外发生时停止、交接和追责。

最终阶段结论：Finance 的管理对象从文件转向能力组合

最后四个 Bonus Day 分别展示 dashboard iteration、business analytics engine、Treasury workflow 和 multi-agent operating model。从 AI4FIN 的归纳视角看，它们不是四个互不相关的 demo，而是同一条能力扩展路径上的四个层级。

第一，界面正在成为财务人员表达意图的工作区

Bonus Day 13 让 Finance 直接在页面上标注修改，不再把每个视觉需求重新翻译成 ticket。更短的交互循环能提高产品迭代速度，但界面反馈不能替代 metric definition、query tests 和 release control。

未来的财务分析产品不只是“IT 做、Finance 用”。Finance 会更直接地参与构建和维护，而 Data/Engineering 的价值更集中在可信数据、semantic layer、测试、平台与权限。

第二，可复用的不是 dashboard，而是回答新问题的受控能力

Bonus Day 14 的进步不是拥有更多图表，而是让新问题复用共同指标、mapping、snapshot 和计算组件。一个真正的 analytics engine 必须能够明确区分：这是已有定义下的新切法，还是需要 owner 批准的新定义。

如果系统每次都能给出答案，却不能说明用了哪份数据和口径，它只是把 ad hoc analysis 做得更快；只有 query、calculation、lineage 和 reviewer decision 被保留下来，才形成组织资产。

第三，专业 agent 的边界比自动化动作更重要

Bonus Day 15 把 agent 放进了高风险的 Treasury 场景，却没有把它设计成自动执行者。公开 demo 中最重要的状态不是“任务完成”，而是 approval queue、stage draft only 和 No email was sent。

这说明专业 agent 的生产化设计应从权限边界开始：可以读什么、可以建议什么、可以暂存什么、必须由谁批准、最终动作在哪个受控系统执行。越接近银行、支付、KYC、签字权和外部沟通，这些边界越不能隐藏在 prompt 中。

第四，多 agent 的核心问题是治理，不是规模

Final Bonus Day 把前面形成的局部能力放进 shared capability、org context 和 orchestration 三层架构。它回答了为什么一个通用 Finance agent 不够，也提醒团队：为每个团队复制一个 agent，同样不是答案。

共享能力需要共同 owner 和 regression tests；局部背景需要 entitlement 和 reviewer；编排层需要状态、失败处理和 lineage。缺一层，多 agent 只会把原来的 spreadsheet sprawl 变成 agent sprawl。

从 Day 1 到 Final Bonus Day，整组案例完成了什么

把十六个案例放在一起，可以看到财务 AI 从单点协助走向运行体系的一条扩展路径：

经营信号与财务输入
→ 可执行工作单元
→ 跨工具、跨时间粒度的一致性
→ 异常、复核与批准状态
→ 可复用模型、内容与知识
→ 可持续回答新问题的分析产品
→ 有授权边界的专业 agent
→ 跨组织共享能力与中央编排

这组公开材料没有证明 AI 可以独立经营财务部门，也没有证明这些原型全部已在生产环境运行。大量页面使用 synthetic、demo、sanitized 或 illustrative data；完整数据、代码、Prompt、Skill、Plugin、权限、测试和运行日志很少公开。

这些公开材料更有力地支持了一个判断：Finance 已经可以把自己的工作方法逐步编码为数据契约、计算组件、页面、工作流、专业 agent 和共享能力层。人的工作会从重复搬运和制作，转向定义口径、设计边界、处理例外、挑战结论、批准行动，以及管理一组持续运行的数字能力。

本文所称的 Finance Operating System，是 AI4FIN 对整组案例共同条件的归纳，不是 OpenAI 对外发布的正式产品名称，也不代表公开材料已经证明其内部存在一套完整运行的系统。它不是一个超级 agent，也不是一个把所有数据接进来的聊天框，而至少需要六类共同条件：

1. 受控事实：source snapshot、as-of、metric registry、entity mapping 和 semantic layer；
2. 确定性计算：公式、query、reconciliation、control totals 和 regression tests；
3. 工作流状态：exception、review、approval、staging、publish、supersession 和 failure；
4. 权限边界：read、recommend、apply、stage、send、execute 和 approve 的分离；
5. 证据与追溯：citation、lineage、version、run ID、decision 和 override；
6. 能力治理：owner、eval、cost、reuse、change management 和 retirement。

最后四个 Bonus Day 的终点，不是“Finance 拥有了更多 agent”，而是 Finance 开始拥有一种新的管理对象：能够被组合、被测试、被交接、被限制，也能够在不再适用时被下线的数字能力。

对于 Finance Leadership，最现实的起点仍然不是全局转型。选择一条高频、可勾稽、边界明确的工作链，建立共同来源、例外队列和人工批准；连续运行几个周期，记录 reviewer edits、失败和发布后更正；再决定哪些能力值得复用，哪些上下文需要独立 agent，哪些动作永远保留在人和受控系统中。

主要原始来源

• Bonus Day 13｜Kevin Cong（原帖 activity ID；公开访问可能受 LinkedIn 登录状态影响）：https://www.linkedin.com/feed/update/urn:li:activity:7476663687668228096/
• Bonus Day 14｜Jacob Blau：https://www.linkedin.com/posts/jacob-blau_12daysofchatcodexstratfin-activity-7477119200969269248-xajZ
• Bonus Day 15｜Jane Ro：https://www.linkedin.com/posts/janecro_12daysofchatcodexstratfin-activity-7477391114749005825-Ecg0
• Final Bonus Day｜Marco Kim：https://www.linkedin.com/posts/marcodkim_12daysofchatcodexstratfin-activity-7477767727005454336-y-sC
• OpenAI Codex：https://openai.com/codex/
• OpenAI｜Introducing the Codex app：https://openai.com/index/introducing-the-codex-app/
• OpenAI｜Codex for (almost) everything：https://openai.com/index/codex-for-almost-everything/
• OpenAI｜Inside OpenAI’s in-house data agent：https://openai.com/index/inside-our-in-house-data-agent/
• OpenAI Agents SDK｜Orchestrating multiple agents：https://openai.github.io/openai-agents-python/multi_agent/

资料范围

本文基于截至 2026 年 7 月 29 日已保存的四个 Bonus Day LinkedIn 原帖、原始 GIF/视频、公开评论样本与 OpenAI 官方材料。公开资料用于还原工作方法，不代表 OpenAI 对外提供了完整数据、代码、Prompt、Skill、Plugin、测试、权限配置或生产运行记录。页面中明确标注 synthetic、demo、sanitized 或 illustrative 的内容均按演示材料处理；作者披露的构建时间、运行方式和组织规模，在没有公开底稿时均保留为作者陈述，不写成经独立验证的生产成效。