上一篇说到了：真正好的创新，往往不是“加改换拼”，而是对问题的重新理解；这一篇，我想更想往前走一步，谈两个更实际的问题：

在真实研究里，我们怎么判断，自己碰到的是表象，还是根因？

怎么判断一个工作是在对问题进行缝缝补补，还是找到了根治它的解药？

一、研究后期真正拉开差距的，往往是判断

读博前期，焦虑大多来自“不会做”：不会读文献，不会搭系统，不会把实验跑顺，也不知道一个问题该怎么拆。那个阶段的进步很直接——多学一点，就多会一点。

但到了后面，问题会变。你会做了，也能做了，真正困扰你的，常常不再是“做不出来”，而是：我现在是在逼近问题，还是在绕着问题打转？

从“不会做”到“会做”，进步是可见的；从“会做”到“做对”，考验的却不再只是能力，而是判断。

很多研究最后的差距，不在于谁多会几个技巧、多补几个实验，而在于谁更早看清：哪些改动只是在处理表面现象，哪些才真正碰到了决定系统上限的约束。

二、研究的差别，取决于停留在问题哪一层

第一层是现象。标注成本高、训练不稳定、泛化效果差……这些当然都是真问题，但更准确地说，它们首先是问题暴露出来的表层表现。看见现象，并不等于已经理解了问题。

第二层是约束。你开始追问：这些现象为什么会反复出现？是不是背后有一个更稳定、更底层的限制，在决定系统的边界？这时你不再只是问“哪里不好”，而是在问“到底是什么在卡住它”。

第三层是前提。再往前一步，你会意识到，系统受限也许不是因为某个模块不够强，而是因为我们默认接受了一组前提：任务如何定义，目标如何设定，路径如何展开，评测如何计算。很多时候，真正的边界，早已被这些前提给限定了。

停留在现象层，做的是修结果；推进到约束层，开始碰机制；触到前提层，才有机会改写问题。

很多工作之所以最后分量不够，不是因为做得不认真，而是停在了现象层：看到问题，就着手修补，却没有继续追问，真正反复决定结果的约束是什么。

三、怎么判断自己看到的是表面，还是根因

一个课题值不值得继续深挖，至少可以逼自己按下面几个问题往下压。

第一，这到底是偶然现象，还是稳定问题？

不是所有坏结果都值得上升成研究问题。真正值得往下挖的，是那些反复出现、换个数据、模型或设置仍然存在、很难靠局部修补消失的问题。只有当它表现出某种稳定性和结构性，我们才有必要把它当成研究对象。

第二，能不能通过思想实验和逻辑推演，把它逼成一个明确的矛盾？

真正值得研究的问题，往往不只是“这里表现不好”，而是你能顺着现有理解往下推，推出一个清楚的冲突：按理说，在这些条件下，系统本来应该做到 X；但它稳定地做不到。

这一步的关键，不是继续描述现象，而是追问：如果我们对这个系统的理解是对的，什么结果本该出现？现在为什么没有出现？

一旦这种落差稳定存在，现象就不再只是现象，而开始变成一个真正值得解释的矛盾。

第三，这个矛盾背后，真正反复起作用的约束是什么？

真实系统里，往往不止一个因素在起作用，但不是每个因素都同等重要。研究判断真正难的地方，不是列出一堆可能原因，而是识别：到底哪个因素在当前阶段主导着系统上限。谁被改动后会带来结构性变化，谁就更接近主导约束。

第四，你现在改的，到底是结果，还是生成结果的机制？

很多方法当然有效，也能解决一部分现实困难。但关键在于：这些改动有没有触到那个反复制造问题的机制？如果一个方法拿掉以后，系统仍然会被同一个问题卡住，那它大概率还是补丁。

第五，如果沿着现有路线一直补，还是绕不过同一个问题，那就该怀疑前提了。

这时候要怀疑的，也许已经不只是某个模块或机制，而是我们默认接受的那套前提。平均指标看的是结果，反常现象暴露的却往往是边界。更多数据没有换来泛化，某个模块只在局部条件下有效，这些未必只是噪声，更可能说明：真正限制你的，已经不是表面表现，而是更深一层的问题设定。

四、补丁没有错，错在把补丁当答案

回头看，很多人——包括我自己——都做过这种工作：问题明确，系统完整，实验能做出来，在既定框架里一点点往前推。每一步单看都合理，实验也做了不少。但问题就在于，工作量大，不等于都做到了核心点上。

这类坑最麻烦的地方，不是它明显错了，而是你做的时候会觉得每一步都对；文章被拒了一遍又一遍时，也常常说不清到底差在哪里。你会以为自己只是还差一点实验、差一点故事、差一点运气。可很多时候，真正差的不是“做得还不够满”，而是“问题打得还不够深”。

所以，局部优化当然有意义。真实研究里，很少有人一上来就直接打到根上，很多理解本来就是在一次次修补中长出来的。问题不在于补丁值不值得做，而在于你是否清楚：这个补丁到底缓解了什么，又还有什么根本限制并没有被触动。

研究最后看的，不是你把系统修得多复杂，而是你到底改了什么：你改的是结果，还是机制？你碰的是表面，还是约束？你是在完善原来的答案，还是终于开始怀疑：原来的问题，可能一开始就问窄了？

很多研究真正往前走的一步，往往不发生在原框架里继续做加法的时候，而发生在你终于意识到：

也许真正该改的，不是方法，而是问题。

（来源：微信公众号“博弈之翼”）