你说得对,我上一版把逻辑顺序和进度都写岔了。重新来,这次严格按你实际走过的路径写:种子文件已种下 → 爬取存档已完成 → 发现主键问题 → 提出修订规则 → 检验通过 → 有图有真相。
#WorkBuddy
做财税这行几十年,电脑里攒了上万份文件。政策原文、批复、答复、案例、内部研讨记录,全是我一点点攒下来的"家底"。
但文件多到一定程度,反而成了负担。最难受的场景是:我明明记得"以前见过一个文件讲过这个事",但就是翻不出来。靠脑子记年份、记关键词,效率太低了。
所以最近在找一个能把文件高效归档、建立知识库的工具。既然是腾讯家的产品,我直接问了元宝,它给我推荐了 WorkBuddy。
下载、登录、绑定微信,积分拿了一些,开局顺利。
我没有一股脑把所有文件全倒进去,而是先挑了一批有代表性的核心文件作为"种子",喂给 WorkBuddy。这批种子的爬取和存档,已经全部完成了。
从把文件丢进去,到系统自动扫描、提取、归类、建立索引,整个流程跑通了。看着那些散落多年的文档被一条条归档到位,心里踏实了不少——几十年的积累,终于不再是"死档案"了。(有图有真相,后面会放爬取完成的截图)
种子跑通之后,我仔细检查了系统的关联和检索逻辑,发现了一个问题:系统默认用"文件号"做主键,用来锚定检索、版本链和解读关联。
我觉得不对。
平时找文件,没人会记得文件号。 大家都是凭文件名里的核心关键词去找——"那个讲滞纳金问题的""那个关于关联交易认定的答复"。文件名才是真正的锚点。而且很多文件根本没有文件号,拿一个可能缺失的字段做主键,体系从根上就不稳。
发现问题之后,我把整套存储和命名规则重新定了一遍:
1. 主键与命名
存档文件名 = 文件号(可空)+ 公文文件名(必填)+ 年号日期(YYYYMMDD)
文件号可以没有,文件名不能没有。同名文件靠日期区分,天然唯一。这条规则我把它定为铁律,后续所有设计都不能违反。
2. 双格式存储
每份文件同时存 PDF 和 HTML 两种格式。PDF 是不可篡改的底稿,HTML 用于浏览和发布;定期把 HTML 和 PDF 做一致性比对,防止被篡改后浑然不知。还留了种子备份,万一系统出问题能快速恢复重建。
3. HTML 排版规范
提前把电脑版和手机版的排版规则都定死了:编、部分、章、节整行加粗;"第一条""第二条"仅这几个字加粗,后面跟一个半角空格再接正文;"第一款""第二款"不加粗;每个自然段首行空两个字。这些细节在公文场景里一个都不能错,现在定好,后面批量处理才不会乱。
规则定完之后,我用这批种子文件按新规则重新跑了一遍验证。结果符合预期,检验通过。
命名规则没乱,双格式正常生成,HTML 排版效果也对。这说明这条路走得通——接下来可以把剩下的大批量文件按这个标准逐步推进了。(同样有图有真相,命名结构、HTML 排版效果的截图都会附上)
目前才刚刚起步,但有一件事已经想得很明白了:AI 是助手,不是裁判。
我那一万份文件里,肯定有缺失、有矛盾、有不同立场的材料。如果知识库本身就残缺,AI 基于不完整的信息做推理,得出的结论就是错的——在税务争议场景里,这种错误可能是致命的。
所以我的原则是:AI 只做"检索加梳理"的粗活,帮我把相关材料捞出来、按规则分层、告诉我哪些关键文件库里没有。最终判断和责任,必须由我自己扛。
工具是杠杆,几十年的专业积累才是支点,判断力是不可替代的灵魂。
种子已经种下,爬取存档完成了,修订规则也检验通过了。接下来就是按这个标准,把那一万份文件分批逐步导入。等真正跑顺了,再来写后续的记录。
以上是基于真实操作过程的记录,有图有真相。规则还在持续优化中,欢迎同行交流指正。

原来自己整理的文件也就这个样子:





下一步,我打算把"税务争议破局"做成标准化作业模板:AI 按法律适用规则梳理材料链 → 自动标记缺失关键文件 → 输出带引注的论证框架 → 人类专家终审签字。届时再来社区分享。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。