北京
一张来自支持团队的Bug报告，只该干一件事：让工程师不用再问任何问题，就能把问题复现出来。每一次"无法复现"或者"是哪个版本"，都在给客户多拖一天。
这里有一份模板，字段顺序按工程师实际阅读的顺序排列，另外还配了几条AI提示词，用来完成那些枯燥的信息收集工作，同时不让模型凭空编造。
模板长什么样
标题要写清楚：什么坏了、对谁坏、坏在哪。好的写法是"CSV导出在超过1万行时超时（Web应用，所有套餐）"，而不是"客户说导出坏了"。
复现步骤必须从一个已知的起始状态开始，逐条编号：以某个角色登录、打开某个页面，然后执行动作，并写明所用的确切数据或文件。期望结果与实际结果各写一行，不加形容词。实际结果里要带上确切的报错原文。
还要有这几项：支持团队是否复现过（复现了就写日期，没复现就写原因）；环境信息，包括应用版本或构建号、浏览器及版本、操作系统、账号或工作区ID、区域、套餐；证据，逐字引用日志行并标注时间戳和时区，附截图或录屏，有失败请求也一并附上。
影响面要如实统计：关联工单ID、受影响账号数量以及统计方式、首次发现日期、是否有临时绕行方案。已经排除的可能也要列出来——清过缓存、换过浏览器、查过权限、搜过已知问题列表。假设部分是可选的，写清楚你怀疑什么、依据是哪几行证据。最后附上来源工单链接，不要把整段客户对话粘进去。
哪几个字段最要命
从已知状态出发的复现步骤，比"去报表页面看看"有用得多。期望与实际两行对照，其实就是修复的验收测试。环境信息是报告被打回的常见原因，动笔之前先从工单里把它捞出来。
证据必须逐字引用。一句被转述过的报错，会把人带到完全错误的方向上。影响面要诚实统计并附工单ID，因为它决定优先级，所以必须可核查。已排除项能省掉工程师重复支持团队第一小时的工作。假设要明确标注为假设——当线索有用，写得像结论就有害。
用AI做收集，但让缺失可见
大模型擅长从冗长的对话里提取环境细节、逐字摘出日志报错，也同样擅长自信地填上一个它根本看不到的字段。所以这几条提示词的设计思路，是让缺失的数据显形。
粘贴任何内容之前，先去掉密码、令牌、密钥和个人数据，并使用公司批准的工具。
第一条提示词用于起草报告：把工单对话和日志喂给模型，要求它按模板填写；环境细节只能取自工单或日志，字段缺失就写[MISSING]，以便知道该去问什么；报错和日志逐字引用并带时间戳；复现步骤写成从已知状态出发的编号步骤，凡是推断出来的步骤标注[CONFIRM]；任何原因都标为假设并附上指向它的日志行。最后明确一句：这是草稿，不要提交，也不要联系任何人。
第二条提示词用于向客户补料：列出报告中所有[MISSING]和[CONFIRM]字段，起草一份简短友好的请求，用编号列表呈现，提醒对方在发送日志或截图前移除密码和个人数据，并且不要承诺修复或给出时间。
第三条提示词用于查重：在最近30天的工单导出里搜索可能是同一个Bug的工单，给出单行描述和确切报错文本，逐条列出ID、日期和匹配短语；只是"可能相同"的放进"Possible"分类并说明理由，同一张工单不要重复计数。
"Possible"这个分类很关键。虚高的影响面统计会让Bug因为错误的理由被排到前面，工程师也会因此不再信任支持团队给出的数字。
在所有内容提交之前，还得由一个人亲自跑一遍复现步骤。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
