文｜蓝华峰Frank
01
“具体的活让AI干，你负责判断。”
每次听到这句话，我都会有一个念头：我以前的判断力，就是在干那些活的过程中，慢慢练出来的。
最近跟一些程序员交流，代码可以让AI写，测试请AI帮忙，出了问题，再把日志交给AI分析。很多原来需要自己折腾的事情，现在很快就有了结果。
我自己也在大量用AI。省下时间的好处，实在没什么可挑剔的。
只是，工作很快做完了，人就一定跟着长本事了吗？
尤其是刚开始工作的人。以前不会，得边做边问。现在可以先把结果交出去，至于里面怎么回事，晚一点再弄明白。
这个“晚一点”，很容易一直往后排。
我担心的倒不是以后没人手写代码了。我更想知道：一个人还没有多少经验的时候，怎么慢慢走到“这件事可以由你来判断”？
02
举个不需要懂代码的例子。
假设公司准备换一套内部提需求的流程。过去靠群里发消息，现在通过一个小工具提交、分派和跟进。AI已经帮忙把工具做出来，提交和分派等功能也测过了。
接下来，是让全公司直接用，还是先找一个小组试一周？
直接用，大家早点省掉来回找消息的麻烦，但出问题影响的人多。先试一周，影响范围小一些，却得暂时维持两套做法。
功能测试通过了，并没有替人回答这个问题。还得看换流程急不急，出了问题能不能退回去，以及试用的人能不能代表其他人。
假如我选了先试用，找来一个熟悉业务的小组。他们用得很顺，一周后，我觉得可以推广了。
结果其他人一用，问题出来了。新人不知道需求该分到哪一类，也不知道该选谁来处理。原先那个小组的人凭经验就能选对，试用时根本没在这里停过。
这些地方可以继续请AI协助修改，补上说明，再让新人试。工具最后也可能顺利用起来。
但对我来说，还有一个判断需要改：我以为那个小组用得顺，就足以说明其他人也能用。
如果只忙着改工具，改完就翻篇，下次我可能还会找同样一批熟手测试，再放心地推广。
工具修好了，不代表我已经看见，自己当初为什么判断错了。
03
我当年从程序员慢慢做到架构相关的工作，也不是代码写到某个数量，就突然会判断了。
从小程序到更大的系统，原来的理解会碰到实际问题。想过一个办法，做下去，发现有些地方和预想不一样，再回头调整。这样积累下来，后来看到某类方案，才会觉得这里值得多问一句。
所以，我不能只怀念当年亲手做过多少事。真正有用的，还包括那些让我发现自己想错了的过程。
用AI，也可以有这样的过程。
就像前面那次推广，即使工具是AI做的，我仍然可以先想清楚试用要验证什么，再看实际使用有没有暴露出意料之外的问题。AI也可以帮我分析反馈，找到遗漏。但试用结果能说明什么，不能因为工具最终上线了，就不再追问。
没必要为了练本事，把省掉的手工劳动再补回来。
但有一种省法值得留意：办法由AI推荐，过程也交给AI处理，最后结果看着不错，就直接结束了。至于自己原来怎么想、哪里没想到，都没留下来。
我现在也会提醒自己，读完AI一段解释，觉得“有道理”，和自己作过一个判断、后来知道它对不对，还隔着一次实际的检验。
解释可以继续听。可那个“原来我把这里想简单了”，得有机会发生在自己身上。
04
如果把这件事放到团队里，就不能只靠员工下班后自觉补课了。
一个新人原来几天才能做完的事，现在当天交上来，老板很可能就会把下一件事交给他。省下的时间，马上又被填满。
过了一年，再希望他独立处理复杂问题，光说“你要有自己的判断”，没有多大用处。
公司验收过他交上来的东西，有没有人和他聊过，当时为什么选这个办法，后来哪一处和预计不同？
还是前面那个工具。如果负责推进的人收到的反馈只有“已经上线，问题也修了”，这次工作就结束了。但如果有人和他一起看看，为什么试用时没发现新人会卡住，下次选试用人员时，他就有机会多考虑一层。
要让人练判断，就得允许这种讨论进入工作：事情做完了，但这个办法未必值得下次照用。
不必每件小事都复盘。可以挑那些以后还会遇到、选错了会付出代价的事，让负责人先说说准备怎么做，做完后再对照一次。
重要的是别把这个人的想法从头到尾都省略掉。
这样练，未必比过去慢，也不用把新人放到承担不起后果的事情上去试错。
我仍然愿意让AI多干活。只是如果公司以后需要一个能判断的人，就不能只关心他今天交出了什么。
活做完以后，还得有机会知道：自己当初哪里想对了，哪里想错了。
蓝华峰 Frank
创始人教练、高管教练
ICF认证PCC教练、LUXX认证MA分析师