AI 拆解百万工单：小团队如何用大模型搞定 Jira 迁移

当 Jira 里的工单突破百万，项目数达到 245 个，你的第一反应是什么？

Tripadvisor 的工程师们面对的就是这样一个烂摊子。十年间每个团队都在 Jira 上做自己的决定，结果就是——数据根本没统一过。拿苹果和橙子比？不，我们是在拿苹果、橙子、葡萄、香蕉一起比。

他们曾试图标准化，但都失败了。不是不努力，而是规模太大。没有数十人的分析师团队和几个月的时间，根本理不清十年间的组织使用模式。

答案是用 2020 年代的思维方式解决问题。

用 AI 做数据侦察

过去不敢问的问题，现在终于能问了：哪些项目还在活跃？哪些字段根本没人填？每个项目的字段空置率有多高？如果删掉某个字段，谁会受影响？

团队写了一系列脚本——不是手动编码，而是把目标和约束条件告诉大模型，和它一起迭代出方案。核心思路：数据量太大装不进 Excel，所以必须分批次采样分析。

通过 Jira API 拉取所有项目的 schema 数据（字段、工作流状态、最近 500 条工单抽样），输出了每个项目的字段使用报告。然后用颜色编码的 Excel 表格呈现给每个团队：橙色 = 安全可删，红色 = 有数据但纳入删除范围，需要团队确认。

关键转折：不是让团队信任我们的判断，而是把数据摆在他们面前。当团队看到自己五年前坚决要求加的字段实际使用率为 0%，看到同一条信息在多个字段重复录入时，他们对迁移的态度从抗拒变成了兴奋。

设计新的 Jira

目标很明确：

• 统一工单类型、字段、工作流，让分析数据更干净，AI 辅助更有效
• 简化工作流，去掉不必要的状态和转换

最终确定的标准工作项：initiative、epic、story、task、bug、incident。工作流只保留必要状态，并做了最小化的转换逻辑。对于有特殊需求的团队，创建了分层配置方案——基于通用方案衍生，方便日后全局变更。

为了改善研发效能指标，强制要求：

• 所有工单必须填写 Story Point（故事点）
• 所有工单必须关联 epic，且每个 epic 必须绑定成本中心

团队担心开发者会忘记填 Story Point？那就用 AI 来自动估算。当工单进入“进行中”状态而 Story Point 为空时，AI agent 读取工单描述，对比全组织历史数据表格，给出估算值并添加标签和注释。效果好，团队也接受了。

组织沟通的艺术

迁移最大的风险不是技术，是人。一个小团队要说服上百个工程团队放下用了十年的流程。

策略一：拆解沟通。针对不同群体发送不同侧重的消息（全员 vs 项目管理员 vs 超级用户）。消息反复出现在固定频道，并配合计算好的跟进节奏。

策略二：路演。对拥有异常工作流的团队，不是强硬推行，而是像销售一样卖新方案的好处。结果大部分团队主动同意迁移。

策略三：数据驱动的调查问卷。对低风险团队，直接发问卷+字段可视化表格。团队几分钟就能判断哪些字段对自己是关键。这彻底改变了对话模式。

关于教育，团队甚至还做了个水管工主题的趣味学习模块，以及用 AI 生成的摇滚乐队讲解故事点的漫画。开发者平时懒得看邮件，但可爱有趣的内容他们愿意点开。

迁移中的弯道

进入实际迁移后，立刻遇到问题：Jira 的批量操作 UI 上限 1000 张工单，而有些项目有 4 万张需要迁移。如果一条一条操作，时间从几周变成几个月。

团队再次求助 AI。在一个电话会议里，把问题描述给大模型，定义约束（API 调用频率、批大小等），会议结束前就有了脚本雏形。最终用这个脚本迁移了超过 10 万张工单。

还有 44 张工单怎么都迁不过去。用 AI 写了一个调试脚本，拉出这些工单的关键字段，发现它们描述字段存在超长文本（18000-30000 字符）。这是 Jira 的隐藏字符限制。诊断只花了十几分钟。

迁移结果

• 84 个项目完成迁移
• 22 个项目因关键业务暂不变更
• 139 个项目设为只读，年底归档
• 全部 245 个项目归档清晰

更重要的成果：所有活跃工程项目的 Story Point 有值、工单都关联 epic。这些信号让研发效能指标第一次有意义。

新系统的分层配置方案意味着：今后任何流程变更，只需在少数几个地方修改，无需逐项目手动调整。配置漂移的问题被根除。

总结：AI 不是替代思考，而是降低提问成本

这个让组织困扰多年的项目，在一个季度内完成。不是 AI 替我们做了工作，而是 AI 让大规模分析变得可能——那些过去因为成本过高而无法问的问题，现在终于能问了。

对面临类似困境的人：你不需要几十人的分析师团队和一年的项目周期。你只需要正确的问题，以及一个能帮你快速找到答案的 AI。

感谢 Hector Sanchez 和 Olivia Malcolmson 在 Jira 配置解读上的帮助。