上周帮朋友公司看一个老系统，页面卡顿、按钮点不动、提交总报错。开发说：‘我们正做重构，把旧代码全重写一遍。’结果上线三天，销售团队炸锅了——客户下单流程少了‘发票抬头’字段，订单导出格式也变了。问为啥没提前说，开发摊手：‘这不就是技术活嘛，产品经理又不懂代码。’
重构不是‘程序员闭门造车’
很多人以为重构=换个写法、优化下性能、把 for 改成 map。但真实项目里，一次重构常牵扯到：表单字段增删、操作步骤合并或拆分、数据展示逻辑调整、甚至整个模块入口迁移。这些变化，用户看不见代码，但立刻能感觉到‘怎么和以前不一样了？’
比如有个电商后台的订单管理页，原来点击‘发货’弹窗填快递单号，重构后改成直接在列表行内输入+回车确认。看似更高效，但仓管员习惯用鼠标批量操作，回车误触导致发错货——这个‘体验断层’，只有天天听一线反馈的产品经理才可能提前预判。
哪些重构场景，产品经理必须到场？
① 涉及用户操作路径变更
像把‘新建→填写→保存→上传附件→发布’五步压缩成三步，每少一步都可能绕过某个校验环节，或让某类用户（比如老年商户）找不到入口。
② 数据结构或字段语义调整
把数据库里 user_type 字段从 0/1 改成枚举值 'individual'/'enterprise'，后端改完没问题，但前端筛选栏文案、导出 Excel 表头、客服查单话术全得同步更新——这些不是代码问题，是产品一致性问题。
③ 第三方对接逻辑变动
原系统调用微信支付接口带 attach=invoice 参数触发开票，重构时被当成冗余字段删了。结果财务对不上账，因为微信回调里再也没传发票信息。
产品经理不用写代码，但得懂‘改了之后会怎样’
不需要你读懂 Spring Boot 的 AOP 切面，但得清楚：
• 这个按钮点击后，前端发几个请求？后端返回哪些字段？
• 如果把这个弹窗改成抽屉式，移动端滑动会不会误操作？
• 原来导出的 CSV 有 12 列，新版本只导 8 列，运营同事拿去跑报表还行不行？
建议做法很简单：重构前拉个 15 分钟站会，开发讲清‘哪些交互/数据/跳转会变’，产品经理快速确认影响范围，当场标出要同步更新的文案、埋点、培训材料。省下的返工时间，够喝三杯咖啡。
最后说句实在的：代码可以重写，用户信任和业务连续性，没法 rollback。