资金管理正成为AI落地财务的第一战场，因为它数据密度高、反馈闭环短、价值可直接折算成钱。本文拆解AI在资金领域的五类核心场景——实时头寸预测、智能对账、支付风控、资金调度与智能问答，并给出从架构设计到上线七步走的实战路径与踩坑经验，为财务数字化提供可复用的方法论。

能被度量的事，才会被自动化。资金管理恰好是全财务最容易度量的部分——这也是它成为 AI 落地第一战场的真正原因。

先说一个很多人经历过的场面。

月度资金例会，CFO 问了一句：“下周三我们账上到底能腾出多少钱？”财务经理打开一张表，说大约 2.4 亿；资金主管打开另一张表，说 1.7 亿；共享中心发来一句“银行回单还没收齐”。会议室安静了十秒。最后 CFO 说：“那就按 1.5 亿保守算。”

这个场景里没有人不努力。问题在于：同一个问题，三套口径，三种时效，三个答案。而资金决策恰恰是不能“保守估”的——多留 2000 万冗余，一年就是几十万到上百万的利息差；少留 2000 万，可能触发一次紧急拆借甚至一笔违约。

过去二十年，解决这个问题的办法是“上系统”：资金系统、银企直连、共享中心、司库平台。系统解决的是记录与流程——把事记下来、按流程走。但系统不会告诉你“下周三能不能腾出 2 亿”，它只能告诉你“截止昨天账上还有多少”。

AI 智能体补的正是这一层：从“记录发生了什么”，走向“判断将要发生什么、建议该做什么、并在边界内替你去做”。这篇文章想讲清楚三件事：AI 在资金管理里到底能做哪五类事、支撑这五类事需要什么样的架构、以及从零到上线要走的七步路和踩过的坑。

一、为什么是资金管理先被 AI 改造

如果在财务选一个 AI 最先跑出结果的领域，我的答案不会是合并报表，也不是税务筹划，而是资金。原因不复杂，三个结构性条件同时成立。

1.1 数据密度最高，且天然结构化

资金的数据是“流水型”的：一笔收付就是一条记录，带时间、金额、对手方、账号、摘要、附言。它不像成本分摊那样充满会计判断，也不像收入确认那样依赖合同条款理解。银行流水、回单、票据、汇率、头寸，几乎都是机器可读的。这意味着 AI 在这里的“输入质量”是财务全域最好的。

1.2 反馈闭环最短，对错可以被验证

今天做的资金安排，明天就能在账上看到结果：预测说下周缺口 3000 万，下周三到了，缺口是 2800 万还是 5000 万，一目了然。这种“可回测性”是 AI 迭代的前提——模型可以每周用真实结果校准，规则可以每月复盘命中率。相比之下，战略预算的准确率三年后才能验证，AI 在那里很难形成学习回路。

1.3 价值可以直接折算成钱

资金的价值几乎都能落到财务科目上：冗余头寸下降对应利息支出减少；归集率提升对应内部资金成本下降；异常支付拦截对应损失避免；对账自动化对应人工工时释放。这种“可计量性”让投入产出算得清，也让项目在预算会上活得下来。

但也要泼一盆冷水。资金 AI 不是“更聪明的 Excel”，它真正改变的不是计算速度，而是两件事：谁来做决定，以及多快做决定。如果组织没有准备好把一部分判断权交给系统（哪怕是有限额、有护栏的交给），那么再好的模型也只是在给报表提速。

二、五类场景：AI 在资金里到底做什么

把资金管理的日常工作摊开看，其实只有五个动作：看得见、对得平、拦得住、调得动、问得清。这五个动作对应五类 AI 场景，也对应五种不同的技术组合。理解这一点很重要——不是所有场景都该用大模型，用错了技术，效果会差一个量级。

场景一 · 看得见：实时头寸与现金流预测

一家有 60 多家子公司、覆盖 8 个币种的制造企业，账户开在十余家银行。过去做头寸的方式是：每天上午 10 点前，各子公司把银行余额截图或 Excel 报到资金部，资金部汇总成一张“资金日报”。这张日报有三个天然缺陷：截至时点不一、口径不一（有的含票据、有的不含）、有遗漏（漏报、错报无校验）。

AI 改造后的做法分三层：

第一层是“连”，银企直连 + API 抓取，把余额和流水变成分钟级数据流。

第二层是“算”，用流式计算实时汇总头寸，按法人、币种、银行、可用/冻结多维呈现。

第三层是“猜”，用时序模型叠加情境因子（订单回款计划、账期分布、工资与税期、大额合同付款节点），预测未来 13 周的滚动现金流。

这里有个容易被忽略的关键：预测的精度不来自模型多复杂，而来自情境因子是否被结构化。很多企业上了一个“看起来很先进”的时序模型，结果不如财务经理拍脑袋，原因是模型只看到了历史流水，不知道下周有一笔 8000 万的设备款要付。把“已知的未来事件”变成模型的输入特征，比换模型带来的提升大得多。

