先说结论：这次没有通稿可拆，没有跑分可打，也没有价格表可以算账。八月底 dev.to 上冒出来一个自托管文档库叫 Kintara，我照了一圈，没找到想踩的点。
在我这儿，这属于罕见事件。
我本来是准备踩的。
dev.to 上这类项目跟野草一样，每个月长一批。Rust 写的，Docker 部署，盯着你 NAS 上某个文件夹，带 AI，tags 一挂，齐活。这届文案的配方，我闭着眼能背下来！
而这种项目里 AI 的用法，九成只有一个：界面右上角糊一个聊天框。
点开，输入框，光标闪。你问「帮我总结这份 PDF」，它回你一段读起来很像那么回事的话。字数够，页码没有。你真去翻，翻不着。
先把丑话说在前头：这篇不算上手实测。镜像放出来了，仓库也在，但我这周没腾出整块时间把它拉起来喂真实文件。下面这些判断，是我隔着发布帖和评论区照出来的。设计能隔着照，手感不行——这个坑我记着。
它默认模型一定会编
Kintara 里有个功能叫 Find。你问一句，模型返回的不是一段流畅解释，是一段带页码的原文引用。服务器拿到引用，先回抽取出的页面文本里查一遍，查不到就丢。查到了，再拿 pdf.js 渲染出来的结果复核一遍。两遍都对不上，一样扔。
我读出来的意思是：这作者默认模型一定会编。
不是「可能会编」，是「一定会编」。
我照过的大多数 AI 集成，做法正好反着来——system prompt 里塞一句「请不要编造内容」，然后祈祷 🙃
幻觉在这类产品里被当成 bug 处理，而不是当成前提设计！Kintara 当前提。所以这不是防幻觉 prompt 写得好不好的问题，是把模型摆在什么位置的问题。
评论区有人问得比我准。一位叫 Suraj 的留言问，这套「建议—独立核验—应用」的流程，能不能抽象成文档系统里 AI 功能的通用接口。作者回复确认，说这本来就是她的设计意图：模型只负责提建议，应用层才是判定有效性、决定落库内容的权威。
做过 RAG 的都懂这句话的分量。
现在多数集成的模型输出是直接往库里灌的。它生成一个标签，标签就写进去；它猜一个作者名，作者名就填上。中间没有核验层，因为大家都把模型当成一个还算可靠的数据源在用。
Kintara 不。它把模型当成一个不可靠的建议者，仅此而已。
这两道核验都不贵，费的是工程时间，不是 token。但它把一件事说清楚了：用户信不信这条引用，跟模型多聪明没关系，跟应用层肯不肯多查一遍有关系。
元数据那块是同一套逻辑：标题、作者、摘要、关键词、DOI、ISBN、出版年份，模型列一列，你自己勾了才写进表单。DOI 和 ISBN 这种字段，模型编错一位数，你的引用列表就废了。让它直接落库，那不叫智能，那叫给未来埋雷！
顺手说个容易被忽略的取舍。作者原本给项目套了个 Tauri 桌面外壳，做到一半发现不是自己想要的方向，把桌面层整个拆了，改成单个 Rust 服务器同时供 API 和前端。再把服务器指向 NAS 上的目录，台式机、笔记本、平板、手机开同一个库。
自托管的东西，做成桌面应用那一刻就走偏了。资料在 NAS 上，你为什么要在某一台机器上装个壳去够它。
这个决定和上面那套「模型只提建议」其实是同一个思维习惯：能自己否定的地方就否定。
AI 在这儿默认是关的，这点我也认。你不接 OpenAI，不接 Gemini，