5个新闻源、10条声明、10份证据——这是source-score项目的全部家当。作者用三行小学数学公式给媒体可信度打分，却搭了一套完整的微服务架构。

从YAML到实时仪表盘：三个仓库的协作逻辑

打开网易新闻 查看精彩图片

项目拆成三个独立仓库，数据层、后端、前端完全解耦。

数据层叫sources，纯YAML文件驱动。三个文件夹对应三种实体：sources/存媒体源信息，claims/存声明原文，proofs/存验证证据。每个YAML都走OpenAPI校验，PR时自动验证格式，合并后由GitHub Actions推送到API。

这种设计把"数据录入"变成了"代码审查"。想添加一条《纽约时报》的声明？不是调接口，而是提一个PR，让协作者能看到完整的修改记录。作者的原话是：「这让数据集变得可审查」。

后端负责两件事：接收YAML推送，执行验证计算。验证逻辑直白到近乎粗暴——支持证据数大于反驳证据数，声明标记为有效。媒体得分=有效声明数/已验证声明数。两个声明都有效，得分就是1。

前端仪表盘用GitHub Pages托管，免费、静态、直接读API。整套部署落在Render的免费实例上，冷启动要几秒。

为什么故意用"简陋"的算法？

作者坦承这套评分「不是最终的可信度算法」。但第一版的目标很明确：可理解、可测试、可争论。

复杂模型的问题在于难以调试。如果一个黑盒神经网络打出0.73分，你很难解释为什么。但"2个支持证据vs1个反对证据"的胜负关系，任何人都能一眼看懂并质疑。

这种设计哲学贯穿整个项目。YAML而不是数据库，因为结构化文件更易审计；三行公式而不是机器学习模型，因为透明比精确更重要；微服务拆分而不是单体应用，因为作者「希望数据、后端、仪表盘保持分离」。

当前demo只手工录入了5个媒体源，每个源2条声明，每条声明1份证据。规模小到可以手工核对，但架构已经预留了自动化扩展的接口。

微服务实践中的工程取舍

这是个典型的"用复杂架构解决简单问题"的案例，但作者的动机很清晰：边练Golang，边验证一个产品假设。

技术选型上能看到明显的个人偏好。CI流程用GitHub Actions而不是更重的工具，因为和代码仓库天然集成；部署用Render免费层，因为demo不需要稳定性；前端完全静态，省掉服务器成本。

这些选择暴露了一个独立开发者的资源约束：时间有限，预算为零，但想证明概念可行。

项目目前的状态是「非常早期，远未完成」。但demo已跑通完整链路：从YAML提交，到自动验证，再到实时评分展示。下一步可能是接入自动化证据抓取，或者引入更复杂的评分维度——但前提是保持可解释性。

对于想复制这个模式的开发者，核心可借鉴点在于：用GitOps思路管理内容数据，用极简算法快速验证产品假设，用免费托管层降低试错成本。打假新闻是个重运营的事，但source-score证明技术原型可以很轻。