藏头诗微信小程序源码解析：从玩法设计到文本生成落地

简介：藏头诗微信小程序源码包是一份完全基于前端实现的微信小程序项目，省去后端服务器依赖，适合小程序开发初学者、个人开发者及需要快速搭建轻量应用的创业者。整套源码共 19 个文件，由 js 逻辑脚本、json 页面配置、wxss 全局与页面样式、wxml 结构模板及少量 png 静态图组成，压缩后仅 147KB，轻量易部署。目前已有 374 人学习，是观察小程序标准工程结构的良好样例。通过阅读这份工程，可以学习 App() 全局逻辑、页面生命周期函数、WXML/WXSS 的 MVVM 数据绑定方式，以及 rpx 自适应单位的使用；同时，源码中涉及用户授权、分享等常见 API 的调用，对初探小程序路由跳转与状态管理也有直接的参考价值。页面与静态资源分层清晰，全局与局部配置组织得当，便于快速定位修改点，适合在此基础上二次开发个性化的藏头诗生成工具。

1. 藏头诗微信小程序源码：先看它解决了什么问题，再决定要不要动手读它

用户输入两到四个字的名字，等一两秒，拿到一首句首藏着这些字的小诗，截图发朋友圈——这就是“藏头诗微信小程序源码”这个 zip 里最核心的场景。它看起来是个小玩具，但拆开看，前端要处理输入、渲染与分享，后端要处理文本生成与内容安全，中间还夹着微信平台的一堆审核约束，对想入门小程序开发的人来说，是个典型的小而全的样例。做文本生成的人也会关心同一个问题：规则拼接、词库组合、模型生成这三条路线，摆在藏头诗场景里的代价分别是什么。这篇就顺着“源码里有什么→怎么生成→怎么跑通→会遇到什么坑→怎么做得更好”的顺序讲透。

2. 翻开 zip 之前：藏头诗小程序的玩法边界与核心模块组成

2.1 两种玩法：藏头、藏字与藏尾，先明确代码要支持哪一种

常见的藏头诗，就是把用户输入的几个字拆开，分别作为五言或七言诗每句的第一个字。名字是两个字的，一般生成四句，两个名字字分别占用前两句句首，后两句用祝福语或意象字兜底；名字是四个字的，正好一个字对应一句。这是最保守也最好实现的玩法。

还有一种变体叫“藏字”，要求名字出现的绝对位置一致，比如都在每句第二个字；再激进一点是“藏尾”，把名字放在每句末尾。玩法不同，数据结构和生成逻辑完全不同。拿到源码后第一步不是看代码，而是确认它做了哪种玩法：去 pages 目录里找输入页的提示文字，看是只让用户填名字，还是让用户选了“五言七言”“藏头藏尾”。这个决定直接决定了后面所有的算法设计。

边界问题通常藏在细节里：两个字的用户要四句诗，名字只覆盖两个句首，剩下的句首用什么字补？我看到过的源码多半兜底用“福、安、乐、康、喜”这类高频祝福字，也有直接重复名字第一个字的，后者很容易翻车——用户叫“张伟”，四句句首变“张伟张伟”，读起来像绕口令。读懂一个小程序的玩法边界，比读懂它的代码更值钱，因为玩法决定了你能改到什么程度。

2.2 源码通用骨架：页面、逻辑、数据接口与诗词库各管什么

一个典型的藏头诗微信小程序源码，无论作者怎么写，目录骨架几乎逃不出这套结构：pages 目录下至少两个页面，index 是输入页，result 是结果页；utils 目录放请求封装和生成算法；data 目录放诗词库；app.js 做全局初始化，app.json 注册页面并声明窗口样式。

数据放哪里，是读源码时最需要留意的一个分叉点。有的源码把诗词库做成一个本地 JSON 文件，生成逻辑完全在小程序前端跑，好处是离线可用、不需要后端，坏处是诗词库体积会挤占小程序包体限制，而且后续更新词库必须重新发版。有的源码把生成逻辑收在服务端，小程序只负责把名字传给接口，好处是算法更新不需要用户升级小程序，坏处是你得自己养一台服务器，还要配置合法域名。从我做这类小项目的经验看，入门级源码里八成走的是“本地词库+前端拼接”路线，因为它不依赖任何部署条件，复制到开发者工具里就能跑。

