核心问题

PM 如何从代码痕迹里读懂业务规则？

真实场景

PRD 里写“用户可以取消订单”，但代码里有很多分支：

已支付不能直接取消
已发货只能申请售后
企业客户走人工审批
活动订单不能退券

真实业务不在一句需求里，而散落在代码的条件分支里。

常见误区

坏判断是：

PRD 写了什么，系统就是什么。

很多系统运行多年后，代码才是最真实的业务档案。

工程视角

从代码里读业务，可以重点看：

  • 命名：核心概念是什么。
  • 条件分支：哪些例外被特殊处理。
  • 状态字段：业务生命周期如何流转。
  • 错误信息：系统认为哪些行为非法。
  • 注释：过去的人想提醒什么。

这些都是业务知识。

PM 可以怎么做

PM 不一定要看懂所有实现，但可以和工程师一起读关键片段：

  • 这里有哪些业务状态？
  • 哪些条件是历史特殊规则？
  • 哪些分支对应当前 PRD 没写的规则？
  • 哪些字段名和业务语言不一致？

Atlas Action

做复杂需求前，整理一张“代码里的业务规则表”：

规则：
代码位置：
业务含义：
是否仍然有效：
这次需求是否影响：

小结

代码不是纯技术材料，它也是业务规则的沉积层。

PM 会读代码背后的业务，就能避免把系统当成空白画布。