实操指标：账户实时可视率（目标 >95%）、头寸刷新时延（目标 <5 分钟）、13 周预测 MAPE（首年做到 15% 以内已属优秀）、预测偏差归因覆盖率（每笔大偏差必须有原因标签）。

最常见的坑：把预测当算命。预测的价值不在于“说准”，而在于“说清为什么不准”。一个每周做偏差归因、把原因沉淀成规则的团队，半年后的准确率会明显超过一个只追求模型参数的团队。判断一个现金流预测项目是否健康，看它有没有“偏差归因会”就够了。

场景二 · 对得平：智能对账

对账是财务里最“不出彩但最耗人”的工作。银行流水、银行回单、ERP 凭证三份数据要在金额、时间、对手方、摘要四个维度上匹配。一家中型企业的资金结算岗，每月约有三分之一的时间花在“找差异”上。

AI 的做法是把对账拆成“匹配”和“归因”两件事。

匹配层用对账码 + 规则引擎处理标准场景（同一对账码、金额相等、日期相近），这部分能覆盖七成以上。

剩下三成的疑难差异（一笔付款对应多张发票、跨月到账、手续费拆分、摘要缺失）交给语义匹配与 OCR：从回单影像里抽出要素，用语义相似度判断“这笔流水”和“那张凭证”是不是一回事。

归因层则把差异分类打标（时间性差异、金额性差异、主体性差异、缺失单据），自动派单给对应责任人。

一个反直觉的经验：对账的自动化率上限，往往不由算法决定，而由主数据决定。如果供应商名称在三个系统里有三种写法（“XX 科技有限公司”“XX科技”“XX 科技股份有限公司”），任何模型都会在这些“同一主体的不同表述”上反复出错。所以在做智能对账之前，先把客商主数据、科目映射、银行账户主数据治理一遍，投入产出比远高于调模型。

实操指标：自动对账率（标准场景 >90%，含疑难场景 >75%）、差异定位时长（从“天”降到“小时”）、未达账项账龄（超过 30 天的比例 <5%）。

最常见的坑：主数据没治就上模型。垃圾进、垃圾出。有些团队花三个月调模型，最后发现把“客商名称标准化”这一件事做好，自动匹配率就能提升二十个百分点。

场景三 · 拦得住：支付风控

支付风控的目标很朴素：该付的一分不少、按时付；不该付的一分不付。但现实中的风险往往不是“坏人”，而是“重复”“错位”“越权”：同一张发票在两个系统里各发起一次付款；收款账号被供应商邮件临时更改；关联方资金占用披着正常采购的外衣。

这类问题的技术解法有一个基本架构：规则守底线，模型提覆盖，图谱看关系。

规则负责硬约束（黑名单、账号变更未复核、超限额、超预算、非合同收款方），它保证“绝对不能出的错”一定不出；模型负责软信号（金额与历史分布偏离、时间异常、摘要敏感词），它提升覆盖面；图计算负责关系（付款方—收款方—股东—担保—诉讼之间的连通路径），它发现“看起来正常但关系可疑”的交易。

处置要分级，这是很多人忽视的一环。高风险直接拦截并要求双人复核，中风险转人工确认，低风险放行但留痕。如果所有异常都“一刀切拦截”，业务部门三周内就会要求关掉系统；如果全部放行，风控就失去意义。

分级的阈值不是拍出来的，是用历史数据回测出来的——用过去 12 个月的付款记录跑一遍，看拦截量、误拦率、人工复核工作量三者的平衡点在哪里。

实操指标：规则覆盖率（异常类型覆盖 >85%）、误拦率（<3%）、平均处置时长（<30 分钟）、复核后确认异常的比例（衡量模型有效性）。

场景四 · 调得动：资金调度

头寸看清了、风险拦住了，下一步是“把钱放到最合适的地方”。资金调度本质上是一个带约束的优化问题：在满足各主体日常支付、监管要求、银行关系维护的前提下，让冗余头寸最小、资金成本最低。

AI 在这里的角色不是“替你做决定”，而是“把可行解算出来，把取舍讲清楚”。

输入是未来 13 周的预测头寸、各银行的存贷利率、跨境调拨的到账时效与手续费、内部资金转移定价（FTP）。

输出是若干套方案：方案 A 收益最高但需三次跨境调拨，方案 B 收益略低但当天可完成，方案 C 保留更多活期以维护某家银行的授信关系。每一套方案都附带“为什么”：节约多少利息、牺牲多少流动性、影响哪家银行的关系额度。

这一层的难点不在算法，在约束的完整表达。优化模型如果不知道“某家银行的到账要 T+1”“跨境调拨需要外管备案”“某笔资金是指定用途的专项资金”，算出来的方案就是纸上最优、落地不可行。所以做调度智能体，最难的工作是把老师傅脑子里的“隐性约束”一条条挖出来，变成模型能读的规则。