2.3 先搞懂微信小程序的双线程运行模型，再看代码

读藏头诗源码之前，有一个概念必须搞清楚：小程序不是普通的网页，它分视图层和逻辑层。视图层跑 WXML 和 WXSS，负责渲染；逻辑层跑 JavaScript，负责计算。两层之间通过 setData 通信，而且是异步的。

这个模型带来的第一个坑是：看到 setData 就以为它在刷新整个页面，于是把整首诗的字符串丢进去，结果渲染卡顿。第二个坑是：把 wx.request 当成浏览器里的 fetch，以为可以直接调用第三方接口，实际上小程序的请求域名必须提前在微信公众平台后台配置，否则真机直接失败。藏头诗这种场景文本很短，真正的性能问题不在渲染，而在页面跳转时把名字参数弄丢了。常见做法是把名字通过 URL 参数传给结果页，或者存到全局变量里，我一般推荐 URL 参数，因为分享场景下别人点进卡片也能拿到参数。

2.4 拿到源码后的第一遍通读顺序建议

别从诗词库开始读，那里面可能有几千条数据，读不完会劝退。我建议按这个顺序：先看 app.json，了解这个项目注册了哪些页面、tabBar 有没有、window 怎么配；然后进 pages/index，读输入页的逻辑，看用户提交时到底调用了哪个函数；接着找到生成函数的入口，在开发者工具里直接跑一下；最后去结果页看渲染字段。

整个链路搞清楚后，再回头读诗词库的 JSON 结构，只看字段名就够——是“首字”还是“全句”，有没有“韵脚”标注。只要数据流清晰，后面所有改动都有抓手。如果读了一圈发现生成逻辑不在前端而在某个接口里，那你要做的第一件事不是读代码，而是确认接口文档和域名配置，后面第四章会专门讲。

3. 把藏头诗生成规则拆成代码：三类算法的选型理由与代价

3.1 规则模板拼接法：起步最快、效果最“程序员审美”

模板法的核心思路是：把名字直接嵌进预设的句式里。名字叫“张伟”，就生成“张灯结彩迎新岁，伟业宏图展宏图”。代码量极少，逻辑一眼能看穿，几行 if 就能跑通。但效果非常依赖模板数量，模板少就翻车，模板多其实就退化成了第二种词库法。

我见过一个源码里的模板是“X 山翠色映朝霞，Y 水清波送晚舟”，名字换成什么都往这个壳里套，结果用户叫“李雷”还能读，叫“张三丰”直接语义崩坏。模板法最大的问题是重字和语义错配：名字里的字在句子里既要做句首，又要和后面的词构成通顺短语，而模板根本没有这个能力。它对写作质量没要求、对运行环境没要求，适合做原型验证，不适合作为一个小程序的核心卖点长期保留。

3.2 基于诗词库的首字组合法：自然度更高，工程代价在词库

词库法是把素材整理成“首字到候选句”的映射，生成时按用户名字逐字查表。比如用户要“林”字开头，库里有“林间新绿一重重”，还有“林风拂面送清凉”，从中取一条；老字“张”可能有三十条候选，越常用的字候选越多。

这种方式的自然度上限高，但工程代价在词库建设和维护。一个可用的映射库，至少要把常用名字字覆盖到三五千字，每个字配两到三句语义完整的句子，整理下来是上万句的量级，靠手工录入不现实，常见做法是从公开的诗词数据里做清洗，再用自造句补覆盖缺口。词库的字段设计很重要，我一般会砍到最少：首字、全句、韵脚、热度权重。韵脚字段看起来可加可不加，但没有它，你没法做押韵筛选，生成结果里就会出现句尾平仄混乱的观感。

3.3 接入大模型接口：效果上限高，但成本、延时与合规要提前算账

