LitSource 对比 CiteTrue

CiteTrue 最容易被理解为一个引文验证系统。用户提交参考文献后，该服务会将其拆分并搜索，结果会报告每条引文是真实、不确定、不真实还是无效。其公开材料强调为学生、作者、审稿人和编辑提供投稿前检查。当你需要审核的对象已经是一份参考文献列表时，这是一个清晰的匹配。

LitSource 也支持同样的后期完整性工作，但它还能在更早阶段发挥作用。研究人员可以在选择任何参考文献之前输入一句话、一个论断或一个综述问题。发现工作流会返回候选学术记录和可供研究人员检查的证据上下文。因此，当问题不只是“这条引文是真的吗？”，还包括“我应该评估哪篇真实论文来支持这个论断？”时，LitSource 很有用。

两种起点都没有普遍优劣。如果导师发给你一份有八十条参考文献的手稿，以引文为先的批量检查器会减少摩擦。如果你正在撰写文献综述的某个部分，其中有一句没有依据的陈述，那么验证一个尚不存在的列表没有帮助；你需要先进行发现。实际选择取决于你当前研究产物的状态，而不是营销表格中的功能数量。

CiteTrue 公开了两种验证深度。快速模式每条参考文献消耗 1 个额度，而 Deep Verify 会使用更广泛的搜索和更强的 AI 流程来处理困难案例，可能消耗 5 个额度。公开 API 文档还解释了结构化的评估值和提示，这对构建可重复的引文质检管道的团队很有用。因此，一条难以处理的文中引文或模糊参考文献可以被升级，而不是与显而易见的匹配得到同样的处理。

LitSource 强调可以让人独立检查的记录：标题、作者、期刊、年份、DOI、PMID 以及可用的底层学术目标链接。这一点很重要，因为存在性只是第一个信任问题。一篇真实文章仍可能被关联到错误的年份、作者列表或论断。展示身份字段和来源上下文能帮助研究人员诊断哪些地方不匹配，而不是把一个置信度标签当作最终答案。

两种工作流仍然存在人工边界。验证结果可以表明一篇论文存在且元数据一致，但它本身不能确定方法学质量，也不能证明该论文支持手稿中的每一句话。对于高风险的学术或临床工作，请打开原始记录，阅读相关章节，并在将任一产品的输出视为最终结果之前，记录该来源为何符合要求。

CiteTrue 的官方指南记录了建议的引文替换方法。当一条引文无法验证时，工作流可以查找与该引文所引论断相关的替代来源。这是一种合理的恢复模式：保留作者本来的陈述，同时替换看似伪造、不相关或无法确认的参考文献。在已有手稿文本的参考文献清理阶段尤其有用。

LitSource 将来源发现视为主要工作流，而不仅仅是修复步骤。用户可以提交研究问题、句子或段落，审阅候选论文，检查来源记录，然后决定哪些条目值得通读全文。在生物医学研究中，PubMed 和 PMID 感知路径使来源出处更加明确。返回的匹配项仍然只是筛选候选，但搜索可以在无需先编造或继承某条引文的情况下开始。

这一区别会影响评估方式。要测试 CiteTrue，请包含困难、格式错误和已知伪造的参考文献，并观察结果在解释每个结果或提出替换建议时的清晰程度。要测试 LitSource，请使用你自己学科领域中一个缺乏支持的主张，并检查候选论文是否可追溯且足够相关，值得进入候选清单。同时进行这两项测试，比比较“AI 驱动”等泛化标签更有信息量。

CiteTrue 发布了异常详细的集成文档。其 REST API 通过流式响应接受验证任务，其 MCP 服务器向兼容的助手开放引文检查功能。官方定价常见问题说明免费方案每天包含 30 次验证额度；一次快速验证使用 1 个额度，而 Deep Verification 使用更多额度。团队应在生产使用前查看官方页面，确认当前的配额、计费和数据处理的条款。

LitSource 的公开差异点在于从发现到验证的流程。同一位研究人员可以从一个论断开始，检查与学术来源相关的记录，保存或导出有用的候选条目，然后审计参考文献列表中的 DOI、PMID 和元数据不匹配。这种连续性可以减少文献综述或生物医学写作流程中的交接，尤其是在来源必须在产品界面之外具有可辩护性的时候。

因此，均衡的建议是基于任务的。如果需要一款专注的引文检查器，并具备 Deep Verify、替换指导和有文档的 API 或 MCP 访问，请选择 CiteTrue。当来源发现、面向 PubMed 的出处和引文真实性需要放在同一个闭环中时，请选择 LitSource。这两款产品相互独立，本页面未获 CiteTrue 认可，公开功能在审核日期后可能发生变化，因此在购买或集成前，请通过官方链接核实当前细节。