# 2 小时写 PRD，3 天上线：我是怎么一个人手搓一个微信小程序的

> 一个出于兴趣的小项目，把"练习-许愿-兑现"做成一个可运行的闭环

上周，我用 3 天时间，一个人把一个微信小程序从一行代码写到了上线可运行。

不是工作项目，纯粹是兴趣使然。我侄子今年上小学二年级，每天回家做口算题都很痛苦——一页纸、一支笔、二十道题，做着做着就走神。身边一位长辈今年六十七，去年体检医生让她"多动动脑，预防老年痴呆"，但她对市面上的脑力 App 完全不感冒。

我就想：能不能做一个东西，让"练习"这件事既对孩子有吸引力，又对老人有参与感？

3 天后，"心算小目标"上线了。这篇文章想跟你聊聊，我从下午 3 点的一个想法到晚上 11 点看到第一个用户跑通完整流程，中间是怎么过的。

## 一、PRD 写了 2 小时，但决定了我后面 3 天的路径

很多人觉得"写 PRD 浪费时间，先写代码再说"。我试过几次这种节奏，结果都是写到一半发现要重构。

这次我刻意先停了一下，下午 3 点开始写 PRD，晚上 5 点写完。核心就回答了 4 个问题：

1. **做给谁？** 两个人群——小学生（让练习有点"盼头"）+ 银发老人（在陪练中找到参与感）。
2. **解决什么问题？** 孩子练习枯燥没动力，老人动脑训练没人陪。
3. **怎么做？** 10 关闯关 → 拿到小红花 → 自己许愿 → 自己挑战 → 自己兑现。
4. **做成什么样？** 操作极简、5 分钟一局、即时反馈、视觉明亮但不低龄。

写到第 4 个问题的时候，我意识到一个关键决策：**这个产品里没有"别人帮孩子实现愿望"的功能**。所有的兑现都是孩子用自己的练习去完成。

这不是技术限制，是产品选择。它让整个交互的道德边界变干净了：不是用愿望绑架家长，而是让孩子体验"努力→回报"的因果链。

PRD 写完之后，整个开发过程几乎没有再大改。

## 二、技术选型：能用最轻的，就别用重的

我是产品经理背景，写过不少从 0 到  的产品。但这个项目，我刻意用了**最轻**的方案：

- **微信小程序原生框架**（WXML + WXSS + JS），不上 Taro、uni-app 这些跨端框架
- **纯前端架构**，所有数据走 `wx.setStorageSync`，没有后端
- **无第三方 UI 库**，所有视觉自己画

为什么？因为项目足够简单，跨端框架带来的复杂度收益是负的。后端则完全是负担——用户量不大时，本地存储比云端更稳定、调试更简单。

我做了几件事让未来扩展更容易：

- `utils/game.js` 是纯函数模块，题目生成、锦囊计算、评语都在这里，跟 UI 完全解耦
- `utils/api.js` 是统一数据访问层，所有读写都过它，未来接服务端只需替换实现
- 页面 JS 只做状态管理 + `_deriveFlags` 预计算，把 WXML 表达式坑全部挡在门外

这一招在后续迭代时帮了大忙——`game.js` 是纯函数，我可以单文件跑测试，不依赖小程序的运行环境。

## 三、我踩过的 5 个坑（每个都熬了一晚上）

### 坑 1：WXML 表达式不支持 `&&` 和多行三元

刚启动小程序就给我报了一堆编译错误：`Unexpected token`、`<` 无法解析。

我的解法：所有条件逻辑都在 JS 侧预计算成字符串变量，比如：

```javascript
_derive(patch) {
  const d = Object.assign({}, this.data, patch);
  return {
    itemClass: d.selected ? 'selected' : '',
    overlayClass: d.stormActive ? 'active' : '',
    // ...
  };
}
```

WXML 模板里只写 `{{itemClass}}` 和单个 `wx:if="{{bool}}"`。从那以后再也没踩过这个坑。

### 坑 2：分享回调时机问题

`onShareAppMessage` 是在分享面板弹出那一刻触发的，页面已经 `onPause`，Promise 根本来不及执行。但我需要在分享时给用户加一个新空瓶（激励分享）。

我的解法：把写存储的逻辑前移到 `bindtap` 同步处理器里，直接调 `wx.setStorageSync`。`onShareAppMessage` 里再做 3 秒去重兜底，防止用户从右上角"..."菜单分享时双加。