大模型生成的藏头诗，自然度和语境理解是前两种方式比不了的，但落地的时候有三笔账必须算清楚。第一笔是延时账：模型接口快则两三秒，慢则十秒以上，用户在小程序里等一首诗，超过三秒就会流失大半。第二笔是成本账：每次生成一次请求消耗 tokens，如果小程序没有收入模式，这就是纯亏损。第三笔是合规账：微信对小程序内的 UGC 内容有明确审核要求，从大模型接口拿到的文本必须先过一遍内容安全检测才能展示给用户。

还有一个技术约束很容易被忽略：小程序端不能直接调用云端模型接口，必须经过你自己的服务端中转。原因是小程序的请求域名必须是备案过的 HTTPS 域名，而且前端直接放模型接口的密钥等于裸奔，AppSecret 一旦被扒出来，损失不可控。所以走这条路的源码，前端和后端是两套工程，前端 zip 里通常只保留了调你服务端接口的部分。如果拿到手的 zip 只有一个纯前端项目，那它大概率没有接模型接口，别被说明文档里的“AI 生成”字样带偏了。

三条路线的对比如下，选型时只看自己手上的资源：

3.4 一套可复现的 JavaScript 核心实现与参数调节

不管源码里采用哪种路线，生成函数的核心逻辑都是相通的。下面这份代码实现了“词库组合+重字过滤+韵脚归一化”的最小可用版本，可以直接放进小程序的 utils 目录里，或者复制到 Node 环境里做验证。

// utils/acrostic.js // 诗词库结构：首字 -> 候选句数组，每句带韵脚分组和热度权重 const POETRY_LIB = { '林': [ { text: '林间新绿一重重', rhyme: 'ong', hot: 80 }, { text: '林风拂面送清凉', rhyme: 'ang', hot: 60 }, ], '风': [ { text: '风起云扬万里程', rhyme: 'eng', hot: 90 }, ], }; // 韵脚分组表：句尾字按韵母粗分组，够用即可，不用做到诗韵全集 const RHYME_GROUP = { a: 'a', ia: 'a', ua: 'a', o: 'o', e: 'o', uo: 'o', i: 'i', ü: 'i', u: 'i', ai: 'ai', uai: 'ai', ei: 'ei', ui: 'ei', ao: 'ao', iao: 'ao', ou: 'ou', iu: 'ou', an: 'an', ian: 'an', uan: 'an', en: 'en', in: 'en', un: 'en', ang: 'ang', iang: 'ang', uang: 'ang', eng: 'eng', ing: 'eng', ong: 'eng', }; function normalizeRhyme(ending) { // 取句尾字的拼音韵母，映射到粗分组，找不到就原样返回 return RHYME_GROUP[ending] || ending || ''; } function buildAcrostic(name, options = {}) { const { lines = 4, fallbackChar = '福' } = options; const chars = [...name].slice(0, lines); // 名字不足四字时，补齐兜底字 while (chars.length < lines) { chars.push(fallbackChar); } const usedEndings = []; const usedChars = new Set(); const result = []; for (let i = 0; i < lines; i++) { const ch = chars[i]; if (usedChars.has(ch)) { // 重字时换用同组候选句，避免两句句首相同 result.push(`${ch}气东来满乾坤`); continue; } usedChars.add(ch); const candidates = POETRY_LIB[ch] || []; // 优先取热度高、且句尾韵脚不与前文重复的句子 const viable = candidates.filter((c) => { const rhyme = normalizeRhyme(c.rhyme); return !usedEndings.includes(rhyme); }); const pool = viable.length > 0 ? viable : candidates; const picked = pool.sort((a, b) => b.hot - a.hot)[0]; if (!picked) { result.push(`${ch}华正茂展宏图`); } else { usedEndings.push(normalizeRhyme(picked.rhyme)); result.push(picked.text); } } return result; } module.exports = { buildAcrostic, normalizeRhyme };

这段代码的核心逻辑分四步：先把用户输入的名字拆成单个字符，不足四句时用兜底字补齐；然后逐字查诗词库，过滤掉句尾韵脚与前面重复的候选；再按热度权重排序，取最优句子；查无此字时，落到模板兜底。参数lines控制生成句数，fallbackChar控制名字不足时的补位字，改成'安'、'乐'都行，但要注意兜底字本身也要避开和名字字重复。

