如何提出好问题

2026-08-13

真正厉害的人，不只是会回答问题，更重要的是会提出好问题。

一个好问题通常有三个特点：

不是搜索一下就能得到答案
在问别人之前，先查资料、查词典、查搜索引擎。把本该自己完成的基础工作交给别人，是对别人注意力的不尊重。
有足够的背景和清晰的边界
不要只问“我该去大城市还是小城市工作？”，而要说明自己的收入、家庭、行业机会、风险承受能力等。背景越清楚，答案才越有针对性。
不是索取，而是讨论
提问者应展示自己的思考、已经尝试的方法和初步选项。例如：“我想到 A、B 两种方案，各自有这些利弊，你觉得哪种更可行？还有没有第三种可能？”
这样的提问既方便别人回答，也体现诚意。

作者认为，提出好问题的过程，本身往往就是解决问题的过程。因为为了把问题定义清楚，人必须搜索、学习、比较、整理背景资料。到真正去请教他人时，大部分问题可能已经解决了。

所以，高质量提问反映的不是口才，而是自学能力、思考能力、做事可靠性和对他人时间的尊重。
这也是为什么在面试、合作和与优秀的人交流时，一个人提出什么问题，往往比他如何回答现成问题更能说明其水平。

一、文章主旨：提问不是小技巧，而是一种底层能力

李笑来认为，真正优秀的人，厉害的地方不只是“会回答问题”，更是“会提出好问题”。

能提出好问题，说明一个人已经做过调查、思考、分析和筛选。他不是把一个模糊的麻烦扔给别人，而是已经走到问题的关键处，需要借助别人的经验继续前进。

Tiếng Việt:
Luận điểm chính của bài là: khả năng hỏi không phải kỹ năng giao tiếp phụ, mà là năng lực nền tảng. Một câu hỏi tốt chứng minh người hỏi có khả năng tự học, tự tìm hiểu và xác định vấn đề.

二、学霸真正强的地方：不是答案多，而是问题好

作者观察到，很多“学霸”平时并不频繁提问。他们会先查词典、翻资料、自己折腾。可是，一旦他们来问，往往会提出一个定义清楚、背景完整、需要认真思考才能回答的问题。

所以，学霸不是“什么都知道”，而是更知道：

什么可以自己解决；
什么值得花时间研究；
什么问题必须向别人请教；
应该怎样提问，才能得到有效帮助。

Tiếng Việt:
Điểm hay ở đây là tác giả phá vỡ hình ảnh “học bá biết mọi thứ”. Người giỏi không nhất thiết biết trước câu trả lời, nhưng họ có quy trình xử lý khi chưa biết.

Đây cũng là khác biệt giữa một engineer junior và senior. Senior không phải là người không gặp lỗi, mà là người biết lỗi nào đọc docs là ra, lỗi nào phải debug, và khi nào cần kéo đồng đội vào để cùng xử lý.

三、好问题的第一个条件：搜索能解决的，不要直接问人

作者提出的第一条原则是：

搜索引擎能回答的问题，就不要先问别人。

例如，一个单词的意思、一个基本事实、某个框架 API 的用法、一个错误信息的含义，如果只要搜索就能找到，就应该先自己查。

这不是说“问人丢脸”，而是说：别人的注意力很宝贵。连最基本的检索都不愿意做，就等于把自己的学习成本转嫁给别人。

作者还提出一个简单的公式：

Google + Wikipedia + English = Almost Everything

意思不是说只靠这三个工具就万能，而是强调：信息和工具已经非常便宜，真正稀缺的是主动使用它们的人。

Tiếng Việt:
Điều này rất hợp với thời AI. Bây giờ công thức có thể mở rộng thành:

Search + Docs + Source code + AI + English = giải được phần lớn vấn đề ban đầu.

Nhưng dùng AI để hỏi kiểu “làm sao sửa lỗi này?” mà không đưa log, phiên bản, ngữ cảnh, code liên quan, thì thực chất vẫn là “伸手党”, tức người chỉ đưa tay xin đáp án.

Một quy trình tốt trước khi hỏi đồng nghiệp hoặc AI:

Đọc kỹ error message và xác định hành vi mong đợi.
Tìm trong docs, codebase, GitHub Issues hoặc Stack Overflow.
Kiểm tra log, test, commit gần đây và các thay đổi liên quan.
Tự nêu 1-3 giả thuyết về nguyên nhân.
Nếu vẫn kẹt, hỏi với toàn bộ bối cảnh đã thu thập.

四、好问题的第二个条件：先搞清楚自己到底想要什么

作者认为，很多问题之所以没有答案，不是因为对方不愿意回答，而是因为提问者连自己的目标都没有定义清楚。

他举了一个学英语的例子：

不够准确的问题：
“这句话怎么翻译？”
更准确的问题：
“这句话到底是什么意思？”
“这句话在这个语境里应该怎么理解？”

“翻译”只是学习外语的一个用途，但很多人其实真正需要的是“理解”。如果目标没分清，就容易把“直译”误当成唯一答案，最后得到的答案也未必能解决自己的困惑。

