神圣计划相关资料或实际入口出现问题时，求助信息越接近可复现过程，越容易被理解。长篇情绪描述不如一条清楚的现象。先整理已有证据，不需要为了把问题单写完整而进行高风险尝试或补造不存在的结果。
用一句话限定核心问题
写明对象、动作和结果，例如“手机竖屏打开某资料页时，第二张表格右侧内容被遮挡”。这比“完全不能用”更有边界。再说明预期结果，例如希望看到全部列，而不是先写一个未经验证的原因。
若有多个问题，分别列项，避免把加载慢、登录失败和日期差异混成同一次故障。每项都用相同方式描述，维护者可以判断它们是否相关。尚未确认有关联时，不把同时出现当作同一原因。
保留最短但完整的复现步骤
按时间顺序写进入地址、必要前提、执行动作和看到的结果。每步只做一个主要动作，包含会影响结果的等待或旋转过程。若问题无法稳定复现，应写明发生次数和已知条件，不编出固定复现率。
例如“一，打开原链接；二，等待正文出现；三，定位到第二张表格；四，旋转横屏后末列仍不可见”。如果没有再次验证，就标记仅观察一次。步骤来源于实际经历，不应复制通用教程当作自己的操作记录。
补齐时间和环境条件
时间应尽量包含日期、时分和时区；环境包含设备类型、系统和浏览器版本或实际运行方式。对于网络情况，描述自己知道的连接类别与是否更换，不需要公开私人网络地址。
如果只有某个账号出现，可使用稳定别名说明；若只测试了自己，不写所有账号都受影响。范围还可包括单页、同站多页、单设备和多设备。未测的项目明确写未测，让接收者知道证据边界。
列出已做动作及各自结果
每个排查动作写一行，包括条件、时间和结果，例如正常刷新后仍截断，换窄窗口后遮挡范围变化。不要只列“重试、清缓存、重装”而不写具体范围，这无法判断哪些状态已经改变。
若某次操作可能移除了会话或本地资料，也应说明，方便理解后续状态。不要为了求助把所有建议动作都提前做一遍。保留最初现场和已有结果，往往比不断试错更有助于维护者定位。
附上必要证据并说明待答问题
截图保留提示和上下文，遮住口令、验证码、令牌与无关个人资料。导出文件要检查隐藏列和属性。附件使用清楚编号，并在问题单中说明每个文件证明什么，不发送整个未经筛选的工作目录。
结尾可以明确希望确认的事项，例如“请核对该页面是否应支持当前宽度，以及是否需要补充特定日志”。通过已核验的服务渠道提交，保留问题单版本。后续补充时追加新结果，不覆盖原始描述，便于追踪处理过程。