石家庄小程序开发：一个本地项目的复盘

前阵子接了个石家庄本地的活，客户在桥西做社区生鲜，门店不大，但周边三个小区的复购率一直不错。老板最初的想法很简单：做个能下单的小程序，别再让店员在微信里手动记单了。聊完需求我发现，事情没那么简单——他们真正缺的不是一个下单入口，而是一套能把门店、配送和会员串起来的东西。

这篇文章就把这个项目的关键决策和踩过的坑整理一下，算是「小程序开发分享」系列的第一篇，也给石家庄本地想做小程序的老板们一点参考。

先想清楚：你要的是工具还是流程

很多客户找到我们时，第一句话是「我要做个小程序」。但在石家庄这样的城市，很多生意是熟人经济，线上化不等于把线下流程原样搬到手机上。生鲜这个客户最初的清单里有二十多个功能，我建议先砍到三个：

• 门店自提与三公里内配送的切换
• 按小区分组的团购价
• 会员余额与积分抵扣

砍功能不是为了省事，而是为了让第一版能在一个月内上线，赶上他们所在小区的促销节点。功能越多，测试周期越长，错过时间窗口的损失往往比少做两个功能更大。

技术选型上的几个取舍

用云开发还是自建后端

这个项目我们用了微信云开发。原因很实际：客户没有运维人员，预算也有限，云开发的数据库、云函数、存储一套下来，省掉了服务器和备案之外的一堆琐事。订单量在日均几百单的量级，云开发完全扛得住。

但如果你的业务涉及复杂的库存对账、多门店结算，或者未来要接 ERP，那还是老老实实自建后端。技术选型没有绝对的好坏，只有匹不匹配。

分包与首屏加载

生鲜类小程序图片多，主包很容易超过 2MB 的限制。我们的做法是把商品详情、订单列表这些非首屏页面拆到分包里，主包只留首页、分类和购物车。配合图片的 CDN 压缩，首屏时间从接近 3 秒降到了 1.2 秒左右。这个优化对转化率的影响，比多加一个营销插件明显得多。

// app.json 分包配置示例
{
  "pages": ["pages/index/index", "pages/cart/cart"],
  "subpackages": [
    {
      "root": "packageGoods",
      "pages": ["detail/detail", "list/list"]
    }
  ],
  "preloadRule": {
    "pages/index/index": {
      "network": "all",
      "packages": ["packageGoods"]
    }
  }
}

本地场景里的那些细节

做石家庄本地的项目，有些细节是通用模板给不了的。比如配送范围，客户的门店在裕华区，配送不是按直线距离算的，而是按几个固定小区的门牌号划分。我们在后台做了一个可视化的区域配置，店员自己就能改，不用每次找开发。

再比如支付后的核销。社区团购经常是团长统一收货再分发，所以订单状态里多了一个「团长已收货」的中间态，用户看到的是「明天下午到团长处自提」，而不是笼统的「已发货」。这种贴合本地习惯的设计，用户接受度会高很多。

做本地生意的小程序，功能可以少，但流程必须顺。用户不会因为你功能多而留下，只会因为一次下单卡住而离开。

关于费用和外包的一点实话

经常有人问石家庄做一个小程序要多少钱。这个问题真没法一句话回答。一个只有展示和表单的页面，几千块能做完；带支付、会员、配送调度的，一两万起步；再往上涉及多门店和供应链，就是另一个量级了。报价差异大的根本原因，是需求描述的颗粒度不同。

如果你打算找外包，我的建议是：把每个页面的操作路径写清楚，最好画个草图，再让对方按页面和接口报价。这样既方便比价，也能避免后期不断加需求导致的扯皮。我们在石家庄做小程序这些年，见过太多因为需求没写清、最后双方都不愉快的案例。

上线之后才是开始

这个小程序上线两个月，订单从每天几十单涨到两百多单，客户又提了新需求：想做拼团和优惠券。我反而劝他先别急，先把现有流程的数据看明白——哪些小区复购高、哪些商品退货多、配送超时集中在哪个时段。数据没跑通就加功能，很容易把刚理顺的流程又搞乱。

知码客一直信一句话：知码识途，匠心铸客。代码写出来是给人用的，不是给机器看的。在石家庄做小程序、做 APP 定制，拼的不是谁功能堆得多，而是谁更懂本地这门生意怎么运转。下一期我会聊聊 APP 和小程序怎么选，感兴趣的朋友可以持续关注。