从需求到上线：一个石家庄小程序项目的开发实录

写在前面：为什么我要记录这个项目

做独立开发这些年，我越来越觉得，一个项目真正值钱的部分往往不在代码本身，而在“需求怎么被翻译成功能”这一段。上个月刚交付的一个石家庄本地项目，正好是个典型样本。客户是做社区生鲜配送的，门店在裕华区，配送范围覆盖周边三四个小区，之前靠微信群接龙下单，每天光对账就要两个小时。这篇文章就把从沟通到上线的过程完整捋一遍，给正在考虑做小程序的本地商家一个参考。

需求沟通：先搞清楚“谁在用”

第一次见面是在客户店里，下午三点多，正是他们最闲的时候。老板拿出手机给我看他们的接龙记录，一屏一屏往上翻，我大概看了十分钟就明白了问题所在：

• 下单信息散落在群里，漏单、重单每天都有；
• 价格经常变动，群公告改了但老客户看不到；
• 配送地址靠手打，经常出现楼栋号写错的情况；
• 月底对账全靠人工，老板自己都说不清到底赚了多少。

这里有个经验想分享：不要一上来就问客户“你想要什么功能”。大部分商家说不清楚，他们只会描述痛点。正确的做法是让他演示一遍现在的工作流程，你负责把流程拆成节点，再判断哪些节点适合搬到线上。这个项目最后砍掉了客户最初提的“会员积分商城”，因为按他们的客单价和复购频率，积分体系根本跑不起来，先做基础交易闭环才是正事。

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

客户预算有限，也没有自己的服务器运维能力，所以从一开始就定了微信小程序 + 云开发的路线。理由很直接：

• 不用买服务器、配域名、搞备案，石家庄本地小商家最怕的就是这些流程；
• 云数据库和云函数按量计费，前期一天几毛钱，跑起来再扩容；
• 支付、登录这些能力微信原生支持，接入成本低。

当然也有代价，比如复杂查询能力弱、冷启动有延迟。所以我在设计时做了取舍：商品列表这种高频读取的数据放云数据库并加本地缓存，订单写入走云函数保证一致性，统计报表则每天定时跑一次汇总，避免实时聚合拖慢页面。

核心功能拆解

1. 商品与价格管理

生鲜的价格波动大，所以后台做了“今日价”和“日常价”两套字段，商家每天早上在手机端改一次价，前端自动取当天生效的价格。这里踩过一个坑：一开始把价格直接存在商品表里，改价后历史订单显示的价格也跟着变了。后来把下单时的价格快照写进订单记录，问题才解决。

// 下单时写入价格快照，避免历史订单被改价影响
const order = {
  goodsId: item._id,
  goodsName: item.name,
  unitPrice: item.todayPrice, // 快照
  count: item.count,
  amount: item.todayPrice * item.count,
  createTime: db.serverDate()
}

2. 地址与配送范围

客户只送周边几个小区，所以做了地址白名单：用户首次下单时选择小区，系统判断是否在配送范围内，不在范围直接提示。这个逻辑看着简单，但省掉了大量售后扯皮。地址簿还支持“常用地址”一键复用，老年用户操作起来也不费劲。

3. 订单与对账

订单状态设计成待付款、待配送、配送中、已完成、已取消五个状态，每次流转都记一条日志。商家端有个简单的日汇总页面，当天订单数、金额、退款一目了然，老板说这个页面是他用得最多的。

上线前的那些琐事

功能写完只是开始，真正花时间的是上线准备。这里列几条容易被忽略的：

• 小程序类目要选对，生鲜配送属于“电商平台”还是“商家自营”，资质要求不一样，提前问清楚；
• 微信支付需要商户号，个体户也能申请，但审核周期要留出时间；
• 隐私协议、用户信息收集说明必须补全，现在审核比以前严；
• 真机测试一定要用低端安卓机跑一遍，老年用户的手机配置普遍不高。

这个项目从签约到上线大概用了四周，其中开发和测试各占一半。上线第一周我又去了一趟店里，看老板实际操作，发现有两个按钮的位置不符合他的使用习惯，当场调整了。这种线下回访在本地项目里特别值得做，隔着屏幕沟通十次不如坐在一起看十分钟。

一点感想

在石家庄做小程序开发，客户群体和一线城市不太一样，很多是夫妻店、社区店，预算不高但对实用性要求很实在。他们不关心你用了什么框架，只关心“能不能让我少干点活”。知码客一直说的“知码识途、匠心铸客”，落到具体项目里，大概就是先弄明白对方真正在做什么生意，再决定写什么代码。技术是工具，把流程理顺了，小程序才有价值。

如果你也在石家庄，正被类似的手工流程困住，不妨先把每天的工作步骤写下来，看看哪些环节最耗时间，那通常就是最该先搬到线上的部分。