Evilom
7.6 KiB
R9ciwHpaiiNECoktn2WcD4D9nmh
Source: https://fcnlycv6dd0w.feishu.cn/wiki/R9ciwHpaiiNECoktn2WcD4D9nmh
今日内容
①财务 AI 知识库——搭建思路 ②调研手机端 AI 调用方案 ③财务数据获取较慢原因梳理
一，财务 AI 知识库——搭建思路
（一）背景目标
🔎 围绕财务部前期提出的知识库相关需求，本次以 Gemini Gem 作为轻量化工具，先搭建一个可测试、可学习、可复用的财务知识库助手。 核心： 先从文件整理和问答检索切入，让财务人员先体验"把资料放进去，通过提问快速查找、提取和总结"的工作方式。上手门槛低，不需要写代码，财务人员可以直接学习和复用，后续再逐步扩展到更复杂的场景。
（二）主要应用场景
- 财务制度问答：
- 报销规则、审批流程、费用归类等制度查询，减少人工翻文件的时间。例如"某类费用应该如何报销""某项审批需要哪些材料"
- 税务政策查询：
- 快速定位政策依据，辅助判断某类业务涉及哪些税务规则。例如"某类业务税率是多少""某张发票能否抵扣"
- 监管规则辅助检查：
- 按既定规则做初步比对，检查某个操作是否可能涉及风险，提示需要人工复核的点
- 合同台账提取（后期扩展）：
- 从PDF/Word中提取合同金额、付款条款、到期时间、风险条款等结构化信息，汇总成台账
（三）工作流过程
第一步：用豆包/GPT辅助生成Gem说明与指令 在正式搭建Gem之前，先用豆包或GPT辅助生成Gem的说明文字和指令框架、 如核心要点：
- **明确Gem的角色定位：**财务制度与税务政策检索助手
- **限定回答范围：**只能基于上传文件内容回答，不能凭空编造
- **设定风险提示口径：**涉及税务风险和合规判断时，只做初步提示，不替代最终判断
- **规范输出格式：**回答时标明依据来源，风险类问题区分"已明确风险""可能风险""需人工确认 第二步：整理知识库文件 ，上传搭建Gem 将三个规则文件（财务制度、税务政策、监管规则手册）整理为PDF/Word格式，确保内容清晰、结构完整，便于Gem检索引用。导入Gem知识库，配置好说明和指令，完成基础搭建。 第三步：导入测试文件，进行测试 测试以下能力：
- 能否识别报销单中违反差旅制度的项目
- 能否对照监管规则提示风险点
- 能否区分"明确违规""可能风险""需人工确认"三个层级
- 回答是否引用了文件依据，是否出现幻觉
第四步：评估结果，调整指令和文件范围
后续根据测试结果，观察Gem的回答准确度、引用质量和边界控制情况，针对问题调整指令表达或补充文件内容，逐步优化到财务可实际复用的状态。
:thinking_face: 财务 AI 应用不能一开始追求大而全的自动化。更现实的路径是先从低风险、高频、可验证的场景跑通，再逐步更复杂的场景。
二、调研手机端 AI 调用方案
（一）背景目标
财务部前期提出希望能在手机端调用AI处理财务文件、查看报表和做简单分析的需求。围绕这一需求，调研评估了三种可行方案：
- Codex官方移动端连接电脑
- 微信桥接Codex
- 手机端Kimi/GPT
（二）三方案说明与对比
方案一：Codex 官方移动端连接电脑 Codex 官方已提供移动端连接电脑端 Codex 的能力。 手机端发起任务后，由电脑端 Codex 在本地执行——读取本地文件、处理表格、生成报告，结果再返回手机端。
- 目前主要适配 Mac 环境，Windows 使用场景受限
- 依赖电脑端 Codex 持续可用，电脑可以锁屏但不能睡眠、断网或关机
- 一旦网络中断，手机端体验随即中断
方案二：GitHub项目微信桥接 Codex - 通过 GitHub 上的第三方开源项目，将个人微信与本机 Codex 打通。
- 部署完成后，用户在微信里发消息给 Codex，电脑端 Codex 在本地执行任务，再把结果返回微信对话框。
- 目前该链路已完成初步测试，微信消息可以传到电脑端 Codex，结果也能正常回传微信。 但对财务侧推广来说存在以下问题：
- 需要在电脑上长期运行后台服务，电脑不能断网或关机
- 部署和维护有一定成本
- 如果只是临时分析一个低敏报表或写一段摘要，直接打开手机端 Kimi/GPT 更简单，微信桥接反而增加了不必要的复杂度
方案三：手机端 Kimi/GPT 直接处理轻量任务 - 直接在手机端使用 Kimi、GPT 等工具，对低敏文件、截图、公开资料或简化后的指标数据进行分析。
- 不需要连接电脑、不需要部署服务，也不依赖某台电脑是否开机，操作最直观，适合短期先推广试用。
:thinking_face: 评估总结： ① Codex官方移动端连接电脑和微信桥接Codex虽然技术上可行，但都依赖电脑在线、网络稳定，还需要一定的部署和维护成本，不适合现阶段主推给财务侧，后续有复杂任务执行需求时再考虑引入。 ② 当前更实际的推进方向是以手机端 Kimi/GPT 直接处理低敏、简单、临时性的报表分析和文字整理任务为主——财务侧现阶段更需要的是"拿起来就能用"的轻量工具，而不是依赖电脑后台服务和额外部署的技术方案。
三，财务数据获取较慢原因梳理
（一）初步结论
这类数据输出慢，不是因为最后汇总计算本身慢，而是因为前端取数、字段映射、数据整理、核验复核等环节整体链路较长，且较多依赖人工处理，导致整体效率偏低。
（二）原因梳理
- 相关财务数据来自多个系统，需分别进入不同平台取数，无法在单一系统中直接形成完整结果。
- 目前多数数据仍需人工导出，再放入 Excel 进行整理和汇总，缺少稳定的自动化取数方式。
- 不同系统中的字段定义、分类方式、统计口径不完全一致，同类成本数据在汇总前需要先做人工映射和规则转换。
- 多个明细表通常需要先复制汇总到一个大表，再通过公式、透视或人工加工形成目标结果，处理链路较长。
- 现有公盘/Excel 跨表取数时，容易出现链接失效、乱码、引用异常等问题，导致无法稳定联动，只能改为手工合表处理。
- 不仅是报表汇总本身慢，上游还存在对账、录入、与外部平台核对等工作，进一步拉长了整体处理时间。
:thinking_face:
总结
- 财务数据获取较慢原因本质上反映的是**财务基础数据组织方式、字段口径设计、归集规则沉淀和数据处理流程**的问题，而不只是某一个报表生成慢的问题。
- 后续如果要真正提速，重点应放在**基础数据规划、规则标准化、流程模板化**。