有次和新来的同事结对，写一个导出功能。我坐副驾位。他敲键盘的手速很快，快到让我怀疑他是在表演而不是在思考。二十分钟后他在一个方法里定义了 let temp = []，然后过了三行又写了个 let temp = []，同一个函数作用域里。我盯着那两行代码，内心戏演了一整出：要不要说？说了会不会显得我小题大做？他是不是故意的？最后我憋出一句"这个……重名了"，他愣了两秒，把下面那个改成了 let temp2。
那两秒的沉默里我看到了结对编程最真实的底色——它根本不只关于代码，它关于两个人类的脆弱和体面。我们花了大量时间讨论键盘该给谁、多久换一次搭档、怎么保持沟通顺畅，但真正的问题在于：你得当着另一个人的面，暴露自己思考过程中的那些不堪。这就是为什么结对编程在这么多人身上失效。你以为它难在技术层面？不是的。它的难，在于它强迫每个人把自己的思维过程像没剪辑的片段一样摊开来给别人看。写代码的时候可以糊弄自己，但旁边坐着的这个人，会让你那些还没成型、模棱两可、混乱到不可思议的想法无处遁形。
早几年我特别排斥结对。理由冠冕堂皇：会影响我的工作流、效率太低。现在回头看，真正让我不舒服的是——我对自己的代码其实没那么有底。一个人可以躲在"我之后再优化"的借口后面，结对之后再这么说，就显得像在给自己遮羞。这种被迫面对自己的感觉，太难受了。后来角色反过来，我带一个刚入职的年轻人做结对。那天下班前他问我：杨哥，你觉得我是不是不适合写代码？我问他为什么。他说，下午我看了你三个小时怎么写那个接口，你的思路也不是很清晰，怎么会做这行的？我当场笑出声。那一刻我意识到，他看到的恰恰是我努力隐藏了七八年的那部分——边写边纠结、改来改去、甚至临时推翻重来。我是资深工程师，可我的思考过程依然跟实习生一样乱。
于是反过来想了一个更绝望的问题：如果结对编程本质上是逼你暴露思维的混乱，那它对所有人都适用，只是大多数人宁可把责任推到方法不对、队友水平不行上面，也不肯承认自己害怕被看穿。这解释了为什么结对编程落地失败率这么高。不是流程问题，不是工具问题，是人的防御机制太过精密。那有没有解？我现在的答案可能有点消极：任何协作方式都绕不开人的脆弱。结对编程不会摧毁这种脆弱，也不会治愈它，它只是把它从键盘后面拽了出来，放到阳光下暴晒。能接受这种暴露的团队，结对自然流畅；不能的，换多好的流程也只是换个方式互相撒谎而已。
说了这么多，我还是在带新人的时候坚持用结对。倒不是因为它效率高、写出的代码质量好——当然它确实有好处，但你要问我具体什么好处，我反而张嘴说不出个一二三。我通篇没提什么知识传递、提高代码质量，因为那些都对，但都是表层的。真正让我坚持的理由没法写进PPT：每次跟人结对，都像在对一面镜子，照出自己思维的脏乱差，逼着我承认、收拾。这个过程不舒服，但我好像慢慢上瘾了。有点像自虐，又有点像疗愈。
