小程序制作流程视频：我拍废12条才总结的脚本

去年年底我给自己定了个目标：把小程序从零到上线的完整流程拍成视频。听起来不难，结果前12条素材全部废掉。不是因为录屏糊了，也不是因为讲错了，而是观众看完还是不知道下一步该干什么。后来我把脚本推翻重写，才明白「流程视频」的重点不是流程，而是让看的人能跟着做。

先想清楚：谁会看这条视频

我最初犯的错，是把视频当成技术分享。结果评论区一半人问“这个软件在哪下载”，另一半问“能不能帮我做一个”。这两类人都不是目标观众。

真正会看完「小程序制作流程视频」的，通常是这三类：

• 想自己动手做第一个小程序的初学者，需要一条能跑通的路径；
• 准备找外包的老板，想搞懂流程里哪些环节不能省；
• 已经会写代码，但没走过完整上线流程的开发者。

我的做法是：一条视频只服务一类人。面向初学者的拍“跟着做”版，每一步都给出可复制的操作；面向老板的拍“看懂流程”版，重点讲每个阶段交付什么、验收什么。混在一起拍，谁都照顾不好。

我用的视频结构：五段式

试了十几次之后，我固定下来一个结构，每次拍之前先把这五段写在纸上：

1. 三十秒讲清终点

开头不要自我介绍，直接展示成品：打开小程序、点两下、看到结果。观众得先知道“做完长什么样”，才有耐心看过程。

2. 环境准备单独成段

这是弃坑率最高的地方。账号注册、开发者工具下载、AppID 配置，全部放在一段里讲完，并且把常见报错提前说出来。我通常会在视频简介里放一份清单，观众可以对照打勾。

3. 主流程只走一条线

别贪心。一个视频里塞登录、支付、地图、订阅消息，观众会晕。我一般选一条最小可用路径，比如“列表页 → 详情页 → 提交表单 → 云数据库落库”，把这条线走通走透。

4. 卡点单独拆出来

录制时我会在旁边记时间戳，凡是自己停顿超过十秒的地方，都是观众的卡点。这些片段单独剪成一小节，配上“为什么会这样、怎么解决”。

5. 结尾给下一步

视频最后不要只说“感谢观看”，要明确告诉观众：下一步去改哪个文件、去看哪个文档、或者去试哪个功能。这一步做了之后，完播率和留言质量明显不一样。

录屏之外的功夫

很多人以为流程视频就是打开录屏软件一直讲。我踩过的坑是：边想边操作，视频节奏一定拖沓。

现在的做法是先写“操作脚本”，把每一步要点的按钮、要改的代码、要说的那句话都写下来，再照着录。代码部分我习惯先在编辑器里写好，录制时只做删改和讲解，避免在镜头前现场敲错。

// 录制前先跑通的最小示例，视频里只演示改动部分
Page({
  data: { list: [] },
  onLoad() {
    this.fetchList()
  },
  async fetchList() {
    const db = wx.cloud.database()
    const res = await db.collection('items').get()
    this.setData({ list: res.data })
  }
})

另外，画面里最好只留必要窗口。我把聊天软件、邮件、浏览器多余标签页全部关掉，分辨率固定 1080p，字号调大两号。观众在手机上看，字小了等于没讲。

剪辑阶段的三条硬规矩

• 删掉所有等待：编译、上传、加载的空白时间一律剪掉，用字幕说明“大约需要几十秒”。
• 关键操作加放大：点击的按钮、修改的那行代码，做局部放大或高亮，别让观众自己找。
• 每段结尾留一句总结字幕：一句话说清这段做完了什么，方便回看的人跳着找。

发布之后我关注什么

视频发出去不是结束。我会重点看三个数据：观众在第几分钟大量划走、评论区重复出现的问题、以及简介里清单链接的点击量。前两个决定下一条视频要补什么，第三个决定这条视频有没有真的帮到人。

还有一个笨办法很有效：把评论区的高频问题整理成文字版补充到简介里。视频负责讲流程，文字负责查细节，两者配合，比单纯堆时长有用得多。

流程视频的价值不在于“我讲完了”，而在于“他做出来了”。判断标准很简单：有没有人照着你的视频，真的把自己的小程序跑起来。

如果你也在准备拍这类内容，建议先别急着开录。花半小时把观众、结构、卡点三件事写清楚，再按下录制键。我废掉的那12条素材，基本都是省了这一步。