从"提需求的人"到"造工具的人"——一名银行财务用 WorkBuddy 打造费用报销工作台的全流程实录

我是一名国有银行从事费用报销业务的财务人员，这篇文章记录了我如何用 WorkBuddy，把积累的报销管理经验变成一套真正能用的「费用报销工作台」：一个覆盖事前申请、报销、审核、支付全流程，内置风控规则、费用标准、流程参数、人员角色权限，真正能跑通的「轻量级费用报销应用」（以最常见的招待费、差旅费报销为例），让报销成为“一件简单且标准的事”。

这不是一个"AI 真神奇"的故事，而是一个传统财务人员在AI时代如何运用WorkBuddy，和时代前沿技术结对、反复打磨、踩坑填坑，把业务理解变成产品力的过程。希望我的经历，能给同样想在业务一线做点什么的朋友一点参考。

一、站在报销业务一线，我每天面对的是三大痛点

做费用报销久了，你会发现这个业务的难点从来不在"算账"，而在"规矩"和"人"。

1. 专业壁垒：业务人员不懂财务制度，“鸡同鸭讲”一脸懵

国有金融企业的财务管理制度非常细致，叠加中央八项规定及其实施细则精神，对包括招待费、差旅费、会议费在内的专项费用，及公司日常各类费用开支，从预算、事前申请、采购、实施、报销支付提出了严格且细致的要求。招待费细分招待类型、费用标准不一，如何合规购买使用酒水；差旅分国内普通出差、会议培训、因公出国境，场景不同报销标准不同；探亲只能报城市间公共交通、市内交通费必须为零；装修施工分期付款的证明材料、付款进度控制表……这些规定写在制度文件里，很少有人真的去读，有的场景一年也报销不了几次。结果就是：填错科目、漏传材料、金额口径不对，单子打回来、改完再报、再被打回，财务和业务双方都在做无效功。

2. 填单复杂：一张单几十个字段，材料一堆，人工填报工作量大

以差旅报销为例，出差人、行程、交通、住宿、补助、发票、收款人……字段动辄十几个，还要对应上传行程单、发票、审批单等多种材料。很多人报销一次要花一两个小时，还要反复核对。尤其涉及会计核算、开票税目、增值税是否抵扣等专业的财税问题，报销要录，但非财务背景的报销人看到一脸懵。效率低倒在其次，错漏才是大问题——一个税率填错、一张发票漏传，后面审核环节全都要重来。

3. 审核压力：国企财务报销要求高，审核点细致到"一行都不能错"

财务审核是最后一道关。人均费用有没有超标、陪餐人数有没有超、公务接待有没有用酒水、报销金额有没有超过事前申请、发票税目是否合理、三流对不对得上……每一个点都是合规红线。审核人员要逐单逐条人工比对，工作量大、容易漏，报销慢了会被投诉，出了问题还要担责任。"提示"和"拦截"哪些该严、哪些该宽，分寸必须拿得准。

因此，我希望系统做到三件事：让业务人员更容易理解报销要求，让填单变成简单且规范流程，让系统能够提前识别明显风险。

二、财务人参与系统开发，也有三个绕不开的老难题

既然业务痛，为什么不做个系统解决？我们其实试过，但财务参与系统开发，有自己的难处。

1. 需求场景不明确。 财务提需求，往往是"我要一个能审核报销单的系统"，但具体到"哪些字段业务录，哪些信息财务填""驳回操作一驳到底，还是可以点对点提交"这种细节，需求文档里根本写不全。开发出来的东西，总差那么一口气。

2. “能用”不等于“好用”。 需求文档是文字，开发按文字做出来，财务一看：这不是我想要的。但问题在哪，一句话又说不上来。比如我们曾经希望"报销前选一下场景"，开发做成了表单里的一个下拉框——能用，但业务人员还是会选错，因为下拉框没有告诉人家每个场景是什么意思，这些问题如果不在试用中暴露，通常会在上线后变成返工。

3. IT 和财务理解偏差。 财务说"招待费要根据类型和城市设置标准"，IT 理解成"加个提示"；财务说"拦截"，IT 理解成"弹个窗"。一个词的理解偏差，就是一次返工。来回几轮，开发周期拉长，产品效果打折，双方都很疲惫。

这三个难题的本质是一样的：财务懂业务但不懂技术，IT 懂技术但不懂业务，中间隔着一层翻译。 而WorkBuddy 让我第一次觉得，这层翻译可以不要了。

三、转变：从"提需求"到"自己动手"，开发模式的三个变化

