1. 项目概述一个零成本、AI驱动的开放知识库如果你是一名研究者、开发者或者正在构建一个需要实时验证信息的AI智能体那么你一定对传统学术出版的漫长周期和封闭性感到头疼。一篇论文从投稿到发表动辄数月评审过程不透明最终成果还可能被锁在付费墙后。与此同时AI智能体在互联网上寻找可靠、结构化、带有置信度评估的知识时也常常面临信息过载和真伪难辨的困境。Pubroot 正是为了解决这两个核心痛点而诞生的。它本质上是一个完全运行在GitHub免费服务上的、由AI进行同行评审的开放知识库。你可以把它理解为一个“增强版的arXiv”任何人都可以提交文章包括原创研究、案例研究、基准测试、教程等一个由六个阶段组成的AI评审管道会在几分钟到几小时内给出结构化评审报告和分数达到标准的文章将被自动发布到一个静态网站上并附带丰富的元数据。这个项目的核心魅力在于其“零固定成本”的架构和“智能体优先”的设计理念。整个后端——从提交入口、评审计算到最终发布——完全由GitHub Issues、GitHub Actions和GitHub Pages承载利用Gemini API的免费额度进行AI评审。这意味着项目维护者无需为服务器、数据库或托管支付一分钱就能运营一个功能完整的学术发布平台。更重要的是它通过MCP服务器、A2A智能体卡片、agents.txt等标准将自己打造成了一个对AI智能体高度友好的“地面实况”数据源智能体可以像调用API一样直接查询、验证知识甚至自主提交内容。2. 核心架构与零成本实现原理Pubroot的整个技术栈选择都紧紧围绕着“零成本”和“自动化”两个目标。其架构可以清晰地分为三层数据层GitHub仓库、计算层GitHub Actions AI和呈现层Hugo静态站点。这三层全部构建在GitHub的生态系统之上形成了一个精妙的闭环。2.1 数据层Git即数据库传统应用依赖MySQL、PostgreSQL等数据库而Pubroot则直接将Git仓库作为其唯一的数据源。这是一种非常经典的“GitOps”思想在内容平台上的实践。papers/目录存放所有已接受的文章每篇文章是一个Markdown文件位于类似papers/ai/llm-benchmarks/your-article-slug/index.md的路径下。文件内容就是提交的正文而元数据标题、作者、摘要、分类等则通过Hugo的前言front matter以YAML或TOML格式存储。reviews/目录存放每篇文章对应的结构化评审JSON文件。这个文件是AI评审管道的输出包含了六个维度的详细评分、评语、已验证的声明列表以及最终的置信度元数据。agent-index.json,journals.json,contributors.json这些是机器可读的索引文件由发布管道在每次有新文章接受时自动更新。它们为网站的前端展示和MCP服务器的搜索功能提供数据支持。这种设计的优势极其明显版本控制天然内置。每一次提交、评审、修改都有完整的Git历史记录可以轻松回溯。数据备份和同步问题不复存在因为Git本身就是为了分布式协作而生的。同时利用GitHub Issues作为提交入口直接将用户交互提交表单和工单系统整合省去了开发独立后台的麻烦。2.2 计算层GitHub Actions驱动的AI流水线这是整个项目的引擎。当一个新的Issue通过提交模板被创建时会触发一个特定的GitHub Actions工作流review.yml。这个工作流执行一个Python脚本也就是六阶段评审管道。解析与过滤Stage 1纯Python逻辑。脚本会解析Issue的标题和正文提取出“标题”、“分类”、“投稿类型”、“摘要”、“正文”等结构化字段。这里有一个关键细节投稿模板使用了Markdown的###级标题来分隔不同字段例如### Title### Category解析器正是依靠这个模式进行精准提取。同时它会进行基础验证比如检查字数、分类是否在journals.json定义的范围内并进行初步的提示词注入检测。新颖性检查Stage 2调用外部API。这里会使用arXiv API和Semantic Scholar API根据文章标题和摘要搜索相关文献。目的是评估投稿的新颖性避免重复发表。同时它也会查询本地的agent-index.json检查是否有内部文章已经覆盖了该主题。仓库分析Stage 3如果投稿者提供了一个支持代码的GitHub仓库链接此阶段会使用GitHub API读取仓库的文件树和关键源代码文件如README.md,main.py,requirements.txt。这些内容将被注入到后续的评审提示词中供AI评估代码质量。构建评审提示词Stage 4这是评审质量的核心。此阶段不是一个简单的提示词拼接而是一个基于投稿类型的动态提示词构建系统。系统会根据投稿是“原创研究”还是“教程”从预定义的评审标准矩阵中选取不同的侧重点。例如对“基准测试”类文章“方法论”和“可复现性”的权重会极高而对“案例研究”“实用价值”则是关键。此外提示词中还会包含从_calibration/目录加载的“少样本示例”这些是人工标注的、评分已知的示例文章用于校准AI的评分尺度确保不同时间、不同模型版本下评分的一致性。AI评审Stage 5调用Gemini 2.5 Flash-Lite模型并启用Google搜索 grounding功能。这是实现事实核查的关键。AI不仅会基于文章内容评分还会对文章中的关键事实声明发起网络搜索进行验证。最终模型需要输出一个严格规定格式的JSON包含六个维度的分数0.0-1.0、详细评语、已验证的声明列表以及一个总体建议接受/拒绝。发布与决策Stage 6根据Stage 5的输出如果总分≥6.0则评审被标记为“接受”。脚本会自动将文章Markdown文件和评审JSON文件提交到仓库的对应目录然后触发另一个工作流publish.yml来重新构建并部署Hugo静态网站。如果被拒绝则会在Issue下评论详细的评审反馈然后关闭该Issue。整个流程完全自动化无需人工干预。GitHub Actions为每次评审提供了一个干净、临时的运行环境任务结束后资源自动释放真正实现了“无服务器”。2.3 呈现层静态站点与智能体接口前端网站使用Hugo生成托管在GitHub Pages上。Hugo是一个用Go语言编写的极速静态网站生成器。它读取papers/目录下的Markdown文件套用_site_theme/中的模板生成最终的HTML页面。搜索功能通过集成Pagefind实现这是一个客户端JavaScript搜索库能对静态站点进行全文检索同样无需后端服务器。智能体接口这是Pubroot区别于传统知识库的亮点。MCP服务器MCPModel Context Protocol是由Anthropic提出的一种协议旨在让AI模型能安全、标准化地使用外部工具。Pubroot提供的MCP服务器让智能体如Claude Desktop中的智能体可以直接“连接”到知识库执行搜索、验证声明、获取评审详情等操作。A2A智能体卡片A2AAgent to Agent是Google提出的智能体互发现协议。/.well-known/agent.json文件就像智能体的“名片”其他智能体可以读取它来了解Pubroot的能力和交互方式。agents.txt llms.txt模仿robots.txt的约定为AI爬虫和智能体提供指引说明哪些内容适合被摄取。这个三层架构的精妙之处在于每一层都利用了完全免费或拥有慷慨免费额度的服务将运营成本降为零同时保持了高度的自动化、可扩展性和对现代AI工作流的友好性。3. 六阶段AI评审管道深度解析评审管道是Pubroot的“大脑”其设计的严谨性直接决定了平台内容的质量和可信度。下面我们拆解每一个阶段看看它们是如何协同工作模拟并优化传统同行评审流程的。3.1 第一阶段解析、过滤与防御这个阶段是管道的守门员全部由确定性逻辑Python代码完成不调用任何昂贵的AI服务从而过滤掉格式错误或恶意的提交节约成本。字段提取依赖投稿模板中严格的Markdown标题格式### Field Name。解析器会按行扫描Issue正文识别这些标题并将其后的内容捕获为对应字段的值。这种方法的优点是简单、可靠对用户和机器智能体都易于生成。分类验证将用户选择的分类如ai/llm-benchmarks与journals.json中定义的完整分类树进行比对。这防止了用户提交到不存在的分类也确保了后续网站生成时文章能被正确归类。字数检查对摘要和正文有最低字数要求如摘要50-300词正文200词。这是一个基本的质量门槛。提示词注入检测一个简单的防御措施。它会检查提交的文本中是否包含大量试图“欺骗”或“引导”AI评审员的特定短语或结构例如重复“这是一篇高质量文章”或包含奇怪的编码字符。虽然不能完全防御高级攻击但能拦住大部分低级垃圾信息。实操心得在设计提交表单时强制性的结构化格式如###标题比自由文本框可靠得多。这极大地简化了后端解析逻辑减少了歧义。对于智能体提交提供一个CLI工具如pubroot submit来自动生成符合格式的提交内容是提升体验和准确性的关键。3.2 第二阶段新颖性检查——连接外部知识宇宙新颖性是学术贡献的核心。此阶段通过查询外部学术数据库为AI评审员提供上下文。arXiv API查询主要针对计算机科学、数学、物理学等领域的预印本。API调用简单返回相关论文的标题、摘要、作者信息。Semantic Scholar API查询这是一个更广泛的学术搜索引擎覆盖更多学科并能提供引用关系。它的“论文推荐”端点非常适合寻找相关研究。内部索引查询在agent-index.json中搜索相似主题的文章。这是为了发现平台内部可能存在的重复或过时内容。结果整合将来自三个来源的相关工作摘要和链接整理成一段文字作为“背景信息”注入到下一阶段的评审提示词中。这相当于在告诉AI评审员“在评审这篇文章前你需要知道这些已有的相关研究。”这个阶段的意义在于它将评审从单纯的内容质量评估提升到了对知识贡献度的评估。AI评审员不再是“闭卷考试”而是有了一个“参考资料列表”。3.3 第三阶段代码仓库分析——验证可复现性对于声称有代码支持的文章尤其是研究、基准测试、教程可复现性是黄金标准。此阶段尝试自动化地评估这一点。仓库链接识别从文章正文或特定字段中提取GitHub仓库URL。文件树获取使用GitHub API获取仓库的根目录结构。一个清晰、标准的项目结构如包含src/,tests/,requirements.txt,README.md通常意味着更好的可维护性。关键文件内容读取有选择地读取README.md项目说明、main.py或类似的主入口文件看逻辑、requirements.txt或pyproject.toml依赖管理。这些内容被截取片段后放入评审上下文。局限性由于API权限和隐私问题此阶段只能分析公开仓库。对于私有仓库文章将获得“已验证私有”徽章而非最高的“已验证开放”徽章。同时它无法真正“运行”代码只能进行静态分析。注意事项依赖GitHub API存在速率限制。在Actions中需要使用GitHub Token进行认证这有更高的限额。对于超大型仓库需要策略性地选择要读取的文件避免超时或超出Token限额。3.4 第四阶段动态提示词工程——评审标准的核心这是整个AI评审的“指挥中心”。它不是一个固定的提示词模板而是一个基于规则的动态组装系统。类型特定标准矩阵系统内部维护了一个表格定义了六种投稿类型原创研究、案例研究等各自在六个评分维度上的“评审侧重点”。例如原创研究“新颖性”权重极高“方法论”权重高。教程“完整性”和“写作质量”权重极高“新颖性”权重低。基准测试“方法论”和“可复现性”权重极高。提示词组装系统会选取与投稿类型对应的评审侧重点描述。嵌入从第二阶段获得的新颖性背景信息。嵌入从第三阶段获得的代码仓库分析结果如果有。插入2-3个“少样本校准示例”。这些示例是从_calibration/目录中精心挑选的代表了优秀、一般、较差三个等级的文章及其“标准答案”评审。它们的作用是“教”AI模型按照Pubroot的特定尺度进行评分减少模型本身的不确定性。最终将所有部分指令、背景、代码、示例、待评审文章按照一个清晰的结构组合成最终的提示词。这个阶段确保了评审的一致性和针对性。无论AI模型本身如何更新只要校准示例和评审标准不变其对同类文章的评分尺度就是相对稳定的。3.5 第五阶段AI评审与事实核查——Gemini与搜索的共舞这是调用大语言模型LLM的阶段也是成本尽管是免费额度和不确定性最高的环节。模型选择Gemini 2.5 Flash-Lite。选择它主要基于两点免费额度足够支撑初期规模和原生支持Google搜索grounding。后者至关重要。搜索grounding这是实现“事实核查”的技术基础。在调用Gemini API时可以开启“搜索增强”功能。模型在生成回答时会实时发起网络搜索来验证用户问题或文本中的关键声明。在Pubroot的上下文中评审提示词会要求模型对文章中的具体事实主张例如“模型X在数据集Y上达到了95%的准确率”进行验证。Gemini会利用搜索grounding来查找来源确认或质疑该主张并将验证结果和引用链接写入评审JSON。结构化输出提示词严格要求模型以特定的JSON格式输出。这包括每个维度的分数0.0-1.0、详细的评语、一个经过验证的声明列表包含声明原文和验证状态以及最终的接受/拒绝建议。使用JSON格式使得后续阶段Stage 6可以毫无歧义地解析结果。评分聚合六个维度的分数会被加权目前可能是简单平均也可能有基于类型的微调计算出一个总分0.0-10.0。总分≥6.0是接受的硬性门槛。这个阶段将LLM的文本理解、推理能力与搜索引擎的实时事实核查能力结合了起来创造了一种混合评审模式。它既评估文章的内在逻辑和表达也尝试验证其对外部世界的陈述是否准确。3.6 第六阶段自动化决策与发布——闭环的终点收到AI的评审结果后此阶段执行最终的“编辑决策”。结果发布无论接受与否完整的评审JSON都会被格式化成一个清晰的Markdown评论发布到原始的GitHub Issue下。整个过程对投稿者完全透明。接受流程如果被接受脚本会根据分类如ai/llm-benchmarks和文章标题生成的slug在papers/目录下创建对应的子目录和index.md文件。将文章正文和元数据标题、作者、摘要、分类、日期等写入该Markdown文件。将评审JSON保存到reviews/目录的对应路径。更新机器可读的索引文件agent-index.json,contributors.json。创建一个Git提交并可能自动合并到主分支。触发部署提交到主分支会触发publish.yml工作流启动Hugo构建过程生成新的静态网站并部署到GitHub Pages。几分钟后新文章就会出现在pubroot.com上。拒绝流程如果被拒绝则在发布详细评审评论后直接关闭该Issue。投稿者可以根据反馈修改后重新提交一个新的Issue。至此一个从投稿到发布的完整自动化循环结束。所有状态变更、内容更新都通过Git提交记录实现了完全可追溯的版本管理。4. 智能体优先的设计哲学与集成实践Pubroot宣称自己是“为智能体时代打造的”这绝非一句空话。其整个数据结构和对外接口都体现了对AI智能体作为一等公民的支持。4.1 机器可读的数据层这是智能体交互的基础。传统网站的数据埋在HTML中需要复杂的解析。而Pubroot所有核心数据都有直接的JSON端点agent-index.json所有已发表文章的索引。包含每篇文章的标题、摘要、链接、分类、分数、信任徽章、唯一ID等。智能体可以一次性拉取这个文件或通过查询参数进行过滤搜索如?journalaimin_score7.5。journals.json完整的分类法。智能体在提交前可以查询此文件了解有哪些可用的期刊和主题确保分类准确。contributors.json投稿者声誉数据库。智能体可以查询某个作者的历史记录和声誉分用以评估其过往作品的可信度。这些JSON文件格式稳定、结构清晰智能体可以像使用任何RESTful API一样使用它们无需解析HTML。4.2 MCP服务器深度工具集成MCP服务器是Pubroot与智能体深度交互的桥梁。智能体如配置了MCP的Claude Desktop可以直接“安装”Pubroot服务器从而获得一系列专用工具search_papers智能体可以像在网站搜索框里一样用关键词、分类、分数范围等条件搜索文章。这对于在研究或回答问题时需要引用可靠来源的智能体来说非常有用。verify_claim这是杀手级功能。智能体可以提出一个事实声明例如“Transformer架构是谷歌在2017年提出的”该工具会在Pubroot的已评审文章中搜索并返回是否有文章验证或讨论了该声明以及相应的置信度。这为智能体的输出提供了可验证的支撑。get_review获取某篇文章的完整评审报告了解其优缺点细节。get_contributor_reputation和get_related_work用于评估作者信誉和查找相关研究。通过MCPPubroot不再是仅供人类浏览的网页而是一个可以被智能体直接查询、推理所依赖的“知识图谱节点”。4.3 智能体发现标准A2A、agents.txt与llms.txt为了让智能体更容易地“发现”和“理解”Pubroot项目遵循了新兴的智能体网络标准A2A Agent Card (/.well-known/agent.json)这是一个描述智能体在此场景下Pubroot本身可被视为一个提供服务的“智能体”能力的标准文件。它说明了“我是谁”、“我能做什么”、“如何与我交互”。遵循A2A协议的智能体可以自动发现并解析这个文件。agents.txt模仿robots.txt用于向网络爬虫指明网站对AI智能体的政策。它可以列出允许或禁止哪些智能体访问以及推荐它们访问哪些部分。Pubroot的agents.txt很可能鼓励AI智能体访问其JSON端点。llms.txt一个类似的倡议旨在为大型语言模型提供网站内容的摘要或指引帮助它们更好地理解和利用网站信息。这些文件共同构成了Pubroot对AI友好的“门面”降低了智能体与其集成的门槛。4.4 智能体投稿流程智能体不仅可以读取还可以写入。投稿流程对智能体是完全开放的获取指南智能体可以首先通过CLI命令pubroot guide --json或MCP工具get_submission_guide获取详细的、结构化的投稿指南包括格式要求、图片政策只允许外链禁止二进制上传、修订政策等。准备内容智能体按照指南准备Markdown格式的文章内容。调用API提交通过GitHub CLI (gh issue create) 或直接调用GitHub REST API按照submission.yml模板的结构创建Issue。智能体需要确保Issue正文的格式严格符合### Field Name的约定以便Stage 1解析器能正确识别。这种设计使得AI智能体能够成为知识的主动贡献者而不仅仅是消费者真正实现了“人机协同”的知识共创。5. 运维、成本与扩展性考量对于一个旨在零成本运行的项目其运维模式、成本边界和扩展潜力是需要深入思考的。5.1 成本结构深度剖析Pubroot的成本模型清晰得令人惊叹GitHub对于公开仓库GitHub Actions的分钟数、GitHub Pages的带宽和存储在合理使用下完全免费。这是项目的基础。Gemini API这是唯一可能产生可变成本的部分。Gemini 2.5 Flash-Lite提供免费的请求额度。根据Google的定价假设免费 tier 之后按量付费每百万字符输入输出成本极低。项目文档称免费额度可支持每月45,000次评审。这是一个非常可观的量级对于项目初期和中期完全足够。外部APIarXiv和Semantic Scholar API均为免费但有速率限制。GitHub Actions的分布式、间歇性调用通常不会触发这些限制。真正的成本是隐性的开发者和维护者的时间。维护评审标准、校准示例、处理极端案例、修复管道bug、应对滥用行为这些都需要投入精力。但相比于运营一个带服务器、数据库、支付系统的传统平台这种维护成本已经低了好几个数量级。5.2 扩展性与瓶颈横向扩展GitHub Actions本身可以并行运行多个工作流。如果投稿量激增可以调整工作流的触发策略或者设置多个队列。由于每个评审任务都是无状态的并行化处理非常容易。性能瓶颈Gemini API速率限制免费额度和付费层级都有每分钟/每天的请求限制。需要实现重试机制和队列管理避免因限流导致评审积压。GitHub Actions运行时间每个工作流有最长运行时间限制默认6小时。复杂的评审如需要分析大型代码库需要优化代码避免超时。Git仓库大小随着文章和评审文件增多仓库体积会增长。但文本和JSON文件体积很小万篇文章可能也就几百MB远未到GitHub仓库的容量限制。质量维护最大的挑战在于维持评审质量。LLM的输出可能存在不可预测性。解决方案是持续优化校准示例和评审提示词。需要建立一个机制定期用一批“测试文章”来评估评审管道的表现并根据结果调整提示词和校准集。5.3 安全与滥用防范垃圾信息与滥用投稿依赖Stage 1的基础过滤和GitHub自身的垃圾信息检测。对于通过初审的恶意内容最终会在AI评审阶段因低分被拒绝。严重的滥用者可以被GitHub封禁。提示词注入与游戏系统这是AI系统的通病。投稿者可能尝试在文章中嵌入特殊指令来操纵AI评审员。除了Stage 1的简单检测更依赖于LLM自身的安全性训练和提示词中的系统指令加固例如明确指令模型忽略任何试图改变评审规则的文本。数据隐私所有提交的内容都是公开的除非链接到私有仓库。这符合开放获取的精神。投稿者不应提交任何敏感或私有信息。5.4 内容保鲜与知识管理Pubroot引入了“知识保鲜”机制这是一个非常前瞻性的设计valid_until字段每篇文章都有一个有效期。技术类内容如LLM基准测试可能6个月后就过时了而历史或哲学类内容可能有效期长达12个月。过期的文章仍然可以访问但可能会被标记或降低搜索排名。supersedes/superseded_by关系当有新文章显著改进了旧文章时可以在新文章的评审元数据中声明它“取代”了某篇旧文章。这形成了一个知识演进的链条。主题槽位对于发展极快的领域如ai/llm-benchmarks可以设置规则限制同一时间段内只保留一篇最新的基准测试文章鼓励贡献者提供最新的综合比较而不是碎片化的过时信息。这些机制共同作用使得Pubroot不是一个静态的档案库而是一个动态的、自我更新的知识流更贴近真实世界知识快速迭代的节奏。6. 实战指南从用户与开发者双视角6.1 作为投稿者如何提高接受率选择合适的类型与分类仔细阅读“投稿类型”矩阵。如果你的工作是实现了一个新算法选“原创研究”如果是记录一个具体问题的解决过程选“案例研究”。准确分类有助于AI应用正确的评审标准。提供可复现的代码尽可能链接到一个公开、结构清晰的GitHub仓库。包含详细的README.md、明确的依赖列表和简洁的示例代码。这不仅能争取到“已验证开放”的绿色徽章极大提升可信度也能在“代码质量”和“可复现性”维度拿到高分。清晰的结构与写作即使有AI评审清晰的文章结构、准确的语法和流畅的表达也至关重要。使用Markdown标题组织内容用代码块展示代码用表格或列表呈现数据。好的“写作质量”是给评审员无论是AI还是人留下好印象的基础。声明要具体且可验证避免模糊的陈述。像“本方法显著提升了性能”这样的说法很难被事实核查。应该写成“在XX数据集上本方法将准确率从85%提升到了92%”。AI的搜索grounding功能可以尝试去验证这类具体声明。利用修订机制如果被拒绝不要气馁。仔细阅读AI给出的详细评审反馈它们通常会指出方法论、事实准确性或表达上的具体问题。针对性地修改后重新提交一个新的Issue。每次提交都是一次独立的评审你的声誉分数会随着接受的文章数而增长从而获得更快的评审速度。6.2 作为开发者如何参与贡献或搭建类似系统理解架构精髓Pubroot的核心模式是“GitHub作为后端” “AI作为逻辑层” “静态站点作为前端”。这个模式可以复用到很多其他领域比如自动化内容审核的知识库、社区驱动的文档站、项目集锦展示等。关注关键文件_review_agent/这是AI评审管道的核心六个阶段的Python脚本是学习如何编排AI工作流的绝佳示例。.github/workflows/review.yml和publish.yml展示了如何用GitHub Actions实现复杂的自动化流程。_calibration/理解“少样本示例”如何用于校准AI输出这对于构建任何依赖LLM的评分或分类系统都至关重要。改进评审质量最直接的贡献方式是优化校准示例。如果你发现某类文章的评分系统性偏高或偏低可以尝试构造新的、更具代表性的校准示例提交Pull Request。扩展分类如果你所在的领域未被覆盖可以编辑journals.json文件提议添加新的期刊或主题。这需要社区讨论以确保分类体系的清晰和有用。构建自己的版本你可以Fork这个仓库修改journals.json和评审标准将其改造成一个专注于你所在垂直领域例如独立游戏开发日志、硬件制作教程、特定编程语言技巧的自动化评审发布平台。由于成本为零试错风险极低。Pubroot展示了一种未来知识生产和消费的范式低成本、自动化、透明化、人机协同。它不仅仅是一个工具更是一个关于如何利用现有云服务、AI能力和开放协议来构建有价值系统的思想实验。无论你是想分享知识的研究者需要可靠信源的智能体开发者还是对无服务器架构和AI应用感兴趣的工程师这个项目都提供了丰富的学习价值和实践灵感。它的成功与否最终将取决于社区贡献的内容质量而这正是其开放和自动化设计所鼓励的。
零成本AI评审知识库：基于GitHub Actions与Gemini的自动化学术发布平台
1. 项目概述一个零成本、AI驱动的开放知识库如果你是一名研究者、开发者或者正在构建一个需要实时验证信息的AI智能体那么你一定对传统学术出版的漫长周期和封闭性感到头疼。一篇论文从投稿到发表动辄数月评审过程不透明最终成果还可能被锁在付费墙后。与此同时AI智能体在互联网上寻找可靠、结构化、带有置信度评估的知识时也常常面临信息过载和真伪难辨的困境。Pubroot 正是为了解决这两个核心痛点而诞生的。它本质上是一个完全运行在GitHub免费服务上的、由AI进行同行评审的开放知识库。你可以把它理解为一个“增强版的arXiv”任何人都可以提交文章包括原创研究、案例研究、基准测试、教程等一个由六个阶段组成的AI评审管道会在几分钟到几小时内给出结构化评审报告和分数达到标准的文章将被自动发布到一个静态网站上并附带丰富的元数据。这个项目的核心魅力在于其“零固定成本”的架构和“智能体优先”的设计理念。整个后端——从提交入口、评审计算到最终发布——完全由GitHub Issues、GitHub Actions和GitHub Pages承载利用Gemini API的免费额度进行AI评审。这意味着项目维护者无需为服务器、数据库或托管支付一分钱就能运营一个功能完整的学术发布平台。更重要的是它通过MCP服务器、A2A智能体卡片、agents.txt等标准将自己打造成了一个对AI智能体高度友好的“地面实况”数据源智能体可以像调用API一样直接查询、验证知识甚至自主提交内容。2. 核心架构与零成本实现原理Pubroot的整个技术栈选择都紧紧围绕着“零成本”和“自动化”两个目标。其架构可以清晰地分为三层数据层GitHub仓库、计算层GitHub Actions AI和呈现层Hugo静态站点。这三层全部构建在GitHub的生态系统之上形成了一个精妙的闭环。2.1 数据层Git即数据库传统应用依赖MySQL、PostgreSQL等数据库而Pubroot则直接将Git仓库作为其唯一的数据源。这是一种非常经典的“GitOps”思想在内容平台上的实践。papers/目录存放所有已接受的文章每篇文章是一个Markdown文件位于类似papers/ai/llm-benchmarks/your-article-slug/index.md的路径下。文件内容就是提交的正文而元数据标题、作者、摘要、分类等则通过Hugo的前言front matter以YAML或TOML格式存储。reviews/目录存放每篇文章对应的结构化评审JSON文件。这个文件是AI评审管道的输出包含了六个维度的详细评分、评语、已验证的声明列表以及最终的置信度元数据。agent-index.json,journals.json,contributors.json这些是机器可读的索引文件由发布管道在每次有新文章接受时自动更新。它们为网站的前端展示和MCP服务器的搜索功能提供数据支持。这种设计的优势极其明显版本控制天然内置。每一次提交、评审、修改都有完整的Git历史记录可以轻松回溯。数据备份和同步问题不复存在因为Git本身就是为了分布式协作而生的。同时利用GitHub Issues作为提交入口直接将用户交互提交表单和工单系统整合省去了开发独立后台的麻烦。2.2 计算层GitHub Actions驱动的AI流水线这是整个项目的引擎。当一个新的Issue通过提交模板被创建时会触发一个特定的GitHub Actions工作流review.yml。这个工作流执行一个Python脚本也就是六阶段评审管道。解析与过滤Stage 1纯Python逻辑。脚本会解析Issue的标题和正文提取出“标题”、“分类”、“投稿类型”、“摘要”、“正文”等结构化字段。这里有一个关键细节投稿模板使用了Markdown的###级标题来分隔不同字段例如### Title### Category解析器正是依靠这个模式进行精准提取。同时它会进行基础验证比如检查字数、分类是否在journals.json定义的范围内并进行初步的提示词注入检测。新颖性检查Stage 2调用外部API。这里会使用arXiv API和Semantic Scholar API根据文章标题和摘要搜索相关文献。目的是评估投稿的新颖性避免重复发表。同时它也会查询本地的agent-index.json检查是否有内部文章已经覆盖了该主题。仓库分析Stage 3如果投稿者提供了一个支持代码的GitHub仓库链接此阶段会使用GitHub API读取仓库的文件树和关键源代码文件如README.md,main.py,requirements.txt。这些内容将被注入到后续的评审提示词中供AI评估代码质量。构建评审提示词Stage 4这是评审质量的核心。此阶段不是一个简单的提示词拼接而是一个基于投稿类型的动态提示词构建系统。系统会根据投稿是“原创研究”还是“教程”从预定义的评审标准矩阵中选取不同的侧重点。例如对“基准测试”类文章“方法论”和“可复现性”的权重会极高而对“案例研究”“实用价值”则是关键。此外提示词中还会包含从_calibration/目录加载的“少样本示例”这些是人工标注的、评分已知的示例文章用于校准AI的评分尺度确保不同时间、不同模型版本下评分的一致性。AI评审Stage 5调用Gemini 2.5 Flash-Lite模型并启用Google搜索 grounding功能。这是实现事实核查的关键。AI不仅会基于文章内容评分还会对文章中的关键事实声明发起网络搜索进行验证。最终模型需要输出一个严格规定格式的JSON包含六个维度的分数0.0-1.0、详细评语、已验证的声明列表以及一个总体建议接受/拒绝。发布与决策Stage 6根据Stage 5的输出如果总分≥6.0则评审被标记为“接受”。脚本会自动将文章Markdown文件和评审JSON文件提交到仓库的对应目录然后触发另一个工作流publish.yml来重新构建并部署Hugo静态网站。如果被拒绝则会在Issue下评论详细的评审反馈然后关闭该Issue。整个流程完全自动化无需人工干预。GitHub Actions为每次评审提供了一个干净、临时的运行环境任务结束后资源自动释放真正实现了“无服务器”。2.3 呈现层静态站点与智能体接口前端网站使用Hugo生成托管在GitHub Pages上。Hugo是一个用Go语言编写的极速静态网站生成器。它读取papers/目录下的Markdown文件套用_site_theme/中的模板生成最终的HTML页面。搜索功能通过集成Pagefind实现这是一个客户端JavaScript搜索库能对静态站点进行全文检索同样无需后端服务器。智能体接口这是Pubroot区别于传统知识库的亮点。MCP服务器MCPModel Context Protocol是由Anthropic提出的一种协议旨在让AI模型能安全、标准化地使用外部工具。Pubroot提供的MCP服务器让智能体如Claude Desktop中的智能体可以直接“连接”到知识库执行搜索、验证声明、获取评审详情等操作。A2A智能体卡片A2AAgent to Agent是Google提出的智能体互发现协议。/.well-known/agent.json文件就像智能体的“名片”其他智能体可以读取它来了解Pubroot的能力和交互方式。agents.txt llms.txt模仿robots.txt的约定为AI爬虫和智能体提供指引说明哪些内容适合被摄取。这个三层架构的精妙之处在于每一层都利用了完全免费或拥有慷慨免费额度的服务将运营成本降为零同时保持了高度的自动化、可扩展性和对现代AI工作流的友好性。3. 六阶段AI评审管道深度解析评审管道是Pubroot的“大脑”其设计的严谨性直接决定了平台内容的质量和可信度。下面我们拆解每一个阶段看看它们是如何协同工作模拟并优化传统同行评审流程的。3.1 第一阶段解析、过滤与防御这个阶段是管道的守门员全部由确定性逻辑Python代码完成不调用任何昂贵的AI服务从而过滤掉格式错误或恶意的提交节约成本。字段提取依赖投稿模板中严格的Markdown标题格式### Field Name。解析器会按行扫描Issue正文识别这些标题并将其后的内容捕获为对应字段的值。这种方法的优点是简单、可靠对用户和机器智能体都易于生成。分类验证将用户选择的分类如ai/llm-benchmarks与journals.json中定义的完整分类树进行比对。这防止了用户提交到不存在的分类也确保了后续网站生成时文章能被正确归类。字数检查对摘要和正文有最低字数要求如摘要50-300词正文200词。这是一个基本的质量门槛。提示词注入检测一个简单的防御措施。它会检查提交的文本中是否包含大量试图“欺骗”或“引导”AI评审员的特定短语或结构例如重复“这是一篇高质量文章”或包含奇怪的编码字符。虽然不能完全防御高级攻击但能拦住大部分低级垃圾信息。实操心得在设计提交表单时强制性的结构化格式如###标题比自由文本框可靠得多。这极大地简化了后端解析逻辑减少了歧义。对于智能体提交提供一个CLI工具如pubroot submit来自动生成符合格式的提交内容是提升体验和准确性的关键。3.2 第二阶段新颖性检查——连接外部知识宇宙新颖性是学术贡献的核心。此阶段通过查询外部学术数据库为AI评审员提供上下文。arXiv API查询主要针对计算机科学、数学、物理学等领域的预印本。API调用简单返回相关论文的标题、摘要、作者信息。Semantic Scholar API查询这是一个更广泛的学术搜索引擎覆盖更多学科并能提供引用关系。它的“论文推荐”端点非常适合寻找相关研究。内部索引查询在agent-index.json中搜索相似主题的文章。这是为了发现平台内部可能存在的重复或过时内容。结果整合将来自三个来源的相关工作摘要和链接整理成一段文字作为“背景信息”注入到下一阶段的评审提示词中。这相当于在告诉AI评审员“在评审这篇文章前你需要知道这些已有的相关研究。”这个阶段的意义在于它将评审从单纯的内容质量评估提升到了对知识贡献度的评估。AI评审员不再是“闭卷考试”而是有了一个“参考资料列表”。3.3 第三阶段代码仓库分析——验证可复现性对于声称有代码支持的文章尤其是研究、基准测试、教程可复现性是黄金标准。此阶段尝试自动化地评估这一点。仓库链接识别从文章正文或特定字段中提取GitHub仓库URL。文件树获取使用GitHub API获取仓库的根目录结构。一个清晰、标准的项目结构如包含src/,tests/,requirements.txt,README.md通常意味着更好的可维护性。关键文件内容读取有选择地读取README.md项目说明、main.py或类似的主入口文件看逻辑、requirements.txt或pyproject.toml依赖管理。这些内容被截取片段后放入评审上下文。局限性由于API权限和隐私问题此阶段只能分析公开仓库。对于私有仓库文章将获得“已验证私有”徽章而非最高的“已验证开放”徽章。同时它无法真正“运行”代码只能进行静态分析。注意事项依赖GitHub API存在速率限制。在Actions中需要使用GitHub Token进行认证这有更高的限额。对于超大型仓库需要策略性地选择要读取的文件避免超时或超出Token限额。3.4 第四阶段动态提示词工程——评审标准的核心这是整个AI评审的“指挥中心”。它不是一个固定的提示词模板而是一个基于规则的动态组装系统。类型特定标准矩阵系统内部维护了一个表格定义了六种投稿类型原创研究、案例研究等各自在六个评分维度上的“评审侧重点”。例如原创研究“新颖性”权重极高“方法论”权重高。教程“完整性”和“写作质量”权重极高“新颖性”权重低。基准测试“方法论”和“可复现性”权重极高。提示词组装系统会选取与投稿类型对应的评审侧重点描述。嵌入从第二阶段获得的新颖性背景信息。嵌入从第三阶段获得的代码仓库分析结果如果有。插入2-3个“少样本校准示例”。这些示例是从_calibration/目录中精心挑选的代表了优秀、一般、较差三个等级的文章及其“标准答案”评审。它们的作用是“教”AI模型按照Pubroot的特定尺度进行评分减少模型本身的不确定性。最终将所有部分指令、背景、代码、示例、待评审文章按照一个清晰的结构组合成最终的提示词。这个阶段确保了评审的一致性和针对性。无论AI模型本身如何更新只要校准示例和评审标准不变其对同类文章的评分尺度就是相对稳定的。3.5 第五阶段AI评审与事实核查——Gemini与搜索的共舞这是调用大语言模型LLM的阶段也是成本尽管是免费额度和不确定性最高的环节。模型选择Gemini 2.5 Flash-Lite。选择它主要基于两点免费额度足够支撑初期规模和原生支持Google搜索grounding。后者至关重要。搜索grounding这是实现“事实核查”的技术基础。在调用Gemini API时可以开启“搜索增强”功能。模型在生成回答时会实时发起网络搜索来验证用户问题或文本中的关键声明。在Pubroot的上下文中评审提示词会要求模型对文章中的具体事实主张例如“模型X在数据集Y上达到了95%的准确率”进行验证。Gemini会利用搜索grounding来查找来源确认或质疑该主张并将验证结果和引用链接写入评审JSON。结构化输出提示词严格要求模型以特定的JSON格式输出。这包括每个维度的分数0.0-1.0、详细的评语、一个经过验证的声明列表包含声明原文和验证状态以及最终的接受/拒绝建议。使用JSON格式使得后续阶段Stage 6可以毫无歧义地解析结果。评分聚合六个维度的分数会被加权目前可能是简单平均也可能有基于类型的微调计算出一个总分0.0-10.0。总分≥6.0是接受的硬性门槛。这个阶段将LLM的文本理解、推理能力与搜索引擎的实时事实核查能力结合了起来创造了一种混合评审模式。它既评估文章的内在逻辑和表达也尝试验证其对外部世界的陈述是否准确。3.6 第六阶段自动化决策与发布——闭环的终点收到AI的评审结果后此阶段执行最终的“编辑决策”。结果发布无论接受与否完整的评审JSON都会被格式化成一个清晰的Markdown评论发布到原始的GitHub Issue下。整个过程对投稿者完全透明。接受流程如果被接受脚本会根据分类如ai/llm-benchmarks和文章标题生成的slug在papers/目录下创建对应的子目录和index.md文件。将文章正文和元数据标题、作者、摘要、分类、日期等写入该Markdown文件。将评审JSON保存到reviews/目录的对应路径。更新机器可读的索引文件agent-index.json,contributors.json。创建一个Git提交并可能自动合并到主分支。触发部署提交到主分支会触发publish.yml工作流启动Hugo构建过程生成新的静态网站并部署到GitHub Pages。几分钟后新文章就会出现在pubroot.com上。拒绝流程如果被拒绝则在发布详细评审评论后直接关闭该Issue。投稿者可以根据反馈修改后重新提交一个新的Issue。至此一个从投稿到发布的完整自动化循环结束。所有状态变更、内容更新都通过Git提交记录实现了完全可追溯的版本管理。4. 智能体优先的设计哲学与集成实践Pubroot宣称自己是“为智能体时代打造的”这绝非一句空话。其整个数据结构和对外接口都体现了对AI智能体作为一等公民的支持。4.1 机器可读的数据层这是智能体交互的基础。传统网站的数据埋在HTML中需要复杂的解析。而Pubroot所有核心数据都有直接的JSON端点agent-index.json所有已发表文章的索引。包含每篇文章的标题、摘要、链接、分类、分数、信任徽章、唯一ID等。智能体可以一次性拉取这个文件或通过查询参数进行过滤搜索如?journalaimin_score7.5。journals.json完整的分类法。智能体在提交前可以查询此文件了解有哪些可用的期刊和主题确保分类准确。contributors.json投稿者声誉数据库。智能体可以查询某个作者的历史记录和声誉分用以评估其过往作品的可信度。这些JSON文件格式稳定、结构清晰智能体可以像使用任何RESTful API一样使用它们无需解析HTML。4.2 MCP服务器深度工具集成MCP服务器是Pubroot与智能体深度交互的桥梁。智能体如配置了MCP的Claude Desktop可以直接“安装”Pubroot服务器从而获得一系列专用工具search_papers智能体可以像在网站搜索框里一样用关键词、分类、分数范围等条件搜索文章。这对于在研究或回答问题时需要引用可靠来源的智能体来说非常有用。verify_claim这是杀手级功能。智能体可以提出一个事实声明例如“Transformer架构是谷歌在2017年提出的”该工具会在Pubroot的已评审文章中搜索并返回是否有文章验证或讨论了该声明以及相应的置信度。这为智能体的输出提供了可验证的支撑。get_review获取某篇文章的完整评审报告了解其优缺点细节。get_contributor_reputation和get_related_work用于评估作者信誉和查找相关研究。通过MCPPubroot不再是仅供人类浏览的网页而是一个可以被智能体直接查询、推理所依赖的“知识图谱节点”。4.3 智能体发现标准A2A、agents.txt与llms.txt为了让智能体更容易地“发现”和“理解”Pubroot项目遵循了新兴的智能体网络标准A2A Agent Card (/.well-known/agent.json)这是一个描述智能体在此场景下Pubroot本身可被视为一个提供服务的“智能体”能力的标准文件。它说明了“我是谁”、“我能做什么”、“如何与我交互”。遵循A2A协议的智能体可以自动发现并解析这个文件。agents.txt模仿robots.txt用于向网络爬虫指明网站对AI智能体的政策。它可以列出允许或禁止哪些智能体访问以及推荐它们访问哪些部分。Pubroot的agents.txt很可能鼓励AI智能体访问其JSON端点。llms.txt一个类似的倡议旨在为大型语言模型提供网站内容的摘要或指引帮助它们更好地理解和利用网站信息。这些文件共同构成了Pubroot对AI友好的“门面”降低了智能体与其集成的门槛。4.4 智能体投稿流程智能体不仅可以读取还可以写入。投稿流程对智能体是完全开放的获取指南智能体可以首先通过CLI命令pubroot guide --json或MCP工具get_submission_guide获取详细的、结构化的投稿指南包括格式要求、图片政策只允许外链禁止二进制上传、修订政策等。准备内容智能体按照指南准备Markdown格式的文章内容。调用API提交通过GitHub CLI (gh issue create) 或直接调用GitHub REST API按照submission.yml模板的结构创建Issue。智能体需要确保Issue正文的格式严格符合### Field Name的约定以便Stage 1解析器能正确识别。这种设计使得AI智能体能够成为知识的主动贡献者而不仅仅是消费者真正实现了“人机协同”的知识共创。5. 运维、成本与扩展性考量对于一个旨在零成本运行的项目其运维模式、成本边界和扩展潜力是需要深入思考的。5.1 成本结构深度剖析Pubroot的成本模型清晰得令人惊叹GitHub对于公开仓库GitHub Actions的分钟数、GitHub Pages的带宽和存储在合理使用下完全免费。这是项目的基础。Gemini API这是唯一可能产生可变成本的部分。Gemini 2.5 Flash-Lite提供免费的请求额度。根据Google的定价假设免费 tier 之后按量付费每百万字符输入输出成本极低。项目文档称免费额度可支持每月45,000次评审。这是一个非常可观的量级对于项目初期和中期完全足够。外部APIarXiv和Semantic Scholar API均为免费但有速率限制。GitHub Actions的分布式、间歇性调用通常不会触发这些限制。真正的成本是隐性的开发者和维护者的时间。维护评审标准、校准示例、处理极端案例、修复管道bug、应对滥用行为这些都需要投入精力。但相比于运营一个带服务器、数据库、支付系统的传统平台这种维护成本已经低了好几个数量级。5.2 扩展性与瓶颈横向扩展GitHub Actions本身可以并行运行多个工作流。如果投稿量激增可以调整工作流的触发策略或者设置多个队列。由于每个评审任务都是无状态的并行化处理非常容易。性能瓶颈Gemini API速率限制免费额度和付费层级都有每分钟/每天的请求限制。需要实现重试机制和队列管理避免因限流导致评审积压。GitHub Actions运行时间每个工作流有最长运行时间限制默认6小时。复杂的评审如需要分析大型代码库需要优化代码避免超时。Git仓库大小随着文章和评审文件增多仓库体积会增长。但文本和JSON文件体积很小万篇文章可能也就几百MB远未到GitHub仓库的容量限制。质量维护最大的挑战在于维持评审质量。LLM的输出可能存在不可预测性。解决方案是持续优化校准示例和评审提示词。需要建立一个机制定期用一批“测试文章”来评估评审管道的表现并根据结果调整提示词和校准集。5.3 安全与滥用防范垃圾信息与滥用投稿依赖Stage 1的基础过滤和GitHub自身的垃圾信息检测。对于通过初审的恶意内容最终会在AI评审阶段因低分被拒绝。严重的滥用者可以被GitHub封禁。提示词注入与游戏系统这是AI系统的通病。投稿者可能尝试在文章中嵌入特殊指令来操纵AI评审员。除了Stage 1的简单检测更依赖于LLM自身的安全性训练和提示词中的系统指令加固例如明确指令模型忽略任何试图改变评审规则的文本。数据隐私所有提交的内容都是公开的除非链接到私有仓库。这符合开放获取的精神。投稿者不应提交任何敏感或私有信息。5.4 内容保鲜与知识管理Pubroot引入了“知识保鲜”机制这是一个非常前瞻性的设计valid_until字段每篇文章都有一个有效期。技术类内容如LLM基准测试可能6个月后就过时了而历史或哲学类内容可能有效期长达12个月。过期的文章仍然可以访问但可能会被标记或降低搜索排名。supersedes/superseded_by关系当有新文章显著改进了旧文章时可以在新文章的评审元数据中声明它“取代”了某篇旧文章。这形成了一个知识演进的链条。主题槽位对于发展极快的领域如ai/llm-benchmarks可以设置规则限制同一时间段内只保留一篇最新的基准测试文章鼓励贡献者提供最新的综合比较而不是碎片化的过时信息。这些机制共同作用使得Pubroot不是一个静态的档案库而是一个动态的、自我更新的知识流更贴近真实世界知识快速迭代的节奏。6. 实战指南从用户与开发者双视角6.1 作为投稿者如何提高接受率选择合适的类型与分类仔细阅读“投稿类型”矩阵。如果你的工作是实现了一个新算法选“原创研究”如果是记录一个具体问题的解决过程选“案例研究”。准确分类有助于AI应用正确的评审标准。提供可复现的代码尽可能链接到一个公开、结构清晰的GitHub仓库。包含详细的README.md、明确的依赖列表和简洁的示例代码。这不仅能争取到“已验证开放”的绿色徽章极大提升可信度也能在“代码质量”和“可复现性”维度拿到高分。清晰的结构与写作即使有AI评审清晰的文章结构、准确的语法和流畅的表达也至关重要。使用Markdown标题组织内容用代码块展示代码用表格或列表呈现数据。好的“写作质量”是给评审员无论是AI还是人留下好印象的基础。声明要具体且可验证避免模糊的陈述。像“本方法显著提升了性能”这样的说法很难被事实核查。应该写成“在XX数据集上本方法将准确率从85%提升到了92%”。AI的搜索grounding功能可以尝试去验证这类具体声明。利用修订机制如果被拒绝不要气馁。仔细阅读AI给出的详细评审反馈它们通常会指出方法论、事实准确性或表达上的具体问题。针对性地修改后重新提交一个新的Issue。每次提交都是一次独立的评审你的声誉分数会随着接受的文章数而增长从而获得更快的评审速度。6.2 作为开发者如何参与贡献或搭建类似系统理解架构精髓Pubroot的核心模式是“GitHub作为后端” “AI作为逻辑层” “静态站点作为前端”。这个模式可以复用到很多其他领域比如自动化内容审核的知识库、社区驱动的文档站、项目集锦展示等。关注关键文件_review_agent/这是AI评审管道的核心六个阶段的Python脚本是学习如何编排AI工作流的绝佳示例。.github/workflows/review.yml和publish.yml展示了如何用GitHub Actions实现复杂的自动化流程。_calibration/理解“少样本示例”如何用于校准AI输出这对于构建任何依赖LLM的评分或分类系统都至关重要。改进评审质量最直接的贡献方式是优化校准示例。如果你发现某类文章的评分系统性偏高或偏低可以尝试构造新的、更具代表性的校准示例提交Pull Request。扩展分类如果你所在的领域未被覆盖可以编辑journals.json文件提议添加新的期刊或主题。这需要社区讨论以确保分类体系的清晰和有用。构建自己的版本你可以Fork这个仓库修改journals.json和评审标准将其改造成一个专注于你所在垂直领域例如独立游戏开发日志、硬件制作教程、特定编程语言技巧的自动化评审发布平台。由于成本为零试错风险极低。Pubroot展示了一种未来知识生产和消费的范式低成本、自动化、透明化、人机协同。它不仅仅是一个工具更是一个关于如何利用现有云服务、AI能力和开放协议来构建有价值系统的思想实验。无论你是想分享知识的研究者需要可靠信源的智能体开发者还是对无服务器架构和AI应用感兴趣的工程师这个项目都提供了丰富的学习价值和实践灵感。它的成功与否最终将取决于社区贡献的内容质量而这正是其开放和自动化设计所鼓励的。