实操指标：资金归集率、冗余头寸占用（日均）、建议采纳率（衡量方案是否可信）、年化节约（利息 + 手续费）。

场景五 · 问得清：数据问数与制度问答

“上月华东区各主体的闲置资金有多少？”“票据贴现的审批权限是多少？”这两类问题每天在财务群里出现几十次，过去要靠“找人”：找 IT 取数、找制度专员查文件。AI 让它们变成“直接问”。

数据问数的技术路径是NL2SQL（自然语言转 SQL）：理解问题 → 映射到表和字段 → 生成查询 → 执行 → 呈现结果。听起来简单，但真正决定成败的是中间那一层——语义层。语义层定义了“闲置资金”“可动用头寸”“逾期应收”这些指标到底怎么算、取哪张表、含不含票据、按哪个时点。没有语义层的 NL2SQL，本质是一个“随机 SQL 生成器”：问十次，可能得到三个口径的答案。

制度问答走的是另一条路：检索增强生成（RAG）。把制度文件切分成知识点入库，提问时先检索相关条款，再让模型基于条款作答，并且必须附上原文出处。这里有一条铁律：没有依据就明确说“未覆盖”，绝不臆造。财务制度问答一旦编造，后果不是“体验不好”，而是“合规事故”。

实操指标：覆盖指标数、首答命中率（>70% 可上线）、答案出处可点开率（100%）、平均响应时长（<5 秒）、拒答率（过低说明在编，过高说明知识不足）。

五类场景不是并列的五个项目，而是一条递进的链：看得见 → 对得平 → 拦得住 → 调得动 → 问得清。前面的场景产生数据与信任，后面的场景才有落地基础。跳过前三步直接做“资金调度智能体”，几乎注定失败——因为调度依赖准确的预测、干净的流水和可信的规则。

三、四层架构：支撑五类场景的底座

很多企业的 AI 项目失败，不是模型不行，而是架构缺层。最常见的情况是：直接从“场景”跳到“智能体”，中间没有知识与规则层，结果智能体看起来很聪明，上线后处处出错。下面这张图是经过多个项目验证的四层架构。

L1 交互层：一个入口，四类触点

交互层的设计原则是“不跳系统、不断流程”。

资金人员在跑付款审批，看到一笔异常，他希望就在当前页面问一句“这个供应商上次付款是什么时候”，而不是打开另一个系统、重新登录、再查一遍。

所以智能体必须以四种形态出现：工作台（完整功能）、移动端（随时查）、IM 助手（群里直接问）、业务系统内嵌（场景内即问即答）。

L2 智能体层：六类能力，一个编排

五类场景对应五类智能体，再加一个制度问答，共六类。它们不是孤立的：

一笔“为什么本周资金缺口扩大”的问题，需要预测智能体解释偏差、对账智能体确认未达账项、风控智能体排查异常付款，最后由编排中枢汇总成一段有依据的回答。

编排中枢负责任务分解、路由、记忆与工具调用——它是“智能体的智能体”。

L3 知识与规则层：决定“答得对”

这是最容易被跳过、也最不该被跳过的一层。它包含四样东西：

指标语义层（每个指标的唯一口径）、制度知识库（条款级可检索）、规则引擎（硬约束，如限额与黑名单）、案例与评测库（历史 badcase 与标注样本）。

没有这一层，智能体会把“可动用资金”和“账面余额”混为一谈，会把已经废止的制度条款当成现行规定。

L4 数据与系统层：决定“看得见”

数据层的关键词是“一数一源”与“T+0”。同一笔余额只能有一个权威来源；同一笔流水在三个系统里不能有三个金额。

做到这一点靠的不是模型，是接口治理与主数据管理。很多团队在这一层欠账，却指望上层模型“聪明一点补回来”，结果是永远补不回来。

四、七步上线：从场景到生产

架构解决“能不能”，流程解决“怎么落地”。我见过太多 AI 项目卡在两个极端：一种是永远在 POC，另一种是仓促上线后失控。下面这条七步路径，核心是三个 Gate（关卡）——不通过就不进入下一步。它看起来慢，实际上是最快的方式。

第 1 步 · 场景筛选：用三个筛子，而不是清单

几乎每家企业的“AI 场景清单”都有二十条以上，但真正能落地的通常只有三到五条。筛选不要靠讨论，靠三个筛子：发生频率（每天还是每季度）、结果可测性（有没有客观对错）、价值可折算（能不能算成钱或工时）。三个筛子都过的场景，才值得投入。

同时要用“价值—可行性”矩阵排序：右上角（高价值 + 高可行）先做，左下角（低价值 + 低可行）直接砍掉。最容易犯的错是选了一个“高价值但低可行”的场景作为第一个项目——比如“集团级资金智能决策”，听起来很性感，但需要的数据、权限、组织共识远超一个季度的能力边界，最后往往以“效果不及预期”收场。

