实测千问大模型

我测过很多大模型的能力，但还没有测过 Qwen 大模型，于是我就趁着端午假期在家，我拿自己的真实内容生产工具链，测试了一波 Qwen 3.7 能不能完成一次跨项目、跨前后端、真正能验收的 Agent 工作流。

我使用的工具是 Qoder CN 和 QoderWork。

简单来说，Qoder CN 是面向开发者的 AI 编程助手，而 QoderWork 是面向所有职场人士的桌面 AI 工作助手。

然后来说说 Qwen3.7-Max，官方强调的是它的核心卖点是：

• 编程能力足够强：能做前端原型、多文件工程、复杂软件开发、kernel 优化。
• 工具调用强：能接 MCP、Office 工具、代码执行环境、Claude Code/OpenClaw/Qwen Code 等框架。
• 长程执行强：Qwen 重点案例是连续 35 小时 自主优化 GPU/PPU kernel，1000+ 次工具调用，反复编译、测试、分析、修 bug，最后做到 10x 加速。
• 跨框架泛化强：不是只适配一个 Agent 框架，而是在 Claude Code、OpenClaw、Qwen Code、自定义 harness 下都能跑。
• 办公/生产力也能做：比如读论文格式规范，然后自动修复 Word 论文排版。
• 甚至延伸到物理世界智能体：通过工具控制机器狗，做导航、规划和决策

所以总结一点来说的话是：

Qwen3.7-Max 负责复杂推理、长程编码、工具调用、工程稳定性。

---

我本次测评是针对了自己实际上线的项目，只不过这个项目还没有跟大家介绍。

这是一个GitHub 开源项目发现与推荐产品，它主要针对面对庞大的 Github 项目无从下手的痛点问题，这个项目每天会给你推荐一个值得收藏的 AI 相关的 Github 。它把 GitHub 项目的采集、评分、审核和推荐串联成一个完整的推荐闭环。

我让 Qwen3.7-Max 给我分析了一下目前这个项目的实现细节。

PreHub 里面有 Next.js 前端，有 Go 写的 API 和 worker，有 PostgreSQL 数据库，有 GitHub 项目采集、候选评分、每日推荐、Radar 趋势看板，还有 Vercel 上的多服务部署和定时任务。

这次我想测的也很明确：

Qwen3.7-Max 能不能在一个真实项目里，完成一次从理解项目、发现问题、规划修复，到最后验证结果的 Agent 工作流。

我先测试了一下它对 PreHub 工程结构的理解能力。

这个页面看上去比较简单。

GitHub 项目会进入候选池，系统会做评分和分类，管理员可以审核，审核后的项目会进入每日推荐，Radar 页面还会关注项目的趋势变化，比如 star 增长、项目活跃度、近期是否值得关注。

它需要模型同时理解页面、接口、数据、任务调度和部署限制。

比如 Vercel 上的定时任务怎么跑？

Go API 和 Next.js BFF 是怎么连起来的？

Radar 页面展示的数据，是全量 GitHub 项目，还是 PreHub 自己的采样池？

这些问题如果模型没看懂，那后面它写出来的东西也不能用。。。。。。

接着，我让 Qwen3.7-Max 分析了一下项目目前存在的问题。

从这次实际测评可以看出， Qwen3.7-Max 对于工程化纠错和优化方面做的非常不错，亮眼的在于分类，不像其他模型，会把很多缺陷和问题挤在一起，Qwen3.7-Max 能够清晰的显示不同场景和问题。

而我用 GPT5.5 和 Opus 4.8 ，他们只能罗列一些具体的代码问题，但没有问题归类和问题场景。

因为这个 GitHub 雷达和推荐项目，平常基本上都是我自己用。

所以有些场景没有做的很完善。

比如管理员、缓存、异常状态、数据口径说明这些地方，都还有优化空间。

我先是针对前面发现的几个场景进行修复。

这一步里，Qwen3.7-Max 有一个挺像工程协作的样子了。

它没有直接上来一顿改。它会先问我是要直接执行，还是先输出一份 Spec 文档，把方案写清楚之后再继续。

我选择了先让它出 Spec。

这个过程我觉得挺符合 Qoder CN / QoderWork 这类工具的使用方式。

大家可以看看 Spec 的输出结果。

Qwen3.7-Max 输出的 Spec，不只是普通的需求说明。

