软件出问题时，只说“保存不了”很难让别人帮忙。让 AI 把你已经观察到的过程写清楚，比让它立刻猜原因更有用。本文练习把一段杂乱记录整理成可复核的报告草稿，适合反馈普通软件故障、网页显示问题或教程中的错误。它不会代替技术诊断，也不会替你向厂商提交。
准备和费用
准备可编辑的文字文档、无私人资料的测试副本和任意文字 AI。整理短文不需要专门购买编程代理，是否收费按你使用的服务与额度为准。只在自己有权操作的软件里复现；涉及扣款、删除、发送消息或真实客户记录时，停止反复尝试，先保存现象并走官方支持渠道。
第一步：把观察写下来，先别解释原因
记录软件完整版本、操作系统版本、使用入口、输入了什么、按了哪个按钮、原本期待什么、实际看到了什么。一次只描述一个问题。截图先检查邮箱、头像、文件路径、标签页和通知；日志中可能有令牌或个人信息，不要原样交给 AI 或贴到公开论坛。
教学虚构，软件名为虚构名称。
便签盒 2.4；系统版本：待补；网络状态：离线。
新建空白笔记，输入“测试甲”，保存，关闭该笔记，再打开。
做了3次，其中2次内容空白、1次正常；没有报错提示。
我猜是服务器没保存，但没有检查证据。
未测试其他版本；用的是测试文件，没有私人内容。这里的“便签盒”不存在，次数也是教学数据，不是真实软件缺陷。真实使用时应自己做记录，不能把这份示例当作投诉证据。版本不知道就去软件的关于或版本信息中查；查不到先留空，不让模型补一个看似合理的数字。
第二步：让 AI 整理，不让它编造
请仅把以下记录整理成一份问题报告草稿，不提交、不推测修复办法。
字段：简短标题、软件和系统版本、前提、编号复现步骤、预期、实际、复现次数、证据、尚缺信息。
观察与猜测分开；缺失版本写待补；3次中2次失败不能写每次必现。
保留“没有报错提示”，不编造报错码、日志或截图。
最后给出最多3个最值得补问的问题，不要求密码、令牌或完整私人文件。
[粘贴上面的教学记录]这份草稿的合格标题可以是“便签盒 2.4：保存后重新打开，测试笔记有时变空白”。预期是重新打开仍看到“测试甲”；实际是三次中两次空白，一次正常。系统版本必须待补。“服务器没保存”只能出现在未验证猜测里，不能升级成原因结论，尤其原始记录还写着离线。
第三步：用最小测试副本补信息
- 先保留原始问题记录，再建一个只含“测试甲”的副本。不要覆盖出问题的唯一文件。
- 照草稿逐步走一遍，检查是否漏了保存方式、重新打开入口或等待时间。把新结果追加在末尾，不把旧失败记录改成成功。
- 若问题消失，写“这次未复现”，并保留两次环境差异。不要为了稳定复现不断执行有风险的操作。
- 若能安全比较，下一轮只改变一个因素，例如新建文件与原测试文件，其他条件不动。没有做过的检查明确写未测试。
AI 提议“关闭所有安全软件”“把日志全部上传”“重装后再说”时，不照单执行。收集报告和修改系统是两件事。涉及账户或隐私泄露时，使用项目专门的私密安全报告入口，不往公开 issue 放细节。
第四步：按官方入口和模板提交前复核
先从产品官网找到支持渠道，确认项目名、仓库和报告范围。GitHub 官方说明：只有启用 Issues 且你有相应访问权限的仓库才能创建 issue；有模板时按模板填写。先查有没有同类问题，再决定是否补充现有报告。不要把所有软件问题都发到同一个仓库。
MDN 的贡献指南强调找对仓库、避免重复、提供清楚的位置和描述。把这套方法用到普通软件反馈，就是写明入口与步骤，而不是只说“有 bug”。这些是报告质量方法，不代表维护者承诺修复时间。
验收：把草稿当作陌生人来读
- 没有上下文的人能按编号重做吗？缺少入口或输入就补上。
- 预期和实际是否分开？“应该正常”不够具体。
- 三次中两次是否仍然是两次？没有把偶发写成必现。
- 系统版本、未测试项是否诚实留空？猜测是否明确标注？
- 附件、地址、日志是否脱敏？最终发送对象和文字是否由你确认？
不合格时只退回对应部分，例如“请保留原复现次数，不要增加原因”，不要让 AI 重写整个事实记录。保存一份已确认草稿和原始记录，后续回复补充信息时能查回依据。本文只提供人工编写的教学输入与核对结果，不声称向任何真实项目提交或复现了该故障。
接着做
还没确定是否值得安装某个项目，可先看把 GitHub README 读成试用决策；要录一段演示证据，先完成录屏前的隐私彩排。
核验来源
核验日期：2026年11月2日。软件反馈入口可能变化，以项目当前指南为准。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
