当 AI 在聊天中解决不了问题，如何优雅地“一键转 Issue”
不是所有问题都该立刻变成 Issue
但所有“解决不了的问题”，都应该被正确记录下来
一、背景：Issue 不应该是“问题的起点”
在很多团队里，GitLab Issue 的现状是：
- 🤯 问题一出现就先提 Issue
- 📋 Issue 里是聊天记录、截图堆砌
- ❓ 问题是否真实存在、是否可复现，其实并不清楚
- 🧑💻 开发者一边查问题，一边“反向补全 Issue”
但在 AI 出现之后，我们开始反思一个问题：
Issue，真的应该由“人一开始就写”吗？
二、我们想要的理想流程
我们重新设计了一个更符合真实研发心智的流程：
- 开发者 先问 AI
- AI 基于企业知识库（RAG）进行解答
- 如果问题被解决 → 结束
- 如果 AI 明确无法解决
- 👉 将完整上下文整理为一个高质量 Issue
- 人工确认 / 编辑
- 提交到 GitLab
Issue 不再是“提问工具”，而是“问题沉淀工具”
三、整体方案架构
1️⃣ 核心组件
- VS Code 插件
- 聊天窗口
- AI 回答展示
- 「转 Issue」按钮
- MCP AI 服务
- 对话上下文管理
- RAG 检索
- Issue 结构化整理
- RAG 知识库
- 内部文档
- 历史 Issue
- 设计文档 / FAQ
- 企业私有 GitLab
2️⃣ 架构示意（文字版）
┌──────────────────────────┐
│ VS Code Plugin │
│ │
│ Chat UI │
│ ├─ 用户提问 │
│ ├─ AI 回答 │
│ └─ 「整理为 Issue」按钮 │
└────────────▲─────────────┘
│ MCP
┌────────────┴─────────────┐
│ MCP AI 服务 │
│ │
│ - 会话管理 │
│ - RAG 检索 │
│ - Issue 结构化 │
└────────────▲─────────────┘
│ 内网
┌────────────┴─────────────┐
│ 企业 GitLab │
└──────────────────────────┘
四、聊天优先：VS Code 中的 AI 助手设计
1️⃣ 为什么一定是“聊天窗口”？
原因很简单：
- 开发者已经习惯：
- 问问题
- 描述上下文
- 逐步补充信息
- 聊天是最低成本的交互方式
- AI 最擅长的也是多轮上下文理解
2️⃣ 一次典型对话流程
Q：某个列表页在数据量大的时候特别卡，怎么优化？
A：基于你们的框架和历史方案，可能原因有……
Q：我按你说的试了，还是不行
A：当前信息不足，建议进一步确认……
此时，AI 会给出一个明确的状态：
“当前问题无法直接解决，建议整理为 Issue”
五、RAG：为什么这是“企业级”的关键
1️⃣ 没有 RAG 的 AI，有什么问题？
- 不知道你们的：
- 技术栈
- 组件库
- 内部约定
- 回答容易：
- 泛化
- 不落地
- 和实际方案冲突
2️⃣ 我们的 RAG 数据来源
RAG 知识库并不追求“大而全”，而是高度贴近真实研发：
- 历史 GitLab Issue（已关闭）
- 内部技术文档
- 常见问题 FAQ
- 组件库 README / 设计文档
AI 回答的不是“通用知识”，而是“你们团队的经验”
六、兜底能力：从聊天到 Issue 的“智能转换”
1️⃣ 什么时候出现「整理为 Issue」按钮？
不是一开始就有，而是满足以下条件之一：
- AI 多轮尝试后仍无法给出解决方案
- 问题明显涉及：
- Bug
- 性能
- 需求缺失
- 用户主动点击「转 Issue」
2️⃣ Issue 并不是“直接生成”
这是整个方案里最重要的设计点：
❌ 不是：AI 自动提交 Issue
✅ 而是：AI 整理 Issue 草稿
3️⃣ AI 会整理哪些内容？
MCP 服务会基于完整对话上下文生成：
- Issue 标题（高度概括）
- 问题背景（来自对话）
- 已尝试方案（非常关键）
- 当前结果
- AI 判断的可能方向
- 推荐标签 / 优先级
4️⃣ Issue 结构示例
## 问题背景
在数据量超过 5000 条时，列表页面渲染明显卡顿。
## 已尝试方案
- 虚拟列表
- 节流滚动事件
- 减少 Watch 监听
## 当前问题
卡顿问题仍然存在，怀疑与组件内部实现有关。
## 补充说明
问题经过 AI 辅助排查，暂未找到明确解决方案。
七、人工确认：企业级 AI 的“安全阀”
为什么一定要人工确认？
因为在企业环境里：
- Issue = 成本
- Issue = 排期
- Issue = 责任
我们坚持一个原则：
AI 只负责“整理事实”，不负责“发起决策”
VS Code 中的确认能力
- 编辑标题 / 描述
- 补充截图 / 日志
- 修改标签
- 最终点击「提交到 GitLab」
八、GitLab 接入与安全设计
- GitLab Token 仅存在 MCP 服务
- VS Code 插件无写权限
- 所有提交都有：
- 操作日志
- 来源标记（AI Assisted）
这保证了：
- 安全
- 可追溯
- 可审计
九、落地效果：Issue 质量发生了什么变化？
📈 真实变化
- Issue 平均信息完整度 ↑
- Issue 反复追问 ↓
- “无效 Issue” 明显减少
- 开发者更愿意使用 Issue，而不是逃避
🧠 更重要的变化
- 团队习惯变成：
- 先问 AI
- 再决定要不要提 Issue
- Issue 从“情绪输出”，变成“问题总结”
十、这个方案还能怎么扩展？
同一套架构，可以自然扩展到：
- 聊天 → 自动生成 MR 描述
- 聊天 → 生成复现用例
- 聊天 → 测试点建议
- 聊天 → 技术债 Issue
RAG + MCP + VS Code，本质是研发流程的智能中枢。
十一、总结
AI 不应该制造更多 Issue，而是减少不必要的 Issue。
通过：
- 聊天优先
- RAG 提供“企业记忆”
- Issue 作为兜底沉淀
- 人工确认作为安全边界
我们终于让 AI：
- 真正进入研发流程
- 又不破坏原有协作秩序
这不是一个“炫技型 AI 功能”，
而是一个能长期在企业里活下来的工程方案。
文章评论