RQ-03 · 资金日报自动拼表

① 场景引入

一、这件事现在是什么样

资金与收付 · 真实业务触发

老板每天早上都要看「今天账上还有多少钱、昨天收了哪些大额、这周要付哪些」。出纳要从工行/招行/建行三家网银分别查余额，再把昨天微信里收到的收款截图、待付的审批单拼成一张资金日报，天天如此。

二、痛点 · 每条都有来源

1出纳的节奏是天天见老板：日清月结、编资金日报报给老板，但三家网银+微信截图+口头交代的数据从没进系统依据· 会计月度/年度工作节奏：1-5号催单、6-10号凭证、15号前报税、25-30号计提结转关账2老板要的资金日报不是银行余额，是「可用资金=各账户余额+在途收款−待付款」，这个口径软件默认不出依据 · 经营周报拼表：老板要的12个指标分散在销售/财务/仓储三个模块，每周手工导出粘Excel花两小时3微信收款截图、口头交代的「这笔钱先记着」完全不进系统，是账实不符最大来源依据 · 小公司财务工作内容：一人全包记账报税管钱出报表兼行政人事

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 出纳的节奏是天天见老板：日清月结、编资金日报报给老板，但三家网银+微信截图+口头交代的数据从没进系统老板要的资金日报不是银行余额，是「可用资金=各账户余额+在途收款−待付款」，这个口径软件默认不出微信收款截图、口头交代的「这笔钱先记着」完全不进系统，是账实不符最大来源

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

4 步 · 每一步的产出都是下一步的输入

1. 账户余额汇总 · 三账户工行/招行/建行余额各自多少、合计多少
2. 在途收款归集 · 微信侧微信里发的收款截图逐条识别入表
3. 待付款汇总 · 审批单侧本周待付金额按付款日排序
4. 拼表 · 生成资金日报可用资金=余额+在途收款−待付款，一张表讲清

要准备什么：三家银行对账单/余额截图工行/招行/建行，格式不同微信收款截图、收据照片业务员随时发，碎片化待付款审批单本周待付清单，含金额与付款日

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 3 ÷ 落地难度 2 = 6.0

最大差异点：不要求老板先学会看系统。日报从三家网银+微信截图直接拼，输出老板能一眼看懂的那张表。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：资金日报.xlsx 可用资金口径 · 收款Top/待付清单
• 可派发清单：在途收款明细.xlsx 可派发 · 微信收款逐条 · 待确认项标注

这套东西不承诺什么：不做资金预测（预测不准会误导决策），不做自动付款（对外付款必须人审批）。只做当日事实的汇总拼表，不猜未来。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：华峰精密机械制造有限公司（虚构 · 87 人 · 苏州）6 月 22 日资金日报，三家对公账户余额 + 微信在途收款 + 本周待付款拼成可用资金日报。

三家银行余额864,000在途收款(已确认)78,000待付款30,000可用资金912,000

输入财务手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

银行账户余额_2026年6月22日.xlsx三家对公账户余额 · 出纳早上从网银截图转录出纳王敏维护 · 每日早 8:30 查一次微信收款截图转录.txt业务员在群里发的收款截图，出纳转录成文字，含两张模糊待确认业务员随时发 · 无结构化待付款审批单_本周.xlsx本周已批待付 4 笔 · 按付款日排序会计李静维护 · 付款前更新历史资金日报口径说明.txt张伟上个月的手记，记了老板问 18 万货款那次的教训财务主管张伟 · 5 月写后再没更新注意标橙色那一份 —— 历史资金日报口径说明.txt。它财务主管张伟 · 5 月写后再没更新，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

帮我把今天三家银行的钱、微信里收到的钱、这周要付的钱，拼成一张资金日报。 银行余额多少、微信收了哪些、要付哪些，都要有。最后给我一个「现在真正能用的钱是多少」的数。 微信截图看不清的别硬填，标出来我去问。

短是因为「可用资金怎么算、微信收款怎么归集」都写在能力包里了。你只需要说清是今天。

触发事情是这么来的

每天一早 · 老板要看钱 · 三处数据拼一张表

6 月 22 号早上，老板赵总问张伟：「今天账上还有多少钱、昨天收了哪些大额、这周要付哪些？」张伟把活派给出纳王敏。王敏手里有工行、招行、建行三家网银的余额，还有群里一堆微信收款截图，和这周的待付款审批单，得拼成一张老板能一眼看懂的资金日报。

第 1 步 · 账户余额汇总 · 三账户

工行/招行/建行余额各自多少、合计多少

这一步的看点 · 从历史里想起了公司踩过的坑汇总到864,000 时，Agent 顺手翻了历史资金日报口径说明（张伟那份手记，平时没人看），发现上个月 5-18 老板问「账上钱够不够付鼎力那笔 18 万的货款」，出纳只报了银行余额 79 万说够，结果付款日对公账户余额不够，差点让老板临时去调头寸。于是 Agent 这次没停在 864,000，直接把这个数标了一句：「银行余额不是可用资金——上个月就栽在只报余额、没算在途收款和待付款上。」

第 2 步 · 在途收款归集 · 微信侧