用 WorkBuddy 开发报销工作台，我做的不是"学写代码"，而是用自然语言，把我脑子里的业务规则一条条讲给 AI 听，让它把规则变成代码、把界面做出来。这个过程中，我的开发方式发生了三个关键变化：

1. 从"写文档"到"聊原型"。 我不再写长篇需求文档，而是先让 AI 做一个能点的原型，我点一遍、让同事点一遍，哪里不对就改哪里。"前置场景选择页"就是这么来的——最初按传统报销录入方式，让 AI 在报销申请表里加了个核算科目下拉框，非财务人员还是不懂具体科目之间的差异，我直接把想法推翻，改成"把财务制度翻译成业务场景，每个场景配一句话说明"。原型先行，需求在试用中自己长出来。

2. 从"一次交付"到"小步快跑"。 把大的工作台规划拆分成一个个小的工作点，每改一处，就升一个版本号、跑一次回归、发布一次线上。以近期修订的 V5.40 到 V5.47，八个小版本，每个版本只解决一两个明确的问题：V5.41 修审批历史归档里驳回记录丢失的问题，V5.44 加版本徽标，V5.45 强化风控规则，V5.46、V5.47 分别重构差旅、招待的事前申请场景选择流程。问题被切碎，每一步都可验证、可回退。

3. 从"口头验收"到"测试兜底"。 我让 AI 为每一轮改动写自动化回归用例，前后累计 110 条。改完代码必跑测试，测过了才发布。财务最怕"改 A 坏 B"，自动化回归就是防这个的。

四、流程设计：把"制度"做成"流程"

业务流程闭环：以业务人员日常最为关心的招待费、差旅费报销为例，我按照事前申请（差旅/招待）→ 选场景 → 填单提交 → 业务领导事前审批 → 报销申请 → 业务领导审批→财务人员费用审核 → 费用支付。一条线串起报销全生命周期，每个环节的状态都在工作台首页的"待办/清单"里可见（运营监控模块为预留扩展位，待后续迭代）。

图1　首页工作台：待办按费用类型分组，顶部可一键切换身份，右上角常驻版本徽标

几个关键模块的设计思路：

（1）费用申请 / 报销申请——场景化是核心。 我把财务制度翻译成业务场景，通过SOP报销制度明确材料需求和费用标准，内嵌到系统流程：招待费 3 个（报销宴请费用、购买酒水、购买招待礼品），差旅费 5 个（国内普通差旅、会议/培训出差、探亲、因公出国境、混合差旅）。用户进表单前先选场景，卡片上写着每个场景的适用范围，比如"探亲——异地调配或交流人员探亲"。把复杂晦涩的财务管理要求转换成业务人员熟悉的业务场景，场景一旦选定，决定后续校验规则，选错场景等于规则用错，必须前置锁定。费用申请和报销申请复用同一张场景表、同一套选择页交互，保证两处体验一致、规则一致。

图2　报销业务场景选择页：8 个场景分组展示，每张卡片一句说明

（2）风控规则贯穿全流程——把制度说教转为操作引导

将财务制度和报销流程标准化为SOP文档，结合日常审核经验沉淀为风控规则，内嵌到费控系统的全流程，通过系统自动校验、提示，在识别、拦截财务风险的同时，告诉业务人员“吃饭人均标准是多少”、“陪餐人数最多几人”、“周末和节假日可以报销出差费用吗”这些常见的问题。

图3 ·招待费申请界面：内嵌费用标准和校验规则，根据申请内容实时校验反馈是否符合要求

（3）费用审核——给审核人员一张"看得全"的工作台。 审核界面把单据内容和审核日志左右分栏，谁经手过、谁驳回过、驳回原因是什么，一屏看清；审批历史统一归档，保留包括驳回、加签在内的所有审批动作和沟通记录——审批日志也是合规证据，不能丢。

图4　费用审核·共享审核视图：左边单据信息，右侧系统风控审核汇总

（4）规则参数——把制度参数化。 费用标准、税务抵扣规则、汇率表、供应商、人员权限、风控谷子额都做成可维护的参数页，制度调整时改参数即可，不用改代码。

图5　制度参数化：把费用标准、风控规则、制度要求参数化，方便前端配置

（5）OCR识别+自动关联——为"填单减负"。 上传发票图片自动识别发票号、日期、明细、税额并回填表单，通过云OCR配备识别服务，也设定兜底条款——OCR识别失败自动回落手工录入。大部分业务信息如和事前一致，选择线上事前申请后自动关联匹配，支持人工确认修改，这是针对"填单复杂"痛点的直接回应。

五、整体架构设计：一个财务人能 hold 住的架构