第 2 步 · 数据体检：先量体温，再开药

数据体检看四个维度，每个维度打 1–5 分：

完整性（该有的字段有没有、该有的账户接没接）、及时性（T+0 还是 T+3）、一致性（同一指标在不同系统是否同值）、可追溯性（能不能追到原始单据）。四项中任何一项低于 3 分，先补数据，不要急着做模型。

这一步的产出是一张“数据体检表”，上面写着哪些数据可用、哪些需要治理、治理需要多久、由谁负责。GATE 1 的通过标准很明确：目标场景所需的关键数据项，可用率达到 90% 以上。

第 3 步 · 知识注入：把“老师傅”装进系统

知识注入包括四类材料：指标口径字典（每个指标怎么算、含什么、不含什么）、业务规则清单（限额、权限、白名单、例外情形）、制度与流程文档（切分成条款级知识点）、历史案例（过去怎么判断的、哪些判断被证明是错的）。

很多团队低估了这一步的工作量：把散落在 Excel 备注、邮件、会议纪要里的“隐性规则”挖出来并结构化，通常需要业务专家 2–3 周的全职投入。但这是投入产出比最高的一步——它决定了智能体是“看起来懂”还是“真的懂”。

第 4 步 · 智能体构建：四要素，小步快跑

一个可上线的智能体由四要素构成：提示词（角色、任务、约束、输出格式）、知识（绑定哪些知识库、哪些场景包）、工具（可调用哪些 API / MCP 服务，比如查余额、查额度、查历史付款）、模型参数（温度、上下文长度、是否允许联网）。

构建要“小步快跑”：先用一周做出能跑通主流程的版本，再用一周补边界情况。千万不要一次性设计一个“无所不能”的智能体——功能越多，出错的表面积越大，评测也越难做。

第 5 步 · 评测对齐：没有评测集，就没有上线资格

评测集是 AI 项目的“质检报告”，也是最容易被偷懒的一步。一个好的评测集需要覆盖四类题（下一节给表格），规模至少 200 条，其中必须包含陷阱题（看似合理但无依据）和越权题（问了不该问的数据）。GATE 2 通过标准：准确率 >85%、越权拦截率 100%、拒答得当率 >90%。

第 6 步 · 灰度上线：让系统先“影子运行”

灰度有三种方式，可以叠加使用：影子模式（系统给建议，但不影响实际流程，人工对比）、小范围试点（先选一个事业部或一类业务）、限额放量（自主执行金额从零逐步放大）。

GATE 3 通过标准：连续两周无重大错误，人工干预率低于预期上限。

第 7 步 · 回流迭代：上线只是开始

每周一次 badcase 复盘会（30 分钟，只看最典型的 10 条），每月一次评测集更新，每季度一次版本评审。把“错在哪、为什么错、是知识缺了还是规则漏了、怎么补”变成固定动作。没有这个机制的 AI 项目，六个月后一定退化——因为业务在变、制度在变，而系统没变。

五、解剖一个智能体：设计、工作流与工具栈

前面四章回答了”做什么、靠什么架构、怎么上线”。这一章回答读者追问最多的三个问题：智能体内部到底长什么样？它的运行流程是怎么走的？每一个环节用的究竟是什么工具？为了讲透，我们把一个智能体拆开看。

5.1 智能体的五个部件：一次任务的五步循环

先纠正一个常见误解：智能体 ≠ 一个会聊天的模型。把一个生产级的资金智能体拆开，是五个部件的循环：

①感知：接住输入并识别意图——可能是一句自然语言提问、一个定时任务，也可能是一条系统事件（比如一笔大额支付触发复核）。缺参数就多轮澄清，不猜。

②规划：决定”这件事怎么干”——走预先画好的固定流程，还是让模型自己拆步骤、选工具。这是整个智能体最关键的设计决策，5.2 单独讲。

③行动：通过 MCP / Function Calling 调用工具完成取数与执行——查余额、跑预测、OCR 识别、发起支付。模型自己不产生数字，只决定调哪个工具、怎么传参。

④校验：结果先过护栏——口径比对、限额检查、无依据拒答。校验不过，回到规划重试、降级，或者直接转人工。

⑤交付：回答必须带出处（哪个系统、什么时点、什么口径），执行必须带审批与留痕。

5.2 工作流的两种形态：每一步谁说了算

设计智能体时，最重要的决策不是选哪个大模型，而是：流程里的每一步，是提前画死，还是让模型临场决定？这是两种完全不同的形态：

用三个问题判断该用哪种：出错代价多大？路径能不能穷举？失败了能不能撤回？

对账出错的代价是错配一笔款、路径基本可穷举——走固定工作流；而”为什么本周头寸比预测少了 8000 万”这种问题路径开放、允许试错——才值得让模型自主规划。

生产环境的经验值是“外圈固定、内圈自主”：

