提问的黄金准则
-
好提问不是把困难丢给别人，而是把自己已经完成的思考、实验和证据整理好，邀请别人接着往下推理。
-
先自己调查，把问题缩小；陈述目标和事实，提供最小充分证据；最后提出一个边界明确、容易回答的问题。
正文：
1. 先自己做功课，再提问
至少搜索过网页、文档、FAQ、历史讨论，做过基本实验。提问时说明：
- 我查过什么；
- 我尝试了什么；
- 我得到了什么结果；
- 我现在具体卡在哪里。
这不是为了证明自己勤奋，而是避免别人重复你已经做过的工作。
2. 先说目标，不要只问某条路径
不要只问：
怎么用 X 实现 Y？
应该先说明你真正想达到什么目标。因为你选择的 X 可能本身就不合适，专家可能会直接给你一条更好的路线。
3. 描述事实，不要把猜测当结论
把下面三件事分开：
- 事实：实际发生了什么；
- 预期：你认为应该发生什么；
- 猜测：你怀疑原因是什么。
例如不要说“GORM 有 Bug”，而应说：
在 Go 1.26、GORM 某版本下，执行这段代码时，我预期生成一条记录，实际生成了两条。下面是 SQL 日志和最小复现代码。
应展示原始症状和证据，而不是只给自己的诊断。
4. 提供完整但最小的上下文
技术问题通常至少应包括：
- 环境和版本；
- 操作步骤；
- 预期结果；
- 实际结果；
- 完整错误信息；
- 已尝试的方法；
- 最小复现代码。
“信息完整”和“内容很多”不是一回事。最好的问题是：没有无关信息，但解决问题需要的信息一个不少。
5. 把问题缩小到一个可回答的点
不要说：
我的项目运行不了，帮我看看。
而要说：
执行
go run .后，第 7 行出现connection refused。数据库容器正在运行，docker ps和连接配置如下。我应该继续检查端口映射还是数据库监听地址？
明确告诉对方，你需要的是“解释原因”“检查思路”“代码审查”还是“下一步排查方向”。
6. 证明你愿意参与解决问题
比起“直接给我完整答案”，更好的问法是：
我目前排查到这里，接下来应该检查什么？
这种问法说明你需要的是方向，而不是把全部劳动转交给别人。
7. 让问题便于阅读、搜索和复现
标题可以使用：
对象/环境 + 实际异常
例如：
WSL2 Ubuntu 24.04：landscape-sysinfo 因 cryptography 导入失败
而不是：
急！求救！为什么不行？
清晰标题不仅方便回答者，也方便未来遇到相同问题的人搜索。
8. 问题解决后，留下结论
补充最终原因和解决办法。这既是对回答者的反馈，也让整段讨论成为可复用的知识。
最实用的提问模板
目标：我想实现什么。
环境：系统、语言、框架和相关版本。
现象：我执行了什么，实际发生了什么。
预期：我原本期望什么结果。
已尝试：查过哪些资料，试过哪些方法，结果如何。
最小证据：必要的代码、命令、日志或截图。
具体问题：我希望你帮我判断什么，或者下一步该检查哪里。