夜雨聆风
四、最容易争议的几类修改
第一类是“加字段”。
比如客户说：“后台这里再加一个备注字段就行。”
看起来只是一个字段，但它可能涉及数据库、前端表单、后台列表、搜索、导出、权限、历史数据兼容。如果只是展示字段，工作量可能不大；如果牵涉数据流转，就可能是新增需求。
第二类是“改流程”。
比如原来订单提交后直接进入待处理，现在要求先经过管理员审核。这个就不只是改一个按钮，而是改变了业务流程，一般应按新增需求处理。
第三类是“加权限”。
比如原来后台所有管理员权限一样，现在要求老板、店员、财务看到不同菜单和数据。这通常涉及角色、权限、数据范围控制，基本属于新增需求。
第四类是“加统计”。
比如原来只要订单列表，现在想看销售趋势、用户来源、成交转化。这不是简单展示，而是数据统计规则，通常也属于新增需求。
第五类是“页面重新设计”。
如果只是微调颜色、间距、文案，可以算优化；但如果要重做页面结构、交互方式、信息层级，就不应该当作普通 Bug 修改。
五、验收反馈应该怎么提？
比较好的反馈方式不是一句“这里不对”，而是写清楚四件事：
第一，在哪个页面。
第二，进行了什么操作。
第三，实际出现了什么结果。
第四，期望结果是什么。
比如：
“后台订单管理页，选择 2026 年 7 月 1 日到 7 月 5 日后点击筛选，实际仍然显示全部订单；期望只显示这个时间范围内的订单。”
这种反馈方式，开发方很容易判断是不是 Bug，也方便快速修复。
如果只是说“订单筛选有问题”，开发方还要反复追问页面、步骤、账号、数据和预期结果，沟通成本会变高。
六、提前写清边界，验收才不会扯皮
很多软件项目后期不愉快，不一定是技术问题，而是边界问题。
一开始没有说清楚哪些功能包含在报价里，哪些修改属于售后，哪些属于新增需求，到了验收阶段就很容易变成互相误解。
比较稳妥的做法是：
需求确认阶段，把页面、功能、角色、流程、字段、接口尽量写清楚。
开发过程中，如果要增加功能，及时确认是否属于新增需求。
验收阶段，Bug 按原约定修复，小优化可以协商处理，新增需求则单独评估工作量和费用。
这样对客户更透明，对开发方也更公平。
软件开发不是不能改，而是要先分清楚：
是在修 Bug，还是在做新增功能。
边界清楚，项目才更容易顺利收尾。
