产品经理在需求描述中常陷入文字迷宫的困境，一条看似简单的自然周计算规则竟引发团队认知断层。本文通过真实案例揭示：当PRD文档里的「如果…则…」层层堆砌时，真正需要的是用逻辑树实现思维可视化——它不仅能暴露分支漏洞，更让测试用例自动浮现。掌握这种表达范式，是从「自己想清楚」到「让所有人不误解」的关键跃迁。

先说一句实话。

这篇文章，不是我一开始就打算写的。

它是被需求逼出来的。

一、事情是怎么开始的（以及我当时有多自信）

事情发生在一个看起来毫无风险的需求上。

「周度数据的起止日期，按自然周计算。」

看到这句话的时候，我心里想的是：这有啥难的？不就一句规则吗？

我当时甚至有点轻敌。

于是我很自然地写了这样一段说明（你可能也写过）：

如果开始日期是周度第一天，则从该日期开始查询

如果不是，则从所在周第一天开始

结束日期同理

但不能超过今天

写完我还挺满意。

逻辑没毛病，对吧？

——问题，从这里开始。

二、需求评审现场，空气慢慢不对劲了

先是研发抬头问了一句：「那结束日期如果不是周日，但这个周日超过今天呢？」

我愣了一下，说：「那就取今天。」

测试马上接上：「那如果开始日期是周中，结束日期也是周中，而且跨周呢？」

前端补了一刀：「那页面上我们展示用户选的区间，还是实际计算区间？」

我突然意识到一件事：大家问的不是“你写得对不对”，而是——他们根本不知道你脑子里的逻辑长什么样。

那一刻真的很 PM。

熟悉的感觉又来了。

三、后来我想明白了一件事（很重要）

我回去复盘的时候，突然有点恍然大悟。

问题根本不在规则。

规则是对的。

大家也都不傻。

问题在于：我在用“线性文字”，描述一个“分支结构”的东西。

打个比方

你让我用一段话，描述一棵树怎么长。

你说得再详细，听的人脑子里长出来的，也可能是三棵不同的树。

规则型需求，本质就是一堆 if / else。

但我们偏偏爱用「如果…则…否则…同时…另外…」去硬写。

这事，本身就别扭。

四、转折点：我没继续改文案，而是换了种脑回路

那天我没再润色文字。

我做了一件现在回看很关键的事——

我拿了一张纸，开始画逻辑。

不写 PRD。

不想措辞。

就问自己一句话：

这条规则，真正要判断的，到底是哪几件事？

答案其实非常朴素：

• 开始日期：它是不是周一？
• 结束日期：它是不是周日？
• 如果不是，那个周日能不能用？（会不会穿越到未来）

就这两件事。

五、逻辑树一画出来，事情突然顺了

先看开始日期（简单到有点不好意思）

开始日期 S

├─ 是周一 → 用 S

└─ 不是周一 → 用 S 所在周的周一

这一步画完，我心里甚至有点愧疚：

这我刚才为什么能写那么复杂？

再看结束日期（麻烦都在这）

结束日期 E

├─ 是周日 → 用 E

└─ 不是周日

├─ 所在周周日 ≤ 今天 → 用周日

└─ 所在周周日 > 今天 → 用今天

画到这里的时候，我整个人是松的。

为什么？

因为你能一眼看出：

• 哪些情况被覆盖了
• 哪些情况不可能出现
• 哪些地方需要兜底

这在文字里，是完全看不出来的。

六、一个很真实的感受：逻辑树会“逼你说人话”

说个行业黑话：

逻辑树是最诚实的需求评审官。

你少考虑一个分支，它就画不下去。

你逻辑绕了一圈，自己先被绕晕。

而且更爽的一点是——

测试同学几乎不用你解释。

每个节点，都是一类测试用例。

每条路径，都是一组场景。

这感觉，太解放了。

七、什么时候你该警惕了？（一点血泪经验）

如果你遇到下面任意一种情况，真的，别硬写文字了：

需求里开始大量出现：「如果…」「但是…」「同时…」「另外一种情况是…」

有现实约束，比如：今天 / 未来 / 数据延迟 / 灰度

你发现自己在群里反复发长语音解释同一件事

这时候，问题通常不在你逻辑，而在表达形态选错了。

九、写在最后：这是个分水岭能力

我现在越来越确定一件事：

初级 PM 的能力，是把需求想明白；

成熟 PM 的能力，是让别人不想歪。

逻辑树不是画图技巧。

它更像一种习惯：

把脑子里的判断摊在桌面上

• 不指望“对方能懂你”
• 而是让误解本身没有生存空间

如果你也在被规则型需求折磨，下次试试先别急着写 PRD，先画一棵树，你会感谢自己的。