重字处理单独拎出来说明：名字里如果带重复字，比如“林林”，第二句会直接走兜底分支。有一种更优雅的做法是为每个字准备多组候选，重字时取另一组，避免句首连续重复。诗词库的热度字段hot是给高频名字用的，常见做法是把“伟、芳、娜、敏、静”这类名字高频字的热度整体调高，让常用名优先命中更通顺的句子，这个技巧在最后一章还会展开。

4. 在开发者工具里把它跑起来：从解压到真机预览的四个关键配置

4.1 解压后先改这三个地方：AppID、项目根目录与调试基础库

从 zip 解压出来的目录，第一件事不是急着看代码，而是导入微信开发者工具。导入时选择目录，工具会提示你填写 AppID，这里可以先用测试号，不影响本地开发；真机预览时再换成你自己申请的小程序 AppID。这三个配置项，我建议按顺序检查：

# 开发者工具导入项目时重点确认三个位置 project.config.json # appid 字段、miniprogramRoot 字段 app.json # pages 数组、window 配置 sitemap.json # 索引配置，不影响本地调试

project.config.json里的miniprogramRoot经常是坑。有的源码把小程序代码放在根目录，有的放在miniprogram/子目录下，如果开发者工具提示“找不到 app.json”，九成是miniprogramRoot指向不对。把miniprogramRoot改成"miniprogram/"或者删掉字段让工具重新识别即可。调试基础库版本也值得确认：太老的基础库不支持某些新 API，太新的基础库可能和源码里的旧写法不兼容。我一般选一个当前稳定版本，跑通后再说。

4.2 打通“输入名字→请求后端→展示诗词”的完整链路

跑通的关键是理解数据的流向。输入页拿到用户填写的名字，经过校验后，要么直接调用前端生成函数，要么把名字 POST 到服务端接口，拿到结果后跳转到结果页。结果页在onLoad里通过options读取名字和诗文本，再用setData渲染到 WXML。

// pages/result/result.js Page({ data: { name: '', lines: [] }, onLoad(options) { const name = decodeURIComponent(options.name || ''); const lines = (options.lines || '').split('|').filter(Boolean); if (lines.length === 0) { // 兜底：本地重新生成 const { buildAcrostic } = require('../../utils/acrostic'); const generated = buildAcrostic(name); this.setData({ name, lines: generated }); } else { this.setData({ name, lines }); } }, });

注意这里我把诗文本用|分隔放进 URL 参数，避免中文和特殊字符在分享链路上被截断；进入结果页后如果参数缺失，再走一次本地生成作为兜底。跳转前记得对用户输入做长度校验，名字超过四个字就不要硬生成，常见做法是弹出提示让用户缩短。页面跳转代码一般是wx.navigateTo({ url: '/pages/result/result?name=' + encodeURIComponent(name) + '&lines=' + lines.join('|') })，其中lines在本地生成时可拿到，在后端生成时等接口返回后再拼。

4.3 把 request 封装成可复用模块：超时、错误码与加载状态

源码里如果走接口请求，wx.request绝对不能被到处裸写。我见过一个翻车例子：作者在三个页面里各写了一份请求逻辑，超时时间不一致，结果用户在一个页面等十秒才报错。正确做法是封装成一个统一的请求模块：

// utils/request.js function request(url, { method = 'GET', data = {}, timeout = 10000 } = {}) { return new Promise((resolve, reject) => { wx.request({ url, method, data, timeout, success(res) { if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data); } else { reject(new Error(`HTTP ${res.statusCode}`)); } }, fail(err) { reject(err); }, }); }); } // 组件里统一用法 const { request } = require('../../utils/request'); request('https://api.example.com/acrostic', { method: 'POST', data: { name: '林风' }, }) .then((res) => { console.log('生成成功，句子数量：', res.lines.length); wx.navigateTo({ url: '/pages/result/result?name=林风&lines=' + res.lines.join('|') }); }) .catch((err) => { wx.showToast({ title: '生成失败，请重试', icon: 'none' }); });