```javascript
onPrepareShare() {
  var bottles = wx.getStorageSync('bottles') || [];
  bottles.push(newBottle());
  wx.setStorageSync('bottles', bottles);  // 同步执行，分享前已完成
}

onShareAppMessage() {
  // 3 秒去重兜底，防止从 "..." 分享时双加
  // ...
}
```

### 坑 3：wxml-to-canvas 插件配置报错

我一开始想用官方推荐的 `wxml-to-canvas` 组件做成绩单截图。但插件配置在本地一直报错，小程序根本加载不出来。查了 GitHub Issues，发现这个插件在小程序 2.x 基础库上有兼容性问题。

我的解法：**不依赖任何第三方**。用原生 Canvas 2D 手绘成绩单——背景、头部、成绩信息、花朵装饰一个一个 `ctx.fillText` 画出来。最后反而更快、更可控，导出图片还很清晰。

这一步我额外花了半天，但意外解锁了一个能力：成绩单的版式我可以完全自定义。后来我把它换成了"薄荷绿底 + 闪电黄卡片 + 黑色描边"的同款视觉，截图出去一眼能认出是我们家的产品。

### 坑 4：波浪 SVG 被裁剪

倒计时波浪是我花心思最多的部分。我做了 5 层 SVG 叠加，深层慢、表面快，交替翻滚，希望有"波涛汹涌逐渐淹没"的紧迫感。

但一开始效果非常丑——只看到一条平直的水面边缘，看不到任何波浪形。

我找了半天，发现是 `.ocean` 容器的 `overflow: hidden` 把 SVG 的波峰全裁掉了。改成 `overflow: visible`，波浪才"露出来"。这一改，整个画面的紧迫感立刻就出来了。

### 坑 5：锦囊模式下波浪抖动

锦囊模式（时间用完了、续命机制）下，波浪会轻微抖动，像是没渲染完。

定位原因：`每 100ms` 我会调一次 `_set({oceanHeight})`，而 `_set` 内部会触发一整套 flags 衍生字段重算，导致 `ocean` 容器频繁重排，和 CSS 动画打架。

我的解法：把 `oceanHeight` 从 `_set` 调用里剥离出来，直接 `setData({oceanHeight})`，不进 flags 衍生。抖动就消失了。

这 5 个坑的共同教训是：**微信小程序比 Web 复杂的地方在于生命周期和异步回调的边界条件，要对每一处 `setData` 调用都保持敏感**。

## 四、动画与视觉：磨了好几轮

视觉我是这样磨出来的：

- 第一版是简约风格，灰白配色。给我侄子看，他说"好无聊"。
- 第二版加了粉色调，被长辈吐槽"看着像那种奇怪的网站"。
- 第三版才换成现在这套：电光蓝 + 闪电黄 + 薄荷绿 + 活力橙 + 纯黑描边。我侄子和长辈都说"挺好看"。

首页文案也调了几次，从面向儿童改成"大人小孩都适合"。心算练习场那个 5 层波浪从 3 层扩展到 5 层，加了垂直颠簸和泡沫闪烁，才有了"波涛汹涌"的紧迫感。

这些迭代教会我一件事：**视觉不是一次性决策，是和真实用户反复试出来的**。灰白配色在 Dribbble 上很高级，但给长辈看就是"无聊"。用户的体感比设计趋势重要。

## 五、上线前的几个工程细节

最后一天主要在打磨几个上线细节：

- **分享稳定性**：每个分享按钮的 `bindtap` 都同步写存储，`onShareAppMessage` 做 3 秒去重。
- **数据迁移兼容**：本地存储版本号字段，未来升级数据结构时不再读老数据。
- **离线友好**：所有交互在没有网络时也能完成（因为全是本地数据）。
- **成绩单截图**：用 Canvas 2D 自绘，不依赖任何第三方组件。

最让我意外的是"全离线可用"这个特性。因为本地存储，小程序在断网时能完整运行所有核心功能。这意外变成了一个加分项——很多用户在地铁、电梯里也能练。

## 六、这个项目的几个亮点

开发完回头看，我自己最满意的几个点：

**1. 时间锦囊的二次函数奖励**

我设计了一个奖励机制——`gift = floor((10 - usedTime)^2)`。意思是用时越短奖励越多，但不是线性增长，是指数增长。

