社区里反复出现的问题，看起来很像现成选题，但它们大多数还不能直接拿来发。真正值得写的，不是“有人问过”，而是“这个问题在真实工作里反复卡住人，而且我能给出比泛泛建议更具体的判断和模板”。
第一步：先确认这是不是重复出现的真实卡点
我现在不会因为一条问题看起来热门，就立刻把它改写成文章。先要确认三件事：它是不是在不同场景里重复出现；它是不是和当前产品、内容或工程主线真的有关；它背后是不是藏着一个比“怎么做”更值得写的判断。
我现在会先做一个最小问题包
在开始起草之前，我会先留四条记录：
- 用户原话或最接近原话的问题表述
- 问题发生的具体情境
- 如果继续不解决，会多付出什么等待成本
- 我现在倾向的判断，而不是“先收集一堆答案”
如果这四条写不出来，问题通常还不够成熟，继续写只会变成空泛 Q&A。
第二步：先决定这篇文章不写什么
社区问题最容易滑向两种低价值写法。第一种是把别人已经说过的话重新排版，读起来像搬运后的整理稿。第二种是把所有可能情况都列出来，最后落回一句“看情况”。这两种文章都不太会留下记忆点。
所以我现在会先写一句排除式判断：这篇文章不准备解决什么。比如它不打算覆盖所有内容增长问题，只解决“没流量时先改文章还是先改导航”；或者它不打算比较所有 AI 工具，只回答“什么时候该让代理直接写代码，什么时候只让它 review”。
这一步很重要，因为真正让文章不水的，往往不是信息更多，而是边界更清楚。
第三步：把问题改写成一个能落地的结构
一个我会真的写出来的转换例子是：社区里有人问，“独立站已经发了不少文章，为什么还是没人点进产品页，是不是该先去多平台分发？”如果我直接回答，这很容易变成一篇套路化的流量建议文。
放回 MakePlans，我会把它改写成一个更具体的文章问题：当读者从文章页认识项目，却不知道为什么要进入 /workspace 录制工作台时，问题到底是缺分发，还是公共站没有把录制模块、产品导航和运行工作区的关系说清楚？这样一来，文章就不再围着“多发平台”打转，而会落到一个真实站点决策：先把“录制视频模块为什么不再默认占首页、而是进入产品导航第一位”讲清楚，再检查首页、产品页和 /workspace 之间有没有明确的进入路径。
这个转换会直接长成一篇 MakePlans 文章，而不是一篇泛泛的增长建议。它的结构可以是：先写读者从文章页进入时看到的是判断还是动作，再写真正分叉是“缺曝光”还是“缺解释”，然后给出我的判断，最后补一个检查表，让读者判断自己该先改入口、改文案，还是改渠道。
我现在更愿意把社区问题写成四段式，而不是标准 FAQ：
- 先写触发场景：这个问题通常在什么时刻冒出来。
- 再写真正分叉：为什么这里会有两个看起来都合理的方向。
- 再写我的判断：我会先选哪条路，代价是什么。
- 最后给模板：读者下一步该怎么自己判断，而不是只接受结论。
一个最常用的收口方式，是给一份小检查表：
- 这是不是重复出现的卡点，而不是一次性抱怨？
- 我有没有一个明确的“先做 A，再做 B”的判断？
- 如果读者照做，他下一步能检查什么？
- 这篇文章是不是仍然需要回到已有主文或资源页？
只要最后一项回答不出来，文章通常还不该发。
第四步：AI 应该在问题包和判断之后再进场
我并不反对用 AI 处理社区问题，相反，这类题目很适合让 AI 先帮你做聚类、找重复表述、压缩分叉点，甚至把原始笔记先整理成提纲。但我现在会强制自己把 AI 放在更靠后的位置：先有问题包，再有判断，最后才让它帮我加速结构和表达。
原因很简单。社区问题的危险，不是材料太少，而是太容易被模型写成“谁都不反对、谁也记不住”的平均答案。只要问题包和判断还没站住，AI 只会更高效地把模糊放大。
最后一步：发布前检查这篇文章是不是仍然像“社区现场”
我发布这类文章前，最后会多看一遍：读者能不能感受到这是从真实问题长出来的，而不是从关键词长出来的。如果整篇文章拿掉标题以后，看起来还能套进十个别的问题里，那说明它还不够具体。
对我来说，把社区问题变成一篇不水的文章，关键不是找到更多问题，而是找到那个已经重复出现、而且你真的愿意站出来给判断的问题。只有这样，社区问题才会从流量线索变成真正能积累信任的内容资产。
把社区问题变成证据，而不是借口
这篇的现场证据应该落在内容生产纪律上：社区问题只能作为选题输入，不能替作者完成判断。一个问题被多人问过，只能说明它有入口；能不能成为文章，还要看它是否能连接到 OnlyBegin 自己的项目经验、取舍和资源。