定架构时，我的诉求很明确：轻量、能演示、数据不出本地、一个人能维护。 最终方案：

1.形态：单文件 HTML 应用，双击就能打开网页版，发布成一个链接就能给全行同事用。

2.数据：浏览器 localStorage 本地存储，无外部依赖，演示和试运行阶段零部署成本。（后来为了解决报销材料存储的问题，改为IndexedDB 保存附件 Blob，localStorage 只保留附件引用 ）。

3.模块：7 大主导航——工作台（首页）、费用申请（事前申请）、报销申请、费用审核、费用支付、运营监控、规则参数；规则参数下再细分风控规则、管理制度、人员角色与权限、供应商信息、汇率表、差旅标准、税务抵扣、识别服务 8 个子页。

4.扩展：发票 OCR 识别走"识别服务"配置，这里我使用了阿里云OCR的1分钱试用版本，让AI配置中转服务接口；未配置或识别失败时自动回落到"智能录入"手工填写，主流程不被卡住。

5.版本治理：版本号只有一个来源（代码里的 APP_VERSION 常量），顶栏徽标自动显示，杜绝版本漂移。

这个架构的好处是：我能看懂每一层在干什么，能独立改、独立发，不依赖 IT 排期。 对财务主导的试运行项目来说，这比"技术先进性"重要得多。

六、亮点一：用户体验优化，让业务人员"少想一步、少错一次"

用户体验方面，我比较在意的几处设计，也是让AI反复打磨修改的地方：

1. 把制度翻译成业务语言——场景选择页。 不再让业务人员在"招待费报销"这个大类下裸填，而是先选"报销宴请费用 / 购买酒水 / 购买招待礼品"，每张卡片配一句人话说明。选场景的过程，本身就是一次制度宣贯。把"看懂制度"变成"选对卡片"，专业壁垒就这么被削平了。

图6　差旅费事前申请场景选择页：五类差旅场景，按场景建单

图7　差旅费事前申请表单：场景选定后只读回显（图中为"探亲"），不允许再改

2.场景内嵌财务标准，统一场景运用。 报销申请、费用申请两个入口共用同一套场景选择页，卡片样式、交互完全一致。用户学一次，处处能用。具体场景需要的的报销材料清单、填单要求、校验规则全部内嵌在系统流程，实时校验，并通过风控规则“拦截/提示”的差异化配置，刚柔并济控制财务合规风险，潜移默化中宣导财务规范。

3.“千人千面”：根据人员角色差异化配置界面。通过人员角色和岗位的权限配置，根据实际工作需要差异化配置他们能看到的界面和模块，避免非财务人员看到一大堆财务功能，也规避不同人员角色功能重叠，防止误入界面。同时还通过人员过滤功能，业务人员只能看到本人相关的单据（如申请人、出差人、审批人是本人），有效保护隐私做好权限隔离。

图8 人员角色与权限表：根据岗位、角色定义可见模块

4. 面向测试的体验设计。 顶栏加了人员身份切换条，一键切换经办人、财务、审批人等角色，把"不同岗位看到什么"变成可现场演示的东西，一键切换即可点击审批流，验证不同角色的产品功能；版本徽标常驻顶栏，谁在反馈问题时说不清"你用的是哪个版本"，一眼便知。

5. 信息分组降噪。 首页待办和单据清单按费用类型分组展示，财务一眼看清"差旅有几单、招待有几单"，不再是一锅粥；单据页面分基本信息（申请人、所在部门、日期）、业务信息（如具体的招待和差旅信息）、财务信息（会计核算、发票及税务信息）、材料上传清单一目了然。

6. 移动端可用。 底部 Tab 适配手机，出差路上也能把单填了。

这些设计都不"炫技"，但每一处都直接对应开头说的痛点：降低专业门槛、减少填报工作量、减少来回沟通。

七、亮点二：财务合规控制，把审核点从"人盯"变成"系统守"

合规是这套工作台的地基，做法可以概括为三句话：制度规则化、控制分级化、拦截双入口化。

1. 风控规则落库、可视化维护。 规则不再只存在于财务人员的经验中，而是以规则编号、名称、说明、适用范围、所属模块和控制方式呈现。购买酒水单价限制、酒水使用校验、探亲交通限制、报销金额超过事前申请等规则，都有对应的业务位置。从"人均费用超标""陪餐人数超标""公务接待不可用酒水"，到"收款人合计超支付金额""差旅费超标准"，每条规则都有名称、说明、控制范围、控制模块、控制方式，财务自己在规则参数页就能维护，制度变规则、规则即执行。

