第 3 章：WorkBuddy 办公工作流实战
本章以“电商订单、支付与履约联合核对”为主线，处理8,150行订单和上万行配套业务记录。WorkBuddy需要完成多表清洗、关联核对、异常分类、Excel公式与图表，再依据同一份统计结果编写Word报告。
第二章重点是如何推进和管理任务；本章重点是让多份数据、计算过程和办公成果相互一致。目标不只是“做出一份漂亮表格”，而是交付能筛选、能重算、能追溯的结果。
3.1 从一张小表升级为多份业务导出
准备本章输入资料，放入独立的“电商交易核对”工作空间。所有数量均不含表头。
| 文件 | 行数 | 用途 |
|---|---|---|
| 订单导出.csv | 8,150 | 订单主数据，包含重复、冲突、非法记录 |
| 支付流水.csv | 6,470 | 实际导出的成功流水，包括重复、多笔和孤立流水 |
| 发货记录.csv | 3,831 | 发货时间与仓库，包括关联异常 |
| 商品主数据.csv | 80 | SKU、商品名称、分类与单价 |
| 库存快照.csv | 240 | 三家门店分别持有80个SKU的当前库存 |
| 案例说明与口径.md | — | 主键、清洗规则、金额与时间口径 |
| 业务反馈.md | — | 客服、仓库和财务提出的核查需求 |
合计18,771行表格数据。数据随机生成，基准固定为2026-10-12T12:00:00+08:00。每张表的字段含义和关联键见口径文件。
不要把答案目录放入工作空间。先让WorkBuddy实际计算，再使用结果核对表比对。
3.2 把业务问题转成有顺序的工作流
本次要回答：
- 导出数据中哪些重复、冲突和非法记录影响统计？
- 可用订单的状态、门店、渠道和订单金额怎样分布？
- 哪些订单与支付流水不一致？
- 哪些付款超过24小时仍未发货，当前库存是否足够？
- IT、财务与仓库接下来应核查哪些订单？
工作流为：
文件盘点 → 订单清洗 → 流水去重与聚合 → 多表关联
→ 支付与履约异常分类 → Excel汇总和图表 → Word报告 → 跨文件复核不能直接把订单与支付明细拼接后数行。一笔订单可能对应多笔支付，错误的一对多关联会把订单数和订单金额放大。应先按order_id聚合支付笔数与金额，再关联一单一行的清洗订单。
新建任务“电商交易核对-20261012”，发送：
读取输入资料中的全部文件，先阅读“案例说明与口径.md”和“业务反馈.md”。
列出每张CSV的实际行数、字段、主键、重复与冲突处理方式，以及表之间的关联键。
不要将前几行预览当作全量统计。
给出分阶段计划：清洗、关联、异常核对、Excel、Word、检查。
说明哪些数据能支持支付与履约核对，哪些信息不足以判断真实损失、退款或历史缺货。
计划保存到outputs/处理计划.md。先完成盘点与计划，不急着写Word。
全部运算以2026-10-12T12:00:00+08:00为基准，输入文件保持不变。3.3 清洗订单：去重不等于随意保留一个版本
在原任务继续：
按口径清洗订单，保存可追溯的中间文件。
先删除所有字段完全相同的多余行。
同一order_id存在不同内容时，把该订单的全部版本隔离。
对无冲突订单检查数量、状态和SKU：任一非法则整单隔离。
channel为空保留，并在清洗结果显示为“未填写”。
输出清洗订单.csv、冲突订单.csv、非法订单.csv和清洗摘要.json。
摘要分别给出原始行数、重复行数、冲突编号数、冲突版本行数、非法订单数、可用订单数。
列出清洗前后的行数守恒关系，不得静默丢掉问题记录。固定样本的结果：
| 指标 | 预期 |
|---|---|
| 原始订单行数 | 8,150 |
| 完全重复的多余行 | 120 |
| 冲突订单编号 | 30 |
| 冲突版本行数 | 60 |
| 非法订单 | 40 |
| 可用订单 | 7,930 |
| 可用订单中渠道未填写 | 100 |
40条非法订单包括数量非法20条、状态非法10条、SKU未匹配10条；本样本这三组互不重叠。通用规则中若一单同时有多个问题，整单仍只排除一次，问题标签另行计数。
守恒关系：8,150 − 120 − 60 − 40 = 7,930。空渠道不属于排除条件，不能再减去100。
3.4 支付、发货与库存关联
继续发送：
对支付流水按完整行去重，再检查payment_id是否存在内容冲突；
同一payment_id的冲突版本全部隔离，不能自动选择。
不同payment_id即使属于同一订单，也不能当作重复导出去掉。
先按order_id汇总成功笔数与成功金额，再关联可用订单。
发货记录按shipment_id检查重复和冲突，保留每单发货证据。
商品按sku关联；库存必须按store+sku共同关联。
把找不到原始订单的支付/发货记录列为“孤立记录”。
原始订单存在但已被冲突或非法规则排除的，单列“关联已隔离订单”，不要混入孤立记录。
关联完成后可用订单仍应一单一行，不得因支付或发货明细连接变多。
保存支付去重.csv、关联异常.csv、订单核对明细.csv和关联摘要.json。预期支付去重后6,410笔，其中6,337笔关联可用订单，58笔关联已隔离订单，15笔为孤立流水。
发货3,831条中，3,775条关联可用订单，36条关联已隔离订单，20条为孤立记录。本批发货记录没有主键重复与冲突。关联异常并不一定是实际业务丢单，也可能是导出范围或数据同步问题，应保留编号继续排查。
3.5 异常分类：支付与履约分别判断
在一单一行的可用订单上，按口径文件生成支付异常标签、超时未发货标签和库存不足标签。
支付异常按定义的先后顺序判断，每单只有一个支付标签。
金额以整数分比较，不先转换成浮点元再四舍五入比较。
超时只计算状态“已支付”的订单，严格超过24小时；已发货不计入超时未发货。
库存不足只作为当前快照证据，不写成历史缺货根因。
输出完整支付异常清单和超时未发货清单，列出order_id、门店、证据和建议核查方向。
保存核对指标.json。不要将支付异常和超时订单数直接相加，二者可能重叠。支付标签的顺序决定了计数能否核对。例如，已支付订单有两笔成功流水时，归为“多笔成功流水”，不同时再算一次“金额不一致”。
| 支付异常 | 预期订单数 |
|---|---|
| 缺少成功流水 | 35 |
| 支付金额不一致 | 24 |
| 多笔成功流水 | 10 |
| 未支付状态存在成功流水 | 10 |
| 合计 | 79 |
超时未发货2,335单，其中905单当前库存不足。库存不足是超时清单的子集，不能再加到2,335上。
支付流水缺失不直接等于没有到账，多笔流水也不直接等于重复扣款。处理建议应写“核查支付渠道原始交易、回调日志和导出范围”，而不是直接承诺退款。
3.6 制作 Excel：先确定工作簿结构
继续要求：
基于已清洗和关联的全量数据，生成outputs/交易核对工作簿-v1.xlsx。
至少包含：
口径、原始订单、原始支付、发货明细、商品主数据、库存快照、
清洗明细、支付去重、异常清单、门店汇总、渠道汇总、每日趋势。
原始工作表保留实际输入，不覆盖原始CSV。
清洗明细一单一行，按约定列布局保存。汇总用公式引用明细，不能把统计数字写死。
CSV、JSON作为中间成果保留；Excel中金额展示注明人民币元，底层金额按整数分保存。
设置筛选、冻结首行、中文列宽、金额格式、条件格式，并保留可编辑图表。
重算后检查公式结果；若当前环境无法重算，请明确说明并先解决，不把空缓存当成零。清洗明细采用以下布局，便于定位公式：
| 列 | 字段 | 来源或作用 |
|---|---|---|
| A—D | order_id、store、sku、category | 订单及商品关联 |
| E—H | quantity、order_amount_cents、status、channel | 可用订单字段 |
| I | paid_at | 转为北京时间的Excel日期时间；未支付为空 |
| J—L | 成功笔数、成功金额_分、支付标签 | 根据支付去重表计算 |
| M—O | 超时未发货标记、可用库存、库存风险标记 | 时间判断与store+sku关联 |
| P | 创建日期 | created_at对应的北京时间自然日，Excel日期值 |
口径表B2保存基准日期时间值2026-10-12 12:00:00，B3保存阈值24（小时）。不要把基准存为一段带中文的文本。
3.7 让公式与图表能真正重算
支付去重表A—E列依次是payment_id、order_id、result、amount_cents、paid_at。本批去重后6,410行，加上表头，数据范围为2至6411。
清洗明细J2统计该订单的成功笔数：
=COUNTIFS(支付去重!$B$2:$B$6411,A2,支付去重!$C$2:$C$6411,"成功")K2汇总成功金额（分）：
=SUMIFS(支付去重!$D$2:$D$6411,支付去重!$B$2:$B$6411,A2,支付去重!$C$2:$C$6411,"成功")L2给出互斥的支付标签：
=IF(OR(G2="已支付",G2="已发货"),IF(J2=0,"缺少成功流水",IF(J2>1,"多笔成功流水",IF(K2<>F2,"支付金额不一致","核对一致"))),IF(J2>0,"未支付状态存在成功流水","无需支付核对"))M2计算超时未发货标记，O2标记其中库存不足的订单：
=IF(G2="已支付",IF(ISNUMBER(I2),IF((口径!$B$2-I2)*24>口径!$B$3,1,0),0),0)
=IF(AND(M2=1,N2<E2),1,0)将这些公式填充到全部7,930条明细，最后一行是7931。更换数据时应依据实际行数调整范围，也可以由WorkBuddy改成Excel表的结构化引用，不能永久只统计前7930条。
门店汇总A2为门店名时，该门店已支付口径订单数：
=COUNTIFS(清洗明细!$B$2:$B$7931,A2,清洗明细!$G$2:$G$7931,"已支付")+COUNTIFS(清洗明细!$B$2:$B$7931,A2,清洗明细!$G$2:$G$7931,"已发货")该门店的订单状态口径金额（人民币元）：
=(SUMIFS(清洗明细!$F$2:$F$7931,清洗明细!$B$2:$B$7931,A2,清洗明细!$G$2:$G$7931,"已支付")+SUMIFS(清洗明细!$F$2:$F$7931,清洗明细!$B$2:$B$7931,A2,清洗明细!$G$2:$G$7931,"已发货"))/100WorkBuddy可以代写和填充公式，使用者需要理解引用了什么范围、统计了什么条件。无法打开公式栏、公式只有一行或计算范围截断，都不能视为完成。
继续添加：
请制作三张可编辑图表，引用汇总区域：
1. 各门店已支付口径订单数柱状图；
2. 支付异常类型分布柱状图；
3. 按创建日期统计的已支付口径订单数趋势图。
每日趋势按清洗明细P列的创建日期分组，不与付款日期混用。
图表注明数量单位与筛选口径，金额图如使用则单独标人民币元。3.8 打开 Excel 核对结果
总体状态与订单金额：
| 指标 | 预期 |
|---|---|
| 已支付状态 | 2,577 |
| 已发货状态 | 3,775 |
| 待支付状态 | 930 |
| 已取消状态 | 648 |
| 四种状态合计 | 7,930 |
| 已支付口径订单（前两种状态） | 6,352 |
| 已支付口径订单金额（人民币元） | 8,379,892.78 |
门店汇总：
| 门店 | 可用订单 | 已支付口径订单 | 订单状态口径金额（元） |
|---|---|---|---|
| 华东店 | 2,680 | 2,168 | 2,869,605.76 |
| 华南店 | 2,630 | 2,096 | 2,784,901.41 |
| 华北店 | 2,620 | 2,088 | 2,725,385.61 |
用Excel或WPS检查工作表、筛选、公式、中文、图表与打印区域。必须看到实际计算值，而不只是公式字符串或空白单元格。
演示公式联动时，另存副本，在清洗明细定位ORD000171。该订单原本成功流水金额比订单金额多100分。仅把副本中该订单F列金额加100分并重算，支付金额不一致应从24降为23，支付异常从79降为78，订单状态口径金额增加1元。原始CSV、原始工作表和正式v1文件不改，后续Word仍使用正式v1的指标。
这项操作用于展示公式引用是否有效，不代表可以在真实业务中修改订单金额来“消除异常”。Excel汇总可以重算，但Word中的静态文字与手工导出的异常清单不会自动更新，需要重新生成并复核。
3.9 从 Excel 编写 Word 核对报告
使用正式的交易核对工作簿-v1.xlsx、核对指标.json和业务反馈.md，
生成outputs/电商交易核对报告-v1.docx。
先确认Excel公式已重算，数据与JSON一致。若不一致先定位原因，不直接取更好看的数字。
报告包含：
1. 范围、基准时间与口径；
2. 数据质量及清洗排除过程；
3. 门店、渠道和订单金额概况；
4. 支付异常分类与代表订单；
5. 超时未发货及当前库存风险；
6. 按IT、财务、仓库区分的后续核查建议；
7. 未确认事项与附件索引。
正文展示汇总及少量带订单编号的代表记录，完整异常保留在Excel/CSV中。
金额明确写“订单状态口径金额”，不能写成已确认到账、利润、净收入或损失。
事实、可能原因、建议分开，负责人和完成日期无依据则写待确认。
使用可编辑的Word标题和表格，处理好分页，不把表格截图粘贴进文档。报告开头可以这样表述：
本批8,150行原始订单，经去除120行完全重复记录、隔离30个冲突订单的60行版本及40条非法订单后，形成7,930条可用订单。已支付与已发货口径共6,352单，订单金额8,379,892.78元。本次识别支付异常79单、超时未发货2,335单，其中905单当前库存不足。上述分类存在交叉，不能相加作为独立异常订单总数。
原始订单范围之外还有15笔孤立支付与20条孤立发货，应在数据边界部分单独说明。报告中的“金额异常”不等于已证实资金损失。
3.10 通过具体问题推动修订
| 发现的问题 | 应从哪里修 |
|---|---|
| 订单总数超过7,930 | 检查多表连接是否一对多放大 |
| 已支付口径只有2,577 | 检查是否遗漏已发货状态 |
| 孤立支付被算成73笔 | 检查是否把58笔关联已隔离订单混入15笔孤立流水 |
| 总金额多计 | 检查重复导出、冲突版本以及支付多笔关联 |
| Word与Excel不一致 | 检查Word是否使用旧版指标或公式未重算 |
| 所有库存不足均写成缺货根因 | 回到当前快照证据，删去无依据的历史结论 |
可以发送：
先不要润色报告。请逐项核对清洗摘要、关联摘要、Excel计算值和Word数字。
定位问题发生在原始输入、清洗、关联、公式、缓存还是文字引用。
修正受影响的上游结果，再同步更新图表、异常清单、JSON和Word。
保留v1，生成v2，并在修订说明.md记录改动和核对结果。如果只需要管理层短版，则另存摘要版，保留同一套数字，避免为每份文档重新计算一套口径。
3.11 复用这条办公工作流
输入CSV已经生成，无需让WorkBuddy临时编造数千行记录。更换批次后，它应依据实际文件计算，不照抄本章数字。重新生成样本的方法见业务数据工具。
稳定后可以把输入契约、清洗顺序、公式结构、报告模板与异常处理方式整理成Skill。定时执行则是在这套工作流可靠之后，再配置启动周期和文件命名；定时启动本身不会纠正统计错误。
第二章留下“如何管理一个多阶段任务”的方法，本章留下“如何让多表、Excel和Word共享同一口径”的方法。第四章进入Codex，用独立小样本学习Python程序开发；其字段、状态和示例规模与本章不同，不将本章数据直接替换进去。