我一直在问“为什么”:AI 时代我想保留的思维习惯
一次和太太的对话,让我重新审视自己怎样成长为工程师和架构师:向身边的人学习,追问原因,验证假设,并在 AI 时代为决定负责。
AI 驱动 · 每小时限 20 次请求

先说重点
今天跟太太聊天,聊到一个特别有意思的问题:一个人到底是咋变成工程师的?又是怎么一步步成长为架构师的?
一开始咱俩还在说技术啊经验啊这些硬东西。结果不到10分钟,话题就转到了思维方式上。这让我突然意识到,自己一直在用一个学习套路,但从来没好好给它起个名字:
- 观察:看看别人和系统是怎么玩的,特别是那些比我处理得更好的时候。
- 追问:别光看表面动作,得往深了挖——到底图个啥?有啥限制?做了啥取舍?
- 试试看:换个法子在真实场景里干一把,过几天再回来看看到底管不管用。
我就靠这个套路来改进跟人合作的方式,也用它来设计系统。现在有了AI,这个套路反而更重要了。不是因为AI答不了"为啥",而是因为听着挺有道理的答案,不一定就是靠谱的决定。总得有人去现实中验证一下,然后为结果负责吧。
太太问我的那个问题
那天我和太太本来就在瞎聊,说工程师和架构师到底是咋成长起来的。
最先蹦出来的答案都挺常规:会写代码、懂系统、能沟通、知道设计模式、技术够深、理解业务,还得有时间积累。这些当然都重要,但感觉单拎出来哪个都不够味儿。
聊了大概10分钟后,我们已经不数技能点了,开始聊一个人平时是怎么想问题的。这问题一下子戳到我了:跟其他干类似活儿的人比,我到底有啥不一样的地方?
以前同事老说我特有自驱力,干啥都贼有热情。但我自己一直说不清楚这是咋回事,反正不是每天早上给自己按个"加油"按钮那么简单。
写代码、用逻辑拆问题这事儿我都干了这么多年了,很多判断现在几乎是下意识的。我很少停下来想:哪些是经验攒的,哪些是刻意练的,又有哪些是从身边人那儿学来的。
认真想想,最先冒出来的不是代码,而是我对周围人的关注。
一个我从来没注意的习惯