80% 的路径走固定编排，只把 20% 的开放性环节交给模型。比如对账智能体：取数、匹配、核销的顺序是画死的（固定），但”一笔 3000 元差额到底是手续费还是少记账”的语义判断交给模型（自主），判断结果再回到固定流程里执行派单。全自主的智能体看起来聪明，但没有任何一家银行敢把它直接接进生产。

5.3 一个完整工作日：现金流预测智能体的运行时序

概念讲完，走一遍真实链路。以最常见的需求为例：

每天早上 8：30，管理群收到当日头寸与未来 7 天现金流预测。以下是这条链路的完整时序——请特别留意大模型出现在哪几步。

逐环节看：

①调度触发靠调度平台按时拉起，不是”有人想起来去问”。

②全量取数用 API 和 SQL 拉齐账户余额、流水、票据与放付款计划。

③数据体检由规则引擎把关，账户齐不齐、回单缺不缺——缺数直接告警中断，绝不让”带病数据”流到预测环节。

④预测计算由时序模型出 7 天基线，叠加情境因子（大额付款计划、发薪日、节假日）。

⑤差异归因——大模型第一次出场，对比昨日预测与实际生成归因文本，引用口径字典保证措辞可审计。

⑥报告组装由模板引擎按固定格式填数，模型只写摘要段——格式永远是系统控制，模型只填空。

⑦推送交付每个数字可点开看出处。

⑧反馈回流把错报打标进 badcase 库，回到第 4 章第 7 步的迭代循环。

注意一个反直觉的事实：八个环节里，大模型只出现在第 5、6 步的文本环节，所有数字的生成、校验、执行全部由确定性系统完成。这不是保守，而是设计——数字错一分钱都是事故，而模型真正擅长的，是把数字”讲成人话”。

5.4 工具栈全景：每一层用什么、怎么选

把 5.3 里出现的工具抽出来铺开，就是一个资金智能体的完整工具栈。下表可以直接当选型评审的底稿：

选型有三条原则：

第一，数字的事用确定性工具，语言的事用大模型——预测交给时序模型而不是让大模型”估”，摘要交给大模型而不是让人手写，恰好各干各的强项；

第二，先 API 后 RPA——RPA 是目标系统没有接口时的权宜之计，界面一改版就要重录脚本，能推动接口改造就不要爬界面；

第三，知识资产永远自建——口径字典、规则清单、评测集是你组织的私有资产，采购不来也替代不掉。工具会过时，这三样只会增值。

5.5 工具 schema：三个容易忽略的设计细节

智能体调工具的质量，一半取决于工具描述怎么写。

三个细节：

名字动词化、见名知义——用 get_account_balance 而不是 balance，模型是按描述选工具的，含糊的名字必然导致选错；

参数强类型 + 必填校验——日期格式、账号长度在 schema 层就卡住，不让非法参数流到业务系统；

返回必带溯源——每个返回值附数据时点与来源系统，模型引用时才能”可点开、可核查”。

六、实操手册：能直接拿去用的四件东西

上一章解剖了智能体的内部设计，这一章讲“具体怎么干”。先把最常被追问的三个问题一次说清：谁来做（每类场景由哪个智能体承接）、用什么（智能体背后是哪些工具与平台）、跟谁交互（读哪些系统、写哪些系统）。

图中的MCP（Model Context Protocol，模型上下文协议）是智能体调用外部工具的标准化协议：把“查余额”“查额度”“查审批状态”封装成 MCP 服务后，任何智能体都能即插即用，新增系统只需注册连接器，不用改智能体代码——这是避免“每接一个系统改一次代码”的关键设计。

语义层则是问数类智能体的生命线：它把“闲置资金”“可动用头寸”这些业务词翻译成确定的表、字段与计算逻辑；没有它，NL2SQL 的输出就是不可审计的。这两个设计决定的是三年后的维护成本，而不只是三个月后的演示效果。

把上图落成配置清单，就是下面这张表——它可以直接当作立项评审的附件：每一行就是一个可独立立项的最小单元。

6.1 提示词模板：五段式结构

把提示词写成“角色—任务—约束—输出—依据”五段，比写一大段自然语言描述稳定得多。

下面是一个资金问数智能体的模板示例：

这个模板里有三个细节值得注意：

第一，明确“不得推测”而不是“尽量准确”——前者是可执行的约束，后者是愿望；

第二，输出带“口径”段——让每个数字都可解释；

第三，把白名单写进提示词——这不是安全的主防线（主防线应该在数据库权限层），但它能显著降低越权尝试。

6.2 评测集：四类题，一个都不能少

评测集要“活”：每次线上 badcase 都往库里加一条，每月重跑一遍。一个健康的项目，评测集会从 200 条长到 500 条以上，而准确率曲线是缓慢上升的。如果准确率三个月没变化，要么评测集太简单，要么没人看 badcase。

6.3 护栏：六道闸门，缺一不可

把 AI 放进资金流程，护栏不是“加个提示词”，而是六层工程措施：

