Qoder CLI + Harness Engineering 实战：构建 7×24h 无人值守用户反馈自动处理系统

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/qngZyrzHYWM8wjYz4ovHXw

摘要

背景介绍在 Qoder 产品家族不断壮大和用户量持续提升的背景下，用户对各个 Qoder 产品的反馈和建议也日益增多。然而，之前的反馈处理流程完全依赖人力：运营人员负责从反馈渠道导出 Excel 数据，清洗、分类后再手动录入到项目管理系统，最后由研发人工分析日志、定位问题。这套流程的痛点非常明显——运营陷在问题录入和分派的重复劳动中，而研发人工分析日志每个问题至少需要 30 分钟以上，遇到复杂问题耗时更长。随着反馈量的增长，人力瓶颈越来越突出，大量反馈积压得不到及时响应。我们的目标很明确：构建一套 7×24 小时无人值守的用户反馈自动处理系统——从反馈提交到问题分类、聚类、...

核心内容

背景介绍

在 Qoder 产品家族不断壮大和用户量持续提升的背景下，用户对各个 Qoder 产品的反馈和建议也日益增多。然而，之前的反馈处理流程完全依赖人力：运营人员负责从反馈渠道导出 Excel 数据，清洗、分类后再手动录入到项目管理系统，最后由研发人工分析日志、定位问题。

这套流程的痛点非常明显——运营陷在问题录入和分派的重复劳动中，而研发人工分析日志每个问题至少需要 30 分钟以上，遇到复杂问题耗时更长。随着反馈量的增长，人力瓶颈越来越突出，大量反馈积压得不到及时响应。

我们的目标很明确：构建一套 7×24 小时无人值守的用户反馈自动处理系统——从反馈提交到问题分类、聚类、日志分析、甚至代码修复，全部由 Agent 自动完成，人只需要在最后环节对 Code Review 做终审。

产品方案

为此，我们设计了一套新的 issue 处理后台，整体分为四个核心模块，按流水线顺序串联：

问题分类：用户提交反馈后，系统首先自动过滤无效数据，将有效反馈分为产品建议和缺陷反馈两大类，并对缺陷反馈进一步判定业务领域细类。这一步替代了运营人员手动分类录入的工作。
问题聚类：在分类基础上，系统对相似问题进行聚合。这样可以减少重复问题的干扰，让后续的高级分析环节聚焦在真正需要处理的问题上，而不是被同一个 bug 的 N 条反馈淹没。
日志分析：针对需要深入排查的缺陷，系统结合代码库自动分析日志、提取用户操作轨迹、定位根因，并给出修复建议。这一步替代了研发逐条人工分析日志的工作。
自动修复：对于 AI 有较高把握能修复的问题，系统自动生成修复代码并创建 Code Review，由人工做最终评审。

在人机协作的边界设计上，我们的原则是：分类、聚类、分析这些环节完全交给 Agent 自动处理；代码修复环节由 Agent 完成编码，但保留人工 Code Review 作为质量关卡。Agent 负责吞吐量，人负责把关质量。

技术实现

**
**

为什么选 Qoder CLI

我们整套系统的 AI 能力层全部基于 Qoder CLI 实现。之所以选择 CLI 形态而非直接调用模型 API 或使用其他 Agent 框架，核心原因有几个：

对于 Harness Engineering 这种 7×24 持续运行的场景，CLI 的随时启停、并发友好、进程隔离特性尤为关键。直接调模型 API 需要自己管理工具调用、上下文窗口、重试逻辑等大量基础设施代码，而 Qoder CLI 把这些全部封装好了，我们只需要专注于业务编排。

环境准备

在服务端应用的 Dockerfile 里增加 Qoder CLI 的安装脚本：

-

RUN curl -fsSL https://qoder.com/install | bash

然后在 https://qoder.com/account/integrations 复制 Access Token，并配置到环境变量 QODER_PERSONAL_ACCESS_TOKEN 中。这样就可以在服务端的代码里通过子进程调用 Qoder CLI 了。

