1. 为什么我选择从零做一个剧本快读小程序
去年年底，我手上攒了十几个短剧和剧本的文本文件，每次想快速过一遍核心情节，都得在手机备忘录和阅读器之间来回切换，体验非常割裂。市面上的阅读类小程序要么功能太重，要么广告太多，要么根本不支持剧本这种特殊格式的快速浏览。于是我就想，干脆自己做一个。正好那段时间在用一个叫 WorkBuddy 的低代码开发工具，就决定拿它来练手，从零做一个“剧本快读”微信小程序，目标很明确：能快速导入剧本文本、按角色和场景拆分、支持一键速读核心情节，并且能顺利上架。
这个项目从构思到上架大概花了三周左右的业余时间，中间踩了不少坑，也积累了一些低代码开发微信小程序的实战经验。如果你也是那种有点想法但不想从零写原生代码的人，或者你手头正好有一堆剧本、小说、长文需要快速拆解阅读，那这篇记录应该能帮你省下不少试错成本。我会把整个开发流程、关键配置、踩坑清单都摊开来讲，尽量做到你照着做就能复现。
WorkBuddy 这类工具的核心价值在于，它把微信小程序的注册、开发、调试、上传、审核这一整条链路做了封装，你不需要配环境、不需要懂 WXML 和 WXSS 的底层细节，只需要关注业务逻辑和界面布局。但低代码不等于无代码，有些地方你还是得懂一点小程序的基本规则，否则审核被拒的时候会一脸懵。下面我就按实际开发顺序，从整体设计、核心功能实现、上架流程、踩坑排查几个维度来展开。
2. 剧本快读小程序的整体设计与技术选型
2.1 核心需求拆解与功能边界划定
做任何工具之前，先想清楚它到底解决什么问题。剧本快读的核心场景是：用户手里有一段剧本或长文本，想快速知道谁在什么场景下说了什么、情节怎么推进的。所以功能优先级是这样的：
- 文本导入：支持粘贴文本、从聊天记录导入、从本地文件读取（小程序环境下文件读取有限制，后面会讲）。
- 角色识别与拆分：自动识别“角色名：台词”这种格式，把对话和旁白分开。
- 场景提取：识别“场景一”“内景”“外景”等关键词，把剧本按场景切分。
- 速读模式：只显示角色名和台词首句，或者只显示场景标题和关键动作，让用户几秒钟过完一场戏。
- 本地存储：用户导入的剧本要能保存在本地，下次打开还能继续看。
功能边界也很重要。我一开始想加语音朗读、角色关系图、多端同步，后来发现这些要么超出低代码工具的能力范围，要么会拖慢上架进度。所以第一版只做最核心的四个功能：导入、拆分、速读、本地保存。这个取舍很关键，低代码开发最怕贪多，功能越少，上架越快，后续迭代也越灵活。
2.2 为什么选 WorkBuddy 而不是原生开发或其它平台
原生开发微信小程序需要掌握 WXML、WXSS、JS、JSON 配置，还要处理登录、存储、网络请求等一堆 API。对于一个业余项目来说，学习成本和时间成本都太高。其它低代码平台我也试过几个，有的偏向电商模板，有的对文本处理支持很弱，有的生成的小程序包体积超标直接传不上去。
WorkBuddy 吸引我的点在于：它提供了可视化的页面编辑器，同时允许我插入自定义的 JavaScript 逻辑来处理文本解析；它内置了微信小程序的登录、存储、分享等常用能力，不用自己从头写；最重要的是，它生成的小程序代码包比较干净，没有太多冗余模块，包体积容易控制在 2MB 以内（微信小程序主包的限制）。实测下来，用 WorkBuddy 做出来的剧本快读小程序，主包只有 1.3MB 左右，留了不少余量给后续加功能。
当然它也有局限。比如它不支持直接调用微信小程序的某些底层 API，像文件系统的读写就受限；再比如它的自定义组件生态不如原生丰富，有些复杂交互得自己用基础组件拼。但这些对于剧本快读这个场景来说，影响不大。
2.3 数据存储方案的选择与取舍
剧本文本可能很长，一个剧本动辄几万字。微信小程序的本地存储单个 key 上限是 1MB，总上限是 10MB。如果直接把整个剧本存成一个字符串，很容易超限。我的方案是分片存储：把剧本按场景切分成多个片段，每个片段单独存一个 key，然后用一个索引 key 记录所有片段的顺序和标题。这样单个片段不会超过 1MB，总容量也能撑到 10MB，足够存几十个短剧本了。
另外，用户导入的原始文本我也做了一层压缩：去掉多余的空格、换行、特殊符号，只保留角色名、台词、场景标记这些关键信息。实测下来，压缩后的文本体积能减少 30% 到 50%，对存储空间更友好。这个压缩逻辑是用自定义 JavaScript 写的，WorkBuddy 支持在页面事件里插入自定义函数，所以实现起来不复杂。
3. 核心功能实现与关键代码逻辑
3.1 文本导入与格式预处理
文本导入有三种方式：粘贴、从微信聊天记录选择文件、从本地相册旁边的文件入口选择。小程序环境下，从聊天记录选文件需要用wx.chooseMessageFileAPI，从本地选文件需要用wx.chooseMedia或wx.chooseMessageFile的变体。WorkBuddy 里可以直接在按钮的点击事件里调用这些 API，拿到文件后读取内容。
读取到的原始文本往往很脏：有全角空格、有奇怪的换行符、有复制粘贴带来的格式标记。所以第一步是清洗。我写了一个cleanText函数，主要做这几件事：
function cleanText(raw) { return raw .replace(/\r\n/g, '\n') // 统一换行符 .replace(/\u3000/g, ' ') // 全角空格转半角 .replace(/[ \t]+/g, ' ') // 多个空格合并 .replace(/\n{3,}/g, '\n\n') // 多个空行合并 .trim(); }清洗完之后，再用正则识别角色和场景。角色行的典型格式是“角色名：台词”或“角色名:台词”，冒号可能是中文也可能是英文。场景行的典型格式是“场景一”“第一场”“内景 客厅”等。我用两个正则来匹配：
const roleRegex = /^([\u4e00-\u9fa5A-Za-z0-9]{1,10})[：:]\s*(.+)$/; const sceneRegex = /^(场景|第.{1,3}场|内景|外景|日|夜)/;匹配到角色行就拆成{ role, line }对象，匹配到场景行就标记为新场景的开始。这个逻辑不复杂，但要注意边界情况：有些剧本的角色名带括号注释，比如“小明（激动地）：”，这时候正则要能处理括号。我的做法是先去掉括号内容再匹配，匹配完再把括号内容作为动作描述附加到台词后面。
3.2 角色与场景的自动拆分算法
拆分算法的核心是逐行扫描，维护一个当前场景对象，遇到场景行就新建场景，遇到角色行就往当前场景里追加对话。伪代码大概是这样：
function parseScript(text) { const lines = text.split('\n'); const scenes = []; let currentScene = { title: '默认场景', dialogues: [] }; for (let line of lines) { line = line.trim(); if (!line) continue; if (sceneRegex.test(line)) { if (currentScene.dialogues.length > 0) { scenes.push(currentScene); } currentScene = { title: line, dialogues: [] }; continue; } const match = line.match(roleRegex); if (match) { currentScene.dialogues.push({ role: match[1], line: match[2] }); } else { // 旁白或动作描述 currentScene.dialogues.push({ role: '旁白', line: line }); } } if (currentScene.dialogues.length > 0) { scenes.push(currentScene); } return scenes; }这个算法实测下来能覆盖 80% 以上的常见剧本格式。剩下的 20% 主要是那些格式特别自由的剧本，比如没有明确角色标记、全靠缩进和排版来区分对话的。对于这种情况，我在界面上加了一个“手动标记”模式，让用户长按某一行来指定它是角色行还是场景行。这个手动模式虽然麻烦一点，但至少保证了所有剧本都能被正确拆分。
3.3 速读模式的交互设计与实现
速读模式是这个工具的灵魂。用户不想看完整台词，只想快速知道这场戏里谁说了什么关键信息。我的做法是：每个角色只显示第一句台词的前 20 个字，旁白只显示前 30 个字，场景标题完整显示。用户点击某一行可以展开看完整内容，再点一下收起。
这个交互在 WorkBuddy 里实现起来很直观：用一个列表组件渲染场景和对话，每个对话项绑定一个expanded状态，点击时切换状态并控制文本的显示长度。为了性能考虑，我没有用复杂的动画，只是简单的显示隐藏切换。实测下来，即使一个剧本有几百条对话，列表滚动也很流畅。
另外，速读模式还支持“只看角色”和“只看场景”两种过滤。只看角色时，旁白和动作描述会被隐藏；只看场景时，只显示场景标题和每个场景的第一条对话。这两个过滤条件用简单的数组过滤就能实现，不需要额外的数据结构。
3.4 本地存储与数据同步策略
前面提到分片存储的方案，具体实现是这样的：每个场景存成一个 key，key 的命名规则是script_{scriptId}_scene_{index}，value 是 JSON 字符串化的场景对象。然后有一个script_{scriptId}_index的 key，存一个数组，记录所有场景的 key 和标题。最后有一个script_list的 key，存所有剧本的元信息（剧本名、创建时间、场景数量）。
读取的时候，先读script_list拿到剧本列表，用户点进某个剧本时再读script_{scriptId}_index拿到场景索引，然后按需读取场景内容。这样既避免了单次读取大量数据导致的卡顿，也方便做分页加载。实测下来，一个 5 万字的剧本，拆成 30 个场景，每个场景平均 1.6KB，总存储量在 50KB 左右，远低于 1MB 的单 key 限制。
数据同步方面，第一版没做云端同步，只做本地存储。因为云端同步需要后端服务，会增加复杂度和成本。但我在数据结构设计上留了余地：每个剧本都有一个updatedAt时间戳，后续如果要加同步功能，可以根据时间戳做增量合并。
4. 上架流程与审核避坑指南
4.1 小程序注册与类目选择
微信小程序的注册流程这里不展开，按官方指引走就行。重点说类目选择。剧本快读属于工具类应用，我选的是“工具-效率”类目。这个类目不需要额外的资质证明，审核相对宽松。但要注意，如果你的小程序涉及内容阅读，可能会被要求提供“网络文化经营许可证”或“出版物经营许可证”。我的做法是在小程序简介和页面里明确写“本工具仅用于个人文本整理与速读，不提供任何在线内容服务”，这样审核时就不会被归到内容平台类目。
另外，小程序名称和简介里不要出现“小说”“阅读”“书城”这类词，容易触发内容审核。我一开始想叫“剧本快读助手”，后来改成了“文本速读工具”，审核一次就过了。这个细节很关键，很多开发者卡在名称和简介上反复被拒。
4.2 代码包上传与体积优化
WorkBuddy 生成的小程序代码包默认会包含一些公共依赖和组件库。上传之前，我做了几件事来压缩体积：
- 删掉未使用的组件和页面，WorkBuddy 的编辑器里可以手动移除。
- 压缩图片资源，把图标都换成 SVG 或字体图标，减少 PNG 的使用。
- 开启微信开发者工具的“上传时压缩代码”选项。
- 检查有没有重复引入的库，比如多个页面都引了同一个工具函数，就把它抽到公共模块里。
优化完之后，主包从 2.1MB 降到了 1.3MB，顺利上传。这里有个经验：微信小程序主包上限是 2MB，总包上限是 20MB。如果你的主包超了，可以把一些非核心页面放到分包里。WorkBuddy 支持配置分包，但操作稍微麻烦一点，需要在它的项目设置里手动指定分包目录。
4.3 审核被拒的常见原因与应对
我一共提交了三次审核，前两次都被拒了。第一次是因为“功能不完整”，审核员说点击某些按钮没反应。排查后发现是某个页面的按钮事件绑定错了，在 WorkBuddy 里重新绑定后解决。第二次是因为“用户隐私协议不完善”，小程序里收集了用户粘贴的文本，但没有明确告知用户数据如何存储和使用。后来我加了一个隐私政策页面，说明所有数据仅存储在本地，不会上传到任何服务器，审核就过了。
第三次提交后大概两天就通过了。总结下来，审核被拒的高频原因有这几个：
| 被拒原因 | 具体表现 | 解决方案 |
|---|---|---|
| 功能不完整 | 按钮点击无响应、页面白屏 | 逐页测试所有交互，确保每个按钮都有反馈 |
| 隐私协议缺失 | 未告知数据收集和使用方式 | 添加隐私政策页面，明确说明数据仅本地存储 |
| 类目选择错误 | 工具类选了内容类 | 根据实际功能选择最贴近的类目，简介避免敏感词 |
| 代码包过大 | 主包超过 2MB | 删除未使用资源，开启代码压缩，必要时用分包 |
| 名称简介违规 | 出现“小说”“阅读”等词 | 改用“文本”“速读”“工具”等中性词 |
提示：提交审核前，一定要用微信开发者工具的“体验版”功能，让朋友帮忙点一遍所有功能。自己测试往往会有盲区，别人更容易发现按钮没反应、页面跳转错误这类问题。
4.4 上架后的数据监控与迭代
上架后我在小程序后台看了几天的数据，发现用户主要集中在晚上 8 点到 11 点使用，平均使用时长 4 分钟左右。这个数据说明用户确实是拿来快速过剧本的，不是长时间阅读。基于这个反馈，我在第二版里把速读模式的默认展开长度从 20 字缩短到了 15 字，让速读更快。同时加了一个“一键复制速读结果”的功能，方便用户把速读后的摘要粘贴到别的地方。
迭代节奏上，我建议上架后先观察一周数据，再决定加什么功能。不要一上架就急着加新东西，因为审核周期和用户反馈都需要时间。我第二版只改了两个小点，提交审核后一天就过了，对用户的影响也最小。
5. 踩坑清单与常见问题排查
5.1 文本解析中的编码与格式坑
最常见的坑是编码问题。用户从不同来源复制的文本，可能带有 BOM 头、零宽字符、软连字符等不可见字符。这些字符会导致正则匹配失败，角色行识别不出来。我的解决方案是在清洗阶段加一步：
function removeInvisibleChars(text) { return text.replace(/[\u200B-\u200D\uFEFF\u00AD]/g, ''); }另一个坑是换行符不统一。Windows 是\r\n，Mac 是\r，Linux 是\n。如果不统一，按\n分割的时候会多出空行或者把两行粘在一起。所以清洗阶段一定要先把所有换行符统一成\n。
还有一个坑是角色名识别错误。有些剧本的角色名是英文，有些是数字，有些带特殊符号。我的正则里限制了角色名长度在 1 到 10 个字符，且只允许中文、英文、数字。如果角色名超过 10 个字，或者包含特殊符号，就会识别失败。对于这种情况，我加了一个“手动修正”入口，让用户可以在解析结果里直接修改角色名。
5.2 存储超限与数据丢失的预防
前面说了单 key 1MB 的限制，但还有一个坑：微信小程序的本地存储总上限是 10MB，而且不同小程序之间的存储是隔离的。如果用户存了太多剧本，总容量超了，新的存储请求会失败。我的做法是在每次存储前先检查已用容量，如果超过 8MB 就提示用户删除一些旧剧本。检查容量的 API 是wx.getStorageInfoSync()，返回一个对象包含currentSize和limitSize。
数据丢失的另一个原因是用户清理微信缓存。小程序本地存储会随着微信缓存被清理而丢失。所以我在设置页面加了一个“导出剧本”的功能，把剧本内容转成文本文件，通过微信的分享功能发给用户自己保存。这样即使本地数据丢了，用户也能从导出的文件里恢复。
5.3 页面卡顿与性能优化技巧
剧本快读的列表页在数据量大时会卡顿。我试过几种优化方案：
- 虚拟列表：只渲染可视区域内的列表项，滚动时动态替换内容。WorkBuddy 里没有现成的虚拟列表组件，我用
scroll-view配合wx:if手动实现了一个简化版，效果不错，但代码量增加了不少。 - 分页加载：每次只加载 20 个场景，滚动到底部再加载下一批。这个方案实现简单，对用户体验影响也小，最终我选了这个。
- 减少 setData 频率：小程序的
setData是性能瓶颈，频繁调用会导致卡顿。我把多个数据更新合并成一次setData，比如展开/收起对话时，不是每点一次就更新一次，而是等用户停止操作 200ms 后再统一更新。
实测下来，分页加载加合并 setData 的方案，在 5 万字剧本下，列表滚动帧率能稳定在 50fps 以上，基本感觉不到卡顿。
5.4 审核被拒后的快速排查流程
被拒后不要慌，先看审核反馈的具体原因。微信审核反馈通常会给一个截图和一段文字说明。根据我的经验，排查顺序是这样的：
- 看截图定位页面：截图里显示的是哪个页面，就去检查那个页面的所有交互。
- 复现问题：用体验版在真机上复现，注意要用审核员可能用的机型（一般是主流安卓和 iOS）。
- 检查网络请求：如果页面依赖网络请求，确认请求是否成功、是否有超时处理。
- 检查权限：如果页面需要用户授权（如相册、位置），确认授权失败时是否有降级处理。
- 修改后重新提交：每次只改一个问题，改完立刻提交，不要攒着一起改，否则审核周期会拉长。
注意：审核被拒后，不要反复提交同样的代码。每次提交前都要确保已经解决了上次被拒的问题，否则可能被判定为恶意提交，影响后续审核优先级。
6. 一些个人体会和后续扩展思路
这个项目做下来，我最大的感受是：低代码工具确实能大幅降低开发门槛，但它不是银弹。WorkBuddy 帮我省掉了环境配置、基础组件搭建、API 封装这些重复劳动，但业务逻辑、数据结构、审核规则这些还是得自己琢磨。尤其是审核环节，低代码工具不会帮你规避审核风险，该踩的坑一个都不会少。
另外，剧本快读这个工具本身还有不少可以扩展的方向。比如加一个“角色台词统计”功能，自动统计每个角色说了多少句话、占了多少篇幅，这对演员快速了解角色戏份很有用。再比如加一个“场景地图”功能，把剧本里的场景按顺序列出来，点击跳转到对应场景，方便快速定位。这些功能在现有数据结构上都能实现，不需要大改。
如果你也想用 WorkBuddy 做一个自己的小程序，我的建议是：先做最小可用版本，上架跑通流程，再根据用户反馈迭代。不要一开始就追求功能大而全，那样很容易卡在某个技术细节上，最后不了了之。先把核心功能做出来，让用户用起来，后面的优化才有意义。