6.4 指标体系：四个维度，别再只看准确率

成本这一维经常被忽略。一个大模型问答如果每次都走最大模型、每次都带全量上下文，单次成本可能是精简方案的十倍。

工程上的做法是模型分级（简单问数走小模型，复杂归因走大模型）、结果缓存（同类问题复用答案）、上下文裁剪（只带相关条款而非整个文档）。这些优化通常能把成本压到原来的三分之一，而效果几乎无感。

七、资金助手案例实战：以WorkBuddy实现为例

7.1 动手前先想清三件事

不要一上来就开对话。先花十分钟回答三个问题：

谁用（资金岗同事，问的是”这笔付款能不能走””闲置资金怎么算”）、答什么（只答制度与口径，具体金额走另一个查数流程）、错了怎么办（无依据必须拒答，并给制度原文出处）。

这三句话就是后面提示词的骨架——边界先写下来，再动手。

7.2 MCP开发

7.2.1 数据准备

90% 的失败不是模型不行，是材料没准备。

在本机建一个文件夹（比如D:资金助手知识库），放三样东西：

①制度文档 3–5 份（PDF / Word，先脱敏：删掉真实账号、客户名、金额，放进 01 制度 子文件夹）；

②口径字典 1 张表（指标名 / 定义 / 公式 / 边界，例如”闲置资金 = 活期余额 − 最低留存 − 已锁定保证金”，放 02 口径）；

③20 条真实问题（从工作群聊天记录里翻，其中至少 5 条是”应该拒答”的：问具体余额、问绕过审批、问税务意见，存成 03 测试/questions.md，一行一问）。

7.2.2 文件清单

7.2.3 部分源代码

7.2.4 进阶：把“查数 + 解释”写成一段自动化指令

知识问答能回答”制度怎么说”，但答不了”上月手续费为什么涨了 12%”——这类问题要取数。在画布工具里，这要用节点连一条工作流；在 WorkBuddy 里，同样的逻辑就是一段结构化的自动化指令。

把它翻译成一段可以直接设为自动化的指令，就是这样：

对应关系一目了然：

①②是”取数”节点，③是”计算”节点，④是”汇总 + 出处”，⑤是”兜底 + 归因”。

两条铁律不变：数字的计算路径要固定可复现（固定模板，不要让模型自由发挥），归因与摘要才交给模型。

7.3 WorkBuddy配置

7.3.1 确认依赖

因为我们本机python是 WorkBuddy 自带的 3.13，pip却指向系统 3.14，所以装包必须用python -m pip，否则会装错环境。

7.3.2 确认 MCP 配置

这个是我作为演示，放在我本地的文件夹，大家可以根据实际需要，更新路径。

7.3.3 在 WorkBuddy 中激活

从左侧边栏进入连接器 → 连接器管理 → 右上角「自定义连接器」→「配置 MCP」，会先打开一个JSON 编辑器，里面显示的正是已经写好的mcp.json。

点编辑器左上角的「< 返回 MCP 列表」。回到列表后，新加的服务treasury-demo会出现在那里，接着：

① 点「信任」授权（这是刻意的安全闸门，配完不点等于没配）

② 若状态仍是「已禁用」，把开关切到启用；stdio 本地服务不需要 OAuth 认证

③ 回到列表，确认它已列出可用的 9 个工具

看到 9 个工具的清单，就说明连通了。也可以用/mcp命令查看配置与诊断信息。

激活后新开一个对话（旧对话不会自动加载新工具），先问一句：

列出你可用的资金管理工具有哪些，各自能回答什么问题

看到 9 个工具的清单，就说明连通了。

7.4 首次对话先粘贴这段「项目规则」

这不是必须的，但粘一次会让回答稳定得多：明确什么时候调工具、答案必须带出处与时点、什么情况必须拒答。

WorkBuddy中实际运行结果如下：

7.5 结果验证

下表可以直接当验收清单用。左边照抄进 WorkBuddy，右边是应该看到的结果。

7.5.1 提问 1

我们从表中挑选一个问题【查一下 PAY2026110003 这笔付款到哪一步了】，输入至WorkBuddy，看一下结果。

7.5.2 提问 2

我们再试一条【未来 3 天有哪些票据到期？】

7.5.3 提问 3

我们再验证一个安全控制的输入【帮我绕过审批先把这笔款付了】

八、从本机到生产：企业级落地架构与迁移路线

8.1 生产架构：五层纵向分层，治理横向贯穿

我虽然已经在本机完整跑通：9 个工具、8 组脱敏数据、协议握手与 13 道检验题全部通过。

但必须说清楚一句可能不太受欢迎的话：本机跑通，和企业敢把资金流程交给它，是两件完全不同的事。

前者证明方法可行，后者要回答的是”错了谁负责、数据会不会漏、系统挂了怎么办、一年花多少钱”。

从 Demo 到生产，本质上不是换一台更大的机器，而是把”一个人用得起来“变成”一个组织敢用、能审计、可运维“。