调用时通过 -p 参数传入 prompt，启用无 TUI 交互的 headless 模式。其他一些常用的参数：

--yolo：自动确认模式，无需人工交互
--model：模型分级选择，效果越好的模型也越贵
--output-format=json：结构化输出，便于程序解析结果，观察思考过程
--worktree：独立工作区，避免多任务写文件冲突
--max-turns：限制最大轮次，防止无限循环浪费 tokens

问题分类

当用户提交反馈数据后，首先利用 Qoder CLI 对问题做初步分类。在这个单轮任务中，Qoder CLI 完成的事情包括：

过滤掉无具体反馈信息的无效数据
对剩下的问题分为产品建议和缺陷反馈两个大类
对缺陷反馈判断是否为有效缺陷
对有效缺陷进一步判定业务领域细类

此轮任务对模型能力要求不高，不需要深度思考，--model 用 Effective 就够了，能够节省不少成本。

问题聚类

在对 Qoder CLI 的结构化输出做解析后，我们得到了问题的分类。在不同的 category 维度下，会再进行一轮相似度匹配和聚类生成的任务。

聚类采用 Qoder CLI 做 LLM 语义化理解，而没有用传统的文本相似度算法。原因在于：相同问题可能有截然不同的描述方式，同时还需要结合用户的截图一起理解，纯文本匹配难以胜任。

在此轮任务中，我们利用 Qoder CLI Auto 模型分级的多模态能力，对截图、用户描述以及客户端环境信息进行综合分析，生成用于与已有活跃问题库进行聚类的元数据，并将这些数据传递给另一个 Qoder CLI 子进程进行聚类处理。

为了保证聚类效果，给大模型的上下文长度需要控制在一定范围之内，以免造成记忆力和注意力下降。因此我们设置了一个动态时间窗口来淘汰旧的聚类问题，根据问题的新鲜度结合时间衰减系数来提高命中正确聚类的准确性。

由于 Auto 模型分级的能力范围有限，对其输出的聚类结果我们还需要进一步动态调优。我们会让 Qoder CLI 输出一个问题相似度数据，在实际操作中可以动态调整阈值来调节聚合效果。更进一步，我们还可以用高级模型设置一个 Harness 工程系统里的「巡检员」来对聚合效果做抽样复查，根据质检结果给出相似度阈值的调整方向建议。

日志分析与根因定位

完成问题分类和聚类之后，进入更深层次的技术分析环节。此轮任务的目的是结合代码库分析日志、提取用户操作轨迹、定位根因。

这里采用Qoder CLI的性能模型，充分利用了 Qoder CLI 的 Agent 自主能力和丰富的工具调用能力。代码库和日志的体积通常非常大，全部用 read 工具读取反而会造成效果下降。Qoder CLI 在这里会聪明地根据问题描述用 grep 工具高效搜索相关内容，还会在没有提示的情况下自主规划用 web_search 工具查询 VS Code 上是否有同样的问题反馈。

在任务结束之前，我们要求 Qoder CLI 对此次任务做一次回顾复盘：是否能用更少的工具调用轮次来找到根因？本次的操作步骤里有哪些环节是无效的、可以避免的？有哪些经验教训是可以总结、避免下一次任务再犯错的？

这个总结反思的数据会单独写到一个 task-retro.md 文件里，由另一个负责流程改进的 Pipeline Agent 定期根据这份经验总结来更新对应的 Skill 内容。整个过程形成一条清晰的进化链路：

这个闭环让系统具备自我进化能力，对应了 Harness 里的 Critic → Refiner 反馈循环：每次 Agent 犯错都是一个信号，如果同一类错误反复出现，说明 Harness 本身有缺口。与其靠人去发现这些缺口，不如让系统自己分析、自己修补。

自动修复

在日志分析任务中，我们会让 A

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充