当古诗词遇上 AI从 38 万句诗词中取一个好名字用 FAISS 向量检索 DeepSeek 大模型把八字五行、音律五格和诗词意境串成一条自动化取名流水线。缘起给新生儿取名这件事对很多新手父母来说堪比一场「信息战」——要查八字五行、翻诗词典故、算五格吉凶、排除谐音梗最后还得在家族群里投票。每一项都不难但叠在一起就变成了一项耗时数周的系统工程。这个项目试图用 AI 把整个流程自动化输入姓氏、性别和出生时辰系统会从 38 万句古诗词中检索灵感结合八字五行约束调用大语言模型生成名字再经过音律评分、五格校验和谐音过滤最终返回 5 个兼顾文化底蕴和数理吉凶的候选名。整个系统可以拆成三层来理解数据层诗词预处理 向量索引 康熙字典、服务层八字计算 → 五行分析 → 向量检索 → LLM 生成 → 多维过滤 → 综合排序、接入层Web H5、微信/支付宝小程序。架构全景先看整体架构。系统采用经典的分层设计从上到下依次是客户端、网关、API 路由、中间件链、核心服务、数据存储和外部 AI 服务接入层支持 Vue 3 H5 页面和微信/支付宝小程序所有请求统一经过 Nginx 反代进入 FastAPI 后端。中间件链是第一个有意思的设计。每个请求在到达业务逻辑之前要依次通过四道关卡反爬虫校验UA 黑名单 HMAC 签名、邀请码验证、IP 速率限制滑动窗口 每日配额、免费额度检查。这个链式结构让安全策略和业务逻辑完全解耦任何一层的规则变更都不需要改动其他部分。核心服务层是取名流水线的主战场下面重点展开。取名流水线从出生时辰到好名字上图展示了一个名字从请求到返回的完整旅程。整个流程可以分为四个阶段命理分析、诗词检索、LLM 生成、质量过滤。阶段一命理分析 —— 搞清楚五行缺什么用户提交出生年月日和时辰后系统首先用寿星天文历sxtwl排出八字四柱然后分析五行强弱确定「喜用神」。这一步的关键在于五行强弱的量化判定。系统不是简单地数个数而是综合月令、长生十二宫和天地干得分来计算一个综合分数# Mock: 五行强弱判定核心逻辑defanalyze_wuxing_strength(bazi_chart:BaziChart)-WuxingResult:day_masterbazi_chart.day_master_stem# 日主天干month_order_scoreget_month_shishen_score(day_master,bazi_chart)changsheng_scoreget_changsheng_score(day_master,bazi_chart)ground_scoresum(score_stem(stem)forsteminbazi_chart.dizhi_stems)stem_scoresum(score_stem(stem)forsteminbazi_chart.tiangan_stems)totalmonth_order_scorechangsheng_scoreground_scorestem_scoreiftotal3.0:verdict偏旺# 日主强喜泄耗eliftotal-2.5:verdict中和# 平衡喜本气else:verdict偏弱# 日主弱喜生扶xi_shenderive_favorable_element(verdict,day_master.wuxing)returnWuxingResult(verdictverdict,xixi_shen,jiopposite(xi_shen))这里有个容易踩的坑晚子时23:00-24:00的处理。传统八字学认为晚子时属于第二天需要将日柱和时柱推进到下一天。很多八字排盘程序在这里出错系统用sxtwl的isLateZiHour标志做了专门处理。阶段二诗词检索 —— 从 38 万句中找灵感这是整个系统最有技术含量的一环。数据准备阶段原始诗词数据来自chinese-poetry开源项目涵盖诗经、楚辞、全唐诗、宋词和四书五经。预处理管线做了三件事繁体转简体OpenCC、按标点断句、过滤负面关键词悼、亡、死、悲、愁等 30 多个字。最终得到约 38 万条干净诗句存入processed_poems.json。向量化阶段每条诗句调用智谱 AI 的 Embedding-3 模型生成 2048 维向量写入 FAISS 索引。为了在有限内存下跑起来索引使用了IndexScalarQuantizerQT_8bit量化配合IO_FLAG_MMAP做内存映射比 float32 方案节省约 75% 内存且不需要把整个索引加载到 RAM。# Mock: 向量检索 多样性采样defsearch_poetry(surname,gender,wuxing_keywords,zodiac_keywords):# 1. 构建复合查询姓氏 性别 五行意象 生肖宜忌queryf{surname}{gender}{ .join(wuxing_keywords)}{ .join(zodiac_keywords)}embeddingzhipu_embedding(query)# 2048-dim vector# 2. FAISS 检索 top_k * 2 条候选candidatesfaiss_index.search(embedding,top_k100)# 3. 分层采样避免唐诗因语料量大而过度代表quotas{诗经:12,楚辞:8,唐诗:18,宋词:12,其他:10}sampledstratified_sample(candidates,quotas)returnsampled# ~50 条来源均衡多样性采样是这里的设计亮点。如果直接取 FAISS 的 Top-K 结果由于唐诗数量远超其他朝代检索到的诗句会严重偏向唐诗。系统采用分层配额采样确保诗经、楚辞、唐诗、宋词各有代表让 LLM 看到风格多元的灵感素材。阶段三LLM 生成 —— 大模型登场拿到诗词素材后naming_engine模块开始组装 Prompt。这个 Prompt 相当「重」——它需要把八字分析结论、五行宜忌附带示例字、生肖取名规则、音律约束姓氏的声母和声调信息、以及采样到的诗句全部注入进去。# Mock: Prompt 核心结构promptf 你是一位精通古诗词和姓名学的取名专家。 ## 基本信息 姓氏{surname}声母{shengmu}声调{tone} 性别{gender}## 五行分析{bazi_analysis}喜用神{xi_shen}宜用五行属性为「{xi_shen}」的字。 ## 音律约束 姓氏声母为「{shengmu}」名字中避免使用相同或相近声母。 姓氏声调为第{tone}声名字应有声调变化。 ## 诗词素材{sampled_poems}请根据以上约束生成 6 个名字每个名字需注明诗词出处。 系统通过 OpenAI 兼容接口调用 DeepSeek-V4 Flash主力或 Mimo V2.5 Pro。支持 SSE 流式输出使用NAME分隔符协议而非增量 JSON 解析让流式场景下的名字逐个呈现更加稳健。阶段四质量过滤 —— 五道关卡LLM 生成的名字不能直接用还要经过五道过滤关卡第一关五格吉凶。根据康熙字典笔画数计算天格、人格、地格、外格、总格对照 81 数理吉凶表。30 个「大凶」数理直接淘汰。第二关禁用字和谐音。检查名字中是否包含禁用字以及是否存在不雅的谐音联想。第三关生僻字。排除用户可能不认识、输入法打不出的字。第四关音律评分。基于pypinyin检查五个维度——声母重复、声调单调、声母相近、韵母雷同等每项违规扣分低于 60 分淘汰。# Mock: 音律评分核心规则defcheck_phonetics(surname,char1,char2):score100s_sm,c1_sm,c2_smget_shengmu(surname),get_shengmu(char1),get_shengmu(char2)s_tone,c1_tone,c2_toneget_tone(surname),get_tone(char1),get_tone(char2)ifs_smc1_sm:score-20# 姓与名同声母ifc1_smc2_sm:score-15# 两字同声母ifs_tonec1_tonec2_tone:score-25# 三字同声调ifare_similar_groups(s_sm,c1_sm):score-10# 相邻声母组ifget_yunmu(char1)get_yunmu(char2):score-10# 同韵母returnscore# 60 则淘汰第五关五行加分。对通过前面所有关卡的名字根据字的五行属性给予加分。这里用了三级回退策略硬编码字典 → 康熙字典查询 → 偏旁部首推断最大化覆盖率。最终的综合排序公式是总分 音律 × 0.4 五格 × 0.3 诗词来源 × 0.2 五行匹配 × 0.1音律权重最高40%体现了系统的设计理念一个好名字首先得好听。诗词来源的时代权重也有讲究——先秦诗词诗经、楚辞得分 100唐代 80宋代 70鼓励系统优先引用更古老的经典。几个值得聊的技术选型为什么用 FAISS 而不是向量数据库这个项目的数据规模38 万条 × 2048 维其实不大FAISS 配合 8-bit 量化后单机就能跑不需要额外部署 Milvus 或 Pinecone 这样的分布式向量数据库。IO_FLAG_MMAP让索引文件常驻磁盘按需加载对内存友好。对于中小规模的 RAG 场景FAISS 仍然是性价比最高的选择。为什么用 SSE 而不是 WebSocket取名场景是典型的「服务端单向推送」——用户发一次请求服务端陆续返回多个名字。SSE 天然适合这种单向流实现简单且对 HTTP 代理友好只需设置X-Accel-Buffering: no。WebSocket 的双工能力在这里是多余的。为什么用分隔符协议而不是流式 JSONLLM 的输出是逐 token 生成的增量解析 JSON 既脆弱又复杂。系统让 LLM 用NAME分隔每个名字块服务端按分隔符 split 后逐块解析比尝试从流中拼凑合法 JSON 稳健得多。会话缓存的设计。系统一次让 LLM 生成 6 个名字但只返回前 5 个。第 6 个以及可能的更多溢出名字缓存在内存中的session_store里TTL 60 分钟。这支持了「换一批」的 UX 模式——用户不满意时可以快速获得备选而不需要重新调用 LLM。数据管线从原始诗词到向量索引整个数据准备过程由三个脚本串联完成chinese-poetry/ (Git submodule, 原始数据) │ ▼ preprocess.py processed_poems.json (38万句, ~64MB) │ ▼ vectorize.py poetry.faiss metadata.db (向量索引 元数据)preprocess.py的负面关键词过滤值得一提。系统维护了一个 30 多个字的黑名单悼、亡、死、悲、愁、苦、泪……任何包含这些字的诗句都会被丢弃。这确保了取名素材的情感基调是积极向上的——毕竟没人想用一个充满悲伤意象的名字。vectorize.py使用异步并发 信号量控制asyncio.Semaphore(20)来加速 Embedding 生成支持多 API Key 轮询和断点续传。每处理 5 个 batch 就 flush 一次到 FAISS 索引避免内存中积累过多数据。安全与运营一个面向公众的 AI 服务不能没有安全防护。系统的中间件链实现了多层防御反爬虫层使用双重认证策略——Web 端走 Session Token2 小时 TTL绑定 IP小程序端走 HMAC 签名。签名算法用了双哈希方案hash(secret:timestamp:nonce) hash(reverse(secret:timestamp:nonce))增加了逆向难度。速率限制层采用 IP 滑动窗口 每日配额 会话冷却的三重机制默认配置是每 60 秒最多 5 次请求、每天最多 200 次 API 调用、同一会话两次请求间隔至少 30 秒。免费额度层支持按天或按终身两种模式可以灵活配置免费体验次数。小结这个项目的核心价值在于把「取名」这个看似感性的过程拆解成了一条可量化、可追溯的工程流水线。八字五行不再是玄学黑箱而是可以计算和验证的数值诗词检索不再是随机翻阅而是基于语义相似度的定向搜索质量过滤不再是人工逐条检查而是五道自动化关卡加综合评分。从技术栈的角度看FAISS DeepSeek pypinyin sxtwl 的组合覆盖了向量检索、大模型生成、音律分析和历法计算四个维度每个组件都各司其职。分层架构和中间件链让系统具备良好的可维护性而多样性采样、分隔符协议、会话缓存这些细节设计则体现了工程实践中的务实思考。如果你正在考虑构建一个类似的「传统文化 AI」应用希望这个项目的架构思路和技术选型能给你一些启发。关于本项目这套系统已落地为「文间拾字」v搜索即可体验。文章中的架构图和流程图均基于该项目的真实实现绘制。如果对技术方案有更多交流欢迎在评论区讨论。