一提到“批判性思维”，很多人以为是“挑毛病”“跟人抬杠”。其实不是。批判性思维里的“批判”，是分析评断，不是批评；有人把它译成“明辨式思维”或“审辩式思维”，更贴切。它是“关于思考的思考”，目的是理清自己的思维，识别自己的错误和偏见，让理性最大化。它不是冥思苦想，也不是直接解决问题，而是向内的——比起发现别人的错误，更重要的是发现自己的错误。
对软件开发人员来说，这一点尤其重要。写文档、写代码、做测试，表面看都是向外产出，实际上质量高低，很大程度上取决于你能否审自己的假设、自己的逻辑、自己的盲区。
写技术文档：别把“我以为”写成“大家都懂”
技术文档最容易犯的错，是把作者脑子里的默认前提省略掉。接口文档写一句“超时后重试即可”，看似清楚，其实埋了坑：重试几次？间隔多久？接口是否幂等？失败后返回什么？写的人觉得“这还用说”，读的人却只能猜。批判性思维要求你在落笔后回头审：读者是谁？我交代了前提吗？有没有把假设写成事实？有没有反例会让这段描述失效？一份好文档，不是辞藻漂亮，而是逻辑清楚、边界明确、可被验证。先审自己的文档，比等别人来挑错强得多。
编码实现：先质疑自己的“理所当然”
编码时，开发者常常顺着直觉往下写：“这个参数不会为空”“这个循环不会太大”“这个接口不会超时”。这些“不会”就是思维里的隐藏假设。批判性思维不是让你怀疑一切，而是让你把这些假设摆到桌面上，问一句：如果它发生了呢？空数组、重复元素、超大输入、并发访问、异常返回，代码还成立吗？注释和实际逻辑一致吗？变量名有没有掩盖真实含义？很多缺陷不是不会写，而是写的时候没审自己。写完一段逻辑，先扮演自己的“反方”：什么输入能让它出错？哪条路径我没走到？先把己误找出来，代码质量就上了一个台阶。
单元/集成测试：不是证明“能跑”，而是试图“推翻”
测试最怕一种心态：跑通了，就认为没问题。单元测试只覆盖正常路径，断言只写“不抛异常”，集成测试只测联调成功，不测超时、错误码和重试——这都是在用“能跑”安慰自己。批判性思维要求测试者向内审：我的用例是不是只选了好走的路？断言够不够强？我是不是只找了支持“代码正确”的证据，忽略了可能推翻它的场景？集成测试还要审接口契约：我是不是假设对方一定按我想的返回？边界、异常、失败路径，才是测试真正该盯的地方。测试不是给代码发奖状，而是帮自己找反例。
先审自己，再谈质量
代码评审时，很多人习惯先看别人哪里不对。批判性思维提醒我们：更有价值的是先审自己。文档里的模糊表述、代码里的隐含假设、测试里的薄弱断言，都是自己思维偏见的投影。发现自己的错误，比发现别人的错误更能提升质量。GJB5000B强调验证与确认、质量保证，落到每个开发者身上，第一步不是应付检查，而是养成“关于思考的思考”的习惯：我为什么这么写？依据是什么？反例是什么？还有没有别的可能？
批判性思维不是让人变得挑剔，而是让人变得清醒。对软件开发人员来说，它是写文档时的边界感，是编码时的反例意识，是测试时的推翻冲动。先破己误，再谈交付。
最后用四句诗总结：
莫把批判当批评，
向内审思见真形。
文档代码测试事，
先破己误方可行。
参考书目：一读就上瘾的逻辑学，作者：阿健，出版社：天地出版社
