南洋吟游 · 社员诗歌平台
从手机备忘录里的两三百首诗开始，长成了一个收录 6900+ 首作品、49 位作者、193w 访问量的诗歌生态平台。一个人，四年，从 JSON 到 SQLite，从手写 HTML 到 coding agent。
这个项目是什么
南洋吟游是上海交通大学国学社的社员原创诗歌平台。收录了 6900+ 首诗词作品，支持按作者、体裁、时间线浏览，有语义搜索、关系图谱、AI 赏析、格律校验等功能。目前累计 193w+ 访问量，持续运营四年。
但如果只说这些，它和任何一个内容管理系统没什么区别。真正让它有意思的是它长出来的过程。
为什么做这个
2022 年，我的手机备忘录里有两三百首自己写的诗。一首诗一个备忘，全是扁平的，不好导出也不好管理。我是一个有点阿斯伯格特质的人，希望我的 creature 都可以 well-organized——眼看着备忘录越来越乱，我写了个爬虫，从备忘录的云服务把所有内容爬了出来，然后用 Flask 搓了一个小站点放上去。主打能用就行。
当时还没有 LLM，只有 Flask 和手写的 HTML、CSS。选 Flask 的原因也很简单：我只会 Python，Python 里只会 Flask。
2023 年开始把站点开放给社团里几个朋友。作为社团的 KOL，我觉得有责任让大家的好作品被展示出来，流动起来。于是加了多作者支持。后来更多人入驻，它就从”我的个人站”慢慢变成了社团的基础设施。
我做了什么
如果要用一个词概括我在这个项目里的角色，我想用”超级个体”——在 LLM 时代到来之前就在试着做的那种。不是某个职能的专家，而是围绕一个特定的组织和兴趣，打通每个需求从被看见到落地的全链路。产品设计、前后端开发、数据治理、运维部署、社群运营，全是一个人。
技术栈一路演化：最初是 JSON 文件存储，每次新增作品都要重启服务器，审核每月批量做一次。没人抱怨，但我们自己觉得这样不行——于是 2026 年迁移到 SQLite，实现了热更新和审核流程。前端在 2025 年 10 月逐页重写过一次，当时 coding agent 的能力还差强人意，我的做法是把每个页面单独拿出来丢给 Gemini 网页版，提需求、改好、放回去、测试、推上去。Flask 从 2022 年到现在没动过——不动是怕出问题。
功能上，每个模块的来历都不一样：
AI 每日赏析是最早上的。出发点很简单：拥抱 AI。当时发现 DeepSeek 能写出煞有介事的、和《唐诗鉴赏辞典》味道差不多的赏析。API 还挺贵，我们怕打，赏析都是预生成缓存的，前端的流式输出只是一个动画——没人知道。
语义搜索是因为当时 RAG 比较火，也算延续了以前玩古典 NLP 的初心。用 BAAI/bge-small-zh-v1.5 把每首诗映射到高维语义空间，支持”以诗搜诗”。
但这套向量基础设施最意外的产物是 Poetry-Prism（诗风棱镜）——一个诗歌风格分析和可视化系统。做法是构造”语义锚点矩阵”：预定义四个维度的锚点词——古典色名（天青、月白、玄色……）、季节意象、心理年龄（少年 vs 老者的意象词）、江湖背包物品（斗笠、折叠伞、眼药水……）。把作者全部作品的向量质心投影到这些锚点上，再用全社员语料的均值和标准差做 Z-Score 归一化，就能算出每位作者在当代大学生诗歌创作群体中的相对风格位置。
最终输出是一张”灵魂画像”海报：心理年龄 55 岁、季节是夏、代表色是玄色、签名香氛是”海与焰”、背包里装着 44 顶斗笠和 28 把折叠伞。每张都不一样，每张都有解释力。用 Gradio + Jinja2 做前端，部署在 Hugging Face Spaces 上，预计算数据压缩到 400KB 的二进制文件，冷启动几秒内完成。上线后成了社员之间传播最广的内容——大家都想看自己的”灵魂画像”长什么样。
关系图谱来自一个朴素的观察：作为社团，人与人的联结是维持运行的根本，作品与作品的联结也是。古典诗有”次韵”——用他人的韵脚作诗酬答，是大家增进感情的常用方式。把这种联结可视化出来，是自然而然的事。
格律校验是被搜韵网逼出来的——有段时间搜韵非常卡（它们还在用 .NET），痛定思痛决定打造自己的基础设施。这个决定无比正确：之后中了的 ACL 论文、方寸辅助创作平台、天权作诗 LLM 的 post-training 和 agent 全都依赖这套格律引擎。作为一个 INTJ，做的时候就已经能看到这些下游应用了。
首页猜诗游戏是 2025 年 11 月做的，初衷是促活和留存。有六种玩法：猜作者、猜词牌、完形填空、诗句排序、找关联作品、上下句匹配——其中完形填空复用了更早做的教学项目「拼好诗」的平仄对仗引擎。刚上线那一周很火，大家上课都在摸鱼玩，也让每个玩家提升了对其他社员作品的熟悉度。后来意外发现这套题目格式可以直接拿去测 LLM 的古典诗词理解能力，于是就有了 Neo-Classic 这篇论文——被 ACL 2026 Main 收录，是我第一篇顶会。
过程中的思考
这个项目最有意思的一条线是编号系统的演化。最初入驻的五位作者，每个人都有自己的编号哲学：我按诗、词、现代韵文分 1xxx/2xxx/3xxx；有个同学按主题/对象分了四类；还有个同学希望诗下面按体裁细分、词按词牌细分——符合传统诗集的排布习惯。我选择了尊重每个人的习惯，给每位作者定制编号逻辑，把作者区分、体裁区分全压缩进 ID 的计算规则里。字段是省下来了，可维护性越来越堪忧。
2026 年，coding agent 的能力终于允许在生产环境做这种危险的重构了——迁移到 UUID 主键，旧编号保留为辅助字段，新旧共存。这是整个生态里最后重构的一块，因为它用户最多、屎山代码最厚、业务逻辑耦合最深。
- −每位作者自定义编号逻辑
- −体裁区分压缩进 ID 计算规则
- −1xxx/2xxx/3xxx 分诗/词/现代韵文
- −字段省了，可维护性堪忧
- +UUID 主键，全局唯一
- +旧编号保留为辅助字段
- +新旧共存，向后兼容
- +解耦了作者-体裁-排序逻辑
LLM 改变了这个项目的边界。以前是”做服务”，现在是”做生态”。南洋吟游本身变成了生态平台化的卡点——也是动刀子难度最大、最危险的一个。
另一个变化是我和工具的关系。2025 年 10 月用 Claude 的体验很差：不稳定的中转站，动辄断连，demo 项目被过度设计。分水岭是 Claude 4.5——之后在实习单位大家都敢直接用 coding agent 写、改、跑通、提测，出问题还能自动反思修复。现在我的工作流是直接 rsync 到生产环境、restart、实时验证，迭代节奏非常快。
一些数字
Q&A
Q: 技术栈这么轻量（Flask + SQLite + 纯 JS），190 万访问量扛得住吗？
到现在还是够用的。SQLite 是今年才从 JSON 升级来的——之前每次加诗都要重启服务器，大家也没抱怨。Flask 四年没动过，不是因为它最好，而是因为我最能掌控它、它不会出问题。技术选型的逻辑不是”什么最优”，是”什么在我的能力和风险范围内最可行”。不过 2026 年新写的项目基本都在用 React、PostgreSQL 之类的了——不是说 Flask + SQLite 不好，而是能力边界和工具都变了。
Q: 一个人做这么多事，怎么决定先做什么？
格律校验的例子最典型。表面上看它只是”搜韵太卡了我自己做一个”，但我做的时候就已经能看到它会成为论文、创作平台、LLM 训练的基础设施。先做能撬动最多下游价值的东西——这可能是 INTJ 的本能。不是每个功能都有这么清晰的链条，AI 赏析纯粹是”拥抱新技术试试看”，语义搜索做完之后才意外发现可以用来生成年度报告的趣味 profile。
Q: 被”像素级”抄了是什么感受？
有点不开心，但不想计较。到 2026 年，技术已经在爆炸的边缘——这时候人的注意力变成了稀缺资源，技术本身并不能解决”人往何处去”的问题。好的技术基建只是一半，好的运营、好的社群组织，让大家感受到”我在这里被归属”——才是另一半。这一半抄不走，也会越来越重要。
Q: 这个项目的起点是”备忘录装不下了”，终点会是什么？
没想过终点。最初的驱动力是很私人的——我不想被平台困住，数据导不出来，世界不受我控制。写爬虫把诗从备忘录里救出来，和后来做整个生态平台，本质上是同一个冲动：打造自己完全可控的世界。只要这个冲动还在，它就会继续长。