北京
一个评审在PR里要你补测试。你读完消息，推一个commit，过一阵再回来——讨论串已经翻篇了。那条请求是被满足了、被撤回了，还是单纯被埋了？
Hacktoberfest第三周的作品Prilizer想解决的就是这件事。它是一个本地“补课台”，面向单个贡献者最多三个公开PR：读取PR正文、评论、评审和行内评论，再用本地Qwen3模型识别其中的请求，并解释讨论发生了什么变化。每条动作都附带原始引用和GitHub链接。
作者最在意的不是摘要本身，而是下一次刷新时会发生什么。一条未完成的请求，即使下一次摘要里没提到，也会继续留在列表上。把摘要标记为“已读”只记录你读过，不代表请求关闭。请求离开活跃列表只有三种情况：来源被明确确认、本地手动忽略、或PR进入新的关闭/合并状态。关闭PR并不证明被要求的代码已经修好。
如果采集不完整或模型调用失败，卡片会显示“Check manually”，并保留旧证据。这个应用不会自动发回复，也不会去解决GitHub上的讨论串。
第一次冻结评测就没过
首轮冻结评测的结果是8/12正确，其中还出现了一次错误的“Waiting”状态。模型漏掉了间接请求，也搞混了是谁在问谁。
作者的应对是加约束：来源角色、新鲜确认，并且把失败样本保留下来。下一轮跑之前，先冻结了十二个不同的合成用例。改后的流水线拿到12/12，零错误Waiting，零无效动作引用。作为对照，固定关键词基线是10/12，带一次错误Waiting——模型抓到了一个关键词基线漏掉的批准条件。
这个结果属于整条流水线，包含确定性的持久化和校验，不能等同于普遍可靠性。摘要措辞没有被评分，人工检查仍在两份摘要里发现了误导性的行为主体归属。
速度是另一道坎
新鲜集合的模型调用耗时8.4–47.1秒。一个真实的Docker CLI PR花了47.3秒，随后在未变更的刷新中复用了分析结果。一个Node.js PR两次撞上60秒超时，应用把它留在“Check manually”。作者设定的30秒目标仍未达成，原始结果和早期失败都保留着。
架构上，一个React页面与回环地址上的Node服务通信，有界的匿名采集器把各讨论通道分开并比对完整快照。Qwen3 1.7B提出结构化请求，应用代码校验引用与来源，然后把请求独立于下一次模型摘要持久化。刷新是手动的，未变更的成功分析走缓存，旧请求继续可见，也没有需要一直盯着的通知流。
作者明确表示，没有测量过这能省下多少人工评审时间。他宁愿把这个问题留着，也不想把一次快速的缓存读取包装成对别人工作日的结论。
为什么开放权重在这里重要
Qwen3的开放权重加上Ollama，让语义解释和保存的讨论跑在同一台笔记本上。GitHub拉取新数据仍需联网，缓存的证据离线可读。模型提出含义，可检查的应用代码负责校验来源ID、精确引用、行为主体资格、新鲜度和请求持久化。规则可以改，也可以换另一个本地模型测试，不依赖托管推理端点。
没有按请求计费的推理账单，但硬件、电费、内存和等待仍然有成本。仓库里包含安装说明、评测输入、原始输出和失败运行记录。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
