学会提问：在 AI 时代如何正确提问起因
很早以前，GitHub 上就有一篇很经典的文章，叫《提问的智慧》（https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way）。
这篇文章我很早就看过。刚开始看的时候，觉得它有点“程序员社区规训”的味道，说话很直接，甚至有些不客气。但后来自己写教程、做课程、在群里答疑，以及被别人问问题问多了之后，我越来越觉得，它讲的其实是一个很基础的问题：
很多人不会提问。
这句话听起来可能有点冒犯。因为提问看起来是一个人人都有的能力，只要会打字，就能把问题发出去。
但实际情况是，很多人只是把一句话丢出来，并没有真正提出一个可以被回答的问题。
比如：
这个报错怎么解决？
为什么连不上？
有人会用这个工具吗？
小龙虾怎么安装？
这类问题不是不能问，而是信息量太少。看到这种问题的人，并不知道你想做什么，不知道你用了什么环境，不知道你已经尝试了什么，也不知道你卡在了哪一步。
换句话说，你不是在提问，你是在让别人替你猜上下文。
提问能力的现状
我发现很多人其实并不会提问。
这个现象在 AI 出现之后更加明显。以前你不会提问，可能只是群里没人理你。现在你不会提问，AI 也会回答你，而且还会回答得很像那么回事。
这就更麻烦了。
因为 AI 不会总是拒绝你。很多时候，它会顺着你的错误问题继续往下推，最后给出一个看似完整、但方向完全跑偏的答案。
比如前段时间遇到一个问题：Claude Code 启动之后一直卡在：
Checking connectivity...
如果用户只问：
Claude Code 为什么连不上？
那么很自然的排查方向是网络。
我们会看 DNS 能不能解析，看 443 端口能不能连，看 TLS 握手是否超时，看服务器出口网络是否有问题，看代理是否配置，看环境变量有没有冲突。
这些排查都没错。
但后面发现，用户真正想做的事情并不是“连接 Claude 官方服务”。
他真正想做的是：在服务器上使用 Claude Code 这个工具，但模型服务走 MiniMax、DeepSeek、Gemini，或者某个国内 API 转发服务。
这就不是同一个问题了。
前一个问题是：
为什么我的服务器连不上 Claude 官方服务？
后一个问题是：
我能不能让 Claude Code 接入第三方模型服务？如果能，Base URL、Token、模型名和协议兼容性应该怎么配置？
表面上看，它们都叫“连不上”。但实际排查路径完全不同。
如果你不把真实目标说出来，别人只能按照默认场景排查。最后就会出现一个很常见的情况：技术分析很完整，但解决的是错误的问题。
我以前是怎么学会提问的
我不是一开始就会提问。
我的生物信息学技能基本上是自学出来的。刚开始学的时候，也会遇到各种问题，也会想着去群里问别人。但后来慢慢发现，大部分问题其实在问别人之前，都可以先自己查一轮。
那个时候还没有现在这么强的 AI，遇到问题主要靠搜索。
我一般会先把报错复制出来，然后做几件事：
- 去掉自己机器上的路径和无关信息；
- 提取关键报错；
- 换不同关键词搜索；
- 中文搜不到就换英文；
- 只搜报错不行，就搜工具名、函数名、参数名；
- 官方文档、GitHub issue、博客、论坛一起看；
- 最后把多个来源的线索拼起来。
很多问题不是一个页面就能解决的。
有时候一个 GitHub issue 只告诉你这是版本问题，另一个帖子告诉你某个参数变了，官方文档告诉你新版行为已经调整，最后你还要自己跑几个命令验证。
这个过程很慢，但它训练了一个能力：看到一个问题时，不是马上问“谁能帮我”，而是先想“这个问题的本质是什么”。
它到底是网络问题、权限问题、路径问题、版本问题、参数问题，还是我对工具的理解从一开始就是错的？
这才是提问能力的基础。
提问不是把困惑发出去。
提问是先把混乱的问题拆成别人能理解、自己也能验证的结构。
我不会优先求助别人
我遇到问题时，一般不会优先求助别人。
不是因为我不需要别人帮助，而是因为我觉得，大部分问题在问别人之前，至少应该先问一遍自己。
以前我会先用百度、Google、Bing。
现在会加上 ChatGPT、DeepSeek、豆包、Kimi、Gemini 等 AI 工具。
但是核心逻辑没变：不要只依赖一个信息源。
搜索引擎会搜到过时内容。AI 会一本正经地胡说。论坛答案可能只适用于某个版本。官方文档也可能写得不完整。
所以真正重要的不是“我会用哪个工具”，而是我能不能从多个来源里面交叉验证，逐步逼近真实原因。
这也是为什么我觉得检索能力很重要。
很多人把搜索理解成“输入关键词，点开第一个结果”。但真正有效的搜索不是这样。它更像是一个不断缩小范围的过程。
比如一开始搜：
connection timeout
太宽了。
然后根据报错细节改成：
socket timeout 110
再结合工具和场景：
python requests socket timeout 110 proxy
再结合网络环境：
linux server https tls handshake timeout proxy
每一次搜索，都是在缩小问题空间。
你不是在找“标准答案”，你是在找线索。
AI 时代，提问反而更重要
现在很多人觉得，有了 AI 之后，就不需要学会提问了。
我觉得恰好相反。
AI 让提问能力变得更重要。
以前你问得不好，别人可能直接不回。这个反馈很明显。
但 AI 不一样。你问得不好，它也会回你。你给它一个模糊问题，它就给你一个模糊答案。你给它一个错误方向，它就沿着错误方向帮你展开。
这就像你在错误的路线上开了自动驾驶。
开得越快，离目标越远。
所以 AI 时代的问题不是“没有答案”，而是“答案太容易出现了”。
你需要判断的是：这个答案到底在解决什么问题？
还是以 Claude Code 为例。
如果你问：
Claude Code 一直 Checking connectivity 是为什么？
AI 大概率会从网络、DNS、TLS、代理、证书、官方服务状态这些方向帮你分析。
这没有问题。
但如果你的真实目标是：
我想用 Claude Code 接入第三方模型服务，而不是连接 Claude 官方服务。
那么你应该一开始就说清楚。
更好的问法是：
我想在服务器上使用 Claude Code，但不打算连接 Claude 官方服务，而是想接入 DeepSeek / MiniMax / Gemini 或某个兼容 API 的转发服务。现在启动时卡在 Checking connectivity。我想判断这是官方连通性检查失败，还是代理问题，还是第三方 endpoint 和 Claude Code 的协议不兼容。我应该检查哪些环境变量、Base URL、Token、模型名和网络请求？
这个问题就清楚多了。
因为它提供了目标、上下文、现象、猜测方向和希望得到的帮助。
AI 才能沿着正确路径回答。
不会提问，就别急着玩高度自动化工具
这里顺便说一下现在很多人喜欢玩的高度自动化工具。
比如各种 Agent、Claude Code、Harness，或者我这里开玩笑说的“小龙虾”。
这些工具本身当然有价值。它们能帮你自动拆任务、调工具、跑命令、改代码、写文件。
但问题是：越是自动化的工具，越要求使用者有判断力。
如果你连这个工具是什么、解决什么问题、依赖什么服务、配置入口在哪里、失败时应该看哪一层都不知道，只是因为别人说它厉害就开始用，那么它并不会让你更强。
它只会更快地放大你的误判。
比如你问：
小龙虾怎么安装？
这个问题本身不是不能问。但如果你连“小龙虾”是什么都不知道，只是看到别人用，就想先装上再说，那就有点危险。
这类工具不是普通软件。它们往往会替你执行很多动作。
你理解它，它是效率工具。
你不理解它，它就是黑箱。
以前你手动操作，错一步可能马上能看出来。现在你让 Agent 自动跑，它可能一口气错十步，而且每一步都看起来很自信。
所以我的建议是：先理解基本原理，再使用自动化工具。
不会提问，不会验证，不会设定边界，就不要急着把复杂任务交给自动化系统。
工具再强，也只是放大器，不是你的大脑。
一个好问题应该包含什么
我觉得一个技术问题，至少应该包含下面几类信息。
1. 目标
你想实现什么？
不是你看到什么报错，而是你最后想达到什么状态。
例如：
我想让 Claude Code 在服务器上接入第三方模型服务。
而不是：
为什么连不上？
2. 环境
你在什么环境下操作？
例如：
Ubuntu 24.04Claude Code 2.1.122远程服务器当前没有设置 HTTP_PROXY / HTTPS_PROXY
环境信息可以帮助别人排除大量无关猜测。
3. 现象
具体发生了什么？
例如：
启动后卡在 Checking connectivity...curl 到 api.anthropic.com 时 DNS 能解析，443 能连接，但 TLS handshake 超时。
不要只说“不行”。
“不行”不是信息。
4. 已经尝试过什么
你做过哪些排查？
例如：
已经测试过 DNS。已经测试过 curl。已经检查过环境变量。没有发现 ANTHROPIC_BASE_URL。
这可以避免别人让你重复做一遍你已经做过的事情。
5. 你的怀疑
你认为问题可能在哪？
例如：
我不确定这是服务器出口网络问题，还是 Claude Code 启动阶段必须访问官方服务，还是第三方 API 不兼容。
这一步很重要。
它能告诉别人你的思考路径，也能让别人判断你是不是已经问到了关键层。
6. 希望得到的帮助
你希望别人帮你做什么？
例如：
请帮我判断排查方向，并给出下一步验证命令。
而不是：
帮我看看。
“帮我看看”是最难回答的一种问题。
更好的提问模板
如果要给一个通用模板，我会写成这样：
我想实现的目标是：……当前环境是：……我现在遇到的现象是：……完整报错或关键日志如下：……我已经尝试过：1. ……2. ……3. ……我目前怀疑可能是：1. ……2. ……我希望你帮我判断：1. 这个问题更可能出在哪一层？2. 下一步应该怎么验证？3. 有没有我忽略的关键上下文？
这个模板不复杂，但非常有用。
它强迫你先整理自己的问题。
很多时候，你把这个模板填完，问题已经解决一半了。
一问一反思
提问能力不是天生的。
它可以训练。
现在 AI 最大的价值之一，就是它提供了一个非常方便的训练对象。
你可以用“一问一反思”的方式训练自己。
比如你问了一个问题，AI 给出的答案很泛。
不要马上怪 AI。
先反思：
我是不是没有说清楚目标？
我是不是只描述了现象，没有描述背景？
我是不是没有说自己已经尝试过什么？
我是不是把真正想解决的问题藏起来了？
AI 现在回答的是不是我真正关心的问题？
然后重新改写问题，再问一次。
这个过程不是在训练 AI，而是在训练你自己。
你会逐渐发现，问题越具体，答案越可用。
上下文越清楚，AI 越不容易跑偏。
判断边界越明确，回答越接近你真正想要的东西。
总结
学会提问，本质上是学会思考。
提问不是把一句“为什么不行”发出去。
提问是把一个混乱的问题，拆成目标、环境、现象、尝试、怀疑和诉求。
没有 AI 的时候，我们靠搜索引擎、文档、论坛和 GitHub issue 来训练这个能力。
有了 AI 之后，这个能力不但没有过时，反而更重要。
因为 AI 会回答你，但它不一定知道你真正想问什么。
如果你问错方向，它也会认真地帮你走错路。
所以，遇到问题时，我建议先做三件事：
- 先问自己：我真正想实现什么？
- 再问搜索引擎和 AI：已有资料里有没有线索？
- 最后再问别人：带着上下文、尝试过程和明确诉求去问。
很多时候，得不到正确答案，不是因为别人不会答，也不是因为 AI 不够强。
而是问题一开始就没有问对。
问清目标，答案才会对路。
]]>