Qwen3.7-Max 输出的 Spec 和其他 LLM 不一样，它直接把代码都给你输出到 Spec 文档中了，不像其他 LLM，会先写方案，然后具体的执行过程只能靠 LLM 自身。

Qwen3.7-Max 这种执行方式我觉得有一点好，它的输出非常明确，不同 LLM 不用再自行根据概念来判断具体要写什么代码了，它直接告诉你代码这么写就完了。

而且更重要的是，在它进行优化的时候，它对于大规模代码结构的理解和安全重构能力比较突出。

我把它提出来的问题也拿其他模型验证了一下，结论基本能对上。

---

前面的项目分析和 Spec，已经能看出它的工程理解能力。

如果只是让它分析项目，那最多证明它会看代码和改代码。

真正要测 Qwen3.7-Max 的 Agent 能力，还是要让它跑一个从开发到测试到验证的完整长链路任务。

刚好 PreHub 上线之后，我发现搜索页有个不小的问题。

搜索支持精准搜索和模糊搜索，精准搜索是匹配全路径 URL，而模糊搜索是你可以指定关键字进行搜索。

但是当我搜索类似 Next.js 这种关键词时，结果并不理想。

我给 Qwen3.7-Max 的要求也比较明确。

我没有让它直接改。

我要求它先复现问题，再定位链路，再输出修复方案，确认之后再修改代码，最后必须跑测试和浏览器验证。

这个长请求最终确实把问题修复了。

修复之后，我在本地搜索 Next.js，已经能返回结果了。

第一条就是 vercel/next.js。

而且页面下面会明确告诉用户：

当前是关键词模式，只搜索 PreHub 已收录的候选库。

如果你要查找任意 GitHub 仓库，请输入 owner/repo 或完整 GitHub URL。

这个结果就比较符合预期了。

因为这个搜索，并不是实时 Github 全域搜索，而是本地入库的全局搜索。这是当时的设计问题，不是 Bug 。

Qwen3.7-Max 这次比较稳的地方在于

它始终围绕同一个目标推进：

让搜索链路更稳定。

让用户知道不同搜索模式的边界。

让修复结果能被测试和浏览器验证。

我整体使用下来，还是觉得非常不错。

---

最后给大家总结下。

我觉得 Qwen3.7-Max 的突出优势是它在真实工作流里的稳定性。

它不会根据我一句“搜索有问题”就开始自行改代码。

它先把 PreHub 的结构摸清楚了，前端是什么，后端是什么。

搜索链路中间还有 Next.js API route、Go handler、数据库全文检索和 GitHub 精确仓库拉取。

Qwen3.7-Max 对工程理解能力还是不错的。

这次我比较明显能感受到，它没有上来直接说我给你改好了。

它会先判断问题类型，再拆执行路径。

哪些地方需要代码修复。

哪些地方只是产品文案要说清楚。

哪些地方不能乱动，比如生产密钥、Vercel 后台、真实数据库。

这就是我觉得 Qoder CN / QoderWork 这类工具配合 Qwen3.7-Max 用起来比较顺手的地方。

它在拿不准方案的时候，会向人征求决策判断。

问题定位和修复能力。

搜索这个问题看起来比较简单，就是 Next.js 搜不到。

但它最后定位出来的不是一个 SQL 模糊搜索的问题。

它区分了两条链路：

owner/repo 和 GitHub URL 是精确仓库搜索，可以实时拉 GitHub 元数据。

Next.js、react、AI agent 这类关键词，是搜索 PreHub 已经收录的本地候选库。

它没有简单把 Next.js 硬塞成一个特殊规则，而是同时处理了后端分词、搜索兜底、前端空状态和页面解释。

跨文件修改能力。

这次修复它涉及到了前端搜索页、服务端数据获取、Go 搜索接口、数据库搜索逻辑、领域类型和测试。

这更接近你真实生产环境的工作流。

第五，是长程端到端验证。

它没有写完代码就停了。

它补了 Go 测试，覆盖 Next.js 分词、owner/repo 识别、GitHub URL 识别、普通关键词不误判等情况。

然后继续跑：

go test ./...
npm run lint
npm run build

最后再回到浏览器里看修复效果。

本地搜索 Next.js 已经能返回结果，第一条就是 vercel/next.js，页面也能明确解释关键词模式和精确仓库模式的区别。

所以如果用一句话总结这次体验：

Qwen3.7-Max 这次体现出来的，是在真实项目里持续推进任务的能力。

对我来说，这才是日常工作流里真正有价值的 Agent 能力。