上一篇文章里，我提到了一个重要的问题：
AI 编程的效果，很大程度上取决于我们能不能用正确的概念描述问题。
但这里其实还有一个更麻烦的问题：
如果我连应该使用什么概念都不知道呢？
比如有人遇到一个问题：
我的网站打不开了。
他知道自己需要解决这个问题，但不知道应该从哪里开始分析。
是 DNS 解析失败？
是 IP 被封？
是 TCP 握手失败？
是 HTTP 请求头错误？
还是服务器本身出了问题？
如果连这些概念都不知道，那么上一篇文章里提到的“用正确的概念描述问题”，其实也就无从谈起。
这让我想到自己学习网络相关概念时接触到的一个很有意思的东西：五层网络模型。
五层模型真正有用的地方，不是让我记住五个名词
物理层、链路层、网络层、传输层、应用层，这几个名字本身其实没什么特别。
真正让我觉得它有用，是因为从那以后，面对一个网络问题时，我多了一种思考方式：
这个问题到底发生在哪一层？
例如：
- 物理层：网线、光纤、无线信号
- 链路层：MAC、MTU
- 网络层：IP、路由
- 传输层：TCP、UDP、端口
- 应用层：HTTP、DNS
假设现在有人告诉我 TA 的电脑上不了网。
对于一个完全不了解网络的人来说，这几乎是一个整体问题。
但有了这个模型以后，我可以开始逐层排查：
有没有物理连接？
↓
链路是否正常？
↓
IP 能不能到达？
↓
TCP 连接能不能建立？
↓
应用层请求有没有正常返回？
这时候我仍然可能不知道答案。
但至少我知道应该从什么地方开始找答案。
我觉得这才是这类抽象模型真正有价值的地方。
它并不是简单地告诉你几个术语，而是给了你一个观察问题的坐标系。
一个概念体系，本质上是一张问题地图
在 AI 普及之前，我觉得学习这些概念的目的就是把知识记下来。
但后来发现，真正有用的并不是记住“TCP 是什么”“IP 是什么”，而是当问题出现时，可以用这些概念去描述问题。
相比于“网页打不开”这种非常模糊的描述。
DNS 解析正常，TCP 连接没有建立。
问题一下就具体了很多。
我们并没有凭空获得更多信息。
只是使用了一套概念，把原本混在一起的问题拆成了不同的部分。
也就是说，概念体系其实就是问题空间里的坐标系，或者说，一张地图。
它让我们知道一个现象应该从哪些维度去观察。
如果连这张地图都没有呢？
这其实就是上一篇文章没有展开的地方。
如果一个人第一次接触网络，只知道网站打不开。
他并不知道什么是 TCP，也不知道什么是 DNS，更不会想到“五层网络模型”。
这时候，AI 可以做一件很有意义的事情：
不是直接让 AI 解决问题，而是先让 AI 帮自己找到问题对应的概念。
例如可以先这样问：
我遇到了这样一个问题：
“我的网站有时候打不开，但有时候又正常。”
先不要告诉我怎么修，也不要写代码。
请告诉我，这类问题通常可以从哪些角度分析？涉及哪些常见概念？有没有类似的模型可以帮助我理解这个问题？
请用一个没有相关专业背景的人也能理解的方式解释。
这时候 AI 给出的可能就是下面这样：（以下为 DeepSeek 的真实回复节选）
链路模型
一次请求的完整链路：
> 客户端 → DNS 解析 → TCP 握手 → TLS 握手 → HTTP 请求 → 负载均衡 → 应用服务器 → 数据库/缓存 → 返回
专业上常称为：
- 请求路径
- 调用链
- 数据流
任何一环出现以下情况，都会导致间歇性失败：
- 丢包
- 延迟抖动
- 超时
- 连接重置
- 限流
- 熔断
专业价值： 理解“为什么有时候好、有时候坏”——因为链路上某一跳在抖动。
你可能还是不知道怎么解决，但至少知道了：
原来这个问题可以从这些角度来看。
接下来再去了解其中某一个概念，就容易得多。
AI 不只是用来给答案的
其实这和上一篇文章的思路是连起来的。
上一篇讲的是：
有了正确的概念，可以把更多信息告诉 AI。
本文则反过来：
如果自己没有概念，也可以让 AI 帮你把概念找出来。
整个过程可能变成：
遇到问题
↓
描述现象
↓
让 AI 帮我寻找相关概念
↓
理解这些概念
↓
重新描述问题
↓
让 AI 帮我解决
最开始，你可能只会说网页打不开。
后来可能会变成：“页面显示502，应该是中间的网关出问题了。”
再后来，也许你已经知道应该自己去查哪里了。
所以 AI 编程未必意味着“不需要学习”。
它更像是改变了学习的路径：
- 以前是先学习概念，再用概念解决问题
- 现在也可以先遇到问题，再借助 AI 找到理解问题所需要的概念
后记：乍看之下，这篇文章好像已经和 AI 编程没什么关系了。不过仔细想想，无论是让 AI 写代码，还是让 AI 帮自己理解一个问题，本质上都是在和 AI 共同建立一套描述问题的语言。