我经常看到某个人身上有个特别棒的点,就在心里默默记下来。
比如有人开会气氛紧张时还能保持耐心;有人能把复杂系统讲得明明白白,还不让人觉得自己笨;还有人知道啥时候该停止讨论直接拍板;细心的工程师能抓住所有人都觉得理所当然的假设;好的管理者能悄咪咪地把障碍清掉,还不用到处显摆自己多厉害。
事情一结束,我就忍不住回想:
- 他刚才那样说,咋就把对话变得顺溜了?
- 他看见了啥,我咋就没注意到?
- 要是换他来处理我刚才那事儿,会咋办?
- 下次我能试着学他哪一招?
如果光想着"人家就是比我牛",那就变成比谁厉害了,根本学不到东西。真正有用的问题得具体:这次他到底做对了啥?为啥管用?我能学背后的道理,不用非得照搬人家的性格吧?
别人眼里的自驱力,可能就是下面这个循环在不停转:
- 看到一个我觉得牛的行为。
- 拿它跟我现在的做法比比。
- 琢磨琢磨差别是咋来的。
- 在真实场景里小试一把。
- 过几天看看效果咋样。
学习这事儿会留下证据,让我知道自己真能变好。这些证据又勾起我的好奇心,然后我就又钻进下一轮去了。
外人看热情好像永远电量满格,但自己心里清楚得很。有时候热情来自挫败,有时候来自失败,也可能就是发现:哎,刚才那事儿人家确实处理得比我强。让我继续往前走的,就是相信这个差距里肯定有东西能学。
工程师这本事也是这么练出来的。我不是天生就会查线上bug,也不是一开始就能分清症状和病因,更不知道责任该放系统的哪一层。这些都是从写代码、犯错误、被review、吵架、处理事故、看书、做实验,还有跟想法不一样的人打交道中学来的。
最后感觉像直觉,但其实直觉都是练出来的。
这正是我之前没看清的联系。向别人学习和在工程里追问"为啥",根本不是两码事,就是一个套路。我先看到差别,再找找差别是咋来的,然后换个法子试试,最后回来看看效果。我这么改自己的行为,也这么改系统。
AI让这个联系变得更明显了,因为AI能直接跳过训练过程给你结果。你可能很快就拿到能跑的代码,但没看到背后那些决定。代码也许没错,但里面的道理没进你的脑子,你的判断力还是没长进。
为啥AI让我看清了这个习惯
现在就业市场的情况还挺复杂的,但AI确实在自动化一些活儿,也在改变某些岗位。装看不见这压力,对谁都没好处。
我也不太信那种特别乐观的说法:每个消失的岗位都会马上冒出个同样好进的AI新岗位。新工作肯定会来,但转型的代价从来不是平均分摊的。今天工作受影响的人,不能拿三年后可能给别人的职位去付眼前的账单啊。
所以,担心是真的。很多人花好多年学会的本事,现在几秒钟就能出个成品。我没啥神奇预测能让这事儿变得舒服。
我的选择是主动拥抱变化。上篇反思里我说过我在激进地用AI替代自己,这话到现在还是真的。
重复的问题、日常消息、机械的实现,还有老打断我专注的琐事,我都想甩给AI。只要一个任务能说清楚、能可靠检查,而且不用我判断就能反复干,我就会反过来问:为啥还要手动干?
我想保住的不是一堆任务清单,而是理解情况、判断啥重要、为方向负责的能力。
现在实现越来越便宜了,问题就不只是"能不能做出来"了。更重要的是:该不该做?哪些限制真该影响方案?哪些后果是我们愿意扛的?
这也是为啥我老回到"干啥"、"咋干"和"为啥"这三个问题的区别上。
AI能帮着决定,但不能替你背锅
| 问题 | 通常在找啥 | 工程里的例子 |
|---|---|---|
| 干啥? | 要交付的东西、需求、状态 | 这个功能或任务到底要改啥? |
| 咋干? | 方法、步骤、工具 | 该咋开发、测试和发布? |
| 为啥? | 目的、限制、取舍、理由 | 它凭啥要存在?为啥这个取舍在这儿能接受? |
工程这活儿,三个问题缺一不可。
光问"为啥",团队可能把目的聊得贼透彻,但就是不出活儿。光问"干啥",很容易搞出一堆没方向的任务。光问"咋干",可能用特别漂亮的方式解决了个错误的问题。
把代码库和一张边界清楚的Jira任务扔给AI,它可能准确告诉你哪儿要改、功能咋实现,任务状态该更新成啥。这确实能省不少时间。但任务本身未必说清楚:为啥这个功能值得花开发时间?为啥某条验收条件是在保护用户?为啥那个最明显的实现会把成本转嫁到别处?
说"AI管干啥和咋干,人类管为啥"听起来挺美,但我觉得没那么简单。
LLM能给一个功能列十条理由,能比较架构方案、猜业务目标,还能写出贼有说服力的决策记录。有时候它比我写得更快更全。
问题不在AI能不能编理由,而在这个理由该不该主导眼前这个决定。
模型只能看到我给的上下文。它不知道哪个利益相关者漏了关键顾虑,不知道团队实际能扛多大运维负担,也搞不清哪条需求主要是为了搞定内部关系,哪次历史失败还在影响信任,还有哪个今天成立的假设下季度就失效了。
它能帮我推理、反驳我,也能指出我没看见的选项。但听着有道理的解释,不等于扎在现实里的决定。最后还是得有人把解释放回现实中验证,然后为结果负责。
这不意味着AI在系统里永远不能做受限决定。意思是,搭系统的人还是得为边界、验证、升级路径和后果负责。
把这个区别放到架构问题里,看得更明白。