微信里发的收款截图逐条识别入表

这一步的看点 · 排除性结论归集微信收款时，Agent 发现苏州耀华精工有两笔 3 万，同一客户、同一天（6-21），看起来像同一笔重复记了两遍。它核了一遍：两笔备注都写了「尾款」，是分两笔转的 6 万，不是一笔 3 万重复——排除重复，按 6 万入在途。顺手它还认出了恒通那笔 18,000：「这笔就是工行对账时那笔没存对公的微信收款，日记账 6-30 记过、银行侧还没到的 18,000。」两个场景的同一笔钱对上了。

第 3 步 · 待付款汇总 · 审批单侧

本周待付金额按付款日排序

这一步的看点 · 把技术动作翻译成钱待付款 30,000 归集完，三块数据齐了，Agent 第一次能把「可用资金」算出来：「三家余额 864,000 + 在途收款 78,000 − 待付款 30,000 = 可用资金 912,000。」老板如果只看余额 86.4 万，会以为比可用资金少了 4.8 万——这 4.8 万就是在途 7.8 万抵掉待付 3 万之后的净差，是「已经在路上、还没进对公户、而且这周还要划出去一部分」的钱。

第 4 步 · 拼表 · 生成资金日报

可用资金=余额+在途收款−待付款，一张表讲清

这一步的看点 · 该拦的地方拦住了拼表到最后，Agent 的结论是 「这份日报今天还不能直接发」——因为微信里有两张收款截图金额模糊看不清（华瑞供应链、明远商贸各一笔），这两笔金额是空的，没进在途收款。它给的替代方案不是干等：方案 A：先按「已确认」口径出表，可用资金 912,000 先发，两张模糊的标「待确认」，不耽误老板看大头；方案 B：等业务员补发两张原图，把两笔金额补进在途收款，再出一版完整的日报。

这份日报今天还不能直接发三家余额、在途收款、待付款都拼齐了，可用资金算出来是 912,000，但微信里有两张收款截图金额模糊看不清（华瑞供应链、明远商贸各一笔），这两笔金额没进表，日报就还差两块拼图。不用干等的两个方案：· 方案 A：先按「已确认」口径出表——可用资金 912,000（余额 864,000 + 已确认在途 78,000 − 待付 30,000），两张模糊的标「待确认」，不耽误老板今天看大头；· 方案 B：等业务员补发两张原图，把华瑞、明远两笔金额补进在途收款明细再出完整版——这一版在途先按 78,000 锁，模糊两笔到了再加，老板当天要看的余额 864,000 和待付

30,000 不受影响。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 口径固定了一条：「可用资金=余额+在途收款−待付款」，老板以后不用再问「到底有多少」
• ✓ 微信收款第一次被结构化：以前散在聊天记录里的收款，现在进表了
• ✓ 出纳的角色变了：从「现凑数字」变成「把三处数据拼成一张能直接发的日报」

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 能自动付款吗？ 不能。对外付款必须人审批，它只汇总待付清单，付不付、什么时候付由人定。
• 能预测下个月现金流吗？ 不能。预测需要应收应付的完整数据和信用假设，中小企业数据不足，猜出来的数会误导决策。
• 微信截图看不清怎么办？ 标「待确认」放进在途收款，不影响出报，你补了原图再更新。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

资金日报自动拼表 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

cash-daily-report.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是财务手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁RQ-03 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 银行账户余额_2026年6月22日.xlsx 三家对公账户余额 · 出纳早上从网银截图转录
• 微信收款截图转录.txt 业务员在群里发的收款截图，出纳转录成文字，含两张模糊待确认
• 待付款审批单_本周.xlsx 本周已批待付 4笔 · 按付款日排序
• 历史资金日报口径说明.txt 张伟上个月的手记，记了老板问 18 万货款那次的教训

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

帮我把今天三家银行的钱、微信里收到的钱、这周要付的钱，拼成一张资金日报。 银行余额多少、微信收了哪些、要付哪些，都要有。最后给我一个「现在真正能用的钱是多少」的数。 微信截图看不清的别硬填，标出来我去问。

为什么这么短就够了：短是因为「可用资金怎么算、微信收款怎么归集」都写在能力包里了。你只需要说清是今天。换成你自己的业务 · 把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 2 份

• RQ-03_资金日报.xlsx 正式件本体 · 可用资金口径 · 收款Top/待付清单
• RQ-03_在途收款明细.xlsx 可派发· 微信收款逐条 · 待确认项标注

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：三家银行对账单/余额截图工行/招行/建行，格式不同微信收款截图、收据照片业务员随时发，碎片化待付款审批单本周待付清单，含金额与付款日

人工边界：不做资金预测（预测不准会误导决策），不做自动付款（对外付款必须人审批）。只做当日事实的汇总拼表，不猜未来。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

资金与收付 · 产出即下一步输入

RQ-01 · 银行余额调节表自动编制 — 制度要求每月做、实际从没做过 · 长期不做等于把 50 万的窟窿藏在未达账项里查看 →RQ-02 · 报销单合规预审 — 报销单看着天天在过、实际天天在扯皮 · 退单的话术和依据，才是财务最缺的 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。