提问与回答

提问不是把难题丢出去，而是把对方需要的信息压缩到最少。回答也一样，给出适用边界比给出结论更有用。

先说出理解

开口前先说「我以为 X 是因为 Y，对吗」。对方能立刻定位你的偏差，不用从头讲起；如果理解正确，一句话就能确认。

目标：把 nightly 构建从 40 分钟压到 20 分钟以内
环境：GitHub Actions，ubuntu-24.04，依赖缓存已开启
已试：拆成两个 job 仍然慢，瓶颈在 test 阶段
现象：pytest 单跑 6 分钟，CI 里要 22 分钟
问题：同样的测试为什么在 CI 里慢三倍

模板不是客套。它把目标、环境、已尝试、卡点分开，回答者能直接跳到需要的信息，而不是先问一轮背景。

• 标题写现象，不写「求助」「急」
• 报错贴完整上下文，不要只截最后一行

追问到真正理解

• 不懂的术语当场打断，别带着误解往下听
• 不知道就说不知道，再补「但我猜」或「我去查」
• 不接受半截答案，继续问直到能自己复述
• 复述对方的解释，确认没有理解偏差
• 把结论写回 issue、文档或代码注释
• 对方答得太抽象，就要求给一个具体例子
• 问清结论的适用边界，不只是当前这个场景
• 好问题会暴露其他人也需要知道的假设

说「不知道」不会显得弱，假装听懂才会在事后付出更大代价。同样，对方说「我也不确定」时，可以一起查，而不是换个人重复问。

先做功课，但别过度

情况	做法
有报错原文	先搜原文和错误码
文档里写过	先读相关章节再问
能最小复现	做一个再发出来
方向不确定	直接问，别猜太久

基础调查让问题更具体，但调查本身不该变成拖延。同事之间随口问没问题，公开频道和 issue 里才需要完整背景。

• 把搜过的关键词记下来，提问时一并附上
• 找到相关 issue 或文档就链接过去
• 区分「查不到」和「没查」，别假装查过

调查记录本身也是提问材料，对方能顺着你的路径继续查，而不是从零开始。

小心 XY 问题

你问的是自己设想的解法，而不是真正的问题。对方按字面回答，你拿到了局部答案，原问题还在。

描述目标，再说明当前方案卡在哪；如果确实要问解法，也讲清它在整体中的位置。

• 先说目标，再说你选的路径
• 卡住时描述现象，不描述猜测
• 让对方有机会否定整个方案

Julia Evans 的 How to ask good questions 和 How to get useful answers 把这些问题展开得更细，值得读一遍。

对 LLM 提问同理：给出约束、报错、期望和已尝试，比一句「帮我修好」得到的答案可靠得多。

怎么回答

回答前先确认对方的目标，很多问题在复述目标时就消失了。给出能跑的最小示例，比给一段解释更容易被验证。

• 说明结论适用的版本和前提
• 指出自己不确定的部分，别用肯定语气盖过去
• 给出排查路径，让对方下次能自己定位
• 把答案写成可搜索的形式，链接回 issue 或文档
• 对方理解错了就纠正前提，不要顺着错误前提回答
• 给出反例，说明什么情况下这个方法不适用

回答「我不知道」并不丢人，补一句「但我可以帮你缩小范围」更有用。社区里的高质量回答，往往不是最长的那个，而是把假设和边界写得最清楚的那个。

回答同事的即时提问可以短，但结论要留下记录。只在聊天窗口里解决的坑，下一个人还会再踩一遍。