比如说我要选pgvector还是Neo4j。
AI能解释两种技术是干啥的,能教我安装、生成数据结构和查询、比较常见取舍,还能很快搭出两个验证原型。
但这些信息加一块儿,还是不会自动变成决定。
我还得先问自己,面对的到底是啥问题。相似度搜索是不是工作的核心?关系是不是必须频繁遍历的一等数据?团队是不是已经很会维护PostgreSQL?哪些查询必须保持够快?我们能承受啥样的一致性、维护、迁移和故障成本?现在是在为已经测过的需求做选择,还是在为想象中的未来提前交学费?
答案可能是pgvector,可能是Neo4j,也可能以后俩都要。还有种经常被忽略的可能:现在一个都不需要。
架构师的价值,不是脑子里记着比别人更长的工具清单。清单当然有用,但更难的是把技术决定跟问题、用它的人、现实限制,还有多年后的影响连起来。
我以前写过自己的技术路子:从软件开发者走到AI架构师,咋用技能包、脚本、MCP工具和SDK,最后意识到重要工作流的控制平面不该交给LLM。每一步都是从追问上个方案为啥失败开始的。实现给了我证据,"为啥"把一个个失败连成了方向。
对我来说,当架构师不意味着离开代码。很多架构假设,恰恰要到代码里才会露馅。变化在于看问题的范围变大了:不光看一个组件能不能跑,还得看系统为啥需要它、它会咋坏、谁来维护,还有它会让未来的哪些选择变得特别贵。
我在实际工作中咋用这个套路
上面说的听着有点玄乎,但我其实没啥正式的自我提升计划。这个套路就发生在平常工作中:
- 观察。先看清发生了啥,别急着替自己的第一反应找借口。
- 追问。找出产生结果的目的、假设、限制或者行为。
- 试试。在真实场景里小调整一下,最好能随时改回来。
- 回看。过段时间再看这个行为或决定后来咋样了,别光看做决定那一刻。
经历一次困难对话后,我会回想自己说了啥,再琢磨咋说会更清楚、更顺。准备做大改动前,我会试着用大白话说清楚理由和限制。AI给出方案后,我会问:哪些假设让它成了好方案?出现啥证据时,它就不成立了?
这个套路也会跑偏:
| 跑偏的情况 | 我咋修正 |
|---|---|
| 追问变成没完没了的分析 | 给调查设个时间,明确列出不知道的点,然后做个最小、能改回来的决定。 |
| "为啥"听着像审人 | 挑战假设和系统,别逼着人家为自己的价值辩护。 |
| 把有说服力的解释当证据 | 找找缺了啥上下文,明确这个解释在啥情况下会错。 |
有时候原因早就清楚了,下一步最有价值的就是干。第十次问"为啥",也可能只是把拖延包装成深度思考。理由清楚到能行动了,就得回到"干啥"和"咋干",把事儿做完。
如果一次追问从来没改变过任何决定或行为,那就不算深入,只是多了一套说法。
现在,我会咋回答太太
我想,这才是我当时真想告诉太太的答案。
我不是因为学会了某个工具、拿到了某个职位,或者发现了AI永远答不出的问题才成了工程师。我只是不断看到自己还不懂的地方,追问它为啥重要,换个法子试试,再从结果里继续学。
这只是一条路,不是标准答案。优秀工程师的成长方式可以完全不同。有人通过不断构建来学,有人通过教学来学;有人能在脑子里直接看见系统结构,有人对细节有惊人的敏感;也有人对人和组织的理解,远远超过任何一张架构图能表达的内容。
我能分享的,就是这个一直塑造我的习惯:留意周围人的优点,检查自己的回应,再追问这个差别为啥重要。
我其实不太担心以后完全找不到机会。这不代表我觉得自己不受就业市场影响,更不代表我独特到永远没法被替代。我的信心来自自己正在走的方向。
当我真理解了问题,能把技术选择和商业现实连起来,并且持续改善跟人合作的方式时,我知道自己能给公司带来多大变化。但我也知道,今天有价值的一项技能,明天可能就会变成几秒钟生成的结果。
所以,我不想把信心绑在某个工具、职位或任务上。我更愿意把它放在另一种能力上:继续学习,质疑自己的假设,并在新环境里重新变得有用。
技术能力重要,经验重要,沟通重要,重复练习重要,把事儿交付出来同样重要。
在这些能力下面,我找到了一个不断推着自己往前的循环。
"干啥"告诉我任务是啥。
"咋干"帮我把它完成。
"为啥"让我判断它值不值得干、眼前是不是合适的做法,以及我是否愿意承担结果。
AI能参与这三个问题。
而我仍然要成为那个能判断答案、采取行动,并在判断出错后继续学习的人。
许可
Article text © 2026 Mark Huang. Licensed under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) unless otherwise noted. 文章文本可在非商业场景下分享或翻译,但需标注原文 URL。商业使用需事先取得书面许可,并清楚引用原始来源。
代码片段、截图、第三方素材和网站源码可能适用单独条款。
建议署名: Based on "我一直在问“为什么”:AI 时代我想保留的思维习惯" by Mark Huang, originally published at https://markhuang.ai/zh/blog/i-keep-asking-why.
相关文章
订阅更新
Go、AI/LLM 和分布式系统的技术文章,绝不滥发。