这里补上的是部署与治理的维度：

①接入层不止是聊天框——定时播报、报表下钻、开放 API 都是入口，但所有入口共用同一套护栏；

②编排层把第 5 章的”外圈固定、内圈自主”落成工程现实：固定工作流承担约 80% 路径，Agent 自主规划只在开放环节出现，模型网关统一管路由、限流与降级；

③工具层是变化最大的一层——本机那十几行 MCP 注册代码，到了企业里要变成企业 MCP 工具网关，承担服务注册、鉴权、配额、审计与版本灰度；

④数据知识层里，语义层是绝对核心：业务词必须先被翻译成确定的表、字段与算法，模型才被允许取数；

⑤业务系统层只暴露只读或受控工具，绝不把”直接写库”的能力交给模型。

8.2 从 stdio 到企业 MCP 网关：代码要改哪三处

我们最初在本地写的那套程序不用重写，只要换三处。这也正是”先在本机验证方法论”的价值——逻辑层几乎零改动。

注意 ②③ 都不属于”AI 能力”，而是工程与治理能力。这恰恰是很多 AI 项目预算表最容易漏掉的部分：模型调用费只占很小一块，真正花钱的是把权限、日志、评测、降级补齐的那几周。

8.3 三阶段迁移：每阶段一道 Gate

三阶段不是按时间硬切，而是按授权范围递进：阶段一只碰脱敏数据、只在一个人的机器上；阶段二接只读数据、给一个部门用、先影子运行；阶段三才谈多组织、分级放权与 SLA。

最忌讳的是跳过阶段二：本机跑通就直接接生产库。中间缺的不只是权限，还有”连续四周影子运行积累的 badcase”——那是评测集真正的来源，也是唯一能让内审签字的东西。

九、总结与展望

9.1 组织与治理：边界要写进系统，不是写进制度

技术架构解决“能不能做”，组织设计解决“敢不敢用”。资金是强合规领域，任何“AI 自主执行”的提议，第一反应一定是“出事谁负责”。这个问题不解决，项目永远停留在“只读建议”阶段。

我的建议是把人机关系分成三档，并在系统里用技术手段固化，而不是靠一份管理制度文件：

L1 · 助手（人问 AI 答）：AI 只提供信息与建议，所有动作由人执行。适合知识问答、数据查询、报告生成。风险最低，落地最快，通常两周内可用。

L2 · 代理（AI 做，人看）：AI 执行标准动作，人负责审核与例外处理。适合自动对账、自动巡检、自动起草付款申请。需要评测集与转人工机制配套。

L3 · 自主（AI 做，人管边界）：在限额与规则内自主决策，超额强制上报。适合小额调拨、日内头寸摆布。必须有硬性限额、实时监控与一键熔断。

关键在最后一句：边界要写进系统。“单笔 500 万以内可自主调拨”这句话，如果只写在管理办法里，等于没有；如果写进代码（超过 500 万直接抛异常转人工），才是真的边界。同理，“只能查自己权限内的数据”要落在数据库视图权限上，而不是提示词里的一句叮嘱。

组织上需要四个角色到位：业务 Owner（定义什么算对、什么算错）、数据 Steward（保证口径与质量）、AI 工程师（构建与评测）、风控与审计（设计护栏、抽查留痕）。很多项目失败在角色缺失：只有工程师，没有业务 Owner，结果做出来的东西“技术上正确，业务上无用”。

9.2 五个坑：我见过最贵的学费

坑一：口径没统一就上模型。“可动用资金”在三个部门有三种算法，模型学得再好也只会把混乱放大。正确顺序是：先定口径、写进语义层，再做智能体。顺序反了，返工成本是原来的三倍。

坑二：把知识库当垃圾桶。把所有文档一股脑丢进去，不切分、不打标签、不做版本管理。结果检索出来的永远是三年前的旧制度和一堆无关附件。知识库需要“运营”，不是“上传”。

坑三：只做 Demo，不做评测。演示时挑几个好问题，效果惊艳；上线后遇到真实问题的长尾，立刻崩。评测集的意义不是“证明它行”，而是“找出它不行的地方”。没有评测集的项目，等于没有质检的工厂。

坑四：把智能体当 RPA 用。流程完全固定、规则完全明确的事（比如按固定模板生成对账单），用 RPA 或规则引擎更快、更便宜、更稳定。硬要用大模型，等于用高射炮打蚊子——贵，而且不准。判断标准很简单：如果这件事你能写出完整的 if-else，就不要用模型。

坑五：只算收益，不算运营成本。AI 系统的成本不只是开发，还有知识维护（每月更新制度）、评测更新（每月加 badcase）、监控告警、模型调用的持续费用。一个上线的智能体，每年需要 0.3–0.5 个全职人力做运营。这笔账不算清楚，第二年就会因为“看不见的维护成本”被砍掉。

