微信平台账号
AppID、管理员、开发成员、体验成员、开放平台绑定与认证续期由谁维护，均应列入账号清单。
微信小程序开发
产品形态、主体资质与平台责任先行武汉微信小程序开发
从业务流程、用户入口、平台规则、支付与数据责任出发，判断小程序是否合适，并把账号、后台、验收与上线边界写入交付清单。
Product Choice
小程序、H5 与 APP，先按使用条件选择
三种形态可以组合，也可能只需要其中一种。入口、系统能力、审核、更新方式和长期运营成本不同，不应仅凭“看起来更专业”决定。
| 比较维度 | 微信小程序 | H5 网页 | 原生或跨端 APP |
|---|---|---|---|
| 主要入口 | 微信搜索、扫码、分享及经授权的生态入口 | 浏览器、链接、二维码或其他页面内打开 | 应用商店、企业分发或约定安装方式 |
| 适合场景 | 微信内高频服务、会员、预约、交易或门店协作 | 轻量活动、信息收集、跨平台分享和临时页面 | 需要更深设备能力、复杂交互、离线或长期独立入口 |
| 平台约束 | 受主体、类目、隐私、内容和版本审核规则约束 | 仍受浏览器、域名、备案和业务合规约束 | 受操作系统、商店审核、证书和版本适配约束 |
| 发布更新 | 提交平台审核后发布，规则或审核结果可能影响上线 | 服务器发布后生效，但缓存和兼容性仍需验证 | 通常需要打包、审核、分发并维护多版本兼容 |
| 成本因素 | 功能、后台、支付、接口、审核整改与持续运营 | 页面复杂度、数据接口、适配、流量与安全 | 多端开发、设备适配、商店账号、测试与版本维护 |
Platform Responsibility
主体、类目、支付与隐私责任不能在上线前才处理
功能能否开发不等于平台一定允许发布。项目开始前应核验账号主体、经营资质、服务类目、收款链路与个人信息处理方式。
- 01小程序 AppID、管理员、认证与关键平台账号由实际业务主体掌握。
- 02类目和资质按真实业务选择，医疗、教育、食品等领域需额外核验。
- 03支付商户号、结算账户、退款与售后责任应与交易流程一致。
- 04只收集实现功能所需的数据，并对权限申请、告知同意和删除路径进行测试。
ACCOUNT
主体与管理员注册、认证、人员变更与账号安全
客户确认CATEGORY
服务类目与资质真实业务、许可文件与平台审核材料
共同核验PAYMENT
支付与资金商户号、结算、退款、对账和售后
业务负责PRIVACY
个人信息处理字段、目的、权限、保留、共享与删除
书面确认REVIEW
版本与审核提审材料、整改、发布窗口和回退方案
平台决定
Data & Ownership
数据与后台归属要能回答“谁持有、谁能导出、谁负责”
源码交付只是资产的一部分。若账号、数据库、商户号和服务器由不同主体掌握，后续迁移、续费和故障处理会直接受到影响。
支付与结算账户
商户号、API 证书、结算账户、退款权限和对账责任应归实际经营主体，并限制不必要的人员权限。
后台与数据库
明确服务器、数据库、对象存储、日志、备份、导出格式和数据保留要求，以及维护终止后的移交方式。
代码与第三方服务
仓库权限、构建说明、配置项、第三方 SDK 与许可、短信地图等外部服务的账号及费用分别列明。
Delivery Checklist
小程序项目常见交付物
以下是用于定义范围的参考清单。是否包含运营配置、历史数据迁移、审核整改次数和上线后维护，应以双方确认文件为准。
| 类别 | 可约定内容 | 验收证据 |
|---|---|---|
| 产品与原型 | 角色、业务流程、页面清单、状态与异常路径、数据字段说明 | 确认版原型、需求记录与变更清单 |
| 小程序前端 | 约定页面、交互、授权提示、错误与空状态、适配范围 | 体验版本、测试账号和用例结果 |
| 管理后台 | 内容、订单、会员、门店或其他已确认模块与角色权限 | 权限矩阵、操作记录和关键流程测试 |
| 接口与数据 | 接口文档、数据库说明、导入导出、日志及备份要求 | 接口测试、数据样例和恢复或导出验证 |
| 平台材料 | 隐私说明、类目与资质提示、版本描述、提审配合 | 提交记录与平台反馈；审核通过由平台决定 |
| 移交与运维 | 合同约定的代码、账号清单、部署说明、培训和维护边界 | 移交签收、权限核对及问题处理流程 |
Review & Release
把平台审核与回退纳入发布流程
审核时间、结果和规则调整不由开发方控制。可控制的是材料准备、问题记录、版本管理、灰度验证与回退预案。
条件核验
确认主体、类目、域名、资质、支付和隐私条件。
范围冻结
锁定首期流程、页面、后台、接口与不包含项。
开发联调
在测试环境完成前后端、支付和第三方接口联调。
业务验收
由真实角色检查主流程、异常、权限和数据结果。
提审整改
提交版本并记录平台意见，区分缺陷与新增范围。
发布回退
发布前备份配置和数据，明确异常时的回退与通知人。
Acceptance Matrix
验收应覆盖正常路径，也覆盖失败与权限边界
“可以打开”不是完整验收。测试数据、账号角色、设备范围、支付环境和第三方接口条件需要在测试前准备。
业务流程
注册、预约、下单、取消、退款、核销或其他约定路径均有明确状态变化和用户提示。
角色与权限
用户、员工、门店和管理员只能访问授权数据；越权、失效账号和重复操作有处理规则。
数据与对账
关键字段、金额、库存、时间和统计口径一致，导出与备份在约定范围内可验证。
隐私与安全
权限在使用时申请，隐私说明与实际字段一致，敏感配置不暴露，日志和错误信息不泄漏个人数据。
Rule Boundary
平台规则和经营责任需要保留明确边界
功能、营销和生态接口均需结合当前公开规则与业务合法性判断，不使用“审核必过”“功能永久可用”等表述。
平台规则、接口能力与收费标准可能调整
类目、隐私、支付、订阅消息、分享、内容安全和开放接口的申请条件可能变化。项目应记录依赖的接口与规则版本；发生变化时先评估影响、替代路径、整改工作和费用，再决定版本安排。
说明业务场景与主体情况审核结果
可协助准备材料和整改已知问题，但审核时间和最终结果由平台决定。
营销功能
优惠、分销、储值、抽奖等能力需核验业务、地区法规和平台限制，不承诺经营效果。
生态协作
公众号、视频号、企业微信等关联能力取决于账号关系、授权和当期开放接口。
How We Deliver
梓彤超越如何实施微信小程序开发
从商城、预约、会员或门店的业务闭环出发，把平台条件、数据责任、测试证据和发布移交纳入同一实施路径。
先画业务状态而不是先列页面
梳理用户、员工、门店和管理员的任务，定义下单、预约、核销、取消、退款等正常与异常状态，形成流程图、角色权限和首期功能清单。
提前核验账号、类目与支付条件
在开发前记录小程序主体、AppID、类目、业务资质、备案、域名、隐私与商户号状态；可协助技术准备，但平台审核和经营合规仍由相应主体负责。
用角色、状态和对账用例验收
按真实角色检查权限和数据范围，覆盖成功、重复、取消、超时、退款、库存或时段冲突；对支付、接口和关键统计保留测试记录与差异处理。
记录提审、发布与长期责任
保存版本、平台反馈、整改和发布记录，并在书面范围内移交代码、后台、数据库、账号、证书和第三方服务清单，说明后续维护与新增需求边界。
Project Questions
小程序开发常见问题
具体条件以项目启动时的平台规则、客户主体、业务流程和书面范围为准。
什么情况下不一定需要小程序？
若只是短期信息展示、没有微信内高频流程，H5 或官网可能更轻量；若依赖复杂设备能力、离线或独立入口，则应评估 APP。
个人主体和企业主体功能一样吗？
通常会受到可选类目、认证、支付和业务资质差异影响。应按实际经营主体和功能在申请时核对平台最新要求。
微信支付由谁申请和持有？
商户号和结算账户应由实际经营主体申请并掌握。开发方可在约定范围内协助技术接入，但账户审核和资金责任不转移。
审核被退回怎么办？
先区分材料、类目、内容、隐私或功能问题，记录平台反馈并整改。若需改变已确认业务范围，应评估变更影响后再实施。
上线后数据能否导出或迁移？
取决于后台和数据方案。应在开发前约定数据表、导出格式、备份策略、第三方平台限制和维护终止后的移交流程。
小程序上线后是否还需要维护？
需要持续关注平台规则、证书与域名、接口、服务器、安全、备份和业务变化。维护内容与响应范围应另有清单。
商城、预约、会员和门店小程序怎么选？
商城围绕商品、订单、支付和售后，预约围绕资源、时段与取消，会员关注身份、权益和积分，门店还要处理组织、库存、核销与数据范围。可组合但应先确定首期闭环，避免把所有营销功能一次纳入。
武汉小程序开发包含支付接入和备案吗？
可以在书面范围内包含技术接入、备案信息准备和提审支持，但企业需持有真实主体、商户号、结算账户及所需资质。平台审核时间、结果、第三方费用和经营合规不能由开发方保证。
多门店小程序后台怎样划分权限？
应区分总部、区域、门店、员工和用户的数据范围，并明确商品、库存、订单、退款、核销、报表和导出的权限。验收要使用不同角色账号验证页面和接口，不能只在管理员账号下走通流程。
先确认业务、主体与数据责任，再进入功能报价
请说明用户是谁、核心流程、是否交易、现有账号与资质、需要连接的系统，以及希望由谁长期运营维护。