17. 把问题带进社群

走到自己和 AI 都卡住的那一刻，下一步是把问题带进社群。能不能得到有效回答，很大程度不取决于问题多难，取决于描述里有没有别人能复现的信息。

没有复现信息的问题最难回答

「用不了」「报错了」「AI 给的代码跑不通」，这类问题回答者接不住，因为他没法在自己这边重现同样的情况，只能凭猜。猜一轮问一轮，几个来回还没对上，问题就晾在那里了。

反过来，一个能照着重现的问题，回答者跑一遍就看见了，回答的门槛一下降下来。把问题整理清楚，本身就是在替回答者省事，也是在替自己提高得到答案的概率。

一份能被复现的问题描述

一份好问题，凑齐五项就够：

• 最小复现：能重现这个问题的最少步骤或最小输入。去掉一切无关的部分，剩下的仍能触发问题。
• 预期结果：本来应该看到什么。
• 实际结果：实际看到了什么，报错就把报错原文贴上。
• 已尝试的步骤：已经试过哪些办法，各自是什么结果。这能让回答者不重复建议已经失败的做法。
• 环境信息：操作系统、用到的工具和它们的版本。这一项在报问题时是必要的，因为很多问题只在特定环境里出现。

拿报价整理器的一个问题填一遍：

最小复现：在输入框粘入一行 M6 螺母，个，0.18（分隔用的是中文逗号），点「整理」。 预期结果：解析出品名、单位、价格三列。 实际结果：整行都被塞进了品名列，单位和价格显示为缺失。 已尝试：换成英文逗号可以正常解析；把中文逗号替换成英文逗号的改法还没做。 环境信息：Windows、Chrome 浏览器、直接双击打开的本地 index.html。

这样一份描述，回答者不用追问就能复现，也一眼看出问题出在分隔符上。

去哪里问

问对地方和问得清楚同样重要。按这个优先级找：

1. 官方文档：很多问题文档里已有答案，先查一遍能省掉一轮等待。
2. 产品社区：用的工具、平台各自的官方社区，最懂它自己的坑。
3. 中文开发者社区：语言门槛低，同类新手多，容易找到相似经历。
4. 项目的 Issue 区：确定是工具本身的缺陷时，去它的代码仓库提 Issue。

具体哪个平台最活跃、要不要注册、能不能访问，会随时间变，用之前自己确认一下当前情况。这里给的是找的顺序，不是某个固定网址。

从提问者到回答者

社群是双向的。受益于别人的回答之后，把角色换一次：挑一个自己已经解决、当初也卡过的小问题，为后来者补一条可复现的回答。回答里带上刚才那五项，尤其是「怎么复现、怎么验证解决了」，让下一个撞上同样问题的人能直接照着走通。

一条经过自己验证、能复现的小回答，比十条「我猜是不是……」有用得多。

这一章留下两样东西：一份可以直接发布出去的问题描述，和一条经过验证的回答。前者让自己卡住时更容易脱困，后者让这套「验收先行、可复现、可验证」的习惯，从一个人的项目延伸到和别人的协作里。

正文到这里走完。后面的后记回看这一路是怎么把经历慢慢变成可复用的词，术语表则按出场顺序，把书里认过的每一个说法收在一处，方便回查。