通用知识库方案在这三个点上不做改造，基本都会在半年内停摆。下面按「问题—根因—做法」拆开讲，页尾可直接提交需求。
本文对应公开社区的高频提问：会计师事务所/税务师事务所怎么做知识管理？所里积累的资料怎么让新人用起来？
财税行业的政策一年改好几次，新旧口径的文件同时在服务器里是常态。问题在于，通用的语义检索只看语义相似度、不看时间。一份已经废止的口径，很可能因为表述跟提问更匹配，被系统优先捞出来，还组织得条理清晰。
发现的时候通常已经晚了——往往要等客户问起、或者复核时才暴露。这不是提示词能调好的问题，是数据结构问题。
每份文件入库时登记生效日期与失效日期，新版入库时把旧版归档出检索索引，而不是并排留着让排序去猜。这是财税方案的基础项，不是可选优化项。
一线的问题通常不是「帮我找某号文」，而是「这个客户的这种情况按哪个口径处理」。而口径散落在三个地方：政策条文、过往底稿、还有资深同事的判断。前两个在服务器里，第三个在人脑子里。
如果整理的时候按文件类型归档（政策类/底稿类/模板类），检索时用户拿到的是一堆同类文件，仍然要自己判断。这条路径走不通。
按业务场景重组知识条目，一条目对应一类问题，带上责任人和复核日期。复核日期到了自动提醒复审，过期的口径降级或下线。没有主人的知识条目会静默腐烂，这是所有知识系统失败最常见的原因。
申报表、台账、计算表——财税机构的主力资料不是段落文本，是表格。通用的切片逻辑按固定长度切，很可能把表头和数据行拆到两个片段里。结果就是：问「某项在第二季度是多少」，系统永远拼不出答案，但它不会说不知道，它会给你一个相近的数字。
表格单独做结构化解析，保留表头与数据行的对应关系再入库。这一步省不掉，省掉就等着一线说「系统是错的」。
底稿、账套、客户身份信息属于高敏感内容。不同客户的材料必须在元数据层打上归属标记，检索时先过滤再做匹配。这一步做在检索阶段才有意义——等到答案生成后再遮挡展示已经晚了，文本已经进模型上下文了。
在财税和律所这类机构，权限设计失误的后果不是「内部薪酬被看到」，是另一个客户的底稿被检索出来。这是执业层面的事故，不是 IT 层面的小故障。
有没有一类问题，是所里每个月都要重复回答十次以上的？
有，就值得做——先把这一类场景做透，做出效果再扩展。
没有，说明问题不在这里，先把资料整理好，别急着上系统。全量导入基本等于把混乱搬了个家。
目前处于首批试点阶段，报价按资料量与场景复杂度沟通确认，页面不列未经确认的数字。
写下你最想解决的一类查询，我们会基于你的资料现状给出能做到与做不到的边界，不合适的场景直接说明。