这个封装解决三个问题：统一超时时间，默认 10 秒，弱网环境自动失败而不是无限转圈；统一错误码处理，任何非 2xx 状态码都会进入 reject；统一加载状态入口，在组件里调wx.showLoading或wx.showNavigationBarLoading即可。参数timeout按需调整，接大模型接口建议拉到 15 秒以上，因为模型推理本身就慢；接自己的服务端则保持 10 秒以下，宁可失败重试也不要让用户干等。

4.4 真机预览与正常请求：域名白名单、HTTPS 与开发环境不一致

开发者工具里默认勾选了“不校验合法域名”，所以你在本地怎么请求都顺畅，但一旦切到真机预览，所有未配置的域名请求全部失败，报错长得很像网络错误。这是藏头诗小程序源码里最常见的“开发环境正常、部署环境翻车”问题。

解决路径是固定的：去微信公众平台后台，在“开发管理→服务器域名”里把 request 合法域名配上，域名必须是备案过的 HTTPS 域名，不能带路径。在小程序代码里把 http:// 的请求地址全部改成 https://，否则真机直接拦截。开发阶段临时调试可以勾选“不校验合法域名”跑通流程，但提交审核前必须把勾去掉，否则审核会以“含未配置合法域名的请求”为由驳回。

注意：本地调试通过只能证明页面逻辑没问题，域名与证书问题只有真机或预览二维码能暴露。提交审核前，至少用预览版在真机上完整走一遍生成链路。

5. 避坑清单：藏头诗小程序做内容生成的五个高频翻车点

5.1 “生成的不是诗”——韵律缺失的排查与最小校验方案

现象：句首字确实对上了，但用户反馈“读起来不像诗”，仔细一看，两句尾字完全相同，而且平仄混乱。原因：生成逻辑只做了首字匹配，没有做句尾去重和押韵筛选，词库里本身也缺韵律标注。

解决：在生成函数中强制加两步校验。第一步是句尾字去重，重复时重选候选句；第二步是按韵母粗分组做押韵判断，前文第三章里那段代码已经实现了normalizeRhyme，这里再补一个最小判断函数：

