你缺的是一个好的环境。
技术评审会上经常能看到这样的场景：同一份方案摆在桌上，有人扫一眼就能提出五六个问题，并发竞争怎么处理、数据量大了会不会拖慢查询、上下游服务挂了怎么兜底。你看了半天觉得方案挺好的，甚至觉得人家提的那些场景也太极端了，真实业务哪有这么多幺蛾子。
过几个月，线上出了故障，一查根因，正是当初被别人提出来但没重视的那个边界情况。
这种差距从哪来？多数人的反应是：我不够细心，或者我经验不够。
这个归因方向有问题。
这不是细不细心的问题
很多人试过各种办法来补这块短板。看别人的技术方案学习，整理一套检查清单，每次做设计的时候逐条对照。有没有效果？有一点，但非常有限。
原因在于，边界情况是无穷无尽的。你整理出来的检查清单，覆盖的是你已经知道的那些问题。那些你还没意识到的问题呢？清单帮不了你。
能在技术评审里一眼看出问题的人，靠的不是记住了更多的清单条目。他们靠的是一种思维模式：拿到一个方案，大脑会自动去搜索「这个设计在什么条件下会出问题」。这个过程不需要刻意触发，已经变成了下意识的反应。
这种思维模式不是天生的，也不是看几篇文章就能练出来的。它是被训练出来的。
训练它的，是你所处的工作环境。
你缺的不是能力，是一个好的环境
张小龙说过一句话：人是环境的反应器。我们只是很多「输入」的「输出」。可以简单理解为：同一个人在不同的环境里，行为是不一致的。在哪里工作，和什么样的人共事，这些外部环境都会有意无意地形成输入，最终改变我们的行为。
一个程序员做技术方案能考虑多周全，和他所在的团队环境直接相关。这不是鸡汤，是观察了很多团队之后得出的判断。好环境提供的东西，具体来说有四样。
严格的代码审查文化
在一个对代码质量要求苛刻的团队里，你提交的每一行代码都会被人审视。变量命名是不是清晰，异常处理是不是完善，并发场景有没有加锁，接口入参有没有做校验。
一开始你会觉得烦，觉得同事太较真。时间长了你会发现，你写代码的时候已经开始自动考虑这些问题了。你的思维回路被重塑了。每次被别人指出一个问题，你的脑子里就多了一条「检查路径」。几百次下来，这些路径固化成了直觉。
陈皓在回忆自己成长最快的那段时间时说过：并不是因为我的努力，而是因为有很多比我厉害的人在Code Review上给了大量的帮助。加班996的时候，从来都不是成长最快的时候。和一群牛人在解决难题的时候，才是成长最快的时候。
高质量的方案评审
有些团队的技术方案评审是走过场。方案一贴，大家扫两眼，没人提问题，通过了。这种评审对你的成长没有任何价值。
好的团队不一样。资深工程师会在评审里追问：这个接口的幂等性怎么保证？消息消费失败了重试策略是什么？这张表数据量到百万级之后，这个查询还能走索引吗？上游服务超时了你这边怎么处理？
你参加了几十次这样的评审之后，即使只是旁听，你也会开始用同样的方式审视自己的方案。这些资深工程师的提问方式和思维路径，会慢慢内化成你自己的思维习惯。
线上事故复盘
每一次线上事故都是一个活教材。事故复盘做得好的团队，不是找一个人来背锅就算了，而是把整个故障链条拆清楚：根因是什么，为什么设计时没覆盖到这个场景，流程上有什么改进空间。
你参与过十几次高质量的事故复盘之后，脑子里会积累一个「失败模式库」。下次做技术方案的时候，这些失败模式会自动浮出水面：上次那个故障就是因为没考虑消息重复消费，这次我的方案里消息处理是不是也得做幂等？
这个失败模式库，教科书和博客里学不到。它只能从真实的生产事故中积累，而且是那种被认真复盘过的事故。
身边有高标准的人
标准这个东西是会传染的。在一个大家都觉得「功能能跑就行」的团队里，你很难对自己提出更高的要求。不是你不想，是你没有参照系。你不知道什么算好，什么算不够好。
墨问的创始人池建强曾经说过：如果一个人还没有形成自己坚固的内核，没有基本的价值评价体系，周遭环境对人的影响就更严重。进入职场后的前十年，提升自己最好的方法是努力让自己能够和更强的团队、更优秀的人在一起。好的环境会在潜移默化之中，塑造我们的思维方式。
当你身边的同事在做技术方案时都会考虑并发安全、数据一致性、服务降级、监控报警，你做方案的时候自然也会把这些纳入考虑范围。不是因为有人要求你这么做，而是在这个环境里，这就是「正常水准」。达不到这个水准，你自己会觉得不对劲。
心理学怎么解释这件事
上面这些观察，不只是个人经验，有成熟的心理学理论可以解释。把理论拉进来不是为了显得高级，而是为了回答一个关键问题：为什么环境的影响力这么大？人的大脑在这个过程中到底发生了什么？我用四个大师说过的理论来进一步阐述这个问题。
班杜拉的社会学习理论
心理学家班杜拉提出过一个概念：观察学习。人不需要自己亲身经历每一件事才能学会，通过观察他人的行为和结果，就能掌握复杂技能。
放到技术团队的场景里，你每次旁听一场方案评审，看到资深工程师怎么提问、怎么分析、怎么从一个看似完美的方案里揪出潜在风险，你就在进行观察学习。你不需要自己踩过那个坑，只需要看到别人指出那个坑，你的脑子里就会记下这条路径。
这就是为什么在好团队里成长快。你每天都在观察高手怎么思考，这种学习效率远高于自己闷头看书。
维果茨基的最近发展区
苏联心理学家维果茨基提出过「最近发展区」这个概念：一个人独自能解决的问题有上限，在有经验的人指导下能解决更难的问题。这两个上限之间的区域，就是最近发展区。成长最快的时刻，恰恰发生在这个区域里。
好团队提供的代码审查和方案评审，正好落在你的最近发展区。你自己做方案的时候可能想不到某个边界情况，资深同事在评审里指出来之后，你一听就懂，下次就能自己想到。这就是在最近发展区里的成长。
如果没有这个支撑，你可能要自己踩了坑才能学到，甚至踩了坑也不一定能意识到问题出在哪。
波兰尼的隐性知识
哲学家波兰尼把知识分为显性知识和隐性知识。显性知识可以写成文档、整理成检查清单；隐性知识存在于人的直觉和判断中，很难用文字完整表达。
识别技术方案中的边界情况，很大程度上属于隐性知识。一个资深工程师能一眼看出方案的薄弱环节，他未必能把这个判断过程完整地写成一份教程。这种能力的传递，主要靠的是日常协作中的言传身教：一起做方案评审、一起排查线上故障、一起讨论技术选型。
这也解释了为什么光看技术博客效果有限。博客能传递的是显性知识，而你真正缺的那部分，是需要在实际协作中才能获得的隐性知识。
卡尼曼的快思考与慢思考
诺贝尔经济学奖得主卡尼曼把人的思维分为两个系统：系统1是快速、自动、不费力的直觉思维；系统2是缓慢、刻意、需要注意力的逻辑思维。
资深工程师在评审方案时那种「一眼看出问题」的能力，是系统1的模式匹配在起作用。他的大脑经过大量真实场景的反复训练，已经建立了丰富的模式库。当一个方案呈现在面前时，系统1会自动把方案中的模式和已有的「失败模式」做匹配，匹配上了就触发警觉。
这个模式库不是背出来的，是通过大量的实战暴露逐渐构建的。在好环境里，你每天接触到的代码审查、方案评审、事故复盘，都在往你的模式库里添加新的条目。在差环境里，你每天接触到的都是「能跑就行」的低标准，模式库自然贫乏。
这四个理论指向同一个结论：技术设计能力的成长，高度依赖你所处环境提供的高质量输入。 自己闷头学能解决一部分问题，那些最关键的、最难通过文字传递的能力，只能在好的团队环境中养成。
好环境和差环境的差距
把上面讲的具体化成一张表，差距就很直观了：
| 维度 | 好环境 | 差环境 |
|---|---|---|
| 代码审查 | 严格审查，指出设计缺陷和潜在风险 | 看看能不能编译通过就批准了 |
| 方案评审 | 资深工程师逐条质询边界情况 | 走过场，没人提实质性问题 |
| 事故复盘 | 追根溯源，总结失败模式，改进设计流程 | 找个人背锅，下次注意 |
| 技术标准 | 并发安全、幂等性、降级方案是基本要求 | 功能跑通、测试通过就上线 |
| 反馈周期 | 每次提交代码都有具体反馈 | 半年绩效谈话才知道有问题 |
| 对你的影响 | 思维模式被持续训练和校准 | 标准不知不觉往下掉 |
给自己做个判断，看看当前的环境处于哪个位置：
- 你上一次在代码审查中收到有价值的改进建议是什么时候？
- 你的技术方案评审，有没有人会认真提出质疑？
- 团队出了线上故障，复盘的重点是追责还是改进？
- 你身边有没有一个技术标准明显比你高的人，你经常从他身上学到东西？
- 你最近半年的技术判断力，比半年前有明显提升吗？
如果大部分问题的答案都不乐观，你的环境可能正在限制你的成长。
如果当前环境不理想，怎么办
承认环境的重要性，不意味着没有好环境就只能认命。有几个务实的做法。
在现有团队里找到那个标准最高的人
每个团队里通常都有一两个技术水平明显高于平均线的人。主动去请教他们，请他们帮你审查方案，观察他们怎么思考问题。哪怕团队整体水平一般，只要有一个高手愿意带你，成长速度就会不一样。
参与开源项目
开源社区的代码审查标准通常很高，尤其是知名项目。你提交一个Pull Request，维护者和社区成员会从各个角度审视你的代码，指出你没想到的问题。这个过程和在好团队里接受代码审查效果类似。
给自己做对抗性评审
每次做完技术方案之后，换一个角色，假设你是一个很严格的评审者，从以下几个角度质疑自己的方案：
- 这个接口的入参如果是异常值会怎样？
- 并发请求打进来，数据一致性能保证吗？
- 依赖的下游服务如果挂了或者响应很慢，这边怎么处理？
- 数据量从现在的万级增长到百万级，当前方案还扛得住吗？
- 这个操作如果被重复执行了，会不会产生脏数据？
这个办法比没有反馈要好。不过诚实地说，效果不如真人评审。因为你的盲区你自己看不到，你提不出自己没有意识到的问题。对抗性评审能覆盖你「知道但容易忘」的部分，覆盖不了你「根本不知道」的部分。
认真考虑换一个环境
如果你已经在一个低标准的环境里待了两三年，技术标准在往下掉，身边没有可以学习的人，团队不做方案评审也不做事故复盘，那你需要认真评估：继续待下去的机会成本有多大。
池建强的建议很中肯：到什么山上唱什么歌。想做什么事，就把自己放到最合适的环境里去。别逆着来。
这不是说一定要去大厂。关键不在于公司大小，在于团队的技术标准和反馈机制。有些小公司的核心技术团队，标准并不比大厂低。
有人可能会想：我现在走不了，房贷车贷小孩学费，哪有那么容易换工作。这种顾虑完全合理。能换环境当然好，换不了的话，上面提到的「找一个高手」「参与开源」「对抗性评审」这几个办法可以同时推进。关键是意识到差距的存在，然后持续行动。最怕的是在一个低标准的环境里待久了，自己都感觉不到标准在下滑。
小结
技术方案设计能力这个话题，行业里讨论了很多年，多数建议集中在「多看源码」「多总结经验」「列检查清单」这些方向。这些建议不能说错，但它们跳过了一个更根本的前提：你得先有一个能持续给你高质量反馈的环境。
环境塑造的不是某一项具体技能，而是你的思维模式。 思维模式一旦形成，它会渗透到你做的每一个技术决策中。在好环境里被训练出来的「自动挑毛病」的思维习惯，会伴随你整个职业生涯。反过来，在低标准环境里养成的「能跑就行」的惯性，也同样根深蒂固。
我见过不少能力不差的程序员，在一个没有技术追求的团队里待了几年之后，技术判断力反而退步了。不是他们变笨了，是环境没有提供足够的刺激和反馈，思维模式中那些「检查路径」因为长期不被激活，慢慢退化了。
如果你正在为自己「想不到边界情况」这件事困惑，先别急着怀疑自己的能力。回头看看你所处的环境：你每天接收到的技术反馈质量怎么样？你身边有没有人在持续拉高你的标准？如果答案不理想，问题可能不在你身上。
参考的内容
- 池建强《人是环境的反应器》，来源于「墨问西东」公众号
- 陈皓《让我们来谈谈「努力就会成功」》
- Albert Bandura, Social Learning Theory, 1977
- Lev Vygotsky, Mind in Society: The Development of Higher Psychological Processes, 1978
- Michael Polanyi, The Tacit Dimension, 1966
- Daniel Kahneman, Thinking, Fast and Slow, 2011
最近在知乎出了「应付6000万会员的秒杀系统专栏」和「几亿用户,百万并发的C端商品系统实战」专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：
- 老码头的技术浮生录
它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。」
知识星球内后续将推出20+个付费专栏，覆盖电商全链路：
| 选购线 | 用户会员营销线 | 中后台 |
|---|---|---|
| 购物车服务 | 营销系统 | 订单系统 |
| 商品服务 | 用户系统 | 支付系统 |
| 菜单服务 | 结算服务 |
从前台选购到中后台结算，星球成员全部免费，后续新增也不额外收费。
我的知乎账号:
- SamDeepThinking