项目问题清单也叫 Issue Log，用来跟踪已经发生、正在影响项目的事项。它不能只写“接口有问题”“数据不对”“客户不满意”，因为这种描述无法复现、无法分级，也无法判断何时可以关闭。AI 适合从会议、测试和群聊中提取问题，但不能在证据不足时猜根因或随意指定责任人。
先区分问题、风险和普通任务
- 问题：已经发生，例如接口响应超时，测试无法继续。
- 风险：尚未发生但可能发生，例如供应商可能延期。
- 任务：为完成目标安排的动作，例如准备测试数据。
尚未发生的事项应放入项目风险清单；聊天记录中的明确动作可以先用聊天记录转待办清单提示词提取，再判断哪些已经构成问题。
问题描述要先写现象和证据
“数据库有问题”是原因猜测，不是问题现象。更可靠的记录是：“7月22日14:10，在测试环境导入客户表时，20条记录中有2条因手机号包含空格失败，系统返回错误码E102；失败样本和日志已附。”先记录可观察事实，再由负责人验证根因。
可直接复制的项目问题清单提示词
你是一名项目问题登记助理。请根据我提供的会议记录、测试结果和沟通材料，提取已经发生并影响项目的问题，整理成可跟踪、可验证、可关闭的问题清单。不要编造根因、优先级、责任人、修复结果或完成日期。
项目名称：[填写]
项目目标和当前阶段：[填写]
原始记录：[粘贴会议、测试、工单或群聊内容]
已有证据：[截图、日志、样本、时间和环境]
团队角色：[填写可以负责确认和处理的角色]
里程碑与限制：[填写]
优先级标准：[如P0-P3定义，没有则写待制定]
请输出：
1. 问题清单表格，每条包含：
- 问题编号和简短标题
- 发现时间、发现人和环境
- 可观察现象
- 复现步骤和证据位置
- 影响对象、范围和严重程度
- 紧急程度与优先级依据
- 当前状态
- 问题负责人
- 下一动作、执行人、截止时间和预期输出
- 已验证根因或待验证假设
- 临时绕行方案
- 关闭标准、验证人和关闭证据
2. 非问题事项：风险、普通任务、重复记录和信息不足项
3. 需要立即升级的问题及依据
4. 信息缺口：缺少日志、样本、时间、环境或责任边界的条目
规则：
- 先写实际现象，再写原因假设，未验证原因不得写成结论
- 相同现象只有在环境、影响和处理方式一致时才能合并
- 严重程度表示影响大小，优先级表示处理顺序，两者不能混用
- 负责人负责推动问题关闭，不代表一定是造成问题的人
- 下一动作必须具体到执行人、日期和可观察输出
- 关闭不能只写“已处理”，必须包含修复、回归、验收和证据
- 涉及数据泄露、资金、安全或大面积不可用时标记立即升级
输出后自检：
- 每条问题是否已经发生并有事实证据
- 是否能由另一名成员按记录复现或核对
- 优先级是否引用统一标准
- 下一动作是否能直接进入任务系统
- 关闭标准是否可以客观验证示例：客户数据导入失败
错误记录：客户数据质量差，需要后端尽快处理。
可跟踪记录：
- 现象：7月22日14:10在测试环境导入20条客户记录，2条返回E102，失败记录的手机号字段包含前后空格。
- 影响：当前失败率10%，阻塞这2条样本进入后续匹配测试，其余18条不受影响。
- 优先级：P2。影响部分测试数据，有临时手工清洗方案，未影响生产用户。
- 下一动作：数据负责人7月23日12:00前提供清洗规则；后端负责人确认系统是否应自动去除空格。
- 根因：待验证。当前只确认失败记录存在空格，尚未证明这是唯一原因。
- 关闭标准：失败样本重新导入成功；新增带前后空格的回归用例通过；测试负责人附结果截图。
如果问题来自客服对话，可以先用客服对话质检提示词提取证据；如果需要用数据判断影响范围，可结合AI数据分析报告提示词，但相关性不能直接写成根因。
严重程度和优先级不要混用
严重程度描述影响，例如数据丢失、核心流程不可用或少量用户受影响；优先级描述处理顺序，还会考虑是否有绕行方案、是否临近上线和资源是否可用。高严重问题通常优先，但两者并不完全相同。团队应先约定P0至P3标准，再让AI按该标准归类。
关闭问题前必须完成四步
- 修复或执行已批准的处理方案。
- 按原复现步骤验证现象消失。
- 完成相关回归测试，确认没有引入新问题。
- 由指定验证人确认，并附日志、截图或验收记录。
AI整理问题清单的失败边界
AI 不能从一句“系统很慢”判断根因，也不能把提出问题的人自动设为负责人。安全事故、资金异常、隐私泄露和生产大面积故障应按组织应急流程立即升级。高频重复问题稳定后，可以用SOP标准作业流程提示词沉淀预防和处理步骤。