# 我一直在问“为什么”：AI 时代我想保留的思维习惯

**Summary:** 一次和太太的对话，让我重新审视自己怎样成长为工程师和架构师：向身边的人学习，追问原因，验证假设，并在 AI 时代为决定负责。

- Canonical: https://markhuang.ai/zh/blog/i-keep-asking-why
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-14
- Section: 行为与心态
- Tags: 工程思维, 自我反思, 持续学习, 软件架构, AI, 判断力
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![卡通夫妻在餐桌边聊天，关于工程的思考从对话中逐渐展开](https://cdn.markhuang.ai/blog/i-keep-asking-why/hero.webp)

*本来聊着怎么当工程师这事儿，最后就绕回了一个问题：为啥？*

## 先说重点

今天跟太太聊天，聊到一个特别有意思的问题：一个人到底是咋变成工程师的？又是怎么一步步成长为架构师的？

一开始咱俩还在说技术啊经验啊这些硬东西。结果不到10分钟，话题就转到了思维方式上。这让我突然意识到，自己一直在用一个学习套路，但从来没好好给它起个名字：

- **观察：**看看别人和系统是怎么玩的，特别是那些比我处理得更好的时候。
- **追问：**别光看表面动作，得往深了挖——到底图个啥？有啥限制？做了啥取舍？
- **试试看：**换个法子在真实场景里干一把，过几天再回来看看到底管不管用。

我就靠这个套路来改进跟人合作的方式，也用它来设计系统。现在有了AI，这个套路反而更重要了。不是因为AI答不了"为啥"，而是因为听着挺有道理的答案，不一定就是靠谱的决定。总得有人去现实中验证一下，然后为结果负责吧。

## 太太问我的那个问题

那天我和太太本来就在瞎聊，说工程师和架构师到底是咋成长起来的。

最先蹦出来的答案都挺常规：会写代码、懂系统、能沟通、知道设计模式、技术够深、理解业务，还得有时间积累。这些当然都重要，但感觉单拎出来哪个都不够味儿。

聊了大概10分钟后，我们已经不数技能点了，开始聊一个人平时是怎么想问题的。这问题一下子戳到我了：跟其他干类似活儿的人比，我到底有啥不一样的地方？

以前同事老说我特有自驱力，干啥都贼有热情。但我自己一直说不清楚这是咋回事，反正不是每天早上给自己按个"加油"按钮那么简单。

写代码、用逻辑拆问题这事儿我都干了这么多年了，很多判断现在几乎是下意识的。我很少停下来想：哪些是经验攒的，哪些是刻意练的，又有哪些是从身边人那儿学来的。

认真想想，最先冒出来的不是代码，而是我对周围人的关注。

## 一个我从来没注意的习惯

![卡通工程师从同事身上学习冷静沟通、细致排查和清晰决策](https://cdn.markhuang.ai/blog/i-keep-asking-why/learning-from-others.webp)

*我不是想变成别人，就是想搞明白人家凭啥这么牛，然后学学自己缺的那部分。*

我经常看到某个人身上有个特别棒的点，就在心里默默记下来。

比如有人开会气氛紧张时还能保持耐心；有人能把复杂系统讲得明明白白，还不让人觉得自己笨；还有人知道啥时候该停止讨论直接拍板；细心的工程师能抓住所有人都觉得理所当然的假设；好的管理者能悄咪咪地把障碍清掉，还不用到处显摆自己多厉害。

事情一结束，我就忍不住回想：

- 他刚才那样说，咋就把对话变得顺溜了？
- 他看见了啥，我咋就没注意到？
- 要是换他来处理我刚才那事儿，会咋办？
- 下次我能试着学他哪一招？

如果光想着"人家就是比我牛"，那就变成比谁厉害了，根本学不到东西。真正有用的问题得具体：这次他到底做对了啥？为啥管用？我能学背后的道理，不用非得照搬人家的性格吧？

别人眼里的自驱力，可能就是下面这个循环在不停转：

1. 看到一个我觉得牛的行为。
2. 拿它跟我现在的做法比比。
3. 琢磨琢磨差别是咋来的。
4. 在真实场景里小试一把。
5. 过几天看看效果咋样。

学习这事儿会留下证据，让我知道自己真能变好。这些证据又勾起我的好奇心，然后我就又钻进下一轮去了。

外人看热情好像永远电量满格，但自己心里清楚得很。有时候热情来自挫败，有时候来自失败，也可能就是发现：哎，刚才那事儿人家确实处理得比我强。让我继续往前走的，就是相信这个差距里肯定有东西能学。

工程师这本事也是这么练出来的。我不是天生就会查线上bug，也不是一开始就能分清症状和病因，更不知道责任该放系统的哪一层。这些都是从写代码、犯错误、被review、吵架、处理事故、看书、做实验，还有跟想法不一样的人打交道中学来的。

最后感觉像直觉，但其实直觉都是练出来的。

这正是我之前没看清的联系。向别人学习和在工程里追问"为啥"，根本不是两码事，就是一个套路。我先看到差别，再找找差别是咋来的，然后换个法子试试，最后回来看看效果。我这么改自己的行为，也这么改系统。

AI让这个联系变得更明显了，因为AI能直接跳过训练过程给你结果。你可能很快就拿到能跑的代码，但没看到背后那些决定。代码也许没错，但里面的道理没进你的脑子，你的判断力还是没长进。

## 为啥AI让我看清了这个习惯

现在就业市场的情况还挺复杂的，但AI确实在自动化一些活儿，也在改变某些岗位。装看不见这压力，对谁都没好处。

我也不太信那种特别乐观的说法：每个消失的岗位都会马上冒出个同样好进的AI新岗位。新工作肯定会来，但转型的代价从来不是平均分摊的。今天工作受影响的人，不能拿三年后可能给别人的职位去付眼前的账单啊。

所以，担心是真的。很多人花好多年学会的本事，现在几秒钟就能出个成品。我没啥神奇预测能让这事儿变得舒服。

我的选择是主动拥抱变化。上篇反思里我说过[我在激进地用AI替代自己](/blog/aggressively-trying-to-replace-myself-with-ai)，这话到现在还是真的。

重复的问题、日常消息、机械的实现，还有老打断我专注的琐事，我都想甩给AI。只要一个任务能说清楚、能可靠检查，而且不用我判断就能反复干，我就会反过来问：为啥还要手动干？

我想保住的不是一堆任务清单，而是理解情况、判断啥重要、为方向负责的能力。

现在实现越来越便宜了，问题就不只是"能不能做出来"了。更重要的是：该不该做？哪些限制真该影响方案？哪些后果是我们愿意扛的？

这也是为啥我老回到"干啥"、"咋干"和"为啥"这三个问题的区别上。

## AI能帮着决定，但不能替你背锅

| 问题  | 通常在找啥        | 工程里的例子               |
| --- | ------------ | -------------------- |
| 干啥？ | 要交付的东西、需求、状态 | 这个功能或任务到底要改啥？        |
| 咋干？ | 方法、步骤、工具     | 该咋开发、测试和发布？          |
| 为啥？ | 目的、限制、取舍、理由  | 它凭啥要存在？为啥这个取舍在这儿能接受？ |

工程这活儿，三个问题缺一不可。

光问"为啥"，团队可能把目的聊得贼透彻，但就是不出活儿。光问"干啥"，很容易搞出一堆没方向的任务。光问"咋干"，可能用特别漂亮的方式解决了个错误的问题。

把代码库和一张边界清楚的Jira任务扔给AI，它可能准确告诉你哪儿要改、功能咋实现，任务状态该更新成啥。这确实能省不少时间。但任务本身未必说清楚：为啥这个功能值得花开发时间？为啥某条验收条件是在保护用户？为啥那个最明显的实现会把成本转嫁到别处？

说"AI管干啥和咋干，人类管为啥"听起来挺美，但我觉得没那么简单。

LLM能给一个功能列十条理由，能比较架构方案、猜业务目标，还能写出贼有说服力的决策记录。有时候它比我写得更快更全。

问题不在AI能不能编理由，而在这个理由该不该主导眼前这个决定。

模型只能看到我给的上下文。它不知道哪个利益相关者漏了关键顾虑，不知道团队实际能扛多大运维负担，也搞不清哪条需求主要是为了搞定内部关系，哪次历史失败还在影响信任，还有哪个今天成立的假设下季度就失效了。

它能帮我推理、反驳我，也能指出我没看见的选项。但听着有道理的解释，不等于扎在现实里的决定。最后还是得有人把解释放回现实中验证，然后为结果负责。

这不意味着AI在系统里永远不能做受限决定。意思是，搭系统的人还是得为边界、验证、升级路径和后果负责。

把这个区别放到架构问题里，看得更明白。

![卡通 AI 快速建造两条技术路径，工程师则在研究用户、地形、限制和真正的目的地](https://cdn.markhuang.ai/blog/i-keep-asking-why/choosing-the-path.webp)

*AI能教我咋建任何一条路；但架构师得先搞清楚，真正的目的地和地形到底是啥。*

比如说我要选`pgvector`还是`Neo4j`。

AI能解释两种技术是干啥的，能教我安装、生成数据结构和查询、比较常见取舍，还能很快搭出两个验证原型。

但这些信息加一块儿，还是不会自动变成决定。

我还得先问自己，面对的到底是啥问题。相似度搜索是不是工作的核心？关系是不是必须频繁遍历的一等数据？团队是不是已经很会维护PostgreSQL？哪些查询必须保持够快？我们能承受啥样的一致性、维护、迁移和故障成本？现在是在为已经测过的需求做选择，还是在为想象中的未来提前交学费？

答案可能是`pgvector`，可能是`Neo4j`，也可能以后俩都要。还有种经常被忽略的可能：现在一个都不需要。

架构师的价值，不是脑子里记着比别人更长的工具清单。清单当然有用，但更难的是把技术决定跟问题、用它的人、现实限制，还有多年后的影响连起来。

我以前写过自己的技术路子：[从软件开发者走到AI架构师](/blog/from-software-developer-to-ai-architect)，咋用技能包、脚本、MCP工具和SDK，最后意识到重要工作流的控制平面不该交给LLM。每一步都是从追问上个方案为啥失败开始的。实现给了我证据，"为啥"把一个个失败连成了方向。

对我来说，当架构师不意味着离开代码。很多架构假设，恰恰要到代码里才会露馅。变化在于看问题的范围变大了：不光看一个组件能不能跑，还得看系统为啥需要它、它会咋坏、谁来维护，还有它会让未来的哪些选择变得特别贵。

## 我在实际工作中咋用这个套路

上面说的听着有点玄乎，但我其实没啥正式的自我提升计划。这个套路就发生在平常工作中：

1. **观察。**先看清发生了啥，别急着替自己的第一反应找借口。
2. **追问。**找出产生结果的目的、假设、限制或者行为。
3. **试试。**在真实场景里小调整一下，最好能随时改回来。
4. **回看。**过段时间再看这个行为或决定后来咋样了，别光看做决定那一刻。

经历一次困难对话后，我会回想自己说了啥，再琢磨咋说会更清楚、更顺。准备做大改动前，我会试着用大白话说清楚理由和限制。AI给出方案后，我会问：哪些假设让它成了好方案？出现啥证据时，它就不成立了？

这个套路也会跑偏：

| 跑偏的情况       | 我咋修正                              |
| ----------- | --------------------------------- |
| 追问变成没完没了的分析 | 给调查设个时间，明确列出不知道的点，然后做个最小、能改回来的决定。 |
| "为啥"听着像审人   | 挑战假设和系统，别逼着人家为自己的价值辩护。            |
| 把有说服力的解释当证据 | 找找缺了啥上下文，明确这个解释在啥情况下会错。           |

有时候原因早就清楚了，下一步最有价值的就是干。第十次问"为啥"，也可能只是把拖延包装成深度思考。理由清楚到能行动了，就得回到"干啥"和"咋干"，把事儿做完。

如果一次追问从来没改变过任何决定或行为，那就不算深入，只是多了一套说法。

## 现在，我会咋回答太太

我想，这才是我当时真想告诉太太的答案。

我不是因为学会了某个工具、拿到了某个职位，或者发现了AI永远答不出的问题才成了工程师。我只是不断看到自己还不懂的地方，追问它为啥重要，换个法子试试，再从结果里继续学。

这只是一条路，不是标准答案。优秀工程师的成长方式可以完全不同。有人通过不断构建来学，有人通过教学来学；有人能在脑子里直接看见系统结构，有人对细节有惊人的敏感；也有人对人和组织的理解，远远超过任何一张架构图能表达的内容。

我能分享的，就是这个一直塑造我的习惯：留意周围人的优点，检查自己的回应，再追问这个差别为啥重要。

我其实不太担心以后完全找不到机会。这不代表我觉得自己不受就业市场影响，更不代表我独特到永远没法被替代。我的信心来自自己正在走的方向。

当我真理解了问题，能把技术选择和商业现实连起来，并且持续改善跟人合作的方式时，我知道自己能给公司带来多大变化。但我也知道，今天有价值的一项技能，明天可能就会变成几秒钟生成的结果。

所以，我不想把信心绑在某个工具、职位或任务上。我更愿意把它放在另一种能力上：继续学习，质疑自己的假设，并在新环境里重新变得有用。

技术能力重要，经验重要，沟通重要，重复练习重要，把事儿交付出来同样重要。

在这些能力下面，我找到了一个不断推着自己往前的循环。

"干啥"告诉我任务是啥。

"咋干"帮我把它完成。

"为啥"让我判断它值不值得干、眼前是不是合适的做法，以及我是否愿意承担结果。

AI能参与这三个问题。

而我仍然要成为那个能判断答案、采取行动，并在判断出错后继续学习的人。