GitHub Issue 列表看起来像一张待办表，真正接手之后才会发现，它更像一个没有整理过的反馈收件箱：有的 Issue 只有一句话，有的附带完整复现步骤，有的已经关闭，还有的正文里同时出现"真实触发"和"尚未端到端复现"。
这次选取公开仓库 MiMo-Code 的 Issues 页面，抓取按更新时间排序的最新 20 条 Issue，交给 TRAE Work 的 Work 模式完成一次真实分析。
最后得到的不是一张"看起来很智能"的排序表，而是一套可以回溯的交付物：
- 20 条 Issue 的数据审计报告；
- 每条 Issue 的分类、可复现性和证据字段；
- P0～P3 优先级建议和人工复核队列；
- 一份反馈分析报告；
- 一份 5 页以内的优先级汇报 PPT；
- 一次人工确认后的变更记录。
更重要的是，这个过程保留了真实的 TRAE Work 操作截图、任务耗时和生成文件。
本文中的分类和优先级是基于公开 Issue 正文制定的本次分析建议，不是 TRAE Work 的官方结论。Issue 数量是选取真实用户反馈的部分数量。
一、真实痛点：Issue 多并不可怕，无法判断证据才麻烦
如果只是查看一两条 Issue，打开页面读正文就够了。但当问题数量增加后，人工整理通常会遇到四个麻烦：
- 反馈类型混在一起：Bug、功能请求、性能问题、使用疑问和社区管理问题都出现在同一列表里。
- 标签不完整：标签可以作为参考，但不能把它当作唯一分类依据。
- 严重程度没有统一口径：一个"无法使用"的问题，可能阻断核心流程，也可能只是某个可绕过的边缘功能。
- 正文证据质量不同：有的 Issue 有环境和复现步骤，有的只有"不能用"三个字。
这次导出的 20 条 Issue 也确实呈现了这种差异：
| 审计项 | 实际结果 |
|---|---|
| Issue 总数 | 20 条 |
| Open / Closed | 16 / 4 |
| CSV 字段 | 9 个 |
issue_number 重复 |
0 条 |
issue_url 缺失或重复 |
0 条 |
| 正文被截断 | 0 条 |
labels 为空 |
12 条，占 60% |
这组数据说明，第一步不应该直接问"哪些最重要"，而应该先问：数据是否完整？哪些结论有证据？哪些内容还需要人工确认？
数据范围和字段
输入文件是 mimo-code-issues-latest-20-2026-08-10.csv，字段如下：
text
issue_number
title
state
opened_on
labels
body_length
body_truncated
body_excerpt
issue_url本次 20 条数据的 body_truncated 全部为 false，但评论、正文中提到的外部截图没有进入这份快照，后面仍然需要在原始 Issue 页面复核。
可以看到 Work 模式、CSV 附件和当前工作区。
二、第一步：先做数据审计，不让 AI 直接下结论
我在 TRAE Work 中的第一条指令没有要求它分类，也没有要求它给优先级，而是先做数据审计。
text
请读取附件 mimo-code-issues-latest-20-2026-08-10.csv。
这是一份来自公开 GitHub 仓库 MiMo-Code 的真实 Issue 快照，用户真实提交数据。请严格基于附件内容工作，不访问与本任务无关的个人信息，也不要补写附件中不存在的事实。
先完成数据审计，不要进行优先级判断。请输出：
1. 实际数据行数，不包含表头；
2. 实际字段名和字段含义；
3. issue_number 是否重复；
4. issue_url 是否缺失或重复；
5. body_truncated 为 true 的行号；
6. labels、body_excerpt、opened_on 的缺失情况；
7. 适合下一步分类的字段建议。
所有数量必须从 CSV 实际读取，不要使用示例数字。
请生成 01-data-audit.md，并在文档末尾列出来源页面、抓取范围和抓取时间。
第一轮任务指令和 TRAE Work 的执行过程。这里关键不是让它马上生成漂亮报告，而是先让它把数据边界说清楚。
实际生成的 01-data-audit.md 给出了 20 行数据、9 个字段、0 条重复编号、0 条 URL 缺失、0 条正文截断，并指出 labels 有 12 条为空。
数据审计结果。右侧报告把 CSV 总行数、字段含义、缺失情况和 Issue 编号范围列了出来。
这一轮让我确认了一件事：标签缺失率达到 60%，所以后续分类必须以 title + body_excerpt 为主，不能直接按 GitHub Label 做统计。
三、第二步：把反馈分类，但保留每条 Issue 的证据链
分类的目标不是给 Issue 贴一个看似准确的标签，而是让后续排期的人知道：它属于什么问题、影响是什么、正文有没有给出复现信息。
第二条指令要求 TRAE Work 为每条 Issue 新增这些字段：
text
category：bug、feature、usability、performance、security、documentation、question、other
module_or_scene：根据正文提取，不确定时填写"待确认"
reported_impact：只复述正文明确写出的影响
reproducibility：reproduced、partially-reproduced、not-verified、not-stated
evidence：引用正文关键证据，并保留 issue_number
classification_confidence：high、medium、low我在指令中额外加了三条限制：
- 不根据标题臆测严重程度；
- 把"用户声称发生"和"正文已经验证"分开；
- 无法判断就写"待确认"，不强行分类。
TRAE Work 最终生成了 02-feedback-classification.csv 和 02-category-summary.md。分类结果如下：
| 分类 | 数量 | 占比 |
|---|---|---|
| Bug | 11 | 55% |
| 功能请求 | 4 | 20% |
| 易用性 | 1 | 5% |
| 性能 | 1 | 5% |
| 安全 | 1 | 5% |
| 提问咨询 | 1 | 5% |
| 其他 | 1 | 5% |
| 文档 | 0 | 0% |
可复现性也被单独统计为：reproduced 9 条、partially-reproduced 2 条、not-stated 9 条。
分类结果。截图中的数量来自真实 20 条 Issue，分类汇总同时列出了每类对应的 Issue 编号。
这里有一个很实用的细节：#1995 的正文只有 "Question"，但它仍然被保留在结果里，分类置信度标为 low，而不是被 TraeWork 悄悄删除。这种"信息不足也要保留"的处理，比把不确定数据清洗掉更适合真实工作。
四、第三步：先定义优先级规则，再让 TRAE Work 执行判断
"请帮我排优先级"是一个不完整的指令。没有规则时，AI 很容易把描述写得严重的问题排在前面，却没有说明证据是否充分。
这次我使用了下面这套内部分析规则：
| 优先级 | 本次定义 |
|---|---|
| P0 | 明显安全风险、数据损坏、数据丢失，或无法安全继续工作 |
| P1 | 核心工作流被阻断，且正文有清晰复现条件或实际影响 |
| P2 | 主要功能受影响，但存在替代路径，或影响范围、复现信息不完整 |
| P3 | 体验改进、功能建议、文档问题或暂不影响主流程 |
| 待确认 | 证据不足、正文矛盾，或无法判断是否属于核心流程 |
需要强调：这不是 GitHub 或 MiMo-Code 的官方优先级标准，只是这次整理使用的分析规则。
第三轮指令中的关键部分如下：
text
请读取 02-feedback-classification.csv 和原始 Issue CSV，生成优先级建议。
每条结果必须包含：
1. issue_number；
2. issue_url；
3. suggested_priority；
4. priority_reason；
5. evidence_quote；
6. evidence_gap；
7. confidence。
如果正文同时出现"真实触发"和"尚未端到端复现"等相互矛盾的表述，必须降低 confidence 并标记人工复核，不要自行裁决。
请生成 03-priority-backlog.csv、03-review-queue.md 和 03-priority-method.md。第一次优先级输出时，TRAE Work 给出的结果是：P0 2 条、P1 2 条、P2 8 条、P3 7 条，另有 1 条待确认。截图中可以看到它把以下问题放到了人工复核区域：
#2067：正文同时出现"真实触发"和"尚未端到端复现"，涉及.git数据损坏，但因果关系需要复核；#2073：涉及子代理删除文件的安全风险，但标题与正文表述不同，正文还提到一张未进入快照的截图；#2052：浏览器技能导致对话无法交互，需要判断它是不是核心工作流；#1995：正文信息极少，只有 "Question"。
第一次优先级输出。这里没有把低置信度项直接塞进排期，而是单独建立人工复核队列。
这一轮最值得复用的方法是：优先级和置信度必须同时输出。P0 代表"潜在影响严重"，不代表"事实已经被完全验证"。
五、第四步：人工只改一条，观察结果是否可追溯
人工复核时，我没有让 TRAE Work 重新分析全部 20 条 Issue，而是给出一条明确修改：
text
我已经人工检查了优先级候选和待确认列表。
请只根据我下面明确列出的修改进行调整，不要重新推断其他 Issue。
Issue 编号：1995
原分类或优先级：待确认
修改后分类或优先级：P3
修改理由：描述不清晰，优先级不高
是否保留为待确认：否
请重新生成修订后的分类文件、优先级文件、分析报告、PPT 和变更记录。
保留所有原始 Issue 编号和链接，不要删除未被人工修改的记录。
人工复核指令和修订结果。截图显示只有 #1995 被修改，其余 19 条 Issue 保持不变。
根目录的 04-change-log.md 记录了这次修订：
- 待确认项从 5 条变成 4 条；
- P3 从 7 条变成 8 条；
- 待确认从 1 条变成 0 条；
- high 置信度从 13 条变成 14 条；
- low 置信度从 2 条变成 1 条。
这一步解决了一个常见问题：AI 生成的结果不是最终事实，人工判断也不能只停留在聊天框里。把人工修改写回结果文件，才有版本记录和复核依据。
六、第五步：把分析结果变成真正能交付的文件
最后一轮让 TRAE Work 读取原始 CSV、分类结果、优先级结果和人工复核队列，生成面向产品和维护者的反馈分析报告，并制作 5 页以内的优先级汇报 PPT。
本次最终交付物包括：
| 文件 | 用途 |
|---|---|
03-priority-backlog.csv |
20 条 Issue 的最终优先级清单 |
03-review-queue.md |
4 条仍需人工关注的 Issue |
03-priority-method.md |
优先级规则、决策过程和限制 |
04-feedback-analysis-report.md |
面向产品和维护者的正式分析报告 |
04-source-traceability.csv |
报告结论到 Issue 编号和 URL 的追溯表 |
04-priority-brief.pptx |
5 页以内的汇报材料 |
04-change-log.md |
人工修订记录 |
最终优先级分布为：P0 2 条、P1 2 条、P2 8 条、P3 8 条；置信度为 high 14 条、medium 5 条、low 1 条。
建议进入下一轮排期评估的 6 条 Issue 是：#2072、#2068、#2048、#2052、#2001 和 #2000。#2067、#2073 虽然潜在影响严重，但报告把它们保留为需要进一步人工复核的 P0 候选项，没有把"严重"直接写成"已确认"。
最终交付物。左侧是 Markdown、CSV 和 PPT 文件列表，右侧是优先级汇报 PPT 的实际预览。
七、这次项目提效操作到底节省了什么
截图中显示了三段 TRAE Work 任务耗时：
| 操作阶段 | TRAE Work 界面显示耗时 |
|---|---|
| 反馈分类 | 13 分 27 秒 |
| 优先级建议 | 4 分 05 秒 |
| 人工复核后重新生成 | 5 分 15 秒 |
| 三段合计 | 22 分 47 秒 |
这个合计不包含上传数据、第一轮审计和最终 PPT 生成，因此不能写成"完整任务只用了 22 分 47 秒"。它只能说明：这三段实际执行过程已经有可见的客户端计时记录。
真正省下来的不是"让 AI 替我做产品判断"，而是：
- 不再逐条复制 Issue 到表格；
- 不再手工统计分类数量；
- 不再凭感觉给每条反馈贴 P0/P1；
- 不再手动把报告结论和 Issue 链接一一对应；
- 人工复核后可以只修改一条，再让相关交付物同步更新。
八、可以直接复用的指令结构
以后处理真实反馈、客服工单、测试缺陷或问卷数据，我会按下面的顺序写指令：
text
【数据范围】
请读取哪些文件，数据来自哪里，快照时间是什么。
【先做审计】
先统计真实行数、字段、缺失、重复和截断情况，不要直接下结论。
【分类字段】
明确 category、module、reported_impact、reproducibility、evidence、confidence。
【判断规则】
定义 P0/P1/P2/P3 或其他等级，并声明这只是本次分析规则。
【证据约束】
每条结论必须保留原始编号、链接和证据摘录；无法确认就标记待确认。
【交付格式】
明确要生成 CSV、Markdown、PPT 或其他文件，并规定字段名。
【人工复核】
只根据人工明确修改的 Issue 更新结果，其他记录保持不变，并输出变更日志。这套方法的核心不是某一句"万能提示词"，而是把任务拆成五个可检查的阶段：
审计数据 → 分类反馈 → 定义规则 → 人工复核 → 交付追溯
九、三个容易踩坑的地方
1. 不要把标签当作完整数据
本次快照有 60% 的 Issue 没有标签。如果只按 label 统计，会漏掉大量真实问题。应该把标题和正文作为主要依据，标签只做交叉检查。
2. 不要把 P0 当成官方结论
本文的 P0～P3 是内部分析规则。维护者可能掌握更多代码、版本和修复背景，最终优先级应以项目实际流程为准。
3. 不要让 AI 把矛盾证据抹平
#2067 同时出现真实触发和未端到端复现，#2073 标题和正文的确定性也不完全一致。好的结果不是替它们强行选一个结论，而是把矛盾明确写进人工复核队列。
总结
这次案例给我的最大收获，是重新理解了"AI 整理反馈"的边界：
- TRAE Work 适合做批量读取、字段检查、分类统计、文件生成和结果同步；
- 人负责定义优先级规则、识别证据缺口、处理矛盾表述和做最终判断；
- 每个结论都应该能够回到一个 Issue 编号和原始链接；
- 每次人工修改都应该进入变更记录，而不是只留在聊天记录里。
如果你手里有项目的客服工单、测试缺陷、问卷反馈或社区建议，可以直接把本文的"审计---分类---优先级---复核---交付"流程替换进去。数据不需要先被整理得很漂亮，但必须保留来源、编号和证据。