1. 立项前的那几场争论:需求是怎么从"检诗找句"变成"文海问津"的
我们六个人第一次坐进学院小会议室的时候,谁也没想到这个选题能讨论两星期。团队里四个汉语言文学方向、两个计算机方向,本来凑到一起是想做一个给文学院研究生用的"诗词检索工具",原因是大家写论文时最烦的就是为一句诗翻遍《全唐诗》《全宋诗》电子版,还经常翻错卷次和版本。但第一场讨论刚进行半小时我就发现,每个人心里想要的工具根本不是同一个东西。有人想要"输入诗句查出出处",有人想要"问某字在古代韵书里的反切",还有人直接说"最好能整段翻译成白话文"。这种需求发散的情况在创新实训项目里太常见了,真正麻烦的不是收集需求,而是把十几种想象收敛成三句能落地的话。
我们做这件事有个前提:团队里没人能负担从零训练模型,也不打算把项目做成一个"看起来什么都会、实际上什么都答不完整"的聊天机器人。于是前两周基本没写代码,一直在做需求访谈和资料调研。这里我把整个过程记录下来,既作为项目记录的第一篇,也供其他做文史方向加NLP应用的团队参考。如果你想了解一个跨学科小团队如何把古籍文本从零变成一个可用的问答检索原型,这篇应该能给你一条相对完整的路径。
1.1 最初的对话里,十个人有十种"想要的东西"
需求调研第一轮,我们做了三件事:采访十一位文学院研究生和三位老师,翻看他们在纸质书里做批注的照片,再把日常提问按照"查原文、查释义、查关系、查争议"四个类别做统计。统计结果很有意思,接近一半的问题属于"查原文",比如"这句话最早出现在哪里""这个典故在《史记》里有没有记载";另外大约三成是"查释义",但不是简单的字词翻译,而是想知道朱熹怎么注、清人怎么辨、今天的教材又采用哪种说法;剩下两成才是"查关系"和"查争议"。
这段调研直接否掉了我们最早设想的"诗词搜索引擎"方向。因为用户真正不舒服的环节,不是找不到某一句诗,而是找到了之后还要自己核对多个版本、翻注疏、判断哪种解释更可靠。他们缺的不是一个更大的数据库,而是一条从原文出发、能串联起版本与注疏的研读路径。这个发现后来成为项目定位的关键:我们不负责替用户下结论,只负责把相关材料用更清晰的方式摆到他面前。
1.2 四轮访谈之后,我们把需求收敛成了三个关键词
需求收敛不是一次完成的。第二轮访谈把范围缩小到先秦到唐宋的常见典籍,第三轮用纸质原型让人试用,第四轮把我们预想的"功能大而全"逐条打回。最终留下来的核心需求可以归纳为三个关键词:定位、对照、解释。
"定位"指的是从一句引文或一个模糊表述出发,找到它在典籍中的确切位置,包括篇名、章节和上下文;"对照"指的是同一句话在不同版本里的异文差异,以及不同注家对同一处字句的解释差别;"解释"则是围绕某个字词、人名、事件或思想概念,把分散在原文各处的相关材料汇总给用户看。三件事听起来容易,真正做起来就会发现每一件都需要精细的文本结构和领域知识,不是单纯把文档丢给大模型就能解决的。
我们把项目命名为"文海问津",也是出于这三个关键词。"文海"是对象,指向浩瀚的典籍文本;"问津"取自"使子路问津焉"里的探路之意,强调的是在文本海洋里找到门径,而不是让系统替用户把书读完。这个名字从一开始就在提醒我们:系统守得住边界、给出确定出处,比"聊得开心"重要得多。
1.3 一个跨学科团队的分工前提:文科生负责问对问题,计算机方向负责把问题变成流程
团队分工也经历了磨合。最开始两个计算机方向的同学习惯性问"你们要什么接口",四个文科方向的同学则回答"我们都想要"。后来我们采用了一个非常老套但有效的办法:每个需求必须附带一个真实场景、一条验收标准和一条放弃理由。比如"输入'学而时
