Qwen Code 改进建议

April 5, 2026 · View on GitHub

核心洞察：对于任何处于快速迭代期的 AI 编程工具而言，真实开发者的隐式使用数据（Telemetry）虽然有用，但无法替代用户在遇到恶心 Bug 或惊艳时刻的“显式主观反馈”。当代码 Agent 帮倒忙时，由于缺乏及时的情绪宣泄出口，沉默的大多数用户往往会直接卸载离开。Claude Code 在其终端 CLI 中内置了 /feedback 指令和一套基于 React Ink 的高颜值评分与表单弹窗系统，甚至能附带传输会话上下文；而 Qwen Code 目前若要反馈，只能要求用户跳出终端，去浏览器里提交繁琐的 GitHub Issue。

返回 改进建议总览

一、反馈路径太长导致的样本流失

1. Qwen Code 现状：极其陡峭的反馈门槛

当用户在使用 Qwen Code 遇到如下场景：

  • 大模型不仅没修好 Bug，反而把整个文件清空了。
  • 此时用户很生气，想向官方吐槽“你们的模型处理长文件有严重 Bug”。 痛点：用户必须打开浏览器，登录 GitHub，寻找 Qwen Code 的仓库，点击 New Issue，然后还要手动复制刚才的 Terminal 报错日志贴上去。这长达 5 分钟的摩擦力，会让 99% 的用户选择放弃反馈，导致官方团队永远不知道模型在哪些边缘 Case 下表现糟糕。

2. Claude Code 解决方案：触手可及的终端调查

在 components/FeedbackSurvey/FeedbackSurvey.tsx 中，Claude Code 直接将反馈表单搬进了黑底白字的命令行中。

机制一：无缝的 /feedback 交互

用户只需在命令行中敲击 /feedback。 终端界面会瞬间变成一个由键盘驱动的评分组件（Score Selector，通常是 1-5 选档）。 打分后，会展示一个原生的多行文本输入框，用户可以像打字聊天一样直接键入：“刚才重构 React Hooks 时模型把依赖数组写丢了”。

机制二：一键附带 Transcript (会话上下文)

由于很多 Bug 是模型上下文引起的，单纯的文字吐槽很难复现。 Claude 在反馈表单最后，提供了一个 Consent 选项：“是否同意将当前长达 2 万字的代码修改会话（Transcript）一并发送给官方用于调试？”（shouldShowTranscriptPrompt 逻辑）。如果同意，系统自动将其脱水打包 POST 到远端诊断 API。

二、Qwen Code 的改进路径 (P3 优先级)

倾听用户声音的距离越短，产品进步的速度就越快。

阶段 1：设计终端反馈表单 UI

  1. 在 packages/cli 新增 FeedbackSurvey.tsx Ink 组件。
  2. 包含基础的 Radio 选项（比如 1: 极其糟糕 - 5: 完美解决）。
  3. 包含一个供自由抒发的 TextInput。

阶段 2：提供 /feedback 指令接入

将这个组件挂载为系统全局 Slash 命令。当用户执行 /feedback 时，阻塞当前的正常对话流，渲染反馈表单。

阶段 3：构建远端接收池

由于 Qwen Code 是开源项目，除了发向自建服务器，也可以利用 octokit：

  • 在收集完用户的打分和文字后，调用 GitHub API，以一个特殊的机器人账号将用户的反馈自动转化为 Qwen Code 仓库中的一个内部 Issue，甚至附带上脱敏后的运行日志 Gist 链接。

三、改进收益评估

  • 实现成本：小到中等。涉及前端组件设计和向后端 / GitHub 发送数据的接口封装，代码量约 200 行。
  • 直接收益：
    1. 海量的高质量负向反馈：因为摩擦力极低，团队能收集到远超平时 10 倍的用户真实吐槽，成为优化大模型微调训练（SFT/RLHF）的无价资产。
    2. 产品温度感：在终端内直接与官方对话，会让开发者感受到这是一个有生命、有人在维护的优质工具社区。