图9　风控规则配置页：规则逐条列明控制范围与提示/拦截级别，财务可自行维护

2. "提示"与"拦截"两级控制，宽严有据。 刚性的金额红线（收款人合计超支付金额、报销金额超事前申请、探亲交通违规、酒水校验）设为拦截，提交即被系统挡下；弹性的提醒（人均超标、行程含周末、材料不齐、涉及审批人本人费用）设为提示，弹窗确认后留痕放行。该拦的死守，该提示的留痕，分寸由制度定、由财务调。

3. 事前申请与报销"双入口"拦截。 以探亲差旅交通限制为例：探亲场景只允许飞机、火车、巴士、轮船等公共交通，不得出现出租车、网约车、包车，且只能报城市间交通费、市内交通费必须为零——这条规则在事前申请提交时拦一次，报销提交时再拦一次，两个入口命中后分栏标红，想绕都绕不过去。报销金额超过事前申请同理，事前、报销双端校验，金额口径前后锁死。

4. 审核界面把风控结果"摊开"给审核人。 单据表单审核采用左右分栏：左边是完整单据表单，右边实时汇总风控命中情况（拦截级、提示级、合计命中数）和财务审批日志，命中字段在左侧表单同色标记。审核人不需要自己算，系统已经把风险点标好了。

图10　单据表单审核：左·单据表单，右·风控规则审核汇总与财务审批日志

5. 留痕与回避，补上合规的细节。 差旅超标提示后确认提交，系统留痕；审批人涉及本人费用时提示转上级（或代职人）审批，落实回避要求；报销材料必填项不齐直接提示；审核日志全链路共享可查，驳回记录进历史归档。每一步操作都有据可查，这是国企报销的底线。

6. 规则可配置、向后兼容。 规则的控制范围、控制模块从单行文本升级为多选勾选框，财务勾选"招待费事前申请·招待费报销"即可完成双端绑定，老数据自动兼容，不用手工迁移。

效果是直观的：过去审核靠人逐条比对，现在系统先拦一遍、提示一遍，审核人员只看系统放行的部分，审核压力和差错率一起下降；过去业务人员填单靠猜，现在选错场景、金额超标、材料缺失在提交时就被系统告知，退回率明显下降。

八、开发协作：云端与桌面双端接力，知识库做交接枢纽

这次开发的另一个特色是跨环境接力。项目在云端 WorkBuddy 起步，迭代到 V5.41 后转到桌面端继续加工至 V5.47，再回到云端接手到目前的V5.64。为了让"换环境不换上下文"，我摸索出一套交接方法：

1.每轮迭代同步更新需求说明书（用生成脚本自动生成 Word，更新说明倒序插入、封面版本号同步——这点证明比较耗积分，我后来改成每天汇总一次）；

2.写交接文档总入口，记录每轮"做了什么、改了哪些函数、怎么验证"、发布工作流和已知坑；

3.把交接文件（源码、说明书、生成脚本、交接文档）上传到 ima 知识库，接手端装上 ima 技能后直接按前缀检索拉取，几分钟内完成上下文重建。

4.把交接流程技能化，经过两轮云端——电脑端——云端的跨环境交接，我让WorkBuddy把交接流程做成了一个标准的技能，每次需要时调用即可轻松实现交接工具包的生成、入库。

版本从 V5.40 到 V5.47，每一版都有明确的主题：V5.41 修审批归档、V5.44 加版本徽标、V5.45 强风控、V5.46/5.47 重构场景选择。版本即叙事，交接即传承——这套方法让我即使隔几天换台机器，也能无缝续上。

九、心得体会：那些反复修改踩过的坑

最后把这次开发踩过的坑整理出来，按"问题—问题描述—解决思路"列成一张表，都是真金白银的教训（积分实在太贵辣），关键是人的设计思路要清楚，语言描述要明确，坚持人工验证结果：

开发踩坑清单

结语

回头看，这个项目最大的收获不是做出了一个工作台，而是验证了一件事：财务人员完全可以成为自己业务工具的设计者和建造者。 我们不需要先学会编程，需要的是把业务规则讲清楚、把边界情况想清楚、把验收标准定清楚——剩下的，AI 能接得住。

从三大业务痛点出发，到三大开发难题，再到一套场景化、规则化、留痕化的报销工作台，这次经历让我真切感到：最好的财务数字化，是懂财务的人亲手把制度变成产品。 而这一切，从一句"帮我做一个报销工作台"就开始了。

欢迎交流指正，感兴趣的话后面我会继续调试工作台，并发布具体的操作步骤和页面功能。