后面我可能会想到很多新的功能，我可以加上去吗？

结论：可以加，但不能把所有新想法直接插入当前开发。先进入需求池，说明用户、问题和成功标准；滚水科技评估对范围、数据、接口、周期和费用的影响，双方确认维护额度或变更单后再进入迭代。

定制项目出现新想法很正常，尤其在原型可操作或系统上线后，业务人员才会看见原流程中的例外。真正需要控制的不是“能不能改”，而是新功能是否打断正在验收的主线、是否把一个小按钮变成数据和权限重构，以及双方如何确认新增成本。无限口头加需求，最终通常既拖延期，也无法判断原合同是否完成。

不同变化应采用不同处理方式：

变化类型	判断示例	推荐处理	是否通常影响费用与工期
原约定功能未按验收标准实现	已约定导出 Excel，但结果缺字段	作为缺陷修复	不应按新增功能收费
小型体验优化	文案、对齐、已存在字段的合理校验	进入维护额度或当前迭代评估	视合同额度，不当然免费
新业务功能	新增会员等级、积分、审批节点或角色	建立需求和验收，单独估算	通常影响
范围级变化	新增 App、支付、硬件、外部系统或多租户	重新评估架构、合规和计划	明显影响，可能形成新阶段
探索性想法	用户和价值尚不确定的 AI 或营销功能	先访谈、原型或人工试验	先付验证成本，暂不做完整开发

需求条目至少回答：谁遇到什么问题，目前如何处理，使用频率和损失是多少，期望行为是什么，哪些情况不处理，什么数据和权限参与，怎样判断上线成功。客户不需要先写技术方案，但需要指定一位能代表业务取舍的负责人。滚水科技负责补齐流程、异常、接口和验收问题，不能仅凭一句“加个积分商城”直接报准确工期。

评估时要查看直接工作和连带影响。新增会员等级可能改登录资料、订单折扣、退款、客服查询、历史数据迁移和报表；接企业微信可能涉及组织同步、身份绑定、消息频率、离职和数据授权；一个字段变化也可能影响 API、导入、导出和移动端。评估记录应列明假设与不做范围，避免双方对同一个名称想象不同产品。

优先级不宜只按提出人的职位。可以比较预期用户数、使用频率、节省时间或增加毛利、合规风险、实施成本和不做的后果，并标注证据可信度。高价值低风险项进入最近迭代；依赖数据或规则尚未确定的先做验证；只服务极少数例外的需求可保留人工入口。需求池不是“以后一定做”的承诺，而是可追踪的决策记录。

开发中的变更应保护已经确认的里程碑。较大需求可选择替换当前范围中的等量功能、顺延交付日期或作为下一阶段；三种选择都要书面确认。变更单写清新增和删除内容、设计或技术影响、费用、付款、日期、验收和保修起点。原合同范围继续按原标准验收，不能因为不断有新需求就永久处于“快做完”的状态。

小改是否免费以维护协议为准，不应承诺“一两天都免费”。维护费通常覆盖已交付功能的缺陷、约定巡检或一定工时，新增功能、第三方政策变化和大版本升级可能另计。更透明的方式是记录每项工作实际消耗、剩余额度和上线版本；客户确认后才开工。滚水科技的 服务流程 与 软件质保说明 可作为合同讨论入口，最终仍以具体项目条款为准。

每个迭代应有固定范围、测试环境和上线窗口。功能上线后观察预先定义的数据，例如使用人数、任务完成率、处理时间、错误率、客服量或收入变化；没有达到目标时，可以调整或关闭，而不是继续堆功能掩盖问题。高风险变化还应有灰度、开关和回滚方案，避免一次上线影响全部用户。

滚水科技鼓励系统根据真实使用持续改进，但不会把“可扩展”解释成无成本、无限制或不影响原有功能。