上周我的“剧本快读”小程序终于过审上架了。从立项到收到审核通过的邮件，全程用 WorkBuddy 打底，真正从零写出一个能跑、能看、能发布的微信小程序。整个过程比我想象中顺，但踩坑也比我预想中多。这篇就把完整开发记录和踩坑清单整理出来，给准备用 WorkBuddy 做小程序、或者正在做类似工具类小程序的朋友做个参考。
先说清楚我做的这个小程序是干嘛的：剧本快读，一个帮你“快速读完一个剧本”的阅读工具。内置一批经典剧本的结构化拆解，包含角色表、剧情脉络、关键场景、台词高亮，还有阅读进度记录。用户打开小程序，选一个剧本，就能按“速读模式”逐段刷剧情，或者切到“精读模式”看原文片段和批注。定位很轻，不搞社区、不搞创作，就是纯粹的阅读工具。
1. 项目定位与工具选型：为什么用 WorkBuddy 做小程序
1.1 这个项目要解决什么问题
写剧本和读剧本的人其实都有一肚子苦水：剧本不像小说，它天生是给“排演”用的，不是给“阅读”用的。普通读者打开一个剧本，面对密密麻麻的角色名、场景名、舞台指示，第一反应往往是劝退。尤其经典剧本动辄几万字，信息密度又高，很多人翻几页就放弃。剧本快读的思路，就是把每个剧本拆成“可速食”的结构化内容：谁、在哪、发生了什么、这句台词为什么重要，全部提前标注好，读者不用从头啃原文也能快速抓住故事主线。
这个定位决定了小程序的功能边界：不追求大而全，只做“拆解+阅读+记录”三件事。这个克制非常关键，因为小程序审核、性能、开发量都有限，功能越杂，后面越痛苦。
1.2 为什么偏偏选 WorkBuddy
市面上做小程序的方案不少，原生开发、各种低代码平台、AI辅助编码工具我都试过。最后选 WorkBuddy，主要是因为三点。
第一，它能帮我处理“结构化内容生成”这部分最繁琐的活。剧本拆解需要大量人工整理，一个剧本几万字，拆成角色表、场景表、事件线，手工做能累死人。WorkBuddy 可以根据我给的剧本原文，自动生成结构化的拆解数据，我只需要校对和微调。这个能力直接决定了我能不能在两周内把内容库做出来。
第二，它把“设计→开发→预览”的链路压缩了。在 WorkBuddy 里，我描述页面需求，它生成对应的小程序页面代码，然后我可以直接在配套的开发者工具里预览效果，改设计比传统方式快不少。
第三，它对微信小程序生态的适配度比较高。生成的代码直接兼容微信开发者工具，不需要做大量二次改造。这一点看起来不起眼，实际用过就知道，很多AI编码工具生成的页面在小程序环境里根本跑不起来，改到怀疑人生。WorkBuddy 在这一点上帮我省掉了大量返工。
注意：我不是说 WorkBuddy 是万能的。它的优势在于“快速产出结构清晰、逻辑简单的工具类小程序”，如果你要做重度交互、实时通信、复杂动画的产品，它不一定是最优选。选工具得看项目类型，别盲目跟风。
2. 需求拆解与内容设计：开工前先把“地基”打牢
2.1 功能清单：小程序的骨架怎么定
动手写代码之前，我先用 WorkBuddy 把需求拆成了一页功能清单。这个环节不建议跳，越是能用工具快速生成的东西，越要先想清楚自己要什么。
最终定下来的功能分三层：
- 核心阅读流：剧本列表 → 剧本详情 → 速读模式（按章节/事件刷）→ 精读模式（原文+批注）
- 辅助功能：阅读进度自动记录、角色关系速览、关键台词收藏
- 基础能力：微信登录、意见反馈、关于页面
所有功能加起来，总共五个主要页面：首页（剧本列表）、剧本详情页、阅读页（速读/精读二合一）、角色关系页、我的页面。页面不多，但每个页面的信息结构都需要仔细设计，因为剧本类内容的阅读体验，拼的就是信息排布。
2.2 数据结构：一个剧本在代码里长什么样
内容类小程序的核心资产是内容，而内容的灵魂是数据结构。这个项目里，我用 WorkBuddy 辅助设计了全套数据模型，最核心的就是“剧本对象”。每个剧本在数据库里存这样一份结构：
{ "id": "hamlet", "title": "哈姆雷特", "author": "莎士比亚", "description": "丹麦王子为父复仇的悲剧", "roles": [ { "name": "哈姆雷特", "desc": "丹麦王子", "importance": 1 }, { "name": "克劳狄斯", "desc": "现任丹麦国王", "importance": 2 } ], "acts": [ { "actNo": 1, "title": "第一幕", "scenes": [ { "sceneNo": 1, "location": "埃尔西诺城堡城墙上", "summary": "守夜人遇见鬼魂，怀疑先王冤死", "lines": [ { "role": "勃那多", "text": "谁在那儿？", "note": "开场即营造紧张氛围" } ] } ] } ], "timeline": [ { "event": "鬼魂显现", "act": 1, "scene": 1, "impact": "复仇动机建立" } ] }这个结构不是一次成型的，我前后调了两轮。第一版做得太细，把每句台词都拆成独立对象，结果数据量爆炸，小程序端渲染卡顿；第二版改成“场次”为最小展示单位，台词数组内嵌在场景里，性能问题立刻缓解。这里有个经验：数据结构一定要跟着“页面怎么渲染”走，别按“内容本身多丰富”走。
2.3 内容库的批量生产：让 WorkBuddy 当我的“拆书编辑”
内容库是最耗时的部分。一个剧本从原文到结构化数据，如果纯手工整理，一个剧本至少三四个小时。我当时的做法是：把公版剧本原文分段喂给 WorkBuddy，让它按我定义的 JSON 结构输出拆解结果。
这个流程跑顺之后，一个剧本的处理时间压缩到四十分钟左右，其中大部分时间是我在检查它拆得对不对，而不是从零开始整理。有一个技巧分享一下：不要一次把整个剧本全丢进去，一次只喂一幕，并且给它明确的输出模板。你给 WorkBuddy 的约束越明确，它输出内容的可用率越高。第一次我图省事，把整本《雷雨》一次性丢进去，结果它拆到第三幕就开始漏角色，完全没法用；改成逐幕处理之后，基本就稳定了。
提醒：使用 AI 工具辅助生产内容时，版权问题要提前想清楚。我全部选择了公版剧本（作者去世超过50年，版权已进入公共领域），并且做了二次结构化创作，这样上架审核和后续运营都没有版权风险。不要拿受版权保护的剧本原文直接做内容库，这不是技术问题，是安全问题。
3. 开发实录：从 WorkBuddy 生成代码到小程序跑起来
3.1 环境准备和项目初始化
开发环境这部分比较常规，但还是有一个容易忽略的点。我用的是微信开发者工具 + WorkBuddy 的代码生成能力。初始化项目时注意，你在 WorkBuddy 里创建项目选择的模板，会直接影响后续生成的代码风格，建议选“微信小程序原生”模板，而不是某些通用H5模板，否则生成出来的组件会带一堆 DOM 依赖，小程序环境里跑不了。
另外，我在项目根目录里提前建好了几个目录：pages（页面）、components（自定义组件）、utils（工具函数）、data（本地JSON数据）。虽然 WorkBuddy 会自动生成目录，但预先把目录结构规划好，后面找代码、改代码会舒服很多。
项目初始化后，我做的第一件事不是写页面，而是先把全局配置app.json检查一遍。这个文件决定了小程序的窗口表现、页面注册、TabBar 等基础行为。我在这里踩了一个小坑：注册页面时漏掉了“角色关系页”，结果开发时直接跳转报错，页面找不到。这种低级错误，新手很容易遇到，检查app.json里的pages数组是否包含所有页面，是每次新增页面后的必做动作。
3.2 用 WorkBuddy 生成核心页面：从需求描述到可用代码
这个阶段，我基本上就是在“描述需求 → 生成代码 → 微调样式 → 真机预览”这个循环里度过。拿首页举例，我给 WorkBuddy 的需求描述大概是：“首页顶部显示小程序名称，下面用卡片列表展示剧本，卡片包含封面、标题、作者、简介摘要和阅读进度条，点击卡片跳转到详情页。”
它生成的代码直接可运行，但样式比较朴素。我做了两处手动调整：一是封面图尺寸从固定像素改成了按屏幕宽度自适应，保证不同机型上不拉伸；二是列表加了“已读/未读”状态角标，提升完成感。整体来说，代码质量和可维护性比我预期高，尤其是页面生命周期处理和 data 绑定这块，几乎没有返工。
阅读页是整个小程序最复杂的页面，也是我花时间最多的部分。速读模式和精读模式共用同一个页面，通过 Tab 切换。速读模式按“场次”为单位展示：场景标题、地点、事件摘要、关键台词；精读模式则展示更多原文内容和批注。
这个页面的代码结构，WorkBuddy 生成的初版基本能用，但我在两个点上做了重构：
- 滚动定位：速读模式下，切换场次时页面需要滚动到顶部，我加了
scroll-view的scroll-top控制； - 阅读进度保存：每次离开页面时，记录当前场次ID和阅读百分比，存到本地缓存；下次进入时恢复位置。
这两块代码量不大，但细节多，如果你是新手，建议重点关注onHide和onUnload生命周期里的状态保存逻辑。很多人只做onLoad的数据加载，忽略了中途退出页面的情况，导致进度丢失，用户用一次就不想用第二次。
3.3 数据接入：本地 JSON 起步，后续平滑迁移云开发
小程序的数据接入，我分了两个阶段。第一个阶段，所有剧本数据以 JSON 文件形式放在data目录下，页面直接通过require引入。这个方案的好处是零门槛、不需要后端、审核简单，本地就能跑通全部功能。对内容量不大的工具类小程序，这个方案完全够用。
第二个阶段，等产品稳定后，我再把数据迁移到微信云开发。迁移时需要注意，本地require是同步加载，云开发数据库是异步读取，所有调用处都要改成 Promise 或 async/await 写法。这个改造虽然不复杂，但涉及页面较多，还是建议提前规划好数据访问层，把所有读取操作封装成统一函数，而不是散落在各个页面里。
3.4 预览调试：为什么我坚持用“真机调试”而不是模拟器
开发过程中，WorkBuddy 的配套预览能快速看效果，但最终发布前，一定要用微信开发者工具的真机调试。原因很实际：模拟器里的渲染结果和真机差距非常大，尤其是字体大小、安全区适配、底部 TabBar 高度这些细节。
我遇到的典型问题是，模拟器里一切正常，真机上阅读页的底部操作栏被 iPhone 的 Home 指示条挡住。解决办法是给操作栏加上padding-bottom: env(safe-area-inset-bottom)，并设置适配高度。这个兼容问题几乎每个小程序开发者都会碰到，早适配早省心。
4. 审核与上架：真正的手续细节比写代码更磨人
4.1 小程序类目选择：这一步很影响审核速度
上架前需要在小程序后台配置类目。我把“剧本快读”选在了“工具 → 信息查询”类目下，因为这个应用的核心功能就是提供结构化的信息阅读服务，不涉及内容创作、社交互动。类目选错了会被打回，而且来回沟通很浪费时间。你可以参考同类产品是怎么选类目的，但别直接抄，得结合自己产品的实际功能边界来判断。
工具类小程序对内容审核相对严格的是：有没有“用户生成内容”（UGC）功能。剧本快读里没有任何让用户发帖、评论、上传的功能，所以审核的复杂度和风险都低了不少。如果产品里有UGC，就得额外做内容安全审核机制，这意味着要接入内容安全接口，开发量完全不是一个量级。
4.2 用户隐私保护：别等审核被拒才补协议
这个小程序用了微信登录获取用户头像和昵称，所以必须在后台配置“用户隐私保护指引”，明确说明收集了什么信息、用来做什么、如何注销账号。我第一次提交时以为这些可以从简，结果直接被拒，理由就是“未声明用户信息的收集和使用规则”。
有两种做法可以规避这个问题：一是如果产品不需要用户信息，就不调wx.getUserProfile，直接用wx.login静默登录获取一个 openid 做身份标识，内容类阅读工具完全够用；二是必须获取头像昵称时，提前把隐私声明写好，并确保页面上有“用户协议”和“隐私政策”的入口链接，不能只在设置里放，首页底部通常要放一行小字链接。
我最终选择了不获取头像昵称的方案，只保留 openid 作为标识。用户不需要授权弹窗，体验也更顺滑。这个权衡建议你认真评估一下：很多产品要头像昵称只是“想要”，不是“必要”，砍掉一个授权步骤，对用户转化率是有正收益的。
4.3 提审前的自查清单
整理一份我在提交审核前过一遍的清单，基本能覆盖大部分被拒原因：
- 所有页面能正常打开，没有空白页和报错
- 所有外链图片有固定域名，且已经配置到后台的“业务域名”里
- 没有强制用户授权才能使用的功能
- 有用户协议和隐私政策入口
- 页面底部没有“测试”“beta”等字样
- 基础库版本选择了合理的下限，不要默认最高版本导致老机型打不开
5. 踩坑清单：这些坑我替你踩过了
5.1 内容生产环节的坑：全量输入、输出格式不稳定
第一个坑：一次喂给 WorkBuddy 的剧本内容过长，导致输出结果质量严重下降，角色漏拆、场景合并错乱。解决方法是化整为零，一次只处理一幕，并且给一个明确的JSON输出模板，要求它严格按模板输出，不要自由发挥。
第二个坑：它生成的 JSON 偶尔会出现字段缺失，比如漏掉impact字段，导致前端渲染时读取undefined。解决思路是在数据入库存前，跑一个校验脚本，检查每条数据的必填字段是否齐全。这个校验脚本我花了十分钟写，但每天不知道帮我省了多少排查时间。
5.2 小程序开发环节的坑：点击事件失效、样式兼容
第三个坑：列表页的点击事件偶发失效。排查很久发现是某些卡片层级被一个绝对定位的装饰元素盖住了，点击事件被拦截。解决方法是把装饰元素加上pointer-events: none，或者调高卡片的z-index。这种问题在模拟器里特别难复现，真机上特别容易出现，排查时优先检查定位元素的层级关系。
第四个坑：字体大小适配。速读模式的正文默认设置了16px字号，在部分 Android 机型上字体显示异常偏大，阅读体验很差。原因是用户系统字体缩放设置影响了小程序内字体渲染。解决办法是给阅读页根节点设置max-width: 100%，并主动用wx.getSystemInfo读取fontSizeSetting，根据缩放比例动态调整页面字号。
5.3 审核环节的坑：类目不符和隐私协议问题
第五个坑：第一次提交审核被拒，理由是“类目与功能不符”。当时我试图把产品定义为“教育”，结果审核人员认为核心功能是阅读工具，应该选工具类目。不要为了看起来“高级”而乱选类目，审核人员的判断标准看的是你的实际功能，不是描述文案。
第六个坑：用户隐私保护指引里的“收集的信息类型”必须与实际调用的 API 一一对应。我最初漏掉了“设备信息”这一项，因为当时调用了wx.getSystemInfo获取系统信息来适配字体大小，这就属于收集设备信息，必须在隐私指引里声明。不声明就是被拒，没有例外。
5.4 一个特别值得说的坑：云开发环境的权限设置
第七个坑：我最早测试阶段把云开发数据库的权限设成了“所有用户可读”，开发时确实方便，但上线前忘了改。这意味着任何人都可以通过开放接口读取数据库全量数据，包括一些不需要公开的内部数据。上线前一定要进云开发控制台，把权限改成“仅创建者可读写”或自定义安全规则。
这个坑危害很大，因为流量小的时候没人注意到，等有流量了数据就裸奔了。安全这根弦，任何时候都得绷着。
6. 写在最后的几点体会
项目上线后，我复盘了整个流程，有几个体会想分享。
WorkBuddy 在这次开发里扮演的角色，更像是一个“无限加班、不抱怨、上手快”的初级开发，它帮我生成了大量结构化的页面代码和内容数据，省掉了最耗费精力的重复劳动。但整个项目的核心决策——产品定位、数据结构设计、审核策略、安全边界——全部是我自己拿的主意。工具可以压缩执行成本，但替代不了思考本身。
另外，从零开始做一个上架的小程序，难度被很多人高估了，也被一些人低估了。说高估，是因为选对工具、用对方法后，一个功能明确的小工具类小程序真的可以在两三周内做出来；说低估，是因为那些看似不起眼的坑——类目配置、隐私协议、安全区适配、权限设置——每一个都可能在最后关头绊你一下。这些坑不会让项目“做不出来”，但会让项目“上不了架”，或者上线后漏洞百出。
最后说一个扩展方向。剧本快读目前是纯阅读工具，数据量有限，第一批只内置了十个经典剧本。后续版本我打算接入云开发，支持用户上传自己的剧本文本，自动生成结构化拆解。那时候就需要在 UGC 内容审核和反垃圾机制上投入更多精力了。如果你也有类似的工具类小程序想法，我的建议是：先跑通一个最小可用的闭环上架，再考虑做复杂功能。上架不是终点，是另一个起点。
剧本快读这个项目让我重新认识了“小步快跑”四个字的分量。没有一次成型的产品，只有不断迭代的版本。希望在读这篇记录的你，也能少踩几个坑，更快把自己的第一个小程序送上线。
