代记账公司如何用本地知识库：四个场景一套方案

为什么代记账行业特别适合先上 AI

和很多行业"先想清楚再动手"不同，代记账的痛点是现成的、每天重复发生的：

• 人手紧：一个会计往往对接几十家客户，旺季问询量翻倍，接不过来；
• 政策更新快：税率、申报口径、优惠政策年年调整，老知识耽误新业务；
• 客户问题碎：八成以上的客户提问是重复的——"这个月征期到几号""这个票能不能抵扣""执照变更要带什么"。

这些问题不需要"通用人工智能"，需要的是一个装着政策文件、内部流程、常见问答、随时能问的知识库。这正是本地知识库（RAG）的甜点区。

场景一：政策与征期答疑，把"问同事"变成"问知识库"

把税务局公开的政策文件、申报操作手册、贵司内部整理的征期日历和常见问答，一次性喂给知识库。之后：

• 会计查口径：直接问"小规模纳税人这个季度的增值税优惠政策是什么"，答案附出处文件；
• 客户接待：把常见问题做成对外的问答入口，重复问题 AI 先答一遍，复杂问题再转人工；
• 新人上手：流程性的问题（执照变更、注销要哪些材料）不再依赖"老会计在不在工位"。

关键要求：每个答案都必须能溯源到知识库里的具体文件。答不出、没依据的，就明说不知道——这比一本正经地胡说八道重要得多，也是选型时要重点验证的能力。

场景二：票据影像的预处理与质检辅助

票据环节 AI 的定位是初筛和提示，不是判断：发票抬头、税号、金额、日期这些结构化信息可以自动识别比对，疑似缺联号、抬头不符、跨期票据给会计一个"待复核"提示。复核权始终在人手上——这既是效率问题，更是责任边界问题。

场景三：征期监控与提醒

征期日历进知识库，再配上定期任务：临近申报截止日，按客户名单自动生成提醒清单推给对应会计。这个场景技术含量不高，但省下的是最贵的"忘了"。

场景四：增长——拓客内容与转介绍

知识库不只对内。把沉淀的政策解读、常见问题整理成面向客户的内容（朋友圈、公众号、答疑短文），是代记账公司最低成本的获客物料；客户服务体验上去了，转介绍自然跟着来。AI 的价值是让一个会计能维护过去一个团队都顾不上的内容产出节奏。

为什么我们坚持"本地"这两个字

代记账手里的是发票、身份证复印件、银行流水、工资表——把这些传到公有云大模型的 API 上，等于把客户的商业机密交给了第三方，这条路在合规和客户信任上都走不远。

本地私有化部署的含义是：模型跑在您自己的服务器上，知识库存在您自己的硬盘里，对话记录不出内网。断网也能用，数据的主权从头到尾在您手里。

我们的标准 POC 起步配置

不空谈架构，给出我们实际使用的 POC 基准：

环节	选型	说明
模型运行	Ollama + qwen2.5 7B 级开源模型	单卡可跑，中文政策文本理解够用
知识库前端	AnythingLLM / WorkBuddy	文档导入、权限分区、对话引用出处
规模基准	1 台服务器 + 5 客户端 + 5 部门	先小规模验证，再按负载扩
数据边界	全链路内网	不经任何第三方云端 API

POC 的目的不是"一步到位"，而是用最小成本验证三件事：答案质量够不够用、员工愿不愿意用、省下来的时间值不值电费。验证通过再谈扩容。

落地五步

1. 免费业务诊断：梳理贵司的重复问题清单和数据资产现状；
2. POC 试点：按上面的基准配置搭起来，选 1-2 个最痛的场景先跑；
3. 喂料与调校：政策文件、内部手册、征期日历进库，验证答案溯源；
4. 员工培训：会打字就会用的界面 + AI-OPC 使用培训；
5. 正式运行与扩展：按使用数据决定扩大场景还是升配硬件。

最后：哪些事不该交给 AI

账务判断、税务申报的最终责任、与客户的实质性沟通——这些必须留在专业会计手里。AI 接管的是"找资料、查口径、盯日期、初筛票据"这些吃时间不吃判断力的环节。人做判断，AI 做跑腿，这条边界划清楚，方案才立得住。