本页目录

题目不稳时它最好用，题目清楚时它会变慢

三个特征同时出现，重命题收益最大

现场很吵，大家都觉得"问题已经很明显了"。恰好是重命题最值得调用的时候——症状越突出，越容易把表象直接命名成题目。

组织协作、流程失灵、跨团队扯皮、用户投诉、重复故障，这些场景的共同点是：你第一眼看到的那个麻烦，大概率只是入口，不是全貌。

只要一个问题同时具备三个特征——现象很显眼、责任很混乱、第一反应方案看起来很顺手——通常就值得先重命题。

如果面对的是一道很清楚的数学题、一个明确的实现任务、一次需要立刻止血的线上事故，重命题的收益迅速下降。

不是方法错，是瓶颈不在题目定义。

还有一种弱区：结构性约束已经清楚，但执行迟迟不到位。该谁改、改什么、怎么验收都已经清楚，只是资源没给够、优先级没排上。继续追问"问题到底是什么"不会带来更多清晰，只会让大家暂时逃离执行压力。

有人学会之后反过来把它当挡箭牌。任何事一来，先说题目没定义清、边界没确认好、归属还要再看。表面很谨慎，实际在延后承担。

重命题的意义是让行动更准，不是让行动无限后撤。

一旦团队高频出现"再定义一下问题""我们还需要更多澄清"但没有收束动作——方法已经空转了。

不是所有问题都有一个优雅、深层、一次命中的根部。有些问题就是脏、碎、混着结构和偶然。

执着于找到一个完美的问题定义，就会永远卡在定义阶段。更稳的做法：定义到足够支持下一个动作，而不是定义到绝对完美。

归属判断本来是为了找准结构位置，不是为了把责任尽快甩出去。

如果一旦问"是谁的问题"，团队气氛立刻变成推责比赛——这一步已经被误用成保护自己，而不是看清系统。

稳的做法，是同时看承受后果的人、制造条件的人和能改结构的人。只抓其中一类，判断会变形。

出现这些情况，重命题该先让位：

一句话边界：重命题最适合阻止"解错题"，不适合替代执行。