系统加功能要多少钱？二次开发报价3种算法
系统跑了两年，业务变了，老板说「在这个系统上加个分销功能，顺便把会员等级改一下」。你回头找原来的开发方，对方报了一个看起来不太合理的价格，你不知道这个数是怎么来的，也不知道该不该换人做。这是软件定制项目里非常典型的一次询价：不是从零开发，而是在一套已经在线运行的系统上继续做。
聚辉软件接过不少这类二期需求。二次开发为什么不便宜、钱花在哪里、二次开发报价怎么核，值得单独讲清楚，因为它和「做一个新APP多少钱」的算法完全不同。
一、二次开发和新建项目的成本结构差异
新建项目从空目录开始，代码、数据库、部署环境都是新的，开发方可以按自己的习惯组织架构。二次开发不一样，所有工作都要先落到一套既有的规则里。这带来三个成本项，是新建项目没有的：
- 读代码成本。一个上线两年的中型系统，代码量通常在 5 万到 20 万行，加上配置文件、数据库脚本、第三方对接记录。开发人员需要先读懂它，才能改对。一个熟悉的技术人员读通一套陌生代码，通常要 3 到 10 个工作日；如果不熟悉，时间会更长。
- 回归测试成本。新建项目只需要测新功能。二次开发改动的是在线系统，任何一处修改都可能影响已有流程。一个改动往往要连带回归测试十几条既有业务路径，这部分工作量常被客户低估。
- 环境与耦合成本。原系统可能对接了支付、短信、硬件设备、第三方 ERP。新功能如果要复用这些接口，开发方必须先把它们复现到测试环境里，这部分准备工作有时比写功能本身更耗时。
把这三项叠加起来，就解释了那个反直觉的现象：一个看起来「就加个页面」的需求，报价可能是新建同类功能的两到三倍。
二、二次开发报价的三种算法与适用场景
行业里常见的报价方式有三种，各自的风险归属不同：
第一种，按功能点估算。把需求拆成可计数的功能点，每个功能点给一个单价，再加读代码与回归测试的固定工时。适合需求边界清晰的场景，比如「加一个分销佣金计算模块」，输入输出都能说清。缺点是需求一旦模糊，功能点数量就会失真。
第二种，按人天计。评估出一共需要多少人天，乘以人天单价。适合改动范围不确定、需要边做边看的情况。风险在于人天容易被放大，所以合同里要约定人天上限和超出的处理方式。
第三种，模块打包价。把二期拆成几个独立模块，每个模块一个总价，按模块验收付款。适合需求相对成熟、可以分阶段上线的项目。这种算法对客户最友好，因为每个模块的价格风险是封顶的。
我们在承接二期项目时，通常采用第三种为主：先做一次 1 到 2 周的技术尽调，把代码质量、接口状况、数据库结构摸清，再按模块报打包价。尽调本身收费，但能换来一个不会中途暴涨的价格。
三、影响二次开发报价的五个关键变量
同样是「加分销功能」，报价从 3 万到 30 万都可能出现，差异来自这五个变量：
变量一，原系统由谁开发。如果原开发方还能继续服务，报价通常最低，因为读代码成本为零。如果换了新公司，这笔读代码的钱必须有人出。这是二次开发换供应商最常见的隐性代价。
变量二，代码可读性。有注释、有接口文档、有部署脚本的项目，接手成本低；没文档、变量命名混乱、业务逻辑写在前端页面里的项目，读代码时间可能要翻倍。这一点在尽调阶段就能判断，也是我们建议客户在首次开发时就要求交付文档的原因。
变量三，数据库改动范围。只加新表、新增字段，成本可控。如果要改既有表结构、做历史数据清洗和迁移，风险和工时都会显著上升，而且必须安排停机窗口。
变量四，第三方接口与硬件。涉及支付通道改造、短信模板报备、硬件协议对接的需求，开发工时里有一大块是不可压缩的外部等待时间。这类需求的报价里，通常要包含联调与反复测试的余量。
变量五，上线方式。灰度上线、可回滚、有数据备份的方案，比「直接替换生产环境」要多花工时，但这是应该花的钱。二次开发出事故，代价远高于多付的这部分开发费。
四、询价前该准备的六项材料
二次开发的报价失真，八成来自信息不对称：开发方看不到系统，只能凭描述猜，猜出来的数字自然要留安全垫。把下面六项准备好，报价的准确度会明显提高：
- 原系统的功能清单或操作手册，说明现有模块与权限结构；
- 数据库表结构导出，至少包含核心业务表；
- 接口清单，标出哪些是内部接口、哪些对接了外部服务；
- 技术栈说明：后端语言与框架、前端框架、数据库版本、部署方式；
- 服务器与运维信息：云服务商、配置、是否有 CI/CD 流程；
- 本次需求的验收标准，写成「什么情况下算做完」，而不是「加一个分销功能」。
如果原开发方不愿意提供这些，那本身就是一个重要信号。源代码、数据库结构、接口文档属于交付物，客户有权要求交付；拿不到这些，意味着你对这套系统并没有真正的控制权，二次开发会变成一场被动谈判。
五、二期项目怎么控制预算
第一，把二期切成小步。一次加三个模块，不如先做最急需的那一个。第一个模块做完，你对新供应商的交付质量、响应速度、代码水平就有了判断，后面两个模块的预算也更好谈。
第二，明确「不改什么」。二期的合同里除了写要做什么，还应该写清本次不动哪些模块、不碰哪些接口。边界写清了，回归测试的范围才有依据，工期才有可预测性。
第三，把数据备份与回滚写进交付标准。这不是可选项。二次开发的上线风险高于新建项目，因为在线数据是真实的。
第四，质保期与新建项目同等对待。改装过的功能出问题，责任同样落在开发方身上。质保范围、起算时间、响应时限，都应在合同里写明。
第五，评估「推倒重做」的可能性。当原系统代码质量极差、文档全无、每次改动都要付出高额读代码成本时，二期的总投入可能在三到五年内超过重做。这个账值得算，但要在尽调数据支撑下算，而不是凭感觉判断。
六、一个实用的判断标准
二次开发报价是否合理，不看总价，看三件事：报价里有没有明确列出读代码与回归测试的工时；有没有给出模块级的价格与验收边界；有没有说明上线方案与回滚安排。
三项都有，说明对方真的打开过你的系统，报价是有依据的。三项都没有，只给一个总数，那这个数字无论高低，都建议再谈一次。我们在二期项目里的做法是把这三项直接写进报价单，客户看不懂代码没关系，能看懂「这 8 天是用来读你原有系统的」就够了。
系统加功能这件事，本质上是在别人的地基上继续盖楼。地基情况决定造价，所以在报价之前，先让人把地基看清楚，比反复压价有效得多。如果您正在评估一套已上线系统的改造预算，可以先整理上述六项材料，我们会据此给出一个带工时拆解的模块级报价。