function isRhymeValid(lines, minSame = 2) { // 取每句最后一个字的拼音韵母，统计归属同一粗分组的个数 const groups = lines.map((line) => normalizeRhyme(getEndingRhyme(line))); const count = {}; groups.forEach((g) => { count[g] = (count[g] || 0) + 1; }); const maxSame = Math.max(...Object.values(count)); return maxSame >= minSame; }

参数minSame表示至少要有几句押同一个韵，对四句诗来说设成 2 比较稳妥，要求四句全押会大幅降低候选可用率。加了这个校验后，生成结果的观感会明显提升，代价是偶尔会触发候选不足，需要把fallbackChar的兜底句子也纳入韵脚标注。

5.2 “真机上输入框弹不出键盘”——页面层级与输入框遮挡排查

现象：开发者工具里输入框正常，真机上点击输入框没有反应，或键盘弹出来把结果按钮完全挡住。原因：输入框被某个绝对定位的容器遮住了，或者input组件的adjust-position属性没有开启。

解决：检查 WXML 里输入框是否被其他元素遮挡，常见元凶是分享按钮的悬浮容器和cover-view的层级问题。输入框加上adjust-position="{{true}}"，让键盘顶起页面；结果页不要用position: fixed的底部按钮，改成常规文档流，让系统自动处理滚动。真机上还有一类玄学问题是低版本基础库对input的cursor-spacing支持不一致，建议统一加cursor-spacing="20"保证光标离键盘边缘有足够间距。

5.3 “开发者工具正常，真机请求全部失败”——域名白名单与证书问题

现象：开发者工具里请求正常返回，扫预览码到真机上，接口全部报 fail，控制台看不到具体错误。原因：八成是合法域名没配，两成是 HTTPS 证书不受信任或域名未备案。

解决：打开微信公众平台后台，在服务器域名里加白名单；确认证书链完整，用浏览器直接访问接口地址，看有没有证书警告；确认域名完成 ICP 备案后再提交审核。如果临时要在没有证书的环境下联调，只能借助开发者工具的“不校验合法域名”开关，但这条路径只适合开发阶段，不适合生产。

5.4 “名字里的生僻字把整首诗毁了”——字库缺失与谐音兜底

现象：用户名字里有一个“祎”字，诗词库里没有这个首字的候选句，生成结果直接落到模板兜底，读起来和名字毫无关联。原因：诗词库只覆盖了高频名字字，没有覆盖生僻字和异体字。

解决：建一个谐音映射表，把生僻字映射到常用同音字，再按映射字去查诗词库。比如“祎”映射“一”，“翀”映射“春”。生成时优先用原字，查不到再用映射字。这个技巧能一次性救回不少冷门名字的生成质量，但要注意两点：映射字与原字必须同音，否则用户一眼看出问题；如果原字和映射字都查不到，才允许模板兜底。对冷门名字，与其生成一首烂诗，不如提示用户“换个常用字试试”。

5.5 “文案被判定违规”——内容安全接口与敏感词拦截

现象：用户输入的名字本身没什么问题，但生成结果中某个字组合在一起被内容安全接口拦截，或者审核时被驳回。原因：诗词库里有大量从公开数据清洗来的句子，里面可能包含敏感字组合；用户输入的名字也可能带特殊字符或敏感字。

解决：在用户输入入口就做一层过滤，只允许中文、长度限制在 2-4 个字，特殊字符直接拦截；在内容展示前，调用微信提供的内容安全能力做检测，检测不通过就重新选候选句或提示用户重试。对从公开网络收集的诗词库，建议洗数据时先跑一遍敏感词匹配，把命中的句子直接从库里删掉，而不是运行时再拦截。运行时拦截虽然有效，但每次都浪费一次请求，删库是一劳永逸。

6. 把“能跑”变成“好用”：诗词库权重、本地缓存与分享场景的落地技巧

6.1 给诗词库加权重：让高频名字命中更优诗句

生成算法本身再优化，也抵不过词库质量。一个可落地的做法是给每条候选句加一个hot权重字段，维护时不是手工打分，而是记录真实线上数据：被选中的句子权重加 1，被用户手动“换一句”的句子权重减 1。运行一段时间后，词库会自动向高频好句倾斜。第一次发布时权重可以按句式通顺度粗设，后续让数据来修正。

6.2 用本地缓存减少重复生成请求

藏头诗是低频工具，但用户往往会对同一个名字反复生成好几次，直到刷出满意的作品。在本地用wx.setStorageSync缓存最近生成记录，键用名字，值用句子数组加时间戳，同一个名字在半小时内再次请求时，先读缓存再请求接口。这样既省接口流量，又让结果页秒开。异步生成场景要注意，缓存读到的可能是旧版本词库的产物，所以缓存里要带一个词库版本号，版本升级时自动失效。

const CACHE_KEY = 'acrostic_cache_v1'; const CACHE_TTL = 30 * 60 * 1000; // 30 分钟有效期 function getCached(name) { const data = wx.getStorageSync(CACHE_KEY) || {}; const hit = data[name]; if (hit && Date.now() - hit.ts < CACHE_TTL) return hit.lines; return null; }

缓存这块有个细节：不要把整首诗的大字符串存进去，存lines数组即可，渲染层面更灵活，也方便在分享卡片里重新拼接。

6.3 让用户愿意用第二次：生成记录与分享卡片

做内容生成类小程序，留存的关键往往不在算法而在分享路径。藏头诗天然适合分享：用户生成一首自己名字的诗，分享出去的卡片本身就是内容。实现onShareAppMessage，让卡片标题带上名字和第一句诗的预览，别人点进来直接从结果页开始，而不是又回到输入页空等。同时在本地维护一个“最近生成”列表，展示用户历史生成的诗句，复访率明显比冷启动好。

我早期做这类项目时，把精力全压在生成算法上，想让诗更有文采，结果用户反馈里提得最多的是分享卡片不好看、生成结果加载慢。后来我把算法冻结，专注打磨结果页的渲染和分享链路，留存反而上来了。藏头诗这种轻工具，用户要的是“快”和“美”，不是“格律精妙”。先让流程顺畅，再谈文本质量，这个顺序希望帮到你。

本文还有配套的精品资源，点击获取