chore:文档补全

output/feishu-docs/R9ciwHpaiiNECoktn2WcD4D9nmh.md

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