一、为什么“改几个功能”可能比重做更难
1. 先要理解别人没有留下说明的设计
新功能需要接在现有用户、订单、支付、会员和权限上。没有文档时，开发人员必须从代码、数据库和接口行为反推规则。
一处看似简单的字段修改，可能影响后台报表、支付回调、定时任务和历史数据。
2. 不能破坏已经运行的业务
新项目可以从零设计，旧系统修改必须兼容现有用户和数据。每次发布都要考虑老版本、缓存、登录态、支付和回滚。
3. 历史问题会在改动时暴露
原系统可能没有自动测试、日志和测试环境。平时看起来能用，是因为业务人员绕开了问题；新功能触发旧路径后，故障集中出现。
4. 技术栈和依赖可能过时
小程序框架、组件库、构建工具、Node 版本和第三方 SDK 都会变化。直接升级可能引发大量兼容问题，不升级又可能无法使用新能力或修复安全风险。
5. 资产和责任不完整
缺少源码、数据库、服务器、域名或平台账号时，新团队无法对完整系统负责。低价承诺接手，最后很容易变成持续追加。
二、报价前必须确认的资产清单
微信与平台账号
- 小程序 AppID
- 主体和管理员
- 微信公众平台权限
- 微信支付商户号
- API 证书与密钥
- 消息模板或订阅消息配置
- 隐私协议与备案状态
- 开放平台绑定关系
账号应属于企业主体，不应长期依赖原开发人员个人微信。
代码与构建
- 小程序前端源码
- 后台服务源码
- 管理后台前端源码
- 数据库脚本
- 配置模板
- 构建和部署说明
- 依赖锁文件
- Git 历史
- 当前线上版本对应的提交
只有一个压缩包，不一定等于可维护源码。必须实际安装依赖、编译并与线上版本核对。
运行环境
- 云服务器或云开发环境
- 数据库
- 对象存储
- CDN
- 域名与 DNS
- SSL 证书
- 日志与监控
- 定时任务
- 备份
第三方服务
- 短信
- 地图
- 实名认证
- OCR
- 物流
- 发票
- 推送
- 客服
- 内容审核
每项都要确认账号归属、余额、调用限制和续费方式。
三、一次接手审计应该检查什么
1. 能否复现当前版本
在不修改代码的情况下，能否安装依赖、构建前端和后台，并部署到测试环境。
如果连当前版本都无法复现，新增功能前应先恢复基本开发链路。
2. 代码结构
检查模块划分、重复代码、全局状态、接口封装、错误处理和配置管理。重点不是追求“代码漂亮”，而是判断改动会不会牵一发动全身。
3. 数据库
查看表结构、主键、索引、状态字段、软删除、历史数据和备份。确认新增需求是否会破坏旧数据。
4. 接口和权限
确认登录、身份、角色和业务数据权限是否由后台真正校验。只在小程序页面隐藏按钮，不能阻止越权调用。
5. 支付和回调
支付、退款、分账和回调必须重点检查幂等、签名、金额单位和重复通知。生产密钥不能混入源码。
6. 日志和异常
出现问题时能否查到用户、请求、订单和错误原因。没有日志的系统，二次开发测试成本会更高。
7. 发布与回滚
是否有测试环境、发布步骤、数据库变更记录和回滚办法。线上直接改代码不是可靠流程。
8. 已知问题与业务绕行
询问客服、运营和财务：哪些功能“大家知道不能这样用”，哪些数据经常手工修。真实问题往往不在需求文档里。
四、二次开发的四种处理路线
路线一：在现有代码上继续开发
适合源码完整、技术栈仍可维护、结构清楚、测试和部署可恢复的系统。
优点是成本低、上线快；缺点是仍要接受原架构边界。
路线二：局部重构
保留稳定模块，先重构问题最严重的接口、支付、权限或订单模块，再增加功能。
适合核心业务可用，但局部风险已经影响交付的系统。
路线三：前端重做，后台兼容
当小程序页面和框架问题严重，但后台接口相对稳定时，可以重做小程序前端，暂时保留后台。
需要确认接口文档和老用户兼容，避免“前端重做”最后被后台问题拖住。
路线四：分阶段重做
当源码缺失、架构不可维护、数据和权限风险高时，继续修改可能比重做更贵。
重做也不等于一次推翻。可以先保留旧系统运行，新系统从一个业务闭环开始，通过数据同步和灰度逐步替换。
五、参考费用如何分级
| 类型 | 典型范围 | 参考预算 |
|---|---|---|
| 只读接手审计 | 代码、账号、环境、风险和建议 | 5000～20000 元 |
| 简单二次开发 | 源码完整、少量页面与接口调整 | 10000～30000 元 |
| 中等改造 | 多模块、后台调整、数据与第三方联调 | 30000～80000 元 |
| 复杂接手 | 支付、订单、迁移、权限、局部重构 | 80000～200000 元以上 |
| 分阶段重做 | 旧系统持续运行，新系统逐步替换 | 需专项评估 |
如果新增需求本身只值一万元，但为了恢复环境和处理历史问题需要三万元，可靠报价应把两部分分开，让企业决定是否继续。
六、哪些情况适合继续改
- 前后端源码完整
- 能构建并部署当前版本
- 企业掌握账号和数据
- 核心技术栈仍有维护能力
- 新需求与原业务模型一致
- 关键模块风险可控
- 有测试或至少可以建立回归清单
七、哪些情况应该认真考虑重做
- 后台源码缺失或与线上不一致
- 无法恢复构建和部署
- 核心账号不属于企业
- 数据库长期靠手工修改
- 权限只做在前端
- 支付和订单经常重复或对不上
- 每次改动都会引发大量无关故障
- 新业务与原系统模型完全不同
- 原供应商无法交接且系统无人理解
重做不是因为“代码看着旧”，而是继续修改的可预测性和安全性已经低于重新建设。
八、接手项目的合理流程
第一步：只读盘点
先看资料、账号、代码、环境和数据，不急着修改生产系统。
第二步：恢复测试环境
在隔离环境构建当前版本，验证接口和数据库。无法复现时先解决基础链路。
第三步：形成风险报告
列出已验证事实、阻塞项、风险等级和缺失资产。区分必须处理和可以暂缓。
第四步：拆分新增需求
把每个需求对应到页面、接口、数据和第三方影响，识别会触发旧问题的部分。
第五步：选择路线并报价
分别给出继续改、局部重构和分阶段重做的预算、周期与风险，让企业选择。
第六步：先做一条低风险闭环
用一个小范围功能验证开发、测试、发布和回滚流程，再扩大改造。
九、合同里必须写清的内容
- 现有资产和缺失资产
- 审计阶段是否只读
- 新增功能范围
- 历史问题是否包含修复
- 数据迁移范围
- 第三方费用
- 测试和验收
- 发布与回滚
- 源码和账号交付
- 质保与后续维护
- 原系统不可控问题的处理方式
最容易产生争议的是“接手后发现的问题算谁的”。合同应区分审计前已知问题、审计发现问题和开发引入问题。
十、老板怎样识别危险的接手承诺
以下说法需要谨慎：
- “不用看代码，肯定能改”
- “先付钱，账号以后再说”
- “没有后台源码也没关系”
- “线上直接改最快”
- “支付问题不需要单独测试”
- “历史数据错了就手工修”
- “先全部升级依赖再看”
- “接手后所有旧问题都免费处理”
真正负责任的团队通常会先要求审计，因为在不知道系统状态时给出确定总价，本身就不可靠。
十一、上线验收要覆盖什么
除了新增功能，还应回归：
- 登录和授权
- 核心用户流程
- 支付、退款和回调
- 订单状态
- 会员权益
- 消息通知
- 后台管理
- 数据权限
- 老用户和历史数据
- 弱网、重复点击和接口超时
- 发布后监控与回滚
二次开发最大的风险不是新功能不能用，而是旧功能被悄悄破坏。
十二、常见问题
只有小程序前端代码，能不能继续开发？
如果新增功能完全不依赖后台，少量页面可能可以；大多数业务功能仍需要后台和数据库。应先确认接口归属和可修改性。
原开发公司不交源码怎么办？
先查看合同中的源码与交付约定，通过正式沟通解决。不要让新团队通过越权方式获取系统。必要时咨询法律专业人士。
审计费用能不能抵开发费？
可以在商务上约定，但审计仍应有独立交付物。即使最终不继续开发，企业也应获得资产和风险报告。
是不是技术栈旧就必须重做？
不是。能稳定运行、有维护人员、风险可控的旧技术仍可继续使用。判断标准是可维护性和业务需求，不是追新。
二次开发要不要先备份？
必须。至少备份数据库、文件、配置和当前可运行代码，并验证恢复方式。
结语：接手旧小程序，第一项交付应该是确定性
小程序二次开发最重要的不是立即写新页面，而是确认企业真正拥有什么、当前版本能否复现、哪些历史风险会影响新增需求。
如果你准备接手旧小程序或更换开发团队，可以先整理账号、源码、服务器、数据库、第三方服务和新增需求。需要进一步评估接手、局部重构或重做路线，可查看小程序与软件开发服务，或通过联系我们提交项目情况。