举个例子：
- 用时 3 秒 → 奖励 49 秒
- 用时 5 秒 → 奖励 25 秒  
- 用时 8 秒 → 只奖励 4 秒

孩子很快就能感受到：原来"快一点"是真的有回报的。

**2. 愿望只能从预设里选**

我做的一个看似"限制用户"的决定：愿望只能从预设类别（甜品奶茶 / 小礼物 / 夸夸我等）里选，不能自由输入。

这反而让产品变得更纯净——孩子不会提出不合理的愿望，家长不会被逼到"答应也不是、拒绝也不是"的角落。降低了操作门槛（不用打字），也悄悄引导了健康的消费观。

**3. 只让分享到群聊**

大多数小程序都恨不得所有渠道都开。我反其道而行——只让发到群聊。这一刀切下去，反而让成绩单有了"公开露脸"的氛围：一次分享触达一群人，群里你一句我一句就把节奏带起来了。

**4. 5 层 SVG 波浪的沉浸式倒计时**

倒计时从"一个数字"变成了"一片正在压过来的海"。5 层 SVG 波浪从深海巨浪到表面泡沫，配合暴风雨雨滴粒子，营造"波涛汹涌逐渐淹没"的紧迫感。锦囊模式下波浪无缝切换暖色系，视觉语言始终一致。

## 七、给想动手的开发者几个建议

最后聊点掏心窝的：

**1. PRD 不是文档，是产品决策的锚点。**  
写 PRD 的过程会强迫你想清楚"做不做"、"给谁用"、"做成什么样"。一旦想清楚了，剩下就是工程问题。我这次 2 小时的 PRD 写了 4 个核心问题，写完后面 3 天几乎没大改过方向。

**2. 微信小程序的坑大多在异步和生命周期。**  
`setData`、`onShareAppMessage`、`wx.createSelectorQuery`、`canvasToTempFilePath` 这些 API 都有隐藏时序问题，每次都用得小心翼翼。我建议写一个工具函数库，把这些坑都封装一遍。

**3. 视觉要反复和真实用户试。**  
设计师的审美和用户的体感经常不一致。我磨了 3 轮视觉才定下来，每一轮都给我侄子和长辈看过。

**4. 一个人也能做完整的产品。**  
我这次一个人推动产品 + 设计 + 开发 + 测试全流程。核心是：**用最轻的技术栈，把核心体验做透**。

**5. 找到你真正想解决的问题。**  
我侄子和身边的长辈给了我灵感——一个是"想要"这件事需要努力，一个是"老人需要日常动脑"。这两个具体的、真实的人，让我整个开发过程都很笃定。

## 八、写在最后

这个小程序现在已经在微信小程序平台上线。整个开发周期从 PRD 到上线一共 3 天，加后续打磨 1 天。


如果你也有个模糊的想法——可能是一个孩子的需求，可能是一个家人的需求——我建议你先停一下，写 2 小时的 PRD。然后剩下的事情，3 天能搞定。

祝你也找到自己想做的那个产品。

— 写于小程序上线第 2 天

---

如果你也在做小程序或 AI Agent，欢迎留言交流。

欢迎体验我的小程序，名字叫做：心算小目标

不是工作项目，纯粹是兴趣使然。我侄子今年上小学二年级，每天回家做口算题都很痛苦——一页纸、一支笔、二十道题，做着做着就走神。身边一位长辈今年六十七，去年体检医生让她"多动动脑，预防老年痴呆"，但她对市面上的脑力 App 完全不感冒。

2小时写PRD，3天上线：我是怎么一个人手搓一个微信小程序的

产品砖家

客户端

前端

开发工具

个人开发者3天上线微信小程序「心算小目标」，将练习-许愿-兑现闭环落地。2小时PRD确定核心逻辑，纯前端+本地存储轻架构，分享5个技术坑解法。面向小学生与银发老人，用闯关获花、锦囊奖励机制激励练习，实现离线可用与群聊分享裂变。

数据迁移

数据结构

代码解释

容器

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2小时写PRD，3天上线：我是怎么一个人手搓一个微信小程序的-腾讯云开发者社区-腾讯云

2小时写PRD，3天上线：我是怎么一个人手搓一个微信小程序的

2小时写PRD，3天上线：我是怎么一个人手搓一个微信小程序的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