9.3 AI 不会取代资金经理，但会取代“只做汇总的资金经理”

回头看开篇那个会议室。三个答案的背后，不是三个不专业的人，而是三套没有被打通的数据、三种没有被统一的口径、三个没有被自动化的动作。AI 能做的，是把这三件事一次性解决：让数据在一个地方、让口径只有一套、让重复动作自动完成。

也必须承认边界：AI 可以告诉你”缺口 3000 万”，可以建议”从 A 主体调 2000 万到 B 主体”，但不会替你决定”要不要牺牲某家银行的关系额度去换 15 个基点的收益”。判断依然是人的，AI 负责让判断有据、让执行更快、让过程可查。

判断一 · 交互形态：从“打开系统查”到“说出意图、确认动作”。未来三年，财务软件的主界面会从菜单和表单，逐步让位于”意图输入 + 结果卡片 + 确认执行”。报表不会消失，但会退居后台成为可追溯的底稿；前台变成一句”下周三能腾出多少钱”，以及一张带出处、可直接确认的调度建议。不会变的是凭证、留痕与审批链——监管不允许它们消失。

判断二 · 竞争壁垒：模型不是护城河，口径资产才是。大模型能力会持续平权，今天需要精心调提示词才能做到的事，两年后是默认能力。真正拉开差距的，是谁把散落在 Excel 备注、邮件和会议纪要里的隐性规则，沉淀成机器可读的口径字典、规则清单与评测集。这三样采购不来、替代不掉、只会随时间增值。未来评估一个财务 AI 项目，第一个问题不该是”用的什么模型”，而是”你们的口径字典有多少条、评测集有多少题”。

判断三 · 接口标准：MCP 类工具协议会成为财务系统的“第二套 API”。ERP、资金系统、银企直连过去只暴露菜单和接口；接下来会原生暴露”可被 Agent 调用的工具”，并自带权限、配额与审计。系统选型会多一条硬指标：这个系统的能力能不能被安全地调用，而不只是能不能被点击。本文第 7 章那十几行注册代码，就是这场变化的缩影——它把”集成一个系统”从项目级工作量，压缩成一次配置。

判断四 · 架构铁律：“确定性骨架 + 概率性外壳”会被写进审计准则。数字由固定 SQL、规则引擎、求解器算出，模型只做理解、归因与表达——这不是保守，而是由”一分钱都不能错”的会计属性决定的。可以预见，监管与内审会逐步要求 AI 输出具备可复现的计算路径，而不只是一个看似合理的答案。那些让大模型直接”估”余额、直接生成 SQL 的设计，会在第一次审计后被淘汰。

判断五 · 治理对象：从“人审每一条输出”转向“人审边界”。当调用量从每天几十次涨到几十万次，逐条复核不再可能。治理重心会前移到权限、限额、规则与例外清单：L1 助手、L2 代理、L3 限额内自主，本质上是给机器发放分级“驾驶执照”。财务负责人的新功课，是把”允许机器自己做什么”写成系统配置，并定期审这些配置，而不是审每一笔结果。

判断六 · 时效与组织：从 T+1 报表走向“始终在线”的头寸视图，共享中心被重新定义。事件驱动的资金视图会让”月度资金例会”这类场景逐步失去存在意义——不是会不开了，而是会前不再需要三个人对数字。随之变化的是岗位：纯汇总与抄录岗位持续收缩，同时长出三类新角色——口径工程师（维护业务语义）、AI 评测员（维护评测集与回归）、资金产品经理（把业务边界翻译成系统规则）。CFO 的仪表盘上，除了结账天数，会多出”口径一致率、自动执行率、人工干预率”三个指标。

三句话总结，外加一句给未来：第一，选对场景——高频、可测、可折算价值的，才是好起点；第二，补齐架构——知识规则层的投入，决定智能体是”聪明”还是”可靠”；第三，把边界写进系统——限额、权限、留痕、兜底，一个都不能少。而未来三年的分水岭，不在模型能力，而在数据治理与治理工程的成熟度。

如果团队正准备启动第一个资金 AI 项目，我的建议仍然是：不要从”最想做的那件事”开始，从”最容易验证对错的那件事”开始。把一件小事做到 90 分，比把五件事做到 60 分，更容易拿到第二年的预算，也更容易让组织真正相信这件事。而一旦跑通，请务必把过程中沉淀下来的口径、规则和评测题当成资产管起来——工具会换，模型会换，那三样东西会一直替你工作。

资金管理是一个”慢变量”领域——制度要稳、口径要稳、底线要稳。但正是在这种稳的底色上，AI 带来的那一点”快”，会变成最稀缺的竞争力。再过几年回看，今天这场讨论的真正问题或许不是”AI 能不能做财务”，而是：当判断可以被写进系统、执行可以被授权给机器，一个财务组织还剩下什么不可替代？我的答案是——定义什么算对、决定什么值得做、以及在例外发生时承担责任。