诗泉用 Go 封装 40 万首古诗词一行 Docker 命令即可私有部署的 REST/GraphQL API 服务核心观点这个项目做的事情非常务实把公认最全的开源数据集 chinese-poetry51k StarsMIT协议从一堆 JSON 文件包装成一个生产可用的后端服务——有标准化接口、有搜索、有限流、有容器镜像。它不是数据研究也不是算法创新定位非常清晰开发者直接取用的诗词基础设施属于工程化封装层的渐进式优化而非底层范式突破。理解它的正确参照系是把它类比为给 SQLite 数据库加了一个标准 REST 网关而不是又一个 NLP 模型。关键信息数据规模来自原文分类数量分类数量七言绝句85,032五言律诗71,400七言律诗69,028五言绝句18,895宋词21,369元曲10,905乐府诗9,315其他96,232合计~383,000还含诗经/楚辞/四书五经—数据源头是 chinese-poetry 项目但原始数据集以宋诗为主体约 26 万首唐诗约 5.5 万首。本项目的40 万是将所有体裁合并统计后的总量使用时要区分海量数据和精品名篇的差异。技术栈与关键设计语言Go核心卖点之一是并发性能简繁转换约 300ns/op使用 gocc 库同一数据库双存储、查询时按?lang参数动态返回不是运行时转换是预处理后双写这是性能低延迟的关键接口REST API/api/v1/ GraphQL/graphql双端点并行保护机制IP 级限流防止数据被无限抓取部署Docker 单镜像支持 amd64/arm64 双架构数据管理Git Submodules 挂载上游数据集解耦数据与服务代码/示例一行启动docker run -d -p 1279:1279 palemoky/chinese-poetry-api:latest典型 REST 调用# 随机取一首李白的五言绝句飞花令场景 curl http://localhost:1279/api/v1/poems/random?author李白type五言绝句 # 飞花令含春字的诗词 curl http://localhost:1279/api/v1/poems/random?char春 # 多体裁组合筛选 curl http://localhost:1279/api/v1/poems/random?author李白type五言绝句type七言绝句type五言律诗 # 繁体中文版 curl http://localhost:1279/api/v1/poems?langzh-HantGraphQL 查询示例# 按标题搜索并获取作者信息 query { searchPoems(query: 静夜思, searchType: TITLE) { edges { node { title author { name } } } } } # 统计各朝代诗词数量 query { statistics { totalPoems poemsByDynasty { dynasty { name } count } } }最核心的机制为什么选择双语双写而非实时转换这是整个项目性能设计中最值得学习的一个决策。简繁转换是字符映射操作虽然单次很快300ns但在高并发场景下比如 API 被多个客户端同时请求每次查询都转换会导致 CPU 被消耗在与业务无关的重复字符替换上。选择在数据预处理阶段一次性双写简体和繁体各存一份查询时直接读取对应列是一种以空间换时间的经典工程取舍。代价是数据库体积几乎翻倍收益是接口延迟完全不受语言切换影响。对于一个定位为高性能 API 服务的项目这个选择是合理的。交叉验证信源一HelloGitHub项目收录页HelloGitHub 平台将此项目收录为开箱即用推荐过去 7 天新增 476 颗 Star截至搜索时总 Star 约 2.1k这个增速对于一个工具型项目属于快速传播阶段。平台描述与原文基本吻合强调Docker 一键部署RESTGraphQL40 万首等卖点没有独立技术评测认同原文的功能描述但未提及任何局限性。信源二zhupite.comchinese-poetry 数据集介绍这个信源让我们可以独立验证数据源本身的质量chinese-poetry 原始项目有 51k StarsMIT 协议数据以 JSON 格式存储宋诗约 26 万首、唐诗约 5.5 万首。两处值得关注的信息差异数量口径问题原始数据集的 55,000 首唐诗和 260,000 首宋诗合计已超 31 万但本项目报告40 万首差值来自元曲、词、经典文集等其他类别的合并统计。这个数字没有问题但唐诗宋词爱好者需要注意——宋诗多为文人案头诗知名度低占比远超唐诗不是 40 万首经典名篇。数据授权原始 chinese-poetry 数据集是 MIT 协议但本项目是GPL-3.0协议。这意味着如果你基于本项目的代码做二次开发并分发必须以相同协议开源——商业团队需注意这个传染性条款。信源三CSDN 技术文章原文一篇转载/整理文章基本是对 README 的中文扩展说明未提供独立测试数据对原文观点全盘认同补充了适合 RAG 知识库、MCP 服务、大模型语料等 AI 时代的新用法这个方向是合理的延伸但未经验证古诗词 JSON 灌入 RAG 的实际效果依赖于 embedding 模型对古文的理解质量并非开箱即用。总结三个信源均认同原文的基本描述没有实质性反驳但也没有提供独立性能基准测试。GPL-3.0 与数据量口径是两个值得独立验证的细节。边界与被夸大的部分高性能没有基准对比原文宣称高性能给出的唯一数据是简繁转换 300ns/op但没有 QPS 数据、响应延迟测试或与其他同类项目如 Python/Node.js 实现的同类服务的对比。Go 语言本身并发能力强但性能最终取决于数据库索引设计和查询复杂度仅凭语言选型无法证明高性能。搜索能力有限项目提供全文搜索、标题/内容/作者分类搜索但从 README 看这更像是数据库 LIKE 查询而非 Elasticsearch 级别的全文检索不支持模糊拼音、近义词、语义搜索。对飞花令场景的单字查询可以满足但复杂语义检索不在其能力范围内。数据噪声原始 chinese-poetry 数据集本身存在数据质量问题有研究者反映部分宋诗存在重复条目、作者信息缺失这些问题会原样继承到本项目。GPL-3.0 许可证的商业限制数据源是 MIT但服务代码是 GPL-3.0闭源商业使用需谨慎。个人启发这篇文章最大的实际价值不在于发现了一个新技术而在于提供了一个立即可用的工程化模板。对不同读者的具体行动建议前端/全栈开发者如果你要做每日一诗小组件、诗词日历、飞花令小游戏或者给 AI 应用加一个古诗词知识模块这个项目可以让你在 10 分钟内绕过数据从哪来的问题直接进入产品设计阶段。?char春这个参数是飞花令场景的直接解法不需要自己写过滤逻辑。后端/架构方向这个项目本身是Git Submodules 管理外部数据源 Go 服务 Docker 容器化的完整范例值得作为学习工程化实践的参考代码库阅读重点看数据预处理流程make process-data和简繁双写设计。AI/RAG 方向将古诗词批量导入向量数据库做语义检索有可行性但务必先验证你使用的 embedding 模型对古文的编码质量——多数通用中文 embedding 模型对古汉语的效果显著弱于现代文。可先用 GraphQL 的统计接口按朝代/体裁分批导入而非一次性灌入 40 万条。决策层/开源贡献者数据质量重复条目、作者信息缺失和搜索能力缺乏语义搜索是两个最值得贡献的改进方向。延伸思考简繁双写策略在其他多语言场景下的泛化性如何中文简繁是字符一对多映射繁→简有歧义本项目用预处理规避了这个歧义。但日语假名、东南亚文字的多字符集问题是否也能用同样策略还是说简繁双写是中文特有的低成本方案在其他语言里代价会指数级放大GPL-3.0 许可证是否会成为生态扩展的天花板数据源 MIT、服务代码 GPL-3.0这个组合在商业项目中会产生传染性风险。如果作者将来希望吸引更多商业贡献者如 SaaS 厂商贡献改进是否应该考虑双授权dual licensing模式这对开源项目的商业化路径有什么影响当古典语料 RAG成为 AI 应用标配数据质量将成为瓶颈而非数据数量—— 本项目 40 万首诗词中其他类占了 9.6 万首约 25%这部分数据的结构化程度、元数据完整性如何当 LLM 的上下文窗口已经足够大批量灌入低质量语料会不会反而降低 AI 应用的回答准确率参考信源HelloGitHub - palemoky/chinese-poetry-api zhupite.com - chinese-poetry 数据集介绍 CSDN - 中国古诗词API推荐 参考来源GitHub - palemoky/chinese-poetry-api: 诗泉高性能中国古诗词 API 服务 · GitHub