先缩小问题，再写标题
提问前先用一句话描述卡住的动作，不要从所有背景故事开始。如果一个帖子同时问账号、图片和通知三个不相干的问题，回答很容易混在一起。优先处理当前最影响目标的一项，其余问题另行整理。标题采用“使用场景＋具体动作＋异常表现”，便于后来遇到相同问题的人找到它。
“求大神救命”无法帮助读者判断能否回答；“手机端编辑草稿后，返回列表未显示新标题”则包含位置和现象。标题不必塞入所有细节，版本、时间和重复次数放进正文即可。
用五块信息搭好正文
环境只写与问题相关的内容，例如设备类型、软件版本、发生页面和可见设置。复现步骤按实际顺序编号，每一步只描述一个动作。预期结果与实际结果分别写，避免把“应该保存”与“页面无变化”混成一句。最后列出尝试过的办法，以及每次尝试后的真实结果。
- 目标：我想完成什么任务。
- 环境：哪些设备、版本或设置可能影响结果。
- 步骤：从哪个页面开始，依次点击或输入了什么。
- 差异：期望看到什么，实际出现什么提示或行为。
- 尝试：已做哪些检查，哪些有效、无效或尚未确认。
材料要能解释问题，也要减少无关暴露
截图应保留问题所在区域、必要的提示文字和上下文。提交前遮住姓名、联系方式、完整账号、订单信息及不相关的私信内容；不要把密码、验证码或访问令牌贴入公开讨论。若日志包含这些内容，可手工摘录与问题相关的错误行，并注明已省略哪些无关字段。
文字提示尽量同时写成可复制的文本，方便读者检索。视频适合展示连续操作，静态错误提示用截图通常更直接。材料的作用是说明问题，不是用大量附件替代正文。
虚构教学例子：一份可以继续追问的求助摘要
以下为虚构教学情境：目标是保存一份学习清单；环境为手机浏览器，具体版本已在正文列出；步骤为打开草稿、修改标题、点击保存、返回列表；预期列表显示新标题，实际仍显示旧标题。已尝试重新进入列表，标题仍未变化；未尝试清除本地数据，因为尚未确认草稿是否已同步。
这样的表述让回复者能够追问保存提示、同步状态或是否能在详情看到新标题，而不用先问“你到底操作了什么”。示例没有预设故障原因，也不把某个处理办法当作既定答案。
发布前做一次读者视角检查
把正文从头读一遍，检查陌生读者是否能按你的描述到达同一个位置。删掉重复抱怨，保留关键失败现象；将猜测用“我怀疑”标明，与观察事实分开。收到追问后在原帖集中补充新材料，并说明补充了什么，减少后来者在多层回复中拼接信息的负担。