唐山小程序开发案例：从需求到上线

做开发这些年，我越来越觉得，一个案例能不能讲清楚，关键不在于技术多花哨，而在于它到底解决了谁的什么问题。今天拿一个我们知码客在唐山本地交付的小程序项目来拆一拆，从需求沟通到上线运维，尽量把中间踩过的坑和做过的取舍都说透。如果你也在唐山做小程序，或者正打算找团队开发，这篇应该能给你一些参考。

项目背景：一个唐山本地的预约场景

客户是唐山市区一家做设备维保服务的小公司，线下有七八个师傅，平时靠电话和微信群接单。问题很典型：客户报修信息散落在聊天记录里，师傅排期靠脑子记，月底对账要翻半天记录。老板的原话是：“我不想要多复杂的东西，能让客户自己约、师傅能看到、我能看到每天干了多少活就行。”

这类需求在唐山小程序开发的咨询里非常常见——不是要做平台，而是把一条已经跑通的线下流程搬到线上。我们最后定的是微信小程序，原因有三个：

• 客户不用下载，扫码或搜一下就能用，中老年客户也能接受；
• 微信支付、订阅消息都是现成的，省掉大量基础建设；
• 预算可控，一期上线成本比做原生 App 低不少。

功能拆解：只做必要的三件事

很多项目死在“什么都想做”。这个项目我们砍到只剩三条主线：

1. 客户侧：报修预约

客户选择设备类型、描述故障、上传一两张照片、选期望时间段，提交后生成工单。这里有个细节：时间段不是让客户随便填，而是从后台配置的可约时段里选，避免出现“客户约了师傅到不了”的尴尬。

2. 师傅侧：工单处理

师傅在小程序里看到派给自己的单子，接单、出发、完成三个状态，完成后拍照上传并填一句处理说明。状态流转用云开发的数据库触发器记录时间戳，后面统计工时直接读。

3. 管理侧：简单看板

老板要看的就是每天单量、完成率、每个师傅的接单数。没做复杂的 BI，就是一个列表加几个数字卡片，够用。

技术选型：为什么用云开发

这个项目我们用了微信云开发，没有单独搭服务器。原因很实际：客户没有运维人员，预算也不支持长期养一台云主机加数据库。云开发的云函数、云数据库、云存储把后端基本包圆了，订阅消息推送也有现成接口。

// 云函数示例：创建工单并写入数据库
const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async (event, context) => {
  const { openid } = cloud.getWXContext()
  const { deviceType, desc, images, timeSlot } = event

  if (!deviceType || !desc) {
    return { code: 400, msg: '请填写设备类型和故障描述' }
  }

  const res = await db.collection('orders').add({
    data: {
      openid,
      deviceType,
      desc,
      images: images || [],
      timeSlot,
      status: 'pending',
      createdAt: db.serverDate()
    }
  })

  return { code: 0, orderId: res._id }
}

需要提醒的是，云开发不是万能的。如果后期要做复杂的多角色权限、跨端同步或者高并发秒杀，还是得回到自建后端。选型要看业务阶段，别为了省事把未来堵死。

开发过程中踩过的坑

图片上传的体验问题

一开始客户直接选原图上传，结果师傅在现场用手机流量传一张 5MB 的照片要等半天。后来加了前端压缩，上传前把长边压到 1280px，体验立刻不一样。这个细节在唐山app开发和小程序项目里都值得注意，尤其是面向一线作业人员的场景。

订阅消息的授权时机

订阅消息不能一进小程序就弹，用户很反感。我们的做法是在客户提交工单成功后，再引导授权“工单状态变更通知”，转化率高很多，也不会显得突兀。

状态机要提前想清楚

工单状态从 pending 到 accepted 到 done，中间还可能有 cancelled。如果一开始没把状态流转画清楚，后面加一个“师傅拒单”就要改一堆判断。建议动手写代码前，先在纸上把状态图画出来。

上线之后：真正的工作才开始

小程序审核通过只是起点。上线第一周我们盯着后台看数据，发现两个问题：一是部分客户提交完就不管了，不知道要等多久；二是师傅完成工单后忘记点“完成”。针对第一个，我们在提交成功页加了预计响应时间说明；针对第二个，加了每天下午的提醒推送。这些小改动不涉及技术难度，但对使用率影响很大。

另外，唐山本地的客户有个特点：线下沟通意愿强。所以我们保留了“一键拨号”入口，客户点一下直接打给客服，比在线留言更符合他们的习惯。做本地项目，尊重本地用户的行为习惯，比堆功能更重要。

给准备做小程序的唐山朋友几点建议

1. 先梳理流程，再谈功能。把线下怎么跑的写下来，往往能发现一半的功能是不必要的。
2. 一期只做闭环。哪怕功能少，只要客户能约、师傅能接、老板能看，就算成功。
3. 预算留出运维部分。小程序不是做完就结束，订阅消息、数据备份、小修小补都需要持续投入。
4. 选团队看案例，不看话术。让对方讲讲上线后遇到的问题怎么解决的，比看 PPT 有用。

我是知码客，在唐山做小程序和 App 开发，平时也写写代码、记录一些项目里的真实取舍。这个案例不算惊艳，但它跑起来了，客户每天在用，师傅不再翻聊天记录找单子——对我来说，这就是一个合格的小程序开发案例该有的样子。