事实求是先说我做这个功能的真实原因。给客户做定制软件，最怕的不是客户提需求，而是客户提完需求之后，隔了两周说“我当时不是这个意思”，或者说“这个功能我们领导又看了，觉得还是应该加个筛选条件”。每次口头答应下来，开发排期全乱，项目成本悄悄涨，最后对账的时候销售说“当时没答应过这个”，客户说“你们也没说要另外收费”，扯皮扯到天荒地老。所以我花了一段时间做了一个“需求变更影响评估”的小工具，把变更输入进去，自动拆成本、算工期，然后直接生成一张变更确认单，让客户签字确认。这篇文章就把这个工具背后的设计思路、计算公式、字段模型和踩坑经历完整记录下来。
这个工具服务的对象很明确：软件开发项目里的项目经理、产品经理、需求分析人员；适用的场景也很固定：项目已经进入开发或者测试阶段，客户提出新的或者修改后的需求，需要判断“这个改动到底要花多少钱、影响多少天上线时间、要不要发给客户做商务确认”。标题里说的“输入客户的初始需求和变更需求”，实际落地时不能靠自然语言的自动比对，第一步要做的是先把变更拆成结构化的描述，再把成本模型、工期模型和文档生成挂上去，这样才是真正能用的“自动计算”。
1. 做功能前先定义“一次变更”是什么
很多项目在“需求变更”上扯皮，根子就在于没有分清变更的粒度。客户说“加一个批量导出功能”，这是一次变更；客户说“导出的时候顺便把筛选条件也存下来，下次打开还能记住”，这看起来只是一个小优化，但从系统设计的角度看，它动到了查询状态管理、默认值逻辑、缓存策略、甚至权限体系，比单纯加一个导出按钮复杂得多。如果不把这层拆开，自动计算出来的成本也是错的。
所以我在做工具的第一件事，不是写代码，而是定义了一个变更条目结构。
一条变更必须包含以下几类信息：
- 变更编号：唯一标识，通常用 CR-2025-001 这样的格式，方便和客户沟通时引用。
- 变更来源：是客户主动提的，还是内部自查发现的，还是测试阶段暴露出来的问题。
- 原始需求描述：指向项目立项时的那条基线需求，要能追溯到需求文档里的具体章节。
- 变更需求描述：客户新提出的、明确的、可验证的验收标准或行为要求。
- 涉及模块：变更影响到的子系统或功能点，例如订单模块、支付模块、报表模块。
- 变更性质分类：新增功能、修改逻辑、界面调整、流程变更、标准或兼容性调整。
- 紧急程度：普通、加急、紧急，这个字段会影响工期计算中的并行度系数。
这里说一个容易忽略的关键点：如果原始需求本身就是模糊的，那么“变更”的边界也会跟着模糊。我见过不少项目在需求阶段写的是“支持多种方式的导出”，开发按“导出Excel”做了，客户验收时却认为“多种方式”至少包含Excel和PDF，于是要求加PDF导出的功能。这算不算变更，团队内部吵了很久。所以工具必须绑定一个前提：任何变更计算都要基于已经签字确认的原始需求基线。如果没有这个基线，系统应该拒绝计算并提示先补充原始需求文档链接或条目编号，而不是自己脑补。
还有一个细节是“取消变更”也要管。客户说这个界面不要了，退回原来的样式，听起来是没有增加成本，但如果开发已经做了三个页面和两个接口，那就是一次变更，只是变更方向是回退。成本和工作量同样要算，算的是“返工和恢复成本”。编辑模型里要给变更状态留足够的位置，我采用了五状态流转：待分析、分析中、待确认、已确认、已关闭，其中“已关闭”又分为已实施和已取消两种子状态。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 变更成本测算的公式拆分：不能只算程序员写代码的时间
很多团队评估变更就是“让开发估一下要几天”，最后发现开发估的工时老是不准，不是开发水平不行，而是评估范围根本没定义清楚。开发估的往往只是编码时间，但在真实项目里，一次需求变更牵涉的远远不止编码，还包括需求分析、方案设计、联调、测试回归、文档更新、甚至发布上线后的观察。
我把变更成本拆成了五个部分，分别建模。
总变更成本 = 人力成本 + 非人力成本 + 风险准备金
人力成本是最大头，五部分分别是：
- 需求分析工时：重新阅读原需求、拆解新需求、和客户沟通确认细节所需的工作量。
- 方案设计工时：如果变更影响数据库结构或系统架构，需要重新做设计。
- 开发工时：前端、后端、脚本等实际代码改动。
- 测试工时：功能测试、回归测试、联调测试。
- 部署与文档工时：发布