为什么某个行业的经验 ＞ 代码

这句话说出来容易被骂，尤其在一个到处都在讲"学会编程就能改变一切"的环境里。但我还是要说，因为它是我干活这些年最实在的一条体会：代码只是手里的那把锤子，决定你盖出什么的，是你脑子里那张图纸，而那张图纸来自你对这件事的真实理解。锤子可以买，图纸只能靠时间攒。

一、先说清楚我在说什么

我这句话里的"经验"，不是指"在这行待了很多年"这个资格，也不是指人脉或者资历。我指的是很具体的一件事：你对这门生意里那些"没说出口的常识"，掌握到什么程度。

每个行业都有一堆默认规则——从业者觉得理所当然、所以从来不会写进需求里的东西。这些规则没人教、也很难从文档里读出来，只能在实际做事的过程里撞出来。而它们往往决定了做出来的东西对不对路。

二、两次让我印象很深的对比

一个是别人身上看到的，一个是我自己吃的亏。

• 第一次：字面实现 vs 一眼看出漏了什么。有个需求大意是"把一批数据整理成一张表"。如果只按字面理解，写个程序跑一遍就完事了。但对方是那个领域里做过几年的人，第一句话问的是"这些数据从哪来、谁填的、有没有可能填错"。后来发现确实有一类数据是手填的、格式不统一，如果不做校验和清洗，整理出来的表是错的——但这一条，需求文档里一个字都没提。
• 第二次：我自己在陌生领域写的"能跑但不对味"。我要做一个我不熟悉的领域的处理逻辑，手上有别人写的说明。我严格按说明实现，测试也通过了。交出去之后，对方反馈"能跑，但不对"。原因是说明里省略了一批"我们平时就是这么干的"边界情形——而这些情形不写进代码，程序在正常数据上永远看不出问题，只会在真实场景里偶尔出错。

这两件事的共同点很有意思：问题都不在代码上。第一次的差距是"想到了没写进需求的东西"，第二次的差距是"没人写进说明的常识"。两次代码本身都写对了，结果却差很远。

三、为什么代码容易让人高估自己

我认真想过这个问题。代码这门手艺有几个特点，会系统性地让人产生"我很强"的错觉：

• 它有即时反馈。写完跑一下，通过就是通过、报错就是报错。这种干脆的反馈会给人一种"我能判断对错"的掌控感。
• 它的对错是可验证的。程序在给定输入下给出错的结果，这件事没有争议，不用跟人辩解。相比之下"这个需求其实理解错了"这种事，往往要等很久、甚至等用户损失了才暴露。
• 它产出可见。一堆代码、一个能点开的页面，这些都是看得见的成果。而"我花了两周把这件事想清楚了，最后发现不用做"——这种成果没有人能看见，连自己都不太好意思说。

于是出现一个很常见的失衡：人们系统性地高估"把东西做出来"的价值，系统性低估"想清楚要做什么"的价值。因为前者的成果看得见，后者的成果只是"避免了一次错误"，而避免掉的错误人们不会记得。

四、经验到底值钱在哪

不是为了给"经验"这个词抬轿子，我想把它的具体价值拆出来，因为它其实是可以被观察的：

1. 能分辨哪些需求是真的，哪些是伪的

提需求的人往往说的是"他想到的解法"，不是"他真正的困难"。没经验的人照着解法做，做完发现没解决困难；有经验的人会往回问一句"你原来是怎么干的，哪一步最难受"，往往能找到一个更简单的真问题。

2. 知道哪里会卡

每个行业都有一批隐性的约束条件——某些环节必须按固定顺序、某些数据天然不干净、某些规则只在特定时段生效。这些都不在设计图里，但都会在真实运行中咬人。提前知道它们，就能提前留出处理空间；不知道，就只能等着被咬。

3. 知道真实的人会怎么用

设计时的用法和实际用法经常是两回事。有人在输入框里贴一整段带格式的文字、有人会在网络很差的车上操作、有人会把中间步骤跳过。这些都不难处理，但前提是你得先知道它们会发生。

4. 知道什么会变、什么不会变

行业里的规则、口径、流程，哪些是稳定的，哪些过两个月就调整——这个判断只有待在里面的人才做得出。而它直接决定你哪个部分该做扎实、哪个部分该做成能随时改的样子。

5. 知道什么代价是可以接受的

技术喜欢追求"更优解"，但现实里的很多场合，一个够用且立刻能跑的方案，比一个更优但要等三个月的方案价值高得多。这个判断需要你知道这件事的紧迫程度和容错空间——而这些信息只存在于业务现场。

五、两者不是对立的

说到这里必须补一句，免得被理解成"代码不重要"。不是这个意思。两者的关系我理成这样：

两个都缺不了。只有经验不会写代码，那想法永远停在纸上；只会写代码不懂这行，那做出来的东西大概能跑但不对。真正稀缺的是两样都有一点点的人——而更常见的情况是，很多人代码水平其实够用了，卡住他的是对这件事的理解。

六、那我现在怎么做

这条体会改变了我干活的顺序，很具体：

1. 先问、先看，再动手。接到不熟的领域，我第一件事不是打开编辑器，是找做过这件事的人聊，或者自己去看真实的数据长什么样。宁可多问半小时，也不带着错误理解写三天。
2. 逼自己把"为什么"写下来。写需求的时候不只写"要做什么"，还写"为什么要做、不做会怎样"。写不出来，说明我还没想清楚，那就继续问。
3. 先做一个能跑的最小版本给对方看。比起憋一个月拿出一个"完整"的东西，早点让对方看到雏形、早点纠正理解偏差，返工量会小一个数量级。
4. 把"能跑"和"对味"分开验收。"程序没报错"是最低标准。真正的验收问题应该问：它有没有解决你原来那件难受的事？