Issue Tracking System（问题跟踪系统）是团队唯一的"问题总台账"：所有缺陷、任务、请求都在这一个地方被记录、指派人、跟踪到关闭。选型只看四件事——问题怎么进来、状态怎么流转、谁看得到、按你们的席位数要花多少钱。
很多人是按功能清单选型的，上线半年才发现工具本身没问题，坏的是入口：问题以聊天消息的形式进来、截图散落在文件夹里、一句"你看下这个"就没了下文。没人说得清还有多少没关，台账里只剩下别人愿意重新录一遍的那几条。
这篇讲两部分：真正决定选型的 9 条标准，以及几乎所有对比文章都跳过的那一步——问题是怎么进来的。
Issue Tracking System 到底是什么
问题跟踪系统（也叫 issue tracker、问题管理系统；范围更窄时叫 bug tracking system 或 defect tracking system）只做四件事：
- 采集：把一个问题记录到"别人能直接动手"的详细程度。
- 跟踪：状态从"新建"走到"关闭"，谁改过什么有历史。
- 度量：回答"还开着多少、压了多久、堆在哪个环节"。
看板、Sprint、路线图、SLA、自动化，都是这四件事之上的附加层。采集和度量弱，看板做得再漂亮也救不回来。
问题跟踪系统 / Bug 跟踪系统 / 工单系统，差在哪
这几个词在厂商嘴里是混着用的，实际差别在范围：
| 系统 |
典型范围 |
通常归谁管 |
| 问题跟踪系统 |
一切需要"做决定"的事：缺陷、任务、需求、疑问 |
产品 / 研发 |
| Bug 跟踪系统 / 缺陷跟踪系统 |
只有缺陷，通常绑定某个版本或测试轮次 |
QA |
| 工单系统 / 服务台 |
外部用户进来的请求，带响应时效承诺 |
客服 / IT |
| 测试管理工具 |
用例、执行记录、结果，缺陷挂在用例上 |
QA |
按范围选，不要按厂商品类选。 从 bug 跟踪起家的团队，一年内基本都会需要问题跟踪系统；一上来就上完整服务台的团队，通常会被流程仪式感拖死。
如果你要的是缺陷全生命周期视角（严重级、验证、回归），看缺陷管理软件对比。这篇讲的是通用台账。
决定选型的 9 条标准
先排序，再试用。 顺序比答案重要。
| # |
标准 |
为什么它决定成败 |
具体看什么 |
| 1 |
入口（采集） |
台账的质量上限＝进去的东西的质量上限 |
不懂技术的人能不能一键提交？报告是否自带标注截图、Console 报错、失败请求、浏览器/系统/分辨率？ |
| 2 |
工作流 |
太死会被绕过，太松等于没有状态 |
加一个状态要不要请顾问？每次流转有没有留痕？ |
| 3 |
字段 |
严重级和优先级不是同一个字段 |
severity（技术影响）与 priority（业务紧急度）是否分开？能否按项目自定义？ |
| 4 |
查重 |
重复单是分诊卡住的第一原因 |
输入标题或页面 URL 时能否即时搜索？合并时是否保留历史？ |
| 5 |
出站集成 |
台账必须能到人已经在看的地方 |
聊天（Slack / Teams）、代码仓库、发布记录，以及一个能把剩余场景都接住的通用 Webhook |
| 6 |
权限 |
外部报障人不能看到你们的全部 backlog |
访客角色是否只能看自己提的？能否按项目隔离可见性？ |
| 7 |
度量 |
算不出积压时长，就管不动队列 |
按账龄分布、按负责人负载、重开率、周期时间，且能导出 |
| 8 |
席位成本 |
席位账比功能表更能改变结论 |
按 5 / 20 / 50 席各算一次；只读用户、访客、报障人算不算席位？ |
| 9 |
退出成本 |
你至少会迁移一次 |
能否连附件和评论一起导出？有没有开放 API？ |
只要忽略第 1 条，这份 shortlist 在演示时会非常好看，第三周就会开始崩。
9 款问题跟踪系统对照（2026）
下面只写计费模式（免费版 / 按席位订阅 / 开源自建），不写具体价格——标价会变，区域定价也不同，请以官网为准。
| 工具 |
适合谁 |
问题怎么进来 |
计费模式 |
要留意 |
| Jira（Atlassian） |
需要可配置工作流、且已在 Atlassian 生态里的团队 |
手动表单、邮件、集成 |
有免费版，之后按席位订阅 |
配置债；很快会出现"管理员"这个专职角色 |
| Linear |
追求速度和键盘操作的产品团队 |
手动、Slack、集成 |
按席位订阅 |
强观点、强范式；不太适合非研发的请求队列 |
| GitHub Issues |
工作本来就贴着代码仓库的团队 |
手动、模板、API |
随仓库方案附带 |
非代码类请求弱，跨仓库汇总弱 |
| GitLab |
想把 issue、MR、CI 放一个平台的团队 |
手动、模板、API |
分级订阅，含免费自建版 |
不同档位之间功能切得很细 |
| YouTrack（JetBrains） |
喜欢用查询驱动视图、要自定义工作流的团队 |
手动、邮件、集成 |
按席位订阅，小团队免费 |
界面信息密度高；非技术报障人上手成本高 |
| Azure DevOps Boards |
微软技术栈、要用测试计划和流水线的团队 |
手动、流水线、集成 |
按用户订阅 |
只有把 Azure DevOps 其它部分也用上才划算 |
| Bugzilla |
长期维护、需要成熟自建缺陷库的项目 |
手动、邮件 |
免费开源 |
界面老旧；报表靠插件 |
| Redmine |
有运维、要模块化和完全掌控的团队 |
手动、邮件 |
免费开源 |
插件容易失控；升级是真活儿 |
| MantisBT |
想要简单自建跟踪器的小团队 |
手动、邮件 |
免费开源 |
自动化弱，现代集成少 |
这 9 款都不是坏工具。真正的失败模式是：为了工作流引擎选了它，然后把入口留给了复制粘贴。
几乎所有选型都跳过的一步：问题是怎么进来的
上面每一款工具都默认"问题已经被描述清楚了"。而现实里，时间恰恰全花在描述上：
- 测试同学写一句"结算按钮没反应"，开发要问三个问题才打开 DevTools；
- 截图留在聊天记录里，和页面 URL、浏览器信息彻底脱钩；
- 真正说明问题的 Console 报错没人采到——报障人根本不知道 Console 是什么；
- 复现不了，于是"在我这儿是好的"关掉，两个 Sprint 后又回来。
对比一下两种报告到手时你手里有什么：
| 修一个问题需要 |
手工描述 |
自带上下文的报告 |
| 在哪出的问题 |
"结算页，好像吧" |
精确 URL 与页面标题 |
| 点了什么 |
报障人的一句话 |
标注截图指出元素，并带 selector |
| 错在哪 |
"就是不工作" |
Console 报错与失败的 Network 请求，原文照录 |
| 环境 |
"Chrome，可能是 Mac？" |
浏览器、系统、分辨率、时间戳 |
| 谁能复现 |
谁都不能，直到报障人再空一次 |
拿到链接的人立刻能复现 |
这正是 BugCapturer 覆盖的一层，而且故意不做成 tracker：测试同学用浏览器扩展采集（截图、标注、标签页录屏），外部用户通过内嵌 Web SDK 提交、什么都不用装，每份报告自动带上 Console 与 Network 上下文。报告流向 Slack、Microsoft Teams、飞书多维表格，或你自己的 Webhook——也就是说，入口层给上面选出来的任何一款 tracker 供料，而不是跟它抢主系统。免费版含 1 个席位、3 个项目、1 个集成，Console 采集永不设限；其余见价格页。
对大多数团队最省事的分工是：tracker 负责决策，采集层负责收齐。 Tracker 管状态、归属和历史；采集层保证每一条进来就是完整的。
一套 60 分钟能跑完的选型流程
写下"入口那句话"（10 分钟）：「一个 [角色] 报一个 [类型的问题]，必须在 [N] 次点击内提交完成，并附带 [这些材料]」。两款工具里有一款满足不了这句话，直接出局。
列出你们真实的三条队列（10 分钟）：不是假设的，是今天问题实际堆积的地方（客户群、QA 表格、客户邮件）。每条都要有入口。
给 9 条标准打分（15 分钟）：每条 1–3 分，入口和度量双倍权重。同分时，通常由第 9 条（退出成本）决定。
拿昨天最难搞的一个真 bug 走一遍（15 分钟）：不要用厂商的演示脚本。从提交到开发看懂，掐表，并数一下开发要追问几个问题。
按 12 个月、20 席位算钱（10 分钟）：把管理员工时折进去。一个"免费"的自建工具，如果每周要花一小时维护，它就不免费。
成本到底怎么算
账单由三个数决定，而只有第一个写在价格页上：
- 席位 × 月数：注意"席位"的定义。如果外部报障人、只读用户也占席位，真实成本远高于人头数。
- 集成与自动化附加费：很多"便宜档"会对自动化次数、API 调用、集成数量计费——而这些恰恰是 tracker 有用的部分。
- 管理成本：设计工作流、清理字段、合并重复单，是持续投入。每月留几个小时，否则台账会烂掉。
对小团队来说，免费版是一个合法的终局，不只是试用期。如果你只有一到五个人、跟的是几个 Web 项目，一个轻量采集工具＋一个聊天频道完全可以替代 tracker——而且你会真的持续用它，这才是唯一重要的指标。
迁移清单
换 tracker，本质上不是字段问题，是附件和评论问题。
- 导出全部：issue、评论、附件、关注人、状态历史。
- 状态映射到目标系统的状态，不要一一对应——你需要的状态几乎总比现在少。
- 迁移前先决定：12 个月以前的已关闭单，搬还是留。
- 先切集成，再邀请用户；反过来的顺序会产生一周的重复通知。
- 切换后回头验一遍入口：搞死一次迁移最快的方式，就是把报障按钮弄坏。
常见问题
Jira 算问题跟踪系统吗？
算。Jira 是可配置的问题跟踪器，同时也覆盖项目与迭代管理。当工作流灵活性重要、且有人负责配置时，它是很稳的选择。
问题跟踪和 bug 跟踪有什么区别？
Bug 跟踪只管缺陷；问题跟踪管一切需要决策的事——缺陷、任务、请求、疑问，缺陷只是其中一种类型。大多数 bug 跟踪器最终都会长成问题跟踪系统。
小团队需要问题跟踪系统吗？
一到五个人，用聊天频道＋采集工具＋一张共享清单就能跑，前提是每一条都有负责人和状态。一旦出现"两个人说不清谁在修"，tracker 立刻回本。
能不能就用 Excel？
小范围、短周期的项目，表格是完全合法的台账。它会在你需要权限、通知、附件、以及"谁改过状态"的历史时崩掉——通常在第一个外部客户加入的时候。
最省钱的合理方案是什么？
用免费或低成本的工具负责采集（自动带 Console、Network、环境信息），再把报告推进你们本来就在付费的聊天或 tracker。成本接近零，数据质量比"全套装＋复制粘贴"好得多。
怎么让问题不再以聊天消息的形式进来？
让提交比打字发消息更快：一次点击、标注截图、自动环境，落点是团队本来就在看的地方。只要报障比抱怨更麻烦，人就一定会抱怨。