同样，“该去大城市还是小城市工作？”也很难直接回答。因为缺少收入、职业机会、家庭情况、风险承受能力、行业发展等背景，答案只能是“看情况”。

Tiếng Việt:
Đây là phần sâu nhất của bài. Nhiều lần ta tưởng mình đang hỏi cách giải, nhưng thật ra còn chưa định nghĩa đúng bài toán.

Ví dụ kỹ thuật:

Câu hỏi mơ hồ:
“Nên dùng microservices hay monolith?”
Câu hỏi rõ mục tiêu hơn:
“Rails monolith hiện có 3 team, deploy chậm và một số bounded context đã có nhịp thay đổi độc lập. Mục tiêu của chúng tôi là giảm coupling khi vẫn giữ chi phí vận hành thấp. Có nên tách service X trước không?”

Hai câu hỏi đều nhắc đến microservices, nhưng câu thứ hai mới nêu được quyết định thật sự cần làm: giảm coupling, cân nhắc chi phí vận hành, và xác định phạm vi tách.

Với AI cũng vậy. Trước khi viết prompt, nên hỏi mình: mình cần gì?

Cần giải thích khái niệm?
Cần debug một lỗi cụ thể?
Cần so sánh trade-off?
Cần bản nháp implementation plan?
Cần review một quyết định đã có?

Mục tiêu càng rõ, output càng hữu ích.

五、好问题的第三个条件：提问是讨论，不是索取

作者强调，好问题不应该 là một yêu cầu trống không như “告诉我怎么办”。它应该带着提问者的思考，形成讨论。

例如，不要只问：

“老师，我应该怎么办？”

可以这样问：

“我已经想了两种方案：A 的好处是……，风险是……；B 的好处是……，成本是……。我目前倾向于 B，但担心……。您觉得哪一种更合适？还有没有我遗漏的第三种方案？”

这种问法的价值在于：

表明你已经认真做过功课；
让对方容易理解问题；
让回答更具体、更有针对性；
即使对方不同意你的方案，也能直接纠正你的思路。

作者建议，尽量把问题设计成“选择题”，而不是完全开放的“问答题”。当然，最后可以保留一个开放选项，让对方补充你没有想到的方向。

Tiếng Việt:
Đây không phải là biến mọi câu hỏi thành “multiple choice” một cách máy móc. Ý chính là: hãy đưa ra cấu trúc suy nghĩ của mình để người khác có điểm bám.

Ví dụ khi hỏi tech lead:

“Em đã thử rollback config và tăng timeout. Từ metrics thì DB connection pool saturation có vẻ là nguyên nhân chính, còn Redis latency hiện bình thường. Em đề xuất kiểm tra pool sizing trước thay vì scale app instances. Anh thấy giả thuyết này có thiếu gì không?”

Câu hỏi như vậy khiến cuộc trao đổi đi thẳng vào việc kiểm chứng giả thuyết, thay vì bắt người nhận tự tái tạo toàn bộ quá trình suy nghĩ từ con số 0.

六、提出好问题的过程，本身就是解决问题的过程

作者指出一个现象：为了提出一个“值得别人回答的问题”，你需要查资料、整理背景、区分概念、尝试方案、排除错误方向。

很多时候，等你把这些都做完，原来的问题已经解决了。

所以，提问的真正收益不只是获得一个答案，而是培养以下能力：

检索能力；
定义问题的能力；
分析背景和约束条件的能力；
构建假设的能力；
与人协作和沟通的能力；
判断何时应该继续自己研究、何时应该求助的能力。

Tiếng Việt:
Điểm này rất giống quá trình debug. Nếu một người viết bug report tốt, họ thường đã đi được nửa đường tới lời giải.

Ví dụ một issue tốt sẽ có:

Expected behavior.
Actual behavior.
Reproduction steps.
Environment/version.
Logs hoặc stack trace.
Phạm vi ảnh hưởng.
Những gì đã kiểm tra.
Giả thuyết ban đầu và mức độ chắc chắn.

Viết được như vậy không chỉ giúp người khác giải nhanh hơn. Nó ép người tạo issue phải tư duy có cấu trúc. Đó chính là năng lực có thể tích lũy lâu dài.

七、老师、高级程序员，也只是自学能力更强的学生

作者说，老师并不是真的“什么都懂”。他们和学生一样，也会遇到不会的问题；不同之处在于，他们更懂得查词典、找资料、比较不同来源，并从中形成判断。

他把这个逻辑延伸到程序员：

“高级程序员”不一定比“初级程序员”知道得多；某种意义上，他只是更知道如何查文档、如何搜索、如何定位问题。

做完这些基础工作以后，90% 的问题可能已经解决。剩下的 10%，才是值得带着准备去请教高手的问题。

Tiếng Việt:
Tôi đồng ý mạnh với ý này, đặc biệt trong ngành phần mềm thay đổi quá nhanh. Không ai giữ hết API, framework internals, cloud configuration hay security edge cases trong đầu.

Năng lực phân biệt senior hơn thường là:

Tìm đúng nguồn có độ tin cậy cao.
Đọc tài liệu và source code hiệu quả.
Không nhầm triệu chứng với nguyên nhân.
Biết đánh giá trade-off chứ không chỉ tìm “đáp án”.
Biết biến điều học được thành kiến thức của team: test, runbook, ADR, docs.

AI giúp rút ngắn phần tìm hiểu, nhưng không thay được việc kiểm chứng và judgment. Một kỹ sư giỏi dùng AI như trợ lý nghiên cứu và implementation assistant, không giao toàn bộ tư duy cho AI.

八、提问质量也是识人的标准

作者认为，在招聘、合作和社交中，一个人问什么问题，往往比他回答现成问题更能暴露能力。

面试时，候选人提出的问题可以反映：

他有没有研究这个行业和公司；
他有没有认真理解岗位；
他最关心什么；
他能不能独立思考；
他是否具有长期视角；
他是不是可靠。

同样，在和优秀的人交流时，单纯加上微信、看朋友圈，通常不能建立真正的联系。相反，如果你在合适的时机提出一个经过思考的好问题，更可能让对方记住你，也为之后的交流创造基础。

Tiếng Việt:
Đây là gợi ý rất thực tế cho interview, networking và cả làm việc với khách hàng.

Ví dụ, một ứng viên hỏi:

“Công ty có những phúc lợi gì?”

Không sai, nhưng thông tin về năng lực tư duy còn ít.

Còn nếu hỏi:

“Với đội ngũ đang phát triển sản phẩm B2B này, đâu là technical constraint hoặc product bottleneck lớn nhất trong 12 tháng tới? Vị trí này được kỳ vọng đóng góp thế nào vào điểm đó?”

Câu hỏi thứ hai cho thấy ứng viên quan tâm đến business, hệ thống và tác động của vai trò. Nó có độ phân giải cao hơn nhiều.

九、不要把“别问蠢问题”误解成“不要提问”

文章最后特别提醒：主题是“如何提出更好的问题”，不是“如何不提问”。

老师、同事、前辈和专家的价值，就是帮助我们缩短自学路径，提高成长速度。尤其对初学者，不应该要求他们一开始就提出专家级问题。

比较好的尺度是：

在自己现有能力范围内，做足该做的功课，然后真诚、坦荡地提问。

如果你已经努力搜索、阅读、尝试、思考，但仍然不懂，那么提问完全合理。重要的是不要假装懂，也不要把别人当成免费搜索引擎。

Tiếng Việt:
Tôi thấy đây là phần cân bằng nhất của bài. Nếu áp dụng cực đoan, “hãy tự tìm trước khi hỏi” có thể tạo tâm lý ngại hỏi, làm chậm feedback loop hoặc để rủi ro kéo dài.

Một quy tắc thực dụng hơn:

Vấn đề nhỏ, rủi ro thấp: tự tìm và thử trước.
Vấn đề có thể gây production incident, security issue, data loss hoặc deadline lớn: báo sớm, đồng thời tiếp tục điều tra.
Khi là người mới: hỏi sớm hơn, nhưng luôn cho thấy phần mình đã hiểu và phần mình đang kẹt.
Khi là người có kinh nghiệm: không chỉ hỏi đáp án, mà đưa ra hypothesis và trade-off.

十、可直接使用的提问模板

1. 技术问题

我想解决的问题是：。
当前表现是：。
相关环境/版本/代码范围是：。
我已经查过或尝试过：。
目前我怀疑原因可能是 A / B，因为：。
我最希望确认的是：。

Mẫu Việt hóa:

Mục tiêu em cần đạt là: ____.
Hiện tượng thực tế là: ____.
Bối cảnh liên quan gồm: ____.
Em đã kiểm tra/thử: ____.
Hiện em nghi A hoặc B vì: ____.
Em muốn nhờ anh/chị xác nhận hoặc góp ý: ____.

2. 决策问题

我的目标是：。
约束条件是：。
我正在比较 A 和 B。
A 的好处和风险是：。
B 的好处和风险是：。
我目前倾向于：____。
我可能忽略了什么？

3. 向 AI 提问

请作为____来帮助我。
我的背景和目标是：。
已知约束是：。
我已经尝试过：____。
请比较 A/B 的 trade-off，并指出我的假设中可能错误的地方。
如果信息不足，请先列出需要我补充的关键问题，不要自行假设。

我的结论

这篇文章表面上在教“如何问问题”，实际上在教一种更重要的工作方式：

先自己把问题推进到足够清楚，再借助他人的知识跨过关键障碍。

对你这种已经大量使用 AI coding agent 的工程师来说，最值得吸收的不是“少问”，而是把提问升级成一种设计能力：

把模糊需求变成可验证的问题。
把复杂故障拆成假设和证据。
把与 AI、同事、客户的沟通变成共同推理，而非单向索取。
把每次卡住的地方沉淀成 docs、checklist 或 project memory。

这样 AI 才会真正放大你的判断和产出，而不只是更快地给你一段看似合理的答案。